目录
5.4 提高自身技术和业务水平, 做到不仅能提出问题, 最好也能给出解决方案
软件错误 (BUG)
1. bug 定义
// ⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障
(fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错
误。
// 准确来说:
// 1. 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误;
// 2. 当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终⽤⼾合理预期的功能要求时，就是软件错误
2. 如何去描述一个 bug
// 描述 bug 的基本要素: 问题出现的版本, 问题出现的环境, 问题出现的步骤, 预期结果, 实际结果
2.1 问题出现的版本
// 开发人员需要知道出现问题的版本, 才能够获取对应版本的代码来重现故障, 并且版本的标识也有利于统计和分析 每个版本的质量
2.2 问题出现的环境
// 环境分为硬件环境和软件环境, 如果是 web 项目, 需要描述浏览器版本, 客户机操作系统等, 如果是 app 项目, 需要描述机型, 分辨率, 操作系统版本等, 详细的环境描述有利于故障的定位
2.3 问题出现的步骤
// 描述问题重现的最短步骤
2.4 预期结果, 实际结果
// 预期行为的描述: 要让开发人员知道怎么样才是正确的, 尤其要以用户的角度来描述程序的行为是怎么样的, 如果是依据需求提出的故障, 能写明需求的来源是最好的
// 错误行为的描述: 描述错误的对象, crash 等可以上传 log, UI 问题可以有截图
2.5 其他
// 某些公司会有一些其他的要求, 例如故障的分类: 功能障碍, 界面障碍, 兼容性障碍等, 有些有优先级的分类, 严重影响测试, 需要开发人员优先修改的, 可以设置优先级为高
// 不要把多个 bug 放在一起, 在无法确认是同一段代码造成的故障时, 不要将 bug 放在一起提交
3. bug 的分类
// 通过定义 bug 的级别, 能够明确看出问题的严重程度. 工作中开发人员通常需要按照 bug 的级别来分配优先级来处理 bug, 除此之外, 通过 bug 级别也能够体现出开发人员的开发质量
// bug 级别一般分为: 崩溃, 严重, 一般, 次要
3.1 崩溃 (Blocker)
// 阻碍开发或测试工作的问题; 造成系统崩溃, 死机, 死循环, 导致数据库数据丢失, 与数据库连接错误, 主要功能丧失, 基本模块缺失等问题
3.2 严重 (Critical)
// 系统主要功能丧失, 数据库保存调用错误, 用户数据丢失, 一级功能菜单不能使用, 但是不影响其他功能的测试. 功能设计与需求不符, 模块无法启动或调用, 程序重启, 自动退出, 关联程序间调用冲突, 安全问题, 稳定性等
3.3 一般 (Major)
// 功能没有安全实现但不影响使用, 功能菜单存在缺陷但不会影响系统稳定性
3.4 次要 (Minor)
// 界面, 性能缺陷, 建议类问题, 不影响操作功能的执行, 可以优化性能方案等
4. bug 的生命周期
// New : 新发现的 Bug, 未经评审决定是否指派给开发人员进行修改
// Open : 确认是 Bug, 并且认为需要进行修改, 指派给相应的开发人员
// Fixed : 开发人员进行修改后标识成修改状态, 有待测试人员的回归测试验证
// Rejected : 如果认为不是 Bug, 则拒绝修改
// Delay : 如果认为暂时不需要修改或暂时不能修改, 则延后修改
// Closed : 修改状态的 Bug 经测试人员的回归测试验证通过后, 则关闭 Bug
// Reopen : 如果经验证 Bug 仍然存在, 则需要重新打开 Bug, 开发人员重新修改
// 无效的 bug : open -> Closed open -> Rejected -> closed
5. 与开发产生争执怎么办
5.1 先检查自身, 是否 bug 描述不清楚
5.2 站在用户角度考虑并抛出问题
5.3 bug 定级要有理有据
5.4 提高自身技术和业务水平, 做到不仅能提出问题, 最好也能给出解决方案
5.5 bug 评审
// 如果确实是 bug, 友好沟通不能解决问题, 那么就召开 bug 评审
// bug 评审主要解决: 决定如何处理 bug 和 分析缺陷产生的原因, 找出预防的对策
// bug 评审至少需要项目组各个方面的代表参加: 测试代表, 开发代表 和 产品代表