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