下载掌阅APP，畅读海量书库
立即打开
软件测试贯穿软件产品开发的整个生命周期，从产品的需求分析审查到最后的验收测试，直至软件发布。从测试实际的前后过程来看，软件测试的过程是由一系列不同的测试阶段组成的，这些阶段主要有：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。在软件测试项目的计划书中，需要给各个阶段制定一个明确的开始和结束时间，这就是通常所说的日程进度表（schedule）。项目进度安排，实际上取决于测试工作量和现有的人力资源。当人力资源充足时，测试周期短；当人力资源较少时，测试周期就会长。
里程碑一般是项目中完成阶段性工作的标志，即用一个结论性的标志来描述一个过程性任务明确的起止点，进度安排就是确定里程碑的起止点。一个里程碑标志着上一个阶段结束、下一个阶段开始，也就是定义当前阶段完成的标准（Entry Criteria）和下一个新阶段启动的条件或前提（Entry Criteria）。里程碑具有很强的时序性，还具有下列特征。
● 里程碑也是有层次的，在一个父里程碑的下一个层次中定义子里程碑。
● 不同类型的项目，里程碑可能不同。
● 不同规模项目的里程碑，其数量的多少不一样，里程碑可以合并或分解。
在软件测试周期中，建议定义下列6个父里程碑。
（1）M1：需求分析和设计的审查。
（2）M2：测试计划和设计。
（3）M3：代码（包括单元测试）完成。
（4）M4：测试执行。
（5）M5：代码冻结。
（6）M6：测试结束。
每个里程碑再划分为子里程碑，如果项目周期很长，还可以对每个子里程碑进一步划分为更小的里程碑，以利于更有效的控制，如表2-7所示。
表2-7 软件测试进度表示例
在本书一开始的引言中，以Scrum为例，简要阐述了敏捷测试流程。而在敏捷测试项目中，如何明确测试的里程碑呢？万变不离其宗，敏捷测试也需要从测试计划到测试设计、再到执行，只是测试设计和执行的界限不那么分明，测试设计和执行往往交替或并列地开展。在敏捷测试中，甚至可以不需要测试用例，而是针对Use Case 或User Story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发相对稳定功能的自动化测试脚本，为后期的回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，只能进行一轮回归测试。综合上述考虑，敏捷测试的实际操作流程如图2-7所示，简单有效。
图2-7 敏捷测试流程简要图
在这样的流程中，大框架也没有什么不同，而且各项测试件（测试计划、需求、自动化脚本等）的评审还是需要的，只是没有明确的评审阶段，测试是一个持续的质量反馈过程，阶段性不那么突出，但还是可以设定一些控制点，即里程碑：
（1）测试任务定义；
（2）测试计划制定和评审通过；
（3）测试需求或测试点（或测试场景）列表明确和评审通过；
（4）验收测试结束。