质量评价体系建设

软件质量评价体系（初稿）XXX修改历史日期日期版本作者修改内容2018/01/261.0xxx新建正式批准角色角色签名日期备注目录1•目的 52•范围 53•参考资料 54•测试过程描述 6测试流程图 6活动说明 7需求评审 7测试计划 9功能测试设计 10功能测试执行 11集成/性能测试设计 14集成/性能测试执行 15测试报告 17测试维护 18缺陷管理 205.1目的 20角色与职责 20缺陷管理流程 21新建缺陷 22修复缺陷 22验证缺陷 225.3缺陷管理系统部分字段详解 225.4规范 25配置管理 256.1目的 25配置项 26测试环境配置 266.4规范 26目的本文是对项目软件测试的指导性文件， 对软件测试过程中所涉及到的测试理论、 测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范，保证软件质量。2范围本文适用于软件测试人员。参考资料《文档评审指南》《项目测试计划模版》《测试用例模版》《测试执行规范》《项目测试报告模版》《测试用例配置管理》《缺陷模板》《SVN 提交规范》《软件测试环境发布流程》

以有效测试过程描述测试流程图测试维护活动说明目的确保产品需求文档可以全面、理解达到一致。

清晰地描述产品的功能和性能； 确保项目组成员对需求的角色与职责需求人员：《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正。评审人员：评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检查《需求规格应由开发人员与测试人员共同组成。启动标准《需求规格说明书》编写完成工作流程图输入/输出输入：《需求规格说明书》输出：需求缺陷规范参见《文档评审指南》测试计划目的明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制；保持测试过程的顺畅，有效控制和跟踪测试进度，应对测试过程中的各种变更。422.2角色与职责测试负责人：根据《项目整体计划》 、《需求规格说明书》编制《测试计划》 ，明确测试内容、测试任务安排、测试进度、测试策略、测试资源、风险控制，以便测试工作正常开展。测试计划实际编写内容参见《项目测试计划模版》 启动标准需求评审完成，《项目整体计划》编制完成工作流程图测试计划测试负责人输入/输出输入：《需求规格说明书》、《项目整体计划》输出：《测试计划》422.6规范测试计划编写内容参见《测试计划模版》功能测试设计目的通过多种测试方法编写测试用例， 以使最少的测试用例件功能的正确性，从而提升软件质量。角色和职责测试人员：采用多种测试方法编写有效的测试用例，并对遗漏正。评审人员：对测试人员编写的测试用例进行评审，提出遗漏直至用例缺陷的验证关闭。启动标准需求文档评审完成，且测试计划制定完成。

实现最大的测试覆盖，保证软/错误的测试用例进行修/错误的用例缺陷，并跟踪工作流程图测试设计测试人员输入输出输入：《需求规格说明书》输出：《测试用例》、测试用例评审缺陷规范测试用例实际内容参见《测试用例模版》功能测试执行目的依据测试计划，按照测试用例对软件进行测试，验证软件功能与需求的实际匹配程度。424.2角色与职责测试人员：依据测试计划，按照测试用例对软件进行测试。对于发现的缺陷必须记录，并且跟踪缺陷的状态， 直至缺陷的验证关闭。在测试执行过程中发现遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。开发人员：对于测试人员提交的缺陷进行确认、修复。评审人员：对测试人员与开发人员意见不一的问题进行裁决。 当测试人员与开发人员对缺陷有效性的意见不统一时，评审人员应总合各方面意见，对缺陷有效性作出最终判定。评审人员应由测试负责人、开发负责人和需求人员共同组成。4.2.4.3启动标准测试用例编写完成，且用例评审完成。424.4工作流程图测试执行测试人员测试执行开始按照测试用例进行软件测试No 是否发现缺陷 发现缺陷测试顺利通过是否全部测试用例执行完成■■■<Yes测试执行完成4.245输入输出输入：功能测试用例输出：功能测试缺陷4.2.4.6规范测试执行过程需按照《测试执行规范》进行，缺陷管理需按照本文 5缺陷管理进行。集成/性能测试设计目的为集成测试提供测试依据，记录并保证集成测试覆盖度；依据《测试计划》及性能指标进行性能测试用例设计、性能测试脚本开发，试有序进行。

保证性能测角色和职责测试人员：以整个软件为对象，确保新功能、老功能、新老功能接口正确进行用例设计；依据性能指标及测试计划编写性能测试用例、开发性能测试脚本。启动标准功能测试完成且软件功能无中断工作流程图集成集成/性能测试设计测试人员测试人员注：此处两文档编写无先后关系注：此处两文档编写无先后关系输入输出输入：功能测试用例、功能测试缺陷、 《测试计划》、性能指输出：集成测试用例、性能测试用例、性能测试脚本规范集成测试用例实际内容参见《测试用例模版》集成性能测试执行目的以整个软件为对象，以测试计划为指导，按照集成测试用例对新功能、老功能、新老功能接口进行测试和性能测试，以保证测试的全面性和完整性。426.2角色和职责测试人员：以整个软件为对象，以测试计划为指导，按照集成测试用例对新功能、老功能、新老功能接口进行测试，并依据性能测试计划对软件性能进行测试。4.2.6.3启动标准集成/性能测试设计完成工作流程图输入输出输入：《集成测试用例》、《测试计划》、《性能测试计划》、《性能测试用例》输出：集成测试缺陷4.2.6.6规范测试执行过程需按照《测试行为规范》进行，缺陷管理需按照本文 5缺陷管理进行。测试报告目的真实、客观反映测试过程中各测试阶段、测试项的情况，并将结果进行数字化进行分析，真实反映/图像化软件质量实际情况。角色与职责测试负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字的形式对实际情况进行分析，真实反映软件实际测试状况。启动标准测试执行完成。工作流程图测试报告测试负责人收集整理各测试阶段、测试项实际测试情况编写测试报告输入输出输入：各测试阶段、测试项实际测试情况输出：《项目测试报告》

