2024软件测试规范标准.docx

软件测试规范标准

目录

前言 1

总则 2

编码规范 2

合理的注释量 2

规范的命名格式 2

测试与测试结果 2

单元测试与报告 2

集成测试与报告 2

系统测试 2

模式 2

进入标准 3

暂停标准 3

退出标准 3

工作流程 3

需求与变更 3

需求定义 3

基线 4

变更管理 4

项目提测 4

提测时间 4

提测交付物 4

版本控制 4

提测间隔 5

测试环境 5

环境分类 5

环境管理 6

冒烟测试 6

缺陷处理 6

修复时间 6

质量保证 7

评审 7

需求评审 7

设计方案评审 7

用例评审 7

交叉测试 8

执行监督 8

优化改进 8

测试演进 8

缺陷预防 8

PAGE

PAGE1

软件测试规范标准

为了规范测试工作、减少开发与测试之前的沟通成本、保证项目进度、提高软件质量，测试组起草了这份软件测试工作规范。

总则

编码规范

软件程序开发需要遵守编码规范，一是可以减少代码的维护成本，提高开发工作效率；二是有利于开发工作的延续、传承，减小项目风险。

合理的注释量

好的代码应该是自描述的，让人费解的地方加上注释。

规范的命名格式

规范很多，要让别人和自己看得清楚，看得明白。

测试与测试结果

单元测试与报告

单元测试一定要做。有条件的话，先写测试代码，后写开发代码。综合使用

各种覆盖方法，例如：路径、函数、条件、语句，CodeCoverage确保高于80%。统一提供单元测试报告。

集成测试与报告

集成测试也一定要做。测试工作要覆盖所有模块和接口。统一提供集成测试报告。

系统测试

单元和集成通过后，项目提测并进入系统测试阶段。系统测试范围依据项目不同可分为功能和非功能测试。

模式

依照Alpha1-到Alpha1n的模式。

提测版本1冒烟测试通过后即进入第一轮测试（记做Alpha1），执行全用例。测试和开发，不断提交和修复BUG，直至用例执行完成；

开发修复完所有缺陷，打包发布版本2；

提测版本2冒烟测试通过后即进入第二轮测试（记做Alpha2），验证缺陷，执行部分用例。测试和开发，不断提交和修复BUG，直至用例执行完成；

开发修复完所有缺陷，打包发布版本3；

提测版本3冒烟测试通过后即进入第三轮测试（记做Alpha3），验证缺陷，执行部分用例。测试和开发，不断提交和修复BUG，直至用例执行完成；

如此，循环往复，直至缺陷收敛，达到测试退出标准，系统测试完成。

出具系统测试报告。

进入标准

需求说明书规定的功能均已实现；

主要流程可以走通。

界面上的功能均已实现，符合设计文档规定的功能。

暂停标准

一级错误数大于1、二级错误数大于2；

软件项目需暂停以进行调整时。

退出标准

按照测试计划完成了系统测试；

达到了测试计划中关于系统测试所规定的覆盖率要求；

在系统测试中发现的错误已经得到修改，各缺陷修复率达到要求。

工作流程

需求与变更

需求定义

需求确定后以文档和原型方式提供给测试方。应包含术语解释，功能描述，精确的数据限制等等。

对开发和测试人员开展统一培训。

基线

《产品需求文档》确认、稳定后，应建立基线，它是进一步开发、测试的基础。当基线形成后，项目负责软件配置管理的人需要通知相关人员基线已经形成，并且哪儿可以找到这基线了的版本。这个过程可被认为内部的发布。至于对外的正式发布，更是应当从基线了的版本中发布。

变更管理

软件工程过程中变更无法避免，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。软件变更管理包括建立控制点和建立报告与审查制度。

变更管理的主要任务包括：

、分析变更的必要性和合理性，确定是否实施变更；

、记录变更信息，填写变更控制单；

、修改相应的软件配置项（基线），确立新的版本；

、评审后发布新版本。

项目提测

提测时间

项目提测时间应安排在开发完成，已通过单元和集成测试之后。开发人员有时间，应过一遍冒烟测试用例，以提高冒烟测试通过的成功率。

提测交付物

《单元测试报告》

《集成测试报告》

《测试环境搭建部署手册》“部署程序包”

“数据库初始化脚本”

版本控制

开发团队制定并遵循一定的软件系统版本命名格式，例如：

“软件系统的版本号由3部分构成，即主版本号+次版本号+修改号。主版

本号1位，只有当系统在结构和功能上有重大突破改进后才发生变化；次版本号

有2位；修改号8位，采用提交时的日期，当系统进行任何修改后，包括数据库结构发生变化，修改号都要随之改变。例如：Ver3.31；

各子系统的版本号独立；

软件系