第一章：我的第一场发布会

做自动化测试开发，有时被认为是 “心在曹营心在汉”。而在我毕业后工作的前两年，我是这样想的。

一方面，我自认为有一定的编码能力，对那些重复执行的、枯燥的测试用例多少有些不屑；另一方面，我又觉得自己的编程水平不足以胜任纯开发岗位，于是选择留在测试团队，回避更高强度的研发挑战。

左右权衡之后，我多次主动找经理表达自己对测试自动化技术的追求，希望能扛起通过自动化改造测试的大旗，做出一番轰轰烈烈的事业，以此证明自己在技术上的实力。于是，我利用业余时间花了半年多，打磨出一个自动化测试工具。随后，召集团队的许多同事，举办了我人生中的第一场自动化发布会。

2008 年发布会当天，我很早就来到公司的会议室，提前调试好投影仪，又预演了一遍 PPT。觉得一切准备就绪，只等大家到场了。

九点钟，团队的许多同事陆续到来，几个测试部门的经理也到了。正准备开始时，我看到部门 Wang 总监也走了进来——这让我颇感意外。没想到他会在百忙之中抽空来听这场发布会。这阵势让我既紧张又兴奋。经理示意我开始，我便正式启动了我的自动化展示。

“大家早上好，我叫 Jacky，来自测试团队。今天要给大家展示一个全新的自动化系统。我的设计采用 Python 编程，因此具备良好的跨平台性，也能方便地与其他系统进行无缝对接。我参考并深入研究了 xUnit 系列单元测试框架的设计模式，尤其是 JUnit，并在其基础上进行了扩展，整体设计非常精巧。考虑到系统可能有多用户使用的场景，我还设计了一个简单的交互界面，基于 jQuery 实现。客户端采用多层架构，保证了设计的灵活性……中间遇到过各种技术难题，也做过多次版本升级。前后花了我半年的业余时间，终于可以在今天正式发布上线了。”

十分钟后，我讲到我认为的技术精华部分，越讲越兴奋。突然，部门总监 Wang 的手机响了，他歉意地说要接个电话，结果这一去就再也没回来。

我停顿了一下，环顾四周，发现有的同事已经开始敲笔记本键盘，有的则低头玩起了手机。我的经理此时也察觉了这样的状况，轻声的提醒我：“尽快给大家讲讲主要功能，演示一下吧。”

我一时有些慌乱，匆匆跳过几页 PPT，进入详细的功能介绍和演示环节。其实，我要发布的是一个相对复杂的测试用例自动生成系统。因为紧张，讲得有些仓促，也失去了最初讲技术时的那种掌控感。

时间渐渐接近尾声，经理开口总结道：

“感谢 Jacky 同学辛苦半年为我们开发出这么 powerful 的工具。希望测试团队的同事会后能试用一下，看看在实际工作中能否应用起来。其他部门的同事如果也感兴趣，有什么建议，也欢迎反馈，以便我们进一步改进。”

发布会就这样结束了。可我心里隐隐觉得不安——我讲的技术，大家好像并没有听进去。

几周过去，我期待的 “试用、反馈和兴趣” 都没有出现。那天参加发布会的同事依旧按部就班地做着各自的工作。时间又过去了半年。

某天下午三点多，我去茶水间接水，正好碰到部门 Wang 总监。

Wang：“Jacky，最近工作怎么样啊？哦，对了，还记得你上次介绍的自动化工具。那天临时有点紧急事没听完，后来有什么进展吗？”
我：“谢谢王总还记得。发布会之后我也问过一些人，貌似大家都不是很感兴趣。”

Wang：“那你有了解过原因吗？”
我：“他们都说太忙了。但我觉得可能是不会用。”

Wang：“那你有跟经理反馈这个情况吗？”
我：“反映了也没啥用。这个工具涉及一些计算机专业的技术，他们做电子信息的，可能不太懂，也没时间学吧。”

