为构建创建自动化冒烟测试——保持项目节奏实践之二

不管使用持续集成与否，都应该为构建产品创建自动化冒烟测试。冒烟测试仅仅是为了验证要构建的版本没有问题。你想添加多少回归测试都可以，我不拦着，但是使用冒烟测试，是要知道当前的构建版本是否对大家有用。

有了自动化冒烟测试，项目团队就可以知道是不是有人破坏了当前构建版本。如果能尽早知道一个构建完成了，你就可以在其基础上做些自己想做的工作。要是必须依赖其他开发人员或是测试人员才能知道当前构建版本出了问题，那你就不能以最快的速度修复当前构建版本了。

别让烟跑出去！

梅瑞狄斯，资深测试人员

作为测试人员，寻找问题是我的职责所在。而且，我也很擅长这个。我有一句座右铭：“别让烟跑出去。”

有一次，我加入了公司的一个新项目。开发人员以前从没有与专业测试人员一起工作过。我拿着一张有15个缺陷的列表，走到他们中一个人的面前，然后说：“你得说说这是怎么回事，要不我把这些问题提交到缺陷跟踪系统里面如何？”他们都惊呆了。

我向他们说明，这些缺陷通过一个自动化冒烟测试都可以找出来。没有哪个缺陷需要靠我的专业知识和经验才能发现。我不想浪费时间找出这些易于发现的缺陷，而是要找出更捣蛋的缺陷——时而发生的问题、系统可伸缩性上的问题和可靠性问题。我想钻到代码之中，把高难度缺陷一个个都揪出来，直到它们全部显形。

那个开发人员脸色发白，屏住呼吸说道：“呃，好吧，我希望你也能那么做。需要我配合你什么？”

我解释了我的座右铭：“你的工作是尽量保证不出问题。我的职责是尽量让问题血淋淋地暴露出来。明白了么？”他表示同意。我想我听到他跟别人说我有点嗜血倾向。不过，管他的，我对此毫无意见。

我签入了我的测试代码，开始构建自动化冒烟测试框架。开发人员开始一点儿一点儿地加入冒烟测试。如果我找到了一个冒烟测试应该发现的问题，就会冲到加入这个缺陷的开发人员跟前，对他说“别让烟跑出去”。不久之后，大家只要一看到我走向开发人员的小隔间，就会有人大叫：“是谁把烟放出去的？”

我们现在合作得非常好。这些开发人员的工作表现非常好，而且他们也让我能很好地完成自己的工作。我们的产品NB极了！（这么说没事吧？）

让构建版本正常工作，这对建立并保持项目的节奏大有裨益。能够第一时间发现构建版本出现问题，也使得项目经理可以将项目带回正常的节奏，或者发现是什么使得团队无法保持节奏。

实际上，如果项目的产品要在多种型号的计算机、数据库或固件上运行，要确保团队每天都为所有的平台编译并构建产品。如果不这么做，到了项目结束的时候，项目经理就得忙着解决那时才能发现的问题了。在项目中越早发现兼容性方面的差池，就越容易应对，而且开发人员在后面的工作中也能将其牢记在心。

（正文图片来自：http://www.flickr.com/photos/arciteka/）