认识达内从这里开始

随着互联网的不断发展，越来越多的企业和程序员都开始关注自动化测试带来的变化，而今天我们就通过案例分析来了解一下，自动化测试都存在哪些误区。

1、只看短期效率收益

有的团队希望自动化case来提升测试效率，当然，这是自动化case可以获取的收益之一。这些团队还会针对自动化对效率的提升制定定量的指标，然后每周，每月，每季度(当然，有些人还没有坚持到季度末就不做了)来跟进。

自动化测试也是一个很难在很短的时间内就能看到收益的工具，并且还需要付出一些成本：需要学习自动化测试的配套工具，编写自动化case的框架，调度自动化执行的相关工具……

因此，开始的一段时间内，自动化测试有可能会降低测试效率。但是，一旦掌握这些技巧，我们就会发现汽车确实比马车跑的快，难道不是吗?

2、只看个人效率收益

在进行自动化测试之前，大多数团队都会选择一些业务来试点，然后根据试点业务的反馈来确定是否要大范围推广。

但是，在实际试点的时候，会出现很多影响因素：例如测试人员前期没有接入测试了解，测试人员没有提前和研发人员确定接口定义，测试人员前期在跟进其他项目……

如上的因素会导致当一个测试项目到来时，测试人员没有足够的时间来消化那些需要在前期所付出的学习成本。在面对一个个紧急的项目和需要付出一定的成本时，这些试点的测试人员会自然而然的继续使用旧有的手工测试的方式来保证项目的快速跟进。

试点项目的测试人员会从自身的利益出发来选择测试方案。然后这些试点的测试人员就会汇报说：自动化测试太浪费时间了，没法提高效率。如果管理者不仔细继续和这些一线的同学深入探讨，那么终就会根据试点同学的结论得出一个偏离事实的结论：自动化测试确实无法提升效率。

然而，上述的一些试点人员遇到的问题从本质上讲，并不是自动化测试本身的问题，这里涉及到更多的流程、沟通、协作的问题。不是自动化测试不能提升效率，而是当前的环境不允许自动化测试发挥作用。

3、成本核算标准不一致

如前所述，自动化测试是需要学习成本的，不经历风雨怎么见彩虹?大多数团队在核算手工测试和自动化测试的成本时采用的标准并不一致。他们会忽略：手工测试重复测试的成本，会忽略手工测试重复书写测试报告的成本……但是他们会给自动化测试追加上：上下游环境依赖成本，环境部署成本，接口定义不完备的成本，自动化用例的维护成本太大了……

手工用例就不需要维护成本?不过从我的观察发现，确实不需要。因为有些团队压根就不写手工用例，当然就谈不上成本了。还有的团队即便有手工用例也从来不会维护，下一个同学测试类似的项目的时候，参考一下之前的用例，然后自己重新写用例。

4、不关注团队收益

试点项目的测试人员只根据自己的个人收益来做测试方案的选择。但是团队中的个人是相互联系的，团队内部的项目也会是连续的，而不是离散的。

某个人测试的某个项目，下一次可能就换其他人来测试了。某个短期来看不会变化的项目，可能数月之后就会修改了。项目每次都修改一点点，可能半年之后就会有上百个修改点了……

如果站在团队的角度考虑，我们团队内每个人编写的自动化用例有时候虽然对个人而言ROI很低，但是对团队的ROI却可能非常大。

如果每一个变更很小的项目都不编写自动化用例，那么当项目做大的时候怎么办?如果每个项目都是上线后就不修改了，那当这个项目的代码要下线的时候怎么办?

当然，这些对于个人而言是无需关注的事情，因为谁知道接下来的测试还是不是你负责?但是，终却还是这个团队来负责的，不是吗?当所有这些都没有仔细执行的时候，在遇到大的项目，在遇到团队技术重构的项目时，对于团队而言，就需要借助其他的手段了。

5、自动化用例是万年不变的

因为自动化用例需要随着业务代码的迭代而迭代，而很多团队又认为这样的成本太大了。因此自动化用例就成了一堆万年不变的功能的测试用例，终自动化就成了“形而上”般的存在。

业务代码都在不断变化，不断升级，不断迭代，凭什么自动化的用例就得万年不变，自动化的用例就不用维护?实在是想不通这里面的道理。

自动化用例的落后，会导致自动化用例无法成为业务代码的试刀石，当他变成一件附属品时，他所带来的一切就只有成本了。

6、项目迭代太快了，等稳定了再用自动化测试

越是大的项目，越是迭代次数多的项目，越是变化快的项目，自动化测试的收益越大。大多数团队，此时想到的更多的是快速的变化带来的是更多的自动化用例的维护成本。

但是，即便是创业公司，谁也不会在项目启动的时候就朝着把项目做烂的目标行进吧?

等项目稳定的时候，估计就是这个产品要下线的时候了。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请在707945861群中学习了解。