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

穿线测试对于测试界的一个重大创新在于，在白盒测试理论出现数十年以后，上海零一拼装信息技术有限公司结合在测试理论方面十余年的潜心研究，率先提出了第二代覆盖率技术，这绝对不是一个口号，而是ZOA真正对于白盒测试的理解以及对于标准第三方测试服务的深度理解经过数年的基础研究以及2年有余的研发而推出的达到商用标准的技术。现在先让我们温习下经典的测试理论：

1、测试方法论

黑盒功能测试法：

黑盒功能测试法, 是把要测试的软件看成一个“黑盒子”, 不管其内部结构如何以及以什么算法实现所要求提供的功能，而是按照需求的功能化要求, 设计相应的测试用例(包括测试的输入数据与条件设置和所预期的软件运行输出结果), 通过软件运行后所给出的输出(包括字符形式的输出与图象输出)与所预期的结果进行人工或者自动化比较, 来验证被测试软件是否能给出正确的结果, 从而判断该软件是否满足需求, 是否与该软件系统的规格说明书和用户手册相关部分一致。

这一方法的优点为:

(A) 能最直观和直接地反映出所设计的软件是否满足需求;

(B) 即使没有任何测试工具支援, 也能靠人工测试的方法完成;

其不足之处是：

(A) 这种测试方法难以找出某些特殊类型的错误。例如: 当对应于某组输入该被测软件并不提供任何输出信息时–可能只是改变了某种工作状态,如果其中的源代码处理部分有错误, 就比较难找出来；

(B) 无法确定哪些测试用例有效或者无效 (所谓无效, 并不是说单独使用某个测试用例时不能收到任何测试效果, 而是在于它和前面已经使用过的测试用例一起使用时, 毫无贡献, 只是重复了前面的测试用例已经完成的测试)；

白盒结构测试法

白盒结构测试法则与黑盒子功能测试方法相反: 它不管所被测试的软件是否满足需求,是否实现了所设计的功能, 而只注重该软件内部的结构, 以便设计足够多的测试用例, 使得百分百或者尽可能多的程序组成要素能被测试到最少一次, 从而尽可能地将其中的软件错误暴露出来。

白盒子结构测试方法的优点:

(A) 能够找出许多用功能测试方法找不出来的软件错误;

(B) 可以在整个软件系统还未完成之前就分别对各个单元进行测试;

(D) 可以同时进行内存泄漏分析;

(E) 可以同时进行分支执行频度分析;

(F) 可以同时进行软件复杂度分析;

(G) 可以同时进行数据和变量分析;

(H) 可以同时进行性能分析;

(I) 可以同时进行动态运行错误定位与执行路径追溯等。

白盒子结构测试方法的缺点:

（1）必须通过专门的测试工具来进行, 需要在用户的软件的拷贝上进行插桩（插入纪录点）记录各分支/条件是否被执行过或者执行过多少次的信息;

（2）会使被测试的软件的运行速度减慢;

（3）需要增加被测试软件运行时的资源开销等。

关于软件质量的误区

有不少软件开发组织和应用软件开发部门的管理者错误地认为，他们已经对他们所开发的软件做了充分的功能测试(又称“黑盒测试“)了，认为“我们的软件质量没问题！” ——但是，专家们分析了大量“经过充分的功能测试“的软件后发现，这些软件中还有大约一半的程序分支从未被执行过！

为什么会这样？原来，软件的功能描述相对来说非常容易、非常简单、也非常粗糙，无法详细到用软件内部的具体实现逻辑结构来说明；而要达到同样的功能，软件可以有许许多多等效的实现方法；特别是，软件功能的实现，与所使用的编写程序的语言、所运行的操作系统环境、所用到的数据库以及某些第三方的软件都有关系。事实上，一个软件中的许许多多程序分支跟该软件本身的功能并没有直接的联系，而是用来处理各种可能出现的运行情况的。例如，所开发的软件在运行中突然被终止时(系统断电或者用户打断)如何保护已经打开的文档；在系统资源用尽之前如何提出警告；在所要用到的某些文件被意外地***了时如何应付等等。这些程序分支在编写中同样存在着可能的错误，必须加于测试。而这通常都需要通过程序的结构测试(又称“白盒测试“)来完成，而白盒结构测试是必须借助于软件测试工具才能进行的。

ThreadingTest针对上诉的质量误区情况在测试过程中对于一组输入，既判断其输出（如果有）是否与预期值一致，又判断其执行路径是否与预期值一致。这样一来，即使测试输出结果与预期值一致，也可能有错误被找出来－如果所预期的执行路径与实际的执行路径不一致。例如，当测试一个计算器程序时，如果输入是2＋2，测到的结果是4，也可能是个错误－如果它的执行路径与预期值不一致：其最终的结果可能是2×2的路径的输出结果。由于TT可以测试有输入而无输出的场合（此时仅仅测试其执行路径是否与所期待的路径一致），因而可以在任何开发阶段使用，实现名副其实的全过程测试驱动。

2、第二代白盒覆盖率技术

覆盖率技术是软件测试的基本技术手段之一，但是数十年以来虽然也出现过多种理论方法以及商用产品，但其一直未在测试界主流应用领域推广，主要原因有以下几点点：

（1）通常覆盖率结果在重新发布版本以后必须重新进行累计，对于庞大的程序相当于对历史的测试全部归零。

（2）软件测试的通常场景，是需要用测试工具对代码进行分析，而软件测试工具，尤其是可以达到商用标准的白盒测试工具一直被国外的几大老牌软件测试工具所垄断，价格高昂，并且对于航天、军事级别的测试需求来说信息安全可靠度差。

（3）白盒测试操作难度大，测试人员很难理解，在测试团队中很难推广。

（4）白盒测试工具都是单机版，很难再大型测试团队中推广使用。

（5）覆盖率和测试用例无任何关系，通常覆盖率是执行一系列动作的混合结果，而通常测试人员以及开发人员在定位问题的时候需要明确知道某个功能对应的代码覆盖率。而这些传统的白盒测试工具都无法支持。

（6）随着移动应用在消费级、企业级的市场所占比重越来越大，一些老牌的测试工具针对移动环境（android、iOS）的测试明显支持乏力甚至不提供支持。

上述原因让第一代的覆盖率技术很难真正的得到推广。ThreadingTest针对第一代的覆盖率技术的缺陷提出了全新的第二代覆盖率技术，并在覆盖率方法的基础上，设计了全新的应用功能：

（1）无需监管测试场景：覆盖率的统计完全可以由后台程序运行收集，对测试人员实现透明化，测试人员只需要运行插桩后的程序，开启程序的自动收集功能，即可无需监管的进行常规测试，TT会自动将程序的测试执行情况收集、分析、存入数据库，配合TT就可以轻松的查看程序的实时覆盖率。