Android应用测试工具ThreadingTest查错实例分析

1      ThreadingTest产品简介

    ZOA公司研发的ThreadingTest智能型测试工具系列一期，是基于程序源代码的白盒测试工具。采取前端分析器和后端结果分析分离的技术路线，实现对多种语言的编译器级分析和多维度测试。

成都创新互联专业为企业提供瓦房店网站建设、瓦房店做网站、瓦房店网站设计、瓦房店网站制作等企业网站建设、网页设计与制作、瓦房店企业网站模板建站服务，10年瓦房店做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

ThreadingTest的核心思想来源于非线性复杂软件工程体系。通过ThreadingTest基于测试用例集与动态代码覆盖的双向追溯的专利技术，使得对于大型应用系统的维护和修改变得不再盲目和极易出错，使得对大型软件的系统测试期和维护期的测试过程从无量化依据到有明确的量化依据的过程进行转变。

ThreadingTest通过一系列自动、高效、可视化技术，使软件维护与开发效率加倍、成本减半、系统软件质量提高几个数量级。

1)  基于双向追溯机制的高效智能化回归测试技术。

2)   实现美军标DO-178BMC/DC白盒结构测试技术。

3)   高速显示的可交互性的程序可视化组件。

4)  测试用例半自动生成、动态错误分类、定位和执行路径可视化技术。

5)  智能化版本对比分析技术。

2      双向追溯

    双向追溯是指通过运行测试用例，实现测试用例与被测源码间相互追溯。根据测试用例查看相关被测源码为正向追溯，根据被测源码查看相关测试用例为逆向追溯。在测试用例列表中选择测试用例，可以追溯到该测试用例的内容描述信息，在模块调用图中显示被测试到的函数；也可以在模块调用图中，点击相关的函数，也可以追溯到相关的测试用例。该追溯技术方便了用户查看和设计测试用例。

   1).正向追溯

正向追溯过程：在测试用例列表中，单击选择一个测试用例后，在双向追溯的CallGraph和ControlFlow图上，被该测试用例追溯到（测试过）的函数会显示到CallGraph图上，同时在TestCase Trace窗口列出这些被执行过的函数，点击CallGraph图中的函数，会将该函数的控制流程图显示到ControlFlow图上，同时ControlFlow还可以通过颜色对每个程序块进行覆盖标识，如果块内空白区域被标示为浅蓝色，则说明该块被覆盖（每一条分支都被执行）。

2).逆向追溯：在函数列表的上选择某个函数，在CallGraph、ControlFlow以及Code视图都显示该函数的函数调用图、控制流程图以及源码，反向追溯到内容为执行过该函数的测试用例列表 。在Method Trace视图部分会显示追溯到的测试用例的详细信息。选择Code视图部分的部分源码，在CodeTrace视图部分会显示这段源码反向追溯到测试用例的信息。

3      覆盖率分析

   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的分析过程和双向追溯的使用。

1      TT工程测试分析说明

TT测试工具区别的于传统测试工具，TT在测试人员那不需要关注具体代码实现的基础上达到对代码的最大覆盖，以及可能出现的非功能bug的较早的预先定位。下面结合开源代码Pedometer来说明基于TT软件的测试分析。

2       示例代码说明

Pedometer程序涉及到安卓开发中的加速器交互、语音更新、后台运行服务等，针对本程序功能模块可以分为设置类操作以影响程序的运行情况，现将测试用例按照Pedometer的设置项来创建测试用例：

1、加速器交互设置类测试用例

2、语音设置类测试用例

3、Pedometer记步参数设置测试用例

3      传统测试人员黑盒测试分析

基于以上分析出Pedometer的功能点，根据设置的参数，在传统测试人员手中只能通过功能点来列出预期输入和预期输出值，比如：存在以下一组测试用例：

以上是在传统测试的时候根据软件的使用和功能点在一定输入条件下，由开发或者设计者预期输出的结果来判断功能点是不是可以使用。在得出具体结论后此项测试用例即算通过。然而对于后台执行的代码逻辑是不是满足设计要求以及容错能力是否达到公司要求，这一切都没有在测试人员的报告中体现，所以在传统的测试方法中还是存在着一定的隐患，导致一些bug交给了用户去发现，由此带来了一系列软件交付的问题。

4       基于TT软件下的白盒测试

根据以上分析出在传统测试方法的弊端，在基础上基于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中查看被测试程序的执行和覆盖情况，

                                     图-19

对移动端白盒测试技术或者性能测试感兴趣，请加入群符号执行  339834199

软件试用申请官网：www.threadingtest.com