高效的敏捷测试第一课敏捷测试介绍，与传统测试对比

开篇词：重剑无锋、大道至简

你好，我是朱少民，欢迎来到我的“敏捷测试”专栏。2000 年至今，我已在测试行业摸爬滚打 20 年，因为热衷分享应该有不少同行认识我。可能是因为读过我写的《全程软件测试》《软件测试方法和技术》等十多本测试图书，也可能是因为看过我写的文章，还可能是听过我的公开课或者技术大会演讲。

很多人也了解我的从业经历。我曾在 WebEx、思科（Cisco）工作了10 多年，期间去了硅谷，在那里，我接触到了先进的软件研发思想、方法及优秀的实践，完成了从测试小白到思科中国 QA 高级总监的蜕变。

截至目前，我已为近 100 家公司提供过测试培训、咨询等服务。经常听到这样的场景：线上出了 Bug 召集会议复盘，开发指责测试没测出来，没把好质量关；测试抱怨开发不做单元测试，要不早发现了。结果往往是大家写个改进报告，测试保证添加相关测试用例并补充到回归测试集，开发承诺以后做好自测，提交了事。

企业需要什么样的测试人才

但是这样真的对工作改进甚至测试人员成长有帮助吗？你有想过吗，企业到底需要什么样的测试人才呢？

移动互联时代竞争激烈，软件研发的交付周期越来越短，企业必须做到持续集成、持续交付，才能更好地满足业务需求，而这正是“敏捷”一直追求的。据统计，截止 2018 年初全球已有 91% 的软件开发采用了敏捷开发。国内很多企业采用了敏捷开发模式，但没有真正理解“敏捷”的初心和目标，没有想清楚敏捷开发模式对测试人员的要求，却在以“敏捷”的标准来衡量甚至淘汰测试人员；甚至有些企业都不知道自己用的所谓“先进方法”就是敏捷。因此，当今测试人员必须真正理解敏捷开发模式对测试的要求，掌握必备的技能，成为一个真正的敏捷测试人才。

究竟什么是“敏捷测试”？敏捷测试是指敏捷开发模式下的一套完整的软件测试解决方案，它强调“与开发协作”、“自动化测试”、“客户思维”和“动态的测试策略调整”。这不仅要求软件测试团队转型，而且要求测试人员具有和过去传统测试不一样的软技能和硬技能，按照敏捷思维方式来重构自己的技能。

测试人如何立于不败之地

那么，测试工程师如何才能快速适应这个转变，掌握敏捷测试的技能，立于不败之地呢？

敏捷测试本身涉及很多东西，它包含了人员、组织、技术、方法、流程和工具等各个方面。但掌握敏捷测试其实很简单，只要你能读懂敏捷测试所坚持的变与不变：不变的是它的价值观、理念以及思维方式；变的是持续改进的敏捷测试方法、技术和工具。

从 2010 年开始，我陆续发表了很多关于敏捷测试的文章，但没有系统整理过。国内出版社引进了Janet 和 Lisa 写的《敏捷软件测试》和《深入敏捷测试》，或许是国内外对”敏捷测试“的认知水平不一，很多测试同行表示看了之后感觉云里雾里，甚至对敏捷测试产生了错误的认识；网络上关于敏捷测试的信息有很多，但是从这堆爆炸的信息中找到真正有效的学习资料非常困难。

我为什么写这个专栏

思考再三，我决定开设这个专栏，目的就是想带领你对敏捷测试进行一个梳理，透过各种繁杂看清它的本质。敏捷测试具有很强的实践性，光有理论知识是不够的。我会以业界优秀实践为基础，不仅告诉你敏捷测试如何做，还会详细讲解为什么这样做，力求以直观、简洁的方式帮你彻底掌握敏捷测试的思想、具体操作流程及有效的方法和工具。

你能学到什么

如果你是一位测试工程师，希望通过学习我的专栏你能得到以下收获：

真正了解什么是敏捷测试，更好地融入到敏捷开发环境中，与业务、产品、开发等相关人员有更融洽的沟通与协作；
了解敏捷测试的具体操作，更快、更有效地完成测试分析、设计和执行，做到事半功倍，今后的测试工作变得更轻松；
拓展测试视野，进一步夯实测试基本功，重构测试技能；
构建一个良好的敏捷思维，终身受用（绝无虚言）。

如果你是测试管理者或项目经理，希望你能增强对敏捷测试全局的理解，清楚如下几点：

