软件产品（项目）质量管理方案研发部变更记录目录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部分构成：所属的模块、名称、编号、预制（前提）条件、操作步骤、预期结果。

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

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

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

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

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

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

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

在编写测试用例时应遵循如下标准：（1）测试用例书写格式正确、描述清晰，其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去；（2）测试用例对测试点覆盖完全，也就是说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缺陷等级缺陷等级指因缺陷引起的故障对软件产品的影响程度。

4.2发布条件软件产品（项目）重大版本发布前需由测试组成员检查需求规格说明书、测试计划、测试用例、测试日志、测试总结报告五份材料，并对软件产品进行抽查测试，必须同时满足下列五个条件才能发布：（1）上述五份资料齐全，交由测试组审查，其中软件需求规格说明书是更新后用户确认过的，测试用例有评审记录，系统全面测试次数不得低于两轮，且每一轮都必须有测试日志和测试总结报告；（2）最后一轮全面测试的用例执行覆盖率不得低于95%；（3）测试需求执行覆盖率应达到100%（业务测试用例均已执行）；（4）检查测试总结报告和禅道系统中BUG修复情况，最终缺陷数量及修复率：一级缺陷（致命）等于0；二级缺陷（严重）等于0；三级缺陷（一般）等于0；四级缺陷（轻微）修复率>90%；（5）测试组根据需求规格说明书和测试用例对软件进行抽查测试：缺陷率（失败的测试用例/所有经过测试的用例数*100%）<5%。