关于接口测试
接口测试是一个比较宽泛的概念, 近几年在国内受到很多企业和测试从业者的追捧, 尤其是上层的UI在取悦用户的过程中迭代更新加快, UI自动化维护成本急剧上升的时代, 大家便转向了绕过前端的接口层面进行测试. 但是很多人, 对接口测试的理解并不完整, 事实上, 我们无论通过何种方式运行一段程序, 都必须调用该程序的接口才能实现.
比如, 我们通过登录页面输入账号和密码, 点击 登陆按钮, 最终该操作会被封装成一个HTTP请求, 发送给后台服务器, 后台服务器会直播调用登录接口, 来运行登陆的实际代码.
在这个过程, 点击"登录"按钮是一个前端界面, 如果通过该方法来观察其运行状态, 那么我们就称之为界面级的黑盒测试, 俗称"点点点". 我们也可以利用各种工具, 比如Fiddler, Postman, SoupUI, 甚至使用代码发送数据给后台服务器, 进而观察其运行结果的, 这些, 我们称之为协议级的接口测试. 这部分是大家经常提级的接口测试, 我就不再继续赘述了.
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：485187702【暗号：csdn11】
当然, 我们还可以从代码层面来直播调用该登录接口, 那么 此时就称之为代码级的接口测试.
比如, 以下是一个简易的在线的计算器的源代码:
class Cal:def add(self, a, b):return a+bdef minus(self, a, b):return a-bdef mul(self, a, b):return a*bdef div(self, a, b):return a/b我们大概率是拿不到源代码的, 但是可以拿设计文档, 这几个方法所需要的参数, 以及类型都是可以拿到, 比如:
由于我们只是调用接口, 只是接口的层次已经更接近底层代码了, 但是依然看不到代码, 所以, 我们依然需要使用用例的设计方法去设计我们的传入参数, 对div这个方法进行演示:
- 整数相除
- 小数相除
- 除数为0
- 输入字符串
- 输入特殊字符
- 超长的数字
- 被除数为空
- 除数为空
- .........
以上, 有没有发现, 像极了使用等价类对页面的输入框进入用例设计. 是的, 没错.
因此, 我们就可以直接调用这些方法, 使用设计好的数据对它进行测试. 以下是使用unittest框架对它进行的测试, 写两条除法的测试用例供演示使用:
import unittestclass TestCal(unittest.TestCase):def test_div01(self):cal = Cal()result = cal.div(15,3)self.assertEqual(result, 5)def test_div02(self):cal = Cal()result = cal.div(15,0)self.assertIn('分母不能为0',result)if __name__ == '__main__':unittest.main()以下是测试结果:
最后, 我们还可以深入到代码实现层, 对代码的实现逻辑进行详细的测试, 常用的方法有
- 语句覆盖
- 判定覆盖
- 条件覆盖
我们又称之为白盒测试或单元测试
看到了吧, 这三种测试方法:
- 黑盒测试(从UI去)
- 协议级的接口测试(发送HTTP请求)
- 代码级的接口测试
以上方法的测试, 整个过程唯一的区别公在于我们调用该计算器的方式不一样, 最终真正工作的, 都是同样的一段代码, 这个本质是绝对不会因为被调用的方式不同而发生一丁点儿的变化. 所以, 任何一种调用的方式, 都在驱动程序运行而已, 本质上来说, 他们所做的事情没有任何区别.
因此, 正是因为接口测试的所谓接口, 是一个不太容易下定义的概念, 所以我们千万不能盲目地认为, 只有协议级的测试才是接口测试, 或者代码级的测试才是接口测试, 这些理解都太过绝对. 事实上, 通过页面上的操作, UI-User Interface, 用户界面, 直译用户接口, 这些页面的操作入口, 也是一个一个的接口啊. 所以, 请大家不要纠结于概念本身, 本文不是要去教大家如何抬杠, 而是明白, 我们的测试确实可以多样化, 可以更多地专注于从不同角度来完成对一个功能的测试, 进而达到更全面的测试覆盖, 尽早地找出Bug才是王道.
