《关键字驱动脚本》PPT课件

ROBOT自动化测试关键字脚本具体实现阿楠kartjswsx001 交流进程1 简单介绍ROBOT的具体使用 2 SQABasic语言的命令种类简单介绍 3 各种类型测试脚本的优缺点分析对比 4 关键字驱动脚本详细说明 5 扩展网上具有代表性的计算器测试脚本以说明关键字驱动脚本 6 如何实现健壮脚本 7 实际举例以说明健壮脚本的注意点及解决方案 8 自由讨论 范围限定自动化测试种类繁多 覆盖面广 针对测试的标识 设计 建立 执行以及结果比较等各方面全部有相关自动化措施 支持工具以及解决方案 范围限定 续 本PPT仅针对执行和结果比较部分的自动化测试以及使用支持工具Robot的具体实现过程 粗略探讨Robot的脚本技术对于提升整个测试自动化体系属性的作用 以及实施自动化过程中需要解决的一些具体问题的解决办法 其实这些方法不是唯一的 也并非在每种情形下都是最佳选择 本人的初衷也是抛砖引玉 望各位斧正 不用注意方式方法 意义软件测试是保证质量的核心问题 自动化测试是最经济的选择 自动化测试定义自动化测试 编写软件去测试其它软件 自动化测试可以被理解为使用一个商业通用测试自动化工具编写一个软件来测试其它软件 编写驱动被测试应用程序的测试脚本以执行键盘 鼠标动作和后台进程并验证应用程序响应和行为 自动化测试的意义自动化测试可以减少或消除一些手工测试中的重复和烦琐 节约测试所必需的时间和提高测试的一致性和可重复性 自动化测试可以提高产品质量并尽可能在软件生命周期的早期发现缺陷 并非任何测试自动化都可以起到预期效果 只有好的自动化测试体系才能扬长避短 达到建立自动化测试体系的初衷 在质量保障方面有所作为 否则测试自动化可能会由于其建立和维护等方面的负担造成延误工期 成本浪费 甚至最终被完全放弃 自动化测试体系的属性那么如何评价一个测试或测试自动化体系是否优越呢 为此 我们应该关注自动化测试体系的以下七个方面的属性 1 可维护性指是否可以很容易使测试更新跟上软件升级的步伐 软件会变更或升级是注定的事实 防止变更或升级造成自动化测试的维护工作量过大是很重要的 否则整个测试自动化工作将可能被全面否决 甚至束之高阁 2 高效性效率是与成本紧密联系的 自动化测试的一个重要目标就是更经济地运行测试 所以应该在测试和测试自动化的设计阶段全面审视各方面因素 在科学合理的测试流程基础上利用优秀的自动化策略将自动化测试与手工测试有机结合 才能实现效率最大化 3 可靠性指测试体制是否能给出精确而且可重现的结果 4 兼容性指是否允许测试用例为不同的测试目标而以不同的方式组合 5 可用性指定制或更改测试用例是否容易 测试人员或用户掌握和理解其使用方法是否容易 6 健壮性指是否可以处理意外情况而不退出或终止 并尽力给出正确有用的信息 7 可移植性指在不同环境中运行测试的能力 我们应该根据使用自动化测试体系的实际目标 综合考虑这七个方面的具体属性 有针对性地提高自己关注的属性 以实施符合实际需要的自动化测试体系 为了实现高效的自动化测试体系 必须源于好的测试软件 这些测试软件是由经验丰富的测试人员精心设计的 在此基础上再应用自动化技术实现自动化测试可以获得建立及维护的合理开销 应该根据需要和能力决定是自主开发还是选购适合的测试自动化工具 以下结合Robot讲述如何利用其脚本技术更好地进行测试自动化 提升自动化测试体系的属性 简单介绍ROBOT的具体使用RationalRobot 创建和维护测试脚本的业界领先工具 RationalRobot可以对在各种独立开发环境 IDE 中开发的应用程序 创建 修改并执行功能测试 分布式功能测试 回归测试以及整合测试 它还可以记录并回放能识别业务应用程序对象的测试脚本 除此之外 使用RationalRobot还可以快速有效地跟踪 报告与质量保证测试相关的所有信息 并将这些信息绘制成图表 RationalRobot可开发三种测试脚本 用于功能测试的GUI脚本 用于性能测试的VU以及VB脚本 RationalRobot作用执行完整的功能测试 记录和回放遍历应用程序的脚本 以及测试在查证点 verificationpoints 处的对象状态 执行完整的性能测试 Robot和TestManager协作可以记录和回放脚本 这些脚本有助于你断定多客户系统在不同负载情况下是否能够按照用户定义标准运行 Robot的基于对象记录技术使你能够通过简单的运行和使用被测试程序来快速产生脚本 Robot使用基于对象记录技术 记录对象内部名称 而非屏幕坐标 若对象改变位置或者窗口文本发生变化 Robot仍然可以找到对象并回放 Robot的基于对象记录技术使你能够测试被测试应用程序的任何对象 包括对象的属性和数据 你可以测试标准Windows对象和特定IDE对象 而不管其在界面上是否可见 SQABasic语言的命令种类简单介绍SQABasic是RationalRobot功能测试的脚本语言 包含在标准B命令基础上增加的命令语句 以提供对测试应用程序和分析结果的帮助 大体有以下几种 一 数据池命令提供访问数据池里的数据的能力 数据池任务包括打开数据池 配置指针 从数据池获得数据和关闭数据池 使用数据池大体有三种方式 定义数据域并自动产生数据 编辑数据池内数据 通过编程方式产生数据 通过其它数据文件向数据池内导入数据 二 对象脚本命令在脚本内部访问应用程序对象和对象属性 对象脚本的任务包括重新得到和设置对象属性 对象脚本命令只能在编辑期间通过手工加入脚本 Robot不能产生这类脚本 三 定时和协调命令计时用户操作和控制脚本回归速率 四 用户操作命令执行用户记录期间在特定对象上的操作 包括选择一个菜单命令 滚动下拉列表框 点击按钮或在编辑框里输入文本等 五 实用命令执行多种操作诸如调用其它脚本 回归初级记录 控制输出到TestManager的日志或者Robot控制台 和管理自定义查证点 六 查证点命令比较回归期间捕获的用户操作的结果与记录期间捕获的相同操作的结果 如果回归结果与记录基线吻合 查证点通过 Result 1 如果结果不同 查证点失败 Result 0 七 数据库操作相关命令建立到指定的ODBC数据源的连接 执行SQL查询语句 并将结果返回数组或文件 查询数据源各类可用信息 接收ODBC函数调用时发生的多条错误的详细信息 关闭ODBC数据源的连接等等 各种类型测试脚本的优缺点分析对比Robot提供的脚本语言是非常有效的编程语言 编写脚本与编写程序非常类似 以下分析各种类型脚本的优缺点 只有应用适当的脚本类型才能使自动化测试灵活高效 发挥脚本的作用 第一种类的测试脚本 录制产生的线形脚本缺点 不具有逻辑判断能力 可维护性差 效率低下 代码量大 兼容性差 优点 简单 通过录制就可以得到 作为被测试程序或者应用程序操作的演示很不错 第二种类的测试脚本 结构化的线形脚本在线形脚本的基础上加上if判断语句和while循环语句等控制结构后 脚本的逻辑判断能力和处理问题的灵活性得到增强 基本实现脚本的模块化 缺点 脚本内仍然捆绑测试信息 即键盘 鼠标动作表示的输入被固化在脚本中 测试修改和定制非常复杂困难 第三种类的测试脚本 共享脚本共享脚本可以被多个测试用例重用 我们将公共操作放在一个地方提供调用实现共享 而不用放在每个需要使用的脚本中 如此在需要更改此部分的代码时 不用修改所有使用此公共操作的脚本 大大减少了维护开销 第四种类的测试脚本 当前最为流行的数据驱动脚本实现了数据与脚本的分离 但测试逻辑依然与脚本捆绑在一起 第五种类的测试脚本 关键字测试脚本真正实现了数据与脚本分离 测试逻辑与测试脚本分离 实现了测试的完全定制 使用模块化的测试脚本组织测试 例如使用Main来Call响应的Subtest 这种方法是非常有效的 因为自动化测试就是编写测试脚本去测试被测试程序 所以脚本开发本身也与程序开发一样 在此使用的其实就是应用程序的一种开发模式而已 关键字驱动脚本详述目标 自恢复 脚本与数据完全分离 可复用 健壮的实现无人职守的测试脚本 解决办法 关键字驱动脚本 基础保证SQABasic可以访问一个对象 得到对象的属性和方法 并可以改变对象的属性和方法 例如 可以得到对象在开发时使用的名称 设置的属性和方法 可以访问界面上不可见对象 可以改变一个对象的属性使对象由不可见为可见 由不可用为可用 例如按钮 得到对象的属性可以作为执行和判定的依据 例如在属性为可用时执行 当设计明确要求此时该对象的属性为不可用时 如果查证属性为不可用则判定用例通过 否则判定用例失败 特点脚本和数据真正分离 脚本可复用 只需要维护其健壮性 可以在其上做无限的测试用例 脚本不包含测试策略 策略体现在数据里 关键字解释关键字指 存放在例如数据池内的可以被用来决定如何测试的数据 这类数据被解释执行 而不仅仅为测试提供参数 过程 在导航脚本的控制下 导航脚本读数据文件 遇到关键字的时候则调用对应的支持脚本 此支持脚本执行并将实际输出与电子表格中的预期输出或事先存储于别处的预期输出进行比较 并将结果写入测试日志报告 意义 如此数据文件内包含测试的逻辑知识用来指定需要执行的测试用例 而支持脚本内包含被测试软件的知识 执行测试用例 脚本和数据就真正分离了 关键字测试脚本实现测试设计内容主要的焦点在于确定要开发的测试数据文件 将测试分解成为测试数据文件有一系列标准可以使用 事务功能 系统分解 测试类型等 将测试单独分解成不同用户角色 不同系统功能 不同的测试类型 不同的测试重点的数据文件 如此不同用户角色对测试数据文件审核更方便 使用 执行和评估更清晰明了 典型的测试设计内容还包括测试环境 大多数情况下需要与其他环境相隔离的独立的测试环境 某些测试需要多个环境 如此可以同时进行多个测试而不互相干扰 如果不具备条件 在设计数据文件时 依据不同测试环境分类设计是很不错的选择 设计用于初始化的数据文件 如此每个数据文件在运行之前可以使用此初始化的数据文件以初始化数据库 如果不初始化数据库 就不得不注意修改后数据的恢复问题 或者费力维护一直处于变化的数据库 其风险与工作量将呈几何级增长 推荐实现模式1 建立应用程序导航图2 对于每个程序中出现的控件类型可能的动作建立对应关键字支持脚本 包括控件的查证动作 3 分层设计测试数据文件 推荐使用表格 4 建立处理测试数据文件 利用导航图 调用关键字支持脚本来完成测试的导航脚本 其中关键字支持脚本 导航脚本是可以完全复用的 导航图实现经过对测试工具的开发 测试工具可以自动登记所有窗口以及窗口内的控件 其默认名称可以修改 并以一定格式存储于指定数据库 否则将不得不手工生成导航图 对每个窗口以及控件 使用测试工具捕获其标识属性 并人工填充到导航图内 导航图简单示例如果是自动捕获可以分类记录尽可能多的属性 以让测试脚本更方便地标识对象 如果人工录入 挑选最容易也最能达到效果的一组属性即可 以下是一个简单的示例 关键字支持脚本实现此部分比较简单 只需要使用测试工具的脚本语言编辑即可 而且针对每一种开发工具只需要开发一次 以后就可以不作任何修改而应用于所有项目的测试中 包括每个控件的可能使用的查证命令 文本框的关键字支持脚本举例 测试数据文件实现详见关键字测试脚本实现测试设计部分内容 建议采用分层设计模式 数据文件示例 续 导航脚本实现此部分已经完全是编程问题 与关键字支持脚本一样 也是可以复用的 甚至不受开发工具的影响 关键字脚本结构示意图 分工1 测试脚本开发小组开发了解被测软件 用各种方式使用被测软件的支持脚本 包括导航脚本开发 2 测试设计人员决定测试策略 组织用例 得到包含关键字 数据和查证点的预期结果等内容的测试文件 3 测试执行人员生成导航图 执行测试 4 测试评估人员查看结果报表 以决定是否通过或者调整测试过程 几个问题的回复假如GUI上的元素发生了变化 增加或减少或改变 假如业务流程发生了变化 假如在回放时出错 而且这用例必须通过 后面的用例才能执行 但无人职守 假如 假如GUI上的元素发生了变化 增加或减少或改变 此时由测试执行人员修改导航图 假如业务流程发生了变化 此时由测试设计小组维护其测试数据的对应部分的电子表格 假如在回放时出错 而且这用例必须通过 后面的用例才能执行 但无人职守 这种假如是要尽力避免的问题 这种假设所说的是前面的用例的输出 作为后面的用例的输入 也就是说前后用例是相互依赖的 如此的依赖性导致前面的用例必须通过 后面的用例才能执行 如果前面的用例在回放时出错则其后的用例不能保证通过与否 哪怕显示为通过 也不一定能确定其确实通过 甚至根本就没法执行 被称为多米诺骨牌效应 所以 我们为避免如此情况 实现用例相互独立 至少轻度依赖 用例具有自恢复能力 即在该用例开始时能够检测确认是否处于适当的界面 数据库数据是否完整无缺 符合当前用例的要求 如果答案为否 自动恢复到适当的界面 用递归调用的方法 自动用当前用例的标准数据库数据导入数据库 继续开始执行用例 如此 哪个用例出错都是自己出错 而不会是受其它用例的影响所导致的结果 当然在何处插入检测点以及插入多少检测点是由多方面因素决定的 一般在出错可能性比较大并修改数据库的地方设置检查点 或者在每个用例执