学习软件测试的第三天

十一.测试报告里包含那些内容

测试报告（Test Report）是测试阶段完成后编写的总结性文档，用于反映软件的测试结果和质量评估，帮助项目决策是否上线。

1.测试报告常见内容结构

模块	说明	示例
1. 项目概况	描述项目名称、版本、测试时间、参与人等	项目：订单系统 V1.2，测试时间：6.10-6.15
2. 测试范围	明确本轮测试覆盖的模块与不测内容	覆盖下单、支付、订单查询；不测退款流程
3. 测试环境	列出环境配置、数据库、浏览器、APP版本等	Android 13 + 订单服务 v1.2
4. 测试用例执行情况	执行总数、通过数、失败数、阻塞数，用饼图/表格呈现	总用例 200，Pass 180，Fail 15，Block 5
5. 缺陷统计	按严重程度分类 Bug 数量 + 重要 Bug 列表	P1：2 个，P2：5 个；附 Bug 链接/截图
6. 回归验证情况	描述之前的 Bug 是否修复并验证通过	本轮共回归缺陷 12 个，已全部关闭
7. 测试结论与建议	测试结果是否满足上线条件？是否建议上线？	系统核心功能稳定，建议上线，但需关注兼容性风险
8. 遗留问题与风险点	仍存在未解决问题、上线风险说明	某些 UI 在 iPhone 13 上错位，建议后续优化
9. 相关文档链接（可选）	测试计划、用例、缺陷列表、截图附件	附表格、测试计划链接、Jira 缺陷列表

2.面试术语

一份完整的测试报告通常包括以下几个部分：

• 项目背景和测试范围，说明本轮测试覆盖哪些模块；

• 测试执行情况，包括用例数、通过率、执行进度；

• 缺陷统计分析，列出缺陷数量、分布、严重程度及重要缺陷清单；

• 回归验证结果，说明是否对历史缺陷做了验证，是否已关闭；

• 测试结论与上线建议，明确产品是否符合发布标准；

• 还会列出风险点和遗留问题，供项目决策参考；
  整体内容要覆盖过程 + 结果 + 建议，帮助项目判断是否可以上线。

十二.如何提交一份高质量的缺陷跟踪单 

一句话总结：一份好 Bug 单 = 一看就懂 + 一测就复现 + 一改就能解决

1.缺陷单应包含的关键字段

字段	说明	示例
标题（Summary）	简洁明了地描述问题现象	【支付模块】点击“确认支付”无响应
所属模块	便于归类问题来源	支付模块 / 登录模块 / 订单管理
缺陷等级（Severity）	表示问题严重程度	Fatal / Major / Minor
优先级（Priority）	表示修复的紧急程度	P1 / P2 / P3 / P4
复现步骤（Steps to Reproduce）	一步一步说明如何触发该问题	详见下方示例
实际结果	当前系统表现	页面无响应，支付请求未发送
预期结果	正常应有的表现	应跳转到支付成功页面并返回订单信息
测试环境	测试的版本、设备、浏览器	Android 13，App v2.1.5，接口 dev 环境
附件信息	截图 / 视频 / 抓包 / 日志文件	上传日志文件和抓包数据
责任人 / 指派给	开发负责人	张三（支付模块开发）

 2.面试术语

一份高质量的缺陷跟踪单，首先需要描述清楚问题发生在哪个模块、什么操作触发、系统如何响应、以及预期行为是什么。
我通常会用清晰的步骤+截图或视频+必要的日志来说明复现方式，确保开发能准确理解问题并快速修复。
我也会合理设置严重程度与优先级，并在 Bug 修复后进行验证回归，推动问题闭环。
此外，我会注意避免重复提交，通过查看历史记录、检索关键词判断是否已有类似问题。

十三.如何提高用例的覆盖率，减少漏测

1.理解“用例覆盖率”的本质

用例覆盖率 = 你测试用例覆盖了多少功能点、场景、路径、边界、异常情况

目标是：不漏业务、不漏条件、不漏路径

2.如何提高测试用例覆盖率？——五大方法

（1）梳理完整的功能点（防止功能遗漏）

• 根据 PRD、流程图、接口文档拆解所有模块和子功能

• 做一张【功能点清单表】或【测试矩阵】

• 保证每一个功能点都有对应的测试用例

示例：订单模块包括下单、修改订单、取消订单、查询订单、导出订单……

（2） 使用系统性设计方法（防止场景遗漏）

方法	作用	示例
等价类划分	覆盖有效/无效输入	手机号输入框：11位数字 vs 空/字母/超长
边界值分析	覆盖临界条件	年龄：18/19/60/61，价格为0或负数
状态迁移法	覆盖流程跳转	订单：下单 → 支付 → 发货 → 收货 → 退货
判定表法	覆盖复杂条件组合	满减/会员/优惠券多条件判断
错误推测法	经验性补充	特殊字符、重复提交、越权访问等

（3）增加负向用例与异常场景

• 不仅测“能用”，也测“出错时怎样”

• 如：字段为空、格式错误、接口返回超时、token失效、网络异常

（4）评审机制 + 交叉检查（多人参与降低盲区）

• 和产品一起做用例评审，确认业务覆盖无误

• 多人审查测试点，避免个人遗漏

• 也可借助测试覆盖工具（如代码覆盖、接口覆盖分析）

（5）用自动化 & 测试回归机制弥补“长期覆盖盲点”

• 核心流程自动化保障每次提测后都能完整验证

