标签：公司 工作 通过 用户名 自己的 别人 结合 功能性 也会
做测试时间长了，对于用例的设计慢慢的也会总结出自己的一套方法。
理论上有很多的用例设计方法，如：等价类，边界值，错误推断法，因果图法，正交试验设计等等。
其实我本人设计用例的方法其实很简单，就从两个方面考虑，通过性和异常来考虑，无非就是多考虑几个异常的场景。
例如：登录业务。
无非就是考虑：1.输入正确的用户名密码 （这是通过性）
2.输入错误的用户名，正确的密码 （这是异常场景一）
3，输入正确的用户名，错误的密码 （这是异常场景二）
4，输入错误的用户名，错误的密码 （这是异常场景三）
至于什么字符，数字，英文等，太繁琐了，实际工作中最多会多考虑一下字符的长度，其他的根本不可能写全。如果每个场景都考虑到位，时间也不允许。
所以我写用例的思路就是从正常场景和异常场景两个方面考虑，涉及到重要模块的时候，多考虑一些异常场景，结合业务知识。例如：涉及到了支付，金额之类的，就要多测试一些数据了。
这篇随笔主要是通过功能性的用例，来引入接口用例的设计。
下面接上我网上找来的一个案例：
这个案例是GET请求，单接口。很简单，主要是通过这个案例来阐述一下接口测试用例的设计思路。
从截图中可以看出，入参参数有3个必填参数。
先设计一个通过性的用例，检查返回结果。
再分别设计多个异常的场景，其中某个或多个或全部必填参数出现错误的情况下，返回是否会报错。
这也与上文中我说的功能用例设计思路类似。
希望大家以后在设计接口测试用例的时候，不要手无足措，利用这个思路，很快就能进入状态。
当然实际工作中，很多情况下，公司只测试通过性的接口用例，异常考虑的不充分。如果你能做的比别人多一点，那么，你很快就能出人头地。
标签：公司 工作 通过 用户名 自己的 别人 结合 功能性 也会
原文地址：https://www.cnblogs.com/star12111/p/13149518.html
