软件接口与性能测试,接口测试与性能测试有什么区别？

最近我在一个论坛上看到了一个关于性能测试和接口测试的经典问题，问题如下：

问题：后端性能测试，一个功能其实都是由后台多个接口组成的。

例如一个单据的保存，可能后台需要调用几个接口。用LR录制这个功能做性能测试。和把它这个功能调用的几个接口连接起来一起做接口性能测试有什么区别呢？

相信很多开始测试自动化的测试同学的入门都是从一些培训班或者网上课程开始的。很多培训在讲授接口测试或者性能测试的时候往往是拿LoadRunner或者jmeter去演示测试过程的。通常的课程安排一般先拿LoadRunner(或者jmeter)讲接口测试，然后继续使用LoadRunner(或者jmeter)去讲性能测试。

无论是接口测试还是性能测试，貌似老师们讲的步骤好像都差不多，先录制接口，然后配置场景，然后执行测试场景，给人感觉好像没啥差别。感觉好晕。那到底两者差别在哪里呢？我们从入门者的角度来谈谈差别吧！

从三个部分去阐述两者的关联和区别：

1、测试与工具的关系

2、接口测试和性能测试的侧重点

3、在实际场景中二者的配置区别

第一部分，测试与工具的关系

首先我们要正视一个理念，LoadRunner和Jmeter只是一个工具，而培训班大力推崇的都是工具培训，容易让我们落入一种XXX就是性能测试的赶脚，其实不然(差别蛮多，后面会单独去写文章分享)，性能测试包含了工具(LoadRunner和Jmeter)，工具仅仅是扮演了性能测试中的一个执行环节而已。

我们可以拿LoadRunner(Jmeter)做接口测试，当然也可以拿到做性能测试。所以工具是什么不重要，关键在于我们怎么去使用它，例如下面一个生活中的例子：铁锹。我们可以拿铁锹来铲土，也可以用铁锹来炒大锅饭，是不是就像LoadRunner既能做接口测试，又能做性能测试一样？

第二部分，性能测试和接口测试的区别。

测试分很多种，如果细细罗列，从单测，接口，功能，性能，UI，至少有五层，那其实区分这些测试类型的关键点就在于测试的侧重点不一样，接口测试是针对后端开发的接口(不一定是http的，也有可能是tcp的)，而性能测试是偏重于产品的各方面各阶段性能(接口的性能，页面的性能，app的性能)，可以说性能测试的覆盖度比接口更大一些。那我们就拿http类型的接口测试和性能测试举例，有啥侧重点区别呢？

简单来说，它俩区别就在于性能测试有多用户(并发)的概念，而接口测试只是单用户场景。我们做接口测试是是用于验证接口的请求和返回是否匹配(其实可以理解成接口测试也是一种功能测试)；而性能测试则是很多人同时在做这种接口测试，更侧重于真实的用户场景。因为我们研发完的产品投入市场后，不会就专门给某一个人使用功能，肯定是会有很多人同时在用我们的产品功能。那在这里，很多人同时在用其实就是性能的一个关键点。

所以总结第二点：性能测试近乎等同于很多用户同时在做接口测试。

第三部分，在实际场景中二者的配置区别

我们就简单地拿LR做接口测试和性能测试的过程为例吧，拿LR执行测试对于大多数人来说就三步：录制接口(或者接口抓包)，配置场景，执行测试场景。

录制接口这一步是没有区别的，因为我们刚才讲到过，性能测试其实也是一种特殊的接口测试。那配置场景这一步有区别吗？可能很多人也说没有区别，但其实是有的，我们举例几个区别。如果是性能测试，首先要配置多用户(或者说多线程)，而接口测试不用；其次如果是性能测试，建议关掉断言(否则可能压不上去，因为断言会耗费LR或者Jmeter自身的性能)；最后如果是性能测试，如果压测不上去，还可能需要做分布式(简单来说，就是多台机器同时执行性能测试)。

那第三步：执行测试场景的时候有什么区别吗？刚才说到，接口测试一般是用断言来验证接口的正确性，那性能测试怎么去验证呢？在执行性能测试场景的时候，我们抛弃断言，要加入另外的校验方式：

最基本的三个点：

1、多用户下接口的响应时间，qps/tps(每秒请求量),出错率。

2、服务器上的资源监控(cpu，内存，io)。

3、被测服务的资源监控(多个服务的cpu，内存，io)以及错误日志。

以上三点都是衡量性能测试的标准，也是当执行性能测试场景出问题时候，用于定位问题的重要证据，所以我们可以知道，当接口测试出了问题，我们可以通过断言迅速知道出了问题；而性能测试出了问题，需要从多个方面多个维度去调试定位，性能测试对于系统架构的理解能力要求更高！