在我的测试自动化实践中，我总是使用减少维护工作的 gui 映射策略。
例如，如果我需要识别“ Google 搜索”按钮 (www.google.com)，它的 XPAth 将是
//input[@name='q']/html/body/center/form/table/tbody/tr/td[2]/input[3]但也许我错过了什么？也许如果文档结构发生变化，我应该知道这一点并且我的一些测试应该失败？
你怎么看？你会推荐什么最佳实践？
如果元素具有脚本/css 使用的 id，我们在测试中使用该 ID。否则，我们会主动检测我们的 HTML 以进行测试。我的意思是我们可以添加一个 id仅用于测试以避免任何歧义。我们通常给它一个前缀来表示这一点，即。id="ftGoogleButton"。这样一来，只使用 HTML 的人就会明白存在与元素相关的自动化测试。这种约定是实用的，因为它们通常只会在 css/js 中查找对给定 id 的引用。
我也会这样做，选择第一个配方而不是第二个......对于大多数测试。
您希望您的测试在与这些测试涵盖的功能相关的更改时中断，并且您希望相同的测试忽略对应用程序的大多数其他更改。
因此，如果您正在检查搜索“foo”是否应该返回超过零个文档，这与页面结构无关，应该忽略此类更改。
但是，在为确保搜索表单配备提交按钮而编写的测试中，您希望在用于从表单导航到按钮的 XPath 中体现这些假设。
正如 krosenvold 所说，让开发人员标准化 htmlname和/或id属性并使用它们是最好的策略之一。我的论文Test Automation as a Development Requirement讨论了这个主题以及开发人员可以做的其他事情，以使应用程序对自动化更加友好。
您还应该确保所有对象标识属性都存储在一个中央存储库中，以使后续维护更容易。大多数商业工具都内置了此功能，但使用开源工具，您可能需要推出自己的机制。