面试题汇总——接口测试常见面试题

给你一个web接口，如何进行测试？



设计Web接口的用例通常需要遵循一定的步骤和原则，以确保接口的完整性、安全性、可用性和性能。以下是进行Web接口用例设计的一些基本步骤：

1. **理解需求**：
   - 明确接口的目的和功能。
   - 确定接口的输入和输出数据格式。

2. **定义接口规范**：
   - 确定HTTP方法(GET, POST, PUT, DELETE等)。
   - 确定请求和响应的格式(如JSON, XML等)。
   - 确定请求的URL和参数。

3. **创建测试计划**：
   - 确定测试目标和范围。
   - 确定测试环境和工具。

4. **编写测试用例**：
   - **正常场景测试**：
     - 验证接口在预期条件下的正确行为。
     - 测试不同的输入数据以确保接口能够正确处理。
   - **边界值测试**：
     - 测试输入数据的边界条件，如最小值、最大值等。
   - **异常场景测试**：
     - 验证接口在异常或错误输入下的行为。
     - 测试非法输入、数据格式错误、未授权访问等。
   - **安全性测试**：
     - 检查SQL注入、跨站脚本(XSS)、认证和授权机制等安全问题。
   - **性能测试**：
     - 测试接口在高负载下的表现。

5. **自动化测试**：
   - 考虑使用自动化测试工具来提高测试效率。

6. **测试数据准备**：
   - 准备所需的测试数据，包括正常数据和边界数据。

7. **执行测试**：
   - 按照测试用例执行测试，并记录结果。

8. **结果分析**：
   - 分析测试结果，确定是否满足预期。

9. **回归测试**：
   - 在接口更新后，重新执行关键用例以确保更改没有引入新的问题。

10. **文档化**：
    - 记录测试用例和测试结果，形成文档。

11. **持续集成**：
    - 将测试用例集成到持续集成流程中，以便于持续监控接口的质量。

12. **反馈与改进**：
    - 根据测试结果对接口进行优化，并更新测试用例。

在设计用例时，应考虑以下原则：

- **全面性**：确保测试覆盖所有功能点。
- **独立性**：每个测试用例应该是独立的，不依赖于其他用例的结果。
- **可重复性**：测试用例应该可以在任何时间、任何环境下重复执行，并得到相同的结果。
- **自动化**：对于重复性高的测试，应考虑自动化以提高效率。

记得，测试用例设计是一个迭代过程，可能需要根据接口的变化和测试结果进行调整和优化。












get请求与post请求的区别？


GET和POST是HTTP协议中两种最常见的请求方法，它们在发送数据到服务器时有以下主要区别：

1. **数据传输方式**：
   - **GET** 请求通过URL传递数据，数据会附加在URL后面，形成查询字符串(query string)。这种方式对数据大小有限制，因为URL长度有限制，通常限制在几千个字符以内。
   - **POST** 请求通过请求体(request body)传递数据，这意味着可以发送更大的数据量，且数据量大小没有GET请求那么严格的限制。

2. **安全性**：
   - **GET** 请求由于数据直接暴露在URL中，因此不够安全，不适合传输敏感信息。
   - **POST** 请求的数据不会显示在URL中，相对来说更安全一些，适合传输敏感信息。

3. **幂等性**：
   - **GET** 请求是幂等的，意味着多次执行相同的GET请求，资源的状态不会改变。
   - **POST** 请求不是幂等的，多次执行相同的POST请求可能会每次都改变资源的状态。

4. **缓存**：
   - **GET** 请求可以被缓存，这有助于提高性能，因为浏览器或代理服务器可以重复使用响应数据。
   - **POST** 请求通常不会被缓存，因为它们通常用于修改服务器上的数据。

5. **历史记录**：
   - **GET** 请求的URL可以被保存在浏览器历史记录中，用户可以回退到之前的GET请求。
   - **POST** 请求不会被保存在浏览器历史记录中，因此用户无法通过浏览器的回退按钮回到POST请求之前的状态。

