执行测试和缺陷管理

学习目标

  • 熟练掌握缺陷管理流程
  • 熟练掌握执行测试要点

1.缺陷的定义

软件在使用过程中存在的任何问题，都叫软件的缺陷，简称bug。

2. 缺陷的评判标准

  • 缺失功能：软件未实现需求说明书明确要求的功能
  • 功能错误：软件出现了需求说明书中指明不应该出现的错误
  • 多余功能：软件实现的功能超出需求说明书指明的范围
  • 约定俗成功能缺失：软件未实现需求说明书中虽然没有明确指出，但约定俗成的功能未实现
  • 不易使用：软件难以理解，不易使用，运行缓慢，用户体验差

3. 缺陷出现的原因

  • 需求阶段（55%）：需求描述不易理解，有歧义、有错误、思虑不周到等
  • 设计阶段（25%）：设计文档出现错误、思虑不周
  • 编码阶段（15%）：代码出现错误
  • 运行系统（5%）：依赖的软硬件系统本身故障、配置项有误

注意：测试人员是发现bug，并不生产bug，无论是否有测试人员存在，软件都会存在bug

4. bug修复成本


5. 缺陷的分类


6. 缺陷特性

  • 80%的缺陷出现在 20%的模块
  • 测试进行越后期，越难发现新缺陷
    • 同一个人，一直使用同样的测试思路，同样的一套测试用例，没有新的突破
    • 某些缺陷天然地只有在很特殊或者很极端的情况下才会被触发。
  • 允许bug遗留延后或不解决
    • 没有足够的时间
    • 不算真正的软件缺陷
    • 修复的风险太大
    • 不值得修复

7. bug流程-生命周期


8. 什么是缺陷报告

  • 为了解决混乱的bug管理衍生的科学管理手段
  • 测试人员发现bug后，通过缺陷报告记录bug
  • 借助缺陷报告实现对bug的跟踪管理过程
  • 通过缺陷报告将缺陷告知给开发人员，是测试人员与开发人员之间重要的沟通方式

9. bug状态


10. 缺陷报告的组成

  • 缺陷id：全项目中的唯一bug编号，不可重复
  • 缺陷标题：一句话概括描述bug
  • 所属模块：缺陷在哪个模块被发现
  • 严重程度：bug的糟糕程度，对程序的影响程度
    • 等级1：致命的（urgent）
    • 等级2：严重的（high）
    • 等级3：中等的、一般的（medium）
    • 等级4：建议性小问题（low）


    在实际工作场景下，每家公司对bug的严重级别定义不一样

  • 前置条件：操作前的准备事项
  • 操作步骤：重现bug的操作步骤
  • 预期结果：操作完步骤后应该得到的系统反馈结果
  • 实际结果：实际操作完步骤后得到的系统反馈结果
  • 优先级：建议程序员对bug的重视级别
    • 级别1：放下手头的开发任务，立即解决（bug-urgent）
    • 级别2：下个版本解决（bug-high）
    • 级别3：在软件产品发布之前解决（bug-medium）
    • 级别4：尽量在软件产品发布之前解决（low）

  • 附件：发生bug时的界面截图、后台报错日志截图、录屏等

11. 提交缺陷报告的注意点

  • 缺陷是可重现的
  • 一个缺陷只上报一次
  • 缺陷报告要规范，符合公司要求，描述要清晰无歧义、不带有言语评判

12. 排查缺陷的思路

  • 依赖的重要文档《测试用例》：根据对比预期结果，判断是否为bug
  • 对比UI稿：通过比对UI稿、交互设计稿，比对出不一致点
  • 借助抓包工具：使用fiddler、Charles、F12工具抓取接口，比对入参和出参的正确性
  • 检查数据库：在界面上操作增删改查动作，对比数据库的变化是否正确、查询数据是否匹配
  • 检查运行日志：使用xshell工具连接服务器，检测后台运行日志，查看报错日志
  • 站在用户角度：假设自己是真实用户，找到对系统不满意的点

bug案例

假设以下测试用例执行完毕后，结果如下：



在禅道中提bug：


13. 测试执行–基本概念

  • 项目提测，并通过冒烟测试，就进入到软件测试最主要的测试执行阶段（也就是执行测试用例、提交问题单、测试评估等活动），进行软件测试
  • 根据已有的测试用例，按照里面的操作步骤一步一步的执行，并查看预期结果与实际结果是否一致。
  • 执行测试不仅仅是执行测试用例，还需要排查bug、定位bug、协助开发解决bug

14. 测试执行-注意事项

  • 搭建适合测试的测试环境
    • 搭建前端服务、后端服务、数据库等，搭建过程中如遇到问题，测试人员可以要求开发人员协助
  • 注意用例的前提条件和特殊说明
    • 前提条件中可能包含了权限、顺序相关的要求
  • 测试用例要全部执行
    • 每条用例至少要执行一遍。少执行一条，就会有一个功能点没有测试到
  • 不要忽视任何偶然现象
    • 若遇到随机bug，需要深挖，可能会发现背后可能隐藏着更大的隐患
  • 加强测试过程记录
    • 执行过的用例做好对应标记，方便后续复盘、追踪bug，发现了缺陷应及时提交确认
  • 提交缺陷时与开发的关系处理
    • 若出现双方分歧，需要对开发人员晓之以理，做到有理、有据，有说服力，避免升级矛盾
  • 提交一份优秀的缺陷报告单
    • 缺陷报告需要合理化，避免啰嗦跑题，以最简短的步骤描述清楚bug情况；但也不能过于简陋，导致开发无法理解bug
  • 及时更新维护测试用例
    • 测试执行过程中，若发现遗漏了一些测试用例，应该及时的补充
    • 测试执行过程中，若发现有冗余的测试用例，应该及时的删减