开发协助测试人员规范

预期目标

一次迭代版本有一个测试报告

测试过程中遇到的问题如下

1. 迭代版本没有测试报告

2. 测试过程很慢

3. master测试版本混乱太多，分不清谁的版本

Release Notes管理：

1. 每个迭代任务必须有对应的迭代版本号

2. 每个迭代版本必须在release notes记录，方便测试人员知晓有哪些迭代版本需要测试报告

3. 版本记录：（1）bom版本升级（2）升级改动点

开发配合测试如下：

1. 需求阶段： （1）需求任务通知：帮助测试能够提前感知需求特性、改动点，通知内容：任务描述、改动接口、功能改动点描述、迭代任务链接 （2）时间通知：开发预估任务开发时间、提测时间，测试人员提前预估测试时间，安排测试计划

2. 开发阶段 （1）开发人员提供系分文档，协助测试人员测试分析（注：功能点较小、任务时间进度紧张、bug hotfix不用提供，但是需要向测试说明） （2）如果开发设计复杂，在提测前，召开需求会议，讲解需求功能、改动点及设计（3）输出准则：开发完成单元测试

3. 提测阶段

（1）测试方案

         正常测试：正常情况下，测试人员进行功能测试、接口测试、压力测试、性能测试、回归测试

         开发自测：时间紧张、功能点较小、测试人员无法快速测试、开发自己的技术优化情况下，开发自测

         回归测试：一般迭代版本，分支测试完成才进行回归测试，如果版本不进行正常测试，直接要回归测试，请开发和测试一起评估

（2）一般的测试流程：测试准备-->分支测试-->master回归测试  

（3）测试准备： 测试人员了解需求特性、分析改动点和测试范围 测试人员提供测试分析文档  

（4）分支测试： 开发提供测试分支版本号（linke地址） 开发提供测试的服务器

（5）master回归测试：  

         串行测试：正常情况下，一个迭代版本回归测试完成，下一个版本才能合入master进行回归测试

        并行测试：如果任务比较紧急情况下需要并行回归测试，请开发评估风险，再通知测试人员进行回归测试

        注：开发请通知测试人员之后，再合入master，勿造成master版本混乱

    4. 测试完成阶段 测试人员输出测试报告