代码之家  ›  专栏  ›  技术社区  ›  Tushar Tarkas

单元测试UI应用程序

  •  1
  • Tushar Tarkas  · 技术社区  · 15 年前

    用户界面应用程序可以进行单元测试吗?让我们考虑一个具有简单登录表单的UI应用程序。这个UI应用程序的单元测试的组成部分是什么。后端响应验证是否应成为登录表单单元测试的一部分?

    在我看来,它应该包括:

    1. 窗体中的UI组件的适当呈现。
    2. 根据用户操作启用/禁用组件(未输入密码且提交表单时,密码不能为空消息)。

    在为UI应用程序设计单元测试用例时,是否应该使用拇指准则/规则?在单元测试中应该考虑应用程序行为吗?

    3 回复  |  直到 15 年前
        1
  •  2
  •   Péter Török    15 年前

    UI测试不是严格意义上的单元测试,但是有工具/框架可以帮助实现这一点。我假设你是指一个网络用户界面-为此你可以尝试例如。 Selenium HttpUnit .

    请注意,“UI组件的适当呈现”是一个非常宽松的术语——它可能意味着一些不能自动验证的东西,只有人眼才能验证。

    通过UI测试功能总是比通过经典的单元测试直接测试代码更麻烦。因此,总是建议尽可能地将业务逻辑与UI分离开来-然后,您可以通过单元测试彻底测试逻辑本身的所有缺陷和缝隙,并且只需要在UI上进行集成测试来验证应用程序作为一个整体是否按预期工作。

    在您的示例中,理想情况下,输入验证和身份验证将与GUI分离,因此您可以对它们进行单元测试(最好是模拟出数据库)。因此,您可以验证登录在所有类型的正常/异常输入(空的用户ID/密码、奇怪的字符、很长的输入、登录同一个用户两次,…)中是否按预期工作。然后,在UI测试中,您只需要测试几个常见的测试用例来验证应用程序是否确实正常工作。

        2
  •  3
  •   Thomas Weller    15 年前

    一般来说,测试UI组件不是一项简单的任务-您需要一个良好的测试代码体系结构、相当多的工具(可能会带来一些许可证成本…)以及至少一个虚拟机。

    最重要的是要有一些“模型视图”- 尤尼米特 '体系结构就位,因为只有这样才能将UI与应用程序的其余部分隔离开来。登录表单的测试可以如下所示:

    • 工具(例如白色或ranorex)模拟用户键入某些用户/密码组合。
    • 测试(通过模拟框架或typemock等帮助)验证是否调用了正确的方法(或在某些情况下不调用)。

    在任何情况下,UI测试都必须避免调用下面的一些业务逻辑。如果您不能以这种方式隔离UI(通常情况下,尤其是对于遗留项目…),那么自动化UI测试可能根本没有好处,因为在这种情况下,自动化测试往往会带来太多的工作。有时候你最好手动测试…

    嗯!
    托马斯

        3
  •  1
  •   tchen    15 年前

    如果您的UI是本机图形应用程序,您可能需要考虑 AutoIt (仅限Windows),它允许您以编程方式单击屏幕上的任何位置,并模拟输入到小部件中的文本或仅键盘按下。它还能够在指定位置读取像素的颜色。或者你也可以用它来拍摄屏幕照片和进行图像比较。

    如果它是基于Web的,您可能还需要考虑使用xpath来确定(非图形)生成的HTML中是否存在元素。不过,它对页面的呈现方式没有帮助。autoit也可以帮助解决这个问题,但是如果您希望所有平台的所有用户都能够合理地访问您的页面,那么您将无法在不同的平台上执行相同类型的测试。

    如果您的UI是基于控制台的,请考虑使用Expect。我更喜欢 Perl based expect ,这是基于 TCL Expect .

    我知道我不是直接回答关于规则或指导方针的问题,但我认为知道那里有哪些可用的工具将打开你认为可能不存在或没有考虑的可能性。正如一个例子,您可以使用autoit来确定一个组件是被禁用还是被启用,因为当它被禁用时,这个小部件的颜色通常与被启用的版本不同。因此,通过使用autoit获取屏幕像素或区域的颜色,您可以通过编程的方式测试这个小部件是否被启用。