前面提到过 UI 自动化测试最大的障碍或者成本最大的地方就在于页面的频繁变化。UI 自动化测试过于依赖于界面，界面变化意味着你的代码无法使用，需要更新维护。
虽然我们可以通过选择更有效的用例来达到降低维护成本的目的，但是毕竟以涉及到 UI 元素变化，我们的代码就需要改变。
目前 UI 自动化测试中最流行和达成共识的做法是是采用 Page Object (简称 PO) 设计模式，使用这种模式可以有效降低 UI 自动化测试代码的维护量。
那么它是如何降低代码维护量的呢？
基本思想：
在 UI 自动化测试中对页面元素的处理引入面向对象思想。从测试用例中剥离页面元素操作，并以页面为单位的类将页面元素上的定位方式及操作进行封装。
什么意思呢？不采用 PO 模式的时候，我们相当于在测试用例中直接调用 Selenium 中的各种 API，由这些 API 去操作页面元素。而 PO 模式相当于在测试用例和 Selenium 之间增加了一层 PO 层。通过自定义的页面元素，再去调用 Selenium 中的 API，同时也将测试用例与 Selenium 的元素操作做了分离。
也就是说，你的测试用例 TestCase 中不会再出现诸如 find_element() 之类的方法了。
通过对页面元素的封装，将页面涉及到的元素定位和操作全部集中到了一起，不会再零散的出现在各个测试用例中。
当页面发生变化时，你不需要到各个测试用例中去查找需要修改的代码，只需要在对应的页面类中去修改其定位方式和操作即可。
比如首页上有一个菜单，每个模块的页面入口都在这里。也就是你的几乎每个测试用例中都会涉及到去点击菜单。
突然某一天，产品经理要求修改这种菜单（可能因为太难看，可能因为用户不太喜欢这种模式、也许老板觉得不够高大上等等），菜单中的标签类型和属性变的面目全非。
当修改完成后，你去运行你的测试脚本，突然一片红色的 Fail，让你有点不知所措。然后逐个去修改页面中关于菜单点击的代码，共修改了 xx 个文件 nxx 个用例 nxx 行代码。
好不容易处理完毕了吧！产品经理说了，要改回去，因为...🙄
如果你采用了 PO 模式，不用关心自己有没有第三方责任险了，因为不用动手了。
为什么会有这么大的改观呢？这得益于你将菜单的元素定位和点击操作全部写在了mainpage.py文件，因为你只需要修改 1 个文件 x 行代码即可，那些 xx 数量级的文件和用例都不用去动了。
通过在 UI 自动化测试中引入 PO 设计模式，可以大大提高自动化测试代码的可维护性。
