自动化测试建设的难点
自动化测试建设的难点1.优先级不够，没有建设的迫切性
如果把质量范畴的各类工作用四象限法来划分的话，自动化体系建设这样的事情大概率会落到『重要不紧急』象限中。
这个判定的逻辑很简单：我们当然认可自动化带来的各种价值，但是目前的手工测试也能很好的发现问题，交付的质量、效率也堪堪可行。
而且，如果你真的要全面推行自动化体系落地，短期成本还会明显增加：
需要招聘有编程能力的测试开发工程师
普通测试工程师学会了自动化测试能力，有了更高的薪酬期望
越懂代码、自动化，测试范围越大(多层累加)，不一定会缩短测试周期
另外尴尬的一点，自动化体系建设的成果很难量化、包装出来：写了多少测试用例、降低了多少人力成本、测试周期缩短多少、业务场景的覆盖率有多少?
挖掘分析上面的指标，你甚至会发现在某些时间段，自动化建设还带来了负作用，这就落了个吃力不讨好。
所以这一堆大大小的原因加起来，结果就导致了这个事情叫好不叫座，没多少领导愿意主动承担起这个事情来。
https://picx.zhimg.com/80/v2-389f5ea94ec360c8320c6b20451f78db_720w.png
2 建设路线图不清晰
能在公司层面推动自动化建设的不多，真正落地自动化体系的不多，愿意出来分享成功经验的不多…这么几个不多累加起来，就导致了我们在建设初期很难去借鉴别人。
作业抄不到，自动化体系负责人又往往是开发背景，工程能力强，但是测试的积累不够，不一定能想清楚整个项目要怎么推动、推进路径是什么;而在执行层，执行者有可能是测试背景有不错代码能力的工程师，按理说能补足上面提到的缺陷，但是毕竟不在一个维度，看得到局部，但缺少一些全局视角。
3 长线建设中干扰因素多，建设决心不够
上面也提到了自动化是需要持续迭代的，这是一个长线建设，贯穿在整个产品的生命周期中。所以在研发过程中碰到的各种干扰因素在自动化建设中同样会遇到。
测试人员不够、项目周期被压缩、需求频繁改动、老板让做的等各种司空见惯的意外，迫使你不得不放下手中的自动化测试工作，改成手工测试加速发版上线。
在版本高速迭代的并且具有敏捷开发能力的互联网公司里，这些流程不合理、资源不足的现象都是合理的，你得承认、接受，并做出妥协，但不要质疑自动化、不要放弃持续建设。
4 测试架构组缺乏对业务测试组的穿透能力
最后提一个很痛的问题：组织架构。很多公司尤其是大厂，缺少公司层面的质量部门。为了快速应对业务的变化，更喜欢采用垂直向的组织架构形式，把各个职能角色放进来，而整个业务条线负责人大多又是产品、开发背景，测试在垂直条线里存在感、话语权都有限。
这样的组织架构下，业务测试组缺少来自公司层面、自上而下的测试规范、行为约束。有些公司建立了一些横向的测试架构组尝试解决，甚至碰瓷中台，推测试中台或者组织中台这样的概念，想要缓解这样的尴尬。
我目前直接负责整个公司的质量体系，我的主管也充分授权，但即便这样的情况下，我依然觉得这些横向的测试架构组的产出不容易穿透到业务测试组中：双方考核目标差异、业务条线压力等都行成了厚实的壁垒，阻挡着自动化体系的落地。
页:
[1]
