汽车之家新车电商测试负责人叶微微谈6步打造高效测试团队

大家下午好，我是汽车之家新车电商测试经理叶微微：

我今天来跟大家分享一下6步打造高效测试团队，首先我来说下测试目前的一个现状，我个人理解测试应该属于一个弱势群体，很多测试同学抱怨：地位底，不受重视；待遇差，成就感低；压力大，加班，提升难；不稳定，得不到开发的认可，特别是背锅的时候首先就是说测试没测试到，测试的场景里面没有这种情况，人员裁剪的时候第一个想到测试，而且测不能生成更为有价值的产出物，我认为行业里面有些人对测试时有一定误解的，我今天来讲下我是怎么打造这种高效测试团队，同时得到领导与开发以及相关人员的认可的，我在这方面有一定的经验，我来跟大家分享一下。

在分享之前我先来做下自我介绍，我叫叶微微，我是2014年加入汽车之家车商城的，作为车商城测试主管负责整个车商城相关系统测试工作，我个人比较擅长团队的打造，人员的培养，以及测试流程体系的构建与优化，而且比较擅长跨部门沟通，指导测试团队测试平台化体系的建设。我在汽车汽车之家这个过程中我的测试团队在汽车之家的认可度比较高，特别是开发领导对我们还是比较信任认可的，2017年我们测试团队是汽车之家唯一一个测试团队被提名公司最高奖的提名奖，所以我认为我们在团队的中的认可度还是比较高的，我将从以下6个方面来讲述高效测试团队是怎么打造成的。

首先我们先来看下目录，第1个：员工差异化培养，第2个：分层管理设置备份，第3个：流程规范和优化，第4个：团队知识体系构建，第5个：创新提高团队影响力，第6个：实现员工价值，下面的话我会一个一个的来跟大家分享我是怎么打造高效测试团队的。

第1个我们先来说下员工差异化培养：其实我们所有的这个高效的线是应该贯穿我们团队对应的阶段来走的，比如说团队前期，团队中期，团队后期，围绕这条线来构建，团队前期我们需要什么样的人我们是要明确的，在团队前期我们需要稳定而且综合能力比较强的人，而且较强的组织影响力，能够推动项目的这种人，什么叫稳定而且综合能力比较强的人，就是说这个人一定要能够抗住压力，不是说干两天不干了的，还有一个就是要技术能力与业务也要比较强，对git，对jenkins，对redis，对mq，对nginx等都要比较熟悉，而且测试过程中能够发现逻辑性比较强的BUG或者是底层更加严重的一些BUG或者是一些业务流程上比较严重的BUG，而不是只是页面上点点，而且要深入系统内部，对于自己发现的问题可以分析问题发生的原因，能力更强的甚至可以提供解决问题的方案，这样就会在团队中产生一定的影响力，而且我们能在项目发生风险是提出对于的解决方案推动我们项目向前，还有要对测试敏感，什么叫对测试敏感了就是说你能发现测试过程中的一序列的BUG，在需求中你能发现需求的不合理，在测试设计中能够合理的设计测试策略与测试方法，在开发设计发现开发设计的不合理，在测试中你能发现更多的BUG（包括交互的，功能的，性能的，安全的等等BUG）,这样的话对项目来说是一个很好的促进保障作用，还有一个我们能搞定测试环境，比如说我有一个重构的项目让你来测试，其实这个时候我是有两套环境的，一套是之前的环境，一套是现在新的系统，比如测试可能只懂是简单的host的配置，系统里面的各种调用，以及我请求的请求是不是到了那台服务器上，这个人不知道，测试完了才知道不对，这个时候对我们项目来说风险是很大的，所以说我们必须要能够搞定测试环境，还有一种像dubbo的分组，如果分组配置的不对，你测试的东西必然是不对，还有我们搞定性能与安全，比如在团队前期我们一些关键的页面与关键的接口以及关键的流程，我们一定要能够保证在系统峰值的时候能够坑住我们的流量保证业务还是正常可用的，还有就是我们电商这样的网站一定要保证用户数据的安全性，不能够A可以看到B的数据，B还可以修改A的数据特别是这种越权的数据校验这种基本的安全必须要搞定，还有包括XSRF,XSS,SQL注入这种安全的测试也要能够搞定。我们团队在这个阶段人是很少的，所以必须需要这种综合能力强的人，这种人几乎可以解决测试所有的问题。

