创建小型测试程序排除软件故障的艺术

迈不过友情╰ 2024-02-17 19:41 26阅读 0赞

**创建小型测试程序排除软件故障的艺术**

作者：Chip Camden  
翻译：PurpleEndurer，2011-01-31 第1版

前言：当你的程序出现故障时，Chip Camden建议你创建一个小型测试程序，因为它会帮助供应商和开发商向你提供帮助。创建这样一个程序的相关资料如下。

又来了！无论你如何细心地测试了所用语言、函数库和架构的每一项性能，无论你如何审慎地为每个组件创建了单元测试，当你最终把它纳入应用程序时，得到的是不可理解的故障。

尝试所知的每一种调试技术；改写并简化了最可疑的代码段；掐掉或剔除整个组件。这可能会帮助你把故障缩小到特定区域，但你对出错的东西或原因仍然没有头绪。如果你知道语言或函数库的来源，你可能会得到更进一步的信息，但你也许仍然会因为缺乏知识或文档，对故障的理解不足以解决问题。

这时需要求助了。在论坛上提交问题，或者直接联系作者/供应商，但他们不能重现该问题。（不知何故，你知道这种情形会发生。）他们要求提供重现实例。你把整个应用程序直接发送给他们，问题永远得不到解决，因为它太麻烦了。最后不了了之。

好吧，我们不喜欢这样的结局。我们怎样才能改写这种结局呢？在付费支持的情况下，我们可以跺脚、叫喊并升级，迫使供应商在该问题上花时间；但如果整个应用程序运行和调试被证明太困难，那么他们仍然可以推说“无法再现（unreproducible）”。供应商可以做的只有这么多。即使他们把这个问题留下来继续研究，也可能需要很长的时间来对它刨根问底。幸运的是，在遇到这种问题时，我们可以做一样东西来帮助供应商为我们提供帮助：这个东西就是我所说的小型测试程序（Small Test Program，简写为STP）。

“哇！等一下！当我们在尝试进行调试时已经删除一切多余的东西！”我听见你泣道。

你说的可能是实情，但是我们的目标却是要排除其他原因。把目标转为缩小测试程序牵涉的范围，这样你几乎总是有更多事情可以做。这两个目标听上去几乎是一样的，而且它们有很多重叠之处，但它们的覆盖范围并不完全一样。在第一种情况下，我们试图尽一切可能来自力更生解决问题。在第二种情况下，我们要尽自己所能帮助开发人员解决问题。这意味着我们需要采取以下步骤：

▲　**去掉对特定配置的依赖。**豪无疑问，你已经定制了自己的开发环境，通过各种捷径和惯例来节省时间；但对不熟悉这些的人来说，它们中任何一项都耗费时间。你要么去掉这些依赖，创造一个更普通的环境，要么为他们提供了一个不会被入侵的快速安装程序。例如，如果您需要用户设置某些环境变量，那么可以提供一个脚本来完成这些设置，然后启动应用程序。最好是完全消除对环境变量依赖——如果在一个以上的地方设置，或没能正确导出，那么这种依赖关系会增加不确定性。

▲　尽自己所能地去掉所有自定义或第三方组件。你应该已经做了这件事情，但在提交故障时，这变得更加重要。外部组件总是引来指责——确实如此，因为它们经常会造成不可预见的问题。把它们排除出来。此外，如果外部组件需要安装和设置，这会延迟开发者看问题的时间。开发人员在让这些组件在其系统上工作时通常会遇到麻烦，如果他们在开始时并不真正需要这些组件，这就纯粹是浪费时间。

▲　**减少需要用户操作的步骤。**如果你认为通过运行测试程序一次或两次就会发现问题，那么你就是一个盲目乐观的人（Pollyanna）。如果他们要将测试程序运行一千次，执行时间里的每一分钟的费用为两个工作日。实际上比这更多，这是因为开发人员也是人——每一次开发人员都必须重新启动一个冗长、艰难的设置步骤，他们需要时不时地暂停下来叹息并纳闷他们的命怎么这么苦。

▲　**清晰记录操作步骤。**我不知道有多少次收到一些自称是重现问题的步骤的东西，内容为“运行应用程序。”除非应用程序非常简单，不需要安装或互动，而且故障明显到连\[典型无能之人\]也不会错过，否则该指令将无法重现。不管它看起来多么明显，都要包括每一个步骤——每条一安装命令，启动应用程序的命令，以及所需输入的一切。如果您遵循上述步骤，这应该不会太多。

▲　**尽可能减少执行代码行数。**整个程序可能在两秒钟内运行，但如果它执行了30000行代码，那么开发人员可能要排除至少30000个可能的原因。此外，这还会让调试变得复杂。如果你能将整个程序压缩至“一，二，搞定！”那你就学乖了。

▲　**包含明确的故障标示。**不要想当然地认为开发人员将立即辨别出来，你那是10个像素的玩意太小了——请在步骤说明中告诉他们。理想的情况是，应用程序在运行时应该大叫：“这就是我出故障的地方！”。使用断言，或者至少用printf或消息框来输出。

▲　**包含明确的成功标示。**有很多次，我已经解决了测试程序表现出来的一个问题，随即又碰到另一个故障。难道我之前解决了一个他们没有报告的问题，现在才看到他们提出的故障吗？通常他们知道第二个故障，但他们根本不费心去阻止它出现，因为他们已经重现了第一个故障。这很失礼。在理想情况下，你希望测试程序是为某个问题量身定制的，这样同样的问题就不会在另一个测试程序中出现。为了实现这一目标，它要有一个成功的标志。这会让我们对故障是否已成功排除不存有任何疑问。

▲　**变换角色来测试程序。**把自己设想为负责该工作的开发人员再运行测试程序，这样可确保你没有什么遗漏。不要在你自己的开发系统上运行它，因为你的环境设置方式可能与开发人员不同。在虚拟机中使用普通配置来运行测试程序，并确保它按你打算的那样精确地把故障表现出来。这可以为你减少几趟电子邮件上的交涉，避免给别人造成“你这人做事糊里糊涂”的印象。

**你为什么需要创建小型测试程序**

你为什么要投入额外的努力创建一个小型测试程序？毕竟这是他们的错误，让他们去找到它，解决它。

我的客户大多是软件开发人员，所以我从两个角度来看这个问题。作为一名在过去20年里数百（也许是数千）个待解决故障的受理者，我不得不把它们提交给许多软件供应商。纯粹从我的个人经验来说，我可以告诉你一点：决定开发人员解决问题快速程度的惟一一个最具影响力的因素——既不是你是否向提供产品支持的供应商付费，或者付了多少费，亦不是你歇斯底里的大怒大喊，也不是你的恭维奉承，更不是他们可以按时响应的信誉——而是：如何清楚扼简要地演示故障。

所以，下次你需要提交问题报告时，应记得史蒂夫·马丁（Steve Martin）的不朽名言：“让我们做得小些”。（完）  
（[http://www.techrepublic.com/blog/programming-and-development/the-art-of-the-small-test-program/3787][http_www.techrepublic.com_blog_programming-and-development_the-art-of-the-small-test-program_3787]）

[http_www.techrepublic.com_blog_programming-and-development_the-art-of-the-small-test-program_3787]: http://www.techrepublic.com/blog/programming-and-development/the-art-of-the-small-test-program/3787