我在SUT中使用了类似的方法，因为它可以与相当复杂的对象一起使用，这些对象既可以在测试执行期间预先创建也可以动态生成-
并且它们的主要用户可识别属性是显示的名称。这是我流程的简化版本，它基于字符串替换。
从变量文件（一个简单的硒定位符集合）开始，该定位符的值具有一个“特殊”字符串，该字符串稍后将被替换：
*** VARIABLES *** ${DROpDOWN ITEMS} xpath=//*[contains(@class,'listitem-element')]/span[contains(text(),'SELENIUM_PLACEHOLDER_CHANGE_ME')]然后，在关键字文件中，有一些专用关键字可用于返回正确的定位符，例如：
*** KEYWORDS *** _Return Selenium Locator For The Dropdown Item Named [documentation] Verifies the desired dropdown item is valid, ando returns its locator (not Webelements!!) [Arguments] ${name} # change the placeholder with the actual UI name ${loc}= Replace String ${DROPDOWN ITEMS} SELENIUM_PLACEHOLDER_CHANGE_ME ${name} # why? Rationale explained below Element Should Be Visible ${loc} message=The dropdown does not have an item called ${name} [Return] ${loc}为什么要进行可见性检查？简单-如果SUT中当前没有这样的对象，则尽早失败，并具有统一的错误消息，而与元素的进一步使用方式无关（单击，检查存在性，属性检索等）
然后，用于对元素执行操作的后续用户关键字使用上一个：
# the user keywords Choose Value From Dropdown [documentation] It does what it does :) [Arguments] ${the value} ${loc}= _Return Selenium Locator For The Dropdown Item Named ${the value} # as you can see, no checks is the element real - that'she offloaded to the helper keyword ^ Focus Element ${loc} Click Element ${loc}最后，测试用例使用关键字来处理您认为有误的任何数据：
*** TESTCASE ***The dropdown should do X [documentation] Steps: 1, 2, 3, etc # do the normal steps you'do do Choose Value From Dropdown my current value
这种方法也适用于否定测试-例如，要检查一个值是否不存在，测试用例应包含：
Run Keyword And Expect Error The dropdown does not have an item called no_such_element Choose Value From Dropdown no_such_element
因此，我们都在使用硒检查元素的缺失，并保持测试用例接近真实的表达-对应该发生的情况的描述，没有特殊的语法和SE关键字。
请原谅任何错别字和轻微的语法遗漏-在手机上键入那么多字并不容易，下一次在使用：D之前我会三思而后行
