c# - 为什么编码的 UI 测试自动化很重要？

Question

我是测试应用程序主题的新手。几天前开始在 Internet 上冲浪以查找一些有用的教程。老实说，我可以找到一些很好的视频，让我大致了解如何使用 MS Visual Studio 2010 进行一些编码 UI 测试自动化、数据库单元测试以及单元测试。但我仍然有很多问题。例如，CUIT 的自动化只是记录我在自己运行应用程序和测试时所做的事情。所以呢..？它只是记录我的行为。这实际上是我在传统上测试应用程序。我知道并且确信一定有一些我不知道的原因！谁能向我解释一下自动化编码的 UI 测试如何帮助我？另一方面，关于数据库单元测试也有类似的问题。我' 我在 YouTube 上找到了一个视频教程，解释了一个例子。它只是简单地检查存储过程是否正常工作！显然，当我运行我的应用程序（按 F5）时，我将简单地了解插入 SP 是否工作正常！因此，我无法理解数据库单元测试的作用是什么？如果有人能给我一个想法或任何有用的链接，我将提前感激不尽。谢谢，

Answer 1

拥有自动化测试的一大优势是它让您有信心更改和修复事物并添加功能，而不必担心某些东西会损坏的可能性，或者会有意想不到的副作用。在每次更改后运行预编码测试既简单又便宜，因此即使在开发周期的后期，您也可以进行风险最大的更改，并且仍然确信您的应用程序仍然是好的。

另一个优点是：假设您编写的某些新代码确实会破坏或更改某些现有功能。然后，您有一个简单的方法来发现一个列表到底发生了什么变化（只需运行自动化测试并查看结果！），然后您可以对这些变化进行推理，并将它们分类为错误，实际需要的副作用/变化等等。否则，开发很快就会变成“前进一步，后退两步”的混乱——每次签入都可能解决一个问题并引入两个新问题。即使开发人员知道这两个新问题（并非总是如此），尽管他们的意图是最好的，但他们稍后会忘记解决这些新问题。

您说您可以“只运行一个 SP”或“只运行”自己的 UI。但这并不能扩展......同样，理想情况下，您希望能够在每次更改后自动运行 1000 次测试，而无需支付任何费用，这意味着它们必须是自动化的。此外，您说您仅通过运行应用程序就知道 SP 是否在工作……但是随着您的数据库和应用程序变得越来越复杂，您在应用程序中实际测试所需要做的事情变得越来越不明显您的数据库正确。此外，如果稍后您需要创建使用相同数据库的第二个应用程序怎么办？（例如，您现在有一个网站，以后需要为管理员创建一些命令行工具）。

当有多个人在同一段代码上工作时，所有这些都变得更加重要，原因很明显。如果没有良好的自动化测试覆盖率，复杂的代码片段很快就会成为一个人的领域（“不要在不与 Joe 交谈的情况下触摸该代码！”）。

当然，这并不意味着你应该盲目地将所有可用的测试技术应用于所有项目，尤其是像 CUIT 这样相对“昂贵”的 oves（它可能很昂贵，因为如果你的 UI 在项目过程中变化很大，这种类型的测试可能更难更新）。相反，您应该对项目中的真正风险区域（如果您愿意的话，“错误农场”）进行适当的评估，以及在周期中引入每种类型的测试的正确时间——即有一个实际的测试计划。最后一段是我的观点，显然有不同的方法来选择什么/如何/何时测试。

Answer 2

关于记录您操作的测试软件的注释，这在尝试复制错误时非常方便，特别是在您第一次开始编写测试时。

就像 Eugene 指出的那样，当您获得多个编码器时，事情会变得更加复杂，我还想补充一点，当软件必须与其他组件（例如服务器、其他软件包）交互时，它会很快变得非常复杂。假设其他组件是完美的并不总是一个安全的赌注。因此，自动化测试的想法是，在您继续编写软件的同时，您可以针对之前完成的所有内容进行测试，而无需进行任何工作。例如，我编写了一个使用蓝牙连接的程序，但我添加了 WiFi，我可以针对 Wifi 使用大多数（如果不是全部）蓝牙测试用例。在 UI 示例中，假设您添加了一个新按钮，在此过程中您不小心破坏了一个旧按钮，如果您有 10 个按钮并且它与新按钮无关，所以您不要

如果您需要更多关于测试的理由，我强烈建议您阅读持续集成，它展示了您应该测试的原因和好处，并提供了如何进行测试的示例。它也有一些关于数据库测试的例子！

我希望这会有所帮助，我也是测试新手，但在短时间内学到了很多东西。

Answer 3

我不记得我在哪里看到的，但它很好地总结了单元测试。

“写得好的单元测试找不到错误......但它肯定可以找到回归”