测试用例是一套有计划，有规律，有明确目的的数据集，以一条或一组出现，用于检验某程序功能是否符合预期要求（达到客户需求），并且以此记录测试的进度和覆盖度，以可控的方式来完成对被测软件或硬件的可交付要求评估。

关于这个问题，可以反过来先想想如果没有用例会怎么样？ 不知道测什么内容，不知道怎么测，不知道测到哪儿了，不知道覆盖度怎么样，不知道风险怎么样，不知道产出了什么，等等。想过这些问题其实你已经知道为什么需要测试用例了。
以下例举几个重要的原因：
1、用例用于实现对被测内容的梳理，完成对测试范围、质量标准的数据化定义；
2、用例用于记录执行过程测试结果，分析覆盖度和进度，评估测试结果，为产品质量提供数据参考和支撑；
3、用例用于持续改进和知识库积累，帮助团队从无到有积累经验，持续改进不足，完成对同业务及扩展业务的经验积累及持续优化，为扩展业务和团队可持续发展奠定基础。

关于这个问题，可以反过来先想想你觉得不好的用例是什么样的，你希望的用例是怎么样的？不统一的格式，口语化的描述，操作和结果不对应、不具象的文字说明，等等。
以下例举几个重要标准：
1、用例需要统一标准格式，同一个业务团队需要保持一致的风格，内部流转的时候能直接使用，以便实现工业化生产；
2、用例需要统一文字描述，不能出现口语化、地方化的描述，文化差异和地域差异是需要解决的核心冲突；
3、用例需要操作结果一一对应，做到操作和结果的检查是一对一的，实际情况下会出现一对多的情况，需要特别说明。
4、用例需要具象化的操作和结果，不能出现如：“点击按钮A/响应正确”这种不具象的描述，因为换人执行很可能不知道什么是正确什么是错误。

用例标准主要是为了能统一风格，提升能效，交付他人可执行，快速迁移和可持续积累，为建立公共用例库做准备。

百度：
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。

个人理解：
黑盒就是看结果表现不看具体内部实现过程。打个比方，游戏中你点个按钮，你只需要知道点了它会有什么反应（比如买卖东西、打开某界面等），不需要知道它发送了什么数据内容，存储了什么数据，消息怎么交互，时序怎么样，怎么加密等。。。

从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。

等价类划分的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒测试用例设计方法。

1.1 划分等价类

1） 划分等价类：
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类。
有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类：与有效等价类的定义恰巧相反。
设计测试用例时，要同时考虑这两种等价类.因为，软件不仅要能接收合理的数据，也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。

2）划分等价类的方法：下面给出六条确定等价类的原则。
①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

3）设计测试用例：在确立了等价类后，可建立等价类表，列出所有划分出的等价类：

1.2 输入条件

输入条件 有效等价类 无效等价类
然后从划分出的等价类中按以下三个原则设计测试用例：
①为每一个等价类规定一个唯一的编号。
②设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步.直到所有的有效等价类都被覆盖为止。
③设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步.直到所有的无效等价类都被覆盖为止。

个人理解
等价类：1有效等价类；2无效等价类
简单说，等价类就分为符合规则和不符合规则2大类，2大类再细化分为满足大类中某小类，并组合循环至每个最小类。所有情况依次列出，就是最终所需等价类列表。

常见情况实例：
a.数量/长度：
密码长度限制6-20。（类似的购买数量次数、扫荡次数、格子数量等等）
有效等价类：6-20位；（6,7,8…）
无效等价类：小于6位（空，1,2…）；大于20位（21,22,23…）

b. 输入类：
可输入英文（小类1），字符（小类2），数字（小类3）
有效等价类（大类1）：（输入英文、字符、数字）
英文；字符；数字；英文+字符；英文+数字；字符+数字；英文+字符+数字；
无效等价类（大类2）：（输入非英文、字符、数字）
中文（小类1）

c.范围时间类：
1活动在19:00-20:00开启（类似的某个时间重置刷新数据，输入日期格式限制等等）
有效等价类：19:00-20:00活动开启
无效等价类：19:00之前活动不开启；20:00之后活动不开启

