qileilove

　　长期以来业务线测试有这种困扰：淘宝业务线传统的项目流程把开发、测试两个阶段分得比较明显，导致开发赶时间写代码，提测阶段测出一些低级bug；重新返工不仅测试时间延长，也导致开发、测试同学都累。

　 　在天彤的支持下，本人今年3月份来到C2B市场团队轮岗开发，实践了开发自测的项目模式。这是一个新产品团队，新模式比较容易落地。迄今经历了5个项目 （C2B公益概念版、C2B标准版、C2B公益版2期、C2B合买版和合买版双12活动），摸索了近1年，有过困难和困惑，总体看来实践效果还是挺不错 的，分享一下。

　　分享分为实践案例、模式小结和展望3部分

　　一、实践案例

　　以时间为维度，实践中经历了以下3个阶段。每个阶段都是在前一阶段模式的基础上根据实际情况优化的

　　阶段1：人人都是开发，没有专职测试

　　有两个项目

　　1、C2B团购概念版（3.20-4.15，开发测试比3：0），第1次实践成功

　　这是第一次轻量级尝试，加上我有3个开发，功能全部自测，最后我主导验收了一下功能。项目流程如下

　　说明：

　　1）由于前端资源紧缺问题，所以后期才开始前端编码

　　2）TC也要开发自己写。给开发培训了一下从UC到TC的转化方法

　　3）整体验收包括代码review、PD验收和我再覆盖一下主流程

　　效果：

　　1）单测和接口测试覆盖很好地保证了质量

　　在单测和接口测试阶段都发现了bug，避免遗留到功能测试阶段；后端编码的稳定性，能让开发在后期专注在前端功能的开发和联调上，不用担忧底层的质量

　　2）功能测试时间大大缩短

　　因为资源问题前端介入较晚，全部联调好后离计划发布日还剩2天，这两天的功能测试时间里我们找出了大部分问题并解决了，完成了验收和发布。项目总共花了19个工作日，开发时间稍微延长，测试时间大大缩短，总的项目时间是缩短的。

　　3）项目质量稳定

　　发布后，后端遗留一个因线上、daily环境不一致导致的bug；前台遗留1个bug。在时间很有限的情况下，总体质量不错

　　问题：

　　UC、TC有一定的重复工作量，初次编写TC的开发工程师写得不太好且消耗时间略多

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

　　效果：

　　关键词还是前端资源紧张，全部联调好后只剩下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天

　　合买版双12活动（11.23-12.6，开发测试比4：1）

　　阶段2进行得比较顺利，于是接下来的项目继续在此模式基础上优化

　　优化点：

　　1）测试全程介入技术方案评审和代码review

　　从技术方案开始介入，review sql、业务层代码、vm层代码

　　2）更加关注系统性能方面的东西

　　测试同学能有时间学习性能测试，并为系统进行了性能调优，为双12做好准备

　　问题：

　　前端代码尚无能力review。

　　二、模式小结

　　有些人疑惑，开发自测后，测试干什么？

　　这就回到了开头提到的困扰。开发自测模式，能把开发和测试从低级bug中解放出来，开发可以提高代码质量，测试可以关注更深层次的系统质量（比如性能和代码优化等），整个团队能提升效率，进入良性循环。

　　那么写了那么多，经历了半年多的探索，目前我们项目组到达了什么程度呢？从项目模式、效果和测试同学的角色3方面来描述一下。

　　1、产出了一个被现实考验过的项目模式（当然还在继续优化中）

　　1）UC

　　开发同学要写详细、标准的UC，方便后续测试和维护；测试同学根据UC简单得写一些TC，方便开发自测

　　2）DAO层单测

　　新增sql必须要写单测用例，修改sql必须要回归单测用例

　　3）业务层单测

　　已经有比较完善的单测环境，开发可以根据个人喜好，在manager层或ao层进行单测，无硬性要求

　　4）代码review贯穿整个流程

　　分为两类代码review，目前我们项目组两类并存

　　i.测试同学主导的每日review

　　项目里每天测试同学都会review开发提交的代码，这不仅仅是发现bug，目前我们的代码review已经能到优化代码或设计方案的阶段。例如：http://kelude.taobao.net/issues/206462?page=1

　　ii.传统的项目组review

　　在项目后期集中式得进行一两次review，有效果但量较大

　　5）功能自测&验收

　　功能自测开发根据UC和TC进行；验收是PD介入，页面有新需求可以及时改动

　　6）整体测试

　　主要由我来执行，进行主流程测试和随机测试，但不会覆盖所有点，其他功能点的质量开发同学自己保证

　　1）工期缩短。这是最明显的，目前这几个项目的daily、预发测试时间加起来都没超过1周的

　　2）质量提高。

　　i.开发同学的代码质量提高了。以前测试同学都基本是保姆式的，现在测试介入得少了，遗漏bug会增加吗？刚开始开发会略感不适应，但长期来看对整个团队肯定是有益的

　　ii.整个开发流程中，很多bug发现在前期，后期底层基本很稳定了

　　3）释放测试资源

　　目前我们团队的开发测试比是4:1，最高时是5:1。在开发大部分时间工作量饱和的情况下，测试资源基本能满足项目组需要

　　4）周期快，能够满足一周多次发布的需求

　　交易线标准的日常流程：上一周提需求，周五UC评审，下周二提测，周三预发，周四发布。1周发布1次

　　目前我们日常主要靠 开发自测+代码review+脚本回归 保证质量，测试同学不用花太多精力进行功能测试。因此团队效率很高，甚至能达到一天一次的发布频率（当然发布多了不是好事）

　　3、测试同学的任务

　　从初级bug的痛苦中释放出来后，测试关注什么？

　　1）业务方面

　　了解整体业务和逻辑，review覆盖整个研发流程，包括技术方案、sql、业务代码、vm，做一个熟悉整个系统的角色

　　2）持续回归

　　这一直是测试同学的强项，维护一个成形的产品需要建立一套完善的回归体系

　　3）其他方面

　　系统性能？算法测试？单测回归？无线？随便，因为有时间有精力了，都可以去做

　　三、展望。我们才刚开始

　　明年测试策略需要怎样完善？产品在不断迭代，市场在不断增长，测试压力得到释放后，有更多的事等着我们去做。目前想到的有以下3点

　　1）测试数据

　　方便开发同学自测

　　2）前端代码review

　　这一直是痛点，前端没有成形的review机制。明年学习一下前端知识，希望在review上有所突破

　　3）完善回归

　　方便开发自测，最好开发能根据改动点进行定制的脚本回归

　　做到了这些，就做成了一个完整的开发自测生态圈。明年继续努力！