手动测试比自动化测试更好。真的吗？

#1 楼

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

您没有时间每天手动进行完整的回归测试，因此投资自动化是一个明智的主意该套件将在您对该特定的新功能/想法进行手动测试时执行回归测试。提供更好的“测试”，但效率和成本都非常高。

#2 楼

我认为对此最合适的答案是IT依赖。

在自动化测试中，脚本仅会执行其编程要执行的操作。他们不会处理意想不到的情况或AUT（被测应用程序）的任何变化。有很多开源工具可用于自动化测试。因此，对于自动化测试，您也不必购买工具。

是的，您必须编写脚本并且必须精通它。脚本不会自己思考，也不会即兴创作。您将必须善于提出正确的要求和逻辑，并为它们编写脚本。


您真的需要了解什么可以自动化，什么不能自动化。您需要确定是否真的值得为AUT实现自动化。如果一个项目是一个小项目，并且没有很多维护以及重复或连续的开发周期，那么对自动化的投资将不会给您带来任何好处，因为编写自动化脚本需要大量的计划，技能，时间和调试工作。但是，如果项目很大并且分为多个阶段并且具有连续的发布周期，则您可能需要考虑进行自动化测试以进行回归。在每个发行版中，您的软件都会更新为新功能，错误修复和更新。此时，您可能需要进行回归测试，以确保该软件的现有模块没有受到妨碍并且功能正常运行。在这里，手动测试会变得很忙。

是的，开发自动化脚本可能会花费很多时间，但是一旦开发完成，它们将节省测试执行时间。但是，您还需要不时更新测试脚本以检查新条件。



所有这些，如果您真的看到了，就没有
自动化测试。是的，您编写了一些脚本，该脚本将执行
AUT并产生一些结果。但是它不会自己发生。您将
编写脚本。您将进行所有的思考，并弄清楚其逻辑。脚本准备好后，您会告诉
执行脚本的计算机或任何设备，并且它会简单地按照您的说明进行操作。脚本执行完成后，将由您来分析结果并确定结果中是否存在任何问题或它们是否正确。然后，您将从中获得问题的
列表，并将其报告给合适的人以进行解决。因此没有任何事情发生，因此它不是自动的
意味着实际上是手动测试！

#3 楼

简短版本-取决于

长版本

根据您正在执行的测试类型，某种形式的自动化可能是最佳选择，这可能会有所帮助进行手动测试的方法，或者比根本不进行测试更糟糕。或介于这些极端之间的任何地方。

计算机非常擅长多次以完全相同的方式进行操作，并且比人类能够更快地完成。如果测试任务需要执行多次操作，每次都以完全相同的方式进行操作和/或在短时间内进行很多操作，则自动测试可能比手动测试更好。 >
人们非常擅长识别异常并拾取模式。如果测试任务需要模式识别，检查无法轻松编码到单个正确预言中的内容（例如屏幕是否看起来正确），则手动测试可能是比自动测试更好的选择。

对于介于两者之间的所有内容，都归结为投资回报率。如果您拥有成熟的自动化框架，可以轻松地添加新测试并轻松修改现有测试（因为您不必在自动化代码中的数百个地方中进行更改），那么您可能更倾向于自动化测试可能/合理。

此外，还有大量自动执行的任务，例如：


运行查询并根据保存的已知商品检查输出文件使用许多比较实用程序之一（WinMerge是一个不错的免费工具）。
运行性能监视器工具以检查内存泄漏，过多的内存使用等。
构建一个快速而肮脏的废弃脚本来多次启动和停止应用程序，以尝试捕获间歇性关闭错误。
构建一个可丢弃的脚本以生成大量数据以供测试使用。
构建设置脚本和拆卸脚本，以使我能够快速生成用于测试某些东西的特定环境。

我使用了一些启发式方法：
80/20规则-如果占应用程序20％的一部分使用量的80％，则它很可能是自动回归的目标。

释放回归-如果必须这样做

关键路径-如果应用程序或应用程序的主要部分在崩溃时无用，则可能成为自动化目标回归。