6. **用途**：
   - **GET** 请求通常用于获取数据，它应该是安全的，不会对服务器上的数据产生副作用。
   - **POST** 请求通常用于向服务器提交数据进行处理，比如表单提交，它可能会引起服务器上状态的变化。

7. **可见性**：
   - **GET** 请求在浏览器的地址栏中可见，因为数据是通过URL传递的。
   - **POST** 请求的数据在浏览器地址栏中不可见，因为数据是通过HTTP请求体传递的。

8. **请求行长度限制**：
   - **GET** 请求由于数据在URL中，可能会受到浏览器或服务器对URL长度的限制。
   - **POST** 请求的数据在请求体中，不受URL长度限制。

9. **附加头信息**：
   - **GET** 请求通常不需要额外的头信息。
   - **POST** 请求可能会包含额外的头信息，比如`Content-Type`，用于指定请求体的媒体类型。

根据这些区别，开发者会根据具体的需求选择使用GET或POST请求。













常见的post请求，提交数据格式有哪几个？



在Web开发中，POST请求是一种常用的HTTP方法，用于向服务器提交数据。以下是几种常见的POST请求数据提交格式：

1. **x-www-form-urlencoded**：
   这是表单提交的默认格式。数据被编码为键值对，并通过URL查询字符串的方式发送。例如：
   ```
   POST /submit HTTP/1.1
   Host: www.example.com
   Content-Type: application/x-www-form-urlencoded
   user_id=123&password=abc
   ```

2. **multipart/form-data**：
   当需要上传文件时使用这种格式。它允许文件和文本字段一起发送，并且可以处理非ASCII字符。数据被分为多个部分，每个部分都有自己的内容类型和长度。例如：
   ```
   POST /submit HTTP/1.1
   Host: www.example.com
   Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXX
   ------WebKitFormBoundaryXXXXX
   Content-Disposition: form-data; name="user_id"
   123
   ------WebKitFormBoundaryXXXXX
   Content-Disposition: form-data; name="file"; filename="file.txt"
   Content-Type: text/plain
   [文件内容]
   ------WebKitFormBoundaryXXXXX--
   ```

3. **application/json**：
   这种格式用于发送JSON格式的数据。它通常用于API调用，其中客户端和服务器之间交换结构化数据。例如：
   ```
   POST /api/submit HTTP/1.1
   Host: www.example.com
   Content-Type: application/json
   {
     "user_id": 123,
     "password": "abc"
   }
   ```

4. **application/xml**：
   类似于JSON，这种格式用于发送XML格式的数据。虽然不如JSON流行，但在某些特定场景下仍然有用。例如：
   ```
   POST /submit HTTP/1.1
   Host: www.example.com
   Content-Type: application/xml
   <?xml version="1.0" encoding="UTF-8"?>
   <root>
     <user_id>123</user_id>
     <password>abc</password>
   </root>
   ```

5. **text/plain**：
   这种格式用于发送纯文本数据。它不常用于表单提交，但在某些情况下可能用于发送简单的文本信息。例如：
   ```
   POST /submit HTTP/1.1
   Host: www.example.com
   Content-Type: text/plain
   user_id=123&password=abc
   ```

每种格式都有其特定的使用场景和优势。选择哪种格式通常取决于客户端和服务器端的需求以及数据的类型。











`Cookie`、`Session`和`JWT` 三者的区别？



`Cookie`、`Session`和`JWT`(JSON Web Tokens)是客户端和服务器之间进行身份验证和信息交换的三种常见机制。它们各自有不同的特点和用途：

1. **Cookie**：
   - **存储位置**：由浏览器管理，存储在客户端。
   - **用途**：用于存储少量信息，如会话标识(session ID)。
   - **安全性**：相对较低，容易被拦截或篡改(尽管可以通过设置HttpOnly标志来提高安全性)。
   - **使用方式**：通常与服务器的session机制配合使用。


