为什么要使用Page Factory？
我是一名新的测试工程师，他一直在阅读有关页面对象模型的信息并实现它们并不断访问Page Factory。 我知道Page Factory是一个POM，它提供了额外的function，例如在调用Page Factory时实例化所有元素，以及更可读的代码用于测试（尽管我的可读性并不完全出售）。 要清楚，我是在POM上出售的。 代码的可重用性和相对容易的维护是很好的，我正朝着这个方向努力。
我提出的两个问题是：
- 为什么我要实例化所有元素而不是动态执行？
- 我错过了Page Factory的优点是什么？
这是2016年Selenium Conf在奥斯汀的Selenium项目负责人和Page Factory的创建者Simon Stewart。 在他的主题演讲中，他说不要使用Page Factory。 这部分讲座从这里开始：
https://youtu.be/gyfUpOysIF8?t=1517
实际发言时间为27:25。
一些答案说，PageFactory在实例化时“加载”所有WebElements – 这实际上并不正确。
在您访问元素之前，元素不会加载。 它是通过基类和RealProxy完成的。 它确实使用标准的FindElement(s)By方法，因此使用WebElements与存储By并在需要时加载它们没有真正的性能优势。
我选择不使用PageFactory模型的一个原因是，我可能会搜索一个我不想存在的元素，并且通过使用自动连线方法，它会搜索以查看它是否存在之前我可以说“在测试中不存在。
另一个问题是PageFactory如何实例化WebElement与Driver.FindBy如何实例化它们之间存在细微差别。 让我感到困惑的是，PageFactory的版本没有实现IWrapsDriver ，这意味着你无法获得用于从元素中找到元素的驱动程序。 这可能看起来不是很多，但这意味着当你想要为WebElement方法编写扩展而又需要驱动程序时，你必须找到一种（更复杂的）获取驱动程序的方法，特别是因为我相信PageObjectModel应该没有直接参考司机……
但是，在很多情况下，开箱即用的PageFactory方法非常好。 我认为使用或不使用PageFactory的关键只是对测试代码和页面对象模型的工作方式和交互方式采用一致的方法 – 因为这是可维护性的关键。
为什么我要实例化所有元素而不是动态执行？
如果我没记错的话， PageFactory扫描任何WebElement属性/字段及其属性，并用代理包装它们。 那时你还没有接触到Selenium服务器（你可以在服务器控制台输出中查看）。 一旦您尝试访问该属性， WebElement就会被实例化。 因此，如果您只访问了一个PO属性/字段，则只创建一个WebElement 。
我错过了Page Factory的优点是什么？
属性的使用使代码更易读，也易于生成。 通常会创建一个为您生成PageObject的工具。
创建PageFactory是为了支持PageObject模式，仅此而已。 你没有必要使用它以便采取PO方式。
最后，如果您对它的详细工作方式感到好奇，我建议您查看源代码。 这就是我刚开始使用Selenium时的所作所为。
-
为什么我要实例化所有元素而不是动态执行？
PageFactory可用于初始化Page类的元素，而无需使用FindElement或FindElements。 当您使用webelement时，一旦您的代码获得更好的可读性。
-
我错过了Page Factory的优点是什么？
您还可以使用Page Factory的某些属性。 最明显的是FindsBy属性，但您也可以使用CacheLookup属性在查询一次后缓存该元素。
为什么我要实例化所有元素而不是动态执行？
通常，当我们通过PageFactory启动任何页面类时，它使我们能够同时加载所有期望的（已定义的） WebElements ，我们打算在粗略的Test Execution中进行交互。
我错过了Page Factory的优点是什么？
使用Page Factory的优势很多。 其中一些如下：
-
Page Factory使您的框架更加结构化，健壮且可维护。 - 可以非常容易地适应任何单个/多个页面的
DOM Tree的更改。 - 通过
Page Factory，@@Test类，BrowserFactory，Page Objects和Assertions之间的不同调用变得更加清晰和高效。 -
Page Factory的其他属性（如FindBy，FindBys和CacheLookup加快了我们的Test Execution速度。