什么是测试用例
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式。同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。
通俗的讲：就是把整个测试流程的操作步骤用按照一定的格式用文字描述出来。
为什么要写测试用例
*测试 用例 是测试执行的指导；是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；是团队内部交流以及交叉测试的依据，便于测试 工作 的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；在测试执行工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。
1、理清思路，避免遗漏测试点
理清思路是我们认为最重要的一点，有的系统本来就是一个大而复杂的项目，我们需要把项目功能细分，根据每一个功能通过编写用例的方式来整理我们测试系统的思路，避免遗漏掉要测试的功能点。
2、跟踪测试进度进展
通过编写测试用例，执行测试用例，我们可以很清楚的知道我们的测试进度，方便跟踪我们的测试进度。
3、回归测试
首先我们的系统不是测一遍就完了的，我们需要在开发环境上测试，测试环境上还要进行回归，其次还有可能涉及到合并测试，而且也有可能会有不同的人在不同的阶段进行测试，那么我们就需要测试用例来规范和指导我们的测试行为。
4、历史参考
在我们所做项目的各个版本中，也许会有很多功能是相同或相近的，我们对这类功能设计了测试用例，便于以后我们遇到类似功能的时候可以做参考依据。
另外如果产品发布后出现了发布缺陷，测试用例也是分析发布后缺陷的依据之一。
一、编写用例的重要性
1. 深入了解需求的过程，一个项目立项开始，测试就开始介入，我们从产品的 PRD 文档、用户交互图，视觉图等相关文档去熟悉产品的各个模块，各个业务流程。或者在产品规划和设计阶段，测试开始熟悉产品。而编写用例的过程中，会充分的思考产品需求的细枝末节，需求的不合理、有矛盾、不明确的地方，还能对产品提出更好的建议，监督产品对需求做出更加详细的设计。整个过程是对需求深入了解的过程，产品的整个印象都在测试脑海里。
2. 测试执行的指导，用例编写是把产品需求转换为一种可操作步骤的行为，方便以后作为测试的标准，有步骤有计划的进行测试。如果没有这个标准，会使你的测试过程无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。
3. 规划测试数据的准备，在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据
4. 反应测试进度，测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试。并且通过测试用例的执行条数，大致了解该模块的测试进度。
5. 举一反三发现潜藏缺陷，测试人员在执行用例的过程中往往会突然发现当初设计的用例步骤中，还可以做这样一个操作，于是发现了 bug，这又体现了测试用例的作用，帮助发现拓展测试范围，扩大测试覆盖面，发现软件中潜藏的缺陷。
6. 分析缺陷的标准 通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
好用例的标准
- https://zhuanlan.zhihu.com/p/94993557
- https://zhuanlan.zhihu.com/p/24308453
- https://blog.csdn.net/qq_28967695/article/details/73609070
- https://yq.aliyun.com/articles/130204
- https://zhuanlan.zhihu.com/p/74623927
- https://blog.csdn.net/deyili/article/details/6640259
- https://zhuanlan.zhihu.com/p/89633142
- https://www.jianshu.com/p/d8931aa92b10
好用例的标准
- 是否可以发现 Bug
设计测试用例的目的就是为了发现 bug，如果 bug 都发现不了，怎么能称得上是一个好的测试用例呢？
- 是否够高效
一个好的测试用例应该不止测试一个测试点，从而减少需要的用例总量。但也不能包含太多不想关的测试点，否则你这个用例就没法测试了，并且给开发的 debug 造成困难。
- 是否够经济
这个测试用例执行起来是否容易，分析和 debug 是否要花太多代价，都是值得考虑的，毕竟咱也要站在组织的角度来看待测试这个事，公司是为了盈利而做这些事，而不是为了做测试而测试。
- 是否有足够的扩展性
主要是考察测试用例在维护时是否要花费很大的代价。
1、用例覆盖程度
毫无疑问，这一点应该是最重要的，无需多说，覆盖率最大化是一套测试用例的最重要评价标准，如果漏测就杯具了。
2、用例是否已经达到工作量最小化
在满足用例覆盖程度最大化的前提下，应该尽量减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的 php 逻辑，可以通过在网页上测试后，用一些工具比如 xdebug 来统计代码覆盖率；对于向外提供接口的server，采用的方式就是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。
3、用例的分类以及描述是否足够清晰
用例的分类，在这里是指相同类型的用例是否放在一起了。例如：接口类的用例，参数的取值范围是 1 -3，但是现在却传入 4；数据类用例，状态机现在位于状态 2，却要求状态跳转到无法到达的 4；逻辑类用例，正常功能的产出等。将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。
用例的描述，是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非 1 - 3 的值”，明显没有写成“传入值 4”有效。这与写程序一样，总是写闭区间的范围而不是开区间。
4、用例是否表明了测试目的
写明用例的测试目的，对文档的易于理解性和工作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。在过程中留下足够的信息，可以在后续工作提高很多效率。
5、测试用例的易于维护性
如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？例如在有状态机的情况下，测试用例之间是相互依赖的（即需要一定的执行顺序），这样被依赖的用例修改后，后端不需要同步根据修改。而如果用例之间没有相互依赖关系（如用例是自己造的数据，不是依赖于前端的产出），可能一旦有变化，就需要修改这两个。当然，这两种情况不能绝对的说哪种好，是需要看实际使用时候的情况进行取舍的。不过，通过一些系统性的工具支持，也会出现一种做法绝对性的好于另外一种的情况，情况很多，做法也有很多，在这里就不多说了。
既然测试用例的重要性可想而知，那么用例评审更加重要，用例评审即是对用例的评议和审查，是必须的过程。在工作过程中，对于测试用例的评审，分享几点自己的心得。
二、用例评审内容
- 是否覆盖测试需求上的所有功能点，不违背产品原型和代码设计，用例设计的结构安排是否清晰合理，有利于高效覆盖需求
- 用例是否具有可执行性，前提条件、执行步骤和预期结果是否正确，有明确的验证方法。优先级安排是否合理
- 是否从用户层面来设计用户使用的场景和业务流程
- 是否包含充分的异常测试用例
- 是否简洁，不冗余，复用性强
四、用例评审需要避免
- 测试点含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该确认下来，不能含糊不清。
- 杂乱无章的评审，有顺序有逻辑的进行评审是很重要的一点，如果臆想按照自己的思路评审，不顾他人感受，那么就等同于做无用功。这样的用例执行出来也会有一定的质量风险。
好的测试用例编写的原则：最低的成本找到最多的问题，最短的路径验证最多的可能
大概有这几种风格：
- 精简型（每个 title 和标题内容都基本用一个词语概括了你需要测试的点，起点拨作用）
- PRD 型（把 PRD 阐述了一遍的样子，内容特别冗余，但是对于开发和产品而言可读性较强，不过不被提倡）
- 操作步骤型（在 TC 中把自己测试这个系统的操作步骤一步一步的详细写出来，以及所需要造的测试数据和异常步骤。但是这种对于开发只查看部分功能点的 TC 可读性可操作性较低，对于写作者本身实用性较高，但是后期一旦业务逻辑修改，需要修改的内容较多）
TC 是测试基础，也是最反映一个测试的思维逻辑和测试思想的地方。
以下 5 点可以判断测试用例是不是一个好的测试用例
1、测试覆盖面全
覆盖面全，是最最重要的一点，只有全面的覆盖，才能找到最多的问题，只有更全面的测试，才能更好的保障产品的质量，当然穷尽测试是不可能的，所有全面也是相对的。
2、测试用例精简
精简的 case，是为了减少重复的工作，减少人工成本和时间成功，通过 TC 设计策略了解和对于需求的充分了解，达到精简测试用例。
3、步骤清晰
步骤清晰，主要是为了提高 TC 的复用型，无论是对于开发还是对于后期的自己都可以看到 TC 一目了然
4、目的明确
冗长的步骤前，用几个字概括你的测试目的，方便阅读
5、易于维护
易于维护，分为以下几种维护：
易于他人维护修改
易于系统升级维护修改
易于挑选不同纬度，不同优先级，不同功能的测试用例
结构清晰、优先级明确、描写清晰的测试用例更容易维护
想写好测试用例，前提是测试分析和需求拆解做的足够好，通过 xmind 或者 UML 图把需求和开发设计提供的产品信息提炼出来。
我个人的提炼标准一般是：
- 所有业务链路是否是闭环；
- 所有业务场景以用户层面来观察是否合情合理；
- 技术设计是否存在性能 / 可靠 / 安全等风险；
- 梳理测试要点，明确每个业务在测试环节里面需要观察的功能预期；
- 开始明确测试方案，确认列出来的测试要点要怎么样才能实施测试。这里多问自己一句：只做功能测试能满足质量覆盖的要求吗？不能就扩展考虑是否做白盒测试 / 接口测试 / 性能测试 / 稳定性测试 / 安全测试 / 体验测试 /…；
- 然后才进入测试用例编写的阶段，通过对测试点的特征评估考虑用哪种测试用例设计方法覆盖；
- 最后输出用例。
在这里, 我想说说我对用例的个人看法：
- 用例不仅仅只是为了满足功能测试，它应该是通过一组输入输出的方式用来衡量产品功能是否符合预期。
- 测试用例不可能永远只被设计者执行，所以请严格按照规范来设计和编写用例，让其他后继的执行人能高效准确的执行。
- 用例设计是极其严肃的任务，但是业内很少 QA 会真正的做到根据被测试对象的特征来挑选测试用例设计方法并严格按照这些方法来输出用例。
如何编写好的用例
三、用例评审过程
1. 提前发出初稿和会议邀约，至少提前一天发出用例初稿，并确定参与用例评审人员，以便项目经理，产品和开发提前阅读用例，让会议更有效率的进行
2. 先做简单的业务流程介绍，这个是在评审开始尤为重要的一个过程，刚开始评审，参与人员会比较蒙圈，产品和开发都不知道测试的思路，或者半途加入新的开发和测试，对需求和业务都不够熟悉，如何让评审快速进入状态，先做简单的需求业务流程介绍，说明白打算如何去做评审。
【举个栗子】一个项目有用户体系、电子账户、理财、生活模块，可以先由大到小的细分下去；可用事先画好的脑图，各种流程图，也可当场快速写上板书。
3. 按模块进行，有些模块，业务性不是特别强的，可以简单说下有哪些模块，每个模块评审的时候，按测试项分类，UI、核心功能、基础功能、边界测试、兼容测试和异常测试等，预期结果类似的，主要讲清楚用例主题，让参与人员知道每条用例是做什么的。
4. 按业务流程进行，业务流程性较强的需求，需要有业务场景和逻辑，按一定的顺序来，让参与人跟着你的思想，避免东一句西一句，
【举个栗子】一个理财活期产品的测试用例评审，购买和赎回，跑批时间段分日间和日终，工作日和周末四个场景，按不同场景分为不同的业务流程进行评审，有理有据，逻辑思路清晰。
5. 按测试数据进行，涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据也是按不同的业务场景来设计的，但直接用测试数据来评审你的测试点，会更清晰，跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方，从而有效的评审测试用例。
三、用例评审后的确认
为了节约时间成本，第一次评审尽量对用例设计全面考虑，提前发现其中的不足之处；但是第一次评审难免会要修修补补的地方，在评审时尽快的修复，不能在一两分钟修复的，记录下来，在会议结束后进行修改，如果改动不是很多的，可以发出邮件，标明修改部分，再最后确认最终版。如果需要进行二次评审，那么重新开始邀约会议做二次评审。
四、关于提升用例编写能力的一些建议
- 熟悉业务，了解系统
任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。
任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题、业务问题。
- 学会换位思考，用客观的思考方式站在用户的角度分析问题
作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么，以及客户不想要什么，也就是所谓的客户的使用场景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户基本不会用到的场景有哪些。
- 多思考，不要拘束于惯性思维
一个人做一个工作时间越久，经验大概率是会越来越丰富的，但同时，也可能被自己的经验所限制。习惯性的套用经验，活在自己的舒适区，会让自己的成长停滞不前。所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要被惯性思维束缚，不要被所谓的经验束缚。
- 学会利用好网络资源提升自己的能力
提升测试用例设计能力，多思考是非常重要的，但不是让你傻思考。当你的进步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学习一些前辈的经验，并把这些运用到实际的测试用例设计中去。山外青山楼外楼，多浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的测试用例设计能力的提升会有很大的帮助的。
- 善于总结和分享
基于以上四点我们还要做到善于总结，乐于分享，把常见到的用例设计的误区和一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，不断提升我们的用例设计能力。
1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。
2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
3、尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。
4、要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。
5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。
6、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多 BUG 只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。
7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个操作步骤。比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。
8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库 相关字段的记录、界面的响应结果、输出结果的规则符合度、日志 的检查和对 其它 业务影响的检查。
9、测试用例级别要划分清楚，这样在测试执行时有主次之分。
10、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。
11、评审用例很关键，因为经过测试用例的评审可以发现：用例设计 的结构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。
12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。
13、站在用户的角度来设计用例，以用户的使用逻辑及操作习惯为出发点，从用户实际可能的操作场景考虑，一定要脱离系统提供功能。
14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在 软件开发 的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例。
总的来说，写出好的测试用例需要我们不断的积累和完善，需要我们不断的在工作中去总结。写出好的测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。
三、如何编写用例
1、测试需求分析，得到测试点
在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：了解需求的整个实现背景、分析需求的合理性、明确需求的范围、挖掘需求文档中隐藏的需求。
在通过需求交底的过程，确定开发的初步实现思路和方法。随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等，确定一些测试可以提前介入的工作需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。
2、分析得到用例优先级
得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优等级，一般分为高中低三个优先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。
3、细化测试点变成可执行 case
根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。
在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
另外需要考虑的就是测试点细化到什么程度的问题，也就是一个度的问题，我们要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易让我们纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。
4、及时更新测试用例
需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的，所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。
另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试 case 描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。
5、及时维护通用测试用例
什么是通用测试用例呢？我理解的通用测试用例就是：项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。所以说，通用的测试用例是一个对用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试用例，对后面的测试和用例维护有一个很大的指导作用。
