研发测试管理制度.docxVIP

测试管理制度 总则 目的 为统一公司所有项目的软件测试标准流程；规范统一的项目测试执行标准；达到对工作效率质量的掌控和监督的作用；同时规范各部门的交互合作流程，从而有效保证职、责、权的分明。特本着规范化、标准化、专业化的管理原则制定本管理制度 适用范围 本制度适用于网络数据部软件开发测试管理 测试规范 角色与职责 项目经理： 协调软件、硬件、人力资源、风险控制、项目进度和质量等； 测试经理： 制定测试计划、管理测试相关资源、分配测试工作、风险控制等，对测试工作进度把握和质量监督、协调客户需求和开发人员的合作、项目完成进行项目总结； 测试工程师： 编写测试用例、执行测试、提交缺陷、编写测试分析报告、性能测试计划、性能测试用例、性能测试报告； 研发人员： 修改缺陷、开发人员修改完缺陷后由测试人员进行回归测试，测试通过则“关闭”缺陷，检验未通过，提交缺陷修改程序代码；提供必要的测试数据； 系统组配置管理人员： 管理测试需要的资源，包括软硬件环境，提供测试过程中技术支持。 测试范围 根据项目实际需要选择完成测试类型 系统集成后的功能性测试；??? 系统集成后的容错性测试；??? 系统集成后的界面测试；????????? 系统集成后的常用控件测试；??? 系统集成后的接口测试；??? 系统集成后的可用性测试；??? 系统集成后的完整性测试； 系统集成后的压力测试； 测试标准规范 所有的缺陷必须全部记录在BUG管理工具（JIRA）； 测试完成标准必须有项目经理和测试Leader的确认； 测试用例执行覆盖率应达到100%（功能测试用例均已执行）； 测试需求执行覆盖率应达到100%（业务测试用例均已执行）； 测试规范是根据开发规范而制定的测试标准，测试规范也是后期测试用例编写的重要依据。 性能测试必要性和指标根据需求情况而决定； 从理论到方法到各类流程到各类报告模版，都属于测试规范的范畴，当一整套规范形成之后，可使得测试工作进行更加稳健，所有问题有据可查； 测试依据 软件需求规格说明书 软件需求规格说明书是软件达到的各项功能的目标。是测试人员各项工作的依据，没有需求就无法判断测试结果是正确的。 软件设计说明（概要与详细设计） 设计说明书包含软件的一些框架、字段、数据库设计等。软件设计说明对测试工作开展有很大影响，没有软件设计说明很多问题将无法溯源，测试准备的前期工作也是根据软件设计说明来制定的。 页面原型（DEMO） 页面原型是项目人员快速熟悉项目的最佳路径。在需求不够明确，设计说明书不够全面的情况下，页面原型也是后期测试用例编写思想的重要根据。 测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他。 测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； 测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； 测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 测试流程 启动测试 测试计划 在开发团队、产品团队与测试团队交接测试内容，对测试目标达成一致，商讨测试计划初稿的可行性，统一项目组的目标和测试的工作内容的同时，明确测试重点，测试组提交《测试计划书》。 根据项目的需求文档，按照测试计划文档模板编写测试计划。测试计划中应该至少包括以下关键内容： 测试需求，明确需要测试组测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级； 测试方案，整体测试的测试方法和每个测试需求的测试方法； 测试资源，本次测试所需要用到的人力、硬件、软件、技术的资源； 测试组角色，明确测试组内各个成员的角色和相关责任； 里程碑，明确标准项目过程中测试组应该关注的里程碑； 可交付产物，在测试组的工作中必须向项目组提交的产物，包括《测试计划》、《测试报告》等； 风险管理，列举出测试工作所可能出现的风险； 测试计划编写完毕后，必须提交给项目组全体成员，并由项目组组中各个角色组联合评审，直至通过评审。 编写测试用例 在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准；测试用例所涵盖的标准如下： 测试用例是用于检验对象是否符合要求的一种“示例”，基本要素为：前提条件、输入数据或动作、期望的响应，目的是找出需求、设计、实现中的缺陷； 测试用例由开发人员和测试人员共同制定，然后撰写《系统测试用例》，责任人为测试工程师； 项