软件测试之从更高的角度去看自动化测试

软件测试之从更高的角度去看自动化测试

　　前言

　　高度，这个词我很早就被提及。

　　高度不够，把这个问题/东西拔高一些再看看，应该站在更高的位置看问题...这些是别人对我的评价，是面试过程中被问到的，是别人对我的指导/建议...

　　有的人会问一个普通打工的需要什么高度呢?不就是点点点的，不就是写if-else的...

　　对问题的思考其实就是优秀和普通的差别吧，尤其是来这里更为明显感觉到

　　我所了解的测试

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

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

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

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

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

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

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

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

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

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

　　数据和环境

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

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

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

　　监控

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

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

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

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

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

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

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

　　结尾

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

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

　　以上是关于软件测试的知识，由多测师亲自撰写! https://www.duoceshi.com/