ThreadingTest白盒测试04对外集训.pptx

ContentsThreadingTest测试理念测试理念1观观ThreadingTest的进化史的进化史2白盒测试白盒测试静态分析静态分析4白盒测试白盒测试动态分析动态分析5ThreadingTest工具使用工具使用3穿线测试的理念穿线测试的理念什么是穿线测试？n通过技术手段，将开发者和测试者的工作组件串联起（穿针引线），实现功能测试与对应的程序源代码执行逻辑的双向穿线，并在此基础之上将开发与测试两个过程进行紧密的连接。（DevOPS技术：是建立开发与运维之间的联系，打破二者之间的信息鸿沟。）穿线测试穿线测试-ThreadingTest-ThreadingTest什么是ThreadingTestnThreadingTest（简称“TT”）是一款白盒测试软件，将黑盒测试与白盒测试过程以及方法进行完美的融合，以黑盒的测试过程及方法，产生白盒测试的数据，同时TT也是全球首款纯软件类的商用级别的移动端白盒测试工具，可以对各种类型的移动类应用进行测试。TT是一款真正对软件测试过程和结果进行深度量化分析的智能测试工具更是一款测试数据数字化管理工具。产品结构连接开发与测试之间的穿线技术连接开发与测试之间的穿线技术穿线测试通过技术手段，让开发与测试从某种对立关系，变为友好的协作关系，且二者可以充分互动。自动建立的测试制品（测试用例）与开发制品（代码逻辑）之间的双向追溯。双向追溯双向追溯（图）反向追溯界面（图）正向追溯界面围绕双向追溯结果的高效互动围绕双向追溯结果的高效互动测试人员通过“点点点”也可以拿到每轮测试过后的量化数据，和开发人员有依据的讨论如何对覆盖率低的补充用例，让测试人员关注更具技术含量的工作。彻底共享测试与开发信息，测试用例将被开发人员使用到需求确认以及做代码变更时候的支撑数据。1无需测试人员的故障描述、重现等流程，开发可以实时看用例执行的程序内部细节，快速定位问题点。2测试人员通过“点点点”也可以拿到每轮测试过后的量化数据，和开发人员有依据的讨论如何对覆盖率低的补充用例，让测试人员关注更具技术含量的工作。3彻底共享测试与开发信息，测试用例将被开发人员使用到需求确认以及做代码变更时候的支撑数据。多个测试阶段的穿线多个测试阶段的穿线穿线测试的另外一个核心理念是将单元测试、集成测试、系统测试等多个测试结果串联并且共享。测试人员可以看到开发人员单元测试的测试结果，这样就可以将重点放到功能验证，提高测试的效率。开发人员可以直接得到远距离的测试结果。并且快速排查缺陷。1穿线测试的另外一个核心理念是将单元测试、集成测试、系统测试等多个测试结果串联并且共享。2测试人员可以看到开发人员单元测试的测试结果，这样就可以将重点放到功能验证，提高测试的效率。3开发人员可以直接得到远距离的测试结果。并且快速排查缺陷。穿线测试通过一些列专利技术，实现了所有第4代白盒测试技术，并在此基础上做了较大的创新穿线测试的白盒技术穿线测试的白盒技术是否可重复测试是否测试评估是否自动测试是否持续测试是否可双向追溯第一代否否否否否第二代是是否否否第三代是是是否否第四代是是是是否穿线测试是是是是是 黑与白的对比黑与白的对比-最有效的测试理论最有效的测试理论黑盒测试方法白盒测试方法黑与白结合使用的测试方法（穿线测试）通过上述3种方法示意图我们可以看到：传统的黑盒测试在70%前的阶段，查找BUG是非常迅速的，但之后有可能几天都发现不了一个BUG。传统白盒测试虽然稳步上升，但却因为种种因素导致其测试时间过长。结合使用方式：采用前70%用黑盒的测试方式，快速的定位BUG以及制作测试用例和测试覆盖率，当超越黑盒测试的差错瓶颈区后，采用黑盒所得到的覆盖率信息，使用白盒的测试方法来发现隐蔽性强的缺陷和漏测点。提供精确量化的8种覆盖率指标和测试评估数据。支持航天航空最高规格的MC/DC覆盖率标准。提供精确量化的8种覆盖率指标和测试评估数据。支持航天航空最高规格的MC/DC覆盖率标准。实现可持续的测试环境下多版本的覆盖率结果累积。支持企业分布式的测试环境全新的应用功能全新的应用功能1提供精确量化的8种覆盖率指标和测试评估数据。支持航天航空最高规格的MC/DC覆盖率标准。2实现可持续的测试环境下多版本的覆盖率结果累积。3支持企业分布式的测试环境。TT的引入，在几乎对原有常规黑盒测试流程不干扰的情况下，以优雅的形式完成白盒测试。智能的穿线方法，不改变原有测试流程智能的穿线方法，不改变原有测试流程穿线测试介于黑盒与白盒之间，既关注功能的输入输出的正确性测试，也注重内部结构的测试。既包含了黑盒和白盒的优点，又弥补了两者的不足。与黑盒测试无缝对接TT以其独特的技术特性，协同开发和测试人员进行高效的沟通互动，让开发和测试融为一体，通过2+1（测试、开发+TT）的模式。智能的穿线方法，不改变原有测试流程智能的穿线方法，不改变原有测试流程超高速、大型、互动的图形化系统超高速、大型、互动的图形化系统TT支持程序结构图、类继承图、函数控制流程图等多种图形的动态显示。其中”函数调用图”图形具有以下高级特性n支持百万图元级别的超高速图形绘制技术。n支持全屏以及超平滑的放大与缩小技术、平滑的移动技术。n支持按照类分组聚集布图以及按照函数调用关系布图，层次数量可自由定义。n支持逐级的子树展开和下钻功能。n支持在函数图元上显示覆盖率与函数相关信息的显示。超高速、大型、互动的图形化系统超高速、大型、互动的图形化系统函数调用图超高速、大型、互动的图形化系统超高速、大型、互动的图形化系统控制流程图软件示波器软件示波器边做测试边看“示波器”，TT率先引入了测试过程软件示波器的概念，在实际测试的过程中，测试员可以看到类似于心电图的数据获取模式。可以看到在运行游戏过程中，示波器会把游戏运行的块、条件、函数的数量以心电图的形式显示出来。软件示波器软件示波器示波器心电图展示方式和Console模式带来的优点n可视化观察程序运行情况。波形可直观反应程序行为。n在console中能看到最近的函数运行堆栈。n通过波形分析程序在各种硬件平台上的运行性能。n可辅助判断等价类以及分析程序行为的变化。TT示波器的Console模式，让测试人员在测试过程中显示获取的函数名称（显示前50条）。并可以按自己需求以3秒-1分钟的自动刷新或手动刷新获取函数的列表。（1）为自动时间和手动刷新条。（2）为获取的函数所在类名、函数名、函数的参数。穿线测试应用价值穿线测试应用价值使软件开发商、需求方、第三方测试商成本降低至少25%以上。打破软件开发者和软件测试者的交流障碍，建立透明追溯机制。n通过技术手段建立开发与测试的高效互动与联系，大幅解放生产力。n彻底改变测试过程枯燥、无技术含量现状，测试过程变得有趣、实时可监控。n5GWM，将可实施白盒测试技术正式带入业界。n现与敏捷开发的配合，支持增量开发、需求变更、缺陷预防。n傻瓜似简洁操作模式，内部实现复杂，操作简单易理解，可向全球开发、测试人员推广。n在安全事件加速去IOE背景下，率先实现国产商用级的专业测试工具。观观ThreadingTest的进化史的进化史2个人基础版个人基础版 -单机版单机版1.1.企业私有云版企业私有云版2.2.在线云测试在线云测试3.3.专家测试专家测试穿线测试方法穿线测试方法穿线测试方法穿线测试方法TTTT测试工具测试工具专家测试专家测试专家测试专家测试星云测试星云测试星云测试星云测试（在线测试）（在线测试）（在线测试）（在线测试）1.TT测试产品，分基础个人和企业私有云版2.专家测试，基于我们穿线测试方法以及测试标准，对用户做专家测试服务，希望希望储备并培养专家测试团队储备并培养专家测试团队3.星云测试，是基于在穿线测试理念和方法搭建的云测是平台，我们可以提供给用户专业的测试平台和数字化分析汇总ThreadingTestThreadingTest工具介绍工具介绍3 ThreadingTest（简称“TT”）是一款白盒测试软件，将黑盒测试与白盒测试过程以及方法进行完美的融合，以黑盒的测试过程及方法，产生白盒测试的数据，同时TT也是全球首款纯软件类的商用级别的移动端白盒测试工具，可以对各种类型的移动类应用进行测试。TT是一款真正对软件测试过程和结果进行深度量化分析的智能测试工具更是一款测试数据数字化管理工具。穿线测试的测试过程：穿线测试的测试过程：个人基础版个人基础版 1.用TT编译工程2.连接并映射TT和测试设备（例Android：真机/模拟器）3.编写并执行测试用例，示波器接受实时的测试数据4.通过个人版开放的功能去做白盒测试分析 企业环境中使用企业环境中使用 1.开发工程师使用TT编译组建去编译打包工程（APK）2.测试工程师通过安装APK，连接TT测试客户端进行测试数据收集3.ITC企业私有云自动汇总测试数据，测试工程作白盒测试分析ThreadingTestThreadingTest使用常见问题使用常见问题TTTT插桩编译类问题：插桩编译类问题：1.如果项目存在较为复杂的项目依赖，个人版的一键式编译方式可能会编译打不成功 解决方案跟TT的技术支持沟通并走TT企业版申请的流程 2.出现语法错误，请反馈给TT的技术支持，技术支持会给出解决方案 3.如果项目不是eclipse结构的，也会出现个人版一键式编译方式失效 解决方案跟TT的技术支持沟通并走TT企业版申请的流程 TTTT连接类问题，一般表现为接受不到测试数据连接类问题，一般表现为接受不到测试数据可能的原因可能的原因:1.做端口映射的端口5037被别的应用占用，一般会占用的有（手机助手、豌豆荚、360软件管理）查看并杀死该进程之后重新做端口映射 2.设置本机IP和端口映射的顺序反了，正确的顺序是设置IP-端口映射 3.被测Android程序的Manifest文件中没有加数据传输的权限，因此接受不到数据，应加上对应的权限之后重新打包APK，安装并测试 4.公司网可能存在防水墙、防火墙，这个也会会导致端口映射不成功 白盒测试白盒测试静态分析静态分析4 白盒测试又称透明盒测试，软件测试的主要方法之一，测试应用程序的内部结构和运作运作。函数函数 调用图调用图控制控制流程图流程图代码逻辑代码逻辑复杂度分析复杂度分析静态分析常用的方法：静态分析常用的方法：白盒测试工程师在做静态分析的时候需要对程序进行函数调用图和控制流程图的绘制，工作量较大，另外代码逻辑复杂度分析人工分析也比较耗费时间 通过查看函数调用关系图，可以检查函数之间的调用关系是否符合要求，是否存在递归调用，函数的调用是否过深，有没有存在独立的没有被调用的函数。从而可以发现系统是否存在结构缺陷，发现哪些函数是重要的，哪些是次要的，需要使用什么级别的覆盖要求ThreadingTestThreadingTest代码结构自动图形化绘制代码结构自动图形化绘制函数调用函数调用关系图关系图 01支持百万图元级别的超高速图形绘制技术。02支持全屏以及超平滑的放大与缩小技术、平滑的移动技术 03支持按照类分组聚集布图以及按照函数调用关系布图，层次数量可自由定义。04支持逐级的子树展开和下钻功能。05支持在函数图元上显示覆盖率与函数相关信息的显示CCallGraph ThreadingTestallGraph ThreadingTest的函数调用图具有以下高的函数调用图具有以下高级特性级特性 程序流程图是最容易理解的一种程序控制结构的图形表示法。控制流控制流程图程图可视化的控制流程图，对主要的控制逻辑语句对应有清晰的图元显示，支持嵌套显示以及串联显示。点击控制流图的每个图元可以看到对应的代码段以及代码段的执行次数、覆盖率情况。在控制流图的代码段，当条件语句成为选中热点后，可以看到条件语句的各个子条件的各种组合执行的真假情况。支持缩略图的显示，可平滑的进行缩放以及全屏显示。01020304CControlFlow ThreadingTestontrolFlow ThreadingTest的控制流程图具有以下的控制流程图具有以下高级特性高级特性复杂度复杂度分析分析 代码复杂度指：代码中所含分支语句的数目，包括“if”，“for”,“while”,“do-while”,“switch-case”等语句。对于高复杂度的模块来进行重构，或者进一步模块化。通过高复杂度的模块的控制流程图和逻辑框图的复杂程度可以让测试工程师与软件维护者判断该软件产品的可测试性和可维护性。nJC0JC0基本段的测试复杂性基本段的测试复杂性 JC0=一段代码中包含的所有可见段（可执行的代码块）的个数nJC1JC1标准段测试复杂性标准段测试复杂性 JC1=一段程序包含的标准段的个数（所有可见段+不可见段0+不可见段2）nJC1+JC1+增强标准段测试复杂性增强标准段测试复杂性 JC1+=一段程序包含的增强标准段的个数 （所有可见段+不可见段0+不可见段2+不可见段1）nJC2JC2条件条件-段的测试复杂性段的测试复杂性 JC2=所有可见段+不可见段+所有条件判断语句个数。nCyclomaticCyclomatic循环度量复杂性循环度量复杂性 Cyclomatic Complexity又称圈复杂度/循环复杂度，圈复杂度大说明程序代码可能质低且难于测试和维护不可见段不可见段0 0（if和swicth）判断体结束后的不可见段,即if和switch中条件判定式不满足的情况，会存在一个不可见段不可见段不可见段2 2（for、while和do-while）循环体结束后的不可见段，即for、while、do-while循环条件不满足时会正常跳出循环，这时会存在一个不可见段。不可见段不可见段1 1（for和while）非正常的结束循环体时的不可见段，也就是指for和while循环体一次都没有被执行的情况，这时会存在一个不可见段。1.帮助测试工程师判断软件产品的可测试性，高复杂度的软件可测试性差、需要花费的测试成本高。2.帮助软件维护者判断软件产品的可维护性，高复杂度的软件可维护性差，维护成本高。3.帮助测试工程师做测试的复杂性分析，高复杂度的代码需要设计较多或者较为充分的测试用例来达到测试目的。4.有了自动化的复杂度的分析，开发人员就可以针对性的对代码重构或者模块化，提高代码的可维护性、可测试性、可读性，强化代码结构，降低bug风险。CComplexityomplexity可以帮助我们做些什么？可以帮助我们做些什么？白盒测试白盒测试动态分析动态分析5 什么是白盒测试的动态分析法？动态分析的主要特点是当软件系统在模拟的或真实的环境中软件系统行为的分析。在动态分析技术中,最重要的技术是路径和分支测试。逻辑覆盖法是最常见的动态分析方法之一，是以程序的内部逻辑结构为基础的测试用例设计技术。它要求测试人员十分清楚程序的逻辑结构，考虑的是测试用例对程序内部逻辑覆盖的程序。ThreadingTest是如何做到自动获取程序内部逻辑覆盖信息的？ThreadingTest通过自主研发的自动插桩技术，在不破坏被测试程序原有逻辑完整性的前提下，在程序的相应位置上插入一些探针。通过探针收集程序的运行特征数据。基于对这些特征数据的分析，揭示程序的内部行为和特征。01 语句覆盖 02路径覆盖 05条件-判定覆盖 04条件覆盖 03判定覆盖 06修正条件-判定覆盖ThreadingTest实现了自动统计多种覆盖率，达到商业规范段覆盖SC0、SC1、SC1+TTTT覆盖率种类覆盖率种类条件判定覆盖Branch 判定覆盖TRUE、FALSE、BOTH 条件覆盖C/DC-条件/判定覆盖MC/DC-修订的条件/判定覆盖覆盖率 =测试覆盖到的程序段的个数 /要统计的程序段的个数nSC0SC0=被执行的块个数/该段程序包含的块个数(即可见段个数)。nSC1SC1=被执行的代码块（包括不可见段0以及不可见段2）/该段程序包含的块个数（包括不可见段0以及不可见段2）。nSC1+SC1+=被执行的代码块（包括不可见段0,不可见段2以及不可见段1）/该段程序包含的块个数（包括不可见段0,不可见段2以及不可见段1）。不可见段不可见段0 0（if和swicth）判断体结束后的不可见段,即if和switch中条件判定式不满足的情况，会存在一个不可见段不可见段不可见段2 2（for、while和do-while）循环体结束后的不可见段，即for、while、do-while循环条件不满足时会正常跳出循环，这时会存在一个不可见段。不可见段不可见段1 1（for和while）非正常的结束循环体时的不可见段，也就是指for和while循环体一次都没有被执行的情况，这时会存在一个不可见段。覆盖率(SCn)=测试覆盖到的程序段的个数 /要统计的程序段的个数(JCn)判定覆盖n【BranchBranch】设计若干测试用例，运行被测程序，使得程序中每个判断的取“真”分支和取“假”分支至少经历一次，即判断真假值均曾被满足。条件覆盖n【TRUETRUE】设计若干测试用例，运行被测程序，使得程序在每个条件中取“真”分支至少经历一次。即TRUE达成100。n【FALSEFALSE】设计若干测试用例，运行被测程序，使得程序在每个条件中取“假”分支至少经历一次。即FALSE达成100。n【BOTHBOTH】设计若干测试用例，运行被测程序，使得程序在每个条件中取“真”和“假”分支至少经历一次。即BOTH达成100。条件/判定覆盖n【C/DCC/DC】设计足够的测试用例，使得判断条件中的所有条件可能至少执行一次取值，同时，所有判断的可能结果至少执行一次。即C/DC达成100。修订的条件/判定覆盖n【MC/DCMC/DC】MC/DC是DO-178B Level A认证标准中规定的,欧美民用航空器强制要求遵守该标准。1、程序中的每一个出口、入口都被调用至少一次。2、程序中判定的每一个条件都执行所有可能的输出至少一次，程序中每一个判定结果执行所有可能的输出至少一次。3、在每个判定中的每个条件都曾独立的影响判定的结果至少一次,(独立影响意思是在其他的条件不变的情况下,改变一个条件)，即每个条件对结果都独立起作用。public boolean canBeCaughtByBullet(BulletSprite bulletSprite)if(name=Fish_Name.SARDINE)return CapturedProbability.getInstance().SardineCanBeCapturedByBullet(bulletSprite.getRank();else if(name=Fish_Name.CLOWNFISH)return CapturedProbability.getInstance().ClownFishCanBeCapturedByBullet(bulletSprite.getRank();else if(name=Fish_Name.PUFFERFISH)return CapturedProbability.getInstance().PufferFishCanBeCapturedByBullet(bulletSprite.getRank();else if(name=Fish_Name.TORTOISE)return CapturedProbability.getInstance().TortoiseCanBeCapturedByBullet(bulletSprite.getRank();else if(name=Fish_Name.SHARK)return CapturedProbability.getInstance().SharkCanBeCapturedByBullet(bulletSprite.getRank();return false;SC0：绿色部分为段覆盖的代码，总共六条，如果要满足全部段覆盖需要设计5个测试用例（当每个条件满足时候，return false 都将被执行，所以只需设计5个测试用例就能满足SC0）SC1：当5种条件都不满足时候，将产生一个隐藏分支测试完全充分需要设计6个测试用例例1：SCO和 SC1的计算例2：SCO、SC1、SC1+的计算public void creat_Curve_Group(Fish_Name fishName,ArrayList movingFishList,TiledTextureRegion fishTextureRegion,Scene scene)Move_Direction direction=this.getDirection();int a=Math.abs(random.nextInt()%41-20;while(a=0)a=Math.abs(random.nextInt()%41-20;for(int i=0;i Configure Build Path，添加robotium-solo-X-X.jar到Libraries中。（3）使用Robotium的测试用例代码框架和Instrumentation用例类似，都是继承ActivityInstrumentationTestCase2基类 注意：如果是用Robotium做集成测试的话，使用的是ActivityInstrumentationTestCase2基类，如果是单个Activity，可以选择继承ActivityInstrumentationTestCase2泛型类。（4）编写测试用例，在测试准备函数setUp中可以通过getInstrumentation（）和getActivity（）方法获取当前测试的仪表盘对象和待测应用启动的活动对象，并创建自动化测试的solo对象（5）在测试结尾tearDown中，会调用Robotium api关闭所有已打开的活动，为后面执行测试用例恢复测试环境RobotiumRobotium编写集成测试用例编写集成测试用例public class DemoTestLogin extends ActivityInstrumentationTestCase2SuppressWarnings(unchecked)public DemoTestLogin()throws ClassNotFoundException super(Class.forName(LAUNCHER_ACTIVITY_FULL_CLASSNAME);/TODO 自动生成的构造函数存根private static String LAUNCHER_ACTIVITY_FULL_CLASSNAME=com.kaixin.android.activity.LoginActivity;private Solo _solo;Overrideprotected void setUp()throws Exception/TODO 自动生成的方法存根_solo=new Solo(getInstrumentation(),getActivity();Overrideprotected void tearDown()throws Exception/TODO 自动生成的方法存根 _solo.finishOpenedActivities();public void test登陆()throws Exception/登录的测试用例编写多元化的获取多元化的获取ViewView：方式工具说明通过R.id获取ViewSolo.getView(com.example.android.notepad.R.id.menu_add)在有源码情况下非常方便，没有源码不可用通过resource id name 获取View：solo.getView(“menu_add”)查看ID方式为：HierarchyViewer.bat工具Uiautomatorviewer.bat工具不需要源码，就能定位viewHierarchyViewer：需要开发机、模拟器，市面商用机需要破解才能使用一般有风险,速度慢。UiautomatorViewer：需要android4.2以上才能获取控件ID通过文字获取View：local.findViewsByTest(“add”)所见即所得，无需分析工具辅助定位，缺点是程序改动文字会导致代码失效，没有上面2种稳定测试用例执行演示测试用例执行演示Robotium Robotium 与与TTTT集成集成TT扩展Instrumentation与Robotium对接1、TT通过扩展Instrumentation框架并提供出来相关SDK以及接口来实现robotium与 TT的深度结合2、在原有的robotium开发过程中只需要改变相关测试类派生的相关基类就可以使用TT 相关api接口，能很容开发出基于robotium的自动化白盒测试程序，和传统的 robotium的测试流程几乎没有差别 3、结合robotium的自动化测试框架以及TT的代码级的测试结果统计，可以更加清晰透 明的可以同时得出功能级、代码级的测试结果 Robotium Robotium 与与TTTT集成集成TT扩展Instrumentation接口说明 TT在重载了Instrumentation测试类的setUp和tearDown函数的测试类中，需要分别调用super.setUp()和super.tearDown()函数，否则无法对数据进行进行测试用例的区分，如果没有需进行初始化和资源释放则不用继承setUp()和tearDown()函数，如下是TT扩展接口派生说明只列举部分其余类似InstrumentationInstrumentation接口开发接口开发 使用Android JUnit Test测试，也存在两种测试方法，测试驱动与测试代码在同一工程下和测试驱动和测试代码位于不同工程，两者之间并无巨大差异，只是在测试时，前者只安装一个App，后者安装两个App，本例子是采用的同一个工程下面，有如下步骤 1、修改工程AndroidManifest.xml文件InstrumentationInstrumentation接口开发接口开发2、测试用例开发，要使用ThreadingTest进行Android Junit测试类的编写，需要将所有的测试类写到一个单独的文件夹下，在进行编译工程时，使用参数-filter将其从编译路径中排除，不对其进行插桩，如下图所示被测源码放在src文件夹中，测试驱动代码放在test_src文件下。3、引入ThreadingTest Android jar包，JavaParser-Android.jar和通信包jeromq-0.3.0-SNAPSHOT.jar，添加至构建路径下InstrumentationInstrumentation接口开发接口开发4、将继承Android JUnit Test类换成继承ThreadingTest Android JUnit Test类，ThreadingTest Android JUnit Test类中与Android JUnit Test相对应的类为在类名前加TT。例如与InstrumentationTestCase相对应的类为TTInstrumentationTestCase，TT Android JUnit Test类所在的包为com.zoa.android.test5、在重载了setUp和tearDown函数的测试类中，需要分别调用super.setUp()和super.tearDown()函数，否则无法对数据进行测试用例的区分，如果没无需进行初始化和资源释放则不用继承setUp()和tearDown()函数6、其他操作、测试用例方法开发同原有robotium相同InstrumentationInstrumentation接口开发接口开发7、TT编译工程 8、TT编译生成apk运行robotium并使用TT监控接受测试数据。TT1.8版本编译界面基于基于TTTT的的robotiumrobotium测试用例的运行测试用例的运行 由于采用测试用例的自动生成，基于TT的robotium开发，测试程序需要和TT存在握手消息，首先需要保证TT处于示波器监控开启状态，并手动创建自动生成测试用例所要创建的用例，目前基于有3种方式可以启动测试用例。运行测试类有三种方式，包括：1、命令行方式 使用adb命令启动Android测试2、eclipse中选择Android JUnit Test运行方式 在eclipse中，右击测试工程，选择run as-Android JUnit Test3、模拟器或者安装有Devtools的真机中，使用Dev Tools 安装Dev Tools工具后，运行选择Instrumentation下显示的与 android:label同名的标签运行instrumentation测试使用使用TTTT扩展扩展InstrumentationInstrumentation运行实例运行实例安装经过TT编译的测试apk之后可以通过以上3种方式来启动apk测试注：如果遇到以下错误可能是测试apk和被测试apk签名不一致导致，需要卸载掉之前的安装包在次运行即可