01 功能覆盖——别让“正常流程”骗了你
99%的测试新手，都在做同一件事：把需求文档里的功能点，一条一条翻译成用例。用户登录、添加商品、提交订单——这些“正例”写出来，所有人都能跑通。
真正的杀手在边界。一个电商系统的“限时抢购”功能，正常流程是：用户点击抢购→扣减库存→生成订单。但测试用例只覆盖这个流程，等于给Bug开了后门。
功能覆盖的靠前维度：正例是基础，反例是灵魂。
反例怎么写？三个方向：
- ►输入反例：金额输入负数、手机号输入字母、日期选择过去时间
- ►操作反例：未登录就下单、库存为0时点购买、同时用两个设备抢同一个商品
- ►状态反例：订单已取消再支付、商品已下架再加入购物车、优惠券已过期再使用
一个真实案例：某支付系统，测试用例覆盖了所有正常支付流程，唯独没测“支付过程中网络中断”的场景。上线靠前天，用户支付成功但系统没收到通知，订单状态卡在“待支付”。修复成本：3个通宵，200万用户投诉。
反例不是Bug，反例是Bug的探测器。
功能覆盖不是写“用户能做什么”，而是写“用户不能做什么，但做了会怎样”。每一条正例，配3条反例。这是维度一。
02 数据驱动——同一个操作，不同数据，不同结果
同一个“搜索商品”功能，输入“手机”和输入“空字符”，结果天差地别。但很多测试用例只写了一个数据——“手机”。
数据驱动的核心：用数据维度，覆盖逻辑分支。
举个栗子。一个登录功能，逻辑是“用户名+密码”验证。测试用例只写“正确用户名+正确密码”，等于只测了1条路径。数据驱动怎么做？
- ►合法数据边界：用户名1个字符、50个字符、包含特殊符号
- ►非法数据类型：用户名输入SQL注入语句、密码输入HTML标签
- ►等价类划分：用户名分为“已注册”“未注册”“已注销”三类
- ►组合数据：正确用户名+错误密码、错误用户名+正确密码、两个都错
一个典型的数据驱动案例：某CRM系统，客户信息导入功能。测试用例只用了10条数据测试，全通过。上线后，用户导入10万条数据，系统崩溃。原因：数据量大时，内存溢出。测试数据只有10条，根本触发不了这个条件。
数据驱动不是“多写几条数据”，而是“用数据覆盖所有代码分支”。
每一条测试用例，至少准备3组数据：正常值、边界值、异常值。如果系统有状态（如订单状态：待支付、已支付、已发货），每个状态都要配一组数据。
数据是测试的子弹，种类决定杀伤力。
03 场景串联——单个功能没问题，组合起来全是坑
这是测试用例质量的分水岭。80%的测试人员，只测“单个功能”。登录没问题、下单没问题、支付没问题——但用户从登录到支付，中间断了。
场景串联的核心理念：用户不是点一个按钮就走的，用户是一条线。
举例：一个在线教育平台
- ►单功能测试：注册OK、选课OK、支付OK、看视频OK
- ►场景串联测试：用户注册→选课→支付→看视频→评价→退款
第二个场景，才真正暴露问题：支付成功后，课程状态更新延迟了3秒；退款后，用户还能看视频10分钟。
场景串联怎么做？
- ►正向流程：用户从入口到出口的完整路径
- ►逆向流程：用户在中途退出、取消、返回
- ►分支流程：用户选择不同选项（如支付方式：微信、支付宝、银行卡）
- ►并发流程：两个用户同时操作同一资源（如抢最后一个库存）
一个血的教训：某外卖平台，单功能测试都过了。场景串联测试没做“用户下单后取消订单再重新下单”。结果上线后，用户取消订单后，优惠券不返还；重新下单时，系统提示“您已使用过该优惠券”。用户怒骂“骗子”。
Bug不在功能里，Bug在功能之间。
场景串联，是把一个个孤岛连成大陆。每个场景至少包含3个功能点，每个功能点之间的状态转换，都要验证。
04 环境差异——开发环境跑得欢，生产环境死给你看
“在我电脑上没问题”——这句话是测试界最大的谎言。
环境差异是Bug的温床。开发环境、测试环境、预发布环境、生产环境，配置不同、数据不同、网络不同，结果天差地别。
环境维度的核心：不是“功能能不能用”，而是“在什么条件下能用”。
环境差异测试的四个层级：
- ►操作系统：Windows 10 vs Windows 11，MacOS vs Linux
- ►浏览器：Chrome vs Firefox vs Safari vs Edge
- ►设备：手机屏幕 vs 平板 vs 电脑，iOS vs Android
- ►网络：WiFi vs 4G vs 5G，弱网 vs 断网
一个真实案例：某SaaS系统，所有测试都在Chrome上完成，全部通过。客户用Safari访问，页面布局全乱，按钮点不了。原因：CSS兼容性问题，Chrome自动修复，Safari不会。修复成本：2周，客户流失30%。
更隐蔽的环境差异：数据环境。开发环境只有100条数据，生产环境有100万条。查询功能在开发环境0.1秒返回，在生产环境卡死10分钟。这不是功能问题，是环境问题。
环境不是背景，环境是变量。
测试用例中，必须标注“测试环境”。每个关键功能，至少覆盖2种环境组合。如果资源有限，优先覆盖用户量最大的环境（如Chrome+Windows+WiFi）。
05 可测性——写出来别人看不懂，等于没写
这是最容易被忽视的维度。很多测试用例，写的人自己都看不懂。
“输入用户名和密码，点击登录，验证登录成功”——这条用例，100个人有100种执行方式。用户名是什么？密码是什么？登录成功怎么验证？全没写。
可测性的核心：测试用例不是给自己看的，是给执行者看的。
高质量测试用例的四个要素：
- ►前置条件：执行前，系统处于什么状态（如“用户已注册但未登录”）
- ►测试数据：具体数值（如“用户名: test01, 密码: 123456”）
- ►执行步骤：每一步的操作（如“1. 打开登录页面 2. 输入用户名 3. 输入密码 4. 点击登录按钮”）
- ►预期结果：可观察、可验证的结果（如“页面跳转到首页，右上角显示用户昵称”）
一个反面教材：“测试用户修改密码功能，验证修改成功”。执行者问：怎么算修改成功？是收到短信？还是页面提示？还是数据库字段变了？没人知道。
不可执行的测试用例，是废纸。
可测性的检查标准：给一个不懂业务的人看，他能按照用例执行，并且判断结果是否正确。如果做不到，说明可测性不及格。
总结
5个维度，不是选择题，是必答题。
- ►功能覆盖：正例+反例，每一条正例配3条反例
- ►数据驱动：正常值+边界值+异常值，每个状态配一组数据
- ►场景串联：单功能+组合场景，每个场景至少3个功能点
- ►环境差异：开发环境+生产环境，至少覆盖2种环境组合
- ►可测性：前置条件+测试数据+执行步骤+预期结果，缺一不可
写100条低质量用例，不如写20条高质量用例。前者浪费工时，后者消灭Bug。
从现在开始，每写一条用例，问自己5个问题：反例写了吗？数据够吗？场景连了吗？环境换了吗？别人能看懂吗？
5个问题，5个维度。做到，你的测试用例缺陷检出率，不止翻倍，是翻3倍。