自动化 GUI 测试：半途而废

StackOverflow https://stackoverflow.com/questions/822275

题

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

相关应用程序是一个通过 AJAX 访问的基于 Web 的 Java 应用程序。大多数现有功能都是使用 jsp、Javascript 和少量 Flash 8 进行编码的。下一波功能将使用 YUI Javascript 库. 。我已经决定了 硒 作为测试工具，因为它的灵活性和价格标签（免费）。主要观点：我的目标是测试可重用性和易于维护。我更喜欢编写检测、验证和练习页面元素的代码，而不是使用记录和回放系统进行测试开发。

任何人都可以提供一些指导，说明可以在代码中放置哪些挂钩或一些最佳实践，以使测试开发更容易并使测试本身更健壮吗？

有帮助吗？

解决方案

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

因此，第一件事是确保他们理解自动化就是编程，而 UI 就是 API。

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

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

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

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

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

  • 能够转储程序状态

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

其他提示

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

我使用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对象，请查看此网站。

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

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

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

    3. 通过这种方式，您的测试将更加清晰，并且在测试内容方面更容易理解。我们甚至尝试了三层方法，第三层（最上层）是使用XML指定的测试。这是为了让我们的非编程测试人员能够指定验收测试而无需深入研究C＃代码。

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

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

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

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

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

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top