自动GUI测试:中途会见我们

时间:2009-05-04 21:55:18

标签: user-interface testing selenium automated-tests

我的任务是开发一个自动GUI测试系统,我可以使用一些建议。幸运的是,我们正在对GUI进行重大的重新设计,开展工作的开发人员可以使他们的代码对自动化更加友好。我的问题是,我不确定要求他们添加什么。无论添加什么钩子都不会影响界面的功能,外观或安全性,并且不应对性能产生明显影响。除此之外,天空是极限!

有问题的应用程序是通过AJAX访问的基于Web的Java应用程序。大多数现有功能都使用jsp,Javascript和一些Flash 8进行编码。下一波功能将使用YUI Javascript library完成。由于其灵活性和价格标签(免费),我几乎已经确定Selenium作为测试工具。重点:我的目标是测试可重用性和易维护性。我的首选是编写检测,验证和练习页面元素的代码,而不是使用记录和回放系统进行测试开发。

任何人都可以提供一些关于可以在代码中放置什么钩子或一些最佳实践的指导,以使测试开发更容易,并且测试本身更健壮吗?

6 个答案:

答案 0 :(得分:6)

基本指导原则:如果他们希望您测试某些内容,测试人员需要一种方法让应用程序进入该状态,并且一旦处于该状态,就可以验证状态是否正确。

所以首先要确保他们理解自动化是编程而UI是你的API。

  • 同意不随意更改用户界面 - 如果测试人员Bob看到组件从按钮更改为链接,并且它与规范匹配,则单击并继续。虽然自动化中的代码更改相对容易,但可能必须在多个位置进行更改。 (您作为测试人员的工作是了解变更的发生并最大限度地降低维护成本;他们的工作只是做出重大改变并了解其影响)

  • 确定您所在页面的方法...... Bob可以区分登录和订单输入,但自动化如何知道?如果输入字段带有“用户名”标签,则为登录页面。如果是带有订单号的输入字段,则为订单字段。

不好 - 更好的练习是识别页面标题,隐藏组件等的一致UI元素。

  • 一种唯一标识您需要与之交互的每个元素的方法(点击,输入,验证等)而不是INPUT_42 ....

  • 询问开发人员测试人员可以提供哪些信息以加快调试速度,并要求他们将其放入日志文件中

  • 能够转储程序状态

  • 一致的错误处理&报告(也是很好的UI设计)

答案 1 :(得分:5)

与大多数问题一样,这取决于。主要是关于你的网站的样子以及页面上有哪些控件 - 是否有很多重复的元素等?

我使用Selenium RC和Selenium IDE取得了很大的成功。主要的是习惯使用Selenium及其命令。习惯于在页面上定位对象(XPath和CSS选择器以及'包含'功能)也很有帮助。你不想要的是很多具有相同选择路径的元素。如果下面的表格和div对它们没有独特的部分,则会给测试增加额外的复杂性。

<html>
  <body>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
    <table>
      <tr>
        <td>
          <div></div>
          <div></div>
          <div></div>
        </td>
      </tr>
    </table>
  </body>
</html>

要测试图像,能够根据图像文件名以外的其他内容检查图像是否很好,因此在更新图像时无需更改测试。如果您需要测试Flash对象check out this site

除此之外,没有一点我注意到可以纳入开发方面。一旦开始在页面上设置测试和定位元素,您可能会很快看到开发人员需要做些什么来帮助您。

答案 2 :(得分:5)

一条建议:将测试代码保存在至少两层抽象中:

  1. 上层:这应该是某种面向您特定应用术语/操作等的外观。此层直接使用Selenium RC库。在后台它使用...
  2. ... 下层:具有一些常见测试模式的库(例如:“断言选择了单选按钮控件的值”),使用Selenium RC库。
  3. 通过这种方式,您的测试将更加清晰,并且在测试内容方面更容易理解。我们甚至尝试了一种三层方法third (uppermost) layer being the tests specified using XML。这是为了让我们的非编程测试人员能够指定验收测试而无需深入研究C#代码。

答案 3 :(得分:2)

添加McWafflestix和s_hewitt的评论 - gui元素需要正确标记,独特且可预测gui自动化的成功。如果元素ID不可预测,您将遇到麻烦。可预测并不一定意味着静态。对于像用户名字段或登录按钮这样的静态页面元素,我希望这些元素的名称/ id从构建到构建是静态的,并且可以运行运行。对于复选框,单选按钮,动态内容,我希望这些是动态的,但可预测的。例如,您可能有一个div,其class =“contentdetail”和id =“12345”。只要你能够制作你的xpath来找到你需要可靠地与之交互的对象,你应该是好的。

编辑:开发人员支持测试自动化的一个好方法是使用测试设置。根据您的应用,自动测试设置和拆卸可能会有问题。例如,在仓库工作流应用程序中,工作流开始时的测试(接受项目进入仓库)很容易设置,但工作流结束时的测试(从仓库到客户的项目)都有许多依赖项(项目必须在仓库中,数量充足,库存位置正确等等),大多数自动化代码可能只需要通过应用程序导航和输入您的方式来达到您可以执行的程度一个测试。在这些情况下,使用某种外部实用程序(在app之外,因此主gui不受影响)注入依赖项或将数据库重置为某个已知状态可能是有益的。在我的仓库示例中,您的实用程序可以通过api级别设置场景,以便自动gui测试可以在相关点获取。

答案 4 :(得分:1)

我对(正确的)单元测试非常环保,但已经遇到过一些提及您应该尝试避免测试GUI的问题。他们通常会忽略特定的原因,所以我无法真正支持它们。

我采用的方法(我认为Juval Lowy在“Programming .NET Components”中提出的方法)是尝试通过接口从GUI中抽象实际代码,这样我就可以为所有业务编写单元测试由GUI触发的逻辑,而不实际测试GUI本身。

它运行良好,并且使得业务逻辑与GUI分离得更清晰,并且使GUI修改压力更小。

答案 5 :(得分:1)

开发人员可以添加很少的代码来帮助。

问题是如果你想测试代码路径的执行和那些代码路径的有效性,那应该在单元测试中完成,那些应该完全脱离你的GUI。但是如果你真的想测试你的GUI,那么你只需要模拟用户输入。可以帮助解决这个问题的一件事是让您的对象和控件正确标记,以便测试框架可以正确检测它们并进行操作。除此之外,没有太多可以做的事情(虽然这本身可以帮助很多)。