2.1 本案例研究的背景
这个案例研究描述了我(指Henri)在一个快速成长的新公司里的经历:刚开始的时候,大约有50个员工,但仅仅过了五六个月,员工数量就增加到超过100人。由于人员数量增加太迅速,导致后来加入的很多开发人员和测试人员缺乏对产品的基本了解。知识的交流被极大地忽视了。结果,产品和测试的质量都很差。
办公室里有大约50 ~ 60个开发人员及20个专用测试人员,分别分布在同一办公大楼的各个楼层。测试人员报告产品中存在的问题,但由于测试质量差以及缺乏对产品的充分了解,以致这些问题往往被忽视。通过改善开发人员和测试人员两个群体间的交流,开发和测试工作都从中受益并且质量都得到了提高。所以,良好的交流是开始考虑自动化测试的先决条件。
【真知灼见】
不要尝试对设计很差的测试实施自动化,先完善测试,再进行自动化。
一个包含大约30 ~ 40个测试的典型的发布测试只在一个平台上运行,这就可能需要15 ~ 20个测试人员花费3 ~ 4周的时间。同时,由于发布测试中有更多的bug修复周期和测试周期(一般是4 ~ 6个周期),因此,在可以发布一个产品的新版本之前,过去需要大量的时间。由此可见,将以上过程实现自动化的需求是非常显著的:周期必须缩短,人力资源必须减少,并且测试人员必须在多个平台上运行测试。
一开始,我们使用Java语言开发了一个能够满足以上需求的内部工具,随后再将更多的新功能逐渐添加进去。到目前为止,这个工具的一个更新的版本也已经开发出来了,且又增加了一些新功能。测试也是用Java语言开发的。虽然自动化测试是从GUI自动化开始的,但是基于命令行界面的测试也变得日益重要,因为它可以使团队更方便地通过已安排的分工协作进行自动化。
虽然当时有一些现成的测试套件可用于测试数据库,但是我们并不知道使用什么自动化工具来进行数据库的测试。另外,我们的数据库有当时市场上还没出现的一些特殊功能,而这是现有的测试工具无法测试的。虽然当时已经开发出了一款内部测试工具,但是它根本没法满足我们的需求。那时,我们突然有一些可用资源来开始这样的一个项目,基于这些原因,我们进一步开始测试工具的开发。