质量评价体系建设

1、软件质量评价体系（初稿）xxx修改历史日期版本作者修改内容2018/01/261.0 xxx新建正式批准角色签名日期备注目录 TOC o 1-5 h z HYPERLINK l bookmark2 o Current Document .目的5.范围5 HYPERLINK l bookmark4 o Current Document .参考资料5 HYPERLINK l bookmark6 o Current Document .测试过程描述6测试流程图6 HYPERLINK l bookmark8 o Current Document 活动说明7 HYPERLINK l bookmark10

2、 o Current Document 需求评审 7 HYPERLINK l bookmark12 o Current Document 测试计划9 HYPERLINK l bookmark14 o Current Document 功能测试设计10 HYPERLINK l bookmark16 o Current Document 功能测试执行11 HYPERLINK l bookmark18 o Current Document 集成/性能测试设计 14 HYPERLINK l bookmark20 o Current Document 集成/性能测试执行 15 HYPERLINK l b

3、ookmark22 o Current Document 测试报告17 HYPERLINK l bookmark24 o Current Document 测试维护18 HYPERLINK l bookmark26 o Current Document .缺陷管理 20 HYPERLINK l bookmark28 o Current Document 目的20 HYPERLINK l bookmark30 o Current Document 角色与职责20 HYPERLINK l bookmark32 o Current Document 缺陷管理流程 21新建缺陷22修复缺陷22验证缺陷

4、22 HYPERLINK l bookmark34 o Current Document 缺陷管理系统部分字段详解 22规范25 HYPERLINK l bookmark36 o Current Document 6.配置管理25目的25 HYPERLINK l bookmark38 o Current Document 配置项26 HYPERLINK l bookmark40 o Current Document 测试环境配置26规范26测试类以有效1.目的本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总

5、体规范， 保证软件质量。本文适用于软件测试人员。3.参考资料文档评审指南项目测试计划模版测试用例模版测试执行规范项目测试报告模版测试用例配置管理缺陷模板SVN提交规范软件测试环境发布流程4.测试过程描述4.1测试流程图测试维护4.2活动说明需求评审目的确保产品需求文档可以全面、清晰地描述产品的功能和性能；确保项目组成员对需求的理解达到一致。角色与职责需求人员：需求规格说明书的编写，以及软件开发过程中需求规格说明书的修 正。评审人员：评审需求规格说明书，从全面性、完整性、正确性、一致性、可靠性方 面检查需求规格说明书，将需求缺陷提交给需求人员，并跟踪需求缺 陷直至需求缺陷验证关闭。评审人员应由开

6、发人员与测试人员共同组成。启动标准需求规格说明书编写完成4.2.1.4工作流程图4.2.1.5输入/输出输入：需求规格说明书输出：需求缺陷4.2.1.6 规范参见文档评审指南测试计划目的明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试 过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。角色与职责测试负责人：根据项目整体计划、需求规格说明书编制测试计划 ，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便 测试工作正常开展。测试计划实际编写内容参见项目测试计划模版。启动标准需求评审完成，项目整体计划编制完成工作流程图测试计划测试负责人

7、测试计划编写测试计划编写完成并知会相关人员输入/输出输入：需求规格说明书、项目整体计划输出：测试计划规范测试计划编写内容参见测试计划模版功能测试设计目的通过多种测试方法编写测试用例，以使最少的测试用例，件功能的正确性，从而提升软件质量。角色和职责测试人员：采用多种测试方法编写有效的测试用例，并对遗漏 正。评审人员：对测试人员编写的测试用例进行评审，提出遗漏 直至用例缺陷的验证关闭。启动标准实现最大的测试覆盖，保证软/错误的测试用例进行修/错误的用例缺陷，并跟踪需求文档评审完成，且测试计划制定完成。工作流程图测试设计测试人员输入输出输入：需求规格说明书输出：测试用例、测试用例评审缺陷规范测试用例

8、实际内容参见测试用例模版功能测试执行目的依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度。角色与职责测试人员：依据测试计划，按照测试用例对软件进行测试。对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。 在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。开发人员：对于测试人员提交的缺陷进行确认、修复。评审人员：对测试人员与开发人员意见不一的问题进行裁决。当测试人员与开发人员对缺陷有效性的意见不统一时，评审人员应总合各方面意见，对缺陷有效性作 出最终判定。评审人员应由测试负责人、开发负责人和需求人员共同组成。启动标准测试

