自动化测试中的数据

谈谈自己入行以后的所闻

* 数据应该单独放置测试框架的某一层   ----- > 有道理

* 数据层，是什么样式的？

列举自己见过的：

    数据层放的都是些什么数据？

           1、真正的测试数据（ps: 就是说功能的入参，比如说登录功能的 账号密码，这2个）

刚刚入门的时候1个接口、或者是1个功能就是1个txt文件来管理，就像一张纸只有几行数据

           2、数据层干脆做成用例层，写 标题 、接口URL、header、参数、断言 

这样放置感觉不叫数据层了，叫用例层，

有个比较狠的测试框架，不需要再填代码了，直接往excel表格里填数据，有个问题来了依赖怎么办？当然写这个框架的人肯定是有办法的，用例里加上所谓的提取返回，参数依赖的关键字。

   case层的用例应该怎么写？

几年前，我把正向的、逆向的用例都通过数据驱动的方式传入 同一个 test_case里，当然连断言都做成了数据驱动，

那么问题来了，有些用例需要单独做数据，就需要在test_case中进行判断哪条用例数据需要改，总感觉这么做不对。

过了很久明白1个道理，等价类划分法，有效和无效进行划分case。所以要注重 test_case的可读性、可维护性

就应该这样写，获取数据-调用封装好的方法-获取响应-断言。至于依赖、业务实现，pageobject就可以帮我们解决

  应该用什么存储数据

 一谈到数据存储，最常见的就是 excel、txt、json、yaml

可是面对1个大型的项目，这样的以单个文件进行存储放在数据层里就显得十分的厚重，不管是打开、修改都显得很繁琐

如果存储？mysql数据库就很好，以单个接口1个表含正向、逆向的数据，通过字段标记哪些是正向、逆向，或者是1个表涵盖多个接口

谈到数据库的读取，入门就学过xxxx语言的JDBC，而这样原生方式肯定没有数据持久层框架便捷，如java的mybaties，优雅的实现

数据庞大了以后，又发现，有些万年不变的数据，就比如仓库名称、供应商名称，做单都需要这些数据，不如就写个ini文件来定义

 

最终

一次又一次的运用、不停的探索中，终于知道了数据到底应该怎么存储

* 配置数据 : 类似于ini格式、yaml格式、application.properties，存储 host、mailname\password、数据库连接账号密码等，这种少量而又重要易变更管全局的数据即是配置数据

* 消耗数据：即函数调用生成，比如注册手机号

* 死水数据：1、基本上无改变的数据，而数据量繁杂，不是用来测试接口的数据，而是为了解决测试接口所必须的数据，如测试创建订单接口，所必须的数据商品、店仓、分类一系列的数据。

                    2、数据驱动的数据，这类数据实现接口业务测试而产生的数据，如删除订单对外暴露 订单id，正反验证功能，有效类：数据库存在、无效类：不存在，空

                         我们都知道，测试删除订单，必须要创建订单，才能真正意思上打通自动化，而为了测试去创建的数据即是刚刚提及的死水数据1。

                         这类数据驱动的数据 多是yaml、json、txt、不推荐excel

* 活水数据：用例中产生，pageobect设计模式中提及提取接口返回值即测试接口所必要的依赖数据，存储在实例变量中

                    很多时候在想为什么不存在在类变量里，原因很简单多线程时会出问题，必须加上线程锁

                    其次，类似于token，我是存储在类变量加上锁，运行一次即赋值给类变量，通过类方法调用类变量使得数据可以重复利用

                    目前我还导出在yaml文件里，方便随时使用token进行排查问题