学习软件测试的第十九天

1.关于功能测试展开，有什么功能测试的工具

功能测试工具 可以分为手动测试和自动化测试工具，常见的功能测试工具包括：

1. Selenium：广泛应用于 Web 应用的自动化功能测试，支持多种浏览器和操作系统。

2. TestComplete：适用于桌面、Web 和移动应用的自动化功能测试，支持脚本和无脚本的自动化方式。

3. Postman：一个流行的 API 测试工具，用于验证 API 的功能性、性能和集成。

4. Jest：一个 JavaScript 测试框架，适用于 React 应用的单元和功能测试。

5. Cucumber：支持行为驱动开发（BDD）的测试工具，使用自然语言编写功能测试。

6. Ranorex：支持桌面、Web 和移动应用的功能测试，提供强大的 UI 元素识别能力。

7. Katalon Studio：一个全面的自动化测试工具，适用于 Web、API 和移动应用功能测试，提供图形界面和脚本功能。

8. Sikuli：基于图像识别的自动化测试工具，适用于图形用户界面的自动化功能测试。

这些工具各具优势，可以根据具体的应用场景和需求选择合适的工具进行功能测试。

2.兼容性测试基于那几个不同的环境进行测试

兼容性测试 是验证软件是否能够在不同的硬件、操作系统、浏览器、设备和网络环境中正常运行。常见的兼容性测试环境包括：

1. 操作系统环境：测试软件在 Windows、macOS、Linux 等操作系统中的表现。

2. 浏览器环境：确保软件在主流浏览器（如 Chrome、Firefox、Safari 等）上兼容，避免不同浏览器带来的显示问题。

3. 硬件环境：测试软件在不同硬件配置下的性能，确保能够适应不同的 处理器、显卡、内存 等配置。

4. 设备环境：验证软件在 桌面 和 移动设备（如 智能手机、平板）上的兼容性，确保响应式设计和适配不同设备。

5. 网络环境：测试软件在不同网络条件（如 Wi-Fi、4G、VPN）下的表现，确保网络延迟和带宽限制不会影响功能。

6. 区域和语言环境：验证软件是否支持不同地区和语言的设置，包括日期格式、货币单位、界面语言等。

通过这些环境的兼容性测试，能够确保软件在各种使用场景下的稳定性和一致性，提升用户体验。

3.性能测试的常见指标

性能测试的常见指标 主要包括：

1. 响应时间：测量系统从接收到请求到返回响应的时间，直接影响用户体验。

2. 吞吐量：衡量单位时间内系统能够处理的请求或事务数量，反映系统的处理能力。

3. 并发数：衡量系统能够同时处理的最大用户或请求数量，测试系统的并行处理能力。

4. 吞吐率/数据传输率：衡量系统在单位时间内成功传输的数据量，适用于需要大量数据交换的系统。

5. 系统负载：测试系统在高负载下的资源消耗情况，如 CPU、内存和磁盘的使用率。

6. 最大并发数：测试系统在不中断的情况下能够处理的最大并发用户数。

7. 错误率：系统在处理请求时发生错误的比例，较高的错误率表明存在性能问题。

8. 稳定性：系统在长时间运行和高负载条件下是否能够持续保持稳定。

9. 响应时间分布：对响应时间的不同分布进行统计，帮助识别性能瓶颈。

通过这些指标的评估，我们可以全面了解系统在不同负载和条件下的表现，确保软件在生产环境中能够稳定、高效地运行。

4.常用的用例方法有哪些

常用的用例设计方法 包括以下几种：

1. 等价类划分法：通过将输入数据划分为等价类，选择每个类中的代表值进行测试，减少测试用例数量。

2. 边界值分析法：重点测试输入数据的边界值，以发现潜在的边界问题。

3. 决策表测试法：使用决策表列出所有输入组合及其对应的输出，确保系统在不同条件组合下的正确性。

4. 状态转换测试法：根据系统的状态机模型，测试系统在不同状态之间的转换，验证状态转换的正确性。

