下载掌阅APP，畅读海量书库
立即打开
上面讨论了传统的软件测试过程，下面就简单介绍一下敏捷测试过程，正文中还会有更多的讨论。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续地对软件产品质量进行反馈。简单地说，在敏捷开发流程中，阶段性不够明显，持续测试和持续质量反馈的特征明显，这可以通过图0-4来描述。
图0-4 敏捷测试过程示意图
如果再具体一些，使流程更具可操作性，需要以敏捷Scrum为例，来介绍敏捷测试的流程。先看看Scrum流程，从图0-5中可以看出，除了最后“验收测试”阶段，其他过程似乎没有显著的测试特征，但隐含的测试需求和特征还是存在的。
（1）Product Backlog（需求定义阶段），在定义用户需求时测试要做什么？测试需要考虑客户的价值大小（优先级）、工作量基本估算之外，需要认真研究与产品相关的用户的行为模式（如Behavior Driven Development，BDD），产品的质量需求，哪些质量特性是我们需要考虑的？有哪些竞争产品？这些竞争产品有什么特点（优点、缺点等）？
图0-5 Scrum流程示意图
（2）Sprint Backlog（阶段性任务划分和安排），这时候需要明确具体要实现的功能特性和任务，作为测试，这时候要特别关注“Definition of Done”，即每项任务结束的要求——即任务完成的验收标准，特别是功能特性的设计和代码实现的验收标准。ATDD（使用验收测试驱动开发）的关键一步也体现在这里，在设计、写代码之前，就要将验收标准确定下来。一方面符合测试驱动开发思想，最初就要把事情做对，预防缺陷；另一方面持续测试和验收测试的依据也清楚了，可以快速做出测试通过与否的判断。
（3）在每个迭代（Sprint）实施阶段，主要完成Sprint Backlog所定义的任务，这时除了测试驱动开发（TDD）或单元测试之外，应该进行持续集成测试或通常所说的BVT（Build Verification Test）。而且开发人员在设计、写代码时都会认真考虑每一组件或每一代码块都具有可测试性，因为测试任务可能由他们自己来完成。如果有专职的测试人员角色，一方面可以完善单元测试、集成测试框架，协助开发人员进行单元测试；另一方面可以按照针对新实现的功能特性进行更多的探索式测试，同时开发验收测试的脚本。如果没有专职的测试人员角色，这些事情也是要完成的，只是由整个团队共同完成。虽没有工种的分工，但也存在任务的分工。
（4）验收测试可以由自动化测试工具完成，但一般情况下，不可能做到百分之百的自动化测试。例如易用性测试就很难由工具完成。即使对性能测试，是由工具完成，但还需要人来设计测试场景，包括关键业务选择、负载模式等。敏捷的验收测试和传统的验收测试不同，侧重对“Definition of Done”的验证，但基本的思想和传统开发是一致的，任何没有经过验证的产品特性是不能直接发布出去的。