软件测试学习 之 敏捷测试与传统测试

敏捷测试的定义

埃森哲对敏捷测试的定义（与维基百科的定义基本一致）大概如下：

敏捷测试是遵从敏捷软件开发原则的一种测试实践。

敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。因此测试变成了整个软件开发过程中非常重要的环节。敏捷测试包含了具备专业技能测试人员在内的跨职能团队，这使得这种组合式的团队能更好的交付价值，满足项目的业务、质量和进度目标。

从定义中可以看出敏捷测试主要的核心内涵有三个：

1. 是遵从敏捷开发的原则（强调遵守）

2. 测试被包含在整体开发流程中（强调融合）

3. 跨职能团队（强调协作）

除此之外，敏捷测试用到的基本测试方法和技术与传统测试是一样的。

敏捷测试的特点

既然敏捷测试属于一种新的测试实践，那么到底它有什么的特点呢？我用“四个更”来归纳：

1. 更强的协作：敏捷开发人员和测试人员工作得更加紧密，喜欢更直接的沟通方式而不是通过邮件文档这种一来一回反反复复的沟通模式；
2. 更短的周期：需求验证或测试的时间不再是按月来计算，而是按天甚至按小时计算。用户验收测试在每个sprint的结尾都会进行；
3. 更灵活的计划：敏捷测试也需要拥抱变化，测试计划不再是一成不变的文档，而会根据业务价值交付的顺序进行灵活的调整；
4. 更高效的自动化：相比传统测试，自动化在敏捷测试中扮演了极其重要的角色。它是实现快速交付确保质量的一种非常有效的手段

为什么要敏捷测试

一个很直接的原因是如果整个项目都在采用敏捷开发模式，比如两周一个迭代，你还在跟项目谈传统的各个测试阶段，就好像两个不同转速的齿轮，根本无法结合。试问，两周时间能完成得了所有的测试阶段吗？所以必须要有新的测试实践来取代原有的模式，才能更好的适应敏捷小步快跑的特点。当然，除了适应开发的节奏外，敏捷测试还是有其特有的价值：

• 缩短价值交付周期

通过采用敏捷测试这种模式，可以契合整个敏捷开发周期，使得整个敏捷开发按照相同而快速的迭代速率和周期交付，让最终用户尽快获取到业务价值；

• 更早发现测试风险

敏捷测试使得测试人员尽早开始进行测试，尽早的发现系统缺陷或存在的问题，避免所有的问题都堆积在最后的测试阶段形成“Big-bang”的结果，降低整体系统风险；

• 强调质量属于大家

质量是构建出来的，而不是测出来的。敏捷测试一直强调质量属于每一个人的责任，除了测试之外，开发、产品经理等都有义务对自己的交付件质量负责，这样才能确保项目的整体质量；

• 化繁为简节省成本

敏捷测试没有要求需要详细的测试计划和测试文档，也没有定义繁复的测试流程及缺陷流程，这种轻量级的管理模式为测试人员减少不必要的负担，节省了工作量及成本。

敏捷测试vs传统测试

那么敏捷测试和我们熟悉的传统测试比，他们到底有什么样的区别呢？我整理了如下对比表：

 

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

敏捷测试与传统测试的区别，并不是敏捷测试测得更快，也不是用的时间更少，更不是将测试的范围缩小，或者将质量降低来减少测试任务，而是在计划、阶段划分、文档、记录、沟通等方面的侧重不同。

传统测试	敏捷测试
传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理	敏捷测试强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化
传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，	敏捷测试更强调持续测试、持续的质量反馈，模糊了阶段性，而且介入更早。
传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任	敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪
传统测试更关注bug，围绕bug开展一系列的活动，如bug跟踪、度量、分析、报告、质量检查等	敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，bug修复的成本很低
传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响	敏捷测试的基础就是自动化测试，敏捷测试需要有良好的自动化测试手段支撑的快速测试
统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚	敏捷测试中，测试人员需要参与全部开发活动，需要参与整个项目组的所有会议，能够发挥更大的作用

作者：我也讨厌自己
链接：https://www.jianshu.com/p/7890b92cb2ef
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。