【测试岗】2024测试岗最全面试题（五）API测试

API测试的一些关键方面和步骤

API测试（Application Programming Interface Testing）是软件测试中的一种重要类型，它主要关注应用程序的接口部分。API是应用程序之间通信的桥梁，允许不同的软件组件或服务进行交互。因此，确保API的正确性和稳定性对于整个应用程序的可靠性至关重要。

以下是API测试的一些关键方面和步骤：

1. 确定测试目标和范围

• 理解业务需求：明确API需要支持哪些功能。
• 确定测试范围：包括哪些API端点、参数和预期行为。

2. 设计测试用例

• 输入参数：测试不同的输入值，包括有效值、无效值、边界值和特殊字符。
• 错误处理：验证API如何处理错误情况，如参数错误、认证失败等。
• 预期输出：为每个测试用例定义预期的输出或响应。

3. 选择测试工具

• 手动测试：使用API客户端（如Postman、curl等）手动执行请求。
• 自动化测试：使用测试框架（如RestAssured、TestNG等）编写自动化脚本。

4. 执行测试

• 功能测试：验证API是否按预期工作。
• 性能测试：测试API的响应时间、吞吐量等性能指标。
• 安全测试：检查API是否容易受到注入攻击、未授权访问等安全威胁。

5. 分析和报告

• 记录测试结果：记录每个测试用例的通过/失败状态。
• 生成测试报告：总结测试结果，包括发现的问题和建议的修复方案。

6. 缺陷跟踪和修复

• 记录缺陷：为每个发现的问题创建缺陷报告。
• 跟踪修复：确保所有问题都得到修复并经过重新测试。

7. 回归测试

• 在修复缺陷或添加新功能后，重新执行测试用例以确保没有引入新的问题。

8.注意事项

• 文档检查：确保API文档与实际实现一致。
• 兼容性测试：验证API在不同平台和浏览器上的兼容性。
• 持续集成：将API测试集成到持续集成流程中，以确保每次代码更改时都会运行测试。

通过执行全面的API测试，可以确保应用程序的接口稳定、可靠且安全，从而提高整个应用程序的质量和用户满意度。

API测试中,功能测试、性能测试、安全测试如何进行

在API测试中，功能测试、性能测试和安全测试是三个重要的方面，它们各自有不同的关注点和执行方法。以下是这三个测试的详细进行方式：

1.功能测试

功能测试主要关注API是否按照预期的功能和要求进行工作。测试人员会模拟客户端发送请求，验证服务器返回的结果是否符合预期。

1. 定义测试数据：根据API接口规范，准备测试数据，包括各种正常的、边界的以及异常的输入。
2. 编写测试用例：设计测试用例，覆盖所有可能的场景和输入组合。每个测试用例都应包含清晰的输入数据、预期输出以及执行条件。
3. 执行测试：使用测试工具或手动方式执行测试用例，记录实际输出并与预期输出进行比较。
4. 结果分析：分析测试结果，统计测试通过率和失败率，对失败的测试用例进行问题定位和修复。

2.性能测试

性能测试主要关注API的响应时间、吞吐量、并发处理能力以及资源利用率等。

1. 确定性能指标：根据业务需求，确定API的性能指标，如响应时间不超过XX毫秒，吞吐量达到XX请求/秒等。
2. 设计测试场景：设计不同的测试场景，包括正常负载、高负载、突发负载等，以模拟实际应用中可能遇到的情况。
3. 执行性能测试：使用性能测试工具（如LoadRunner、JMeter等）执行性能测试，记录实际的性能指标。
4. 结果分析：分析性能测试结果，判断API是否满足性能指标要求，如果不满足，则需要进行性能调优。

3.安全测试

安全测试主要关注API是否存在潜在的安全风险，如未授权访问、SQL注入、跨站脚本攻击（XSS）等。

1. 识别潜在风险：根据安全标准和最佳实践，识别API可能存在的安全风险。
2. 设计安全测试用例：针对每个潜在风险，设计相应的测试用例，如尝试未经授权的访问、输入恶意数据等。
3. 执行安全测试：使用安全测试工具或手动方式执行安全测试用例，观察API的响应和行为。
4. 结果分析：分析安全测试结果，判断API是否存在安全风险，如果存在，则需要修复相应的安全问题。

