API测试的五大误区

原创|行业资讯|编辑:龚雪|2015-11-30 10:39:24.000|阅读 256 次

概述:互联网“土地革命”的下一个阶段也许是关于API的战争。Web时代着力于为用户提供更快、高效地产品和服务,而API则可以拓展B2B之间的业务品牌联系。这意味着,无论是商家还是客户都需要一个服务级别协议(SLA),来促进业务整合。然而对于服务消费来说,面向服务的架构(SOA)需要信任,公众和私人服务需要API的完整性。

互联网“土地革命”的下一个阶段也许是关于API的战争。Web时代着力于为用户提供更快、高效地产品和服务,而API则可以拓展B2B之间的业务品牌联系。这意味着,无论是商家还是客户都需要一个服务级别协议(SLA),来促进业务整合。然而对于服务消费来说,面向服务的架构(SOA)需要信任,公众和私人服务需要API的完整性。

随着API经济的出现,不可否认的一点是越来越多的业务将会影响API风险。确保您API的安全性、可靠性和预期性能水平显得比以往任何时候都要重要。

误区一:在有SLA的情况下,不需要进行API测试

如果应用程序API出错了,很容易让用户感觉你的应用程序随处充满漏洞。无论故障是出现在组件中还是API中。应用程序对我们来说很重要,包括开源软件和将要采用的API。我们使用第三方功能的同时,也会将我们暴露于风险中。

当你将API整合到你的业务处理中,API的完整与否将会与业务风险息息相关。几乎不考虑客户满意度和品牌忠诚度的做法是很危险的。一般情况下,我们认为其他组织公开的API是安全和可靠的。但如果不是,它可能会给我们带来很多问题,例如品牌侵蚀、顾客丢失、收益减少。

对于每个API测试的严格程度,取决于它在业务过程中的重要程度。比如,一家航空公司的在线办理登机手续过程中,有一个负责在线打印天气预报的API,它的测试并不需要投入太多的精力。

误区2:它已经包含在GUI测试中

很多次,当问客户是怎样进行API测试的时候,他们都是回答:“这是属于GUI的测试内容呀。”进行GUI测试是无可否认的,它是任何终端到终端的测试过程中不可缺少的一部分。但是,GUI测试本身并不能有效的行使API。

比如,一个公开的API,并且可以直接访问。它是否可以扛得住大范围的误用和恶意攻击呢?

在应用程序的UI层面进行操作是很难获得大面积的API测试覆盖率的。它只能测出一些显而易见的,很容易表现出来的错误。然而,更多的问题是掩盖在行为、数据、性能和安全方案下的。这些都是很难从UI中看出来的。所以,仅仅是CUI测试而没有API测试,我们很难保证API的安全性和可靠性。

此外,我们还需要关注事件过程。当UI报告显示“交易成功”,你确定它是否真的各个方面都达到了预期效果呢?例如:

  • 数据库是否更新?
  • 消息是否被传送到ESB?
  • 如果测试失败,你能找出时间、位置和原因么?

最后还是要强调,GUI的测试结果真的不堪一击。会为如今快速更新换代的应用程序带来难以预计的风险。应用程序即使只有微小的变化也会导致测试套件的不同步。比如:

  • 即使没有出现错误也会报告测试失败——这将大大降低团队的工作效率。
  • 测试失败时,无法找出问题的真正原因。

误区3:GUI测试人员可以直接执行API测试

通过上面的内容,我们知道GUI测试是不能替代API测试的。那么,有人又说了:“既然这样,等测试人员测试完GUI,再让他们测试API好了。”这样也是不行的,我们需要将负责这两个测试的人员分开。因为人很容易受到惯性影响,从而导致发现不了问题,也就是所谓的当局者迷。

一个简单的API测试的主要步骤包括多样的正负输入和大量的测试案例。这些不需要大量专业知识和工具就可以完成。这些方法可以很好地测试API的功能。

但如果你想真正了解API在关键业务过程中的出错风险,必须在真实场景中使用API。它是否可以记录多种事务状态(是否登陆,不同的偏好设置等)?进入到下一个步骤的消息响应是否合适?它是否触发了正确的行为?例如,JMS消息是否恰当的出现在ESB中。

