我正在申请质量检查职位,而SDET则问了我一个问题:

如何测试后端API?

在采访中。

我不确定我回答正确了。只是想知道我是否可以从某人那里得到一些意见。

评论

“后端”形容词具有误导性,这个问题总体上是开放性的。您能更具体一点吗?

@Aziz-您如何回答?

您是否有意将问题标记为“手动测试”?您是否希望手动测试后端API?当然,可以使用SoapUI之类的GUI工具来手动探索API行为,但是从长远来看,这是罕见的做法。

@Bj Rollison,您为什么认为“后端”形容词具有误导性?对我来说,它稍微缩小了上下文范围,这意味着该应用程序还包含一个GUI前端部分。还有一些根本没有GUI的应用程序,在这些应用程序中,API可以被视为一种API。

@dzieciou-我假设您所指的是无头代理,其中没有GUI(图形用户界面),但仍然有(通常)API的接口。

#1 楼

测试API的方式取决于很多事情。该API是将由某些外部人员/系统使用的公共API,还是它是大型产品基础结构的一部分? API是一个通用术语,有时用于描述从COM接口到您可以引用的DLL或JAR到REST Web服务的所有内容。可以将不同的方法应用于测试这些不同的事物。

通常,如果API是基础结构的一部分,则可以通过单元测试和使用消耗它的产品的使用来对它进行彻底的测试。

如果它是一个外部可使用的API,那么您需要做得更透彻,因为人们可以以不同于您预期的方式使用它,并以非常不同的格式发送数据,等等。通常,它还需要合理,直观并在外部可消耗的情况下有据可查。您还需要更加注意私有和公开的内容,这对于仅由单个产品使用的API可能不那么重要。

测试API几乎总是需要您创建某种用于测试目的的消费者。您必须能够与API进行交互。使用者通常非常简单-或使用现有工具-并由自动化测试用例驱动,而不是由手动用户交互驱动,尽管我看到人们为测试目的创建了复杂的GUI应用程序的情况,以及仍然主要通过手动方式进行测试的情况锻炼该应用程序。

如果API具有依赖关系,则可以选择模拟那些依赖关系,以便可以更彻底地测试所有这些交互并命中所有正负代码路径。例如,如果API与数据库交互并具有创建,修改和删除数据的能力,则您可能希望模拟与数据库的交互以更轻松地测试用例,例如在不存在记录或记录不存在时删除记录。是最终记录,或者是由于依赖关系而无法将其删除,甚至是与数据库的连接不可用时,您都可以查看API如何处理这些情况。

评论


好答案。我还要特别指出网络是您在测试中要考虑的依赖项中的另一种-当网络变得不稳定时,后端必须表现合理。 (怪异的意思是缺少响应和会话中断。)

–布鲁斯
2014年8月18日在23:03

另外,如果后端预期流量很大,那么它将带来其他整个类别的负载和性能测试。

–布鲁斯
2014年8月18日23:06

-1,因为您何时才能创建用于测试API的应用程序?相反,使用Postman之类的工具可以进行API测试。

– FDM
17年6月1日于13:51

@FDM我只是意味着您需要编写一些代码以调用API,这很可能只是一些测试以及诸如邮递员之类的测试库或工具。我对答案进行了更清晰的编辑。

–山姆·伍兹(Sam Woods)
17年6月14日在18:49

#2 楼

测试API并不是测试API时唯一需要做出的决定。对于任何测试任务,您都需要确定:



您正在测试程序的哪些方面?您想在API测试中涵盖哪些应用程序功能?您是否要验证一些有状态的情况(例如,当用户登录时)?或者,也许您想验证API在不同配置下的行为方式?

您正在寻找什么类型的问题?应用程序的哪一部分最有可能失败?在什么条件下?是否存在功能或性能问题?这应该可以帮助您了解使用API​​而不是使用前端测试更容易/更快/更便宜的场景。

您如何判断测试是否通过?向API提出请求后,如何评估系统是否正常运行?您将只评估显式的API响应(例如,它确认已发送电子邮件)还是要验证其实际内容(电子邮件实际上已发送给您的帐户)?此外,您如何知道给定API调用的预期结果?

具体要执行什么任务?根据先前答案中的指示,您可以考虑进行探索性测试,只是在探索API行为,寻找某些特定的错误或预先定义全面的测试用例时?您是手动执行还是自动执行?您将执行一些功能测试还是性能或负载测试?

谁来进行测试?您将成为测试API的人,还是可能会有一些人编写客户应用程序以测试API的不同部分?您对与API相关的技术可以自动执行测试了解多少?答案将帮助您选择正确的工具进行测试。

现在,您可能掌握的信息太少,无法做出可以使您,面试官和公司利益相关者满意的最终决定。因此,您可以向访调员询问有关后端API性质的更多问题:


API的使用者是谁?前端层是SUT还是外部客户端应用程序的一部分?也许没有前端?这是仅少数人使用的公共API还是内部API?答案将告诉您应该如何彻底测试API?
端到端测试(包括前端)涵盖了哪些场景,尚未涵盖哪些场景?通过前端测试时面临哪些挑战?答案将指导您选择应该涵盖和不应该涵盖的场景类型。例如,如果仅在后端侧实现了无效的输入验证功能,则这是API测试中需要强调的一个领域。
使用什么技术公开API? SOAP或REST Web服务,RMI,CORBA,命令行,COM等。答案将暗示您应使用哪种工具或编程语言来实现测试用例。
是否有一些关于API的正式规范?或者您需要以某种方式猜测预期的行为,例如从UI规范中?
后端是否与系统中的其他组件对话?到数据库?是否与外部服务联系?


#3 楼

总的来说,我认为您不应该期望将模拟的前端连接到用于测试的API调用上(但是如果您幸运的话!)。相反,通常会使用单元测试和集成测试来测试API函数。

您需要对API函数调用本身具有可见性,因此测试将是白盒或至少是灰盒。应该为您提供一个规范文档,其中应列出每个API函数的签名(输入参数,函数或方法名称以及返回类型)。然后,从Spec Doc中编写单元测试(在我的情况下,我更喜欢PHPUnit)来检查每个API函数的输入和返回,例如测试边界值和空输入。

最后,如果API是服务的一部分,那么您还需要进行集成测试。这些测试将类似于该服务的“端到端”测试,其中您将测试包括对API函数的调用在内的整个功能。通常,您将在客户入口点开始进行集成测试,并在对客户正确的情况下验证退货是否有效。就个人而言,我更喜欢使用Behat Mink或Cucumber进行功能测试。

评论


非常感谢您的投入。因此要澄清一下,对于集成测试,可以使用手动/自动(Behat Min或Cucumber)UI测试对吗?

–阿兹
2013年9月5日在16:32

集成或功能测试通常将具有某种可用的界面,因为理想情况下,功能应为客户可交付使用。因此,可以使用Web驱动程序(例如Selenium)来完成UI测试。但是原始问题中的后端API意味着没有可用的接口,因此有必要直接测试功能。

–弗朗西斯
2013年9月5日17:34

#4 楼

在测试中,您需要理解和重点关注两个方面。


了解要测试的API的用途。这是为了什么这将如何使用?回答这些问题应为您提供与您的上下文有关的测试思路。
以下是根据我在测试中的个人经验提供的示例测试思路:


输入数据


您的数据来自哪里?数据库,其他api等?


数据/应用逻辑


如何解析数据?
是否有一个
如何存储已解析的数据?
数据是否需要进一步的“按摩”输出?



数据输出


API端点是什么?
每个端点的值类型是什么(字符串,整数等)?
是什么决定了正确性?每个端点中的值是什么?
使用的API协议是什么? (REST,SOAP等)


交付


关于帐户访问是否有特殊规则?
有使用限制吗?





有很多工具可以使用。进行功能测试时,各种chrome和firefox插件将使您的生活更轻松。 SOAPUI也是一个非常方便的桌面客户端。如果您方便使用编程语言,则Python,PHP和Ruby确实具有易于使用的REST API库。

模拟也是一种最小化依赖关系的方法,但是如果使用不当,这可能会失控。我一直很喜欢使用mocky.io,因此即使在开发人员完成代码编写之前,我也可以开始编写测试。

#5 楼

实际上,您的问题很好,但答案可能过于笼统,因为它是一个笼统的问题。

我们属于在线媒体领域。我们曾经做过的后端API测试部分包括:


首先,我们了解API角色所在的系统的功能。
然后我们开发了使用JS和后端中使用的API进行的端到端测试。
一旦这些测试稳定下来,我们就使用Jenkins作为持续集成在特定时间间隔后触发这些测试。
然后用于在詹金斯检验的输出中观察结果。如果测试通过,那么我们就没事了,但是如果测试失败,那么我们通常会进行调查,然后在该程序上执行错误。

通过这种方式,我们可以测试后端API。

评论


最后两点并非特定于测试后端API。您可以使用CI并调查任何自动化测试的失败情况。

– dzieciou
2013年9月8日19:53

@dzieciou:是的,这是正确的。我仍然提到它们具有完整的测试流程。您可以使用其他方式进行CI。

–talktokets
2013年9月9日在16:48

#6 楼

在后端API测试中,所使用的工具取决于需要测试的API的类型。


REST服务:对于HTTP GET方法,您可以简单地使用Web浏览器,对于其他HTTP方法可能需要单独的工具,例如Chrome,curl Unix命令或SOAPUI的Postman插件。
SOAP服务:您需要专用的软件,例如SOAPUI。


评论


请删除英语教师版本...

–杰·帕塔克(Jay Pathak)
18年3月21日在9:40