如何完成从传统测试向敏捷测试的转型，包括敏捷文化的建立；
如何构建一个有效的敏捷测试体系，包括有效的测试流程、稳定而高效的基础设施或自动化测试平台；
如何指导团队、指导工程师开展测试工作，极大地提升测试效率，做到持续测试，满足持续交付的要求；
如何协调不同团队和不同岗位的沟通和协作，帮助整个团队提升研发质量和效率。

专栏内容如何设置

本专栏分为 7 个部分，共 49 讲，每讲 10 多分钟。内容”少而精“，能让你在较短时间内了解到敏捷测试的精髓并能应用到工作中。

第一部分：整体讲解什么是敏捷测试、敏捷测试流程及敏捷测试思维。
第二部分：很多表面上看起来是技术层面的问题，其实本质上是人的问题。所以，在进入敏捷测试的具体操作讲解之前，必须先谈谈人员和组织文化，包括：敏捷开发中测试的职责由谁承担、如何承担，如何完成团队面向敏捷测试的转型，以及在组织内部如何培养质量意识和学习型文化。
第三部分：介绍如何构建敏捷测试基础设施。不仅介绍自动化测试框架、测试工具链，如何应用虚拟机技术与 Docker 技术搭建测试环境，还会帮助你掌握敏捷环境下的自动部署、自动验证，以及构建基于 DevOps 的测试基础设施。你会发现敏捷测试在持续集成、持续交付以及 DevOps 的实施过程中无处不在。
第四部分~第七部分：分享敏捷测试从计划到收尾的完整实施的过程。我会侧重介绍敏捷思维下如何做测试分析与计划、测试设计与执行，以及收尾与持续改进。同时还会介绍很多优秀的敏捷测试方法和技术，比如测试左移、测试右移、探索式测试、SBTM 等。

好了，开篇就聊到这里吧。最后送给大家一句话：35岁不一定失业，但不生于忧患一定会死于安乐，如果可以，不要等到”被淘汰“才开始努力。希望本专栏能够成为你前行的灯塔，让我们一起开启这段敏捷测试之旅，下节课我们不见不散！

第01讲：究竟什么是敏捷测试？

2013 年，在 InfoQ 发表了相同标题的文章，但这篇文章是全新而作。在回答“究竟什么是敏捷测试”之前，我先问一个问题：你了解敏捷开发吗？

虽然我听不到你的回答，但还是先提醒你回忆一下著名的敏捷宣言和 12 项敏捷开发原则，带着这些回忆或过去的思考，来听听我下面给你讲的案例，在听的过程中，你可以去审视这个案例，来判断哪些符合敏捷价值观，哪些又违反了敏捷开发原则，最后我们一起来分析案例，并回答“究竟什么是敏捷测试”。

从传统测试转型到敏捷测试的案例

这个案例来自一家国内的公司，这家公司的产品主要是基于 Android 系统的智能终端。故事发生在 6 年前，即 2013 年，这家公司的软件研发部门在这一年开始了一系列面向敏捷测试的尝试。

先给大家介绍一下案例背景，公司的软件研发部门下属有四个开发部门和一个庞大的测试部门，其中，一个负责各种研发工具开发的部门也隶属于测试部门。开发人员和测试人员比例几乎是 1:1，开发部门的职责是按照负责的功能模块划分的，而测试部门负责软件系统级别的所有测试，包括功能测试、性能测试、安全性测试、可靠性测试、兼容性测试等。当时采用的是传统的瀑布式开发模式，即 V 模型，代码编写和产品测试被明确地分成了两个阶段，如图 1 所示：

图1 软件研发的 V 模型

1. 持续集成的尝试

这里所用到的工具包括：分布式的代码版本控制工具 Git + 代码审查工具 Gerrit + 持续集成工具 Jenkins + 自研的基于 Monkey Runner 的自动化测试框架。基于 Git + Gerrit + Jenkins，开发部门已经实现了代码的自动构建。

希望达到的目标是代码提交后完成自动构建、自动部署和自动化测试，并且自动生成测试报告。在实施过程中，工具链没有问题，自动构建和自动部署也没有问题，问题就出在自动化测试上。

一个产品的手工测试用例大概是 1000 个，但是能转化为自动化脚本并且放在集成环境里执行的用例，在很长时间内只有 100 多个，只实现了版本验证，即我们通常所说的“冒烟测试”。这意味着，当开发人员提交代码，触发的自动化测试达到的覆盖率非常有限，即使这个集成环境能够支持持续验证，所有人都觉得很鸡肋。

