● Siderite 的缺陷
我这一缺陷并非来源于我们的代码，而是来源于如 Javascript 引擎或 。Net 架构这类承载代码的东西。那次我正在测试一个应用程序，该程序引入了一个新的日历控制器。测试工作耗费了我大量的时间和精力，我非常担心它是否可以顺利运行。只要一想到老板可能点到一个有问题的键，我就寝食难安。
但是问题还是出现了！
有一个特定的时间——夏令时，如能完整地设置这一天的年月日，且将地点设置为我的家乡——罗马尼亚，则能正常运行。倘若未设置地点，仅设置年月日，日历控制器就会显示为该天的前一天，23 点整。几经测试都是同样的结果。我尝试将默认的 0 时设置为 12 时，之后这一缺陷就再也没有出现过，我猜测这可能是由于 Windows 某种类型的更新所引起的。
● Alan Myrvold 的缺陷
我碰到缺陷总会很兴奋，尤其是那些对我有益的缺陷。
几年前，我在一个商业软件公司测试数据挖掘软件。这听上去不错，尽管我大学的专业是统计，而非计算机科学，但也总算有点接近。该软件会从大量的数据源读取数据，包括 。CSV 文件。我发现从某些中等大小的文件中读取数据的时间会比预期长。于是我将这个缺陷记录下来，并计划进行更多的测试。
Stephan 是开发部的领军人物，和他共事是我的荣幸。他在软件设计、编码方面都很在行，为人也很和善，总能耐心解答他人的问题，受到测试人员的尊敬。他看了看我的缺陷，又看了一下代码，坚决表示这个由第三方编写的代码看上去是正确的。当读取数据时，程序将数据列入一个红黑色的树列，从 Stephan 那里得知这是一种数据结构，用于有效地存储二进制树。当我问到它的工作原理时，Stephan 借了本书给我，是 Cormen et al 的 Introduction to Algorithms（算法入门）影印本。
程序依旧运行得不顺畅。于是我对这些文件按正序、随机以及倒序的顺序分别进行了性能测试，发现同样的文件按不同的顺序进行测试的结果竟然大相径庭。于是我开始对读取的数据进行调试，因为我不能接触到源代码，所以只能逐个分解并跟踪数据流。我在纸上仔细地画出了读取数据时所构建的树结构图，并注意到它正好与红黑色树的需求相冲突，尽管源代码看上去是没有问题的。我编制了一份正确的算法实现，待 Stephan 仔细审阅后终于得到认可。
经验总结：
◆ 手动测试时，旁人的观点很有可能帮助您发现原先被忽略的缺陷。
◆ 在没有源代码的情况下也能进行调试，尽管会比较困难。
◆ 看上去正确的代码也可能是错误的。
◆ 计算机科学的知识可以帮助测试人员。
● Eric Sink 的缺陷
我曾碰到过这样一种产品，它能使其他应用程序崩溃。
开始，我们觉得这是难以置信的。人们纷纷打电话到我们的服务中心，抱怨使用我们的产品导致了其它程序的崩溃。但是这种崩溃又是不可重现的，而且这整件事情听起来也有点荒谬。如果正巧其他的应用程序崩溃的时候，而我们的产品正在运行，这因果关系又如何能判断呢？
但最终证实这是千真万确的。当我们的一个对话框操作失败时，有时候确实会引发其他应用程序的奔溃。
原文出处：http://blogs.msdn.com/micahel/
（未完，精彩待续）
版权声明：51Testing软件测试网及内容提供者拥有本文全部版权，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
相关阅读：
