测试过程管理之发布申请流程
接上节内容项目测试的周边文档，今日分享发布申请清单与缺陷跟踪管理表。
对于小型项目来讲，发布申请清单由项目经理填写并审核，然后交付部署人员直接发布了。但在严谨的项目规范里，这种方法并不可行，尤其是大型项目，如果是涉及到外部客户的项目，发布申请清单更是需要经过层层审核，通过后方可执行发布动作。
发布申请清单
发布申请清单首先，我们先了解下项目中发布的整个流程，很多传统的测试人员一般只跟踪到测试交付，或是产品验收结束阶段。对于发布流程不清晰 ，或是等到发布后会由项目经理通知需要线上测试。以此类推，测试人员一直处于被动的工作阶段。对于项目的整体规范，发布流程如下：测试团队系统测试交付通过->UAT测试团队预发布测试通过->产品经理验收通过->研发经理填写发布申请清单->交由所属项目经理&QA经理签字确认->研发经理发送申请发布邮件->职能部门负责人同意后方可执行发布动作，否则会给出拒绝发布的原因。
一般情况下，发布申请清单主要包含以下内容：
项目名称
当前版本
发布版本
申请人
申请日期
版本描述
测试情况
回退机制
备注
相关审核人员
当前版本填写当前的应用版本号，申请人为申请发布的第一责任人，也是填写发布清单的人员，版本描述即目前即将要上线的内容，可以分为新增和删除，优化功能；测试情况填写申请发布版本的测试结果 ，如SIT/UAT测试通过，XXX产品团队验收通过等；备注与相关审核人员可根据公司需要配置；一般由项目经理及QA经理、职能部门负责人审核；回退机制根据项目性质及公司要求来，回退机制与风险识别同等重要，一旦发布异常，需要做好容灾测试的建议方案。以下举个例子：
试运行：2天；
试运行期间，内部用户进行系统功能验收及测试团队线上常规测试；若发现问题且问题数量较多（超过XX个）或出现严重程度高的问题则进行回退，回退版本至上一个版本；回退需要在XX确认前进行并马上进行问题修复；若发现问题数量较少且严重级别较低，则后续安排逐步修复。
即使我们现在工作中并不需要测试人员去接触到发布相关的工作，也需要主动学习以使我们融入进整个项目中，而非单纯地"执行测试"。
缺陷跟踪管理表
缺陷跟踪管理表在工作中还是比较常见的，缺陷报告一般使用缺陷管理工具来维护与跟踪。这里的缺陷跟踪管理表一般用于项目后期与测试收尾阶段，对于遗留缺陷的跟踪与维护，缺陷跟踪管理表会在测试报告、发布申请清单、客户项目周例会会议中使用到。每个项目中都难免会存在一些需要耗费时间精力的问题，特别是性能测试问题，平均修复周期在1周左右。但按照测试计划测试交付时间已结束时，需要测试人员整理出遗留问题并以跟踪管理表的形式来维护。
缺陷跟踪管理表主要包含以下内容：
缺陷编号
缺陷类别
紧急程度
用例编号
问题描述
解决方案
提出人
处理人
解决时间
以上，也可以从缺陷管理平台中过滤导出，需要注意的是用例编号是对应缺陷的测试用例编号，如果是在探索性测试或是内部用户发现的，且并无对应用例路径 ，则需要在所属用例中增加该用例，并更新到用例库中，也是日后学习与要注意的地方。解决方案可以灵活填写，但要交付出去时解决方案不能为空。处理人可以有多个。缺陷跟踪管理表一般会放在协同文档。
