测试过程管理之提测申请流程

 很多面试题目中，面试官会通过提问“说说你之前公司的测试流程”“以前工作中都接触过哪些类型的测试文档”，来判断以前公司的测试管理是否规范，以及所属项目的规模大小。通常的软件测试项目中只包含测试计划（视项目大小存在与否）、测试用例、测试报告、缺陷报告文档，其实并不能完全涵盖整个测试流程，如果回答时只是阐述到这些，远远不够。即使是目前公司并没有规范的项目及测试流程，自己也需要了解下A类项目的整体规范，合理运用在当前项目的同时也可以丰富自身的阅历。

      分享几个项目测试的周边文档：提测清单、发布清单、项目组测试日报；今天主要来阐开讲解下提测申请清单及作用。

      首先了解下提测的整个流程：研发组发出提测邮件（说明提测内容、提测时间点、自测结果附件以及测试注意事项等）->由测试组相关负责人接收邮件->部署测试环境->执行可接收性测试->测试通过与否结果以回复邮件通知研发组

      以上是通用的提测流程，更加正式的客户应用测试中，开发会在开发阶段执行通过所有可接收性测试用例，通过后才会进行下一步的编码工作。这样也在开发初期便避免了严重级别问题。为之后的提测阶段节省大量时间成本。

      以上提测流程中涉及到的提测清单也是归属于项目测试文档中的，提测清单根据公司要求、项目规模及性质会略有不同，但通常包括以下必要内容：

• 提测需求

• 提测时间

• 提测责任人

• 测试路径 

• 自测情况说明

• 功能点

• 自测结果 

• 对应开发人员

• 测试特别注意事项

• 测试退回说明

      以上，提测需求一般会关联到需求编号，如果使用了需求管理工具，可以导出或手动关联；提测责任人一般填写提测模块或需求的第一负责人，如遇突发情况会紧急联系；测试路径依据测试终端的不同，会给出相应的路径说明；自测情况说明一般包括是否通过单元测试、是否通过代码评审、是否通过数据库完整性检查等，提测清单填写人员需根据实际完成情况来勾选对应通过选项；自测结果包含通过、不通过、未开发等状态，一般自测通过率达到95%即可提测，低优先级功能点可以同时进行；测试注意事项一般由提测责任人来填写，告知测试人员检查时的侧重点；测试退回说明一般指提前约定好的退回规则，如缺陷率达到一定百分比则停止测试，或通过计算千行代码缺陷率或是按功能点通过细分来判断。

       一般情况下，提测申请清单也有细分，如根据需求的性质 ，新增需求、迭代需求、功能优化需求、建议优化需求、技术类需求、性能需求等。来灵活调整提测申请清单的模板选项配置。测试负责人接收到邮件后，需要针对提测清单执行可接收性测试，测试通过回复提测邮件说明测试结果及告知下一步测试计划；测试不通过回复提测邮件说明不通过原因及建议修复方向并附件缺陷报告。

      项目中并不存在非常完美的测试流程，只有不断磨合、不断适应项目本身的发展需要，才可以不断改进我们的测试过程管理，从而为最终的产品质量保驾护航。