GUI的抽象测试

时间:2009-11-11 06:33:08

标签: user-interface testing

一般来说,如何测试GUI的各个部分?什么是好的做法? (是的,我在这里过于笼统)。

记下记事本的查找对话框:

Notepad's Find dialog box http://img697.imageshack.us/img697/5483/imgp.png

有哪些东西可以测试?如何知道它的正常工作?什么是边缘情况需要注意?压力测试?

4 个答案:

答案 0 :(得分:2)

Here
我怀疑是否可以对此做出任何好的概括 - 它总是取决于具体情况。

答案 1 :(得分:1)

我认为最好将功能方面和GUI测试的可用性方面分开。

让我们在上面的示例中说明用户输入一些文本并点击“查找”按钮的用例。从功能方面我会说你的测试应该检查这个用户操作(事件)是否调用适当的事件处理程序方法。如果你的代码在GUI显示代码和中间有很好的分离,这些可以自动化 功能部分。

可用性方面的测试将涉及检查显示是否在多个平台中正确显示。我认为这需要手动验证。但是我认为有一些工具可以自动化这种GUI测试,但我没有使用它们。

答案 2 :(得分:1)

当有人要求对GUI进行测试时,我总是认为这意味着“可通过此GUI访问的应用程序的这一部分”。否则,这意味着只测试GUI而没有任何逻辑钩住。 Dunno为什么没有人真正要求测试是否按下按钮时触发事件或显示窗口获取焦点。

无论如何回到问题。首先要了解等价类,边界条件等其他测试技术。而不是尝试将其应用于给定的问题。而不是试图创造性。 在创建以下测试时应该应用所有这些:
1)快乐路径测试 - 当给定输入良好时应用程序正常运行 2)否定测试 - 当给定输入不良时,应用程序正确行事 3)精神病用户行为(我看到有人使用这个术语,我发现它很棒) - 一个用户没有什么比打破你的应用程序更好的事情,或者实际上知道他做了多么糟糕和可怕的事情是愚蠢的与您的应用程序。

毕竟如果所有测试都通过而且你无法弄清楚其他测试,那么你不知道它是否正常工作,但是你可以说它通过了所有测试并且似乎工作正常。

至于给定的GUI示例 1)
应用程序查找字符串是否在打开的文件中? 应用程序是否在打开的文件中找到字符?
在搜索过程中如何对文件结束做出反应? 当有许多外观时,它是否找到给定字符串/字符的其他外观或只有一个外观? 它是否处理像*或?这样的特殊搜索字符?是否正确? 它是否朝着理想的方向搜索? “马赫箱”选项是否正常工作? 当打开find设置一些标准时,取消搜索并再次启动它 - 搜索条件是否恢复为默认值?或者在单击取消时将它们设置为离开它们?

2)
在尝试搜索未打开文件的数据时,是否通知用户没有找到马赫? 在尝试搜索文件末尾时是否正确反应?
在尝试搜索文件的开头时它是否正确反应?
没有加载文件时搜索功能如何响应? (在MS记事本中它可以完成,但在其他编辑器中,您可以启动编辑器而无需打开文件,因此此测试)
我可以标记Up和Downs搜索方向吗?

3)
它是否在4GB文件上正常工作?
我可以在“查找内容:”字段中加载4 GB字符串并进行搜索吗? 我可以通过提供ASCII代码提供特殊字符输入吗? (就像按下Alt和字符数......或类似的东西) 我可以搜索空字符(在字符表中有类似的东西) 我可以搜索行尾或CarretReturn等字符吗? 它会搜索不同语言的字符吗? (中文或其他非英文字母字符)
我可以注入像'DROP ALL TABLES这样的东西; (如果那是基于网络的搜索) 我能通过真正快速双击搜索按钮两次启动适当的事件吗? (在网络应用上更容易)

使用合理的测试套件,您知道它似乎正常工作。

答案 3 :(得分:1)

测试已完成的用户界面很困难且容易出错。

但如果您对程序员的观点更感兴趣,请阅读论文The Humble Dialog。它提供了一个用于创建UI的体系结构,其功能可以使用标准测试框架在代码中进行测试。