Wang：“那你后面有什么打算呢？”
我：“就听老板安排吧。不过我在加一些新的测试策略，让生成的测试用例更高效。我还打算用 Perl 和 PHP 重写系统，想尝试不同的技术实现方式……”

Wang：“你觉得这样能让它走得更好、更远吗？你想过这个工具真正要解决什么问题吗？”

我被问住了，也被触动了。

到目前为止，我一直试图用更 “高精尖” 的技术去做我认为创新的东西——难道这有错吗？

我忽然想起经理之前与我一对一谈话时，也提到过 “问题” 的问题。那次他还特意送了我一本书——温伯格（Gerald M. Weinberg）的《你的灯亮着吗？——如何找到问题的真正所在》。只是当时我总以 “忙着开发自动化” 为借口，一直没认真读过。

书仍在手边。我开始一边翻看，一边思考自动化中的各种问题。

转眼多年过去。在这漫长的测试自动化实践中，我解决了许多问题，也创造了很多脚本、工具、系统和框架；与此同时，这些成果又被一一废弃或替代。

然而，我也察觉到，许多做自动化的同事也在重复同样的循环——创造、使用、废弃、重来。在这个循环中，我们真的找到了自动化要解决的问题吗？

这里，我也无法回答关于 “为什么要自动化” 的问题，也不敢轻易提出所谓的 “最佳实践”。

我唯一能确定的是：要从真实的问题和痛点出发，在具体上下文中，找到可行的解决方向。

只要一个问题被解决，自动化的价值就前进了一步；只要能带来哪怕一点点效益，它就值得被发布和使用。同时，也要提醒自己：每当解决一个了旧问题，就必然会产生更多的新问题。

这恰好符合 “软件没有银弹” 的论述。

最后，我把这些具体的问题和解决思路整理成集，唤作 “自动化的演化模式集”。

第二章：启动模式

演化模式 0.0：手工测试的苦闷

某天，我在 QQ 上和一个做测试的网友相识。他叫 Bob，是一个测试团队的主管，目前带领一个 7 人规模的手工测试团队做 Web 应用的测试工作。因为他对自动化测试的相关技术不是太熟悉，但是又想做一些事情，希望咨询我的意见和建议。

Bob：我现在打算从手工测试的团队中挑出一个人开始做自动化测试，工作该如何启动和开始呢？
我：规划自动化资源是你的意思？还是你老板的意思？

Bob：都不是吧！
我：那是谁的呀？

Bob：是这样的，我们组有一个很有激情的测试工程师。一天，他来找我说，希望做更多的挑战性的事情，比方说自动化测试。我让他列举哪些自动化测试适合我们做，他也说不清楚。
我：那这也只是他个人的想法呀？其他人呢？你和你老板怎么看呢？

Bob：其他人我没问。我老板是研发总监，他平时只关注功能完成度、质量和上线时间，是否是自动化他没有给出具体的意见。
我：那短期内，似乎因为迎合一个组员的兴趣爱好就开始启动自动化工作，挑战有点大啊。

Bob：我也挺纠结的。一方面，我不想伤害了这个同学的工作积极性，并且这样的想法对团队发展是有帮助的。另一方面，目前手工测试压力已经非常大了，手下的这些测试人员连轴转都感觉事情干不完。再抽出人来做自动化，肯定没办法和老板交代。虽然我们团队也没有自动化的经验，但我想如果能找到比较热门的自动化技术方向或项目的切入点，或许这个让我纠结的事情可以有一些破解的办法。

我们的聊天暂时被我中断了，因为 Bob 眼前的问题让我想起了之前碰到的很多的故事。特别是对于初创的团队，或小规模的只做手工测试的团队，他们核心的诉求就是——给我一个充足的理由去自动化。

在讨论如何自动化如何引入前，我们先看看整个的软件研发团队是怎么开始最初的工作的：