在进行这些测试时，测试人员需要保持高度的细心和耐心，确保测试的全面性和准确性。同时，他们还需要与开发人员紧密合作，及时沟通问题，确保API的质量和稳定性。

API测试用例设计方法

测试用例设计是API测试中的关键步骤，旨在确保测试的全面性和有效性。以下是具体的测试用例设计方法：

1. 等价类划分法：

   • 将输入数据（如参数）划分为若干个等价类，从每个等价类中选取一个或多个代表性数据进行测试。
   • 例如，对于API的某个参数，如果其取值范围为1-100的整数，则可以划分为有效等价类（1-100内的整数）和无效等价类（小于1或大于100的数、非整数等）。

2. 边界值分析法：

   • 重点关注输入数据的边界值，因为很多错误都发生在边界条件上。
   • 对于上述的1-100整数范围，应测试边界值1、100以及接近边界的值（如2、99等）。

3. 因果图法：

   • 使用因果图来描述输入与输出之间的关系，从而设计测试用例。
   • 这种方法适用于输入参数较多，且参数之间存在依赖或约束关系的情况。

4. 场景法：

   • 根据业务需求，设计一系列的场景或业务流程，然后针对每个场景设计测试用例。
   • 例如，对于一个电商API，可以设计用户注册、登录、购物、支付等场景，并针对每个场景测试API的功能和性能。

5. 错误推测法：

   • 基于测试人员的经验和直觉，推测可能出错的地方，并设计相应的测试用例。
   • 这种方法需要测试人员具备丰富的经验和敏锐的洞察力。

6. 正交实验设计法：

   • 当输入参数较多且每个参数有多个取值时，可以使用正交表来设计测试用例，以较少的用例覆盖尽可能多的参数组合。

7. 组合策略：

   • 在实际测试中，通常不会只使用一种方法，而是根据具体情况组合使用多种方法。
   • 例如，可以先使用等价类划分和边界值分析确定基本的测试用例，然后使用场景法或错误推测法补充和完善测试用例。

在设计测试用例时，还需要注意以下几点：

• 确保测试用例的覆盖性，即尽可能覆盖所有的功能点、业务规则和边界条件。
• 保持测试用例的独立性，避免一个用例的执行结果影响其他用例的执行。
• 设计合理的预期输出和判断条件，以便准确判断测试结果是否符合预期。
• 定期对测试用例进行审查和更新，以适应业务变化和技术更新。

最后，不同的测试用例设计方法有其适用范围和局限性，因此在实际应用中需要根据项目的具体情况和需求选择合适的方法。

常用到的API 测试工具及具体用法

1. Postman：

   • 请求构建：在Postman中，你可以通过直观的界面构建各种HTTP请求，包括GET、POST、PUT、DELETE等。你可以设置请求的URL、HTTP方法、请求头、请求体等。
   • 环境变量管理：Postman支持环境变量，你可以创建多个环境，并在不同的环境中使用不同的变量值。这对于测试不同的服务器或配置非常有用。
   • 断言与测试：Postman允许你编写测试脚本，以验证API的响应是否符合预期。你可以设置断言来检查响应状态码、响应头、响应体等。
   • 自动化测试：通过Postman的Runner功能，你可以创建自动化测试集合，并设置定时运行或集成到CI/CD流程中。

2. SoapUI：

   • 测试用例创建：SoapUI允许你创建和管理SOAP和REST API的测试用例。你可以通过拖拽界面创建测试步骤，设置请求和响应的断言。
   • 数据驱动测试：SoapUI支持从外部数据源（如Excel、CSV或数据库）加载测试数据，这使得基于真实数据的测试成为可能。
   • 模拟服务：SoapUI的MockService功能允许你模拟API的响应，这在测试前端或其他依赖API的系统时非常有用。
   • 报告与集成：SoapUI提供了详细的测试报告，并可以与Jenkins等CI工具集成，实现自动化测试和报告生成。

