问自动化手动测试是否为您提供了良好的自动化测试？

EN

对此，我深思熟虑的回答是“不”，我会更进一步，因为我认为盲目地自动化手动测试可能是一种自动化的测试反模式。

手动测试脚本由能够做出决策、判断和评估的测试人员执行。因此，手动测试通常能够覆盖被测试系统的大部分区域，达到大量的测试条件。手动测试很容易成为一个庞大的、覆盖应用程序许多领域的描述，这可能是一个非常有用的手动测试。然而，对于自动化测试来说，这并不是一个可取的设计。

试图覆盖手动测试所涵盖的每一点的自动化测试往往是脆弱的。他们倾向于更频繁地崩溃，而且还会让人恼火的是，当自动测试遇到故障或错误时，它通常会完全停止，这意味着以后的步骤不会运行。这可能意味着，为了完成测试运行，需要解决更大脚本的一些小问题。根据我的经验，在单独的测试中使用这些断言要容易得多，这样其他测试就可以独立运行。随着时间的推移，我发现，试图复制手动测试脚本的大型自动化测试，已经成为一个相当棘手的维护问题。特别是，当你真的想要运行它们时，它们往往会掉下来。这种挫折感可能会导致对自动化测试本身的重大失望。

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

在尽可能短的时间内访问尽可能多的应用程序区域时，手动测试脚本往往是最有效的。相反，自动化测试脚本在按需要访问应用程序的少数区域时往往会更高效。

可以说，自动化常常“涉及自动化已经到位的使用正式测试过程的手动过程”的原因之一是，自动化常常首次引入到已经进行手动测试的现有项目中，这可能不可避免地导致简单地自动化现有的手动脚本。不过，我会问自己，如果测试从一开始就被自动化了，我是否会像手工测试一样设计测试？--我觉得我诚实的回答是“不”。

因此，尽管现有的手动测试显然可以成为自动化测试的有用文档，因为它们可以显示当前正在测试的内容以及如何测试，但它们不应该规定自动化测试本身的设计。在我看来，好的手工测试设计向人类解释了如何最有效地测试应用程序的特性；良好的自动化测试设计使机器逻辑更容易快速地执行重要功能，在我看来，这些都是非常不同的工程问题。

注意:这是一个社区WIKI答案

@testerab

不一定。以下是自动化手动测试可能不可取的一些原因：

• 某些测试可能更容易手动执行，因为它们手动执行非常快，但作为自动化测试编写代码需要花费不成比例的时间。
• 某些测试可能更容易手动执行，因为它们在系统中仍然变化非常迅速，因此维护自动化测试的成本将超过快速执行测试的能力。
• 许多测试可能更值得手动执行，因为人脑可以(而且应该！)问许多在自动化测试中无法捕捉到的问题(例如，这种行为是否比它应该花费的时间更长？)为什么在这一点上，一半的屏幕会被一个大的黑色方块所迷惑？嗯，这似乎很不寻常；我要在完成这个测试之后再检查一下。)
• 用另一种方法来说，人类可以(而且应该)使用“丰富的预言”，当他们测试时(超过了书面的“预期结果”)，比自动化测试中的编码逻辑更容易。
• 某些测试(实际上很多)与测试集中已经存在的其他测试一起考虑时，效率极低(例如：(a)已经测试过的其他组合的重复性很高，(b)缺乏更多的覆盖范围)；这种无效的测试一般不应手动执行，也不应转化为自动测试。
• 测试人员可能缺乏技能或时间来很好地自动化手工测试。在这种情况下，继续使用手动脚本可能比邀请编写不良的自动化的维护负担更好。
• 自动手动测试容易受到产品中不属于实际bug的微小变化的影响。它们可能成为一个可维护性问题。当它们失败时，它们并不是一个诊断性很强的测试，因为更“白盒”的测试可以非常具有诊断性。
• 对人类来说很容易的测试可能几乎不可能实现自动化。“这个视频里的声音清楚吗？”即使是一个相当喝醉的人也能做得很好，但是一个计算机程序去做它几乎是科幻级的编程。
• 需要硬拷贝或特定硬件交互的测试可能不是自动化的好选择。这两种软件都可以使用其他软件部件进行模拟，但接下来需要验证的是其他软件，以确保它能够正确地模拟硬件。
• 如果您需要执行一组非常复杂的配置步骤，以便自动化单个测试用例，则手动测试可能是最简单的。它也可能是一个非常罕见的测试用例的指示器，可能不值得放在自动化套件中。
• 就像做开发工作一样，在测试过程中创建的任何工件都必须评估它们的价值，看看它们是否是可重用的。如果一个自动化测试在第一次运行之后是不可重用的，那么您实际上已经花费了资源来创建一些在使用后被“丢弃”的东西。手动测试可能只需在文档中使用一组快速指令执行一次，比使用资源实现自动化要有效得多。

