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

软件测试再也不黑盒—

                                                  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能够测试有输入而无输出的场合（此时仅仅测试其执行路径是否与所期待的路径一致），于是能够在任何开发阶段使用，实现名副其实的全过程测试驱动。

 

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

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

（1）        一般覆盖率结果在从新发布版本之后必须从新进行累计，对于庞大的程序至关于对历史的测试所有归零。

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

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

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

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

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

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

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

图 实时监控界面自动收集被测程序执行状况并统计

（2）        双向追溯是TT实现覆盖率到达100%的重要工具，经过双向追溯功能测试人员运行完全部用例能够发现全部未测试分支，而且和开发确认如何才能覆盖，并增补用例。直到达到关键模块的100%覆盖的测试。对于较难覆盖程序逻辑，开发以及测试人员能够做为重点进行代码走查及联合用例设计。围绕覆盖率结果，开发和测试人员能够充分的互动，而在穿线测试工具出现以前，因为没有覆盖率这个共享数据，开发和测试人员之间很难充分的互动和协做，由于开发人员并不清楚测试用例具体对应的程序执行逻辑，而测试人员也不清楚如何完成充分的测试。

图 双向追溯界面测试用例和代码以前经过围绕覆盖率进行互动

 

（3）       支持基于Java语言开发的android移动应用测试。

图手机上进行操做，与之相连的电脑上TT实时收集测试信息

（4）        累计覆盖率技术：若是存在多个被测程序版本的覆盖率结果，TT能够实现对多个版本的覆盖率进行合并，而且在一个视图中展现

图 主界面CallGraph图中选择多个版本的累积覆盖率展现

（5）        支持在程序结构图、控制流程图等多种图形上显示覆盖率，测试以及开发人员能够从多个视角清晰的看到程序的覆盖率状况，能够查看总体的覆盖率，也能够查看单独某一个函数的覆盖率，甚至能够查看某一个分支的覆盖执行状况。

图 覆盖率展现

图 覆盖率展现

图 覆盖率展现

图 覆盖率展现

（6）        支持分布式测试，多个测试人员测试产生的覆盖率，能够在统一视图中显示。

（7）        实现美军标DO-178B MC/DC白盒结构测试技术，实现100%覆盖率，可视化复杂条件组合，使产品质量大幅提高。

       经过第二代覆盖率技术，整个测试能够在充份量化的环境下运行，整个开发以及测试团队能够实时看到每一个用例的覆盖率对总体测试的贡献程度。根据覆盖率的生长等指标对整个测试进程进行动态调整，同时能够引导对于累计覆盖率偏低的关键模块补充用例。咱们但愿，国产专业级白盒测试工具TT，可以真正的将白盒测试技术作系统的升级，而且为测试人员所掌握和喜爱，并进而将中国的软件测试提高到一个新的境界。