作者：~小明学编程
文章专栏：测试开发
格言：热爱编程的，终将被编程所厚爱。
目录
测试用例的设计方法
等价类
边界值
错误猜测法
判定表法（使用于关系组合）
设计步骤
具体例子
正交法
场景设计法
测试方法
黑盒测试
白盒测试
灰盒测试
常见的测试方法有哪些？哪种测试方法用的最多？
水杯的测试用例
功能性测试
界面测试
性能测试
兼容性测试
易用性测试
安全测试
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
设计测试用例：
测试用例的万能公式：功能、界面、性能、兼容性、易用性、安全性。
下面我们对一个水杯来设计测试用例。
测试用例的设计方法
等价类
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。
这个方法的缺点是难以系统化，并且过度依赖个人能力。
判定表法（使用于关系组合）
这里所介绍的是判定表法而不是因果图法，因为因果图法的第一步是确定输入输出条件，然后找出输入和输出之间的关系，接着画因果图，然后再将因果图转换为判定表，个人觉得因果图这一步既麻烦，用处也不大我们完全可以根据输入条件和输出条件来画判定表，直接省略因果图这一步。
设计步骤
- 确定输入条件和输出条件。
- 找出输入条件和输出条件之间的关系。
- 画判定表。
- 根据判定表编写测试用例。
具体例子
假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠”。
1.确定输入条件和输出条件：
● 输入：订单已提交、金额大于300、有红包。
● 输出：优惠、不优惠。
2.找出输入条件和输出条件之间的关系：
(1)订单已提交，订单金额大于300元，则优惠。
(2)订单已提交，订单金额小于等于300元，无红包，不优惠
(3)订单已提交，有红包，则优惠。
(4)订单已提交，订单金额大于300元，有红包，则优惠。
(5)订单未提交，不优惠。
3.画判定表：
4.根据判定表编写测试用例：
1)金额大于300元，没有红包，提交订单，结果为有优惠
2) 金额不大于300元，有红包，提交订单，结果为有优惠
3)金额大于300元，有红包，提交订单，结果为有优惠
4)金额不大于300元，没有红包，提交订单，结果为无优惠
5)金额大于300元，没有红包，不提交订单，结果为无优惠
6)金额不大于300元，有红包，不提交订单，结果为无优惠
7)金额大于300元，有红包，不提交订单，结果为无优惠
8)金额不大于300元，没有红包，不提交订单，结果为无优惠
正交法
正交法需要用到我们的正交表，而正交表由因素数和水平数来构成。
比如我们下面这个例子：用户注册信息的填写。
那么因素数就是：姓名，电子邮箱，密码，确认密码，验证码。
水平数为：填写与不填写。
正交表的两条性质：
每一列中各数字出现的次数都一样多。
任何两列中的各有序数对出现的次数都一样多。
我们的正交表通常是很难写的所以我们常借助allpairs工具来生成:
步骤：
1.找到因素数和水平数:
因素数：姓名，电子邮箱，密码，确认密码，验证码。
水平数：填写，不填写。
2.allpairs工具来生成正交表：
3.根据正交表来编写测试用例
1) 全部填写姓名，电子邮箱，密码，确认密码，验证码
2) 填写姓名，不填写电子邮箱，密码，确认密码，验证码
3) 填写电子邮箱，确认密码，不填写姓名，密码，验证码
4) 填写密码、验证码，不填写姓名，电子邮箱，确认密码
5) 填写姓名，电子邮箱，密码，不填写确认密码，验证码
6) 填写姓名，确认密码，验证码，不填写电子邮箱，密码
4.补充其它的测试用例
针对上面我们可以再次补充一条：不填写电子邮箱，确认密码，姓名，密码，验证码。
场景设计法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。
测试方法
黑盒测试
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。
优点：
1.不需要了解程序内部的代码以及实现，不关注软件内部的实现。
2.从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维。
3.测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。
黑盒测试用到的测试方法有，等价类，边界值，判定表，场景法，错误猜测法等。
白盒测试
白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。
但是，灰盒测试没有白盒测试详细、完整，黑盒测试覆盖产品功能范围广。所以灰盒测试是不能取代黑盒测试和白盒测试。不过黑盒测试可以取代灰盒测试，但是不建议，需要消耗很大的代价，需要设计非常非常多的测试用例。
常见的测试方法有哪些？哪种测试方法用的最多？
白盒测试和黑盒测试。在工作中需要根据实际情况来结合白盒测试和黑盒测试。通常来说测试人员使用黑盒测试方法相对要多一点。
水杯的测试用例
功能性测试
- 装水，喝水。
- 水杯可以装满水。
- 水杯只能装一般的水。
- 水杯具有安全刻度，超过刻度就会溢出。
- 水杯是否烫手。
- 水杯能折叠吗。
界面测试
- 水杯的形状是否符合产品的说明。
- 水杯的大小是否符合产品的说明。
- 水杯的材料是否符合产品的说明。
- 水杯的颜色是否符合产品的说明。
- 水杯的外观是否完整美观。
性能测试
- 水杯的耐热性。
- 水杯的抗冻性。
- 水杯的抗摔性。
- 抗腐蚀性。
- 水杯的抗压性。
- 装水的性能。
- 水杯使用的最大次数。
兼容性测试
- 水杯是否能够装水，啤酒，果汁，可乐等。
易用性测试
- 倒水是否方便。
- 喝水是否方便。
- 水杯拿着是否舒服（符合人体工学）。
- 水杯是否方便打开。
- 水杯是否防滑。
- 水杯清理是否方便。
安全测试
- 材质是否健康。
- 材质是否易燃易爆。
- 材质在高温下会不会产生有毒物质。
- 材质是否有可能与一些液体发生化学反应。