2. 测试前移和组织架构的尝试

当时对测试前移的定义是在软件编码阶段就进行测试，而不是等到开发结束以后才开始测试。简单的说就是边开发边测试，期望通过这个缩短产品开发周期。

（1）第一阶段

开发部门按照 Scrum Team 进行划分，按照 3:1 的比例招聘了测试工程师。一开始没想明白他们到底需要什么样的测试人员，所以招来的基本上都是手工测试，看不懂代码的居多。

他们在 Scrum Team 里的主要工作包括：手工测试；一遍遍按照开发的要求复现 bug；给开发人员打杂，比如给终端更新一个新版本、找找开发想要验证的硬件型号，等等。而在项目早期，产品硬件不到位或者软件集成到一起不工作时，手工测试则没法进行。

（2）第二阶段

领导们本来希望通过敏捷模式可以减少测试人员的数量，但事与愿违，测试部门专门负责系统测试的人员并没有减少，反而在开发部门内部又多了几十名测试。原因在于两拨人马用的测试方式都差不多，人多了，无非体现在报的 bug 多了，测试部门看重的是需求的覆盖率，人自然减不下来。

所以，在一次改组中，领导宣布所有的测试人员都转到测试部门，要求测试部门减掉相应数量的测试外包。Scrum Team 可以向测试部门要求按 3:1 的比例配备测试人员。测试部门能够了解 Scrum Team 的测试范围，减少了重复测试。改组之后，人数倒是减下来了，但是仍然以手工测试为主，因为组织架构的变更，开发和测试经常因为谁对开发阶段的测试说了算而争论不休，开发和测试变得更加泾渭分明，关系更紧张了。

（3）第三阶段

经过一段时间的运行，觉得这样不行，不符合敏捷团队的特征，又决定把负责开发阶段测试的人员转到开发部门。良好的转变是：每个 Scrum Team 开始由一名资深测试工程师担任 Test Owner，负责制定测试策略和测试计划，以及协调开发测试与系统测试之间的安排。开发部门也开始对开发阶段的测试工程师进行开发能力的培养。

3. 单元测试的尝试

一开始单元测试的覆盖率几乎是 0，开发人员只管写代码和修复测试人员提交的缺陷。由于持续集成和测试前移的不成功，大家认为开发部门应该要求开发人员做单元测试，以代码覆盖率衡量单元测试的结果。开发也答应做，但是整整一年未见成效，原因是：忙，没有单元测试的经验和技能。

4. 测试能力更新的尝试

测试部门意识到自动化的重要性，但是部门只有 5% 的工程师负责自动化测试。经过层层申请，公司同意采取末位淘汰制替换 10% 的手工测试工程师。通过内部转岗、外部招聘，以及员工培训的多种方式，在一年之后自动化测试工程师的比例终于达到了 25%。团队开始搭建统一的自动化测试框架。自动化测试在 API 和 UI 测试的覆盖率终于看到明显提高，但是在整体需求覆盖率上也没有超过 30%，而且单元测试的缺失依然是硬伤，没有开发人员的参与，测试总在 UI 层折腾，当然是事倍功半。

从这个例子可以看出，这家公司的研发部门从传统测试转型到敏捷测试的过程中，并不清楚什么是真正的敏捷测试，而是摸着石头过河，不断尝试，每走一步都很艰难，而且走了不少弯路，最后还没有达到敏捷测试的彼岸，更不用说，产品的质量和测试的效率得到显著的提升。

什么是敏捷测试

那究竟什么是敏捷测试呢？可以肯定的是，“敏捷测试”既不是一种测试方法，也不是一种测试方式，而是为了适应敏捷开发而特别设计的一套完整的软件测试解决方案。这个解决方案应该能够支持持续交付，涵盖所需的、正确的价值观、思维方式、测试流程、一系列优秀的测试实践和更合适的测试环境、自动化测试框架和工具。敏捷测试可以采用目前已有的各种测试方式、方法，以及传统测试相比侧重有所不同，但主要的差别还是价值观、测试思维方式、流程和实践等。

敏捷测试应该具有“敏捷宣言”所倡导的价值观，为此我们可以按照“敏捷宣言”的格式，写出如下的“敏捷测试宣言”：