第二就是我们在团队中期我们需要差异化培养团队人员，什么叫差异化，如果我们招聘的名额允许的话我们肯定是什么样的人我们都需要，自动化性能安全专项业务测试专家等等，那么这样对团队来说也是一个很好的辅助作用，但是如果我们的招聘人员不是那么富裕的话，那么我们就需要根据人员的特性去差异化培养人员，当然是在这个测试必须可以搞定新业务测试的基础上，比如这个人对自动化比较感兴趣，有些人对性能感兴趣，有些人对安全干兴趣，有些人对专项感兴趣，那我们这个时候就要利用他们的这个兴趣去差异化培养他们，我们去安排的工作的时候也可以根据这个去安排，这样对我们的测试工作是一个很好的整合作用，也保证测试的稳定性，在我们团队的后期我们团队本身比较稳定了，我们就要去提升我们测试的效率的事情上去做一些改变，比如做一些平台化啊，大家只要填写场景化的测试数据就可以，然后通过平台定时间跑一些任务这样可以协助我们的业务测试帮他们节省一些时间放在更加重要的任务上面，同时我们招人就要招架构化的人才可以帮我们来更加规范的做一些高效流程架构以及工具架构的改造。

我们接下来讲第2点分层管理设置备份，我会从以下4个方面来说，其实这个应该在团队中期做这个分层管理设置备份更好，管理要分层，管理者在前期相对来说肯定是事必躬亲，大家都知道很多技术的管理者都是技术比较好然后提升上去的，他们大部分对管理把控的不是很好，而且不能够做到适当放手这一点，技术性的管理者喜欢什么东西都自己做，你团队5个人还好，10个人，20个人你肯定就不太好了，团队中期团队慢慢壮大那这个时候我们就要学会放手，让团队成员承担更多这种责任，当然一些重要的大的项目还是需要去监督管理一下，有一些相对比较小的我们就要让团队成员自己去承担去处理，可以提升他们的管理能力、项目处理能力、技术能力等都可以得到提升，第2在团队发展中期我们设置组长这种制度，比如我有15个人的时候我可以分两个组，那对我来说我就只要对这两个人，而不是对这15个人，而且我的一些管理理念与策略可以通过这两个人去传达，前期我可能会监控一下项目，然后看看执行结果，其他时间我就可以干工作上更为重要的事情，这样对我自己来说也是一个提升，对团队来说也是一个进步，还有一个就是说一些重大项目我们可以设置一个主导测试这样的一个角色，这个主导测试一定是对需求、测试设计、开发设计、测试执行、上线监控等等都需要参与的，那主导测试他对整个项目的全部过程都是比较透明的，最后把整个项目结果都会反馈回来我们就可以更好的控制整个项目的执行。然后还有一个就是资源的合理调配，从以下两方面来说根据人员特性合理安排工作，还有要项目安排有侧重，在合理范围对测试工作进行降级，什么叫根据人员特性安排工作，有一些人做测试他比较喜欢从全局的角度考虑测试起来比较快，能够发下一些流程的的BUG，有一些人喜欢从局部的某个功能模块角度考虑测试起来比较慢但是能发现更为深层更为细节的一些BUG,那我们可以考虑这种快慢接合粗细搭配的方式，能够很好的保证项目的质量问题，同时我们对项目安排也需要有侧重，我们测试拿到所有的项目不是说所以都需要测试比较细比较深入，那这个时候我们需要去做项目或者功能模块的优先级以及功能的重要成度做一些判断，哪些是非常重要的我们不能够降级，哪些可以走大流程，哪些可以不测试我们可以做一些判断，那我们就能够把更多的测试资源放到我们不能够降级的事情上面去，这样会很好的保障了测试的质量与效率。

