自动化功能测试框架开发最佳实践.ppt

内容提要 为什么需要自动化测试 什么值得做自动化功能测试 自动化功能测试框架 基于RFT的自动化功能测试框架 总结 为什么需要自动化功能测试 为什么需要自动化功能测试 项目/产品周期越来越短 已有功能的测试 新功能的测试 对测试覆盖率的要求越来越高 回归测试数量大量增加 非工作时间的测试 对项目/产品的敏捷性要求越来越高 更灵活快捷的应对各种变更 内容提要 为什么需要自动化测试 什么值得做自动化功能测试 自动化功能测试框架 基于RFT的自动化功能测试框架 总结 什么值得做自动化功能测试 重复执行的测试 对已有的、稳定的功能进行的测试 相对简单/单一设计的测试 大量数据、变量的输入/验证的测试 内容提要 为什么需要自动化测试 什么值得做自动化功能测试 自动化功能测试框架 基于RFT的自动化功能测试框架 总结 自动化功能测试框架 基于测试脚本模块化的自动化测试框架 基于测试脚本类库架构的自动化测试框架 数据驱动的自动化测试框架 表/关键字驱动的自动化测试框架 混合的自动化测试框架 基于测试脚本模块化的自动化测试框架 基于测试脚本模块化的自动测试框架要求我们创建小而独立的针对被测应用功能的测试脚本，然后把这些各脚本层次化的组织起来完成对特定测试用例的执行。 要求测试人员熟悉被测应用的技术细节、具体测试工具及脚本技术 测试脚本开发较简单，但编码量较多，且需要一定的积累，测试脚本维护工作量大 实际使用中，开发自动化测试案例脚本的效率不高，完成测试所需的时间比单纯的“录制－回放”方式提高不多。 基于测试脚本类库架构的自动化测试框架 与基于测试脚本模块化的自动测试框架类似，不同之处在于提高了抽象层次；将测试用例、任务、对象进行了层次化，测试用例脚本调用测试任务，测试任务调用测试对象来完成测试。（例如：ITCL（IBM框架）） 要求测试人员熟悉测试工具、技术细节、框架包（例如：ITCL中的IBM.jar）的使用细节。 测试脚本开发较简单，但编码量较多，需要积累或建立相应的类库，有一定的测试脚本维护工作量。 由于待测应用中的待测对象获取仍然需要手工干预/编码，实际使用中完成测试所需的时间比“录制－回放”方式提高有限。 数据驱动的自动化测试框架 数据驱动的框架中，测试的输入和输出值都是从数据文件中读取的（datapools、ODBC、CSV文件等），测试用例被包含在测试数据文件中，数据来控制流程，而测试脚本相当于“驱动引擎”来执行。 对自动化测试框架核心的开发维护人员有较高的技术要求，其他测试人员的技术要求不高。 完成测试所需要的脚本开发量小，测试的关键工作在于“数据”的准备 实际使用中比“录制－回放”方式成倍的提高测试效率 表/关键字驱动的自动化测试框架 与数据驱动类似，测试脚本相当于“驱动引擎”来驱动被测应用和数据，测试用例是包含/写在“表”（也可以是可视化的界面应用端）中的。通俗讲它是数据驱动的更高级版本，数据驱动的控制是函数级的，表/关键字驱动控制的是动作级的。 对自动化测试框架核心的开发维护人员有较高的技术要求，其他测试人员的技术要求不高。 “表”可以使用标准的自然语言，由测试执行引擎来解析，因此只要了解书写规则，业务人员也可以写出自动化测试执行引擎可以“读懂”的测试用例 完成测试所需要的脚本开发量小，测试的关键工作在于表/关键字的准备 实际使用中比“录制－回放”方式成倍的提高测试效率 混合的自动化测试框架 根据实际情况综合使用上述自动化测试框架，以充分利用各自的优点。 例如： 内容提要 为什么需要自动化测试 什么值得做自动化功能测试 自动化功能测试框架 基于RFT的自动化功能测试框架 总结 基于RFT的的自动化功能测试框架 基于RFT的的自动化功能测试框架 驱动表举例： 基于RFT的的自动化功能测试框架 对象维护举例： 基于RFT的的自动化功能测试框架 对象的识别 Find、TestObjects 屏蔽好被测应用的约束 密码安全控件、特殊外设输入等 需要开发部门的配合 规范的界面对象命名 建立反馈机制 测试引擎设计的平衡 兼顾通用和应用特性 总结 需要用系统化的思维考虑自动化测试，否则…… * 自动化功能测试框架开发最佳实践 IBM 中国软件开发中心 朱伟杰 zhuweij@ 需求 开发 测试 产品 迭代N 迭代2 迭代1 需求管理 需求分析 需求获取 设计/实现 构建(Build) 缺陷处理 测试计划 测试用例 测试结果 测试执行 发布计划 功能增强及补丁 产品约束 自动化 功能 测试 Datapools 脚本 脚本 脚本 模块化的测试脚本 对象库 方法库 脚本类库 测试用例脚本 抽取建立 脚本类库 与datapools 的接口 依据测试用例控制调用和执行，以实现对测试场景的回放 2- 测试脚本放入配置管理