GitChat 作者：梦婷
原文：大众点评搜索测试全揭露：1:9 的测试开发比下 QA 如何前行
关注微信公众号：GitChat 技术杂谈 ，一本正经的讲技术
【不要错过文末活动】
背景介绍
本人2012年7月以应届生身份进入大众点评搜索团队，整个团队QA（测试）共3人（包括我，后1人于11月离职），RD（开发）约15人；2013年，QA依旧只有2人，RD增加至20人；2014年8月起因承接点评Web和APP的搜索相关前端业务，新成立搜索移动端团队，当时QA 4人，RD约35人；2015年，专注于算法的搜索体验团队也独立并壮大，最后整个部门的RD演变为45人（搜索平台团队15人、搜索体验团队20人、搜索移动端团队10人），QA共5人。
搜索平台团队
该团队负责整个点评的搜索引擎平台和所有业务搜索系统（100+），例如大家常用的商户搜索、优惠券搜索、用户点评搜索、团购搜索等。
搜索体验团队
该团队负责所有业务搜索的排序算法优化、推荐系统，例如如何精准匹配用户意图将理想的结果排在前面、如何为搜不到满意结果的用户推荐可能感兴趣的团购等。
搜索移动端团队
该团队负责所有搜索前端业务，例如点评WEB站、APP上所有搜索提示页与列表页。
2012年7月我加入时，整个团队基本处于这样一种状态：RD接业务A需求A1、A2、A3，业务B需求B1、B2、B3，业务C……A1开发完成QA在Alpha环境测试A1功能，A2开发完成QA测试A2功能，A1+B1+C1的代码变动一起合入Master分支在Beta环境进行集成测试，然后周二或者周四发布到预发布环境、线上正式环境。
QA永远有做不完的Alpha功能测试、Beta集成测试+回归测试、预发布新功能验证+回归测试、线上验证与回归测试。妥妥的车轮战，印象中没有9点之前下班过，临发布加班至11点也是常有的事。这样的节奏与工作状态，也导致没有时间进行测试理论或者技术方面的提升，包括性能测试、安全测试等方面的深入，总之就是苦日子看不到头，而且没有成长的盼头。
团队现状
在我2016年离开搜索部门之前，负责搜索平台团队质量保障工作的QA 2人（兼有整个团队测试工具开发、持续集成系统维护、搜索测试环境维护职责），搜索体验团队QA 1人，搜索前端团队QA 2人。
各团队QA日常
搜索平台团队
该团队2个QA主要负责跟进A级别(可简单理解为>20人天开发量)项目测试，维护CI系统，维护搜索所有后端业务测试环境，定位功能自动化回归失败原因并解决，分析性能回归失败原因并与开发共同定位性能问题，为开发提供其他必要测试支持（例如项目风险分析、开发自测侧重点分析、对开发进行性能测试培训、结对测试辅助新入职开发提高代码质量），开发测试效率提升工具，定期和RD进行线上缺陷和流程Review，以质量提升为目的进行流程优化，推动开发定期进行降级演练等。
搜索体验团队
该团队1个QA主要负责搜索体验团队重点关注的商户、团购搜索和推荐效果，维护由于算法改动造成的对应业务自动化失败，根据业务发展进行性能回归场景变动，分析性能回归失败原因并与开发共同定位性能问题，根据各开发代码质量做出不同级别项目的测试支持，严控发布质量。
搜索移动端团队
该团队2个QA主要负责点评APP Android和iOS客户端每个版本的搜索相关需求功能测试、兼容测试、基于场景的专项测试、用户体验测试，维护Mobile API功能自动化、UI 功能自动化、打点数据上报功能自动化脚本，并根据每个版本测试情况提供测试报告和各开发代码质量优化侧重点报告，定期Review推动开发代码质量提高。
自动化情况
搜索平台和体验团队，所有重要业务的搜索后端系统，均有用例覆盖率80%以上的API功能自动化（P1/P2用例覆盖率100%）和常用场景的性能自动化；搜索移动端团队，Mobile API P1/P2功能自动化用例覆盖率 100%，UI P1/P2功能自动化用例覆盖率 100%，打点上报P1功能自动化用例覆盖率 100%。以上所有自动化日常通过率100%，一旦出现Fail，QA第一时间定位原因提交Bug或者修复。
持续集成系统情况
搜索平台和体验团队
CI（持续集成）系统会每15分钟轮询一次代码仓库, 一旦发现Master分支代码变动，触发API功能自动化Job A。该Job会拉取最新代码，打包，启动搜索Service，执行Beta环境对应功能自动化脚本。
如果Job A通过，CI触发对应代码自动部署到Beta环境和性能环境。Beta环境主要供搜索RD自行进行新功能验证、供其他业务团队RD&QA联调使用；性能环境主要服务于性能自动回归，将对应业务最新搜索系统性能和基线版本进行对比，若QPS等指标变化超过阈值则邮件报警，监控显示屏上对应Job飘红预警。
如果Job A失败，CI自动邮件给本次代码改动相关RD进行报警，监控显示屏上对应Job变红并展示此次代码提交责任RD。搜索平台或者体验团队QA看到红色Job也会立马介入，分析本次失败是Bug还是BCD级别项目的逻辑变动导致，然后提Bug或者根据最新逻辑进行修复。
在2014年本人转向移动端测试之前，这一整套已经完成并持续服务至今。当时我们的监控可视化系统其实就是树莓派的主机+两个显示器，可以给大家看一张监控显示屏的效果图：
搜索移动端团队
移动端团队RD部署MobileService代码到Beta环境后，发布系统会自动触发CI上的Mobile API功能自动化回归 Job，对于API的功能自动化结果监控与处理，同平台与体验团队。
移动端UI相关代码则随点评APP的版本发布流程进行合并、测试与发布，QA会在执行该版本新功能测试之前进行UI功能自动化脚本维护与回归，并在回归测试阶段进行打点数据上报功能自动化回归及脚本维护。
各团队RD日常
搜索平台和体验团队
RD在需求评审会或者开发设计评审会上和QA共同评估项目级别。A类项目QA全程跟进；B-D类项目RD则根据QA提供的风险分析、自测重点分析、自测用例等自行进行业务代码和UT开发、Beta环境新功能验证工作。
如果功能自动化回归、新功能验证都通过，RD自行发布代码到预发布环境，发布系统会同时触发预发布环境的功能自动化回归，RD进行新功能的验证后，若没有自动化回归失败导致的短信报警，则自行发布到生产环境。
完成生产环境一台服务器的灰度发布后，发布系统会自动触发对应业务的搜索请求DIFF，即：利用真实用户请求，对灰度机器和其他任意一台机器执行相同的搜索请求，根据结果的对比报告，校验本次改动是否在预期之内。该工具同时也能反馈出算法类的改动对排序的影响到底有多大。
在生产环境，QA们维护的线上功能自动化会定期（按级别5-15分钟不等）轮询校验，一旦失败自动触发短信报警。如果DIFF结果分析没问题，RD在发布过程中一边查看各台服务器Log是否存在异常情况，一边等待线上功能自动化的验证，若15分钟之后一切正常，则本次发布完成。
每位RD很可能每天都会进行这样一整套流程，而且由于QA与RD约定后端服务只要避开请求高峰期，5个工作日全天都可随时进行发布，因此后端搜索服务的发布频率根据业务需要可以非常高，印象中单单商户搜索系统曾经一天发布5次。
搜索移动端团队
相比后端团队RD而言，这个团队的RD可能更“幸福”一些，因为发布遵循APP版本发布流程，有专门的团队进行打包发布，不需要他们操心。他们除了开发代码，更多的对质量的支持在于辅助QA进行一些提高测试效率的工具开发、每个版本之后和QA共同Review质量问题，根据QA的报告和自己的薄弱点有意识地进行质量提升。
3年里我们到底做了些什么
搜索平台和体验团队
自动化困境与破局
本文第一部分描述了2012年QA的惨状，当时其实RD也很惨，所有搜索业务的代码全部都在一个应用里面，每次发布RD需要跟着QA耗上一整天。因为没有靠谱的自动化，一个小的改动都会怕影响整个系统，影响所有搜索业务，所以需要人肉进行各环境的回归测试和发布，必须要一天。
RD们甚至选出了发布值日生，轮流和QA一起跟进发布。测试和发布的低效，导致QA没有时间进行技术上的提升，无论是测试理论提升，还是能提高效率的工具开发水平提升。
为了破解这个恶性循环，2013年搜索的RD Leader一方面带着整个团队进行新搜索平台系统开发，目标是业务解耦、模块解耦；一方面给QA培训开发知识，帮助QA提升代码水平。然后，RD&QA的Leader做出了一个大胆的决定：在新系统开发期间，QA放弃原先的项目测试，全部精力投入CI系统、新的自动化系统建设。除了新搜索平台系统这种绝对A类大项目，所有项目一律开发自测自己上线。
所以，本人就有幸经历了独立搭建搜索CI系统，和RD以及当时公司的敏捷教练一起规划并实现新自动化系统的整个过程。
自动化框架选型
这个新的自动化系统，必须要解决以下问题：
新增测试脚本低效的问题：为了满足快速的迭代要求，需求评审会结束，验证点一旦确定，就希望对应功能验证脚本快速开发完成。
无法迅速扩展到新业务搜索系统的问题：搜索部门的目标是承接公司无论大小，所有业务的搜索系统。在公司快速发展的过程中，业务搜索系统也会井喷式增长，因此对应的自动化测试脚本必须跟上业务发展速度。
对数据的依赖问题：以防别的团队QA改动DB数据，进而导致搜索的功能自动化不是因为真正的Bug失败。
对特定环境的依赖问题：搜索这种基础服务，Beta环境必须保持稳定，不能频繁部署未经验证的功能代码，故不能利用Beta环境进行自动化测试。
除了需要解决上述痛点，它还要支持灵活的Case管理，允许根据级别从Case里方便的选出一部分单独运行，要有详尽的报告方便快速定位问题。
最终，我们选择了Python + Shell + RobotFramework。Shell脚本完成从拉取代码到打包到启动服务的过程，Python用于开发底层Lib，RobotFramework用于管理Case和出具报告。
为什么这样的选型能满足团队要求？
因为RobotFramework是关键字驱动的框架，而且搜索服务架构稳定后，各业务搜索系统基本功能不会有太大变化，所以只要底层API封装好，横向从一个业务的搜索系统扩展到另外一个业务搜索系统相对快速，所有底层API和准备脚本都可以共用。
对于新入职的QA而言，Python比Java上手快得多，根据已有Case完成一个新的Case甚至两行代码就可以搞定。
为了不依赖特定环境的DB，RD在新的搜索平台里添加了对CSV这种数据源的支持；对各种配置尽量利用独立的文本文件，不依赖任何在线配置系统；为了方便快速定位问题，对于这种只需要RPC接口的系统，他们也提供了HTTP方式的访问方式。
所以，对我们的自动化而言，只要提前准备好CSV文件作为数据源，在服务启动之前利用Shell脚本改动配置文件为所需，启动服务后，校验大部分后端API的过程其实就是发送HTTP请求，校验Json格式的Response，完美解决数据和环境依赖问题。
用过RobotFramework的同学也应该清楚，它的Tag非常灵活，一个Case多个Tag可以并存，它的Html报告也十分详尽，所以之前提到的Case管理和报告问题也解决了。
对于搜索这种只依赖数据的底层服务，因为解决了对数据和环境的依赖，所以后来我们的自动化一旦失败，90%就是因为有Bug，只要维护及时甚至可以说100%就是有Bug，可信度极高。
CI系统
为什么要依赖CI？
试想，每个RD每天改动那么多代码，即便自动化全部搞定了，如果不在改动之后立即对整个系统进行集成校验，一旦出问题，谁的代码，哪一行代码导致的问题，RD们去定位必然也极其耗时耗力。而集成测试，能保证最新的代码只要自动化验证通过，系统就可以提供完整的主流程服务。
所以我们充分利用了CI这一点，有问题快速暴露、快速定位、快速解决。当然，这也需要每一位RD养成及时Commit，持续提交强可读性Comment的代码提交习惯。这也需要我们的自动化回归必须15分钟内运行完成，跟得上CI轮询代码仓库的节奏。曾经为了达到这个目的，我们把Sonar静态代码扫描独立成额外的Job，不让它拖累自动化回归Job。
2013年，由于搜索应用的特殊性（人家都是War包，容器使用Tomcat，搜索是Tar包，容器用Jetty），它无法接入运维为其他部门提供的发布系统（当时运维的发布平台也不完善），所以我把应用的打包部署也配成Job，让RD们可以自助进行任何环境的部署工作。
性能回归
对于搜索这种对稳定性和性能要求极高的应用，功能自动化最多可以暴露稳定性方面的问题，那么性能呢？如果只是每周或者定期做个性能体检，或者大促活动之前进行一次压测，等发现系统无法满足业务要求的时候，一切为时已晚。到时即便知道性能不达标，也不知道是这段时间哪些改动造成的。所以，我们让性能也能自动回归。
由于支持HTTP的调用方式，所以我们选择了Jmeter + Shell。Shell脚本的作用依旧在完成从代码拉取到服务启动的过程，Jmeter做压测，最后的报告和邮件报警使用的是公司测试工具组利用Python开发的一个专门针对.jtl文本的解析与邮件预警工具。
性能自动化回归最重要的点在于结合业务场景进行的压测场景细分，例如商户搜索，就分为根据关键词进行搜索、根据分类导航进行搜索、以用户经纬度为中心的附近搜索等等。场景规划好，jmx文件设置好，一切就都在掌控之中了。
最后我们还发现这个回归有个副产品：帮忙暴露多线程功能Bug。本人就曾经因为跟踪性能回归出现的一个诡异问题，最终和RD定位出一个隐藏很深的高P缺陷。
DIFF工具
大家可以想想每到XX系统重构的时候是不是都会超级抓狂？没有人力去梳理所有Case的时候，直接用大量真实用户请求DIFF新老系统，被我们认为是最高效最全面暴露问题的方式。
所以我们把它用在灰度发布，帮助把住倒数第二道关；我们把它用在大项目重构后的快速测试；我们把它用在排序算法的效果分析。
只要是API类、只读数据源、需要满足幂等特性的应用，我认为就可以考虑使用这种思路，后来承接前端业务后我们也把它用在Mobile API开发的自测和灰度把关上了。事实证明，效果杠杠滴，QA可以放心地不跟进Mobile API的任何项目，全年也没有任何P3以上线上Bug。
搜索移动端团队
UI自动化
谈到UI自动化，大家都会说维护成本太高啦，投入产出比太低啦等等。其实我也这么觉得，所以我们只做主流程UI自动化，也就是多个版本几乎万年不变的功能自动化。
由于搜索的前端业务流程相对简单，点评APP的搜索提示和搜索列表页面都是纯Native，所以我们才决定试试UI自动化回归。对于那些每个版本都会变得不成样子的页面，做UI自动化的动机、效果和投入产出比，我表示强烈怀疑。
搜索移动端团队的UI自动化在平时维护成本低，偶尔也能帮忙发现一些问题，所以效果还行，虽然不像后端的功能自动化收益那么高。
UI自动化选型
2015年时为了去了解一下当时火得不要不要的Appium，而且因为团队QA习惯用Python，所以最终选择了这样一个能支持Python，传说能一份代码适用多类终端的工具。它的社区Testerhome比较活跃，有问题容易找到解决方案，也是我们入坑原因之一。
用Python + Unitest + Appium还有一个最大的好处是Python脚本可以随时中断，写一句执行一句，调试相对容易。
数据上报功能自动化
提到打点测试这个东西，很多QA可能恨得牙痒痒，因为测它纯属体力劳动，枯燥无趣，就算出现Bug，也不影响用户体验，所以真想把它扔掉，扔给产品自己去验。
由于对搜索团队而言，打点非常重要，一个新的算法效果如何，全指望着打点数据报表指明方向，所以虽然起初我们是怀着极大的怨恨心理从产品同学那里把这部分工作接过来的，但是后来发现其实我们的业务场景，只要保证P1主流程的打点不出问题就OK了，边角的小问题不影响大局，而且把这部分工作自动化还变成了QA的KPI亮点工程。
经过几次打点问题的分析，发现问题基本出现在客户端RD改动业务逻辑，导致误伤打点逻辑，而非数据上报后续流程中。那么如果能截住APP在各种场景上报的数据，对它进行校验，就能暴露这部分问题。既然我们做了主流程的UI自动化，那么顺手就可以把这部分校验工作自动化。
所以我们寻求移动架构组帮助，请RD们在Debug版本里加入一个功能，让我们可以在Debug面板里设置上报数据接收的服务器，运行自动化时将其设置为本地启动的一个Server，截取所有上报数据并进行校验。这样一个开关也不会影响正式版本，避免插桩。
最终，这部分自动化脚本在半年内帮助发现过三个以上的P1级别打点缺陷。
如果你也处于这种高开发测试比的团队，怎么办
基本认知
质量是整个团队的事情
虽然QA的本职在帮助暴露缺陷，但需求是PM提的，代码是RD写的，QA不应该为质量负全责。包括面对当前的Bug情况，是否可以发布，本来也应该是整个团队一起拍板决定的（如果有正规的项目经理，那么更多时候是项目经理拍板），QA更多的作用在于呈现风险，为决策提供参考。
要相信RD同学保质保量的能力
既然我们的老板对一个团队在配备相对少的QA的情况下的质量依旧有信心，说明老板对招募的RD能力非常有信心，招募的必然都是精英，那么QA也应该要对RD同学有信心。而且，大家都知道缺陷暴露越早修复成本越小，评估风险后认为可以完全开发自测上线的，就全部放手让RD同学尽情发挥吧。少了和QA沟通Bug的成本，自己发现的问题自己修复起来肯定也是速度极快成本极小的，自己要负全责的时候必然也是兢兢业业打起十二分精神的。
有什么资源做什么事
大家在起步阶段的创业公司很少会看到QA，那么说明其实团队没有QA也玩得转，那么为什么老板还要招募QA? 难道招你来是为了帮RD做本来可以在没有QA的情况下自己做的事的吗？必然不是。因此我认为，在高开发测试比的团队，QA更多的职责在于辅助开发更好地自测，提供必需的测试工具、必要的测试培训、QA看问题发现问题的角度、更专业的测试而非检查。
你可以做什么
基于上述三大基本认知，我认为大家可以尝试做下面的事：
弄清楚，开发自己做不好自己的“检查”，为什么？
是因为缺乏发现问题的眼睛？那么可以尝试提供结对测试支持，提供自测Checklist、带领RD一步步学会换个角度看世界。
是因为不会做性能测试？那么提供压测工具、提供压测理论培训、提供压测咨询服务。
是因为只了解自己的一个小模块，怕改动以后对整个系统造成巨大影响？那么请RD自己弄好自己小模块的UT，QA和RD一起搭建、完善针对整个系统的IT，让他们提交代码后，能快速从自动化或者哪里得到自己会不会、会多大程度影响整个系统的反馈。
努力提升自己质量保障工作的能力
既然检查交给RD同学了，那么QA自己要具备去做质量保障领域其他事情比如测试的能力，并且让整个团队看到QA的价值，不然要QA何用？
所以，你可以去了解学习下专业的测试知识，例如《测试架构师修炼之道：从测试工程师到测试架构师》、探索性测试等等。
如果公司没有专门的SQA，可以去了解下如何利用流程，优化流程等等来达到质量保障的目的，然后在团队里实施起来。
还可以多参加些线上线下的沙龙（如果你看到本文了，说明你已经开始做这件事了，祝贺，请坚持），多和不同公司、不同行业的QA们交流，看看人家是怎么做的，有哪些可以用在自己团队，着手去尝试。
多和老板沟通、和RD Leader沟通，确保自己想做的事有人支持
本来这应该是最重要的，应该放在第一条，但是如果没有上面两条，可能一开始老板和RD Leader根本不相信你除了检查还能做别的事。所以，我最后说下最重要的这一点。
上文提到的我们做的所有事，都是基于一个前提条件：搜索RD们、运维们和我的上司们极大极大的支持。不然，CI弄得再好，自动化弄得再好，可能也就是KPI工程，起不到实际作用。在测试资源不足时，我们的RD甚至可以做到每个迭代，自己自测的东西做完后，自己去根据逻辑变动维护自动化脚本。我们的DIFF工具，是RD主力开发完成的，QA更多在根据专业眼光提工具优化需求。当然，我们RD的UT也是非常完备的，金字塔基非常牢固。
为什么RD愿意做这些事？我姑且以小人之心妄自揣测一下。因为质量是整个团队的责任这一价值观从上到下的统一；因为有Bug被精英RD们认为是非常羞耻的一件事，他们一直认为QA是来帮忙的，本来他们应该自己全部搞定这些事；因为一旦他们自己能搞定这些事了，项目上线效率提升非常大（毕竟质量达标才能上线），俗一点讲，每年多做点事，少一点线上缺陷，KPI也更好看等等等等。
后记
回过头看这4年，我觉得非常幸运，刚毕业就踏入这样一个三观正到不能再正的团队，一起完成了这么多有意义的事。有这样一群同事，我上辈子是修了多大的福。
在点评搜索团队时，曾经天真的认为所有团队RD都是这样，所有团队QA都可以仿照移植我们这一套。离开这个团队以后，才知道以前自己多么幸福，能完成这一套是汇聚了多少天时地利人和。
我亲历过这段历史，所以想为大家呈现这段历史，让一些刚步入社会就被996压得无力喘息的同学看到另外一种工作状态的可能性。以下借用《未来简史》中尤瓦尔·赫拉利的一段话，与大家共勉。
现在的状况既非自然而然，也不会永恒不变。过去曾经是另一个样子，只是有了一连串的偶然事件，才创造出现在这个不公平的世界。只要我们采取明智的行动，就能改变并创造出更好的世界。
最后，感谢我的Boss佰智，感谢RD Leader召刚、新利、玉璞、志田，感谢我那群可爱的搜索同事们。谨以此文，粗略地记录下搜索团队那些年的光辉岁月，向我们一起并肩作战的日子致敬！！！
彩蛋
重磅 Chat 分享：《如何在三年内快速成长为一名技术专家》
分享人：
方腾飞 并发编程网创始人，支付宝架构师
Chat简介：
工作前三年是职业生涯中成长最快的几年，在这段时间里你会充满激情，做事专注，也容易养成良好的习惯。
在我们公司有些同学在前三年中就快速成为某一个领域的技术专家，有些同学也可能止步不前。本场Chat和大家一起探讨下如何在三年内快速成长为一名技术专家。
学习方法：
掌握良好的学习心态 掌握系统化的学习方法
知识如何内化成能力
实战技巧：
你需要学会的编码习惯 如何在普通项目中提高自己的能力
在业务团队做
引用文字开发如何成长
想要免费参与本场 Chat ？很简单，公众号后台回复「技术专家」