测试用例 Test Case
同一个功能需要反复检查时,团队要用固定的输入和步骤确认实际结果没有偏离预期。
技术栈与工具约 10 分钟 · 从真实需求理解
1测试用例怎样把一次检查变得可重复?
TEST CASE · CASE-024保存草稿
固定同一份输入,按步骤运行,再对照 Expected / Actual。
固定输入,方便重复检查
- 01STEP 01输入标题…
title = 周报草稿EXPECT · 输入框保留标题 - 02STEP 02点击保存·
click 保存EXPECT · 请求成功返回 - 03STEP 03检查提示·
assert bannerEXPECT · 页面显示“已保存”
EXPECTED已保存
ACTUAL—
运行后记录实际结果
Test Case 是一份可以重复执行的检查记录。它把测试输入固定下来,列出要按什么顺序操作,再写清楚预期结果;运行后还要记录实际结果,才能判断这次通过还是失败。
- 输入是稳定的测试数据或前置夹具,例如标题“周报草稿”。
- 步骤是按顺序执行的动作,例如输入标题、点击保存。
- 预期与实际要能对照,不能只写“看起来没问题”。
2测试用例不是验收标准,也不是测试报告
验收标准先定义什么算完成,测试用例把其中一条要求变成可以执行的输入和步骤;测试报告则记录多次执行后的通过、失败和统计结果。
- 看到固定输入、操作顺序和断言,想到 Test Case。
- 看到 Given、When、Then 在描述完成边界,想到 Acceptance Criteria。
一个好的测试用例要让另一个人照着做出同样的检查,而不是依赖作者当时的记忆或截图。
3一份测试用例由哪些部分组成?
EXPECTED = ACTUALPASS
把用例拆开,输入决定从什么状态开始,步骤决定怎么执行,证据决定如何判断这次运行是否成功。
- INPUT FIXTURE 是可重复的测试数据,避免每次运行都换一组输入。
- STEPS 是有顺序的动作和检查,说明测试真正执行了什么。
- EVIDENCE 把 Expected 和 Actual 放在一起,给出可以追溯的判断。
4怎样把测试用例交给 Agent?
请为这个功能写一份可重复的 Test Case:固定测试输入,列出每个步骤和对应的 Expected 结果;执行后记录 Actual,并明确说明通过还是失败。不要只给截图或一句“测试完成”。
5不用背,看看你能不能判断
1 / 3
为什么测试用例要固定输入?
请选择一个最符合题意的答案
社区延伸
看别人真实遇到过什么
社区帖子还没有关联到这个词条。