1、OA系统概述与测试策略
大家好，我是这次课程的主讲。在测试圈摸爬滚打了十几年，OA系统算是我接触最多的业务系统之一。说实话，很多人觉得OA测试就是点点按钮、看看流程通不通，其实远没那么简单。
今天这一章，我们先聊聊OA系统到底长什么样，自动化测试能帮我们解决什么问题，以及——怎么制定一套靠谱的测试策略。
OA系统的核心模块
OA系统，说白了就是企业内部的办公平台。你想想看，一个公司几百上千号人，审批、考勤、公告、会议……这些事总不能全靠纸质单据和口头传达吧？
我参与过的OA项目，核心模块通常包括这几块：
- 流程审批模块：请假、报销、合同审批。这是最核心的模块，也是测试的重灾区。
- 公文管理模块：收发文、签报、公告。权限和状态流转特别复杂。
- 行政办公模块：会议室预订、车辆管理、物资申领。并发冲突是常见坑。
- 个人办公模块：待办事项、日程、通讯录。看似简单，但集成点多。
- 系统管理模块：用户、角色、菜单、日志。这是所有模块的基础。
重点提醒：流程审批模块的测试，一定要关注「分支条件」和「会签/或签」逻辑。我在项目中遇到过，一个三层的审批流程，因为条件判断写错了，导致所有报销单都直接跳到了CEO那里……
自动化测试的价值与挑战
为什么要做自动化？这个问题我经常被问到。其实答案很直接：
- 回归测试效率：OA系统迭代频繁，每次发版手动跑一遍核心流程，半天就没了。
- 数据准确性验证：审批状态、表单数据、日志记录，这些靠人眼检查容易漏。
- 并发场景覆盖：比如多人同时提交审批、会议室秒杀，手工很难模拟。
- 持续集成支持：代码提交后自动触发测试，快速反馈问题。
但挑战也不少。我个人习惯把挑战分成三类：
| 挑战类型 | 具体表现 | 我的应对思路 |
|---|---|---|
| UI频繁变动 | 按钮位置、表单字段经常调整 | 多用数据驱动，少写死定位器 |
| 流程状态复杂 | 一个审批单可能有十几种状态 | 状态机建模，覆盖核心路径 |
| 环境依赖多 | 依赖LDAP、邮件、短信等外部服务 | 接口Mock + 测试容器 |
避坑指南：我曾经在一个OA项目里，自动化脚本跑了一周都稳定通过，结果上线当天全挂了。原因是什么？测试环境的日期是静态的，而生产环境的日期是动态的——审批超时自动驳回的逻辑，在测试环境根本没触发。嗯，从那以后，我所有时间相关的用例都会做「时间旅行」测试。
测试策略制定
测试策略这东西，听起来很虚，但落地起来其实就几个问题：测什么、怎么测、什么时候测、谁来测。
我一般会从这几个维度来制定OA系统的测试策略：
1. 分层测试模型
别一上来就想着UI自动化。我的经验是：
- 接口层：覆盖流程流转、数据增删改查。占比60%左右。
- UI层：覆盖关键用户操作路径。占比20%左右。
- 集成层：覆盖跨模块、跨系统交互。占比15%左右。
- 探索性测试：人工补漏。占比5%左右。
2. 优先级划分
你想想看，OA系统那么多功能，不可能全自动化。我建议按这个顺序来：
- P0：登录、待办列表、审批通过/驳回。这些挂了，用户直接没法干活。
- P1：表单提交、流程撤回、抄送。影响面大，但还有临时方案。
- P2：历史查询、统计报表、个性化设置。可以容忍短期故障。
3. 数据策略
OA系统的数据依赖特别重。我个人习惯的做法是：
- 用API预置测试数据，别靠UI一步步创建
- 每个用例独立准备数据，用完清理
- 敏感数据脱敏，别把真实员工信息写进脚本
小技巧：我在项目中常用「数据工厂」模式。写一个工具类，传入参数就能生成一个完整的审批单、一个用户、一个部门。这样用例写起来特别清爽，维护成本也低。
4. 持续集成策略
自动化测试不接入CI，价值直接打五折。我建议这样安排：
- 提交阶段：跑接口层的冒烟用例，5分钟内出结果
- 每日构建：跑全量接口用例 + 核心UI用例，30分钟内出结果
- 发版前：跑全量回归，包括集成测试，2小时内出结果
嗯，这里要注意一点：CI流水线里一定要加「失败重试」机制。OA系统的测试经常因为环境抖动挂掉，重试一次能过滤掉大部分假阳性。
5. 风险应对
最后说说风险。我见过太多团队，自动化测试做了一半就放弃了。原因无非是：
- UI改版太频繁，脚本维护成本高
- 测试数据不稳定，跑一次挂一次
- 团队没有自动化经验，遇到问题卡住
我的建议是：从小处着手，先搞定一个核心流程，跑通了再扩展。别想着一步到位，那只会让你陷入「自动化陷阱」。
总结一下：OA系统的自动化测试，核心在于流程的稳定性和数据的可控性。策略上，接口优先、UI辅助、数据独立、CI集成。记住，自动化不是目的，而是手段。我们的目标是——让测试更高效，让发版更安心。
下一章，我们会具体聊聊环境搭建和第一个自动化用例怎么写。到时候我会分享一些我踩过的坑，保证让你少走弯路。