一. 针对没有需求的案例来设计测试用例
针对没有需求的案例，我们可以从如下几个方面思考来设计测试用例
功能测试 + 界面测试 + 性能测试 + 安全测试 + 兼容性测试 + 易用性测试
案例一：针对一个水杯来设计测试用例
案例二：针对一个登陆系统来设计测试用例
二. 针对有需求的案例来设计测试用例
大概设计思路如下：
需求分析
概括出需求有哪些功能
设计测试点
设计测试用例
1. 穷举法
假如说给定的软件需求是：提示姓名长度为6~15位。
测试时数据我们设定为6、7、8 … 14、15，这样通过穷举法来设计测试用例，若测试用例通过，则认为功能符合需求要求。
假如说，给定的长度不是6~15位，而是6 ~ 500位，这时应该如何设计测试用例呢？这样测试用例通过穷举法肯定是不现实的。
2. 等价类
概念：针对需求把输入范围内的所有测试用例划分成若干个等价类，从其中一个等价类里取出一个用例，若该测试用例测试通过，则认为该测试用例所在的等价类通过。
等价类的核心是对测试数据进行分区分块，使用较少的测试用例达到符合的系统测试覆盖率。
等价类又划分成有效等价类和无效等价类：
有效等价类：针对需求来说是有效且有意义的数据构成的集合。
无效等价类：针对需求来说是无效且没有意义的数据构成的集合。
根据等价类划分测试用例的步骤：
确定有效等价类和无效等价类
编写测试用例
举例
需求：姓名可输入6~200位的字符，应该如何来设计测试用例呢？
第一步：确定有效等价类和无效等价类
有效等价类：6~200
无效等价类：小于6大于200
PS：其实在设计时还需要发散性的根据需求考虑更多情况，比如还可以针对字符的类型（数字、字符串、特殊字符）来设计有效等价类和无效等价类，这里只是简单的举例，只考虑长度。
第二步：编写测试用例
3. 边界值
边界值法通常是对等价类的补充。注意设计边界值测试用例时需要加上：边界值 + 次边界值
还是继续用等价类的例子，这次我们补充上边界值的测试用例：
4. 判定表法
判定表法的核心是要考虑输入输出之间的组合关系，根据这个这个关系画出判定表然后设计测试用例。
判定表设计测试用例的步骤：
确定输入条件和输出条件
找出输入条件和输出条件之间的关系
画判定表
根据判定表编写测试用例
举例
需求：订单已提交，且订单总金额大于300元或订单有红包，则认为该订单属于有优惠的订单，否则属于没有优惠的订单。
step1：确定输入条件和输出条件
输入条件：金额大于300元、有红包、订单已提交
输出条件：有优惠、无优惠
step2：找出输入条件和输出条件之间的关系
step3：画判定表
step4：根据判定表来编写测试用例
金额大于300元，没有红包，没有提交订单，结果为无优惠
金额不大于300元，有红包，没有提交订单，结果为无优惠
金额不大于300元，没有红包，提交了订单，结果为无优惠
金额大于300元，有红包，没有提交订单，结果为无优惠
金额大于300元，没有红包，提交了订单，结果为有优惠
金额不大于300元，有红包，提交了订单，结果为有优惠
金额大于300元，有红包，提交了订单，结果为有优惠
金额不大于300元，没有红包，没有提交订单，结果为无优惠
5. 场景设计法
5.1 简介
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
5.2 基本设计步骤
根据说明，描述出程序的基本流以及各项备选流
根据基本流和各项备选流生成不同的场景
对每一个场景生成相应的测试用例
对生成的所有测试用例重新复审，去掉多余的测试用例
测试用例确定后，对每一个测试用例确定测试数据值
5.3 基本流和备选流
基本流：也叫有效流或正确流，模拟用户正确的业务操作流程。
备选流：也叫无效流或错误流，模拟用户错误的业务操作流程。
5.4 使用场景
主要用来测试软件的业务逻辑和业务流程。一般先采用等价类划分、边界值分析、错误推断法、因果图及判定表法等对单点功能进行验证，验证通过后再采用场景法进行业务流程的验证。
5.5 优缺点
优点：涉及到业务场景，使用场景法有利于测试设计者设计测试用例，使测试用例更容易理解和执行。
缺点：只验证业务流程，不验证单点功能。
5.6 实例
场景介绍
用户进入网上购物系统网站进行购物，选好物品后进行购买。
这时需要使用账号登录，登录成功后付款，交易成功后生成订单，完成此次购物活动。
第一步：分析需求，确定基本流和备选流事件
第二步：根据基本流和备选流来确定场景
第三步：设计用例
第四步：设计测试用例中所需的数据
6. 错误猜测法
错误猜测法是基于对被测试软件设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而去针对性地设计测试用例。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
以注册为例，我们可以对这个场景直接进行错误猜测，从而设计测试用例：
校验中特殊字符空格的处理？
密码校验中的大小写？
姓名中的特殊字符？
密码发送是否明文？
