思考: 第一象限 ---- 数据驱动测试

数据, 对于开发而言, 是关注的同时又经常忽略的资料.

就经历而言, 多数的数据需要自己执行后产生, 容易增加开发人员的惰性. 导致数据覆盖的边界不合理. 同时, 数据还是开发在设计API时必须的资料. 在新系统的开发中, 由于没有参考的数据,

因此在设计接口时, 从实现功能的角度出发, 不会更多关注数据方面. 所以对于数据的流转, 设计上是可以进行精简的.

对于测试而言, 有更多的时间分析业务和系统的业务流程以及流程中的数据交换和变化, 因而应当更多去思考系统中是否存在潜在的关联和隐含的设计

甚至就数据而言. 本身就是形成用例的前置条件. 测试环境的搭建之后, 往往会参照真实的数据进行用例的测试, 或是直接引入灰度环境测试等

因此除了业务, 测试(相对于整个团队中其他人员职能)会其次的接触到数据.

我就假设有这么一种测试模式: 数据驱动测试

　　1. 用户的行为产生了哪些数据

　　2. 数据产生了什么业务或交互

　　3. 数据产生的过程传递

　　4. 数据的生命周期

　　5. 数据的准确性, 性能以及时效性

　　6. 数据对于系统结构的影响

　　7. 数据隐含了哪些用户故事

　　8. 是业务产生了数据, 还是数据驱动了业务

 

数据可以用来阐述用户行为, 当然也应该存在某种程度上的对于系统的描述. 

 

数据驱动区别于其他测试方法的可能如下:

　　1. 功能测试关注的是用户故事的验收

　　2. 接口测试关注的是业务代码的验收

　　3. 性能测试关注的是特定场景下的稳定性

　　4. 数据测试可以关注的是设计的合理性, 系统的边界等