穿线测试理念介绍V1.0版
穿线测试特性
穿线测试，其含义取自于对通过一个连线能够对实体进行连接，通过这个穿线建立实体间的联系，并在此之上通过穿线实现物体的互相可追溯特性。穿线测试的核心思想类似于目前火热的DevOPS技术，但相比于DevOPS是建立开发与运维之间的联系，打破二者之间的信息鸿沟，穿线测试则着重于将开发者和测试者的工作组件串联起来，开发和测试之间依托TT可以进行高效的互动，这里面最核心的思想之一是:功能测试与对应的程序程序源代码执行逻辑的双向穿线。
ThreadingTest自动建立测试用例与程序源代码之间的逻辑关系，正向穿线，开发工程师可以看到测试工程师执行用例的代码细节，以方便进行缺陷的修复，测试数据可以直接为开发调试提供依据，快速定位并修复缺陷。逆向穿线，测试工程师通过修改的源码快速确定测试用例的范围，极大减少回归测试的盲目性和工作量，快速修订测试用例，达到测试覆盖率最大化。穿线测试的核心思想取自于华人科学家熊继光先生（著名软件测试工具panorama的作者）的非线性软件工程体系思想，同时是该思想的第一个商业实现产品，一定程度上可以骄傲的说在软件测试领域，中国人无论在理论还是商业产品上，站在了最前沿。
穿线测试是继白盒测试、黑盒测试以来对软件测试领域的重大理论突破，通过一系列技术，能彻底的打破原有的软件开发与软件测试之间的鸿沟，率先提出量化的软件测试工程理念，代码的可一致性修改和维护等全新理念，ThreadingTest产品的具体技术特性如下：
1.连接开发与测试之间的穿线技术
1.1 测试用例与代码执行逻辑的双向自动关联
自动建立测试用例与代码的逻辑关系，正向追溯，开发工程师可以看到测试工程师执行用例的代码细节，以方便进行缺陷的修复，开发工程师和测试工程师可以高效的进行互动，测试数据可以直接为开发调试提供依据，快速定位并修复缺陷。
正向追溯的展示：
图解：
A：正向追溯的起点，点击测试用例B和D部分展示了该测试用例所执行到的函数以及函数的复杂度以及覆盖率。
B：CallGraph视图部分，显示正向追溯追溯到的函数调和执行情况。点击CallGraph图元，C窗口展示该函数的控制流程图以及函数各个结构分支的执行覆盖情况。
C： ControlFlow 视图部分，显示所选函数的控制流程图以及各个结构分支的执行覆盖情况。
D：正向追溯到的函数列表，包括函数的源码的其实行号和终止行号，多种复杂度和覆盖率等数据。
E：Code视图，显示所选函数的源码部分。
穿线测试的最大的作用，在于反向穿线的时候，可以看到某一些代码到底和哪些功能点有关，这样测试人员就会知道，当某一部分代码修改以后，哪些功能点是和修改的代码是相关的，通过反向穿线就可以自动获得，这是一个测试用例集自动削减的过程，虽然软件测试领域针对回归测试用例选取有很多的理论化方法阐述，穿线测试则通过穿线技术提供了一种可商用的解决方案。而难能可贵的是功能点和庞大程序执行逻辑信息的建立是自动化的。
图解：
A： 反向追溯的起点，类-函数导航树，点击某个函数 ，B和C窗口显示该函数的函数调用图和控制流程图。
B： CallGraph视图部分，显示所选函数的控制流程图以及函数各个结构分支的执行覆盖情况。
C： ControlFlow 视图部分，显示所选函数的控制流程图以及各个结构分支的执行覆盖情况。
D： 反向追溯到的测试用例列表，包括测试用例的运行时间，预期输入输出以及需求设计等文档信息。
E： Code视图，显示所选函数的源码部分。选择一某段代码，F窗口会显示执行过所选代码的测试用例。
F： 从Code视图中选择的代码反向追溯到的测试用例信息。
1.2 引导开发与测试合作完成100%覆盖率测试
测试人员运行完所有用例可以发现所有未测试分支，并且和开发确认如何才能覆盖，并增补用例。直到达到关键模块的100%覆盖的测试。对于较难覆盖程序逻辑，开发以及测试人员可以作为重点进行代码走查及联合用例设计。围绕覆盖率结果，开发和测试人员可以充分的互动，而在穿线测试工具出现之前，由于没有覆盖率这个共享数据，开发和测试人员之间很难充分的互动和协作，因为开发人员并不清楚测试用例具体对应的程序执行逻辑，而测试人员也不清楚如何完成充分的测试。
1.3 帮助测试人员可视化开发人员单元测试结果
测试人员可以通过开发人员的测试结果，量化确定是否提交版本达到进行第三方测试标准，并且对于开发提交的每个版本量化其内测指标以及内测充分度。
1.4 基于穿线技术实现的高效智能化回归测试技术
测试人员可以对每次开发提交的版本进行量化分析，以辅助对回归测试的范围进行确定。通过TT，开发人员对于程序进行修改的时候，可以清晰看到修改所涉及到的用例，并且进而进行一致性的修改，避免引入新的缺陷。开发工程师可以比对设计逻辑与实际运行逻辑是否存在差异化，并进而快速发现潜在的缺陷以及错误的代码行为。
（1） 基于动态覆盖率模型的方法，能够最真实的体现程序的执行特性
（2） 采用自主的波及分析技术计算得到的测试用例，会非常准确的选取的确定变更而需要重新运行的测试用例的范围；
（3） 大型应用系统维护阶段的测试，可通过TT进行测试用例辅助选取，而不再凭测试人员的历史经验来确定；
（4） 无需为变更而运行所有测试用例，可确定每次变更的重点测试范围，以轻松应对频繁调整和上线的情况。
2 第二代覆盖率技术
覆盖率技术是软件测试的基本技术手段之一，但是30多年以来虽然也出现过多种理论方法以及商用产品，但其一直未在测试界主流应用领域推广，通常覆盖率结果在重新发布版本以后必须重新进行累计，对于庞大的程序相当于对历史的测试全部归零，这显然很难真正的推广覆盖率技术。ThreadingTest针对第一代的覆盖率技术的缺陷提出了全新的第二代覆盖率技术,为覆盖率方法的基础上，设计了全新的应用功能：
（1） 累计覆盖率技术：如果存在多个被测程序版本的覆盖率结果，TT可以实现对多个版本的覆盖率进行合并，并且在一个视图中展示
图 主界面CallGraph图中选择多个版本的累积覆盖率展示
（2） 无需监管的覆盖率搜集：覆盖率的统计完全可以由后台程序运行搜集，对测试人员实现透明化。
（3） 支持在程序结构图、控制流程图等多种图形上显示覆盖率，测试以及开发人员可以从多个视角清晰的看到程序的覆盖率情况。
（4） 支持分布式测试，多个测试人员访问系统产生的覆盖率，可以在统一视图中显示。
（5） 实现美军标DO-178B MC/DC白盒结构测试技术，实现100%覆盖率，可视化复杂条件组合，使产品质量大幅提升
（6） 可以在控制流程图上看到每个判断语句的复合条件的任意子条件的覆盖情况。通过第二代覆盖率技术，整个测试可以在充分量化的环境下运行，整个开发以及测试团队可以实时看到每个用例的覆盖率对整体测试的贡献程度。根据覆盖率的生长等指标对整个测试进程进行动态调整，同时可以引导对于累计覆盖率偏低的关键模块补充用例。
3 超高速、大型、可交互的图形化系统
TT支持程序结构图、类继承图、函数控制流程图等多多种图形的动态显示，其中callgraph图形具有一下高级特性：
（1） 支持百万图元级别的超高速图形绘制技术
（2） 支持全屏以及超平滑的放大与缩小技术、平滑的移动技术
（3） 支持按照类分组聚集布图以及按照函数调用关系布图，层次数量可自由定义
（4） 支持逐级的子树展开和下钻功能。
（5） 支持在函数图元上覆盖显示覆盖率与函数相关信息的显示。
（6） 可追溯：CallGraph是“活”的，不是静止不动的，可以选择途中任何一个模块而追溯所有调用它的路径和相关模块以及被他调用的模块，用于修改模块不一致性缺陷的预防等。
（7） 可交互操作，例如高亮显示一个模块及其相关模块，或者单独绘制一个模块的调用关系。
（8） 可选取CallGraph图中任何一个模块为根生成局部子图，并系那是所生成的子图的相关信息：使得团队的各个组群或者个人可以方便的得到相关的局部信息。
（9） 实现各模块与逻辑框图的链接：完成宏观（CallGraph）与微观视图（ControlFlow）的结合， 发挥更好的可视化效果。
图 CallGraph图
其中controlflow支持如下特性：
（1） 可视化的控制流程图，对主要的控制逻辑语句对应有清晰的图元显示，支持嵌套显示以及串联显示
（2） 点击控制流图的每个图元可以看到对应的代码段以及代码段的执行次数、覆盖率情况
（3） 在控制流图的代码段，当条件语句成为选中热点后，可以看到条件语句的各个子条件的各种组合执行的真假情况
（4） 支持缩略图的显示，可平滑的进行缩放以及全屏显示
（5） 可以与callgraph相互自动链接、追溯、转换。
图 ControlFlow图
4 实时的被测应用示波器
TT率先将引入的测试示波器概念，在实际测试的过程中，可以实时的看到从程序中各种逻辑体执行的速率、频率等信息，测试人员可以从传统的对被测应用的黑盒子测试（仅能看到功能的反馈无法看到程序内部的反馈）进而转换成为类似于对于硬件测试的示波器一样，能够对整个测试过程的关键测试数据进行实时的分析和查看。
图 动态实时监测
5 多个版本的代码比对视图
软件开发过程中由于多次的迭代和增量开发而不可避免的产生多个版本，相对应的也会产生多次的版本测试。针对多版本的情况ThreadingTest提供了多版本的函数级比较和测试覆盖率合并功能。
多版本对比以函数为单位，列出了所有函数的增加、修改、删除等一系列状态的对比演化过程（也可以说是一种版本追溯机制），结合CallGraph和ControlFlow图式,使用者可以快速定位不同版本之间函数的区别、某一模块的修改对其他模块产生的影响，提高缺陷的预防能力。
测试工程师，通过多版本的比较，可以有针对性的修改各版本中的测试用例，进行测试对比，找出升级版本带来的隐藏问题。
多版本对比的另一大特性是覆盖率合并，对于多个版本实现智能覆盖率合并，以前述的函数级多版本对比为基础，通过覆盖率合并算法，准确统计出当前最新版本的累积覆盖率，从而极大减少测试工程师的重复测试工作。
图 多版本函数演变对比
图 多版本覆盖率累计
6 多样化的平台、语言及应用支持
TT目前已经发布了对J2EE应用的版本以及针对Android应用的版本，未来将发布苹果移动应用版本以及c/c++版本。随着TT的将会针对更多的语言和应用类型进行扩展，在应用类型上将从传统的应用向多线程高速运转的游戏类应用扩展。
6.1 前后端分离架构，可扩展多种语言支持，后端数据库结构为程序语言的高度抽象
在开发对新的语言支持的时候，后端几乎不需要更改就可以直接复用，唯一需要修改的是针对各种语言的前端分析组件。
6.2 TT程序具有跨平台技术特性
目前我们已经推出windows版本，可以轻松的扩展到linux，mac os等环境下运行。
TT支持理论上已经可以支持所有类型的应用的测试，未来我们会推出专门针对游戏应用的版本，以适应多线程、大量循环的游戏类应用。
6.3 TT同时支持多种测试场景
TT可根据实际情况，应用到被测系统的单元测试、功能测试、集成测试、系统测试中，它对实际的测试阶段及范围没有任何的限制，它是一款通用的测试工具，也可以同时在多个阶段由不同的人员使用，实现测试数据的共享以及测试过程的接力。
7 TT的编译技术
7.1 100%Java语法支持，最高支持Java1.7版本，并保持同步升级
为了实现程序的运行期测试覆盖率分析，首先需要对处理的程序做词法分析和语法分析，然后对其中的各个判断语句进行插桩（Instrumentation）。TT的内核支持目前最新的Java1.7版本的所有语法，因此在对被测应用进行分析的过程中，可以保证100%的正确性，达到商用标准。同时对其他更早的Java语言版本保持向前兼容。ThreadingTest J2EE版本的插装器在分析过程中能够保持100%的Java(JDK 7以及以下版本)语法兼容性，对任意复杂的程序分析不会产生错误，并保证插装后的程序亦不会产生语法错误及行为变化。
7.2 批量编译技术
TT支持批量编译技术，可以提供和eclipse相媲美的编译速度，支持与标准编译过程（例如ant）进行集成。
7.3 超高速的测试数据发送架构
通过TT编译出来的代码包，在执行性能上和普通编译的代码性能差异很微小，不会对被测应用的行为特征发生变化。TT支持两种测试数据送出模式，一种是即时送出，一种是去重送出。去重送出可以适应多线程，多循环的应用场景，例如游戏类应用以及J2EE后台应用。
8 支持分布式测试场景
8.1 支持分布式应用的集成测试
当用户的系统为分布式系统，由多个组件在集成环境下同时对外提供服务的情况下，ＴＴ支持对这个分布式环境的各个组件及其交互的联合测试。即可以看到一个外部请求，对不多个子系统之间的所有的执行情况。
8.2 支持多用户同时测试与测试数据的有效隔离
TT允许多个用户同时对被测应用测试，而不同用户针对不同用例即时在同一时刻做的测试而产生的测试数据之间也不会发生任何混淆的情况。
相关阅读:
- 数据库迁移测试：选白盒还是黑盒？ (zaza9084, 2014-4-04)
- Appium自动化测试框架构建 (zaza9084, 2014-4-08)
- 对于移动APP测试的一个小技巧 (zaza9084, 2014-4-09)
- 测试设计经验总结 (zaza9084, 2014-4-09)
- 关于白盒测试的一些想法 (zaza9084, 2014-4-14)
- 测试人必备的5类测试辅助工具 (zaza9084, 2014-4-21)
- 基于VC测试工具的二次开发 (zaza9084, 2014-4-28)
- phpwind如何安装 (淑君NJ, 2014-5-08)
- 移动客户端测试常用工具 (zaza9084, 2014-5-14)
- 动手写一个Remoting接口测试工具 (zaza9084, 2014-5-22)
TAG: Android测试 移动测试 白盒测试 测试 测试工具 android测试
