有一种传统观点认为，软件开发人员无法测试自己的代码。我认为这更像是在说你不能有意义地测试你编写的以某种方式运行的软件的行为。推理很简单。如果您在编写代码时考虑到快乐的路径，那么在测试时您将始终在快乐的路径中导航，而被某种形式的确认偏差所蒙蔽。
更具体地说，假设您编写了一段代码来读取电子表格，将总和和平均值制成表格，并将这些结果报告给用户。当您构建这个小应用程序时，您要做的第一件事就是让它成功读取文件，以便您可以编写依赖于此先决条件的应用程序的其他部分。在您的开发过程中，您将不太可能测试阅读电子表格可能出错的所有事情，因为您会在继续测试平均值时形成一种正确导入的肌肉记忆和你正在集中精力的总和。你不会想，“如果列调换了会怎样”或“如果我传入的是 word 文档而不是电子表格会怎样？”
由于这种影响，我们被责备不要测试我们自己的软件。这就是质量保证部门存在的原因。他们有正确的视角和分离，以免被他们对事情应该如何发展的知识所蒙蔽。但这真的意味着您 不能 测试自己的软件吗？其他人可能更适合这样做，但您当然可以努力减少自己盲点的大小和范围，以便在环境迫使您测试自己的代码的情况下更加有效。您可能正在兼职做一个充满激情的项目，或者是一家初创公司的唯一技术成员——您并不总是有选择。
让我们来看看一些可以帮助您更有效地测试软件的技术，无论这些软件是由您编写的还是由其他人编写的。这些是您可以实践并变得更好的实际方法。
探索性测试
探索性测试是寻找创造性的、奇怪的方法来破坏软件的想法。您会发现其中一件事是，用户具有惊人的能力，可以以您无法想象的一些最不可能、坦率地说是愚蠢的方式使用软件。 “我点击保存，然后将水倒入磁盘驱动器，但保存没有用。”
你想培养想象用户可能会做的疯狂事情的能力，并问问自己会发生什么。做到这一点的一个好方法是观察使用您的软件或实际上使用任何软件的非精明用户。他们会做一些奇怪的和意想不到的事情——那种你不会做的事情——你可以记下它们并将它们用作对你自己的软件做的事情的想法。访问质量检查人员或用户支持人员的论坛，以发泄他们遇到的愚蠢的事情，并使用它们。建立一个你可以在你的东西上启动的清单。
陷阱测试
除了开发一系列愚蠢的使用场景来攻击您的软件之外，您还应该了解普通用户会犯的常见错误。这些不是那种会让你三思而后行的事情，而是那些经常发生的事情，不会让任何人感到惊讶。
用户是否在电话号码字段中键入了文本？用户是否不小心连续点击了四次“支付”？任何字段留空？这些是常见的软件错误类型，您应该对其进行分类，并养成在您自己的软件中抛出错误的习惯。如果你经常练习，它将成为第二天性。
关于边缘情况的推理
边缘情况与常见陷阱有微妙的不同。边缘情况是您的软件围绕代码的特定、有意义的值运行的方式。例如，在我们的电子表格示例中，您可能已将软件设计为处理电子表格输入中的最大行数。如果您接受 10,000 行，请养成测试 9,999、10,000 和 10,001 行以查看其行为的习惯。如果它做对了这三个，它就极有可能做对 4,200 和 55,340。
选择边缘案例可以让您获得最大的收益。您将养成用最少的努力找出最多可能的错误的习惯。
有帮助，并非万无一失
建立一个东西库来扔给你的软件会让你更有效地测试你自己的东西。这是一项宝贵的技能，您应该培养。但是，归根结底，没有什么可以替代对您的工作进行第二眼观察。使用这篇文章中的技术作为让其他人测试它的补充——而不是替代。