5. 因果图法：通过因果图可视化输入条件与输出之间的逻辑关系，生成测试用例。

6. 随机测试法：通过随机生成输入数据进行测试，发现意外错误，尤其适用于复杂或难以预测的系统。

7. 用户场景法：通过模拟实际用户的操作场景进行测试，确保系统能够符合真实用户的需求。

这些用例设计方法可以帮助我们覆盖更多的测试场景，提高测试的全面性和有效性。

5.举出你所常用的两个测试用例的方法的具体使用方法

等价类划分法 和 边界值分析法 是常用的测试用例设计方法，具体使用方法如下：

1. 等价类划分法（Equivalence Class Partitioning）：

   • 将所有可能的输入数据划分为多个等价类，每个类中的数据可以认为是等价的。选择每个类中的代表值进行测试。

   • 示例：对于年龄输入字段，将输入数据划分为有效类（18 到 60 岁）和无效类（低于 18 岁和高于 60 岁），选择代表值进行测试。

2. 边界值分析法（Boundary Value Analysis）：

   • 重点测试输入数据的边界值，边界值周围的数据点容易触发错误。测试时选择最小边界值、最大边界值以及边界前后的值进行验证。

   • 示例：对于年龄输入字段，选择 18（最小边界值）、17（最小边界值-1）、60（最大边界值）、61（最大边界值+1）进行测试。

6.软件调试和软件测试的区别

软件测试 和 软件调试 是软件开发过程中两个关键且互补的过程，它们的区别如下：

1. 目标：

   • 软件测试：验证软件的功能和性能是否符合需求，主要用于发现缺陷。

   • 软件调试：定位和修复代码中的错误，修复已经发现的问题。

2. 执行者：

   • 软件测试：通常由 测试人员 执行。

   • 软件调试：通常由 开发人员 执行。

3. 关注点：

   • 软件测试：关注发现潜在缺陷，验证系统行为是否符合需求。

   • 软件调试：关注问题的修复，分析和解决错误。

4. 方法和工具：

   • 软件测试：使用测试用例、自动化脚本等，常用工具如 Selenium、JUnit、Postman 等。

   • 软件调试：使用调试器和日志工具，常用工具如 GDB、IDE 调试器 等。

5. 时机：

   • 软件测试：在开发后期进行，目的是验证产品质量。

   • 软件调试：通常发生在开发阶段，用于修复程序中的错误。

6. 问题发现方式：

   • 软件测试：通过执行测试用例主动发现问题。

   • 软件调试：通过分析错误信息、堆栈信息等来定位和修复问题。

软件测试侧重于验证软件功能和性能是否符合预期，发现潜在缺陷；而软件调试则侧重于定位和修复已发现的错误或缺陷。 

7.postman的使用流程

Postman 的使用流程 通常包括以下几个步骤：

1. 安装 Postman：下载并安装 Postman 客户端。

2. 创建请求：选择请求类型（如 GET、POST、PUT 等），输入 URL，配置请求头和请求体。

3. 发送请求：点击 Send 按钮，向 API 发送请求，并查看响应结果。

4. 验证响应：通过 Postman 的 测试脚本功能验证响应数据是否符合预期。

5. 创建集合：将多个相关请求组织成集合，以便管理和执行。

6. 编写测试脚本：在 Tests 标签下编写自动化测试脚本，确保 API 的正确性。

7. 自动化测试：使用 Collection Runner 或 Newman 批量执行测试，生成测试报告。

8. 生成报告：导出测试报告，用于进一步分析和共享。

9. 导出和分享：将请求集合导出为 JSON 格式，或通过分享链接与团队共享。

8.断言的常见语法

Postman 中常见的 断言语法 包括以下几种：

1. 状态码断言：验证 API 返回的 HTTP 状态码是否符合预期，如：

   pm.response.to.have.status(200);