第一天：投资人，觉得软件有市场，资源也到位，就算正式立项了。
第二天：开发，经过设计和实现，通过发布第 1 个版本。
第三天：测试，开始对第 1 个版本进行手工测试，晚上加班到很晚。
第四天：测试，开始对第 2 个版本进行同样的手工测试，晚上加班到很晚。
第五天：测试，开始对第 3 个版本进行同样的手工测试，晚上加班到很晚。
……

在敏捷和持续集成思想的加持下，从第三天开始，研发团队会持续构建和发布新版本。但是，令测试团队感到沮丧的是，快下班的时候会收到这样的邮件。

这是很多人都会面对的、最让人无语的操作。当然，测试的窘境远不止这些：

1.产品迭代周期缩短。很多互联网产品，一天几个十几个版本都很正常。

2.测试周期缩短。在版本迭代过程中，测试是最后一个环节，所以产品上线时间无法更改的情况下，测试的周期是最先考虑被牺牲掉的。

3.测试团队投入缩水。对于测试投资总是滞后的，所以不论是业务缩小还是扩张，测试团队的投入会最先被缩小。

【问题】为了验证每个版本的质量，你每天都要完成大量的、重复性的手工测试，而且可以利用的时间和人手都很有限。作为一名测试工程师，你不愿放弃对于产品质量的承诺，同时你也不希望持续的苦闷。

隐忍苦闷，无限期加班，是最简单的解决方案，但是很难长久。所以，测试团队开始想到两个可能的方式——裁剪（测试方法）和增效（自动化）。

测试方法，不论大家了解的等价类、边界值、判定表，还是基于风险的测试方法，都是基于经验的。通过更有可能发现缺陷（对项目影响更大）的测试用例，代替执行所有的测试用例，就是这些测试策略的核心思想它们都是站在经验和统计学之上的。

自动化，小到测试脚本，大到自动化组件、框架或系统，都是通过机器语言和物理设备代替人去测试。通过全部或者部分自动执行测试用例，代替手工执行所有的测试用例，就是自动化核心目标。在自动化启动的最开始，很容易被利益相关者理解、接受和支持，因为它在减少人工投入方面是显著的，甚至它们还是很好的资产可供持续使用。

【选择】1.隐忍苦闷，继续加班；2. 应用测试方法，只做有限的测试；3. 推行自动化技术，手工自动化结合，做高效的测试。

多数测试的团队都会采用混合模式。但是不管采用任何单一和组合的方案，都是有风险的。在眼前利益和长远利益的权衡中，这些风险是不能忽视的。一个优秀的研发团队，需要识别和处理这样的风险。

加班重复的手工执行全部的测试。对于项目来说，测试的可靠度和可信度会因人、时间、和条件有所差异。而对于人来说，重复的工作很难给测试人员带来积累和成就感，长时间的加班必然导致效率的降低或是人员流失的风险。

测试方法都是前人的经验，或者基于统计的。但是，如果使用不当，例如错误的识别的边界值，或是定义的测试用例的风险分析与客户期望背道而驰，就可能会造成对测试效果的影响。并且这些影响在客户报告问题之前是很难被察觉的。当被客户报告问题的时候，利益相关者会趋向于解决眼前的问题，并质疑测试裁剪的努力。

对于自动化投入，产品的用户大都不会直接感知到。但是，投资自动化的管理层可能会过分夸大的自动化预期，例如：将 100% 的测试用例自动化作为自动化的目标、通过自动化完全代替人工测试、错误的选择的自动化范围、以自动化技术作为推动自动化实施的唯一原动力，这对自动化的启动和推进带来不良的影响。

【风险】应对重复手工测试的挑战，推行各种改进措施都是有风险。在实施改进前向利益相关者告知这些风险是有必要和有益的。

我再次打开和 Bob 聊天的 QQ 消息框，继续关于自动化启动的话题。

