软件测试完整体系：缺陷报告、项目管理工具、测试报告

QALab
107 阅读13分钟

一、软件缺陷

  • 从严重级出发，严重级低，暂时可以不考虑（后续尝试复现）；严重级高，需要分析排查
  • 思考排查测试过程，测试步骤是啥，测试环境是否有差异（替换法）
  • 寻求协助：测试老员工，开发协助（记录出现问题的时间，查询对应时间段的日志，通过日志分析）
  • 如果没有日志，需要开发给一个带有调试日志版本的系统，后续连续跟踪三个 版本后，再未复现，此时放弃
  • 后续版本再次出现，直接转/提正式bug，详细描述你的复现过程，并附带日志信息

缺陷（bug）的定义：软件在使用过程中存在的任何异常问题都叫软件的缺陷，简称bug。 软件的缺陷导致软件无法正常运行，无法满足用户需求或产生不符合预期结果的情况。

缺陷如何判定（判定标准）：

  1. 软件未实现需求(规格)说明书中明确要求的功能 –> 少功能
    • 例如：某社交APP不支持文字信息的发送
  2. 软件实现的功能超出需求(规格)说明书指明的范围 –> 多功能
    • 例如：某社交APP除了消息发送功能，还有数学计算功能
  3. 软件出现了需求(规格)说明书中指明不应该出现的错误 –> 功能错误
    • 例如：某电商APP下单时，对于有折扣的商品价格并没有按照折扣价计算
  4. 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 –> 隐性功能错误
    • 例如：某社交APP输入消息时，只支持九宫格输入法，不支持手写输入
  5. 软件难以理解，不易使用，运行缓慢，用户体验不好 –> 不易使用
    • 例如：某社交APP运行特别缓慢，并且发送消息操作过程复杂，用户使用感到迷茫
  • 注： 标准①③严重，标准④中等级别， 标准②⑤中下级别，标准②几乎不出现

缺陷描述要素

【前置】用例执行步骤：

  1. 待测用例：准备待测试用例，最后添加一列执行结果
  2. 待测软件：开发提测后，运行待测软件
  3. 判断结果：判断实际结果是否和预期一致，一致测试通过（pass），不一致（fail）提交缺陷报告
案例演示：根据已编写用例进行用例执行

ScreenShot_2026-05-06_145404_637.png

缺陷报告构成核心要素

图片高清修复.png

缺陷的其他要素

图片高清修复 (2).png

缺陷的优先级可以对应用例优先级；一般情况下严重级和优先级一致

缺陷报告中优先级与严重程度建议保持映射对齐：即最严重的S1级缺陷对应最高优先级P1，S2对应P2，以此类推，便于缺陷管理与处理排序。

阻塞（Blocker）: 功能无法使用

‌致命（Critical/Fatal）‌：导致系统崩溃、数据丢失、核心功能完全失效，必须立即修复。例如软件无法启动或关键业务流程中断。

‌严重（Major/High）‌：主要功能无法正常使用，但系统仍可运行。例如登录功能失效或支付流程出错。

‌一般（Normal/Minor/Medium）‌：次要功能受影响，用户操作受限，但不影响主流程。例如部分页面加载异常或信息显示不全。

‌轻微（Trivial/Low）‌：界面显示错误或非关键性交互问题，如错别字、按钮错位等，对功能无影响。

‌建议（Suggestion/Enhancement）‌：不影响功能，但存在用户体验改进建议，如界面美化、操作流程优化等。

‌P0（紧急）‌：必须立即修复，24小时内解决。此类缺陷导致系统崩溃、无法安装、核心功能完全不可用或阻断测试流程，如软件闪退、关键业务中断。2小时内修复

‌P1（高）‌：需在版本发布前优先修复。影响主要功能使用，但系统仍可运行，如支付失败、登录异常等关键问题。当日修复

‌P2（中）‌：应修复但可延后处理。影响次要功能或用户体验，如部分页面加载错误、非核心模块功能异常。三天内修复