2. 响应时间断言：验证响应时间是否小于预期，如：

   pm.response.to.have.responseTime.lessThan(200);

3. 响应体断言：验证响应体是否包含特定的内容，如：

   pm.response.to.have.body("success");

4. JSON 响应断言：验证 JSON 格式响应中是否包含指定的字段，如：

   pm.expect(jsonData.userId).to.eql(1);

5. 响应头断言：验证响应的 Content-Type 是否为 application/json：

   pm.response.to.have.header("Content-Type", "application/json");

6. 数组数据断言：验证数组字段的长度或内容，如：

   pm.expect(jsonData.data).to.be.an("array").that.has.lengthOf.above(0);

7. 字符串断言：验证响应中某个字符串的内容，如：

   pm.expect(jsonData.message).to.include("OK");

8. 条件断言：根据条件判断是否进行断言，如：

   if (jsonData.status === "active") { pm.expect(jsonData.active).to.be.true; }

通过这些断言，Postman 可以帮助我们验证 API 请求的 状态码、响应时间、响应内容、响应头 等，确保 API 按预期工作。

9.在其他接口中如何引用值

在 Postman 中，我们可以使用 环境变量、全局变量 和 测试脚本 来在一个请求的响应中提取值，并将其用于后续请求。

在 Postman 中引用其他接口的值主要通过以下几种方式：

1. 环境变量和全局变量：通过在 Test 脚本中提取响应数据，并使用 pm.environment.set() 或 pm.globals.set() 存储数据，后续请求可以通过 {{variableName}} 引用这些值。

2. 提取和传递数据：在一个请求的 Test 脚本中提取响应数据（如 userId），并将其存储为变量，在后续请求中使用该变量，如请求体或请求头中。

3. 链式请求：在多个请求之间传递数据，通过在第一个请求中提取数据并存储在环境变量或全局变量中，然后在下一个请求中引用该变量，实现在多个请求之间的数据传递。

10.你在测试中发现一个bug,然后你去问开发，开发说这不是个bug,怎么办？

在测试过程中，如果发现一个问题并报告给开发，但开发认为这不是一个 bug，我会采取以下步骤：

1. 明确问题描述：确保我准确地描述了问题，并提供详细的复现步骤、期望结果、实际结果以及相关的日志或截图。

2. 理解开发的观点：与开发沟通，了解他们认为这不是 bug 的原因，可能是因为需求、设计或实现的差异。

3. 对比需求文档：回顾需求文档，确保测试和开发对功能的理解一致。如果有差异，讨论需求文档中的标准。

4. 寻求第三方帮助：如果问题依然没有解决，我会寻求 产品经理（PM） 或 业务方 的帮助，确认功能是否符合需求。

5. 记录并跟踪问题：记录争议问题，并通过问题管理工具跟踪和讨论，必要时标记为 待评审，等待最终决策。

6. 提升沟通技巧：在整个过程中保持理性和专业，确保与开发团队的沟通顺畅高效。

11.对于一个手机秒杀活动，你要如何测试，或者说有哪些测试点

1️⃣ 功能性测试

确保秒杀活动的 功能性 完全符合需求，并且用户能够顺利参与活动，完成购买。

• 活动时间测试：

  • 确保活动在预定时间内开启，并且在活动结束时停止。

  • 测试活动的时间是否精准（比如，秒杀活动在上午10点整开始，确保精确到秒）。

• 商品展示与库存检查：

  • 测试秒杀商品是否按活动规则正确显示，是否展示了准确的库存数量。

  • 测试库存更新是否及时，确保商品库存数随购买减少，并且当库存不足时，不再允许下单。

• 参与限制测试：

  • 测试是否有每人购买限制（如每个用户限购一部手机），并确保系统限制生效。

  • 测试用户在活动中是否被正确识别和限制，比如 登录验证 是否生效，是否能防止同一用户通过多个账户抢购。

