软件测试文档.pdfVIP

软件测试工作规范

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

量，测试组起草了这份软件测试工作规范。

1.1.编码规范

软件程序开发需要遵守编码规范，一是可以减少代码的维护成本，提高开发工作效

率；二是有利于开发工作的延续、传承，减小项目风险。

1.1.1.合理的注释量

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

1.1.2.规范的命名格式

规范很多，要让别人和一个月的自己看得懂。

1.2.测试与测试结果

1.2.1.单元测试与报告

单元测试一定要做。深入理解“testdrivendevelopment”思想，有条件的话，先

写测试代码，后写开发代码。综合使用各种覆盖方法，例如：路径、函数、条件、语句，

CodeCoverage确保高于80%。

统一提供单元测试报告。

1.2.2.集成测试与报告

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

统一提供集成测试报告。

1.2.3.系统测试

单元和集成通过后，项目提测并进入系统测试阶段。

系统测试范围依据项目不同可分为功能和非功能测试。

1.2.3.1.模式

依照Alpha1-到Alpha1n的模式。

提测版本1冒烟测试通过后即进入第一轮测试（记做Alpha1），执行全用例。测试和

开发，不断提交和修复BUG，直至用例执行完成；

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

提测版本2冒烟测试通过后即进入第二轮测试（记做Alpha2），验证缺陷，执行部分

用例。测试和开发，不断提交和修复BUG，直至用例执行完成；

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

提测版本3冒烟测试通过后即进入第三轮测试（记做Alpha3），验证缺陷，执行部分

用例。测试和开发，不断提交和修复BUG，直至用例执行完成；

……

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

出具系统测试报告。

1.2.3.2.进入标准

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

2）主要流程可以走通。

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

1.2.3.3.暂停标准

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

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

1.2.3.4.退出标准

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

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

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

1.3.工作流程

1.3.1.需求与变更

1.3.1.1.需求定义

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

据限制等等。

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

1.3.1.2.基线

《产品需求文档》确认、稳定后，应建立基线，它是进一步开发、测试的基础。当基

线形成后，项目负责软件配置管理的人需要通知相关人员基线已经形成，并且哪儿可以找

到这基线了的版本。这个过程可被认为内部的发布。至于对外的正式发布，更是应当从基

线了的版本中发布。

1.3.1.3.变更管理

软件工程过程中变更无法避免，这种变更必须严格加以控制和管理，保持修改信息，

并把精确、清晰的信息传递到软件工程过程的下一步骤。软件变更管理包括建立控制点和

建立报告与审查制度。

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

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

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

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

4、评审后发布新版本。

1.3.2.项目提测

1.3.2.1.提测时间

项目提测时间应安排在开发完成，已通过单元和集成测试之后。开发人员有时间，应

过一遍冒烟测试用例，以提高冒烟测试通过的成功率。

1.3.2.2.提测交付物

《单元测试报告》

《集成测试报告》

《测试环境搭建部署手册》

“部署程序包”

“数