‌P3（一般）‌：建议修复，优先级较低。多为低频使用功能的问题，如边缘场景下的兼容性问题。周内/本版本内修复

‌P4（低）‌：可暂缓或忽略。多为界面错别字、文字重叠、图标不齐等不影响操作的微小瑕疵。后续版本修复

值得注意的是，‌严重程度高的缺陷不一定优先级高‌，例如一个错别字若出现在品牌名称中，可能被定为P0优先级，尽管其严重程度仅为轻微。

缺陷报告示例

ScreenShot_2026-05-22_131717_296.png

wechat_longscreenshot_2026-05-22_132347_741.png

总结：

  1. 前置：执行用例三步骤 ①准备测试用例 ②提交待测软件 ③判定执行结果
  2. 缺陷报告核心内容 缺陷标题、预置条件、重现步骤、预期结果、实际结果、 附件日志（可选）
  3. 缺陷报告其他内容 缺陷编号、缺陷严重级、缺陷优先级、缺陷类型、缺陷状 态
  4. 易错点：编写建议 ①缺陷标题：测试条件+实际结果（预期结果） ②缺陷级别：一般优先级和严重级保持一致即可
  5. 执行用例注意事项： 执行用例时可在用例中增加一列实际结果

测试用例与缺陷报告的关系

测试用例是缺陷发现的前提依据，缺陷报告是测试用例执行结果的沉淀输出，二者是软件测试流程中紧密关联的核心文档‌，具体关系可以从测试流程、作用关联、迭代反馈三个维度梳理：

1. 流程层面的先后依赖

软件测试遵循固定流程：获取测试需求→设计开发‌测试用例‌→执行测试用例→提交‌缺陷报告‌。测试用例执行前，缺陷不会被系统化发现，只有按照测试用例执行测试，对比预期结果与实际输出不一致后，才会生成对应的缺陷报告。

每一个缺陷都可追溯到对应测试用例：专业测试工具中都会支持缺陷与测试用例的关联绑定，便于开发修复后，通过原测试用例完成回归验证，确认缺陷是否被正确修复。

2. 作用层面的互补支撑

表格

文档类型核心作用对另一文档的价值
‌测试用例‌提前定义测试场景、步骤与预期结果，指导测试执行，避免遗漏为缺陷提供可复现的标准流程，缺陷描述可直接引用测试用例的步骤和数据，降低沟通成本
‌缺陷报告‌记录发现的问题详情，跟踪缺陷处理全流程验证测试用例的有效性：如果缺陷是未被用例覆盖的场景，说明测试用例设计不全，需要补充对应用例
3. 迭代层面的循环优化

缺陷可以反哺测试用例的完善：

  • 如果缺陷属于漏测场景，需要新增/补充对应测试用例，提升后续版本的需求覆盖率；
  • 如果原有测试用例因为需求变更已经失效，缺陷处理过程中会同步废弃或更新测试用例；
  • 当缺陷修复完成后，必须重新执行对应测试用例完成回归，确认缺陷关闭，形成闭环迭代。

随着AI技术在测试领域的应用，现在已经可以通过多模态模型自动完成缺陷报告与关联测试用例的匹配，大幅提升回归测试的效率，解决了人工匹配容易遗漏的痛点。

案例 编写缺陷报告

要求： 1. 根据之前练习中已经编写的用例进行执行 2. 执行过程发现bug提交缺陷报告

软件缺陷管理

缺陷的跟踪流程：目的：搞清楚工作中如何和开发协同处理bug，直到bug清除（关闭）

