小公司做自动化的困境

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

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

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

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

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

4. 对自动化的定位有误

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

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

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