ThreadingTest移动白盒测试工具

　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移动应用测试。

（4）累计覆盖率技术：如果存在多个被测程序版本的覆盖率结果，TT可以实现对多个版本的覆盖率进行合并，并且在一个视图中展示。

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

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

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

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

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取