回到网易8个月软件测试团队转型实践

2016年初月回到网易，进入交友事业部，更加专注于移动互联网APP研发测试领域，在将近一年来的时间里，经历了开发、测试团队的转型，下面讲述带领测试团队从挖掘痛点的转型实践。

测试团队现状

交友事业部人员朝气蓬勃，个人认为更像一个创业型的公司，初期技术资源都投入到产品功能需求开发中，对于产品质量稍作妥协，不需要太严格的过程控制和质量把控，相比开发资源而言，测试的投入资源不是那么急需。

随着用户量的上升，各种类型的移动设备问题错综复杂，用户对产品的质量有要求，部门老大对质量越来越重视，狠抓这块，从2015年Q4、2016年Q1分别招入两名测试人员，整个技术团队对于质量把控的诉求越来越强烈了，到后来整个测试团队跟随开发团队的规模壮大而壮大起来了。

开发测试人员配比

交友事业部有三款APP产品：同城约会、美聊、花田，一线开发人员总数20人，一线测试人员总数4人，示例如下（2016年Q1统计）：

图-开发测试人员配比

图中可见测试开发比例是1:6，Android、iOS端各占一名黑盒测试人员，后端API无相关测试人员参与；

测试技能现状

所有产品线的测试手段都是以手工测试为主，无自动化辅助手段，回归测试成本高，Android、iOS独占测试人员忙于业务的功能性需求的黑盒测试，非功能性需求无法满足。

Android、iOS与后端Server进行数据交互的API规范定义是一致的，早期无相关测试人员参与，导致发现API问题较晚，推迟到客户端功能开发完成阶段才进行检验，同时也造成后端API回归成本高；

功能测试以及API相关测试在研发测试过程走一轮、预发布环境第二轮、生产环境走第三轮，深度依赖于手工测试，发现问题滞后，相比需求、研发阶段修复的成本来说，发现的阶段越晚修复成本越高，最终可能导致带着严重问题上线运营。

测试流程现状

交付式测试，开发人员把相关功能任务设置为done之后交付给测试人员，测试人员未全程参与从需求源头开始跟进（及时了解需求背景和细节，消除需求含混性，及早开展测试用例编写工作），从而研发过程中客户端功能、后端API的可测试性（一个完整的功能是可以分多个功能小点提测，最终完整再提测一次）无法提高，测试人员也无法及早进行冒烟测试；

无测试人员专属的持续集成构建环境，Android、iOS打包依赖开发，测试人员存在时间等待上的开销成本一直存在未能降低。

原文转自：http://www.uml.org.cn/Test/201707191.asp