Answers:
首先，我想说的是我做的所有事情都是SQL Server，所以这些就是我给出的示例。但是总的来说，这适用于任何形式的代码，而与系统无关。
让我们首先将其分解。
您有一个系统，并且即将升级部分或全部系统。例如，将实例从SQL Server 2012升级到2014。此时，测试是必不可少的。不幸的是，即使是小型应用程序的每个部分也可能无法测试。到那时，我将进行所谓的“工作”测试。基本系统是否正常运行。完成您的常见任务开始。不要测试所有选项，而只是测试主路径。
在进行SQL Server升级时，还需要阅读一些内容。基本上，您想阅读Backward Compatibility新版本的条目（这是2014版），并确保任何列表中都没有任何内容（重大更改，行为更改等）。
在这里，我们正在研究新的/更改的应用程序代码（因为现有的任何东西都已经过测试，对吗？）。在这种情况下，应进行所有测试。您应该提前设置测试用例，并至少通过大多数受影响的功能来运行。最好此时，您还应该让其他人进行类似的检查。该代码可能会存在很长时间，并且会被大量人使用。您想确保它能正常工作。
真正有助于解决问题的一件事就是生成一组unit tests易于重复的内容。 史蒂夫·琼斯（Steve Jones）建议使用tSQLt来测试您的TSQL代码（恐怕只有SQL Server）。但是通过这样做，您可以快速进行一组固定的测试，这确实有助于回归测试（测试所有内容，例如在升级之前进行测试）。
您不仅要对应用程序代码进行更改，还希望彻底测试新功能和配置更改。例如，如果您决定开始使用列存储索引第一次，您将需要测试涉及受影响表的每段代码。使用生成的单元测试来测试应用程序。这些功能可能对您来说是新功能（可能是平台中的新功能），并且可能会有一些您没有想到的陷阱。至于配置更改，您所谈论的是可能会影响整个系统的事情。经验法则是测试，并仔细测试。在进入活动系统（可能只有生产系统）之前，您不会真正看到一些更改，但这不是没有在测试环境中首先尝试它们的借口。
如果您有影响用户数据的代码，则通常需要对其进行测试，甚至可能是因为Ad Hoc。话虽这么说，如果您一次又一次地运行同一段代码，只是使用不同的参数，那么您可能不必担心每次测试。
例如，您需要每季度从AdList表中删除一个或多个广告。
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')到那时，您已经测试了代码（您只是在更改固定的字符串），并且仅运行代码就可能相当安全（假设您有很好的备份以防万一）。
一个简单的方法来测试DELETE，UPDATE或者INSERT是将其更改为一个SELECT和运行它们，然后确认你所期望的行数和类型返回。
您可能会认为您不需要测试SELECTs，因为它们实际上并未更改任何数据。但是，您运行代码的原因是对的吗？假设您正在为经理做研究，经理将把这些数据交给他们的经理，依此类推。您进行测试以确保您没有收到错误的数据（或阻止其他人收集其数据）。
这可能是“测试一切”规则的一个例外。您正在对系统数据运行信息查询。这里重要的是取回您期望的数据。如果查询很简单（查询系统视图），那么只要检查了视图/列的真正含义，您就可以了。如果查询很复杂（例如打3或4个系统视图，并在返回的列上进行计算），则您可能需要运行一些测试，以确保可以取回期望的数据。
总之，是的，您想测试所有内容。如果对您来说编写和运行它足够重要，那么对您进行测试就足够重要。但是，这并不意味着您必须花费大量时间来测试每一行代码的每个分支。但是需要进行一些测试。
自动化单元测试是您的朋友。随着的到来DevOps和Continuous Integration你会看到越来越多的应用和快速，方便地测试你的代码的方法。当然，这确实需要具有良好的测试环境和数据，但这是一个完全不同的讨论。