4

我们使用自动化测试来验证我们的 Web 应用程序的功能。为了使测试用例中的断言更简单、更灵活，我们正在考虑引入“TestIDs”，即HTML 标记中的ID，帮助测试用例查找和验证页面上的元素。此外，这些 TestID 将允许更具体的集成测试，由于页面上的数据有限，这些测试目前是不可能的。

然而，这让我们犹豫不决：

  • 引入测试 ID 意味着更改测试的测试
  • 安全性- 我们会披露内部域对象 ID 和其他在页面上不可见的信息
  • 标准- 根据我们如何将 TestID 放入标记中，我们很可能会违反元素或属性的预期语义使用（例如，“id”或“类”属性、其他 html 元素等）
  • 干扰- TestID 可能会干扰应用程序代码
  • 性能- TestID 是不必要的标记（对用户而言）并增加页面大小（仅在大页面上显着）

将 TestID 限制为测试/暂存 HTML 似乎不是一个好主意，因为我们显然想要测试将在生产中使用的代码，并且不希望我们的测试/暂存环境表现不同。事实上，我们目前在发布后针对实时系统运行部分测试套件。

您认为 TestID 是一个好主意吗？如果是，您将如何将它们放入标记中？

一些示例标记来演示我在说什么：

<!-- this test id allows an integration test to verify that
  the carrot 188271 is in fact green but exposes the id to the user -->
<tr id="testid-carrot-id-188271">
    <td class="color">green</td>
    <td class="size">doesn't matter</td>
</tr>
4

3 回答 3

6

我永远不会将用于测试的代码留在实时站点中。这只是糟糕的原则和邀请黑客攻击。

只要您的测试 ID 的格式不会与页面上的其他 ID 冲突（ID 必须是唯一的）并且不会被任何实时代码引用（如果您无法确定有什么这里有更大的错误），那么具有 ID 的测试站点和没有 ID 的实时站点之间的行为应该没有任何差异。

在我看来，最佳实践是这样设计，使您的测试代码在您的开发站点上正确执行，并且您知道删除它不会损害您的实时站点。如果我的网站需要定期测试实时版本以确保其正常工作，我会担心。

于 2009-06-22T17:03:30.227 回答
3

您是否考虑过使用其他东西来识别元素，例如 XPath？我不知道您的页面有多动态，但 XPath 可以非常具体地包含您想要的元素。

就我个人而言，我不会用测试 ID 膨胀生产 HTML。

于 2009-06-22T16:55:21.377 回答
3

我想说更容易和更好的测试的好处超过了感知的风险。我假设您正在谈论类似以下内容：将 id='resultDetail' 添加到页面上的结果详细信息元素，以便更容易找到自动化测试。坦率地说，我看不出这有什么害处。如果我的观点过于简单化，也许您可​​以提出一些示例标记，让我们更好地了解您正在考虑的内容。

Having seen your sample markup, I don't see any problem with having the id available to the user. Many applications expose domain ids. As a matter of fact, in my experience, often those domain ids are an integral part of the UI - often ids will be links that you can click on to get more detail, to edit, delete, etc...

于 2009-06-23T12:24:47.497 回答