感谢回归测试

感谢回归测试。 本周早些时候，我对自己写的一些新代码感觉非常好，并且（我认为）进行了调试。 我正在增强OpenVOS POSIX函数的功能，这些函数将二进制时间值转换为分解的时间结构（对于你们这些C语言专家来说是"tm结构"）。 早在1998年，当我最初修改这些例程以在POSIX环境中工作时，我走了一条捷径，调用了底层的VOS内核子例程。 这种方法既快又简单，但这意味着我们的POSIX运行时不能处理1970年到1980年之间的日期，因为VOS不处理这些日期。 最近，我一直在将几个主要的新的开源包移植到OpenVOS 17.0。 我发现我们有很多测试都失败了，因为我们不能处理这个范围的日期。所以我开始修改代码以处理VOS和UNIX时代（1970到2048）的所有日期。 我知道这个任务很容易出错，我决心要找到一种方法来解决代码中的所有错误。 使用日期的一个好处是，这个集合是有限的。 另外，由于现代计算机的速度相当快，让他们把所有可能的组合进行压缩并看看会发生什么并不难。 我想确保测试处理1970年和1971年的代码区域，原因我不会在这里讨论。所以我写了一个测试，每天转换2次，从1970年1月1日开始，一直延伸到现在。 它只用了一秒钟的CPU时间的一小部分。 果然，我在我的代码中发现了一个栅栏柱错误。 我纠正了这个错误，然后测试就通过了。 我对这个过程感觉很好，我的审核员也签署了修改意见，我认为我已经完成了。 然后，我的一个同事在我的改动上运行了回归测试套件。 在每次修改编译器和运行时之后，我们都会这样做，只是为了确保我们不会意外地破坏任何东西。 不幸的是，我的几个回归测试都失败了。 当我发现为什么我的测试没有抓到它，尽管测试显然很彻底，我发现这些问题直到2038年才出现。 虽然我在时间例程中加入了1970年到1980年的十年，但我把2038年到2048年的十年删掉了。 果然，当我回过头来，每天都在这个范围内测试时，我证明了我的测试会发现问题，只要我要求它发现问题。

这里的教训是什么？ 我想最显而易见的是，如果你能测试所有的组合，那么要确保你真的测试了所有的组合。 也许一个更重要的教训是花时间建立一个回归测试套件。 它们是值得花费时间和精力的。 它们可以在你增强代码的过程中削减成本，缩短发现和修复问题的时间。 你不需要避免非常多的客户报告的问题来证明建立回归测试套件的成本。 我估计，在这个过程中，每增加一个阶段，修复软件问题的成本就会增加一个数量级。 由于任何流程中至少有4个阶段（设计、代码、测试、部署），所以事情很快就会变得昂贵。