在大公司负责过团队建设和管理，到了创业公司，打法完全不一样了，毕竟创业公司没有像大公司那么多资源来多渠道开拓市场，必须聚焦击破，对团队成员的单兵作战能力要求更高。

本文讲述在将近一年时间里，经历了开发、QA团队的转型，如何带领QA工程团队从挖掘痛点转型成功的实践。

云服务三大类对比，保利威处于SaaS服务这一层的ToB市场。

测试团队现状

保利威属于实打实的创业公司（主要方向是ToB），初期技术资源都投入到商业产品需求开发中去，对于产品质量稍作妥协，没有专业且严格的过程控制和质量把控，相比开发资源而言，当时测试的投入资源不是那么充足、急需。

随着客户体量的上升，公司对质量要求越来越重视：稳定、安全、快速，要对已经推出产品的使用客户负责任，研发、测试团队建设破在当下，需要快速入手分析问题所在和提供解决方案实施。

初入新环境：收集团队成员反馈的问题

初到一个新环境，不要急于改革，毕竟不了解一切：包括曾经背负的债务以及当下急需突破的方面，从一线工程师那里了解问题所在，其中一个入口，先从团队成员收集反馈问题，简要信息如下：

→ 用例不全：核心用例无

→ 专项测试缺失：性能、安全等

→ 测试流程规范建设不全：很多项目缺失指引

→ 测试环境未与研发环境隔离

→ 基础平台建设缺失：无持续进程、静态代码分析

→ API功能研发自测：测试从未参与

→ 人员技能单一：功能测试为主

→ 人力不足：很多项目无法跟进

反馈的问题很多，而且分散，“攘外必先安内”，需要对研发过程产生影响，首先测试团队要修炼内功，有料人家才服你。

开发测试人员配比

首先搞清楚团队成员状况在产品线的分配情况，以便全局掌握资源分配：18年研发人员大概30人，测试仅3人，会错以为达到《Google软件测试之道》提出的1:10概念，但实际摸索下来一看硿硿焉，没有什么底气，只有提升研发团队成熟度以及单兵作战能力，使得平均水平提升了，测试开发比例1:（5-10）才是有可能的，当然也依赖于关键环节的建设：比如基础持续集成环境、自动化回归环境等等。

就目前而言，人员紧缺，产品线支撑覆盖面不广，对于产品线的分配资源需要调整，并不是简单看到：直播、点播两大类，按照产品线梳理规划如下安排：三人正职+三人实习的策略，先解决当下测试拖后腿问题：

测试技能现状

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

PC客户端、移动端（Android、iOS）、H5/Flash播放器与后端Server进行数据交互的API规范定义是一致的，无测试人员参与，功能性测试由研发人员在本地完成，遇到夜间发布，线上耗了时间检查接口可用性。

测试流程现状

测试人员从需求阶段开始参与，期间消耗不少时间在环境问题上：无测试人员专属的持续集成构建环境，PC客户端打包依赖研发人员本地的环境，曾经发生过上线发布过程等待打包完成，只能通过IM工具传包，没有下载地址。

各类播放器测试流程尚未建设：每个新人测试，都需要重新培训一遍，测试成本增加

Android、iOS打包依赖开发，测试人员存在时间等待上的开销成本一直存在未能降低。

另外，也了解到团队初期仅仅围绕功能开展测试活动，缺乏分层策略，

API测试无相关人员参与，导致发现API问题较晚，推迟到客户端功能开发完成阶段才进行检验，同时也造成后端API回归成本高；
重复稳定的UI功能，没有自动化回归测试覆盖；
测试任务评估没有依据，需要测试哪些点，需要多少人测试，讲不清楚；

上下游协作反馈

测试质量不高，线上问题多
客户需求交付不及时，销售吐槽多
测试介入太迟，研发信心不足

工程生产力改进实践

在谈生产力改进之前，要提一个理念：测试左移。如下图所示：

橙色线条：代表了传统测试发现缺陷的阶段，大多数集中在功能测试和系统测试阶段被发现；

红色线条：代表发现缺陷所带来的修复成本；

越后期修复缺陷的成本就越高，且呈指数增长；缺陷主要是开发前期引入的，前期缺陷修复成本很低，及早发现缺陷，测试越早介入越好，就如下图动画所示，将测试工作左移，当然这些工作未必是测试人员参与，应当是整个研发、测试的职责所在。

“攘外必先安内”，需要对研发过程产生影响，首先测试团队要修炼内功，有料人家才服你。

