leeyorke入职手册¶
问题复盘¶
思考框架¶
01 | 测试必须先明白什么¶
严禁一上来就什么也不做就开始写测试用例，或者直接上手测试。测试之前必须先明白：
缺陷一定存在。默认系统有问题。
测试无法穷举。承认测试不可能穷举，所以核心问题变成：哪里最可能出问题？出了问题代价最高？这就需要优先把资源砸在破坏力最大的 20% 核心风险(需要思考该产品的高风险场景)上。
杀虫剂悖论。测试用例的效果会随着时间的推移而减弱，需要不断更新和优化测试用例。
02 | 测试点通用梳理框架¶
事物都有共性，产品也不例外，不管你是测试芯片、测试软件、测试电梯、测试杯子、测试手机，测试用例的编写框架都会有共性。测试用例的编写框架如下：
产品测试框架
│
├── Level 1：测试对象（测什么）
│ │
│ ├── 功能（Function）
│ │ ├── 作用：验证产品是否实现需求规定的能力
│ │ ├── 关注：
│ │ │ ├── 功能是否存在
│ │ │ ├── 功能是否正确
│ │ │ └── 功能是否符合业务规则
│ │
│ ├── 数据（Data）
│ │ ├── 作用：验证数据生命周期是否正确
│ │ ├── 关注：
│ │ │ ├── 输入
│ │ │ ├── 存储
│ │ │ ├── 传输
│ │ │ ├── 计算
│ │ │ └── 输出
│ │
│ ├── 状态（State）
│ │ ├── 作用：验证系统状态及状态转换是否正确
│ │ ├── 关注：
│ │ │ ├── 状态创建
│ │ │ ├── 状态迁移
│ │ │ ├── 状态终止
│ │ │ └── 非法状态转换
│ │
│ ├── 接口（Interface）
│ │ ├── 作用：验证系统与外部系统的交互
│ │ ├── 关注：
│ │ │ ├── API
│ │ │ ├── 协议
│ │ │ ├── 消息格式
│ │ │ └── 错误处理
│ │
│ ├── 用户（User）
│ │ ├── 作用：验证不同用户角色下的行为
│ │ ├── 关注：
│ │ │ ├── 权限
│ │ │ ├── 操作路径
│ │ │ ├── 用户体验
│ │ │ └── 误操作
│ │
│ ├── 环境（Environment）
│ │ ├── 作用：验证不同运行环境下的行为
│ │ ├── 关注：
│ │ │ ├── 操作系统
│ │ │ ├── 浏览器
│ │ │ ├── 网络
│ │ │ ├── 硬件
│ │ │ └── 第三方依赖
│ │
│ └── 生命周期（Lifecycle）
│ ├── 作用：验证产品全生命周期行为
│ ├── 关注：
│ │ ├── 安装
│ │ ├── 配置
│ │ ├── 升级
│ │ ├── 运行
│ │ ├── 恢复
│ │ └── 卸载
│
├── Level 2：质量属性（测得好不好）
│ │
│ ├── 功能性（Functional Suitability）
│ │ ├── 作用：验证功能是否满足需求
│ │ ├── 完整性
│ │ ├── 正确性
│ │ └── 适当性
│ │
│ ├── 性能（Performance Efficiency）
│ │ ├── 作用：验证资源消耗与处理效率
│ │ ├── 响应时间
│ │ ├── 吞吐量
│ │ ├── 并发能力
│ │ ├── 资源利用率
│ │ └── 容量上限
│ │
│ ├── 可靠性（Reliability）
│ │ ├── 作用：验证持续稳定运行能力
│ │ ├── 稳定性
│ │ ├── 容错性
│ │ ├── 可恢复性
│ │ └── 可用性
│ │
│ ├── 安全性（Security）
│ │ ├── 作用：验证资产保护能力
│ │ ├── 认证
│ │ ├── 授权
│ │ ├── 保密性
│ │ ├── 完整性
│ │ ├── 审计
│ │ └── 抗攻击能力
│ │
│ ├── 兼容性（Compatibility）
│ │ ├── 作用：验证与其他系统共存能力
│ │ ├── 互操作性
│ │ ├── 协议兼容
│ │ ├── 数据兼容
│ │ └── 版本兼容
│ │
│ ├── 易用性（Usability）
│ │ ├── 作用：验证用户使用成本
│ │ ├── 可学习性
│ │ ├── 可操作性
│ │ ├── 防误操作
│ │ ├── 可发现性
│ │ └── 无障碍能力
│ │
│ ├── 可维护性（Maintainability）
│ │ ├── 作用：验证系统后续修改成本
│ │ ├── 模块化
│ │ ├── 可修改性
│ │ ├── 可测试性
│ │ └── 可观测性
│ │
│ ├── 可移植性（Portability）
│ │ ├── 作用：验证迁移到新环境的难度
│ │ ├── 可安装性
│ │ ├── 可适配性
│ │ └── 可替换性
│ │
│ └── 物理安全（Physical Safety）
│ ├── 作用：验证产品不会伤害人和环境
│ ├── 电气安全
│ ├── 机械安全
│ ├── 热安全
│ ├── 环境适应性
│ └── 法规符合性
│
├── Level 3：失效模式（系统怎么坏）
│ │
│ ├── 缺失（Missing）
│ │ ├── 作用：发现应该有却不存在的行为
│ │ └── 例：订单未生成日志
│ │
│ ├── 错误（Incorrect）
│ │ ├── 作用：发现结果错误
│ │ └── 例：金额计算错误
│ │
│ ├── 超限（Out of Range）
│ │ ├── 作用：发现边界处理问题
│ │ └── 例：年龄允许999岁
│ │
│ ├── 延迟（Delay）
│ │ ├── 作用：发现处理超时问题
│ │ └── 例：支付结果30秒后返回
│ │
│ ├── 中断（Interruption）
│ │ ├── 作用：发现流程被异常终止
│ │ └── 例：升级过程断电
│ │
│ ├── 重复（Duplicate）
│ │ ├── 作用：发现重复执行问题
│ │ └── 例：重复扣款
│ │
│ ├── 顺序错误（Wrong Sequence）
│ │ ├── 作用：发现执行顺序问题
│ │ └── 例：未登录直接支付
│ │
│ ├── 数据损坏（Corruption）
│ │ ├── 作用：发现数据被篡改或破坏
│ │ └── 例：数据库记录异常
│ │
│ ├── 权限失控（Unauthorized Access）
│ │ ├── 作用：发现越权访问问题
│ │ └── 例：普通用户删除管理员数据
│ │
│ ├── 资源耗尽（Resource Exhaustion）
│ │ ├── 作用：发现资源不足问题
│ │ └── 例：内存泄漏
│ │
│ └── 状态不一致（Inconsistent State）
│ ├── 作用：发现多模块状态不同步问题
│ └── 例：订单已支付但库存未扣减
│
├── Level 4：覆盖维度（从哪些角度测）
│ │
│ ├── 正常路径
│ │ └── 作用：验证用户最常见操作流程
│ │
│ ├── 异常路径
│ │ └── 作用：验证错误输入和异常场景
│ │
│ ├── 边界值
│ │ └── 作用：发现临界点缺陷
│ │
│ ├── 等价类
│ │ └── 作用：减少重复测试
│ │
│ ├── 状态转换
│ │ └── 作用：验证状态迁移逻辑
│ │
│ ├── 时序
│ │ └── 作用：验证事件发生顺序
│ │
│ ├── 并发
│ │ └── 作用：验证多线程多用户场景
│ │
│ ├── 容量
│ │ └── 作用：验证数据量增长后的行为
│ │
│ ├── 恢复
│ │ └── 作用：验证故障恢复能力
│ │
│ ├── 升级
│ │ └── 作用：验证版本升级过程
│ │
│ ├── 降级
│ │ └── 作用：验证服务降级策略
│ │
│ └── 回滚
│ └── 作用：验证失败后的恢复机制
│
└── Level 5：风险优先级（先测什么）
│
├── 致命风险（Critical）
│ ├── 作用：优先保证不会造成重大损失
│ └── 例：资金错误、生命安全事故
│
├── 高风险（High）
│ ├── 作用：优先保证核心业务正常
│ └── 例：支付失败、数据丢失
│
├── 中风险（Medium）
│ ├── 作用：保证主要体验质量
│ └── 例：部分功能异常
│
└── 低风险（Low）
├── 作用：优化体验和细节
└── 例：UI显示问题
03 | 测试时间分配法则¶
花80%的时间在20%的核心功能上，花20%的时间在80%的非核心功能上。
根据《人月神话》的时间分配黄金法则：1/3计划, 1/6编码, 1/4软件测试与系统早期测试, 1/4完整系统测试。
在软件设计阶段，参考ISO/IEC 25010:2023标准可以帮助开发者明确质量目标并制定相应的设计策略。例如：
功能适用性设计：确保软件功能能够满足用户需求，考虑功能完整性和正确性，避免功能遗漏和误差。
性能效率设计：优化算法和数据结构，提高软件的性能和资源利用效率。
兼容性设计：确保软件能够与其他系统和产品共存和互操作，避免兼容性问题。
可用性设计：优化用户界面和交互流程，提升软件的易用性和用户满意度。
可靠性设计：设计冗余和容错机制，提高软件的稳定性和可恢复性。
安全性设计：确保数据和信息的安全，防止未授权访问和数据泄露。
维护性设计：采用模块化设计，提升代码的可读性和可维护性，减少变更和测试成本。
可移植性设计：确保软件能够在不同平台和环境中运行，考虑系统依赖和安装便利性。
04 | 产品通用测试框架¶
产品通用测试框架
│
├── 1. 意图验证 ← 对应「意图」维度
│ ├── 1.1 需求覆盖度
│ │ ├── 核心使用场景是否全部实现
│ │ └── 目标用户群的需求是否被满足
│ ├── 1.2 价值实现
│ │ ├── 产品是否解决了它声称解决的问题
│ │ └── 用户能否通过它达成预期目标
│ └── 1.3 规格符合性
│ ├── 实物与设计规格/需求文档的一致性
│ └── 所有声明特性均可验证
│
├── 2. 载体完整性 ← 对应「载体」维度
│ ├── 2.1 材质与结构
│ │ ├── 材料规格符合性（成分、等级）
│ │ ├── 结构完整性（无裂缝、变形、缺损）
│ │ └── 制造精度（尺寸公差、装配间隙）
│ ├── 2.2 外观质量
│ │ ├── 表面缺陷（划痕、气泡、色差、毛刺）
│ │ └── 装配质量（错位、松动、缝隙均匀性）
│ └── 2.3 标识与随附文件
│ ├── 铭牌、警告标识是否清晰、位置正确
│ └── 说明书、合格证、装箱清单完整性
│
├── 3. 功能测试 ← 对应「功能」维度
│ ├── 3.1 功能完整性
│ │ ├── 所有声明功能均存在且可触达
│ │ └── 无缺失功能项
│ ├── 3.2 功能正确性
│ │ ├── 正常输入 → 输出结果正确
│ │ ├── 边界值 / 极限条件下的功能表现
│ │ └── 多功能协同运作是否相互干扰
│ └── 3.3 异常与降级
│ ├── 错误输入 / 误操作时的响应行为
│ └── 局部失效时整体是否进入安全降级状态
│
├── 4. 性能测试 ← 对应「功能」的量化层
│ ├── 4.1 效率
│ │ ├── 响应速度 / 处理速度是否达标
│ │ └── 能耗 / 资源消耗是否在规格范围内
│ ├── 4.2 容量与承载
│ │ ├── 最大承载能力（重量、流量、并发数）
│ │ └── 超载时的行为（拒绝 vs 失效 vs 损坏）
│ └── 4.3 精度与一致性
│ ├── 输出精度是否符合规格
│ └── 多次操作结果的一致性（重复性误差）
│
├── 5. 界面与可用性 ← 对应「界面」维度
│ ├── 5.1 交互可达性
│ │ ├── 操作入口是否清晰可见、易于定位
│ │ └── 操作反馈是否及时明确（声、光、触感、视觉）
│ ├── 5.2 易用性
│ │ ├── 操作步骤是否符合直觉
│ │ ├── 目标用户无需培训能否完成基本操作
│ │ └── 操作所需力度 / 幅度是否在人体工学范围
│ ├── 5.3 信息呈现
│ │ ├── 显示 / 输出内容是否准确、清晰、无歧义
│ │ └── 错误提示是否可被用户理解
│ └── 5.4 无障碍适配
│ └── 特殊用户群（老人、儿童、残障）的可用程度
│
├── 6. 可靠性与耐久性 ← 对应「约束」→ 时间稳定性
│ ├── 6.1 稳定性
│ │ ├── 长时间连续运行的稳定性
│ │ └── 重复操作的一致性（第1次 vs 第N次）
│ ├── 6.2 耐久性
│ │ ├── 机械磨损（摩擦、弯折、按压次数）
│ │ ├── 疲劳寿命（循环载荷下的失效点）
│ │ └── 加速老化（等效使用寿命内的性能衰退）
│ ├── 6.3 故障特性
│ │ ├── 故障率是否满足 MTBF / MTTF 指标
│ │ └── 故障是否可被用户感知（可检测性）
│ └── 6.4 可恢复性
│ ├── 故障后能否自行恢复正常状态
│ └── 可维修性（更换易损件的便利程度）
│
├── 7. 环境适应性 ← 对应「约束」→ 物理环境
│ ├── 7.1 气候环境
│ │ ├── 高温 / 低温下的功能表现
│ │ ├── 高湿 / 浸水条件（防潮、防水等级）
│ │ └── 热冲击（温度骤变时的结构与功能完整性）
│ ├── 7.2 机械环境
│ │ ├── 振动（运输途中及使用中的持续振动）
│ │ └── 冲击 / 跌落（规格内跌落后功能是否正常）
│ ├── 7.3 电磁环境（电子类产品）
│ │ ├── 抗干扰能力（EMS：在外部电磁场中正常工作）
│ │ └── 辐射发射（EMI：不对外部造成超标干扰）
│ └── 7.4 非常规使用场景
│ └── 极端场景、超预期使用方式下的表现与失效模式
│
├── 8. 安全性 ← 对应「约束」→ 伤害防护
│ ├── 8.1 物理安全
│ │ ├── 锐边 / 尖角 / 夹点伤害风险
│ │ ├── 过热 / 起火风险
│ │ └── 机械运动部件的夹伤 / 压伤防护
│ ├── 8.2 化学安全
│ │ ├── 有害物质（重金属、VOC、塑化剂）
│ │ └── 与接触物的兼容性（食品接触、皮肤接触）
│ ├── 8.3 电气安全（电子 / 电力类产品）
│ │ ├── 绝缘性能、漏电防护
│ │ └── 过载 / 过压 / 短路保护机制
│ ├── 8.4 故障安全（Fail-safe）
│ │ ├── 失效时默认进入安全状态（断电、停止、锁定）
│ │ └── 紧急停止 / 安全切断机制是否有效
│ └── 8.5 信息安全（数字类产品）
│ ├── 用户数据保护与隔离
│ └── 未授权访问防护
│
├── 9. 合规性 ← 对应「约束」→ 外部规则
│ ├── 9.1 法规与认证
│ │ ├── 目标市场强制认证（3C、CE、UL、FCC 等）
│ │ └── 行业标准符合性（ISO、IEC、GB 等）
│ ├── 9.2 环保合规
│ │ ├── 有害物质限制（RoHS、REACH）
│ │ └── 能效等级标准
│ └── 9.3 标识合规
│ └── 法定标签、警告语、认证标志的规范性
│
└── 10. 生命周期 ← 时间轴的展开
├── 10.1 出厂前（包装与存储）
│ ├── 包装保护性（防跌落、防压、防潮）
│ └── 存储条件适应性（温湿度、有效期）
├── 10.2 交付节点（开箱体验）
│ ├── 开箱流程顺畅，配件齐全
│ └── 首次使用引导是否充分
├── 10.3 使用中（维护性）
│ ├── 日常清洁的便利性
│ ├── 易损件识别与更换便利性
│ └── 维修可达性（能否被拆开维修）
└── 10.4 报废（处置）
├── 可拆解性（分类回收的可操作性）
└── 材料可回收率
使用这个框架的方式：
拿到一个待测产品时，先过一遍 10 个一级节点，划掉不适用的（杯子直接跳过 8.3、8.5；桌子直接跳过 7.3），再对剩余节点逐条问：”这个测试点在这个产品上，怎么测？测什么值？判断标准是什么？” —— 这三问的答案就是一条测试用例。
工作方法论¶
01 | 学会任务拆解¶
开始做一件事情之前，先问自己几个问题：
先拆解任务。确保拆解后的每个子任务都能在 一小时之内 完成，如果不能，就继续拆解，直到每个子任务都能在一小时之内完成。
归类子任务。用
GTD法则对每个子任务进行归类，你必须知道哪些属于核心任务，哪些属于支线任务。确立优先级。确定每个子任务的执行优先级，按照优先级，先完成核心任务，再完成支线任务。核心任务是你必须完成的任务，而支线任务则是可选的，可能会分散你的注意力。
以上步骤完成后，按照任务清单的优先级严格执行。
目的是什么？
高效完成任务，让你注意力始终保持在主线任务上，不被支线任务干扰。
02 | 测试工程师必备核心素质¶
在执行测试任务时，必须具备以下素质才能将任务执行到位
吹毛求疵。第一个首要必备的素质就是吹毛求疵。即在执行测试时，如果遇到任何蛛丝马迹（不符合直觉，功能有问题），就要立即记录下来。或者直接提缺陷单（并@相关人员，一般是项目相关人员，避免日后出问题说你没测出来）
严谨。将吹毛求疵发现的所有缺陷，进一步测试，确保稳定复现，然后再提缺陷单（确保每一个缺陷单都是有效单）。同时要对缺陷追根究底，努力找到问题的根源。
耐心。面对问题耐心解决，不要泄气，不要抱怨。
强势。如果所有缺陷都未修复，测试人员就不能准予测试通过。假使项目在缺陷为完全修复的情况下依旧要发布新版本，那么及时请上级批准并澄清责任。
03 | 沟通法则¶
学会拒绝。如果别人的请求你不想接受或让你不舒服，或者会占用你过多的时间和精力，你应该学会拒绝。拒绝并不意味着你不愿意帮助别人，而是你需要保护自己的时间和精力，以便更好地完成自己的工作。
学会求助。如果你遇到了困难或者需要帮助，不要害怕寻求帮助。向同事、上级寻求帮助可以让你更快地解决问题，并且也可以建立更好的工作关系。记住： 如果你不会也不问，最终责任就会由你来承担 。
语言表达技巧¶
禁止使用嗯、啊、这个、那个、然后等口头禅。
生活作息与健康保持¶
注意休息，保持充足的睡眠时间，养成良好的作息习惯。保持身体健康，适当锻炼，注意饮食均衡。
早起。养成早上7:00前起床的习惯，起床之后打开窗户**拉伸10分钟**，然后在花10分钟打扫一下卫生。
洗漱。每天洗头、洗脸、刷牙。
做早餐。如果时间来得及就做早餐，恰巴塔欧芹什么的。
出门上班。上班的8小时也要合理安排，详见工作安排一节。
下班。如果是坐地铁，就提前一两站下车，这样可以多走一些路锻炼身体。
早睡。将睡觉时间控制在22:30之前，基本上都是18点之后下班, 回到家算19~20点吧，养成20点准时洗漱的习惯，洗漱预估1小时。洗澡、洗脸、刷牙、洗内裤、洗袜子。衣服做到两天一洗。
看书。如果洗漱完有时间的话，看1小时书，纸质书，电子书都行。22:25准时上床，手机放在桌子上，不要带上床。
人际关系¶
职场人际关系的处理方法和技巧