什么是敏捷测试呢？敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少

测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：

究竟什么是敏捷测试？

敏捷测试有哪些流程改进？

测试人员如何面对敏捷测试的挑战？

在敏捷测试中如何制定相应的测试策略？

   什么是敏捷测试

    假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应

该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增

加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试

则依赖于版本验证（BVT）测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对

软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，

                                      

    敏捷测试流程的优化

    在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用一周时间，也就是每周发布一个新版本。开发周期短，功能不断累加，给软件测试带来

很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的测试计划书，然后再建立每个功能任务的计划而且需

要和项目经理、并和测试团队讨论，最终得到大家的认可才能通过，仅测试计划经过“起草、评审和确认”一个完整的周期就需要一周的时间。在敏捷方法

中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。

    在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（RDMS系统）中。在敏捷测试中，可能不需要

测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于干其他的工作。原有测试规范还要求进行多轮回归

测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效。

                        

  在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给项目经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：

1、测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。

2、在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和项目经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

  新功能的测试和回归测试策略

  测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：

• 不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。

• 持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。

• 实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。

• 基于经验，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。

  回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是

一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：

• 通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。

• 基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。

• 持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。

  测试人员在敏捷测试中的价值

  在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？

• 在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。

• 测试人员不仅扮演“用户代表”角色，而且通过需求讨论、功能演示等各种活动及时地提供质量反馈，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。

• 测试人员即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。

• 在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。

• 产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。

• 一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。

  理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发测试的效率和质量会有进一步的提高。

什么是敏捷测试呢？敏捷测试当然不能简单地理解为测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少

测试任务。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：

究竟什么是敏捷测试？

敏捷测试有哪些流程改进？

测试人员如何面对敏捷测试的挑战？

在敏捷测试中如何制定相应的测试策略？

   什么是敏捷测试

    假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。敏捷测试应

该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增

加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试

则依赖于版本验证（BVT）测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对

软件产品质量进行反馈。简单地说，敏捷测试就是持续地对软件质量问题进行及时地反馈，

                                      

    敏捷测试流程的优化

    在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用一周时间，也就是每周发布一个新版本。开发周期短，功能不断累加，给软件测试带来

很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范明确规定，首先要建立项目的测试计划书，然后再建立每个功能任务的计划而且需

要和项目经理、并和测试团队讨论，最终得到大家的认可才能通过，仅测试计划经过“起草、评审和确认”一个完整的周期就需要一周的时间。在敏捷方法

中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。

    在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（RDMS系统）中。在敏捷测试中，可能不需要

测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于干其他的工作。原有测试规范还要求进行多轮回归

测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效。

                        

  在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给项目经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：

1、测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。

2、在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和项目经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

  新功能的测试和回归测试策略

  测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有：

• 不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。

• 持续地进行验证，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。

• 实施端到端（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。

• 基于经验，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。

  回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是

一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：

• 通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。

• 基于风险和操作面分析来减少回归测试的范围，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。

• 持续测试的过程，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。

  测试人员在敏捷测试中的价值

  在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？

• 在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。

• 测试人员不仅扮演“用户代表”角色，而且通过需求讨论、功能演示等各种活动及时地提供质量反馈，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。

• 测试人员即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。

• 在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块或组件），集成测试和端到端（End-to-End）测试显得更为重要，测试人员在这些测试上能发挥更大的作用。

• 产品发布前，验收测试和回归测试依然不可缺少，这更是测试人员的用武之地。

• 一个迭代周期结束后，对缺陷根本原因进行分析、总结规律，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。

  理想情况下，测试人员掌握设计模式、具有很好的编程能力，可以和开发人员进行角色互换。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发测试的效率和质量会有进一步的提高。