3. JMeter：

   • 性能测试：使用JMeter，你可以创建性能测试计划，模拟大量用户并发请求，以评估API的性能。
   • 请求构建与配置：你可以构建各种HTTP或HTTPS请求，并设置请求的线程数、响应时间等参数。
   • 监听器与报告：JMeter提供了多种监听器来收集测试结果，如响应时间图、吞吐量图等。你还可以导出详细的测试报告。
   • 插件与扩展：JMeter支持丰富的插件和扩展，你可以根据需要添加自定义的插件或脚本。

4. RestAssured（Java库）：

   • 依赖管理：首先，你需要在你的Java项目中添加RestAssured的依赖。
   • 请求构建与发送：使用RestAssured的API，你可以构建并发送HTTP请求。你可以设置请求的参数、头信息、正文等。
   • 响应验证：RestAssured提供了丰富的断言方法，你可以验证响应的状态码、内容类型、JSON结构等。
   • 集成测试：RestAssured通常用于Java项目的集成测试中，你可以将其与JUnit或TestNG等测试框架结合使用。

5. Smartbear ReadyAPI：

   • API设计与管理：ReadyAPI提供了API设计和管理的功能，你可以创建和管理API的定义、请求和响应模板。
   • 测试创建与执行：使用ReadyAPI的直观界面，你可以创建功能测试、性能测试和安全测试。你还可以设置测试的执行计划和调度。
   • 团队协作与版本控制：ReadyAPI支持团队协作，你可以与团队成员共享测试用例和结果。它还集成了版本控制，使得测试用例的管理更加高效。
   • 报告与集成：ReadyAPI生成详细的测试报告，你可以将其导出或集成到CI/CD流程中，与其他工具（如Jenkins）协同工作。

这些工具的具体用法会根据具体的测试需求、项目环境和团队习惯有所不同。在使用这些工具时，建议查阅官方文档或参加相关培训，以深入了解其功能和最佳实践。

面试官最经常问的问题

以上的基础概念及流程不做赘述，基础的都会问,下面讲重点

1.做API 测试中，你会用到的工具？（如实回答，用啥就说啥）

2.给你一个登录接口，你如何开展测试？（了解你实际应用中知识的掌握全面性）

对于给定的登录接口，我们可以从多个维度进行详细的测试以确保其稳定 性和安全性。以下是一些建议的测试方法和步骤：

1. 功能测试
   1.1 正常登录

• 输入正确的用户名和密码，验证是否能成功登录。
• 验证登录成功后，用户是否重定向到预期页面。
  1.2 异常登录
• 输入错误的用户名或密码，验证是否提示错误信息。
• 输入不存在的用户名，验证是否提示用户不存在。
• 输入空的用户名或密码，验证是否提示相应的错误信息。

2. 性能测试
   2.1 并发测试

• 使用工具如JMeter或LoadRunner模拟大量用户同时登录，测试系统的并发处理能力。
  2.2 响应时间测试
• 记录从发送登录请求到收到响应的时间，确保响应时间满足业务需求。

3. 安全性测试
   3.1 密码加密

• 验证登录接口是否对密码进行了加密处理，如使用哈希算法。
  3.2 SQL注入攻击
• 尝试输入带有SQL注入语句的用户名或密码，验证系统是否能正确防御此类攻击。
  3.3 跨站脚本攻击（XSS）
• 检查登录页面是否存在XSS漏洞，尝试输入带有恶意脚本的用户名或密码。
  3.4 暴力破解防护
• 验证系统是否设置了登录尝试次数限制，以及是否使用了验证码等机制来防止暴力破解。

4. 可用性测试
   4.1 兼容性测试

• 在不同的浏览器和操作系统上测试登录功能，确保兼容性。
  4.2 错误提示友好性
• 验证错误提示信息是否清晰易懂，能否帮助用户快速定位问题。

5. 接口测试
   5.1 接口文档验证

• 根据接口文档，验证接口的地址、请求方法、请求参数、响应参数等是否正确。
  5.2 接口参数测试
