qileilove

　　使用思维导图设计用例的注意事项：

　　1、分级：

　　第一级：按测试的类型划分，如功能测试，交互测试，性能测试（可以是如懒加载，异步加载等内容涉及到性能改进的），异常测试（也可以放入功能测试下）等。对于功能涉及面广的一定要严格区分出来，并且需要特别重视异常测试的内容；

　　第二级：按照需求的测试点划分，一般可以划分为多个测试点；

　　第三级：如果测试点可以细分到测试子项，就把测试子项作为第三级，否则直接在测试点后面写用例。

　　2、对于功能测试下的分级：

　　可以按照组件，功能流程，数据层面，UI层面及异常情况等来进行分级。

　　3、对于具体测试用例的编写，注意逻辑性及条理性：

　　1）如果好几条用例是在某个条件下完成的，是属于控制和被控制的关系，则可以放入该条件的节点下；

　　2）如果用例是属于某个功能点下的，属于包含与被包含的关系，那也放到它下面；

　　3）如果用例之间执行有顺序要求，则标记好序号1，2，3；

　　4）保证同级之间的用例是相互平行，互不影响的，如果有相互间的影响，那肯定得有层级关系；

　　5）书写用例时每条最好是说明一件事情，而且得出的是肯定或否定的结论，不要出现“是否，有可能，可否”等等 字样，结果必须确定；

　　6）用例中最好不要出现操作步骤，这个属于具体用例中的内容，但如果不多可以使用括弧备注。

　　总之，思维导图是指导我们的思维过程，但是所有的思维发散都要有一个模型，在模型基础上进行发散思维，这样子，我们思考时候才是有条理的，进行测试时也才有条理性，没有条理性的用例迟早会出乱子，有遗漏。

　　我画了个示例图。以简单的邮件订阅为例：

　　以这张图来说，会比较有条理性，即使给其他人看也能明白，当然，这里面对邮箱格式的测试，其实不用这么啰嗦，可以直接对开发人员使用的正则表达式进行测试即可，关于正则表达式如何帮助我们更高效的测试，不是本文的重点，以后可以找个专题来说。

版权声明：本文出自 zzzmmmkkk 的51Testing软件测试博客：http://www.51testing.com/?258885

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　前文提到，测试用例代表了软件测试的工具方面，是它的核心之一。那么什么是测试用例，它又有哪些要点需要我们去掌握？

　　1.4.1  什么是测试用例

　　软件测试的核心行为就是针对要测试的软件设置测试用例。所谓测试用例，英文名为Test Case，是一个与程序部分行为以及输入、输出相关的描述或者标识。

　　【测试用例的IEEE定义】

　 　美国电气与电子工程师协会（IEEE，The Institute of Electrical and Electronics Engineers），它出台了一个标准的测试用例定义，即"测试用例是描述输入实际值和预期输出行为或者结果的文档，它同时也标识了测试过程结果与约 束。"

　　在实际工作中，花费测试工程师大部分时间的，都是与测试用例相关的。

　　1.4.2  测试用例的几大要素

　　一般来说，测试用例应该清楚地描述出对被测试软件发出什么数据或者条件，以及该输入所期望的结果。在小白这样的商业网站，测试部门规定测试用例应该具备如下几个要素。

　　1．标识符

　 　这一点虽然和测试用例的内容没有关系，但却是测试过程中不可缺少的。比如，小白所在的部门每周都要开一次例会，向经理或者开发部门的同事说明当前整个产 品的测试状态，有时候需要特别指出某个测试用例的内容，那么用一个简单的代号来代表这一测试用例是非常适合的，这个代号一般情况下都是一个正整数，比如 1、88、437等这样。在小白所在的公司，测试用例是存放在一个数据库中的，代号也就自然地采用了数据库系统中的标识符字段类型。如果采用其他的方式存储测试用例，可以人工指定，只要保证标识符不重复就可以了。

　　如图1-6显示了应用于真实测试场景的某测试用例文档，它实际上是一个Office Word文件，测试工程师（即编写者）在文件内容中手工指定了各个测试用例的标识符。

图1-6  测试用例的标识符

　　2．测试的内容

　　测试内容可以说是测试用例最重要的部分，它一般指明了当前测试用例的运行目的，比如测试网页是否可以打开、单击按钮后是否能够显示正确的计算结果等。在很多情况下，测试内容与下个要点：输入的条件区别并不是很清楚。

　　3．输入的条件

　　输入条件可以是操作步骤，也可以是输入的数据，还可以是系统运行环境的需求（比如处于某种特别的操作系统环境内这一条件）。图1-6中的各个测试用例，都详细地写明了每一步骤的具体操作。

　　【复现步骤】

　　对于被测试软件而言，不同的输入条件会导致不同的输出预期，因而可能出现的Bug表现并不一定相同。如果重复某些输入条件，总会导致某个Bug的出现，那么就把这些输入条件称为Bug的复现步骤（Repro Step）。

　　该项信息描述了在当前的输入条件下，预期的输出。比如计算器程序中十进制数字的2+3的输出应该等于5。若输出预期与实际结果不同，则应该考虑 为Bug的可能性（有的时候，输出预期也会随项目的进度而变化，因此预期与实际不同并不意味着100%是Bug，此时需要与项目经理等相关人员进行协 商）。

　　5．测试环境信息

　　这一部分的内容描述了该测试用例所适用的环境，比如操作系统的版本，所依赖硬件软件的版本、语言等。测试环境信息有时候也可以成为输入条件或者 复现步骤的一部分，比如某个按钮只有在IE浏览器中才会出现、某个Bug只在IE浏览器中才会产生，那么IE既是测试环境信息，也是输入条件和复现步骤。

　　6．与其他测试用例的依赖关系

　　在测试某些软件的时候，比如MSN，如果登录这个测试用例都无法通过，那么剩下的发消息，发文件等测试用例也肯定继续进行（除去直接调用接口的 那些测试之外），这就是一种测试用例之间的依赖关系。合理地应用测试用例之间的依赖关系，能够提高测试效率，减少无谓的测试时间浪费。

　　7．测试用例需要被开发、审阅、使用、维护和保存

　　这也是测试工作很重要的一部分。软件的说明书Spec可能会变化，因此测试用例需要变化，这就要求对测试用例进行增加、修改和删除。测试用例是 文档，需要有固定的场所进行保存，一般是数据库或者文件。测试用例需要审阅，以达到预期的效果和更高的工作效率（重复的测试用例肯定会浪费测试工程师的时 间）。

　　1.5  软件测试的核心II：测试工程师

　　除了测试用例之外，软件测试的另一个核心，同时也更为关键，就是测试工程师了。这是因为，测试用例也是由测试工程师来编写的，受人的因素影响很大。可以说，人是决定软件成败的主要因素。本节将介绍测试工程师所必备的一些素质。

　　1.5.1  测试工程师与软件质量保障

　　有的时候我们在招聘广告上能够发现有些公司招聘测试人员的时候，列出的职位名称是软件质量保障工程师（QA，quality assurance），那么这两种称呼是否是代表同一种工作内容呢？

