ZX9*_*ZX9 12 database-design testing learning features configuration
是否有任何时候您对您的语言/数据库/系统变得如此熟悉，以至于无需测试新功能/配置/查询/等。在您的系统中实施之前通过包含/模拟测试（特别是关于修改数据的功能）？还是在测试环境中通过模拟来测试新查询总是必不可少的？
进一步说明，很明显，测试总是最安全的。但是，有没有一种方法可以确定何时风险如此之小以至于测试不值得付出努力？另一种表述方式：何时或曾经是专业的实践来承担风险来实现一个功能？
此外，让我们假设所有内容都已备份，因此，在最坏的情况下，数据可能通过一些努力来恢复数据。
有人可以引用具体的专家经验来解决这个问题吗？请在适当/可能的情况下包括参考文献。
Ken*_*her 10
我想首先说我所做的一切都是 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')
那时您已经测试了代码（您只是更改了固定字符串）并且运行代码可能相当安全（假设您有良好的备份以防万一）。
测试 a 的一种简单方法DELETE，UPDATE或者INSERT是将它们更改为 SELECT 并运行它们，然后确认返回了您期望的行数和类型。
您可能认为您不需要测试SELECTs，因为它们实际上不会更改任何数据。但是，您出于某种原因运行代码，对吗？假设您正在为您的经理做研究，他会将这些数据交给他们的经理等等。您进行测试以确保您没有得到错误的数据（或阻止其他人收集他们的数据）。
这可能是“测试一切”规则的一个例外。您正在对系统数据运行信息查询。这里重要的是取回您期望的数据。如果查询很简单（查询系统视图），那么只要您检查了视图/列的真正含义，就可以了。如果查询很复杂（比如在返回的列上使用 3 或 4 个系统视图进行计算），那么您可能需要运行一些测试，以确保您将返回您期望的数据。
总之，是的，您想测试一切。如果它对您编写并运行它足够重要，那么它对您进行测试就足够重要了。然而，这并不意味着您必须花费大量时间来测试每一行代码的每个分支。但是需要进行一定程度的测试。
自动化单元测试是您的朋友。随着DevOpsand的出现，Continuous Integration您将看到越来越多的应用程序和方法可以快速轻松地测试您的代码。当然，这确实需要有一个良好的测试环境和数据来配合，但这是一个完全不同的讨论。