敏捷测试 第2讲 敏捷测试流程

Scrum 模式下的测试流程

Scrum 模式下的敏捷测试流程有 7 项主要活动——测试需求分析与定义、测试计划、测试设计、BVT（Build Verification Test）、持续测试、版本验收测试、测试交付与反思等，但不能理解为 7 个阶段，许多活动都是并行的，包括计划、设计都是贯穿整个迭代。

（1）测试需求分析与定义，对用户故事（User Story，US）、Epic 等进行评审，为每一个用户故事建立验收标准，确保它具有可测试性，并从业务需求出发，了解要做哪些测试，初步界定测试的范围等。

（2）测试计划，这里指的是当前迭代的测试计划，包括进一步明确具体的业务要求和质量要求、制定测试目标、明确测试范围和测试项、分解测试任务、识别出测试风险并制定测试策略等。计划是一个覆盖整个迭代的过程，通常用 Planning，也就是前面所说的，要基于上下文不断调整或优化测试计划，只是在 Sprint Planning 时先写出初步的测试计划，按这计划开始执行后续的测试过程。

（3）测试设计，这里强调的是大颗粒度或粗颗粒度的测试设计，包括测试模型设计，如事件流图、状态图等的设计，而不是指测试用例的设计。

（4）BVT，版本构建（Build）的验证测试，即只要有版本构建，不管是每日构建，还是代码提交触发的软件版本构建，都需要对软件版本进行自动验证，因为只有高成功率的持续集成才有意义。这里的 BVT，不仅包含传统的冒烟测试，即对当前软件版本实现的基本功能进行测试，而且包括对代码进行扫描，检查代码的规范性、安全性等，即通常所说的代码静态分析。

（5）持续测试，是迭代中主要的活动，根据前面案例所讲的，测试的问题常常出在这里，让测试成为持续交付的瓶颈，就是没能做到持续测试。这里包括设计评审、单元测试、用户故事实现的验证、集成测试等，包含持续的新功能测试和持续的回归测试，也包括性能测试、安全性测试、兼容性测试等专项测试。

（6）版本验收测试，敏捷中的验收测试通常是指对用户故事验收标准的验证，但是我觉得还得在交付前需要增加这样一个环节——将所有的用户故事串起来进行相对全面的测试。比如，从业务流程出发，完成端到端（End-to-End，E2E）的测试，相当于许多团队在 Beta 环境、准生产环境上进行一轮完整的测试或试用一段时间。因为之前的测试具有一定的局限性，一个单元一个单元的测、一个故事一个故事的验证，比较零碎，缺少系统、全面的测试，而且代码一直在修改。

（7）测试交付与反思，即使通过验收测试，并不意味着测试结束了，就像 Scrum 迭代后期还有两个会议：迭代评审会和反思会。虽然测试报告、缺陷分析等可以自动完成，但也是要做的事，就像 BVT 是自动进行的，我们也把它定义为一项重要的活动。除了测试报告、缺陷分析之外，测试交付还包括质量分析，并要回顾、审视整个测试过程，找到做的不好的地方，在下一个迭代版本中改进。

敏捷测试的通用流程

• 无论是 TDD 还是 ATDD，都是强调“测试先行”
• 重构的前提就是测试就绪
• 流程都需要根据上下文——开发模式、产品、行业、团队进行调整或剪裁，找到适合自己的流程，并不是一成不变的。
• 现实中有不少敏捷团队还保留着“提测”这样的环节（属于传统测试，不是棉结测试）
• 持续测试也不等于持续集成，持续测试也不等于自动化测试，持续测试就是从产品发布计划开始，直到交付、运维，测试融于其中、并与开发形影不离，随时暴露出产品的质量风险，随时了解产品质量状态，从而满足持续交付对测试、质量管理所提出的新要求。

 敏捷测试流程闭环与持续测试

敏捷项目管理角度看测试流程 

• 尽可能写出简单的测试计划，能写一页纸就不写两页纸、能写两页就不写三页......

• 没有测试用例的设计，而只是粗颗粒度的测试设计，前面有说明；

• 测试执行的双支撑，不仅需要自动化测试，而且还需要探索式测试；

• 强调质量文化、基础设施等重要性，并贯穿整个测试周期。

到底要不要专职的测试人员

• 团队情况：组织文化、人员素质和技能等；

• 产品运营模式，是 2B 还是 2C，是 SaaS 模式还是传统产品模式；

• 是否为关键业务系统，即是否是使命攸关系统（如金融、电信等核心处理系统）或性命攸关系统（如航空、航天、核工业等核心系统）。

敏捷模式下强调的是整个团队对可交付软件的质量负责、对测试负责，强调团队协作，发挥团队的作用。当团队越来越具有很强的敏捷思维方式和相应的能力时，可以考虑逐渐减少专业测试人员。

什么情况下可以考虑没有专职的测试人员呢？

• 团队质量内建的文化已经形成，敏捷测试思维 / 价值观构建完毕，团队成员技术能力和责任感表现优秀；

• 软件运营模式是 SaaS 模式，并拥有灰度发布机制，能做到快速部署、快速回滚；

• 不属于关键的业务系统