0

我在测试自动化中遇到了设计问题：-

要求 - 需要通过自动化框架测试不同的服务器（使用 unix 控制台而不是 GUI）。我要运行的测试——单元、系统、集成

问题：在设计测试用例时，我认为测试用例应该是测试套件的一部分（测试套件是一个类），就像我们在 Python 的 pyunit 框架中一样。但是，我们应该将测试用例作为可扩展自动化框架的函数，还是应该将测试用例作为单独的类（每个类都有自己的设置、运行和拆卸方法）？从自动化的角度来看，将测试用例作为一个类的想法是更具可扩展性、可维护性还是作为一个函数？

4

2 回答 2

0

通常测试用例用作类而不是函数，因为每个测试用例都有自己的设置数据和初始化机制。将测试用例实现为单个功能不仅会使在运行任何测试用例之前设置测试数据变得困难，而且是的，如果您运行相同的测试场景，您可以在测试用例类中使用不同的测试方法。

于 2012-10-13T08:38:58.047 回答
0

以下是我的看法：

将测试编写为函数的优点：

  • 如果您需要该测试用例的任何先决条件，只需调用另一个提供先决条件的函数。对拆解步骤做同样的事情
  • 对于团队中的新人来说看起来很简单。通过将测试视为函数，易于理解正在发生的事情

将测试编写为函数的缺点：

  • 不可维护 - 因为如果有大量测试需要相同类型的先决条件，测试用例作者必须保持调用测试用例中的每个先决条件函数。测试用例中的每次拆解都相同

  • 如果在很多测试用例中有这么多对这样一个先决条件函数的调用，并且如果产品功能等发生任何变化，您必须在很多地方再次手动做出努力。

将测试用例编写为类的优点：

  • 设置、运行和拆卸都有明确的定义。测试先决条件很容易理解
  • 如果有测试 1 正在做某事，并且测试 1 的结果用作测试 2 和 3 中的设置先决条件，那么它很容易从测试 1 继承，并调用其设置，首先运行拆卸方法，然后然后，继续您的测试。这有助于使测试彼此独立。在这里，您无需努力维护代码的实际调用。由于继承，它将隐式完成。
  • 有时，如果 Test 1 的 setup 方法和 Test 2 的 run 方法可能成为另一个 Test 3 的先决条件。在这种情况下，只需继承 Test 1 和 Test 2 类，并在 Test 3 的 setup 方法中，调用测试 1 的设置和测试 2 的运行。同样，您不需要维护实际代码的调用，因为您正在调用设置和运行方法，这些方法从框架的角度进行了尝试和测试。

将测试用例编写为类的缺点：

  • 当测试数量增加时，您无法查看特定测试并说出它的作用，因为它可能继承了太多您无法回溯的级别。但是，有一个解决方案 - 在每个测试用例的每个设置、运行、拆卸方法中编写文档字符串。并且，编写一个自定义包装器来为每个测试用例生成文档字符串。继承时/之后，您应该提供一个选项来将特定函数（设置、运行、拆卸）的文档字符串添加/删除到继承的函数中。这样，您可以运行该包装器并从其文档字符串中获取有关测试用例的信息
于 2012-10-13T09:06:38.530 回答