如何使用多个步骤执行集成测试

时间:2014-05-28 21:16:57

标签: testing integration-testing assert

我在测试中读过很多关于多个断言的问题。有些人反对它,有些人认为没关系。但是我开始想知道如何通过更长时间的测试来完成它。

例如,使用Android设备进行此测试:

  1. 启动wifi
  2. 安装应用
  3. 卸载应用
  4. 停止wifi
  5. 运行测试几次

    由于我想多次运行它并始终按此顺序进行,因此必须进行单次测试(?)。所以我在路上被迫做了四个断言:

    1. 检查wifi是否已打开。
    2. 检查应用是否已安装。
    3. 检查应用是否已卸载。
    4. 检查wifi是否已关闭。
    5. 测试没问题

      这是错的还是丑的?我没有看到如何在不分割测试的情况下摆脱它,因为我认为它只是一个测试用例,但它似乎也是错误的。

2 个答案:

答案 0 :(得分:0)

根据我对描述的理解:是的,这是错误的,因为这部分

  

始终按此顺序

隔离良好的单元测试(不依赖于其他测试),其结果不依赖于特定的执行顺序。这很重要,因为许多框架根本无法保证执行顺序。

我认为您可以在多个测试中分割该测试。请记住,为了测试某些东西,您可能需要更改它之前的状态(这是您启动/停止WIFI所做的),因此这是难以克服的。

这可能是你的测试布局:

StartWifi
StopWifi
InstallApp_WithWifiStarted_InstallsSuccesfully
InstallApp_WithoutWifiStarted_AbortsInstallation

并继续像这样卸载(我不确定它的要求是什么)。

通过这些测试,您现在将了解以下内容:

  • 可以启动wifi服务
  • 可以停止wifi服务
  • 使用wifi安装应用程序
  • 安装没有wifi的应用程序不起作用

然而,对于您的单一测试,您只能从失败中推断整个生产线出现问题,但不清楚在哪里。问题本来可以在

找到
  • 启动wifi
  • 安装应用
  • 卸载应用
  • 停止wifi

使用单独的较小的测试,您可以排除那些不适用的测试,因为它们可以自行工作。

[此时我注意到您已将标签从单元测试更改为集成测试]

重要的是要注意,你所做的事情并不是很糟糕:较大的单位也很适合测试,尽管如你所说,这是你接近集成测试的地方。

使用单元测试和集成测试作为补充测试方法非常重要:通过进行这些较小的单元测试和更大的集成测试,您可以验证较小的部件是否有效以及它们的组合是否有效。 / p>


结论:是的,在您的测试中有几个断言是可以的,但请确保您还有较小的测试来测试独立单元。

答案 1 :(得分:0)

是的,在单个测试中使用多个断言很好。你的测试是一个集成测试,它看起来像一个验收测试,对于那些(系统的很大一部分运行)有很多断言是正常的。但是,应该只有一个断言。

为了说明这一点,我认为您需要测试您正在测试的功能的四个测试(仅考虑快乐路径):

  • 测试可以打开wifi。

    • 打开wifi。
    • 断言wifi已开启。
    • 关闭wifi。

  • 测试wifi是否可以关闭:

    • 打开wifi。
    • 关闭wifi。
    • 断言wifi已关闭。

  • 测试是否可以安装该应用程序:

    • 打开wifi。
    • 安装应用程序
    • 断言已安装该应用程序。
    • 关闭wifi。
    • 卸载应用程序(如果需要这样做以进行清理)。

  • 测试是否可以卸载应用程序:

    • 打开wifi。
    • 安装应用程序。
    • 卸载该应用程序。
    • 断言应用程序已卸载。
    • 关闭wifi。

每个测试只测试一个动作。可能需要多个语言级别的断言来测试该操作是否完成了它应该执行的所有操作;没关系。重点是断言只有一个,并且它在测试结束时(不计算清理步骤)。需要设置代码的测试不需要断言该设置代码是否成功;那已经在另一个测试中完成了。同样,在清理步骤中使用的操作(断言后面的步骤)在一个地方进行测试,并且在用于清理时不需要再次测试。每个动作都在一个地方进行测试。结果是,您只需要阅读一个测试以了解一个功能应该如何运行,并且如果功能的行为方式发生变化,您更可能只需要更改一个测试。

相关问题