敏捷测试2：敏捷测试对比传统测试

作者从以下六个方面对比了传统测试和敏捷测试，我们一起来学习一下：

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

不太能想象没有测试人员角色的敏捷team是一个什么样的team。每一个人有能力将需求中的一部分实现出来，并能通过自动化工具自行检验？那各个模块之间的交互性有问题了，会不会漏掉？全民测试，反过来会不会是没有人能对质量负责？

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

持续测试，这个好！软件测试中发现的大多数bug，都是在新版本delivery出来之后，由新增的代码或者改动的代码引起的。如果能在每次版本迭代的时候，由自动化工具将代码检测一遍，大多数bug其实就已经被抓到了。

这应该就是我在（1）里面提出的问题的答案。团队成员每个人都可以实现一部分功能，同时也为自己实现的这一部分功能写相应的自动化测试脚本。系统架构工程师则负责系统测试的自动化测试实现。全员coding，全员测试。

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

世界上唯一不变的就是变化。快速迭代的软件，就是为了适应变化，来吧！

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

因为敏捷测试的敏捷特性，注定了系统在开发过程中的变化，一周一个样，甚至一天一个样。客户也许也不清楚他想要的是什么样的产品，我们先做出来一个，让他看看，确认了之后，再继续。验证-》确认》再验证-》再确认，直到产品变成客户最想要的样子。

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

没有测试计划测试文档，却最终交付了没有bug的产品，这才是真正敏捷。

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

用户最终想要的产品，是能抗住压力的产品。想要这样的产品，就得在提交产品之前，把代码构建出来的各种可能性，都遍历测到。遍历这种活，交给机器自动化完成更靠谱。

从传统测试到敏捷测试，每个团队都要经历一段不好熬的时期。开发和测试，都得变化。开发想怎么测，测试也得想怎么开发。