一个可供参考的基于Dubbo的Mock测试系统实践案例

正文

请到「今天看啥」查看全文

2. 数据库验证

测试接口的输入值需要通过手工编写数据库SQL查询获取，接口调用完成后，需要通过大量的SQL验证数据库值的正确性。

3. 日志验证

通过返回值和数据库不能确保代码走到了预期的逻辑，只能通过肉眼观察日志确认代码的实际运行逻辑

4. 测试报告

人工记录用例结果，人工编写报告，耗时耗力，难以准确定位代码问题。

Mock模拟系统的产生

业务系统调用其它系统来完成功能逻辑，而想要得到其它系统接口的特定输出，就需要做相应的运营配置，这其中增加了很多的沟通成本。甚至偶发性bug只能在特定的环境状况下复现，作为不可测的逻辑。

以风控系统为例，如果业务系统需要测试某个商编某个商品类别下的累积限额，需要风控的同事配合不断修改限额阈值，目前的情况是多个业务系统都在接入风控，配合测试的人力成本和时间成本是很高的。为此设计了挡板模拟系统，其功能结构如下：

针对测试人员测试用例数据无法沉淀和复用的问题，我们将采用“用例与日志锚点库”方案：

请到「今天看啥」查看全文