2. **Session**：
   - **存储位置**：存储在服务器端。
   - **用途**：用于存储用户的状态信息，如用户登录信息、购物车内容等。
   - **安全性**：相对较高，因为敏感信息存储在服务器端，但需要通过cookie来标识session。
   - **使用方式**：用户首次访问服务器时创建，用户与服务器的每次交互都会携带session ID。


3. **JWT**：
   - **存储位置**：可以存储在客户端(如LocalStorage或cookie)，也可以在服务器端。
   - **用途**：用于在客户端和服务器之间安全地传输信息，常用于身份验证和信息交换。
   - **安全性**：基于JSON Web Token标准，使用密钥(secret)进行签名，可以包含用户信息，但不应包含敏感信息。
   - **使用方式**：一旦生成，客户端可以在每次请求中发送JWT，服务器通过验证签名来确认其有效性。


**区别**：
- **存储**：Cookie存储在客户端，Session存储在服务器端，JWT可以存储在客户端也可以在服务器端。
- **安全性**：Session通常被认为是最安全的，因为它不暴露给客户端。JWT通过使用密钥签名来保证安全性，但需要妥善管理密钥。Cookie如果不正确使用，可能会有安全风险。
- **性能**：使用Session时，每次请求都需要查询数据库，可能会影响性能。而使用JWT可以减少服务器的负载，因为它不需要查询数据库来验证状态。
- **跨域**：JWT由于其自包含的特性，更适合于跨域认证场景。
- **大小**：由于JWT包含了所有必要的信息，所以通常比Cookie和Session ID大，这可能会影响性能。

选择使用哪种机制取决于具体的应用场景和需求。









接口http响应码有哪几种？



HTTP响应码(HTTP status codes)是客户端和服务器之间通信的一部分，用于表示请求的处理结果。它们分为五类：

1. **1xx(信息性状态码)**：表示服务器已接收到请求，需要继续处理。
   - `100 Continue`：客户端应继续发送请求体。
   - `101 Switching Protocols`：服务器将转换到客户端请求的协议。
   - `102 Processing`：服务器正在处理请求。

2. **2xx(成功状态码)**：表示请求已成功被服务器接收、理解、并接受。
   - `200 OK`：请求成功。
   - `201 Created`：请求成功，并且服务器创建了新的资源。
   - `202 Accepted`：服务器已接受请求，但尚未处理。
   - `204 No Content`：服务器成功处理了请求，但不需要返回任何实体内容。

3. **3xx(重定向状态码)**：表示为了完成请求，需要进行额外的操作。
   - `300 Multiple Choices`：请求有多个可能的响应。
   - `301 Moved Permanently`：请求的资源已经永久移动到了新的位置。
   - `302 Found`：临时重定向。
   - `304 Not Modified`：自从上次请求后，请求的资源未修改。

4. **4xx(客户端错误状态码)**：表示客户端似乎有错误。
   - `400 Bad Request`：服务器无法理解请求的格式。
   - `401 Unauthorized`：请求未授权。
   - `403 Forbidden`：服务器理解请求但拒绝执行。
   - `404 Not Found`：服务器找不到请求的资源。

5. **5xx(服务器错误状态码)**：表示服务器在处理请求过程中发生了错误。
   - `500 Internal Server Error`：服务器遇到了一个意外情况。
   - `501 Not Implemented`：服务器不支持请求的功能。
   - `503 Service Unavailable`：服务器暂时无法处理请求。

这些是最常见的HTTP响应码，但还有更多特定的代码用于不同的场景。













常见的请求头字段有哪些？


HTTP请求头(Header)是HTTP请求和响应的重要组成部分，用于传递一些附加信息。以下是一些常见的请求头字段：

1. **Host**：请求的主机名，允许多个域名共享同一个IP地址。

2. **User-Agent**：发送请求的客户端信息，包括浏览器版本、操作系统等。

3. **Accept**：客户端能够处理的媒体类型，如 `text/html`、`application/json` 等。