/图像427.6规范项目测试报告实际内容参见《项目测试报告模版》测试维护目的软件产品的版本是随着软件的升级而不断变化的， 而每一次版本的变化都会对测试用库产生影响，所以测试用例库也需要不断地变更和维护，使之与产品的变化保持一致。428.2角色与职责测试负责人：真实、客观地对测试过程中各测试阶段、测试项的情况，并以数字4.2.8.3启动标准测试执行完成。

/图像工作流程图测试维护测试维护测试人员测试人员注：此处三个维护行为无先后关系注：此处三个维护行为无先后关系输入输出输入：测试用例、测试用例库输出：更新后的测试用例库规范测试用例的管理参见《测试用例配置管理》缺陷管理目的对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准角色与职责参与缺陷流转的角色有三个：测试人员、开发人员和评审人员。测试人员：依据测试计划，按照测试用例对软件进行测试。对于发现的缺陷必须记录，并且跟踪缺陷的状态，直至缺陷的验证关闭。在测试执行过程中发现的遗漏测试用例必须补充至测试用例，保证测试用例与实际测试的一致性。开发人员：对于测试人员提交的缺陷进行确认、修复。评审人员：对测试人员与开发人员意见不一的问题进行裁决。 当测试人员与开发人员对缺陷有效性的意见不统一时，评审人员应总合各方面意见，对缺陷有效性作出最终判定。评审人员应由测试负责人、开发负责人和需求人员共同组成。缺陷管理流程缺陷管理流程测试人员 开发人员 评审人员提出Bug认BugNo是否有效意见是否统一一Yes

NoYesNo

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

，并添加注释。若在此过程中开发人员与当确认该缺陷有效时，开发人员应按照要求修复缺陷。 缺陷修复后，开发人员需添加注释详细填写修复的内容、缺陷根源、修复版本，更改缺陷状态为“待验证”当确认该缺陷不是本系统引起， 需要其它项目组协同进行分析解决

。开发人员应保持缺陷状态为“处理”，并将该缺陷的“处理人员”改为相应的项目组人员，以便缺陷能及时流转。验证缺陷测试人员负责验证缺陷是否已解决。如已解决则关闭缺陷，否则将“缺陷状态”更改为“重开”，以便开发人员重新对此缺陷进行处理。缺陷管理系统部分字段详解缺陷状态：指缺陷通过一个跟踪修复过程的进展情况。包括：新建、处理中、拒绝、无效、待验证、重开、关闭缺陷严重程度：是指因缺陷引起的故障对系统的影响程度。员负责确认。由提出人初步指定，开发缺陷级别 定义 帮助和示例1、死机、重启、内存泄漏、自动关机； 软件在待机或者使用时岀现死机、报错、系统重启、自动关机、瘫痪等造成无法使用的问题；无法开机；操作应用时内存不足，造成大量软件应用不能使用的情况；2、花屏、白屏等屏幕异常现象； 唤醒后屏幕、键盘失效；屏幕岀现花屏、白屏现象；一级问题（致命问题）A

3、系统无响应； 待机或者使用中系统没有响应；电话不能呼岀、拨入或呼通率低于95%以下，单通（1%以上）;通话不能断，短信不能收发，延迟（非网络问题）；屏幕无法点亮，屏幕半亮无法使用，屏幕灰屏无法使用等；4、岀现数据丢失、数据库被破坏或者损坏用户器件；

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

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

不能岀现违反国家法律法规信息，不能岀现引起民族或矛盾的信息；参数设置不能保存或失效；8用户界面信息异常； 提示信息与实际不符，显示不全、漏显示、重叠、错误、乱码或者不美观等现象；大范围的UI、文字、音、图案、灯光提示错误、不准确；三级问题（一1、主要功能已实现，存在影响用户正常使用软件应用的部分功能的失效，或者操作某功能响应般问题）C

的问题；

慢，界面刷新不及时；1、轻微、提示性问题，不影响系统功能 帮助文件、提示信息缺少或可读性差、用词不当、错别字及不易于理解的描述；2、操作复杂或用户不常操作到的路径； 操作3级以上菜单功能岀现的问题；操作多个模块（3个）交互后岀现的问题四级问题（轻微问题）D

3、需要提示信息的地方没有相应提醒； 收费业务在用户订阅前没有提示信息；4、用户使用不便或者容易出现误操作； 操作功能使用不方便，并且不方便的程度很轻微；5、建议性问题以使软件可用性更强； 外观色彩、字体大小显示更适合长时间使用；提示音不应有特别刺耳或者容易让人疲劳的情况；增加一些简单功能使软件更人性化；删除多余的功能；缺陷紧急程度：指缺陷必须被修复的紧急程度。具体协商约定紧急程度的具体含义。

由提出人指定。各测试小组可以项目组包括：高、中、低缺陷起源：指引起缺陷的起因。由开发人员初步指定，测试人员负责确认。包括：需求、架构、设计、编码、测试、环境、数据、无效缺陷根/r