d.日期格式类：xx-xx-xx（00-01-01）
有效等价类：xx-xx-xx（01-01-01）
无效等价类：xxxx-xx-xx（2001-01-01）；xxxxxx（010101）；xxxxxxxx（20010101）；

e. 同类型类：
如穿戴不同性别装备（类似如：穿戴位置，道具类型，buff效果等等）
有效等价类：穿戴所属性别装备、使用同类型道具、叠加同类型buff
无效等价类：穿戴非所属性别装备、使用非同类型道具、叠加非同类型buff

f. 逻辑类：
如常规流程和非常规流程，更改实现逻辑，如改购买请求为出售请求，这个可能涉及更改实现代码（协议安全相关，暂不考虑）
有效等价类：正常购买时购买请求
无效等价类：更改购买为出售请求
其他待补充。

边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。

2.1 边界值划分
（1）边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

（2）基于边界值分析方法选择测试用例的原则：
1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2）如果输入条件规定了值的个数，则用最大个数,最小个数，比最小个数少一，比最大个数多一的数作为测试数据。
3）根据规格说明的每个输出条件，使用前面的原则1）。
4）根据规格说明的每个输出条件，应用前面的原则2）。
5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
7）分析规格说明，找出其它可能的边界条件。

个人理解
边界值：基于极限情况的考虑，一般结合等价类使用，可极大减少测试用例数，提高测试效率。

常见情况实例：
a. 数量限制类：如密码长度限制6-20。（类似的购买数量次数、扫荡次数、格子数量等等）
测试数据为：临界及其±1：6，5，7，20，19，21

b. 日期时间类：如闰年，非闰年有无2.29这天（开启时间，刷新时间等等）
测试数据为：输入2.28，2.29，2.30，根据是否闰年，判定输入是否正确
如世界boss在18：00出现，18:30消失：
理论测试数据为：17:59:59查看是否刷新世界boss，18:00:00查看是否刷新世界boss，18:29:59查看世界boss是否消失，18:30:01查看世界boss是否消失。（实际可根据情况，一般调整时间至前后10s左右自然过渡）

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。 考虑输入条件之间的相互组合，可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）。
因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
3.1 生成测试用例
(1) 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
(2) 分析软件规格说明描述中的语义。找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出因果图。
(3) 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现. 为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。
(4) 把因果图转换为判定表。
(5) 把判定表的每一列拿出来作为依据，设计测试用例。
从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。
前面因果图方法中已经用到了判定表。判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

判定表组成法：
条件桩（Condition Stub）：列出了问题的所有条件.通常认为列出的条件的次序无关紧要。
动作桩（Action Stub）：列出了问题规定可能采取的操作.这些操作的排列顺序没有约束。
条件项（Condition Entry）：列出针对它左列条件的取值.在所有可能情况下的真假值。
动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
规则：任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。
判定表的建立步骤
①确定规则的个数。假如有n个条件.每个条件有两个取值（0,1），故有2n种规则。
②列出所有的条件桩和动作桩。
③填入条件项。
④填入动作项.等到初始判定表。
⑤简化.合并相似规则（相同动作）。
B. Beizer 指出了适合使用判定表设计测试用例的条件：
①规格说明以判定表形式给出，或很容易转换成判定表。
②条件的排列顺序不会也不影响执行哪些操作。
③规则的排列顺序不会也不影响执行哪些操作。
④每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
⑤如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
正交试验设计
就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。

个人理解
关于因果图、判定表、正交实验，一般混着用，以下内容仅为个人认知，仅供参考。其使用场景大多适用于多输入、多条件情况下，选取特征组合，减少用例数且保证测试覆盖度，提升效率但又保证测试质量的方法。该方法也有一个缺点是把所有因子等权重进行正交分析，如果因子有权重差异则该方法不一定适用，看情况使用。该方法在多条件组合的时候手工分析实现相对难度较大（正交表选取方案有一篇参考公式，可单独搜索），可以借助工具如PICT（一个用例生成工具，具体用法可自行百度）等，可有效完成该方法相关的测试用例设计。该工具相关使用方法在之后工具介绍中再补充介绍。

