以下文章来源于Tester大田 ，作者Tester大田
其实很多人测试人er都知道测试用例的重要性，它不仅会锻炼我们的测试思维，还可以对项目有个整体的把握，假如有新人来了，通过看测试用例也能熟悉不少，也省去一些我们教的时间。
不少公司项目都是快速迭代的，会没有足够时间写测试用例，但我们也最好用XMind去梳理一遍测试点。等项目结束或有时间时，把测试用例补上是最好的。切记：一定要梳理测试点，以免上线出现漏测等问题。
测试用例究竟是什么？而我们要怎么写呢？
1、首先来看看它的官方定义：是为项目需求而编制的一组 测试输入、执行条件以及预期结果，以使某个程序是否满足客户需求。
其实测试用例的本质就是为每个测试点的进行数据设计和步骤设计。
2、8大要素组成部分
1.用例编号
注释：产品名--测试阶段（it--集成测试阶段、st--系统测试、uat--验收测试）
2.测试项目
注释：对应一个功能模块（细分功能）--子项目
3.测试标题
注释：直接对测试点进行细化得出，输入内容 结果，同一功能模块标题不能重复（来自测试点），建议一行写一个测试点，细致，数量越多
4.重要级别
注释：高--核心功能，中--次要，异常，低--界面、不常用场景（或者：high、medium、low）（或者：P1 P2 ... 冒烟测试P1，回归测试P1,P2---可以依据P1、P2作为测试策略）
5.预置条件
注释：需要满足一些前提条件，否则无法执行--不必须
6.测试输入（即数据）
注释：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）
7.操作步骤
注释：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
8.预期结果
注释：根据预期输出比对实际结果，来判断被测对象是否符合需求。--预期结果是唯一的不能出现是否
9.实际结果
我在工作中测试用例主要写：测试项目、测试标题、测试输入（数据）、操 作步骤、预期结果。
想到一个问题，也是大多数人都遇到过的问题，那就是遇到隐形需求如何写用例（需求不明确）?
我认为：根据经验对比同类型产品去充分了解产品；参考成熟产品；跟产品进行确认
关于用例评审
测试用例写完后，会进行用例评审。
评审过程是：首先，测试负责人会发起测试组评审会议，邀请测试组成员进行用例审核，看是否有修改的地方，若不通过，测试负责人修改用例，发起组内评审；若通过，测试负责人会发起项目组评审会议，同样上述步骤。最后用例归档，结束。
可能有小伙伴问用例需要评审吗？
紧急情况用例也需要评审吗？
我的回答是：yes～不然上线出问题谁来责任
首先正常情况下都是需要评审的；紧急情况下会简单的做一下内部评审，发给相应人员（可以是自己的组长、开发、产品）看下，有意见就说，没有意见就一边测试一边完善测试用例。
好啦，今天就说这么多，如果有问题欢迎你的留言，大田希望和大家共同成长～～～
Tester大田
2022.02.07 ，日更的 2/365 天
感谢支持，多多交流
