自动化测试总结

最近要在新入职的公司准备一份自动化测试的培训，这是我在得知要作自动化测试培训之后，随手画了个图，压压惊：

这是我能想到的关于自动化测试的一些要点，而后根据一篇我三年前写的关于自动化测试的随笔更新了一下，固然遗憾的是到目前为止，我接触的成功的敏捷开发项目还不多，虽然敏捷近些年一直很火。关于敏捷自动化测试这一块也只有一次不太成功的经验，因此本文中我回避了这一块：

1.什么是自动化测试

以程序测试程序，以代码代替思惟，以脚本的运行代替手工测试。自动化的测试涵盖了：功能（黑盒）自动化测试，功能（白盒）自动化测试，性能测试，压力测试，GUI（Graphical User Interface）测试，安全性测试等。

【Updated on 7/28/2015】

关于什么是自动化，查阅了一些资料，并无一份权威规范的解释，如下摘自维基百科：

In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes.Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or add additional testing that would be difficult to perform manually.

首先，test automation跟 automation test是有区别的，测试自动化涵盖的面更普遍。本文阐述的是自动化测试，在这里暂且混淆这两个概念。

这一段英文不难，自行翻译。我眼里看到的几个要点：1.须要工具；2.工具控制流程，比较预期输出与实际输出；3.重复性高且有必要的测试流程能够自动化；4.用于手工测试难以达成的领域

说说我本身的理解：

自动化测试是测试思想的一个延伸，为测试工程师提供了一个“触须”，其行为能够当作一个工具，可是本质上自动化测试仍是一种思想。

顺便提一句，狭义上的自动化测试指的就是基于GUI的自动化测试，而单元测试跟API测试，你有想过怎么用手工不借助任何工具去作吗？因此它们天生就属于测试自动化的范畴。

 

2.自动化测试的优点

回归测试更方即可靠 ；可运行更多，更繁琐的测试，且快速高效；可执行一些手工测试执行至关困难或者作不到的测试，如大量的用户并发；更好的利用资源，具备一致性和可重复性的特色，自动化测试脚本彻底可复用；提高了软件的可信度；多环境下测试等。

【Updated on 7/28/2015】

自动化最实在的优点在于——工做好找：有一个测试工程师（并非本人）发现一个有趣的现象，她申请过的几乎全部测试职位，在招聘时都须要自动化测试经验。但当她开始工做后，就发现这些公司都试图作自动化测试，可是结果大多不怎么地。不过，尽管她参与的都是一些杯具的项目，不过她总能把这些杯具包装成洗具以应对下一次面试。

因此呢，既然自动化测试有那么多优点，为何还有那么多项目作失败了呢？

我我的有个推论：自动化测试的优点都是自动化测试成功完成获得的结论，而自动化测试的劣势才是自动化项目立项的基础。

还有个优点：自动化测试能够将产品的知识固化到脚本中，以下降测试人员流动对项目形成的影响。可是这个优点的前提是，这些脚本易于维护，这就须要一些必要的文档，这又是另外一个议题了。

 

3.自动化测试没法作到的事以及劣势

永远不可能彻底替代手工测试，自动化测试没法作到手工测试的覆盖率，不是每一个测试用例都适合作成自动化，如建议一个页面的布局是否正确、安装测试、文档测试、兼容性测试、恢复性测试。

手工测试发现的缺陷远比自动化多。自动化测试是几乎没法发现新缺陷的，最大的用途是用来回归，确保曾经的bug没有在新的版本上从新出现。

自动化测试工具是死的，它不具有任何想象力。自动化测试的好坏，彻底取决于测试工程师。

成本投入高，风险大。对测试人员的技术要求高，对测试工具一样有要求。

【Updated on 7/28/2015】

关于成本，包括了资金预算，人力资源，人员培训，硬件资源等。下图显示了自动化测试的投入成本与时间的关系，很显然，前面多数时间，成本是很高的。

基于以上劣势，因此虽然“贵为”自动化测试工程师，我有一大半的时间在劝老板，“亲，能不能不作自动化”。这真是个悲伤的故事。

 

4.合适引入自动化

项目周期长，系统版本不断，而且需求不会频繁变动，此时是适合引入自动化测试的。

系统的测试对象基本能够正常识别，以及对没法识别的控件可否提供一个解决方案。

系统中不存在大量的不可识别第三方控件。

须要反复测试，如可靠性测试、回归测试等须要进行上千次的系统测试。

 

5.不适合自动化

项目周期短，需求频繁变动。即便是周期长的项目，若是常常需求变动，也不适合作自动化。

软件版本尚未稳定的状况下，主功能或大量功能有被从新更改的可能话，也不适合作自动化。

没有明确的项目测试自动化计划，措施和管理。

多数对象没法识别，以及脚本维护频繁与艰难，两者有其一，自动化一定失败。

 

6.自动化测试的流程【Updated on 7/28/2015】

合理的自动化切入点：一般，项目只有经历了完整的系统测试以后才算具有了基本的引入测试自动化的条件。

【Updated on 7/28/2015】

我的观点：不管什么测试，越早介入则越有利于下降成本，下降风险。而随着新型的开发模式兴起，自动化测试也具有了尽早介入的条件。好比敏捷开发中，某核心模块核心功能完成后，则可针对该模块的该功能开始实施自动化测试。

 

测试自动化分析：

（1）可行性分析

（2）抽样demo分析,demo通常选取冒烟测试用例，检查脚本是否可以成功运行经过，已设计的测试点是否所有执行

（3）测试需求分析，分析哪些功能点准备进行自动化

【Updated on 7/28/2015】

（1）可行性分析是自动化测试最重要的部分之一。可行性分析是自动化测试最重要的部分之一。可行性分析是自动化测试最重要的部分之一。重要的话要讲三遍。