　　回答是基本一样，但有细微不同。软件测试工程师的主要职责在于发现并确认Bug的解决与否，而软件质量保障工程师则更进一步，在测试工程师的职 责之外，还包括创建、维护为保障软件质量而确立的规范、规则与流程，比如软件配置管理（Software Configuration Management，又称SCM工程师）等。

　　【字面意义的理解】

　　从字面意义上来看，测试工程师主要针对软件的已有Bug，类似体检部门；而软件质量保障工程师则不光针对已有Bug，还对预防Bug的产生提出建议，类似健康顾问。当然，在实际工作中，两者的区别并不是那么清晰的，在很多公司内部，他们所从事的工作内容是完全一致的。

　　1.5.2  测试工程师应该具备的素质

　　一个合格的测试工程师，应该具备如下专业素质：

　　具备基本的数据结构，操作系统等专业知识。这一点对于从事性能测试的人员来说更为重要。

　　具备一定的程序开发经验。掌握一到两门语言对于进行自动测试是大有益处的，另外，具有程序开发经验，也更容易理解软件Bug的来龙去脉。这一到 两门语言可以是某些高级语言，比如C#和VB.net，以及一种脚本语言，比如JavaScript、VBScript或者Python等的组合。

　　软件使用经验丰富，对于软件的不正常行为敏感。这一点对于发现Bug是很有帮助的。

　　同时，测试工程师还应该具备如下的性格特征。

　　有好奇心，乐于探索软件功能，乐于尝试新的软件产品。

　　乐于探索谜题，追根溯源。对于一个Bug，必须有追根溯源的精神，才能够发现它的特点，这个性格特征在判断Bug的产生原因，以及是否与其他Bug重复等日常的工作内容中都会展现。

　　必须具备一定的创造性。测试工程师是无法模拟出用户使用软件的所有场景的，因此必须具备一定的创造性，通过测试更多情况下软件的不同表现，发现被测软件更多的问题。

　　具备一定的沟通和交流技巧。这一点尤为重要，测试工程师由于工作性质的要求，要给开发工程师所编写的代码找到问题。因此在平时的工作中要注意利 用良好的沟通、交流技巧，使得开发工程师能够接受自己正确的观点，在保证软件质量的情况下不影响团队的合作氛围，让整个团队都体会到测试工程师和测试工作 的重要性。

　　1.5.3  测试工程师的职业发展

　　软件测试工程师在我国尚属一个比较新的职业，目前专业人才相对缺乏。另外，和软件开发相比，软件测试具有进入门槛相对较低，职业生涯相对较长的特点。因此，从事软件测试的职业是具备较好的发展前途的。随着工作经验的不断积累，比较好的发展路        径是：

　　初级测试工程师。进行黑盒手工功能性测试（第2章我们将讲解什么是黑盒测试、功能性测试）或者本地化测试等，一般是从学校毕业后参加工作的2～3年，正处于学习或者进一步熟悉、巩固测试基本知识与方法的阶段。

　　中级测试工程师。进行测试计划的编写，测试工具的开发，各种测试的实施等。处于这一阶段的人员，相比于初级测试工程师工作了更长的一段时间，掌握了测试的基本理论和知识，对软件开发流程有了比较深入的了解，同时对某项软件开发技术有较深入研究的程度。

　　高级测试工程师或者测试经理。经历了初级和中级测试工程师的磨炼，从头至尾参与了一个产品或者多个产品的生命周期，在其他方面能力也具备的情况下，就可以从事这样的职位了。工作职责一般是统筹软件的测试计划，决定测试方法，确立、实现测试框架，管理控制测试进度等。

　　开发人员。实际上，从测试人员转为开发人员的比例不算小，因为测试人员对产品比较熟悉，如果自身的开发能力较强，往往具备纯开发人员所不具备的测试知识和用户视角，因此编写的代码质量更高。

　　以上是软件测试工程师的发展路线。在公司的选择上，一般来讲，大型或者国外的企业往往更加重视测试，所以软件测试工程师更多出现在这样的企业中，导致其平均薪资水平相对比较高。对于想从事初中级测试工程师的读者来说，一般可以考虑如下4类公司。

　　国内的IT相关企业。这些企业大致有各软件开发公司，通信、电子、游戏公司等。

　　外资企业在国内的研发中心。这类公司的产品开发人员相对更集中在公司总部，同时为了节省成本，测试工程师则较多地安排在国内。

　　为外资企业做软件外包的国内企业。微软、Google、IBM等很多在华的跨国企业都会聘用这些企业的员工进行外包测试工程师的工作。

　　大型网站。中小型网站往往没有专职的测试人员；大型网站由于架构较复杂，分工相对更为专一，会有专职的测试工程师队伍以保证质量。

　　1.6  本章小结

　　本章通过刚刚作为软件测试工程师新人的小白短短几天的经历，对软件测试的基础知识进行了简要的介绍。

　　在本章的开头，给出了公认的软件定义。所谓软件，就是计算机系统中的程序和相关文件或文档的总称。

　　随着软件越来越复杂，软件危机逐渐出现，人们为了从软件开发的初期就避免出现这样的问题，研究总结出若干软件生命周期的模型，主要有如下4种：

　　Big-Bang大爆炸模型；

　　Code and Fix边做边改模型；

　　Waterfall瀑布模型；

　　Spiral螺旋模型。

　　通过在工作中应用这些模型，很好的进行了软件项目管理。

　　但是，软件中的Bug依然不可避免。所谓Bug就是软件的错误或者偏差。在软件开发的过程中，越早发现Bug就越能节约软件开发的成本。

　　编写测试用例，利用人工或者自动的方法寻找被测试软件Bug并确认修复，是软件测试工程师在工作中要完成的职责，加上有效的预防Bug产生的规范，就可以在很大程度上保障软件的质量。

　　（未完待续）

相关链接：

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载一)

捉虫记--大容量Web应用性能测试与LoadRunner实战(连载二)

　　先说招聘吧！我觉得有几点是比较重要的：

　　1、不太去关注答案，应该更关注应聘者回答问题的思路及方法；

　　2、不要太关注工作经历，而更多的是经验；

　　3、面试过程最好更轻松随意一些，应聘者更自然和真实的表现才能了解他们更真实的东西。

　　面试问题二三事

　　我不是透露各大IT公司面试题的，而是说说面试中都会问到什么样的问题，总结来看，无非是在操作技能，知识面，工作经验，工作能力及沟通水平几方面做考察。但是，很多面试官和应聘者都不明白哪方面应该是面试中考察的重点。

　　1、操作技能

　　如果你会被问到vi的一些命令没答上来，linux中如何查看进程，如何创建目录难倒你了，其他表现都很不错，面试官因为这个否定了你，这只能说明他们不知道操作技能意味着什么。我觉得，只要google或百度一搜索就可以找到答案，没有必要去记住它，如果每天都在用，自然而然就记住了，一年不用，谁都会忘记，但是到时候再需要的时候，又能轻松重拾。我们可以把这些常用的操作存到个人笔记中，Evernote，有道云笔记都是好选择，可以速查。

