1.视频演讲
- 让测试也敏捷起来
- 颠覆者生存：互联网产品测试观点
- 敏捷测试实践
- 什么是敏捷软件测试
【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。
确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量，或是敏捷开发实践中的“测试驱动开发”，“行为驱动开发”，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。
既然是这样，为什么我们还要在这个专栏中专门来讨论“敏捷软件测试”？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的“下一个阶段”，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。
那么，到底什么是敏捷软件测试？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。
敏捷软件测试是建立在敏捷核心价值观的基础上，为了更生动的描述其与传统软件测试的区别，本人从自己的实践经验出发，尝试给出包含了本人认为包含了敏捷测试关键要素的“敏捷测试检查表”：
项目 | 检查点 | 注释 |
团队 |
|
|
反馈 |
|
|
质量文化 |
|
|
开发测试 |
|
|
检查表提到了“团队”、“反馈”、“质量文化”和“开发测试”四个方面的内容，在本人看来，这四个方面体现的就是敏捷软件测试与传统软件测试的最大的不同。传统软件测试关注的是通过尽可能完备的“覆盖”去发现尽可能多的问题，把测试和开发当成是两个独立的过程，测试是对开发阶段产生成果的验证。而敏捷软件测试则建立了一种不同的质量文化：测试的目的是为了保证产品快速发布，也就是对生产率本身的提高。基于“验证”的出发点必然会要求测试与开发的独立，以及尽可能“客观”和“完备”的度量产品质量；而基于“生产率”的出发点则要求建立敏捷的团队，要求测试与开发尽可能紧密，要求建立具有高度可测试性的软件，以及基于这些的高度自动化测试。
在检查表列出的所有项目中，“质量文化”是基础，“团队”是敏捷软件测试得以实施的条件，“反馈”和“开发测试”则是敏捷软件测试的具体方法。当然，你可以可以从敏捷的核心价值观来阶段这些项目：“团队”关注的是沟通与尊重；“反馈”直接对应于反馈；“质量文化”基于勇气（承担质量责任的勇气）与尊重；而“开发测试”则是反馈与简单的具体体现。
另一个在本文最初提出来的问题是：“敏捷软件开发还需要测试工程师吗？”，对这个问题，业界有不同的观点。有人认为需要，因为总有一些是需要测试工程师的技能完成的工作；当然，也有人认为不需要，因为敏捷开发中的测试注重开发测试与自动化测试，开发工程师就可以自己搞定与测试相关的工作。在实践中，那些大规模实践敏捷开发的公司（例如Google），倾向于在组织中设置数量较少的测试工程师，在项目中分配较少的测试资源，甚至对某些项目，完全不使用测试工程师。
就我的个人实践经验，对大部分的项目，尤其是为明确的客户开发的项目，需要在敏捷开发团队中设置专职的测试工程师，因为：
- 测试与开发具有不同的思维方式：测试更注重全面的验证和检查一个系统，而开发工程师往往很难在大的范围内建立这样的思维方式。因此，无论是从系统的层面验证产品，或是从应用系统的角度发现值得测试和验证的点（access point），专职的测试工程师都更有效。
- 专职的测试工程师能够更关注于测试基础，建立测试需要的基础架构：由于测试工程师具有更好的对测试的理解，通常他们能够更多的考虑测试的需求而开发适合项目的测试基础架构（自动化测试框架），而开发工程师可以使用这些框架来建立面向功能或代码的测试。
但是，不得不说的是，敏捷开发对开发和测试工程师都提出了更要的要求，尤其是对测试工程师而言，传统的只能“精确模拟用户操作”的测试工程师，因为不能为产品带来生产率的提升，在敏捷开发的团队中，很难有所作为。在本专栏的后续文章中，我们会进一步讨论测试工程师在敏捷软件开发中的工作和任务。
- 自动化测试——敏捷测试的基石
在专栏的上一篇文章《什么是敏捷测试》中，我们介绍了敏捷测试的主要特点。作为被冠以“敏捷”名称的测试，敏捷测试同样以“快”为目标。在敏捷测试中，“快”有三个方面的含义：
- 团队能够通过测试快速获知系统当前所处的状态，了解距离可工作的软件还有多远；
- 能够在一个迭代周期中快速完成回归测试和对新功能的测试；
- 开发工程师能够从持续的测试中得到快速的关于提交代码反馈。
简而言之，敏捷测试要求测试能够测试在“短的时间间隔内持续发生”且能够在“短时间内完成”。考虑到纯粹的依赖人工测试基本不可能达到“短的时间间隔内持续发生”和“短时间内完成”这两个目标，而自动化测试在执行效率方面具有天然的优势，在敏捷测试中使用自动化测试技术应该是自然而然的选择。
考察敏捷开发中的一个迭代周期：
- 在迭代周期开始的时候，团队与客户一起定义本迭代周期内需要完成的功能；
- 团队建立验收测试验证标准；
- 开发工程师开始实现新功能，使用TDD为产品建立安全网，使用持续集成尽可能保证每一次代码提交不引入新的缺陷；
- 所有新功能被添加后，在RC上运行回归测试保证原有功能的正确性；针对新功能运行测试保证新功能的正确性；
- 执行验收测试验证系统是否达到可交付的标准。
除1和2外，剩下的3个项目都与测试执行密切相关，如果依靠手工测试来进行这些项目，毫无疑问，测试会成为整个敏捷开发的瓶颈。而如果把这些项目中的测试建立在合适的自动化测试基础上的话，测试就可以和开发一起敏捷起来。从这个角度来说，把自动化测试描述成“敏捷测试的基石”毫不夸张。
自动化测试并不是新鲜事物。从80年代起，对软件自动化测试的研究就从来没有停止过，而自动化测试工具也一直是测试工程师津津乐道的话题。IBM、HP、Borland等许多提供软件开发解决方案的公司都拥有完整的测试解决方案；在开源社区，自动化测试工具的种类也不下于100多种。这么说起来，是不是只要选择了合适的工具在测试中进行部署，就能快速的建立起敏捷测试需要的自动化测试基础了呢？根据美国某组织在2005年开展的一项非正式的调查，在所有参与被调查的200多个自动化测试项目中，完全成功的只有30多个，不到20%；完全失败的却达到100多个，占到了50%的比例。
自动化测试项目为什么会失败？根据调查，“不合适的自动化测试目标”与“从自动化测试中无法获得收益”是项目失败的主要原因。希望把自动化测试定义为“完全替代手工操作”、期望仅仅“在UI层建立自动化测试”都不是合适的自动化测试目标；尤其是“在UI层建立自动化测试”这个目标一定会带来无法从自动化测试中获得收益的后果。
UI自动化测试是自动化测试领域中较早被研究的，其主要出发点是使用工具和脚本驱动应用操作，依靠工具对UI层的元素属性进行验证。现有的大部分商业测试工具，如IBM Functional Tester、HP QTP等都属于这一类工具。从好的方面来说，UI自动化测试相对其他自动化测试更接近真实用户；但不得不说的是，UI自动化测试的高昂的投入往往是组织不能持续进行自动化测试原因。
我参与第一个自动化测试项目的时间是在12年前。在那些惨痛的日子里，我会痛苦地看着我苦心建立的自动化测试脚本以高达50%的失败率运行，然后再花上2个星期更痛苦的调试和修复自动化测试脚本的时间。随着脚本数量的增加，我的痛苦如日俱增。最后，我不得不放弃了对这些昂贵的自动化测试脚本的维护，转向我情感上不情愿，理智上却不得不做的选择：重回手工测试。
12年前的例子并不是我唯一经历的UI自动化测试的痛苦，实际上，在10多年的软件测试生涯中，这样的不愉快各种情况下一再重复。下表是前年我们的某个完全依赖于UI自动化测试项目中的自动化测试投入产出比较表。
自动化测试覆盖率 | 功能点数量 | 测试用例数量 （自动化/全部） | 自动化测试执行 失败率（平均） | 每个测试周期的 人员投入 |
0% | 65 | 0/182 | - | 2人周 |
20% | 83 | 41/210 | 10% | 1.5人周 |
44% | 110 | 131/302 | 22% | 2人周 |
61% | 120 | 213/350 | 43% | 3.5人周 |
UI自动化测试带来痛苦的主要根源在于UI本身的不稳定性。由于UI是应用与用户的直接交互界面，用户的大量需求都直接对应在UI本身的改变上，这就导致了UI本身的不稳定，建立在UI上的自动化测试也因此不稳定。当然，除了不稳定外，UI自动化测试带来的测试环境的需求也是导致UI自动化测试开销剧增的原因之一；另外，UI自动化测试本身并不能很好的帮助定位缺陷，对开发工程师而言，其在反馈上的价值远不如单元测试。
除了UI自动化测试外，在敏捷测试中其他可用的自动化测试还包括单元测试与接口测试（或者叫服务测试）。下图是敏捷开发中被广泛认可的自动化测试产出金字塔，在相同投入的情况下，单元或是代码级测试能带来最大的收益，而UI层面的收益最小。
自动化测试所涉及的技术非常多，例如在单元测试中经常需要使用到的Mock技术，基于针对不同语言而不同的解依赖技术等；在接口测试层面，更是需要根据接口本身的类型和特点确定具体的测试技术；在UI层，根据应用的不同（桌面应用，Web应用，嵌入式应用等），自动化测试技术也存在巨大的差异。
关于各种自动化测试技术的讨论，本文在后续文章中会选择其中的一些进行重点介绍，本文则主要介绍Diff技术这种与传统的“比较预期输出与实际输出”略有不同的自动化测试技术。
Diff技术，顾名思义，其主要关心的是“不同”。以搜索引擎产品的测试为例：以同一个关键字在搜索引擎上进行多次重复测试（查询），随着时间段的变化，搜索引擎的索引数据也在发生变化，即使对同一个关键字，也不太可能在每次测试时给出一个所谓的“预期结果”。
怎样才能在这种情况下开展测试？一种可行的技术是就是“Diff”技术。下图展示了Diff方法的应用。
简单来说，Diff方法的应用包括以下步骤：
- 设置两个待比较的版本实例（通常是相邻的两个版本，例如RC和上一个产品版本），两个版本具有相同的数据基础或后端环境；
- 使用发送模块同时向两个版本发送相同请求；
- 比较模块收集两个实例的输出并对其进行比较；
- 比较结果输出为Diff报告。
Diff报告体现的是两个实例之间的不同，不同并非一定是由于缺陷导致，因此Diff报告需要通过人工审阅，判断报告中“不一致”的原因，决定后续步骤——后续步骤通常包括创建一个缺陷，安排探索性测试，或是据此确定回归测试范围等。
Diff测试技术可以在多个测试层面上被应用。例如，在UI层面上，可以通过图片Diff的方式（比较两个版本在相同输入情况下的UI截图）发现应用界面上的变化；对Web应用来说，也可以以文本Diff的方法比较两个实例输出的HTML文档，或是特定页面元素；在接口层面上，可以比较在两个实例上，相同的UI操作导致的前后端通讯的不同……
Diff技术甚至可以在测试过程中帮助确定测试范围。例如，对一个RC的全面的Diff发现，所有100个功能点中，有80个功能点的Diff结果与上一个版本没有任何差异，有20个功能点的Diff结果与上一个版本存在差异。基于这个结果，我们可以很容易的将存在差异的20个功能点作为RC测试的重点——个人认为，与依靠代码分析确定测试范围相比，这种方式直观有效得多。
当然，在实际项目中应用Diff技术也会遇到很多挑战，如何尽量消除Diff结果中的“噪声”是一个关键问题。以应用基于图片的Diff技术为例，如何消除图片比较结果中的噪声就是一个既需要技术手段（通过图片比较算法）也需要非技术手段（建立针对每个页面的mask）的话题。
PS：
第四届中国软件质量年会资料下载
http://www.cnsq.org.cn/download.html
接触敏感测试也是到google上海后，原先的工作即是传统意义的测试，涉及到很多业务类的东西，自然项目上多会采用传统的瀑布型(以后会写篇对不同类型项目讨论下项目的人员组织结构)；
自己对敏捷测试的一些理解：
1.关键还是人——测试人
当我加入财经搜索项目时，并没有像我在newegg那样，新进人员的会有完整的文档甚至是视频，整个的测试流程需要测试人自己来搭建，由于开发测试比是10比1，项目交给你后，你就是为这个项目的质量工作提供一条龙服务，那么这个测试人非常重要；google的项目/产品模式都是从下往上的推动，强调个人的主动性，这个可以从gmail、chrome看出，gmail完全是20%时间做出来的项目
2.更加强调沟通
这个和过去强调的项目人员角色清晰化格格不入，过去的项目人员各自负责一块功能，埋头苦干，沟通仅仅限于任务，而对于产品的前景、项目的发展往往抛给项目经理，因此一直以来IT人员给人的印象总是默默勤劳的，而沟通的事情都是项目经理或测试组长的事情；
而在敏捷测试里，由于资源的分配，可能一个项目就只有一个测试人员，那么他就必须和开发人员、技术经理、产品经理进行广泛的沟通，推动他们对质量的意识，更早的开始测试；甚至可以参与到产品需求及产品发展方向的讨论；所以整个团队的人员都需要有良好的沟通能力，也为后面的文档轻量化提供了条件
3.更加强调个人能力
仅仅是黑盒测试的能力远远不够，编程能力是必须的，搭建自动化测试平台，性能测试，建立质量的metrics或dashboard提供给开发团队让他们随时关注产品的质量；甚至可以参与建立单元测试的框架，推动开发单元测试的覆盖率；google里有一个很好的项目质量认证级别，每次的升级也是对整个团队的鼓舞；同样的开发人员的能力也有新要求，上面文章提到了代码的可测试性以及Cbuild(continue build粒度比daily build更小)
4.更加灵活自由
因为是敏捷，所以不再像CMMI那样强调流程化，每个节点都需要有对应文档， 测试计划更简洁——one page test plan，发布更频繁——bi-weekly push到weekly push，那么对应的测试用例更粒化：回归测试用例集可以包括基本手工测试用例集、自动化测试用例集、完整测试用例集(这个往往只有在整个项目改版的时候需要)；而对于新功能，前面文章中提到了diff工具，对新功能先有个评估，之后再开始测试，所谓磨刀不误砍材工
5.不具有广泛推广的意义
可能很多人看到google敏捷测试的经验，会跃跃欲试的想在自己公司推广，特别是目前web市场的火热，更多的web项目看起来很适合使用敏捷测试，但是在你考虑开始推广敏捷测试时，请先注意以下几点
a.你的项目/产品是以功能为主还是业务为主，如果是业务驱动型，可能测试人员数量就不会小，那么在测试的同时可能更会关注业务上的内容
b.你的开发/测试人员个人能力是否足够强，能力上需要有个评估，例如测试人员coding的能力，开发人员对质量的认知度，否则无法“快”
c.人员备份问题，这里说到的敏捷团队人员都比较小，肯定不超过10人(实际可能只有5，6个人员，产品经理和Engineer manager是共享的，负责多个产品)，那么团队是否稳定，因为很多公司不可能提供像google那样的福利待遇，一旦人员流失，由于文档轻量化，接替人员不能在短期内接手，项目进度会受到影响
所以虽然google在web测试或敏捷测试上有很丰富的经验，但是你还需要参考传统意义上的测试优势(微软在客户端的测试经验就非常强)，具体结合你的项目来确定测试流程，自从手机智能化后，很多公司已经开始参与移动手机项目，那么手机上的测试模式又可能会有新的发展(希望熟悉这方面的朋友来分享经验)
