测试的行为本质是什么？

　　为什么先从这个概念开始谈起，因为对于新手来说，总是把自动化看得很高端和复杂。

　　先来看看功能测试如何进行的：编写测试用例，测试用例当中最主要的是测试步骤和预期结果；测试人员根据测试用例执行操作步骤，然后通过眼睛和思考判断实际结果与预期结果是否相等。如果相等，测试通过；如果不相等，测试失败。

　　自动化测试要做的事情与功能测试是一致。这里的自动化主要包含三个层面的自动化，单元测试自动化，接口测试自动化和web测试自动化。当然，不同层面的自动化关注点是不一样的。

　　单元测试自动化，调用被测试的类或方法，根据类或方法的参数，传入相应的数据。然后，得到一个返回结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，这里单元测试关注的是代码的实现与逻辑。

　　接口测试自动化，根据接口文档，到底是传get请求呢？还是post请呢？调用被测试的接口，构造相应的数据（id=1,name=zhangsan），得到返回值，是200成功，并返回查询结果。还是10021，用户名不能为空。不管输入的参数是怎样的，我们都将得到一个结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，接口测试关注的是数据。只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。

　　web测试的自动化，这种测试更贴近用户的行为，模拟用户点击了某个按钮，向个输入框里输入了什么。但是用户可以看到登录成功了，但web自动化并不知道它刚才的点击有没有生效。所以，要找“证据”，比如，登录成功后页面右上角会显示“欢迎，xxx”。这就是登录成功的有力“证据”。于是，当web自动化登录成功后，就去获取这个数据进行断言。断言如果相等，测试通过；如果不相等，测试失败。所以，web自动化的关注点用户操作形为，页面上真正的按钮和输入框是否可用。

　　所以，从测试的行为本质上来看，功能测试与单元自动化测试，接口自动化测试和web自动化测试并没有区别。唯一的区别是，一个由人来执行，一个由代码或工具执行。

我们时常会听到两个声音：

　　一种声音，许多测试新手把自动化想象成走向人生巅峰的必备技能。只要掌握了自动化就可以当上CTO，迎娶白富美，走向人生巅峰了。时常用期盼的小眼神问：xxx 自动化多少钱一个月？如何学习自动化测试技术？推荐个书或资料或视频吧？

　　另一种声音，略懂自动化的，被自动化坑过的，或者压根就鄙视和抵触自动化的，又把自动化说成屎。页面老是变，维护成本高，这个元素TM怎么定位不到。劳民伤财，费了很大力气也发现不了bug。而自动化用例本身到是bug不断。什么？自动化居然不能做浏览器兼容性测试？什么？你们领导让你搞自动化呀？你们领导SB。

　　先说前一种声音，理论上任何技能都是为了提高效率和产出，节约公司成本为前提的。比如，以前项目要5个测试，现在用了自动化之后，3个就够了。但如果用了自动化，还需要再招2个人来维护自动化脚本。那就没戏。那我只为学习不行啊？我学好了找个专职做自动化的岗位不行啊？工资起码比现在功能测试高吧！行行行！学习当然行。但方法要正确。我稍后再说正确学习自动化测试的姿势。（左手右手一个慢动作...）但，其实我想告诉你，对于测试来说，理论上你掌握一个单一的技能是远远不能走上人生巅峰的。

　　再说另一种声音，这个情况一般是我们对自动化测试的期望太高了。自动化嘛，不就应该自动化脚本写好，自动化脚本刷刷的跑。然后，喝杯茶的功夫，bug就找到了。要真这么美好，这得有多少功能测试人员得转行去搬砖了。一般造成这个认识的，主要两方面原因，技能不够，有些只依赖于各种自动化测试工具，有些一只能写写简单的模拟用户操作的脚本。第二个原因，不管三七二十一上来就拿自己所测试的项目开刀。这元素咋定位？这功能怎么写断言？我靠，脚本运行又出错了。你有分析你的项目是否适合做自动化了么？看到有些同学拿着只能在IE下运行的某XXX项目，艰难的定位着元素，赶紧放弃吧！！

我这里主要指的是webUI自动化以及使用selenium工具的情况下。

数据驱动怎么玩? 

 　　数据驱动：因为数据的改变导致结果的改变。说人话就是，因为我在百度里搜索的是“selenium”导致结果就是包含了“seleniumhq.org”。因为我登录时候输入的是“zhangsan”导致的结果就是登录之后页面右上角显示“欢迎，zhangsan”。你自己体会一下，我说的也不一定对。

　　曾几何时，不知哪位测试大牛说的，数据一定要放在excel表格里才逼格满满。再后来就演变成元素的定位一定要放到excel里才够“数据驱动”，才是玩自动化测试的高级境界。

　　抱歉，可能我姿势不对！因为我不知道你们是如何想像着把元素定位放到excel表格里面的。

　　但我认为这样做纯属多此一举。

　　1、读excel有多麻烦，你知道么？不知道的百度一下，“python读取excel ” 或 “java 读取excel”。你想像一下，每个用例的每一步元素定位之前，先读一下excel是有多麻烦。

