CMMI测试规程应用

本节列出本文档的修订记录以便追踪文档的变更历史，并方便阅读。每个正式发布版本必须保留修订记录。

版本号	修订日期	修订说明	修订人	审核人	批准人
V0.1	2018/12/19	创建测试管理规程	XX	XXX
V1.0	2018/12/21	根据预评审时，XX和XXX的建议，去掉测试总结活动，更新目录	XX	XXX
V1.1	2019/1/21	正式评审通过	XX	XXX
V2.0	2019/7/1	试点修正后发布	XXX	XXX

目 录

1 目的 4

2 范围 4

3 读者对象 4

4 术语和缩略语 5

5 角色与职责 5

6 流程图 7

7 准入条件 7

8 输入 8

9 主要活动 8

9.1 制定测试计划 8

9.2 评审测试计划 9

9.3 分析测试需求 9

9.4 设计测试案例 10

9.5 评审测试案例 11

9.6 部署测试环境 12

9.7 冒烟测试 12

9.8 执行测试案例 13

9.9 提交缺陷 13

9.10 修复缺陷 14

9.11 回归测试 14

9.12 编写测试报告 15

9.13 评审测试报告 15

9.14 纳入配置库 16

10 裁剪 16

11 度量 17

12 验证 17

13 输出 17

14 准出条件 17

15 参考文件 17

16 过程责任矩阵 18

 

 

1. 目的

本过程规定了在项目中通过实施有效的确认活动，以保证产品或产品构件被置于其预期的环境中时，满足预期的用途。

SG1 准备确认

SP1.1 选择需要确认的产品

SP1.2 建立确认环境

SP1.3    建立确认规程与准则

SG2 确认产品或产品组件

SP2.1 执行确认

SP2.2 分析确认结果

以下是验证过程域，可以参见目标和关键实践与确认过程域作对比。

SG 1准备验证 

SP 1.1 选择需要验证的工作产品 

SP 1.2 建立验证环境 

SP 1.3 建立验证规程与准则 

SG 2执行同级评审 

SP 2.1 准备同级评审 

SP 2.2 进行同级评审 

SP 2.3 分析同级评审数据 

SG 3验证选定的工作产品 

SP 3.1 执行验证 

SP 3.2 分析验证结果

1. 范围

本文档定义了在软件开发工作中对产品集成进行管理的标准流程。

1. 读者对象

本文档的读者为项目组所有相关人员，特别是测试人员。

1. 术语和缩略语
2. 角色与职责
3. 流程图

 

 

术语和缩略语	描述
TS(Technical Solution)	技术解决方案
QA (Quality Assurance)	质量保证
CM (Configuration management)	配置管理
确认（VAL）	确认（Validation，VAL）的目的在于证明产品或产品组件被置于预期环境中时满足其预期用途。确认问题一经识别，就会由与“需求开发”、“技术解决方案”、“项目监督与控制”等过程域相关联的过程加以解决。
验证	验证（Verification，VER）的目的在于确保选定的工作产品满足其规定的需求。

角色	职责描述
测试经理	负责制定项目的测试计划； 负责组织测试活动； 负责跟踪和监控测试过程的活动，并确保测试质量目标的达成； 组织搭建测试环境； 组织准备测试数据； 组织测试人员建立并维护测试案例和测试脚本； 组织测试人员执行测试工作； 对缺陷的提交和验证进行跟踪； 组织编写测试相关文档； 组织测试相关文档评审。
测试设计人员	对测试需求进行分析； 负责分析和设计测试案例； 负责测试脚本的编写； 负责测试执行场景的设计； 参加测试相关文档测试计划、测试案例、测试报告的评审活动评审。
环境管理员	负责部署测试环境； 准备测试数据； 协助进行测试环境搭建，确保测试环境与生产环境配置的一致性； 参加测试相关文档评审。
测试人员	编写测试案例； 执行测试案例； 负责测试案例的执行、记录测试缺陷和测试结果； 参加测试相关文档评审； 负责提交测试缺陷，跟踪缺陷修复情况，回归缺陷； 参与测试计划、测试案例、测试报告的评审活动；
开发人员	确认测试组整理的测试需求文档； 向测试组提供项目技术架构、实现等培训； 评审测试组编写的测试案例； 评审测试组编写的系统测试阶段的计划和报告等文档； 对测试发现的缺陷进行定位与修复； 发布软件版本。
质量人员	对测试过程进行监督与控制； 对测试产品质量进行跟踪。
配置管理员	负责测试版本的集成和发布； 负责对测试交付物的配置管理。 将相关配置项纳入配置库并基线化

 

 

1. 准入条件

