让我们从更高的角度看自动化测试

发表于:2017-12-12来源:cnblogs作者:jwentest点击数: 标签:自动化测试
高度不够,把这个问题/东西拔高一些再看看,应该站在更高的位置看问题...这些是别人对我的评价,是面试过程中被问到的,是别人对我的指导/建议...有的人会问一个普通打工的需要

前言

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

我所了解的测试

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

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

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

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

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

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

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

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

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


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

数据和环境

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

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

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

 

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

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

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

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

 

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

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

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

 

结尾

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

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

原文转自:http://www.cnblogs.com/jwentest/p/8024968.html