• Bug 回归 → 回补用例 → 提高覆盖率

 3.面试术语

为了提高用例覆盖率，我通常会从以下几个方面着手：

• 首先根据产品需求文档和流程图，梳理出完整的功能点清单，确保每一项功能都有用例覆盖；

• 然后使用等价类划分、边界值分析、状态迁移等方法系统性设计用例，不仅测正向流程，也补充各种异常情况；

• 同时我也会组织用例评审，与产品和开发一起确认是否有遗漏；

• 对于高风险区域或历史高发 Bug 区域，我会重点设计用例并适当补充自动化测试；

• 最后通过回归 Bug、补测缺陷路径、覆盖异常路径，不断完善测试用例库，从而有效减少漏测现象。

十四.如果没有需求文档，如何展开测试 

当缺乏需求文档时，测试要以“逆向推理 + 主动沟通 + 探索验证”为核心。

1.六步策略

（1）先观察产品原型或界面

• 如果有 UI 原型图、设计图、前端页面，可先了解页面结构、输入输出字段

• 推测基本功能逻辑（如注册登录、列表查询、分页、详情等）

目的：建立功能框架

（2） 参考接口文档、接口返回数据

• 有些项目虽然没完整需求文档，但有 Swagger、YAPI、Postman 接口文档

• 根据接口参数和响应字段，推断功能、校验规则、字段类型

目的：辅助理解业务逻辑

（3）请教产品/开发还原需求逻辑

• 主动向产品经理或开发确认每个功能点的行为与边界

• 比如：“这个表单提交时哪些是必填项？”、“这一步流程失败会跳转回哪一步？”

目的：补齐知识盲区，避免误测或漏测

（4）实际操作 + 探索式测试

• 自己动手操作 App 或 Web，模拟用户行为，观察系统响应

• 多尝试边界值、异常输入、重复操作、断网等场景

目的：实际运行中发现问题，建立测试点

（5）记录功能点 + 推导用例

• 根据观察和沟通结果，整理出：

  • 功能点列表

  • 输入条件、预期行为

  • 场景组合（正向 + 负向 + 异常）

目的：形成简版测试用例，辅助执行

（6）持续补全和反馈

• 边测试边补用例

• 把发现的问题/需求模糊点及时反馈给产品团队，推动形成规范文档

目的：形成文档化沉淀

2.面试术语 

在没有正式需求文档的情况下，我会采用“探索 +沟通 +归纳”的方式开展测试：

• 首先我会查看界面原型、接口文档、接口返回内容，从中推断功能逻辑；

• 同时我也会主动向产品或开发请教业务规则、关键流程和边界情况；

• 然后通过实际操作进行探索式测试，尝试不同输入组合和异常路径，记录系统行为；

• 在此基础上，我会整理出功能点列表并形成测试用例，覆盖常规流程和高风险场景；

• 测试过程中我也会不断补充遗漏点，并推动产品团队完善文档；
  通过这些方法，即使在文档不全的情况下，也能保障测试质量。

十五. 遇到概率性bug怎么办

1.什么是概率性 Bug？

概率性 Bug 是指：同样的操作流程，不一定每次都会触发的问题，具有不稳定性、偶发性，难以重现。

例如：

• 偶尔登录失败，但刷新就好了

• 有时下单卡死，重试又成功

• 安卓部分机型偶尔白屏、崩溃

2.七步排查策略 

（1） 确认 Bug 是否真实存在

• 多次重试、换设备/浏览器/网络尝试

• 拉同事一起复测，验证是否“错觉”或“操作误差”

（2）保留现场证据

• 截图、录屏、抓包、控制台报错信息

• 抓 crash 日志、APP logcat、后端日志、前端报错

即使复现不了，也能提供线索给开发分析

（3）寻找共性规律

• 问自己 5 个问题：

  • 是在什么设备上出现？

  • 是在什么时间段？

  • 是网络好/差时才出现？

  • 是否特定用户/数据引发？

  • 是不是多线程或并发相关？

规律越清楚，越容易复现/定位

（4）尝试精确复现条件

• 切换不同网络（WIFI / 4G）

• 使用相同账号/相同数据重试

• 用多线程 / 多用户模拟并发

• 配合开发设置断点/日志加强追踪

（5）加入埋点或日志打点

• 请求入参、接口耗时、状态码、结果状态等详细打印

• 开发加入调试代码，记录异常出现时的上下文信息

抓住现场是关键

（6）提交缺陷时清晰描述概率性

• 用例描述中明确写明“偶发”、“概率复现”、“成功率约 XX%”

• 附带录屏/日志/接口返回内容

• 提供尽可能多的设备信息、操作条件、系统环境

（7）与开发协作排查后端日志

• 如果问题和接口有关，让开发查后端日志

• 如果是 APP 卡死/白屏，查看是否存在内存泄漏、线程阻塞等问题

 3.面试术语

遇到概率性 Bug 时，我会先确认问题是否真实存在，然后尝试通过截图、录屏、抓包等方式保留现场信息；
接着我会从设备型号、操作路径、网络状态、并发场景等多个维度分析是否存在共性规律；
有条件的情况下，我会请求开发在关键节点增加日志，方便后续定位；
提交缺陷时会明确说明这是一个“偶发问题”，并尽可能提供完整的上下文信息和测试环境描述；
如果无法复现，我也会持续关注该问题，并在后续测试中尝试重现，推动其被记录和跟进。