我：一个具体的可以切入的技术方向不难，但是是否适合你和你们的部门，就不确定了。不过你可以试着了解你们面临哪些问题，在引入自动化的早期，可能更为合适些。

Bob：我有看到，最近 Web 测试有很多自动化的工具和技术，特别是 Selenium 很火，是不是可以学习一下呢？
我：是可以了解一下。此外，你可以和组里面其他同学聊聊，包括你的老板或是其他相关人，从中发现测试暴露出来的问题和别人对测试发展的观点。例如，用户不太关心的部分，少测试或者不测试。容易出错的地方多测，并且开始推行自动化。在这些与大家息息相关的，特别是一些痛点的地方发力，可以让变革更加容易产生。

Bob：少测，或者不测？这样老板能让过关么？
我：如果老板不了解 “完全测试是不可能的”，那你是过不了关。并且，就算推行自动化测试，也有很多风险，准备实施前，要得到管理层的大力支持才行。

Bob：是。有必要和大家沟通沟通了。
我：有进展了，我们可以再继续聊天哦。我也非常希望能够学习你们的问题和经验。

Bob：好的。谢谢！

合上 QQ，我把第一个自动化演进的经验，加入到自动化的演化模式集中。

名称	手工测试的苦闷
问题	为了验证每个版本的质量，你每天都要完成大量的、重复性的手工测试，而且可以利用的时间和人手都很有限。作为一名测试工程师，你不愿放弃对于产品质量的承诺，同时你也不希望持续的苦闷。
选择	1.隐忍苦闷，继续加班；2. 应用测试方法，只做合适的测试；3. 推行自动化技术，手工自动化结合，做高效的测试。
收益	1.继续加班，收益不变；2. 应用测试方法，执行时间大大缩短；3. 推行自动化技术，人工投入有效缩减的同时测试时长被提高
风险	应对重复手工测试的挑战，推行各种改进措施都是有风险。在实施改进前向利益相关者告知这些风险是有必要和有益的

演化模式 0.1：解决问题即自动化

和 Bob 结束了对话后，我又切换回公司的日常工作当中。

我所在测试部门是做手机测试的，分成很多的小团队，近来，为了应对日益增加的针对相机测试的需求，我们组建了小团队去集中火力做专项测试。然而，在最开始的日子，资源紧张，人手有限，测试能力不高，在客户面前吃尽了苦头。

一次，我们项目经理收到了客户抱怨，说相机的可靠性很差，他们拿到的软件版本中相机在连续拍照一晚上就会出现手机黑屏的情况。开发在分析错误日志查找原因的同时，也希望我们测试部门在公司测试环境下去复现这个缺陷。

当时，负责相机自动化测试的同事告诉大家，连续一晚上拍照的压力测试一直在做。最开始，由于测试团队自动化的能力还不具备，所以就找研发部门在相机的程序中加了一个彩蛋，用作自动化测试。当这个彩蛋被激活后，只要输入循环次数，选择前置或者后置摄像头，就可以进行连续拍照的压力测试了。但是，既然有这样的和客户一样的压力测试程序，为什么没有在客户的版本中发现这个缺陷呢？最后，团队内部的讨论的意见是得它可能是一个偶发问题。

与此同时，开发团队也找到了问题产生的原因。新的版本提交到测试团队，为了防止由于偶发造成这样的缺陷，我们在多台设备上做了一晚上的测试，没有发现这样的问题。这样的版本在第二天就提交给客户了。然而，隔日早上，客户发给我们同样的抱怨，所有的人都傻眼了。这个抱怨也惊动了公司的高层，作为技术人员，压力自然达到顶点。

“到底哪里出了问题？” 测试部门的同事都很疑惑。“为什么同样的版本同样的测试方法，在客户的硬件上就能发现问题，而我们的不可以？” 这时，有个同事提到：“客户的手机用的是 4G 的存储卡，而我们是 2G 的。这个应该是唯一的硬件配置的差别了，不过貌似和相机的这个测试也没啥关系吧？”

