刚接触软件测试，听人说要走 “需求分析、用例设计、执行测试” 这些步骤，可每个步骤到底要做啥？比如 “需求分析” 是光看文档就行，还是要跟人沟通？“执行测试” 时遇到 bug 该咋记录？别慌，今天云哥就把软件测试各步骤的具体操作拆解开，还用了多种格式呈现，保证大家一看就懂，一起往下看吧！

一、先总览：软件测试有哪几步？各步核心目标是啥？（表格 + 引用）

先给大家列个总表，清楚各步骤的顺序和核心目标，后面再逐个讲具体操作：

测试步骤	核心目标	耗时占比（参考）	新手易忽略的点
需求分析阶段	明确 “要测什么”，确定测试范围	15%	没跟产品确认疑问，导致理解偏差
测试计划阶段	规划 “怎么测”，安排资源和时间	10%	没考虑风险预案，遇到问题手忙脚乱
测试用例设计阶段	写清 “测的步骤”，覆盖需求场景	25%	只测正常场景，漏了异常情况
测试执行阶段	动手 “找 bug”，验证功能是否正常	35%	发现 bug 不截图，开发无法复现
测试总结阶段	反馈 “测的结果”，评估产品质量	15%	只统计数据，没分析问题原因

引用一位资深测试的话：“需求分析做不好，后面全白搞；用例设计不全面，执行时全是坑。” 可见每个步骤都不能马虎，具体操作得细致。

二、分步详解：每个步骤具体做什么？（教程 + 列表 + 问答）

1. 需求分析阶段：不是 “看文档” 这么简单（步骤教程）

很多新手以为需求分析就是看一遍需求文档（PRD），其实远不止，具体要做 4 步：

• 第一步：通读文档，划重点
  打开 PRD，把产品的核心功能、用户操作流程、异常场景处理这些内容划出来。比如测试 “外卖 APP 下单功能”，要划 “选餐→加购物车→填地址→付款→收订单通知” 这个流程，还有 “地址为空时不能下单”“付款失败要提示用户” 这些规则。
• 第二步：画思维导图，梳理测试范围
  用 XMind 或 MindMaster 画思维导图，把要测的功能拆成小模块。比如 “下单功能” 可拆成 “选餐模块、购物车模块、地址模块、付款模块”，每个模块再列具体要测的点，比如 “地址模块” 要测 “新增地址、编辑地址、删除地址”。博主经常使用这个方法，能避免漏测。
• 第三步：跟相关人员确认疑问
  看文档时遇到不懂的，比如 “付款时支持哪些支付方式”，要及时找产品经理确认；遇到技术相关的，比如 “订单数据是否实时同步”，要问开发。别自己猜，之前有个新手没确认 “是否支持优惠券叠加”，结果测错了，白忙活半天。
• 第四步：输出需求分析文档
  把梳理的测试范围、确认的疑问答案写成文档，发给团队成员，确保大家对需求的理解一致。文档不用太复杂，用 Word 或 Excel 列清楚就行。

问答：需求文档看不懂专业术语咋办？
答：直接问产品经理要 “产品原型图”（比如 Axure 画的），结合原型图看文档，比如原型图里有 “付款按钮” 的位置和点击后的弹窗，比文字好理解；也可以让产品给你演示一遍产品流程，边看边记疑问。

2. 测试计划阶段：像 “项目经理” 一样规划（列表 + 建议）

这个阶段要做的就是把测试的 “人、财、物、时间” 规划好，具体操作：

• 人员安排：谁负责测哪个模块？比如 A 测 “下单功能”，B 测 “订单查询功能”；谁负责写测试报告？提前定好，避免推诿。
• 时间规划：用 Excel 做个时间表，比如 “需求分析 3 天→测试计划 2 天→用例设计 5 天→执行测试 7 天→总结 3 天”，还要留 1-2 天缓冲时间，防止开发延期影响测试。
• 资源准备：需要哪些设备？比如测试 APP 要准备安卓手机（至少 2 个型号）、iOS 手机；需要哪些工具？比如用例管理工具 TestRail、缺陷管理工具 JIRA，提前下载好并熟悉基本操作。
• 风险预案：列出可能遇到的问题和解决办法，比如 “开发延期 2 天→压缩用例中非核心场景的测试时间”“测试设备坏了→备用设备提前充电，随时能用”。

建议：新手做测试计划时，最好找老测试帮你看一遍，比如有没有遗漏资源准备，时间安排是否合理，能少走很多弯路。

3. 测试用例设计阶段：写 “能落地的测试步骤”（示例 + 列表）

测试用例是给执行测试的人看的，步骤要具体到 “傻子都能跟着做”，具体操作：

