Fake
定义Fake(伪对象) 在软件测试、尤其是单元测试和测试开发中,是一种常见的 Test Double(测试替身)。 Fake 是一种 “带有简化实现的替代对象”,它能部分模拟真实对象的行为,但不完全等价。 它通常 有实际逻辑、能跑起来,但只是 简化版 / 非生产级。 假设业务真正使用:MySQL 数据库、Redis 缓存、文件存储系统 这些在单元测试中启动非常慢,也很重。 于是你可以构造 Fake:FakeDB(伪数据库):用 内存 map 存储数据,不用启动真正的 MySQL;提供 find/add/update 接口;测试环境可运行、速度快。FakeCache(伪缓存):用 map 代替 Redis;实现 get/set 逻辑 它们可以运行,但不能用于生产,只适合测试。 样例1234567891011121314151617181920212223242526272829303132type User struct { ID int Name string}type UserRepo interfac...
Stub
定义Stub(桩)是 Test Double(测试替身)的重要类型。 Stub(桩)是用于替代真实依赖,但会返回“固定的、预设的”结果的对象。 Stub 是一种测试替身,用来替代真实依赖,返回预设的、固定的数据,使单元测试可控、快速、可靠。 用途 控制依赖的返回结果:数据库查询、三方 API 返回、RPC 结果…… 模拟各种测试场景:查询成功、查询失败、超时、无数据….. 让单元测试更快、更稳定、更可控:不用访问真实网络 / 数据库,执行速度飞快。 示例假设有如下函数 1234567func GetUserNameByID(repo UserRepository,id int)string{ user,err:=repo.FindByID(id) if err!=nil{ return "unknown" } return user.Name} 可以自由控制返回的数据,Stub实现为: 1234567891011type StubUserRepository struc...
Dummy对象
定义Dummy 对象(哑对象)是软件测试和单元测试中经常出现的概念,它属于 Test Double(测试替身) 的一种。 Dummy 对象是一种“什么都不做,只为了占位置”的对象。 它不会被真正使用、也不参与逻辑,只是为了满足参数要求,让程序能够正常运行。 它就像“哑巴”,不会说话、不做事、不参与逻辑,仅仅存在。 核心特征:只占位,不使用。 使用场景 函数或类需要某个参数,但测试时根本不需要用到这个参数 例如: 123func Register(user User,logger Logger){ //测试时只关注user 而不是logger} 测试时logger可以用Dummy,对象只为了占位置 避免因为依赖导致无法进行单元测试 例如依赖数据库、网络、日志系统… 但你测试的函数根本不需要它 → 用 Dummy 代替。
Python基础
注释加入注释并不会对代码的运行产生影响,但加入注释可以使代码更加易懂易用。 1234567# 用 # 字符开头的是单行注释"""跨多行字符串会用三引号(即三个单引号或三个双引号)包裹,但也通常被用于注释""" 一切皆对象在 Python 中,你无需事先声明变量名及其类型,直接赋值即可创建各种类型的变量: 12345678910111213>>> x = -3 # 语句结尾不用加分号>>> x-3>>> f = 3.1415926535897932384626; f # 实在想加分号也可以,这里节省了一行3.141592653589793>>> s1 = "O">>> s1 # 在 Python 中双引号和单引号的作用相同'O'>>> b = 'A' == 65 # 'A' 和 65 不是一个数据类型,所以不相等>>...
身份证输入框测试用例设计
总结身份证输入框测试需覆盖格式校验、业务规划(年龄/性别/地址)、兼容性、安全性、用户体验五大维度,设计正向与反向用例合法性识别、错误提示及容错处理。 详细测试用例设计格式校验(核心:18位编码规则)业务规则验证(解析编码含义)交互与兼容性安全性与容错特殊场景
SQL基础操作
基础查询查询所有列1SELECT * FROM table_name; *表示通配符,*表示选择表中的所有列table_name表示需要查询的表的名称 查询多列1SELECT column1,column2,... FROM table_name; 这条语句会返回table_name表中的column1,column2,…列的所有行 使用别名1SELECT first_name AS name,last_name AS surname FROM table_name AS tn; 这条语句会返回表中的first_name,last_name列,并将它们分别重命名为name和surname。同时table_name被重命名为tn 查询结果的过滤1SELECT column1,column2,... FROM table_name WHERE condition; WHERE子句可以根据条件过滤结果condition:限制条件 查询结果的排序1SELECT column1,column2,... FROM table_name ORDER BY column1 [ASC|DE...
心跳检测
定义心跳检测(Heartbeat)就是客户端定期给服务器发一个“我还活着”的小包(通常无业务意义)。 目的:检测客户端是否掉线;保持 NAT / 防火墙映射不过期(重要);让服务端维护在线状态、回收资源 心跳检测的模式模式A:客户端主动发送 → 服务端被动检测(常用)客户端每隔 N 秒 发送一个 ping服务端收到后更新“最后活跃时间 last_active” 优点:简单稳定缺点:服务器压力稍大(要记录时间) 模式 B:服务端主动发 → 客户端回 pong(WebSocket 常用)Server: pingClient: pong(自动回复) 优点:服务端主动性强,适合 WebSocket缺点:需要维护 ping loop 心跳机制的核心思想服务器维护每个连接的两个字段: 12conn.last_active // 最近一次接收消息或心跳的时间戳conn.timeout // 超时时间,例如 60s 每隔一段时间(例如 10 秒),服务器进行一次检查: 12if now - conn.last_active > timeout: c...
TCP的三次握手和四次挥手
TCP三次握手(建立连接)TCP是面向连接的,需要通过三次握手建立可靠连接 12345客户端(Client) 服务端(Server) | ------ SYN = 1, seq = x ------> | | <--- SYN = 1, ACK = 1, y,x+1 ---| | ------ ACK = 1, ack = y+1 -----> |连接建立 第一次:Client->Server:SYN=1客户端发送一个SYN包(同步序列号),告诉服务器:我要发起连接,并带上初始序列号seq=x 让服务器知道客户端想建立连接 第二次:Server->client:SYN=1,ACK=1服务器收到SYN后,发送SYN+ACKACK=1表示:我收到了你的SYN,确认号ack=x+1SYN=1表示:我也准备好了建立连接,序列号seq=y 服务器同意连接服务器也要同步序列号(SYN) 第三次:Client->...
LRU页面置换算法
定义LRU(最近最少使用)算法就是:每次需要淘汰页面时,选那个“最长时间没被访问”的页面换出去。 它是一种典型的缓存置换算法,用来决定内存不够时应该把哪一页踢掉。 LRU 的核心思想:过去访问行为预测未来访问行为。 举例设有 3 个物理块,访问序列:1, 2, 3, 2, 4, 1, 2 我们模拟 LRU: 步骤 访问 内存状态 淘汰 1 1 1 - 2 2 1 2 - 3 3 1 2 3 - 4 2 1 3 2 2刚被访问,放到最新 5 4 3 2 4 淘汰1,最久没用 6 1 2 4 1 淘汰3 7 2 4 1 2 - 思想:每次访问都把页面放到“最新”位置。淘汰最久没用的。 实现LRU 链表(或双端队列)实现: 最新访问的页放队尾最久未访问的页放队头缺页时:淘汰队头每次命中:把该页移动到队尾 缺点:需要频繁移动节点,时间 O(1),但真实硬件上开销仍然不小。 硬件支持的“访问位 + 时钟”近似 LRU: 因为真正 LRU 实现太重,所以 CPU 给每个页表项提供: Referenced bit(访问位,R bit)Dirt...
健全性测试
定义“健全性测试”(Sanity Testing)是一种软件测试类型,属于回归测试(Regression Testing)的子集,用于在对软件做出小范围修改或修复缺陷后,快速验证关键功能是否仍能正常工作。 健全性测试是指在软件新版本发布或修改后,检查关键模块是否“健全”(即是否仍然可用、逻辑未被破坏)。 其核心思想是:“不用全面测,只测关键改动相关的核心功能,确认系统基本可用。” 目的 验证 bug 修复是否成功; 验证修改是否未引入新的严重问题; 决定是否需要进行更全面的回归测试。 特点 项目 内容 测试范围 小,主要针对改动处或相关功能 执行时间 短,几分钟到几小时 测试深度 浅,不做全面验证 触发时机 修复缺陷或版本轻微更新后 执行者 通常由测试人员或开发人员快速执行 与其他测试的对比 类型 目标 范围 时间 冒烟测试(Smoke Testing) 确认系统是否能启动、主要功能是否可运行 宽但浅 每次构建后 健全性测试(Sanity Testing) 验证修复或小改动是否未破坏核心逻辑 窄但针对性强 修复或补丁后 回归...
