软件产品项目质量管理方案.docx

软件产品项目质量管理方案.docx

《软件产品项目质量管理方案.docx》由会员分享，可在线阅读，更多相关《软件产品项目质量管理方案.docx（11页珍藏版）》请在冰豆网上搜索。

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

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

研发部

变更记录

版本号

变更说明

变更人

变更日期

审核人

审核日期

V1.0

初稿

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部分构成：

所属的模块、名称、编号、预制（前提）条件、操作步骤、预期结果。

所属模块：

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

用例编号：

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

用例名称：

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

预制（前提）条件：

就是在执行操作步骤前，系统需要达到的状态。

操作步骤：

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

预期结果：

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

3.3.3测试用例标准

测试用例不是越多越好，相反如果测试用例中冗余用例太多，这样在执行测试用例会浪费大量测试人力，而且不会产生测试效果。

在编写测试用例时应遵循如下标准：

（4）测试用例书写格式正确、描述清晰，其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去；

（5）测试用例对测试点覆盖完全，也就是说BUG基本都是通过测试用例发现的，发现的比例越高越好，越高说明测试用例的防护能力越强，当然测试用例不可能特别完备，在我们执行测试用例的过程，如果BUG不是通过用例发现的，我们需要对用例进行增加，更新用例库。

3.3.4测试用例评审

测试用例编写完成后要进行评审，项目组成员对测试用例的正确性、合理性、全面性、可执行性进行评审，给出合理意见，通过评审的测试用例才能作为测试执行的依据。

3.4测试日志

3.4.1测试日志重要性

测试人员依据测试用例对软件进行测试，记录每一条测试用例的执行结果，形成测试日志，对未执行的测试用例进行标注，并标明原因，便于下一轮测试优先考虑。

在测试执行过程中，测试人员严格记录测试日志，可有效避免漏测的问题。

测试日志是对测试执行过程的记录，形成过程管理文档，后期可追溯。

3.4.2测试执行

测试人员按照测试用例严格执行测试，并将测试过程中产生的BUG记录到禅道系统中，录入BUG时，将问题、重现步骤、环境（浏览器版本、操作系统）等信息描述准确，尽量配合截图，方便开发人员一目了然了解问题，同时标明优先级和缺陷等级，可供开发人员优先处理优先级和缺陷等级高的BUG。

3.4.3BUG管理跟踪

录入禅道中的BUG要及时跟踪，开发人员修复后要进行回归测试，验证通过关闭，未通过再次激活，并指派给相应的开发人员，直到BUG关闭为止。

3.5测试总结报告

3.5.1测试总结

每一轮测试完成后，要及时总结，同时对BUG进行统计和分析，对于发现BUG较多的模块要重点再测一遍，测试完成后要及时编写总结报告，方便项目经理及项目组成员快速了解本轮测试的情况及当前软件版本中BUG情况。

测试总结报告还有以下作用：

反馈：

对版本测试结果反馈至产品经理、项目经理、开发人员、测试人员；

督促：

对测试结果问题分类分析展示，在各方的相互督促下，会促进BUG的解决；

汇报：

向上级汇报、向下级、平级反馈；

展示：

通过总结报告，不仅直观展示测试人员的工作成果，也很好的展示自己的工作内容。

3.5.2报告内容

测试总结报告包含测试基本信息（软件版本、测试人员、测试周期）、软硬件环境、需求覆盖率、测试用例执行情况、测试执行率、BUG统计及分布等、测试结论、测试总结及建议。

软件版本：

当前测试的软件版本；

需求覆盖率：

执行的测试用例覆盖的需求数/总的需求数量*100%；

执行测试用例情况：

用例执行总数、通过用例数、未通过用例数、阻塞用例数；

测试执行率=已执行的用例数/用例总数*100%，如果有未执行用例，说明原因，并分析对测试结果有无影响；

BUG统计：

按缺陷等级统计缺陷数量及各等级BUG占比；

BUG分布：

按模块统计缺陷数量及各模块BUG占比；

测试结论：

依据BUG情况，给出测试是否通过结论，并列出论据；

测试总结及建议：

本轮测试的情况总结，并给出建议。

4产品发布条件

4.1缺陷等级

缺陷等级指因缺陷引起的故障对软件产品的影响程度。

严重级别

对应缺陷严重等级

描述

一级

致命缺陷

不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。

系统崩或挂起等导致系统不能继续运行。

包括以下各种错误：

1）由于程序引起的死机，非法退出；

2）数据库发生死锁或连接数据库错误；

3）死循环；

4）主要功能丢失或功能严重错误；

5）数据流错误；

6）严重的数值计算错误；

7）因错误操作导致程序中断；

8）主要的业务流程不正确。

二级

严重缺陷

严重地影响系统要求或基本功能的实现，使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。

包括以下各种错误：

1）造成数据库不稳定的错误；

2）系统可被执行，但操作功能无法执行；

3）功能的实现不完整；

4）需求规格说明书中的需求未在最终系统中实现；

5）产生错误结果；

6）次要的业务流程不正确；

7）界面错误。

三级

一般缺陷

严重地影响系统要求或基本功能的实现，但存在合理的更正办法。

系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。

包括以下各种错误：

1）提示信息不太准确或用户界面差、操作时间长等一些问题；

2）操作界面错误（包括数据窗口内列名定义、含义是否一致）；

3）打印内容、格式错误（只影响格式和外观，不影响数据结果的错误）；

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

5）删除操作未给出提示；

5）不能定位焦点或者定位有误，影响功能实现；

6）显示格式不正确但输出正确；

7）虽然正确性、功能不受影响，但系统性能和响应时间受影响。

四级

轻微缺陷

使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

界面拼写错误或用户使用不方便等小问题或需要完善的问题。

包括以下各种错误：

1）系统的提示语不明确，不简单明了，容易给用户错误和歧义的提示；

2）滚动条无效；

3）可编辑区域和不可编辑区域不明显；

4）必填项与非必填项未加以区别；

5）界面不一致，或界面不正确；

6）光标跳转设置不好，鼠标（光标）定位错误；

7）输入输出不规范；

8）长时间操作未给用户提示；

9）键盘支持不好，如在可输入多行的字段中，不支持回车换行；

10）页面不能及时刷新，影响功能实现；

11）上下翻页，首位页定位错误；

12）日期或时间初始值错误（起止日期、时间没有限定）；

13）出现错别字，标点符号错误，拼写错误，以及不正确的大小写等；

14）一些建议性问题。

4.2发布条件

软件产品（项目）重大版本发布前需由测试组成员检查需求规格说明书、测试计划、测试用例、测试日志、测试总结报告五份材料，并对软件产品进行抽查测试，必须同时满足下列五个条件才能发布：

（1）上述五份资料齐全，交由测试组审查，其中软件需求规格说明书是更新后用户确认过的，测试用例有评审记录，系统全面测试次数不得低于两轮，且每一轮都必须有测试日志和测试总结报告；

（2）最后一轮全面测试的用例执行覆盖率不得低于95%；

（3）测试需求执行覆盖率应达到100%（业务测试用例均已执行）；

（4）检查测试总结报告和禅道系统中BUG修复情况，最终缺陷数量及修复率：

一级缺陷（致命）等于0；

二级缺陷（严重）等于0；

三级缺陷（一般）等于0；

四级缺陷（轻微）修复率>90%；

（5）测试组根据需求规格说明书和测试用例对软件进行抽查测试：

缺陷率（失败的测试用例/所有经过测试的用例数*100%）<5%