彩票走势图

互联网“土地革命”的下一个阶段也许是关于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驱动的流程总是符合预期，你需要一个有一个强大的回归测试套件。它可以帮助你完成预期的监控力度。并且当出现问题时，会立刻通知你。使你更容易查明故障的根本原因，帮助你快速解决问题，大大减少了故障对业务的影响。