自动化脚本的测试

Question

人们通常会对您的自动化脚本进行多少测试？

最好将自动化测试套件作为一个单独的项目，还是您正在测试的产品的敏捷开发周期的一部分？

作为编写和运行自动化测试套件的唯一QA人员，您真的对脚本的健壮性和正确性有信心吗？

有什么建议吗？

Answer 1

我认为除了运行测试用例和进行代码评审之外，测试用例本身是没有意义的。然而，测试可重用的测试代码是有意义的；问题是它是否有足够的意义来证明所投入的时间是合理的。我认为这个问题需要一个组成部分一个一个地回答。

除了运行测试用例之外，我通常不会对测试代码进行测试，因为我创建测试用例是为了确保它们按照预期运行。我已经意识到，每次运行测试用例时，我运行的测试用例都在隐式地测试我的测试工具/夹具。在对先前测试过的项目上的测试代码进行重大更改之后，我确实执行了测试运行，以确保在同一段代码上不会得到不同的测试结果。得到不同的结果将提示测试代码错误，因此对其他特性的回归测试最终也是对我的测试代码的回归测试。通常，我发现测试和测试代码倾向于“测试自己”，因为大多数测试错误都会导致测试检查失败。最大的例外是测试工具，它存在于任何测试之前，并获得一些基本测试，以确保正确地记录通过和失败，正确地从DB加载数据等等。

我偶尔会在测试用例没有测试我认为的测试用例的地方发现测试错误。但是，这些问题很少是由测试代码错误IME引起的(在第一次成功运行之后)，并且通常是由错误的规范或错误的测试数据(例如，通过测试运行错误的文件)造成的。这些类型的bug很难测试；错误的规范最好是通过强烈的好奇心来发现，而坏的测试数据通常只在错误没有导致测试失败，而是应该失败时才被发现，并且是通过其他一些方法(通常是另一个隐含测试该行为的测试用例)来检测的。

IME，所有测试都需要以一种或另一种形式处理待办事项，但细节并不那么重要。我们目前让测试工具改变他们自己的用户故事，但是固定装置和测试用例是正在测试的相关用户故事上的任务。我用另一种方式做了，所有的测试都被跟踪为自己的项目，但这往往会隐藏更多的测试。我认为最重要的是，测试会被记录下来，当人们做出调度决策时，测试会被认真对待，并引起人们的注意。

我知道我的测试质量很好，当我看到我的测试发现了很多错误，很少有bug通过。当我看到我发现了多少bug和产品的质量之间有很强的相关性时，我可以猜到我的测试质量是好的。也有一些情况下，我有“并行测试”软件，我自己自动化和黑匣子测试使用探索性技术。我发现，我们发现相同数量的bug，80%是相同的问题，大约20%是不同的，但同样的严重程度和优先级，在同一时间框架内。这让我对我的测试自动化技能有了更多的信心。

然而，一些测试人员使用诸如突变测试之类的技术来做更多的事情。突变测试是指对被测试的系统进行一组人为的(可能是随机的)小改变。接下来的问题是，您的测试是否捕捉到了这些更改？如果产品代码在没有死代码的情况下设计得很好，那么您应该选择那些回归。“美丽的测试”在书的第三部分(第18章)中有一个关于突变测试的章节。

Answer 2

不幸的是，在我工作的地方，你第一个问题的答案是“不够”。

您的第二个问题，我想说，您应该把自动化作为被测试的应用程序的敏捷开发周期的一部分。用户故事的测试是自动化的，因为它们是由您开发和访问的，然后每次运行脚本都会自动地对所有以前的测试用例进行回归(我建议分别对自动化进行调度，这样您就可以在使用新功能的同时进行稳定的开发并运行)。

对于你的第三个问题，如果你不能让其他人检查你的测试脚本，那么它们的功能和产生正确反应的能力就是你的自信程度。这意味着您需要定义和验证您知道的准确的基线，以及正确的工作流。如果您更新脚本以考虑应用程序更改的时间超过了新的开发时间，这是一个合理的指示，说明您的脚本可能更健壮。例如，如果您需要4个小时来添加一个新的测试，重新生成基线并验证您的新基线是否准确，但是您需要6个小时才能更新脚本的其他部分来处理对应用程序流或结构的更改，您没有一个非常健壮的套件，可能会使您的脚本更加模块化。

希望这能给你找个地方找。

Answer 3

当我编写GUI自动化测试套件时，我发现最好将它作为一个单独的项目来处理。

在测试逻辑级别上，我没有发现为自动化测试编写自动化测试很好地利用了时间。然而，在较低的层次上，我发现它非常有用。

例如，我可能编写一个处理win32对话框的通用组件，它将检测对话框、读取消息并正确关闭对话框。当我在测试脚本中使用它时，我希望它能够满足以下情况：

• 如果对话框不像预期的那样出现怎么办？
• 如果出现了不同的dialog怎么办？
• 如果，由于某种原因，对话框没有关闭呢？(with某些工具，这可能导致整个测试运行无限期挂起)

最重要的是：

• 如果我需要更新这个组件呢？对于我所有的自动化测试，它还能正常工作吗？

因此，我可以创建一个简单的网页来模拟每个对话框场景，以及一个简单的测试，并测试我的对话框处理组件可以处理每一种情况。然后，当我对它进行更新时，我可以再次运行测试，并知道我没有损坏任何东西。它比再次运行整个测试套件要快得多，而且我对驱动测试套件的健壮代码有一些信心。