“等等，说到存储卡，我想到了。” 做相机测试的工程师说道，“我昨天也才发现，客户反映做了一晚上测试，是执行了 12 个小时。而我们自己的测试程序，其实只运行了 8 个小时。”

“那我们为什么不也执行 12 个小时呢？” 测试经理很着急的问到。

相机测试的工程师解释道：“就是和刚才说到的存储卡容量大小有关。之前，我们也试图跑 12 个小时甚至更久，就是把拍照次数设置成 10000 张，结果跑了 9 个小时后程序不停的报错。找开发查看问题的原因，才发现外置存储卡满了。后来，为了让测试能够正常的执行，我就把拍照的次数缩短到执行 8 个小时了。这样每次执行前清空存储卡，就可以保证不会让出现类似的问题。”

测试经理显然对这样的答案很不满意，“既然知道这样的问题，为啥绕开它？而不是解决它？”

“我当时也给开发提过需求，希望他们在后门中增加照片删除的功能。但是，那个开发觉得没必要继续改进这个测试后门。后来，我们组内讨论是否可以重新设计一个全新的相机自动化测试的工具，这个问题也可以解决。而且当时，也有和您讨论过这个自动化工具开发的方案。后来您说测试压力很大，所以就先放一放了。” 显然，做相机测试的工程师也有些无奈，想把事情做好，但是苦于没有资源和领导的支持，所以把问题又再次抛给了测试经理。

【问题】没有自动化的经验、没有资源的投入、甚至是领导的支持，开展 “自动化测试” 非常困难。但是，当客户的问题摆在面前，同事的压力扑过来时，你不得不重新面对它。该选择什么样的方法来解决你的问题呢？

“我下来会和客户联系，如果他们能够共享他们的手机给我们去复现问题，我们也许就不需要做什么了。” 测试经理说到，“不过，这对我们来说，也是一个很好的机会，帮我们测试部门迈出测试自动化的第一步，不再总是依赖开发团队。”

说到这里，大家有些诧异，包括那个做相机测试的工程师。“还是最初的问题，既然存储卡满了，为什么我们不能删掉呢？” 测试经理继续道，“小张，你之前不是有学习过 Shell 编程么？半天的时间，我们把这个自动化清除照片的自动化脚本做出来。可以不？”

“我试试看，应该可以。” 小张答道。不过相机测试工程师提出了异议：“我还以为是要重新考虑设计一个测试工具。只是为了这一个问题是否…”

“通过机器，而不是人，完成删除存储卡上的照片。这样自动化和你理解的自动化不一样对吧？” 测试经理放慢了语速，更加平和的说到。

一个小数后，相机测试团队的第一个测试自动化出炉了。就是这么简单的几行 Shell 程序，在手机上实现了一小时清理一次照片目录的功能。更重要的是，它解决了一个很棘手的测试团队面对的问题。

与此同时，开发人员经过分析发现，前一次修正的代码不是真正引起这个缺陷的原因。而恰恰是由于，每次拍照的时候由于内存没有回收而引起了泄露。拿到开发最新的修正版本，测试团队这次再也不敢掉以轻心。除了在最新的版本上用 “拍照压力测试 + 这个照片目录清理脚本” 对修正后的版本进行 12 个小时的验证外，同样的测试也在客户发现问题的版本上执行。修正前 Fail，修正好 Pass，我们的验证才算正真的通过。

第二天早上，一共 6 个手机，3 个 Fail，3 个 Pass，符合我们的所有预期。这个版本提交给客户，再没有收到客户的抱怨。

这是发生在我周围真是的案例，我随手拿出我的演化模式集，把这第二个加了进去。