ROI-如果需要花费较长时间进行手动操作且容易出错，并且需要定期进行，则很可能成为自动回归的目标。这里有一个例子：在我以前的工作场所，税金计算对客户至关重要。由3名测试人员组成的小组花了5天的时间来进行部分税收回归测试。自动化完整的税收回归需要花费几个月的时间，但是一旦完成，它就可以每晚运行，并且会发现任何破坏税收计算的变化。在一年之内，就节省了测试人员的时间而言，自动化工作已使投资回报率提高了。就无法满足客户需求的回归而言，投资回报率要高得多。自动化的好目标。各个部分可能是自动化的，但端到端流程可能不会自动化。

外部依赖项-如果依赖第三方应用程序或接口，则可能不是自动化的好目标。信贷提供者属于此类：并非所有信贷提供者都通过了与他们的接口的认证后就可以保持开放的测试环境，并且环境中的任何错误都无法控制。

依赖于需要物理操作的硬件-这里最简单的示例是检查打印输出（可以自动进行打印，但是这样做很麻烦，而且容易出错）。如果您的软件对硬件造成了物理变化，那么它可能不是自动化的理想目标。

“硬度” /“柔软度”-如果它具有完全正确的结果，则它可能是自动化的良好目标（例如税率计算的正确结果）。如果它是“软”的（例如图像显示效果好还是屏幕布局看起来不错），则可能不是很好的自动化目标。点。

#4 楼

我想通过以下几点为自动测试提供有力的证明：



覆盖率。自动化测试要快得多，并且可以提供更好的测试覆盖率。未涵盖的内容可能是错误的。

可重复性。由于在不同的测试运行中时间和输入几乎相同，因此结果比手动测试更一致。发生的错误通常可以重现；手动测试则不然。

记录。自动化测试具有自动记录和评估功能。软件的质量立即可见。

即使是稍微复杂的程序或设备，自动化测试也必不可少。手动测试根本无法以可接受的努力涵盖复杂的功能。在自动化遵循用户的操作的意义上，它们通常先于自动化测试。探索性测试是对完全相同的自动化测试的必要补充。

#5 楼

两者都不比另一个更好。他们并不是在竞争，实际上只是在解决问题的不同方法。让我们使用一个类比。

脚与汽车的对比

手动测试（英尺）

想想手动测试，例如步行或跑步。您需要步行的地方。我的意思是，即使只是早上从床到浴室，您也需要步行。步行即可轻松更改方向或目的地。您可以在经过的时候仔细检查事情，包括停下来闻玫瑰。而要做这一切只需要您的时间。

但这并不是最有效的出行方式。步行或奔跑要花费很长时间。这样做还需要大量精力。有了它，您就更容易迷路，特别是在长途旅行中。此外，如果您每天走相同的路线，您实际上可能没有花时间停下来闻玫瑰花香，而当枯萎时您可能会错过。

自动测试（汽车）

另一方面，自动化就像一辆汽车。快速（vrooooom）。您仍然必须驾驶它，但是一旦放下它，对于将您从A点带到B点非常有用。而且很容易始终遵循相同的路线。此外，它具有所有这些指示符，因此您可以确切地知道出了什么问题。而且您被困在路上，可以随便开车。而且，它很昂贵。我的意思是，您看到汽车的价格了吗？加上汽油成本。可能会花钱。有很多方法可以降低成本（拼车或打车，又称QA服务），但步行仍然要贵得多。它只能使您走到现在。您不能完全沿着杂货店的过道走，所以必须走路。

为什么不能同时使用呢？自动化是非常有限的。

手动测试非常棒，但是对于大型项目，您不能完全依靠手动测试。繁琐的工作和太多的时间，无论您跑多快，都将永远无法跨越那个距离。您需要通过自动测试（您的汽车）来增强它，这样您才能到达需要的地方。有些事情您无法使用它进行测试，并且仅可以检查它到底在寻找什么，而没有其他设置。您确实需要做的不仅仅是自动化测试，有时还需要手动进行深入研究。如果要在车道尽头进入邮箱，则可能不需要开车。同样，对于小型项目，您可能不需要太多或任何自动化。但是，如果您要穿越城镇或全国各地，则肯定需要自动化来帮助您。否则，您将被遗弃在灰尘中。

#6 楼

成本

通过手动测试，您还需要编写脚本。如果您无法使测试工作重现性，您将继续重新发明轮子，甚至可能忘记功能不那么明显。如果您想购买商业专有的测试工具，我真的会提出挑战，但这不在此问题的范围内。