我希望这个答案有所帮助；我请其他人改进这一不完整的清单。

相反，手动测试可能有助于直接自动化的迹象是：

• 如果测试有一个非常详细的脚本，包括精确的检查
• 如果当手工脚本由熟练的测试人员运行时，很少或从未在这些特定的检查之外发现有趣的bug，或者如果通过没有脚本的临时测试，发现有趣的bug通常要快得多。
• 如果功能不经常改变，就会破坏自动化
• 如果执行手动脚本需要测试人员多小时的时间
• 如果自动化这些脚本所需的时间不会超过手动运行脚本所需的时间，并且当前没有更高优先级的任务
• 如果执行手动脚本被运行它们的测试人员描述为无聊，但不运行它们也不是一种选择，即使对该特性进行临时测试也是如此。这是一个强烈的信号，表明应该考虑某种类型的自动化，可能还需要特别的测试，因为无聊的测试人员通常都是糟糕的测试人员。但是，看看其他点，以确定它应该是手动用例的直接端口，还是考虑到自动化而设计的新测试套件。
• 如果手动测试是任务/产品关键项，则必须在初始发布日期之后回归。注意，并不是所有的自动化都是回归自动化，但是回归测试是自动化在ROI中得到极大提升的地方。
• 同时，即使测试不是回归项，如果手动测试的自动版本的创建将为其他项目和/或过程增加价值，那么创建自动化也是值得的。任何由测试过程创建的、可重复使用的工件都不会浪费精力。
• 如果手动测试是要在每次构建中执行的冒烟测试列表

请也改进这个不完整的列表！

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

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

1. 投资回报。自动测试的ROI很高，这些测试繁琐、重复、覆盖用户将频繁执行的操作、任务关键、涉及大量数据验证或这些因素的任何组合。相比之下，GUI检查和设置和遗忘配置的ROI要低得多.
2. 数据依赖。如果测试高度依赖于数据，但对数据输入方式的更改相对较少，那么它们通常是自动化的好选择。例如，在执行一系列测试之后自动化SQL数据验证是有意义的。如果测试可以由数据驱动，这将使它们更加有效，因为可以通过简单地添加到测试数据存储区来添加新的测试用例。
3. 外部接口。虽然模拟来自外部设备的输入是可能的，但它不一定是实际的或可能的。类似地，通过Mach 1眼球打印一些东西和运行打印输出通常比通过编程打印文件和检查要容易得多，特别是当您正在处理您正在接口的应用程序的封闭接口或有限生命期测试版本时。
4. 先决条件设置。有时，需要大量的工作才能使设置自动化，因为这是一个简单的测试，可以通过手动测试更容易地完成。

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

我不会提倡由没有领域知识的人实现自动化，因为领域知识对于决定什么应该自动化至关重要。如果一个没有领域专业知识的人正在自动化，我希望他们能和一个领域专家一起来决定什么是自动化的。