　　2、知识

　　知识是一个人善于学习和 认知的体现，可能是一些概念和理论基础。知道怎么做，那是操作技能，知道为什么这样做，才是知识。知识越丰富的人也才意味着对问题的认识才会越深入，知其 然并知其所以然。也许，知道怎么做就足以应付工作了，但是当需要对更复杂问题进行处理的时候，光知道如何操作就难以应付了。就好比一个测试新 人，提交bug的时候多是只说明了现象，而测试经验丰富的人会分析下出现这个bug的原因和条件，可以给开发人员一些提示，更快的定位问题。但是一定要给 出有把握的分析，否则可能会误导开发人员。这里的经验其实就是知识的积累，积累的越多经验也就越丰富，在分析问题解决问题时也才更快速。

　　3、工作经验

　 　经验不等同于经历，只能说没有经历过的人肯定没有经验。我觉得，经验=知识+经历，对自己所做过的事情有所思考，并逐步学习积累个中知识，理顺前因后 果，才能成为经验。经验是对所掌握知识的运用和驾驭。面试官可以问问，工作中你遇到过什么难以解决的问题？当时又是如何处理的？给一道即兴发挥的用例设计题，或者如何设计测试体系的。

　　4、潜力

　　任何成功的人光有前面的三条：操作能力，知识，经验远远不够，还有更重要的潜力。潜力可能包括态度，工作方式，思维方式，做事风格及分析问题解决问题的能力等，而且这些软实力至关重要，决定了他能做的有多好，前面3条只能代表他能做什么。

　 　所以，对于一个应届毕业生来说，可能前面三条都不具备，不能说这个人没有能力，只要有端正的态度，良好的学习能力，沟通能力，总结能力，分析定位解决问 题等方面的能力，获得大家的认可是迟早的事。而对于一个老手，如果缺乏知识及工作经验的话，肯定就是最后一条没有做到位。

　　不容质疑，这 四点具备的人才能真正算是一名优秀的测试人员，当然对于其他行当的人来说，这4点一样重要。他们不是独立的，是相辅相成的，有潜力的人一定可以更快的学到 知识，积累到经验，通过知识和经验的积累又会反过来提高能力，增强潜能。所以，我的观点是面试官应该更关注潜能，这样招聘到的人才能更好的服务于企业。当 然，如果像富士康一样，只想找会操作的人，没必要为他的潜能支付更多的报酬，这是个例外。在IT企业里，我想企业都是求贤若渴的吧？

　　如何成功的面试？

　　1、如果光问一些操作上的东西，而忽视了应聘者其他方面，完完全全算是一次失败的面试；

　　2、如果面试只是问了一些工作经验和相关知识，只能算是了解了这个人做过什么和知道什么，算成功了一半；

　　3、只有更深入的了解他的潜能，对于未做过的事未解决过的问题，他的处理思路，思考方法以及对待这个问题的态度，才真正决定他还可以做什么。这样才算是一次成功的面试。

　　4、另外，是否遇到过这样的面试官，如果应聘者每个问题回答的都很好，他不甘心，非要出个难题难倒你，来证明他有多牛，应聘者回家告诉他的朋友今天又被BS了。其实没有必要，因为我们面试的目的是要应聘者证明他的实力，通过面试来找到他们的亮点和长处。

　　test_support_ui_project：

　　提供一些UI的基本操作（功能）和性能相关内容，主要是性能，收集几种最终要的性能数据；

　　realibility_test_project：

　　封装test_support_ui中的性能测试内容，对chrome进行稳定性测试，包括稳定性测试，crash收集，报告等；

　　执行相关有：

　　pyautolib_project：

　　chrome相关的pythonUI测试框架，将uitest的C++导成python然后进行执行；

　　webdriver_project/chromedriver_project：

　　为外部网站测试提供支持，比如selenium，webdriver等；

　　还有三个我觉得不错的和自动化有关的部分：

　　breakpad的引入：

　　crash的收集报告框架，在测试框架中引用它，对测试过程中出现的crash进行dump收集，并统一分析；

　　IAccessible的实现：

　　使用代理方式在views库中封装IAccessible的接口，共外部进行界面相关的获取；实现方式和我在MASS实现中提到的一样，继承统一基类，注册，然后分别实现自己的UI支持；

　　memory_watch：

　　chrome中的内存检监测小工具。

　　大概先看了一个雏形，感觉里面的自动化架构设计很漂亮，虽然涉及到的部分很多，也很碎，但是看样子chrome都已经分而治之了。界面的功能和 性能，页面的功能和性能，js的功能和性能，后台数据的获取和安全，页面的渲染，插件的稳定，性能数据的获取和分析，dump的采集和报告，基本上每一个 部分都能深入去了解。有时间了慢慢的再研究一下。

　　白盒部分：

　　和很多国外的产品一样，白盒测试部分比重很大，整个chromium中的自动化测试，白盒部分超过25%或者更多（没有具体计算这个数字），白盒测试大概可以分为两个类别，单元测试和交互测试，它们的测试框架不同，分别是gtest和google mock。

　　核心工程：

　 　核心自动化工程是automation，在chromium/src/chrome/test/下面，包含大部分自动化测试的代理部分，所有内部测试通 过ENABLE_AUTOMATION进行编译的开关。这个代理架构上，是两个UI相关的的架构，一个是对外的chrome界面的自动化操作，一个是内部 view的界面库测试。代理的提供者在其他的自动化项目中，automation下面的代理和非代理部分都有各自的提供者。chromium中的自动化其 实是一套很不错的C++自动化架构，准确来说不是一套，但是大思路一致。其中：

　　automation_proxy.h/.cc：

　　自动化的总代理，用来和提供者automation_provider.h/.cc进行信息的交互，并且包含其他具体代理；代理是ipc的方式；

　　browser_proxy.h/.cc：

　　browser的代理，主要用来和browser的automation_provider进行交互，测试chrome界面的主要部分，包括tab的处理等；

　　tab_proxy.h/.cc：

　　tab的代理，用来和tab的provider进行交互，测试的应该是固定tab页内的js相关；

　　automation_json_request.h/.cc：

　　Json格式的数据传输，很多数据都是Json方式传输的；

　　window_proxy.h/.cc：

　　同样的道理，window相关的代理。

　　主要自动化测试工程分为三类，功能、性能和执行，其中：

　　功能包含：

　　chrome_frame_project：

　　chrome frame相关，主要是插件方面；

　　browser_project：

　　chrome主界面的测试相关；

　　test_support_ui_project：

　　提供一些UI的基本操作（功能）和性能相关内容，主要是性能，收集几种最终要的性能数据；

　　realibility_test_project：

　　封装test_support_ui中的性能测试内容，对chrome进行稳定性测试，包括稳定性测试，crash收集，报告等；

　　执行相关有：

　　pyautolib_project：

　　chrome相关的pythonUI测试框架，将uitest的C++导成python然后进行执行；

