第2章　终极数据库自动化

　　Henri van de Scheur

　　Henri van de Scheur讲述了一个跨越6年的故事，是有关他和他的同事在开发一款适用于多个环境的测试数据库工具时所发生的事情。他们为自己的自动化测试设定了良好的目标，并为测试工具搭建了一个良好的架构。他们使很多测试实现了自动化，从而为自动化测试构建了一个完整的生命周期，包括周期性的bug清理。测试是每晚、每周运行的，或者根据特殊的时间表来安排执行。虽然取得了巨大的成功，但他们也遭遇过一系列的问题，Henri都如实地进行了描述。这个数据库测试工具（现在是开源的）是由一支小团队短短几年内在挪威开发的，并且取得了非常可观的投资回报率（ROI），如表2-1所示。

　　表2-1　案例研究特征

　　2.1　本案例研究的背景

　　这个案例研究描述了我（指Henri）在一个快速成长的新公司里的经历：刚开始的时候，大约有50个员工，但仅仅过了五六个月，员工数量就增加到超过100人。由于人员数量增加太迅速，导致后来加入的很多开发人员和测试人员缺乏对产品的基本了解。知识的交流被极大地忽视了。结果，产品和测试的质量都很差。

　　办公室里有大约50 ~ 60个开发人员及20个专用测试人员，分别分布在同一办公大楼的各个楼层。测试人员报告产品中存在的问题，但由于测试质量差以及缺乏对产品的充分了解，以致这些问题往往被忽视。通过改善开发人员和测试人员两个群体间的交流，开发和测试工作都从中受益并且质量都得到了提高。所以，良好的交流是开始考虑自动化测试的先决条件。

　　【真知灼见】

　　不要尝试对设计很差的测试实施自动化，先完善测试，再进行自动化。

　　一个包含大约30 ~ 40个测试的典型的发布测试只在一个平台上运行，这就可能需要15 ~ 20个测试人员花费3 ~ 4周的时间。同时，由于发布测试中有更多的bug修复周期和测试周期（一般是4 ~ 6个周期），因此，在可以发布一个产品的新版本之前，过去需要大量的时间。由此可见，将以上过程实现自动化的需求是非常显著的：周期必须缩短，人力资源必须减少，并且测试人员必须在多个平台上运行测试。

　　一开始，我们使用Java语言开发了一个能够满足以上需求的内部工具，随后再将更多的新功能逐渐添加进去。到目前为止，这个工具的一个更新的版本也已经开发出来了，且又增加了一些新功能。测试也是用Java语言开发的。虽然自动化测试是从GUI自动化开始的，但是基于命令行界面的测试也变得日益重要，因为它可以使团队更方便地通过已安排的分工协作进行自动化。

　　虽然当时有一些现成的测试套件可用于测试数据库，但是我们并不知道使用什么自动化工具来进行数据库的测试。另外，我们的数据库有当时市场上还没出现的一些特殊功能，而这是现有的测试工具无法测试的。虽然当时已经开发出了一款内部测试工具，但是它根本没法满足我们的需求。那时，我们突然有一些可用资源来开始这样的一个项目，基于这些原因，我们进一步开始测试工具的开发。

　　2.2　测试中的软件

　　该项目中要测试的软件是比较特殊的，因为它仅仅只包含数据库。虽然有一些现存的测试套件可用于测试数据库，例如测试多个数据库API和查询语言之间兼容性的测试套件，包括JDK（Java Development Kit）、JDBC、ODBC（Open DataBase Connectivity）和SQL，但是这些工具的使用并不广泛，并且（或者）它们仅仅只是为使用它们的数据库量身定做的。所以本案例研究中的测试和测试工具都是内部开发的。

　　我们定义了一个操作系统组合而成的平台，包括它的品牌和JDK版本。我们后来又将另一项包含进去：平台是32位还是64位的。

　　例如，包括以下几项：

　　Solaris 10 SPARC, JDK 6, 32位；
　　Solaris 10×64, JDK 6, 64位；
　　Solaris 10×64, JDK 6, 32位；
　　Solaris 10×86, JDK 6, 32位；
　　Solaris 10×86, JDK 5, 32位；
　　Windows Vista 64, JDK 6, 64位。