4. **Accept-Encoding**：客户端能够处理的压缩格式，如 `gzip`、`deflate` 等。

5. **Accept-Language**：客户端偏好的语言，如 `en-US`、`zh-CN` 等。

6. **Authorization**：认证信息，如基本认证、Bearer Token 等。

7. **Connection**：连接管理，如 `keep-alive` 或 `close`。

8. **Content-Length**：请求正文的长度，单位为字节。

9. **Content-Type**：请求正文的媒体类型，如 `application/x-www-form-urlencoded`、`application/json` 等。

10. **Cookie**：存储在客户端的Cookies。

11. **Date**：请求发送的日期和时间。

12. **From**：请求发送者的电子邮件地址，通常用于服务器记录，不用于认证。

13. **If-Modified-Since**：如果自这个日期和时间之后资源没有被修改，则返回304状态码。

14. **Referer**：表示当前请求的页面的URL，用于跟踪跳转来源。

15. **Cache-Control**：缓存指令，如 `no-cache`、`max-age=3600` 等。

16. **Pragma**：特定的缓存指令，如 `no-cache`。

17. **Transfer-Encoding**：传输编码头部，如 `chunked`。

18. **Upgrade**：向服务器请求使用不同的协议或加密算法。

19. **Via**：列出了请求经过的代理服务器。

20. **Warning**：关于消息内容的警告信息。

21. **DNT**(Do Not Track)：请求不被追踪。

22. **X-Requested-With**：通常由AJAX请求添加，标识请求是来自XMLHttpRequest。

23. **X-Forwarded-For**：实际客户端IP地址，当请求通过HTTP代理或负载均衡器时。

24. **X-Forwarded-Proto**：实际使用的HTTP协议，如 `http` 或 `https`。

25. **X-Forwarded-Host**：原始的Host头，当请求通过HTTP代理或负载均衡器时。

这些请求头字段在不同的场景下有不同的用途，如认证、内容协商、缓存控制等。在实际开发中，根据需要选择合适的请求头字段来实现特定的功能。

















HTTP与HTTPS的测试区？



HTTP与HTTPS的测试区别主要体现在安全性、数据传输方式、端口号、证书需求、性能以及测试关注点等方面。以下是根据搜集结果总结的两者在测试时需要关注的区别：

1. **安全性**：
   - HTTP：数据以明文传输，容易受到中间人攻击，安全性较低。
   - HTTPS：通过SSL/TLS协议加密数据，安全性较高，可以有效防止数据在传输过程中被窃听或篡改。

2. **端口号**：
   - HTTP默认使用端口80。
   - HTTPS默认使用端口443。

3. **证书需求**：
   - HTTP不需要证书。
   - HTTPS需要SSL证书来验证服务器身份，证书通常需要向证书颁发机构(CA)申请，可能涉及费用。

4. **性能**：
   - HTTP由于缺乏加密解密的步骤，性能通常较高。
   - HTTPS由于加密解密过程，可能会带来一些性能开销，但随着技术进步，这种差异正在逐渐减小。

5. **测试关注点**：
   - HTTP测试主要关注请求和响应的数据格式、连接稳定性等。
   - HTTPS测试除了需要关注HTTP的测试点外，还需要额外关注：
     - SSL/TLS握手过程，这可能影响请求响应时间。
     - 证书的有效性，包括证书的有效期和信任链。
     - 业务系统在跳转时的安全性，特别是从HTTP到HTTPS的跳转。
     - 加密层可能带来的额外延迟和耗电问题。

6. **数据传输**：
   - HTTP的传输是无状态的，数据传输不加密。
   - HTTPS除了数据加密外，还提供了数据完整性保护和身份验证。

7. **搜索引擎优化(SEO)**：
   - 根据谷歌的算法调整，使用HTTPS的网站在搜索结果中的排名可能会更高。

8. **缺点**：
   - HTTPS虽然安全，但在握手阶段可能花费更长时间，影响页面加载速度和设备耗电。
   - HTTPS连接缓存效率较低，可能导致数据开销和功耗增加。