自动化工具的学习曲线要​​高得多，这可能是需要考虑的成本因素。如果您问我，您提到的其他名称实际上并没有真正的效力。检查应用程序的工作方式。敏捷测试象限建议您在手动和自动测试之间找到良好的平衡。

我确实认为手动视觉测试对于提供质量更好的软件具有巨大的好处。因此，应尽可能进行探索性测试和可用性测试。理想的测试金字塔确实包含一些手动测试，但只有一点点。现代软件开发涉及到从开发到部署的所有过程的自动化。自动化测试更适合您的项目，因为：


必须重构代码以创建可维护和可扩展的代码库。
您可以更快地发布并获得更快的速度。如果您具有良好的自动测试覆盖率（65-90％），则可提供用户反馈。用户反馈比人工测试可以提供的反馈要好得多。 （除非应用程序具有生死攸关的情况）
即使在短期内也更便宜。当然，如果您按照YAGNI原则进行“测试驱动开发”之类的工作，那么您将只构建真正需要的代码。

自动化测试可以安全地保护代码或产品中的功能性路径。不知道您是否要验证用户可能不会执行的所有路径，这可能是您进行大量手动测试时遇到的情况。不要将测试时间浪费在不会发生的事情上。进行风险分析以考虑要测试什么。

也没有真正的自动化测试。我喜欢James Bach所说的“工具支持的测试”。 :)

发布周期

越来越多的公司正在疯狂地进行快速发布，以验证市场适应性或保持领先地位。如果您仅进行手动测试，则随着功能的增长，发布周期将越来越慢。因此，使产品的核心功能自动化是当今必不可少的事情。自动化一切。如果您有时间问我，只有使一切自动化的公司才能经受住考验。手动测试速度较慢，在时间压力下容易捷径，从一开始甚至到最后都要昂贵。看看http://sprintforenterprises.com/

#7 楼

手动测试，以了解何时需要人为智力（探究测试），以真正尝试与接口打交道并发现弱点。或者，如果您的软件项目很小，并且不保证安装机器人。

需要大量简单，可重复的过程（回归测试）时又可以进行自动化测试，也可以是繁重的工作。
在这里给您一些尺寸-我们在8小时内对70台计算机运行了10k +端到端GUI测试-由12个人创建和维护。

#8 楼

简短答案


手动测试比自动化测试更好。是真的吗？


否。自动测试都不比手动测试更好。两者都是用于不同目的的工具。它们可以并且应该一起使用。

很长的回答

首先，我为您完全模仿一些非技术项目负责人的观点而称赞，他们只是想快速，廉价地完成工作，并尽快将产品推出（维护工作也将由公司的其他部门完成！）。

考虑争论是一个很好的练习，要始终意识到自己处在一个失落的斜坡上。非常适合求职面试，扮演提倡者的形像。让我以同样的精神回答。

注意：我认为您只是在了解/谈论与编程环境非常不同的老式“自动化软件”，而这仅仅是“关键” /鼠标单击记录器”。还有其他与实际软件开发过程更加集成的方法（例如https://cucumber.io），这就是我下面的答案。手动测试，您不需要购买软件自动化工具


是正确的，但是存在免费工具。 />

正确，但是重复的体力劳动比只做一次更复杂的工作要昂贵得多。充当真实的用户。


正确且具有机器人性（即可重现，可靠，快速）有利于自动化测试。自动化的测试不会使人无用。


另一方面，手动测试使开发程序可以像启动时一样使用。


这也可以并且应该通过自动化测试来完成，它们被称为“功能测试”或“集成测试”，另一个流行词是“行为驱动的开发”。


用户以某种方式处理程序时可能会弹出的任何错误都更有可能被手动测试捕获。真正。因此，对于任何错误报告，您要做的第一件事就是创建一个“红色”测试来重现它（这很容易，因为您拥有支持这种事情的测试生态系统）。这可能不会花太多时间来调试代码并找到没有测试可能性的错误。修复bug的过程使测试变成绿色，您现在还确保了bug永远不会再次出现。 ），您希望能够立即对其进行处理。自动化测试需要花费更多的时间来建立，这使您无法快速，轻松地测试想法。使您到达必须更改某些内容的地步。这比手动完成要容易得多。

#9 楼

在我看来，这两个测试扮演着不同的角色。

