云端接口测试（云端接口什么意思）

本篇文章给大家谈谈云端接口测试，以及云端接口什么意思对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享云端接口测试的知识，其中也会对云端接口什么意思进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Apifox写接口自动化测试用例总结-2
• 2、敏捷交付中的自动化测试
• 3、如何对API进行负载测试与调优（一）

Apifox写接口自动化测试用例总结-2

下面从以下几个方面来进行总结：
1.设置环境
2.设置变量
3.自定义脚本写法
4.python脚本调用

在界面的右上角，是 环境管理 的入口，选择管理环境后进入。

可以在左侧新建或删除环境，右侧可以对某个环境进行编辑。

如果在系统测试时需要多个系统来测试，可以在添加默认服务的基础上，再添加其他系统的URL，在编写对应的接口时，手动选择对应服务信息。

根据需要，可以在页面右上角，快速切换为你所需要的环境。

打开环境管理（软件右上角设置形状的按钮），选择全局变量 tab。

1.添加一个名为my_variable的变量，将本地值设置值为hello，点击保存。
2.打开一个接口，在运行 tab （或接口用例）的参数值里输入{{my_variable}}即可引用该变量。
3.点击运行按钮，发送请求，实际运行的时候系统会将{{my_variable}}替换为hello，然后发出请求。

本地值和远程值的区别:
1.所有使用到变量的地方，实际运行的时候都是读写本地值，而不会读写远程值。
2.本地值仅存放在本地，不会同步到云端，团队成员之间也不会相互同步，适合存放token、账号、密码之类的敏感数据。
3.远程值会同步到云端，主要用来团队成员之间共享数据值。
4.注意:由于本地值仅存放在本地，使用一些清理软件清理 Apifox 文件缓存会导致本地值被清空，请务必注意。
变量类型:
1.环境变量是最常用的变量，同一个变量可以在不同的环境设置不同的值，变量值会跟随环境切换而改变。环境变量在环境管理模块设置
2.全局变量 使用方法类环境变量类似，但全局变量不会跟随环境切换而改变。
3.临时变量 仅在单次运行接口用例或测试管理里的测试用例或测试套件过程中有效，不会持久化保存。

使用方式:
以下两个环节可添加脚本：
在将请求发送到服务器之前，使用前置脚本。
收到响应后，使用 后置脚本(断言测试)。

接口请求的执行流程如下：
[全局前置脚本] - [分组前置脚本] - [接口前置脚本] - [发送接口请求] - [返回接口结果] - [全局后置脚本] - [分组后置脚本] - [接口后置脚本]
调试脚本:
调试脚本可以在 前置脚本 和 后置脚本里编写，使用console.log('hello')方式将调试信息写入控制台，打开 控制台 即可查看。

使用python进行前置脚本编写：

第三步：python环境变量配置完成后重启电脑和apifox
第四步：前置脚本编写

敏捷交付中的自动化测试

提到敏捷交付，我们总会说到持续集成，持续交付，持续发布，即频繁地交付产品特性。而我们都知道要实现真正的持续交付，必然少不了两个关键要素：

只有测试不行，只有集成工具也不行，二者需合二为一，保持相同的步调，实现持续不断的质量反馈，方能实现保质地持续发布。

可以开门见山地说：Automation Test ≠ Automation Tools ≠ Continuous Test

根据我个人的项目经验，试着画了下面这个图来表达这三者的关系。

在提及自动化测试的时候，很多人会把工具的使用等同于自动化测试。自动化测试应该是一个策略性的系统工程，不只有自动化工具。像我们的产品一样，不仅要有技术语言，还要有产品架构设计。自动化测试除了工具框架，还需要考虑：

项目的技术栈，产品架构，开发流程，基础设施，可靠的测试数据，稳定干净的测试环境，如何呈现测试报告，如何工程化测试配置，测试套件等等。

有了自动化测试还不够，我们的目的是在持续交付的过程中实现快速频繁的质量反馈，我们需要持续不断地测试（Continous Testing)。实现持续测试，不仅需要团队从文化上去支持，真正做到全员对测试和质量负责，创建Devops文化氛围，打通开发-测试-运维的壁垒；还需团队从技术上去储备知识，比如云平台、虚拟化技术，容器及相应的编排技术，甚至网络知识等等。

维基百科对自动化的解释：

In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes.

从定义可以总结出自动化测试的两个特点：

