m0_57735085的博客

常见的 HTTP 响应码1xx（信息性状态码）：请求已接收，客户端可以继续发送请求。：协议已切换。2xx（成功状态码）200 OK：请求成功，返回数据。：请求成功，已创建资源。：请求已接受，正在处理。：请求成功，但无返回内容。3xx（重定向状态码）：资源已永久移动，客户端使用新 URL。302 Found：资源暂时移动，客户端继续使用原 URL。：客户端应访问另一个 URL。：资源未修改，客户端使用缓存版本。4xx（客户端错误状态码）：请求无效，服务器无法理解。：需要认证，未提供有效认证信息。

首先，为模型提供清晰的功能需求和测试场景描述，确保模型能够理解需要测试的核心功能。

测试开发岗位，顾名思义，是在和之间的一个岗位，它结合了传统测试和开发的工作内容，要求测试开发人员不仅有强大的，还要具备一定的，能够用代码来提高测试效率和质量。测试开发岗位结合了传统测试和开发的职责，主要侧重于通过编程技术提升测试效率，保证软件质量。：编写自动化测试脚本，设计和实现自动化测试框架，减少手动测试的工作量，确保功能的正确性和系统的稳定性；：根据项目需求设计和开发测试工具，集成到持续集成（CI/CD）流程中，确保自动化测试在每次代码变更时都能自动执行；

功能完成与验证：所有计划功能已经完成开发并经过全面的测试验证，无阻塞性缺陷；缺陷管理：所有重大和高优先级的缺陷已修复，剩余的中低优先级缺陷不会影响关键功能；性能验证：版本的性能指标（响应时间、吞吐量等）符合预期，且经过压力测试验证无瓶颈；安全性与稳定性：系统无重大安全漏洞，经过稳定性测试验证，具备容错能力；兼容性与回归测试：兼容性测试已完成，确保新版本不会影响已有功能，回归测试无关键问题；用户体验：用户界面和交互符合设计要求，用户体验顺畅；版本文档。

及时与产品、开发、测试同事沟通不清楚的点，必要时整理接口表、业务流程图、测试点文档，提升效率和复用价值。我认为快速熟悉项目最重要的是“有结构地学习 + 主动参与实践”。

用过 Monkey 工具，它是 Android 自带的随机事件测试工具，主要用于稳定性测试。我曾用它对项目进行过 10,000 次事件压力测试，发现过由于按钮快速重复点击导致的空指针崩溃，也遇到过因网络请求未限流导致界面卡死的问题。通过 logcat 和 crash 报告进行分析后修复，增强了 APP 的稳定性。

工具核心用途特点关键词适合场景使用门槛Postman接口手动调试简单好用、调试利器接口初测、联调★Swagger接口文档生成 & 试用自动生成、接口说明书、在线试用文档同步、联调协作★JMeter压力测试批量请求、并发测试、性能监控上线前压测★★★Apifox一体化接口平台文档 + 测试 + Mock + 自动化测试团队开发、项目管理★★开发调试接口 → 用 Postman生成接口文档 → 用 Swagger接口做压测 → 用 JMeter。

可以把断言理解成验收标准我们不是只发出请求，而是要检查接口返回的结果是不是“对的”。比如你点外卖后，收到的不是奶茶而是汉堡，你当然要投诉 —— 接口断言就是“检查你点的是不是你要的”。

不仅在工作中，我在生活中也有总结复盘的习惯。比如做完一件事情之后，我会习惯性地回顾一下过程有没有更高效的方式，或者有没有哪一步可以优化。举个简单的例子，像我平时做 PPT 或准备答辩汇报时，完成后我会先自己过一遍内容逻辑和语言表达，再总结哪些地方讲得不够清晰，下次就会改进表达顺序或者精简内容结构。包括我日常学习也是一样，比如看完一段测试视频或学完一门课程，我会写笔记，整理成知识框架，而不是学完就放那。

这是整个测试生命周期（STLC）的基本框架。

兴趣驱动：我在参与项目的过程中，曾经担任过开发和测试相关的工作，对比之后发现自己更喜欢测试工作中那种系统性分析和缺陷挖掘的过程，觉得很有成就感。能力匹配：我性格比较细心、耐心，喜欢从不同角度思考问题，擅长发现隐藏的逻辑漏洞。我认为这些特质更适合测试岗位，也更容易在这个方向上发挥优势。已有积累：我也系统学习了软件测试相关的技术，比如功能测试、接口测试、自动化测试等，并结合实际项目做过应用，具备一定的基础和实操经验。