常见情况实例：
例1，可以从2个入口，购买2种特殊道具，有金币足和不足2种情况：
（因子1）游戏道具：（因子状态）B1、B2
（因子2）购买入口：（因子状态）A1、A2
（因子3）金币：（因子状态） 足（Y）、不足（N）

如果按理论设计用例数为： 2x2x2 = 8
正交实验的结果是：3 x（2-1）+1 = 4

例2，因子状态数量不一致时，

如果按理论设计用例数为：3x4x2x2 = 48

正交实验可选方案为（用例数3*4=12，但实际状态组合需要优化）：

方案讨论（思考理解）：
上述方案是最基本的组合，满足最重要的规则，就是每列的因子状态数出现次数一定是相同的，所以因子状态以组为单位循环出现，但上述因子状态的选取还缺乏考虑循环规则。上述的组合问题是对于后面3种因子状态循环规则是固定的，即6副/开启/是、8副/不开启/否。这样其实后3种因子状态组合相当于只有1种，所以我们实际选取时需要对因子状态进行适当的循环规则，如把副数的循环规则改为：第1轮6/8/10/12，第2轮循环改成8/10/12/6，第3轮10/12/6/8，第4轮12/6/8/10。其他因子类似，这样就能更好的实现不同状态组合覆盖。

建议：
实际工作中，一般把最常用的因子放前面，且因子的选取不是固定的，生产的用例数也不一样，一般考虑最常用，状态最多的，不常用的因子看情况匹配对应上同时控制循环组合。甚至也不需要考虑一定按正交实验组合提取用例，在正交实验提取用例基础上额外增加想要的组合也是有可能的。

错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法.
错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。 例如，在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

个人理解
基于一定经验积累的可能性推测，实际工作中很实用，一旦发现问题需详细找出类似功能，甚至流程上的检查。经验来源很多，多了解同类型游戏，同功能模块，不同平台等等情况下容易出错的地方，多积累就能积累经验。

常见情况举例：
a. 流程相关
或许在比较完善的体系中不存在该问题，但很多中小团队有可能存在这样的问题，一方面流程不规范，同时也跟团队人员性格等等有关系。稍微有点繁琐。
比如：某些同事经常不检查就提交资源，然后打包打出来的包各种配置错误，代码不对，那么此时开始测试，发现各种问题，检查后发现是配置或者提交不对等等非技术原因，浪费时间，极大降低效率。如果多次如此，你肯定就知道提前提醒相关人员各个环节要做监控和检查。

b. 功能相关
如：
输入类：1.某个功能内输入框没有做限制，其他功能的输入框是否如此？；
调用类：2.某个功能调用某方法时报错，其他功能调用该方法是否报错？；
刷新类：3.当某个地方数据没有及时刷新，其他功能数据是否及时刷新？；
UI类：4.某界面按钮快速点击多次弹出多个对话框，其他界面按钮是否如此？；
其他特别：硬件相关，存储方式相关，系统平台相关等
（其他待补充…）

软件几乎都是用事件触发来控制流程的，事件触发的情景基本流和备选流便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

基本流和备选流：如下图所示，

图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

个人理解
所谓场景，个人看来是某一组操作集的完整过程，简单理解就是某一种可能的操作过程。软件（游戏）基本上都是消息驱动（或事件触发）的，所以任何1个操作都会触发对应的响应，不同的操作方式，就形成了不同的反应组合，意味着形成了不同的可能情况，就是不同的场景。是对某个功能不同可能操作的测试，也是对功能流程逻辑的测试。
如：购买商品
基本流：选中购买-确认付费-购买成功
备选流1：货币不够-结束购买
备选流2（1的基础上）：货币不够-充值
基本流是基本流程，备选流在基本流程外触发或产生，可以直接结束，可以继续往其他备选流走，也可以回到基本流或结束当前备选流。跟系统的设计和复杂度有关系。

