安全之美——1.2.1 概念简介

Microsoft的产品测试的目的是为了确认他们对软件行为的信任，而不是为了打击这种信任。软件架构师和工程师经常会遇到这种盲点。在1968年的一篇论文中，Peter Wason指出“为了获得正确的解决方案，有必要产生一种意愿，就是试图推翻假设，并对那些常常确信是正确的直观想法进行测试”（注6）。他通过一个简单的智力测试演示了确认陷阱。 找一些人并通知他们正在进行一个小实验。我们将向参与者提供一个整数数列，它们遵循一个规则，参与者的任务就是猜出这个规则。为了确定这个规则，参与者可以说出另外的数列，然后我们告诉他这个数列是否符合这个未知的规则。当参与者认为他已经猜中了这个规则时，就可以把它说出来。 这个规则实际上非常简单，就是递增的数列。但是我们先不把它说出来。 我们最初提供的数列是2、4和6。 此时，其中一位参与者提出了数列8、10和12。我们应该告诉他8、10和12确实遵循这个规则。另一位参与者可能提出1、3和5。同样，我们告诉他数列1、3和5也遵循这个规则。 当人们看到初始数列2、4和6时，会注意到一个显而易见的关系，就是每个后续的数都比前一个数大2。当他们提出匹配的数列时，可能会让它满足这种关系，但这完全只是他们自己的想法，与我们的秘密规则无关。当他们所提出的数列得到证实时，会进一步驱使他们确信自己原先的猜测是正确的，而不是想方设法否定自己的猜测。 现在，我们可以把这个秘密规则想象为一个接受输入的软件规则，并把这个小实验的参与者想象为软件测试人员，他们相信所有用户的输入都应该按2递增。他们并不会测试其他数列，例如1、14和9076（更不用提像-55、-30和0这样的数列了）。因此，系统最终肯定会接受没有经过测试的输入，这很可能导致系统的崩溃。 为什么会出现确认陷阱？事实上我们都倾向于自己的猜测是正确的而不是错误的。虽然按照严格的逻辑要求，应该用不遵循自己的假设的数列（例如10、9、8）对这个假设（即所有的输入必须是偶数，或者必须按2递增）进行测试，但是试图增强自己的假设而不是驳斥它却是人类的天性。 “这部分软件是否按预想的工作？”这个问题不仅需要用我们所倾向的方式进行测试，而且要用怪异的、恶意的和随机的方法进行测试。但是，内部软件测试很少会重建常规的终端用户和恶意对手很可能对软件进行这类输入的这个真实场景。