← 返回简历

私募基金测试体系实践

在零真实数据的金融环境里，用业务建模和参数化重构建立可复用的测试体系

我在九坤投资做高级测试工程师，负责私募基金管理系统。

这个项目的测试有三个死结。

第一，数据零信任。 私募基金名称、历史交易数据全部保密，测试环境拿不到任何真实数据。传统测试直接断粮。

第二，业务黑盒。 开发只知道自己这块代码，不清楚这个功能在上下游怎么流转，需求文档碎片化，甚至开发自己都不明白某个字段在业务链里的意义。

第三，代码债务。 之前的测开团队用 Java 思维硬写 Robot Framework，接口之间毫无依赖复用，后面用到前面的逻辑就重写一遍，脚本越堆越臃肿。

我的判断：这三个问题不能分开解决。没有业务理解，Mock 数据非常生硬；没有好的代码结构，自动化就是债务；没有跨团队沟通，测试永远停在表面。

第一步：主动穿透业务

不满足于这个按钮能点通，我去找业务人员问清楚：这只基金从申报到清算，数据从哪来，经过哪些系统，最终输出什么，业务目的是什么。我把上下游依赖、字段口径、数据流向全部梳理清楚。这是测试设计的前提，也是我以前做业务测开养成的习惯。

第二步：场景化 Mock

我不硬塞一条能跑通的数据，而是先把基金业务拆成申报、募集、交易、清算等场景，每个场景下按字段依赖关系构造数据。申报资料需要什么字段组合，资金往来涉及哪些账户状态，每日盈亏的计算口径怎么定义，全部按业务逻辑来。

更重要的是，我把所有造数场景的 SQL 记录下来，形成团队第一份可复用的数据资料集。后来人接同类需求，不用重新摸索，直接改参数就行。

第三步：重构自动化

之前的脚本像 Java 代码一样机械堆砌，一个接口一套硬编码，参数变化就重写。我引入参数化和 BDD 两种思路。参数化覆盖不同接口的参数组合，用数据驱动快速构造高覆盖场景；BDD 按业务描述写清楚行为，给团队打样。我把自己负责的全部接口按这两种方式重写，参数化为主，BDD 为辅。

第四步：主动沟通

我加了很多以前测开不做的动作：在群里周知业务场景，测试前事先造数，测试中调整数据，验证完页面再验后台。同时主动对接上下游系统负责人，确认字段定义和取值口径。以前传统测开很少干这些，但我带过团队，知道测试如果不懂业务上下文，覆盖面一定非常片面。

结果

测试不再依赖真实数据，Mock 体系支撑了基金全生命周期验证。团队有了参数化脚本和 BDD 样本，后续维护成本降低。更重要的是，测试从页面级功能验证，升级为理解业务后的全链路验证。