自动化测试数据之可不可复用.PDFVIP

目 录 自动化测试数据之可不可复用 1 我的 GUI 自动化测试框架发展历程 8 软件测试中的冲突测试 32 基于 Win32 窗口的开源自动化测试工具 White 38 我的测试之路 48 使用 Mobi Ready 进行手机软件兼容性测试 52 Mantis 深入学习 57 浏览器兼容性测试的自动化预研分析 68 深入分析 TestComplete 名称映射 74 自动化测试数据之可不可复用 作者：刘毅 摘要：我认为测试数据不仅是自动化测试的核心要素，也是所有类型的测试 所共有的一个基本元素，离开测试数据的测试基本上就丧失了它的可靠性与意 义。当然，对于自动化测试来说，它对测试数据的使用和管理又有着它自己的特 殊要求：可反复使用、能够自动生成或更新，可轻松迁移……可能有些人对一个 系统拥有三、四套乃至更多的测试环境，同时存在多个版本的并行测试没有概念， 那么这些人在自动化测试的其他方面要有着更高的追求，但是对于测试数据来 说，却从不曾为之忧心和烦恼。 关键字：自动化测试；测试数据；回归测试；数据复用；存储过程 需求背景 我们的应用是基于 Weblogic 和 Oracle 的 B/S 结构保险业务系统，应该属于 标准的 J2EE 架构。自动化测试力量现阶段集中在 UI 层验证测试，主要应用于 系统测试中的冒烟和回归测试。常规版本周期从半个月到一个月不等，紧急需求 或生产缺陷引发的非常规版本测试周期从一个工作日到一个月不等——想必比 起互联网应用的发布速度，我们算是比较宽松的。虽然比较宽松，但是由于系统 耦合度极高，业务逻辑极其复杂且不具有通用的规则引擎，数据种类千变万化， 系统内外关联影响很大，我们任何一个版本的任意一个小小的改动点都有可能引 发生产 L-1 级别的程序缺陷乃至重大故障。考虑到关联影响的分析太过依赖个人 能力，不具备高度的可复制性和易推广性，所以我们对回归测试和的要求很高， 也是因为对回归测试的要求很高，我们对冒烟测试的要求也很高，并且要求能够 快速完成。 逆向思考 最初我们纠结于可用的数据如何从数据库抓出来，抓出来之后是直接使用还 是先做本地存储然后定期更新。后来我们发现无论如何操作，从一个 4TB 数据 库中抓取可用的数据似乎又是一个漫长的过程，尤其是部分同事对 SQL 效率优 化没有太多概念的时候，测试脚本常常因此运行太长时间而被自动化测试管理平 台的超时控制机制强行终止。即便是获取数据的速度不慢，而有些特殊业务的数 1 据量也不能支持长久的测试运行和测试环境的切换，依赖上游数据的产生根本不 具备及时性和稳定性。 似乎我们大部分人反对使用固定数据进行测试，因为这个观念从自动化测试 入门开始就被灌输到我们的脑子里了，绝大多数接触过自动化测试的人都知道测 试脚本需要参数化，并且实现测试数据和脚本操作的分离。参数化和数据分离是 正确的，只不过数据分离并不代表测试数据不可以固定使用，如果一条数据可以 进行千万次的对系统的功能验证，只要它是有效的，我们是否非要去不停地更新 掉这条数据呢？我觉得未必！其实我们所说的固定数据更多的是指，在一个功能 点中存在多种数据处理方式，也就是存在多个代码分支的情况下，只使用一条或 几条相同的数据去覆盖其中的一个分支。那么如果我们能够去分析一下这些代码 分支，针对不同的逻辑分支去构造数据进行测试，那么每一个分支上的测试数据 即便是固定的，测试遗漏也不会比我们的正交覆盖更多。所以，只要我们努力理 清代码的逻辑分支，并且实现测试数据的使用完回