自动化GUI测试：与我们半途而废

Question

自动化GUI测试：与我们半途而废

user-interfacetestingseleniumautomated-tests

10

我被委托开发一个自动化GUI测试系统，需要一些建议。幸运的是，我们正在进行重大的GUI重新设计，负责此项工作的开发人员愿意让他们的代码更加友好，方便自动化。我的问题是我不知道要求他们添加什么钩子。无论添加什么钩子都不能影响接口的功能、外观或安全性，并且不应对性能产生明显影响。除此之外，没有任何限制！

所涉及的应用程序是通过AJAX访问的基于Web的Java应用程序。大部分现有功能是使用jsp、JavaScript和少量Flash 8编码完成的。下一波功能将使用YUI JavaScript库完成。由于其灵活性和价格（免费），我几乎决定使用Selenium作为测试工具。主要考虑点：以测试可重复使用性和易维护性为目标。我更喜欢编写检测、验证并执行页面元素的代码，而不是使用记录和播放系统进行测试开发。

是否有人能提供关于可以放置在代码中的钩子或使测试开发更容易且测试本身更加健壮的最佳实践的指导？

- Logan

6个回答

5

与大多数问题一样，这取决于你的网站长什么样，页面上有什么控件 - 是否有许多重复的元素等？

我在使用Selenium RC和Selenium IDE方面取得了很多成功。主要是要习惯使用Selenium及其命令。熟悉定位页面上的对象（XPath和CSS选择器，以及'contains'函数）也很有帮助。您不希望有很多具有相同选择路径的元素。如果下面的表格和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对象，请查看此网站。

除此之外，在开发方面我没有注意到有什么可以结合进去的东西。一旦您开始设置测试并定位页面上的元素，您很快就会看到开发人员需要做什么才能帮助您。

- s_hewitt

5

一个建议：将你的测试代码至少分为两个抽象层：

上层：这应该是一种面向特定应用程序术语/操作等的外观。这一层不直接使用Selenium RC库。它在后台使用...
...下层：一个具有一些常见测试模式的库（例如：“断言单选按钮控件的值X被选择”），它使用Selenium RC库。

这样，你的测试将更易于维护，并且在测试什么方面方面上更容易理解。我们甚至尝试了三层方法，其中第三层（最上层）是使用XML指定的测试。这是为了让我们非编程测试人员能够指定验收测试而不必深入到C#代码中。

- Igor Brejc

2

补充McWafflestix和s_hewitt的评论 - gui元素需要被正确标记，唯一且可预测，才能成功地进行gui自动化。如果元素id不可预测，则会遇到麻烦。可预测并不一定意味着静态。对于静态页面元素，例如用户名字段或登录按钮，我希望这些名称/ id在构建到构建和运行到运行时保持静态。对于复选框、单选按钮、动态内容，我希望它们是动态的，但可预测的。例如，您可能有一个class =“contentdetail”和id =“12345”的div。只要您可以精心制作xpath以可靠地找到需要交互的对象，您就应该没问题。

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

- Tom E

1

我对（适当的）单元测试还不是很熟悉，但我遇到了一些提到你应该尽量避免测试GUI的情况。他们通常省略具体原因，所以我无法支持他们。

我的做法（我认为Juval Lowy在“Programming .NET Components”中也建议这样做）是通过接口将实际代码与GUI分离，这使得我可以编写单元测试来测试由GUI触发的所有业务逻辑，而不必真正测试GUI本身。

这种方法效果很好，使代码更加清晰，业务逻辑与GUI分离，同时也使得GUI修改变得更加轻松。

- STW

1

这些人可能的意思是你不应该在单元测试中测试GUI。对此，你将GUI和业务逻辑分开的方法是一个好主意。当然，你仍然必须测试GUI，最好这些测试也应该自动化。 - sleske

1

开发人员在代码中添加的内容非常少，无法提供太多帮助。

问题在于，如果您想测试代码路径的执行和有效性，则应在单元测试中完成，并且这些测试应完全与 GUI 分离。但是，如果您真的想测试您的 GUI，则必须模拟用户输入。唯一可以帮助解决此问题的方法是正确标记对象和控件，以便测试框架可以正确检测并进行测试。除此之外，就没有太多可以做的了（尽管这本身就可以帮助很多）。

- Paul Sonier

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Klaus K · Accepted Answer

基本指导原则：如果他们希望您测试某些内容，测试人员需要一种方法将应用程序置于该状态，并且在该状态下验证该状态是否正确。

因此，首先要确保他们理解自动化是编程，UI是您的API。

协议不随意更改UI - 如果测试人员Bob看到组件从按钮更改为链接，并且与规范匹配，则单击并继续。虽然这在自动化中是相对容易的代码更改，但这是可能必须在多个位置进行的更改。（您作为测试人员的工作是了解变化并最小化维护成本；他们的工作是仅进行重要更改并了解影响）

确定您所在的每个页面的方法.... Bob可以区分登录和订单输入之间的区别，但自动化如何知道呢？如果有一个带有“用户名”标签的输入字段，则为登录页面。如果有一个带有订单号的输入字段，则为订单字段。

不好-更好的做法是使用一致的UI元素来识别页面-页面标题，隐藏组件等。

一种唯一地标识您需要交互的每个元素的方法（单击，键入，验证等）。而不是INPUT_42....

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

能够转储程序状态

一致的错误处理和报告（也是良好的UI设计）