• 第一步：确定用例要素
  每个用例必须包含：用例名称、前置条件、测试步骤、预期结果、实际结果。比如：
  • 用例名称：测试外卖 APP 正常下单流程
  • 前置条件：用户已登录、购物车有商品、地址已添加
  • 测试步骤：1. 打开外卖 APP→2. 点击 “购物车”→3. 点击 “去结算”→4. 选择默认地址→5. 点击 “提交订单”→6. 选择微信支付并付款
  • 预期结果：付款成功，跳转至 “订单确认页”，显示订单号
  
  
• 第二步：覆盖全场景
  别只写正常场景，还要包含异常场景和边界场景，比如：
  • 异常场景：地址为空时点击 “结算”（预期：提示 “请添加收货地址”）
  • 边界场景：购物车商品数量达到上限（比如 100 件，预期：提示 “最多添加 50 件商品”）
  
  
• 第三步：评审用例，补漏洞
  把写好的用例发给产品、开发、其他测试，开评审会。比如有个用例没考虑 “用户用优惠券付款”，评审时开发指出来，及时补充，避免执行时漏测。

4. 测试执行阶段：找 bug + 记录 bug，缺一不可（操作列表 + 问答）

这是新手最容易上手的阶段，但要做好也有讲究，具体做 3 件事：

• 准备测试环境
  比如测试 Web 端，要打开对应的测试网址（不是生产环境）；测试 APP，要安装开发给的测试包（不是应用商店的正式版），确保环境和用户实际使用的一致。
• 按用例执行测试
  打开测试用例，一步一步操作。比如按 “正常下单” 用例操作，要是付款后没显示订单号，就说明遇到 bug；要是操作和预期结果一致，就标记 “用例通过”。
• 详细记录 bug
  发现 bug 后，用 JIRA 或禅道这类工具记录，必须包含：
  1. bug 标题：简洁说明问题，比如 “外卖 APP 提交订单后，未显示订单号”
  2. 操作步骤：跟测试用例步骤一致，方便开发复现
  3. 实际结果和预期结果：对比写清，比如 “预期：显示订单号；实际：空白”
  4. 截图 / 录屏：把 bug 现象截下来，最好录操作过程，开发能快速定位问题
  
  

问答：执行时发现用例没覆盖的 bug，要不要记录？
答：当然要！先在工具里记录 bug，标上 “新增场景”，然后补充到测试用例里，后续执行时就能覆盖到。我之前测 “登录功能” 时，发现 “输入 11 位错误手机号” 没提示，用例里没写，记录 bug 后补充了用例，避免下次漏测。

5. 测试总结阶段：不是 “报数据”，要 “分析问题”（图表 + 心得）

很多新手以为总结就是列 “用例通过率、bug 总数”，其实还要分析问题，具体做 2 步：

• 第一步：统计数据，做图表
  用 Excel 统计 “总用例数、执行数、通过数、失败数、bug 总数、严重 bug 数”，比如 “总用例 100 条，执行 98 条，通过 85 条，bug20 个（严重 5 个）”。再用柱状图展示 bug 类型分布，比如 “功能 bug12 个、界面 bug5 个、性能 bug3 个”，直观看到主要问题。
• 第二步：分析问题，提建议
  别只列数据，要分析 “为什么会有这么多功能 bug？”“严重 bug 集中在哪个模块？” 比如发现 “付款模块严重 bug 多”，要建议开发重点检查这个模块的代码；要是 “界面 bug 多”，建议产品和设计在需求阶段多确认细节。

心得：我刚开始写测试总结时，只报数据，领导说 “光看数据不知道问题在哪，要给解决方案”。后来我加了问题分析和建议，总结报告才真正有价值，大家别犯跟我一样的错。

三、新手避坑：各步骤最容易做错的操作（警示列表）

最后给大家列几个新手常踩的坑，提前避开：

1. 需求分析时 “不问不确认”，凭自己理解测，结果方向错了；
2. 用例设计时 “只测正常场景”，比如测 “登录” 只测 “正确账号密码登录”，漏了 “密码错误、账号为空” 的情况；
3. 执行测试时 “发现 bug 不截图”，开发说 “我这没这问题”，没法复现；
4. 总结时 “只统计不分析”，数据再好也不知道怎么改进产品。

云哥觉得，软件测试各步骤的具体操作，看着多但不难，关键是 “细致” 和 “多沟通”。比如需求分析多跟产品确认，用例设计多跟同事评审，执行测试多记录细节，慢慢就能熟练。希望这些内容能帮到大家，别再对各步骤的操作迷茫啦！