本文来自作者： 梦婷 在 GitChat上高质量分享，「 阅读原文 」看看大家与作者交流了哪些问题

1. 背景介绍

本人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点也是常有的事。这样的节奏与工作状态，也导致没有时间进行测试理论或者技术方面的提升，包括性能测试、安全测试等方面的深入，总之就是苦日子看不到头，而且没有成长的盼头。

2. 团队现状

在我2016年离开搜索部门之前，负责搜索平台团队质量保障工作的QA 2人（兼有整个团队测试工具开发、持续集成系统维护、搜索测试环境维护职责），搜索体验团队 QA 1人，搜索前端团队 QA 2人。

2.1 各团队QA日常

• 搜索平台团队

  该团队2个 QA 主要负责跟进A级别（可简单理解为>20人天开发量）项目测试，维护 CI 系统，维护搜索所有后端业务测试环境，定位功能自动化回归失败原因并解决，分析性能回归失败原因并与开发共同定位性能问题，为开发提供其他必要测试支持（例如项目风险分析、开发自测侧重点分析、对开发进行性能测试培训、结对测试辅助新入职开发提高代码质量），开发测试效率提升工具，定期和RD进行线上缺陷和流程Review，以质量提升为目的进行流程优化，推动开发定期进行降级演练等。

• 搜索体验团队

  该团队1个 QA 主要负责搜索体验团队重点关注的商户、团购搜索和推荐效果，维护由于算法改动造成的对应业务自动化失败，根据业务发展进行性能回归场景变动，分析性能回归失败原因并与开发共同定位性能问题，根据各开发代码质量做出不同级别项目的测试支持，严控发布质量。

• 搜索移动端团队

  该团队2个 QA 主要负责点评 APP Android 和 iOS 客户端每个版本的搜索相关需求功能测试、兼容测试、基于场景的专项测试、用户体验测试，维护 Mobile API 功能自动化、UI 功能自动化、打点数据上报功能自动化脚本，并根据每个版本测试情况提供测试报告和各开发代码质量优化侧重点报告，定期Review推动开发代码质量提高。

2.2 自动化情况

搜索平台和体验团队，所有重要业务的搜索后端系统，均有用例覆盖率80%以上的API功能自动化（P1/P2用例覆盖率100%）和常用场景的性能自动化；搜索移动端团队，Mobile API P1/P2功能自动化用例覆盖率 100%，UI P1/P2功能自动化用例覆盖率 100%，打点上报P1功能自动化用例覆盖率 100%。以上所有自动化日常通过率100%，一旦出现Fail，QA第一时间定位原因提交Bug或者修复。

2.3 持续集成系统情况

搜索平台和体验团队

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功能自动化脚本维护与回归，并在回归测试阶段进行打点数据上报功能自动化回归及脚本维护。

2.4 各团队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. 3年里我们到底做了些什么

3.1 搜索平台和体验团队

自动化困境与破局

本文第一部分描述了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，可信度极高。

3.2 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。

3.3 搜索移动端团队

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级别打点缺陷。

4. 如果你也处于这种高开发测试比的团队，怎么办？

4.1 基本认知