• 订单生成与支付流程测试：

  • 测试秒杀成功后，用户是否能顺利跳转到订单页面，并且订单信息正确无误。

  • 测试支付流程，确保支付成功后，用户收到 订单确认，并且库存及时更新。

---

2️⃣ 性能测试

秒杀活动的核心挑战是系统能否承受高并发的访问。性能测试关注系统的 负载能力、响应时间 和 稳定性。

• 并发用户数测试：

  • 模拟大量用户同时访问秒杀页面，测试系统能处理的并发用户数，确保即使在高并发下，系统仍能正常响应。

  • 通过压力测试工具（如 JMeter 或 LoadRunner）模拟 数万 或 数十万 的并发用户访问秒杀页面。

• 响应时间测试：

  • 测试页面加载时间、商品信息展示时间、提交订单时间等，确保响应时间在合理范围内，不影响用户体验（如页面加载时间应小于 2 秒）。

• 秒杀高峰期压力测试：

  • 模拟活动高峰期间的流量，测试系统在 秒杀开始前 和 秒杀结束后 的压力表现，确保系统能够承受 瞬时访问量。

• 数据库性能测试：

  • 测试在高并发下，数据库查询 和 库存更新 是否能及时响应，避免 库存数据不一致 或 数据库死锁。

---

3️⃣ 安全性测试

秒杀活动往往涉及较大的用户交易数据，因此 安全性 是不可忽视的测试点。

• 防刷单测试：

  • 检查是否有有效的防刷单机制，如验证码、图片验证、人机验证等。

  • 确保用户不能通过 自动化脚本 或 爬虫 手段刷单或绕过限制。

• 数据安全性测试：

  • 测试用户的个人信息、支付信息是否经过加密处理。

  • 确保 支付接口 的安全性，避免出现 信息泄露 或 交易被篡改 的情况。

• 防攻击测试：

  • 测试系统是否防止了常见的 DDoS 攻击、SQL 注入、XSS 跨站脚本攻击 等网络攻击。

---

4️⃣ 用户体验测试

• 页面加载与响应：

  • 测试秒杀活动页面的 加载速度 和 交互体验，确保活动页面内容快速加载且没有卡顿现象。

  • 确保 用户界面（UI） 的设计清晰，购买按钮易于点击，用户能顺畅地进行秒杀操作。

• 异常场景处理：

  • 测试秒杀失败时，系统如何提示用户，确保 友好的错误提示（例如库存不足时给出 “秒杀已结束” 提示）。

• 秒杀过程的易用性：

  • 确保用户在秒杀活动中能够清晰地看到 倒计时、库存量 等关键信息，并能够顺利操作。

  • 测试不同设备和浏览器下的体验，确保秒杀活动对 移动端、PC端、不同操作系统（Android、iOS）等兼容。

---

5️⃣ 恢复性测试

秒杀活动具有高并发、高负载的特性，因此恢复能力是必须测试的内容，确保系统发生故障时能快速恢复。

• 断电或服务器重启后恢复测试：

  • 模拟服务器崩溃或重启，测试系统是否能恢复正常，并且 用户数据 和 订单信息 能够在系统恢复后保持一致性。

• 数据库恢复测试：

  • 在活动中，模拟数据库异常或失联后，测试系统如何进行数据备份与恢复，确保活动数据的持久性。

 总结 

对于一个 手机秒杀活动，我会从以下几个方面进行测试：

1. 功能性测试：确保活动时间正确，商品展示与库存准确，用户购买限制生效，订单生成与支付流程顺畅。

2. 性能测试：模拟高并发用户访问，测试系统的并发承载能力、响应时间以及数据库性能。

3. 安全性测试：防止刷单和恶意攻击，确保交易过程中的用户数据和支付信息安全。

4. 用户体验测试：测试页面加载速度、秒杀过程的易用性，确保用户体验友好。

5. 恢复性测试：测试系统在高负载下的恢复能力，确保在出现故障后能快速恢复。