　　webdriver_project/chromedriver_project：

　　为外部网站测试提供支持，比如selenium，webdriver等；

　　还有三个我觉得不错的和自动化有关的部分：

　　breakpad的引入：

　　crash的收集报告框架，在测试框架中引用它，对测试过程中出现的crash进行dump收集，并统一分析；

　　IAccessible的实现：

　　使用代理方式在views库中封装IAccessible的接口，共外部进行界面相关的获取；实现方式和我在MASS实现中提到的一样，继承统一基类，注册，然后分别实现自己的UI支持；

　　memory_watch：

　　chrome中的内存检监测小工具。

　　大概先看了一个雏形，感觉里面的自动化架构设计很漂亮，虽然涉及到的部分很多，也很碎，但是看样子chrome都已经分而治之了。界面的功能和 性能，页面的功能和性能，js的功能和性能，后台数据的获取和安全，页面的渲染，插件的稳定，性能数据的获取和分析，dump的采集和报告，基本上每一个 部分都能深入去了解。有时间了慢慢的再研究一下。

　　来自www.openqa.org的解决方式为：

　 　How do I use Selenium to login to sites that require HTTP basic authentication (where the browser makes a modal dialog asking for credentials)?

　　Use a username and password in the URL, as described in RFC 1738:

　　Test Type

　　open http://myusername:myuserpassword@myexample.com/blah/blah/blah

　 　Note that on Internet Explorer this won’t work, since Microsoft has disabled usernames/passwords in URLs in IE. However, you can add that functionality back in by modifying your registry, as described in the linked KB article. Set an “iexplore.exe” DWORD to 0 in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE.

　 　If you don’t want to modify the registry yourself, you can always just use Selenium Remote Control, which automatically sets that that registry key for you as of version 0.9.2.

　　中文解释如下：

　　可以把用户名和密码加到URL中进行解决，比如http://admin:admin@192.168.1.1这样就不会再需要登录，直接进去操作即可。对于IE，需要修改注册表，把下属内容复制到reg格式的文件双击执行即可。

　　Windows Registry Editor Version 5.00

　　[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE]

　　“iexplore.exe”=dword:00000000

　　下面给出相关的Selenium的源代码：

　　本文转载自：http://loggingselenium.com/?p=335

　　目前业界常见的自动化测试工具在断言方面大多都是采用“指哪儿打哪儿”的细粒度模式，即，在自动化测试过程中只能对设置为断言条件的字段（页面元素）进行断言。而且这些测试工具即使提供录制脚本的功能，但对于断言往往还需要测试人员手工补充插入。

　　除了补充、维护断言条件的工作量大之外，这种断言模式还存在一些明显的不足，下面结合一个实际的例子（如下图）进行分析：

　　● 无法感知未设为断言对象的字段上发生的错误

　　以上图为例，如果在“增加用户”的测试脚本之后只对列表中的“用户姓名是否存在” 进行断言，那么就可能遗漏“入职日期没有提交成功”的错误。而且由于页面的信息量往往很大，我们是不可能对所有字段都设置为断言条件的。

　　● 难以对于UI样式或UI逻辑进行断言

　 　以上图为例，有一个UI样式类的缺陷（左侧菜单树的根节点“console”下面多出来一条虚 线）和一个UI逻辑类的缺陷（右侧用户列表只有一页，但“下一页”和“最后一页”图标依然是可以点击的，即没有灰显）。此类缺陷即使对于经验丰富、心思缜 密的测试人员，在人工测试时也是很可能发现不了的，并且在自动化测试过程中也很难进行断言。

　　即使存在上述问题，测试脚本中是否有充分的断言，依然是评判自动化测试有效性的一个重要指标。但实施过自动化测试的人应该都会有这样的体会：“大部分断言在大部分情况下只是佐证软件是运行正常的”。

　　当然，所有人都应该是非常期待看到这样的结果，毕竟谁也不希望每次回归测试时都是用例大面积不通过。只是辛辛苦苦写这些断言语句的测试人员心里未免有些“小遗憾”。

　　本系列上篇文章中谈到“很多人一提到自动化测试脚本，马上就想到需要提供录制工具”，但如果换个角度思考，很可能就是“柳暗花明又一村”。

　　在这里，我们同样换个角度思考，假设我们的自动化测试主要目标是为了证明软件运行正常，那么我们会怎么做？

　　笔者这边的一个经验就是“按照完整的业务流程来组织测试用例，只对少量、必要的关键点进行断言”。以“租户对虚拟化资源的申请使用”为例，来具体看看测试用例的组织方式：

　　1、新租户注册；

　　2、管理员登录系统，对注册租户进行审批，然后退出系统；

　　3、审批后的租户登录系统；

　　4、租户申请所需要的虚拟化资源（比如，40G硬盘、2核CPU、2G内存），然后退出系统；

　　5、管理员登录系统，对租户申请的资源进行审批，然后退出系统；

　　6、租户登录系统，在已申请资源的基础上创建安装指定操作系统的虚拟机；

　　7、断言虚拟机是否创建成功；

　　8、租户退出系统；

　　9、管理员登录系统，删除租户；

　　10、断言租户之前申请的资源是否被完全释放；

　　11、租户再次登录系统，断言是否无法登录；

　　上述测试用例就是按照完整的业务流程进行组织，并且只对少量关键点（7、10、11）进行断言，如果整个用例可以运行通过，就能证明这个业务是没有问题的。

　　另外还有一个值得考虑的现象，就是相对于自动化测试而言，一个优秀的测试人员在人工测试时是如何判断功能正确与否的呢？他不会死板的只盯着某几 个输入域的值，他一定还会同时关注页面上所有数据的正确性、会更加关注业务流程是否正确、会更敏锐的发现页面样式或UI逻辑类的缺陷。

　　为了兼顾“证明软件正常运行”和“人性化的识别软件缺陷”，一个优秀的测试工具应该考虑提供以下多种断言机制。

　　一、控件级细粒度断言即前面提到的最常见的断言方式。在测试过程中，可以在任何位置增加断言脚本，来判断页面指定控件是否存在、控件显示值是否为预期结果等。通常建议只对关键校验点进行断言。

　　二、页面级粗粒度断言通过对比前（之前测试通过）后（后续持续发布）版本在测试用例路径和输入参数相同的情 况下，整个页面内容（包括截图和数据）是否严格相同来做粗粒度断言。

　　通过页面截图进行断言有两个实现要点：首先要选择一个合适的截图方案（笔者推荐采用Selenium WebDriver提供的TakesScreenshot接口）；其次需要提供图片对比工具，以便测试人员可以一眼看出两个版本页面截图的差异。

　　下面是笔者在测试框架中实现的截图自动化对比功能的实际效果。下图中左侧部分是“实际结果截图”、右侧是“预期结果截图”、中间部分是差异对 比，测试人员一眼便可看出其中的Bug：“表格行选中的翻页缓存（在当前页选中几条记录，翻到下一页再翻回本页，需要保持之前的行选中状态）功能丢失 了”。