图片变高清.png

  • 缺陷报告编写规范：

    • 准确：描述的信息是正确的。
    • 具体：有细节且是真实特定的。
    • 简洁易懂：描述简单容易理解
    • 次序清晰：描述缺陷过程有条件，有先后顺序。

  • 提交缺陷注意事项

    • 可重现：缺陷可以复现
    • 唯一性：一个缺陷上报一个问题
    • 规范性：符合公司或者项目要求

  • 缺陷（bug）不可复现怎么办？

  1. 从严重级出发，严重级低，暂时可以不考虑（后续尝试复现）；严重级高，需要分析排查
  2. 思考自己测试过程，是否和设计步骤，思考测试环境
  3. 寻求协助：测试老员工，开发协助（记录出现问题的时间，查询对应时段的日志，分析日志）
  4. 如果没有日志，需要开发给一个有调试日志的版本，后续连续跟踪三个版本后，再未复现，此时放弃
  5. 后续版本再次出现，直接转/提正式bug，详细描述你的复现过程
    • 从内部出发向外找原因：替换法和排除法、寻求外援（打印/查日志）

二、项目管理工具

常见项目管理工具

  • 禅道（国产、免费）
  • JIRA（国外、收费）
  • QC、TAPD、PingCode、Bugzila...

2.1 禅道介绍

  • 禅道的特点
    • 三权分立：产品、开发、测试
    • 四角协同：产品经理、项目经理、开发团队、测试团队

2.2 测试应用

禅道使用流程

图片变高清 (1).png
  • 管理用例 ：写用例 → 评审用例 → 执行用例
  • 管理缺陷 ：写缺陷报告 → 跟踪缺陷 → 回归测试
  • 详情见禅道系统使用演示

2.3 禅道使用

用例管理

  • 用户入口：测试 --> 用例 --> 功能用例

  • 编写用例

image-20211211164659411-1698996460607-1.png

image-20211211164536039-1698996460607-2.png

  • 评审用例

    新创建的用例，待评审

image-20211211171912716-1698996460607-3.png

  • 执行用例

    必须评审通过

image-20211211171932563-1698996460608-4.png

禅道的执行结果：pass(通过) ；fail(失败) ；N/A(忽略) ；block(阻塞)。

image-20220222185916128-1698996460608-5.png

缺陷管理

  • 提交bug

image-20211211173242127-1698996460608-6.png

image-20211211173315891-1698996460608-7.png

  • 跟踪bug
    • 测试->Bug-> 状态：激活，“激活”就是缺陷报告里的“new”；
    • 状态：已解决->回归测试（要更新为开发提过的版本再测）->点关闭（修复好了）

image-20220222173817967-1698996460608-8.png

  • 验证bug

image-20211211173610023-1698996460608-9.png

缺陷报告： ScreenShot_2026-05-25_232803_693.png 禅道提bug： ScreenShot_2026-05-25_232538_356.png

管理缺陷：禅道->测试->Bug->状态：激活，就是缺陷报告里的new

案例 1.在禅道上完成用例的管理

  • 注意：检查是否已经开启用例评审功能
      1. 创建单条测试用例/批量测试用例
      1. 评审测试用例
      1. 执行测试用例

案例 2.在禅道上完成缺陷的管理

  1. 提交缺陷（测试账号）
  2. 跟踪管理缺陷（模拟开发和测试，重点关注测试）

实战项目

产品功能架构：产品主要分为三个前端子产品

ScreenShot_2026-05-06_162553_085.png

  1. 用户端：APP，用户可以查看资讯、文章内容，进行问答讨论交流
  2. 自媒体运营平台：PC网站，自媒体用户可以管理文章、评论，查看分析粉丝数据
  3. 系统后台：PC网站，内部运营管理系统

测试安排

测试范围：① 覆盖核心业务功能测试 ② 覆盖核心单功能测试

测试对象：媒体平台+系统后台

测试环境：

软件测试的流程
  1. 需求评审：确保各部门需求理解一致
  2. 测试计划编写：测什么、谁来测、怎么测
  3. 用例设计：验证项目是否符合需求的操作文档
  4. 用例执行：项目模块开发完成开始执行用例文档实施测试
  5. 缺陷管理：对的缺陷进行管理的过程
  6. 测试报告：实施测试结果文档

