项目上的缺陷分析

作为QA测试工程师，我们有一项本职任务就是参与质量的分析，评估上线产品的质量。我记得在我之前就业的公司中，公司有一项绩效评估就是bug发现情况用来评估开发的出错率和测试的测试情况，同时评估开发的产品质量。虽然这个指标用来绩效评估存在一定不合理性，但是在产品迭代开发中用来评估产品阶段性开发质量还是有一定客观性的，同时也可以从持续跟进的bug统计分析中看出一些问题，比如某些开发容易在某些地方出错，比如某个迭代的需求实现更容易出现问题。

到了我司后，因为工作模式和流程的原因，在项目上也没有便捷的bug管理工具用来集中统计bug，所以缺陷分析在平时工作流中是缺少的一环节。但是去年上的两个产品项目中，一个PM和一个TL角色对我说“我们是否可以bug可视化，是否可以评估下我们团队产品开发质量”。我当时的想法就是——我们采用卡墙的形式来记录我们的需求，按照公司的敏捷流程和当时采用的工具，我也按照一些bug记录规范把bug记录在了我们工具平台上的卡墙上了，怎么就不是bug可视化了呢；而且评估开发者的开发质量也没啥用，该出错的地方还是出错了；就用bug来评估产品的质量，也存在不合理性。当时也因为没时间的原因就搁置了，后来在当前项目时因为一些原因我开始了一次比较正式的缺陷分析。

虽然去年在前两个项目我没有做具体的缺陷分析，但我把这件事记在了心里。在项目初期我给自己和团队制定了一个项目运行中的规范，其中一项就有缺陷分析。规范中提到什么时候做缺陷分析，缺陷分析时bug统计记录哪些维度，缺陷分析主要用来反馈什么问题。我记得在当前项目运行到第四个迭代时，我着手做bug统计，开始了缺陷分析，因为项目运行中触发了一个缺陷分析的条件：第四个迭代产生的bug明显增多了，我需要找到一些原因。

规范中提到做缺陷分析的时机：

1. 发现线上bug——该角度是产品已经流转到线上。
2. 回归测试和bug bash 过程中发现bug——该角度是产品实现流转到上线前。
3. 迭代中bug多或者迭代运行中某个迭代bug增长多——该统计是产品实现流转到测试角度。

我设计的bug统计主要从以下角度记录

发现阶段

缺陷描述

缺陷类型

缺陷原因

归属人

缺陷归属卡

所属模块

改进方案

当做bug统计记录来做缺陷分析时，设计到的维度肯定不只我设计到的这几个维度，有可能还有bug的等级、bug的优先级、bug的状态之类的。

我从第四个迭代开始进行了缺陷分析，从缺陷分析的一些数据中，我们还是能看出一些问题，比如从缺陷类型中我们可以客观看出该迭代产品在哪些质量表现上问题比较突出，从缺陷原因中可以总结什么原因导致的bug，后续迭代中是否可以规避或者改进。

当然缺陷分析不只对bug分析这两个维度，可分析的维度有很多，主要是根据项目中的需要，需要从这个分析中得出什么结论，看出什么问题。比如我在该项目中用Excel记录的bug，一方面可视化每个阶段的bug，一方面可以从几个维度来记录分析bug达到当前项目的一些目的：

1. 数据可视化来看待每个阶段的开发质量。
2. 从持续跟进中，总结出软件哪些地方容易出bug；每个角色在哪些方面容易出问题。
3. 从项目流程上看，哪些环节容易导致bug。

而第二点和第三点都是为了减少bug的产生。

当然只有一个迭代的bug统计分析，还不能看出更多的问题，所以我对后续的迭代持续做了bug统计分析，一直持续到项目结束，历经几个月的时间。从持续迭代分析中又看出更多的问题，比如几个迭代中，对于那种功能模块链路比较长，涉及状态比较多的，就容易出现状态流转时边界判断不统一，主要原因是各个卡中写的AC不一致，写卡前没有对产品流程上的相关状态条件进行梳理。

当我做了几个迭代的缺陷分析后，我需要同项目参与者分享这个分析结果：

1. 问题比较明显的开发者或者产品分析者需要单独和他们沟通并制定改进方案。
2. 流程上出现了某些问题的需要全员参与分析讨论并给出解决方案或者加重关注。

在沟通之后，后续的缺陷分析中需要重点关注给出方案的问题，检验是否在这方面做到了，从而减少或者杜绝了这方面的bug。

本文中多次提到缺陷（bug），而我对bug的定义是——

• 宏观上看有可能是既定需求的功能问题，也有可能是需求或者交互上的体验问题，或者是不同设备上的表现问题。
• 微观上看有可能需求或者设计上的不易用性，也有可能是代码设计上的缺陷性或者编码错误等，甚至是计算机资源的消耗和用户隐私泄露。

而上图中提到的缺陷原因和缺陷类型我的设计是趋向于质量类型和项目周期中参与者角度来看的的

bug类型	类型定义
01_业务逻辑	从需求本身上看，业务存在逻辑性问题，逻辑不符
02_数据问题	数据显示不正确或不完整，不符合业务需求和规范或者不适使用者认知
03_界面优化	界面不美观，排版有问题，不符合设计要求和使用者的习惯，需要进行界面优化
04_交互操作	页面间或者页面内交互不当，或者一些功能按钮或者功能操作没反应，比如点击、滑动。
05_接口调用	前后端或者第三方因为接口导致的问题，比如接口名称变更、字段定义变更。
06_设备兼容	不同设备、版本或者环境上表现不同，包括界面显示或者功能上
07_性能效率	直观体验操作反应慢、页面显示慢，不支持多并发等
08_安全隐患	权限控制不当，越权请求操作等泄露数据

 

bug原因	释义
001_需求缺漏	需求分析没记录完整或者写明，或者相同模块写的前后不一致，或者交互设计有缺失，同时开发过程中也没确认而导致的bug
002_需求变更	在既有的需求分析卡上，有需求变更时，没有记录到位或者相关干系人同步不到位而导致的bug
003_方案缺陷	在实现某个功能时，实现的技术方案有缺陷，从而导致bug
004_编码错误	在既定的方案下，实现需求时，因编码上的错误或者代码错误上引起的bug
005_代码重构	对已实现的的需求，进行代码上重构或者改写导致的bug
006_实现遗漏	没有实现某些需求上的功能或者某阶段发现的必修问题到下一阶段还没修复
007_业务理解有异	对业务需求分析或者业务价值理解有异，实现出来的和需求不太一致
008_依赖缺陷	依赖方有问题导致的问题，或者双方契约不一致或变更导致的bug
009_部署不当	在低环境已好的实现因为部署原因导致在其他不同环境上表现不一致
010_配置问题	因CI/CD、容器或代码在不同环境因配置出错导致的bug
011_代码合并	因代码提交或者合并导致代码的bug
012_数据存储	数据丢失、数据库连接出错、数据同步失败、数据库死锁、数据库表设计不合理等与数据库相关的bug
013_测试遗漏	某个需求实现在测试阶段没有被发现，遗漏到下一阶段