通过全面的测试，确保秒杀活动能够在 高并发、短时限 和 极限负载 条件下顺利运行，为用户提供无缝的秒杀体验。

12.关于性能测试，同时有非常多人同时访问怎么测试

在进行多人同时访问的性能测试时，主要的测试步骤包括：

1. 明确测试目标和场景：确定需要测试的业务场景，并设置合适的并发用户数。

2. 使用性能测试工具：使用如 JMeter、LoadRunner 等工具模拟大量并发用户，逐步增加并发量，进行负载测试。

3. 监控系统资源：在高并发情况下，监控 CPU、内存、数据库 等系统资源，确保系统能够稳定运行。

4. 分析性能指标：关注 响应时间、吞吐量、并发用户数、错误率 等指标，评估系统的性能。

5. 执行压力测试和峰值测试：通过 压力测试 和 峰值测试 确保系统能承受极限负载，并且具备恢复能力。

13.cookie和session的区别

Cookie 和 Session 是 Web 应用中用于存储客户端与服务器之间的状态信息的两种机制，它们的主要区别如下：

1. 存储位置：

   • Cookie：存储在客户端的浏览器中。

   • Session：存储在服务器端，通过 session ID 进行标识。

2. 生命周期：

   • Cookie：可以设置过期时间，浏览器关闭时可以选择是否失效。

   • Session：通常在浏览器会话结束时失效，或者服务器设置的超时时间内失效。

3. 存储容量：

   • Cookie：每个 cookie 的大小限制通常为 4KB。

   • Session：数据存储在服务器端，容量受限于服务器存储空间。

4. 安全性：

   • Cookie：易受 XSS 攻击 和 窃取，需要加密和设置 HttpOnly 和 Secure 属性来提高安全性。

   • Session：数据存储在服务器端，安全性较高，易于控制过期和失效机制，但也可能面临 会话劫持。

5. 依赖性：

   • Cookie：依赖客户端浏览器，可能会被禁用。

   • Session：依赖服务器端存储，客户端仅需传递 session ID。

6. 用途：

   • Cookie：常用于存储客户端信息，如登录状态、用户设置等。

   • Session：常用于存储会话期间的用户数据，如认证信息、购物车内容等。

Cookie 是存储在客户端的小数据，用于维持用户状态，生命周期由浏览器控制；Session 是存储在服务器的数据，通过 session ID 维持会话，生命周期通常与用户会话相关。 

14.基于登录状态的接口怎么测试（token值）

基于登录状态的接口测试（Token值） 主要包括以下几个步骤：

1. 获取有效 Token：模拟登录请求，获取有效的 Token。

2. 使用有效 Token 访问接口：在请求的 Authorization 头中添加 Bearer <Token>，确保接口能正确验证用户身份并返回资源。

3. 测试无效 Token 和过期 Token：验证无效或过期的 Token 是否会导致接口返回 401 Unauthorized 错误。

4. 测试 Token 刷新功能（如果适用）：验证是否可以使用 refreshToken 获取新的 accessToken，并使用新的 Token 访问接口。

5. 其他测试点：如 Token 缓存、多用户测试 和 Token 存储安全性。

15.测试的全流程

软件测试的全流程 通常包括以下几个阶段：

1. 需求分析与测试计划：理解系统需求，编写详细的测试计划，明确测试目标、范围和资源。

2. 测试用例设计：基于需求文档设计测试用例，确保覆盖功能需求和异常场景，并进行评审。

3. 测试环境搭建：搭建与生产环境一致的测试环境，配置测试工具和版本控制。

4. 测试执行：执行功能测试、性能测试、安全性测试、兼容性测试和回归测试，确保系统功能和性能符合预期。

5. 缺陷管理：记录缺陷，分析和定位缺陷，验证缺陷是否修复，关闭缺陷。

6. 测试报告与总结：编写测试报告，总结测试结果，并提出改进意见。

通过这些步骤，确保软件的质量满足需求和预期，并在不同环境和条件下保持稳定性和安全性。