• 验证接口对参数的合法性校验是否完善，如参数类型、参数范围等。

6. 非功能性测试
   6.1 稳定性测试

• 在长时间运行和高负载情况下，测试登录接口的稳定性和可靠性。
  6.2 日志记录
• 验证登录接口是否记录了必要的操作日志，以便出现问题时进行排查。

7. 测试总结与报告

• 根据测试结果，总结登录接口存在的问题，并给出相应的修复建议。
• 编写详细的测试报告，记录测试过程、测试结果以及修复建议，供开发人员参考。
  通过以上多方面的测试，我们可以全面评估登录接口的质量和安全性，确保系统的稳定运行和用户的安全登录。

3.关联接口，如何测试

关联接口测试在Postman和JMeter中的实现方式略有不同，但核心思路是一致的：即先调用一个接口获取数据，然后将这些数据作为参数传递给另一个接口进行测试。以下是这两种工具的具体测试步骤：
使用Postman测试关联接口

1. 梳理接口关系：首先，根据接口文档，理解并梳理各个接口之间的关联关系，确定调用顺序和数据传递方式。
2. 配置单个接口：在Postman中，为每个需要测试的接口配置正确的请求方法、URL、请求头和请求体。
3. 提取数据：在第一个接口的响应中，使用Postman的Tests功能编写脚本，提取需要传递给下一个接口的数据，并将其存储为环境变量或全局变量。
4. 参数化关联：在第二个接口的请求中，使用之前存储的变量作为参数。在Postman中，可以使用双花括号{{variable_name}}的形式引用变量。
5. 发送请求并验证：点击Send按钮发送请求，并检查第二个接口的响应是否符合预期。

使用JMeter测试关联接口

1. 创建测试计划：在JMeter中，创建一个新的测试计划，并添加线程组。
2. 添加HTTP请求：在线程组下，添加HTTP请求默认值以设置公共的请求头或请求体。然后，添加HTTP请求以模拟对第一个接口的调用。
3. 提取响应数据：使用JMeter的正则表达式提取器或JSON提取器，从第一个接口的响应中提取需要的数据。
4. 传递数据到下一个请求：在第二个HTTP请求中，使用之前提取的数据作为参数。可以通过引用变量的方式实现，如${variable_name}。
5. 添加断言：为第二个请求添加断言，以验证响应是否符合预期。
6. 运行测试计划：点击运行按钮，JMeter将按照测试计划中的配置执行测试，并显示结果。

注意事项：

• 在进行关联接口测试时，需要确保测试数据的一致性和准确性。避免使用硬编码的数据，而是尽量使用变量或参数化的方式。
• 对于复杂的关联逻辑或需要多次调用的场景，可以考虑使用JMeter的BeanShell或JSR223脚本进行更灵活的处理。
• 测试完成后，要仔细分析测试结果，检查是否有失败或异常的情况，并进行相应的调试和优化。

4.如何使用Mock

（以Postman举例，因为它自带mock服务）在Postman中使用Mock功能，你可以模拟后端API的响应，以便在前端开发或测试过程中，即使后端服务尚未就绪，也能进行接口的调用和验证。以下是在Postman中使用Mock的基本步骤：

1. 创建Collection：首先，在Postman中创建一个新的Collection。这个Collection将用于组织你想要Mock的API请求。

2. 添加请求到Collection：在刚创建的Collection中，添加你需要Mock的API请求。你可以设置请求的HTTP方法（GET、POST等）、URL、请求头和请求体等参数。

3. 启用Mock服务：选中Collection，然后在Collection的右侧或底部的操作栏中找到“Mocks”选项。点击“Mocks”后，你将看到一个开关按钮，将其打开以启用Mock服务。

4. 设置Mock响应：对于Collection中的每个请求，你都需要设置Mock响应。点击请求旁边的“Mocks”选项卡，然后添加或编辑响应。你可以设置不同的状态码、响应头和响应体，以模拟后端API的不同响应情况。

