小型网站建设源码,沈阳网站建设方案模板,做图片推广的网站吗,境外电商哪个平台好在最近的部署中#xff0c;当我被问到“什么是API测试#xff1f;”时#xff0c;我正与客户一起制定API测试策略。那时我突然意识到#xff0c;要描述API测试居然是一件如此具有挑战性的事情#xff0c;即使你如实地描述了它#xff0c;也往往听起来很无聊和复杂。
好吧…
在最近的部署中当我被问到“什么是API测试”时我正与客户一起制定API测试策略。那时我突然意识到要描述API测试居然是一件如此具有挑战性的事情即使你如实地描述了它也往往听起来很无聊和复杂。
好吧容我在这里告诉你API测试并不乏味或复杂。它实际上非常有趣且功能强大换一种思路和方式来理解它可以释放你创建真正有效的测试策略的能力。要真正了解如何进行API测试请继续阅读。
什么是API如何使用 在服务开发中应用程序接口API是各种应用程序使用通常由协议定义的通用语言相互通信的一种方式。这些示例是用于RESTful服务的Swagger文档或用于SOAP服务的WSDL。甚至数据库都有接口语言即SQL。
API就像UI允许人类与应用程序交互的方式一样使机器之间能够高效地进行通信。
API之所以出色是因为它们代表了构建块开发人员可以使用它们轻松地组装各种交互而不必在每次需要机器进行通信时都重写接口。另外由于API具有协议因此只要彼此之间按照API协议进行通信就可以以完全不同的方式构建希望相互通信的应用程序。这使来自世界各地的不同组织的不同开发人员可以创建高度分布的应用程序同时可以重复使用相同的API。
当用户与应用程序即移动应用程序的前端进行交互时该前端对后端系统进行API调用从而通过两种主要方式简化了开发过程
开发人员不必担心为每个移动设备或浏览器制作定制的应用程序。可以更新或修改不同的后端系统而不必每次都重新部署整个应用程序。
结果开发人员可以通过将单个服务集中于完成离散任务来节省时间而不必花费时间将逻辑写入其应用程序。
标准API使用的一个很好的例子
亚马逊购物服务的文档化API使开发人员可以在创建应用程序时与亚马逊购物进行交互。开发人员可以在其用户体验的适当时间使用Amazon API以创建无缝的客户旅程。
例如这可能看起来像这样
用户体验对应的API调用1.搜索优质的视频游戏1. SearchItems2.亚马逊建议使用Minecraft2. GetItems3.将Minecraft添加到我的购物车3. AddToCart
用户与用户界面进行交互而应用程序与开发人员定义的后端Amazon API进行交互。只要基础API的行为符合预期一切就可以很好地工作。
……但是如果量很大的话。
于是我们得出了测试这些API的重要性。
现在我也找了很多测试的朋友做了一个分享技术的交流群共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源没人解答问题坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化性能安全测试开发等等方面有一定建树的技术大牛
分享他们的经验还会分享很多直播讲座和技术沙龙
可以免费学习划重点开源的
qq群号691998057【暗号csdn999】 什么是API测试
那么如何执行API测试它到底意味着什么如何进行API测试与仅在UI级别与应用程序进行交互的用户不同开发人员/测试人员必须确保任何和所有基础API的可靠性。如果不对API本身进行测试则开发人员和测试人员将被困于手动测试就像用户在UI级别上对应用程序进行测试一样等到整个应用程序堆栈都已构建之后才能开始测试。
相反你可以改为通过以下方式执行自动API测试在API级别测试应用程序设计与基础API直接交互的测试用例并以此获得众多优势包括以稳定方式在易于自动化的层上测试业务逻辑的能力。与手动测试仅限于验证特定的用户体验不同API测试使你能够针对未知情况对应用程序进行防弹。
如何进行API测试
不同类型的API测试——位置、原因和方式
进行API测试的最佳方法是从下至上构建可靠的测试实践。为此一种设计测试策略的好方法是遵循Martin Fowler的测试金字塔。金字塔方法建议你在具有UI测试的单元测试的坚实基础之上构建各种API测试例如协议、方案、性能等。API测试允许你在单元测试无法达到的水平上测试应用程序逻辑。
这些测试策略是互补的。在应用程序的较低层进行更早的测试可以帮助你“快速失败并尽早报错”尽早在源头而不是在SDLC中发现缺陷。单元测试很重要但是目前我们专注于API测试。你如何测试APIS可以进行哪些测试他们为什么重要如何进行API测试
你如何使用API
下一节将介绍不同类型的API测试包括在何处/为什么/如何使用它们。
协议测试
API表示2个或更多应用程序之间的协议。协议描述了如何与接口交互、可用的服务以及如何调用它们。该协议很重要因为它是沟通的基础。如果协议有问题那么别的什么都没有用了。
API测试的第一个也是最基本的类型是协议测试它测试服务协议本身SwaggerPACTWSDL或RAML。这种类型的测试可以验证协议是否正确编写并且可以由客户使用。该测试通过创建一系列可以拉入协议并验证以下条件的测试来工作
服务协议是按照规范写的消息请求和响应在语义上是正确的模式验证端点有效HTTPMQ / JMS主题/队列等服务协议没有改变
我认为这些是你的第一个“烟雾测试”。如果这些测试失败则实际上没有理由继续测试该特定服务。如果这些测试通过则可以继续测试API的实际功能。
组件测试
组件测试就像API的单元测试一样——你想采用API中可用的各个方法并分别测试其中的每个方法。通过对服务协议中可用的每种方法或资源执行测试步骤来创建这些测试。
创建组件测试的最简单方法是消耗服务协定并让它创建客户端。然后你可以使用正负数据对每个单独的测试用例进行数据驱动以验证返回的响应具有以下特征
请求有效载荷格式正确模式验证响应有效载荷格式正确模式验证响应状态符合预期200 OK返回了SQL结果集甚至是一个错误如果你要这样做响应错误有效负载包含正确的错误消息响应与预期的基线匹配。这可以采取两种形式回归/差异——响应有效负载在每次调用之间看起来完全相同自上而下的方法实际上是你捕获响应的快照并每次都对其进行验证。这也可能是识别API更改的重要催化剂稍后会详细介绍。断言——响应中的各个元素都符合你的期望这是针对响应中特定值的更浅显、自下而上的方法。服务在预期的时间内响应
这些单独的API测试是你可以构建的最重要的测试因为它们将在所有后续测试技术中得到利用。当你可以在以后所有不同类型的测试中简单地引用这些单独的API调用时为什么还要重建测试用例呢这不仅提高了一致性而且简化了进行API测试的过程。
场景测试
大多数人在考虑API测试时都会想到场景测试。在这种测试技术中你将各个组件测试组装成一个序列就像我上面为Amazon服务描述的示例一样。
获取序列有两种很棒的技术
查看用户故事以识别正在进行的各个API调用。练习UI并捕获对基础API的流量。
通过场景测试你可以了解是否可能通过将不同的数据点组合在一起而引入缺陷。
与客户合作时我遇到了一个非常有趣的示例。他们采用了一系列服务来呼叫客户的财务资料、可用帐户、信用卡和最近的交易。这些API调用中的每个调用都是单独工作的但是当你按顺序将它们放在一起时它们就会开始报错。造成这种情况的原因是一个简单的时间戳从一个API调用返回时它的格式与后续请求中期望的格式不同。他们在进行单元测试或冒烟测试时没有意识到这一点因为他们断言返回时间戳时未指定格式。直到测试整个场景后才可以清楚地发现将时间戳从一个呼叫转移到另一个呼叫会导致故障。
场景测试的另一个好处是当你以未预期的方式使用API时可以验证预期的行为。发布API时你将向外界提供一系列构建模块。你可能具有将这些块组合在一起的规定技术但是客户可能会有无法预料的需求并且意外地将API组合在一起以暴露应用程序中的缺陷。为了防止这种情况你会想到使用API的不同组合创建许多方案测试以使应用程序免受重大故障的影响。
由于组件测试构成了场景测试的基础因此组织通常拥有大量的场景测试。它们是在引入新功能以模拟客户使用新功能的旅程时构建的。这样一来你确实可以减少测试时间因为你只需要为新功能构建测试并且你知道自己拥有可靠的基础测试库来捕获任何意外情况。
性能测试
在特定于性能的测试环境中性能测试通常会降级到测试过程的结尾。这是因为性能测试解决方案往往很昂贵需要专门的技能并且需要特定的硬件和环境。这是一个大问题因为API具有必须满足的服务级别协议SLA才能发布应用程序。如果你等到最后一刻进行性能测试则无法满足SLA可能会导致巨大的发布延迟。
在流程的早期进行性能测试可以使你在运行完整的回归周期之前发现与性能相关的问题。如果你到目前为止一直遵循测试过程那么实际上将非常容易因为你拥有执行性能测试所需的所有基础测试用例。你可以简单地进行场景测试将其加载到性能测试工具中然后以更多的用户数量运行它们。如果这些测试失败则可以将失败的原因追溯到各个用户并更好地了解将受到的影响。然后管理人员可以利用这种了解来决定是否发布应用程序。
安全测试
安全测试对组织中的所有利益相关者都很重要。如果暴露并利用了安全漏洞则可能导致严重的声誉损失和财务损失。就像用户会意外地使用你的API一样用户也可能有意尝试利用你的API。黑客可以掌握你的API发现漏洞并加以利用。
为了防止此类行为你需要构建测试案例以尝试执行这些类型的恶意攻击。你可以利用现有的测试用例来执行此操作因为方案测试可以将攻击向量提供给应用程序。然后你可以重新使用此攻击媒介来发起渗透攻击。一个很好的例子是将不同类型的参数模糊测试或SQL注入攻击与方案测试结合在一起。这样通过应用程序传播的任何更改都将由你的安全测试选择。要了解有关API安全测试的更多信息请查看这篇文章并持续关注。
全渠道测试
由于应用程序与之交互的多个接口移动WebAPI数据库等如果单独测试其中的任何一个你将遇到测试覆盖率的空白而忽略了这些接口之间复杂的交互的精妙之处。
全渠道测试通过将API和数据库测试交织到移动和Web UI交互的验证中全面覆盖了应用程序的许多界面以确保彻底覆盖测试范围。这意味着要进行一个正在使用其中一个接口并与另一个接口进行协调的测试——执行WebSelenium或MobileAppium之类的UI测试并将它们与你的API或数据库测试中的任何一个交织在一起从系统通过测试执行。借助有效的全渠道测试你可以创建稳定、可重用的测试案例这些案例可以轻松实现自动化。
管理变更
更改是应用程序风险的最重要指标之一。变更可以多种形式发生包括
服务的协议消息格式更改从API添加或删除的元素底层代码更改会影响返回的数据格式重新架构服务以将其分解为多个部分随着组织转向微服务这种情况极为普遍
发生更改时你需要构建测试用例以识别更改并提供补救计划。使用提供分析以解决这些更改的影响的解决方案将使你了解发生了什么更改并确定受影响的特定测试的目标。
然后可以以模板的形式捕获更改以使用新功能更新任何基础组件或方案测试。由于其余测试引用了这些测试因此更改的影响将减少。
总结
建立可靠的自动化API测试策略是确保你的应用程序“今天和昨天一样工作”的最佳方法这不仅仅是一个容易理解的短语而已。API测试允许你构建一个可靠的框架来识别应用程序多层中的缺陷。这些测试可以全部自动化并且可以连续运行因此你可以确保应用程序符合业务期望同时也能保障功能的精确。由于API测试的工作水平远低于UI测试的水平因此你知道你需要保持一致性并且所构建的测试将持续很长时间。
加油吧少年你准备开始API测试了吗但在此之前你还需要弄清楚要使用什么工具。有兴趣的朋友请持续关注后续文章了解如何为你的组织选择最佳的API测试解决方案。
下面是配套资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你 最后 可以在公众号自动化测试老司机 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
如果我的博客对你有帮助、如果你喜欢我的博客内容请 “点赞” “评论” “收藏” 一键三连哦