16.接口测试的中的请求方法有哪些

接口测试中的常见请求方法 包括：

1. GET：用于获取资源，测试接口是否能够正确返回数据。

2. POST：用于创建资源或提交数据，测试接口是否正确处理并存储数据。

3. PUT：用于更新资源，测试接口是否能够正确替换资源内容。

4. PATCH：用于部分更新资源，测试接口是否能够正确更新部分字段。

5. DELETE：用于删除资源，测试接口是否正确删除数据。

6. HEAD：与 GET 类似，但只返回响应头，测试接口是否正确返回元数据。

7. OPTIONS：用于检查服务器支持的 HTTP 方法，测试接口是否正确响应方法支持。

17.get和post的区别

GET 和 POST 是常见的 HTTP 请求方法，主要区别如下：

1. 请求目的：

   • GET：用于从服务器获取数据或资源。

   • POST：用于向服务器提交数据，通常用于创建或更新资源。

2. 数据传输方式：

   • GET：数据通过 URL（查询参数）传递，适合传输少量数据。

   • POST：数据通过请求体（Body）传递，适合传输大量数据或敏感信息。

3. 数据大小限制：

   • GET：URL 长度有限制，适合传输少量数据。

   • POST：没有明确的大小限制，适合传输大量数据。

4. 缓存与书签：

   • GET：请求结果可缓存，支持书签。

   • POST：请求结果不可缓存，不能书签。

5. 幂等性：

   • GET：幂等的，多次请求返回相同结果。

   • POST：非幂等的，每次请求会产生不同的副作用。

6. 使用场景：

   • GET：获取数据（如浏览网页、查询数据）。

   • POST：提交数据（如登录、注册、表单提交）。

GET 用于从服务器获取数据，数据通过 URL 传递，适合小量非敏感数据；POST 用于向服务器提交数据，数据通过请求体传输，适合传输大量或敏感数据。 

18.常见响应码有那些

✅ 二、总结为标准面试术语版回答：

常见的 HTTP 响应码 包括：

1. 1xx（信息性状态码）：

   • 100 Continue：请求已接收，客户端可以继续发送请求。

   • 101 Switching Protocols：协议已切换。

2. 2xx（成功状态码）：

   • 200 OK：请求成功，返回数据。

   • 201 Created：请求成功，已创建资源。

   • 202 Accepted：请求已接受，正在处理。

   • 204 No Content：请求成功，但无返回内容。

3. 3xx（重定向状态码）：

   • 301 Moved Permanently：资源已永久移动，客户端使用新 URL。

   • 302 Found：资源暂时移动，客户端继续使用原 URL。

   • 303 See Other：客户端应访问另一个 URL。

   • 304 Not Modified：资源未修改，客户端使用缓存版本。

4. 4xx（客户端错误状态码）：

   • 400 Bad Request：请求无效，服务器无法理解。

   • 401 Unauthorized：需要认证，未提供有效认证信息。

   • 403 Forbidden：服务器拒绝请求。

   • 404 Not Found：请求的资源不存在。

   • 405 Method Not Allowed：请求方法不允许。

   • 408 Request Timeout：请求超时。

5. 5xx（服务器错误状态码）：

   • 500 Internal Server Error：服务器发生内部错误。

   • 502 Bad Gateway：网关或代理收到无效响应。

   • 503 Service Unavailable：服务器无法处理请求。

   • 504 Gateway Timeout：网关或代理超时。

19.403和404的区别

403 和 404 的区别：

1. 403 Forbidden：

   • 表示 服务器理解请求，但由于 权限不足 或 安全限制，服务器拒绝执行该请求。用户没有访问资源的权限。

2. 404 Not Found：

   • 表示 客户端请求的资源 在服务器上 不存在，通常是由于 URL 错误、资源删除 或 资源未找到。

20.集成测试对应测试流程的那一块模块