在进行HTTPS接口测试时，测试人员需要了解HTTP和HTTPS的区别，并针对性地设计测试用例，以确保安全性和性能达到预期要求。








接口用例编写要点？



接口测试是软件测试的一种，主要用于检测系统组件之间的交互。编写接口测试用例时，需要考虑以下几个要点：

1. **理解接口定义**：了解接口的请求方法(如GET、POST、PUT、DELETE等)、请求URL、请求头、请求参数、返回数据格式等。

2. **定义测试目标**：明确测试用例需要验证的功能点，如接口的功能性、性能、安全性、稳定性等。

3. **正向测试用例**：编写正常情况的测试用例，验证接口在预期内的行为。

4. **负向测试用例**：设计异常情况的测试用例，如传递无效的参数、错误的数据格式、超出范围的值等，以验证系统的异常处理能力。

5. **边界值测试**：对于输入参数，测试其边界值，如最小值、最大值、步长值等。

6. **数据依赖性测试**：如果接口依赖于其他接口的输出数据，需要设计测试用例来验证这种依赖关系。

7. **安全性测试**：验证接口对SQL注入、XSS攻击、CSRF攻击等安全威胁的防护能力。

8. **性能测试**：测试接口在高并发、大数据量等情况下的表现。

9. **兼容性测试**：如果接口需要支持不同的客户端或浏览器，需要验证其兼容性。

10. **自动化测试**：考虑将测试用例自动化，以提高测试效率和准确性。

11. **文档化**：详细记录测试用例的步骤、预期结果和实际结果，便于团队成员理解和后续的回归测试。

12. **错误处理测试**：验证系统对错误请求的响应，如返回合适的错误码和错误信息。

13. **版本兼容性**：如果接口有多个版本，需要测试不同版本之间的兼容性。

14. **跨服务调用**：如果接口涉及到跨服务调用，需要测试服务间的调用是否正确。

15. **日志和监控**：验证接口调用是否正确记录日志，以及监控系统是否能够正常工作。

16. **测试数据管理**：确保测试用例使用的数据是可控的，不会影响到生产环境。

17. **回归测试**：在系统更新后，对接口进行回归测试，确保新版本没有破坏旧版本的功能。

18. **使用工具**：利用接口测试工具(如Postman、JMeter、SoapUI等)来辅助测试。

19. **环境准备**：确保测试环境与生产环境尽可能一致，以减少环境差异带来的风险。

20. **评审和更新**：定期评审测试用例，根据系统的变化进行更新和维护。

编写接口测试用例是一个持续的过程，需要根据项目的具体需求和变化进行调整和优化。












如何判断一个接口错误是前端还是后端产生的？


判断一个接口错误是前端还是后端产生的，可以通过以下几个步骤进行排查：

1. **查看错误信息**：通常，接口调用失败后，会返回一个错误信息或者错误码。根据错误信息的内容，可以初步判断是前端还是后端的问题。

2. **检查请求参数**：确保前端发送的请求参数格式正确，符合后端接口的要求。如果参数不正确，那么错误很可能是前端的问题。

3. **检查网络请求**：使用开发者工具(如浏览器的开发者工具)查看网络请求的状态。如果请求没有成功发送到服务器(例如，出现了404、500等状态码)，则可能是后端的问题。

4. **检查请求头信息**：有时候，错误可能是由于请求头信息不正确导致的，如缺少必要的认证信息。

5. **查看后端日志**：如果权限允许，查看后端服务的日志，看看是否有关于请求处理的异常记录。

6. **测试后端服务**：如果可能，单独测试后端服务，看看它是否能够正常处理请求。

7. **使用Postman或Curl测试**：使用这些工具来模拟HTTP请求，如果后端服务能够正常响应，那么问题可能出在前端。

8. **检查前端代码**：检查前端的请求发送逻辑，包括异步处理、错误处理等，确保前端代码能够正确处理各种情况。

