自动化测试框架不难，难的是细节（总结片）

 

1、自动化测试

一、自动化测试脚本大体可划分为：

　　|、线性脚本：经过录制直接产生的线性可执行的脚本

　　|、结构化脚本：具备顺序、循环、分支等结构的脚本

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

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

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

　　|、混合型脚本：以上任意两种及以上

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

 

二、自动化测试执行：

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

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

 

 

三、自动化测试的难点（界面的变更性和脚本的维护性）：

①公共自动化用例的维护

②公共UI方法维护

③稳定性和效率提高：

　　|、异常处理封装

　　|、分层测试

　　|、创建共享对象库/测试库

　　|、第三方插件引入

　　|、GUI业务流程解耦拆分、尽可能避免太长的端到端UI测试(例如web到移动端的业务流测试)

　　|、引入mock/接口测试代替部分环节的测试，从而衔接到要执行自动化测试，提升自动化测试稳定和效率

　　|、web处理一些不可识别第三方控件。尽量采用js来处理，更显示稳定和高效

　　|、uiautomator监听处理android系统不肯定的系统级别弹窗

④自动化测试实施项目选取策略：

　　|、重复性高且有必要的测试流程

　　|、项目周期长，系统版本不断，而且需求不会频繁变动项目

⑤自动化测试框架包括：

　　|、测试用例分布式执行：seleniumGrid

　　|、脚本模块化：分层

　　|、数据驱动:mysql存储数据，testng的数据提供者

　　|、日志分析：本地log4用例执行信息

　　|、错误截图：监听截图

　　|、报表回收：测试数据存储mysql数据库等

　　|、共享对象库/公共函数库：UI元素信息管理/UI元素操做方法维护

　　|、环境配置：chromedriver/adb/IEdrver/Firefoxdriver

　　|、用例统一设计模式：基类(测试用例beforeclass/afterclass)，多用例集中于一个需求/模块里

　　|、异常处理：testngListenter监听，UIwater处理系统级弹窗

　　|、接口和mock结合介入

　　|、第三方工具引入：adb/shell/redis

　　|、用例执行方式(分布式测试seleniumGrid、device多并发测试)

自动化广义总结：
一、自动化测试工做不复杂但也不简单，其须要自动化测试人员既懂业务也懂技术。
二、对自动化测试见解太低以及对自动化测试要求过高，都是由于其盲目性，一个懂产品技术和自动化测试技术的工程师，是很快能定位其自动化测试需求和开展的方法。
三、每一个公司有每一个公司本身的特色，调研和需求分析很重要。
四、自动化测试框架不难，难的是细节。
五、自动化平台很重要，没有一个平台，不方便推广，其自动化测试只能流于形式。

 补充：

自动化测试框架找对象：

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

关于动态查找，我举个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方法，调用这些接口或者方法便可实现动态查找。

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

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