提bug的注意事项

通常情况下,项目比较忙的时候,功能测试过程中遇到了一些看是bug的,就直接提到了bug管理系统,等着开发去定位,渐渐的就养成了这个习惯,反正不是bug的话开发会否决的,殊不知这样不仅占用了开发时间,也会影响到项目的发布时间,同时也不利于自己定位bug的技术能力。

来到新公司工作了也快一个多月了,最近在测采购报表,涉及到多个系统的取数,我是先弄清楚报表每个字段的取值,然后通过SQL查询来和页面的数据比对,有些没有显示的字段信息,就直接update表数据了,结果页面还是没有展示出来,于是就提了bug。
后来发现一些数据是经过系统间的数据流转的,单纯改数据的话相关联的字段信息本身就不会被更新,不是程序的逻辑,不能走SQL,也证明对业务的不够熟悉。

测报表必须清楚基础数据的来源,涉及计算的字段信息最好能减少多个系统的交互,报表中直接做分析

举例:
1、采购报表关键字段:商品信息、加权采购成本价、毛利率、建议补货数、库存,库存金额

商品信息:从商家中心取数
加权采购成本价:从仓库系统获取入库单,ERP系统进行计算(逻辑比较复杂)
建议补货数:从订单系统获取销售量,仓库系统获取库存进行计算
库存金额:采购报表中计算

当一个报表需要从多个系统取数时,当某个系统挂了报表的所有数据都会受到影响,页有请求频繁把对接系统给调挂了,反倒影响了正常都业务功能

2、关于搜索
比如根据商品类目一级+二级进行搜索,没有结果,我当bug提了

结果是开发帮忙定位当问题,前端从接口取的二级类目字段错误,导致当搜索问题

搜索.png

总结:实际上这个问题完全可以通过抓包和接口文档来定位的

3、回归测试
版本修复过好几次,只顾着核对每个字段的计算逻辑了,没有回归报表来源的条件,导致先前已经关闭的bug又被重新激活了,没有覆盖,上线后才发现问题。
版本修复后开发说只要回归那部分修改的功能就可以了,我信以为真了,结果。。。诶,以后测试过程中不能完全相信开发的话,自己也要尽快提升看代码的能力

你可能感兴趣的:(提bug的注意事项)