名称	解决问题即是自动化
问题	没有自动化的经验、没有资源的投入、甚至是领导的支持，开展 “自动化测试” 非常困难。但是，当客户的问题摆在面前，同事的压力扑过来时，你不得不重新面对它。该选择什么样的方法来解决你的问题呢？
选择	任何编程语言、或者任何计算机应用技术，能够有助于快速推进问题的解决，都可以让测试自动化从 0 变到 1。
收益	除了收获问题的快速解决，测试团队有了构建第一个自动化的自豪感和对未来更多的自动化演进的期许
风险	第一次的尝试可能投入过大，并且对解决问题没有帮助

演化模式 0.2：被分割的过程

经历了之前的 “相机测试门” 后，我们测试团队确实转变了对自动化的看法。正如测试经理说的那样，测试自动化事业大门就此被打开，并且逐步被发展起来。一段时间内，大家都会热衷于把手头需要重复做的事情自动化了。并且，大家也乐于分享自己的自动化的脚本和小工具给一直做手工测试执行的同学，手工测试执行的同学轻松了很多，笑容也比以前多了许多。

快乐总是短暂的，新的问题会很快到来的。

在自动化之前，针对每个版本，手工测试同学连轴转，非常忙碌的执行着每个测试用例。慢慢引入自动化测试以后，很多工作由机器代替人来做了，开发人员觉得我们测试的效率有了显著的提高，所以就开始肆无忌惮的发布版本，让我们进行测试。这样，在每个小版本迭代周期里，只运行与修改模块相关的、重要的自动化测试，成了大家约定俗成的流程。

执行了一段时间，除了一个让开发人员不解的状况。每当 “视频播放器” 和 “相机” 这两个模块被开发同时修改以后，测试结果有时候会推迟很久才发出来。搞技术的人总是要追求完美的，虽然是一个很小的事情，竟然也被一名开发工程师发现了。也不能说这个开发工程师有多么挑刺儿，只是他希望更早的知道测试结果。

于是乎，开发人员主动找测试去沟通，才了解了实际情况。当 “视频播放器” 和 “相机” 这两个模块被开发同时修改以后，由于时间很紧，按照之前协商的测试执行的策略，测试工程师只需要一前一后的执行两个压力的测试用例即可。其中，一个是相机多次录像的压力测试，一个是视频播放器循环播放多个视频的压力测试。录像的压力测试，没有再沿用开发同学提供的后门的方法，而是测试组的同学开发的自动化测试脚本。循环播放多个视频的压力测试，是将一组视频文件复制到手机的存储卡上，利用播放器自带的列表播放功能，实现的自动化。

在设计这个两测试用例时，循环次数是固定的。录像压力测试做 100 次，每次录制 3 分钟的视频，总共时间也就 300 分钟，5 个小时。视频播放所用到的视频文件，总共时长是 4 个小时。但是，两个连在一起运行有时候会执行整整半天。

由于之前的照相的压力测试是小张设计的，所以这次录像的压力测试还是他。这次，小张找到了问题所在。其实很简单，连在一起的时候，视频播放器除了播放拷贝到手机上的视频以外，本身录像压力测试保存的 5 个小时的 100 个视频文件也被播放了。由于是自动化执行，执行该测试的同学只是简单的把两个用例连起来运行，哪会意识到他们之间还会 “打架” 呀。

于是小张告诉运行该测试的同学，在执行第二个用例之前，先记着先清空录制的视频。但是，测试的同学有些不乐意了：“就为了这个事情，等测试跑起来，我还得再等 5 个小时，还让不让人下班了？”

【问题】两个测试过程 P1 和 P2，单独自动执行都需要较长时间。让测试人员等待 P1 执行完后执行 P2，总会遇到很大的阻力。

有了前面自动删除照片的经验，小张很快就决定把自动化删除视频文件也添加到相机压力测试中。然而，过了一周的时间，小张发现事情远比想的要复杂。自动删除视频碰到困难，因为一边摄像一边删除正在更改的文件时，系统会报错，测试执行也会被中断。而在所有的视频录制结束后，删除整个视频目录文件也会失败。幸运的是我们发现了系统的缺陷，不幸的是这个缺陷是系统自身的问题，修复要等待第三方厂商的跟进，我们当时对此束手无策。于是，小张开始继续钻研其他方案。最终，又经过一周的时间，小张另辟蹊径，通过恢复出厂设置，完成对于文件的删除。这个方案使得测试又可以正常的执行下去，虽然后面两个用例一起执行的情况几乎再没有发生。

