当测试发现"这个功能测不了"、"加个日志就能定位"、"这个模块没法 Mock"时使用此技能。从可控性(能否控制测试条件)、可观察性(能否看到内部状态)、可隔离性(能否独立测试)、自动化性和可诊断性五个维度评估系统的可测试性水平,给出具体的系统改进建议和推动策略。可测试性差的系统一定质量差——不是因为系统本身不好,是因为你根本测不透它。输出可测试性评估报告和各维度的改造建议。 ⚠️ 本技能含废弃测试清理建议,执行前请确认非关键数据。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
编程
测试批判性思维
试用当需要挑战已有假设、挖掘隐含约束、发现"所有人都没想过"的测试场景时使用此技能。测试中最常犯的错误是接受了需求文档里的隐含假设——比如"用户一定会有网络"、"输入一定有内容"、"操作顺序一定正确"。用「如果不呢」的深度质疑方式反向思考,暴露那些被默认为"正常"的异常场景。每一个测试场景都应该走一遍"如果这个假设不成立呢"的质疑流程。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
它能做什么
当需要挑战已有假设、挖掘隐含约束、发现"所有人都没想过"的测试场景时使用此技能。测试中最常犯的错误是接受了需求文档里的隐含假设——比如"用户一定会有网络"、"输入一定有内容"、"操作顺序一定正确"。用「如果不呢」的深度质疑方式反向思考,暴露那些被默认为"正常"的异常场景。每一个测试场景都应该走一遍"如果这个假设不成立呢"的质疑流程。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
技能文档
⚠️ 安全警告:本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证;测试前应脱敏/掩码处理。 本技能仅在 workspace/ 输出评估文件,不持久化、不外传、不跨会话复用。
测试批判性思维
核心原则
对每个"正常"都问"异常呢?";对每个"确定"都问"假设呢?" 本技能适用于测试用例查漏补缺、需求深度分析和风险评估等需要逆向思考的场景。
质疑框架
5W1H 质疑法
What(是什么):
├─ 这个功能是什么?
├─ 这个规则是什么?
├─ 这个约束是什么?
└─ 如果不是这样会怎样?
Why(为什么):
├─ 为什么要有这个功能?
├─ 为什么要有这个规则?
├─ 为什么是这样实现?
└─ 如果没有这个为什么会怎样?
Who(谁):
├─ 谁在用这个功能?
├─ 谁负责这个模块?
├─ 谁会影响这个功能?
└─ 如果换一个人会怎样?
When(什么时候):
├─ 什么时候用这个功能?
├─ 什么时候触发这个规则?
├─ 什么时候会出问题?
└─ 如果换个时间会怎样?
Where(在哪里):
├─ 在哪里使用这个功能?
├─ 在哪里存储这些数据?
├─ 在哪里会出现问题?
└─ 如果换个地方会怎样?
How(怎么做):
├─ 怎么实现这个功能?
├─ 怎么触发这个规则?
├─ 怎么处理异常情况?
└─ 如果换个方式会怎样?
逆向思维
正常 → 异常
├─ 正常输入 → 异常输入(空值、超长、特殊字符)
├─ 正常流程 → 异常流程(中断、失败、超时)
├─ 正常数据 → 异常数据(空、脏、大量)
└─ 正常环境 → 异常环境(断网、高负载、硬件故障)
确定 → 假设
├─ 用户会正常操作 → 用户会误操作
├─ 网络会正常 → 网络会异常
├─ 数据会正确 → 数据会错误
└─ 服务会正常 → 服务会故障
存在 → 不存在
├─ 数据存在 → 数据不存在
├─ 服务可用 → 服务不可用
├─ 权限足够 → 权限不足
└─ 资源充足 → 资源不足
假设挖掘
常见假设类型:
├─ 用户行为假设
│ ├─ 假设:用户会按预期操作
│ ├─ 反例:用户误操作、恶意操作
│ └─ 追问:用户不按预期操作会怎样?
│
├─ 环境假设
│ ├─ 假设:环境会正常
│ ├─ 反例:网络异常、服务故障
│ └─ 追问:环境异常会怎样?
│
├─ 数据假设
│ ├─ 假设:数据会正确
│ ├─ 反例:数据缺失、数据错误
│ └─ 追问:数据异常会怎样?
│
├─ 时序假设
│ ├─ 假设:操作会按顺序执行
│ ├─ 反例:乱序执行、并发执行
│ └─ 追问:时序异常会怎样?
│
└─ 依赖假设
├─ 假设:依赖服务会正常
├─ 反例:依赖服务故障
└─ 追问:依赖异常会怎样?
"那又怎样" 追问法
发现问题 → 那又怎样?
│
├─ 影响一个功能 → 那又怎样?还影响什么?
│ └─ 示例:登录失败 → 那又怎样?→ 无法访问任何功能
│
├─ 影响一个用户 → 那又怎样?还影响谁?
│ └─ 示例:VIP用户无法支付 → 那又怎样?→ 影响收入
│
├─ 影响一个数据 → 那又怎样?还影响什么数据?
│ └─ 示例:订单数据错误 → 那又怎样?→ 影响库存、财务
│
└─ 影响一个系统 → 那又怎样?还影响哪些系统?
└─ 示例:支付系统故障 → 那又怎样?→ 影响所有交易
应用场景
用户说"帮我测试登录功能" → 应用5W1H质疑法:如果用户名不存在?如果密码错误?如果网络中断? → 应用逆向思维:正常登录→异常登录(空密码、超长密码、SQL注入) → 应用"那又怎样"追问:登录失败→那又怎样?→无法访问任何功能
用户说"密码长度至少8位" → 应用规则质疑:如果刚好8位?超过100位?全是空格?包含emoji? → 挖掘隐含假设:假设用户不会用特殊字符
用户说"这个功能看起来很简单" → 触发本技能进行深度质疑,挖掘"简单"背后的隐藏风险
思维练习
练习1:功能质疑
功能:用户登录
正常思维:
- 用户输入用户名密码
- 系统验证
- 登录成功
批判性思维:
- 如果用户名不存在会怎样?
- 如果密码错误会怎样?
- 如果用户输入会怎样?
- 如果用户同时在多设备登录会怎样?
- 如果用户登录后长时间不操作会怎样?
- 如果网络中断会怎样?
- 如果数据库挂了会怎样?
- 如果用户恶意暴力破解会怎样?
练习2:规则质疑
规则:密码长度至少8位
正常思维:
- 验证密码长度是否≥8
批判性思维:
- 如果密码刚好8位会怎样?
- 如果密码超过100位会怎样?
- 如果密码全是空格会怎样?
- 如果密码包含emoji会怎样?
- 如果密码是常见密码(12345678)会怎样?
- 如果密码包含用户名会怎样?
- 如果密码包含生日会怎样?
- 如果密码长期不更换会怎样?
练习3:数据质疑
数据:用户输入手机号
正常思维:
- 验证手机号格式
批判性思维:
- 如果手机号为空会怎样?
- 如果手机号不是11位会怎样?
- 如果手机号包含特殊字符会怎样?
- 如果手机号已注册其他账号会怎样?
- 如果手机号是虚拟号码会怎样?
- 如果手机号是国际号码会怎样?
- 如果手机号被标记为骚扰电话会怎样?
- 如果手机号运营商不支持会怎样?
练习4:时序与并发质疑
场景:秒杀活动"先到先得"
正常思维:
- 用户点击抢购
- 系统按到达顺序分配库存
- 先到先得
批判性思维:
- 如果两个用户同一毫秒下单会怎样?
- 如果库存只剩1件但有10人同时抢会怎样?
- 如果用户网络快但服务器处理慢,顺序会乱吗?
- 如果用户先下单成功但支付超时会怎样?库存回滚了吗?
- 如果用户用脚本批量抢购会怎样?
- 如果系统时钟不同步,"先到"还能判定吗?
- 如果用户中途取消订单,库存是否立即释放?释放后谁先抢到?
- 如果并发量超出数据库锁能力会怎样?超卖还是死锁?
练习5:状态流转质疑
场景:订单已退款但仍可评价
正常思维:
- 订单完成 → 用户评价 → 评价展示
批判性思维:
- 如果订单已退款,评价入口是否应该关闭?
- 如果退款在用户评价之后发生,已有评价是否保留?
- 如果订单部分退款(退1件留1件),评价权如何处理?
- 如果用户评价后又申请退款,评价展示状态如何?
- 如果订单状态在"已发货"和"已退款"之间快速切换会怎样?
- 如果退款走的是第三方支付通道,本地状态与第三方状态不一致以哪个为准?
- 如果订单被系统自动取消(超时未支付),用户还能看到吗?能评价吗?
- 如果订单状态机缺少"部分退款"这个中间态会怎样?
练习6:跨系统契约质疑
场景:上游系统推送数据格式变更
正常思维:
- 上游推数据 → 我们消费 → 按字段处理
批判性思维:
- 如果上游今天新增一个字段我们没适配会怎样?
- 如果上游删除一个我们依赖的字段会怎样?
- 如果上游字段类型从 int 变成 string 会怎样?我们的反序列化会崩吗?
- 如果上游推送频率从1次/分钟变成100次/分钟会怎样?限流了吗?
- 如果上游推送了"空值"但语义是"未传"而非"传了null",我们区分了吗?
- 如果上游系统维护停推,我们的下游会感知到吗?会报错还是静默?
- 如果上游推送了重复数据(同一条推两次),我们的幂等性保证了吗?
- 如果数据契约没有版本号,上游悄悄改了字段含义我们怎么发现?
常见陷阱
陷阱1:确认偏误
现象:只找支持自己判断的证据,忽略反例
示例:认为"登录功能很简单"→只检查正常登录→遗漏异常场景
破解:强制列出5个"反例/异常情况"再开始测试
陷阱2:锚定效应
现象:被第一个信息锚定,忽略其他可能性
示例:听到"用户量1万"→用例按1万设计→实际要考虑100万
破解:先不看任何限制条件,设计理想用例;再把条件加回来过滤
陷阱3:可得性启发
现象:只测最近出过问题的地方
示例:上次上线是登录模块出Bug→这次死磕登录→忽略了新功能的核心风险
破解:按风险评估矩阵排序,不要凭印象分配测试精力
陷阱4:乐观偏差
现象:默认事事顺利,低估异常概率
示例:"用户一定会按要求操作"→遗漏误操作场景
破解:对每个正常路径追问"如果在这里出错了呢?"
陷阱5:框架效应
现象:被问题表述方式限制了思考范围
示例:"验证删除功能"→只测删除→忽略了恢复/回收站/级联删除
破解:跳出当前模块问"这个功能的上游是什么?下游是什么?"
陷阱6:沉没成本
现象:已经做了大量用例就停止质疑
示例:写了50条查询用例→觉得"够多了"→遗漏了关键的并发查询场景
破解:用例数量和质量无关,强制问"还有没有极端场景没覆盖?"
自检清单
批判性思维应用后检查:
- 是否对每个"应该"都问了"如果不呢?"
- 是否对每个"正常"都问了"异常呢?"
- 是否对每个"确定"都问了"假设呢?"
- 是否挖掘了隐含假设?
- 是否应用了"那又怎样"追问?
- 是否覆盖了反向场景?
检查清单
- 隐含假设是否挑战?
- 证据是否充分?
- 逻辑是否自洽?
- 替代解释是否考虑?
- 结论是否可证伪?
相关技能
当所有分析(需求解构、场景树、边界清单、组合矩阵)都已完成,需要把分析结果转化为结构化的测试用例时使用此技能。专注用例结构规范、分类体系、覆盖策略和优先级编排。不要在分析还没做完时就跳到用例生成——没有充分的输入,用例一定是泛泛的。适用于将前面的分析产出物整合为 P0-P3 分级、可追溯的标准格式测试用例。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
当需要管理测试团队、制定团队目标和绩效标准、或者团队扩招需要面试标准时使用此技能。覆盖测试团队管理(目标设定/KPI 制定/人员成长)、绩效评估(能力模型/360 评估)、招聘面试(面试流程/技术评估标准)和组织建设。不要只管进度不管成长——一个稳定的测试团队靠的是每个人都在不断学习和进步。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
当需求文档信息不够、不知道接下来该问产品什么、或者需要从开发那边获取更多技术细节时使用此技能。很多人测不好不是因为不会设计用例,而是因为一开始就没问对问题。提供需求调研、边界确认、规则挖掘、技术细节追问等不同场景的结构化提问模板,确保在测试设计前获取到足够上下文。每一个问题都标注了问谁、怎么问、什么时候问。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
当团队里有测试新人需要带、想提升团队整体测试水平、或者需要把个人经验转化为团队能力时使用此技能。通过 Pair 测试、经验分享、checklist 沉淀、模板建设和培训材料等方式赋能团队。不要等着新人犯错再教——好的赋能是提前给工具和方法论,让新人在第一次做之前就知道"正确的做法是什么"。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills
在最终输出前对测试用例做最后一轮防幻觉验证:事实核查(引用的需求ID是否存在)、一致性检查(用例之间是否矛盾)、可执行性验证(步骤是否能实际操作)、来源追溯(每个用例是否能追溯到具体需求)。当测试用例已经生成完毕、准备输出了,但你不确定AI有没有编造不存在的功能或需求时,应当使用此技能。这是整个工作流的最终质量守门——如果验证失败,必须返回问题清单要求修正,不得跳过。 本技能属于 QA Test Skills 技能集(49 个技能之一),完整工作流体验需安装全套:npx skills add Kokxi/qa-test-skills