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

ThreadingTest 产品简介 ZOA公司研发的ThreadingTest智能型Android应用测试工具系列一期，是基于程序源代码的白盒测试工具。采取前端分析器和后端结果分析分离的技术路线，实现对多种语言的编译器级分析和多维度测试。 ThreadingTest的核心思想来源于非线性复杂软件工程体系。通过ThreadingTest基于测试用例集与动态代码覆盖的双向追溯的专利技术，使得对于大型应用系统的维护和修改变得不再盲目和极易出错，使得对大型软件的系统测试期和维护期的测试过程从无量化依据到有明确的量化依据的过程进行转变。 ThreadingTest通过一系列自动、高效、可视化技术，使软件维护与开发效率加倍、成本减半、系统软件质量提高几个数量级。 基于双向追溯机制的高效智能化回归测试技术。 实现美军标DO-178BMC/DC白盒结构测试技术。 高速显示的可交互性的程序可视化组件。 测试用例半自动生成、动态错误分类、定位和执行路径可视化技术。 智能化版本对比分析技术。 双向追溯 双向追溯是指通过运行测试用例，实现测试用例与被测源码间相互追溯。根据测试用例查看相关被测源码为正向追溯，根据被测源码查看相关测试用例为逆向追溯。在测试用例列表中选择测试用例，可以追溯到该测试用例的内容描述信息，在模块调用图中显示被测试到的函数；也可以在模块调用图中，点击相关的函数，也可以追溯到相关的测试用例。该追溯技术方便了用户查看和设计测试用例。 1).正向追溯 正向追溯过程：在测试用例列表中，单击选择一个测试用例后，在双向追溯的CallGraph和ControlFlow图上，被该测试用例追溯到（测试过）的函数会显示到CallGraph图上，同时在窗口这些被执行过的函数点击CallGraph函数，会该函数的控制流程显示到ControlFlow如果块内空白区域被标示为则说明该块被（每一条分支都被执行）Pedometer来说明基于TT软件的测试分析。 示例代码说明 Pedometer程序涉及到安卓开发中的加速器交互、语音更新、后台运行服务等Pedometer的设置项来创建测试用例： 1、加速器交互语音Pedometer记步参数设置测试用例 传统测试人员黑盒测试分析 基于以上分析出Pedometer的功能点，根据设置的参数，在传统测试人员手中只能通过功能点来列出预期输入和预期输出值，比如：存在以下一组测试用例： 测试用例描述 输入 输出 Pedometer记步程序语音后台服务关闭 点击设置按钮(在voice设置项里面点击关闭speak播报项 在使用Pedometer的时候不会出现语音播报 以上是在传统测试的时候根据软件的使用和功能点在一定输入条件下，由开发或者设计者预期输出的结果来判断功能点是不是可以使用。在得出具体结论后此项测试用例即算通过。然而对于后台执行的代码逻辑是不是满足设计要求以及容错能力是否达到公司要求，这一切都没有在测试人员的报告中体现，所以在传统的测试方法中还是存在着一定的隐患，导致一些bug交给了用户去发现，由此带来了一系列软件交付的问题。 基于TT软件下的白盒测试 根据以上分析出在传统测试方法的弊端，在基础上基于TT软件的测试基础上可以达到对代码级别的质量监控。TT在使用的过程大致分为4个步骤： 首先根据项目代码尽量划分出界限明显模块，分别创建测试用例，针对当前测试用例进行测试，最大化的模拟用户操作或无界面程序的控制台输入条件来覆盖软件各个功能点。 基于TT软件DTC监控，针对划分的测试用例来监控代码运行以及覆盖情况，分析出关键代码逻辑覆盖率为0或者较低的项，此处易出现逻辑未覆盖导致不可知问题。 结合TT监控得出的覆盖率信息，补全测试用例使覆盖到违背覆盖的代码逻辑，此项可以设计根据先前规划的测试用例得出当前所需的输入条件，以便快速实现最大化覆盖。 如果代码的健壮性足够好，在补全测试用例之后，此时一般不会出现异常或者软件退出问题，但功能点容易不满足要求。如果代码健壮性不好对异常数据保护不够，在补全测试用例之后根据分析得出输入条件，此时在运行程序的时候很容易出现异常退出等致命问题。 所以结合以上分析，下面以Pedometer为实例来说明TT使用和分析。 第一步，根据功能点来划分了一系列测试用例，这些测试用例，测试用例描述： Pedometer 手机硬件设置相关用例：该测试用例包括手机加速器以及灵敏度设置项、手机屏幕超时设置项。该用例主要影响Pedometer在屏幕待机与否的情况下加速器灵敏度相关逻辑的设置。 Pedometer 语音设置项相关用例：该测试用例包括Pedometer语音相关设置，在使用Pedometer中是否播报以及播报信息种类和间隔时间 Pedometer使用者信息设置相关用例：该用例包括