9、用例编写完成，且用例评审完成。工作流程图输入输出输入：功能测试用例输出：功能测试缺陷5.缺陷管理进行。规范测试执行过程需按照测试执行规范进行，缺陷管理需按照本文集成/性能测试设计目的为集成测试提供测试依据，记录并保证集成测试覆盖度；依据测试计划及性能指标进行性能测试用例设计、性能测试脚本开发，保证性能测试有序进行。角色和职责测试人员：以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计；依据性能指标及测试计划编写性能测试用例、开发性能测试脚本。启动标准功能测试完成且软件功能无中断工作流程图集成/性能测试设计测试人员注：此处两文档编写 无先后关系输入输出输入：功能测试用例、功能测试

10、缺陷、测试计划、性能指标输出：集成测试用例、性能测试用例、性能测试脚本规范集成测试用例实际内容参见测试用例模版集成/性能测试执行目的以整个软件为对象，以测试计划为指导，按照集成测试用例对新功能、老功能、新老功 能接口进行测试和性能测试，以保证测试的全面性和完整性。角色和职责测试人员：以整个软件为对象，以测试计划为指导，按照集成测试用例对新功能、老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。启动标准集成/性能测试设计完成工作流程图输入输出输入：集成测试用例、测试计划、性能测试计划、性能测试用例输出：集成测试缺陷5.缺陷管理进行。规范测试执行过程需按照测试行为规范进行，缺陷管

11、理需按照本文测试报告目的真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化/图像化进行分析，真实反映软件质量实际情况。角色与职责测试负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。启动标准测试执行完成。工作流程图测试报告测试负责人收集整理各测试阶段、测试项实际测试情况编写测试报告输入输出输入：各测试阶段、测试项实际测试情况输出：项目测试报告规范项目测试报告实际内容参见项目测试报告模版测试维护目的软件产品的版本是随着软件的升级而不断变化的，而每一次版本的变化都会对测试用例库产生影响，所以测试用例库也需要

12、不断地变更和维护，使之与产品的变化保持一致。角色与职责测试负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字/图像的形式对实际情况进行分析，真实反映软件实际测试状况。启动标准测试执行完成。工作流程图测试维护测试人员注：此处三个维护行为 无先后关系输入输出输入：测试用例、测试用例库 输出：更新后的测试用例库规范测试用例的管理参见测试用例配置管理5.缺陷管理目的对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准角色与职责参与缺陷流转的角色有三个：测试人员、开发人员和评审人员。测试人员：依据测试计划，按照测试用例对软件进行测试。对于发现的缺陷必须记录，并且跟踪缺陷的状

13、态， 直至缺陷的验证关闭。 在测试执行过程中发现的 遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。开发人员：对于测试人员提交的缺陷进行确认、修复。评审人员：对测试人员与开发人员意见不一的问题进行裁决。当测试人员与开发人员对缺陷有效性的意见不统一时，评审人员应总合各方面意见，对缺陷有效性作 出最终判定。评审人员应由测试负责人、开发负责人和需求人员共同组成。5.3缺陷管理流程缺陷管理流程段 阶测试人员提出BugNo意见是否统一Yes记录为无效Bug验证Bug是否修复Yes关闭Bug缺陷的处理步骤如下:开发人员评审人员是否有效YesNo认BugNoNoYes判定Bug是否有效5.3

14、.1新建缺陷缺陷的提出人负责在缺陷管理系统中新建缺陷，并对缺陷的基本情况进行描述。缺陷的基本信息主要包括：缺陷描述、紧急程度、严重程度、处理人员等。提出人在登记缺陷时，必须确定所输入的缺陷内容要描述清楚，产生缺陷的步骤描述 要完整，使缺陷能够被重现出来。在描述缺陷产生的步骤上，务必简易清楚。提出人可以利用错误抓图等方式进行补充描述。修复缺陷当有多个缺陷同时打开时，开发人员应首先修复紧急程度更高的缺陷。开发人员首先分析缺陷，并将缺陷状态更改为“处理中” 。当开发人员确定该缺陷不是有效的缺陷时，则将缺陷状态更改为“拒绝”，并添加注释详细填写拒绝的原因。最终由测试人员将该缺陷记录为“无效”。若在此过

15、程中开发人员与测试人员对缺陷有效性的意见不统一，应进行缺陷评审，由评审人员判定。当确认该缺陷有效时，开发人员应按照要求修复缺陷。缺陷修复后，开发人员需添加注释详细填写修复的内容、缺陷根源、修复版本，更改缺陷状态为“待验证”。当确认该缺陷不是本系统引起，需要其它项目组协同进行分析解决，开发人员应保持缺陷状态为“处理”，并将该缺陷的“处理人员”改为相应的项目组人员，以便缺陷能及时流 转。验证缺陷测试人员负责验证缺陷是否已解决。如已解决则关闭缺陷，否则将“缺陷状态”更改 为“重开”，以便开发人员重新对此缺陷进行处理。缺陷管理系统部分字段详解缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。包括：新建、

