质量保障之路：达达测试团队成长记

一 基本概况
达达-京东到家是中国领先的同城速递信息服务平台和无界零售即时消费平台。达达目前已覆盖全国 400 多个主要城市，服务超过 120 万商家用户和超 5000 万个人用户，日单量峰值达到千万级；京东到家已覆盖北京、上海、广州等近 40 个主要城市，注册用户 5000 多万，月活跃用户超 2000 万，日单量峰值突破 100 万单。依托达达的高效配送和大量优秀零售合作伙伴，京东到家为消费者提供生鲜蔬果、日用百货、医药健康、鲜花蛋糕、个护美妆等海量商品1小时配送到家的极致服务体验。
达达-京东到家目前有上海，北京，成都3个研发中心，负责同城速递信息服务平台“达达”的研发主要在上海研发中心，本文主要介绍上海研发中心测试团队（下文简称上海测试团队）的日常工作内容。

二 我们的日常工作
上海测试团队围绕保障项目快速上线并稳定运行这一核心目标来组建，主要的工作内容除了业务和技术项目的质量保障，还包括各类流程规范的制定及优化，自动化建设，持续集成，性能测试，开发提升研发中心效能和质量的平台等。

上海测试团队目前约30人，分为业务测试组，测试开发组，质量管理组三大块。业务测试组的工作职责是保障业务和技术项目的质量，对应业务的自动化建设，因此需要具备需求分析能力，方案及用例设计能力，白盒测试能力，CodeReview能力，编程能力，从而实现核心系统的测试和可持续性自动化，保障系统在频繁发布的情况下依然稳定运行。测试开发组的工作职责包含开发各类自动化框架，性能测试，开发提升效率的工具和平台，研究业界主流测试工具及技术，并在团队内实践推广，需要有前后端编程经验，熟悉主流的开发框架和自动化框架，熟悉主流的压测工具。质量管理组的工作职责主要是分析各类质量数据并提供优化改进方案，制定各类流程规范并推动落地，在研发中心层面推行质量文化。

2.1 项目质量保证
上海测试团队不仅是对产品功能负责，而是对整个项目的质量负责。从产品需求分析，开发设计评审，测试方案设计，功能测试，性能测试，回归测试，线上验证，项目流程跟进等多方面确保线上系统稳定性。

2.1.1 产品需求分析
项目流程中，问题越早被发现，解决的成本越低。尽早发现产品需求的问题，对提升整个项目质量，提高过程效率，都有极大的帮助。

产品需求移交之前，产品经理会输出Prd文档，测试人员需要提前阅读需求文档，了解需求背景，功能详情，并结合现有业务，用户体验，被测系统架构，实现成本等因素，对产品需求进行分析。分析过程中需要记录文档中不明确或有疑问的部分，在需求移交会议中，主动提出疑问，完善需求细节和需求不明确的地方，提升项目团队对需求的一致认知。会后主动跟进会议纪要中待确认的部分，验收修正后的需求文档，然后开始编写功能用例。

2.1.2 开发设计评审
清晰合理的开发设计可以避免很多“坑”，既有利于后续业务扩展，代码重构，又可以有效提升系统稳定性。

开发设计阶段，测试人员需要结合产品原始需求，现有业务，现有系统架构等对开发设计进行分析，评估包括数据库设计，缓存，代码配置，接口设计，代码逻辑，业务日志等各方面的合理性。评估可能影响到的业务，是否存在新老版本兼容问题，潜在的性能风险，遗漏的修改点等内容。评审通过后，依赖开发设计，完善用例设计，进一步明确测试范围和测试粒度。

2.1.3 测试方案&用例设计
测试方案和用例设计是测试的核心。执行测试用例之前，测试人员需要明确被测对象，测试范围，测试方法，测试计划，测试用例等内容，这些内容都需要在方案和用例中体现。不经过分析，思考和计划就开始执行测试的行为存在极大的漏测风险。目前，上海测试团队用思维导图进行方案和用例的设计及管理。

完善的测试方案需要包含以下内容：测试需求，被测对象，测试范围，测试环境，测试方法，必要的时候还需要增加上线步骤，上线验证计划，涉及跨团队项目需要加上联调计划等内容。