还是就是我们要去可视化汇报，我会从以下两个方面来说项目管理可视与Bug管理可视化，项目管理可视化：包含项目拆分、提测依赖、进度、风险、上线清单、上线依赖我们都需要告诉我们的老板以及所有相关的项目方，不是说这些东西都要等老板或者相关人来问才知道项目的进度与风险，那这样的化增加了项目的风险以及不可执行性，通过可视化就可以避免很多这样的现象，老板也不会盲人摸象，比如我在双十一等重大项目过程中我就把项目可视化的看板或者时问题提前告知老板项目进度项目风险等问题，我会从各个点上去分析，以及风险对应的解决方案是什么，测试需要干什么，或者是我不能控制的我需要举手告诉我的老板以及对应的相关项目人员来规避一些风险，还有一个就是Bug管理的可视化包括BUG增量统计、收敛统计、处理时效统计，如果我有一个项目是一个星期五天这样的工期，我第一天提了10个Bug，第二天提了50个Bug，第3天提了100个bug，那这肯定有问题，不符合常规，为什么我们的问题不在前面两天发现，第一天没怎么测试还是测试不了，或者是有什么block住了，那我们就要反思为什么会这样，那我们通过可视化老板就很容易知道这样的问题以及风险，还有就是Bug的收敛统计，还是刚刚的例子，我第一天提了100个Bug，第2天提了50个，第3天提了30个，我们这个时候就要看开发解决的Bug是否有收敛，但是开发第一天解决了10个，第二天5个，这个收敛向下的趋势就有问题而且不明显其实对我们项目是有一定风险的，通过这个可视化我们就可以告诉我们老板或者开发老板这个风险，可以预防一些项目风险，还有一个就是Bug的处理时效，刚刚也说了开发解决了bug我们测试没有及时关闭，还有就是bug库里面的bug开发压根就没怎么解决过，还有就是我们有些bug解决了测试又reopen了，这个时候项目是有风险的，我们就要分析原因，是测试没来的及关闭，还是测试任务过重还是开发任务过重，我们要去分析这样的原因可视化给都我们项目对应的人，我们就可以预防一些项目风险是有一定作用的。还有一个就是分层管理最后一个环节我们各级要设置备份人，要做到人人有备份，谁不在，工作也能有备份来做，包括管理自身，尤其要有备份。

