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

　　1、传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理。而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。

　　2、传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，模糊了阶段性，而且介入更早。

　　3、传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。

　　4、传统测试更关注bug，围绕bug开展一系列的活动，如bug跟踪、度量、分析、报告、质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，bug修复的成本很低。

　　5、传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响。但敏捷测试的基础就是自动化测试，敏捷测试需要有良好的自动化测试手段支撑的快速测试。

　　6、传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试中，测试人员需要参与全部开发活动，需要参与整个项目组的所有会议，能够发挥更大的作用。

敏捷测试中的关键过程

　　在一个sprint中，测试人员的工作内容主要分为五个部分：user story分析、测试用例设计开发、测试执行和分析、测试持续集成、回归测试。这五个部分的工作均要持续到sprint结束，只是启动时刻有早有晚，具体如下图所示

user story分析工作：敏捷测试是不断确认客户的需求得以圆满实现，因此对用户需求的分析、理解需要一直持续下去，发现有偏差及时纠正，及时设置合理的验收点、测试项。

Testcase Develop工作：设计测试用例，完成测试代码的开发、测试数据的准备，并及时与开发人员沟通软件接口，确保测试代码能够成功驱动业务代码。

Testing & Analysing工作：执行测试，统计测试覆盖率，分析测试结果，若发现bug，及时沟通，并协助定位bug。

Continuous Integration工作：将测试代码进行集成，以保证当前功能若被后续集成代码污染是能够及时得到报警，不断地完善软件产品的功能基线。

RegressionTesting工作：在完成全部user story后，对所有代码进行完整的回归测试，对所有bug修复情况进行确认。

敏捷测试对测试人员的要求

　　优秀的敏捷开发过程越来越重视测试人员，测试人员在其中所起到的作用越来越大，相应的对测试人员的要求就越来越高。一个合格的敏捷测试角色，应当具备以下素质：

1、良好的沟通能力

　　测试人员全程参与所有开发活动，需要与产品、开发、项目经理设置用户进行频繁的沟通，必须具备良好的沟通能力。

2、换位思考能力

　　一方面需要站在产品、用户的角度，考虑产品的功能、性能、易用性等，一方面需要站在开发的角度，思考软件技术方案的可行性，实现的难度、合理性、可测性等，充分考虑到各种情况。

3、掌握多种的测试手段

　　面对不断变化的需求，足够的测试手段储备，是从容应对变化的本钱。

4、一定的开发技能

　　在敏捷开发团队成长到一定程度后，测试与开发角色的界限会变得模糊。在初始阶段，测试人员也应当具备完成单元测试代码编写的能力。

5、拥抱变化

　　“唯一不变的就是变化”，所以，需求的变动是必然的，每次的需求的调整都是将产品开发推向更正确的方向。在接受变化的同时，测试人员应该积极的反馈可能的设计缺陷和错误。

自动化测试与手工测试

　　轻量级增量开发、快速迭代的特点，使得测试人员需要重点关注两个方面的软件质量，一是新功能的需求符合性，二是原有功能的稳定性、可靠性。通常，对新功能进行灵活性高的手工测试，而对原有功能进行自动化回归测试是目前看来最合理的一种手工测试与自动化测试的分工。

　　敏捷功能测试= 新特性的手工测试（针对user story验证） + 原有功能的自动化测试（回归测试）。

总结

　　测试人员是敏捷团队非常重要的一环，测试人员的成长对敏捷团队非常重要。从传统测试工作转入敏捷测试工作必然会遇到很多不适，但是只要坚持对敏捷的学习和各种新工具的开发使用，一切都能够适应下来。

　　谁都知道，变化，才是永远不变的，敏捷则是我们应对变化的武器。