学无止境——记录一个被别人发现的bug

简介: 学无止境——记录一个被别人发现的bug

大家好,我是阿萨。今天发生了一个让我印象很深刻的bug。为什么说印象深刻呢?主要是自己观察力不敏锐以及一个根深蒂固的常识导致的校验点遗漏。因为可以算自己测试上的一个盲区导致的。


一:这个bug的表现现象是什么呢?



举个天气预报的例子。不同降雨量的中国地图中。各个地区不同降雨量的颜色已经标记出来了。该给观众说明 这些降雨量颜色是咋标记的时候出错了。都是100毫米降雨量的图例,我用5段0-20-40-60-80-100和我用0-33.33-66.66-100的图例,降雨量地图颜色就变化了。


色块渲染的结果会因为图例说明而改变。比如图例上都是蓝到白色的渐变。图例区间分5块和分3块。应该对色块渲染不产生影响。但是渲染颜色的时候确实发生了改变。


二:为什么我没有发现这个bug?


这个需求是我负责的。开始测试的时候,其实主要关注图例了。因为图例分段是新增功能,而且渲染色块颜色差别没有那么大。所以就忽略了这个小细节。另外还有一个最基本的common sense:那就是没有图会因为图例的分块多少发生改变。基于这个常识导致忽略了对色块关注。

由此可见:一丝丝的侥幸和先入为主都要不得。尤其是数据可视化领域里一点偏差,结果差距巨大。


三:如何避免此类问题?


这个问题被别人发现,而自己没有发现。说明自己这个地方的验证点有缺失。所以总结了几个要点:


1. 测试数据一定要典型。比如颜色上一定要大红大绿,饱和度越高问题越明显。虽然红配绿,赛狗屁;但是关键时刻它就是好用。


2. 测试数据差异化或者对比度要明显。最好是很少数字就能说明问题。比如1-50-100 三个数字大小以及颜色深浅不同就可以看出结果差别。三个数字就可以测试出颜色渐变效果。不用动不动就整个几个亿的数据,不需要!!!


3. 测试校验点 要覆盖所有关联地方。


4. 切实构造一个客户场景,说明每个新特性的典型场景。


四:心得


学无止境,然则问可少耶?多学习,多提问。多反思。不断积累经验,在找bug的路上精益求精。



相关文章
|
6月前
bug长时间未修复该怎么办?
bug长时间未修复该怎么办?
bug长时间未修复该怎么办?
|
6月前
|
SQL IDE 关系型数据库
记录一次SQL中的bug的修复过程
记录一次SQL中的bug的修复过程
87 0
|
6月前
|
JSON JavaScript 算法
记录Apifox的bug
记录Apifox的bug
102 0
|
6月前
你真的会提交缺陷单吗?俗称报bug
你真的会提交缺陷单吗?俗称报bug
112 0
你真的会提交缺陷单吗?俗称报bug
|
SQL JSON Java
一些异常及解决方法记录(持续更新)
一些异常及解决方法记录(持续更新)
544 0
|
6月前
|
测试技术
如何高质量的做BUG分析
如何高质量的做BUG分析
217 0
|
6月前
|
测试技术
如何提交一个好Bug
如何提交一个好Bug
175 0
|
SQL 关系型数据库 数据库
记一次程序 Bug 导致数据删除的恢复过程
使用RDS、DMS进行数据恢复实践
1000 0
uniapp bug记录(后续更新)
uniapp bug记录(后续更新)
123 0
|
IDE 开发工具
STM32bug【 KEILMDK中出现STLink强制更新提示,又无法更新】
STM32bug【 KEILMDK中出现STLink强制更新提示,又无法更新】
382 0