基于模型的思考方式构造测试数据

 

基于模型的思考方式构造测试数据

 

系统测试过程中，我们经常会遇到这样的被测试系统。系统的流程很长，比如Web类型的系统，从申请借款至还款节点，中间有：借款人申请借款、信审、发标、投资人投标、银行放款、借款人还款，等等节点，涉及很长的工作流。

 

那么在面对这么多节点系统时，有时候需要跳过前面几个节点，只验证后面的某个节点（因为只有该节点改动了吗，其他节点没改动过需求）。

 

 

这个时候怎么办？一步，一步从头至尾的页面填数据，打开我们的自动化selenium工具录制？还是一步就把数据推进到这次需求改动的节点呢，比如：借款人还款节点，界面打开就有数据了。当然，是一步推到想测试的节点最好，省去了前面节点的模拟录入，手工录入的环节。

 

我们都知道实际在软件的研发过程中，每个节点是不同的页面，每个节点页面的数据需要补充完整之后，且成功保存之后才能进行到下个节点的展示界面，进行录入和校验页面数据。

 

那么问题来了…

 

如果当前某个节点页面存在缺陷，js啊、数据各种校验不通过啊，等等。直接推进到任意节点，则是非常高效而且特别方便的做法。

 

做研发和测试筒子，都知道数据落盘（存储）一般都是在数据库里面的，传统的造数据方式给对应节点页面涉及的表插数据，找DBA或者脚本能力不错的同事写一组数据进去，这个方法是可行的，但是对于系统内部数据库设计完全没有理解，数据和数据之家的关系是什么样的，也没有理解。

 

基于模型的思考方式构造测试数据

如果采用领域模型的方式，先去整理完整的业务过程（借款人申请借款、信审、发标、投资人投标、银行放款、借款人还款）都涉及了什么业务对象，这些对象又归属哪些域。

 

再去整理每个节点会引起哪些对象的变化，分别给这些对象造数据达到推进到指定节点的目的。

 

参考下图：

 

注：4132/4133 等编号，则是调用后台触发执行具体数据库脚本的脚本编号。