自动化测试总结（三）

测试计划定制：

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

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

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

（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）

（到这里了，就到这里）