测试知识——测试左移与测试右移的理解与实践 - 青城杂文录 - 博客园
一，什么是测试左移和测试右移
1、什么是测试左移？
测试左移的思想本质是越早的发现不合理的地方，出问题的几率就越低。
测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作，因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的bug。
参与和理解会使测试人员获取产品完整的知识，彻底想清楚各种场景，根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前识别出一些缺陷。
2、什么是测试右移？
测试右移是产品上线了之后也可以进行一些测试活动。当然在生产环境直接做测试是不推荐的，但是我们可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。尽量做到技术人员要比业务方先发现问题。
测试右移其实还可以理解为如果线上发生任何问题，我们有没有能力第一时间发现问题并解决问题，并保证线上数据的一致性或尽可能少的影响线上用户，以及并且实时获取用户反馈。
二，测试左移，我们可以做什么
1. 在需求评审时不只是了解需求，更是要去评估需求的质量，分析需求的合理性以及完整性。
2. 代码扫描，代码质量检查，进行单元测试，测试驱动开发，这些都是在开发阶段就引入测试的手段。
3. 测试人员尽早介入测试，参加需求分析，评审。
4. 持续测试：自动化测试。
对于测试左移其实我们还有很多东西要做，就好像一开始说到的都是为产品质量服务，那么在研发流程中的任何角色、人员都要为质量服务。
有哪些活动可以提高质量上限（举例）？
- 健康的项目流程（合理并且严格遵守的项目流程）
- 合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）
- 出色的系统架构
- 完整的系统设计（评估设计的质量，分析需求的合理性以及完整性）
- 充分利用静态代码扫描
- 进行研发标准的定义
- 更早的测试分析（先于开发完成需求的分析，做好各种评审的准备）
- 尽早的测试执行（提早参与测试执行，在集成前就发现一些问题）
有哪些活动可以提高质量下限（举例）？
- 健康的测试流程
- 优秀的测试用例
- 合理的测试计划
- 合适的自动化
- 适当的探索式测试
- 开发自测（TDD、BDD，测试提供更好的用例、技术支持）
- 团队质量意识的培养
对于测试左移，也需要一个重要的基础，工程习惯，SDLC成熟度，测试分层，持续集成，链路上延展发布的节奏，纵深上需要贴合业务的专精领域的深度探索，代码扫描（规范，问题，安全，异常等），CR， 代码提交行为分析，test double（mock ， fake， stub，dummy）， UT， 自动化，验收测试等。左移需要工程效率具备不亚于研发的代码能力。
因此对于测试左移，笔者认为可以围绕质量服务思想展开，参与人员则不仅仅局限于测试人员
当然实践起来会存在一些问题，例如笔者团队实践起来，就出现了
- 测试要求提供概要设计、接口文档！！！
- 测试要求单元测试必须通过！！！
- 测试干预需求设计！！！
很多人都认为是测试在要求完成一些没必要的事情，测试在干预我的工作。
其实问题的矛盾点在于前面说过的一句话：不管是测试左移还是测试右移，都是为产品质量服务。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试同学需要关注的。对于测试左移的落实，最重要的就是全员质量服务意识的培养
2，测试右移，我们可以做什么
- 测试上线及时验证，有问题，开发快速回滚代码
- 上线后开发监控服务日志，日志报错，代码回滚
- 监控服务流量，出现流量报警快速定位问题
- 闭环的线上问题反馈-检查-解决-更新流程
- 更便捷的日志查看、回传服务
- 丰富有效的log，便于问题的快速定位
- 丰富的监控指标（例如业务异常点指标）
- 成本监控（例如短信发送等）
- 关键指标每日监控（服务器指标）
- 生产数据监控（警报）（通过sql语句实现生产数据监控，例如是否有多个订单号一样的订单出现等）
- 用户反馈问题及时跟进，针对缺陷，通知开发尽快解决，针对体验，通知产品打磨细节。
因此对于测试右移，我认为可以围绕问题反馈、发现、定位、监控展开，参与人员则不仅仅局限于运维人员
当然一样的，实践起来也是存在问题，除了技术问题之外，还有例如：
- 线上监控搭建后无人使用
- 线上问题反馈机制，业务人员不配合等等
- 监控指标不合理，反而被认为增加服务器负载
测试右移的落实，除了质量服务的培养，更加重要的反而可能是：完善的反馈、发现、定位，在监控架构完善后，怎么更好的与项目流程结合，不要让其成为累赘。
扫一扫
1724
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
