自动化测试框架及其测试思路

  • 格式:docx
  • 大小:10.42 KB
  • 文档页数:5

下载文档原格式

  / 5
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

自动化测试框架及其测试思路

1.1自动化测试的优点:

实现快速的回归测试,加速测试进度从而加快产品发布进度

1.2为什么要做自动化测试框架

通过以往的尝试,发现真正实现自动化测试,并不是掌握了某个自动化工具, 掌握了脚本的编写及时就能够达成,面对复杂的 ERP 系统,简单的录制/回放并不 能达到自动化测试的要求,完全通过编写脚本的方式,工作量巨大且可维护性极 差、不能复用。实现自动化就是为了能够提升测试效率,不具备可维护性、复用性 差将成为导致自动化测试失败的最致命因素,付出巨大代价但起到的效果甚微。

基于以上因素并结合行业发展思路,在正式实施自动化之前,必须搭建一套适 合的自动化测试框架,将脚本能够有效的组织、连贯应用起来,提高测试脚本的可 维护性和可读性。

1.3希望达成的目标

搭建符合以下要求的自动化测试框架,使得未来自动化测试正式实施时能够有 序、高效的展开:

〃高复用性

〃高可维护性

// 提高测试效率和降低测试成本

// // 更多的测试,提高测试覆盖率

// 保证一致性

//

提报测试的可靠性,避免人为因素

〃稳定性

〃快速编与脚本

〃自动的执行

〃正确输出结果

〃能够不断提升自动化测试比例

1.4实现思路

〃分层设计:业务流程、功能点、操作组件

我们在进行测试时,首先会验证各个页面、各个字段的正确性,到验证功能点的正确性,在组合各个功能点进行业务逻辑、业务流程的验证,最终确保系统慢走业务员需求。

对于自动化脚本,采用分层的思想,先实现最底层的操作组件,通过调用操作组件、及业务逻辑实现对功能点的验证,在通过调用业务逻辑组合功能点实现对业务流程的验证。不同的业务流程,对于底层的操作组件、中间层的功能点函数是完全可以复用的,只是调用的业务逻辑的差异,或

者是测试数据的差异性。

尽可能做到各个脚本之间具备独立性,不相互依赖,便于进行各种基本场景的组合运行。

如销售系统中的选择房间操作,在做预约、小订、订购等操作时,都需要用到选择房产,因此可与将选择房产作为一个公共的操作组件,详细描述选择的操作步骤,在测试新增预约、新增小订、姓曾订购等功能点时都需要调用到选择房产的操作组件,只是业务的校验逻辑与所选择的数据不一致。

再看业务流程,新增一个小订单后可以作废,也可以由小订转认购,业务流程就有两个:新增小订单一作废订单,新增小订单一转认购,这两个业务流程中增小订单”这个功能点是一致的,可以通过调用不同的用例数据组合成不同的业务员流程。

〃脚本分离设计:对象、操作、测试数据、业务逻辑相互剥离、灵活调用

对某个功能进行自动化测试,实际上就是对这个功能设计的对象进行操作,输入测试数据来验证其结果的正确性,复杂的验证点需要编写业务逻辑。如果全部用脚本的方式编写,针对每一条测试数据就需要编写一份脚本,脚本量相当巨大,同时任何改动(程序、测试用例、GUI对象)都需要调整大量的脚本。

为了达到科维护性、了复用性,将对象、操作、测试数据、业务逻辑剥离、分开管理,通过调用关系去组合实现不同的测试用例。

对象资源库

测试数据资源库

操作组件(描述操作步骤)

分离后,如果要增加测试用例,只需要维护测试数据,如果程序修改,增加了对象,那么只需要维护对象库,操作组件,增加对这个对象的操作。

〃封装基础函数、基本的业务逻辑、验证点

通过对基本业务逻辑、验证点的封装、调用,实现快速的脚本开发

如果一个数据保存的功能,每一条数据在做了增、删、改的操作后,都需要验证保存至后台数据库的数据正确性,通过与其结果与数据库实际产生的数据集进行比较验证,在获取数据库实际产生的数据集的方式是通过的,只是不同的功能所要验证的数据表、字段及Where条件不一致,获取数据集的方式就可以封装一个基

础函数,传入不同的SQL语句作为参数即可。同时与其结果与实际结果集的比较也可以封装为基础函数。

再如,系统页面中的某些操作或条件下,部分字段是只读不允许编辑的,或者是隐藏不显示的,编写脚本时需要对每一个对象写一条语句验证其只读和隐藏属性的正确性,如果将只读和隐藏属性的验证进行封装,针对每一个页面进行验证,那么只需要传入这个页面只读或隐藏的对象名,调用封装的函数执行验证。可以大大减少脚本量,也更便于维护。

〃有效的执行体系

批量、定制执行、自动运行

自动化测试真正达到提升测试效率,需要实现无人值守情况下的批量自动执行,并且可以定制执行。

异常处理机制

脚本执行过程中,因程序错误或环境问题、脚本自身问题经常会出现非预期的

错误:如预料外的弹出窗口、发现错误的数据、未找到对象、输入文件打不开或不能读等,有些情况下当前用例出错,并不影响后续用例的执行,需要支持异常处理机制,终止执行或者终止当前用例,继续后续用例的执行,亦或者跳转当前步骤,继续执行后续操作,并输出当前的错误报告。

业务数据还原初始状态

自动化测试需要循环执行,执行完成后,需要恢复初始化状态(主要是业务数据),以使得程序重新提交版本后能够循环执行,不断的对新版本进行回归验证。

版本管理

随着带验证版本的不一致,自动化测试脚本也会不断的更新、维护、同样需要进行版本管理。

〃结果体系

针对每条用例,输出用例执行结果

针对每个检查点,输出详细的检查点执行结果

输出执行日志

〃结构化管理

对象、操作组件、基础函数、测试数据、功能点脚本、业务流程组合、如此多的层级、调用关系、不惜进行结构化管理,采用高度组织化的目录结构、分级管理,方便进行正确及快速的调用,方便能够快速定位、查找问题。