5. 生成Mock URL：启用Mock服务并设置好响应后，Postman会为你生成一个Mock URL。这个URL将用于在前端代码或测试工具中调用Mock服务。你可以将Mock URL复制到剪贴板，并在需要的地方使用它。

6. 使用Mock URL进行测试：现在，你可以使用Mock URL在前端代码或测试工具中进行测试了。当你发送请求到这个Mock URL时，Postman会根据你设置的Mock响应返回相应的数据。

请注意，Mock功能通常需要在Postman的付费版本中才能使用，而且具体的界面和选项可能会因Postman的版本更新而有所变化。因此，建议查阅Postman的官方文档或相关教程，以获取最准确和最新的使用指南。

此外，你还可以使用Postman的其他功能来增强Mock的使用效果，比如使用Pre-request Script来动态生成Mock响应，或使用Postman的监控功能来查看和分析Mock请求的调用情况。这些高级功能可以帮助你更灵活地模拟后端API的行为，提高开发和测试的效率。

5.Postman中如何进行参数化

在Postman中进行参数化是一个非常有用的功能，它允许你在多个请求或环境中使用相同的变量，从而简化测试过程并提高复用性。以下是进行参数化的基本步骤：

1. 创建全局变量或环境变量

• 全局变量：在Postman的“Globals”标签页中创建，这些变量在所有环境中都是可用的。
• 环境变量：在“Environments”标签页中创建，你可以为不同的环境（如开发、测试、生产）设置不同的变量值。

2. 设置变量值

• 对于全局变量和环境变量，你可以直接输入变量名和对应的值。
• 变量名通常使用双大括号 {{variable_name}} 的形式来表示。

3. 在请求中使用变量

• 在请求的URL、请求头、请求体等任何字段中，你都可以使用 {{variable_name}} 的形式来引用变量。
• 当发送请求时，Postman会自动将变量替换为相应的值。

4. 切换环境

• 如果你想在不同的环境中使用不同的变量值，可以在Postman的右上角选择相应的环境。
• 这样，当你发送请求时，Postman会使用当前选定环境中定义的变量值。

5. 使用Pre-request Script动态设置变量

• Postman允许你在发送请求之前运行JavaScript代码（称为Pre-request Script）。
• 你可以使用这些脚本来动态地设置变量的值，基于之前的响应或其他逻辑。

6. 使用Data Files进行批量测试

• 对于需要多次测试不同参数值的情况，你可以使用Postman的Data Files功能。
• 创建一个包含多行数据的CSV或JSON文件，并在Postman中指定这个文件作为数据源。
• 每次运行集合时，Postman都会从文件中读取一行数据，并将其作为变量的值用于请求中。

示例：

假设你有一个API需要不同的用户ID进行测试，你可以这样做：

1. 创建一个环境变量 userId 并为其设置一个初始值。
2. 在请求的URL中使用 {{userId}} 来引用这个变量。
3. 使用Pre-request Script或Data Files来动态或批量地改变 userId 的值。

这样，你就可以通过简单地改变变量的值来测试不同的场景，而无需手动修改请求的每一个部分。

6.请简述一下cookie、session以及token的区别

Cookie、Session和Token在Web应用或API中常用于处理用户认证和会话管理，但它们各自有着不同的特性和用途。

1. Cookie：

   • 存储位置：Cookie是服务器发送到用户浏览器并保存在本地的一小块数据。它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
   • 大小限制：Cookie有大小限制，并且浏览器在存储cookie的数量上也有限制。
   • 安全性：Cookie存在安全隐患，因为可以通过拦截或本地文件访问得到cookie，进而进行攻击。
   • 用途：常用于跟踪用户会话状态，保存用户偏好设置等。

2. Session：

   • 存储位置：Session是运行在服务器端的，数据存储在服务器上。
   • 大小限制：Session没有大小限制，其大小主要取决于服务器的内存大小。
   • 安全性：相比Cookie，Session的安全性更高，因为敏感数据存储在服务端，不暴露给客户端。
   • 工作原理：Session ID通常通过Cookie发送给客户端，客户端在后续请求中携带Session ID，服务器根据Session ID查找对应的Session数据。
   • 用途：用于在服务器端维护用户的会话状态，例如登录状态、购物车内容等。