下面我们从6步打造高效测试团队的第3点流程规范和优化来说，其实我们测试在产品和设计过程中需要有规范的思维模式，测试按照规范的思维模式，拆解项目和发现项目的依赖和关联性，比如说我拿到一个购物车的项目我们测试需要有规范化的思维模式，在需求与设计阶段我就要搞清楚项目的目的是什么，我们要解决什么问题，我们项目的完成时间点，我们这些背景都搞清楚，我们就要进一步分析我们现有系统是否可以满足当前需求，或者是是否可以简单的实现就可以满足当前的需求，如果这些都考虑了之后或者是实现不了，那这个时候我们根据产品和开发的设计我们就要穷举一些系统，然后再确定系统关系购物车与用户中心、交易系统、商品系统、库存系统、促销系统、优惠券系统都有关系，然后再拆分这些系统模块，再拆分这些模块的系统功能，了解这些系统之间的数据的一些特性，然后再细化系统功能模块，加入开发的设计，那这样的话我们就是一个完整的思维模式对我们整个测试效率是有很大作用的，还有就是我们的提测流程，我们一定要有冒烟测试，这个冒烟包含两个方面，这个东西是我们在测试过程中发现的问题，比如说我们做过一个大项目，开发最后开发出来的东西不是业务想要的也不是产品想要的东西，或者是产品的需求本身就出错了，那这个的话我们流程的浪费是很多的，对测试对项目来说这种问题是很要命的问题，所以在大项目的时候我就加了一个业务与产品冒烟在测试冒烟之前，如果业务与产品说不行我们项目还有可改的余地，如果到了后期我们改的余地都没有，如果产品与业务冒烟成功了后我们有我们测试的一些标准，比如大流程的各个节点不能够影响流程的block住这种现象，如果有block的这种现象我们一定要打回去，这样对我们项目也是一个很好的保障作用，还有提测的规范，提测代码的 地址，tag，数据库变更，配置文件等修改我们都需要些清楚，还有就是我们规范代码结构、规范部署路径和配置、规范日志路径、规范日志格式，其实这些我们以后的CI与代码diff等都有一定的作用，特别是精准测试的也有一定帮助，还有就是我们测试过程中发现了一些问题，我们可以通过规范的日志与日志格式找出Bug产生的原因，找到对应的出问题的类与方法，我们就可以帮开发节省很多时间，这样很容易获得开发的认可，具备这样测试能力的测试其实现在应该是越来越多（以前比较少，只要提了bug就可以了），现在越来越重视这方面的能力了，还有一个就是上线流程，我们在一些大项目必须有上线排期会确定确定上线依赖和回滚策略，这个步骤在大项目中一定不可以省略，特别是一些新来的开发很容易忽略这个上线排期会，对这些东西不太重视，我们有时候不会所有流程都去监督，那这样就会导致一个一个问题他们本身有些问题，比如之前一个系统做了俩三年的好多人不知道这个逻辑，现在这个大系统重构，你对数据进行清洗的时候你就会出很多这样或者那也的的问题，只要是没有进行上线排期的会的都会出现各种问题，如果有了上线排期我们就验证下我们的上线清单包含我们的redis配置，mq的配置，集群的配置，nginx 的配置，数据库字段以及数据的清洗的变更，以及代码本身配置的变化进行一些验证就可以保障我们出问题的几率变小，还有如果我们出线了线上问题的时候我们优先解决我们线上的问题，而不是先去划分责任，还有我们在上线前需要有快速排查按问题分类汇总，我们双11就做的很好，每次上线前就先线想好一些会出现的问题，想好问题的解决方案，这样我们在出现问题我们可以快速查找对应的解决办法，还有就是问题解决完后我们一定要进行问题的复盘与总结，做到出现过的问题不会再犯，还有我们项目上线完后还需要我们进行很长一段时间的测试监控，我们需要进行一些线上主流程，一些对外暴露的接口的接口状态与接口逻辑的校验，这样我们可以保障我们项目的稳定执行。

然后我从6步打造高效测试团队的第4点团队知识体系构建来说，我也是从下面四个方面来说一下：第1个业务流程体系索引化、第2个是测试技术教程化实例化、第3个是测试策略规范化、第4个是管理文档归档，第1个业务流程体系索引化，模块化功能或操作，索引化流程对应模块其实是这个意思就是我拿到一个功能模块我们要进行测试的话我就要进行拆分功能模块，比如我拿到商品详情页我就要把商品详情的各个模块拆分出来，比如我涉及到商品图片的、商品价格的、商品促销的、店铺优惠券、商品优惠券、平台优惠券、库存的、涉及到分享的这些功能我全部模块化掉，模块化掉之后我通过场景化来组装这些模块的思维，如果有些场景有重复的模块我们就不需要重复编写这样的模块通过索引就可以找到对应的模块，我们编写这些文档的标准是：任何一个没有接触过的测试，按流程文档可以操作下来并知道如何测试，降低交叉测试和人员流动的熟悉成本，我们可以很方便了解我们所以的场景以及模块，对我们提升测试效率是有很大帮助的。