• 测试阶段分为单元测试、集成测试、系统集成测试、验收测试这几个阶段；每个测试阶段的准入条件以上一个测试阶段的测试工作结束为准入条件；
• 上一测试阶段结束，测试报告完成编写，并且通过评审，已基线控制下。

1. 输入

• 《项目计划》
• 《业务需求说明书》
• 《软件需求说明书》
• 《概要设计说明书》
• 《接口设计说明书》
• 《数据库设计说明书》
• 《单元测试报告》
• 需要集成的产品组件。

1. 主要活动
   1. 制定测试计划

主要描述	根据项目计划制定测试计划。
准入条件	集成测试准入条件：需要集成的产品组件开发完成并通过单元测试则进入集成测试； 系统测试准入条件：集成测试完成，测试报告评审通过进入系统测试； 验收测试准入条件：系统测试完成，测试报告评审通过进入验收测试； 原则：上一测试阶段测试完成，测试报告评审通过并且转测试，冒烟测试通过，作为下一测试阶段的准入条件。
主要执行角色	测试经理	其他参与角色	测试设计人员、测试人员、开发人员、质量人员、环境管理员
输入	项目计划等项目相关文档	输出	《测试计划》
步骤	测试经理根据评审通过的《软件需求规格说明书》等项目相关文档，识别出测试的对象、测试目标、测试需求、测试方法，并估计系统测试的工作量、所需系统测试资源以及系统测试的进度、任务分解，并制定《测试计划》。 《测试计划》中需列出测试所需的工具。《测试计划》必须获得相关干系人的认可，并通过评审。通过评审后，测试项目经理需把测试计划纳入基线并提交配置库。 编写测试计划时需使用《测试计划》模板。
准出条件	《测试计划》编写完成
注意事项

1. 1. 评审测试计划

主要描述	测试经理组织相关人员对测试计划进行评审。
准入条件	测试计划编写完成
主要执行角色	测试经理	其他参与角色	测试设计人员、测试人员、开发人员、质量人员、环境管理员
输入	测试计划	输出	评审记录
步骤	测试经理组织测试计划的评审工作； 测试设计人员、测试人员、开发人员、质量人员、环境管理员参加测试计划评审，并提出评审意见； 测试经理修改测试计划并发送相关干系人； 测试经理提交测试计划至配置库； 配置管理员将测试计划纳入基线管理。
准出条件	《测试计划》评审通过
注意事项

1. 1. 分析测试需求

主要描述	由测试设计人员对需求进行理解与分析，形成测试要点。
准入条件	《测试计划》已经完成并评审通过
主要执行角色	测试设计人员	其他参与角色	测试经理、测试人员
输入	项目需求相关文档	输出	测试要点
步骤	测试设计人员参与需求讨论、评审会议，与业务人员和系统架构师详细沟通，充分理解业务需求和需求规格对功能的要求； 对于测试团队覆盖的系统，测试设计人员对需求进行测试需求分析。 测试设计人员依据业务需求说明书、软件需求设计说明并结合业务经验进行测试需求分析，包括明确测试内容、确定测试范围、设计测试场景、归纳测试要点。测试需求分析应涵盖需求全部内容，通过客户与技术两个角度，从业务目标、业务流程、系统功能、系统结构、系统数据、系统交互、影响性等多个维度进行分析。 测试需求分析的测试要点作为测试案例编写的主要依据。若需求或设计发生变更，测试设计人员应对测试需求分析进行相应调整。
准出条件	测试需求分析完成
注意事项

1. 1. 设计测试案例

主要描述	根据测试要点进行测试案例的设计。
准入条件	测试需求分析完成
主要执行角色	测试设计人员	其他参与角色	测试经理、测试人员
输入	测试要点	输出	测试案例
步骤	编写《测试案例》要覆盖《业务需求说明书》或《软件需求规格说明书》中所有的业务需求或功能点。《测试案例》采用统一模板，必须写清用例的预置条件、操作步骤、期望结果，要保证用例的清晰性、完整性； 测试人员依据业务需求说明书、软件需求规格说明书、项目相关其他技术文档以及测试需求分析的测试要点，据此编写测试案例，在测试过程中如有需求变更情况，测试人员应补充或修改测试案例； 测试案例应重点针对所测需求的应用系统新增或修改代码所实现的系统功能或可能影响的其它系统功能，同时还应关注并确保与其他关联系统的连通性和接口正确性； 测试案例可包含实现被测试功能的前置准备条件及输入数据、测试操作步骤、测试脚本以及预期正确的操作结果； 测试案例必须包含对异常操作、错误输入、非法字符、控制必输项、超出数据输入范围以及反向流程等异常情况进行测试的反案例； 测试案例保存在测试管理工具中，同时应当作为资产归档保存至配置管理平台。
准出条件	测试案例编写完成
注意事项

