最近,我被要求编写以下样式的一些自动化GUI测试:


打开应用程序
打开所有对话框
在每个对话框中检查。 ..

这些类型的测试值得吗?这些测试有什么好处?在某些情况下,它们可能非常易于编写,但在另一些情况下,则需要对应用程序许多不相关部分的广泛了解。同样,他们可能需要很长时间才能完成,无论是否发现问题。有时候我觉得这些测试是不值得的,但是我可能是错的。有什么想法吗?

#1 楼

要回答“它们是否值得?”这个问题,您需要探索:


它们在创建,维护和执行上花费多少(在时间和金钱方面)?
这些测试提供什么价值?他们在寻找错误吗?提供信心吗?
还有其他更便宜的方法来提供相似的价值吗?我们有一名实习生,他的职责是彻底检查UI并根据UI对象大小,位置,间距,字体选择等标准对它进行测量。他基本上执行了您指示的所有步骤,等等。我们最终能够使其中一些自动化(这是在测试自动化的早期),但不是全部。在我们看来,这笔钱花得很充裕。对于我的公司来说,完全的UI一致性被认为是我们预期市场的重要属性。

#2 楼

回答您的问题需要知道为什么要求您编写这些测试。与解决应用数学问题不同,我们通常不会出于纯粹的乐趣或智力挑战而编写自动化的UI测试。我以为您被要求以这种风格编写它们。如果有理由认为UI特别容易出错,并且自动测试UI比手动测试容易,则编写它们可能是有道理的。错误的原因。推理通常是这样的:UI最终是用户将与之交互的界面,业务逻辑中的错误不一定会由UI的使用方式触发,并且当您测试UI时,您将在以下位置测试业务逻辑同一时间。但是,结构良好的应用程序会将UI与业务逻辑分开。通常最好将API级别的测试用于业务逻辑。测试将更快,更好地利用UI中不可用的API级诊断。它们也会与UI更改隔离(尽管它们当然不会与API更改隔离)。

您已经在SQA中工作了一段时间,所以我怀疑您已经知道这一点,但是我会出于完整性考虑。一些工具供应商和UI自动化宣传人员倡导的推理方法如下:自动化是很困难的,因为它需要编程,但是如今,强大的捕获/回放工具可以用最少的编程知识快速创建自动化的UI测试套件。您没有说要使用哪种技术来编写这些测试,但是如果您正在考虑使用捕获/回放,则可能需要在本论坛中阅读有关该主题的其他问题。

评论


由于错误的原因,UI测试的另一点是:进行严格的UI测试可能是无法测试的代码的征兆,而在较低级别上的测试还不够好。 UI测试本质上应该只是确保UI响应应有的方式-而不是功能测试(某些例外情况,例如端到端测试)。单元测试,API测试,组件测试等应涵盖功能。在大多数情况下,UI测试应该只是整体测试工作的一小部分。

– Ethel Evans
2012年7月12日在17:32

#3 楼

我同意Aniket的观点,这种详尽的UI测试是不值得的。需要考虑的另一件事:

前一段时间,我从离开公司的人那里继承了一个手动测试用例计划。他一直在做诸如检查应用程序每个区域中的列表排序行为之类的事情。他不是程序员,也不了解排序机制的下拉框后面的代码每次都相同。他正在过度测试。如果您的测试计划要求与每个小部件进行交互,这就是您遇到的事情。开发人员选择使用的UI框架。无论如何,当您执行功能测试时,很可能会发现任何特定于UI的错误。

#4 楼

恕我直言,不。

原因如下:


根据您的UI,实现成本可能会很高。当您的UI在下一个版本中发生更改等时,请别忘了总结一下维护它的成本。这本身应该引起您的第三次思考。
UI测试可能很不稳定。以我的经验,UI测试用例的准确性非常低。我想如果用蛮力强迫会变得更糟。
如果有10个元素,那么会有10个!迭代?!
执行这些TC所需的时间和资源,然后调查故障可能会超过收益。 :-) 我猜不会。有您的答案。

希望有帮助。

#5 楼

我认为,自动化测试方案需要围绕实际用例构建,因此有意义的测试脚本应接近用户通常会执行的操作

如果在您的系统中,通常用户会这样做打开所有表格并填写所有复选框,然后,是的,否则-它没有用。即使此测试会发现一些错误,并且开发者将花费一些时间来修复它们,以解决永远不会发生的情况,对于开发人员来说,花这段时间为他们的用户创建新功能会更好吗?