我不得不承认，我爱上了Selenium，因为它的记录和播放功能以及用于从 IDE 记录的操作的测试用例生成功能。但是我仍然犹豫是否要进入实施阶段，因为在记录过程中内置于测试用例中的附带细节（例如，使用 DOM、xpath..etc 定位事件），这可能使测试用例在任何时候都容易失败将 html 导入 RC 后进行更改。我完全理解，作为回归测试的一部分，不时调整预期结果是测试人员工作的一部分，但我也不希望花在这上面的时间大于进行手动测试所需的时间.
据我所知，带有 Robot 框架的 Selenium 具有测试用例的关键字形式。我的猜测是它允许我们将附带的细节提取到各种关键字中，这可以使测试用例更容易调整并且更易于维护。（如果我错了请纠正我）
很高兴听到有关如何设置有效的 UI 自动化环境的建议。我应该只使用 Selenium RC 还是 Selenium 和 Robot 框架？为什么？
提前致谢
您说得对，所制作脚本中偶然且经常变化的细节是录制和播放自动化的最大问题。您显然可以在录制后从脚本中删除细节，但在我看来，最好从一开始就手动构建可重用的库和代码脚本。
使用“真实”编程语言编写脚本的一个很好的替代方法是使用一些更高级别的自动化框架，例如您提到的机器人框架。正如您所推测的，Robot 的可重用关键字和变量使得从测试中提取细节变得非常容易。SeleniumLibrary 演示中的测试用例很好地说明了这一点，该演示还展示了如何通过 Robot 使用 Selenium。
您还询问了斯库里。我自己从未使用过它，但它确实看起来很有趣。您可能会对这个解释如何通过 Robot Framework 使用它的好方法感兴趣。
我们公司正在使用 Fitnesse 而不是 Robot 来控制 Selenium，但是我们也遇到了同样的问题。我们从对 DOM 的假设转变为仅通过 ID 访问元素。由于这在 Fitnesse 中很麻烦，我们目前正在努力将 Selenium 后端添加到我们自己的框架（以前只有 Java 和 Smalltalk 的后端）。
因此，通过要求 DOM 中存在具有特定 ID 的元素，如果有人从页面中删除了这些元素，我们当然会破坏我们的测试；但是，我们发现这种行为非常有用，因为这会强制执行与实现进行的测试的合同，而且一旦有人破坏了实现，我们就会发现缺少的元素，这是一件好事。
此外，保持 UI 自动化的肤浅是一种很好的做法：仅使用 Selenium 测试页面上存在的内容，并通过直接调用底层函数来测试业务逻辑。