首先 周三的例子通过python+seleniun3实现了，并且还开始在项目中开始了脚本编写。有点小小的成就感
其次，今天课程的关键词 数据解偶，模块化，页面对象
        数据解偶和模块化我是深有体会的，之前测试项目中有用到自动化，因为是嵌入式设备，所以大多数都是自己写脚本，并没有现成的平台可以用。所以经历很多摸索。一开始是流水账式，后来发现测试用例一多，就无法维护。后来就思考，能不能数据和期望结果是一张表格，测试用例其实就是数据不一样。哇，这一做不得了，测试框架很清晰，测试用例管理很灵活。维护也很简单。效率必须提高。如果早知道有数据解偶这个词就好了😊。会少走很多弯路。
       模块化，是写代码的一个必备功能。特别是像我们大多数是基于c开发，如果没有做到模块化，那维护就如看天书😊
      页面对象，不是太能理解。我感觉像c++里面的面向对象。狗就一大类，小狗，大狗，哈士奇……，那都是基于狗这个基类继承发展出来的不同属性……。

最后 回答问题，关于争议问题？我觉得就如标题所说，效率为王，那个形式好用就用那个。那个对提升效率有用就用那个。

我们之前采用过这样一种设计：
输入数据和要操作的页面元素，都作为数据在外部进行存储，根据不同业务，以用例的形式进行组织并按行存入数据库，一条用例对应有一行记录页面操作，另一行记录输入数据。
然后脚本中封装了一些方法，使得操作页面元素的写法更加清晰可读。这样在数据中就可以直接这样写click（id，“username”）表明是点击id=username的页面元素，当然对于更加复杂的页面元素，也设计了可读性较高的写法表示多层获取，方便用例设计人员编写。
脚本读取这样表示页面操作的数据之后，抽取出层级关系，即可拿到页面元素。
对应的读取输入数据。
因此主要的操作步骤和数据内容都放在外部存储，脚本就不必随着业务用例的修改而修改。
而对于重复的页面操作则使用了子用例的概念，直接按照编号或名称进行调用，避免冗余。

1.数据驱动这个概念太重要了，从上层设计的角度看，数据分离是必须的，但有时候项目时间紧急，为了尽快满足实现，很多人就忽略了这些上层设计，只顾眼前利益，结果就影响了长远利益；

2.页面对象模型，这个名词之前就听说了，但是自己在写 selenium 时并没有进行充分的应用，曾经自己还为了 selenium 自动化设计了 4 层的分层实现逻辑，目前看起来和这个页面对象就是一样的道理，果然有理论性指导实践会更轻松；

3.关于最后的问题，我也觉得不能一概而论，比如我说的 4 层实现（原子操作层、函数层、实现层、用例层），我把登陆操作给放到了函数层，其他的控件操作则都是在用例层，一方面满足了分层和 PO 的要求，另一方面也保证了实现的简化；

以上，欢迎关注公众号「sylan215」一起沟通交流。