我已经看到了应该使所有测试自动化的争论,并且我看到了必须进行手动测试的争论。
我不知道该相信谁。甚至可以自动化所有测试吗?当人们说所有测试都应该自动化时,它们是指手动测试人员通过详细的测试脚本工作的测试类型,还是指手动测试人员探索应用程序的测试类型?我该决定哪种方法正确?
#1 楼
恕我直言,任何单调且可重复的测试都可以并且应该自动化。
话虽如此, />手动测试是不可替代的,应该专门用于创造性的探索性测试,这完全是由测试人员的经验和直觉驱动的,它通过使用“假设”问题来深入研究显而易见的测试
需要技巧和创造力的场景。
评论
为了确定什么是单调的和可重复的,您必须首先进行手动测试才能知道。一旦执行了足够的操作,边缘盒就可以变得单调且可重复,并且可以直观地创建正确的过程以反映边缘盒,然后它只是进一步推动了自动化过程,您需要进行手动测试,直到您可以重复相同的事情为止。
–尼尔森
18-11-15在5:53
为了确定测试过程中什么是单调的和可重复的,人们需要一种具有高级测试设计的测试策略,但是不一定需要执行手动测试就可以知道这一点。
– Vishal Aggarwal
18/12/4在11:45
#2 楼
答案是“取决于情况”。假设测试分为两个主要类别:功能性和探索性:
功能性
功能性是指“证明某项功能符合定义的要求”,通常通过以下测试脚本进行操作:
单击按钮A。
输入将此文本输入到文本框2:“ foo”。
单击按钮B。然后屏幕应变为亮粉红色。
探索性
探索性意思是“尝试打破这一点”,通常由测试人员自己的创造力和独创性。例如,
单击按钮A
现在将10,000个表情符号字符粘贴到Textbox2中。
单击按钮C,而不是B。 。
一般来说
一般来说,您应该旨在使第一种测试自动化-通常在首先手动执行这些测试之后,您就知道它们通过了。
但是,您可以正确的软件开发流程,有时甚至在编写代码之前就进行开发。但是实际上,这是非常罕见的。
但是
要注意的一件事是,有时很难自动化一些功能测试。
Web和桌面UI应用程序很漂亮这很容易,因为有一个定义明确的模型可以使用,并且有许多工具可以自动执行这些测试(硒等)。 。
对于需要被测试的东西需要专用硬件或许可证的测试也可能很难,因为您只是没有非生产资源来进行测试。
因此您会发现自动化的能力这些事情各有不同。
探索性测试的注意事项
第二种(探索性)通常不能自动化,因为它们依赖于人类的直觉。但是,也有例外-例如,数据输入表单可以通过“模糊”测试自动进行,该测试将尝试大量的输入组合,以查看是否可以找到导致问题的组合。说所有测试应该是自动化的,是的,它们通常表示功能测试,而不是探索性测试。
探索性是功能自动化的输入
要考虑的另一件事是,探索性测试通常可以作为自动化功能测试;因此,例如,一旦使用手动测试找到了一个极端的案例,为该案例创建自动回归测试可以提供巨大的价值。在这种情况下,您已经将未知案例变成了定义的功能案例。现在也是与利益相关者和开发人员讨论确定是否应该保留刚刚发现的新行为的好时机:)
我如何确定哪种方法正确?
答案又是,这取决于诸如
您需要花多少时间来编写自动化文件
自动化程序要花费多少时间
它将提供多少价值。 />如果一天的编码可以使您完全自动化(例如,“登录”对话框),那么对应用程序的关键部分执行数千次简单的功能测试就没有意义了;另一方面,花一个月的时间为不重要的功能开发自动化没有意义(例如说应用程序“关于”对话框的非关键功能)。
希望有所帮助。
评论
我想添加它以进行探索性测试。如果发现问题,请将其转换为功能测试用例,以便开发人员可以解决该问题,并防止再次发生该问题,并且测试人员不必再次进行测试。
– Viktor Mellgren
18-11-15在9:12
@ViktorMellgren-是的,的确很好!我可能应该更新答案,以表明探索性测试是功能测试自动化的输入。
–斯蒂芬·伯恩
18年11月15日在11:18
像python的假设这样的库是一种自动探索性测试的形式-因此它可以自动化,至少在一定程度上是自动化的。但这并不能真正替代手动探索性测试。
–阴影
18年11月16日下午2:00
#3 楼
这是一个非常简单的问题。我想每个人都会同意:是否需要手动测试? ->必须的
我们可以用自动化代替一切吗? ->基本上没有。在对项目中的应用程序进行自动化测试时,要考虑很多因素(例如时间表,可行性,ROI,可维护性,未来计划)。以我的经验,您必须明智地决定项目中计划的自动化程度。
评论
如果您充实为什么必须进行手动测试,那么此答案将更有价值。 “他说,她说”在堆栈交换上不鼓励使用。
–阴影
18年11月16日在2:01
#4 楼
总之,计算机只能执行测试执行,并且只能执行其中一部分。由于测试不仅包含执行力,所以答案是:否。有关更多详细信息和其他因素,请参阅我的博客文章:
http://thatsabug.com // blog / why_automation_will_not_save_you /
#5 楼
手动测试是自我测试的主要目的,这是绝对必要的。如果您正在开发一种将被没人使用的产品,则可以用自动化代替一切。(我知道
使用自动化进行测试会更好,但是完全自动化?否。对我来说,这是70%的人工与30%的自动化。
即使对于全自动工厂,它们仍然需要人为保险丝,对吗?
#6 楼
我们不能将“手动测试”设置为零,但可以将其最小化。关键的和可重复的事情必须自动化。必须具备星际体系,才能将“手动”任务转换为自动化。
#7 楼
不是所有的东西都可以用自动化测试代替,也不是所有的事情都可以用手动测试来覆盖,从测试的上下文来看,它们是成比例的。无需频繁进行重大更新即可构建。是的,需要手动测试。
#8 楼
您不能自动测试的一件事是用户界面接受度。也许您可以自动化“确定按钮是否存在”和“如果您在确定按钮上单击甚至产生点击,是否会发生正确的事情”。但是您无法捕捉到像“确定”按钮那样以1x1像素大小渲染,位于可见区域之外,位于其他按钮之后,标有“ OK”的语言错误,上下颠倒并以白色字体书写的错误在白色背景上。
测试人员会立即发现有问题。但是,自动测试服需要真正先进才能检测到这些错误。而且,如果您构建了这样的高级测试服,则会产生大量误报。人类用户甚至可能不会注意到该按钮比以前小一个像素,因为他们仍然可以找到它。但是,自动测试服在显着差异和显着差异之间是没有区别的。
#9 楼
关键因素不是技术能力,而是成本其他答案对可以轻松实现自动化的测试以及可以更好地执行(在技术/质量水平上)测试的种类提供了很好的见解。使用手动质量检查。但是,我觉得经常错过的一件事是,真正的决定永远不会是“我们可以自动化这些测试”,而是“自动化这些测试是否更具成本效益”。 >制定测试自动化策略时,目标与手动测试策略完全相同-提高产品质量。自动化本身并不是直接提高质量的举动。取而代之的是,这是获得相同质量提升的另一种方式-与之相关的成本也不同。项目。但是,与大多数测试相关的成本远远高于雇用人工QA来测试相同区域的成本。
请注意,此处的成本并非专门指货币成本;而且还需要时间以及如何影响产品的发布时间表
如此,在任何情况下,当考虑“可以”和“不能”自动化时,真正需要解决的问题是;
主要注意事项
在确定哪些领域可能适合自动化时,一些关键标准可能是:
您的产品是一次性发行还是长期服务?
在持续进行开发和更改功能的同时,自动化将继续需要开发以满足不断变化的需求。在诸如视频游戏之类的单发行版产品中,花费在开发大多数自动化上的时间可能永远不会得到回报。测试在开发完成后很快就会完成。手动测试具有灵活性的优势-人工可以在其中拾取任何构建并继续对其进行检查。在只有很少更改的长期项目中-只需花费很少的维护即可运行多年即可收回自动化成本,并且可能会比同等的手动测试便宜。在涉及易于测试但涉及大量不同数据的领域中,有什么简单的功能涉及大量数据吗?
自动化开发成本可能很低,而且回报丰厚。例如,测试1000个配置文件中的每一个都正确无误地加载-作为自动测试可能很容易开发,但是要花很多天才能进行手动质量检查。同样,本地化测试涉及检查每种语言的相同功能-如果自动化可以以一种语言运行,则可能无需花费额外的精力即可在所有其他语言上运行。有功能导致故障的大型组件吗?
*对于某些产品,某些区域可能会导致故障,从而对未来的开发和测试产生很大的影响。例如,如果产品需要2小时才能下载手动质量检查,但无法在启动时崩溃进行测试-自动化此简单检查可能会减少减少人工质量检查所浪费的时间(每次构建都可以尽早捕获,节省2小时) x测试人员数量,工资小时数。)
您是否有需要满足的法律要求?
对于某些产品,需要考虑未测试的成本。虽然在一般情况下自动化可能会更昂贵;有时有必要将其成本与最坏的情况进行比较。也就是说,如果手动测试未能发现错误,这以后会使您的公司容易被起诉-自动化成本可以通过降低风险来证明是合理的,尽管它比几乎等同的手动检查要昂贵。
摘要
没有什么应该和不应该自动化的规则。每家公司为手动质量检查和自动化开发人员支付不同的费用-即使使用相同的产品,在一家公司中具有财务意义的另一家公司也可能没有意义。
作为最终经验法则:
自动化可以被认为是一项投资,需要反复运行以抵消人工质量检查的回报。也就是说,自动化衡器起价昂贵,但可扩展性好。也就是说,手动质量检查的价格便宜-但扩展性很差。
评论
这不是应该在产品级别上做出的决定,而是在特定测试的给定任务集级别上做出的决定。您可以考虑重新措词,以帮助读者理解,在整个产品级别上做出此决定可能是个坏主意。
–铁·格林姆(Iron Gremlin)
18年11月16日在1:56
#10 楼
从前,我阅读并后来编写了测试计划,其中规定必须在每个发行版之前手动完成某些测试。原因是,即使系统损坏,我们也看到自动化测试显示所有绿色。发生这种情况时,我们通常会尝试修复自动化测试,但是我们接受到,没有任何负担得起的自动化测试可以让我们轻松地让人们说“我在舞台系统上对其进行了测试,看起来不错”或“我登录并且可以正常工作,将节点再次放入负载均衡器。“
例如,我看到了Selenium测试套件,其中一个测试可以登录,单击进入配置文件页面的方式,并验证个人资料页面打开,另一个测试将登录以创建会话,直接导航到个人资料页面,然后对其进行测试。你猜怎么了?有一个具有不同单击路径的新配置文件页面,第一个测试已更改,但开发人员未删除旧的配置文件页面或第二个测试。因此,硒测试不再代表客户的旅程。但是它们都是绿色的。
如果可能的话,还有其他测试应该自动化。单元测试或API测试,大型测试,令人费解的微妙变体。但是自动化测试仅证明所有断言都是绿色的,这对于发布是必需的,但不足以实现发布。
评论
我扩大了您的问题,因为它吸引了很好的答案。如果您认为我误解了您,可以撤消我的更改。必填xkcd:这将告诉您应该/不应该自动化的内容。
您必须手动测试自动化流程。
我认为这有点主观,类似于您是否认为设计/ UX之类的东西可以自动化(就其价值而言,我认为其中任何一个都不能有效地自动化)。