覆盖度全面，可读性好的测试用例可以最大程度的验证产品功能，同时保证其他业务的可用性。测试人员需要对需求和开发设计进行分析，拆解功能，区分前后端，运用常规的用例设计方法，尽可能用最少的用例覆盖最多的逻辑和用户场景，提升测试效率。用例设计评审通过后，可以开始执行测试，测试过程中若发现有遗漏或错误，需要及时维护更新，方便日后查阅。

2.1.4 线上功能验证
产品功能发布后的验证是项目流程中非常重要的环节。功能发布后如果不第一时间做验证，将验证交给用户，是非常危险的举动。

需求评审或开发设计阶段，测试人员需要评估上线内容在生产环境验证的可行性，若无法验证，应及时提出需求，可通过添加白名单配置，提供内部接口等方式，方便测试人员进行线上验证。

功能上线后，应第一时间告知测试人员，由测试人员进行新增功能的线上验证和主要功能回归，验证通过后，上线才算完成。若验证不通过，应及时反馈给开发和产品，做好信息同步，然后一起评估是采用Hotfix，延期修复还是代码回滚等方案。

2.1.5 项目流程跟进&总结
测试人员除了项目测试以外，还承担着项目流程管理的工作。目前项目迭代我们采用敏捷开发方式，项目过程中人人都可以是项目经理。

很多项目中，测试人员会担任项目Owner，组织晨会，跟进进度，确保项目进程中各个关键节点按计划完成。项目上线后组织复盘总结，梳理和优化各类流程，落地质量文化，提升全民质量意识。

目前，上海测试团队已经总结输出包括常规项目流程，跨团队项目流程，App发布流程，事故处理流程等稳定性规范，并已经将这些规范落地到日常项目实践中。同时团队内部已经整理出了缺陷提交模板，线上问题回溯模板，线上问题跟进流程等规范。

2.2 自动化
自动化测试常见的实现方式，从上至下有：UI自动化、接口自动化、单元测试这几大类。
达达-京东到家的业务发展迅猛，更新十分频繁，所以高投入价值有限的UI自动化暂不适用。
接口自动化在所有的自动化测试中是投入产出比最低的一种，能极大节约回归测试的时间，也是我们后端项目上线的必要条件（目前，全量接口自动化回归测试百分百通过作为上线标准）。接口自动化在上海测试团队从一开始的Jmeter简单实现主流程接口的自动化，到现在使用Python+Unittest实现了区分接口全量用例、冒烟用例，已经有2年。
所有接口自动化用例均由业务测试同学自己编写，在梳理个人业务线接口的同时，也能更好地提升代码的能力，最终具备代码走查能力。

图：接口冒烟自动化用例执行结果

单元测试能将问题尽早暴露出来，覆盖越完全的单元测试越能发挥出其巨大价值。在2017年，我们开始着力推动开发工程师实现单元测试，目前已覆盖了大部分团队的项目，配送端二级项目严格执行着：每次代码提交时都会自动触发单元测试，并根据单元测试结果判断是否能够进入CodeReview环节。

图：单元测试构建成功后自动提交CodeReview

2.3 工具建设
2.3.1 One平台
在原来的项目流程中，从需求建立、研发、测试、上线等过程，需要经历多个平台，这样是非常低效且易出错的，任何一个环节遗漏或操作失误都可能演变成线上事故。One平台就是在这样一个背景下诞生的，抱着集成多平台，实现「All in One」–由繁化简的目的，实现了三大功能：

Devops实践-提升效率利器
实现One平台与持续集成相结合，高效部署测试环境，集成Docker与K8s后，解决了原测试环境一次只能供一个测试进行测试工作的瓶颈，使项目流程更通畅便捷，极大提高了效率。

项目流程-保障稳定性的手段
互联网时代下的轻量敏捷，小步快跑也要保障质量。在整合多平台的过程中，我们重新梳理并定义了通用项目流程，所有的项目都必须严格按照项目流程执行，使平台成为把控流程的工具的同时，收集了项目流程中的各项数据，作为分析提高效率、保障稳定性的依据。

