敏捷测试专家徐毅：怀疑论者的思维模式

测试的重要性和价值，已经毋庸置疑，然而，怎样才能借助于测试与质量为企业贡献价值呢？

敏捷、精益，移动、云计算，方方面面的变化都给测试与质量工作带来了极大的挑战，又该如何直面这些挑战呢？

这是今年 QCon 上海的大测大悟专题试图回答的问题。今天，我们邀请到本专题的出品人，敏捷测试专家徐毅，来分享一下他对于测试的一些观点，以及这个QCon 专题有哪些让大家有所收获的内容。

InfoQ：首先，请简单的介绍一下自己目前负责的工作，以及自己在测试领域做过哪些方面，关注过什么。

徐毅：我叫徐毅，现在在康仕诚公司担任资深敏捷顾问工作，提供跟敏捷开发、敏捷测试和敏捷转型相关的服务。

（注：关于我的测试历程，在图灵社区上我写过好几篇文章详细地描述过）

刚开始工作时，做过一段时间的开发工作。05 年初在杭州的前诺基亚 3G 研发中心开始从事测试工作，负责某些功能模块（我们称之为 Feature）的测试，在我们的测试流程中，所负责模块的所有测试活动都要负责，从编写测试计划、设计测试用例、执行到检查结果和编写报告，包括所有的测试类型，都由同一名测试工程师负责，还要负责报告缺陷和推动开发人员修复缺陷；同期也加入了新成立的测试自动化组，是其中仅有的两名成员之一，这对我的测试哲学影响非常大，由于从一开始做测试就是结合着自动化，所以我也坚定地认为没有任何测试不可以被自动化，只取决于实现它需要投入多少以及大家愿意投入多少成本去实现它。随后开始负责一些更大型模块的测试、模块集的回归测试以及更大的领域（我们称之为 Domain）回归测试。

06 年 1 月我加入了我们的第一个 Scrum 试点项目，成为了最开始的 4 人团队（Grid）里的第一个也是唯一一个测试人员，开始以敏捷方式做测试。我们尝试抛弃了几乎所有现有流程，从零开始思考，到底有哪些流程和规范是需要的，然后再加进来。结合测试自动化、持续集成等各种实践的经验，我们制定了一套更敏捷的测试流程，作为新的整体研发流程的一部分。

同期我也一直在做测试自动化的工作，从编写脚本、开发维护 library 再到接手负责公司内部的一个模块化测试自动化框架（HitMan）；之后作为测试自动化组成员，对 robotframework 进行评估并开始使用，作为第一批 4 名内部培训师之一负责培训和推广 robotframework 的使用；后来，产品线进行了 Scrum 大转型，所有的测试人员都必须要使用 robotframework 编写自动化的测试用例，这制造了带很多的麻烦，作为组织内第一批 2 名测试自动化教练之一，负责辅导 Scrum 团队内的测试人员学会使用 robotframework 工具以及做好测试自动化这件事，包括规划整体的测试自动化体系。

07 年中，我加入了另一个新产品开发担任其中一个团队（Thunder）的 Scrum Master，我们依然采用敏捷开发方式。一开始我还需要投入 50% 的工作量用来做具体的测试工作，但由于 Scrum Master 工作任务的零碎和不可预期，使得我难以保障工作任务按期完成，于是我开始辅导团队内的两名新手测试人员。我的目标是辅导他们编写质量上乘的自动化测试脚本，通过提升质量、降低维护成本抵回我所损失掉的 50% 工作量，个人目测 2 个月后就达到了这个目标。同时，基于前一个试点项目的成功经验，我们非常重视持续集成工作，并组建了一个虚拟的团队（可以看做是一个 SWAT 团队），由经验丰富的工程师组成，包括开发人员（秦之远，曾于 QCon 演讲过持续集成）、测试人员（也即是我）、直线经理等各种角色，以便随时响应修复失败的 build，捍卫持续集成最重要的纪律“保持 build 始终可用”，从确立 SCM 策略、编译问题、测试环境、测试脚本等各种问题都需要解决。

08 年底，我加入了公司内部名为“Flexible Company”的敏捷转型团队担任精益及敏捷顾问，负责支持全球范围内诺西（时为诺西）所有研发中心产品线团队的敏捷转型，敏捷测试的辅导也是我工作内容的一部分，包括以核心团队加实践社区的方式推动测试自动化体系的建设和稳固，以及在研发组织内建立敏捷测试的文化和体系。

11 年我去了上海惠普，在企业服务（Enterprise Service）部门担任资深敏捷顾问；12 年去了北京诺基亚手机，担任敏捷及精益教练；13 年回到上海，加入了 CCG 担任资深敏捷顾问。在这期间，我的工作内容都是辅助内部或外部客户，推动敏捷开发方式的普及、推动敏捷转型，或是推动敏捷测试的落地，等等。

InfoQ：您目前关注的重点是什么？

徐毅：具体一点的话，我关注如何让测试在敏捷开发方式下发挥更大的作用，以及如何让测试自动化和持续集成成为研发效率提升的基石。泛一点的话，我关注如何以各种方式提高测试工作的效率和效果，并对研发价值的整体提升做出贡献。我也很关注如何结合系统思考、学习型组织、精益创业等很多的优秀理念，把它们都运用到敏捷转型或测试提升等过程中去。

InfoQ：感觉在过去一年，自己接触到的、关注的领域发生了什么变化？

徐毅：感觉云、虚拟化、大数据等一些概念进入了更务实的阶段，而且在业内一些公司已经开始对测试工作产生了很多的正面影响。

作为一名自豪的前诺记人，惊闻微软将以 70 多亿美元收购诺基亚设备部门，我的心情非常的复杂。

