13 | 效率为王：脚本与数据的解耦 + Page Object模型

觉得data provide只是从行为操作上分离了数据的提供方式，没有从根本上解决自动化测试中测试数据本身的稳定性、快速响应变化、数据丢失、数据被修改的这些难点和blocker，比如生产数据库里的数据没半边会导入并refresh测试环境数据库，之前cases里使用的数据都没有了；比如几个小组在一个系统里使用同一个测试环境数据库，A组正在用的测试数据B组也正在用，B组还要把数据改变一下再用，或者B组用完后测试数据已经发生改变了；比如使用的测试数据本身随着时间是有实效性的到，状态会改变的，从active变成inactive的等；觉得自动化测试的其他方面都不是什么大问题，最主要的阻碍就是测试数据本身(特别是在真实的测试环境上时，单元测试不会有这些问题)，想问一下老师，有没有一些好的方法、方式、工具、工程实践来解决上述这些数据本身的问题？

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

更倾向于 页面模型只封装控件，这种方法其实也是模块化思想的深一层应用，控件是页面的更小单元，且一个产品或项目中使用的控件种类有限，但是页面却很多，每个页面控件组合方式又不同，在项目中两种方法多次实践后，将控件单独封装后，页面操作又节约大量的开发和维护成本。

我一直认为api测试就是接口测试，但是看老师写的貌似有不一样，请问具体有什么区别呢？

我觉得一个对象除了要有属性还得有行为。

数据驱动测试的思想不适用于 GUI测试 这个是想说“不仅”适用于GUI吧

个人感觉分开好一些 提高了粒度 增加了灵活的使用性 （入行新手一个月 仅仅是个人感觉）

我们主要做后台服务，大部分都是对接口进行自动化，当多个接口一起运行时，有缓存的影响等，容易耦合，请问后台接口自动化如何解耦？

没有必要在 “传统“这个层面讲很多..

老师讲讲接口测试，有没有好的实践