集成测试 对应测试流程中的 模块集成 阶段，位于 单元测试 和 系统测试 之间。集成测试的主要目标是验证系统中不同模块之间的 接口和交互 是否正常，确保模块组合在一起后能够协同工作。集成测试关注 模块间的接口调用、数据流传递、错误处理 和 依赖关系，并可以采用自顶向下、自底向上、增量等测试方法。

21.关于mysql,如何输出一个表中的人数

在 MySQL 中，若要查询表中的总人数，可以使用 COUNT(*) 函数。例如，使用 SELECT COUNT(*) FROM users; 来统计 users 表中的所有行数。如果需要按照特定条件查询人数，可以使用 WHERE 子句，如果需要去重统计人数，可以使用 COUNT(DISTINCT column_name)。

查询表中的总人数

SELECT COUNT(*) AS total_users FROM users;

 查询特定条件下的总人数

SELECT COUNT(*) AS total_adults FROM users WHERE age > 18;

查询唯一用户的总人数（去重）

SELECT COUNT(DISTINCT username) AS unique_users FROM users;

 COUNT(DISTINCT username)：统计 去重后的用户名 数量。

22.项目还有五天要上线了，开发说给他三天，留给自己两天测试，但是到最后了开发却说他还需要两天，你怎么办？

在面对这种情况时，我会采取以下措施：

1. 与开发沟通：了解开发方为什么需要额外的时间，评估是否为合理的延期，并讨论是否可以采取其他加速措施。

2. 评估风险与影响：评估项目上线后的风险，优先测试核心功能和关键路径，并做必要的回归测试。

3. 调整测试计划：根据剩余时间调整测试范围，集中测试高风险和关键功能，通过自动化测试提高效率。

4. 向上级汇报：将当前进度和风险向项目经理或相关负责人汇报，确保他们了解情况，并协商解决方案。

5. 文档记录与验收：记录当前测试进度，确保团队达成一致的上线标准，并确保测试质量和项目质量得到保证。

23.一共写了四个请求，但是只有两个通了，还有两个界面没显示，是什么原因？

对于 四个请求 中只有两个成功，另外两个界面没有显示的情况，我会按以下步骤排查：

1. 检查请求的响应状态码：查看失败请求是否返回 4xx 或 5xx 错误，定位问题原因。

2. 验证接口数据格式和内容：确保接口返回的数据格式正确，并且前端能够正确解析和渲染数据。

3. 排查网络问题和超时：检查请求的响应时间和超时设置，确认是否由于网络问题导致请求未完成。

4. 前端渲染问题：查看浏览器控制台是否有 JavaScript 错误，检查 DOM 元素是否正常渲染。

5. 检查后端依赖服务：查看服务器日志，确保后端服务和数据库查询没有异常。

6. 确认权限问题：确保请求携带了正确的认证信息，并且用户具备访问相应资源的权限。

24.在编写bug用例的时候需要写那些内容

在编写 Bug 用例 时，通常需要包含以下内容：

1. 标题：简洁描述 Bug 的核心问题。

2. Bug ID：唯一标识符，用于追踪和管理 Bug。

3. 严重程度：Bug 的影响程度（Critical, Major, Minor, Trivial）。

4. 优先级：修复 Bug 的紧急程度（High, Medium, Low）。

5. 描述：简要说明 Bug 的现象和背景。

6. 复现步骤：清晰、准确地列出复现 Bug 的步骤。

7. 预期结果：描述没有 Bug 时的正常行为。

8. 实际结果：描述实际出现的问题或错误。

9. 截图/视频：提供可视化的辅助材料，帮助理解 Bug。

10. 环境：描述 Bug 发生时的操作系统、浏览器版本等环境信息。

11. 日志/错误信息：附上任何相关的错误日志或调试信息。

12. 修复建议（可选）：如果有，可以提供一些解决方案建议。

25.出现一个bug,如何判断是前端还是后端问题

当出现 Bug 时，判断是 前端 还是 后端 问题可以通过以下几个步骤：