生产力改进实践环节，首先对内开展，围绕以下几个大方面开展的：

Scrum敏捷过程管理

项目管理并不能直接提升产品质量，同样投入再多测试也不能提升产品质量，产品在转化为研发任务的制造过程中已经决定了质量。

项目管理有一个很重要的观点：事前预防、事中控制、事后分析。

制定Scurm敏捷过程管理框架，也是为了贯彻这个观点，打通从需求阶段出发、研发阶段、发布阶段、运营阶段环节，把控过程反馈、识别风险，调整计划，做好拥抱变化，把质量偏差控制到最小可接受范围，实现客户的商业价值需求落地。

PM过程管理风险反馈工具

根据团队特性，自研过程风险反馈的燃尽图：及早发现进度问题的最佳时间，，让项目进度透明化，技术、视觉、交互、产品都参与到风险识别和反馈中来。同时，整体和个人进度还与OKR的信心标识保持一致，聚焦目标状态。

状态标识：（与ORK信心标识保持一致）

好（绿）：好

中（黄）：中

差（红）：差

带来的效益：

1、使用PM过程管理风险控制之后，工作时间内每时每刻能够看出趋势问题、风险所在

2、产品人员主动关注过程风险，及时调整有问题的任务，提高研发交付的时效

3、项目经理不再需要询问每个研发人员，通过每日进度表，可以看到项目总进度，研发、测试人员的个人进度，及时沟通遇到的困难，推进解决

平台数据展示研发过程进度和风险，另外在办公区还有电视投影PM工具，随处可见个人任务进度和风险。

持续集成打包与静态代码分析

过去PC客户端的代码构建在研发人员本地进行，测试人员每次获取新包，需要等待研发人员手工打包，到了晚上在家测试还需要致电研发人员打包，这些不必要的环节，消耗大量时间，让测试、研发人员的关注点偏离了。

另外客户端的代码质量没有数据参考，版本之间的变化趋势未能体现，测试发布的信心不足以增强。

团队需要引入有效的自动化构建平台，以及静态代码分析平台，用以指导日常开发过程的质量改进，将代码问题的反馈机制自动化，构建数据可视化。

持续集成打包

过去测试人员为了测试包，需要等待开发本地打包，也得耗上几个小时，现在为了让产品可以快速迭代，将客户端应用（PC、MAC）的自动化打包通过持续集成来构建，包括：代码更新、构建打包、自动上传；

→ 客户端自动化打包

自动化打包程序做了不少事情，包括代码构建、编译、以及执行GUI程序签名等等，全自动化一条龙服务；

→ Flash播放器自动化打包

原方案：人工打开IDE工具 --> 更新代码 --> 点击GUI打包按钮操作

改进方案：持续集成 --> 更新代码 --> 自动化脚本点击GUI打包按钮操作，全程无需人工参与，每次打包节省时间20分钟左右

打包脚本示例：

静态代码分析

为了保证代码质量，从代码层级降低线上出错的可能性，技术团队引入了静态代码分析技术：在不执行计算机程序的条件下，对源代码进行分析，找出代码的设计缺陷，例如代码规范、内存泄露，以及体现总体质量：代码覆盖度、技术债务的趋势图，通知技术改进，拦截在上线之前，这些数据都成为QA统计的数据来源。

打破单一技能集合：软硬兼施

不少团队为了双管齐下，把职责分明：做业务功能测试、做自动化测试的分开，刚开始会让有自动化脚本编写能力的测试人员来承担自动化测试工作，可能导致一个问题：自动化做出来的成果都是比较表面的，深层业务并没有吃透，比如API功能测试，仅仅做了一个API的单一验证，其实整个业务的关联链路涉及哪些API，这是自动化开发人员不曾接触到的，而懂业务的又在困惑，为什么脚本那么脆弱，不能命中率那么低，那么关键的业务链都覆盖不了呢？

保利威测试团队打破常规，软硬兼施：懂代码的必须深入业务测试，懂业务的必须参与脚本开发。这样子对于测试团队每个成员，就要求硬技能和软技能相结合。

测试组成员，在遇到业务测试痛点时，会思考有没有工具来解决问题，没有的话自己如何编写一个？下面一个例子是测试遇到多人连麦场景，如果每次打开客户端和观看页测试效率极低，于是写了一个demo页面，将产品线的相关SDK引入进来，形成一个简化操作，提高测试效率。

播放器自动化测试突破

