在 iOS 生态逐渐向 Swift 靠拢的同时，Objective-C（OC）依旧是大量成熟大型 App 的主力语言 。
尤其在企业级项目、历史项目、框架库、原生组件中，OC 的稳定性与可控性仍旧不可替代。
因此，构建一套 适用于 OC 项目、覆盖功能、性能、系统日志与跨端场景的测试体系，对许多团队来说依然非常重要。
本文将从工程实战角度出发，围绕 OC 测试的常见场景，结合 XCTest、OCMock、Instruments、克魔（KeyMob）、PerfDog、Charles、Safari Inspector、MetricKit、Xcode 调试工具 等多工具构成一套可落地的测试体系。
文章风格保持工程化、不含广告化语气、不依赖网络搜索，基于开发者实际工作场景编写。
一、为什么 OC 项目需要更完善的测试体系？
OC 项目通常具有以下特点：
1. 历史代码多，缺乏单测
许多业务逻辑仍依赖面向对象、运行时特性，测试难度比 Swift 更高。
2. 容易出现运行时错误
如：
- unrecognized selector
- KVC/KVO 崩溃
- NSException
3. 复杂的 UI 逻辑
OC 项目多数 UI 架构较老，性能问题更容易在 UI 层暴露。
4. 与 Hybrid、C++、底层框架兼容
意味着测试不仅包括 OC 逻辑，还包含底层组件行为。
5. 老项目更需要性能和稳定性保证
因此，OC 测试必须覆盖功能 + 性能 + 系统日志 + 文件数据 + 跨端行为多个维度。
二、XCTest：OC 单元测试的核心基础
XCTest 是苹果官方单元测试框架，对 OC 项目非常成熟。
1. 单元测试（Unit Test）
用于验证 OC 模块内部逻辑，例如：
- (void)testCalculateTotalPrice {
OrderManager *m = [OrderManager new];
XCTAssertEqual([m totalPrice], 0);
}适合测试：
- Model
- 工具类
- 业务计算逻辑
- 数据解析
2. UI 测试（XCUITest）
用于流程自动化，例如：
- 启动 App
- 自动点击按钮
- 输入内容
- 验证 UI 状态
这对 OC 项目的回归测试非常重要。
三、OCMock：Objective-C 测试中的"Mock 利器"
OCMock 是很多 OC 工程师仍在使用的 Mock 框架，可用于：
1. Mock 对象方法
模拟接口返回、逻辑分支：
OCMockObject *mock = OCMClassMock([UserService class]);
OCMStub([mock fetchUser]).andReturn(mockUser);2. Mock Delegate / Block 回调
3. 验证方法是否被调用
OCMVerify([mock trackEvent:@"open"]);在业务依赖较深、运行时行为较复杂的 OC 项目中，OCMock 对提升测试覆盖率非常关键。
四、Instruments：OC 性能测试的"显微镜"
无论 OC 还是 Swift，底层性能测试统一依赖 Instruments。
在 OC 项目中尤其需要关注：
1. Time Profiler
用来查：
- 主线程阻塞（OC 中更常见）
- 无意的同步调用
- 高耗时方法
2. Leaks / Allocations
OC 的内存管理更复杂，容易出现：
- 循环引用（block/self）
- 未释放对象
- 自动释放池滥用
3. Core Animation
OC 项目往往 UI 结构更重，更容易出现渲染问题：
- 重绘过多
- 离屏渲染
- 布局过于复杂
Instruments 是 OC 性能调试的核心工具。
五、克魔（KeyMob）：系统日志 + 性能监控 + 文件调试（OC 项目的非常高适配度）
OC 项目因历史原因或系统层依赖更容易产生：
- KVO 异常
- 内存压力导致 jetsam
- UI 卡顿导致 watchdog
- NSException 崩溃
- WebKit/WebView 崩溃
- Sandbox 文件解析需求
KeyMob 能补足 Xcode 的能力，包括：
1. 实时性能监控
可监控：
- CPU
- GPU
- 内存
- FPS
- 网络
- 温度、能耗
非常适合验证 OC 项目常见的性能回归问题。
2. 系统日志（Device Logs）捕获
OC 项目最容易出现的系统错误包括：
EXC_BAD_ACCESS
jetSam (Memory highwater)
KVO crash
watchdog (main thread hang)Xcode 很难完整捕获，但 KeyMob 可以完整展示。
3. App 文件与数据管理
用于查看：
- plist 配置
- 缓存文件
- OC 底层序列化文件
- 用户数据目录
- 崩溃日志
对调试 OC 项目中的 Sandbox 逻辑非常有效。
六、PerfDog：OC 视图结构下的 FPS/CPU/GPU 关键诊断
OC 项目往往使用更传统、更复杂的视图结构，例如：
- UITableView + 大量 cell
- 手写 UI 布局
- 大量 CALayer
- 混合 CoreAnimation 与 UIKit
- 异步绘制不足
PerfDog 能精准分析：
- FPS 掉帧点
- 多次交互后的性能退化
- CPU 峰值与 UI 更新关系
- GPU 渲染压力
尤其适用于 OC 项目中常见的"越滑越卡""页面切换卡顿"。
七、Safari Inspector：Hybrid、H5、OC 容器混合场景测试
许多历史 OC 项目使用：
- UIWebView（老项目）
- WKWebView（新项目）
- Hybrid（OC + JSBridge）
- uni-app 容器
Safari Inspector 可以：
- 查看 JS 性能
- 分析 DOM 结构
- 验证 JSBridge 延迟
- 找出 Hybrid 阻塞 UI 的行为
OC 项目中经常出现 WebView 卡顿问题，Safari Inspector 是必选项。
八、Charles / Proxyman：OC 网络层测试工具
OC 时代许多项目仍使用：
- AFNetworking
- NSURLSession + 手写网络层
Charles 用于测试：
- 网络异常
- 重定向
- Cache-Control 是否正确
- 弱网行为
- 接口链路延迟
是 OC 应用网络层回归测试的标配工具。
九、MetricKit + Firebase：OC 线上性能监控体系
OC 项目一般运行在用户量庞大的应用中，线上监控尤为重要。
MetricKit 可收集：
- CPU 时间
- 内存峰值
- 热力状态
- 崩溃类型
- 启动性能
- 每日性能趋势
Firebase 可收集：
- 页面渲染时间
- 启动性能
- 网络耗时
- ANR 事件
两者结合可构成 OC 应用的线上稳定性监控体系。
十、构建 Objective-C 测试的完整工程化工具链
| 测试类型 | 工具组合 | 用途 |
|---|---|---|
| 单元测试 | XCTest + OCMock | 测试 OC 方法逻辑 |
| UI 自动化 | XCUITest | 完整流程测试 |
| 性能测试 | Instruments + PerfDog + KeyMob | CPU/GPU/FPS/内存分析 |
| 网络测试 | Charles | 请求调试 & 弱网 |
| WebView/Hybrid | Safari Inspector | JS/DOM 性能 |
| 系统级行为 | KeyMob + Console.app | jetsam/watchdog/KVO |
| 上线监控 | MetricKit + Firebase | 用户真实性能趋势 |
这套工具链适合绝大多数 OC 项目。
十一、实战案例：OC 首页卡顿的定位过程
某 OC 老项目首页滑动卡顿明显。
PerfDog
FPS 在快速滑动时下降到 30--40。
KeyMob
CPU 峰值突然升高至 90%。
Instruments（Time Profiler）
发现某 cell 的图片解码与富文本渲染在主线程执行。
Safari Inspector（该项目含 Hybrid）
Hybrid 部分存在 DOM 节点过多问题。
优化方案：
- 使用异步图片解码
- 重绘逻辑移到后台线程
- Hybrid 列表启用虚拟渲染
最终 FPS 稳定在 58--60。
OC 测试的关键在于"多工具协同"
OC 项目测试不是"写几行单测"，而是构建一套体系：
逻辑测试
UI 测试
性能测试
系统日志
网络链路
Hybrid 性能
线上数据验证
而实现这一点，必须依赖：
- XCTest + OCMock（功能）
- Instruments（CPU/GPU/内存）
- KeyMob（系统日志 + 实时性能）
- PerfDog（FPS 精准采样）
- Safari Inspector（Hybrid）
- Charles（网络）
- MetricKit + Firebase（线上表现）
只有当这些工具协同工作，OC 应用的质量才能稳步提升。