尽管 Swift 已成为主流，但许多核心业务、底层框架与大型存量项目仍然以 Objective-C（OC） 作为开发主语言。
而 OC 的动态性（Runtime）、消息派发机制、内存模型（ARC）、KVO/KVC 特性也使其在测试环节拥有更高要求：
功能正确性要更严格、内存管理要更精确、性能测试必须更全面、系统行为更需关注。
因此，真正的 OC 测试体系从来不是“写几个单测”或“点点 UI 流程”，而是一个由 功能测试 + 性能测试 + 内存分析 + 系统日志验证 + 多工具协同调试 组成的完整链路。
本文结合 XCTest、OCMock、Instruments、克魔（KeyMob）、PerfDog、Xcode 调试器、Charles、Safari Inspector、Crashlytics、MetricKit 构建一套现代化的 Objective-C 测试体系。
一、为什么 OC 测试比想象中更复杂？
OC 的动态特性决定了它的测试重点与 Swift 不太一样：
1. Runtime 行为强依赖测试覆盖
- method swizzling
- 动态转发
- 消息派发优化
- 类簇设计（Class Cluster）
2. 内存模型可预测性弱于 Swift
- block 循环引用
- weak / strong 跨线程访问
- KVO 未移除导致崩溃
- delegate 未释放导致内存增长
3. OC 更依赖多线程测试
- GCD
- NSOperationQueue
- RunLoop 行为
- Timer 生命周期
4. UI 使用纯代码，布局问题更易隐藏
因此 OC 测试必须覆盖：
- 功能
- 性能
- 内存
- 系统行为
- 异常恢复
- WebView / 网络链路
- 上线诊断
这也是多工具协同的必要性。
二、OC 功能测试的基础：XCTest + OCMock
1. XCTest（单元测试与集成测试）
适用于：
- Model 层逻辑
- 工具类
- 算法
- 数据处理
- 网络请求内部逻辑
OC 单元测试建议重点放在纯逻辑部分，而非 UI 部分。
2. OCMock（对象替身）
可用于模拟：
- 网络层
- 数据返回
- 外部依赖行为
- Delegate 回调
在 OC 中，由于协议回调广泛使用，OCMock 能大幅提升测试效率。
三、Xcode 调试工具：OC 代码执行行为的第一观察层
1. LLDB（断点调试）
常用于：
- 调试消息派发顺序
- 检查对象释放情况
- 验证 ARC 行为
2. Memory Graph Debugger（内存图）
可以看到：
- 循环引用
- 控制器未释放
- Block 锁定对象
对 OC 来说非常重要，因为 ARC 不会自动解决循环引用问题。
四、Instruments：OC 性能测试的核心武器
OC 代码因消息派发、动态绑定等机制使其在性能分析中需要更精确的工具，而 Instruments 是第一选择。
1. Time Profiler（CPU 分析）
适用于：
- 查找频繁调用的方法
- 定位耗时循环
- 分析主线程阻塞
在大量 OC 代码的工程中，Method Dispatch 是常见性能瓶颈。
2. Allocations / Leaks（内存分析）
可检测：
- NSDictionary/NSArray 的大规模创建
- Runtime 动态对象产生的临时对象
- 控制器未释放
OC 使用者最担心的问题就是：退出页面内存不下降。
3. Zombies（对象访问错误）
用于定位：
- 访问已释放对象
- KVO 未移除导致的异常
这些错误在 OC 中非常常见且隐蔽。
五、克魔（KeyMob）：真机行为验证 + 系统日志是 OC 测试的关键补充
OC 项目的稳定性很大程度上取决于系统行为与真机表现。
KeyMob 可以补齐 Instruments 的短板：
1. 真机性能监控（CPU / GPU / 内存 / FPS）
适合 OC 常见场景：
- 列表滚动卡顿
- 动画掉帧
- 页面多次进入退出
- 长时间运行导致内存上涨
2. 系统日志是 OC 测试中极其重要的部分
OC 常见错误会在系统日志中体现，例如：
KVO crash
object deallocated while key value observers still registered
EXC_BAD_ACCESS
malloc_error
jetsam (内存压力)
watchdog (主线程卡死)
这些信息 Xcode 无法完整呈现，而 KeyMob 能抓全量。
六、PerfDog：OC UI 层性能的高精度测试工具
OC 多用于成熟项目，其中 UI 常非常复杂，PerfDog 在以下方面表现突出：
- FPS 曲线
- GPU 压力
- 列表滚动性能
- 动画执行性能
- 长时间运行的内存趋势
OC 工程中常见“写得很巧妙”的 UI 动画，其实性能消耗很大，PerfDog 能清楚暴露这些问题。
七、Charles：OC 网络行为测试的必要工具
OC 项目网络层多数基于：
- AFNetworking
- NSURLSession
Charles 可用于检测：
- 弱网下的性能表现
- 队列并发导致的性能压力
- 数据包过大导致 CPU/内存上升
- 多次重试导致资源占用
许多 OC 项目的性能问题源于“网络层处理不当”。
八、Safari Inspector：OC + WebView 项目必测环节
大量 OC 项目仍然嵌入 Hybrid，例如：
- UIWebView（历史项目遗留）
- WKWebView
- 业务活动页
- uni-app 页面
Safari Inspector 能检测：
- JS 执行是否阻塞主线程
- DOM 是否过大
- 资源加载是否合理
- JSBridge 是否过度调用
OC 与 Hybrid 常见的问题常常是“二者交互效率低”，此工具必不可少。
九、MetricKit：OC 项目上线后的性能诊断核心
MetricKit 可提供：
- OOM（内存压力杀）
- CPU 峰值
- I/O 耗时
- 启动时间
- WebKit 崩溃
- 主线程卡顿（hang diagnostics）
OC 项目的复杂程度通常较高，因此版本趋势尤为重要。
十、Crashlytics：OC 运行行为异常的重要补充
Crashlytics 负责捕获“线上真实用户场景”中的异常行为，包括：
- EXC_BAD_ACCESS
- KVO 崩溃
- 数组越界
- 多线程访问错误
- 死锁/卡住
- 被系统杀死前后的线程状态
OC 的动态性决定了 Crashlytics 数据比 Swift 项目更有价值。
十一、构建完整的 OC 测试工具矩阵
| 测试维度 | 工具组合 | 适用场景 |
|---|---|---|
| 功能测试 | XCTest + OCMock | 业务逻辑 |
| CPU 性能 | Instruments + KeyMob | 热点、阻塞 |
| UI 性能 | PerfDog + Core Animation | 掉帧、动画 |
| 内存问题 | Leaks + KeyMob + Zombies | 泄漏、释放错误 |
| Hybrid 性能 | Safari Inspector | JS/DOM/资源 |
| 网络性能 | Charles + KeyMob | 弱网、超时 |
| 稳定性 | MetricKit + Crashlytics | 线上趋势 |
这是可落地、工程化的 OC 测试体系。
OC 测试不是“老项目维护”，而是工程能力的体现
优秀的 Objective-C 测试体系必须具备：
可观测 → 可定位 → 可量化 → 可复现 → 可回归 → 可监控
而要做到这一点，需要以下工具链协同：
- XCTest、OCMock（逻辑测试）
- Instruments（深度 CPU/内存分析）
- KeyMob（真机性能 + 系统日志）
- PerfDog（UI 流畅度与长时间测试）
- Safari Inspector（WebView 测试）
- Charles（网络测试）
- MetricKit / Crashlytics（上线表现）
这就是完整的 OC 测试体系。
