自动化手动测试是否可以提供良好的自动化测试？

#1 楼

我考虑过的答案是肯定的“否”，我会走得更远，因为我认为盲目地自动化手动测试可能是自动化测试的反模式。

手动测试脚本由能够做出决定，判断和评估的测试人员执行。结果，手动测试通常能够覆盖处于大量测试条件下的被测系统的大部分区域。手动测试很容易成为一个庞大的描述，涵盖了应用程序的许多领域，这可能是非常有用的手动测试。但是，对于自动化测试而言，这不是一个明智的设计。

自动化测试试图涵盖手动测试涵盖的每个方面往往很脆弱。它们倾向于更频繁地中断，也很烦人，当遇到故障或错误时，自动化测试通常会完全停止，这意味着以后的步骤将无法执行。这可能意味着，为了完成测试运行，可能需要解决较大脚本的一些小问题。以我的经验，将这些断言放在单独的测试中要容易得多，以便其他测试可以独立运行。
随着时间的推移，我发现，试图从字面上复制手动测试脚本的大型自动化测试变得相当可观。维护头痛。特别是，当您真正想要运行它们时，它们往往会经常掉落。挫败感可能导致对自动化测试工作本身的幻想破灭。

盲目尝试使整个手动测试自动化也可能阻碍从测试自动化工作中获得最大收益。手动测试本身可能并不容易自动化，但是它的各个部分可能是自动化的，并且可以通过自动化来减少手动测试脚本的大小。

在尽可能短的时间内访问应用程序的多个区域时，手动测试脚本往往是最有效的。相比之下，自动化测试脚本在击中需要的应用程序区域时往往会更有效率。

可以说，自动化经常“涉及使已经存在的手动过程自动化的原因之一”使用正式测试过程的地方”是因为自动化通常是第一次引入已经具有手动测试的现有项目，这不可避免地导致人们倾向于简单地自动化现有的手动脚本。但是我会问自己，如果测试从一开始就是自动化的，我是否会设计与手动测试相同的测试？ -我觉得我的诚实回答是“不”。

因此，尽管现有的手动测试显然可以作为自动化测试的有用文档，因为它们可以显示当前正在测试的内容以及测试方式，但它们不应指示自动化测试的设计本身。在我看来，好的手动测试设计可以向人们解释如何最有效地测试应用程序的功能。良好的自动化测试设计可以使机器逻辑轻松快速地行使重要功能，而我认为这是非常不同的工程问题。

#2 楼

注意：这是一个社区维基问答

@testerab

不一定。以下是一些不建议使用自动化手动测试的原因：


某些测试可能更易于手动执行，因为它们可以快速手动执行，但会花费不成比例的编写自动测试代码的时间
某些测试可能会更容易手动执行，因为它们位于仍在快速变化的系统的一部分中，因此维护自动化测试的成本将超过快速执行它们的能力
许多测试可能更值得手动执行，因为人的大脑可以（并且应该！）询问许多无法在自动测试中捕获的问题（例如，此操作花费的时间是否比应该花费的时间长？为什么此时屏幕的一半被莫名其妙地覆盖着一个大的黑色方块呢？嗯，这似乎很不正常；完成测试后，我将对其进行检查，等等。）
上面的观点人类可以（也应该）使用“富含维生素比起自动测试中的编码逻辑，他们更容易进行测试（在书面的“预期结果”之上和之外）
将某些测试（实际上是很多）与已经存在于测试中的其他测试一起考虑测试集效率极低（例如，因为它们（a）在已经测试过的其他组合中具有高度重复性，并且（b）缺乏所达到的更多覆盖范围）；这种无效的测试通常不应手动执行，也不应转换为自动测试。
测试人员可能缺乏使手动测试很好地自动化的技能或时间。在这种情况下，最好继续使用手动脚本，而不是给自动化编写不当的维护工作带来负担。
自动化的手动测试很容易受到产品中轻微变化的影响，这些变化并不是真正的错误。它们可能成为可维护性问题。当它们失败时，它们并不是很诊断，在哪里更像“白盒”的测试可以非常有诊断性。
对人类来说容易进行的测试可能几乎无法自动化。 “此视频中的声音清晰吗？”即使是相当醉酒的人也可以完成这项测试，但是执行该测试的计算机程序几乎是科幻小说级的编程。两者都可以使用其他软件进行模拟，但是您需要验证其他软件以确保其正确模拟了硬件。
如果需要执行一组非常复杂的配置步骤以实现自动化一个测试用例，手动测试可能是最简单的。这也可能是一个非常罕见的测试用例的指示，可能不值得将其放入自动化套件中。
与进行开发工作一样，必须评估在测试过程中创建的任何工件的价值，以确定是否值得是否可以重用。如果自动化测试在首次运行后不可重用，则您实际上已经花费了资源来创建一些在使用后会“丢弃”的东西。手动测试可能只需使用文档中的一组快速指令即可执行一次，远比花费资源使其自动化更有效。

我希望这个答案会有所帮助；我邀请其他人来完善此不完整的列表。相反，手动测试可能会直接实现自动化的好迹象是：


