在这种情况下，运行测试提醒您它虽然跳过了测试，但是它不会使您失望。实际上，它给您评为 Pass-Fail-Incomplete。
您能够找到很多可以为您自动编写测试的工具。然而，这些工具生成的测试往往相当琐碎和基本，例如方法是否能够处理传递来的 null 参数。这种工具不能真正了解每个类和方法应有的功能。所以，您需要人类的智能。
处理失效代码
在这一阶段很可能会令您吃惊的是，您的代码中有多少是您实际上并不需要的。遗留代码基础往往具有很多残留代码，这些代码现在已经不需要了，尽管在当时是必需的。越老的遗留代码，您会找到越多的残留代码。有时候，这些代码是明显不可达的（未调用的私有方法以及未读入的本地变量，等等）。这种类型的残留代码也可以通过静态代码分析工具如 PMD 和 FindBugs 找到。有时失效代码看起来并不是那么明显，只有为了测试试图到达它时才能发现实际上的残留程度。
不管您用何种办法找到这种残留代码或者无论任何理由 它原来被放在这里，都将它去掉。您需要维护的代码越少越好。
探索性测试
进入一个遗留系统，您常常对哪里进行检查有好的想法：您对于某个特定的模块、程序包或者是环境设置有问题，这些问题驱使您进行测试。在这种情况下，尽一些办法使您的测试集中在那个区域。
有时会发现非常清楚和明显的 bug。修复它之前，首先编写一个测试。然后运行这个测试证实测试失败。然而，经常令人吃惊的是，关于这个 bug 的第一直觉并不正确，测试通过了。测试失败与否，都不要把它丢掉。它对于将来的开发仍然是有价值的。把它放在您的测试套件中，继续编写其他的测试。重复进行，直到找到一个真正失败的测试，从而找到造成 bug 的真正原因。
结束语
不要过分追求完美。即使您有一个大规模的未经测试的遗留代码基础，现在就开始为它编写测试吧。不要为达到获得百分之百的覆盖率过多担心。您所编写的每个测试都会增加您对代码的信心、排除 bug 并且为将来的开发提供更多的灵活性。需要增加一个特性？编写一个测试。找到一个 bug？编写另外一个测试。遗留程序员也可以很灵活。
文章来源于领测软件测试网 https://www.ltesting.net/