项目测试实施 如何开展测试：

  1. 需求评审
    • 看懂理解，达成一致
    • 找出重点，预估时间
  2. 编写测试计划
    • 测什么？
    • 谁来测？
    • 怎么测？
  3. 用例设计
    • 提取测试点（XMind）-> 质量模型
    • 编写用例（Excel）
  4. 用例执行
    • 用例准备，添加执行结果
    • 缺陷管理，提交bug
  5. 缺陷管理
    • 跟踪管理缺陷
  6. 测试报告
    • 测试完成的标志

测试范围

  • 发布文章业务流程
  • 登录、发布文章、文章审核功能

业务流程测试步骤：

  1. 熟悉需求
  2. 确认流程图，梳理测试点
  3. 测试点转执行测试用例
  4. 缺陷管理

单功能测试步骤：

  1. 熟悉需求
  2. 提取测试点覆盖需求
  3. 测试点转执行测试用例
  4. 缺陷管理
案例 根据流程图，针对“发布文章业务流程”设计测试用例

步骤：

  1. 熟悉需求
  2. 确认发布文章流程 法本流程：登录->发布->文章审核->审核通过
  3. 确认流程图 工具：processon
  4. 编写测试用例

ScreenShot_2026-05-06_165244_121.png

案例 登录需求
ScreenShot_2026-05-06_165610_975.png

项目地址：heima-wemedia-java.itheima.net/#/login

需求说明：

  1. 用户名：必填项，格式正确、注册成功的用户账号；
  2. 密 码：必填项，注册成功账号对应密码
  3. 协 议：必填项，未勾选时提示 “请勾选【我已阅读并同意用户协议和隐私条 款】”
  4. 登 录：用户名、密码正确、勾选协议后点击登录按钮，登录成功

异常说明：

  • 用户名为空时，提示【请输入用户名】
  • 用户名不存在时，提示【当前用户不存在】
  • 密码为空时，提示【请输入密码】
  • 密码和账号不匹配时，提示【密码错误】
案例 发布文章

ScreenShot_2026-05-06_170140_598.png

案例 发布文章测试需求

需求说明：

  1. 文章标题：必填项，文章标题不能小于4个字符且不能超过30个字符；
  2. 文章内容：必填项，可以输入文字、选择图片、本地上传图片（支持扩展名：jpg、png，文件不得大于2MB）
  3. 标签：必填项，标签长度不能超过20个字符
  4. 频道：必填项，可选择java、mysql、vue、python、weex、大数据、其他
  5. 定时：必填项，用户可通过日历控件选择当前时间之后的日期及时间
  6. 封面：单图、三图、无图、自动上传图片（支持扩展名：jpg、png，文件不得大于2MB）
    • 说明：
      • 点击【提交审核】，提示新增文章成功，跳转到内容列表，文章状态显示待审核
      • 点击【存入草稿】，提示保存文章成功
案例 根据流程图，针对“文章审核功能”设计测试用例

ScreenShot_2026-05-06_170623_100.png

案例 文字审核

ScreenShot_2026-05-06_171048_988.png

2.4 JIRA使用

测试主要应用：bug管理

  • 提交bug
  • 跟踪验证bug

image-20240616170356660.png

image-20240616170009997.png

image-20240616170126203.png 扩展

image-20240616171720160.png

测试报告

  1. 测试报告作用？ 测试完成的标志，对于测试工作的总结，也是对质量的评估和承诺。
  2. 测试报告核心内容？（下图）
ScreenShot_2026-05-06_171249_392.png ScreenShot_2026-05-06_171922_777.png

总结：

  1. 如何开展项目测试： ①需求评审 ②测试计划 ③用例设计 ④用例执行 ⑤缺陷管理 ⑥测试报告
  2. 用例设计核心思路 提取测试点：参考质量模型核心5特性
avatar
文章
阅读
粉丝