API测试:  挑战与最佳实践

1 (2)

现代复合应用聚合了私有,合作,公开等多种应用,并正以惊人的速度取得发展来满足于业务目标。ProgrammableWeb的报告中提到今天有超过9500个应用被发布——是2011年10月发布应用量的两倍更多,而私有应用的数量估计已经超过几百万。

随着应用程序的发展得越来越相互依赖化,复合应用的安全性,功能性和性能表现等仅仅和其最薄弱的环节一样健壮。一个端到端交易的成功取决于所有部件完美运行的所用时间;甚至一个流行的API的小故障可能导致成千上万的问题。因此API的完整性具有巨大的商业影响。一个不满足预期的API可能会如开打潘多拉之盒一样来带无数问题——既要组织内部生产也需要组织内部消耗它。

如果您正在将API发布到您的关键交易中,您需要承担该API完整性(或缺乏完整性)的相关风险。由于外部API集成到业务流程中的数量的增长,这样做可能是潜在的失败点。任何应用程序故障对业务的影响是相同的,不管故障是在你所开发的组件或者你正在消费的API中。而相互指责推卸责任的做法无助于提升客户满意度和品牌忠诚度。

如果你正在公开一个API,其意味在于它将如一个描述一样工作。一旦消费该API的组织将这一功能整合到他们自己的应用程序中,API的故障将危害依赖于此功能的交易。如果你的API很流行,可以保证一个小故障就编程头条新闻。若你的API更安全,可靠并可以来,你将取得被消费的更好机会和更大的业务拓展潜力。如果你提供了一个有问题的接口,并有其他API可以取代,你可能会失去业务,因为调整API集成相关的成本是如此之低。

API经济的完整性挑战

在今天的API经济中,你要保护你品牌的能力有赖于你意识到一下的挑战…

2 (2)

1) 更广泛的攻击面

只需要通过一个内部基础组件暴露一个API就无可否认的从安全性角度提高了应用程序的攻击面。这可能是脆弱的API级别的攻击(Injections,有效负荷为基础的攻击等)或者利用无效的认证,加密,访问控制等手段。如果API是由公共云服务托管的,那更广泛的攻击面将使挑战变的更复杂。在传统的计算机中,生产者是了解并完全控制网络安全的参数的。而在云服务中,这种控制的级别显著降低。如果你现在利用第三方服务组,确保API将提供满足组织希望水平的安全性责任是需要你承担的。

2) 提高潜在的意外误用

考虑到API发布后有机会访问的人的范围和数量,他们会用一些意想不到的方式进行使用,这几乎是不可避免的:通过使用者懵懂的以开发者完全无法设想的方式使用或者通过试图利用它们来进行恶意攻击的攻击者。在SOA的早期—-当服务是通过可控制内部网络发布的时候—-您可以相当肯定的是,您的服务将被用户有同事或者熟悉服务的人在其预期情况下进行使用。现在,当一个API发布给公众,生产者将交出所有控制权并确定如何将这些API消耗掉。

3) 特殊情况下不可预知的需求

通常API需要满足既定性能的SLA;然而,验证性能与服务的水平的协议是相当复杂的,因为难以预料API被访问的时间和具体方式。因此验证API性能的SLA的针对性应用场景是相当重要的。包括一个API仓库被关注的意外突然激增等情况。如果你要测试一个在附加层交互的API服务,潜在的变量或不可接受的性能表现将以指数形式增长。这使得该两者更为关键-——并且更具挑战性——执行一套强大的性能测试场景和详尽定位是否可以满足被测试系统的预期要求。

4) API消费者需要的测试环境

要促进API的广泛采用,它通常需要提供API消费者的测试环境(又名:受控沙箱)使他们能够在堆生产系统零影响的情况下针对发布的服务进行开发和测试。通过允许集成来在API真实实现或者新功能完全完成之前,这样的测试环境也很关键。提供测试环境的另一个主要驱动力是给予API消费者可以简单访问到广泛范围的行为,数据并和性能配置等信息来帮助他们测试其希望整合该API的系统的性能概况。

5) API测试“必备”

确保API可以提供必要的安全,可靠性和性能水平,在当今的API生态环境中对包含开发,持续执行,认真维护一个广泛的复杂测试是成功至关重要的要素。以下是几个关键的API

测试“必备”,将帮助你实现鉴于上述挑战的目标。

3 (2)

a . 智能化测试的创建和自动验证

使用API时,测试大范围的场景和细节调是非常重要的,所以自动化被推向前沿。使用有限的或人工的方式来创建或执行简单的自动化测试可能已经足以为内部使用的Web服务进行测试(例如,通过SOA),但更复杂,更广泛的自动化测试要求API有足够强大的表现来满足业务预期。你需要自动化的水平达到能够给你一整套可在系统化的方式下重复的全面的功能测试方案。