第2个是测试技术教程化实例化从以下3个方面来说，对于自动化测试、性能测试、安全测试、业务测试等技术，教程化，有实操这个是我们最基本的要求，平时我们的团队核心成员必须做技术分享，对培训结果进行检查，我们在培训之前就想好我们的检查点，通过培训后的结果检查也可以知道我们培训的效果以及讲师的培训质量，通过这种技术培训，弱化员工在团队中的作用，预防人员流动风险，而不是我们的核心成员离开了之后，有些大项目难项目就做的不好了就不能做了这样肯定不太好，所以核心走了我们可以看他之前的一些文档一些培训就可以上手干活去处理，这样降低了项目的风险，还有一个就是说测试策略规范化，按照我们能够提前发现需求和设计阶段的问题、测试制订测试策略有依据、测试一些中间件组成的架构时有深度，比如说我去测试详情页的时候我们就要知道我们哪些数据是走redis的，那我就要有一定的规范，我要知道我的我们什么时候初始化redis缓存数据、什么时候更新、什么时候失效、什么时候删除、什么时候穿透回原、我的补偿机制是什么，把redis涉及的测试我们都按照这样的策略来进行测试，那对我们后面的测试也是这样的规范然后进行扩展下那是不是我们测试起来就保障了我们测试起来有一定深度，还有第4个是管理文档归档，新人入职就需要看新人入职的一些文档，前一个星期该干什么，后一个星期该干什么，后面跟项目深入，还有一个是环境管理我们进行归档，我们新人来了后就知道我们所有的环境在哪，我们的入口，我们的账号，我们的数据库等等有对应的文档就可以提升我们新人也好相关业务方也好（产品开发）的执行效率对项目有一个很好的推进作用，然后我们对我们做过的项目进行一些归档，以后不管谁走我们可以找到对应的逻辑，不会人走了逻辑也没了，能够很好的提升我们的一些效率，这事在团队前期阶段就需要开始贯穿。

还有一个就是创新提升团队的影响力，我也是通过以下四个方面来说，平台化的建设、平台推广、著作权与专利、外部分享对吧，平台化的建设我从接口自动化、性能自动化、CI（部署+持续集成代码扫描、覆盖率监控、自动化测试）、设计商业化这四个方面来说，其实接口自动化的化其实针对我们团队中期我们有了一些专业的人，我们前期可能写一个脚本就处理的，脚本把数据与执行逻辑都混在一起，那我们在中期就把这种数据抽离出来出来放到excel或者csv中，慢慢到我们业务发展很快我们这个也不能够很好的满足我们的测试需求，我们的人员也比较多，我们这个时候可以写成平台化的这种关键字驱动的这种方式，我们把逻辑也放到页面上，数据放到数据库中，方便不懂代码的人员操作一些更为底层的测试，提升我们的测试效率，还有性能自动化也是，还有一个是CI就是团队的中后期，我觉得更为重要的就是精准测试，就是我们开发改动了一个系统的某个模块，那我们这个时候可以根据我们代码覆盖率的去判断我们测试的覆盖是否完整覆盖，这样对我们测试来说其实也是很好的一个提升效率的方法，还有就是静态代码扫描我们可以根据我们自定义的一些规则，以及findbugs里面的一些适合我们的规则可以在代码提测前就能发现我们的代码的一些不规范的代码，然后就是商业化如果我们平台化做的确实很好了我们可以商业化，当然我们现在还没有达到这个高度。

还有一个就是平台化的推广，我们在中期后期我们平台化做的相对来说比较好了，我们这个时候要从效率方面去考虑提升我们测试团队的效率，我们可以把平台化的这个工具推广给我们的测试与开发去使用，提升他们的效率，协助手工业务测试把一些可以通过机器重复执行的任务或者是手工测试干不了的活交给平台去自动定时执行，业务测试可以释放一些测试时间到更为重要项目上面去，提升我们的测试效率，以前我们的开发需要写很多单元测试的用例现在不需要了甚至调试也可以在我们平台上进行，如果我们做的更好的时候我们可以推广给我们外部团队也来使用，我们持续优化平台，我再来讲一下如果我们团队要获得别人的认可我认为这个事情必须要做，那就是著作权和专利，我们每年申请一次著作权和专利，这个跟高效可能作用不大，但是跟认可是有一定作用与影响的，我们只有可以保持团队的活跃性有一些创新的点子，比如我们我们平台化，我们的接口测试我们对dubbo接口关键字驱动，就是我们的测试不需要去了解底层代码，以前dubbo底层代码接口测试你必须熟悉代码才可以进行测试，现在你只需要填写场景化的场景数据就可以了，方便了无代码经验的人员快速进行测试提升了测试效率，其实我是觉得有一些创新的，还有就是参加一些外部分享，我们可以参加一些外部交流以及测试大会与技术大会，其实这样提升我们本身的一个认识我们可以很好的了解一些行业新技术与新应用，我们也可以把我们好的一些理念与新技术传达给外界，也可以发现我们自身的不足。