　　  关于可行性分析，请参考2,3,4,5点；你的一个错误决定（自动化测试项目立项），极可能给好几我的带来全职工做机会，从这个角度来说，还能促进鸡的屁==

（2）抽烟Demo，主要仍是用来验证你的工具是否能用

（3）自动化测试不是100%测试，不可能达到手工测试的覆盖率，要筛选功能点进行自动化测试

 

测试计划定制：自动化测试计划越全面，后期越能循规蹈矩的去实施，自动化测试的成功率越高

计划赶不上变化，有时候太全面了或许也不是什么好事。

自动化测试设计阶段：主要分为自动化测试框架和自动化测试用例。

（1）自动化测试框架的设计，开发与搭建：应能保证测试的分布执行，脚本模块化，数据驱动，日志分析，错误截图，报表回收，共享对象库，公共函数库，环境配置，统一设计模式，异常处理，场景恢复的一个无人值守的，针对每一个独立项目的测试框架

【Updated on 7/29/2015】

关于为何须要自动化测试框架，我有另一篇文章详细说明了，这里再也不复述

http://www.cnblogs.com/ryansunyu/p/4080985.html

而后我顺便说说找对象的事，是自动化测试框架找对象，不是我找对象：）

一般每种框架都应该支持动态跟静态两种找对象的方式，静态找就涉及到对象库，包括对象库的读、写、合并、维护等一系列问题，这些均可以交给框架作；

关于动态查找，我举个RFT的例子，大家意会一下：

Two types of find API in Rational Functional Tester:

• find(Subitem Properties).
• find(Subitem Properties, Boolean mappableOnly).

       Subitems can be either atChild() or atDescendant() or atList().

• atChild: One or more properties that must be matched against the direct child of the starting TestObject.
• atDescendant: One or more properties that can be matched against any child of the starting TestObject
• atList: A sequential list of properties to match against. Valid subitems for atList are atChild, atDescendant, and atProperty.
• mappableOnly: Arguments that limit the search. If it is set to true, the search for children will be limited to those test objects that are mappable, otherwise non-mappable test objects are also searched.

 

 

首先测试工具会提供动态查找的接口或者方法，RFT里面提供的是find方法，调用这些接口或者方法便可实现动态查找。

动态查找的好处是能够采用“相对路径”来定位对象，而相对的，对象库则采用的是“绝对路径”。若是一旦对象的一些属性改变，静态查找的方式可能会找不到对象，固然了，如今的自动化测试愈来愈智能，已经能够作到选取匹配度最高的对象返回。动态查找还有个好处是它找到的对象是“代码”，你能够进一步在框架里去对这些对象进行处理，而对象库里的每个对象都是一个独立的对象，你可使用它们，可是很难改变它们。

一般如今的自动化测试框架都是采用动静结合的方式，即两种找对象的方式都会兼顾，由于通常来讲，静态查找的方式速度更快，效率更高。可是静态查找带来的问题也是显著的，主要集中在对象的维护管理以及合并上，如何共享对象，避免重复加对象等。此时，规范对象命名就显得很重要了。以往我作的自动化测试项目中，这些都是坑。

 

（2）自动化测试用例设计三部曲：手工测试用例是从无到有，而后自动化测试用例是根据手工测试用例来写的。首先，筛选手工测试用例。而后转换手工测试用例，最后新增&补充自动化测试用例。

为何不能用手工测试用例彻底替代自动化测试用例？

自动化测试用例的范围每每是核心业务流程或者重复执行率高的，自动化测试的覆盖率不能达到手工测试的覆盖率。自动化测试的用例选择通常以正向为主，而反向的状况却有不少，可是并非全部反向状况自动化测试都会涵盖，而是有筛选的选取一部分。也并非全部的手工测试用例均可以用来作自动化的，如页面布局的检查。手工测试能够不须要回原点，可是自动化测试每每是必须的。自动化测试用例与手工测试用例不一样，不须要每一个步骤都写预期结果。

【Updated on 7/29/2015】

一般作自动化测试的时候我都会写一个叫作shake-down test的测试用例，这个用例会把系统里全部完成了的表单都过一遍，只是作一个Navigate的操做，以确保某个页面是否可用。

每次作回归测试前，能够先跑一遍shake-down test，很快能够肯定哪些功能是accessible，至关于作了一整个系统的一个冒烟测试。

测试脚本设计与开发：

测试脚本大体可划分为：

（1）线性脚本：经过录制直接产生的线性可执行的脚本

（2）结构化脚本：具备顺序，循环，分支等结构的脚本

（3）可共享脚本：能够被多个测试用例使用，被其余脚本调用的脚本（即模块化的脚本）

（4）数据驱动脚本：测试数据跟业务流程控制分离的脚本，经过读入数据文件来驱动流程进行的脚本

（5）关键字驱动脚本：脚本，数据，业务分离，数据和关键字在不一样的数据表中，经过关键字来驱动测试业务逻辑。关键字驱动的特色是，它更像是描述一个测试用例在作什么，而不是如何作。

（6）混合型脚本：以上任意两种及以上

（7）敏捷自动化测试脚本/框架：这一块等我有了成功经验再补充=。=

自动化测试执行：

（1）无人值守的测试：环境搭建，部署与配置；自动化测试用例与测试脚本相互绑定；自动化测试用例执行顺序排列与组合

（2）异常处理与场景恢复

提交自动化测试产物：大体须要提交执行状况，测试结果，分析报表，测试报告，质量状况等。

测试脚本维护：严格来说，每一个阶段都在作测试脚本维护。一个不值得维护的自动化测试项目是不值得立项的。（一般这里有不少全职工做机会~LOL）