为了这个目标,建议的方法是使用直观的界面来贯穿整个自动化测试复杂场景,包括消息传递层,ESB产品,数据库和大型主机:

在API中定义自动化测试场景,需要跨越多种协议和消息类型,包括:REST, WADL, JSON, MQ, JMS, EDI,固定长度消息等等。

自动化丰富多层验证跨越整个端到端的自动化测试场景。

参数化测试针对消息,验证和数据库配置,测试场景中提取的值或变量进行测试。

不需要编写脚本来定义复杂的测试流程逻辑。

可视化:消息和时间工作流如何通过分布式架构进行测试执行。

这些功能都是应该—-或至少可以—在基于SOA的Web服务测试所具备的。事实上,大多数的这些功能都是在SOA测试的环境中被发明,测试和改进的。API—-用他们的极端风险和被滥用的无数机会—-使我们来到了临界点,要使这些自动化测试和验证功能有一些“必备”的条件来认真的满足组织所需要的和期望的要求。

b .  改变测试资产和环境的管理

不断发展的API可以帮助企业保持竞争优势,同时影响业务需求。然而,如果自动化测试套件未能跟上不断变化的API 的步伐,这种频繁的变化呈现的将是显著的质量风险。

一种用于测试资产的快速,边界,准确的更新的系统,是保持测试资产同步于不断变化的API的关键。如果你能自动评估变更现有测试的影响,然后快速的更新或创建现有的测试来响应识别变化的影响。你就可以极大的减少所需的成本,以确保您的测试不会不满足于您的预期,或忽略重要的新功能。

c . 仿真测试环境的服务虚拟化

服务虚拟化技术创建了仿真测试环境可以随时随地访问那些难以获得的、难以访问的或者难以为开发或测试配置的依赖资源的行为。 “依赖资源”应该包含大型主机、移动应用程序前段、数据库、web service、第三方应用程序,或者其他系统,这些资源都是在你的团队直接控制外的。服务虚拟化可以与硬件/OS虚拟化共同使用来访问那些你需要更容易、更快或者更彻底的环境。

在API测试的情况下,服务虚拟化可应用在两个关键方面:

模拟访问依赖资源的行为(例如,从一个移动应用程序,数据库,遗留系统,或者第三方服务),你需要这些行为来彻底的验证你的API。

模拟你的API的行为,创建一个测试环境使得API使用者可以在不影响你的生产环境情况下进行开发和测试——或者在API完成之前开始开发和测试。

d . 使用服务虚拟化的广泛的性能测试

根据API的高暴露性质,会有一个高潜力的变换以及一直波动的通信流。为了确定你的API是否在变幻莫测的事件或者API经常面对激增需求上使SLA满意,必须加大性能测试的范围。你可以使用服务虚拟化(上述说介绍的)创建仿真测试环境,这些测试环境可以帮助你针对不同的很难再测试环境中创建的性能场景进行测试。

例如你可以容易的设置性能条件(例如,定时,延时)来模拟峰值、预期和缓慢的性能——可能会帮助你为云的突发传送指定计划或者确定当有来自中国的访问时API可以如何回应。

您还可以配置各种错误和失败条件,这些错误和失败很难在真实系统中复现——例如,有个你的API依赖Amazon Web Service,你可以很容易的模拟AWS瘫痪了的场景。这种能够快速的在相依系统中配置大量的条件的能力对确定你的API能否在异常条件下提供合理的——或者至少不失得体的——响应是必不可少的。

采取服务虚拟化帮助性能测试的最后一个方法:你可以“虚拟化”任何与第三方系统的链接,可靠的消除你的压力测试可能会对服务造成影响的风险,你没有获得连续发送测试消息的允许。

e . 使用服务虚拟化进行广泛的安全测试

考虑到API的增加的攻击范围,一个多方面的安全测试策略对确保开发为你的应用程序构建了合适的安全级别是必不可少的。这包括:

执行复杂身份验证的、加密的和访问控制的测试场景。

生成大量范围的涉及参数起毛、注入、大量负荷等的测试场景。

运行针对你现有的功能测试场景的渗透攻击场景。

测试运行期间监控后端,查看安全是否被攻破。

另外,如果你正在使用服务虚拟化(上述的),你可以利用她使你的安全测试达到另一个水平:

它提供了快速的方法来模拟攻击场景以及模仿不同的安全依赖关系的行为。这使你从现有功能测试场景获得更大的价值(因为你可以对比不同的安全场景来运行他们,否则这些安全场景再次测试时会很难配置和实现)。

它使的在没有安全专家时执行大量的安全测试。相对于大量的预配置安全场景执行已存在的安全场景可以很容易的被执行。

它可以帮助你隔离和集中于应对各种攻击场景和不同的依赖安全行为的响应。