问数据驱动的测试模式- Pros和Cons和好的示例？

EN

当您有很多可以表示为参数空间中的点的测试用例时，数据驱动测试工作得很好。数据驱动方法的一些优点是：

• 测试用例比用代码表示时更容易添加或删除。
• 您复制的测试代码较少，因此在测试代码中不易发生代码/粘贴错误。
• 开发人员以外的其他人可能能够编写测试用例。

一些潜在的缺点是：

• 通常情况下，您的测试用例不能很容易地建模为参数空间中的点。一旦模型变得太复杂，表示测试用例的符号就像编程语言一样复杂。在这一点上，最好还是坚持使用编程语言。
• 引入新的测试参数可能需要编辑大量的测试用例。您可以在数据格式的详细性和可伸缩性之间进行权衡，例如，CSV表示可能不如JSON格式灵活，因为后者可能允许默认值。
• 如果数据存储在一个单独的文件中，那么您很容易受到与任何外部配置文件(例如Spring文件、翻译文件或log4j配置文件)相同的抱怨，也就是说，同时查看数据和代码有点困难。我认为这个问题是可以处理的。

我使用了一种数据驱动的方法来测试工作流，其中每个测试用例都是一系列(操作、预期状态、预期值)。

我还在比较器测试中使用了数据驱动测试，其中我使用一组请求比较两个不同版本的服务的行为。对于每个请求，我将请求发送到服务的两个版本，然后比较响应。如果反应不同，我可能发现了一个错误。这与功能测试不同，但仍然很有用。

最好的解释应该是一个例子--如果你需要测试一些东西--比如登录页面--测试的步骤并没有变化，但是输入(和输出)有数据驱动的测试要比很多测试用例要好得多--在登录页面示例中，用户和密码是唯一的区别。可以根据测试框架构建类似的方法，数据源可以是代码(数组/列表)、电子表格、CSV或其他文件。

数据驱动的测试可能有点难读，但我使用的模式是对以下列进行测试输入--如上面所示：

Enabled | TestName | User | Password | Login | Notes Y | baseline test | good-user | good-password | succeeds | if fails all wrong Y | bad password test | good-user | bad-password | fails | Y | disabled user test | disabled-user | good-password | fails | N | new test | new-user | new-password | fails | disable test until purpose clear

第一列是我将其编码到循环控件中的内容，以便在需要时可以跳过数据输入。第二种是可读性和日志记录。notes列只是添加关于该测试数据点的注释。

注意-当测试一组预期失败的负面条件时，我进行第一个测试/检查一个阳性测试，以确保如果数据是正确的，该操作将工作。如果这样做失败了，那么环境或测试中的某些内容是错误的。

使用基于文本的数据源来存储数据，而不是电子表格--这使得源代码管理系统中的更改更加清晰。

我会说使用数据驱动的测试，但是如果参数或预期输出的数量变得太大，那么它可能就不值得了。有了大量的输入或输出，您就失去了可读性，执行操作的代码可能变得过于复杂。

下面是关于数据驱动测试的更多信息：https://testautomationpatterns.org/wiki/index.php/DATA-DRIVEN_测试

我要在这里冒险，很可能是少数人的意见，但现在我要走了！

我避免使用它们！

现在我注意到你提到的第一个要点：

我是遗漏了什么，还是数据驱动的模式被高估了？

是的，对他们来说。我经常有初级工程师气喘吁吁地接近我，当他们发现它时，向我展示他们建造了什么，通常我会战战兢兢。

最具讽刺意味的是，我反对的部分是，他们实际上可以使它太容易进行测试！哇哦。让我解释一下:一旦你有了数据表，就很容易开始把这些情况乘以，通常一个很好的自由剂量的复制和粘贴就开始发生了。通常情况下，您将以数十个案例的形式来尝试各种组合。对于UI测试，这肯定会使测试套件非常缓慢和长时间运行。

他们也没有把重点放在具体的例子上，也没有给出关于这个问题的高质量的详细反馈。

我更喜欢BDD的“示例”样式，其中有一个完整的测试示例，它运行并指定条件、输入和边界的确切时间，并使用适当的语言以简单可读的语言描述条件。

总之，我确实认为他们有自己的位置。我说避免进行UI和集成测试。用于Unit和一些验收测试，但请确保它们没有严重或缓慢的依赖关系。例如，如果您有模拟和存根所有依赖项的单元测试，并且每个依赖项在0.01秒内运行，那么就可以使用几十行数据表驱动的测试了。请记住，一个人仍然需要维持，并且至少要经常读这些行。