3. Token：

   • 工作原理：Token是一种无状态的身份认证方式。服务器生成一串字符串（Token），并通过HTTP头部或URL参数的方式传递给客户端。客户端在每次请求时都需要带上该Token进行身份认证。
   • 安全性：Token可以设置过期时间，提高了安全性，并能有效保护用户的隐私信息。
   • 用途：常用于API和移动应用程序的身份验证和授权，因为Token可以在不同的服务器间传递而不需要共享Session数据。

总结来说，Cookie、Session和Token各有其特点和适用场景。Cookie主要用于在客户端跟踪会话状态和用户偏好；Session在服务器端维护用户会话状态，安全性较高；而Token则更适用于API和移动应用的身份验证和授权，因为它可以在不同的服务器间安全地传递用户身份信息。在选择使用哪种机制时，需要根据具体的应用场景和需求进行权衡。

7.常见的API接口类型有哪些？区别？

常见的API接口类型主要包括以下几种：

1. RESTful API：

   • 定义：RESTful API 是基于 REST（Representational State Transfer，表述性状态转移）架构风格设计的接口。它使用 HTTP 协议进行通信，并遵循一定的规范，如使用特定的 HTTP 方法（GET、POST、PUT、DELETE 等）来表示不同的操作。
   • 特点：无状态性、可缓存性、客户端-服务器架构、分层系统等。RESTful API 通常以 URL 的形式提供，易于理解和使用。

2. SOAP API：

   • 定义：SOAP（Simple Object Access Protocol，简单对象访问协议）是一种用于交换结构化信息的协议，常用于 Web 服务中。SOAP API 使用 XML 格式来定义和传输数据。
   • 特点：SOAP 提供了消息传递的框架，包括消息的封装、路由和安全性等。它支持多种传输协议，如 HTTP、SMTP 等。SOAP API 通常用于企业级应用之间的集成。

3. Web Service 接口：

   • 定义：Web Service 是一种通过网络提供软件功能的方式。它可以被视为一种特殊的 API，用于在不同的系统之间共享数据和功能。Web Service 可以基于多种协议和技术实现，包括 RESTful 和 SOAP。
   • 特点：Web Service 具有跨平台、跨语言的特点，使得不同系统之间的集成变得更加容易。它通常使用 XML、JSON 等格式进行数据传输。

4. RPC（远程过程调用）接口：

   • 定义：RPC 允许一个程序调用另一个程序中的函数或方法，就像调用本地函数一样。RPC 接口通过网络进行通信，实现了跨进程的函数调用。
   • 特点：RPC 接口隐藏了底层通信的细节，使得开发者可以像调用本地函数一样调用远程函数。它支持多种编程语言和平台，提高了开发效率。

这些 API 接口类型的主要区别在于它们的设计原则、通信协议、数据格式以及使用场景。RESTful API 和 SOAP API 是两种最常见的 Web 服务接口，它们在数据表示、传输协议和安全性等方面有所不同。Web Service 接口则更侧重于通过网络提供软件功能，而 RPC 接口则实现了跨进程的函数调用。在选择使用哪种 API 接口类型时，需要根据具体的应用场景、平台支持和开发需求进行综合考虑。

8.谈谈你对HTTP协议的了解

HTTP协议，即超文本传输协议（Hypertext Transfer Protocol），是互联网上应用最为广泛的一种网络协议。它是客户端与服务器之间通信的基础，用于传输超文本标记语言（HTML）文档和其他资源。以下是对HTTP协议的一些深入了解：

1. 主要特点：

   • 简单快速：HTTP协议简单且易于理解，这使得HTTP服务器的程序规模小，通信速度较快。客户端向服务器请求服务时，只需传送请求方法和路径。
   • 灵活：HTTP协议允许传输任意类型的数据对象，正在传输的类型由Content-Type加以标记。
   • 无连接：每次连接只处理一个请求，服务器处理完请求后，即断开连接。这种方式有助于节省传输时间。
   • 无状态：HTTP协议对事务处理没有记忆能力，即服务器不会记住之前客户端的请求信息。这有助于减少服务器端的存储需求，但也可能导致每次连接传送的数据量增大。

