软件测试不再黑盒threadingtest带来第二代白盒覆盖率关键技术.docx

软件测试不再黑盒— threadingtest带来第二代白盒覆盖率技术 穿线测试对于测试界一个重大创新在于，在白盒测试理论出现数十年以后，上海零一拼装信息技术结合在测试理论方面十余年潜心研究，率先提出了第二代覆盖率技术，这绝对不是一个口号，而是ZOA真正对于白盒测试了解和对于标准第三方测试服务深度了解经过数年基础研究和2年有余研发而推出达成商用标准技术。现在先让我们温习下经典测试理论： 1、测试方法论 黑盒功效测试法 黑盒功效测试法, 是把要测试软件看成一个 “黑盒子”, 不管其内部结构怎样和以什么算法实现所要求提供功效，而是根据需求功效化要求, 设计对应测试用例(包含测试输入数据和条件设置和所预期软件运行输出结果), 经过软件运行后所给出输出(包含字符形式输出和图象输出)和所预期结果进行人工或自动化比较, 来验证被测试软件是否能给出正确结果, 从而判定该软件是否满足需求, 是否和该软件系统规格说明书和用户手册相关部分一致。 这一方法优点为: (A) 能最直观和直接地反应出所设计软件是否满足需求; (B) 即使没有任何测试工具支援, 也能靠人工测试方法完成; 其不足之处是: (A) 这种测试方法难以找出一些特殊类型错误。比如: 当对应于某组输入该被测软件并不提供任何输出信息时 – 可能只是改变了某种工作状态,假如其中源代码处理部分有错误, 就比较难找出来； (B) 无法确定哪些测试用例有效或无效 (所谓无效, 并不是说单独使用某个测试用例时不能收到任何测试效果, 而是在于它和前面已经使用过测试用例一起使用时, 毫无贡献, 只是反复了前面测试用例已经完成测试)； (C) 含有没有可避免盲目性: 当软件被修改后, 因为不知道哪些测试用例能测试到被直接修改过模块或受修改过模块影响模块, 于是只好将全部测试用例再从头运行一遍, 而且是动态运行,很费时费力。 白盒结构测试法 白盒结构测试法则和黑盒子功效测试方法相反: 它不管所被测试软件是否满足需求,是否实现了所设计功效, 而只重视该软件内部结构, 方便设计足够多测试用例, 使得百分百或尽可能多程序组成要素能被测试到最少一次, 从而尽可能地将其中软件错误暴露出来。 白盒子结构测试方法优点: (A) 能够找出很多用功效测试方法找不出来软件错误; (B) 能够在整个软件系统还未完成之前就分别对各个单元进行测试; (C) 能够经过测试用例有效性分析而实现测试用例最小化, 方便大大地缩短软件修改后回复测试时间和费用; (D) 能够同时进行内存泄漏分析; (E) 能够同时进行分支实施频度分析; (F) 能够同时进行软件复杂度分析; (G) 能够同时进行数据和变量分析; (H) 能够同时进行性能分析; (I) 能够同时进行动态运行错误定位和实施路径追溯等。 白盒子结构测试方法缺点: （1） 必需经过专门测试工具来进行, 需要在用户软件拷贝上进行插桩（插入纪录点）统计各分支/条件是否被实施过或实施过多少次信息; （2） 会使被测试软件运行速度减慢; （3） 需要增加被测试软件运行时资源开销等。 相关软件质量误区 有不少软件开发组织和应用软件开发部门管理者错误地认为，她们已经对她们所开发软件做了充足功效测试(又称黑盒测试)了，认为我们软件质量没问题！ —— 不过， 教授们分析了大量经过充足功效测试软件后发觉，这些软件中还有大约二分之一程序分支从未被实施过！ 为何会这么？原来，软件功效描述相对来说很轻易、很简单、也很粗糙，无法具体到用软件内部具体实现逻辑结构来说明；而要达成一样功效，软件能够有许很多多等效实现方法；尤其是，软件功效实现，和所使用编写程序语言、所运行操作系统环境、所用到数据库和一些第三方软件全部相关系。实际上，一个软件中许很多多程序分支跟该软件本身功效并没有直接联络，而是用来处理多种可能出现运行情况。比如，所开发软件在运行中忽然被终止时(系统断电或用户打断)怎样保护已经打开文档；在系统资源用尽之前怎样提出警告；在所要用到一些文件被意外地删除了时怎样应付等等。这些程序分支在编写中一样存在着可能错误，必需加于测试。而这通常全部需要经过程序结构测试(又称白盒测试)来完成，而白盒结构测试是必需借助于软件测试工具才能进行。 ThreadingTest针对上诉质量误区情况在测试过程中对于一组输入，既判定其输出（假如有）是否和预期值一致，又判定其实施路径是否和预期值一致。这么一来，即使测试输出结果和预期值一致，也可能有错误被找出来 － 假如所预期实施路径和实际实施路径不一致。比如，当测试一个计算器程序时，假如输入是2＋2， 测到结果是4，也可能是个错误 － 假如它实施路径和预期值不一致：其最终结果可能是2×2路径输出结果。因为TT能够测试有输入而无输出场所（此时仅仅测试其实施路