4. 测试对象分析

测试对象分析不是把被测系统“看一遍”，而是把系统拆成可验证的维度，再从每个维度中提取出“需要学什么、需要测什么、需要准备什么”的学习需求。它的核心产出不是一份系统介绍，而是一张维度—对象—验证点—学习需求的映射关系。只有这张映射清晰，后续的测试设计、环境搭建和用例编写才有依据。

以一个典型的“在线订单服务”作为教学示例对象。假设它对外提供 REST 接口，内部依赖 MySQL 与 Redis，并通过消息队列异步通知库存服务。这个系统虽然不大，但已经覆盖了功能、接口、数据、性能四个维度的主要分析场景。下面按维度展开，说明每个维度应该看什么、提取什么。

功能维度：从业务能力到可验证行为

功能维度关注“系统应该做什么”。分析时不要停留在“订单模块”这种粗粒度名称上，而要拆到功能点—触发条件—预期行为—异常分支。例如“创建订单”至少包含：合法商品与库存充足时创建成功；库存不足时拒绝并返回明确错误；重复提交同一请求时幂等处理；未登录时拒绝访问。每个功能点都要问三个问题：输入是什么、状态如何变化、输出如何判断。

从学习需求角度看，功能维度提取的是：业务规则理解、状态机理解、边界条件识别、异常路径设计。如果系统有订单状态（待支付、已支付、已取消、已完成），就必须把状态迁移图作为学习对象，而不是只记接口名。

接口维度：契约、协议与依赖关系

接口维度关注“系统如何被调用、如何调用别人”。对每个接口，至少要提取：请求方法、路径、请求头、请求体字段及类型、响应码、响应体结构、错误码含义、鉴权方式、超时与重试策略。以创建订单接口为例，示例契约如下：

POST /api/v1/orders
Header: Authorization: Bearer <token>
Body: { "skuId": "SKU-1001", "quantity": 2, "userId": "U-2001" }
成功: 201 { "orderId": "O-9001", "status": "PENDING_PAY" }
失败: 400 参数缺失; 401 未认证; 409 库存不足; 500 服务异常

接口分析还要看依赖方向：订单服务调用库存服务是同步还是异步？超时时间是多少？失败后是否回滚？这些决定了后续接口测试需要 mock 哪些外部依赖、需要构造哪些异常响应。学习需求由此提取为：协议规范、鉴权机制、错误码体系、依赖桩设计、契约测试方法。

数据维度：结构、流转与一致性

数据维度关注“系统读写什么数据、数据如何变化”。需要识别三类数据：持久化数据（MySQL 表结构、字段约束、索引）、缓存数据（Redis key 设计、过期策略）、传输数据（接口报文、消息体）。以订单表为例，关键字段包括 order_id、user_id、sku_id、quantity、status、created_at。分析时要明确：哪些字段有唯一约束、哪些字段允许为空、状态字段的合法取值集合是什么。

数据维度的学习需求通常包括：表结构与约束理解、测试数据构造、数据清理与隔离、缓存与数据库一致性验证。例如，创建订单后 Redis 中是否写入了对应缓存？取消订单后缓存是否失效？这些都需要设计专门的数据验证点。

性能维度：指标、场景与瓶颈假设

性能维度关注“系统在什么负载下表现如何”。分析时先确定关键业务场景（如下单、查询订单），再为每个场景定义指标：响应时间 P95、吞吐量 TPS、错误率、资源占用（CPU、内存、连接数）。示例目标可以设为：下单接口在 100 并发下 P95 小于 500ms，错误率低于 0.1%。

性能分析还要形成瓶颈假设：数据库连接池是否足够？Redis 命中率是否会影响响应？消息队列积压是否导致异步通知延迟？这些假设决定了压测时需要重点观察的监控项。学习需求由此提取为：负载模型设计、指标采集、瓶颈定位、容量评估。

从分析到学习需求提取

完成上述维度分析后，把结果整理成一张可执行的学习需求表。每一行对应一个“维度—对象—验证点—学习需求”，例如：功能维度—创建订单—库存不足返回 409—需要学习业务规则与异常分支设计；接口维度—创建订单接口—鉴权失败返回 401—需要学习 token 机制与接口测试工具；数据维度—订单表—status 合法取值—需要学习约束验证与数据构造；性能维度—下单场景—100 并发 P95—需要学习压测脚本与监控指标解读。

这张表的价值在于：它把“测试对象分析”从描述性工作变成了可追踪的学习任务清单。后续每学一项，都能对应到具体验证点；每设计一个用例，都能回溯到某个维度的分析结论。分析是否充分，判断标准也很直接：能否仅凭这张表写出第一轮冒烟用例，并说清每个用例验证的是哪个维度的哪个点。

回到分析本身，最容易犯的错误是“只列对象、不提取需求”。比如看到订单表就写“订单表”，看到接口就写“订单接口”，这没有完成学习需求提取。正确的做法是：每识别一个对象，就追问它对应哪个验证点、验证点又要求掌握什么知识或工具。功能对象追问业务规则与异常分支，接口对象追问契约与依赖桩，数据对象追问约束与一致性，性能对象追问负载模型与瓶颈定位。这样得到的分析结果才是可执行的。

最后需要强调，测试对象分析是持续迭代的。第一轮分析可以只覆盖主流程和核心接口，随着测试深入，再补充边界条件、异常依赖和性能瓶颈假设。每次迭代都应更新映射表，并把新增的学习需求纳入后续学习计划。分析的质量不取决于覆盖了多少对象，而取决于每个对象是否都落到了可验证、可学习、可追踪的点上。