2. 传输过程：

   • 发送数据时，数据会从上层传输到下层，每经过一层都会被打上该层的头部信息。
   • 接收数据时，数据会从下层传输到上层，传输前会把下层的头部信息删除。

3. 与TCP的关系：

   • HTTP协议要求必须建立在可靠的传输协议基础之上进行，因此底层的通讯协议通常使用TCP协议。TCP协议提供可靠的、面向连接的字节流服务，确保数据在传输过程中的完整性和顺序性。
   • HTTP/1.1协议在建立一次TCP连接后，可以经历多次请求与响应的过程后再断开连接（即长连接），这可以减少系统开销并提高响应效率。

4. 应用：

   • HTTP协议在互联网应用中无处不在，它支撑着Web浏览器与Web服务器之间的交互，使得用户能够浏览网页、下载文件、提交表单等。
   • 随着Web技术的不断发展，HTTP协议也在不断演进，以支持更多的功能和优化性能。例如，HTTP/2协议引入了多路复用和头部压缩等技术，进一步提高了Web应用的性能和用户体验。

总的来说，HTTP协议是互联网通信的基石之一，它简单、灵活且易于扩展，为Web应用的发展提供了强有力的支持。然而，随着技术的不断进步和应用的不断扩展，HTTP协议也面临着一些挑战和需要改进的地方。未来，我们可以期待HTTP协议在保持其简单性和灵活性的同时，进一步提高性能和安全性，以满足不断变化的互联网应用需求。

9.GET、POST的区别

GET和POST是HTTP协议中两种主要的请求方法，它们之间存在一些明显的区别：

1. 语义与用途：

   • GET主要用于从服务器获取数据，通常用于查询操作，例如搜索或读取某个页面的内容。
   • POST则用于向服务器提交数据，常用于提交表单、上传文件等修改数据的操作。

2. 数据传输方式：

   • GET请求将参数附加在URL后面，这样，参数会出现在浏览器的地址栏中，也可以被保存在浏览器的历史记录或缓存中。
   • POST请求将数据放在HTTP请求体中，不会在URL中显示。因此，对于大量数据或敏感数据的传输，POST更为合适。

3. 安全性：

   • 由于GET请求的参数在URL中，因此可能存在安全隐患，尤其是在处理敏感数据时。
   • POST请求因为数据在请求体中，相对更安全。然而，这并不意味着POST请求本身就能提供数据安全性保障，实际的安全性还需依赖其他机制，如HTTPS。

4. 数据量与长度限制：

   • GET请求由于将参数附加在URL上，所以存在长度限制。这个限制因浏览器和服务器的不同而有所差异，但通常不适合传输大量数据。
   • POST请求则没有这样的限制，可以传输更大量的数据。

5. 幂等性：

   • HTTP规定GET是幂等的，即多次请求应该返回相同的结果（尽管实际应用中可能因动态数据而有所不同）。GET请求也通常被浏览器主动缓存。
   • POST请求则不是幂等的，每次请求都可能对服务器上的资源产生不同的影响。

6. 缓存：

   • GET请求可以被浏览器主动缓存，如果下次传输的数据相同，可以直接从缓存中获取，提高加载速度。
   • POST请求则不会被浏览器缓存。

总的来说，GET和POST在语义、数据传输方式、安全性、数据量限制、幂等性和缓存等方面都存在明显的区别。正确理解和使用这两种请求方法对于构建稳定、安全的Web应用至关重要。

10.响应状态码有哪些？

响应状态码是用于表示HTTP请求响应状态的三位数字代码。它们由HTTP协议定义，并用于告知客户端（如Web浏览器）请求的处理结果。状态码分为五类，每类的第一个数字定义了响应的类别。

以下是常见的HTTP响应状态码及其含义：

1. 1xx - 信息性响应：

   • 100 Continue：客户端应继续其请求。