1. 1. 评审测试案例

主要描述	评审测试案例并对测试案例进行更新
准入条件	测试案例设计完成
主要执行角色	测试经理	其他参与角色	业务人员、测试设计人员、测试人员、开发人员、质量人员
输入	测试案例	输出	评审记录
步骤	在《测试案例》编写、修改完成以后，将《测试案例》交付给测试经理，由测试经理组织人员进行《测试案例》的评审，评审人员中必须包括业务人员、测试设计人员、测试人员、开发人员、质量人员； 测试设计人员根据评审意见更新《测试案例》，并最终由测试经理组织人员进行确认工作； 测试案例评审通过后，将测试案例导入测试管理平台，或者可以直接在测试管理平台编写测试案例，并进行评审； 评审通过后的测试案例应当作为资产归档保存至配置管理平台。
准出条件	测试案例评审并更新确认完成
注意事项

1. 1. 部署测试环境

主要描述	部署测试环境，并验证测试环境满足测试需要。
准入条件	测试版本提交
主要执行角色	环境管理员	其他参与角色	测试经理、测试人员
输入	测试计划 版本包 测试申请	输出	测试环境
步骤	测试人员根据系统测试计划中的要求，准备和搭建系统测试环境（软件环境、硬件环境），并使之能够运行起来； 测试经理组织检查环境的适用性，可以由测试人员验证测试环境是否适用。
准出条件	测试环境部署完成并验证可用。
注意事项

1. 1. 冒烟测试

主要描述	评审开发设计的相关文档
准入条件	设计文档已经完成
主要执行角色	测试经理	其他参与角色	测试人员、开发人员
输入	冒烟测试案例	输出	冒烟测试案例执行结果
步骤	测试经理组织测试人员对待测版本进行冒烟测试； 冒烟测试案例从本测试阶段的测试案例中进行选择，选择的原则是覆盖关键业务路径； 冒烟测试案例必须全部测试通过，如果严重堵塞的功能，则说明该测试版本不具备进入下一测试阶段的条件。 如果没有通过冒烟测试，测试经理则会将测试版本和冒烟测试结果返回给开发团队； 如果冒烟测试通过，则正式进入下一测试阶段进行测试执行。
准出条件	冒烟测试通过
注意事项

1. 1. 执行测试案例

主要描述	进行测试案例的执行，并记录测试结果
准入条件	测试案例设计完成，并且转测试时冒烟测试通过
主要执行角色	测试人员	其他参与角色	测试经理、开发人员
输入	测试案例	输出	测试结果/缺陷
步骤	测试人员按照测试案例的内容，对被测系统执行测试案例。集成测试、系统测试及验收测试应执行全部类型测试案例，其中验证测试案例可以在系统测试案例中进行选择并增加业务场景验证的案例； 测试案例如因为特殊情况无法执行，测试经理应组织相关方共同进行风险评估，由测试人员将测试案例状态置为无法执行，可根据具体测试管理平台设置状态，并在测试报告中说明无法执行的原因和风险； 测试人员要在测试过程中记录测试结果并形成测试执行记录文档，可供日后对测试过程的检查与追溯；可以在测试管理平台中将测试案例的状态进行改变并记录执行结果； 测试经理在测试执行过程中负责对测试过程进行管理与监控、协调关联系统配合测试、测试结果与缺陷的判定以及测试执行记录的检查等，如需求由业务人员进行分析，则由业务人员负责对测试结果与缺陷的判定以及测试执行记录的检查。
准出条件	测试案例执行并进行设置执行状态
注意事项

1. 1. 提交缺陷

主要描述	测试人员执行测试案例并提交发现的缺陷
准入条件	执行测试案例
主要执行角色	测试人员	其他参与角色	测试经理、开发人员
输入	测试案例	输出	缺陷
外部	测试人员执行测试案例并记录测试结果； 测试人员将测试时发现的缺陷提交缺陷管理平台，并指定给相关人员； 在测试案例执行过程中发现的缺陷应遵循《缺陷管理规程》中对缺陷的管理要求在测试管理工具中登记管理与跟踪。 对于测试过程中遗留的缺陷应在测试执行结束前由测试经理或项目组再次评估并确认遗留缺陷的影响与风险，严重级别及以上的缺陷必须修改关闭； 缺陷的具体管理流程参见《缺陷管理规程》。
准出条件	测试案例执行完成并提交所有缺陷
注意事项

1. 1. 修复缺陷

