测试用例模板这东西，测试看着简单，用例用起来全是模板坑。我见过太多测试员，和例拿着Excel表填了十几行“输入正确数据，测试点击按钮，用例验证结果正确”，模板然后就被开发打回来说“这用例没法执行”——因为压根没写清楚“正确数据”到底是和例什么。 先给个能直接用的测试模板，字段就七个：用例编号、用例前置条件、模板测试步骤、和例输入数据、测试预期结果、用例实际结果、模板优先级。别多加花哨的“所属模块”“用例类型”之类的，新手容易填错，老手看着烦。编号要规范，比如“LOGIN_001”，一眼就知道测的是登录模块第几条用例。 举个例子。测一个注册功能，普通人的写法是：“输入用户名密码，点击注册，提示成功。”这算啥？用户名是数字还是字母？密码要不要特殊字符？要不要验证手机号？开发看了直接扔回来。 换成能跑的模板，长这样： 用例编号：REG_003 前置条件：数据库已清空，注册页面正常打开 测试步骤： 1. 输入用户名“test_user_01”（纯小写字母加下划线，长度10位） 2. 输入密码“Abc@123456”（首字母大写，含@符号，共9位） 3. 再次输入确认密码“Abc@123456” 4. 点击“立即注册”按钮 预期结果：页面提示“注册成功”，3秒后自动跳转到登录页，数据库user表中新增一条记录，用户名为test_user_01，密码字段为加密值（非明文） 实际结果：（执行时填写） 优先级：高 看出差别了吗？关键是把“输入数据”具体到能复现——哪怕换个人来执行，照着步骤敲键盘，结果也应该一模一样。前置条件写“数据库已清空”是为了排除脏数据干扰，否则你测注册，库里早有个同名用户了，报错提示“用户名已存在”，你分不清是功能问题还是数据问题。 再补一个负向用例，这种最容易漏。测密码强度校验： 用例编号：REG_007 前置条件：注册页面正常打开 测试步骤： 1. 输入用户名“valid_user” 2. 输入密码“123”（仅3位数字） 3. 确认密码“123” 4. 点击注册 预期结果：密码输入框下方红字提示“密码长度至少6位，需包含字母和数字”，注册按钮不可点击，无任何请求发送到后端 优先级：中 这用例强在哪？它把“注册按钮不可点击”和“无请求发送到后端”都写进去了。很多新手只验证“有没有提示”，但没验证“后端到底收没收到非法请求”。万一前端漏了校验，后端也没拦，那这bug就漏到生产环境了。 写模板时有个小窍门——步骤别超过五步。超过五步，执行的人就开始犯迷糊，容易漏操作。实在步骤多，就拆成多个用例，比如“注册_填写信息”和“注册_提交验证”分开写。每个用例只验证一件事，这是铁律。 还有“预期结果”别写“系统正常运行”这种废话。要写具体的反馈：页面跳转到哪、弹出什么文本、数据库怎么变、接口返回什么状态码。越具体，后面自动化测试越省事——直接拿预期结果当断言条件用。 模板里的“实际结果”一栏，执行时别只写“通过”或“失败”。真出了bug，要写“实际弹出提示‘用户名已存在’，但该用户名为新注册，且数据库未查询到记录”，这样开发拿到bug单，一眼就知道问题出在判断逻辑上，而不是去猜。 最后说个真实案例。我们项目组有次上线前，测试用例里写“输入手机号”，结果没人定义手机号格式。测试员填了个“13800138000”，开发按“1开头11位数字”做的校验，测出来全通过。上线第二天，用户拿“8613800138000”（带国际区号）注册，直接报错。后来模板里加了“数据格式说明”字段，逼着写用例的人把“11位数字，以13/15/17/18/19开头”这种细节写死，再没出过这种幺蛾子。 模板是死的，人是活的。你拿着上面的框架，往里填自己项目的真实场景，填得越具体，测试就越靠谱。别嫌麻烦，你省下的每一句描述，后面都是执行时的一个坑。