InfoQ：您认为要让测试在敏捷开发方式下发挥更大的作用，是否必然会涉及到开发人员与测试人员角色的合并，以及自动化测试的完整覆盖？

徐毅：

【关于角色】

首先，敏捷开发方式要能够发挥作用，几乎所有牵涉到的角色都需要做出改变才行，不仅仅只是测试同仁。但这并不一定是通过“合并”的方式，更多的是“融合”。在此过程中，现有角色有可能消失，也有可能被赋予了新的内涵，也有可能演化出一些新的角色和职位。

其次，我们要区分“做事的人”和“做什么事”。在我们很多的讨论中，“测试”、“开发”这些词汇往往即被用来描述一个职位、一种角色，也被用来描述一件事（也即测试这种活动）。在传统方式中，测试这件事被绑定在了测试这个角色的身上，其中一大原因就是在大多数流程中，测试都被看做是在某个阶段可以集中完成的事务，这样的情况下，自然是专业分工一批人出来只做测试的效率和效果最佳。然而，在敏捷开发方式下，测试的颗粒度越来越小、频率越来越高，沿用传统方式根本就无法有效地开展测试工作，而传统意义上的“测试人员”在这种情况下也很难履行自己的职责。同样，频繁交付新功能的同时还必须确保不会损害已有功能，关键在于“回归测试”的效果和效率，不仅需要加强测试自动化以提升回归测试运行速度和效率，也需要扩大回归测试的覆盖面，从传统的功能测试、集成测试等，扩展到测试金字塔的每一层。而这些变化是不可能只靠头顶“测试人员”称号的工程师就能完成的，这就意味着掌握开发能力的工程师也需要参与测试活动中。他们需要做好自己所开发代码的单元测试、理解测试工作并提高代码可测性、支持测试自动化工作，甚至是向测试人员学习测试技能以改善其单元测试的效果。

取决于企业环境和行业的不同情况，以及敏捷开发方式的不同实现情况，角色变化的具体情况也会有所不同，无法一概而论。

【自动化测试的完整覆盖】

当富士康都开始大规模启用机器人的时候，我们还在讨论自动化测试的必要性或是覆盖率，其实是很搞笑的一件事情。

自动化的好处在于，当测试被自动化之后，就不再存在决定“这一轮测试执行还是不执行”的困扰了。当然，这需要做到高质量的测试自动化，而且是自働化。测试自动化可不只是写写脚本，工具的选择、整体规划都非常的重要。推荐大家看看业内第一本专门讲自动化的著作，Mark Fewster 和Dorothy Graham 的《 Software Test Automation 》，虽然年代久远，但仍然非常有价值。

然而，谈论“完整”，则又是一件很搞笑的事情。完整不完整，取决于分子（已自动化的测试）和分母（所有的测试）两个元素。对于测试这回事来说，我们都应该知道，测试是不可能穷尽的，那也就意味着，分母是接近于无穷大的一个数字。在这种情况下，想做到“自动化测试的完整覆盖”只能是痴人说梦。制定良好的测试策略，以此挑选、确定需要执行的测试，从而保障测试的效果；加强测试自动化，从而提高测试的效率。

“100% 测试自动化”并不是一个好的操作型定义，但它却能够逼迫我们去想办法尽可能地提高测试自动化率。而测试自动化率则直接影响到我们在敏捷开发方式下的交付频率和质量。

InfoQ：不知道您对于“其实我们根本不需要测试人员，开发者应该自己做测试”这个观点是怎么看的？

徐毅：这是一个非常有争议也常常被提起的话题。作为测试人，首先需要研究的就是命题本身，也即这个观点本身。我们重新来诠释这个观点的话，它的潜台词就是：“测试这点事，我们不需要专门的测试人员来做，我们开发人员完全可以胜任。” 再细细剖析，那就不得不提出一些质疑了：

• 测试这点事到底包括哪些事，冰山之下是否还有暗礁？
• 完全可以胜任，意思是可以“执行”这些活儿，还是说能够做得一样好，效果一样？
• 有能力做到，是否意味着一定会去做这些事呢？如果不是，那这些活儿谁来干呢？
• 即便开发人员能够胜任这些工作，他们需要为此投入多少时间呢？10%？30%？50%？80%？这个时候，还称呼他们“开发人员”是否合适？

所有这些争执的缘起，只因为测试队伍里有不称职、不上进的同仁，而开发队伍里也有一样不称职、不上进的同仁，以他们为标准的话，自然是不需要专职人员，其他角色均可以取而代之。一名用户文档编写人员，如果也具备了高超的开发技能，我们是否可以说“其实我们根本不需要开发人员，用户文档编写人员就可以自己做开发”呢？基于微观事实做出宏观论断，没有意义，也无助于改善现状。

在我看来，开发、测试的最大区别在于思维模式的不同。开发的思维模式更像是创建型，从 A 到 B，想方设法也要找到一条路，不管有多少可能性，必须找出一个来；而测试的思维模式更像是怀疑论者，这条路真的能到 B 吗？路标清晰吗？这是 A 到 B 的唯一一条路吗？万般可能性，最好统统试一遍。

推荐大家阅读 Elisabeth Hendrickson 所著的《 Explore It 》。

InfoQ：方便举一个例子介绍虚拟化对测试工作产生的影响么？

徐毅：在测试工作中，一个比较常见的瓶颈就是有限的测试环境资源，利用虚拟化技术，辅以测试的分布式并发执行，可以缓解这一方面的问题。

而且虚拟化也有助于解决测试环境标准化和 bug 现场重现等一些问题。