ZOA公司研发的ThreadingTest智能型测试工具系列一期，是基于程序源代码的白盒测试工具。采取前端分析器和后端结果分析分离的技术路线，实现对多种语言的编译器级分析和多维度测试。
ThreadingTest的核心思想来源于非线性复杂软件工程体系。通过ThreadingTest基于测试用例集与动态代码覆盖的双向追溯的专利技术，使得对于大型应用系统的维护和修改变得不再盲目和极易出错，使得对大型软件的系统测试期和维护期的测试过程从无量化依据到有明确的量化依据的过程进行转变。
ThreadingTest通过一系列自动、高效、可视化技术，使软件维护与开发效率加倍、成本减半、系统软件质量提高几个数量级。
1) 基于双向追溯机制的高效智能化回归测试技术。
2) 实现美军标DO-178BMC/DC白盒结构测试技术。
3) 高速显示的可交互性的程序可视化组件。
4) 测试用例半自动生成、动态错误分类、定位和执行路径可视化技术。
5) 智能化版本对比分析技术。
双向追溯是指通过运行测试用例，实现测试用例与被测源码间相互追溯。根据测试用例查看相关被测源码为正向追溯，根据被测源码查看相关测试用例为逆向追溯。在测试用例列表中选择测试用例，可以追溯到该测试用例的内容描述信息，在模块调用图中显示被测试到的函数；也可以在模块调用图中，点击相关的函数，也可以追溯到相关的测试用例。该追溯技术方便了用户查看和设计测试用例。
1).正向追溯
正向追溯过程：在测试用例列表中，单击选择一个测试用例后，在双向追溯的CallGraph和ControlFlow图上，被该测试用例追溯到（测试过）的函数会显示到CallGraph图上，同时在TestCase Trace窗口列出这些被执行过的函数，点击CallGraph图中的函数，会将该函数的控制流程图显示到ControlFlow图上，同时ControlFlow还可以通过颜色对每个程序块进行覆盖标识，如果块内空白区域被标示为浅蓝色，则说明该块被覆盖（每一条分支都被执行）。
2).逆向追溯：在函数列表的上选择某个函数，在CallGraph、ControlFlow以及Code视图都显示该函数的函数调用图、控制流程图以及源码，反向追溯到内容为执行过该函数的测试用例列表 。在Method Trace视图部分会显示追溯到的测试用例的详细信息。选择Code视图部分的部分源码，在CodeTrace视图部分会显示这段源码反向追溯到测试用例的信息。
ThreadingTest拥有多种测试覆盖率分析结果报告。其中SC0，SC1，SC1+都是段覆盖（SegmentCoverage）的几种标准，段覆盖又称块测试覆盖，用来考量被测代码中每个可执行语句块覆盖的比例。SC0只管覆盖代码中的执行语句块，却不考虑各种语句结构的分支覆盖情况等，因此往往被看做比较弱的覆盖，但却是很必要的一种覆盖量度，因此在SC0的基础上我们衍生出来了SC1以及SC1+覆盖率量度。TT除了提供了三种关于段的相关覆盖率，也提供了各种语句结构的条件以及判定的各种级别的覆盖率数据：
1) 条件为真（TRUE）百分比
2) 条件为假（FALSE）百分比
3) 条件真假（BOTH）都覆盖百分比
4) 分支覆盖（Branch覆盖）
5) C/DC条件/判定覆盖（百分比）
6) MC/DC覆盖
基于以上的功能点，我们以一个实例来说明TT的分析过程和双向追溯的使用。
TT测试工具区别的于传统测试工具，TT在测试人员那不需要关注具体代码实现的基础上达到对代码的最大覆盖，以及可能出现的非功能bug的较早的预先定位。下面结合开源代码Pedometer来说明基于TT软件的测试分析。
Pedometer程序涉及到安卓开发中的加速器交互、语音更新、后台运行服务等，针对本程序功能模块可以分为设置类操作以影响程序的运行情况，现将测试用例按照Pedometer的设置项来创建测试用例：
1、加速器交互设置类测试用例
2、语音设置类测试用例
3、Pedometer记步参数设置测试用例
基于以上分析出Pedometer的功能点，根据设置的参数，在传统测试人员手中只能通过功能点来列出预期输入和预期输出值，比如：存在以下一组测试用例：
测试用例描述 | 输入 | 输出 |
Pedometer记步程序语音后台服务关闭 | 点击设置按钮à在voice设置项里面点击关闭speak播报项 | 在使用Pedometer的时候不会出现语音播报 |
以上是在传统测试的时候根据软件的使用和功能点在一定输入条件下，由开发或者设计者预期输出的结果来判断功能点是不是可以使用。在得出具体结论后此项测试用例即算通过。然而对于后台执行的代码逻辑是不是满足设计要求以及容错能力是否达到公司要求，这一切都没有在测试人员的报告中体现，所以在传统的测试方法中还是存在着一定的隐患，导致一些bug交给了用户去发现，由此带来了一系列软件交付的问题。
根据以上分析出在传统测试方法的弊端，在基础上基于TT软件的测试基础上可以达到对代码级别的质量监控。TT在使用的过程大致分为4个步骤：
1、首先根据项目代码尽量划分出界限明显模块，分别创建测试用例，针对当前测试用例进行测试，最大化的模拟用户操作或×××面程序的控制台输入条件来覆盖软件各个功能点。
2、基于TT软件DTC监控，针对划分的测试用例来监控代码运行以及覆盖情况，分析出关键代码逻辑覆盖率为0或者较低的项，此处易出现逻辑未覆盖导致不可知问题。
3、结合TT监控得出的覆盖率信息，补全测试用例使覆盖到违背覆盖的代码逻辑，此项可以设计根据先前规划的测试用例得出当前所需的输入条件，以便快速实现最大化覆盖。
4、如果代码的健壮性足够好，在补全测试用例之后，此时一般不会出现异常或者软件退出问题，但功能点容易不满足要求。如果代码健壮性不好对异常数据保护不够，在补全测试用例之后根据分析得出输入条件，此时在运行程序的时候很容易出现异常退出等致命问题。
所以结合以上分析，下面以Pedometer为实例来说明TT使用和分析。
第一步，根据功能点来划分了一系列测试用例，这些测试用例，测试用例描述：
1、 Pedometer 手机硬件设置相关用例：该测试用例包括手机加速器以及灵敏度设置项、手机屏幕超时设置项。该用例主要影响Pedometer在屏幕待机与否的情况下加速器灵敏度相关逻辑的设置。
2、 Pedometer 语音设置项相关用例：该测试用例包括Pedometer语音相关设置，在使用Pedometer中是否播报以及播报信息种类和间隔时间
3、 Pedometer使用者信息设置相关用例：该用例包括使用者信息的设置
第二步，在创建以上三个测试用例之后，分别根据每个测试用例的关注点来进行实际的操作，在测试的过程中需要最大化的覆盖到每个用例的可输入条件，这样可以减少用例的重复，加快分析和测试效率。分别选中各个测试用例启动TT 软件中的DTC监控进行实际软件使用。
第三部，在上述三个预期测试用例执行完成之后，用例覆盖情况如图-1所示，在TT软件的listview中查看被测试程序的执行和覆盖情况，
图-1
1、重点找出不含有判断逻辑的函数（在TT listview视图中无逻辑函数覆盖率True或者false 为“--”标示如图-2所示）且其sc0（基本段覆盖率）为0或者低于100%的函数，这种函数不含逻辑语句，如果其函数已被执行且其sc0为0极有可能是中间有return等跳转语句，此处需要注意是否是代码处理逻辑有问题。以同样的方法可以查看sc1和sc+为0或者低于100%的函数。
图-2
2、重点找出含有判断逻辑的函数，TRUE或者FALSE覆盖未达到100%，如果达到，这种情况则说明代码有未执行分支情况需要切换输入条件来补全。
第三步，补全测试用例，这里我们根据程序退出时候一般对资源释放顺序或者资源清理不彻底易出现问题这个点先查找函数退出时的调用的几个函数这里以Pedometer中的退出操作涉及到的函数有：
private voidresetValues(boolean updateDisplay)
在listview中查找该函数的覆盖信息如图-3所示：
图-3
这里该函数的false覆盖率数值只有33%，可以断定其判定条件为加的分支有未执行到的。切换至该函数控制流程图中查看条件真假执行情况如图-4
图-4
第四步，根据补全测试用例找出bug点，这一步在初始规划测试用例覆盖的足够全面，一般可以认为是结束点。对于复杂的工程上述几步可以作为一次迭代，重复测试来达到最大化的覆盖。进过查看代码发现，在执行退出操作的时候变量mIsRunning 在暂停操作中被置为false所以可以设定一个测试场景，在暂停的时候退出程序，以达到if（mService != null && mIsRunning）为假的情况，所以补全测试用例，新增加在暂停的退出测试用例：退出功能用例之后运行监控得到统计数据如图-5
图-5
查看该函数的控制流程图条件执行情况如图-6
图-6
在增加了改组测试用例的场景后，很不幸该程序出现了异常退出问题，进过查看源代码发现，在暂停功能和退出中释放了同一个资源导致异常退出如图-7所示
图-7
上面事例对于被测试软件的静态分析，可以找出开发者的一些隐蔽的bug和逻辑错误，当然软件的开发是一次次的迭代过程，在软件开发的过程中一些考虑不周全的模块难免需要重新设计和修改，那么这些模块的修改会对依赖该模块的部分产生影响，那有什么办法可以查看这些模块间的线性关系，TT中的双向追溯、版本对比、以及函数调用图就可以解决这样的问题。
1、 分析Pedometer中的带得知在程序暂停的时候语音信息提示功能是不可使用的，现在加入提出要求在Pedometer暂停的时候播放当前的里程数，针对这一修改我们通过TT查看关联的模块影响。
2、 为了达到预设场景的功能实现需要修改Pedometer源代码中暂停功能的代码如图-8：
图-8
在这里我们在暂停的时候不停止后台服务，而是通过mPause这个布尔值标示来区别当前是否处于暂停状态，同时修改重置响应函数逻辑为true状态。以便在使用者运动过程中控制是否接收数据。这部分消息通知代码逻辑我们修改如图-9：
图-9
3、 为了满足设定场景我们代码修改到想在已经符合了下面通过TT软件进行DTC监控获取运行数据,显然现在程序使用已经有问题了，首先在界面暂停之后在重新运行已经无法打印当前运行数值，我们先通过TT软件的双向追溯中的逆向追溯功能查看在“暂停“函数逻辑中调用了那些函数，和我们修改的函数有什么关系通过这些对比我们可以定位到问题出现在哪个函数中，如图-10
图-10
4、 我们打开执行的测试用例“退出功能“，在函数导航树中查看要关注菜单操作的函数：
public booleanonOptionsItemSelected(MenuItem item)
如图-11和图-12中所示：
图-11
图-12
上述图中展示出双向追溯中逆向追溯跟踪到Pedometer菜单操作所在函数的处理逻辑执行情况，很明显在最新修改的标示为代码红色代码区域标示代码未执行，我们在操作Pedometer时候已经很明显的发现，重置功能已经不可使用了，在这里很直接的看到红色的代码逻辑其实是没有执行到，这里可以分析出代码未执行到的原因，如图-13所示的2个消息类型并未发送导致没有响应该case标签。
图-13
进一步查看代码发现在菜单响应函数中对于“暂停“和”重新开始“两个按钮个
切换功能有问，题如图-14代码所示：
图-14
图中标注的判断条件只判断了mIsRunning标示，但是为了达到在暂停时
候播放语音的标示为在这里却没有使用导致消息MENU_RESUM没有内发送，
此处存在开发问题。修改办法在这里要加上刚才我们修改的标示位mPause的
判断，如图-15所示：
图-15
以上通过正向追溯发现了修改一个简单的bool值影响了别的函数导致问题出
现。测试人员可以很快的将问题初步定位出来及时反馈给开发者，在开发人员再
次定位的时候能很快的解决问题提高了bug修复效率。
5、 再次分析ＴＴ双向追溯中正向追溯数据如图－１６所示：
图-1６
点击高亮子树中我们查看和该菜单操作有关的函数第一个是：
resetValues(booleanupdateDisplay)我们在测试中也发现在暂停之后充值数据也不能在使用，查看其覆盖情况如图-17：
图-17
很明显该函数的逻辑也是未被执行同样存在该问题mPause标示量没有添加判
断做同样的修改如图-18
图-18
6、如此可以跟踪发现类型存在的问题，下面我们可以根据修改的代码再次验证
我们发现的问题是否正确，我们再次编译后发现现在已经实现了我么预期的功能
在暂停时候还可以语音播放提示信息，重置和重新运行切换也正常使用。覆盖情
况如图-19
图-19
对移动端白盒测试技术或者性能测试感兴趣，请加入群符号执行 339834199
软件试用申请官网：www.threadingtest.com
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