与开发协作测试胜于测试分工与测试工具
可运行的测试脚本胜于写在纸上的测试用例
从客户角度来理解测试需求胜于从已定义的需求来判定测试结果
基于上下文及时调整测试策略胜于遵守测试计划

敏捷测试强调“与开发协作”、“自动化测试”、“客户思维”和“动态的测试策略调整”更具有价值。

那我们回过头来，再看看上面的案例，至少第 1、2 条，他们没做到：测试人员没有得到足够的重视和尊重，开发和测试协作不够，而是：

有一段时间还存在独立的测试部门，“开发和测试变得更加泾渭分明，关系更紧张了”
“没有开发人员的参与，测试总在 UI 层折腾，当然是事倍功半”
“触发的自动化测试达到的覆盖率非常有限”
……

在转型初期，没有加强相关测试人员的培训，甚至都不知道敏捷模式对测试人员的要求，招进来的测试人员不合格。在执行过程中，缺乏测试策略，没有强调从客户的需求出发和动态地调整测试策略。

敏捷开发还有 12 项原则，上面案例中的团队有没有一条一条地、针对性地去对照着做？虽然敏捷开发 12 项原则似乎没有谈到测试，但测试是整个软件研发的一部分，自然也要遵守这些原则，适应敏捷开发的基本要求，例如：

如何支撑或协助“持续不断地、尽早交付有价值的软件”？
如何拥抱变化——“欣然面对需求变化，即使在开发后期也一样”
……

只有遵守这些原则，才能获得顺应敏捷开发的正确姿势，也只有采用敏捷开发的优秀实践，如测试驱动开发，并和开发紧密协作，测试才不会成为敏捷开发的“绊脚石”。

基于敏捷开发的 12 项原则，我制定了下列 8 项敏捷测试原则：

尽早和持续地开展测试
基于风险的测试策略是必须的
测试计划、设计和执行力求简单
能及时完成对软件质量全面评估
软件本身是测试研究和分析最主要的对象
在满足所要求的质量，测试进行得越快越好
对测试技术精益求精
不断反思，持续优化测试流程与设计

这些原则，在后面介绍的敏捷测试流程、实践中将会逐步地体现出来，到时再详细讲解。

由于篇幅有限，今天就谈到这里。如果觉得还不是很明白或者不过瘾，客官别急，后续我还会继续和你讨论敏捷测试的特点、敏捷测试思维方式和敏捷测试流程等，相信在看完或听完后面三讲的内容之后，就能更彻底地理解什么是敏捷测试。

最后，给你出一道思考题：上面我列了 8 条敏捷测试原则，你能否基于敏捷价值观和敏捷开发原则，再追加 1～4 条敏捷测试原则吗？欢迎留言讨论。

第02讲：通过案例全面比较传统测试与敏捷测试

这一讲的内容我想通过一个例子来全面比较一下传统测试与敏捷测试的区别，这个例子来自一本书——《凤凰项目：一个 IT 运维的传奇故事》。这是由美国的三位 DevOps 专家撰写的一本关于 IT 运维的小说。有人说，在 IT 咨询业，没读过这本书都不好意思跟人家谈 DevOps。

别急，我们这一讲的重点的确不是 DevOps，而是比较传统测试与敏捷测试，一千个人眼里有一千个哈姆雷特，尽管大家对 DevOps 有不同的理解，但是，你要知道，DevOps 其实是敏捷开发向 IT 运维的自然延伸，它的原则和实践与敏捷开发是一致的。从测试的角度看，这也是帮助我们理解敏捷测试的一本非常不错的书。

凤凰项目：一个 IT 运维的传奇故事

考虑到不是每个人都读过这本书，我先来介绍一下这本书讲了一个什么故事。

故事发生在美国一家历史悠久的汽车配件制造公司，有几年出现了经营困难，被竞争对手不断超越，公司经历了几轮裁员，但是情况还是没有好转。公司最大的竞争对手已经开始宣传它们可以提供客户在线定制汽车的业务，而公司的 IT 系统却满足不了这样的需求。为了扭转局面，公司把希望押在一个 IT 系统架构改造项目上——“凤凰项目”。取这个名字就有凤凰涅槃重生的意思，可见对于公司是至关重要的。

这个项目需要对公司线下门店、网上商店销售系统和后台订单处理系统进行改造，但是已经难产了两年，预算大大超支。这个项目涉及三个主要部门：研发、IT 运维和零售业务部门，测试是研发部门的下属部门。研发部门负责新系统的软件开发，测试部门负责测试，IT 运维部门负责搭建测试环境、生产环境以及新系统的部署，零售业务部门负责网上商店及线下门店的销售业务。

