接口测试
接口测试是软件测试的一种,它包括两种测试类型:狭义上指的是直接针对应用程序接口(下面使用缩写API指代,其中文简称为接口)的功能进行的测试;广义上指集成测试中,通过调用API测试整体的功能完成度、可靠性、安全性与性能等指标。[1]
API的调用没有用户图形界面(下称GUI)操作,是一种发生在信息层的测试,[2] 在由于敏捷开发广泛应用而使得GUI经常有变化的当下,利用GUI执行大批量自动化测试几乎不可能,因而针对相对稳定不变的API进行的测试有着极高的重要性,将其自动化也是一个很重要的工作。[3][4]
API测试概述
API测试包括直接针对API本身进行的测试和将API置于实际应用环境,将API与其服务的用户逻辑一同进行集成测试两种。[1] 此类测试包括针对表现层状态转换(SOAP)应用程序接口、Web服务,企业服务总线、数据库、大型机、网页(及其UI),以及 企业资源计划等相关系统的测试。
API测试的执行者除开发此API的开发人员外,还包括使用此API构建应用程序的人。[5]
API测试用于测试API收到合理参数,被调用后是否能够以预期的格式返回正确的结果。在测试中尤其需要关注API对服务虚拟化是否能够作出适当的处理:比如对一个不合理的输入抛出合适错误、对极端的输入也能够在可以接受的响应时间内给出正确应答或是能够妥善应对潜在安全攻击(如XSS攻击)。[1][4] 虚拟化则是在API测试中常用的一种模拟广泛用户场景的方法。[6]
API测试,GUI测试和测试自动化
相比于GUI测试,业界广泛认为API测试更适合应用自动化测试和持续测试连续测试方法(尤其与敏捷软件开发方法和DevOps方法结合时)。[3] 原因如下:
- 系统的复杂性: GUI测试无法充分验证所有功能路径及有着复杂结构的后端API/服务。
- 发布周期、反馈周期短:采用敏捷开发和DevOps的团队工作周期相对较短,经常按照客户反馈修改产品,因而GUI变动可能比较频繁,测试脚本无法固定。
由于这些原因,API被认为是待测系统中最稳定的界面,开发人员应当减轻他们对GUI测试的依赖,更多的向API测试中投入精力[4]。
将API测试自动化的一大优点便是测试覆盖面可以变得非常大,绝大多数的测试都可以自动化,这样更多的边缘就能被测试覆盖到,可以有效地减轻边缘缺陷造成的软件问题。 这样之后,也可以保留一部分GUI测试来针对系统级典型用户场景进行迁移、可用性的测试。[3][4][7]
API测试应用场景
API测试通常应用在下列测试当中[7]:
单元测试
在计算机编程中,单元测试(英语:Unit Testing)又称为模块测试,是针对程序模块(软件设计的最小单位)进行函数级正确性检验的测试工作[8]。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、或者派生类(子类)中的方法。
通常来说,程式设计师每修改一次程式就会进行最少一次单元测试,在编写程式的过程中前后很可能要进行多次单元测试,以证实程式达到软件规格书要求的工作目标——没有程序错误。
功能测试
功能测试是一种质量保证流程,是一种基于测试用例的软件组件规范的黑盒测试[9]。在这种测试当中,被测函数是通过检查输入和输出是否合理来测试的,很少考虑内部程序结构(不像白盒测试)。它是一种比单元测试规模更大的的测试,针对由多个单元构成的某一特定功能进行的测试, 包括测试用例的定义、执行、验证和回归测试[10]。
负载测试
负载测试有时称为极限测试(Extreme),这个术语在专业软件测试社区中以不同的方式使用[11] 。它通常是指通过模拟多个用户同时访问软件程序来模拟软件实际使用场景中会遇到的情况并对其进行测试。因此,这种测试在测试多用户系统时很常见。这种测试通常使用客户机/服务器模型(如web服务器)构建。然而,其他软件也可能需要进行负载测试。例如,文字处理器或图形编辑器可能遇到读取非常大文档的情况;而一个金融方案可能会被要求按照总共几年以上的数据生成一份报告。因此负载测试广泛应用于各中软件的开发中。负载测试最好模拟实际使用情况直接进行测试,而不是使用理论或分析模型“模拟”。
运行错误检测
运行错误指的是尽管程序可以通过编译开始执行,但是在执行过程中发生异常,提前退出程序。最常见的是指针越界,打开文件失败继续读取文件,资源泄露(如内存泄漏、死锁)等。总而言之是让计算机执行一些不能执行的语句时抛出的错误[12]。
网页UI测试
是集成测试的一部分,也涵盖API测试的内容[15]。
互操作性测试
互操作性(英文:Interoperability;中文又称为:协同工作能力,互用性)作为一种特性,它指的是不同的系统和组织机构之间相互合作,协同工作(即互操作)的能力。系统工程设计方面常常会用到这条术语。通过测试在不同环境下调用API时,API给出的功能反馈是否符合预期来测试待测系统的兼容性则是互操作性测试侧重的内容[16]。
Web服务规范测试(WS-*)
测试待测系统(一般针对应用SOAP协议的系统)是否符合WS-*规范[17]。
渗透测试
渗透测试是指一个具备资安知识与经验、技术人员受雇主所托,为雇主的网路设备、主机,模拟骇客的手法对网路或主机进行攻击测试,为的是发掘系统漏洞、并提出改善方法。这种攻击通常是出于善意的。对于API而言,这种测试则指的是通过渗透手段测试某个API中是否有可以利用漏洞[18]。
API测试软件
- SoapUI
- Paw
- SOAtest
外部链接
- 51Testing 安全测试专题 (页面存档备份,存于)
参考文献
- Testing APIs protects applications and reputations (页面存档备份,存于), by Amy Reichert, SearchSoftwareQuality March 2015
- All About API Testing: An Interview with Jonathan Cooper (页面存档备份,存于), by Cameron Philipp-Edmonds, Stickyminds August 19, 2014
- The Forrester Wave™ Evaluation Of Functional Test Automation (FTA) Is Out And It's All About Going Beyond GUI Testing 的存檔,存档日期2015-05-28., by Diego Lo Giudice, Forrester April 23, 2015
- Produce Better Software by Using a Layered Testing Strategy (页面存档备份,存于), by SEAN Kenefick, Gartner January 7, 2014
- Onus for third-party APIs is on enterprise developers (页面存档备份,存于), by Amy Reichert, SearchSoftwareQuality July 2014
- Accelerate Development with Automated Testing, by Nathan Wilson, Gartner December 30, 2013
- Cohn, Mike. . Addison-Wesley Professional. 2009: 312. ISBN 978-0321579362.
- 孙立财; 尹海波; 张巍. . 光电技术应用. 2006, 21 (2): 36–38 [2019-08-02]. (原始内容存档于2019-08-02).
- Prasad, Dr. K.V.K.K. (2008) ISTQB Certification Study Guide, Wiley, ISBN 978-81-7722-711-6, p. vi
- . www.51testing.com. [2019-08-02]. (原始内容存档于2019-08-02).
- Wescott, Bob. . CreateSpace. 2013. ISBN 978-1482657753.
- . cloud.tencent.com. [2019-08-02]. (原始内容存档于2019-08-02).
- . www.51testing.com. [2019-08-02]. (原始内容存档于2020-09-21).
- . www.ibm.com. [2019-08-02]. (原始内容存档于2019-08-02) (中文(中国大陆)).
- . xz.aliyun.com. [2019-08-02]. (原始内容存档于2019-08-02).
- . web.archive.org. 2008-09-19 [2019-08-02]. (原始内容存档于2008-09-19).
- . docs.oasis-open.org. [2019-08-02]. (原始内容存档于2010-07-07).
- . www.51testing.com. [2019-08-02]. (原始内容存档于2020-09-21).
- Barton Miller (2008). "Preface". In Ari Takanen, Jared DeMott and Charlie Miller, Fuzzing for Software Security Testing and Quality Assurance, ISBN 978-1-59693-214-2