一、背景与挑战

　　服务端质量保障是确保服务器端应用程序在开发、部署和运行过程中达到预期性能和可靠性的关键步骤。一个全面的服务端测试策略不仅能提高系统的稳定性和安全性，还能提升用户体验和满意度。

　　货拉拉服务端整体采用微服务架构，单点服务交互链路呈复杂的发散状：　　

　　面对如此复杂的系统架构，质量保障具有如下挑战：

　　支撑快速迭代: 业务保障结果需满足高效&高质量

　　高效：业务测试人员在固定时间范围内可支撑更多业务保障。

　　高质量：线上缺陷率逐步降低，最终实现万无一失。

　　高稳定：业务系统性能达标&健壮性高的能力

　　性能：服务端在不同工作负载下的表现满足预期。

　　健壮性：面对各种失败情况下，系统均可弹性应对，不会引发更严重的问题。

　　"0"资损：资金保障需确保系统定价链路准确与资金链路数据无损

　　定价：不同类型的订单估价满足业务预期。

　　资金数据：不同业务领域组合成的资金链路数据整体相符，无不一致和账不平的事情发生。

　　针对以上背景和挑战，我们需建设一套完善且高效的测试策略！

　　二、知己知彼-bug从哪里来？

　　让我们一起进入开发的视角，开发一个业务需求需要怎么编写代码，变动的代码可能会产生哪些bug呢？　　

　　三、逐一击破-测试策略

　　整体测试策略分5大类，层层包含且存在增量差异，最终环环相扣形成完整保障闭环。　　

　　1.代码分支测试

　　保障目标

　　项目任意阶段部署到测试/线上环境的服务代码均包含master分支代码。

　　master分支代码无论何时均和线上运行代码相同。

　　保障策略

　　制定代码分支管理规范，将规范落地为 【代码分支检测】 工具自动检查和接入服务部署与准入准出流水线管控，最终形成可持续且闭环的代码分支保障。

　　代码分支规范：　　

　　代码分支管控：　　

　　2.变更测试

　　保障目标

　　确保每个服务端功能按照预期工作。

　　保障策略

　　整体分3块，分别是功能测试、资损测试和稳定性测试。

　　2.1 功能测试

　　集成&接口测试主要由测试人员根据变更业务内容&代码diff进行测试分析设计用例&保障，其中代码diff可结合 [精准测试] 工具辅助测试分析；单元测试《单元测试在货拉拉的落地与实践》主要由开发人员根据类、函数或模块变化进行测试分析设计用例&保障。

　　单元测试：检查单一功能是否正确。

　　集成测试：评估多个功能联动是否正常。

　　接口测试：验证服务端提供的API接口是否符合预期，包括请求参数、返回结果、错误处理等。此处会结合测试工具 [数据工厂] 和 [MOCK] 协助测试 。

　　2.2 资损测试

　　定价链路：采用流量回放《货拉拉流量回放体系搭建与应用》工具录制线上定价流量，在代码/配置变更之后实时回放/历史录制回放（灰度环境操作），通过分析回放出的结果差异得出代码/配置变更是否符合业务预期，不仅可协助测试发现遗漏的问题，还可以协助产品/业务预设出此次变更之后用户司机的价格变化，避免舆情发生的可能。

　　资金数据：采用 [数据核对] 工具，各领域服务端测试人员在此工具上配置好各类数据模型关系（例如：db与db，db与es，db与接口等），最终形成全链路数据模型关系网。工具动态监测到binlog变动之后，基于前置输入的数据驱动关系模型进行核对，实时拦截数据不一致与账不平的问题发生。

　　2.3 稳定性测试

　　性能：使用Jmeter工具进行压力和负载测试，确保系统在高负载、高并发等复杂环境下能够稳定运行。货拉拉正在逐步扩大自动化压测《全链路压测自动化的探索与实践》的实践，使用全新效能方式，将会极大降低性能测试时长&人工误判情况发生。

　　健壮性：使用故障演练《故障演练体系建设》工具，模拟生产环境中接口、服务和中间件等维度异常时，系统能够迅速恢复并继续提供服务。常见需确保健壮性的场景有：

　　网络通信异常处理：

　　连接中断：服务端需要能够处理客户端突然断开连接的情况，确保不会因此导致资源泄露或系统崩溃。

　　超时处理：对于长时间无响应或超时的请求，服务端应有相应的超时处理机制，避免资源被长时间占用。

　　数据包损坏：在网络传输过程中，数据包可能会损坏。服务端应具备验证数据包完整性的能力，并在发现损坏时能够采取适当的恢复措施。

　　数据一致性与完整性：

　　事务处理：对于需要保持数据一致性的操作，服务端应支持事务处理机制，确保在异常情况下能够回滚到操作前的状态。

　　数据校验：对输入数据进行严格的校验，确保数据的合法性和准确性，避免因为非法数据导致系统异常或数据损坏。

　　系统稳定性与容错性：

　　异常处理：服务端应具备完善的异常处理机制，能够捕获并处理各种运行时异常，避免因为未处理的异常导致系统崩溃。

　　冗余部署：通过冗余部署来提高系统的容错性和可用性。例如，使用多台服务器进行负载均衡和故障转移。

　　资源监控与告警：对系统资源进行实时监控，并在资源使用异常或达到阈值时发出告警，以便及时采取措施进行处理。

　　服务降级与限流：

　　服务降级：在系统资源紧张或出现故障时，通过降低非核心服务的优先级来保障核心服务的正常运行。

　　限流：对访问流量进行限制，避免因为突发流量导致系统过载或崩溃。

　　依赖管理：

　　第三方服务依赖：对于依赖的第三方服务，服务端应具备监控和异常处理的能力，以应对第三方服务不可用或异常的情况。

