从高的角度看自动化测试

前言

高度，这个词我很早就被提及。
高度不够，把这个问题/东西拔高一些再看看，应该站在更高的位置看问题...这些是别人对我的评价，是面试过程中被问到的，是别人对我的指导/建议...
有的人会问一个普通打工的需要什么高度呢？不就是点点点的，不就是写if-else的...
对问题的思考其实就是优秀和普通的差别吧，尤其是来这里更为明显感觉到

我所了解的测试

前几天，看到虫师的一篇文章，是关于测试左移和测试右移的。左移就是测试提前介入，右移就是上线的跟进，这些都是接触过的，

测试并不是点点点，看看有没有bug，一般测试所在的团队都叫质量保障or质量管控部门，对整个项目质量的把控，而不是代码的把控。

因为之前一直在搞接口自动化，对接口自动化的流程有所了解，都是 数据准备--> 请求发起 --> 获取返回 --> 进行断言 --> 发送报告，然后结合jenkins搞下持续集成，结合代码覆盖率工具搞下覆盖率，

完成整个流程：研发提交代码 - > 静态代码检测 -->自动化用例执行 --> 结果报告 --> 代码覆盖率报告

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

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

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

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

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

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

数据和环境

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

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

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

 

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

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

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

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

 

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

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

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

 

结尾

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

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

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

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