直接使用 Selenium RC 或使用 Selenium 与 Robot 框架
我不得不承认，我爱上了 Selenium，因为它的录制和播放功能以及 IDE 中录制的操作的测试用例生成功能。但我仍然犹豫是否要进入实现阶段，因为在录制过程中内置于测试用例中的附带细节（例如，使用 DOM、xpath 等定位事件），这可能会使导入到 RC 后，只要 html 发生更改，测试用例就容易失败。我完全理解，作为回归测试的一部分，不时调整预期结果是测试人员工作的一部分，但我也不希望花在这上面的时间比手动测试花费的时间多。
据我所知带有Robot框架的Selenium具有测试用例的关键字形式。我的猜测是，它允许我们将附带的细节提取到各种关键字中，这可以使测试用例的调整更容易并且更易于维护。 （如果我错了，请纠正我）
如果能听到有关如何设置有效的 UI 自动化环境的建议，我们将不胜感激。我应该只使用 Selenium RC 还是带 Robot 框架的 Selenium？为什么？
提前致谢
I have to admit that I fell in love with Selenium for its record-and-play feature as well as the testcase generation functionality for those recorded actions from the IDE. But I am still hesitated to advance to the implementation stage because of the incidental details (e.g, locating the events with DOM, xpath..etc) that are built into the testcase during the recording, which could make the testcase failure prone whenever there is a html change once it's imported to the RC. I fully understand that it's a part of testers' jobs to adjust the expected results from time to time as part of the regression test, but I also do not wish the time spent on this is larger than the time that takes to do the manual test.
As far as I know Selenium with Robot framework has the keywords form of testcases. My guess is it allows us to extract the incidental details into various keywords, which could make the testcases being adjusted easier and are more maintainable. (Please correct me if I am wrong)
It will be appreciated to hear suggestions on how an effective UI automation environment should be setup. Should I just use Selenium RC or Selenium with Robot framework? And why?
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您说得对，生成的脚本中偶然且经常变化的细节是记录和回放自动化的最大问题。显然，您可以在录制后从脚本中删除详细信息，但在我看来，最好从一开始就手动构建可重用的库和代码脚本。
使用“真实”编程语言编写脚本的一个很好的替代方案是使用一些更高级别的自动化框架，例如机器人框架 你提到的。正如您所推测的，Robot 的可重用关键字和变量使得从测试中提取详细信息变得非常容易。 SeleniumLibrary 的演示中的测试用例很好地说明了这一点，演示还显示了这一点如何通过 Robot 使用 Selenium。
您还询问了Sikuli。我自己从未使用过它，但它看起来确实很有趣。您可能对这个很棒的操作方法感兴趣< /a> 解释了如何通过 Robot Framework 使用它。
You are absolutely right that incidental and often changing details in the produced scripts is the biggest problem of record-and-playback automation. You can obviously remove the details from the scripts after recording, but in my opinion it's better to build reusable libraries and code scripts manually from the start.
A good alternative for coding scripts using "real" programming languages is using some higher level automation framework such as Robot Framework that you mentioned. As you speculated, Robot's reusable keywords and also variables make extracting details away from tests very easy. The test cases in SeleniumLibrary's demo illustrates this very well and the demo also shows how to use Selenium through Robot.
You also asked about Sikuli. I've never used it myself but it sure looks interesting. You might be interested on this great how-to that explains how to use it through Robot Framework.
我们公司使用 Fitnesse，而不是 Robot，来控制 Selenium，但是，我们也有同样的问题。我们从对 DOM 做出假设转变为仅通过 ID 访问元素。由于这在 Fitnesse 中很麻烦，我们目前正在努力将 Selenium 后端添加到我们自己的框架中（之前只有 Java 和 Smalltalk 的后端）。
因此，通过要求 DOM 中存在具有特定 ID 的元素，如果有人从页面中删除这些元素，我们当然会破坏我们的测试；然而，我们发现这种行为非常有用，因为这强制执行了与实现进行的测试的合同，并且一旦有人破坏实现，我们就会发现丢失的元素，这是一件好事。
此外，保持 UI 自动化肤浅是一种很好的做法：仅使用 Selenium 测试页面上显示的内容，并通过直接调用底层函数来测试业务逻辑。
Our company is using Fitnesse, not Robot, to control Selenium however, we have the same problem. We switched from making assumptions about the DOM to only accessing elements by ID. Since this is cumbersome in Fitnesse we are currently working to add a Selenium backend to our own Framework (which previously only had backends for Java and Smalltalk).
So, by requiring that elements with certain ID's are present in the DOM we will of course break our tests if someone removes the elements from the page; however, we found that this behavious is very useful as this enforces the contract the tests made with the implementation and it is a good thing we find missing elements as soon as someone broke the implementation.
In addition, it is good practice to keep UI automation skin-deep: Only test what is present on the page with Selenium and test the business-logic by calling the underlying functions directly.