播放器是由研发人员自测并且发布上线，在没有测试人员参与的情况下发生过不少问题：新功能影响了旧功能（发布回归验证没做），研发人员冒烟测试没有指引，播放器的发布时间不固定，测试人员不能及时跟进。在众多播放器中，表现的功能其实是一致的，于是需要引入播放器自动化测试的解决方案。例如Flash的业界常见解决方案：

SeleniumFlexAPI.swc好多年没有更新了，如果flash播放器的解决方案与H5的不同，就需要多投入资源，对于现阶段而言没有过多精力，团队决定打破常规，采用一种组合的策略统一H5和Flash播放器的解决方案：

持续集成平台引入播放器自动化测试构建，每次研发需要发布播放器版本的时候，自动执行回归用例，产出报告，查看通过率。

除了在开发过程、回归阶段获取收益，该方案，组员申请了专利《广州易方信息科技股份有限公司一种非侵入式的Flash播放器自动化测试方法》。

Windows-GUI自动化测试工具

背景：POLYV直播客户端-云课堂，每次发布之后，需要回归核心功能，人工成本高。

工具首选：Python结合Pywinauto 进行 Windows UI 自动化

基于开源框架二次封装，完成基础核心功能模块的自动化用例，用于持续集成打包之后，自动化回归验证，目前已经应用于多个直播推流客户端：POLYV云课堂、直播助手、大班课。

自研的在线用例管理平台

设计初衷：减少xmind传递成本，统一线上维护用例脑图，有效开展结对测试和评审，同时掌握用例覆盖度，有数据统计支撑需求、功能的质量。

当时提出的一些需求参考如图所示：

测试任务的评估依据

ToB产品的商业价值&质量非常重要，测试任务的评估分为两个维度：按照产品的质量等级和ThinkPoint来做组合：

产品的质量等级

Think Point评估依据

参考了以前网易的经验，增加跟业务相关的维度

团队人才建设

18年初的测试团队规模太小了，业务测试需求无法完全覆盖，人员技能集中在功能方面的黑盒测试，没有分层自动化策略，研发API管理局限于文档、wiki形式，没有相关平台支撑，测试团队缺乏测试开发的相关经验，技术功底不足以推动团队前行。

从18年Q2开始制定团队建设计划，那么整个测试团队的关注点是什么，如何聚焦，根据技术总体需求、产品需求来落实测试需求呢？

团队的特性就是需要快速前行支撑业务，聚焦重点，释放重复劳动，使用自动化辅助的方式，改变现有业务支撑的调配方式，让测试工程师们更多参与过程中指导研发团队提升成熟度。

根据团队特性，测试、开发划分了边界，只有从这些方面出发，才能更好要求组员的技能形成阶梯化，以及在招聘要求是按照此需求来落地，市场上大有可为之人，如何切合实际为之更重要，下面从几个方面来谈谈。

测试团队转型

从单一手工测试进阶到全栈测试开发工程师，比如负责登录功能的测试工程师，除了完成功能测试，还包括登录的性能测试、自动化测试、安全扫描等等。

多项技能发展，每个领域都有专家，基础分水岭：2-3年资深分水岭：3-5年专家分水岭：7-10年。

测试组架构及分层测试策略

根据测试层次关注点，把测试团队拆分虚拟小组，划分测试架构策略：

现阶段以功能测试为主：五人业务功能小组，挖掘功能测试痛点转为自动化需求；
探索提升API功能测试、性能测试为辅：由测试开发组负责，集中解决业务服务层关键点测试；
按需进行Web安全测试扫描：基础平台搭建，全员可参与自助扫描；

而对于重中之重的业务功能，测试分层策略如下：

UI Test

→ 轻量级GUI自动化投入：新功能手工测试为主，核心功能加入自动化用例集合

→ 播放器自动化测试：解决回归验证、日常巡检

→ SDK自动化测试：解决前线客户槽点

→ 探索式测试：打破传统功能测试局限，提高小项目测试效率

Service Test

→ HTTP API功能、性能自动化测试：解决关键业务点验证，脱离终端耦合

→ Socket io自动化测试：解决长连接验证问题

Unit Test

→ 代码层级：解决PC、Android、iOS 等SDK对外DEMO测试问题，不参与研发函数级别测试

通过一系列培训，新招的应届同学已经可以使用Visual Stduio进行PC SDK的相关测试工作。

人才招聘

招聘更好的人，宁缺毋滥

在《重新定义团队》中，作者花了很多的篇幅强调招聘的重要性，Google 的原则是宁缺毋滥。打造一个优秀的团队很费功夫，而让团队瓦解却只需要一颗老鼠屎。