手动测试可以测试软件的性能，外观，感觉，自动化无法涵盖的部分主观和客观方面。

自动化对于回归测试以及对服务器或软件的其他功能进行测试很有用，这些功能会返回程序可以验证的内容（例如数据文件或服务器状态）。

结合在一起，它们可以帮助掩盖用户立即注意到的错误以及更细微的错误，这些错误可能不会使应用程序崩溃，但肯定会导致它在接受度方面落伍标准。当然，这是我所有基于经验的观点。

#10 楼

我想加我的2美分。

我相信两者都有其价值。真正重要的是为手动还是自动执行创建测试的人。

所有测试应针对特定且可实现的目的进行创建。好的测试需要时间和精力来创建。为此没有必要创建和执行。功能性，非功能性e.t.c.仅仅为了打动利益相关者而进行很多测试是没有意义的。

有许多有用和有效的测试设计技术，例如等效划分，边界值分析，域分析（我从未使用过）和逐对分析。使用这些测试设计技术创建自动化测试将是理想的。别忘了，还有重要的测试报告和缺陷记录。

最后，这全都与获得高质量软件有关。

#11 楼

这取决于何时选择自动化以及何时选择手动您可以通过自动测试和手动测试来测试软件，项目。


自动化测试与手动测试


快速而有效地运行脚本，但是设置会花费时间。回归自动化测试可以更有效地运行并产生结果。一切都会自动为您完成。

自动化工具有一定的局限性，无法测试视觉效果，例如图像颜色或字体大小，但可以手动进行。

#12 楼

手动测试和自动测试有很大不同。长时间执行重复动作的人很难集中精力发现错误。
自动测试还可以执行更多，更快，更频繁的测试，例如作为构建过程的一部分。

自动化测试还可以比人类进行更深入的数据检查。例如，我所研究的一个系统，自动化测试通常通过被测软件运行数百TB的数据，生成数百TB的输出，然后检查每个字节。

但是，手动测试（使用具有自由探索能力的智能测试人员）非常适合查找您未考虑进行测试的事物或发现怪异的错误。它们通常更适合测试UX问题。在规范不精确的地方，手动测试是很好的选择，测试人员需要做出判断。这经常发生在编写精确规范的成本不值得的情况下（例如，UI通常没有精确规范，特别是在非消费类软件上）。

#13 楼

我认为两者都是理想的-但是，如果我只能拥有一个，那么只要可以添加测试用例，我就会进行自动测试。手动测试非常规系统非常耗时且容易出错。自动化测试需要花费一些时间才能创建，但是可以快速运行多次。我建立的系统无法单独对IMO进行手动测试，而在正确的情况下有滚雪球的机会。按下按钮，获得绿灯-快乐的开发者！ :-)

#14 楼

自动化测试是自动进行的，不一定像真实的用户那样。



并不完全正确。您可以使用在真实的浏览器中自动测试的工具（如jasmine），或用于模拟webkit浏览器的测试框架（如jasmine和phantomJs）。在Web开发方面，您的功能可能有效，但设计可能是完全倾斜的。即使那样，我还是在一个地方使用了一个就地工具，该工具会在硒测试期间对每个提交进行页面截图，然后进行图像比较以查看图像是否发生了变化。当CSS破坏了您未处理的站点的其他部分时，对接起非常有用。

#15 楼

对于什么是非常主观的主题，这里有一些很好的答案！

苹果比橙好吗？ -由于测试人员可能缺少用户界面，因此“自动化”成为前进的方向。
您还需要查看对“自动化”的定义，因为很多人只考虑一次使用（例如，在Selenium中自动化回归测试）。

自动化还可以为手动测试人员创建测试数据，或用于筛选手动测试人员的结果并生成报告...人与机器和谐相处:)

#16 楼

这实际上是一个非常有问题的问题。我认为这仅在某些方面会更好。首先，正如您所说，短期内它更便宜，更快。如果您只有几天的时间来测试所有内容，则几乎没有时间可以自动化某些东西。但是对于较长时间的测试，只要正确构建了自动化测试，自动化就会带来好处。

是的，大多数流行的平台（例如Selenium）不能执行CSS测试/视觉回归测试（与手动测试器不同）。但是到目前为止，已经开发了许多新的质量检查自动化工具，因此可以为他们的项目选择合适的工具。