16、处理中、拒绝、无效、待验证、重开、关闭由提出人初步指定，开发人缺陷严重程度：是指因缺陷引起的故障对系统的影响程度。 员负责确认。缺陷级别定义帮助和示例一级问题 （致命问 题）A1、死机、重启、内存泄漏、自动关机；软件在待机或者使用时出现死机、报错、系统重 启、自动关机、瘫痪等造成无法使用的问题；无 法开机；操作应用时内存不足，造成大量软件应 用不能使用的情况；2、花屏、白屏等屏幕异常现象；唤醒后屏幕、键盘失效；屏幕出现花屏、白屏现 象；3、系统无响应；待机或者使用中系统没有响应；电话不能呼出、 拨入或呼通率低于 95蛆下，单通（1%Z上）； 通话不能挂断，短信不能收发，延迟（非网络问 题）；屏

17、幕无法点亮，屏幕半亮无法使用，屏幕 灰屏无法使用等；4、出现数据丢失、数据库被破坏或者损 坏用户器件；系统数据丢失或出现数据库破坏现象给用户带来 损失；任意应用一直报错无法正常使用机器；5、手机卡不能被识别；掉网，脱网；在使用时出现不能识别 SIM卡/T卡；烧坏手机卡， 损坏T卡，给用户带来损失的情况； SIM卡无法 识别网络；掉网或脱网；6、危机用户安全的；手机发烫，异常啸叫；可能造成用户听力、视觉 或者其他人身损伤的。二级问题（严重问 题）1、基本业务功能未实现；基本业务功能处理不符合协议；产品定义中需求 的基本功能没有实现；2、应用程序自动退出或失效；通信方面出现单通（小于等于 1%）、

18、通话回音、 通话啸叫、电流音、信号漂移、重新搜网、掉卡、 通话自动挂断、三方通话出现问题、短信业务出 现接收延迟（小于等于 1小时）、丢短信（丢失 率大于3%）、经常发送失败等现象；网络自动断 网、连接失败及无数据交换的基本功能；应用程 序自动退出，或提示强制关闭/无响应关闭；B3、自动亮屏；软件在使用过程中应用软件自动退出，或者某些 功能失效；4、软件使用造成系统反应慢；在使用过程中整个系统运行速度逐渐变慢，造成 系统性能下降；5、客户反馈问题；客户反馈问题根据客户定义级别来报（没有定义 的，应标识为二级严重问题）。客户包括第三方 合作伙伴；6、不符合国家法律法规的，或会引起民 族或文化争议

19、的问题；不能出现违反国家法律法规信息，不能出现引起 民族或矛盾的信息；7、参数设置异常；参数设置不能保存或失效；8、用户界面信息异常；提示信息与实际不符，显示不全、漏显示、重叠、 错误、乱码或者不美观等现象；大范围的 UI、文 字、声音、图案、灯光提示错误、不准确；三级问题 （一般问 题）C1、主要功能已实现，存在影响用户正常 使用的问题；软件应用的部分功能的失效，或者操作某功能响 应慢，界面刷新不及时；四级问题 （轻微问 题）D1、轻微、提示性问题，不影响系统功能帮助文件、提示信息缺少或可读性差、用词不当、 错别字及不易于理解的描述；2、操作复杂或用户不常操作到的路径；操彳3级以上菜单功能出

20、现的问题；操作多个模 块（超过3个）交互后出现的问题3、需要提示信息的地方没有相应提醒；收费业务在用户订阅前没有提示信息；4、用户使用不便或者容易出现误操作；操作功能使用不方便，并且不方便的程度很轻微；5、建议性问题以使软件可用性更强；外观色彩、字体大小显示更适合长时间使用；提 示音不应有特别刺耳或者容易让人疲劳的情况； 增加一些简单功能使软件更人性化；删除多余的 功能；缺陷紧急程度：指缺陷必须被修复的紧急程度。由提出人指定。各测试小组可以项目组具体协商约定紧急程度的具体含义。包括：高、中、低缺陷起源：指引起缺陷的起因。由开发人员初步指定，测试人员负责确认。包括：需求、架构、设计、编码、测试、环境、数据、无效缺陷根 源类型含义需求由于需求定义或需求分析引起的缺陷架构由于企业架构设计的问题引起的缺陷设计由于本系统设计原因引起的缺陷编码由于编码的问题引起