学习软件测试的第十五天
1.会写测试用例吗？测试用例有什么要素
“会的，我写过多个功能测试和接口测试的测试用例。我写用例的时候会根据需求文档或原型图分析测试点，然后从正常流程、异常流程、边界情况等方面设计测试场景。每条用例我都会包含：用例编号、测试标题、前置条件、测试步骤、预期结果，有时也会补充实际结果和备注。”
测试用例其实就像“说明书”，告诉测试人员怎么一步步去测一个功能。它至少需要包含以下几个方面的内容：
| 要素 | 通俗解释 |
|---|---|
| 用例编号 | 每条用例都有一个编号，方便管理和追踪 |
| 用例名称 | 简单描述这个用例是测什么的 |
| 前置条件 | 执行测试之前系统需要满足的条件，比如登录成功 |
| 测试步骤 | 按照什么步骤去操作系统，点哪儿、输什么 |
| 预期结果 | 每一步操作之后，系统应该如何响应（判断成功与否的标准） |
| 实际结果（可选） | 真正执行后的结果，有时会记录下来对比验证 |
| 备注（可选） | 记录一些特殊情况说明，比如依赖环境、注意事项等 |
2.需求分析是怎么做的
通用流程
你可以围绕以下三个关键词来解释：理解 → 拆分 → 确认。
🎯 1. 理解需求：读懂需求文档
首先会仔细阅读产品需求文档（PRD）、原型图或接口文档，了解业务目标、功能流程、页面布局、接口规则等，明确“这个功能是干嘛的、用户怎么使用它”。
🔍 2. 拆分需求：找出测试点
然后我会从业务流程中一步步拆解，找出每个操作节点可以测试的内容，比如：
输入字段的合法性（边界值、格式校验）
页面跳转是否正确
权限是否控制到位
接口响应是否符合规范
异常情况是否有提示
这个过程就是“提炼测试点”
✅ 3. 确认需求：沟通不明确的地方
如果需求文档有模糊或遗漏的地方，比如“按钮提示语不清楚、异常场景没写”，我会及时找产品或开发沟通确认，确保不带着误解去测试。
面试术语
在进行需求分析时，我通常遵循以下流程：
需求理解：深入阅读产品需求文档（PRD）、接口文档、原型图，掌握业务流程和功能目标。
测试点提取：从功能流程中识别可测内容，覆盖正常路径、异常处理、边界条件、安全性等方面。
需求确认：对模糊或矛盾点主动与产品/开发沟通确认，确保测试方案与业务意图一致。
测试设计准备：基于分析结果，为后续用例编写和测试执行做好准备。
3.压力测试报告怎么写
压力测试就是：模拟大量用户同时使用系统，看系统能不能扛得住、在什么情况下开始崩溃。所以，报告要能回答这几个问题：
| 问题 | 举例说明 |
|---|---|
| 能撑住多少人？ | 比如“并发1000人访问首页，响应时间还能在1秒以内” |
| 在什么压力下开始崩？ | 比如“并发2000时，系统CPU飙满、数据库响应超时” |
| 哪些地方是瓶颈？ | 比如“接口X耗时长、数据库连接池用完了” |
| 有没有优化建议？ | 比如“建议加缓存、数据库分库分表” |
我在编写压力测试报告时，会结构化地从以下几个方面展开：
测试背景与目标：说明测试目的，例如上线前容量评估或性能瓶颈排查。
测试环境描述：包括服务器配置、网络环境、压测工具版本及脚本说明。
测试场景设计：列出主要压测对象及并发设置（如QPS、虚拟用户数、持续时间）。
性能指标统计：涵盖响应时间、吞吐量、成功率、错误率、资源占用等关键数据。
系统拐点与瓶颈分析：识别系统在不同负载下的性能变化与限制点。
结论与优化建议：评估系统最大承载能力，提出针对性的性能优化方向。
4.jmeter怎么做接口测试的
通俗说明：
🧱 第一步：创建接口请求
在 JMeter 中添加：
Thread Group（线程组）👉 理解为“模拟的用户”在线程组下添加
HTTP Request👉 这是你要测试的接口配置 URL、方法（GET/POST）、参数、Headers（如 token）
📬 第二步：添加请求断言（判断是否成功）
添加
Response Assertion（响应断言）比如断言返回内容中包含
"code":200或某个关键字段
🗂 第三步：批量参数化（可选）
使用
CSV Data Set Config加载参数文件（如 user_id 列表）实现多条用例循环测试，模拟接口在不同输入下的表现
📈 第四步：查看接口响应和执行结果
使用以下监听器查看结果：
View Results Tree：查看每次请求的请求参数、响应内容Summary Report：统计请求成功率、平均响应时间等
💡 小技巧：
如果只是做功能验证，可以设置线程数为 1，循环次数为 1，确保逐条调试。
响应内容可以设置提取器（JSON Extractor / Regular Expression）提取某些值做后续断言或参数传递。
面试术语
“JMeter不仅可以做压力测试，也能做接口功能测试，我会用它来发请求、断言结果、批量参数化和查看响应。”
是的，我可以使用 JMeter 进行接口测试。具体流程包括：
构建测试计划：在 Thread Group 中配置线程数和循环次数；
添加 HTTP 请求：设定接口地址、方法、参数、Header 等；
添加断言判断：使用 Response Assertion 检查响应内容或状态码是否符合预期；
参数化处理：通过 CSV Data Set Config 实现数据驱动测试；
响应结果分析：借助 View Results Tree 和 Summary Report 查看执行详情和统计数据。
通过这种方式，JMeter 不仅能做接口功能测试，也便于后续切换到接口性能压测。
6.postman用过吗？怎么用
通俗解释
1️⃣ 最基本的用法：接口调试
我平时使用 Postman 最多的是做接口调试，比如后端提供了接口文档，我会在 Postman 里手动构造请求，检查接口返回是否正确。
比如我会设置：
请求方式（GET / POST / PUT / DELETE）
请求地址（URL）
请求参数（Body / Params / Header）
查看返回的响应状态码、返回值、时间、响应体结构
这就像是用 Postman 替代前端直接调接口。
2️⃣ 进阶用法：接口自动化测试
我会使用 Postman 的 Collection（集合）功能，把多个接口组织成一组测试集，添加断言、保存环境变量，并通过点击“Run”实现批量测试。
常用功能包括：
Tests 标签页写断言
pm.test("状态码为200", () => {pm.response.to.have.status(200); }); pm.test("响应包含 success", () => {pm.response.text().includes("success"); });使用环境变量 / 全局变量来动态传参
使用 Pre-request Script 做加密、token 设置等前置处理
3️⃣ 自动化运行和报告：结合 Newman 使用
我也使用过 Newman（Postman 的命令行运行工具）来做持续集成接口测试，可以将 Collection 导出为 JSON，通过命令行运行并生成 HTML 报告。
面试术语
是的，我熟练使用 Postman 进行接口调试和测试。具体包括：
接口调试：通过配置请求方法、URL、参数、Header 等进行接口联调，检查响应数据与状态；
测试用例组织：使用 Collection 管理多个接口测试，设置环境变量、token 等，提高测试效率；
断言验证：在 Tests 标签中编写 JavaScript 脚本，对响应码、返回体字段等进行校验；
自动化执行：通过 Newman 工具命令行运行接口测试集合，生成可视化测试报告，适用于持续集成场景。
7.有做过AI相关的测试吗？有了解过AI吗？
是的，我参与过AI模型接口及系统的测试，主要包括模型输入输出的正确性验证（如图像识别标签是否准确）、非AI部分的功能测试（如Web页面、API接口）、模型在异常输入场景下的稳定性验证，以及模型效果评估（准确率、召回率、F1等）。此外，我还参与了接口的压力测试，通过JMeter或Python脚本模拟高并发，重点监控首token响应时间、整体延迟和系统稳定性。测试过程中，我会结合Postman、日志平台和自写脚本辅助分析，确保模型服务在功能、效果与性能上都满足业务需求。
我对AI有一定了解，特别是在业务落地层面。比如：
图像识别模型会用在安防监控、工业质检中，重点测试图像清晰度和分类精度
NLP（自然语言处理）模型会用在客服对话、智能问答中，重点测试语义准确性与上下文连贯性
大语言模型（如 ChatGPT、文心一言、Qwen）还需要关注生成文本的正确性、风险性、重复性等
8.redis是干嘛的和MySQL的区别
Redis 是一个基于内存的高性能键值型 NoSQL 数据库，常用于缓存热点数据、实现分布式锁、限流、消息队列等功能，它通过内存读写实现毫秒甚至微秒级的响应速度，适合对性能要求极高的场景。
与之相比，MySQL 是一种关系型数据库，采用结构化表格存储数据，支持 SQL 查询、事务控制、主外键约束等，适合用于长期持久化、强一致性要求的核心业务数据。
两者的主要区别可以从以下几点来看：
Redis 是非关系型数据库（NoSQL），以键值对形式存储，数据结构灵活、访问速度快、适合做缓存；
MySQL 是关系型数据库（RDBMS），以表格方式管理数据，支持复杂查询、事务和数据一致性；
Redis 存储在内存中，支持可选持久化；MySQL 存储在磁盘中，数据天然持久化；
Redis 适合高并发访问、临时状态、秒级响应；MySQL 更适合结构清晰、历史数据管理和数据分析。
从数据库类型上看，Redis 代表的是非关系型数据库，追求性能和灵活性；MySQL 代表的是关系型数据库，强调结构化、完整性和事务保障。在实际项目中，两者通常是互补使用：Redis 缓解数据库压力、加速读写，而 MySQL 管理核心业务数据，实现数据安全与一致性保障。
🔹Redis 是干嘛的？
你可以把 Redis 想象成一个**“超快的临时记忆本”**，放在服务器旁边，专门用来干这些事：
| 用途 | 举例说明 |
|---|---|
| 缓存热点数据 | 比如用户资料、商品信息，避免频繁查数据库，提升访问速度 |
| 存储会话信息 | 登录的 token、用户会话状态 |
| 限流/计数 | 比如一分钟内最多只能发10条短信，就用 Redis 来计数 |
| 排行榜、点赞数等 | Redis 的有序集合特别适合这些场景 |
| 消息队列 | Redis 可以临时当作一个简易队列来异步处理任务 |
9.sql在软件测试中的作用
SQL 在测试中主要做什么？
可以概括为四个字：查、对、验、清！
| 功能 | 举例说明 |
|---|---|
| 🔍 查（查询数据） | 比如注册后查 user 表看是否真的写入成功 |
| ✅ 对（对比接口数据） | 比如测试某个“订单列表接口”，接口返回 5 个订单，你可以查数据库看看是不是这 5 个 |
| 🕵️♂️ 验（验证业务逻辑） | 比如测试“逻辑删除”，你要看 is_deleted 字段是不是变了 |
| 🧹 清（测试数据清理） | 写 SQL 删除脏数据或初始化测试数据，保持环境干净 |
举几个常见测试中用 SQL 的场景：
功能测试后数据库验证
测试完某个新增/修改功能后，去数据库验证数据是否写入正确
接口测试数据对比
比如查询接口分页返回10条数据，用 SQL 查出来也要是那10条
测试数据准备
用 SQL 造数据，批量插入几百条用户或订单记录
异常场景制造
修改某字段为 null/非法值，看系统是否能正确处理异常
执行后端校验规则
比如“同一手机号不能注册两次”，你可以查数据库验证有没有重复手机号
面试术语
SQL 在软件测试中具有非常重要的作用，主要体现在以下几个方面：
数据验证：通过 SQL 查询数据库，验证前端操作或接口请求是否正确落库，确保数据一致性；
接口测试比对：对接口返回的数据与数据库真实数据进行比对，验证查询逻辑与分页准确性；
测试数据准备与清理：使用 SQL 脚本批量插入、修改、删除测试数据，提升测试效率；
业务规则验证：通过数据状态分析判断系统是否按业务逻辑执行，如状态流转、字段约束等；
异常数据制造：人为构造异常数据以测试系统的容错能力和边界处理。
因此，熟练掌握基本的 SQL 增删改查能力是测试工程师的基本技能之一，尤其在功能测试、接口测试和数据驱动测试中非常常用。
10.新加入项目，怎么快速熟悉
当我新加入一个项目时，我通常会按以下流程快速熟悉项目并进入工作状态：
宏观了解业务与目标：通过阅读需求文档、原型图、产品说明书，理解系统的核心业务流程与使用场景；
熟悉系统结构与模块职责：结合架构图、接口文档，了解各模块功能划分、系统调用关系以及测试边界；
掌握测试流程与环境配置：熟悉测试用例管理平台、缺陷管理工具、部署方式、接口联调方式等；
实战驱动学习：通过参与功能提测、回归测试等实际任务，加深对项目的理解；
主动沟通与总结：及时与产品、开发、测试同事沟通不清楚的点，必要时整理接口表、业务流程图、测试点文档，提升效率和复用价值。
我认为快速熟悉项目最重要的是“有结构地学习 + 主动参与实践”。
11.客户发给你一张页面报错的问题截图你会怎么办
当客户提供一张页面报错截图时，我会按照以下步骤进行处理：
分析截图内容：初步判断错误类型（如前端异常、接口返回错误、权限限制等）；
补充上下文信息：主动向客户了解操作路径、使用环境、用户账号、是否可复现等关键信息；
复现与定位问题：在对应环境中还原问题，通过浏览器控制台、接口响应、服务器日志等手段进行分析；
协同修复与反馈：若为测试缺陷则立刻记录Bug并推动修复；若为配置/数据问题则与相关方协同处理，并将分析结果及时反馈给客户。
我认为在处理这类问题时，关键在于快速定位、清晰沟通和跨角色协作能力。
12.怎么把接口串联在一起
在接口测试中，将多个接口串联主要用于模拟业务流程和验证端到端的功能完整性。我的做法是：
分析业务流程：根据接口文档或产品逻辑，确定各接口的调用顺序及其依赖关系；
参数提取与传递：通过提取前置接口的返回参数（如 token、订单号、商品ID 等），动态传入后续接口；
工具实现串联测试：
使用 Postman 的 Tests 和 Pre-request Script 脚本配合环境变量；
使用 JMeter 的 JSON Extractor、变量传递机制；
使用 Python 脚本构建流程自动化，控制灵活、可读性强；
加断言与结果验证：为每个接口设置响应断言，确保整个流程数据链条正确，逻辑闭环。
这种流程化测试方式常用于下单、支付、注册登录等核心链路测试，也是接口自动化测试的重要基础。
13.bug定位思路
通用思路
🔍 通俗理解：Bug 就像“哪里出了故障”，你要像侦探一样排查原因
我们可以按这 五步排查法 来讲👇
🧭 第一步：复现 bug（能稳定重现）
先确认 Bug 是否真实可复现。如果不能复现，就抓关键路径、环境信息、前置条件。
是所有人都有问题，还是特定账号 / 数据？
哪些操作步骤会触发？
是偶发还是必现？
🔎 第二步：界定问题位置
根据现象判断 bug 大概是出在哪一层：
页面报错？查看浏览器控制台（前端问题）
接口异常？抓请求，看 URL / Header / 参数 / 返回值
页面无响应？检查是否是网络或权限问题
服务挂了？看后台日志、Nginx、数据库连接等
🧾 第三步：查日志 / 查看代码 / 控制变量
如果能访问后端日志或测试环境代码，可以进一步验证是否是：
数据异常（null、非法值）
配置缺失（缓存、开关、权限）
代码逻辑 Bug（路径错误、异常没捕获）
🧪 第四步：对比正常情况
正常情况 + 异常情况对比，是最快排查方式：
换个账号是否正常？
相同接口参数下是否一致？
请求差了哪个字段？
🗣 第五步：与开发协作分析
如果自己无法完全定位，就带着操作步骤 + 请求参数 + 报错截图/日志和开发沟通，快速定位根因。
面试术语
我在 Bug 定位过程中，一般遵循以下思路：
复现场景还原：通过测试用例或用户操作流程还原问题，判断是否稳定复现；
问题归因定位：根据错误表现判断问题归属（前端渲染、接口异常、权限问题、环境配置等）；
日志与抓包分析：结合浏览器控制台、接口抓包工具（如 Charles、Fiddler）、后端日志进行深入排查；
数据与环境比对：对比异常与正常场景的数据和配置差异，定位触发条件；
协同开发快速定位：当遇到系统级或代码层问题，会整理操作步骤、请求参数、截图日志，与开发协同定位问题根因。
我认为 Bug 定位最关键的是：清晰的排查路径 + 有效的信息收集 + 跨角色沟通能力。