提示：以下是本篇文章正文内容，下面案例可供参考
一、接口
#1. http和https的区别
基本概念
HTTP（80）:超文本传输协议
- 基于请求和响应，无状态的，应用层的协议
- 长基于TCP/IP协议传输数据
- 以明文的方式发送内容
HTTPS（443）:超文本传输协议
- 安全套接字层超文本传输协议
- 通过计算机网络进行安全通信的传输协议
- 在基于HTTP协议的基础上加入了SSL/TLS协议
- HTTP + 加密 + 认证 + 完整性保护 = HTTPS
通讯过程
区别
| 安全性 | 通讯方式 | 默认端口 | 证书 | |
|---|---|---|---|---|
| HTTP | 低 | 三次握手，四次挥手 | 80 | 不需要 |
| HTTPS | 高 | SSL/TLS安全连接 | 443 | 需要 |
#2. tcp三次握手与四次挥手
三次握手
三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。
- 第一次握手：客户端发送网络包，服务端收到了。
这时，服务端得出结论：客户端的发送能力、服务端的接收能力是正常的。 - 第二次握手：服务端发包，客户端收到了。
这时，客户端得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。 - 第三次握手：客户端发包，服务端收到了。
可以携带数据
这时，服务端得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
因此，需要三次握手才能确认双方的接收与发送能力是否正常。
四次挥手
建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
TCP 连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务端均可主动发起挥手动作。
刚开始双方都处于ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：
参考文章：https://www.xiaolincoding.com/network/3_tcp/tcp_interview.html#%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81-tcp-%E5%8D%8F%E8%AE%AE-tcp-%E5%B7%A5%E4%BD%9C%E5%9C%A8%E5%93%AA%E4%B8%80%E5%B1%82
#3. get和post的区别
#4. session，cookie和token的区别
Cookie：浏览器接受服务器端Set_cookie指令，并且把cookie保存在电脑上，每个网站保存的cookie只作用于自己的网站
Session：数据存储到服务器端，只把关联数据的加密串放在Cookie中标记
Token： 是一个用户请求时附带的请求字段，用于验证身份与权限
可参考企业微信接口文档，GitHub：
- 凭借认证信息获取token，或通过后台配置好token
- 在相关请求中使用token，多数以query参数的形式提供
相关文档可参考：点击此处可学习更多内容
#5. 接口请求返回的状态码
1xx -代表请求已被接受，需要继续处理，这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束：
100 （继续）初始的请求已经接受， 请求者应当继续提出请求。
101 （切换协议） 请求者已要求服务器切换协议，服务器听从客户的请求已确认并准备切换。
2xx - 代表请求已成功被服务器接收、理解、并接受：
200 （请求成功），服务器成功返回请求的数据。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求。
3xx - 表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向：
300 （多种选择） 针对请求，服务器可执行多种操作。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET
或 HEAD 请求的响应）时，会自动将请求者转到新位置。**
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用
原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响
应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，
不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响
应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使
用原有位置来进行以后的请求。
4xx - 这些状态代码表示请求可能出错，妨碍了服务器的处理：
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此
响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。**
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授
权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲
突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件）服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的
处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此
状态代码。
417 （未满足期望值） 服务器未满足”期望”请求标头字段的要求。
5xx - 表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生：
500 （服务器内部错误） 服务器遇到错误，无法完成请求。**
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。
#6. URI 和URL的比较
URI 统一资源标示符，用来唯一的表示一个资源
URL 统一资源定位符，是一种具体的URI
URL的结构：https://www.baidu.com/s？wd=%E9%9C%8D%E6%A0%BC%E6%B2%83%E5%85%B9&fenlei=256&rsv_pq=0xd7bcdea400014620
1. 协议 https
2. 域名 /www.baidu.com
3. 端口 默认端口443
4. 路径 /s
5. 请求参数 wd=%E9%9C%8D%E6%A0%BC%E6%B2%83%E5%85%B9&fenlei=256&rsv_pq=0xd7bcdea400014620
#7. 接口测试用例设计思路
#8. 如果接口出现异常，该如何分析异常原因？
要分析接口异常的原因，可以遵循以下步骤：
- 查看日志
如果接口使用了日志系统，可以查看日志文件以了解接口在运行时的详细情况，包括请求参数、返回结果、异常堆栈信息等。 - 抓包分析
使用抓包工具可以捕获网络流量，包括请求和响应的数据包，然后对这些数据进行分析 - 分析代码
检查异常对应代码中可能出现的空指针、数组越界等异常情况。 - 联系开发人员
如果无法找到问题所在，可以联系开发人员，以协助排查问题。
#9. 接口测试能发现哪些问题？
做接口测试可以发现很多在页面上操作发现不了的 Bug：
1. 可以检验接口是否按照约定返回响应
2. 可以修改请求参数，突破前端页面输入限制，检验系统的异常处理能力。比如边界值处理错误，输入异常值接口抛异常，输入参数多或者少接口抛异常等等
3. 可以检验系统的安全性。比如明文传输、返回结果含有敏感信息，没对用户身份信息做校验，没做恶意请求拦截等等
4. 可以通过接口测试并发场景，检验系统的性能和稳定性。比如接口并发多条相同操作，响应时间过长，接口压测出现瓶颈等等
通过接口测试，可以让接口质量得到保证，这样前端也会更稳定，功能测试专注与发现前端的 Bug 即可。
#10. 请谈谈接口测试的优势都有哪些？
1. 高效：接口测试比界面测试更快。
2. 可重复性：接口测试可以编写自动化测试脚本，保证测试的可重复性。
3. 覆盖范围更广：接口测试可以测试应用程序的每个接口，覆盖更广泛的测试场景。
4. 稳定性更好：接口测试可以发现和解决应用程序接口的问题，提高应用程序的稳定性和可靠性。
5. 易于集成：接口测试可以更容易地集成到持续集成/持续交付流程中。
6. 提前发现问题：接口测试可以早期检测到问题。
7. 更好的协作：接口测试鼓励团队之间更好的协作。
8. 提高安全性：接口测试有助于识别安全漏洞。
9. 成本效益：接口测试比其他形式的测试更具成本效益。
10.更好的用户体验：接口测试有助于确保软件易于使用并提供良好的用户体验。
#11. 怎么使用postman批量运行多个接口请求？
参考文章地址：点击此处，了解更多内容
1. 创建一个测试集管理多个接口请求
2. 把原有的接口保存到测试集中，或者直接在测试集中添加请求。保证想要批量运行的接口请求都在一个测试集当中即可。
3. 选择测试集中的 Run collection，进入运行测试集的界面
4. 设置测试集运行的迭代次数、延迟时间、使用的测试数据文件，勾选保存响应、保持变量值、测试集运行完毕后保存 cookie
5. 点击 Run 按钮运行测试集
6. 查看测试集运行结果，可以查看全部接口运行结果，也可以分别查看通过的接口或者失败的接口信息。
二、接口自动化
#12. 接口测试如何设计测试用例？
主要从四个方面来设计接口用例：功能，业务逻辑，异常，安全。
功能：是否符合需求
1）从用户角度出发看接口能否实现业务需求，功能是否正常；
2）功能是否按照接口文档实现；
举例：比如博客园添加随笔，需要登录才能添加。也就是业务要求不支持游客添加随笔功能，如果设计一个没有登录的用户，然后去测试添加随笔接口，结果接口能添加到随笔，说明功能不正常，不符合需求和接口文档描述。
业务逻辑：是否依赖业务
1）接口实现逻辑；
2）业务逻辑覆盖（语句/条件/分支/判定/…）；
举例：该接口调用之前，需要调用登录接口，如果不登录也能请求数据，不符合业务逻辑。
异常：参数异常和数据异常
1）参数异常：关键字参数，参数为空，多，少参数，错误参数；
2）数据异常：关键字数据，数据为空，长度不一致，错误数据；
举例：不管数据异常还是参数异常，测试点差不多，一个参数有key和value，key表示参数，value表示数据。第一，看看参数和数据能不能支持关键字，例如Java中的保留关键字等等；第二就是参数和数据都为空，看看是否做了判断；第三，参数多和少，例如有两个参数的接口，需要设计一个包含三个参数的用例，一个只有一个参数的用例。数据长度不一致，例如设计很长的字符串是否支持，因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据，如故意输错单词等等。
安全测试用例设计：
- cookie：有cookie才能获取数据，如果不带cookie还有信息返回，说明有问题；
- header：正常接口带header信息，删除header看是否能够返回数据；
- 唯一识别码：app手机识别码，一般是唯一的；
- 文本输入框sql注入和xss攻击。
#13.介绍下接口自动化测试的过程？
接口自动化测试是软件测试中非常重要的一个方面，它可以提高测试效率，降低测试成本，并提供可靠的回归测试，下面是一个简单的接口自动化测试的步骤：
- 确定测试的范围：根据项目需求，确定需要自动化测试的接口。
- 准备测试数据：准备相关的测试数据，包括请求的参数和期望的响应数据。
- 编写测试脚本：选择一个合适的自动化测试工具（如Postman、RestAssured等），使用工具提供的接口测试功能编写测试脚本。测试脚本应包括对接口的请求和断言响应结果的代码。
- 执行测试脚本：运行编写的测试脚本，发送请求并获得响应结果。
- 断言和生成报告：对脚本执行结果进行断言，验证实际的响应结果是否与期望值一致。根据测试结果生成测试报告，记录测试覆盖率和执行情况。
- 执行回归测试：随着项目的迭代和需求的变更，及时更新测试脚本，并执行回归测试，确保修改不会对其他功能产生负面影响。
在接口自动化测试过程中，可以根据具体的项目需求，使用不同的自动化测试工具和技术，以及制定相应的测试策略和计划来保证测试的顺利进行。
#14. 在你们项目上，如何实现接口自动化的？
在我所负责的项目，主要使用的是Java的HttpClient库实现接口自动化的。另外还可以使用RestAssured、HttpClient或者OkHttp等HTTP客户端库：
RestAssured
下面是一个使用RestAssured进行接口自动化测试的简单示例：
-
首先，确保您的项目中已经引入了RestAssured库的依赖，可以通过Maven或Gradle进行引入。
-
创建一个测试类，使用JUnit或者TestNG等测试框架进行测试方法的定义和管理。
-
在测试类中，使用RestAssured提供的API发送HTTP请求，并对响应进行断言。
java
import io.restassured.RestAssured;
import io.restassured.http.ContentType;
import io.restassured.response.Response;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.given;
import static org.junit.jupiter.api.Assertions.assertEquals;
public class APITest {
@Test
public void testPostAPI() {
RestAssured.baseURI = "http://api.example.com";
String requestBody = "{ \"name\": \"John\", \"age\": 25 }"; // 设置请求参数，JSON格式的字符串
Response response = given()
.contentType(ContentType.JSON) // 设置请求头为JSON格式
.body(requestBody) // 设置请求体为JSON格式参数
.when()
.post("/users"); // 发送POST请求
assertEquals(200, response.getStatusCode()); // 断言响应状态码为200
String responseBody = response.getBody().asString();
// 进行更多的断言和验证
assertEquals("User created successfully", responseBody); // 假设响应体为"User created successfully"
// ...
}
// 可以添加更多的测试方法来测试其他的接口和接口功能
}
在上面的示例中，我们使用given()方法来构建请求，通过contentType()方法设置请求头为JSON格式。然后，通过body()方法将JSON格式的参数作为请求体传递。最后，使用when()方法和HTTP方法（例如post()）发送请求。当然，我们可能还要设置基本的URL（使用RestAssured.baseURI）和导入相关的依赖，例如io.restassured.RestAssured和io.restassured.response.Response。
- 运行测试类，测试框架会执行测试方法，并输出相应的测试结果。
需要注意的是，这只是一个测试示例，并不涵盖所有的情况和功能。实际的接口自动化测试中，可能还需要处理请求参数、请求头信息、验证响应内容等更多的操作。您可以根据具体的项目需求和接口要求来编写对应的测试方法和逻辑。
HttpClient库
和restAssured使用方式一致，参考一下代码：
java
import org.apache.http.HttpEntity;
import org.apache.http.HttpResponse;
import org.apache.http.NameValuePair;
import org.apache.http.client.HttpClient;
import org.apache.http.client.entity.UrlEncodedFormEntity;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.impl.client.HttpClientBuilder;
import org.apache.http.message.BasicNameValuePair;
import org.apache.http.util.EntityUtils;
import org.junit.jupiter.api.Test;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.util.ArrayList;
import java.util.List;
public class APITest {
@Test
public void testPostAPI() throws IOException {
HttpClient httpClient = HttpClientBuilder.create().build();
HttpPost request = new HttpPost("http://api.example.com/users"); // 设置API的URL
// 设置请求参数
List<NameValuePair> params = new ArrayList<>();
params.add(new BasicNameValuePair("name", "John"));
params.add(new BasicNameValuePair("age", "25"));
// ...,此处可添加更多的参数
try {
request.setEntity(new UrlEncodedFormEntity(params));
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
HttpResponse response = httpClient.execute(request); // 发送POST请求
// 处理响应
HttpEntity entity = response.getEntity();
String responseBody = EntityUtils.toString(entity);
// 进行断言和验证
System.out.println(responseBody);
// ...
}
// 可以添加更多的测试方法来测试其他的接口和接口功能
}
在上面的示例中，我们使用HttpPost来发送POST请求，并通过UrlEncodedFormEntity设置请求参数。我们首先创建一个NameValuePair列表，每个NameValuePair代表一个参数的键值对。然后将参数列表设置为请求实体的内容。
#15. 接口测试断言从哪些方面去设计?
接口测试断言可以从以下五个方面进行设计：
-
响应码：检查响应码是否符合预期，用来判断测试用例是否执行成功（针对http接口）；
-
关键字：验证关键字是否符合预期，用来判断测试用例是否执行成功；
-
正则匹配：当一个接口返回的内容较多，并且有一定规律时，可通过正则表达式来校验接口返回的信息来判定测试用例是否执行成功；
-
数据库匹配核对：比如对查询一个接口返回的数据进行验证时，可通过编写sql语句查询结果，然后将sql语句执行后数据库返回的结果与接口返回的结果进行核对，以此来判定测试用例是否执行成功；
-
通过相关接口进行辅助验证：比如，当测试一个删除接口时，删除一条记录后，想验证这条记录真的被删除，可调用查询接口，若删除的记录没被查询到，则说明删除这条记录成功。
三、性能
#16. 在工作中，使用JMeter做压力测试时，需要关注其中的哪些指标？
性能指标由 压测结果指标 和 服务器指标 两部分组成。
压测结果指标
主要是根据JMeter生成的压测报告而言，则需要关注：吞吐量、请求的响应时间以及请求的错误率。
吞吐量 ：每秒钟系统能够处理的请求数。
在系统压测过程中，会达到系统的一个最高值，此时如果继续加压，对应系统的吞吐量不会增高反而会下降。因为，虽然并发数在增加，但是系统已经超负荷工作，无法满足新的并发需求。
请求的响应时间： 服务处理一个请求并获取它响应的时间。
获取请求的响应时间，应从请求的平均值、90%请求、99%请求等多个角度统计，而不仅仅是根据平均值来进行判断。
请求的错误率 ：压测并发脚本中出错的请求所占比例。
请求对错误率需要看具体是外部原因还是服务本身原因导致。外部原因比如网络超时等；服务本身由于逻辑或多线程处理问题导致。
服务器指标
服务器指标主要指的是服务器相关指标，比如：CPU、内存、网络、服务器负载 等等。
在进行性能测试时，不能只关注一方面的指标，需要压测结果指标 和 服务器指标两方面结合来判断出系统的问题所在，给出最终压测结果报告。
#17. 性能篇：jmeter做性能测试时， 造成响应时间慢的原因？
造成响应时间慢的原因可以有多种，以某些常见原因举例：
-
网络延迟：网络延迟是响应时间变长的主要原因之一，尤其是在远程服务器上。 -
服务器负载：当服务器的负载变得过重时，处理用户请求的速度可能会变得很慢，从而导致响应时间变长。 -
数据库查询：数据库查询是一个可能导致响应时间变慢的原因。如果查询包含多个连接表、查询多个字段或对大量数据进行排序等，则会导致查询执行时间的增加。 -
缓慢的应用程序操作：如果应用程序设计不良，可能导致操作执行慢。例如，一些页面需要加载大量的Javascript文件、CSS等。
以上只是一些可能导致响应时间变慢的原因之一，实际在 JMeter 测试中可能涉及到更多问题。因此，在JMeter测试时，需要细心分析识别问题并及时解决。
#18. 谈谈压力测试和负载测试有什么不同？
压力测试和负载测试都是性能测试的子类别，二者的区别如下：
-
测试目的不同
压力测试是测试系统可以承受的最大负载，确定系统的极限，在压力测试时会增加系统负载以检查其是否能够承受压力。
负载测试是测试系统在特定工作负载下的性能表现，可以模拟平均负载以及高峰负载，确保系统在这些负载下的稳定性和可靠性。 -
测试方法不同
压力测试通过逐渐增加查询、提交和数据量等负载，使得系统负载逐渐增加，最终达到系统极限，得到系统负载能力和处理瓶颈的参考值。
负载测试是模拟实际业务场景，按照实际访问数据进行测试，并记录系统资源使用情况，如CPU、内存、网络吞吐等。负载测试主要是在已知负载条件下，对系统进行性能评估。 -
测试重点不同
压力测试主要关注系统瓶颈以及系统最大容量，以确定该系统能够接受多少负载。在测试中，主要关注系统在负载过载情况下是否能够保持稳定性，并分析原因及解决方法。
负载测试主要关注系统在真实负载下的反应能力，可用性和性能。通过模拟特定的负载情景，测试瓶颈以及应用性能。在测试中，主要关注系统可靠性、可扩展性和成本效益。
总结而言，压力测试和负载测试虽然属于性能测试的范畴，但两者采用不同的测试方式、测试目的和测试重点。压力测试用于测试系统最大承载能力、硬性极限，而负载测试用于模拟业务场景下的负载，以检查系统在实际工作负载下的性能和稳定性。
1062
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
