在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库(在线管理系统)中。在敏捷测试中，可能不需要测试用例，而是针对Use Case或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合这些考虑，敏捷测试的流程简单有效，如图2所示。

图2 敏捷测试流程简要图

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

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

　　参与代码复审(Code Review)，并适当辅助开发人员进行单元测试。

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

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

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

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

　　持续地进行验证，一旦某块新代码完成(Code Drop)，开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。

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

　　阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。

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

　　回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：

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

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

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