9. **跨域问题**：如果请求被浏览器拦截，可能是因为跨域资源共享(CORS)问题，这通常涉及到后端的配置。

10. **版本控制**：确认前后端使用的接口文档版本是一致的。

11. **环境问题**：确保前端和后端运行在正确的环境(开发、测试或生产环境)中。

12. **咨询同事**：如果问题依然难以定位，可以咨询负责后端的同事，进行协作排查。

通过上述步骤，通常能够定位到接口错误是由前端还是后端产生的。在排查过程中，重要的是要有条理地进行测试和验证，逐步缩小问题的范围。




















接口自动化框架如何搭建？





搭建接口测试自动化框架是一个系统化的过程，涉及到需求分析、技术选型、框架设计、测试用例编写、测试执行和结果分析等多个环节。


以下是一个基于Python语言的接口测试自动化框架搭建的基本步骤和思路：


### 1. 需求分析与规划
确定测试目标，了解需要测试的接口特性，包括但不限于功能、性能、安全性等。

### 2. 技术选型
选择合适的编程语言和工具，Python因其简洁和强大的库支持而广泛用于自动化测试。常用的库包括`requests`用于发送HTTP请求，`pytest`或`unittest`用于编写和执行测试用例。

### 3. 框架设计
设计测试框架的结构，通常包括以下几个部分：
- **基础环境**：如Python版本、编译器(如PyCharm)、虚拟环境管理等。
- **配置管理**：使用如`configparser`的库来管理测试环境配置。
- **数据管理**：使用Excel、YAML、JSON等格式来存储测试数据。
- **测试用例**：编写测试用例，可以使用`pytest`结合`allure`生成测试报告。
- **日志管理**：使用`logging`模块来记录测试过程中的日志信息。
- **报告生成**：使用`allure`或其他工具生成详细的测试报告。

### 4. 测试用例编写
根据测试需求编写测试用例，可以使用`pytest`的参数化测试来实现数据驱动测试。

### 5. 持续集成
将测试框架集成到CI/CD流程中，使用如Jenkins等工具自动执行测试。

### 6. 测试执行
执行测试用例，可以是本地运行或集成到CI/CD流程中。

### 7. 结果分析
分析测试报告，确定测试结果是否符合预期，并对失败的测试用例进行调试。

### 8. 维护与优化
根据测试结果和项目需求对测试框架进行维护和优化。

### 示例项目结构
一个典型的接口测试自动化框架项目结构可能如下：
```
- config/               # 配置文件
  - config.ini
- data/                 # 测试数据文件
  - test_data.json
- logs/                 # 日志文件
- reports/              # 测试报告
- tests/                 # 测试用例
  - test_api.py
  - conftest.py          # pytest配置文件
- utils/                # 工具类
  - request.py           # HTTP请求封装
  - logger.py            # 日志封装
- main.py                # 主运行文件
- requirements.txt      # 依赖包列表
- README.md              # 项目说明文档
```

### 注意事项
- **代码复用**：尽量封装重复代码，提高框架的复用性。
- **模块化**：将框架划分为独立的模块，便于管理和维护。
- **可读性**：编写清晰的代码和文档，便于团队协作和后续维护。
- **灵活性**：设计时考虑框架的灵活性，能够适应不同的测试需求。

通过遵循上述步骤和注意事项，可以搭建起一个稳定、高效的接口测试自动化框架。






python的requests中，get请求，data  json   param区别



在Python的`requests`库中，`get`请求是一种向服务器请求数据的方式。在使用`get`请求时，可以通过不同的参数来发送额外的信息给服务器。以下是`data`、`json`和`params`三个参数的区别：

1. **data**:
   - `data`参数通常用于发送表单数据，它将数据编码为`application/x-www-form-urlencoded`格式。这适用于大多数表单提交，其中数据是键值对。
   - 例如，如果你有一个登录表单，你可能需要发送用户名和密码，你可以这样使用`data`：

     ```python
     import requests
     response = requests.get('http://example.com/login', data={'username': 'user', 'password': 'pass'})
     ```