　　通过页面数据进行断言的实现方式相对简单一些，首先要提取页面上所有的数据（或文本），接着进行格式化，然后再自动化对比。 “页面级粗粒度断言”的特点及应用场景如下：

　　● 无需编写任何断言语句；

　　● 需要能够提供可用于自动对比的历史正确版本，特别适用于可以持续构建的项目；

　　● 能判断出UI样式和UI逻辑类的错误；

　　● 由于对比绝对精准，导致可能存在误判，因此需要人工对差异图片进行排查； 【注】由于很多Web页面都有渐入渐出、点击时按钮变色等很炫的效果，所以在两次截图的瞬间可能页面的动态样式是不一样的，这就是所谓的“误判”。笔者对 于一个“动态样式”适中的项目采用这种断言方式，统计结果表明误判率在20%左右。

　　● 鉴于回归测试的时候，通常大部分用例应该是可以通过的，所以“页面级粗粒度断言”的投入产出比非常占优势！

　　三、 基于业务逻辑断言在测试设计时把有依赖关系的用例一起执行，如果某个步骤出现问题，即便不设置任何断言语句，在当前步骤或后续步骤的测试用例也会执行失败。下面以“增加、查询、修改、删除”这个最典型的流程来说明（如下图所示）。

　　假定在“增加”环节出现问题，那么我们的测试用例执行情况可能出现如下几种结果：

　　1、如果在“增加记录A”的用例中包含对是否增加成功的断言，那么测试用例从“增加记录A”开始出错；

　　2、如果在“增加记录A”中不包含断言，而是在“查询A”的用例中包含是否有查询结果的断言，那么测试用例会从“查询A”开始出错；

　　3、如果在“查询A”中也不包含断言，那么测试用例会从“修改查询结果”开始出错。

　　所谓“基于业务逻辑断言”，就是指上述第三种情况，其特点及应用场景如下：

　　● 无需编写任何断言语句，但测试设计要考虑业务逻辑顺序；

　　● 与“页面级粗粒度断言”相比，不需要提供可用于对比的历史正确版本，通常适用于项目刚开发或样式做整体调整等情况；

　　● 断言错误的位置不精准，可能延后；

　　● 执行过程每一步都做截图备份（通过Selenium WebDriver可以很方便的实现），可以非常有效的辅助定位准确的出错原因；

　　● 鉴于回归测试的时候，通常大部分用例应该是可以通过的，所以“基于业务逻辑断言”的投入产出比非常占优势！

　　四、自定义扩展断言在人工测试时经常有些操作结果的正确与否在当前页面无法做出判断，需要到其它页面甚至系统外部 （比如，数据库、输出日志）获取信息来做出判断。以最常见的“基于数据库进行断言”为例，测试工具需要支持把断言时用到“预期结果”和“实际结果”配置为 对应的SQL语句。

　　以上介绍了从测试工具的角度可以提供的多种断言机制，在自动化测试过程中应该根据项目实际情况，考虑采用上述多种断言的组合，以弥补控件级细粒度断言的不足。

　　本系列文章至此，已经分享了如何降低测试脚本的编写、维护成本，如何在不失测试有效性的前提下减少断言成本。改善上 述两大问题之后，自动化测试基本上就可以比较顺利的开展了。接下来如何让自动化测试的价值最大化呢？答案就是频繁的执行测试脚本。因此下一步要做的就是持 续集成（或者称为每日构建）。下一篇文章会分享一个由测试团队主导的持续集成案例，敬请关注！

　　原文：http://www.infoq.com/cn/articles/Agile-test-automation-3

相关链接：

我们的测试为什么不够敏捷

敏捷自动化测试（2）——像用户使用软件一样享受自动化测试

　　基于风险测试

　　概念不多说，简单讲分为高中低九个区块，所有研发任务会首先进行风险判别，属于高危三区块的测试人员全程参与，属于中危三区块的测试人员提供测试设计支持不参与执行过程，属于低危三区块的开发人员自行完成。

　　从10年就开始说全民测试概念，直到12年实施土壤才逐渐形成，一专多能复合型人员是未来发展趋势，细节不多说，这里主要谈一个问题，工作量蒸发。

　　蒸发

　 　以往常说能量守恒，总体工作量不会消失只会发生转移，从测试人身上转移到开发人或其他角色身上，很多开发人都会问按上面方式运作是否开发人工作量会增 加？答案是在初期一定会，不过一旦进入良性循环就不会，因为它从根源上减少了以往运作方式中缺陷修复成本和沟通协作成本。大家都知道问题越晚修复风险越高 成本越大，以往进入测试阶段缺陷修复所带来的成本有多高不多说。

　　举例，我们一般说股票买卖有人赚就有人亏，但实际上股票市值会蒸发，没人赚也没人亏但就是不见了。工作量也类似，从根本上减少，当然你也可以说它是扩散到不为人知的角落。注意，随意举例而已，请金融专家勿纠结。

　　那么如何从根源上减少成本？

　　测试驱动开发

　 　是否所有团队都适合做TDD？答案是否定的，不过一开始就把事做对相信没人会反对。研发任务伊始构建测试框架（测试设计框架、测试代码框架），告诉开发 人这样做才对，同时依据以往故障构建缺陷预防框架，告诉开发人这样做就错，一对一错互为补充。注意，开发人不要在任务后期引入单独测试阶段，要把传统的事 后验证转变为事前预防。

　　TDD能有效降低缺陷修复成本，那么沟通协作成本如何降低？以往多个角色共同完成任务变为现在一个角色完成任务你说降低没？但这里有个衍生问题，是否需要引入检查机制？单由一人完成任务是否会有风险？交叉测试？结对编程？

　　快速测试

　　自动化测试和 探索性测试。自动化测试不多说大家都明白什么意思，让机器去检查。探索性测试不等同于快速测试，但我们现在就把它当快速测试用，专业测试人使用ET能快速 把产品过一遍，当然这对测试人员能力有较高要求，同时对传统测试知识沉淀方式上有较大冲击。顺带再次鄙视一下不懂业务的测试工程师，毫无存在价值，别跟我 说你了解什么测试业务，你了解啥？

　　基建

　　测试自动化不是终点，往前一步是傻瓜化， 再进一步是智能化。要让测试活动开展门槛越来越低，测试技术使用越来越简单，只有做到这一步全民测试才有基础，清洁阿姨才有参与测试活动的可能，多年来想 做引导式的测试应用系统，看清楚绝非平台更不是框架，今年应该能腾出手来弄弄。

　　多样化的测试手段持续积累，什么好用我们用什么，技术无国界更无山头。持续集成常态化，绝不无谓追求脚本数量，覆盖率统计要合理，首先考虑分支覆盖率，辅以场景覆盖率。

　　从狭义上讲测试工作的核心价值永远是发现问题，如何发现更多更深入的问题，业务场景验证覆盖率设计的越高代表能力越强，换言之测试范围评估的越准越牛逼。