　　2、这样好维护！谁告诉你的？你能记清excel第125行第2列对应的哪个页面上的哪个元素的定位？因某个页面上多加一个元素，我又在excel第32行下面插入一行元素定位，从33行往的所有元素的行号都变了，你那些读取excel中元素定位的操作都要跟着改吧！？

　　那你给说道说道，什么情况下需要excel管理用例，在我看还真没想到什么场景必须excel管理。不过，有什么条件可以参考：

　　1、这个数据有点多，比如这个输入框限制500字，我输入501个字提交看是否会提示错误。这500字写代码里有点多了。可以建立个文件读取。

　　2、这个数据经常改动，比如自动化测试用例通过个哪个环境执行，哪款浏览器运行，运行哪个项目下的用例。这个配置是需要我经常改的，可以创建一个专门的配置文件来保存。

　　3、这个数据作用于多个地方，比如系统的登录用户名密码，可能很多条测试用例都用一个账号登录。那我不可能每个用例，都写一遍这个账号，假如想统一更换帐号还得每个用例都改一下，这个时候也可以对这个数据独立保存。

　　你看！你看！元素的定位也挺符合你的第2、3条的，经常变动，一个元素定位可能被多个用例用到。那你为什么不研究一个Page Ojbect 设计模式？专门解决元素变化问题的。

web自动化要用多大的数据？

 　　对了，前两天有人给我留言：你这个web自动化书吧挺好的（书在本博客面右上！），就是没有关于数据库的操作！亲，你不是在做web自动化，应该是在做性能自动化吧！？那我要碰到很多数据的情况下怎么存？这一定是你意淫出来的情况。那我在页面上插入了一条数据，我需要查询数据库表检查对不对呀？

　　你确定你是在做web自动化么？web自动化是基于UI的自动化测试，是模拟用户操作的。你家用户这么高端，在你们的网站上买了个商品，还要跑到你家数据库里去查一查，刚才买的商品有没有写到xxx表里？

　　那自动化怎么知道商品对没有没插入到xxx表？那我反问一下用户怎么知道自己有没有购买成功，一定是他在“已购买”的商品栏里看到自己的商品。你不会获取这信息做断言啊？

　　说往数据库里存数据那位，你家用户在使用你们的系统的时候，自己要先准备几千条数呀？你说用户用excel存数据我信，你说用户上传excel数据文件我信，你说用户弄个数据库存几千数据，我不信！

这样的系统不太适合web自动化! 

 　　什么样的系统不太适合web自动化？以查询报表为主的系统，就是以插入，查询，删除，编辑为主的xx管理系统。如查你还不清楚的话，下图仅供参考。

　　我此言一出，估计你要灰心了！我家系统就是这种的，添加，查询，编辑。这种系统一般定位起来也比较麻烦，要写又臭又长的xpath。（估计你现在已经和我产生共鸣了。）

　　这种系统的核心就是数据，其后台实现就是各种查询接口。功能可用就好，一般这系统不讲究用户体验之类的。关键是数据得正确。尤其是针对金融领域相关的系统，那少算一个数、一个零、一个小数点，事可就大了。但在我看来做web自动化的实际意义并不大。或者这类系统要自动化的并不是系统最重要的部分。当然，我并不是说系统的功能不重要。

　　最主要的是这种系统不太好断言结果，你想，你的数据是查询出来的，今天查询出来“张三”在第一页，后面这个查询数据增加，“张三”跑后第五页了，再后来跑到第170页，你说怎么用固定的信息断言？ 没有断言，你怎么知道查询的结果对不对？

　　我可以查数据库呀，我前面说了，查数据库的就不是web自动化了。

　　其实，这类系统非常适合做接口自动化测试。关于，接口自动化的学习和需要掌握的技能，我会放到下一篇介绍（这一篇要还没啥阅读量，我就不写了^_^，毕竟这些吐槽也挺无聊的）。

　　有同学说了，那我学自动化还有什么用？我家系统就是这种的。

　　1、首先，我并不是说这类系统不能自动化，拿来练习web自动化还是可以的嘛。再说了，web自动化也是测试人员必备技能之一嘛，以后为你跳槽加薪好处也是大大地嘛。

　　2、你学习的技能并没有白费：

　　2.1、编程能力提升了吧！那编程语言能干的事情可以多了去了。

　　2.2、单元测试框架学会了吧！这框架还可以用来写单元测试和接口测试呢！

　　2.3、自动化测试的思想学到了吧！移动自动化也是这么玩的，只是把selenium换成appium而已。

　　那我就好奇了，虫师，你家系统是什么样的？怎么就适合做web自动化了？知道你会这么想(问)，我以前写过一个私有云的自动化（类似百度云盘），去年写过一个bbs社区的自动化，当然也都不算太成功（羞射...）。碰到更多的就是如上图的，所以，从去年底在开发的帮助下改去写接口自动化了。

关于自动化测试的误区