当前位置: 首页 > news >正文

学习软件测试的第十九天

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. 操作系统环境:测试软件在 WindowsmacOSLinux 等操作系统中的表现。

  2. 浏览器环境:确保软件在主流浏览器(如 ChromeFirefoxSafari 等)上兼容,避免不同浏览器带来的显示问题。

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

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

  5. 网络环境:测试软件在不同网络条件(如 Wi-Fi4GVPN)下的表现,确保网络延迟和带宽限制不会影响功能。

  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 RunnerNewman 批量执行测试,生成测试报告。

  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️⃣ 性能测试

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

  • 并发用户数测试

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

    • 通过压力测试工具(如 JMeterLoadRunner)模拟 数万数十万 的并发用户访问秒杀页面。

  • 响应时间测试

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

  • 秒杀高峰期压力测试

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

  • 数据库性能测试

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


3️⃣ 安全性测试

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

  • 防刷单测试

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

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

  • 数据安全性测试

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

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

  • 防攻击测试

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


4️⃣ 用户体验测试

  • 页面加载与响应

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

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

  • 异常场景处理

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

  • 秒杀过程的易用性

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

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


5️⃣ 恢复性测试

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

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

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

  • 数据库恢复测试

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

 总结 

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

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

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

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

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

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

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

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

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

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

  2. 使用性能测试工具:使用如 JMeterLoadRunner 等工具模拟大量并发用户,逐步增加并发量,进行负载测试。

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

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

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

13.cookie和session的区别

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

  1. 存储位置

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

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

  2. 生命周期

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

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

  3. 存储容量

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

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

  4. 安全性

    • Cookie:易受 XSS 攻击窃取,需要加密和设置 HttpOnlySecure 属性来提高安全性。

    • 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的区别

GETPOST 是常见的 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. 验证接口返回数据:使用 PostmancURL 检查后端 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. 文件和目录操作:使用 lscprm 等命令管理文件,使用 chmod 修改文件权限,使用 find 查找文件。

  4. 网络配置与排错:通过 pingtraceroute 测试网络连接,使用 curlwget 测试 HTTP 请求。

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

  6. 软件包管理与安装:通过 aptyum 安装和管理软件包,确保环境的稳定性和可维护性。

  7. 日志和系统监控:使用 dffreetop 等命令监控系统资源,查看系统日志并及时响应异常。

 

http://www.lryc.cn/news/596563.html

相关文章:

  • imx6ull-系统移植篇18——linux顶层 Makefile(下)
  • API是什么,如何保障API安全?
  • Springboot和postman的使用
  • XSS内容分享
  • 智能泵房监控系统:物联网应用与智能管理解决方案
  • Qt中QObject类的核心作用与使用
  • Qt 事件处理机制深入剖析
  • List<UserInfo> list = new ArrayList<>();为什么要这样创建数组?
  • 如何用keepAlive实现标签页缓存
  • 从 COLMAP 到 3D Gaussian Splatting
  • 滑动窗口经典问题整理
  • langchain4j之RAG 检索增强生成
  • Linux操作系统之线程(六):线程互斥
  • TCP day39
  • 质量即服务:从测试策略到平台运营的全链路作战手册
  • 重生学AI第十九集:VGG16的使用以及模型的保存与加载
  • 【期末考试复习】计算机组成原理 - 直接补码阵列乘法器
  • 【接口自动化】pytest的基本使用
  • CSS+JavaScript 禁用浏览器复制功能的几种方法
  • web登录页面
  • 黑马点评练习题-给店铺类型查询业务添加缓存(String和List实现)
  • kafka4.0集群部署
  • 数据结构01:链表
  • docker compose 安装使用笔记
  • Docker实战:使用Docker部署TeamMapper思维导图工具
  • 【实时Linux实战系列】基于实时Linux的传感器网络设计
  • Spring Boot音乐服务器项目-登录模块
  • 【论文阅读】Fast-BEV: A Fast and Strong Bird’s-Eye View Perception Baseline
  • 基于VU13P的百G光纤FMC高性能处理板
  • Rust实战:决策树与随机森林实现