通常情况下，项目比较忙的时候，功能测试过程中遇到了一些看是bug的，就直接提到了bug管理系统，等着开发去定位，渐渐的就养成了这个习惯，反正不是bug的话开发会否决的，殊不知这样不仅占用了开发时间，也会影响到项目的发布时间，同时也不利于自己定位bug的技术能力。
来到新公司工作了也快一个多月了，最近在测采购报表，涉及到多个系统的取数，我是先弄清楚报表每个字段的取值，然后通过SQL查询来和页面的数据比对，有些没有显示的字段信息，就直接update表数据了，结果页面还是没有展示出来，于是就提了bug。
后来发现一些数据是经过系统间的数据流转的，单纯改数据的话相关联的字段信息本身就不会被更新，不是程序的逻辑，不能走SQL，也证明对业务的不够熟悉。
测报表必须清楚基础数据的来源，涉及计算的字段信息最好能减少多个系统的交互，报表中直接做分析
举例：
1、采购报表关键字段：商品信息、加权采购成本价、毛利率、建议补货数、库存，库存金额
商品信息：从商家中心取数
加权采购成本价：从仓库系统获取入库单，ERP系统进行计算（逻辑比较复杂）
建议补货数：从订单系统获取销售量，仓库系统获取库存进行计算
库存金额：采购报表中计算
当一个报表需要从多个系统取数时，当某个系统挂了报表的所有数据都会受到影响，页有请求频繁把对接系统给调挂了，反倒影响了正常都业务功能
2、关于搜索
比如根据商品类目一级+二级进行搜索，没有结果，我当bug提了
结果是开发帮忙定位当问题，前端从接口取的二级类目字段错误，导致当搜索问题
搜索.png
总结：实际上这个问题完全可以通过抓包和接口文档来定位的
3、回归测试
版本修复过好几次，只顾着核对每个字段的计算逻辑了，没有回归报表来源的条件，导致先前已经关闭的bug又被重新激活了，没有覆盖，上线后才发现问题。
版本修复后开发说只要回归那部分修改的功能就可以了，我信以为真了，结果。。。诶，以后测试过程中不能完全相信开发的话，自己也要尽快提升看代码的能力
网友评论