作为测试工程师，需要理解掌握各方法的原理，不断积累测试经验，综合使用上述方法，提高测试效率及测试覆盖度；
设计用例基本思路：
1、首先等价类划分，减少测试工作量，输入条件和输出条件都可以等价类划分；
2、任何时候都会用到边界值分析，发现bug最多的方法；
3、错误推测法可以补充一些测试用例；
4、检查逻辑是否覆盖完全，适当补充测试用例；
5、如果条件有组合情况，从一开始就使用因果图法和判定表法；
6、参数配置类软件，用正交试验法，减少组合方式。
7、功能图法也是很好的方法，不同时间条件的有效性设计不同的测试数据。
8、业务清晰的系统，可以利用场景法贯穿整个测试案例过程，再综合使用上述方法。

有了上述学习，我们了解掌握了用例设计的常见方法，学会了基础"武功招式"，但我们要成为真正的武学宗师，不止学招式，还得学内功，以内功驱动招式才能无往不利。接下来的部分将是练内功的部分，在实际工作种需要特别注意。

测试用例是基于交付产品的需求而写的，简单理解就是基于产品需求写的。所以编写任何测试用例的前提条件是需求，在写之前一定要深入理解需求，在不知道明确需求的情况下不要编写详细测试用例（这里仅讨论正常流程，不规范团队下的处理后续分享内容讨论）。
如何更好的理解需求，提高用例有效性，建议从几个点出发，
1、用户场景，我们的产品为了解决什么问题而设计，解决的关键问题是什么，只有理解好了用户的需求，我们才能更好的站在用户的角度去思考，去评估产品是否满提供了极致的用户体验；（该部分更多适用于固定业务，如银行、金融、医疗等领域）
2、团队场景，更多时候我们往往是在新设计（游戏就是不断创新），需求来源于产品。
1）需求评审，尽量要有需求评审过程，需要核心人员参与技术和业务评估，以确定当前需求满足团队期望，通过需求评审后，开始编码阶段编写用例变更风险降低。2）需求风险评估，由于需求变更频繁非常常见，建议根据需求评估变更风险。有意控制用例的粒度，对成熟稳定的（做过的、市面有成熟解决方案）足够细，对变更风险高（新设计的、待验证的）的粒度粗，持续细化。
3）研发实现方案，需求最终实现都是研发人员完成的，所以跟研发人员沟通实现方案，能更全面直接的帮助你理解细节；
4）沟通，建立有效的信息沟通机制，特别是需求变化的时候要及时同步相关人员，并确认知晓。关于沟通后期分享会单独详细解读。

需求变更的时候需要及时维护（增加，修改，删除）测试用例，以保证新的测试用例能够检验新需求，同时保证实时性，没有因维护滞后而影响测试工作。测试过程中，也经常会发现测试用例不完善或可精简，也需及时维护测试用例。
实际工作中，往往没有足够的时间去编写较完善的测试用例，各个公司的规范不一样，也决定了实际应对的不同。

1）格式：用例常见写成excel，但实际情况下，可以变换形式，如时间不足的情况下，可以不编写测试用例，但一定要整理测试点，可以是excel，也可以是xmind等，待时间充足时再补充完成测试用例。
2）记录：一般情况下，所有用例变更和执行都要记录，以此保证可跟踪到需求变化、测试的进度和覆盖度，以保证用例可使用，可跟踪测试进度。如果需要通过用例记录过程数据，还需要制定用例修改记录标准，如记录修改时间、原因，变更内容等信息。
3）存档：用例、用例执行情况均需要归档，一般情况下存储在公共项目各自路径下，常见目录结构：xx项目-xx版本-用例，用例可分为各模块/各用途/执行记录/变更记录等，根据情况自定义。

我们在项目不同的阶段，可根据情况编写不同粒度的用例，以满足不同的需求。如：自测、冒烟、回归、详细测试

