vi设计经典案例seo提高网站排名
目录
软件错误 (BUG)
1. bug 定义
2. 如何去描述一个 bug
2.1 问题出现的版本
2.2 问题出现的环境
2.3 问题出现的步骤
2.4 预期结果, 实际结果
2.5 其他
3. bug 的分类
3.1 崩溃 (Blocker)
3.2 严重 (Critical)
3.3 一般 (Major)
3.4 次要 (Minor)
4. bug 的生命周期
5. 与开发产生争执怎么办
5.1 先检查自身, 是否 bug 描述不清楚
5.2 站在用户角度考虑并抛出问题
5.3 bug 定级要有理有据
5.4 提高自身技术和业务水平, 做到不仅能提出问题, 最好也能给出解决方案
5.5 bug 评审
软件错误 (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 评审至少需要项目组各个方面的代表参加: 测试代表, 开发代表 和 产品代表