从以往合作来看，研发和运维部门关系紧张，经常互相甩锅。站在运维部门的角度看，开发部门每次都不考虑运维部署新系统需要花的时间，而且把项目时间都占用了，根本没有时间做测试。每次都是仓促上线部署，软件产品不稳定，质量很差，用户体验当然也不好。IT 部门甚至不得不靠每隔一小时重启一次服务器让系统得以运行。

针对凤凰项目，运维部门迟迟拿不到关于产品和测试系统配置的具体技术参数，和需要的基础架构信息。而从开发的角度看，运维部门很少派人参加项目会议，从 IT 那儿拿到信息反馈往往要等上好几个星期，测试环境和生产环境部署需要的时间太长，而且经常不一致，导致上线后各种问题。

可以说，凤凰项目是一个特别典型的 IT 项目，基本上囊括了现实中所有的项目问题：项目延期，代码质量低下，开发 / 测试 / 生产环境不一致，工期不考虑测试和部署，没时间测试，上线后每天救火，部门间不合作，出了问题互相指责，等等。

故事的主人公比尔本来是一名 IT 总监，临危受命成为负责整个 IT 运维的副总裁。上任之初他可以说是焦头烂额，到处扑火，还经历了一次愤然辞职。幸运的是，在困难之际出现了一位高人——艾瑞克，他有可能成为公司董事会的成员，精通精益生产，练就独门绝技“三步工作法”。在艾瑞克的传授指点下，比尔奇迹般的完成了任务，不仅顺利地完成了 IT 系统的改造任务，而且引入了新的工作模式，让 IT 运维部门、开发部门、测试部门、业务部门协同工作实现了持续构建、持续交付、持续反馈，也帮助公司实现了销售额大增，顺利度过难关。

三步工作法

让我们先来看看这神奇的“三步工作法”。

第一步，流动原则，建立开发到 IT 运维的快速工作流。减小批量大小，通过内建质量杜绝向下游传递缺陷，缩短代码从变更到上线所需的时间，同时还提高服务的质量和可靠性。

第二步，反馈原则，在技术价值流的每个阶段，包括产品管理、开发、测试、信息安全和运维，在所有工作执行的过程中，建立快速的反馈闭环。这中间包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更，避免返工。

第三步，持续学习与实验原则，建立学习型组织和质量文化，既鼓励探索、反复实践，又能够把个人经验转化为组织的财富。

简单的说就是持续交付、持续反馈、持续学习，是不是和敏捷很相似？所以说，精益、敏捷、DevOps，本质上是异曲同工。

这本书里给出的目标是在生产环境一天完成十个部署，在现在来看是一个很低的目标，但是要知道这本书是 2013 年出版的，在当时，大部分 IT 部门是每季度甚至每年完成一个部署。你可能认为故事里描述的项目改造后的情况太理想了，不太可能在短短几个月时间里发生这么大的变化。故事当然是经过艺术加工的，是生活的浓缩和提炼，而且现实中很难遇到像艾瑞克这样的高人，多数情况下还得靠自救和不断试错。

凤凰项目改造前后对比

那么现在，让我们来总结一下凤凰项目改造前后和测试有关的变化，基于变化，相信你能体会到传统测试与敏捷测试之区别。

传统测试和敏捷测试的区别

最后，我们再对传统测试和敏捷测试的区别进行一个系统性的总结。

（1）传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。

（2）传统测试具有明显的阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告，一个阶段一个阶段往前推进，但敏捷测试更强调持续测试、持续的质量反馈，没有明确的阶段性界限。

（3）传统测试强调测试的计划性，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。

（4）传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。

（5）传统测试关注测试文档，包括测试计划、测试用例、缺陷报告和测试报告等，要求严格遵守文档模板，强调测试文档评审的流程与执行等，而敏捷测试更关注产品本身，关注可以交付的客户价值。敏捷测试中，强调面对面的沟通、协作，强调持续质量反馈、缺陷预防。

（6）传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

最后，给你出一道思考题：基于凤凰项目改造前后对比的那张表，是不是说明他们实现了从传统测试到敏捷测试的成功转型？是否可以更进一步去看看这本书，理解他们为什么能转型成功，欢迎留言讨论。