LOL自动化测试怎么操作的？每天10万次自动化测试曝光
lol魔法少女系列皮肤下载
<span id="num_a_人顶
<span id="num_b_人踩
LOL今天更新到6.5版本，在每次的版本更新前拳头公司都会进行多次的测试，那拳头公司是怎么进行测试的呢?拳头的测试时怎么进行的呢?
　　对于一款在线游戏来说，游戏发布往往只是开始，随后就需要不断地给游戏增加新的内容或者游戏模式。但是每一次的更新都需要大量的游戏测试，玩家数越多的游戏所需要的测试量也越大。作为同时在线突破过750万、MAU超过了6700万的《英雄联盟》来说，Riot公司每次新版本发布需要的测试量是难以想象的。
　　最近，在该公司的官方技术博客中，Build验证系统开发团队负责人Jim &Anodoin& Merrill讲述了Riot Games为《英雄联盟》采取的自动化测试方案，据他透露，这款MOBA游戏每天的自动化测试数超过10万个，以下请看记者编译的内容：
　　大家好，我是Jim &Anodoin& Merrill，为《英雄联盟》做自动测试方面的工作，特别专注于游戏内体验。我目前担任Build验证系统研发(BVS-Dev)团队的队长。很大程度上，我们团队主要是为自动化测试打造工具并帮助团队写出更好的测试程序。
　　过去的几年里，我们一直都在打造测试系统和基础设施，主要是为了提高开发者们的效率并降低游戏中的bug数量。我们现在每天要运行10万个测试案例，对于这个测试量，自动化测试可以帮助我们把内容更快地推送到玩家们面前，而且可以减少bug。我希望分享一些我们所尝试过的一些做法，也希望能够开启游戏领域有关自动化测试方面的讨论。
　　为什么我们要在意自动化测试呢?
　　《英雄联盟》的变化非常之快，平均来说，在每天的源代码管理检查中都可以看到超过100个与代码和内容相关的改变，而要覆盖所有的这些改变就是一个挑战。随着每两周推一次更新的速度，我们快速检查故障就变得极其重要。在发布过程中的bug发现太晚就会导致更新的发布延迟，导致重新部署更新内容，或者必须暂时禁用某些英雄，这些对于玩家们来说都是糟糕的体验。自动化测试可以让品质分析师们更多地专注于创意测试和上游故障的预防，这样他们可以创造更多的价值。
　　自动化测试还可以更快地显示测试结果，对于人类来说，对于提交的每一行新代码或者内容都进行完整的测试是不现实的，即便是能够做到，那也需要大量的测试者参与并且快速地返回足够多的测试结果。
　　我们的测试系统运行基于持续集成(CI)，并且在大约一小时后反馈报告。这就意味着开发者们收到结果的时间是相对合理可控的，这可以减少上下文切(context switching)换次数和时间。实际上，自动化测试中发现的bug解决速度比普通的bug快8倍。更好的是，如果我们需要给测试增加吞吐量的话，只要简单的给测试集群系统增加一些执行程序就可以了。
　　Build验证系统
　　这个带有想象力色彩的Build验证系统(BVS)是我们为游戏客户端和服务器打造的测试框架，它负责获取测试资料，把它们应用到测试机器上，开始并管理测试系统、执行测试并且报告各自的测试结果。测试和线束都是用Python写的，而且我们写了大多数的BVS代码，这样可以帮助测试程序写作者们不用受到收集必须的资源所带来的麻烦。因此，一些测试类当中的参数可以确定运行什么地图、需要加入多少客户端以及什么英雄需要在游戏中(被测试)。
　　测试使用客户端和服务器上的远程程序调用端点来解决指令并监控游戏状态。大多数情况下，测试包含一套相对线性化的指令和查询，现有的测试覆盖了从英雄技能到视觉规则以及杀死一个怪应该获得的奖励等所有方面。我们一些早期测试并没有那么线性化，但这样的做法让非技术开发者们对于这个系统的使用更加困难。由于确定测试环境的所有工作都是独立完成的，所以测试本身不管是在本地工作室还是在测试集群中进行都是一样的。所以这让本地运行测试更加容易，而且给游戏做出改变也更容易。
　　比如我们对深渊(抢驻新服)巨口&克格莫新W技能的伤害处理测试看起来是这样的：
　　代码截图(详细代码请移步至Riot官博)
　　克格莫测试的第一个部分包括了生化弹幕技能的伤害测试，看起来是这样的：
　　当测试完成运行之后，它就会给独立的报错服务提供测试结果，该服务大概可以存储6个月的运行数据。基于特定测试数据的来源不同，该服务还会采取不同的措施。本地运行测试会打开执行器上的网页，它上面详细技术了失败和成功的案例。然而在测试集群中进行的测试会给所有一经发现过的问题创造新的bug标签，根据结果给对象增加标记，如果有失败案例的话，就会给测试执行者发送邮件。测试数据还通过报错服务进行汇总和追踪，可以让我们看到测试失败是什么时候发生的、发生的频率以及距离通过的版本出现有多少时间等等。
　　在wood 5中我们没有使用任何监控，所以看不到这次重大故障的问题所在
　　为了避免古怪或者不可靠的测试，每一个测试都必须通过标准处理过程才能被信任。在一个测试进行了代码审核并且提交之后，它就进入了一系列被称为BVSStaging的测试。这时候，测试必须展示出至少一周的稳定性才能被提出来使用。如果staging阶段的测试失败，那么结果就只会让测试开发者们知道，这样会避免整个团队的困惑。
　　一旦测试展示了可靠性之后，它就会被提到两套程序中的一个。首先是BVSBlocker，它包含的测试能够确定一个build是否值得进一步测试，不能通过Blocker测试的build是不会应用到测试环境中的，因为要么是游戏不能运行，要么就是有很多严重的bug影响游戏性能。另一套是BVSCore，也是我们功能测试的核心，包括对于每个英雄技能的测试。
　　深度探索框架
　　BVS通过三个层面实现：执行器、驱动器以及脚本。执行器接入一个功能测试的通用API，驱动器则加入特定步骤的配置并且执行测试。最后，脚本为测试案例加入特定的逻辑。目前情况下，我们只有一个在使用中的驱动器(也就是LOLGame)，但执行器和驱动器分离的做法，意味着我们未来的项目可以通过加入它们自己的驱动器使用BVS，并且共享编写LOLGame驱动器的工具。
　　流程图
　　它们需要的单个组件注册器和可选参数都是其各自声明(declaration)的一部分，当参数提供到指令栏的时候，它们被存储为组建消耗作为初始化部分的关联数组(dictionary)。初期版本的BVS针对Python使用标准的argparse库，但我们选择不使用argparse库的原因有两个方面：首先，潜在的参数输入量会变的更大，因此很难在系统中进行追踪;第二，驱动器需要拥有驱动器特有的参数，这也就意味着在启动时生命解析器是不可行的。
　　一个驱动器类的示例参数
　　这里有三个层面的相关粒度：测试集、测试和测试案例。
　　测试集是共同运行的一组测试的集合，比如前面提到的BVS Blocker测试集是一系列运行在CI上的冒烟测试(smoke test)，测试集目前是通过JSON文件向BVS描述的，这些文件可以早期创建，也可以在测试过程中生成。
　　测试指的是加入了一系列使用相同游戏参数的类似测试栏里的(单独的)类，比如，LoadChampsAndSkins测试通过运行加载每个英雄和皮肤资源的测试案例来实现，并且要确定加载是合理的。
　　测试案例指的是在一次测试中将要起到一定功能的单位，比如，LoadChampsAndSkin测试中的loadChampionAndSkin函数就是一个单独的测试案例，这个案例会被执行数百次，因为要匹配每个英雄和皮肤之间的关系。克格莫的整套测试案例是通过高级测试被执行的，这些测试可以允许更为复杂的测试案例拥有比函数更多的结构。
　　BVS里的并行化基本上是在测试设定层面就做好了，当然也可以发生在测试期间，因为BVS把测试集当作JSON存储和读取，我们在这个JSON里创造了子列表，既可以通过单个执行器连续执行，也可以在测试群里并行执行。在BVS的初期，我们可以手动平衡，因为对于比较小的测试列表来说，手动比自动化效率更高。随着使用中的主要测试集不断增多，我们开始转向了可以产生同样JSON文件的自动化加载平衡器，但我们现在用的是在过去10次运行中的每个测试组件所用的平均时间。
　　大多数的BVS用户只对于测试本身感兴趣，因为我们也开始用自己的方式寻找出路，确保他们不用考虑驱动器处理的所有细节。同样的是，我们使用了相对比较大的标准库，它包含了PRC端点。我们这么做的最主要原因只是为了确保测试没办法留后路，但最重要的原因是，我们把它当作一系列的行为标准，既能预防马虎的测试程序编写，还能确保不同测时间的连贯性。
　　特别是我们在BVS的标准测试库里不用任何形式的sleep函数，只有测试程序写作者才会更多地用到sleep函数，这就导致了由于硬件不同而产生的测试差异化，在标准数据库模式下的所有wait函数都是条件wait函数，这会让游戏有一个稳定的挤走，只有条件被满足的时候才执行。
　　wait条件函数案例
　　自初期开始，我们为BVS采用了一个主要方法就是，把和所有市相关的逻辑都分离开来。过去BVS还承担了确认应该使用哪些资源的作用，为了保持职责分工的清晰，我们专门有个独立的服务，它负责所有和运行测试没有直接关联的工作，这个服是使用了Django REST框架的Django应用，它可以提供一个BVS和当前BVS其他服务可以用的API。
　　运行和运行后流程
　　整体性能
　　整体来说，《英雄联盟》每次推出新版本之后，BVS在18分钟里运行大约5500个测试案例，总的来说就是每天运行10万次测试。从故障提交到BVS得出首个测试报告的时间大约在一两个小时之间。50%的重大或者拦路虎级别的bug都是被BVS发现的，其余则是在内部QA或者在PBE上发现的。没有被BVS发现的问题通常都是直接跳过的，因为测试覆盖面不够广，而不是测试做的不好。
　　虽然我们发现的大多数bug都是游戏崩溃或者功能缺失方面的，但通常我们也会最先发现一些真正难以发现的bug。我个人比较喜欢的一个bug是，游戏中所有的塔都向地图的右上角倾斜，导致产生了史诗级的塔防效果图。我们发现的还有非自动化测试不一定能够发现的问题，比如如果一个英雄在射程范围的边缘对敌人施放技能可能会导致miss。
　　总体来说，自动化测试并不一定要取代人工测试，但它毫无疑问地加快了反馈周期，让我们的人工测试者们有更多的自由用在具有建设性的测试上。随着越来越多的内容被加入到《英雄联盟》中，我们还会覆盖更多的测试范围，这毫无疑问会提高我们的销量并改善游戏版本的表现。
　　Riot收购Radiant娱乐 英雄联盟不再是独子
热门安卓游戏排行
类别：休闲游戏
类别：休闲游戏
类别：角色扮演
48284人推荐57644人推荐65960人推荐75945人推荐85424人推荐94965人推荐104930人推荐
最新安卓游戏排行
类别：棋牌游戏
类别：角色扮演
类别：棋牌游戏
41人推荐50人推荐61人推荐70人推荐80人推荐98人推荐101人推荐更多公众号：iTestTrain啄木鸟软件测试培训网目前提供的课程包括有： 《软件开发质量管理培训》， 《大数据理论与实践》， 《如何帮助传统企业利用大数据进入互联网+时代》， 《软件测试基础知识培训教程》， 《云计算测试培训》最新文章相关作者文章搜狗：感谢您阅读自动化测试系列——基本策略1.0 本文版权归原作者所有，本文由网友投递产生，如有侵权请联系 ，会第一时间为您处理删除。扫一扫下载手机客户端
扫描我，关注团购信息，享更多优惠
||网络安全
| | | | | | | | | | | | | | | |
||电子电工
汽车交通| | | | | | | | | |
||投资理财
| | | | | | | | | | | | | | | | |
| | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
||外语考试
| | | | | | | | |
| 视频教程|
自动化测试最佳实践:来自全球的经典自动化测试案例解析
定价：￥89.00
校园优惠价：￥178.00 (200折)
促销活动：
此商品暂时缺货（可留下联系方式，到货将第一时间通知您）
电话号码：
*邮箱地址：
原书名：Experiences of Test Automation: Case Studies of Software Test Automation
原出版社：
ISBN：0上架时间：出版日期：2013 年4月开本：16开页码：434版次：1-1
所属分类：
“你手中的这本书是关于自动化测试的不可多得的至宝，它讲述了在自动化测试的实践中什么是好实践，什么不是。本书使你避免陷入自动化测试的泥潭，从而更可能取得成功。”
――Linda Hayes
&&& “在本书中，Dorothy Graham 和Mark
Fewster通过一系列引人注目的案例研究展示了自动化测试中的各种学习经历，每个案例研究都讲述了自动化使用的工具和方法。本书内容如此全面，是同类书中第一本带读者深入到自动化测试世界中的书籍。本书包含了许多案例研究，案例研究讲述了在自动化过程中都发生了什么，案例包含的项目来自各行各业，测试环境包括了各种技术环境。通过找出各个案例之间的类似点以及对某些主题的重复，能够帮助读者更加理解应该避免哪些错误。通过本书，读者可以了解到需要做些什么才能取得测试自动化的成功。
――Andrew L. Pollner， ALP International Corporation的总裁和CEO
&&& “在畅销书 《Software Test Automation: Effective Use
of Test Execution Tools》出版之后很多年，Mark Fewster和Dorothy
Graham又写出了一本畅销书。敏捷方法已经赋予自动化测试在当今测试实践中的主导地位。本书从各种不同视角讲述了自动化测试的案例研究，这些案例写得都很好，这使得本书非常有实用价值。我强烈地将本书推荐给那些从事或者想要从事自动化测试的人。”
――Erik van Veenendaal，Improve Quality Services的创始人，TMMi
Foundation 的副主席
“阅读本书就像参加一个测试学术会议一样，书中包含了多个案例研究和对自动化测试深刻的见解。但是本书要比参加学术会议便宜得多，而且还不需要到处奔波去参加会议。令我印象尤其深刻的是，本书在第0章中浓缩了我能想到的使得自动化成功的各个方面。这是在学术会议中得不到的。
――Hans Buwalda
“本书包含了大量令人兴奋的、写得很好的、涉及范围极广的案例研究，案例讲述了在现实世界中自动化测试的经验、技巧、教训和其他值得记住的要点。对于任何需要向经理和同事证明在自动化实践中什么是好的、什么是不好的人员来说，本书都是非常有用的。”
――Isabel Evans，FBCS CITP，质量经理，Dolphin Computer Access
“本书首先讲述了使得自动化测试有效的基本手段。之后讲述了各种情境下的自动化测试中值得注意的事项。本书会指导你：因合理的缘由而应用自动化测试，如何采取适合于公司和项目的自动化方法，以及如何避免各种错误。对于任何参与测试的人――无论是管理人员、测试人员，还是自动化测试人员，本书都非常有价值。”
――Martin Gijsen，自由的测试自动化架构师
“Fewster和Graham为我们提供了连接自动化测试理论与现实之间的一座重要桥梁。自动化测试的框架设计和实施是一种非精确的科学，亟须一套可复用的标准，而这套标准只能从不断涌现的先例中总结出来，而本书则能帮助建立这样的先例。就如同在司法系统中使用先前判决案例作为支持当下做出法律判决的依据一样。在自动化框架设计与实施上，从本书所能习得的各式案例，适用于帮助人们做出当下的决定，支持这样的活动或教育相关人员。1
――Dion Johnson，Automated Testing Institute（ATI）软件测试顾问及首席咨询师
“即使我一贯秉持‘自动化测试无用’的立场，本书也的确让我驻足思考。它让我开阔了思维，同时也让我做出‘噢，原来这种情况我没考虑到’的反省。对于那些想要参与自动化测试的公司，我推荐将本书作为入门参考书。”
――Audrey Leng
“本书是一个惊人的成就。我相信它是自动化测试方面写得最好的书之一。Dot和Mark通过对28个案例研究的叙述给予我们一个完全崭新的概念，包括引人注目的小窍门、真知灼见以及经验教训。这些案例研究来自于生活经验中，既有成功的，也有失败的，包括了自动化的多个方面、不同的环境以及多种混合的解决方案。书本来就是智慧之源，而作者采用了非常好的方式――利用叙述故事的形式给我们留下很深的印象，从而增强学习效果。无论读者处于何种层次，本书是所有想要进入或者已经进入自动化测试领域的人所必备的。它的确是同类型书中独一无二的。”
――Mieke Gevers
《自动化测试最佳实践:来自全球的经典自动化测试案例解析》中文简体字版由Pearson Education（培生教育出版集团）授权机械工业出版社在中华人民共和国境内（不包括中国台湾地区和中国香港、澳门特别行政区）独家出版发行。未经出版者书面许可，不得以任何方式抄袭、复制或节录本书中的任何部分。
《自动化测试最佳实践:来自全球的经典自动化测试案例解析》封底贴有Pearson Education（培生教育出版集团）激光防伪标签，无标签者不得销售。
《自动化测试最佳实践:来自全球的经典自动化测试案例解析》是世界名著《Software Test Automation》的姊妹篇，是自动化测试领域的至宝，是每一位测试人员都应该反复研读的一本书。
它是Dorothy Gramham、Mark Fewster、Lisa Crispin、Alan Page等30多位来自世界各地的自动化测试专家和大师的经验结晶，通过对30多个来自世界各行各业的经典测试案例的分析和研究，讲述了最新的自动化测试工具、技术、方法，以及自动化测试的实施、引导和管理，不仅包含大量最佳实践，还包含很多失败的教训。让读者不仅能吸取前人留下的宝贵经验和远见卓识，少走弯路，还能更好地领会自动化测试的自然规律。
　　Dorothy
Graham　软件测试领域的大师级人物，有着40余年的软件测试经验，曾获得软件测试领域欧洲卓越成就奖。世界知名的顾问，Grove
Constaltants公司的创始人，在软件测试的学术研究方面有极深的造诣，写作经验也极为丰富，著有软件测试领域的世界名著《Software
Test Automation》，影响深远。
Fewster　软件测试领域的大师级人物，在软件测试和自动化领域有30余年的工作经验。现担任英国计算机协会软件测试专家兴趣小组（BCS
SIGiST）和信息系统考试委员会（ISEB）的委员。最近20年致力于为软件测试的各个方面提供培训和咨询服务。经常在国内和国际会议与研讨会上发表演讲，并且与Graham合著了软件测试领域的世界名著《Software
Test Automation》。
　　朱少民，国内软件测试界的领军人物和资深专家，二十多年来一直从事软件测试、质量管理和过程改进等工作，先后出版十多部著作，包括测试方面的畅销书《完美测试》、《全程软件测试》、《轻轻松松自动化测试》、《软件测试方法和技术》等，经常在国内外会议上发表演讲。之前曾任思科-网迅（中国）软件有限公司QA高级总监，目前是同济大学软件学院教授、中国科技大学软件学院教指委委员。
《自动化测试最佳实践:来自全球的经典自动化测试案例解析》
第0章　案例研究反思
0.1　管理层问题
0.2　技术因素
第1章　敏捷团队的自动化测试之旅：第一年
1.1　本案例研究的背景
1.2　整个团队的承诺
1.3　建立自动化策略
1.4　利用验收测试驱动开发，使用FitNesse测试GUI
1.5　使用增量方法
1.6　正确度量
1.7　庆祝成功
1.8　引入工程冲刺
1.9　团队成功
1.10　持续改进
　　时光荏苒，转眼间本书的翻译工作已经进行了半年多，算是没有辜负出版社的期望，按时完成翻译任务。当初，看到本书的英文版，就有翻译本书的强烈愿望。本书作者Dorothy Gramham和Mark Fewster之前写的《Software Test Automation》就很有影响，作为其姊妹篇，本书一定会更胜一筹。更让我感兴趣的是本书的组织结构和众多引人入胜的故事。
　　本书的作者实际不只是Dorothy Gramham和Mark Fewster他们两位，而是30多位来自世界各地的自动化测试的成功探索者，包括Lisa Crispin、微软的Alan Page等测试大师。本书可以看做是这些自动化人员的自传，每一章自成体系，一章一个案例，进行深入的剖析，30多个案例形成了自动化测试的一顿大餐。这些从事自动化测试多年的测试人遍布全球，分布在美国、英国、德国、印度、荷兰、挪威、丹麦、比利时、加拿大、澳大利亚等地，同我们分享他们在自动化测试过程中所经历的酸甜苦辣，其中有过迷茫，有过失败，也有喜悦和激动。自动化测试的故事，有浪漫之旅，也有历经坎坷、披荆斩棘才走完的艰辛之路；更有凤凰涅、绝地逢生，迎来自动化测试春天的感人故事。这些自动化测试之旅，短的有一年，而长的会跨越六年、持续十多年，甚至像《星球大战》那样，有前传，还有后传。每个故事都是他们亲身经历的，让我们感同身受。
　　本书就像是一本写实的小说，里面有很多个性鲜明的人物。如喜欢将还没有通过各项测试的正在开发中的版本向客户展示的经理，也有偶然间因为某些突然冒出来的想法从开发转向测试的技术人员；既有人认为自己作为测试人员不应该写代码，也有经理认为能写代码的都是程序员，都应该去开发部门等；既有自己做了很伟大的事情却因为公司制度以及测试衡量标准的原因导致没有能够升迁的技术人员，也有为各种软件公司提供咨询的专家。当我们阅读本书的时候，仿佛自己也参与到了这些项目的自动化测试之中。当看到项目所取得的惊人成就时，一种自豪感会油然而生；当看到应用自动化导致项目越来越糟时，自己也会感到迷茫，不知何去何从；在突破层层困难，拨开云雾见天日之时，自己心中便会有“柳暗花明又一村”的顿悟；当自己辛辛苦苦搭建起来的框架和之前无数个日日夜夜的努力，却因为管理层的原因导致项目中断时，不禁会感到彷徨与无奈。
　　本书展示了丰富的自动化测试对象，除了经典的政府信息系统、企业ERP系统、通用的数据库系统之外，还包括从主机到Android移动应用，从汽车电子系统、医疗设备到设备仿真、硬件接口等的自动化测试。而且，本书自动化测试所处的环境也是千差万别，所涉及的项目之广也是同类书籍所不及的：
　　有涉及传统的V模型，也有涉及敏捷的开发模型；
　　有基于关键系统（如北大西洋东部领空的空中交通控制系统）的自动化测试，也有一般商业系统（如保险公司）的自动化测试；
　　有基于模型的自动化测试，让我们领略数学严谨的同时，见证低成本高收益的自动化测试；
　　有针对自由的猴子测试、探索式测试来实现其自动化方式，让手动测试和自动化测试相辅相成；
　　有针对云端实施自动化测试、在线的持续回归测试，将基于产品的自动化测试变更为基于服务的自动化测试。
　　在翻译本书的同时，译者深深地感受到了自动化的魅力和力量。测试自动化在节省了大量人力的同时，也在推动整个软件行业的前进。正如本书所述，正确地采用自动化能够极大地提升软件的质量和测试的效率。然而在错误的地方应用自动化只会带来更大的开销。本书呈现了一些失败的案例，目的是告诉读者，单单技术方面的因素并不能决定自动化测试的结果，管理方面的因素也要考虑到其中。如自动化框架很好、人员积极性很高，并且已取得了不少积极的效果，但是却因为其他一些无法抗拒的因素最终走向了失败。在很多故事中，我们可以看到作者反复强调：“一些经理本身不懂测试自动化，他处在经理这个位置更多是像被强插在这个位置的。”这在现实中并不少见，公司应该对经理进行培训，使其可以促进自动化测试的良好发展，而不是作为阻碍因素。本书可以为这些经理提供各种真知灼见，指导他们如何促进自动化的发展，也可以指导技术人员如何斗智斗勇，从经理那里获得应有的资源，同时尽量从自动化测试启动时就让经理们也参与其中，并通过不断地向他们展示自动化进度和成果来获取其支持。
　　正如一句广告词“简约而不简单”，这句话用来描述本书恰到好处。每个章节都用一种平易近人的语气来讲述，故事好像一个接着一个地发生。但是作者想要表达的事情并不简单，作者不断地去找寻各种方式，向读者呈现一个个故事背后的必然性和偶然性，并且强调什么样的实践是好的，什么是坏的。作者的一些观点在本书中多次出现，如“自动化测试并不便宜”、“不要忽略管理因素”、“自动化测试是对手动测试的补充而非替代”。作者反复强调这些，就是要警示读者，在自动化领域有很多经验教训，我们应该对此有着清晰的认识。这些观点一遍一遍被反复强调，警示着我们不要重蹈覆辙。在阅读本书时，除了了解和掌握自动化测试的各种应用方法、技术和工具之外，还会对自动化实施及其引导、管理等方面的各项影响因素有所明察，从而杜绝虚幻、脱离实际的想法。看完本书，我们能更好地领会自动化测试的自然规律，吸取很多前人留下的宝贵经验，增长见识，使我们自己少走弯路，采用更有效的自动化测试方式和方法，以完成我们的测试使命。
　　最后，感谢机械工业出版社华章公司引进了这么优秀的英文原著，并给予了我们大力支持，使得本书的中译本能够和读者见面。我们还要感谢天津策艺公司柴阿峰、迈瑞血球研发中心肖利琼、宁波大学刘慰等三位友人以及同济大学郭智超、俞诗嘉等两位同学。他们从百忙中抽出宝贵时间，帮忙校对，进一步提高了翻译质量。
　　希望本书能成为一种有效的助推力量，让更多的测试人员参与到自动化测试的实践中来，促进国内自动化测试百花齐放、百家争鸣。使自动化测试不再是奢侈品而成为软件测试的必需品，惠及千千万万的软件项目，最终促进国内软件行业的发展。
　　于美丽的同济大学嘉定校区
　　用于软件测试自动化的工具已经发展了近30年，但还是有很多自动化测试的尝试会失败，或者至少并非那么成功，这是为什么呢？
　　在笔者的前一本书《Software Test Automation》中，提出了一些有效的自动化测试原则，为了验证这些原则今天是否依然有效，以及是否还有其他的原则可以应用于自动化测试中，所以我们开始收集现实世界中自动化测试实施案例。结果很高兴地发现：在过去10年中，许多人在软件测试自动化领域取得了很大的成功，其中不少人参考了我们的书。当然，我们并不是唯一描述或发现了这些好的自动化实践的人，然而找寻一些成功的而且能在一段时间内都适用的实践在今天看来还是难以实现。我们希望本书中的故事会帮助更多的人在自动化测试的尝试中取得成功。
　　本书收集了当前的很多关于自动化测试的真实故事。自从我们上一本关于自动化测试的书在1999年出版以来，自动化测试技术有了很大的飞跃。我们想要找出什么样的方法是成功的、哪种应用程序正在通过自动化测试来完成测试的，以及近几年来测试自动化是如何改变的。不同的人会用不同的方式去解决自动化相关的问题――我们想要知道我们从他们的经历中能学到什么，以及在什么样的情形下如何用新的方式应用自动化测试。
　　本书中的案例研究包括一些成功的方法，同时也包括一些不成功的方法。本书旨在教会读者如何避免错误，以及如何从实际成功的例子里汲取经验教训。本书旨在帮助读者从其他一些专家真实的经历中学到大部分自动化测试的经验。
　　本书中的案例研究主要是关于测试执行过程中的自动化，其他一些自动化的类型在一些章节中也会提及。我们着重研究系统级的自动化（包括一些用户验收测试），尽管其他的一些章节也会包括单元测试或集成测试。我们将在不同的应用程序、环境和平台下描述测试自动化，每章用到的工具包括商业的、开源的以及公司内部的程序，这些工具可以用在传统开发或者敏捷开发项目中。我们很惊奇地发现有近90种商业或者开源软件正在使用，这些软件的名称列在附录A中（附录包含了每章作者用到的各种工具，不仅仅是测试用的工具）。
　　本书描述的实例都是真实的，虽然在一些案例中没有透露作者或者公司名称。我们鼓励这些案例研究的作者去描述到底发生了什么，而不是仅仅给我们一些通常的建议，所以本书的描述是相当真实的。
　　在收集这些实例的过程中，我们也遇到了很多困难，比如，我们很难涉及各种行业中的应用。那些在公司里坚持不懈地致力于发展自动化测试的人给我们留下了深刻的印象。然而，我们也遇到了他们中的许多人遇到的一些困难，这些困难有时候会导致测试失败。相信本书中讲述的经历会帮助你在自动化测试道路上更加成功。
　　案例研究的附加内容（我们得到的经验）
　　本书并不是一系列文章的简单组合，我们和每一章的作者一起工作，以便将一些最有价值的信息传达给读者。我们对于每一章的审校都是非常全面的，我们通常进行很多轮审校，提出问题及改动建议（特别感谢每章作者的耐心和他们传达的额外信息）。我们最开始收集的文档超过了500篇，所以这里每一章的内容都是精挑细选的。
　　我们会提供一些真知灼见、经验教训和小窍门，帮助读者从本书中尽可能汲取大部分知识。每一章都有我们的一些评论，这些评论包含了一些我们认为非常有用的要点。仔细注意以下这些有用的标记：
　　真知灼见（good point）：值得注意的观点（即使它们并不是那么新）。
　　真知灼见
　　管理层的支持至关重要，但是期望必须是符合实际的。
　　经验教训（lesson）：从失败中学到的教训――我们最好不要做的事情。
　　经验教训
　　和软件开发一样，自动化开发也需要进行规范化。
　　小窍门（tip）：一些看起来新的、有趣的诀窍，可用来帮助我们解决特定的问题。
　　小窍门
　　使用一个“转换表”记录一些可能发生改变的事情，这样自动化可以使用一些不变的标准术语。
　　在你读每一章的时候，我们会用一些感叹词来提醒读者重要的地方，比如，“注意这里”，“看这里”或者“这会非常有用”。
　　自动化测试――集“圣杯”、“青春之泉”、“点金石”为一身。在过去的几十年中，测试者为了能从手动测试――构建测试实例与测试数据，设置系统先决条件，运行测试，比较实际数据与预期数据并报告可能的缺陷――的苦海中脱离而不断追寻自动化测试。自动化测试能够简化所有这些操作，甚至还能简化更多的测试操作。
　　然而遗憾的是，成功有效并且经济实用的自动化测试往往很难实现。自动化测试项目大多在启动后便步履蹒跚、时常跌倒，最终迷失路途，被遗弃在不断增长的废弃项目堆上。
　　自动化的失败可以归咎于很多原因，其中无法实现预期效果或许是最常见的原因，还有就是不充足的资源分配（例如时间、人员和资金）。其他因素包括：难以满足需求的开发工具，阻碍工作质量的欲速则不达的急躁情绪，缺乏对自动化测试的理解――自动化测试也是一种软件开发，需要用与软件开发一致的专业方法来进行。
　　Dorothy和Mark在1999年出版的著作《Software Test Automation》，为同类书籍设定了标准。该书的第一部分详细列举了在大多数成功的自动化实例中发掘出的方法――脚本技术、自动比较、测试件架构和有用的衡量标准。第二部分讲述了一些机构在实现自动化测试过程中所吸取的经验教训。现在，又经过了10年在行业内的摸爬滚打，Dorothy和Mark提供了另外一些机构和个人的实践经历，用以指导自动化作业。本书同时描述了经典的和最新潮的自动化测试方法。每一章通过叙述某一独特自动化实例的一个故事（既有成功的也有失败的），给我们提供指导。
　　某些主题在本书中再次出现：合理、可以达成的目标；管理层支持；衡量标准，包括ROI（Return On Investment）；需要的技术；规划；设定期望；建立关系；工具；培训；以及政策――所有的一切都是成功的测试自动化所必需的。然后，这些主题同样也可运用在项目及个人层面。本书一个非常大的好处在于拓展了测试自动化领域，从更全面的角度来考虑这些主题。
　　我第一次见到Dorothy和Mark是在1998年的“慕尼黑Euro STAR软件测试会议”上。他们对自动化测试的认知以及帮助其他人完成自动化测试的热情，给我留下了非常深刻的印象。我真心祝贺他们取得如此出众的成就，并向大家推荐本书。
　　――Lee Copeland
　　“你手中的这本书是关于自动化测试的不可多得的至宝，它讲述了在自动化测试的实践中什么是好实践，什么不是。本书使你避免陷入自动化测试的泥潭，从而更可能取得成功。”
　　――Linda Hayes
　　“在本书中，Dorothy Graham 和Mark Fewster通过一系列引人注目的案例研究展示了自动化测试中的各种学习经历，每个案例研究都讲述了自动化使用的工具和方法。本书内容如此全面，是同类书中第一本带读者深入到自动化测试世界中的书籍。本书包含了许多案例研究，案例研究讲述了在自动化过程中都发生了什么，案例包含的项目来自各行各业，测试环境包括了各种技术环境。通过找出各个案例之间的类似点以及对某些主题的重复，能够帮助读者更加理解应该避免哪些错误。通过本书，读者可以了解到需要做些什么才能取得测试自动化的成功。
　　――Andrew L. Pollner， ALP International Corporation的总裁和CEO
　　“在畅销书 《Software Test Automation: Effective Use of Test Execution Tools》出版之后很多年，Mark Fewster和Dorothy Graham又写出了一本畅销书。敏捷方法已经赋予自动化测试在当今测试实践中的主导地位。本书从各种不同视角讲述了自动化测试的案例研究，这些案例写得都很好，这使得本书非常有实用价值。我强烈地将本书推荐给那些从事或者想要从事自动化测试的人。”
　　――Erik van Veenendaal，Improve Quality Services的创始人，TMMi Foundation 的副主席
　　“阅读本书就像参加一个测试学术会议一样，书中包含了多个案例研究和对自动化测试深刻的见解。但是本书要比参加学术会议便宜得多，而且还不需要到处奔波去参加会议。令我印象尤其深刻的是，本书在第0章中浓缩了我能想到的使得自动化成功的各个方面。这是在学术会议中得不到的。
　　――Hans Buwalda
　　“本书包含了大量令人兴奋的、写得很好的、涉及范围极广的案例研究，案例讲述了在现实世界中自动化测试的经验、技巧、教训和其他值得记住的要点。对于任何需要向经理和同事证明在自动化实践中什么是好的、什么是不好的人员来说，本书都是非常有用的。”
　　――Isabel Evans，FBCS CITP，质量经理，Dolphin Computer Access
　　“本书首先讲述了使得自动化测试有效的基本手段。之后讲述了各种情境下的自动化测试中值得注意的事项。本书会指导你：因合理的缘由而应用自动化测试，如何采取适合于公司和项目的自动化方法，以及如何避免各种错误。对于任何参与测试的人――无论是管理人员、测试人员，还是自动化测试人员，本书都非常有价值。”
　　――Martin Gijsen，自由的测试自动化架构师
　　“Fewster和Graham为我们提供了连接自动化测试理论与现实之间的一座重要桥梁。自动化测试的框架设计和实施是一种非精确的科学，亟须一套可复用的标准，而这套标准只能从不断涌现的先例中总结出来，而本书则能帮助建立这样的先例。就如同在司法系统中使用先前判决案例作为支持当下做出法律判决的依据一样。在自动化框架设计与实施上，从本书所能习得的各式案例，适用于帮助人们做出当下的决定，支持这样的活动或教育相关人员。1
　　――Dion Johnson，Automated Testing Institute（ATI）软件测试顾问及首席咨询师
　　“即使我一贯秉持‘自动化测试无用’的立场，本书也的确让我驻足思考。它让我开阔了思维，同时也让我做出‘噢，原来这种情况我没考虑到’的反省。对于那些想要参与自动化测试的公司，我推荐将本书作为入门参考书。”
　　――Audrey Leng
　　“本书是一个惊人的成就。我相信它是自动化测试方面写得最好的书之一。Dot和Mark通过对28个案例研究的叙述给予我们一个完全崭新的概念，包括引人注目的小窍门、真知灼见以及经验教训。这些案例研究来自于生活经验中，既有成功的，也有失败的，包括了自动化的多个方面、不同的环境以及多种混合的解决方案。书本来就是智慧之源，而作者采用了非常好的方式――利用叙述故事的形式给我们留下很深的印象，从而增强学习效果。无论读者处于何种层次，本书是所有想要进入或者已经进入自动化测试领域的人所必备的。它的确是同类型书中独一无二的。”
　　――Mieke Gevers
　　第0章案例研究反思
　　成功的自动化测试需要智慧和毅力。你的经验可能和本书所描述的有一些相似之处，但每个人的故事都是独一无二的。通向成功的道路并不简单，但是正如书中案例研究所描述的那样，自动化测试已经在各种应用领域、各种环境和项目的各个生命周期中取得了成功。
　　通过思考，我们根据书中出现的案例和奇闻轶事总结出了一些方法。本章高度总结了现有经验中需要吸取的最重要的教训。你可能会在阅读完后面各个案例研究章节后再次阅读本章。
　　哪些主要因素促成了自动化测试的成功？导致自动化测试失败最常见的因素有哪些？
　　对这些问题没有简单而通用的答案，但存在一些公共的要素。我们认为最重要的两个要素是管理问题和测试件架构：
　　对自动化的管理层支持，包括设置切实可行的目标，以及提供足够合适的资源来取得已计划的ROI。
　　一个好的自动化测试件架构，拥有正确的抽象层，在降低自动化测试件维护和自动化测试各个方面成本的同时提供灵活性和适应性。
　　除了共同的要素外，还有其他一些方面，甚至是一些令人吃惊的要素，将它们也考虑进去可以帮助你在自己的自动化测试中取得更大的成功。这是我们写这本书的希望和目的！
　　在以下的大多数小节中，我们会着重强调一些章节号，并讨论一些特定的主题。这些主题可能也在其他章节涉及，我们会在这里列出各章针对某一特定主题进行的专门讨论。
　　我们首先在0.1节讨论管理层问题，但经理们也需要注意0.2节描述的技术问题。
　　0.1管理层问题
　　从许多案例研究中可以清晰地了解到，管理层的支持力度关系到自动化测试的成功与失败。举例而言，第4、6、11、17和20章都叙述了管理层支持欠缺导致自动化测试失败的情形。
　　0.1.1自动化测试目标
　　制订一个合适的目标对自动化测试的成功实施至关重要！这似乎是显而易见的，但令人惊讶的是，在没有任何清晰目标或仅仅是只有一些模糊的陈词滥调作为目标（如“更快的测试”、“做得更好”、“节省时间”）的情况下，一个自动化测试就开始了，这类事情经常发生。目标越具体，自动化测试越有可能得到好的评价并取得成功。
　　将软件测试所要达到的目标与自动化所要达到的目标区分开来是很重要的。自动化是运行测试的一种方法，无论这些测试是好还是坏。一个好的测试目标是发现许多bug。这没有必要成为一个好的自动化测试目标：在近期对项目进行一些改动之后，需要进行回归测试以确保变更的部分不会影响系统的行为，而这类测试很少发现新的错误。这并不意味着自动化测试不成功，只是因为它有了错误的目标。如果一个高层经理感到自动化测试没有达到预期目标（即使这个目标是一种误导），那么资金也可能被撤掉。
　　0.2.9节讨论了一些能够有效地找到bug的自动化测试示例。一些好的自动化测试目标在第1、2、3、6、7、10、11、12、14、20、21、25、27和29章中讨论。
　　0.1.2管理层支持
　　在一个无法对自动化测试进行精心培育并有效引导的组织中，自动化测试很难成功发展起来。对于个人来说最好先亲自试验一下，如果想要大规模地进行自动化测试，并能收获自动化测试对于产品最终发布所带来的巨大好处，则需要管理层的大力支持。一种“自下而上”的方法并不是通向良好自动化测试的一条长期可持续的道路。
　　管理层支持对自动化测试的成功至关重要；我们可以在本书的很多案例研究中看到这一点。管理层支持包括多种形式：对工具的资金支持，对于一个试点项目和测试件架构的开发过程的资金支持，以及为此需要付出的时间，管理层还要有兴趣去理解自动化行为以监督成本与回报（参见A.3节的ROI）。
　　对于经理来说很重要的一点是，对于自动化过程他能够提供什么，以及对要达到期望的结果需要付出时间与努力有着很明确的了解。
系列图书推荐 ￥59.00￥41.30
同类热销商品￥35.00￥24.50
订单处理配送
北京奥维博世图书发行有限公司 china-pub,All Rights Reserved