2. **json**:
   - `json`参数用于发送JSON格式的数据。当你需要以JSON格式发送数据时，应该使用这个参数。`requests`库会自动将字典转换为JSON格式，并设置适当的`Content-Type`头部。
   - 这通常用于API调用，其中客户端和服务器之间交换JSON格式的数据：

     ```python
     response = requests.get('http://example.com/api/data', json={'key': 'value'})
     ```

3. **params**:
   - `params`参数用于发送查询字符串参数。这些参数会附加到URL后面，形成查询字符串。这对于不需要发送大量数据的简单请求非常有用。
   - 例如，如果你想要过滤服务器返回的数据，你可以使用`params`：

     ```python
     response = requests.get('http://example.com/api/data', params={'filter': 'value'})
     ```

这个请求的URL将会是`http://example.com/api/data?filter=value`。

总结来说，`data`用于表单数据，`json`用于JSON格式的数据，而`params`用于URL查询字符串。根据你的具体需求，你可以选择适当的参数来发送数据。





















在HTTP协议中，GET 和 POST 是两种最常见的方法，它们各自有不同的用途和特点：

1. **GET 方法**:
   - 通常用于请求数据，而不用于发送大量数据到服务器。
   - GET 请求的参数是通过URL的查询字符串传递的，这意味着参数是可见的，并且可以被缓存、收藏为书签、并且保留在服务器的日志中。
   - GET 请求应该是幂等的，意味着多次执行相同的GET请求，资源的状态不会改变。

2. **POST 方法**:
   - 通常用于向服务器提交数据进行处理，比如表单提交。
   - POST 请求可以发送大量数据，并且数据是通过请求体传递的，而不是URL。
   - POST 请求不是幂等的，多次执行相同的POST请求可能会每次都对服务器上的资源造成改变。

当你使用 JSON 格式发送数据时，通常选择 POST 方法，因为：

- JSON 数据通常比查询字符串包含更多的数据，并且更适合通过请求体发送。
- API 设计中，使用 POST 方法来处理那些需要修改服务器状态的请求更为常见。



然而，这并不是绝对的规则。


在某些情况下，如果你正在使用 JSON 格式请求数据，并且请求符合 GET 请求的特点(如请求不引起服务器状态改变，且是幂等的)，


你也可以使用 GET 方法。


例如，当你调用一个 API 来获取数据，并且这个操作是只读的，那么使用 GET 方法加上 JSON 数据是合适的。


在实际使用中，你应该根据 API 的设计和HTTP协议的最佳实践来决定使用 GET 还是 POST。


如果你不确定，查看 API 文档或与 API 提供者联系以获取正确的使用方法是一个好的实践。






















web测试与app测试的区别？


Web测试与App测试虽然都属于软件测试的范畴，但由于它们的运行环境、用户交互方式、系统架构等方面的不同，导致在测试过程中存在一些关键的区别。以下是根据搜集到的信息总结的Web测试与App测试的主要区别：

1. **测试环境的差异**：
   - Web测试主要关注浏览器上的呈现和交互，以及跨浏览器的兼容性问题。
   - App测试则需要在多种操作系统和设备上进行，考虑不同品牌、型号、屏幕尺寸和硬件性能的影响。

2. **交互界面的不同**：
   - Web应用通常依赖于鼠标和键盘操作，而App设计重点在于触摸屏操作的流畅性和响应速度。

3. **功能复杂性**：
   - Web应用可能功能更为复杂，需要验证表单提交、数据处理等。
   - App可能倾向于更轻量、快速的交互方式，对启动速度、响应时间有更高要求。

4. **性能要求**：
   - Web性能测试关注页面加载速度、服务器响应时间等。
   - App性能测试更注重CPU占用率、内存消耗、电池寿命等资源占用情况。

5. **安全性考量**：
   - Web应用需防范XSS、SQL注入等网络安全攻击，注重数据加密和用户权限控制。
   - App安全性测试更关注数据存储安全、代码安全性及设备功能访问权限的管理。

