如何编写自动化测试-将测试用例作为函数或将测试用例作为类

Question

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

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

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

Answer 1

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

Answer 2

以下是我的意见：

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

• 如果您需要该测试用例的任何先决条件，则只需调用另一个提供先决条件的函数即可。 对拆卸步骤执行相同的操作
• 对于团队中的新手来说看起来很简单。 通过将测试视为函数可以轻松理解正在发生的事情

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

• 不可维护-因为如果存在大量需要相同先决条件的测试，则测试用例作者必须维护调用测试用例中的每个必备功能。 测试用例中的每个拆解都相同

• 如果在许多测试用例中有如此多的对此类必备功能的调用，并且产品功能等发生任何变化，则您必须在许多地方再次手动进行工作。

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

• 设置，运行和拆卸均已明确定义。 测试先决条件很容易理解
• 如果存在要执行某项操作的Test 1，并且将Test 1的结果用作Test 2和3中的设置先决条件，则可以轻松地从Test 1继承它，并调用其设置，首先运行拆卸方法，然后然后，继续测试。 这有助于使测试彼此独立。 在这里，您不需要付出任何努力来维护代码的实际调用。 由于继承，它将隐式完成。
• 有时，如果Test 1的设置方法和Test 2的运行方法可能成为另一个Test 3的先决条件。在这种情况下，只需继承Test 1和Test 2类，并在Test 3的setup方法中调用测试1的设置和测试2的运行。再次，您不需要维护实际代码的调用，因为您正在调用setup和run方法，这些方法是从框架的角度进行尝试和测试的。

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

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