2. 2xx - 成功响应：

   • 200 OK：请求成功。
   • 201 Created：请求成功，且创建了新的资源。
   • 204 No Content：请求成功，但无返回内容。

3. 3xx - 重定向响应：

   • 301 Moved Permanently：请求的资源已永久移动到新的URL。
   • 302 Found（或 307 Temporary Redirect）：请求的资源临时移动到新的URL。
   • 304 Not Modified：资源未修改，可使用缓存版本。

4. 4xx - 客户端错误响应：

   • 400 Bad Request：请求有语法错误或无法理解。
   • 401 Unauthorized：请求未经授权，需要身份验证。
   • 403 Forbidden：服务器拒绝请求。
   • 404 Not Found：请求的资源不存在。
   • 407 Proxy Authentication Required：请求需要通过代理服务器进行身份验证。

5. 5xx - 服务器错误响应：

   • 500 Internal Server Error：服务器内部错误，无法完成请求。
   • 502 Bad Gateway：作为网关或代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
   • 503 Service Unavailable：服务器暂时无法处理请求，可能是过载或维护中。

这些状态码提供了关于请求处理结果的重要信息，使得客户端能够相应地处理响应。在Web开发和API设计中，理解和正确使用这些状态码是非常重要的。

11.常用的接口断言方法

常用的接口断言方法主要包括以下几种：

1. 状态码断言：这是最基本且最常用的断言方式。它用于检查接口返回的状态码是否符合预期，例如200表示成功，404表示未找到资源等。如果实际返回的状态码与预期不符，则断言失败。

2. 响应头断言：除了状态码，有时还需要验证响应头中的某些字段是否符合预期。例如，可以检查Content-Type是否为application/json，或者检查是否存在某个特定的响应头字段。

3. 响应体内容断言：对于返回的数据内容，通常需要进行详细的断言。这包括检查响应体是否包含特定的字符串或关键字，验证JSON或XML结构中的字段值是否正确，以及确认返回的数据类型、长度或格式是否满足要求。

4. 数据库验证：对于涉及数据库操作的接口，可能需要通过查询数据库来验证接口的实际操作结果。例如，可以检查数据库中的记录是否已成功创建、更新或删除。

5. 时间断言：对于某些接口，可能需要验证其响应时间是否在指定的范围内。这有助于确保接口的性能满足要求。

6. 自定义逻辑断言：有时，根据具体的业务需求，可能需要编写自定义的断言逻辑。这可以通过编写脚本或使用测试框架的扩展功能来实现。

在实际应用中，通常会结合使用多种断言方法来确保接口的完整性和正确性。同时，为了提高测试效率和可维护性，建议将常用的断言逻辑封装成可重用的函数或模块。

需要注意的是，不同的接口测试工具和框架可能提供了不同的断言方法和功能。因此，在选择和使用断言方法时，需要根据具体的测试工具和框架来进行调整和适配。

12. HTTP和HTTPS之间的主要区别

1. 安全性：HTTP是明文传输协议，信息在传输过程中是未加密的，这意味着攻击者如果截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。相比之下，HTTPS是具有安全性的SSL加密传输协议，它通过SSL/TLS协议对传输的数据进行加密，确保浏览器和服务器之间的通信安全，有效防止数据被窃取或篡改。
2. 连接方式和端口：HTTP的连接是无状态的，且通常使用80端口。而HTTPS是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，使用的端口是443。
3. 证书申请：HTTP在证书申请方面相对简单，一般可免费申请。然而，HTTPS协议需要到CA（证书颁发机构）申请证书，由于免费的证书较少，因此通常需要支付一定的费用。

综上所述，HTTPS相较于HTTP提供了更高的安全性，通过加密传输和身份认证机制保护数据的安全，适用于对安全性要求较高的场景，如在线支付、用户登录等。而HTTP则适用于对安全性要求不高的场景。在选择使用哪种协议时，应根据具体的应用场景和需求进行权衡。

13.接口自动化测试框架

后续会详细总结
Python+requests+unittest/pytest
　　unittest+ddt+beautifulreport+logging
　　pytest+allure+logging