工作台-研发日常小助手
研发小伙伴们每日登录One平台后，只需打开工作台，便可以看到各个状态下的需求小卡片，以及待处理的各类缺陷，每日工作任务一目了然。

图：One平台工作台待办缺陷

2.3.2 mock服务
Mock服务有在我们公司有三种应用场景，分别是：压测Mock服务，对接平台Mock服务，RAP Mock服务

压测Mock服务：
应用于常态化压测，将被测服务的Rpc调用都做了Mock处理，具体实现上，服务本身是一个Mock内核，需要Mock的接口及返回值等内容都从Config中心读取。在发现服务上使用Consul，可以自动识别不同的压测环境，拉取Mock服务及被测服务链路，以便在不同的环境实现压测任务。

对接平台Mock服务：
应用于在APP回归时，模拟生成7Fresh的订单数据，是一个简单的Flask请求，在对接第三方平台测试中发挥了巨大作用。此外，因为对接平台的 Qa 环境是提供外部对接商户联调使用的，但是我们的Qa 环境有时会出现不太稳定的现象，导致很多对接商户的联调受阻。对接平台在测试环境通过开关，控制测试环境mock化，提升了外部对接商户的联调稳定性。

RAP Mock服务：
RAP是可视化接口管理工具，具体的功能这里不展开说明。后端开发可以在这里维护接口文档，前端开发即可调用rap服务拿到对应的Mock数据，对于日常的前端开发工作来说十分方便。除此之外，在测试接口时，测试也可以在这里直接拿接口信息贴到Postman里使用。

2.3.3 性能测试平台
随着达达-京东到家的业务体量逐渐变大，系统稳定性成为一个需要重点关注的问题。我们有三种不同的性能测试模式：核心接口的常态化压测、日常迭代过程中的接口压测、大促期间的全链路压测。
常态化压测以mock服务为基础，当核心接口涉及改动时，对各个被压测接口每次进行压测后的结果与基线数据做对比，当指标在基线上下一定范围内浮动时，即判断为压测通过，本次改动可上线；日常开发迭代中，建立起了一套性能测试准入准出的标准规范，在项目的各个阶段，一旦发现有性能风险时，即可按性能测试流程规范展开压测工作，评估风险后进行调优或上线；在2018年618期间，得益于Consul带来的链路保证，我们首次尝试了全链路压测，并且平稳地度过了618。
性能测试需求时时刻刻都在发生，为了能更好地展开压测工作，在下半年我们计划搭建性能测试平台，让性能测试变得更规范也更简单高效。

2.3.4 JustRun
JustRun起源于2017年的Hackthon，在这次技术盛会上测试团队首次提出「数据工厂」概念，针对测试同学复杂场景、开发人员自测困难的痛点，解决测试过程中造数据难的问题。
JustRun的命名吻合了其干练、简明的气质，生成测试账号、测试订单、模拟经典场景等所有操作均一键完成，不但减轻了测试人员日常被其他小伙伴们打断工作、咨询测试数据的负担，也为其他小伙伴的工作提供了更便捷的操作，极大提高了整个上海研发中心的工作效率。

图-JustRun生成订单

2.3.5 持续集成
我们的持续集成基于Jenkins实现，随着项目增多，需要适配不同的测试环境，到发展中期还实现了一次业务代码的重构，当打包方式发生变更时，需要一个一个修改配置，效率低下且容易遗漏，原来使用自有风格部署的模式就渐渐跟不上需求，于是引入了Pipeline资源库，方便管理Jenkins部署源码，每次变更只需要修改通用的Groovy源码即可。
在Devops大热的这两年，我们也紧跟潮流，实现了Jenkins和测试环境服务的全量容器化部署，Jenkins支持动态扩充节点进行打包部署，当有打包需求时，自动生成一个新的节点执行任务，执行完成后自动销毁，减少了因为对Jenkins节点服务器的使用依赖，节省了服务器资源。
在与K8s打通过后，实现测试环境服务的多套环境并行，在与One平台打通后，解决了原测试环境一次只能供一个测试进行测试工作的瓶颈。