为了使我们设计的测试案例可以真实的反应API在真实场景的行为,需要关注:

  • 安全访问控制认证机制
  • JMS和MQ队列
  • 主机方位
  • SAP或其他ERP访问
  • ESB访问
  • 数据库访问
  • 数据交换中将测试数据设为最优先级
  • 真实数据可能会与其他数据产生合并、混淆
  • 复杂的验证可能覆盖和关联多个不同的场景步骤和技术

误区4:无法执行终端到终端的测试

因为涉及到多个从属系统,想要构造一个完整真实的测试环境几乎是不可能的。因此,开发人员和测试人员可能面临:

  • 复杂的测试环境
  • 区分和控制边界,限制资源访问
  • 不可访问的第三方/合作伙伴的系统和服务
  • 限制测试时间窗口
  • 缺少/不稳定成分
  • 不断变化的开发环境

使用服务器虚拟化,团队可以快速创建模拟测试环境,获得必要的系统行为。无需访问实际的生产环境即可进行测试。服务器虚拟化解决方案捕获实时系统行为,让你无需为制约因素、等待时间和访问费用的问题烦恼。

误区5:不仅仅是测试,还需要监控

随着敏捷开发与持续交付的采用率上升,变化的发生无处不在。甚至一些微不足道的变化都可能引起上游组件与API的交互和下游组件对API的处理。

了解到细微的变化如何对业务流程造成影响,我们知道测试的每一步都是至关重要的。它能保证程序可以达到预期的功能、性能、安全性和可靠性。通过对这些变化对程序的影响,我们可以很容易的设置测试周期。

有些测试团队为了控制风险,会重复执行测试方案。这里有一些更好的建议:

  • 使用连续的回归测试,以确保进程达到预期目标。
  • 定期分析被测试的API,以及它们的依赖关系。

即使你经常监视您的应用程序与APM解决方案,大多数只是临场表现的变化。功能更改通常没有监测,检测或报告。如果要确保API驱动的流程总是符合预期,你需要一个有一个强大的回归测试套件。它可以帮助你完成预期的监控力度。并且当出现问题时,会立刻通知你。使你更容易查明故障的根本原因,帮助你快速解决问题,大大减少了故障对业务的影响。



标签:测试软件测试

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动成果

登录 慧都网发表评论


慧都网友 2015-11-30 10:52:46.000
0

API测试要与业务优先级结合,很重要。


慧都网友 2015-11-30 10:51:27.000
0

没有达到运营预期结果,而且源代码、功能也没发现问题,可以多关注API


慧都网友 2015-11-30 10:47:55.000
0

API很重要,无论是人机交互还是机器之间的通信都需要


为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
相关厂商
相关产品
Parasoft C/C++test

Parasoft C/C++test – 针对 C/C++ 开发的综合性代码质量保障工具,有效提高开发团队工作效率和软件质量。

Parasoft Jtest

Parasoft Jtest是一款Java自动化测试工具。能够无缝集成Parasoft SOAtest。

Parasoft dotTEST

Parasoft dotTEST是一种自动化的、非侵入式的代码质量保证解决方案。

Parasoft Insure++

Parasoft Insure++是专用于 C 和 C++ 语言的运行时内存分析和错误检测工具。

Parasoft SOAtest

Parasoft SOAtest是业内最全面的API、云服务和SOA测试平台,并提供优秀的负载与性能测试、API安全测试等功能。

Parasoft Virtualize

Parasoft Virtualize是一个用于创建、部署和管理模拟的开发与测试环境的虚拟解决方案。

Parasoft DTP

Parasoft DTP是一个完整的软件生命周期管理平台。

Development Testing Platform(DTP)

Development Testing Platform(DTP)是一款开发测试平台。通过在SDLC中持续应用软件质量最佳实践降低了商务风险。

Parasoft SOAtest with Load Test

SOAtest with Load Test是处理业务与安全关键性事务的完整的自动化端到端测试软件。

在线客服 在线QQ 电话咨询
400-700-1020
反馈
在线客服系统
live chat