软件测试与发布管理规范Word格式文档下载.docx

软件测试与发布管理规范Word格式文档下载.docx

《软件测试与发布管理规范Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件测试与发布管理规范Word格式文档下载.docx（14页珍藏版）》请在冰豆网上搜索。

1目的

本文档是测试团队的日常工作规范，主要于侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。

更加规范的完成产品的功能测试和性能测试，确保产品质量，完成技术发布的准备工作。

测试技术和策略等问题不在本文档描述范围之内。

2测试团队的构成

职责

Ø

在需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。

编写合理的测试计划，并与项目整体计划有机地整合在一起。

编写覆盖率高的测试用例，针对测试需求进行相关测试技术的研究。

认真仔细地实施测试工作，进行缺陷跟踪与分析，并提交测试报告供项目组参考。

角色划分

在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。

角色名称

相关主要责任

测试主管

组建测试小组，代表测试小组与其他角色组进行沟通

编写测试计划，搭建测试环境

测试过程中的进度控制、风险管理

编写测试报告，召开测试评审

编写测试报告分析总结

测试人员

识别测试需求，编写测试用例，协助测试评审

执行测试用例，测试结果记录，测试缺陷记录与跟踪

软件支持工程师

为测试工作提供技术支持，如果安装环境、版本部署、测试工具支持等

3工作流程及规范

测试与发布流程图

计划与设计阶段

测试任务启动

开发团队与测试团队交接测试内容，告之较为确切的测试日期，对测试目标达成一致，统一项目组的目标和测试的工作重点。

项目经理提供当前最新的相关资料《软件项目计划书》、《软件测试任务书》等。

测试人员可预先熟悉背景资料，协助测试主管编写《软件测试计划书》初稿。

过程要点

详细说明

前置条件

项目经理提供《软件项目计划书》，项目进入软件实现阶段（编码）

工作内容

项目经理通知测试主管正式测试交接时间，测试规模预估等

退出标准

测试任务得到测试主管确认，并提交《软件测试计划书》初稿

输出文档

《软件测试计划书》初稿。

责任人

项目经理，测试主管

编写测试计划书

需求分析文档确立后，测试团队需要编写测试计划文档，为后续的测试工作提供直接的指导。

项目需求文档建立

根据项目的需求文档，按照测试计划文档模板编写测试计划。

测试计划中应该至少包括以下关键内容：

●测试需求——需要测试团队测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级

●测试策略——整体测试的测试策略和每个测试需求的测试方法

●测试资源——本次测试所需要用到的人力、硬件、软件、技术的资源

●测试团队角色——明确测试团队内各个成员的角色和相关责任

●里程碑——明确标准项目过程中测试团队应该关注的里程碑

●可交付工件——在测试团队的工作中必须向项目组提交的产物，包括测试计划、测试报告等等

●风险管理——列举出测试工作所可能出现的风险

测试计划编写完毕后，必须提交给项目组全体成员，并由项目组组中各个角色组联合评审

测试计划文档由项目组评审通过，提供《软件测试计划书》正稿

在项目开发过程中，要适时的对测试计划进行跟踪，以评估此计划的完整性、可行性，在项目结束时还要最后评估一下测试计划的质量

《软件测试计划书》

设计测试用例

在需求分析文档确立基线以后，测试团队需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。

在用例的编写过程中，具体的任务和责任人如下：

测试需求明确，测试计划明确，项目经理提供《软件需求规格说明书》

根据每一步测试计划编写全部的测试用例

测试用例需要覆盖所有的测试需求

《软件测试用例单》

测试主管、测试人员

测试用例评审

在测试团队完成测试用例之后，项目组需要对项目的测试用例进行评审，在用例的评审过程中，具体的任务和责任人如下：

测试用例完成

根据项目《软件需求规格说明书》对测试用例进行评审

更新测试用例，测试用例覆盖到所有的测试需求

《软件测试用例评审报告》

项目经理、测试主管

实施测试阶段

冒烟测试

在开发团队完成某个功能模块之后，测试团队首选对功能模块进行冒烟测试，确保基本功能都完成。

详细描述

开发团队完成某个功能模块

测试人员根据《软件需求规格说明书》对模块进行冒烟测试，确保基本功能完成。

冒烟测试通过，基本功能完成。

测试人员、开发人员

模块/集成测试

实施针对已经通过冒烟测试的功能模块和已经评审通过的测试用例，实施测试用例绝对将花费测试团队绝大部分时间，这些工作都是建立在前期很多计划工作的基础上。

测试主管提前制定出当日的测试计划，确定可用的测试用例。

测试人员根据测试计划中分配给自己的测试任务和测试用例，实施相应的测试用例，并将记录实施用例的结果。

缺陷及时记录和提交，并与相关开发人员沟通。

测试用例中的所有任务被执行，结果被记录，缺陷被提交。

缺陷分析

测试主管和项目经理根据项目的定位，软件需求及软件测试中的80/20原则针对测试人员提交的缺陷进行分析，以提高测试效率。

