有人说：一个打工测试要什么高度呢？不就是点点点和写if-else吗

Time will tell.

前几天看到某大佬写的一篇关于测试左移和测试右移的文章。

左移就是测试提前介入。

右移就是上线的跟进。

测试并不只是点点点，看有没有bug。

一般测试所在的团队叫质量保障或是质量管控部门，对整个项目质量的把控，而不是代码的把控。

之前一直在做接口自动化，对接口自动化的流程有所了解，都是：

数据准备 --> 请求发起 --> 获取返回 --> 进行断言 --> 发送报告

然后结合 jenkins搞下持续集成，结合代码覆盖率工具搞下覆盖率，完成整个流程：

研发提交代码 --> 静态代码检测 --> 自动化用例执行 --> 结果报告 --> 代码覆盖率报告

一般自动化就是这样的流程，恰恰就是这样而形成了局限性。先说说每一点可以深入做的东西，那么应该思考以下几个问题：

1. 易用性。是不是扔给其他人写用例，人家容易上手

2. 用例 /数据的维护难度，这是自动化用于项目比较头痛的问题

3. 自动化框架是否可优化，支持多线程吗。执行1000条用例花费多少时间

4. 测试数据如何维护。是新建数据，还是使用固定数据？

然而这里缺失了最重要的环节：

1、数据和环境

1. 自动化的环境要和现在的功能测试环境脱离，需要重新搭建一套自动化环境；

2. 测试数据也要跟功能测试环境隔离，互不干扰，但又需要可以随时同步；

3. 数据是否可清洗，可备份，可回滚，可移植；

2、监控

1. 有没有合理的监控机制；

2. 更早的发现问题来止损；

3. 现有的架构是否对异常能灵活的降级；

4. 可以从线上数据监控来分析分析业务需求是否达到期望，是否可以促进项目的质量；

因此接口自动化的流程应该变成了：

环境搭建 --> 数据准备/清洗 --> 用例执行 --> 发送报告 --> 线上监控 --> 项目迭代

这样就是从高了一层的角度去看质量，形成了闭环。

测试可以从项目质量把控去要求研发做一些事情，如日志打印的规范，线上监控…

这边了解到很多团队是让研发去写测试用例，测试去review用例，用例执行可能由产品或开发来执行，然后测试有足够的时间去做工程化的东西。

当有小需求过来，研发自测通过后，但担心会影响到其他业务，如果测试有足够好的自动化测试工具提供，这样就可以解放部分时间。

有重构项目，迁移项目的时候，自动化也可以节省很大部分的时间。

最后分享一个Python自动化资料学习扣裙：175317069。里面有已整理好的测试学习资源，也有行业深潜多年的技术人分析讲解。