软件测试工作的日常

核心：“以找错为手段，以保障软件质量为目标”，俗称，就是找茬

🏅 专业名词

业务人员： 通常是使用软件的人员，甲方

需求人员：对接提出功能改点的人，然后写成一份需求文档（类似产品说明书），供开发人员开发功能、测试人员依据需求文档写测试案例：进行测试

需求文档：一份明确这个系统的功能如何修改的文档，所有的测试依据，依据这份文档进行测试。

需求澄清： 需求人员写好一份需求文档后，会拉着开发、测试讲解需求的改点，此时测试

测试案例：根据需求文档进行，写的测试用例，描述测什么场景，怎么测，测试的时候按照测试用例进行测试，记录实际的结果

测试环境：分为测试环境和生产环境，一般测试的时候都是在测试环境，所有数据都是虚拟的。生产环境是实际人员使用的环境

BUG/缺陷：测试过程中发现的问题，以 BUG 的形式，提在一个缺陷管理平台，记录问题，供开发人员进行修改

回归测试： 上线新版本之前进行对整个系统，有计划性的重新验证功能点，目的是防止开发修改代码的时候影响到别处

测试报告：整个系统测试完成后，由测试人员进行填写测试报告，形成最终的记录产物（每个公司要求的模板不同）

生产问题：上线后，实际业务人员使用后遇到的问题。测试人员应避免生产问题的出现，考核标准通常以生产问题为准

‍

📃 流程图

需求人员-安排测试改点

需求澄清： 需求人员进行需求澄清，拉着开发、测试进行讲解功能改点

编写需求文档： 需求人员进行对业务提出的功能进行分析，整理成一份需求文档的产物

提出软件更新需求： 业务人员根据当前政策或需要对软件功能进行优化

测试人员-测试过程中

提出疑问： 根据需求澄清，提出不合理的细节或是需要再次确认的关注点

测试评审： 求澄清完后，需要写一份测试案例，后进行评审，和需求人员、开发进行确认，哪些场景需要查缺补漏

测试跟踪： 开始介入测试后，对发现的 BUG 进行跟进，提 BUG 给开发，开发修复完成后进行重新验证

汇报进度： 每天进行汇报进度，如测试进度、发现 BUG 数量、能否按期上线

测试人员-软件上线后跟进

生产问题跟进：如上线后遇到生产问题，需要进行第一时间跟进，复现问题，协助开发修复问题后，重新上线

生产问题复盘：因发生生产问题会影响面比较大，需要进行复盘是哪个环境出问题：如需求没考虑到、测试漏测、开发代码问题。

测试前准备

1. 测试前定义：明确要测什么、怎么测

   1. 核心动作：通过产品的需求文档拆解软件的 “功能点”

      举例：若测试一款 “外卖 APP 的下单功能”，需明确：① 支持哪些支付方式（微信 / 支付宝）？② 地址修改后订单是否同步更新？③ 库存不足时是否有明确提示.

   2. 关键目标：避免 “测试时发现需求理解错”，比如漏测 “优惠券与满减能否叠加”，后期返工成本极高。

2. 制定测试计划与设计测试用例

   1. 明确 “测试范围”（只测下单功能，还是包含订单列表？）、“资源”（用什么手机型号 / 浏览器？）、“进度”（3 天内完成测试）

      举例：若测试一款 “外卖 APP 的下单功能”，需明确：① 支持哪些支付方式（微信 / 支付宝）？② 地址修改后订单是否同步更新？③ 库存不足时是否有明确提示.

   2. 把 “需求” 转化为 “可执行的步骤”，是测试的 “操作手册”。

      用例编号	测试场景	操作步骤	预期结果	实际结果（测试后填）
      TC001	正常下单流程	1. 选 1 份炒饭；2. 填收货地址；3. 用微信支付	支付成功后生成订单，状态为 “待接单”
      TC002	库存不足场景	1. 选 “仅剩 1 份的可乐”；2. 同时开 2 个账号下单	只有 1 个账号能下单，另 1 个提示 “库存不足”

测试中跟进

1. 测试中：执行“找错动作”，精准记录问题

   1. 定义：这是最直观的 “测试日常”，核心是 “按用例执行 + 主动探索”，既要完成既定任务，也要敢于 “跳出用例找隐藏 bug”。

   2. 基础动作：对照测试用例，一步步操作软件，判断 “实际结果是否符合预期”。

      • 若符合（比如下单后正常生成订单）：标记用例 “通过”；
      • 若不符合（比如支付成功但订单没生成）：标记 “失败”，进入 “缺陷记录” 环节。

   3. 记录缺陷（Bug）

      • 核心原则： “开发看了你的记录，能一步到位复现 bug” ，避免 “你说有 bug，开发说测不出来” 的内耗。

      • 缺陷记录需包含的 5 个关键信息（以 “支付成功无订单” 为例）：

        • 缺陷标题：外卖下单 - 微信支付成功后，订单列表未显示新订单；
        • 测试环境：iOS 16 + 外卖 APP V2.3.0 + 测试服务器；
        • 复现步骤：1. 登录账号 XXX；2. 选 1 份炒饭（ID：123）；3. 微信支付 18 元（交易号：456）；4. 返回订单列表刷新；
        • 预期结果：显示 “待接单” 订单；
        • 实际结果：订单列表为空，且无任何错误提示；

   4. 跟踪缺陷

      • 缺陷跟踪：开发修复 bug 后，会在工具上标记 “已修复”，你需要确认 “修复是否有效”—— 比如开发说 “支付无订单” 已修，你要重新按之前的步骤测一遍，看订单是否正常显示。
      • 回归测试：不仅要测 “修复的 bug”，还要测 “相关功能”—— 比如修复 “支付订单” 后，要顺带测 “订单取消”“退款” 是否正常，避免开发改了 A 功能，崩了 B 功能。

2. 日常沟通（确认细节、跟进 BUG、汇报进度）

   • 与产品经理：确认需求细节（比如 “地址最多支持多少个字”）；
   • 与开发工程师：同步 bug 细节（比如 “你修复后我测还是有问题，可能是 XX 步骤没考虑到”）；
   • 与项目负责人：同步测试进度（比如 “今天用例执行了 60%，发现 2 个严重 bug，可能要延期 1 天”）；