小公司做自动化的困境

  1. 人员数量不够

非常常见的场景, 开发没几个, 凭什么测试要那么多, 假设这里面有3个测试, 是不是得有1个人会搞框架? 是不是得有2人搞功能测试, 一个人又搞框架, 有些脚本, 真来得及吗?

  1. 人员基础不够

现在有的大公司, 是这样子协作的, 也就是某模块需求谁谁测试的, 那么对应的自动化脚本, 就由谁来写, 但是小公司, 招聘成本就低, 就不太可能找到又能熟悉功能测试的, 又会自动化. 还是挺难的. 况且搞功能测试的人, 搞的时间长了, 也不太想写代码的, 所以, 就市场上, 这类型人员的供给是比较少的, 到了小公司那里, 就得高价格招聘了.

  1. 测试框架比较差编写成本大

我个人认为市面上的框架, 都有很大的改进空间的, diamante重复率高, 需要懂pythony语法是痛点, 导致普通员工上手难度大. 好的框架范式, 可以参考我写的框架. https://github.com/WaterLoran/RuoYiTest

  1. 开发文档和接口不规范导致编写成本大

开发写的接口, 没有统一规范的话, 框架的抽象难度也会很大, 然后测试人员写脚本的时候, 成本也会增加, 相当于这是历史包袱, 即没有重构所带入的包袱

  1. 领导不懂导致投入不足

如果领导迫于一些压力, 比如交付压力, 又短时间内看不到自动化的收入的话, 就会认为没有用

  1. 对自动化的定位有误

有些人会期望他能够把BUG发现, 这是错误的想法, 他的定位应该是, 回归测试, 即把之前的用例执行一遍, 发现老代码问题, 看看有无改动引发, 以及跑完自动化脚本之后, 能够给人信心去发布版本

  1. 对自动化的回报期望过大

功能测试人员平均每天发现10个BUG, 以及线上反馈的问题每天5个的话, 但是自动化每周才发现1个改动的BUG. 确实自动化的收益太小了, 但是另外一个问题, 就版本质量这么差的时候, 可能就应该重新审视功能测试过程, 做线上问题的问题追溯, 容纳后调整功能测试的流程和规范和要求, 而不是期望自动化也能有同样的收益, 毕竟自动化的定位是不一样的

相关推荐
大霞上仙12 分钟前
Ubuntu系统电脑没有WiFi适配器
linux·运维·电脑
Karoku0661 小时前
【企业级分布式系统】Zabbix监控系统与部署安装
运维·服务器·数据库·redis·mysql·zabbix
为什么这亚子1 小时前
九、Go语言快速入门之map
运维·开发语言·后端·算法·云原生·golang·云计算
布值倒区什么name1 小时前
bug日常记录responded with a status of 413 (Request Entity Too Large)
运维·服务器·bug
。puppy2 小时前
HCIP--3实验- 链路聚合,VLAN间通讯,Super VLAN,MSTP,VRRPip配置,OSPF(静态路由,环回,缺省,空接口),NAT
运维·服务器
颇有几分姿色2 小时前
深入理解 Linux 内存管理:free 命令详解
linux·运维·服务器
光芒再现dev2 小时前
已解决,部署GPTSoVITS报错‘AsyncRequest‘ object has no attribute ‘_json_response_data‘
运维·python·gpt·语言模型·自然语言处理
AndyFrank3 小时前
mac crontab 不能使用问题简记
linux·运维·macos
成都古河云3 小时前
智慧场馆:安全、节能与智能化管理的未来
大数据·运维·人工智能·安全·智慧城市
算法与编程之美4 小时前
文件的写入与读取
linux·运维·服务器