产品分析
功能：
1、登录
2、进入到商品管理，对商品列表进行新增和删除
测试用例分析
-
测试用例-新增类目
1、用户登录
2、点击首页按钮，进入商品管理->商品列表菜单
3、点击添加
4、创建商品类目
5、获取操作结果
6、断言测试结果 -
UML图分析
1、灰色方块在po模式中代表一个页面(即一个类，class)，方块中的文字代表每个页面的名称(即类名，class名)；
2、虚线代表每个页面中能实现的功能(即类中能提供的方法）；
3、 箭头的起始端，表示页面功能(即方法)所在页面(即类，class)；
箭头上的文字代表功能名称(即方法名称)；
箭头的末端表示将跳转到哪个页面(即访问到哪个类class)，或者表示页面的返回数据(即类的返回值)；
对测试步骤进行PageObject建模
-
传统的线性脚本
传统的线性脚本存在大量样板代码(findelement，click等)，不能清晰表达业务场景;不能清晰的根据元素完整识别测试过程；不能根据测试场景的修改，灵活修改测试用例代码，不能增强代码的可维护性。 -
PO模式（页面对象模型）设计思想
将浏览器中的一个页面抽象成一个类；
将页面中的元素抽象成类的属性；
将页面中所提供的功能抽象成类的方法；
将页面的细节封装到公共方法中;
-
PO模式设计原则
1、不要暴露页面内部的元素给外部(即类中的属性最好是用私有属性表示，不能随便被外部访问到)；
2、不需要建模UI内的所有元素(即并不是所有页面元素都需要建模，具体情况具体分析，这里视频讲得有点水，对新手不太友好，需要自己去实践)；
3、要用公共方法代表UI(即页面)所提供的功能；
4、同样的行为不同的结果可以建模为不同的方法(比如登录功能有两种不同结果：登录成功、登录失败，此时需要根据结果设计为两种不同的方法)；
5、方法应该返回其他的 PageObject(方便链式调用)， 或者返回用于断言的数据(方便断言)；
6、不要在方法内加断言； -
PO模式改造
编写PO测试脚本
1、 根据UML时序图梳理测试用例(梳理业务操作流程，根据业务流程编写测试用例，根据测试用例创建主调类，前置后置函数和主调函数，编写注释)
2、 根据UML时序图构造PO模型(类、类属性、方法)
3、 根据UML时序图创建页面类，定义页面方法，注释，先不用写具体细节
4、 根据UML时序图编写链式调用(即类的调用)
4.1、先根据UML时序图编写类的返回值
编写类的返回值时应注意的事项；
4.2、创建好主调类以及主调函数，将各个封装的PageObject注释，添加到对应的被调函数中；
4.3、根据UML时序图，设计每个类与类之间的调用，实现链式调用
遇到的坑一：
在使用链式调用时，类中方法return 的对象是一个ClassName() ,而不是ClassName：
区别在于return ClassName() 返回的是一个实例化后的类对象，return ClassName 返回的是一个已经存在的类 或者 变量，该类中没有__init__构造方法，因此只能通过return ClassName() 实例化类。
4.4、在主调类中的setup_clas函数和主调函数中调用封装好的PageObject类和类中的方法；
4.5、运行脚本，保证脚本能调通。
5、封装BasePage( 即封装driver对象，常用的方法：find_element()、find_elements()、send_keys()、quit()等 )
5.1、将每个网页页面继承BasePage，并在类中调用相关的方法，且返回实例类时，需要带上self.driver参数
5.2、运行脚本，保证脚本能调通。
6、实现每个页面方法(业务具体实现)
6.1、运行脚本，保证脚本能调通。
7、封装页面元素
7.1、使用类属性封装页面元素节点
把页面元素提取出来，通过定义类属性的方式，放到每个页面类的前面：
7.2、 将自定义的显示等待条件封装到BasePage类中
PO测试脚本的优化
测试断言、数据清理、参数化、添加日志、测试报告等
删除功能和新增功能封装流程相似，在已经搭建好的商品列表页面，新增一个delete方法，封装好相关属性即可。