如果测试包含非常详细的脚本，包括精确的检查
如果由熟练的测试人员运行手动脚本时，在那些特定的检查之外很少或从未发现有趣的错误，或者如果通过特殊测试通常可以更快地找到有趣的错误，脚本
如果该功能的更改不经常以破坏自动化的方式
如果执行手动脚本需要花费很多时间的测试时间
如果自动化这些脚本所花费的时间不会超过预期的时间花费了手动运行它们的任务，并且目前没有更高优先级的任务
如果执行手动脚本被运行它们的测试人员描述为BORING，但是不运行它们是不可行的，即使对该功能进行了临时测试。这是一个有力的信号，表明应该考虑某种自动化，可能还需要临时测试，因为无聊的测试人员通常是不好的测试人员。但是，请注意其他几点，以确定它应该是手动案例的直接移植，还是应该考虑自动化设计的新测试套件。
如果手动测试是一项任务/产品关键项目，必须退后超过初始发布日期。请注意，并非所有自动化都是回归自动化，但是回归测试是自动化极大提高ROI的地方。手动测试的价值将为其他项目和/或过程带来附加价值，值得创建自动化。测试过程中创建的可重复使用一次以上的任何工件都不会浪费精力。
如果手动测试列出了要在每个版本中执行的冒烟测试列表，请改进此内容。列表也不完整！

#3 楼

简单地自动化一组手动测试用例并没有什么好处，尤其是在没有领域知识的情况下。

决定是否自动化的一些因素是：


投资回报率。自动测试具有高投资回报率，这些乏味，高度重复，用户将频繁执行的掩盖动作，关键任务，涉及大量数据验证或这些因素的任意组合。相比之下，GUI检查和设置并忘记配置的投资回报率要低得多。
数据依赖性。如果测试高度依赖数据，但对输入数据的方式要求相对较小，则通常是自动化的理想选择。例如，在执行一系列测试后，自动执行SQL数据验证是有意义的。如果可以使测试成为数据驱动的，那将使其更加有效，因为可以通过简单地添加到测试数据存储中来添加新的测试用例。
外部接口。虽然可以模拟来自外部设备的输入，但不一定实际或不可能。同样，通过Mach 1 Eyeball打印某些东西并运行打印输出通常比以文件方式进行打印和以编程方式检查要容易得多，尤其是在处理封闭接口或应用程序的有限寿命测试版本时接口。
先决条件设置。有时需要花费大量的工作来自动化设置，最终这是一个简单的测试，可以通过手动测试轻松进行。

最终，目标应该是首先确定测试非常适合自动化的情况（在任何涉及税收计算的情况下，自动化看起来很有吸引力都不会花很长时间！），并根据上面的列表以及您的组织和应用程序需求不断进行重新评估。

我不会提倡没有领域知识的人自动化，因为领域知识对于确定应该自动化的内容至关重要。如果某个没有领域专业知识的人正在自动化，那么我希望他们会与领域专家一起确定要自动化的内容。

#4 楼

我认为这是一个很好的起点，只要您了解或计划创建一个流程来管理它们的增长，如何存储和组织以及如何将它们全部链接到您当前的开发和测试实践中。这是我过去一直在努力的事情。

例如，假设您正在使用cukes并构建一个巨大的功能/场景测试用例。这真的很有用，因为它可以配置整个部分的下拉列表，复选框，字段和值等。如果正确配置，它还可以确认是否在前端显示了正确的选项。

在这种情况下，最好的办法是编写并构建测试（在开发过程中的质量保证里程碑期间），将其添加到库中（这样它就可以运行并执行有用的测试），并确保将其拾取并转化为自己的方法称为validateOptions（或其他方法）。有点像内置的优化过程，可以定期检查测试用例和结构。

这样，将来，您只需要在测试中调用一种方法，而不必再次调用完整的方案并且您将监视和维护新库。

实施起来并不容易，但从长远来看确实有帮助。

如果您已经有了《手册》测试库已存储并记录在案，我认为没有更好的自动化起点。它还为您提供了有关投放和范围的指标。

#5 楼

我只会自动执行仅需要结果的重复性任务，或者仅在不需要其他操作的Selenium，Fitnesse或Web测试的情况下寻找文本验证。当您不关心GUI时，自动化是一个很好的选择，尽管您可以进行屏幕比较，但我不希望自动化这些测试，因为它们以后可能会很脆弱，尽管我通常可以自动化搜索或User之类的操作配置文件检查，将永远只显示定义的文本进行验证。这类测试将很少见。

我发现了“手动测试”，使我可以接触到该应用程序，以了解什么可以并且应该自动化，我不编写脚本然后制作它自动化测试。当然可以，但是除非您真正了解自动测试的目标，否则不要这样做。

#6 楼

我在回答另一个问题时提到了这一点。使手动测试自动化可以为您提供良好的自动化测试，但是除了最初的编码工作之外，还有其他成本。例如，需要记录自动化测试。通常，一旦测试自动化，除原始编码器外，每个人都不知道它的意图。您可能可以在记录手动测试的位置记录它们，但是随后必须使该文件与代码保持最新。默认情况下，这不会发生。或者，您可以将测试记录为代码中的注释，但同样，注释也必须保持最新，默认情况下，注释将保持最新，就像产品代码中的注释一样。

默认情况下，如果没有严格记录自动化，它将成为泄漏的抽象。自动化不是“自版本Y起对功能X的测试”，而是“功能X的测试”，甚至是“证明功能X起作用的事物”。一旦测试变成黑匣子，它就会被滥用，从这种意义上讲，自动测试比手动测试更糟糕，而不是更好。

#7 楼

不一定，尽管我倾向于相反的做法-将来我会自动进行空运行。
手动测试通常会跳过很长的重复任务，避免繁重的文本分析，或者无法在响应时间短的情况下进行测试。 />另一个问题是，您如何称呼“测试脚本”？这些是执行的完整详细步骤，或者只是对测试内容和预期结果的更高层次的描述，第一个不适合自动化，而第二个则很适合。