测试模式分类：结构、行为、并发、异常

做训练模式检测这些年，我接触过不少团队。大家最常问的问题是：“到底该用哪种测试模式？”其实答案不复杂。你先分清楚你要测的是什么——是代码的结构、行为，还是并发下的表现？异常情况要不要覆盖？把这四个方向想透了，测试模式的选择就清晰了。

我个人习惯把测试模式分成四类：结构模式、行为模式、并发模式、异常模式。它们各有各的脾气，也各有各的适用场景。下面我一个个说。

结构模式

结构模式，说白了就是盯着代码的内部结构测。你关心的是函数调没调用，分支走没走到，赋值正不正确。基于代码覆盖率的技术——比如语句覆盖、分支覆盖、条件覆盖——都算结构模式。

特点：测的是“代码写没写对”，不是“功能对不对”。依赖源代码，对被测程序内部了解得越深，测得越准。

适用场景：单元测试初期、关键路径验证、回归测试中验证改动有没有覆盖所有分支。我在项目中遇到过好几次：改了一行if条件，以为只是简单逻辑，结果分支没走到，上线炸了。后来我就要求每段关键分支必须用结构模式覆盖。

行为模式

行为模式不看内部实现，只看输入输出。你给它什么，它该返回什么。黑盒测试、基于规格说明的测试都属于这一类。等价类划分、边界值分析、因果图，都是行为模式的经典方法。

特点：不关心代码怎么写，只关心功能对不对。测试用例设计围绕需求展开，与实现解耦。

适用场景：需求变更频繁、对外接口稳定、集成测试阶段。有一次我接手的项目代码乱得像蜘蛛网，结构模式根本跑不通——覆盖率工具都报错。我就全切到行为模式，只用接口和预期结果测，反而把核心功能稳住了。

并发模式

并发模式最难，也最容易被忽视。它测的是多线程、多进程、异步任务同时跑时，程序还能不能保持正确。竞态条件、死锁、活锁、共享资源冲突……这些问题单线程永远复现不了。

特点：时序敏感，非确定性，很难稳定复现。需要专门设计并发场景，比如多线程同时读写同一个变量、调整线程调度顺序等。

适用场景：多线程服务、消息队列、数据库并发写入、高并发API。我曾经遇到过一个支付系统，QPS一上200就会出现金额对不上。用单线程测没问题，一上并发就翻车。最后我用并发模式构造了100个线程同时扣款，才把竞态条件揪出来。

异常模式

异常模式，测的是“不正常的情况”。输入非法数据、网络断开、磁盘写满、第三方服务超时、参数为null……这些在正常路径上不会发生，但一旦发生，程序能不能优雅处理？

特点：专门构造不合法、超预期、资源不可用的场景。错误处理、异常抛出、降级逻辑、重试机制都在这个模式里测。

适用场景：全链路测试、容灾演练、安全测试。我记得有次上线前，我特意给一个文件上传服务构造了“磁盘空间不足”的异常场景，结果发现程序直接抛了个500，用户收到的是无意义的错误码。后来加了个友好提示和自动清理机制，才算补上这个坑。

测试模式	核心关注点	典型方法	主要场景
结构模式	代码内部逻辑、路径覆盖	语句覆盖、分支覆盖、MC/DC	单元测试、关键路径验证
行为模式	功能正确性、输入输出关系	等价类、边界值、因果图	接口测试、集成测试
并发模式	多线程/多任务下的正确性	竞态构造、线程调度干预	高并发服务、共享资源
异常模式	错误处理、异常恢复	故障注入、非输入构造	容灾、安全、鲁棒性

这四种模式不是互斥的。一个成熟的测试策略往往是四者的组合。你想想看，结构模式保证“代码写对了”，行为模式保证“功能做到了”，并发模式保证“人多不乱”，异常模式保证“出事不崩”。缺一个，风险就在那。

你可能会问：“四种模式怎么落地？每个测试用例都得标上属于哪类吗？”我的做法是：在测试设计文档里给每个用例打上模式标签。结构模式用例用ST₋xxx命名，行为模式用BH₋xxx，并发用CC₋xxx，异常用EX₋xxx。这样跑完一轮测试，你一眼就能看出哪种模式覆盖率不够。