我正在构建一个Robotframework自动化项目。
随着项目的增长，随着项目选择人数的增加，维护也变得更加困难。
项目中的+ 10K选择器（一个大的选择器），每个选择器几乎没有变化;
现在我有以下结构：
typedCompare(1.0, 1.0)以一种使项目可扩展和可维护的方式保留这些定位器（与代码分开）的最佳方法是什么？
有很多方法可以做到这一点，哪一个最好？
我感谢一些想法/建议。谢谢。
答案 0 :(得分：2)
没有一个答案适合您的问题，因为它取决于您的应用程序，技术能力水平和您的（组织）编码风格。
如果您的应用程序的UI在页面或页面部分的形式中非常重复，并且具有静态ID，则页面对象模型非常适合。您可以使用PageObject Library或从中获取灵感。
集中定位器的另一种方法是使用Click Element abc=SomeVirtualId之类的自定义定位器。这个方法的一个例子可以在answer到另一个SO问题中找到。当您的元素的Id可预测并且可以生成时，此方法也很有用。然后它集中了逻辑，而不需要很多自定义关键字。
答案 1 :(得分：2)
首先，没有“最好的”。对一个组织或团队来说最好的不是另一个组织或团队。你有多少？他们经常变化多久？它们在页面之间或应用程序之间重复使用了多少？您是在测试中使用它们还是仅在关键字中使用它们？您的大部分关键字是用机器人语法编写的，还是用python或其他编程语言编写的？
我个人非常相信不存储或管理整个项目的定位器。我认为测试根本不应该有定位器。
我认为，当您将机器人框架用作框架时，通过创建自己的自定义关键字，它最有效。定位器只需要对使用它们的关键字或关键字可见，而不是遍及整个代码。
我强烈支持使用页面对象模式，其中每个页面或页面的每个部分都表示为一个对象。在该对象中，您只需要该页面或页面部分中元素的定位器。根据我的经验，这通常意味着每页只有很少的定位器。
有关如何使用robot实现页面对象的示例，请参阅我的开源项目robotframework-pageobjectlibrary。这个实现有一个存储定位器的数据结构，但在过去的一年里，我发现自己很少使用它，而是选择硬编码每个函数中的定位器。
答案 2 :(得分：2)
我目前正在开发一个类似的大型机器人框架项目，所以我不得不自己解决这个问题。这是我的解决方案：
.
|-- Project
| |-- Tests
| | |-- Suite1.robot
| | |-- Suite2.robot
| | |-- ....robot
| |-- Resources
| | |-- Suite1_Resources
| | | |-- Suite1_Keywords.txt
| | | |-- Suite1_Variables.txt
| | |-- Suite2_Resources
| | | |-- Suite2_Keywords.txt
| | | |-- Suite2_Variables.txt
| | |-- ..._Resources
一个套件处理整个网站范围内的关键字（例如，检查导航），其余则针对每个单独的页面。每个关键字文件仅处理网站上某个特定页面的关键字。每个变量文件仅处理其关联页面的变量。每个变量名称都以与其关联的页面的两个字母ID开头，以避免意外地从另一个页面继承同名变量。关键字文件从其关联的变量文件和其他关键字文件继承。 .robot测试根据需要从多个关键字文件继承，以形成测试用例。