Apache JMeter 是一款基于 Java 的开源性能测试工具，广泛用于对 Web 应用、API 接口、数据库服务等系统进行压力测试和负载测试。它支持模拟多个并发用户访问，提供图形化界面以及丰富的插件和扩展脚本能力，常用于系统性能评估和接口稳定性验证。就是服务器的“处理器太累了”，忙不过来，表现为：CPU 占用率持续飙高（比如 80%、90%、甚至 100%）响应慢、卡顿、甚至服务崩溃系统风扇狂转，后台日志刷不停这就像你连续处理很多任务没休息，容易“过载罢工”。

Mock用假的数据或接口来“模拟”真实的行为或系统，以便提前进行开发或测试。回归测试就是每次修改了代码后，再重新跑一遍以前正常的功能，确保改动没有影响其它地方。它就像每次装修房子后，都要检查水电有没有被破坏。🛠️验证旧功能没被破坏🧱在修改代码之后执行⚙️可手动、可自动化📈提升产品稳定性与发布质量。

项目Alpha 测试Beta 测试执行者开发团队内部人员外部用户、真实客户环境开发端、测试环境真实或模拟真实的用户环境目的发现系统级缺陷，验证功能完整性收集用户体验反馈，检测边界问题参与用户不对外开放，内部专属小范围开放，真实目标用户产品成熟度功能基本完成，但仍可能频繁修改接近发布版本，问题较少是否可控高度可控，问题易重现不可控性高，问题更真实上线前后一般在上线前紧接 Alpha 后，正式发布前冒烟测试就像你买了一台新电视，先插电试试看能不能开机、换台、调音量。

项目主键（Primary Key）外键（Foreign Key）索引（Index）功能唯一标识记录建立表与表之间的引用关系提高查询效率唯一性唯一且非空可重复、可为空可唯一可非唯一数量限制每张表最多一个主键可有多个外键一个表可以有多个索引是否约束是：自动创建唯一约束是：参照完整性约束否：仅优化性能，不限制数据合法性应用场景用户ID、订单号等用户与订单、分类与文章高频查询字段如邮箱、手机号、时间戳等。

浏览器接收到响应后，会：解析 HTML->下载和解析 CSS、JS、图片、字体等资源（并发请求）->构建 DOM 树、CSSOM 树->生成渲染树（Render Tree）->布局（计算元素大小和位置）->绘制（渲染像素到屏幕）浏览器输入 URL 后经历：URL 解析、DNS 查询、TCP 三次握手、发送 HTTP 请求、服务器响应、浏览器渲染流程（构建 DOM、CSSOM、渲染树、布局与绘制）、执行 JS 脚本及资源加载，最终页面展示。若是 HTTPS，还需完成 TLS 握手，协商密钥、加密算法等。

同样的操作流程，不一定每次都会触发的问题，具有不稳定性、偶发性，难以重现。例如：偶尔登录失败，但刷新就好了有时下单卡死，重试又成功安卓部分机型偶尔白屏、崩溃。

概念定义谁来定严重程度（Severity）描述Bug 对系统本身的影响有多严重，越严重越说明功能损坏严重测试人员评估为主优先级（Priority）描述Bug 处理的紧急程度，越高表示越早要修项目经理或开发协商决定Bug（缺陷）指的是产品在实现中没有达到需求、设计或用户预期的表现，包括：功能错误（逻辑不对、结果出错）页面异常（样式错乱、元素缺失）性能问题（卡顿、响应慢）安全问题（越权、信息泄露）维度判断依据功能需求是否偏离文档/原型描述UI表现是否符合 UI 规范、是否明显错误。

测试目标：验证“订单管理模块”是否满足功能需求测试范围：订单创建、查询、取消；不包括物流配送接口测试方法：功能测试、接口测试（Postman）、边界值分析、负向用例测试人员：1名测试+1名开发支持时间计划：用例设计2天、执行3天、回归2天风险：接口文档不完整 → 提前协调产品补全交付物：测试计划、用例文档、测试日报、测试总结报告。