　　在测试设计尽善尽美的前提下我们再看需要何种测试技术支撑我们的测试思路，千万不要本末倒置，你说你有个多不得了的高精尖技术结果完全用不上高射炮打蚊子一个问题没发现，你不去死你还等什么？

　　如何评估测试工具的ROI，如何评估狭义测试技术为业务产品带来的价值，这是个问题。

　　然后，尽量在taocode上开源哇哈哈哈哈哈。

　　可测性可恢复性

　　永远不要仅站在测试角度看问题，更不要整天绞尽脑汁想着如何单独凸显测试价值，把产品质量做好了就是测试人的价值。

　　产品可测性可恢复性的概念不多说，可测性的目标两个：第一能准确评估，第二能推动提升。可恢复性的目标三个：快速知晓、快速分析、快速解决。

　　如果到今天还有测试人对产品质量特性没概念，那实在不知说什么好了。

　　人员

　　专精化路线。去年初我们十来个人支撑两个业务，现在我们还是十几个人但要支撑六个业务，未来可能还会增加。早前提过业务测试架构师或业务测试专家的概念，希望人人都能成为“专家”。

　　开年以来我们有四位测试人员转岗开发，为今年角色融合打下了坚实基础，未来还会有更多，希望到财年末整个技术团队能真正成为人人都是开发，人人都是测试，人人都是前端。

　　Eric Willeke在思考：任务看板上的那些没有通过测试的用户故事，该怎么处理呢？应该把它回退到“开发”状态，还是保留“测试中”的状态？他提出了一些不同的方案：

　　● 一个方法是把开发和测试状态合并为“完成”状态，这样就不存在状态变化了。团队通过协作，分解出一系列小到能分配给单个开发人员/测试人员的子任务，但直到每个人都同意所有子任务都完成了，这个用户故事才算完成。

　　● 另外一种方法是把故事移到测试状态，需要的话再移回去，如此反复。如果这就是你日常工作中的真实情况，那么你应该以此建立模型。

　　● 还有一种方法是在某项上放置一个“缺陷”标志（或者缺陷卡片），但是在测试过程中当开发人员来帮忙修复缺陷的时候，标志还会一直放在那里，直到所有问题都被修复。如果这种情况更符合你的实际工作，你更应该以这种方式建立模型。

　　Thierry Henrio提出了不同的方案，他从精益制造行业借鉴过来了“红卡箱”（red bins）的概念：

　　我是这么做的：

　　● 每个状态栏都准备一个专用的红卡箱， 放在看板的底部靠上方

　　● 当某个状态栏的任务出现了问题，就把红卡箱移过去

　　● 我们有30分钟解决问题，消灭红卡箱

　　这套机制对于鼓励团队高效处理问题还是很有效的。但当问题出现在上游工序，那么30分钟就不够了，这种方法的效果也大打折扣。

　　专用的红卡箱相比红色标志，有更加强烈的可视化效果。

　　Ron Jeffries举了一个例子，解释了在任务板上，什么时候任务卡片应该流转回上游工序：

　　[...]如果任务又回到了原来的那位本应该搞定它的负责人的手上，那么把任务回退到前一步工序是一个不错的建立工作模型的方法。 不管你用哪种方法，Adam Sroka认为你的看板应该反映现实情况，而不是一些理想状态：

　 　我们要为正在采用的步骤建立模型，而不是去给设想中的步骤建模，这一观点是很微妙的，却也非常重要。对我来说，这是今年夏天我参加了David主讲的研 讨会后，对看板最深刻的理解。可视化你在做的事情，随后，引入清晰的WIP限制，不断改进，等等。 对我而言，看板很适用。我也有XP的背景，我把流动可视化（visualizing flow）看成一种委婉的引入改变的方式。我过去常常在第一天就想做很多改变，现在我意识到，我可以通过帮助大家诚实地面对他们正在做的事情来轻松地做到 这一点。

　　同行评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。

　　2、适用范围（必写）

　　适用于西安联合信息技术股份有限公司项目开发部的所有项目。

　　3、定义

　　PDP(Project Define Process)项目自定义过程。

　　4、过程概要

　　同行评审为了提高软件质量和提高程序员生产率而被普遍应用的评审方法，在业界已取得很好效果。同行评审能够在任何开发阶段执行，它可以比测试更早地发现并消除工作成果中的缺陷。同行评审的主要好处有：

　　● 通过消除工作成果的缺陷而提高产品的质量。

　　● 越早消除缺陷就越能降低开发成本。

　　● 开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。

　　同行评审包含三个活动：制定同行评审计划、执行评审、评审缺陷管理。可在项目制定项目计划时，同时制定同行评审计划。

　　同行评审有以下四种基本类型：

　　● 单人评审

　　● 评审三角

　　● 组评审

　　● 走查

　　评审类型一般视工作成果的重要性和复杂性而定。其中组评审和走查需要参与人员多，为了节约时间，允许人们有选择地对工作成果进行组评审和走查。

　　4.1 制定同行评审计划

　　4.1.1 活动目的

　　确定需要评审的工作成果、评审方式，预定评审时间、地点以及相关人员。

　　4.1.2 启动条件

　　《项目计划》已启动

　　4.1.3 输入

　　需求文档、开发计划、PDP。

　　4.1.4 角色与职责

　　部门副总裁，SQA，项目经理。

　　4.1.5 主要步骤

　　1）确定被评审对象

　　项目经理确定工作产品清单后，同部门副总裁和SQA协商确定，需要进行评审的工作产品。

　　2）确定评审类型

　　部门副总裁通过权衡工作产品的范围和业务影响（有多少时间适合分配给同行评审活动），选择适当的同行评审类型。

　　3）说明评审要点

　　4）说明参加角色

　　5）发布审批

　　项目经理负责在项目计划阶段发布项目内部关于同行评审活动的约定（工作产品的同行评审计划）将发布内容整合到项目计划，在进度和资源方面给项目组内同行评审活动开展提供必要保障。

　　4.1.6 输出

　　同行评审计划（列入《同行评审管理表》中）

　　4.1.7 退出条件

　　同行评审计划（列入《同行评审管理表》中），通过评审批准时

　　4.1.8 方法

　　无

　　4.1.9 工具

　　无

　　4.2.1 活动目的

　　对代码进行快速、灵活地评审，及早地识别和消除工作成果中存在的缺陷。

　　4.2.2 启动条件

　　代码完成时；

　　4.2.3 输入

　　代码

　　4.2.4 角色与职责

　　开发组成员/组长。

　　4.2.5 主要步骤

　　开发组成员完成各自负责代码后，由同组其他成员或者组长来进行代码评审，评审结果可录入《缺陷统计表》或者直接在代码中体现。

　　4.2.6 输出

　　缺陷统计表

　　4.2.7 退出条件

　　评审缺陷移除时

　　4.2.8 方法

　　见同行评审PPT中关于评审要点的描述

　　4.2.9 工具

　　无。

　　4.3 组评审

　　4.3.1 活动目的

　　对工作成果进行正式组评审，尽早地发现工作成果中的缺陷，帮助开发人员及时消除缺陷，促进项目组对被查对象和标准的共同理解。

