行业动态

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

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

  前言

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

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

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

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

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

  我所了解的测试

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

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

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

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

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

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

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

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

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

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

  数据和环境

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

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

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

  监控

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

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

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

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

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

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

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

  结尾

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

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

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


新闻资讯

联系我们

联系人:何女士

手机:13825291265

电话:0755-21072941

邮箱:hr@duoceshi.com

地址: 广东省深圳市龙华区龙华街道清湖和平路62号优鼎企创园D栋201室,202室

用手机扫描二维码关闭
二维码