2009年1月30日星期五

从艺术到工具

从艺术到工具


刘冬清


软件测试最早的经典著作大概是70年代Meyer那本《The art of software testing》了。30多年过去了,这本书依然值得一读。 

有很多书叫XXXX的艺术,那究竟艺术是什么意思呢?我理解,艺术是指需要较多创造性的活动。凡是称为艺术的,就是人们还不知道如何用一种固定的方式做好的事情。有人用这种方式做的很好,但有人用完全不同的方式也可以做的很好。有一些被广泛认可,一般人都可以学会的技术,但是这些技术并不能保证把这件事做好。比如大部分人都会写文章,知道一些起承转合的技术,但能写出可以称为艺术品的文章的人就很少,也很难教出来。

一件事情如果完全成为技术,那就可以用机器自动化下来的。这样,人们就可以被解放出来,去从事有创造性的艺术性工作。30年前,软件测试被称为是艺术,三十年后,依然适用,进步不大。当然也有很多技术被发展出来,但很多时候在工业界实践中,并不太注重这些技术的使用。在加入IBM之前,我找了一些测试方面的书看过,里面有很多技术性的方法,比如等价类划分,边界值分析,决策表之类。然后真的开始测试工作的时候,很惊讶的发现,其实大家基本不去有意识的应用这些方法,而只是很模糊的看着Functional Specification,凭经验去写测试用例,然后通过review来保证基本的覆盖率。有着复杂的,高度程式化的Process,和非常原始的技术。这样的测试结果,好像也没什么大问题,至少产品还是一茬茬的卖着。难道测试其实这么做做就成了?

工程实践和书本理论的差别在于,实践中有更为复杂的背景,有资源和成本的考虑。工程考虑的不是怎么做最好,而是怎么做最划算。对于我们所测试的这样的一个小小的component,是不值得投入过多的资源的。这样的测试也够了。当然,从大老板的角度来讲,这是一个微不足道的产品,对于我来说,是我的全部工作,考虑一下如何把它做好是有益于自己也有益于人民的。

我是相信技术能为人民服务的。在软件测试在很大程度上还是艺术的情况下,将现有的测试艺术技术化是一条可行之路。我们无法知道毕加索是如何创立立体派的,但是一旦它被创造出来,我们就可以模仿他,发现其中的模式,然后将其转化为一门技术,并提供工具来应用。创造——模仿——模式——工具,知识就这样从天才头脑里转化到了普通人手中。当这部分工作成为常规的自动化或半自动化不需要太多人干预的工作后,人们就可以去解决更复杂的问题,如此周而复始。

软件测试是贯穿整个软件生命周期的——本以为这应该是业界共识,然而现实并不是这样。虽然有些人认为并不需要独立的专职的QA,但测试工作并不少做。在各个阶段,测试的目的不同,对象不同,手段也不同。那么每个阶段都有什么样的艺术呢?

  • 需求阶段——对需求的测试

这个阶段这几年我几乎接触不到。只是在后面测试的时候会有时候觉得不明白为啥要做这么个功能?在什么场景下用?不了解所以不谈。

  • 计阶段——对设计的测试

其实这个阶段也参与很少,只是在近期才有了一些经验。软件里设计有很多层面,比如架构,模块,甚至写代码本身都是设计的过程,这里指的是对软件行为的设计。就是说用什么样的技术手段,以什么样的方式来满足需求。

对设计如何测试?在google上也搜不到特别好的结果。也许开会review是个好办法?对于大的功能,应该通过场景设计,或者prototype 演示的办法去测试。这样通常是比较发散的一个过程,如何把一些专家的知识程序化下来让每个人都可以参照呢?我能想出的简便办法是check list,将需要考察的方面以问题的形式列出来,以此为根据进行review

  • 开发阶段——对代码的测试

现在都讲测试驱动开发。这里的测试通常有两种形式,单元测试和Acceptance 测试。主要区别是测试的目的不同,单元测试验证代码做了程序员想让它做的事情;Acceptance 测试验证软件做了客户想让它做的事情。

在很多人的努力下,单元测试已经从少数高人的个人实践变成了很普通的技术。刚接触Java的时候,我的师兄教育我,每个类都写一个main函数,这样可以很方便的测试,这就是单元测试的意识。xUnit的出现,为单元测试提供了模式和工具。

好的工具会让事情做起来顺理成章。FIT是我知道的Acceptance 测试最好的工具,它作为一座桥梁为客户和技术人员的提供了沟通之路。FIT workflow将好的工作方式变成了容易遵循的套路。

一种广泛应用于这两种测试的模式是AAA模式: Arrange —— Act —— Assert。这种相对固定的形式是计算机最适合的。同时也可以保证软件有牢靠的基础。然后加上人来做的探索性测试——这部分需要发挥人的创造性,依然主要是艺术性的。

  • 发布阶段——对产品的测试

这里的产品指的是需要给客户的东西。比如软件的安装包,文档,范例等等。由于是面对客户,很多这方面的测试是需要人来做的,无法自动完成。然而人来做不一定就是很有趣的,这些常常是很烦人的工作。比如对文档的review,和范例的使用。这些地方是不是能有所创新呢?

文章真是难写,写着写着就不知道要写什么了。总结一下,这篇文章我想说的是:艺术性的东西,可以变成技术,然后变成工具而广泛传播。公式如下:创造——模仿——模式——工具




关注者

All about Testing