《测试用例 + 缺陷报告：从写用例到提Bug，一次讲清楚》

有了测试点之后，怎么把它写成规范的测试用例？测出Bug之后，怎么报告、怎么跟踪？

一、测试用例：不只是“随便记一下”

1.1 测试用例是什么？

在写用例之前，我一直以为测试就是“拿着手机点点点，发现不对就截个图”。学完之后发现完全不是这么回事。

测试用例的定义（我的笔记原话）：

为特定测试目的而设计编写的详细、可执行的文档。

拆开来看就是三个关键词：

• 特定测试目的：你这次测的是什么？（比如“验证密码长度限制”）

• 详细：每一步怎么操作、用什么数据、期望什么结果，全部写清楚

• 可执行：换一个人拿着你的用例，也能一模一样地执行出来

1.2 为什么要写测试用例？（三个作用）

说白了，写用例既是对自己负责（不漏测），也是对团队负责（可追溯）。

二、一个规范的测试用例，包含哪些内容？

根据我的课堂笔记，一个完整的测试用例包含以下要素，我以“微信密码8-16位”为例来填充：

写用例的时候我有一个感受：“测试步骤”一定要写得足够细，细到随便一个人拿着都能执行。像“输入密码”这种描述太模糊，要写清楚“在哪个框输入什么内容”。

三、从测试点到测试用例：一个完整的流程

笔记里有一张流程图，我把它整理成文字版：

简单说就是：需求 → 测试点 → 测试用例 → 评审 → 执行。

四、执行测试，发现Bug

4.1 什么是Bug？（缺陷的定义）

我的笔记里写得很直白：

软件在运行过程中出现的各种异常，叫Bug。

常见的Bug类型包括：

4.2 Bug报告怎么写？

发现Bug之后，需要提交一份缺陷报告。根据我的笔记，包含以下要素：

笔记里还特别写了一句：“一个缺陷报告只反映一个问题”。不要在一个报告里堆好几个Bug，这样开发和测试都容易乱。

4.3 Bug的生命周期（状态流转）

发现Bug不是终点，还要跟踪它直到关闭。笔记里记录的状态流转如下：

几个关键状态：

笔记里还提到了开发可能“拒绝Bug”，这时候需要和开发沟通清楚——是需求本身如此，还是确实有问题，不能直接关上就不管了。

五、缺陷管理工具：禅道

实际工作中，我们不会用Excel来管理Bug，而是用专门的工具。笔记里提到的有：

• 禅道（国内最常用，集用例管理+缺陷管理于一体）

• JIRA（国际大厂常用）

• TAPD（腾讯出品）

禅道上做的事（笔记原文）：

整个流程从“写用例”到“发现Bug”到“跟踪修复”都在一个平台上完成。

六、用例 + 缺陷 速查卡

测试用例要素速查

缺陷报告要素速查

缺陷状态流转口诀

New提交 → Open确认 → Fixed修复 → Closed关闭
验证没过 → Reopen重新打开 → 再修再验

七、我的学习感受

通过这一部分的学习，我对测试的整体流程有了更清晰的认识：