浅谈对自动化测试的理解

1. 自动化主要包含三个层面的自动化：单元测试自动化，接口测试自动化和web测试自动化。

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

B.  接口自动化，根据接口文档，编写测试用例，根据测试用例向接口提交请求数据，根据返回结果的数据去判断状态码，响应的msg，去判断接口测试是否通过。所以，接口测试关注的是数据。只要数据正确了，功能就能做成大半，剩下的无非是如何把这些数据展示在页面上。

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

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

 

2. 自动化测试的种类

第一种：工具自动化

     我们在做功能测试阶段，有些重复的手工测试，我们可以用工具来代替。常用的工具有jmeter或者QTP或者是loadrunner，利用这些脚本把用户的操作录制下来，转化成脚本。对脚本进行优化以及参数化后，就可以用来做自动化了。

第二种：代码+工具自动化

     这种自动化就是代码与工具的结合，基本上不需要你太懂代码，略懂代码就OK了，这里推荐的工具依然是：

     Jmeter、loadrunner和QTP，如果想完成高一阶的自动化测试，就可以考虑代码与工具想结合，让你的自动化测试不受制于工具，加入代码更加灵活的运用自动化。

第三种：代码自动化

     不管是单元自动化还是接口自动化或者说UI层面的自动化，都可以利用代码来实现。那么这个大家可能会关心的是哪种语言会比较好，给大家推荐Python·这门语言，入门快语法简单：但是在学习的这个过程中只有两件事情大家要做好：

专一：学一门爱一门，学精了再去学习别的语言；

3. 适合做自动化的项目

    做自动化测试是需要一定的人力物力以及时间成本的，所以在我们决定去做自动化框架写自动化代码的时候，我们非常有必要去考虑一下，什么样的项目适合自动化测试，以免浪费了人力物力然后又收效甚微。

    一般具有如下几个特征的项目，都合适做自动化测试：

任务测试明确，不会频繁变动

 

每日构建后的测试验证

 

比较繁琐的回归测试

 

软件系统界面稳定，变动少

 

需要在多平台上运行相同的测试用例、组合遍历型的测试，大量的重复任务

 

软件维护周期长且项目进度压力不大

 

被测软件新系统开发较为规范，能够保证系统的可测试性

 

具备大量的自动化测试平台

 

测试人员具备一定的编程能力

 

     当然，并非以上9条都具备的情况下才能展开自动化测试工作，一般满足以下三个条件就可以对项目展开自动化测试。

 

◎需求变动不频繁

   自动化测试脚本变化的大小与频率决定了自动化测试的维护成本。如果需求变动过于频繁，那么测试人员就需要根据变动的需求来不断地更新自动化用例，从而适应新的功能。而脚本的维护本身就是一个开发代码的过程，需要扩展、修改、调试，有时还需要对架构做出调整。如果所花费的维护成本高于利用其节省的测试成本，那么自动化测试就失去了他的价值与意义。一种折中的做法就是先对系统中相对稳定的模块与功能进行自动化测试，变动较大的地方进行手工测试。

 

◎项目周期较长

   由于自动化测试需求的确定、自动化框架的设计、脚本的开发与调试都需要一定的时间，而这个过程本身就是一个软件的开发过程，如果项目周期比较紧张，没有足够的时间去支持这一一个过程的话，就不要进行自动化测试。

 

◎自动化脚本可以重复使用

  自动化测试脚本的重复使用要从三个方面来考虑：

 

所测试的项目之间是否存在有很大的差异性（如C/S系统架构与B/S系统架构的差异）

 

所选择的测试技术和工具是否适应这种差异

 

测试人员是否有能力设计开发出适应这种差异的自动化测试框架

 

no.4

自动化工具以及开发语言的选择

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

  

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

     桌面程序工具有：QTP、AutoRubber

     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架构，所以QTP的使用进程也是在逐步降低，并没有了当初的火爆现象。

 

     如果，被测产品是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

 

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

 

 

   作为小白入门，我们推荐Python+selenium来做B/S架构的自动化测试，语言易懂入门简单。

 

no.5

神秘的单元测试框架

    单元测试是一个贯穿于整个开发过程的连续过程，单元测试目标一般是某个类或者是函数，单元测试最基本的原理就是比较预期结果是否与实际执行结果相同，如果相同则测试成功，否则测试失败。

 

    上文我们举例说，我们选择Python+selenium来做为自动化入门的推荐，为了更好地理解Python unittest这一单元测试框架的作用，我们来举例进行说明：

下面我们写一个比较简单的函数，加法函数：

Class  Add：     Def  add（self，a，b）：            C= a+b           Return  C

单元测试代码：

Import  unittest  class  TestAdd（unittest.TestCase）：         def setUp（self）：         pass         def  test_add（self）：         a=Add（）.add（4,5）        self.assertEqual（a,9“结果错误，请检查输入的数据或者是代码！”）   suite=unittest.TestSuite（） suite.addTest（TestAdd(“test_add”)）   runner=unittest.TextTestRunner（） runner.run（suite）

单元测试结果：

D：\python_33\python.exe “C:\Program Files（x86）\JetBrains\PyCharm Communi ty Edition 3.4 4\helpers\pycharm\utrunner.py” D:\python_33\code\python_2017\test.py truTesting started at 23:15..   Ran 1 test in 0.00s   Ok   Process Finished with exit code 0

 

怎么样，看起来是不是很神奇，这样就可以轻松帮你解决一个类的单元测试。具体要怎么实现，怎么测试，还需要我们进一步学习。