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

使用ThreadingTest进行安卓应用测试查错实例分析 TT工程测试分析说明 TT测试工具区别的于传统测试工具，TT在测试人员那不需要关注具体代码实现的基础上达到对代码的最大覆盖，以及可能出现的非功能bug的较早的预先定位。下面结合开源代码Pedometer来说明基于TT软件的测试分析。 示例代码说明 Pedometer程序涉及到安卓开发中的加速器交互、语音更新、后台运行服务等，针对本程序功能模块可以分为设置类操作以影响程序的运行情况，现将测试用例按照Pedometer的设置项来创建测试用例： 1、加速器交互设置类测试用例 2、语音设置类测试用例 3、Pedometer记步参数设置测试用例 传统测试人员黑盒测试分析 基于以上分析出Pedometer的功能点，根据设置的参数，在传统测试人员手中只能通过功能点来列出预期输入和预期输出值，比如：存在以下一组测试用例： 测试用例描述 输入 输出 Pedometer记步程序语音后台服务关闭 点击设置按钮?在voice设置项里面点击关闭speak播报项 在使用Pedometer的时候不会出现语音播报 以上是在传统测试的时候根据软件的使用和功能点在一定输入条件下，由开发或者设计者预期输出的结果来判断功能点是不是可以使用。在得出具体结论后此项测试用例即算通过。然而对于后台执行的代码逻辑是不是满足设计要求以及容错能力是否达到公司要求，这一切都没有在测试人员的报告中体现，所以在传统的测试方法中还是存在着一定的隐患，导致一些bug交给了用户去发现，由此带来了一系列软件交付的问题。 基于TT软件下的白盒测试 根据以上分析出在传统测试方法的弊端，在基础上基于TT软件的测试基础上可以达到对代码级别的质量监控。TT在使用的过程大致分为4个步骤： 首先根据项目代码尽量划分出界限明显模块，分别创建测试用例，针对当前测试用例进行测试，最大化的模拟用户操作或无界面程序的控制台输入条件来覆盖软件各个功能点。 基于TT软件DTC监控，针对划分的测试用例来监控代码运行以及覆盖情况，分析出关键代码逻辑覆盖率为0或者较低的项，此处易出现逻辑未覆盖导致不可知问题。 结合TT监控得出的覆盖率信息，补全测试用例使覆盖到违背覆盖的代码逻辑，此项可以设计根据先前规划的测试用例得出当前所需的输入条件，以便快速实现最大化覆盖。 如果代码的健壮性足够好，在补全测试用例之后，此时一般不会出现异常或者软件退出问题，但功能点容易不满足要求。如果代码健壮性不好对异常数据保护不够，在补全测试用例之后根据分析得出输入条件，此时在运行程序的时候很容易出现异常退出等致命问题。 所以结合以上分析，下面以Pedometer为实例来说明TT使用和分析。 第一步，根据功能点来划分了一系列测试用例，这些测试用例，测试用例描述： Pedometer 手机硬件设置相关用例：该测试用例包括手机加速器以及灵敏度设置项、手机屏幕超时设置项。该用例主要影响Pedometer在屏幕待机与否的情况下加速器灵敏度相关逻辑的设置。 Pedometer 语音设置项相关用例：该测试用例包括Pedometer语音相关设置，在使用Pedometer中是否播报以及播报信息种类和间隔时间 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中的退出操作涉及到的函数