背景
为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。
目的
为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理
测试用例设计原则
系统性
对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系
连贯性
对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯
全面性
应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备
正确性
输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合
容错性
程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
可操作性
测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果
测试用例设计步骤
测试需求分析
从软件需求分析文档中，找出待测软件/模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点
业务流程分析
对所在行业的业务知识要熟悉，然后对被测软件/模块的业务流程要进行全盘的整理出来（可画简单的流程图作为参考），主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件
测试用例设计
测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况
测试用例评审
由测试用例设计者发起，参加的人员需包括测试负责人、产品经理、项目经理、开发人员及其他相关的测试人员
测试用例完善
测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善
测试用例设计方法
等价类划分法
将所有可能的输入数据（有效的和无效的）划分成若干个等价类
确定等价类的原则
1.如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类
2.如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，此时可确立一个有效等价类和一个无效等价类
3.如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类
4.如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合
5.如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则）
6.如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。
测试用例的选择原则
1.为每一个等价类规定一个唯一的编号，即写一个单独的测试用例
2.设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直至所有的有效等价类都被覆盖过
3.设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直至所有的无效等价类都被覆盖为止
边界值分析法
确定边界值的原则
刚好等于、稍小于和稍大于和刚刚大于等价类边界值，针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取
测试用例的选择原则
1.如果输入了条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个边界范围的值作为测试输入数据
2.如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据
3.根据规格说明的每个输出条件，使用前面的原则
4.如果程序的规格说明给出的输入输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用列
5.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例
6.分析规格说明，找出其他可能的边界条件
错误推测法
主要基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法（参照以往的软件系统出现错误之处）。测试用例设计基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如：输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。
因果图法
是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
测试用例优先级
用例的重要级别一般分为4个等级：核心（P0）、高（P1）、中（P2）、低（P3）
P0:确定此版本是否可测的测试用例，如fail会阻碍大部分其他测试用例的验证，一般用于冒烟测试
P1:确保系统基本功能，以及重要的错误、边界的测试用例，最常执行以保证功能性是稳定的，一般用于验收测试
P2:确保系统功能的完善方面的测试用例，更全面地验证功能的各个方面，包括异常、边界、中断、断网、容错、UI等测试，一般用于回归测试
P3:不常被执行的测试用例，一般包括用户体验的优化、性能、压力、兼容性、稳定性、安全性、可用性等测试
测试用例编写内容
1.一级模块：对应产品线名称，如礼品卡小程序、OPS管理系统等
2.二级模块：对应产品线下的大功能模块，如礼品卡小程序里的主题、品牌、我的等，二级模块也是测试用例group
3.用例标题：对测试项简短的描述
4.用例级别：确定用例执行的级别，P0、P1、P2或P3
5.预置条件：执行用例时需要的预置条件
6.操作步骤：执行该动作需要完成的操作
7.预期结果：执行完该动作后程序的表现结果
8.验证结果：该测试用例是否执行通过，一般分通过、部分通过和不通过三种结果
9.BUG编号：对不通过的用例，需填写禅道中对应此用例的BUG编号
10.测试执行者：按照该用例执行测试的人员
11.备注：如有则填写相应的备注信息