手工测试比自动化测试要好。这是真的吗？

Question

使用手动测试，您不需要购买软件自动化工具或编写脚本。

自动化测试是机器人的，不一定像一个真正的用户。另一方面，手动测试允许开发程序像发射时一样被使用。当用户以某种方式处理程序时，可能出现的任何错误都更有可能在手动测试中被捕获。

可以改变课程的东西(功能、GUI等)对于该项目，您希望能够立即进行工作。自动化测试需要更多的时间来设置，这不允许您快速、轻松地测试想法。

Answer 1

想象一下，您正在工作的环境中，新特性迅速出现，并且每隔几个小时就会构建一次。每个新特性都有可能破坏系统某些部分中的某些内容。

您没有时间每天手动进行完全回归测试，因此投资于一个自动化套件来执行回归测试是一个明智的想法，而您需要对这个特定的新特性/想法进行手动测试。

理论上，您可以通过雇用更多的测试人员来获得更好的结果，这些测试人员将手动进行所有的回归，而且它实际上可以提供更好的“测试”，但这将是非常低效和昂贵的。

因此，自动化测试并不比手工测试“更好”，它只是比手工测试更高效。

Answer 2

我认为最合适的答案是它取决于。

使用手动测试，您可以随时在运行时临时编写和调整测试，并查看意外情况并处理好它们。

在自动化测试中，脚本将只完成他们被编程要做的事情。它们不会处理意外情况或AUT (在测试下的应用程序)的任何更改。

是的，你不需要购买自动化工具，但这不仅仅限于手工测试。有许多开放源码工具，您可以使用这些工具来自动化测试。因此，对于自动化测试，您也不必购买工具。

是的，你必须写剧本，而且你必须擅长它。剧本不会自己思考和即兴发挥。您必须善于提出正确的要求和逻辑，并为它们编写脚本。

你真的需要了解什么是可以自动化的，什么是不能实现的，你需要弄清楚它是否真正值得为AUT实现自动化。如果一个项目是一个小项目，并且不会有许多维护和重复或连续的开发周期，那么投资于自动化将不会给您带来任何好处，因为编写自动化脚本需要在计划、技能、时间和调试方面付出很大的努力。但是，如果项目很大，并且分为几个阶段，并且有连续的发布周期，那么您可能需要考虑回归的自动化测试。随着每一个版本，您的软件将更新新的功能，错误修复和更新。此时，您可能需要进行回归测试，以确保软件的现有模块没有受到阻碍，并且功能运行良好。在这里，手工测试会变得非常繁忙。

是的，开发自动化脚本可能会占用大量的时间，但是一旦开发出来，它们将节省测试执行的时间。但是，您还需要不时地更新测试脚本，以检查新的条件。

除此之外，如果你真的看到，没有自动化测试这样的东西。是的，您编写了一些脚本，它将执行AUT并产生一些结果。但这不可能独自发生。你会写剧本的。你将做所有的思考，并提出它的逻辑。一旦脚本准备好，您将告诉计算机或任何设备，它将执行脚本，它将简单地遵循您的指示。一旦脚本执行完成，您将分析结果并确定其中是否有任何问题或它们是正确的。然后你会得到他们的问题清单，并报告给合适的人修理。因此，没有任何事情发生在它自己，因此它不自动暗示它的实际手动测试！

Answer 3

很短的版本-这取决于

长版本

根据您正在进行的测试类型，某种形式的自动化可能是最好的选择，它可能是帮助您设置来执行手动测试的方法，或者可能比根本不进行测试更糟糕。或者在这两个极端之间的任何地方。

计算机非常擅长做同样的事情，而且速度比人类快很多倍。如果测试任务需要重复多次，每次都以完全相同的方式执行，并且/或在短时间内做很多事情，那么自动化测试可能是比手动测试更好的选择。

人们非常善于识别异常和识别模式。如果测试任务需要模式识别，检查一些不容易编码到单个正确的甲骨文中的东西(例如屏幕看起来是否正确)，手动测试可能是比自动测试更好的选择。

对于介于两者之间的每一件事，都取决于投资回报。如果您有一个成熟的自动化框架，使添加新测试变得简单，并且修改现有的测试变得简单(因为您不必在自动化代码中的数百个地方更改内容)，那么您可能会在可能/合理的情况下更倾向于自动化测试。

此外，还有大量的自动化辅助任务经常发生，例如：

• 使用多个比较实用程序之一运行查询并根据保存的好文件检查输出(WinMerge是一个不错的免费工具)。
• 运行性能监视工具来检查内存泄漏、内存的过度使用等等。
• 构建一个快速而肮脏的丢弃脚本，多次启动和停止应用程序，以尝试捕获间歇性关闭错误。
• 构建一个可丢弃的脚本来生成大量用于测试的数据。
• 构建安装脚本和解压缩脚本，使我能够快速生成用于测试的特定环境。

我使用的一些启发式方法是：

• 80/20规则-如果它是20%的应用程序的一部分，得到了80%的使用，它很可能是一个自动回归的目标。
• 发布回归--如果必须对每个版本进行检查，那么它很可能是自动回归的目标。
• 关键路径--如果它会使应用程序或其主要部分失效，那么它很可能成为自动回归的目标。
• ROI --如果手动操作需要很长时间，并且容易出错，并且需要定期执行，那么它很可能成为自动回归的目标。这里的一个例子是:在我以前的工作场所，纳税计算对客户来说至关重要。一个由3名测试人员组成的团队用了5天的时间进行了部分税收回归测试。自动化整个税收回归需要几个月的时间，但一旦完成，它就可以每晚运行，并捕捉到任何破坏税收计算的变化。在一年内，自动化的努力在节省测试人员的时间方面变成了积极的ROI。在没有到达客户的回归方面，ROI要高得多。
• 复杂性--如果有很多移动部件(即交互的应用程序和服务)，那么它可能不是自动化的好目标。单个的部分可能是自动化的，但是端到端的流程可能不会。
• 外部依赖--如果它依赖于第三方应用程序或接口，那么它可能不是自动化的好目标。信用提供者属于这一类别:并不是所有的信用供应商都是在对他们的接口进行认证之后才让他们的测试环境处于开放状态的，而且环境中的任何错误都是您无法控制的。
• 对需要物理操作的硬件的依赖--这里最简单的例子是检查打印输出(打印输出可以自动化，但这样做很辛苦，而且容易出错)。如果您的软件导致硬件发生了一些物理变化，那么它可能不是自动化的好目标。
• “硬度”/“软度”--如果它有一个正确的结果，它可能是自动化的一个好目标(例如税收计算的正确结果)。如果它是“软”的，例如图像是否显示良好或屏幕布局是否良好，那么它可能不是一个很好的自动化目标。

这绝不是一个全面的清单，但它是一个起点。