GitChat · 测试 | 大众点评搜索测试全揭露：1:9 的测试开发比下 QA 如何前行

【不要错过文末活动】

背景介绍

本人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日常

• 搜索平台团队

• 搜索体验团队

  该团队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年本人转向移动端测试之前，这一整套已经完成并持续服务至今。当时我们的监控可视化系统其实就是树莓派的主机+两个显示器，可以给大家看一张监控显示屏的效果图：