【选择】通过合适的自动化手段，消除不必要的人工干预，将两个分别需要长时间运行的 P1 和 P2 合并成 P。

虽然这个问题解决了，但小张在给测试经理的周报中提到，为了解决这个问题前后他花了整整的两周时间。在测试部门的周例会上，测试经理再次提出来这个事情，与大家讨论。会上，一个测试同事一句点醒的小张：“两个测试用例的执行顺序调换一下不就解决了么？” 瞬间，小张觉得自己满满两周的工作真的是白白浪费了，悔不该早点儿和大家商量讨论。测试经理同时也提出，无法删除视频的缺陷是必须要修复的，而且一个月内肯定要搞好，否则我们的客户是不会接受的。等到这个缺陷修复以后，自动化就没有任何用处了。

在处理自己的碰到的问题时，小张的初衷是好的。因为，解决了需要人工干预才能继续自动化的这个问题，不但可以帮助到测试执行的同事早下班，也可以让所有其他同事更早的拿到测试结果。但是，在实施开始后，他又慢慢的失去了方向，将自动化作为最终的目标。而且，最关键的，他这样做也不够经济。

【收益】如果 P1 和 P2 单独执行都需要若干小时，通过自动化完成到 P 的合并需要若干分钟到若干小时，这样的自动化投资还是划算的。而如果 P2 执行的时间（例如几分钟）远远小于 P1（例如若干小时），那么合并成 P 就不那么划算，而是将 P2 放在 P1 前执行的就是一种更经济选择。

“被分割的自动化过程”——这是测试自动化经常可以考虑解决的问题。一方面，由于测试需要解决的问题差异性很大，自动化技术的差异性也很大，这就造成了测试自动化过程被分割开来。而另外一方面，大家对于测试过程总是时长缩短的期望，测试人员对于降低工作时间碎片化的期望，反过来由促使分割的测试自动化过程被合并。合并的越多，合并的总时间越长，合并后执行的越稳定，越持久，这样的测试自动化才约值得去做。这个工程优化的问题被我作为第 3 个经验加到演化模式集里。

名称	被分割的自动化过程
问题	两个测试过程 P1 和 P2，单独自动执行都需要较长时间。让测试人员等待 P1 执行完后执行 P2，总会遇到很大的阻力。
选择	通过合适的自动化手段，消除不必要的人工干预，将两个分别需要长时间运行的 P1 和 P2 合并成 P。
收益	如果 P1 和 P2 单独执行都需要若干小时，通过自动化完成到 P 的合并需要若干分钟到若干小时，这样的自动化投资还是划算的。
风险	对于 P1 执行结果获得的滞后而失去风险报告的及时性

演化模式 0.3：输入和判定的交替

“已经 100% 全自动化了！” 对于测试自动化开发工程师，告诉同事和经理自己完成了这样的目标，最初总会让人眼前一亮，为之振奋。但是有时候，测试判定这个尾巴被留下以后，会让执行自动化的工程师苦不堪言。

某天，我收到一个测试工程师投来的简历。他叫 Kevin，既有测试工作的背景，也有编程的经验，电话面试过也觉得还不错，于是就约好了让他来公司做正式的面试。短暂的寒暄过后，我们就很快的切入自动化测试的问题上。

我：看到你之前有做过 PC 上浏览器的测试工作。能否大概介绍一下你都做哪方面的测试么？都是怎么做的？
Kevin：我之前参与过的浏览器测试，包括功能性测试、压力测试、兼容性测试和性能测试。功能测试以手工测试为主，兼容性测试和性能测试有专门的测试工具和 benchmark，压力测试我们有用 Selenium 开发一些脚本。

