QA手动测试死了吗？

Question

我可以自动化所有类型的测试（单元测试，等等），以便我不需要QA团队进行手动测试吗？如果不是，为什么？

Answer 1

我会这样总结：

• 自动化测试用于查找您了解（错误代码）的问题。

• 手动测试用于查找您不了解的问题（设计/规格不正确）。

如果使用手动测试来查找代码问题，则效率低下。如果您使用自动化测试来发现设计问题，则这是不可原谅的。

Answer 2

只要人类使用您的产品，黑盒测试就永远不会消失。没有什么可以替代人类识别“奇怪的事情”的能力。

Answer 3

没有

您的质量保证可以是一个较小的团队，他们的目的是找到意想不到的事情。他们可以用户可能的方式使用系统。以程序员不期望的方式。

一旦找到了什么，就会编写一个自动化测试，这样他们就不需要重复了。但你仍然需要他们找到那些案件。

更不用说，他们会发现拼写错误，用户界面的可用性问题，难以阅读的颜色组合等等。

Answer 4

自动化测试与测试一样好。从理论上讲，如果您可以为用户与系统进行的每次潜在交互编写测试，那么手动测试就会过时。但是，这根本不可行。

良好的测试将减少QA团队所需的手动测试量，但不能消除它。此外，良好的自动化测试可以帮助防止不得不手动重新测试问题，因为一旦发现问题，就可以开发出一个好的测试来自动处理特定场景。

Answer 5

Vista体验的原因之一据推测，MSFT已经削减了“仅仅是人类”的测试人员，转而支持编写脚本的测试人员。

当然，当您深入控制面板时，脚本没有注意到各种不同主题的内容，或者复制估计对话框或其他“次要”gui功能使整个产品看起来很糟糕

Answer 6

手动QA，通常称为Blackbox QA，远未消亡。

单元测试和一般自动化测试确实可以覆盖至少90％的代码路径测试。许多人没有意识到最后一本手册10％可能是软件和硬件组织可以做的一些最重要的工作。

让我们以用户界面为例。单元测试可以告诉您复选框位于正确的位置，并按预期打开和关闭。测试无法告诉你的是，它的位图非常糟糕，并且在应用程序中采用了可怕的紫色和黄色配色方案，看起来非常糟糕。

Blackbox QA最重要的原因是您最终在组织内拥有强大的客户支持者。许多这些QA人员（包括我自己）拥有更多的创作背景，而不是编程背景。虽然有些人可能认为这是一个失败，但这些人并不关心代码是如何工作的 - 他们关心产品的运作方式。他们花时间思考客户而不是开发人员; “哦，我差点死了的iPod已经完成了同步，这意味着我可以关闭我的笔记本电脑然后让它充电。是的，然后我会在我的机器睡着时将它拉出来（即使我正在播放它的音乐）我的电脑）一切都会好的。“

开发人员和测试人员知道产品应该如何工作，并且所有产品都按照规范进行操作。以粗心的方式使用产品是一个很好的测试人员的工作，以确保不会发生坏事。当你复制数据时，从计算机上拔出一个USB驱动器，你疯了吗？！？当然，这是一个非常愚蠢的想法。但人们总是这样做。一个优秀的QA人员会做到这一点，以确保拉动硬盘驱动器不会占用整个系统。或者在下载电影时关闭WiFi，或在购买新内容时同步音乐，然后同时更改您的帐户密码和电子邮件地址。或者在MP3播放器上安装操作系统并试图从它启动，然后在系统从设备启动时将系统拉出系统（是的，我做到了，发现了一个非常好的错误）。

Joel on Software说“为什么QA”比我更有说服力 - http://www.joelonsoftware.com/items/2010/01/26.html

Answer 7

没有！

并非一切都可以通过自动化测试进行测试。请不要建议！用户界面美学是您的QA团队应该帮助您修复的东西，而自动化测试则不能。仅举一例。

Answer 8

绝对不是。自动化测试是代码。他们可能有自己的错误，可以掩盖AUT中的错误。此外，没有自动化测试能够询问“如果我这样做会怎么样？”，或者能够对有可能发生故障的位置做出有根据的猜测。自动探索性测试不存在。

在机械方面，编写仅运行一次的自动化测试通常效率低下。如果手动操作比开发测试花费的时间少，那么将其自动化是浪费。

Answer 9

忽略手动测试会导致您错过自动化无法捕获的重要错误。真实世界测试需要手动和自动测试的正确组合。

用户体验和界面问题只能通过手动测试来识别。

自动化非常适合回归测试，因为它是在一个已经过用户体验审查的稳定环境中完成的。

自动化也非常适合为测试人员删除许多繁琐的任务，因此他们可以专注于更有可能出现UI错误的新功能或领域。

Answer 10

[根据我使用手册和放大器的经验自动化]

手动测试：这是实际测试，您可以根据当前情况尝试不同的方案，例如，当网络中断应用程序的行为时，您可以断开连接并连接网络和检查结果。这有助于处理功能性错误以及UI错误。

自动化测试：如果继续脚本定期执行，这些脚本也需要更新，类似于应用程序更新，如果页面加载有延迟，则可能会提供错误的结果或网络响应或缓慢。

两者都有自己的优点和缺点，但是，Automation不能取代更大的逻辑应用程序的手动测试。 视频会议等用户交互场景不适合自动化。 自动化脚本本身就是代码，它也可能有错误，有时会产生错误的结果。 自动化可能适用于某些应用程序，其中内容在较长时间内保持相同，而且功能和值主要是静态的。

Answer 11

  

我可以自动化所有类型的测试（单元测试，等等），以便我不需要QA团队进行手动测试吗？

否

  

如果不是，为什么？

并非所有技术/测试都适合自动化。

除此之外，如果自动测试代码是由编写要测试的代码的同一个人编写的，那么测试可能缺少一些重要的（但是，原始开发人员未检测到）方面可能是验证。

Answer 12

在新项目开始时我们获得了SRS或Prototypes，因此，只有QA了解应用程序的工作流程，他才能为应用程序实现自动化。如果不进行手动测试，自动化不起作用。但是手动测试总有可能。

Answer 13

自动化你可以做，但不检查设计，所以如果你检查设计或你可以做手动测试

Answer 14

1. 不，你不能。

2. 因为自动化测试只是确认测试是在固定条件下进行的。但是可以通过手动测试找到多种情况。此外，根据要求，现有产品可以更改/更新/可以具有新添加的功能。因此，在自动化测试之前，您必须运行手动测试以确保每个测试条件都正常工作。

Answer 15

最后，所有测试用例都由人执行。即使整个系统是自动化的，但有时您还是需要在此处进行一些手动测试。

自动测试可帮助您找出具有您已经了解的功能的错误，而手动测试则可以帮助您找出可能错过的自动化错误。

Answer 16

没有

Bec自动化主要用于回归测试而非所有测试用例。

手动测试是常青树。

特殊测试和探索性测试应仅使用手册进行