测试，质量评估的重要手段之一，而自动化测试只是测试的一种具体实现方式而已。它能释放QA的双手和一部分大脑（这部分大脑，即know knowns），将对已知特性和既定逻辑流程的检测交由计算机来完成。而QA去做更多需要思辨能力，分析判断能力的事情。例如，通过向团队提问，来澄清需求的unknowns；通过探索产品去拓宽对产品的knowns；抑或运用经验帮助团队走出Unknown Unknowns 带来的迷局。

维基百科对持续测试的解释：

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

从这个定义可以看出，持续测试的目的即在软件交付的流水线中执行自动化测试以提供对产品质量的反馈。

想强调定义里的几个关键字：automated tests, delivery pipeline, immediate feedback, business risks.

不管多火的工具，如果不能兼容项目的技术栈和基础设施，那都无处发挥其优势，流行的不一定是适合项目的。

在写自动化之前，QA需要对项目的技术栈，开发流程，和基础设施有基本的认识和了解；另外也需要了解和掌握各个工具之间的优劣，这样才能为项目选择最匹配的自动化工具。是不是像老生常谈？但是别人告诉你的经验和自己经历的实战真的两种不同的收获。就跟蹲家看电视和去现场看演唱会的区别一样，别人的经验之谈总归是别人的，自己走过的路才是自己的。

这两年 Cypress 真的很火，去年在项目上做UI自动化测试的时候，出于好奇也想实践一把。实践出真知，Cypress本身可以通过环境变量和plugin配置代理，但是不支持socks5的代理（客观现状是项目所有资产，包括测试环境都是通过socks5的代理连接），线上环境无法访问。当时还试过将socks5的代理转换成http代理，但因为Cypress本身是多线程的，而socks5只能截获第一个进程的网络通信， 即使能连通应用本身，Cypress也无法将测试过程可视化的优势发挥出来。人无完人，工具也一样，只有适合你的才是好的。

考虑自己也不会造轮子，喜欢拿来就用，加之项目上socks5代理约束，之后便转用了CodeceptJS, 几次尝试下来，觉得非常满足项目需要。下面罗列CodeceptJS 几个好用的点，具体细节请移步 官网 。

由于团队有完全的自由来选择技术栈，在做第三个产品的时候， 我们的开发小哥哥就已经不满足于只写REST API了，第三个产品开始引入GraphQL。在以前的项目上用过REST Assured 做API测试，觉得也是好用的，但当时并没有选用REST Assured, 因为在那时，刚好发现一枚ThouhgtWorks开发自己做的API功能测试工具 Pandaria 。（这也从侧面证明TW的开发很有质量意识）选择这个工具，除了自己不会造轮子，除了它支持代理，更重要的是它基于Cucumber JVM，我个人以前的项目上用过cucumber，对gherkin语法还算熟悉，还有它能提供漂亮的测试报告。它既支持REST API的测试，也支持GraphQL 的测试，完美匹配我个人的技术和项目的实际情况。

在项目做第一个规范安全流程的产品时，MVP1(Minimum Viable Product) 一完成，该产品的接口自动化测试和端到端自动化测试便实现了，并集成到了产品CI/ CD 流水线上。后来由于客户方硬件集成的问题，该产品基于MVP1进行了一次演进，从产品直接融入并规范安全流程换成了‘曲线救国’地强化安全流程，页面和接口设计也有较大变动。由于产品流程设计上的变动导致之前的接口测试和端到端的自动化测试全部都失效，需要重新编写和维护。

这个经历挺真实的，自动化是有好处，但是也是有代价的： 在MVP1，特别是POC（Proof Of Concept)阶段的产品建议不要急于做自动化，项目的初期更别尝试做UI层面的自动化。当然对工具的spike是可以的，把框架搭建好，等待特性稳定了，就可以直接加测试用例了。

我们选择自动化一定是要考虑项目是否存在客观的现实需求，在动手实施具体的自动化测试之前，一定要对自动化测试的投入产出比做一次客观理性地评估。如上图所示，自动化测试的成本相对单次（或者少量的）手动测试来说是较高的，为了少量的测试活动而做自动化，投入产出比是很低的。需要QA根据项目进度，产品演进程度，测试策略，回归频率等等做一个综合评估，找到出图中交集的点，即何时何种情况团队和产品应该必须引入自动化测试了。因为自动化前期需要投入产品分析，工具框架选型，用例设计，数据环境准备等等，后期还需要持续不断地投入人力进行及时的维护和更新以保证自动化测试的严密性和足够的覆盖率。

