- 人员数量不够
非常常见的场景, 开发没几个, 凭什么测试要那么多, 假设这里面有3个测试, 是不是得有1个人会搞框架? 是不是得有2人搞功能测试, 一个人又搞框架, 有些脚本, 真来得及吗?
- 人员基础不够
现在有的大公司, 是这样子协作的, 也就是某模块需求谁谁测试的, 那么对应的自动化脚本, 就由谁来写, 但是小公司, 招聘成本就低, 就不太可能找到又能熟悉功能测试的, 又会自动化. 还是挺难的. 况且搞功能测试的人, 搞的时间长了, 也不太想写代码的, 所以, 就市场上, 这类型人员的供给是比较少的, 到了小公司那里, 就得高价格招聘了.
- 测试框架比较差编写成本大
我个人认为市面上的框架, 都有很大的改进空间的, diamante重复率高, 需要懂pythony语法是痛点, 导致普通员工上手难度大. 好的框架范式, 可以参考我写的框架. https://github.com/WaterLoran/RuoYiTest
- 开发文档和接口不规范导致编写成本大
开发写的接口, 没有统一规范的话, 框架的抽象难度也会很大, 然后测试人员写脚本的时候, 成本也会增加, 相当于这是历史包袱, 即没有重构所带入的包袱
- 领导不懂导致投入不足
如果领导迫于一些压力, 比如交付压力, 又短时间内看不到自动化的收入的话, 就会认为没有用
- 对自动化的定位有误
有些人会期望他能够把BUG发现, 这是错误的想法, 他的定位应该是, 回归测试, 即把之前的用例执行一遍, 发现老代码问题, 看看有无改动引发, 以及跑完自动化脚本之后, 能够给人信心去发布版本
- 对自动化的回报期望过大
功能测试人员平均每天发现10个BUG, 以及线上反馈的问题每天5个的话, 但是自动化每周才发现1个改动的BUG. 确实自动化的收益太小了, 但是另外一个问题, 就版本质量这么差的时候, 可能就应该重新审视功能测试过程, 做线上问题的问题追溯, 容纳后调整功能测试的流程和规范和要求, 而不是期望自动化也能有同样的收益, 毕竟自动化的定位是不一样的