软件产品(项目)质量管理方案

软件产品（项目）质量管理方案

研发部

变更记录

目录

1概述 (1)

1.1编写目的 (1)

1.2使用范围 (1)

2质量保证体系介绍 (1)

2.1预防体系 (1)

2.2有效检查体系 (1)

2.3快速抢救体系 (2)

3产品发布前资料 (2)

3.1需求规格说明书 (2)

3.1.1需求规格说明书重要性 (2)

3.1.2需求变更 (3)

3.2测试计划 (3)

3.2.1测试计划重要性 (3)

3.2.2测试计划内容 (3)

3.3测试用例 (4)

3.3.1测试用例重要性 (4)

3.3.2测试用例内容 (4)

3.3.3测试用例标准 (5)

3.3.4测试用例评审 (5)

3.4测试日志 (5)

3.4.1测试日志重要性 (5)

3.4.2测试执行 (5)

3.4.3BUG管理跟踪 (6)

3.5测试总结报告 (6)

3.5.1测试总结 (6)

3.5.2报告内容 (6)

4产品发布条件 (7)

4.1缺陷等级 (7)

4.2发布条件 (9)

1概述

1.1编写目的

制定本方案的目的是为了协助项目组保证软件产品（项目）质量，以保证所交付的软件能够满足项目预定需求，能够满足经领导小组评审批准的软件产品（项目）需求规格说明书中规定的各项具体需求。

1.2使用范围

本方案作为本部门在软件开发、测试时的质量要求，以保证软件产品（项目）质量。

2质量保证体系介绍

为保证软件产品（项目）质量，应该建立三套体系：预防体系，有效检查体系、快速抢救体系。

2.1预防体系

预防体系能在软件开发过程中有效地防止工作成果产生缺陷。主要措施有：

（1）专家培训，不断提高项目组成员的技术水平、业务水平；

（2）流程化，不断提高规范化水平，把经验和教训固化在流程中，流程化的目的是希望产品质量不要依赖于人，而是要依赖于流程、制度、规范，当然流程化不仅仅是把流程

整理出来，还要在运行过程中不断优化，保证流程确实是好用的、容易执行的。

（3）复用化，实现相同的功能尽量复用现有代码，或者把公共功能做成模块，便于大家复用，减少重复开发。

2.2有效检查体系

有效检查体系能在软件开发过程中能尽早发现问题，尽早解决问题，这样付出的代价最小。主要措施有：

（1）技术评审，请专业技术人员对技术方案、思路进行评审，在编码之前找出可能的问题。

设计时就埋下的缺陷隐患在后期是很难解决的。设计不好的软件就像体质不好的人，后

期再多的调理也收效甚微。

（2）代码评审，评审工作主要看代码是否与当初的设计方案一致，这样我们就能最大限制减少问题的产生。

（3）测试，测试是软件质量保证重要的一个环节。测试人员首先熟悉软件需求规格说明书后，开始着手测试方面的工作，包含编写测试计划、测试用例，执行测试，测试总结，BUG

跟踪，回归测试等。

2.3快速抢救体系

快速抢救体系是指在软件产品发布之后，客户发现的问题要尽早回应、解决，尽量减少对客户和公司的影响。

3产品发布前资料

3.1需求规格说明书

3.1.1需求规格说明书重要性

软件需求规格说明书在软件项目开发周期中有着非常重要的作用，是整个项目周期中最核心的依据，不管是设计还是编码，都要围绕它进行，否则产品就会偏离方向，成为一个不合格的产品。

同时需求规格说明书对测试来说也有着非常重要的作用，测试相关的一切行为都要紧密围绕着它进行，一份好的测试用例可以尽可能多的测出软件产品的缺陷来保障软件产品的质量，而写出一份好的测试用例必须是在熟悉软件规格说明书之后针对需求点来设计的。

需求规格说明书也能帮助项目组新进成员快速了解软件的功能需求，快速融入团队。所以一定要重视需求规格说明书。

3.1.2需求变更

在开发过程中，难免会遇到需求变更的情况，这时就要求我们一定要做好记录，及时更新，使软件的每个功能点都能找到对应的原始需求点，保持需求规格说明书的有效性。

3.2测试计划

3.2.1测试计划重要性

测试计划是软件测试中重要的一步，在熟悉软件需求后开始编写测试计划，目的是指导测试组成员进行测试工作，对软件产品（项目）的测试工作有一个宏观的规划，同时它也是编写测试用例的重要依据。

3.2.2测试计划内容

测试计划内容包含测试目的、测试环境、测试内容、测试工具、功能点分析、测试重点及难点分析、测试完成和终止的标准、测试时间及人员安排等。

测试环境：包含硬件环境和软件环境，其中硬件环境包含服务器配置型号、网络设备等；软件环境包含操作系统、数据库和各中间件详细信息。

测试工具：包含性能测试工具，BUG管理工具等。

功能点分析：对软件功能点模块进行分析，列出功能点。

测试重难点分析：列出软件测试的重点和难点模块和功能，便于在资源有限的情况下向重点模块倾斜；

测试终止的标准：制定测试终止的标准，如冒烟测试（产品主要功能或主业务流程）不通过则终止系统测试，或者项目暂停等；

测试完成的标准：制定测试完成的标准，如执行完所有用例，一级、二级、三级缺陷已全部修复，四级缺陷修复率>90%等。

测试时间及人员安排：计划通过几轮测试，每一轮测试的时间安排及测试人员安排等情况。

3.3测试用例

3.3.1测试用例重要性

测试用例是测试执行的依据，没有测试用例的测试随机性强、不够系统化、全面化，全凭测试人员的主观意愿，想到哪测到哪，容易漏测，所以一定要依据测试用例来执行测试。

在熟悉需求规格说明书和测试计划完成后要开始编写测试用例，测试用例要全面、合理，要针对功能点和需求点来逐步设计，同时在测试执行过程中如果发现用例不合理的要及时更新，漏掉的部分要及时补上。

3.3.2 测试用例内容

测试用例主要由6部分构成：所属的模块、名称、编号、预制（前提）条件、操作步骤、预期结果。

所属模块：当前用例所属软件的功能模块，复杂系统建议采用一级模块、二级模块。

用例编号：一般采用模块编号+用例编号组成，方便快速定位到用例。

用例名称：要求熟练的测试人员看见名称就大概明白测试用例所测试的点，不要求描述过分详细，尽量简短、精练。

预制（前提）条件：就是在执行操作步骤前，系统需要达到的状态。

操作步骤：如果有多个步骤，每一个步骤都需要填上序号，每一行一个步骤，不能写得过于简略，至少要让熟悉过系统的测试人员可以执行，也建议不要写得太复杂。

预期结果：如果有多个检查点，需要都罗列出来，每一行一个标号，让人一目了然有几个结果检查点，另外检查点尽量写详细些，不要出现结果正常、不正常等字眼，应该描述出正常的具体情况。