主页 | 马里凡

Vuepress Hope

一个强大的Vuepress主题。

Mr.Hope

Mr.Hope是Vuepress Hope主题的作者，点击跳转到Hope的博客。

友情链接

包括一些教程网站、博客网站等。

开个盲盒

点击后随机跳转到本站的一个页面

21个提升英语口语的办法

原文：21 Most Effective Ways to Improve Your English Speaking Skills

马里凡2025/12/5小于 1 分钟

软件测试入门

一、基本认知

1.公司开发的软件产品为个人toC或企业toB或政府toG提供价值服务，软件测试的本质是在有限的人力物力时间资源前提下保障产品交付到客户手里的质量，使用户满意买单，也为社会创造价值，最终公司获利。

2.项目团队成员：

一般公司为客户提供完整解决方案，解决方案分解为多个产品，一个复杂的产品可能还分解为多个项目进行运作（一个简单产品就用一个项目运作），每个项目要完成明确范围的产品功能需求目标。
现代公司都是项目制运作：用户需求痛点/市场调研/项目投入产出/风险分析等，首先解决Why为什么要做和What做什么的问题，产品经理/项目经理编写立项材料，领导审批通过后启动项目，项目经理组建项目团队人员，制定时间路线图、产品/开发/测试分解任务排期。
项目团队成员角色和负责范围：
产品经理：输出产品需求文档，开发/测试对需求有疑问时，需澄清需求，同事负责对接业务人员，将业务人员的原始需求转化为项目详细需求，制定业务交互流程和产品解决方案。
项目经理：项目整体管控协调，制定项目任务详细排期表，协调人力/物力资源，推动风险阻塞事项，管控项目进度。
开发工程师：基于产品需求设计项目整体技术架构、模块设计、接口设计、数据库表设计，输出开发设计文档，对需求编码实现，完成自测并提交测试，缺陷修复，测试/生产环境部署。
测试工程师：基于产品需求文档和开发设计文档，设计测试方案并编写用例，包括前端功能测试、后端接口测试、性能测试、稳定性测试等，测试执行，提交闭环测试缺陷，输出测试报告，功能上线后进行生产验证。
其他关联人员角色：
运营/运维人员（有的产品开发兼任，无专岗）：需求上线后监控生产环境软件或系统运行使用情况，客户流量情况，CPU/内存资源使用监控，异常日志监控，出现异常事件时及时发现并紧急处理，包括资源扩容/隔离重启服务/反馈开发人员排查问题等。
业务人员（有的产品兼任，无专岗）：销售，客服等相关业务人员，能够直接对接客户。能够收集用户反馈、用户痛点，反馈产品经理原始需求。
关联系统的人员：产品需求澄清或联合制定产品解决方案、项目推动依赖事项、开发之间联调、测试之间联测（端到端系统测试）

马里凡2025/11/28大约 6 分钟

Git的基本使用

🎯 核心原则

主分支保护：main/develop 分支只接受 Pull Request
功能隔离：每个功能/修复都在独立分支开发
代码审查：所有变更必须经过 peer review
持续集成：自动运行测试和检查
清晰历史：保持提交历史的可读性和可追溯性

马里凡2025/12/20大约 6 分钟

访问请求流程

马里凡2025/12/20小于 1 分钟

关于TCP

本文参考JavaGuide:有了 HTTP 协议，为什么还要有 RPC ？

总结

问题：TCP 是流式协议，没有消息边界
现象：会出现"粘包"（多个消息粘在一起）和"拆包"（一个消息被拆开）
解决方案：消息头 + 消息体
- 消息头：固定格式，包含消息体长度等信息
- 消息体：实际要传输的数据
工作流程：
- 发送方：计算长度 → 添加头部 → 发送
- 接收方：读取头部 → 解析长度 → 读取对应长度的数据
  
  更细节知识参考：为什么要组装发送的数据
  
  基于上方文章补充：当接收端收到的消息长度小于 Content-Length 时，说明还有些消息没收到。那接收端会一直等，直到拿够了消息或超时。
优点：
- 明确的消息边界
- 可以传输任意长度的数据
- 支持复杂协议扩展

纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于界定 消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。这就是为什么几乎所有基于 TCP 的协议（HTTP、WebSocket、Redis 协议等）都需要定义自己的消息格式来界定消息边界的原因。
TCP 是传输层的协议 ，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的 应用层协议 而已。

马里凡2025/12/20大约 4 分钟

关于UDP

UDP的特点

UDP的三个特点：面向无连接、不可靠、基于数据报。

基于数据包

基于数据报是指无论应用层交给 UDP 多长的报文，UDP 都照样发送，即一次发送一个报文。至于如果数据包太长，需要分片，那也是IP层的事情，大不了效率低一些。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。而接收方在接收数据报的时候，也不会像面对 TCP 无穷无尽的二进制流那样不清楚啥时候能结束。正因为基于数据报和基于字节流的差异，TCP 发送端发 10 次字节流数据，而这时候接收端可以分 100 次去取数据，每次取数据的长度可以根据处理能力作调整；但 UDP 发送端发了 10 次数据报，那接收端就要在 10 次收完，且发了多少，就取多少，确保每次都是一个完整的数据报。