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

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

变更记录版本号变更说明变更人变更日期审核人审核日期V1.0初稿TOC\o"1-5"\h\z概述 1编写目的 1\o"CurrentDocument"使用范围 1\o"CurrentDocument"质量保证体系介绍 1\o"CurrentDocument"预防体系 1\o"CurrentDocument"有效检查体系 1\o"CurrentDocument"快速抢救体系 2产品发布前资料 2需求规格说明书 2需求规格说明书重要性 2\o"CurrentDocument"需求变更 3测试计划 3测试计划重要性 3\o"CurrentDocument"测试计划内容 3测试用例 4测试用例重要性 4\o"CurrentDocument"测试用例 内容 4\o"CurrentDocument"测试用例标准 5\o"CurrentDocument"测试用例评审 5测试日志 5测试日志重要性 5\o"CurrentDocument"测试执行 5\o"CurrentDocument"BUG管理跟踪 6测试总结报告 6测试总结 6\o"CurrentDocument"报告内容 6产品发布条件 7缺陷等级 7\o"CurrentDocument"发布条件 9概述编写目的制定本方案的目的是为了协助项目组保证软件产品（项目）质量，以保证所交付的软件能够满足项目预定需求，能够满足经领导小组评审批准的软件产品（项目）需求规格说明书中规定的各项具体需求。使用范围本方案作为本部门在软件开发、测试时的质量要求，以保证软件产品（项目）质量。质量保证体系介绍为保证软件产品（项目）质量，应该建立三套体系：预防体系，有效检查体系、快速抢救体系。预防体系预防体系能在软件开发过程中有效地防止工作成果产生缺陷。主要措施有：） 专家培训，不断提高项目组成员的技术水平、业务水平；流程化，不断提高规范化水平，把经验和教训固化在流程中，流程化的目的是希望产品质量不要依赖于人，而是要依赖于流程、制度、规范，当然流程化不仅仅是把流程整理出来，还要在运行过程中不断优化，保证流程确实是好用的、容易执行的。复用化，实现相同的功能尽量复用现有代码，或者把公共功能做成模块，便于大家复用，减少重复开发。有效检查体系有效检查体系能在软件开发过程中能尽早发现问题，尽早解决问题，这样付出的代价最小。主要措施有：（1）技术评审，请专业技术人员对技术方案、思路进行评审，在编码之前找出可能的问题。设计时就埋下的缺陷隐患在后期是很难解决的。 设计不好的软件就像体质不好的人， 后期再多的调理也收效甚微。代码评审，评审工作主要看代码是否与当初的设计方案一致，这样我们就能最大限制减少问题的产生。测试， 测试是软件质量保证重要的一个环节。 测试人员首先熟悉软件需求规格说明书后，开始着手测试方面的工作，包含编写测试计划、测试用例，执行测试，测试总结， BUG跟踪，回归测试等。快速抢救体系快速抢救体系是指在软件产品发布之后，客户发现的问题要尽早回应、解决，尽量减少对客户和公司的影响。产品发布前资料需求规格说明书需求规格说明书重要性软件需求规格说明书在软件项目开发周期中有着非常重要的作用，是整个项目周期中最核心的依据，不管是设计还是编码，都要围绕它进行，否则产品就会偏离方向，成为一个不合格的产品。同时需求规格说明书对测试来说也有着非常重要的作用，测试相关的一切行为都要紧密围绕着它进行，一份好的测试用例可以尽可能多的测出软件产品的缺陷来保障软件产品的质量， 而写出一份好的测试用例必须是在熟悉软件规格说明书之后针对需求点来设计的。需求规格说明书也能帮助项目组新进成员快速了解软件的功能需求，快速融入团队。所以一定要重视需求规格说明书。需求变更在开发过程中，难免会遇到需求变更的情况，这时就要求我们一定要做好记录，及时更新，使软件的每个功能点都能找到对应的原始需求点，保持需求规格说明书的有效性。测试计划测试计划重要性测试计划是软件测试中重要的一步，在熟悉软件需求后开始编写测试计划， 目的是指导测试组成员进行测试工作，对软件产品（项目）的测试工作有一个宏观的规划，同时 它也是编写测试用例的重要依据。测试计划内容测试计划内容包含测试目的、测试环境、测试内容、测试工具、功能点分析、测试重点及难点分析、测试完成和终止的标准、测试时间及人员安排等。测试环境：包含硬件环境和软件环境，其中硬件环境包含服务器配置型号、网络设备等；软件环境包含操作系统、数据库和各中间件详细信息。测试工具：包含性能测试工具， BUG管理工具等。功能点分析：对软件功能点模块进行分析，列出功能点。测试重难点分析：列出软件测试的重点和难点模块和功能，便于在资源有限的情况下向重点模块倾斜；测试终止的标准：制定测试终止的标准，如冒烟测试（产品主要功能或主业务流程）不通过则终止系统测试，或者项目暂停等；测试完成的标准：制定测试完成的标准，如执行完所有用例，一级、二级、三级缺陷已全部修复，四级缺陷修复率 >90%等。测试时间及人员安排：计划通过几轮测试，每一轮测试的时间安排及测试人员安排等情况。测试用例测试用例重要性测试用例是测试执行的依据，没有测试用例的测试随机性强、不够系统化、全面化，全凭测试人员的主观意愿，想到哪测到哪，容易漏测，所以一定要依据测试用例来执行测试。在熟悉需求规格说明书和测试计划完成后要开始编写测试用例 ，测试用例要全面、合理，要针对功能点和需求点来逐步设计， 同时在测试执行过程中如果发现用例不合理的要及时更新， 漏掉的部分要及时补上。测试用例内容测试用例主要由 6部分构成：所属的模块、名称、编号、预制（前提）条件、操作步骤、预期结果。所属模块：当前用例所属软件的功能模块，复杂系统建议采用一级模块、二级模块。用例编号：一般采用模块编号 +用例编号组成，方便快速定位到用例。用例名称：要求熟练的测试人员看见名称就大概明白测试用例所测试的点，不要求描述过分详细，尽量简短、精练。预制（前提）条件：就是在执行操作步骤前，系统需要达到的状态。操作步骤：如果有多个步骤，每一个步骤都需要填上序号，每一行一个步骤，不能写得过于简略，至少要让熟悉过系统的测试人员可以执行，也建议不要写得太复杂。预期结果：如果有多个检查点，需要都罗列出来，每一行一个标号，让人一目了然有几个结果检查点，另外检查点尽量写详细些，不要出现结果正常、不正常等字眼，应该描述出正常的具体情况。测试用例标准测试用例不是越多越好，相反如果测试用例中冗余用例太多，这样在执行测试用例会浪费大量测试人力，而且不会产生测试效果。在编写测试用例时应遵循如下标准：（1）测试用例书写格式正确、 描述清晰，其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去；测试用例对测试点覆盖完全，也就是说 BUG基本都是通过测试用例发现的，发现的比例越高越好，越高说明测试用例的防护能力越强，当然测试用例不可能特别完备，在我们执行测试用例的过程，如果 BUG不是通过用例发现的，我们需要对用例进行增加，更新用例库。测试用例评审测试用例编写完成后要进行评审，项目组成员对测试用例的正确性、合理性、全面性、可执行性进行评审，给出合理意见，通过评审的测试用例才能作为测试执行的依据。测试日志测试日志重要性测试人员依据测试用例对软件进行测试，记录每一条测试用例的执行结果，形成测试日志，对未执行的测试用例进行标注，并标明原因，便于下一轮测试优先考虑。在测试执行过程中，测试人员严格记录测试日志，可有效避免漏测的问题。测试日志是对测试执行过程的记录，形成过程管理文档，后期可追溯。测试执行测试人员按照测试用例严格执行测试，并将测试过程中产生的 BUG记录到禅道系统中，录入BUG时，将问题、重现步骤、环境（浏览器版本、操作系统）等信息描述准确，尽量配合截图，方便开发人员一目了然了解问题， 同时标明优先级和缺陷等级， 可供开发人员优先处理优先级和缺陷等级高的 BUG。BUG管理跟踪录入禅道中的 BUG要及时跟踪， 开发人员修复后要进行回归测试， 验证通过关闭， 未通过再次激活，并指派给相应的开发人员，直到 BUG关闭为止。测试总结报告测试总结每一轮测试完成后，要及时总结，同时对 BUG进行统计和分析，对于发现 BUG较多的模块要重点再测一遍， 测试完成后要及时编写总结报告， 方便项目经理及项目组成员快速了解本轮测试的情况及当前软件版本中 BUG情况。测试总结报告还有以下作用：反馈：对版本测试结果反馈至产品经理、项目经理、开发人员、测试人员；督促：对测试结果问题分类分析展示，在各方的相互督促下，会促进 BUG的解决；汇报：向上级汇报、向下级、平级反馈；展示：通过总结报告，不仅直观展示测试人员的工作成果，也很好的展示自己的工作内容。报告内容测试总结报告包含测试基本信息 （软件版本、 测试人员、 测试周期） 、软硬件环境、 需求覆盖率、测试用例执行情况、测试执行率、 BUG统计及分布等、测试结论、测试总结及建议。软件版本：当前测试的软件版本；需求覆盖率：执行的测试用例覆盖的需求数 /总的需求数量 *100%；执行测试用例情况：用例执行总数、通过用例数、未通过用例数、阻塞用例数；测试执行率 =已执行的用例数 /用例总数 *100%，如果有未执行用例，说明原因，并分析对测试结果有无影响；BUG统计：按缺陷等级统计缺陷数量及各等级 BUG占比；BUG分布：按模块统计缺陷数量及各模块 BUG占比；测试结论：依据 BUG情况，给出测试是否通过结论，并列出论据；测试总结及建议：本轮测试的情况总结，并给出建议。产品发布条件.1缺陷等级缺陷等级指因缺陷引起的故障对软件产品的影响程度。严重级别对应缺陷严重等级描述系统崩或挂起等导致系统不能继续运行。包括以下各种错误：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。1）由于程序引起的死机，非法退出；2）数据库发生死锁或连接数据库错误；一级致命缺陷3）死循环；4）主要功能丢失或功能严重错误；5）数据流错误；6）严重的数值计算错误；7）因错误操作导致程序中断；8）主要的业务流程不正确。严重地影响系统要求或基本功能的实现， 使系统不稳定、 或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。包括以下各种错误：）造成数据库不稳定的错误；2）系统可被执行，但操作功能无法执行；二级 严重缺陷3）功能的实现不完整；4）需求规格说明书中的需求未在最终系统中实现；5）产生错误结果；6）次要的业务流程不正确；7）界面错误。严重地影响系统要求或基本功能的实现，但存在合理的更正办法。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。包括以下各种错误：1）提示信息不太准确或用户界面差、操作时间长等一些问题；2）操作界面错误（包括数据窗口内列名定义、含义是否一致） ；三级 一般缺陷 3）打印内容、格式错误（只影响格式和外观，不影响数据结果的错误）4）简单的输入限制未放在前台进行控制；5）删除操作未给出提示；5）不能定位焦点或者定位有误，影响功能实现；6）显示格式不正确但输出正确；7）虽然正确性、功能不受影响，但系统性能和响应时间受影响。

使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题。包括以下各种错误：1）系统的提示语不明确，不简单明了，容易给用户错误和歧义的提示；2）滚动条无效；3）可编辑区域和不可编辑区域不明显；4）必填项与非必填项未加以区别；5）界面不一致，或界面不正确；轻微缺陷6）光标跳转设置不好，鼠标（光标）定位错误；轻微缺陷7）输入输出不规范；8）长时间操作未给用户提示；9）键盘支持不好，如在可输入多行的字段中，不支持回车换行；10）页面不能及时刷新，影响功能实现；）上下翻页，首位页定位错误；12）日期或时间初始值错误（起止日期、时间没有限定） ；13）出现错别字，标点符号错误，拼写错误，以及不正确的大小写等；14）一些建议性问题。4.2发布条件软件产品（项目）重大版本发布前需由测试组成员检查需求规格说明书、测试计划、测试用例、测试日志、测试总结报告五份材料，并对软件产品进行抽查测试，必须同时满足下列五个条件才能发布：上述五份资料齐全，交由测试组审查，其