2019-05 sprint1迭代回顾

2019-05 sprint1迭代回顾

公司最近在推进Devops建设，所以对发布流程进行了很大调整：按照特性分支发布。作为项目的唯一测试，需要做的不仅仅是功能测试、接口测试或是自动化测试，也承担了一部分发布的工作。

• 测试会收到提测分支合并的请求，首先需要检查分支的名称是否符合规范（为方便后续发布及核对设置的名称规则），再查看提交的合并请求是否有非提交人员的其他人的审核（通过分支上的备注及点赞功能），这两件是必检查项

• 其次，对于bug分支要特别关注，查看解决的bug是由于之前提交的分支产生的，还是未知的bug被发现，这个时候就需要测试人员运用对比代码的功能，对比代码的差异性及提交历史。
  -----对于bug分支的关注原因是，测试环境是全量的代码（由于不能有等待时间，所以合并进去的分支即使有bug，也可以合并下一个分支，造成测试时间等待），而上线是按照特性分支上线，如果特性分支的bug另外新建分支，这个新建的分支和特性分支关联性会太强，导致两个必须一起上。不建议两个关联性太强的原因有：1、发布过程没有工具，都是人为手工操作，很容易有遗漏2、定位问题，得对比两个分支的代码来看，消耗人力3、只要有一个分支还存在bug，另一个分支就不能上线，如果两个都涉及比较多的代码改动，后续测试的工作量会比较大。

• 特性分支测试完成后，需要上预发布环境。测试需要将测试完成的特性分支合并到预发布环境分支，并打上最新的tag。再将最新的tag和发布内容通知运维操作。

• 特性分支上预发布环境之后，需要对预发布环境的进行回归测试，保持测试环境的全量代码没有问题，但是单特性分支是有问题的。这步流程加大了测试的工作量，因为特性分支上预发布的操作很频繁，就需要每合并一次就需要对系统全流程或是大部分流程进行回归测试，以保证预发布环境再每次合并完特性分支后，全流程的功能是正常的。

• 最后由预发布环境到生产环境这一步骤会稍微轻松点。将所有发布内容及标签通知运维部署就行。

特性分支发布已经实行了有两个迭代，分支这块的操作流程耗费了大量的沟通和工作量。需要优化的是团队按照统一标准或共识进行操作会提升一些效率。反复核对和确认、大量的回归测试压缩了迭代内功能的测试时间。虽然是按照特性分支进行上线，但是会造成大量的测试中的任务遗留到下个迭代，要么是测试验证没完成，要么是bug未解决。