编写软件测试用例是在将隐性的测试思维显性化、结构化和工程化。

第一部分：测试用例的知识

一个优秀的测试用例必须有唯一性、可重复性、可证实性。不管采用什么格式，都必须有以下七个重点：

唯一标识和关联追溯：这是用例的身份号，一般由项目代号、模块名和数字序号组成。必须关联对应的需求文档（如JIRA编号或PRD章节），是保证每个用例都有来源，当需求变更时能准确定位需要修改的用例，避免无用功。

前置条件：执行步骤之前的初始状态定义。是用户已登录，更要细化到用户处于VIP等级且账户余额为100元或数据库中存在ID为XXX的历史订单。缺少精确的前提，执行结果就失去了可复现的标准。

测试数据：数据必须具体且边界清晰。不要写输入错误密码，而要写输入长度为7位的纯数字错误密码。数据的来源（是造数工具生成，还是SQL预置）也应简要说明。

操作步骤：步骤必须原子化（不可再分）且顺序强依赖。如点击‘购物车’图标是一个步骤；滑动页面到底部并点击‘加载更多’就是两个步骤的合并，需要拆开。每一步都要有确定的动作动词（点击、输入、滑动、等待）。

预期结果：包含三个方面：界面反馈（弹窗文字、按钮状态变化）、数据变化（数据库字段更新、本地缓存写入）、系统跳转（页面路由是不是正确）。避免模糊词，如系统正常是不合格的，应改为页面顶部出现绿色Toast提示‘修改成功’，且数据库update_time字段更新为当前时间戳。

优先级和风险等级：优先级（P0/P1/P2）决定了冒烟测试和回归测试的范围。风险等级则标注该功能崩塌对业务的影响面（如支付永远是最高风险）。

后置处理：说明执行完毕后怎样恢复环境，比如删除本次生成的测试订单或重置用户密码为初始值，保证用例之间的独立性和环境的洁净度。

第二部分：编写思路

思路一：从用户故事出发，设计场景流

不要一上来就盯着输入框。先绘制用户的旅程：起点（触发） - 过程（交互） - 终点（结果）。

正向场景：包括80%用户的重要操作，保证主流程通畅。思路是最少步骤完成目的。

异常场景：这是体现测试作用的重点。思考用户在第三步突然断网、支付途中强行杀进程、服务器返回500错误时前端是不是崩溃。编写思路是逆向思维：把用户能犯的错、系统能出的错，全部前置预演一遍。

思路二：运用等价类 + 边界值

等价类划分：将无限输入归为有限集合。如合法年龄的等价类是18-60岁。写用例时，只需从每个等价类中抽取一个代表值（如25岁）即可代表整个类，无需重复编写相似步骤。

边界值分析：编写思路是卡住临界点。对于长度限制为10的输入框，必须包括0位（空）、1位（最小）、9位（最大-1）、10位（最大）、11位（溢出）。在写预期结果时，重点证实第11位是不是被截断或报错。

思路三：采用状态迁移法整理复杂流转

当涉及订单状态、审批流等思路时，思路是画图写点。先在草稿纸上画出状态流转图（待支付 - 已支付 - 已发货 - 已签收），然后针对每条箭头编写用例。这能保证包括所有合法的状态跳转，同时证实非法的状态跳转（如已签收状态不允许申请退款）。

思路四：以原子化和语言精确性重塑描述

第一道：去UI化。步骤不要写在第一个框里填，而要写在‘手机号’输入框中。预期结果不要只盯着页面，要思考底层API返回的code字段是不是为0。

第二道：去主观化。使用统一的词汇表。规定点击指轻触，滑动指拖拽。规定跳转指路由变更，弹窗指浮层提示。当语言精确到程序员无法反驳时，这份用例就是最好的开发自测清单。

第三部分：避坑指南和进阶认知

切忌把用例写成操作手册：好的用例是有思路的，不是步骤的简单堆砌。每一条用例背后都应该有一个确定的测试点如证实幂等性、证实事务一致性。

切忌过度设计：对于UI方面的细微样式变动（如按钮圆角），不应纳入重要功能用例，而应放入UI走查清单。测试用例需要保持对业务思路的敏感度，对纯样式设计保持钝感，否则维护成本会失控。

复用思维：公共的登录步骤、基础的查询前置，不应重复写在每个用例里。编写思路是提取公共前置，在主用例中写请参考公共用例TC-001完成登录状态准备，只聚焦当前模块特有的思路。

最凡是写不清楚的用例，往往是因为对需求理解不透彻。 如果编写时感到卡顿，立刻去找产品经理或开发核对，而不是强行编造步骤。