我：你之前报告的缺陷，能举一个例子么大概描述一下么？
Kevin：之前碰到访问一些门户网站，某些图片总是显示不出来。而且，这个问题是偶然发生，某个特定网站会每次都发生。经过我不断的测试和总结规律，给开发提供了一个很详细的测试报告，帮助开发最终定位了问题的原因。

我：那当时感觉一定很棒哦。对了，如果要针对这个问题做回归测试，该怎么自动化呢？看到你之前有开发测试脚本的经验，现在能否写一个这样的测试脚本呢？
Kevin：好的。

5 分钟后，下面的测试程序就完成。

Kevin：写好了，这样就可以 100% 的实现自动化执行了。
我：执行是自动化了，但是，它只是解放了我们的双手，测试执行的过程人还是不能空下来吧。大家还会觉得这算是 100% 的自动化方案么？你有啥改进的办法？

【问题】当一个自动化的测试过程被启动后，如果还需要测试工程师一直或时不时的去看两眼的话，这样的自动化通常会被认为是低效的。

于是，Kevin 又拿起笔来，对之前的测试程序做了如下的增强。

Kevin：程序修改了一下，每次网站被打开后，都进行截屏，然后保存成文件。等整个测试程序执行完后，测试工程师只要逐个打开每个图像文件进行检查就完了。
我：那除了这样的方法，还有什么方案呢？

Kevin：下载一个屏幕录制的工具，把整个过程都录下来。这样也可以的吧。
我：嗯，这样也可以让测试过程与人工检查分开。不过，与截图相比，这样做有什么不足？

Kevin：与截图相比，在视频中查找检查点会比较麻烦吧，耗时应该会更多一些吧。
我：但是，用视频也会有它适用的场景的测试，你觉得会有哪些呢？

Kevin：比方说，有些视频网站播放视频出现的错误，有些游戏出现的 bug 等等。单单只是设置一个或几个检查点，很难选择到合适的位置，也很难完整的代替全部的主观感受。
我：如果针对网站或者游戏的服务器端进行测试，或者针对 API 的单元测试，是不是我们就可以永远脱离这样的困境，实现真正意义上的 100% 自动化呢？

Kevin：是的。不过，也不是 100% 吧。否则很多测试自动化的系统，或者被测试系统本身，都增加了日志系统，便于在失效以后去做进一步的分析和判断。这算是问题根因分析的一种手段。不过，对于自动化测试这些方式都可以使用。
我：很好。我们现在再设想对于网游进行长时间的压力测试…

【选择】将测试过程启动后的所有需要人工的判定操作合并，然后推迟到测试过程执行结束后。

后来，Kevin 顺利的通过了我们测试部门的面试，加入我们的团队，成为一个测试自动化开发的工程师，继续去发挥他在自动化开发上的经验。而这次与 Kevin 的面试过程，也被我收录成一个新的经验加到演化模式集里。

名称	输入和判定的交替
问题	当一个自动化的测试过程被启动后，如果还需要测试工程师一直或时不时的去看两眼的话，这样的自动化通常会被认为是低效的。
选择	将测试过程启动后的所有需要人工的判定操作合并，然后推迟到测试过程执行结束后。
收益	如何自动化过程 P1 – PN 的总执行耗时为 T1，推迟所有人工判定过程的时间成本为 T2，如果 T1 时间原因大于 T2，这样的投入还是合适的。此外还要考虑附加成本投入（如增加日志或视频监控等）
风险	对实际测试行为反馈的滞后，以及无法推后所有检查点的情况（前序测试过程判定结果作为后续测试过程的输入）

张昊翔

2025/10/16

WeChat: hzhan11
QQ: 22321262
Email: xjtu_xiangxiang@hotmail.com
LinkedIn: https://www.linkedin.com/in/hzhan11/