所有的测试用例全部都实施完成

根据项目的定位等针对测试人员提交的缺陷进行分析

如存在缺陷转为需求，则更新需求规格说明书

测试人员提交的缺陷完成分析

回归测试

在每轮测试结束之后，由测试团队重新拷贝修改后的最新版本，进行回归测试。

在每轮测试中，按照现有的测试用例没有新的缺陷被发现，测试报告中全部的活动缺陷都被解决。

测试团队将按照测试计划中对于回归测试的策略对产品进行回归测试，回归测试的用例属于测试用例的一部分或者是全部测试用例，但不超出原先预定的测试用例的范围。

回归测试所运行的用例全部通过。

性能测试

如有必要，需要收集用户对性能方面的要求，做性能测试，同时出具《性能测试报告》。

项目集成测试完毕，并完成所有的回归测试

根据收集到的用户对性能方面的要求，制定性能测试策略，并进行性能测试，收集性能测试结果数据。

《性能测试报告》

项目的性能指标达到用户的要求

总结阶段

测试工作结束或即将结束时，测试团队就要开始着手准备进行总结的工作。

编写系统测试报告

在回归测试结束之后，测试主管将要编写系统测试报告，对系统测试情况进行总结，并且提交给全体项目组，为产品的后续工作提供重要的信息支持。

测试团队完成了所有的测试实施工作

测试主管根据测试的结果，按照系统测试报告的文档模板编写测试报告，测试报告必须包含以下重要内容：

●测试资源概述——多少人、多长时间

●测试结果摘要——分别描述各个测试需求的测试结果，产品实现了哪些功能点，哪些还没有实现

●缺陷分析——按照缺陷的属性分类进行分析

●测试需求覆盖率——原先列举的测试需求的测试覆盖率，可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明

●测试评估——从总体对项目质量进行评估

●测试团队建议——从测试团队的角度为项目组提出工作建议

测试主管完成了符合标准的系统测试报告，发送给全项目组。

《系统测试报告》

测试工作总结

测试总结工作是在以上的工作全部结束以后，它的目的是评估本次测试工作，总结经验，使下一次的工作做得更好。

测试主管完成了符合标准的测试报告，发送给全项目组

测试主管根据测试的结果，按照测试总结的文档模板编写测试总结：

内容包括：

●测试效果总结——测试是否达到预期目的

●测试文档总结——测试过程文档是否齐全，可信，符合标准

●测试评估——从总体对测试的质量进行评估

●测试建议——对本次测试工作指出不足，需要在以后工作中改进的地方

●宣布测试结束——测试验收组成员签字宣布本次测试结束

测试主管完成了符合标准的测试总结，发送给全测试团队。

《项目测试工作总结》

测试归档

测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归类，存档。

测试验收通过

归类，存档测试过程涉及到的文档，主要包括以下文档（必须）

●《软件测试任务书》

●《软件测试计划书》

●《软件测试用例单》

●《软件测试用例评审报告》

●《系统测试报告》

●《性能测试报告》

●《项目测试工作总结》

全部文档归类完毕，版本号封存

缺陷跟踪

测试验收结束后，跟踪产品在试运行阶段暴露出来的新缺陷，以及已提交的缺陷是否再次发生。

测试团队完成了所有的测试实施工作，测试验收通过，产品上线试运行、运行。

●已发现缺陷是否再次发生

●是否有新发现的在测试中未发现的缺陷

●是否有新发现的在测试中已发现但未修改的缺陷

定义：

A类：

新发现的缺陷

B类：

已发现的缺陷

C类：

已发现未修改的缺陷

产品撤销、下线

项目经理

4缺陷类型定义

本规范定义以下五类缺陷：

级别

描述

1-紧急

由于程序所引起的死机,非法退出

功能未实现或功能不符

出现死循环

导致数据库发生死锁

数据通讯错误，数据流错误

严重的数值计算错误

2-较高

程序接口错误

轻微的数值计算错误

界面错误（详细文档）

打印内容、格式错误

3-中等

简单的输入限制未放在前台进行控制

删除操作未给出提示

辅助说明描述不清楚

显示格式不规范

长时间操作未给用户进度提示

4-轻微

提示窗口文字未采用行业术语

可输入区域和只读区域没有明显的区分标志

系统处理未优化

微小的问题，几乎不影响功能；

如界面上错误字

建议增加或修改优化操作

5测试标准

软件测试合格须符合以下标准。

A类错误

B类错误

C类错误

D类错误

无

≤2%

≤4%

以上比例为错误占总测试模块的比例。

软件产品未经测试合格，不允许投运（延后处理、转为需求缺陷的除外）。

6争议处理

如开发团队对测试结论有争议，由验收组成员会议协调解决。

测试团队和开发团队应无条件服从仲裁结果。

7标准文档

《软件测试任务书》

《软件测试计划书》

《软件测试用例单》

《软件测试用例评审报告》

《系统测试报告》

《性能测试报告》

《项目测试工作总结》