　　4.3.2 启动条件

　　工程师已完成工作成果，并已对工作成果进行了内部检查，消除了拼写、排版等初级错误。

　　4.3.3 输入

　　待评审的工作成果和与该工作成果评审相关的一些材料，如评审检查表。

　　4.3.4 角色与职责

　　评审组：项目相关干系人，相关部门经理，相关部门副总裁（根据需要选择人员）

　　4.3.5 主要步骤

　　● 部门副总裁首先确定会议的人员名单，确定评审会议的时间、地点、设备，然后起草《同行评审通知》，确定评审议程和流程。

　　● 项目经理发布同行评审通知，同时把工作成果及相关材料、评审议程、检查表等发给参与会议的评审组成员

　　● 评审组审阅工作成果及相关材料，发现缺陷并记录在《缺陷统计表》中。

　　● 配置管理员记录汇总各评审员缺陷表，并更新。

　　[Step2]评审

　　● [Step2.1] 主持人（项目经理）宣讲

　　→ 主持人宣讲本次评审会议的议程、重点、原则、时间限制等。

　　● [Step2.2] 作者（项目组）介绍工作成果

　　→ 作者扼要地介绍工作成果。

　　● [Step2.3] 识别缺陷和答辩

　　→ 评审组根据“缺陷表”提出查找到的缺陷。

　　→ 作者根据缺陷进行答辩，双方要对每个缺陷达成共识（避免误解）。

　　● [Step2.4] 讨论缺陷解决方案

　　→ 作者和评审组共同讨论缺陷的解决方案。

　　→ 对于当场难以解决的问题，由主持人决定“是否有必要继续讨论”或者“另定时间再讨论”。

　　● [Step2.5] 会议结束决议

　　→ 针对所有缺陷给出评审结论和意见，主持人签字后本次会议结束。评审结论有三种：

　　（1）工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。

　　（2）工作成果基本合格，需要作少量的修改，之后通过审核即可。

　　（3）工作成果不合格，需要作比较大的修改，之后必须重新对其评审。

　　[Step3] 修正、跟踪与审核

　　● [Step3.1] 修正与跟踪

　　→ 作者修正工作成果，消除已发现的缺陷。

　　→ 项目经理及SQA跟踪每个缺陷的状态。

　　● [Step3.2] 提交审核

　　→ 作者消除所有已发现的缺陷后，再将修正后的工作成果递交给评审组审核。

　　● [Step3.2] 审核工作成果

　　→ 评审组审核修正后的工作成果。审核结论有两种：

　　（1）修正后的工作成果合格。

　　（2）修正后的工作成果仍然不合格，需重新修改，重复[Step3]。

　　4.3.6 输出

　　缺陷统计表、评审记录表（列入《同行评审管理表》中）

　　4.3.7 退出条件

　　评审缺陷关闭并且工作成果经过审核后合格。

　　4.3.8 方法

　　见同行评审PPT中关于评审要点的描述。

　　4.3.9 工具

　　《评审检查表》

　　4.4.1 活动目的

　　尽早地将缺陷移除；促进项目组对被查对象和标准的共同理解

　　4.4.2 启动条件

　　执行走查的工作成果完成时

　　4.4.3 输入

　　管理类文档产物、代码、 项目Demo以及与工作成果评审相关的一些材料，如评审检查表。

　　4.4.4 角色与职责

　　评审组：项目相关干系人，相关部门经理，相关部门副总裁（根据需要选择人员）

　　4.4.5 主要步骤

　　[Step1]评审

　　● [Step1.1] 主持人（项目经理）宣讲

　　→ 主持人宣讲本次评审会议的议程、重点、原则、时间限制等。

　　● [Step1.2] 作者介绍工作成果

　　→ 作者扼要地介绍工作成果。

　　● [Step1.3] 识别缺陷和答辩

　　→ 评审组根据“缺陷表”提出查找到的缺陷。

　　→ 作者根据缺陷进行答辩，双方要对每个缺陷达成共识（避免误解）。

　　● [Step1.4] 讨论缺陷解决方案

　　→ 作者和评审组共同讨论缺陷的解决方案。

　　→ 对于当场难以解决的问题，由主持人决定“是否有必要继续讨论”或者“另定时间再讨论”。

　　● [Step1.5] 会议结束决议

　　针对所有缺陷给出评审结论和意见，主持人发起评审结论的确定，如评审组无法形成多数统一意见，由评审组最高领导作出最终判断。

　　→ 评审结论有三种：

　　（4）工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。

　　（5）工作成果基本合格，需要作少量的修改，之后通过审核即可。

　　（6）工作成果不合格，需要作比较大的修改，之后必须重新对其评审。

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿 

　　[Step2] 修正、跟踪与审核

　　● [Step2.1] 修正与跟踪

　　→ 作者修正工作成果，消除已发现的缺陷。

　　→ 评审主持人和SQA跟踪每个缺陷的状态。

　　● [Step2.2] 提交审核

　　→ 作者消除所有已发现的缺陷后，再将修正后的工作成果递交给评审组审核。

　　● [Step2.3] 审核工作成果

　　→ 评审主持人（或者指定审查员）审核修正后的工作成果。审核结论有两种：

　　（3）修正后的工作成果合格。

　　（4）修正后的工作成果仍然不合格，需重新修改，重复[Step3]。

　　4.4.6 输出

　　缺陷统计表、评审记录表（列入《同行评审管理表》中）

　　4.4.7 退出条件

　　评审缺陷关闭并且工作成果经过审核合格时。

　　4.4.8 方法

　　见同行评审PPT中关于评审要点的描述

　　4.4.9 工具

　　《评审检查表》

　　5、实施建议

　　希望最早进行此过程的培训，让评审人员明确目的、各评审人的职责，评审关注点。

　　不同设计时，不同角色评审人员关注点。

　　裁剪建议：可根据项目特点裁剪部分项目成果的评审。

　　6、涉及到的相关文件和表单

　　《评审检查表》

　　《缺陷统计表》

　　《同行评审管理表》

　　众所周知，自动化测试可以一定程度上减轻测试人员负担，提高测试效率，并且通过自动化还可以实现可靠性测试和性能测试。对于移动客户端测试而言，如果我们能够让手机自动运行应用程序来帮助我们检测功能的正确性，会不会很酷？有道测试组对一些热门的手机自动化工具进行了调研，并选择了一些工具进行实际的使用。本文将会结合实际工作，对移动客户端（Android&iOS）GUI自动化的工具调研和实现进行介绍。

　　Android

　　工具

　 　Android APIs提供的instrumentation类可以初始化Android应用程序代码，允许你监控应用程序的系统交互，配合KeyEvent、 MotionEvent类，发送用户事件，进而实现GUI 层的自动化。测试程序需要继承ActivityInstrumentationTestCase2来实现自动化。