主要描述	开发人员分析测试人员提交的缺陷，并针对缺陷解决方案，修复代码，备注缺陷产生的原因。
准入条件	缺陷已提交并分配给相关开发人员
主要执行角色	开发人员	其他参与角色	测试经理、开发经理、测试人员、开发人员
输入	缺陷	输出	代码
步骤	开发人员分析测试人员提交的缺陷； 针对缺陷提出解决方案，修复代码，备注缺陷产生的原因； 提交修复后的代码；  在当前测试阶段的每个轮次的测试中，修复缺陷并提交新的测试版本包。
准出条件	当前测试阶段缺陷修复完成，达到准出标准。
注意事项

1. 1. 回归测试

主要描述	测试人员针对新提交的测试版本进行回归测试。
准入条件	缺陷修复完成，并提交新的测试版本
主要执行角色	测试人员	其他参与角色	测试经理、开发经理、开发人员
输入	回归测试案例 新的测试版本	输出	回归测试案例执行结果
步骤	环境管理人员部署新测试版本； 测试人员进行回归测试； 可以根据程序修改涉及功能点的个数确定回归测试范围。
准出条件	回归测试通过
注意事项

1. 1. 编写测试报告

主要描述	编写测试报告
准入条件	测试案例执行完成，回归测试通过
主要执行角色	测试经理	其他参与角色	测试人员
输入	测试案例 测试执行结果 缺陷 测试版本	输出	测试报告
步骤	测试人员所有测试案例执行完毕，并回归测试通过； 测试经理编写测试报告，作为测试完成的产出物；测试报告的内容包含：测试环境、测试通过的软件版本、测试执行情况总结、测试缺陷分析情况、测试结果的风险分析等； 测试报告的编写参照模板《测试报告模板》； 测试完成后，需将测试案例、测试执行记录等测试相关文档归档保存到配置管理平台作为测试资产保存。
准出条件	测试报告编写完成
注意事项

1. 1. 评审测试报告

主要描述	评审测试报告
准入条件	测试报告编写完成
主要执行角色	测试经理	其他参与角色	业务人员、测试设计人员、测试人员、开发人员、质量人员
输入	测试报告	输出	评审记录
步骤	在《测试案例》编写、修改完成以后，由测试经理组织人员进行《测试报告》的评审，评审人员中必须包括业务人员、测试设计人员、测试人员、开发人员、质量人员； 测试经理根据评审意见更新《测试报告》； 《测试报告》评审通过后的应当作为资产归档保存至配置管理平台； 每个测试阶段的测试报告评审通过作为下一测试阶段准入条件之一。
准出条件	测试报告评审通过
注意事项

1. 1. 纳入配置库

主要描述	将测试过程中所有的产出物纳入配置库
准入条件	测试阶段所有工作完成
主要执行角色	配置管理员	其他参与角色	测试经理、测试设计人员、测试人员
输入		输出
步骤	测试经理、测试设计人员、测试人员将输出物提交配置库； 配置管理员检查此阶段所需提交的配置项，将相关配置项纳入配置库。
准出条件	配置项纳入配置库。
注意事项

1. 裁剪

根据裁剪规则或者裁剪指南进行裁剪。

1. 度量

测试案例数量

测试案例评审发现的问题数量

测试发现的缺陷数量

解决缺陷所花费的工作量

测试案例编写的工作量

1. 验证

质量人员通过审计测试过程的相关工作产品和活动来进行验证。

1. 输出

• 测试版本
• 《测试计划》
• 《测试案例》
• 《测试报告》
• 缺陷
• 评审记录

1. 准出条件

测试完成，测试报告评审通过。

1. 参考文件

 

1. 过程责任矩阵

活动	责任				输出
	执行	负责	批准	通知
制定测试计划	测试经理	测试经理			测试计划
评审测试计划	测试人员 开发人员 质量人员	测试经理		环境管理员	评审记录
分析测试需求	测试设计人员	测试经理			测试要点
设计测试案例	测试设计人员	测试经理			测试案例
评审测试案例	测试经理	测试经理			评审记录
部署测试环境	环境管理员	测试经理		测试人员
冒烟测试	测试人员	测试经理
执行测试案例	测试人员	测试经理
提交缺陷	测试人员	测试经理			缺陷
修复缺陷	开发人员	开发人员			代码
回归测试	测试人员	测试经理
编写测试报告	测试经理	测试经理			测试报告
评审测试报告	测试经理	测试经理		测试人员 质量人员
组织测试总结	测试人员	测试经理		质量人员	测试总结
纳入配置库	配置管理员

填写说明：

1. 活动列下的所有活动须与章节9中的子活动对应。
2. 执行：执行该子活动的角色，可以是多个角色。必须有角色。
3. 负责：对活动负责的角色，只能是一个角色。必须有角色。
4. 批准：决策活动是否批准进入下一个活动的角色。根据情况填写角色。
5. 通知：该活动需要被通知的角色。根据情况填写角色。
6. 输出：活动输出的工作产品。