2、C2B标准版（5.15-7.13，开发测试比4：0）。暴露一个问题

　　因为第一个项目比较成功，所以第二个项目继续沿用上一次的自测模式，项目流程基本不变。

　　效果：

　　关键词还是前端资源紧张，全部联调好后只剩下1天的daily测试时间。因为前期各自自测做得比较充分，所以依旧是后端稳定，前端小问题比较多。花了1天修复完大部分前端问题后，按时发布。

　　问题：

　　此次需求点很多，时间又紧，人员配置全部都是开发的情况下，没有一个人能够关注到整体业务，对所有的业务逻辑能比较清晰。导致

　　1）系统方面：后面新需求过来评估时，要花费更多的时间，潜在bug发生的可能性增加

　　2）业务方面：用户体验，对PD新需求的控制力什么的，照顾不太到

　　3）流程方面：UC略不规范，导致转化成TC不太方便，也不方便别人看，不方便验收和测试

　　阶段2：开发自测，测试关注整体业务

　　1、公益版2期（7.13-8.3，开发测试比4：1）

　　2、合买版（10.19-11.3，开发测试比4：1）

　　这两个项目又新增了开发资源，吸取了前两次的经验教训后，继续优化一下项目模式。

　　优化点：

　　1）项目里我不再担任开发人员，全职做测试；因为前面两个项目自测效果不错，所以依旧坚持开发自测的思路

　　2）强化UC，弱化TC。开发不再编写TC，但要详细写好UC。由我负责写一些主流程TC和容易出错环节的TC

　　弱化TC的原因：

　　i.和UC有重复工作量

　　ii.黑盒功能用例写得再多也不能保证全部覆盖

　　iii.TC也是给开发自测参考用的。开发自测习惯是根据代码逻辑做功能测试，流程性的一般根据自己的UC进行自测，然后再覆盖一下TC上容易遗漏的点，基本能满足自测期望达到的目标

　　3）增强代码review

　　测试从前期介入代码review中，避免项目后面大家一起review的工作量太大。项目代码略稳定后，我每天花在代码review上的时间至少占工作量的三分之一

　　4）完善回归系统

　　效果：

　　1）测试能对整体业务点都很了解，并且能在前期review出一些bug

　　2）从时间上可以看出，项目时间都在一个月内。这里测试时间压缩了很多，两个项目提测到发布都只花了4天