[自动化测试框架.pptVIP

自动化测试框架 WuXi_ETP 目录 软件测试框架介绍 自动化测试框架指南 测试驱动 测试脚本开发 测试用例 选择适合自动化测试的用例 自动化测试框架的发展 软件测试框架介绍 什么是框架framework ? 整个或部分系统的可重用设计，表现为一组抽象构件以及构件实例间交互的方法； 可被开发者定制的应用骨架。 前者是从应用方面、而后者是从目的方面给出的定义。测试框架也是如此，测试框架出现的最终目的是花少量的资源来完成尽可能多的测试任务，所以测试框架的建立以及框架的重用性方面是最值得测试人员深入探究的地方。 软件测试框架介绍 什么是测试框架? 测试框架是一组自动化测试的规范、测试脚本的基础代码，以及测试思想、惯例的集合。 测试框架的好处在于： 减少冗余代码、提高代码生产率、提高代码重用性和可维护性。提高开发速度，提升测试代码的执行效率； 提高软件代码质量，同时引入重构概念，让代码更干净和富有弹性； 提升系统的可信赖度，作为回归测试的一种实现方法支持修复后“再测试”，确保代码的正确性。 自动化测试框架介绍 自动化测试框架一般可以分为上下两个层次，上层是管理整个自动化测试的开发，执行以及维护，在比较庞大的项目中，它体现重要的作用，它可以管理整个自动测试，包括自动化测试用例执行的次序、测试脚本的维护、以及集中管理测试用例、测试报告和测试任务等。下层主要是测试脚本的开发，充分的使用相关的测试工具，构建测试驱动，并完成测试业务逻辑。 测试驱动_A 测试驱动是一个自动化测试框架的核心，其决定整个自动化脚本设计。当前比较流行的测试驱动有数据驱动和关键字驱动。 数据驱动 测试驱动引擎从数据源获取测试数据，然后将数据以参数的形式传递给测试脚本，最后通过执行测试脚本，验证测试结果，并将测试结果输出。一般数据源与测试结果存储在数据库、Excel文件、CSV文件等。数据驱动主要优点是：测试脚本与测试数据的分离，当应用功能变更时，只需要修改该功能部分的脚本；执行测试用例的人员不需要了解测试脚本的实现，只关注测试数据表与测试报告表。而且测试脚本的执行是离散的，即非线性的，测试人员可以有选择的执行测试用例。 测试驱动_B 关键字驱动 关键字驱动的自动化测试框架是在数据驱动的基础上进行改进，数据源里包含的不只是数据，还有关键字，一个测试用例由一个或若干个关键字组成。每个关键字对应个不同的业务逻辑，例如，登录、注销等。数据表通过关键字，查找映射表，执行相关的脚本。 驱动引擎是对数据表的数据进行分析，根据不同的测试数据或关键字调用相应测试脚本。驱动引擎还需完成一些测试环境初始化、全局参数设置、测试用例是否执行的判断，以及测试报告的处理等 测试脚本开发_A 脚本划分 为了方便以后脚本的维护问题，必须对脚本进行有效的分层，同时，提高了脚本的复用率。 公共类库 公共类库包括所有模块都可能用户的操作方法，其抽象了不同模块同性，比如操作excel表的方法、读写测试报告、驱动引擎等。 模块特定类库 在模块内部将可以为该模块共享使用的方法抽象出来，作为一个公共类。它可以是一个单的逻辑操作，也比较独立。比如客户端登录操作、控制台登录操作、控制台更新操作等。 测试用例脚本 测试用例脚在最上层，它根据测试点进行设计，面向具体的应用。它可直接调用公共类库或模块特定类库的方法，即调单个逻辑操作。它是单个或多个逻辑操作的集合，即一个测试用户脚本。 测试脚本开发_B 脚本规范 测试脚本的开发也要遵循编程的规则与标准，应该统一规划，所有开发脚本的人员按照统一的规定进行编码。除了编程本身规范，还考虑测试用例与库函数名的命名。 例如，项目M4.1客户端登录测试用例可命名为：TC_M4.1_client_login；读取excel表的函数可命名为：read_excel。 测试用例 测试用例粒度 测试用例的粒度决定了用例模型级的复杂度，也决定了每一个用例内部的复杂度。应该根据每个系统的具体情况来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。用例不能太大，这样一旦出执行测试用例出错，不利于定位问题；但也不能太细化，太小则不方便执行。 测试用例与测试套件 一个大型的项目有许功能模块，必然会产生大量的测试用例，怎样才能有效的管理这些测试用例呢？这就需要创建测试套件，通过测试套件将测试某一个模块或功能点的测试用例集合起来，方便运行与管理。例如，只验证“用户管理”模块功能，则只需要执行“用户管理”模块套件即可。 选择适合自动化测试的用例 通常适合自动化测试的用例有： 产品型项目 产品型的项目，新版本是在旧版本的基础上进行改进，功能变不大的项目，但项目的新老功能都必须重复的测试。 回归测试 回归测试