　　依赖版本管理：合理管理依赖的版本，避免因依赖版本冲突导致的问题。

　　3.回归测试

　　保障目标

　　避免增量代码变动影响到自身服务领域或其他服务领域的线上逻辑。

　　保障策略

　　整体分2块，分别是进行单服务回归的回放测试和全链路回归的端到端测试。

　　3.1 回放测试

　　在项目详细测试阶段开启流量回放全量录制并结合 【代码覆盖率】 工具提取出有效流量样本实时沉淀至用例集，在项目回归测试阶段直接对变更的单服务进行回归保障。　　

　　3.2 端到端（E2E）测试

　　模拟真实用户的操作流程，通过向直接和客户端交互的服务发起请求，经过网络传输，到达服务端，再到服务端处理完请求后返回结果，判断结果是否正确。这种测试方式涵盖了整个服务端系统的工作流程，确保服务端系统在实际使用环境中能够正常工作。它如果配合流量回放一起使用，一个保链路，一个保单服务节点，就可实现在降低人力成本情况下有效替换掉老式的接口自动化保障。　　

　　测试方法采用testng测试框架进行自动化方式保障，场景case根据业务功能模块分类建设，其中P0级别业务功能模块可用于线上/线下确保环境可用的定时巡检使用，其他功能模块场景case可通过机器人快速唤醒执行，不仅可应用到项目冒烟与回归测试阶段使用，还可以用于线上回归验证和快速应急使用。

　　4.灰度测试

　　保障目标

　　避免发生以下2种情况

　　新业务能力上线之后由于用户反馈不佳下线，不仅投入的资源都浪费了，还在系统留下了大量的垃圾代码。

　　变更代码之后，影响了线上已经在run的业务逻辑，全量用户受到影响，引发故障。

　　保障策略

　　灰度测试，也被称为灰度发布或灰度部署，是在某项产品或应用正式发布前，选择特定人群（用户或服务器集群）试用，并逐步扩大其试用范围，以便及时发现和纠正其中可能存在的问题。货拉拉具备多版本灰度环境 【小货拉拉】 ，可以通过城市、用户司机人群和app版本号等策略进行灰度，最终实现"尽快试错，聚焦有用功能 ” 、“小步快跑，风险尽在掌握”的目标。　　

　　5.监测与报警

　　保障目标

　　及时发现并处理故障：通过持续的监测，能够迅速发现服务端运行中出现的异常或故障，如接口处理错误、服务宕机等，从而及时采取修复措施，确保服务的持续稳定运行。

　　预防潜在风险：通过监测数据的分析，可以预测潜在的风险点，如资源使用瓶颈、性能下降趋势等，提前进行优化和调整，避免服务中断或性能下降。

　　保障策略

　　在货拉拉除了CI团队提供给业务的monitor监测与报警能力，测试团队也建设了 【日志哨兵】 工具，实时监测业务代码异常，并将代码异常结合经验库决策判断，最终且实现精准与实时的问题触达。　　

　　四、成果与收益

　　从第三章阐述的5类测试策略在货拉拉的具体落地可以看出，除了业务变更部分需要人参与的比较多，其他基本都处于工具化的状态。这不仅让货拉拉服务端质量保障具备了将测试从保姆模式转成教练模式的条件，还为质量&效率带来了提升。

　　千行代码缺陷率降低40%

　　研发可利用测试的效能建设深入参与到质量保障任务中，主要有单测、代码分支检测、日志哨兵等赋能，让研发可自我闭环问题，降低缺陷数。

　　测试质量提升至<=1%

　　线上缺陷数/(线上缺陷数+线下缺陷数），其中分母不包含研发自闭环保障阶段发现的问题。

　　测试人效提升30%

　　测试人效提升主要来源于研发可自闭环需求变多、人工测试保障面变少和工具辅助测试提效，这让测试人员在固定时间范围内可支撑更多业务保障。不同业务线会存在一些差异，中台服务领域因每次变动和线上业务逻辑差异较小提升会比较明显。

　　下面的饼图为货拉拉货运在2024年02～07月（H1）期间服务端缺陷暴露渠道占比：

　　人工测试暴露问题仍然是主力，其次是日志哨兵>代码分支检测>E2E>流量回放>数据核对>小货拉拉；

　　在效能拦截的问题中，其中46%问题拦截在需求提测前，30%问题拦截在详细测试阶段，24%问题拦截在回归&灰度测试阶段，整体呈递减趋势；

　　效能协助研发自闭环问题占比效能拦截全量问题的60%，日志哨兵>代码检测>流量回放。　　

　　五、未来规划与思考

　　1.未来规划

　　1.1 有明确测试方法部分继续使用工具和流水线去替代人工测试

　　eg：此文第三章提到的代码分支测试部分

　　1.2 工具无法替代部分结合AI给予推荐和决策建议

　　eg：智能问题定位，智能用例推荐等方向

　　2.思考：

　　测试会被替代么？

　　作者认为不会被替代。不同时代随着新的技术和业务模式的出现，对测试是持续需要的，但是会带来新的挑战和需求，需要测试人员不断提升自己的技能和知识，以适应行业的变化和发展。其次我认为测试的核心竞争力是测试方法，代码/AI等相关技能都需要有方法论为支架才能发挥出效果，期望大家在丰富新知识的同时，不要忘记持续丰富自我的测试方法论模型。　　

　　感谢大家阅读至此，期望此文能给你带来启发和思考，由于篇幅有限，文章中提到的已在货拉拉应用的相关效能工具（中括号加粗部分）有些未能展开介绍，后续会持续分篇章分享，请大家敬请期待！