00-1010已经测试了好几年，真正学习和实践自动化测试一年，感觉这一年收获很大。一直想写一篇文章分享一些自动化测试的实践经验。我最终决定花些时间来做这件事。

首先，明确自动化测试的概念。广义来说，自动化包括所有用工具(程序)代替或辅助手工测试的动作，可以认为是自动化，包括性能测试工具(loadrunner，jmeter)，或者我自己编写的程序，用来生成1到100个测试数据。狭义地说，人工测试过程是通过用工具记录或编写脚本来模拟的，测试用例是通过回放或运行脚本来执行的，从而取代了系统功能的人工验证。

当然，我们一般认为“自动化测试”是“基于产品或项目UI层的自动化测试”。

什么是自动化测？

的概念最近被曝光了。传统的自动化测试更注重产品UI层的自动化测试，而分层自动化测试则主张产品的不同阶段(层次)需要自动化测试。

如果你对软件测试感兴趣，想了解更多的测试知识，解决测试问题，并开始指导帮助你解决测试中遇到的问题，我们这里有technology ykh。如果你正在找工作或者刚从学校出来，或者你已经工作了，但是你经常觉得有很多困难。如果你觉得自己考得不够好，想继续学习，想转行又怕学不会，可以拨打1079636098加入我们。可以在群内获取各大软件测试公司的最新面试资料和Python自动化、接口和框架搭建学习资料！

相信考研的同学对上面的金字塔并不陌生。这不是对应产品开发不同阶段的测试吗？我们需要标准化单元测试，也需要相应的单元测试框架，比如java的Junit、testNG、C#的NUnit、python的unittest、pytest等。几乎所有主流语言都有相应的单元测试框架。

集成和接口测试对于许多新手测试人员来说并不容易理解。单元测试侧重于代码的实现逻辑，例如if分支或for循环的实现。然后，集成和接口测试的第一个关注点是函数或类(方法)提供的接口是否可靠。例如，如果我定义一个add()函数来计算两个参数的结果并返回它们，那么我需要调用add()并传入参数，并比较返回值是否添加了这两个参数。当然，界面测试也可以以url的形式交付。例如，如果我们通过get向服务器发送请求，那么我们发送的内容将作为URL的一部分传递给服务器。然而，例如，由网络服务技术提供的公共接口需要通过工具(如soapUI)进行测试。

我们应该熟悉UI层的自动化测试。大多数测试人员的大部分工作都是测试UI层的功能。比如我们反复测试一个表单提交、结果查询等功能，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的工作。UI层有很多自动化测试工具，主流的有QTP、Robot Framework、watir、selenium等。

为什么要画金字塔而不是长方形或者倒三角形？这是为了显示自动化测试在不同阶段的比例。如果一个产品从来没有做过单元测试和界面测试，只做UI层的自动测试是不科学的，很难从本质上保证产品的质量。如果你试图实现UI层的全面自动化测试，那将是一种人力和金钱的浪费，会投入大量的人力和时间，最终的收益可能远远低于付出的成本。因为级别越高，维护成本越高。尤其是UI层的元素会时不时的变化。因此，我们应该把更多的自动化测试放在单元测试和接口测试阶段。

由于UI层的自动化测试成本太高，我们只能做单元测试和接口测试。不！因为不管是什么样的产品，UI层最终都是呈现给用户的。因此，测试人员应该更加关注UI层。那么正是因为测试人员在UI层投入了大量的精力，我们才有必要通过自动化的手段来帮助我们“部分解放”重复性的工作。

自动化测试最害怕的就是变更，因为变更的直接结果就是测试用例的失败，所以维护自动化脚本是很有必要的。如何控制故障，降低维修成本，对自我改造的成败至关重要。相反，一个总是成功运行的自动化测试用例是没有价值的。

至于金字塔中三个测试的比例，要根据实际项目要求来划分。在《google 测试之道》这本书里，对于谷歌产品，70%的投入是单元测试，20%是集成和界面测试，10%是UI层自动化测试。

分层的自动化测试

自动化测试？

根据《中国软件测试从业人员调查报告》，手工测试占到的89% ，相对开发来说，测试的门槛底，薪资普遍较底，所要求的知识面虽然有一定广度，但缺乏深度。这是测试的普遍现状。

正因为手工测试人门槛不高，使大量的毕业生，甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强烈的危机感。由于工作的技术含量不高，薪资的涨幅遇到瓶颈，另一方面受到新进入者的威胁，同样的工作公司花5K招来的人就可以做，那么就不会花8K 的招。

好吧，这个问题不应该出现讨论技术的话题中，但他的确是大多测试人员不得不面对的一个问题。所以，从测试人员自身的发展来说，我其实非常需要通过自动化技术来增加自己的竞争力。当然，做到一定年限测试人员会选择转管理或其它岗位，这又是另一个话题了。

从测试行业的发展来说，国内产品由于产品特点，世界级的产品不多，技术含量相对不高，质量要求相对要求不高，外包国外项目，测试人力成本低廉，所以需要大量的手工测试人员。

所以，在不远的未来，我认为纯的工手测试人员的需求是递减，公司更需要更高技术能力的测试。质量需要测试，测试行为永远不会消失，但纯的手工测试人员是否消失是有可能的。

好吧，你可以说测试多朝阳的行业，我纯属在危言耸听。不管未来如何，我们都需要提升自身的技能对吧！

什么项目适合做自动化测试？

假如你已经决定要学习自动化测试了，如何学习是要面临的下一个问题？这个问题以被测试产品为出发点进行分析，假如你所学的技术不能得到应用（验证），将会使你的学习过程寸步难行。

首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。

软件需求变动不频繁

测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

项目周期较长

由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。

自动化测试脚本可重复使用

自动化测试脚本的重复使用要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；所选择的测试工具是否适应这种差异；最后，测试人员是否有能力开发出适应这种差异的自动化测试框架。

选择什么工具进行自动化测试

假如你已经确认了XX 项目适合做自动化测试，那么接下来你要做的就是选测试工具了。

首先要先确认你所测试的产品是桌面程序（C/S）还是web应用（B/S）。

桌面程序的工具有：QTP、 AutoRunner

web应用的工具有：QTP、AutoRunner、Robot Framework、watir、selenium

由于B/S架构的诸多优势，早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如，被测试有产品是C/S架构的，那么推荐QTP ，QTP在UI自动化测试领域占到了一半的试用率。所以，足以说明QTP在自动化领域强大，易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然，要想学好QTP ，你必须要掌握VBS脚本语言。

如果，被测产品是B/S 结构，那么推荐selenium ，为什么不是QTP 或其它工具？因为selenium 对B/S应用支持很好，更重要的一点，它支持多语言的开发，真正的试用selenium ，你所要掌握的不仅仅是一个工具而已，你还需要学习一门语言。我为什么要选择selenium？还要学一门语言，这无疑增加了我的学习成本。增加成本的同时，也增加的你的竞争力，而且，在这个过程中你不单单只是学会了一个自动化工具而已，你完全可以使用所学的语言去做更多的事情。

好吧！假如你决定试用selenium 了之后，你又面临了一个新的问题，选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。

从语言易学性来讲，首选ruby ，python

从语言应用广度来讲，首选java、C#、php、

从语言相关测试技术程度（及 资料）来讲：ruby ,python ,java

或者你可以考虑整个技术团队主流用什么语言，然后选择相应的语言。

愿你我相遇，皆有所获！ 欢迎关注微信公众号：程序员一凡

1.免费领取一份216页软件测试工程师面试宝典文档资料。

2.软件测试学习路线以及相对应的视频学习教程免费分享！