研发测试管理制度.doc

测试管理制度

一、 总则
1. 目的
为统一公司所有项目的软件测试标准流程；规范统一的项目测试执行标准；达到对工作效率质量的掌控和监督的作用；同时规范各部门的交互合作流程，从而有效保证职、责、权的分明。特本着规范化、标准化、专业化的管理原则制定本管理制度

2. 适用范围
本制度适用于网络数据部软件开发测试管理

二、 测试规范
1. 角色与职责
项目经理：
协调软件、硬件、人力资源、风险控制、项目进度和质量等；

测试经理：
制定测试计划、管理测试相关资源、分配测试工作、风险控制等，对测试工作进度把握和质量监督、协调客户需求和开发人员的合作、项目完成进行项目总结；

测试工程师：
编写测试用例、执行测试、提交缺陷、编写测试分析报告、性能测试计划、性能测试用例、性能测试报告；

研发人员：
修改缺陷、开发人员修改完缺陷后由测试人员进行回归测试，测试通过则“关闭”缺陷，检验未通过，提交缺陷修改程序代码；提供必要的测试数据；

系统组配置管理人员：
管理测试需要的资源，包括软硬件环境，提供测试过程中技术支持。

2. 测试范围
根据项目实际需要选择完成测试类型
• 系统集成后的功能性测试； l 
• 系统集成后的容错性测试； l 
• 系统集成后的界面测试；       l 
• 系统集成后的常用控件测试； l 
• 系统集成后的接口测试； l 
• 系统集成后的可用性测试； l 
• 系统集成后的完整性测试；
• 系统集成后的压力测试；

3. 测试标准规范
• 所有的缺陷必须全部记录在BUG管理工具（JIRA）；
• 测试完成标准必须有项目经理和测试Leader的确认；
• 测试用例执行覆盖率应达到100%（功能测试用例均已执行）；
• 测试需求执行覆盖率应达到100%（业务测试用例均已执行）；
• 测试规范是根据开发规范而制定的测试标准，测试规范也是后期测试用例编写的重要依据。
• 性能测试必要性和指标根据需求情况而决定；
• 从理论到方法到各类流程到各类报告模版，都属于测试规范的范畴，当一整套规范形成之后，可使得测试工作进行更加稳健，所有问题有据可查；

三、 测试依据
1. 软件需求规格说明书
软件需求规格说明书是软件达到的各项功能的目标。是测试人员各项工作的依据，没有需求就无法判断测试结果是正确的。
2. 软件设计说明（概要与详细设计）
设计说明书包含软件的一些框架、字段、数据库设计等。软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将无法溯源，测试准备的前期工作也是根据软件设计说明来制定的。
3. 页面原型（DEMO）
页面原型是项目人员快速熟悉项目的最佳路径。在需求不够明确，设计说明书不够全面的情况下，页面原型也是后期测试用例编写思想的重要根据。

四、 测试需求分析
测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他。
• 测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据；
• 测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例；
• 测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖；

五、 测试流程

六、 启动测试
1. 测试计划
在开发团队、产品团队与测试团队交接测试内容，对测试目标达成一致，商讨测试计划初稿的可行性，统一项目组的目标和测试的工作内容的同时，明确测试重点，测试组提交《测试计划书》。
根据项目的需求文档，按照测试计划文档模板编写测试计划。测试计划中应该至少包括以下关键内容：
• 测试需求，明确需要测试组测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级；
• 测试方案，整体测试的测试方法和每个测试需求的测试方法；
• 测试资源，本次测试所需要用到的人力、硬件、软件、技术的资源；
• 测试组角色，明确测试组内各个成员的角色和相关责任；
• 里程碑，明确标准项目过程中测试组应该关注的里程碑；
• 可交付产物，在测试组的工作中必须向项目组提交的产物，包括《测试计划》、《测试报告》等；
• 风险管理，列举出测试工作所可能出现的风险；
• 测试计划编写完毕后，必须提交给项目组全体成员，并由项目组组中各个角色组联合评审，直至通过评审。
2. 编写测试用例
在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准；测试用例所涵盖的标准如下：
测试用例是用于检验对象是否符合要求的一种“示例”，基本要素为：前提条件、输入数据或动作、期望的响应，目的是找出需求、设计、实现中的缺陷；
测试用例由开发人员和测试人员共同制定，然后撰写《系统测试用例》，责任人为测试工程师；
项目经理和测试Leader审批《系统测试用例》，如果同意，则测试人员按照该计划执行测试工作；否则修改测试用例，直到通过审批为止；
• 测 试 用 例
项目名称

项目负责人

模块名

优先级别

模块开发人员

开发完成日期

用例设计人员

设计日期

评审人员

评审日期

测试次数

测试执行日

编号
流程
目的
操作步骤
动作
预期结果
执行结果
备注
1
键入地址—>登录系统
登录成功
输入地址，回车；输入用户名、密码、验证码，点击登录按钮
点击“登录”按钮。
登录成功，显示主功能页面
成功
页面样式有问题
2

3

此用例模板为参考，详情见Excel版本并以实际Excel格式为准；

七、 测试环境