虽然敏捷强调质量全员负责，但我所待过的团队，做过的项目，践行得好的很少。幸运的是，现在团队的质量意识都很好。但故事一开始不都是美好的，每个团队都是在 “掉坑-反馈-调整磨合” 的循环里走向成熟的。

在交付一个微服务化的产品时，后端多个API，每个API有相应的API集成测试，产品还有UI测试，同时团队还有额外的3个产品需要维护。每个产品都有自动化测试，前端的后端的。其中一个微服务实现的产品就有四套测试，而且后续还会增加视觉测试。

在刚开始的时候，测试挂了没人去看，也没人去修。由于项目是基于 Trunk Based Development ，为了保证测试的及时性，每天不是在加新用例的路上，就是在修各种测试的路上。UI测试相较于API测试更为脆弱，需要频繁的维护成本，特别是项目基于主干开发的团队。那段时间感觉自己成了automation engineer，对产品新增的功能特性并不是非常清楚，对故事卡的可测性也没及时作出反馈，感觉自动化并未真的达到释放自己精力和时间的初衷。

如果只是QA一个人来维护管理，那么这个QA一定做不了自动化以外的事情了。ThoughtWorks好多项目都只有一个QA，我们的这个QA是Quality Analyst， 并不是Automation Engineer。敏捷项目之下，QA的首要任务应该是驱动团队各个角色对质量负责。

为了提升团队对自动化测试的重视程度， 如下是一些我个人在项目上实践过的方法：

除了以上，项目还需要有高度可视化或者能及时通知测试状态的方式。

项目上用的是Jenkins自带的 Build Monitor View。将对项目pipeline的监控投影到电视上，并配置相应的提示音，能非常及时地让团队知道最新的构建，部署，测试状态。

如下是我们项目上当前的一个流水线dashboard：

这些实践都是对‘质量全员负责’最落地的践行。我相信，每个团队是不一样的，但是敏捷QA的主要价值一定是能驱动团队为质量作出改进和贡献。

敏捷QA是对项目流程质量，产品内部质量，产品外部质量都需要负责的，而自动化测试只是质量保证的一种措施而已而非唯一措施。‘质量全员负责’的团队才能释放出你们的QA，去做更多Quality Analysis的工作，比如提更多需要思辨能力的问题以实现产品风险的识别和管理，反思开发流程以促进团队流程质量的提升，分析产品架构制定适合项目产品的整体测试策略等等。

在项目上做自动化集成到流水线的时候，有遇到一些常见的在云容器里运行测试会遇到的问题。

1）测试工具相关的

虽然很多问题都是可以从网上找到答案，但是在解决问题的时候，通常需要我们了解工具框架的工作原理，否则连搜索关键字可能都憋不出来。

2）测试报告可视化相关的

测试报告对于我们快速定位失败根因有很大的帮助，好的测试报告可以直接揭示问题的根源。在云端运行测试，我们通常希望测试工具能输出可读性强的测试报告以方便非技术人员阅读，也希望测试工具能把运行过程的细节打印在console里，以方便技术人员定位根因。

像前面提到的CodeceptJS它就提供多种不同形态的运行，并且可以运用Mocha生成各种类型的测试报告。目前市面上的测试工具，都会有对第三方库的依赖，特别是前端测试框架和工具，这个对QA或者团队的技术宽度是有一定要求的。

另外Jenkins有非常丰富的插件库，在选择测试工具的时候可以把是否有Jenkins报告可视化支持考虑进去。QA需要对Jenkins和测试工具都相当熟悉，还需要知道如何通过将某一测试工具生成的某种格式的测试报告集成在Jenkins上以方便一键获取测试报告。
像cucumber的测试报告插件：

像Allure的测试报告插件：

有了这些插件的辅助，在流水线上就一键可得测试报告，为‘质量团队负责’提供了很好的契机。

3） Pipeline as Code, 想要集成测试到流水线，不可避免是需要一些DevOps相关知识的

也许项目的需求是如何通过Jenkinsfile 并行运行各种测试，也许是通过Jenkinsfile传递测试相关参数以为云上运行测试所用，还也许你需要在Jenkinsfile里添加调试信息用以线上调试，等等。

云上运行，我们还要学会如何在一个slave 上优雅地管理运行测试的容器，不出现容器占用，slave内存不足，测试失败之后报告不可得等等问题。

所以只会自动化工具不够，只有自动化测试也不够。如果你们团队开发们没有DevOps的经验，或者他们忙于特性开发，上线冲刺，那么QA必须对Docker，Kubernetes 基本命令和用法有些了解。QA就是一个不分前后端，不挑技术栈，需要持续不断学习的角色。

