测试左移和测试右移，我们为何要“上下求索”？ - 测试蔡坨坨

转载请注明出处❤️

作者：测试蔡坨坨

原文链接：caituotuo.top/7b9ad46d.html

你好，我是测试蔡坨坨。

今天，我们来聊一聊测试左移和测试右移。

传统测试流程与敏捷测试

在探讨测试左移和测试右移之前，我们先来聊一下传统的软件测试流程（瀑布模型）和目前很多公司在用的测试流程（敏捷模型）的区别。

软件测试作为软件研发的一部分，有什么样的开发模式，就有与之对应测试模式。因此就有了适合传统瀑布开发模式的传统测试和适合敏捷开发模式的敏捷测试。

• 传统测试是在程序开发完成之后，更强调测试的独立性，将开发和测试两个角色分的比较清楚，而敏捷测试更强调整个团队对测试负责。
• 传统测试具有明显的阶段性，而敏捷测试更强调持续测试和持续质量反馈。
• 传统测试强调测试的计划性，而敏捷测试强调测试的速度和适应性，需要不断调整测试计划以适应需求的变更。
• 传统测试更关注测试文档，如测试计划、测试用例、测试缺陷和测试报告等，而敏捷测试更关注产品本身以及交付的客户价值，强调面对面的沟通协作，持续质量反馈和缺陷预防。
• 传统测试鼓励自动化，但成功与否没有致命的影响，而敏捷测试需要由良好的自动化测试框架支撑，因为在敏捷模式下，产品迭代速度快，市场不断调整，客户需求不断变化，单纯的手工测试越来越无法适应整个变化过程，测试人员如何快速响应并保证产品在上线后的质量能够满足客户要求，如何保证在上线一个新功能的同时快速对旧功能进行回归，保证旧功能不被新功能影响而出现严重的Bug，自动化测试无疑是一个不错的选择。

从两者的区别，我们可以看出传统测试最明显的弊端就是介入晚以及没有持续测试。

所以，为了从根本上解决这类问题，于是开始推广并实践测试左移和测试右移。

测试左移，顾名思义就是测试要在提测之前介入软件研发流程，及时发现错误，避免将许多本可以规避的问题带到测试阶段才发现，导致修复成本过高，甚至导致项目延期无法按时交付。提倡预防缺陷胜于发现缺陷，需要把质量构建推向源头，也就是产品需求，因为最严重的错误不外乎是系统不能满足用户需求。

测试左移通过持续对产品需求和设计进行评审，在需求评审时不只是简单了解需求，而是要去评估需求的质量，分析需求的完整性以及合理性，及时发现需求和设计中的问题，从而可以更好地避免由于产品文档不完善导致需求不明确的问题。

测试左移还包括代码评审，以及让开发做更多的测试，加强单元测试，开发自测，持续集成等。在开发阶段参与设计方案的设计，了解开发的实现方式和代码框架，从而可以更好地评估改动范围、需要回归的内容以及是否有遗漏的模块和系统。测试还可以通过提供测试用例或自动化测试脚本的方式给开发，让开发在设计时考虑更全面，同时方便开发自测，有助于提高产品质量，避免在收到提测包时冒烟测试主流程都没通过，导致测试效率低下。

测试还需要不断培养产品、开发同学的质量意识，提倡团队对质量负责，同时提供必要的技术支持，协助产品、开发更好地进行测试，比如：公共测试用例、测试工具、测试脚本等。

这样一来，你会发现提测的质量会大大提高，原本要花一天时间冒烟的功能很快就能通过。

测试右移指的是在软件发布之后关注线上环境，持续监控软件的线上质量，以验证产品在用户的实际环境、数据、场景下，功能和性能是否符合用户预期，而不是项目发布完成就万事大吉了。

比如以下测试右移的活动：

• 通过监控预警系统，及时发现问题并跟进解决，将影响范围降到最小。监控预警系统对IT基础设施，以及业务系统中的大量数据进行采集处理，监测系统运行状况，通过可视化看板展示系统及服务的运行状态、资源使用情况，当发生异常时，能及时告警，并帮助运维人员快速定位问题。

  • 对各种IT系统设施进行监控，比如：操作系统、服务器、虚拟机、容器和网络通信信息，CPU、内存、磁盘等资源的使用情况；对中间件监控，比如：数据库中间件、MQ消息队列、Web服务器等系统，监控一段时间的请求量、响应时间以及访问日志信息；对应用监控，比如：服务依赖关系和接口性能监控；对业务监控，例如：关注线上业务及用户使用情况，使用场景，多关注用户价值高、使用率高的功能，在用例中补充遗漏的场景，尽量多地进行覆盖；对用户体验监控，比如：加载时长、卡顿率等。
  • 数据采集处理包括数据收集、数据处理、数据应用，处理后的数据可以在监控面板上以曲线图、饼状图和仪表盘等直观的方式展示，同时根据设定的阈值和告警规则监控各项指标和数据状态，当符合告警规则时，系统通过邮件、短信等方式通知相关人员，以达到及时响应的效果。

• 在线性能测试

  • 全链路压测
  • 在线性能监控
  • 流量回放技术

• 安全性监控

  在研发阶段进行代码的静态分析、安全性功能验证和渗透测试等，以发现代码和系统级别的安全漏洞。在产品上线后，通过监控和检查，发现系统的安全漏洞并及时修正。比如：身份认证、授权、访问控制和不可抵赖等是否已经整合到系统内；对用户名、访问时间、操作和资源地址进行审计，判断是否符合规范和要求；入侵检测，检测一些用户是否越过访问控制机制进入系统内部，对访问频率过高的情况进行警报并暂时冻结等。

• A/B测试

  把新旧两个版本同时推送给不同的客户，通过对比实验进行科学验证，从而判断这些变化是否产生了更积极并符合预期的影响力，为下一步的决策或改进提供依据。

• 对于大规模、高复杂的服务系统来说，仅在测试环境进行测试已经无法满足质量需求，在生产环境下进行测试必将会在现在及未来云时代中占据重要地位，而混沌工程及其基于故障注入的测试提供了在生产环境中进行科学实验的方法和技术。

不得不承认测试左移和测试右移的提出，对于测试角色来说，无疑是一个很大的进步。

但是，这也反映出了一些问题。测试左移在一定程度上代表着测试人员对即将拿到一个什么样的半成品充满了担忧，所以我们迫不及待想做些什么，于是我们拼命地往左边挤，力求尽快发现一些错误，将这些问题扼杀在摇篮里，避免自己接到一手烂摊子而焦头烂额。测试右移在一定程度上是测试人员对自己测试的不自信，因为有时候我们绞尽脑汁设计测试用例，通过多轮反复验证，满怀期待的上线，但是用户总会以某个不可思议的角度狠狠地敲你一棒子，于是我们通过测试右移，持续测试，关注线上环境，赶在客户发飙之前悄悄地把缺陷解决。

同时也反映了测试人员对质量的影响是很小的，单纯在测试阶段执行测试是不够的，所以我们不得不“上下求索”，以求一份安心，不应该把提测认为测试活动的开始，把上线认为是测试活动的结束，更不要认为质量只是测试人员需要关注的，因为质量不是被测试出来的而是被设计出来的，应该伴随整个软件的生命周期。