聊聊自动化测试为什么推广难

    前几天和群里的一个朋友聊天，他提到了自己的一个问题，为什么感觉自动化测试推广很难，当时和他简单的讨论了一下，也有一些很有亮点的东西。
t8t ]v)J0    现在各个公司都在做自动化测试，但是在实施自动化测试的过程中碰到了很多问题，推广难是其中最普遍的问题之一。很多公司在初期的自动化测试做的不错，但是想推广的时候却发现效果不尽人意，和预期所想象的差太远。为什么？原因当然有很多，我主要想聊其中的两个原因，一个是自动化测试的易用性，另一个是自动化测试的用例设计问题。51Testing软件测试网q U'w|1V
    自动化测试的易用性是什么？简单的说，就是自动化测试人员开发的脚本，易于使用、易于维护、易于排查问题。首先说易于使用，笔者所在公司使用RFT做自动化测试，采用了IBM的三层结构的设计，还引用了很多第三方JAR包来扩展自动化测试的功能，组内一直用的很好。后来有功能测试人员把这套脚本拿过去，却反馈说不好用，过去一看，原来是没把JAR包加到构建路径里，然后过去解决问题：加JAR包、设置工程依赖、设置编译目录、设置脚本执行参数，一会儿搞定，由此想到，这其实就反映的是自动化测试的易用性问题。如果我们开发的脚本不能被功能测试人员广泛的使用起来，那么自动化测试的推广自然无从用起。笔者现在也正在这方面努力改善。争取做到能让功能测试人员一键执行自动化测试：自动部署新程序、自动下载自动化测试脚本、自动编译自动化测试执行包、自动执行测试、第二天来看结果，而且自动化测试的内容简单明了，一目了然。如果能做到这种程度，大家都喜欢用自动化测试、都乐于用自动化测试，推广工作自然水到渠成。易于维护和易于排查就不细说了，因为做自动化测试的人都懂得要让自己的脚本有一定的扩展能力和可维护性。51Testing软件测试网na)pf*Mc[
    第二点要说的是自动化测试的用例设计，其实这是一个老生常谈的问题，就不再这里细说了，只是强调几点大家容易忽视的：决定自动化测试效果的不是测试脚本如何编写，而是你的用例如何设计；一份糟糕的测试用例只会让自动化测试做无用功，自然没人爱用；如果我们的自动化测试用例，覆盖了软件大部分的核心功能和业务场景，那么自然会变的重要。51Testing软件测试网l:m*k7F1Rpo
    在群里的那位朋友，把自动化测试推广难的原因归结于测试环境混乱和开发过程，我觉的这是影响推广效果的两个因素，但是不是主要原因。自动化测试推广难在于没人爱用；没人爱用的原因是因为测试人员觉得自动化测试不能提高他们的工作效率和工作质量；那么自动化测试如何提高测试人员的效率和质量？1、要让测试人员易于使用自动化测试；2、永远永远的把用例设计摆在自动化测试工作的首位~！
^o }1d#q0OT,to;r+X0