1. 检查请求和响应：通过 开发者工具 查看请求状态码和响应内容，若返回 4xx 或 5xx 错误，问题多半出在 后端。

2. 查看前端日志：检查 浏览器控制台 中的错误信息，如 JavaScript 错误，若有错误，通常是 前端问题。

3. 验证接口返回数据：使用 Postman 或 cURL 检查后端 API 是否返回正确的数据，若数据不正确，问题可能在 后端。

4. 检查网络请求和数据传递：通过 开发者工具 查看请求的参数和数据传递，确保请求和响应的正确性。

5. 检查数据库和后端日志：确认 后端数据库查询 是否正常，以及是否存在后端逻辑错误。

26.python中list用法，如何增删改查

在 Python 中，list 的常见增删改查操作包括：

1. 增加元素：使用 append()、insert() 和 extend() 方法向列表中添加元素。

2. 删除元素：使用 remove()、pop() 和 del 删除列表中的元素。

3. 修改元素：通过索引直接修改列表中的元素。

4. 查询元素：通过索引、切片、in 操作符、index() 方法查询列表中的元素。

5. 其他操作：如获取列表长度 len()、清空列表 clear()、排序 sort() 和反转 reverse()。

27.关于vi命令展开，vi如何操作

vi 是一个强大的文本编辑器，具有多种模式：

1. 命令模式：用于执行命令，如光标移动、删除、复制、粘贴、查找替换等。

2. 插入模式：用于插入或编辑文本，通过按 i 进入，按 Esc 返回命令模式。

常用操作包括：

• 插入模式：i（前插入）、a（后插入）、o（新行插入）等。

• 命令模式：光标移动、删除操作（如 dd 删除行）、查找和替换、保存和退出文件等。

• 退出操作：wq（保存并退出）、q!（不保存退出）等。

28.wq和q的区别

:wq 和 :q 都是用于退出 vi 编辑器的命令，但它们有不同的作用：

1. :wq：保存文件并退出 vi 编辑器。

2. :q：退出 vi 编辑器，前提是文件没有未保存的更改。如果文件有修改，使用 :q 会提示错误。

3. :q!：强制退出 vi 编辑器，忽略未保存的修改。

29.有一个表里面有name和message最后输出的结果是叫张三的评论了几天信息，这个sql语句怎么写

假设你希望查询 张三 的评论，并统计他评论的天数。你可以使用以下 SQL 语句来实现：

SELECT name, COUNT(DISTINCT DATE(created_at)) AS days_commented
FROM comments
WHERE name = '张三'
GROUP BY name;

• WHERE name = '张三'：筛选出 张三 的评论。

• COUNT(DISTINCT DATE(created_at))：对 created_at 字段进行 日期提取（去掉时间部分），然后使用 COUNT(DISTINCT ...) 来计算 张三评论的不同日期数，即评论的天数。

• GROUP BY name：按 name 分组，这里我们只关心 张三，所以结果就是张三的评论天数。

30.你是如何运用Linux的

我在 Linux 系统中主要运用以下功能：

1. 开发和编程环境搭建：使用 vi/vim 编辑器编写代码，安装开发语言环境（如 Python、Java），以及管理版本控制工具（如 Git）。

2. 服务器管理和运维：通过 SSH 远程管理服务器，使用 systemctl 管理服务，执行进程管理、日志查看等操作。

3. 文件和目录操作：使用 ls、cp、rm 等命令管理文件，使用 chmod 修改文件权限，使用 find 查找文件。

4. 网络配置与排错：通过 ping、traceroute 测试网络连接，使用 curl 和 wget 测试 HTTP 请求。

5. 自动化和脚本编写：编写 Bash 脚本 自动化任务，使用 cron 设置定时任务。

6. 软件包管理与安装：通过 apt 或 yum 安装和管理软件包，确保环境的稳定性和可维护性。

7. 日志和系统监控：使用 df、free、top 等命令监控系统资源，查看系统日志并及时响应异常。