小公司做自动化的困境

  1. 人员数量不够

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

  1. 人员基础不够

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

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

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

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

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

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

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

  1. 对自动化的定位有误

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

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

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

相关推荐
追风赶月、25 分钟前
【Linux】线程概念与线程控制
linux·运维·服务器
CP-DD39 分钟前
Docker 容器化开发 应用
运维·docker·容器
努力的悟空2 小时前
国土变更调查拓扑错误自动化修复工具的研究
运维·自动化
周末不下雨3 小时前
win11+ubuntu22.04双系统 | 联想 24 y7000p | ubuntu 22.04 | 把ubuntu系统装到1T的移动固态硬盘上!!!
linux·运维·ubuntu
耗同学一米八4 小时前
2024 年河北省职业院校技能大赛网络建设与运维赛项样题四
运维·网络
东华果汁哥5 小时前
【linux 免密登录】快速设置kafka01、kafka02、kafka03 三台机器免密登录
linux·运维·服务器
肖永威5 小时前
CentOS环境上离线安装python3及相关包
linux·运维·机器学习·centos
zhd15306915625ff5 小时前
库卡机器人维护需要注意哪些事项
安全·机器人·自动化
布鲁格若门5 小时前
CentOS 7 桌面版安装 cuda 12.4
linux·运维·centos·cuda
Eternal-Student5 小时前
【docker 保存】将Docker镜像保存为一个离线的tar归档文件
运维·docker·容器