1. 系统内部集成测试(System Integration Testing) SIT
环境用途:
日常功能性测试、系统测试、集成测试
性能要求：生产环境的等比例缩小，高于最小系统可运行性能要求
环境要求：包含生产环境各系统及数据库
数据要求：包含预生产环境各类型数据的部分数据

2. 预发布环境(Pre Release Environment) PRE
环境用途:
模拟生产环境发布回归测试
性能测试
性能要求：生产环境的1/2或者1/4性能
环境要求：包含生产环境各系统及数据库
数据要求：包含生产环境各类型数据的部分数据

八、 提交测试

由开发人员在JIRA提交测试申请给产品人员，产品人员对开发人员提测内容进行审核，审核通过后交由测试负责人进行测试任务排期分解。
JIRA提测地址：http://172.17.254.247:8080/browse/TA

九、 执行测试

接到测试申请后，测试人员对提测范围进行冒烟测试，如果提测对象无法通过冒烟测试，测试人员可驳回提测，终止测试。
冒烟测试通过标准：
• 功能测试的功能单元能实现
• 集成测试的功能或系统不缺少，接口功能正常，系统间由接口对接正常
• 系统测试的系统运行正常，测试数据正常规范，系统间接口正常

3. 执行测试用例
测试人员按照《系统测试用例》，执行测试、质量保证、缺陷跟踪等规定的流程。

4. 跟踪消除缺陷
• 测试发现了缺陷，开发人员应当尽早消除缺陷。
• 开发人员找到错误时，修改前首先思考：修改此缺陷是否会引发其他问题？如会引发其他问题则可能需要修改硬件结构或软件结构。
• 有些时候，设计中可能潜伏同一类型的许多错误（例如由不良编程习惯引起的软件错误），发现后应当乘胜追击，全部排除。
• 不论原先设计是否绝对正确，只要进行了改错后要马上重新测试，以免引入新的错误。
• 记录缺陷排除的心得体会，与他人共享经验教训。
5. 优先测试原则
测试必须有计划且需制定合理简洁的测试流程，当人力资源或测试时间有限，不能做全面的测试，则集中力量测试高优先级的内容，放弃低优先级的内容。以下表格中，左边的测试优先级通常高于右边的测试优先级。
测试内容
测试优先级
测试内容
特色功能
高于
非特色功能
用户常用功能
高于
非常用功能
需求重点的功能模块
高于
非重点功能模块
系统性能瓶径所在的模块
高于
不是性能瓶径所在的模块
最复杂、最容易出错的模块
高于
不复杂、不会出错的模块
开发者没有信心的模块
高于
开发者自信的模块
涉及财物相关功能模块
高于
其他功能模块
开发者技术能力弱
高于
开发者技术能力强
功能价值高的模块
高于
功能价值低的模块
6. 回归测试
在每轮测试中，按照现有的测试用例没有新的缺陷被发现，测试报告中全部的活动缺陷都被解决。测试组将按照测试计划中对于回归测试的策略进行回归测试，回归测试的用例属于测试用例的一部分或者是全部测试用例，但不能超出原先预定的测试用例的范围。在每轮测试结束之后，由测试组重新拷贝修改后的最新版本，进行回归测试。回归测试最多为三轮，如果三轮仍未达到停止测试标准，由项目负责人决定后期策略。

十、 提交报告
在约定的测试周期完成之后，测试Leader需要总结此测试的结果，编写测试报告；测试报告包含如下内容：
• 测试报告的版本；
• 测试的人员和时间；
• 测试所覆盖的缺陷，测试组在这轮测试中所有处理的缺陷，报告了测试Leader处理的缺陷和实施工程师验证的缺陷。不仅要写出覆盖缺陷的总数，还要写明这些缺陷的去向；
• 测试新发现的缺陷数量；
• 上一版本活动缺陷的数量；
• 经过此轮测试，所有活动缺陷的数量及其状态分类；
• 测试评估，写明在这一版本中，那些功能被实现了，那些还没有实现，这里只需写明和上一版本不同之处即可；
• 急待解决的问题，写明当前项目组中面临的最优先的问题，可以重复提出；
• 在每轮测试结束之后应尽快将符合标准的测试报告发给全项目组；并抄送给相关领导审阅；

十一、 测试工作总结
测试总结工作是在以上的工作全部结束以后，它的目的是评估本次测试工作，总结经验，并在组内进行技术和经验分享，为使下一次的工作做得更好。
十二、 测试归档
测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归类，存档。主要的归档文件如下：
· 《测试计划书》；
· 《测试用例书》；
· 《测试报告书》；

十三、 性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

十四、 软件测试暂停、停止标准
软件系统在进行单元、集成、系统、性能、安装、验收测试时，发现致命错误（大于等于1）、严重错误（大于等于2）时，暂停测试，返回开发。
软件系统经过单元、集成、系统、性能、安装、验收测试，并分别达到其测试停止标准时，停止测试转入下一阶段。
软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。
软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据。
详细依据 《软件测试停止标准》

十五、 项目文档产出
1. 常规项目测试产出文档
• 《测试计划》
• 《测试用例》
• 《阶段性测试报告》
• 《性能测试报告》
• 《测试总结报告》
• 《测试问题列表》
• 其他

2. 特殊项目需求选择性产出文档
• 《BUG多维度分析》
• 《研发效率明细及统计》
• 《人员能率分析》
• 《模块质量分析》