2.4 质量文化建设
互联网公司项目迭代很快，一个项目从开发到上线往往只有3至4天；需求不详细，需求变更多，合作开发质量意识不强都会导致测试时间被压缩，使得项目质量无法得到保障；在这种情况下，仅仅靠测试工程师来保证质量是不够的。产品经理，运营，开发，测试，运维作为项目的参与者，对项目的最终质量及线上稳定有直接影响，让大家都建立质量意识，成为项目过程中保障质量的一分子，是很重要的事情。

2.4.1 规范化
没有规矩，不成方圆。规范是质量，效率和稳定性的基石，上海研发团队内主要有两大类规范，一类是流程规范，主要强调需求移交后一直到上线过程中，哪些事情能做，按照什么样的标准做，哪些事情不能做；另一类是开发规范，主要是为了降低后期的维护成本，提高可读性提升团队开发合作效率。
稳定性相关的流程规范包含以下内容：

常规项目流程

代码变更规范

配置变更规范

Dbrt变更规范

Dba操作规范

运维操作规范

开发规范包含以下内容:

Java代码规范

Python代码规范

Job开发规范

Kafka使用规范

Git流程规范

2.4.2 常态化
有了规范只是个开始，保证规范能够落地，让每个人都清楚明白并严格执行，过程中需要做很多事。对于质量意识常态化，我们主要围绕经验传递和培训两个维度来做。
经验传递相关主要做了三件事，一是重大项目的总结，目的是复盘项目过程中各个阶段的问题，优化改进流程使得后续的重大项目能够更加顺利。二是经典Bug，测试团队内部每季度都会评选经典Bug，通过这个活动方便大家分享测试思维和测试方法，拓宽视野，丰富思维，增进沟通，同时也输出测试策略和测试方法的经验总结，帮助开发提升自测质量。三是故障Review，质量管理组每周一会组织各个故障相关技术团队的Leader和组员一起Review故障，分析原因并总结出通用的避免措施。以上的相关内容都会形成文档化的记录，放在Confluence上供大家查阅。
整个培训体系分成两方面，一方面是新人入职培训，目标是为了方便大家更快、更全面的了解大研发的各部门、工作规范和工具而安排的专项培训。培训的内容包含

公司发展史及企业文化

新达达产品介绍

IT规范和信息安全

稳定性相关流程规范

技术架构

数据库开发设计规范

另一方面是研发培训，主要培训研发项目流程，开发规范，稳定性相关规范（主要是2.4.1规范化里提到的相关内容），目的是为了保障日常的研发效率和质量。上海研发中心内部会为每个新入职的同学在团队内部挑选一个导师，导师会负责新同学的落地融入，以及这些规范的学习。

2.4.3 可视化
一个项目通常需要产品经理、设计师、开发工程师、测试工程师多方参与，共同协作，项目的质量也是靠大家共同保证的，对于各个职位输出物的质量需要被量化和自动化收集。需求阶段，产品经理的输出物主要是需求文档，我们会从需求变更次数，临时需求数，伪需求次数这三个维度来衡量质量。开发阶段，开发工程师的输出物主要是代码，我们会从打回需求数、自测通过率率、Bug数、线上Bug数、故障数来衡量。测试和发布阶段，测试工程师的输出物主要是缺陷和测试报告，我们主要考察打回需求次数，项目打回数，有效Bug数，和生产环境Bug漏测数。目前上海研发团队主要采用自研的研发效能平台来管理项目，以上数据都会通过该平台采集展现。

原文链接

https://mp.weixin.qq.com/s?__biz=MzAwMzg1ODMwNw%3D%3D&mid=2653791900&idx=1&sn=1fdbb69b46c682e0e61240f2fadc73cf&chksm=80edcc70b79a4566eaa485007a6723d9d98f9301e8410c4dff31050b5d11ac01a772ddd41efb&mpshare=1&scene=23&srcid=0919uQa2HSnt8aFyAazuzX6P%23rd

服务推荐

• 蜻蜓代理
• 蜻蜓ip代理
• 代理ip网
• 代理ip
• 微信域名拦截检测
• 微信域名检测api