创业公司一个窘境就是起初没有太完善的HR制度，人才筛选比较费劲，需要更多leader亲力亲为，这也是在创业型公司更容易成长的地方之一。

招聘是一种艺术，第一轮是笔试题，大多数与专业相关，包括编程题；第二轮是面试，作为面试官，在整个过程中，我会使用沙漏，告诉面试者你有30分钟以内的沟通时间，围绕：工作经验、项目解说、学习能力、场景应答，大多数通过行为面试法来解决。

相对于大公司繁琐的面试、等待结果的过程，我们在原则上一般面试完就答复是否录取，无须回去等待太久，避免给双方带来时间上的损失。曾经一天安排了18人笔试，集中面试8人筛选给出结果后马上安排入职。

人才培训体系建设

人才招聘进来了，怎么成长呢？

市场价值导向决定公司战略，公司战略决定研发、测试团队投入资源。

首要把主力军放在核心项目上，短期小项目在合规的流程内运作，人员经过培训后可进行简单快速地开发、测试，因此，在注重效率和合理分配资源的同时，开发了N+3 Plus 新人培训模式，与传统大公司的模式错开（有些大公司繁琐的制度、人力培训，长达两个月的项目实战），更加快速投入到实战环节进行验证。

N：主要由HR以及业务小组定制培训内容和时长，不同团队定制时长不同；

3：集中投入3天时间在项目实战环节；

Plus：持续改进，不断提升技能，符合团队业务价值发展；

N+3 Plus 新人培训模式在测试团队成功开展两个季度，历经十多名新人实战，快则一周后参与项目实战，慢则两周。

测试团队文化建设

在大公司谈论团队文化建设，比较容易，有体系的沙龙、导师制度以及月度的分享，创业公司怎么做呢？

艺术来源于生活，然而生活本身就应该是艺术

业界的分享太多了，照搬过来消化不了，我们鼓励工程师们从实际出来，把项目中用到的解决方案、新技术，系统化整理后组织以分享的形式传播给大家，也就是分享源自于实战，但是又要高于实战。

鼓励全员参与文化建设，比如说安排测试技术调研，每个人选一个方向突破投产使用。

跳出测试思维的条条框框

测试过程质量的高低，能够体现出研发过程的工程品质，但测试不是万能的。

如何根据市场反馈以及经验模型，结合数据分析，做到精准测试更为关键。

对于创业公司，唯快不破，但又不能让质量掉队，精准测试的打法势在必行。

前不久，北京的老同事问我，是不是现在不玩自动化，都去玩什么混沌工程了，在测试中如何应用呢？

这个问题挺有意思，抛开自动化，平时测试用例得覆盖度越详细、越深入，发现的问题越多，随之而来修复的越快，交付的质量也会随之提升。单纯手工测试，蛮干是可以撑一阵，自动化只是一个工具，没有它就不能活吗？并不是的，测试人员需要更多独立思考，跳出原有的条条框框：围绕工程品质，成本收益来谈。自动化、容量评估、链路治理、线上问题追踪，以及精准测试分析、性能链路监控、资损防控，玩法太多，甚至望文生义的混沌工程，怎么玩得天花乱坠都可以，关键是落地有收益。

混沌工程到底是什么。根据 Netflix 的解释，混沌工程师通过应用一些经验探索的原则，来学习观察系统是如何反应的。这就跟科学家做实验去学习物理定律一样，混沌工程师通过做实验去了解系统。
生活中有类比的例子：你在家里每天吃饭会用筷子吧，万一去到印度，直接用手扒饭，你就慌了，因为不熟悉的事情害怕发生，熟悉的事情，天天发生应对。混沌工程应用到测试中，可以理解为：让事情发生成为常态，常态的事情，你已经具备管用的处理办法。例如所有异常机制持续集成可以回归覆盖，线上冷数据转为热数据

一个是研发过程质量，一个运营质量，还有一个是前置的问题解决等等，整个研发工程品质，涉及方面太多了，不能局限关注测试过程，把眼界放宽，看的更远、更广，有些事情比写多几条、执行多几条功能测试用例重要，在我看来，测试不仅仅是一个团队，还有工具平台开发，还会涉及很多系统工程化问题，称为QA工程团队更佳。

作者介绍：

李乐，2018年4月离开网易，加入保利威，负责QA工程团队建设，以及研发过程PMO管理、技术运营等。

原文链接：

https://shimo.im/docs/QPqqVcWTTVvQYjxP/read

创作场景

QA 工程团队转型经验分享：从大公司到创业公司的打法