测试自动化脚本

#1 楼

我认为，除了运行测试案例并进行代码审查之外，测试测试案例本身没有任何意义。但是，测试可重用的测试代码是有道理的。问题是，是否有足够的理由证明将要花费的时间是合理的。我认为这个问题需要逐个组件地回答。我已经意识到，我运行的测试用例在每次运行这些测试用例时都会隐式地测试我的测试工具/夹具。在对先前测试的项目中的测试代码进行重大更改之后，我确实执行了测试运行，以确保在同一段代码上不会得到不同的测试结果。获得不同的结果将表明存在测试代码错误，因此针对其他功能的回归测试最终也将成为我的测试代码的回归测试。通常，我发现测试和测试代码倾向于“自我测试”，因为大多数测试错误会导致测试检查失败。最大的例外是测试工具，它在进行任何测试之前就已存在，并获得一些基本测试以确保正确记录通过和失败，从数据库正确加载数据等。

偶尔会发现测试用例无法测试我认为是什么的测试错误。但是，这些很少是由测试代码错误IME（在首次成功运行后）引起的，通常是由规范不正确或测试数据不正确（例如，通过测试运行错误的文件）引起的。这些错误很难测试。最好通过强烈的好奇心来发现不良规格，并且通常仅在错误不会使测试失败但应该通过的错误时才发现不良测试数据，并且可以通过其他方式（通常是另一个隐式测试该行为的测试用例）来检测不良数据。

IME，所有测试都需要以一种或另一种形式进入待办事项列表，但具体细节并不重要。当前，我们使测试工具更改其自己的用户故事，但是固定装置和测试用例是要测试的相关用户故事的任务。我以另一种方式完成了所有测试都作为其自己的项目进行跟踪，但这往往会使测试隐藏更多。我认为最主要的是将测试记录下来，将其认真对待并在人们制定计划决策时引起注意。很多错误，很少有错误通过。当我发现发现的错误与产品的质量之间存在很强的相关性时，我可以猜测我的测试质量很好。在某些情况下，我会使用“并行测试”软件，自己进行自动化，并使用探索性技术进行黑盒测试。我发现我们发现了相同数量的错误，其中80％是相同的问题，大约20％是不同的，但在相同的时间范围内具有相同的严重性和优先级。这使我对自己的测试自动化技能有了更大的信心。变异测试是指对被测系统进行一组人为的（也许是随机的）小更改时。问题就变成了，您的测试是否抓住了这些变化？如果生产代码经过精心设计而没有死代码，则应该选择这些回归。 “ Beautiful Testing”在本书的第三部分中有一个有关突变测试的章节（第18章）。

#2 楼

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

第二个问题，我想说您应该将自动化视为被测应用程序的敏捷开发周期的一部分。在开发和访问用户故事时，它们会自动进行测试，然后每次运行脚本都会自动回归所有以前的测试用例（我建议单独安排自动化，以便您可以注销稳定的开发并获得在使用新功能的同时运行）。

关于第三个问题，如果您没有其他人可以查看您的测试脚本，则它们的功能和生成正确响应的能力就是您的信心。这意味着您需要定义和验证已知准确的基准，以及正确的工作流程。如果您更新脚本以应对应用程序更改的时间超过了新开发时间，则可以合理地表明您的脚本可能更健壮。例如，如果您需要4个小时来添加新测试，重新生成基准并验证新基准是否正确，但是更新脚本的其他部分来处理应用程序流程或结构更改则需要6个小时，您没有一个非常强大的套件，可能会使脚本更加模块化。

#3 楼

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

在测试逻辑级别，我发现没有时间来编写用于自动化测试的自动化测试。但是，在较低的级别上，我发现它非常有用。例如，我可能会编写一个用于处理win32对话框的通用组件，它将检测对话框，读取消息并正确关闭对话框。当我在测试脚本中使用此脚本时，我希望它可以满足以下情况：
如果出现其他对话框怎么办？
如果出于某种原因，
对话框没有关闭怎么办？ （使用某些工具，这可能会导致整个
测试运行无限期挂起）

，最重要的是：


是否需要更新此
组件？它对于我的所有自动化测试仍然可以正确运行吗？

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

#4 楼

取决于您对它们进行的复杂程度，自动化测试本身就是一个开发项目。就我自己而言，我一直将我的自动化测试代码提交给同行，以供他们检查我的逻辑并查看是否有任何问题。我也尽力确保我至少执行一次每个代码路径，以确保所有内容都能正常运行。自己的项目。如果正在进行敏捷开发，则需要执行一些任务来为项目调整/添加/创建新的自动化代码。

#5 楼

对于您的第一个问题，不可能使所有事情自动化，并且有很多关于如何决定自动化的思路，但是我的一般经验法则是根据每个功能的需求优先级来自动化测试用例的采样。有些测试比其他测试重要。与“记录是否正确排序？”相比，“可以添加/编辑/删除该记录”是一个更重要的问题。

第二点，我认为这取决于自动化的类型，以及向套件中添加其他测试的耗时。 GUI自动化需要功能性功能，因此很难包含在敏捷过程中。较低级别的单元测试和功能测试可以包括在开发工作中，测试人员可以与开发人员合作创建测试。

第三点，您的自动化测试是否发现了错误？他们是否阻止了一些使观众停下脚步的问题？您的部门是否依靠测试来检查功能区域，以节省执行手动回归的时间？

如果您对上述任何一个问题的回答是肯定的，我认为您应该为自己所做的工作感到自豪，并对此充满信心。就是说，您不应该停止尝试改善所做的工作以使其变得更好。安排一些时间与团队中的开发人员会面，以解释测试涵盖的内容以及工作方式。他们可能对您有一些好主意。

#6 楼

我会就我的工作职位回答他们-


我确实确保测试失败时会失败，为此，我需要在脚本中模拟错误的错误进行检查如果真的失败了。
在我的工作中，它是敏捷开发生命周期的一部分。在开发人员进行开发的过程中，我经常进行自动化脚本的工作（尽管在UI可用之前，我无法访问测试钩子）
有点困难，我通常会请其他人（团队之外）来检查我的代码，执行它，如果有更好的选择，请给我反馈。但是，如果没有可用的代码，请查看您自己的代码。可能过一阵子你就写了。您自己可能会找到更好的方法。好吧...

#7 楼

为了使您的问题井井有条（因为我经常进行此练习）


我会尽力而为，包括请其他人对其进行审查或运行脚本
自动化应该总是被视为一个项目，因为它具有相同的最终结果，这是人们会使用的产品。以其他方式对待它最终会导致某些东西没有可维护性，并且基本上只能一次性使用。 ，发布给使用它的人，与人们交谈并记录一切。您不会永远在那里，并且希望下一个人在工作中度过轻松的时光，否则您离开时将被废弃，并且您不希望那样地对待时间

玩得开心！

#8 楼

在我之前的项目中，每次提交源代码控制系统时，我们都会在测试脚本的核心上运行一组单元测试。目的是确保我们不会破坏会影响整个自动化的重要基本功能（记录器，解析器等）。