探究软件测试之明珠--精准测试

2017-03-07 15:27

目前的现实物质世界与软件构造的虚拟世界几乎处在同一维度，人的思维有多复杂，软件代码就有多复杂。不管是金融领域的核心系统还是工业嵌入式软件，动辄上亿行的代码量、几百万个函数，数百个进程，这样的研发与维护的工作量难度可想而知。所以，我们经常可以看到各种报道，比如程序崩溃造成几亿元的金融交易损失、机器人失控攻击使用者、智能生产线效率低迷等。尤其纵观全球工业智能化进程，中国工业在核心软件的研发能力尚较为薄弱，面临诸多挑战，常常被国外同行所诟病。奋起直追、打破技术壁垒不仅需要高层的战略重视，更需要软件核心研发部门与核心测试部门的在技术战术上的密切配合。
分析目前国内软件测试基本处于两种状态：一是绝大多数企业采用手工黑盒测试，二是部分对软件产品质量要求高的企业不得已去购买国外白盒测试工具。但这两种测试办法都有非常大的缺点。简单来讲：手工黑盒测试（从用例设计角度流行的自动化测试也总体属于该范畴），顾名思义测试者看不到程序内部结构，主要凭大量的测试用例及海量人工投入来减少事故发生的概率。这种办法对软件可靠性要求不高的应用来讲问题不是很大，但是对于大型金融保险、航天军工等关键系统就意味着时刻携带隐形的巨大风险。此间案例非常多，不再一一罗列。第二种办法是采购国外白盒测试工具。白盒测试工具一般重点应用在研发阶段的单元测试上，它对测试覆盖率的结果要求高，满足了客户的部分需求。但它的缺点也显而易见，暂且不说国外白盒软件采购与维护高昂的价格、学习周期漫长，我们仅从技术层面客观地看：它们普遍技术路线滞后，测试过程与源码捆绑不支持分布式测试、混合的覆盖率结果无法和具体用例关联和追溯、不支持不同版本覆盖率的累计、不支持回归测试用例的智能选取等等。
换句话说，您一个LISENCE花了几十万、上百万，只能单机使用，版本更新以后所有依赖于代码的测试数据就完全失效了。覆盖率结果无法对应到具体用例，很难通过覆盖率对应的程序逻辑分析用例缺陷的真实原因，用户只能花费大量时间进行间接排除法，更无法通过覆盖率得出各种精细化管理、快速发现缺陷的直接结果。传统白盒仅仅关注覆盖率，但从单元角度试图完成高水平的大型软件的覆盖已经非常不现实。软件质量保障问题如此重要，却长期得不到实质的突破性发展。
最近国内外软件测试领域中，崛起了一支新生力量“星云测试”（www.teststars.cc

余下全部

共有评论0条

<返回

<返回首页