直接使用 Selenium RC 或 Selenium 与 Robot 框架

Posted 2023-03-23

【中文标题】直接使用 Selenium RC 或 Selenium 与 Robot 框架

【英文标题】：Use Selenium RC directly or Selenium with Robot framework

【发布时间】：2011-06-21 14:35:28

【问题描述】：

我不得不承认，我爱上了 Selenium，因为它的记录和播放功能以及用于从 IDE 记录的操作的测试用例生成功能。但是我仍然犹豫是否要推进到实施阶段，因为在录制过程中内置于测试用例中的附带细节（例如，使用 DOM、xpath..etc 定位事件）可能会使将测试用例导入 RC 后，只要有 html 更改，就容易发生测试用例失败。我完全理解，作为回归测试的一部分，不时调整预期结果是测试人员工作的一部分，但我也不希望花在这上面的时间大于进行手动测试所需的时间.

据我所知Selenium with Robot framework 有测试用例的关键字形式。我的猜测是它允许我们将附带的细节提取到各种关键字中，这可以使测试用例更容易调整并且更易于维护。 （如有错误请指正）

如果您能听到有关如何设置有效的 UI 自动化环境的建议，我们将不胜感激。我应该只使用 Selenium RC 还是 Selenium 和 Robot 框架？为什么？

提前致谢

【问题讨论】：

或者，有人用过 sikuli 吗？与 selenium ide 相比如何？测试用例能否轻松集成到测试运行器中？

【参考方案1】：

您说得对，所制作脚本中偶然且经常变化的细节是录制和播放自动化的最大问题。您显然可以在录制后从脚本中删除细节，但我认为最好从一开始就手动构建可重用的库和代码脚本。

使用“真正的”编程语言编写脚本的一个很好的替代方法是使用一些更高级别的自动化框架，例如您提到的Robot Framework。正如您所推测的，Robot 的可重用关键字和变量使得从测试中提取细节变得非常容易。 SeleniumLibrary's demo 中的测试用例很好地说明了这一点，并且演示还展示了如何通过 Robot 使用 Selenium。

您还询问了Sikuli。我自己从未使用过它，但它确实看起来很有趣。您可能对 this great how-to 感兴趣，它解释了如何通过 Robot Framework 使用它。

【讨论】：

那么，你说最好直接在 Robot Framework 中编写测试？我有在 Robot 中编写测试的经验（我喜欢它），但我根本没有尝试过 Selenium IDE。使用起来似乎更容易或更快..

如果您的目标是创建 Robot Framework 测试，那么从一开始就使用 Robot 语法创建它们肯定会更好。例如，您不能轻松地将 Selenium IDE 测试转换为 Robot 语法。 Selenium IDE 生成的测试级别非常低，通常难以维护，但显然有一些用例可以做到这一点。

【参考方案2】：

我们公司正在使用 Fitnesse 而不是 Robot 来控制 Selenium，但是我们也遇到了同样的问题。我们从对 DOM 的假设转变为仅通过 ID 访问元素。由于这在 Fitnesse 中很麻烦，我们目前正在努力将 Selenium 后端添加到我们自己的框架（以前只有 Java 和 Smalltalk 的后端）。

因此，通过要求 DOM 中存在具有特定 ID 的元素，如果有人从页面中删除了这些元素，我们当然会破坏我们的测试；但是，我们发现这种行为非常有用，因为这会强制执行与实现进行的测试的合同，而且一旦有人破坏了实现，我们就会发现缺失的元素是一件好事。

此外，保持 UI 自动化肤浅是一种很好的做法：仅使用 Selenium 测试页面上存在的内容，并通过直接调用底层函数来测试业务逻辑。

【讨论】：

如果我错了，请纠正我，听起来贵公司强制网络开发人员将 ID 挖掘到元素标签中。而且，如果 ID 是测试人员和开发人员之间的合同，这将大大降低在测试用例中引入附带细节的风险。此外，修复它所花费的时间实际上是因为需求的变化。请问我们公司的 QA 工程师如何生成他们的测试用例，使用 Selenium IDE 或简单地编写代码。与其他选项相比，此选项有什么好处。期待你的答复。谢谢

是的，我们使用每个 DOM 元素的 ID。但是这些可以自动生成，开发人员和测试人员都可以轻松找到它们，因为它们被粘贴到原始 html 中（没有间接性，这仅用于我们的测试而不是用于外部消耗）。一旦测试人员有了 ID，他就不再需要导航 DOM 树，而只需按 ID 选择并以表形式编写测试用例，如 |123|contains|asdf|，如果其中一个测试表注意到错误，测试套件可以将元素 ID 提供给立即知道他们破坏的确切位置的开发人员。

很久没有回这个页面了。与其创建一个错误并希望开发人员在正确的位置注入 id，不如我自己作为测试人员自己做。我自己做，并通过检查我的集成测试是否涵盖更改的代码来判断我是否可以触及生产代码。开发人员有他们的时间。认为这会让工作完成得更快，工作环境更愉快。