下面我来讲两个我们创新的流程，第一个是XP流程创新（主导测试只需要编写测试用例以及自动化测试用例功能回归测试，测试可以放到更重要的项目上面去，节省很多重要测试资源），还有个是接口测试平台Dubbo接口关键字驱动，利用java语言整合了Spring与Testng两大框架，实现http接口和dubbo接口的动态调用，方便无代码编写能力的测试人员使用，我们这套东西本身体现在几个方面，接口参数动态调用，时间戳、签名、token、接口上下依赖，还有dubbo接口本身不易测试性，这几个我们都知道是本身手工测试不太好测试的地方，还有我们这个平台最为创新的地方就是Dubbo关键字驱动，只需要些场景化的测试数据就可以（对应dubbo我们都知道要测试他必须要知道dubbo消费者服务的接口的代码，如果不熟悉我们不可以进行测试我们，dubbo接口测试实现方案，使用spring框架去自动订阅zookeeper服务，消费服务端接口。通过反射机制动态生成请求接口类，请求接口方法和接口请求对象数据。http/https接口测试实现方案，使用 JSOUP 请求方式，动态参数生成请求数据，实现绝大部分https接口请求）。

最后就是实现员工价值，我们也从以下四个方面入手，精准定位合理安排、挖掘潜能、帮助提升和晋升、扩大影响力获取成就感，然后第一个精准定位合理安排，根据人员的执行力、组织影响力、学习能力，合理安排员工的成长方向，这个其实是这样的我们在团队中后期会这么干，团队前期人员本身的能力比较综合，中后期我们一定要做人员的这个方向规划，让员工获得更好的成长，比如说我们团队中期我们人越来越多我们就要根据人员特性来安排他们对应的工作让他们在对应的领域得到一定的发展，前提是必须搞得定业务测试，比如还有人测试更为关注流程上的，有人更为关注系统细节上的那你就把他们综合调配一下保障系统稳定效率兼顾，对项目本身是一个很好的促进作用，还有一个他们对这些自动化、安全、性能、专项有爱好，那我们就要根据他们的爱好制定可以落地的KPI，但是这个kpi一定是要能够落地的还需要量化，比如接口测试：你老板说要你把所有系统的接口都要用自动化覆盖到，这里面有两层含义，一层是你所有接口只要能够正常调通能够返回接口状态码为200，还有一层是你接口正常异常接口字段的可填必填以及逻辑的校验这两个不是一个级别的，所以做KPI也是要根据实际能够落实的，可以按照1期2期3期这样来对测试也是一个促进作用，也可以让他们获得更好的成就感，还有帮组提升晋升，让员工获得管理能力、技术能力、项目能力和测试能力提升，我们在团队前期开始就开始主动让员工负责一些项目让他们能够或者一些方面的能力也好，技术也好，然后还有好的优秀的员工一定要让他们获得晋升不管是物质上还是精神上都需要让他们获得到提升，最后一个就是扩大影响力获取成就感，这个多做分享多做总结，第一可以认识到自己的不足，第二可以让自己的技术获得提升、第三可以把自己好的一些技术或理念传达给到大家，以上是我们的分享，谢谢大家，还有句话送给大家，不管是管理者也好还是执行也好可以思考下：

诸葛亮从来不问刘备，为什么我们的箭那么少？

关羽从来不问刘备，为什么我们的士兵那么少？

张飞从来不问刘备，兵临城下我们该怎么办？

如若万事俱备，你的价值何在？