使用ThreadingTest进行安卓应用测试查错实例分析

threadingtest · 发表于 2014-7-26 14:38:15

1 TT工程测试分析说明

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

2 示例代码说明

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

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

2、语音设置类测试用例

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

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

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

测试用例描述	输入	输出
Pedometer记步程序语音后台服务关闭	点击设置按钮à在voice设置项里面点击关闭speak播报项	在使用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中查看被测试程序的执行和覆盖情况，

图-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

5 TT软件中双向追溯的重要作用

上面事例对于被测试软件的静态分析，可以找出开发者的一些隐蔽的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