6. **系统结构方面**：
   - Web项目通常基于B/S架构，客户端会随服务器端更新而更新。
   - App项目基于C/S架构，服务端的修改可能需要所有核心版本的客户端进行回归测试。

7. **兼容性测试**：
   - Web测试需要考虑不同操作系统和浏览器的兼容性。
   - App测试则需要考虑不同设备、操作系统版本、屏幕尺寸和分辨率的兼容性。

8. **测试工具和平台**：
   - Web测试常用工具包括Selenium、Chrome DevTools、JMeter等。
   - App测试则可能使用Appium、Xamarin Test Cloud等专门针对移动应用的测试工具。

9. **专项测试**：
   - Web测试可能包括链接测试、打印机测试等。
   - App测试可能包括安装、更新、卸载测试、权限测试、安全测试、边界测试、界面操作测试、干扰测试和网络测试等。

10. **用户体验和反馈**：
    - Web应用的用户体验设计和用户反馈机制可能与App不同，App更侧重于动画和触觉反馈。

根据上述点，可以看出Web测试和App测试在测试策略、测试重点、测试工具选择上都有所不同，测试人员需要根据项目特性和用户需求选择合适的测试方法和工具。





















自动化测试，三大时间等待的区别？


在自动化测试中，为了确保脚本能够正确地与应用程序同步，通常会使用不同的等待策略来处理页面加载、元素出现等时机问题。以下是三种常见的等待方式及其区别：

1. **强制等待(Static Wait)**：
   - 强制等待是一种最简单的等待方式，它使用`time.sleep()`方法实现，无论元素是否加载完成，都会让代码执行暂停指定的时间(秒)。
   - 这种方式简单易用，但效率较低，因为它不考虑元素的实际加载情况，只是简单地等待固定的时间。
   - 示例代码：`time.sleep(5)`，表示代码会暂停5秒。

2. **隐式等待(Implicit Wait)**：
   - 隐式等待是Selenium WebDriver提供的一种全局等待机制，通过`driver.implicitly_wait()`方法设置。
   - 它在一个统一的时间段内，对所有查找元素的操作生效。如果在设置的时间内元素出现，则继续执行，否则会抛出找不到元素的异常。
   - 隐式等待默认时间是0秒，一旦设置，将在整个WebDriver实例的生命周期内有效。
   - 示例代码：`driver.implicitly_wait(10)`，表示在查找元素时，如果元素在10秒内未出现，则会抛出异常。

3. **显式等待(Explicit Wait)**：
   - 显式等待是一种更智能的等待方式，它使用`WebDriverWait`类和`expected_conditions`模块来实现。
   - 显式等待是针对特定元素的，可以设置最长等待时间和轮询频率，它在指定的时间内不断检查某个条件是否满足，一旦满足则继续执行，否则会抛出超时异常。
   - 显式等待可以更精确地控制测试流程，减少不必要的等待时间，提高测试效率。
   - 示例代码：
     ```python
     from selenium import webdriver
     from selenium.webdriver.common.by import By
     from selenium.webdriver.support.ui import WebDriverWait
     from selenium.webdriver.support import expected_conditions as EC
     
     element = WebDriverWait(driver, 5, 0.5).until(
         EC.presence_of_element_located((By.ID, 'element_id'))
     )
     ```

每种等待方式都有其适用场景，通常在编写自动化测试脚本时，会根据实际情况选择合适的等待策略，以确保测试的准确性和效率。











一、什么是jsonpath

　　用来解析json数据的所使用的。

 

二、拓展

1、python 处理json格式所使用的函数

(1)json.dumps()  

　　将字典或者列表转换为json格式的字符串。

(2)json.loads()

　　将json格式字符串转换为python对象。

(3)json.dump()

　　将字典或者列表转换为json格式的字符串并且写入到文件中。

(4)json.load()

　　从文件中读取json格式的字符串并且转换为python对象。