v6ole
186 lines
11 KiB
Markdown
186 lines
11 KiB
Markdown
# 中国电信软件研发规范测试管理分册（修订版）
|
|
|
|
> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
|
|
|
|
中国电信软件研发规范测试管理分册 （修订版）
|
|
|
|
中国电信集团有限公司
|
|
|
|
## 2023 年 12 月
|
|
|
|
i
|
|
|
|
> 编制人员信息已移除。
|
|
|
|
版本变更历史
|
|
|
|
## 1 文档说明
|
|
|
|
### 1.1 编制说明
|
|
|
|
为进一步提升全集团的软件质量保障， 规范软件测试过程 、测试组织 、测试文档、测试缺陷和测试技术等管理，明确软件测试过程中的测试准则和方法，特制定本测试管理规范， 用于指导和规范全集团的软件测试过程。
|
|
|
|
### 1.2 文档结构
|
|
|
|
本规范由文档说明、总体要求，测试准则、软件流程、缺陷管理等部分构成，各章节的主要内容如下：第 1 章节-文档说明， 综述本文档的整体编制说明。第 2 章节-角色与职责， 对测试过程中的角色与工作职责进行描述。第 3 章节-测试流程， 主要描述测试各个过程中的工作要求。第 4 章节-分级测试要求， 基于研发流程对测试进行分阶段说明。第 5 章节-测试验收标准， 主要描述不同项目级别的测试验收要求。第 6 章节-缺陷管理， 主要描述软件缺陷的处理流程要求。第 7 章节-测试异常处理， 主要描述测试异常的处理流程要求。第 8 章节-软件环境划分， 主要描述测试环境各阶段的划分。
|
|
|
|
### 1.3 适用范围
|
|
|
|
本规范适用于指导中国电信研发项目软件测试工作的总体要求以及单元测试 、集成测试 、系统测试 、验收测试等测试活动的具体要求。
|
|
|
|
### 1.4 起草单位
|
|
|
|
本规范的起草单位是中国电信集团公司。
|
|
|
|
### 1.5 解释权
|
|
|
|
本规范解释权属于中国电信集团公司。
|
|
|
|
### 1.6 版权
|
|
|
|
本规范的版权属于中国电信集团公司。
|
|
|
|
### 1.7 名词解释
|
|
|
|
## 2 角色与职责
|
|
|
|
根据被测试软件的不同级别，软件测试的人员组织可能有所不同，从相对完整和严格的要求而言，软件测试组织主要包括如下工作角色。同时也可能存在一个人可以承担多个角色，一个角色也可以由多个人共同承担的情况，具体角色人员及其职责如下：
|
|
|
|
## 3 测试流程
|
|
|
|
### 3.1 总体流程
|
|
|
|
软件测试贯穿项目的整个生命周期，为规范各测试活动，把控各环节的质量，各级别、类型的测试应遵循本章测试流程要求。测试流程分为测试计划、测试准备 、测试执行 、测试总结四个阶段， 具体流程描述如下：
|
|
|
|
### 3.2 测试计划阶段
|
|
|
|
#### 3.2.1 测试需求分析
|
|
|
|
测试人员应全程参与需求分析与评审的过程， 并从测试角度，评估软件需求的可行性 、可测性， 充分了解需求， 明确需求的详细测试范围。
|
|
|
|
#### 3.2.2 测试方案/计划设计
|
|
|
|
测试方案/计划是指导测试过程的纲领性文件，在此阶段，测试负责人应以测试需求为基础， 制定详细的项目测试方案/计划， 为测试的执行提供依据。需求评审通过后， 由测试负责人根据需求内容， 确定测试范围和测试策略、估算测试工作量与资源、规划测试安排及进度，并对测试过程中存在的风险进行评估等， 输出测试方案。在测试流程中，测试负责人应按照标准制定合适的测试方案或测试计划并组织评审以验证其可行性。
|
|
|
|
#### 3.2.3 测试方案/计划评审
|
|
|
|
测试负责人完成测试方案或测试计划的撰写后，应组织产品经理、研发人员等相关项目成员进行测试方案评审，确保测试方案的可行性。评审结束后，负责将评审结果以及测试方案同步至所有相关人员。
|
|
|
|
### 3.3 测试准备阶段
|
|
|
|
#### 3.3.1 测试用例/脚本设计
|
|
|
|
测试需求及方案确认后， 测试执行人员应根据需求内容和测试的类型，完成测试用例或测试脚本的设计编写，测试用例或测试脚本应尽可能覆盖需求涉及的业务场景 、系统功能 、条件分支 、边界值等。
|
|
|
|
#### 3.3.2 测试用例/脚本评审
|
|
|
|
测试人员完成测试用例或测试脚本的设计编写后， 应组织（项目经理、研发人员等相关项目成员）进行测试用例或测试脚本的评审，确保测试用例或测试脚本的正确性 、可行性和充分性。
|
|
|
|
#### 3.3.3 测试环境准备/部署
|
|
|
|
项目进入提测阶段后，测试人员可依据项目实际情况判断是否需要自行部署项目的测试环境；如需部署，测试人员应按照项目部署文档完成测试环境的配置部署并对环境加以验证。
|
|
|
|
### 3.4 测试执行阶段
|
|
|
|
在测试执行过程中，测试人员应依据测试计划以及通过评审的测试用例或测试脚本， 逐一执行 。在执行过程中， 测试人员应认真观察并如实记录测试过程、测试结果和发现的问题。测试人员的主要工作有以下两方面：
|
|
|
|
（1） 根据每个测试用例/脚本的期望测试结果 、实际测试结果和评价准则判定该测试用例/脚本是否通过 。如果不通过,测试人员应认真分析情况﹐ 将问题记录于缺陷管理工具中，并告知相对应的研发人员让其进行确认与修复 。（缺陷管理具体流程见 6 缺陷管理）（2）当所有的测试用例/脚本都执行完毕,测试人员应根据测试的充分性要求和失效记录﹐ 确定当前的测试工作是否充分,是否需要增加新的测试内容 。如需增加测试内容， 则应进行测试用例/脚本的补充， 直至测试项达到预期要求(具体要求见 3.3.1 测试用例/脚本设计 、3.3.2 测试用例/脚本评审)， 此外， 增加的测试内容需记录在册， 用于后续的项目复盘或总结分析。
|
|
|
|
### 3.5 测试总结阶段
|
|
|
|
#### 3.5.1 测试结果分析
|
|
|
|
测试执行结束后， 测试人员应根据需求规格说明书 、测试计划 、测试执行结果、缺陷清单等作为依据，对本次测试的需求整体内容进行系统的分析测评，是否达到需求目的， 满足测试准出规范。
|
|
|
|
#### 3.5.2 测试报告撰写
|
|
|
|
测试报告是产品需求测试阶段的最终文档产出物，测试报告记录测试的过程与结果，对发现的问题和缺陷进行分析，为软件存在的质量问题提供依据， 同时为软件的验收和交付打下基础。
|
|
|
|
#### 3.5.3 测试归档
|
|
|
|
软件测试文档是测试过程的重要组成部分， 提供了测试过程的记录和证据，测试归档根据 4.2 节测试准出要求， 测试工作结束后，对测试过程中涉及到各种标准文档进行归档， 保存测试组织资产。
|
|
|
|
## 4 分级测试要求
|
|
|
|
为保障软件测试质量，对于较大型的软件测试应实施分级管理，通常软件测试级别分为： 单元测试、集成测试、系统测试、验收测试。项目组应根据项目任务书， 并结合实际需要， 制定各阶段的测试内容及准入准出标准。
|
|
|
|
### 4.1 单元测试
|
|
|
|
单元测试的对象是可独立编译或汇编的程序模块 、软件构件或软件中的类（统称为模块），其目的是检查每个模块能否正确地实现设计说明中的功能、性能 、接口和其他设计约束等条件， 发现模块内可能存在的各种差错。
|
|
|
|
### 4.2 集成测试
|
|
|
|
集成测试的目的是检查模块之间， 以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。
|
|
|
|
### 4.3 系统测试
|
|
|
|
系统测试的对象是完整的、集成的计算机系统， 系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发合同规定的要求。
|
|
|
|
### 4.4 验收测试
|
|
|
|
验收测试的目的是在真实的用户（或系统）工作环境下检验完整的软件系统是否满足软件开发技术合同（或软件需求规格说明）规定的要求。其结论是软件的需方确定是否接收该软件的主要依据。
|
|
|
|
## 5 测试验收标准
|
|
|
|
测试准出标准是指结束当前版本的测试工作所需满足的条件。
|
|
|
|
## 6 缺陷管理
|
|
|
|
本章节内容定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性， 以保证项目研发质量。
|
|
|
|
### 6.1 缺陷描述
|
|
|
|
缺陷的描述主要包含以下要素： 缺陷标题 、缺陷类型 、缺陷严重等级 、缺陷优先级、缺陷状态、缺陷复现步骤、测试人员、缺陷解决人、解决方案、解决日期等（具体信息可详见附件《缺陷追踪表模板》）
|
|
|
|
#### 6.1.1 缺陷类别
|
|
|
|
根据引发该缺陷的根源进行分类， 缺陷类别可分为需求缺陷、架构缺陷、设计缺陷 、编码缺陷 、测试缺陷 、集成缺陷。
|
|
|
|
#### 6.1.2 缺陷严重等级
|
|
|
|
根据缺陷导致的后果严重度， 缺陷严重等级一般可分为四类： 致命 、严重、一般 、轻微。
|
|
|
|
#### 6.1.3 缺陷优先级
|
|
|
|
缺陷优先级一般可分为四类： 立即解决 、优先解决 、一般 、较低。
|
|
|
|
#### 6.1.4 缺陷状态
|
|
|
|
缺陷主要包括以下状态：
|
|
|
|
### 6.2 缺陷处理流程
|
|
|
|
#### 6.2.1 提交缺陷
|
|
|
|
测试人员在发现缺陷后，应对缺陷的类型、复现步骤、影响范围、严重等级、处理优先级等信息进行分析，确认（与测试负责人、研发负责人确认或自主确认）缺陷的修复人，记录缺陷信息于缺陷清单中交予缺陷修复人员或在缺陷管理工具中记录并指派给对应修复缺陷的研发人员。
|
|
|
|
#### 6.2.2 确认缺陷
|
|
|
|
研发人员在接收到缺陷后， 应对缺陷的信息进行确认， 确认无误后， 可依据缺陷确认的结果对缺陷进行处理。
|
|
|
|
#### 6.2.3 修复缺陷
|
|
|
|
研发人员在确认缺陷完毕后，应依据缺陷的优先级对缺陷进行修复，修复完成并更新系统后，应更新缺陷的状态并告知对应的测试人员进行缺陷的回归验证。如研发人员因各种原因在短期内无法对缺陷进行修复的，可与产品经理进行协商， 是否能对缺陷进行延期处理。
|
|
|
|
#### 6.2.4 缺陷验证
|
|
|
|
测试人员在接收到缺陷已修复的信息时，应按照缺陷复现步骤，对原有缺陷进行回归验证，并根据验证结果，验证成功则关闭缺陷，验证失败则重新记录失败原因并将缺陷指派给研发人员进行修复。
|
|
|
|
#### 6.2.5 缺陷激活
|
|
|
|
缺陷关闭后，状态并非一成不变，在遇到复现情况时，可激活已关闭的缺陷。
|
|
|
|
## 7 测试异常处理
|
|
|
|
### 7.1 测试暂停/恢复
|
|
|
|
在测试过程中遇到严重错误或不可抗因素影响导致无法进行测试活动时，允许暂停测试活动， 直至符合测试恢复原则。
|
|
|
|
### 7.2 测试争议处理
|
|
|
|
当对测试结果出现争议时，应依据争议的原因， 区分在不同情况下的最终决策者。
|
|
|
|
## 8 测试环境划分
|
|
|
|
测试环境是测试工作中非常重要的一环，稳定和可控的测试环境，可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。根据测试活动目的不同， 会区分出不同的软件环境， 生产实践中， 也会存在将多个测试活动都在同一套环境上进行的情况，各项目根据实际需求视情况而定。
|