Home | 简体中文 | 繁体中文 | 杂文 | Github | 知乎专栏 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏

11.4. BUG率的误区

在做绩效的时候,你是否会考察BUG率?你是否认为BUG越少,团队越好?BUG多的员工能力就有问题?……

11.4.1. BUG 叠加

我们首先要明白BUG叠加概念,什么是BUG叠加概念呢?

我举一个例子,就以我们日常都会接触到的购物平台为例:

			
用户注册 -> 浏览商品 -> 购物车 -> 下单 -> 支付 -> 完成交易
			
			

所谓BUG叠加就是,前面功能会影响后面功能产生BUG,例如 购物车是依赖商品展示的,而下单过程又依赖购物车和商品展示,以此类推。从用户起点到业务流程终点,每经过一个节点,都会产生新数据,数据不断发生运算变化,最终存储在数据库中。

这就完成了吗?没有。交易完成之后数据还要进入公司的财务系统做账,开票等等。还会进行数据二次提炼,通过ETL等手段,将数据同步到数据仓,例如BI大数据分析等等。

这样越是靠近用户端的开发功能越简单,产生BUG的数量越少。越是靠近数据末端,交互越复杂,交互过程会完成新增数据,数据经过多次转发,重新计算,重组等等,越来越复杂,这造成了开发复杂,测试复杂,BUG率飙升。

11.4.2. BUG 分类

我们将系统不能工作的一切原因统称为 BUG,对BUG 没有分类统计。

很多时候 BUG 成为了待办事项。最终体现不出真能的质量数据。