会自动化工具算是有了织网的道具，有自动化测试资产算是编出了能捞鱼的网，而持续测试才能真正地实现持续交付，才算是把一张张过滤不同缺陷的网放置于了不断提交变更的交付之流中。

只有网而无法至于河里，或者不知道于何处放置，那就只能站于岸边时时撒网捕鱼，不够及时，也不算释放了捕鱼人 （QA和团队) 。

我们期望的是，各种不同的网 （自动化测试资产） ，置于不同的河段（ 软件产品不同层级：函数级别？组件级别？接口级别？系统级别？） ，过滤不同的鱼 （缺陷） ，而不管是谁 （团队的所有角色） 都可以去确认有没有捞着鱼 （测试挂了吗？为什么挂？我们对目前的变更有足够的信心吗？） ，也需要所有人时时确认我们的渔网是不是破了？ （测试覆盖率不够？断言不严谨？测试用例过时？） 。

软件交付是一项团队工作，即便自动化测试也一样需要全员协作。

文/ThoughtWorks郭泰瑜

如何对API进行负载测试与调优（一）

本文由Donny译自 3scale.com 的 《How to load test tune performance on your API》
这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。

当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。

如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。

可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。

本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！
首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。
本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Node.js API。它有三个API接口：
/question – 返回一个随机黑牌

/answer – 返回一个随机白牌
/pick – 返回一对随机的问题与答案

你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。

所以，你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：
（1）每秒请求数的平均吞吐量（Average throughput in requests per second）

（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）

（3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？）

（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）

另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：

（1）重复负载生成（Repetitive load generation）

（2）模拟流量模式

（3）真实流量

通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。

找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际操作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。

最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。
好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。

如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。

在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4.large 实例就够了。

注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4.large

接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4.xlarge AWS服务器

我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。
我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。

JMeter

在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：

（1）用来注入负载测试的线程
（2）参数化测试中使用的HTTP请求

（3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果

优点：

（1）它是功能性负载测试的最好工具。你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。

（2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传

（3）可扩展性强，有很多社区插件可以修改或扩展内置的行为

（4）开源并且免费

缺点：

（1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。

（2）测试高负载时，操作步骤很麻烦。你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。

（3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。

JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。
Wrk

Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。wrk和ab完全不同于JMeter：

（1）一切都是可以通过命令行工具配置和执行的。

（2）配置少但强大，只有基本生成HTTP负载的必要几项配置

（3）性能强悍
然而，和传统ab工具相比还是有几个优势的地方，主要是：

（1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载

（2）利用Lua脚本很容易进行扩展默认的行为

不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。wrk用起来很快就可以上手。
Vegeta

Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。它专注于如何达到与维持每秒请求数速率。也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。

SaaS 工具

正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。最近有些产品提供负载测试服务。我们试过两个， Loader.io 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。

注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。
Blazemeter

这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。
Loader.io

它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。它有你所需要的功能和漂亮的可视报告。 Loader.io 的免费版还是不错的，每秒最多可以有10000次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。

我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。
我们先尝试找到我们的API可以承受的最大吞吐量。在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。这个吞吐量就可作为我们后面测试要用的每秒请求数。

同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。
我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。我们使用  Keymetrics.io  和  PM2  模块。

我们的Node.js应用运行了一个非常简单的HTTP 服务。Node.js是单线程设计的，但为了利用c4.large AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。
由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。
我们先使用Loader.io对API进行测试。以下是持续30秒，每秒10,000次请求的测试结果，10000次请求是Loader.io免费版中允许的最大吞吐量。
在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。
这表示我们的API可能还可以处理更高的吞吐量。我们接下来通过运行wrk进行第二次测试证实了这一点。我们的目标就是要将我们的API服务器性能推到极限。
wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions

这里是我们对这个测试做了多次重复测试的结果：
Running 1m test @ http://api-server/question

4 threads and 1000 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 62.23ms 30.85ms 1.35s 99.39%

Req/Sec 4.07k 357.61 5.27k 94.29%

Latency Distribution

50% 60.04ms

75% 63.85ms

90% 64.17ms

99% 75.86ms

972482 requests in 1.00m, 189.89MB read

Requests/sec: 16206.04

Transfer/sec: 3.16MB

结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有75.86毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：
我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。

请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。
本文译自： How to load test tune performance on your API 关于云端接口测试和云端接口什么意思的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 云端接口测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于云端接口什么意思、云端接口测试的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。