　　为了方便编写自动化测 试用例，我们需要对ActivityInstrumentationTestCase2进行扩展。业界也已经有一些成熟的自动化工具，诸如 Robotium、Athrun、NativeDriver、MonkeyRunner等。我们需要针对自身产品的需求，从中选取一款合适的工具来实现自 动化。对于移动客户端GUI的自动化而言，需要保证选取的工具有以下几点特性：

　　1、工具开源，易于扩展。

　　2、脚本编写简洁，维护成本低。

　　3、满足客户端的自动化需求。

　　4、便与校验结果的正确性。

　　5、可用于持续集成。

　　表1列出了这四款工具的区别：

表1 Android自动化工具对比

　　MonkeyRunner通过编写Python脚本来实现自动化，结果的验证是通过截屏比对图片来实现，验证方式不够灵活，不建议采用。

　　NativeDriver 是WebDriver 接口的一种实现，使用移动客户端原生UI而不是浏览器UI（Selenium） 的自动化测试工具。类似于selenium RC的方式来运行测试程序，对于熟悉WebDriver的用户，上手会很快。从表1可以看出该工具也可以满足我们的自动化需求，但在调研初期，该工具提供 的接口较少，没法满足测试需求，而今的完善程度也已经很高了。没有使用该工具可以认为是历史原因吧。

　　Robotium被大家所熟知，基于instrumentation实现，提供的接口可以满足大部分自动化需求。但不支持webview，而有道词典的查词结果展示恰好使用的是webview组件，该模块就没有办法通过该工具来实现自动化。

　 　Athrun的实现和Robotium类似，提供的接口也很多，并且支持webview，也可实现持续集成。对于我们的产品而言，满足自动化的需求。由 于工具开源，在今后需求不满足的时候我们也可以在该工具的基础上做一些封装。所以最终选择了Athrun来实现笔记和词典的GUI自动化。

　　实例

　　和写Android应用类似，首先要建立一个Android Test Project ，指定被测试的Android Project。如果没有应用源代码，也可以在测试程序的AndroidManifest.xml文件内，修 改<instrumentation> 标签下targetPackage为我们要测试的应用程序的package。之后导入framework.jar，就可以开始编写自动化脚本了。图1是有 道云笔记Android端登录模块的自动化用例：

图1 Android 自动化用例

　　从代码可以看出，寻找组件的接口很简单，可以通过组件的id、value等属性来寻找。如果组件没有相对独立的属性，也可以通过该组件的父节点 一层层来寻找。Android SDK提供的hierarchyviewer工具将模拟器当前Activity的 UI组件以树状形式展现，可以清晰的看到每个组件的详细属性。

　　验证一条测试用例是否通过的方式也有很多种，可以验证Activity的跳转、组件的展示，当然还有一些可能就需要通过截屏。图1是通过验证执行用例后Activity的跳转来判断测试用例是否通过。

　　以上我们就完成了一条测试用例的自动化。显然基于Athrun的框架，使得我们的自动化用例编写方便了很多，成本也大大降低了。

　　为了完成各种自动化测试用例，我们有必要对Athrun有更详细的了解，以便二次开发所需接口。感兴趣的朋友可以通过http://code.taobao.org/svn/athrun/trunk/android/来下载工具源代码。

　　iOS

　　工具

　　在介绍iOS自动化之前，首先要介绍下Xcode 所提供的 instruments工具。该工具是一款用来动态跟踪和分析OS X和iOS代码的实用工具。这是一个灵活而强大的工具，它让你可以跟踪一个或多个进程，并检查收集的数据。这样，Instruments可以帮你更好的理 解应用程序和操作系统的行为。

　　instruments除了提供自动化工具automation外，还有诸如leaks、allocations等用来检测和分析程序性能的工 具。对于iOS测试和开发而言，追踪和定位缺陷，instruments是非常实用的。图2是instruments的主界面：

图2 instruments 主界面

　　关于instruments所提供的各种工具的使用，感兴趣的朋友可以在iOS Developer Library中了解。

　　接下来就要介绍一下UI Automation，它可以用在真实设备或模拟器来执行自动化测试。

　　使用JavaScript编写测试用例，调用UI Automation的接口模拟用户交互操作。该工具会将自动化运行的日志信息返回到instruments 信息栏。

　　实例

　　在Xcode通过 profile的方式来启动instruments。或者直接双击启动instruments，在instruments主界面中选择设备上被测试的应用 程序。然后在Automation Script栏编写自动化脚本。使用iOS设备需要注意的一点是确保Developer profile设置是Release模式。图3是有道云笔记iPhone版登录模块的自动化用例：

图3 iOS 自动化用例

　　完成自动化脚本后，可以通过点击Instruments 的Record按钮来运行，也可以通过instruments相关命令来运行。前者适合于调试，后者适合于持续集成。

　　从图3可以看出，对应的UI 组件需要逐层指定。定位这些组件有两种方式。对于iOS 5以上的系统可以通过录制生成脚本，但录制的方式可能会记录错误。所以为了定位准确的组件位置，就需要调用logElementTree ，将当前屏幕组件的层次树状结构打印到日志中，通过日志定位组件。

　　从上图也可以看出UI Automation 所提供的验证机制有些繁琐，验证每一个组件是否存在都需要去做判断。这仅仅是冰山一角，UI Automation会对捕获到弹出窗口（alert）点击默认操作按钮，提供的日志文件也不便于分析，所以我们有必要对UI Automation的接口进行二次封装，更方便去编写自动化用例。

　　Athrun也提供了iOS的自动化框架，有三种实现方式。第一种AppFramWork是代码注入型，需要在源码中插入测试代 码，Objective-C编写测试用例，自动化成本较高，不建议使用。第二种instrument Athrun就是对UI Automation的接口进行扩展，提高了原有接口运行的稳定性。第三种instrumentDriver基于instrument JS框架来开发InstrumentDriver服务端，在java上实现客户端，使用java脚本控制iOS自动化执行。该框架还实现了单步运行，调试 等UI Automation没有的功能。图4为instrumentDriver的架构图：

图4 instrumentDriver 架构图

　　从instrumentDriver的介绍可以看出，相比苹果所提供的UI Automation是有不少优点的。目前由于我们需要通过自动化脚本配合instruments 其他性能检测工具来实现对应用程序的性能测试，所以依旧采用instruments 原生工具配合扩展的JS脚本的方式。后续如果可以找到更好的获取性能数据的办法，会逐渐转向instrumentDriver的方式来实现iOS的自动 化。

　　对比

　　从表2可以简单看一下目前我们选择的iOS和Android自动化工具的区别：

表2 iOS和Android自动化工具对比

　　结语

　　自动化的实现一定程度上提升了我们的测试效率，由于互联网产品迭代速度较快，这里建议大家自动化从冒烟测试做起，用 例设计要尽可能简洁，多做封装，以便降低维护成本。同时实现自动化的持续集成，更早介入测试，更早发现问题。在此基础之上，我们还可以通过自动化配合获取 性能数据的脚本来实现对应用程序的性能测试。这些工作可以使得我们的测试覆盖更广，测试力度更深，更好的检测和监控产品质量。

　　原文：http://techblog.youdao.com/?p=571