【表情包-软件测试基础理论】bug 怎么写？怎么跟踪？怎么分级？

应广大粉丝强烈建议，本系列改名为【表情包-软件测试基础理论】

吃软件测试这碗饭的，如果基础理论都不懂，谈何长久？

欢迎来学习本系列，基础理论比较枯燥，这也是为什么现在很少人掌握的主要原因。热饭尽量用浅显易懂 生动的例子 来帮助大家学习基础理论，所以请耐心看完此系列。

前言

bug是什么，就是软件缺陷，博主在多个公司都深入探讨过何为bug，结果发现一个公司一个样。虽然都是公司自己长期积累下总结的宝贵经验，但是你拿出去面试时候说，就明显掉份。那么怎么来标准的说bug呢？怎么听起来就觉得高大上呢？一起来学习吧。

bug属性：

目前很多公司都借助一些bug管理工具进行提bug，而又没有什么标准，顶多领导说一句，写的详细点，最好有截图就完事了。导致新人老手写的是各有千秋，开发阅读起来各种头疼脑热。

标准写法：

需求id，用例id，bug编号，bug标题，bug描述，预期输出，实际输出，复现步骤，附件图片，备注，提交人，责任人 等。

bug分级：

标准说法：

【致命级】：引起系统服务崩溃，用户关键数据丢失，巨大资产损失，生命安全风险等bug。

【严重级】：引起软件主要功能失效。

【一般级】：引起软件主要功能失准，次要功能失效等。

【轻微级】：引起软件次要功能失准等。

【优化建议级】：影响用户体验等问题，文案错别字等。

bug生命周期

经常有面试官问，如果开发不承认这是bug怎么办？其实，在一些大公司或者外企中，会有一种类似裁判的部门存在，叫做CCB （变更控制委员会），由他们进行最终判决，如果是bug就必须改，不是就立即删除。

周期如下：

新建bug（测试工程师）↓

审核是否是bug（测试经理）↓

若不是bug，则放到丢弃桶里，结束周期。

若是bug，则判断bug是否重复（测试经理）↓

若已重复，则丢弃bug，结束周期。

若没重复，则继续判断是否需要延期修复（开发经理）↓

若需要延期，则放到延期标签下。

若需要立即修复，则继续给到开发工程师修复？（开发工程师）↓

开发工程师是否拒绝修复（开发工程师）↓

若同意修复，则修复后给到测试工程师验证 ↓

若验证成功，则关闭bug，技术周期。（测试工程师）

若验证失败，则再次提交给开发工程师。↓

若开发工程师拒绝修复，则提交到CCB机构判断。↓

机构判断可以不修复或不是bug，则丢弃bug，结束周期。（CCB）

机构判断若需要修复则给到开发工程师 ↓

开发工程师则必须修复。↓