自测：粒度粗，符合主流程或研发帮助测试，自测用例包含主流程、核心功能，或需要研发协助修改逻辑或数据测试等时候用，主要交给产品/研发等人员使用，需要与产品研发人员沟通以符合使用人的习惯；

冒烟：粒度粗，检测主流程和核心功能，用于详细测试前的基本评估，防止存在重大问题进测浪费团队测试资源；

回归：粒度中等，检查问题修复及相关功能，或交付前checklist，用于验证问题修复或确认检查内容；

详细测试：粒度细，即常规意义的用例。

测试思路决定了测试用例的写法，通过测试用例可以看出一个人的测试思路。测试用例应当简洁高效、覆盖率高、复用性高。

1、从方向上，一般采用：由点及面，由面及点结合的方式
如测试某个功能，测试思路一般有2种，
第1种（由面及点，初期不建议使用）：入口进入，先检查所有相关界面UI，字体等资源，每个界面只管所有功能可正常跳转到下一级界面，层层深入，直到最底层
第2种（由点及面）：入口进入，检查某单个功能相关资源，各资源再触发新的界面或功能，直到该功能相关测试完成，再对其他功能进行测试，直到所有功能完成测试

2、从执行上，测试过程可分为：操作前、操作中、操作后
所有的测试过程都可以套进来，用例其实就是对操作前中后的具象化表现的测试，用例在设计时也可以参考前中后过程来进行。

3、从效率上，考虑测试顺序
举个例子，我们要测试：增加商品、删除商品、查找商品、修改商品。
顺序1：如果按照增删查改的顺序，我们的测试用例应该是：创建、创建删除、创建查询、创建修改
顺序2：如果按照增查改删的顺序，我们的测试用例应该是：创建、查找、修改、查找、删除
我们对比下这2种顺序会发现，顺序2明显优于顺序1，顺序1最少需要创建3个商品才能完成，但顺序2只需要创建1个商品，就能完成整个测试。
这是最常见的情况，所以有意控制执行顺序能极大提升执行效率，需要我们结合实际情况去具体分析控制。

4、从粒度上，考虑阶段和作用
我们在项目不同的阶段，可根据情况编写不同粒度的用例，以满足不同的需求。如：自测、冒烟、回归、详细测试
自测：研发中、研发完成；
冒烟：版本提测；
回归：版本补丁或版本发布前；
详细测试：测试阶段。

每个公司，每个人编写测试用例的格式是不同的，不同的人有不同的思维方式，编写测试用例时，只要符合自身特点，满足测试标准就行。当然在团队合作模式下，需要保持统一。

一般情况下，测试用例包含属性有：
用例编号 ，用例编号用于标记，方便后续查找；
功能模块 ，测试模块，标记模块位置，可根据需求拆分多级，建议稳定3级；
测试点 ，对功能模块的补充，测试思维的具体表现，建议初期写用例可使用该字段帮助你梳理大的方向；
前置条件 ，测试需要的前期准备或前置必备条件；
预期操作（输入） ，测试的操作过程，可以组合一组操作但和结果必须一一对应；
预期结果（输出） ，测试操作的预期结果，和操作必须一一对应；
实际结果 ，测试操作的实际结果，和操作必须一一对应；
备注说明 ，对测试用例的补充说明，可用于记录一些特殊情况或易错的经验教训；

如果要通过其进行部分管理工作，可加入 测试类型 ， 测试时间（可分多轮） ， 测试人员 等属性

以下是搜集各路测试牛人的测试用例截图（均在excel下，仅供参考，未经许可不可转载内容信息）：
格式1：

格式2：

格式3：

格式4：

以上可借鉴和吸收，形成自己的基本格式。

本次分享内容从核心内容上介绍了常见的用例设计方法、常用的用例格式，额外解读了用例的作用、维护、设计思路。
通过这些内容，我们将掌握用例设计的方法，用例编写的基本技巧，理解测试用例的意义。

在教练U的分享培训下，你很好的完成了测试用例的学习。恭喜你，突破了职业生涯中第1个小难点，在成为测试专家的路上踏出了坚实的一步，让我们期待下一阶段吧。