我有个挺扎心的项目经验一个软件测试工程师被塞了个需求要写代码自动生成离婚协议里的房产分割条款核心算法用的是递归函数。乍一听像段子但真做起来我发现这项目正好把“递归”和“软件测试”这两个词焊死在了一起没有测试递归能把你的调用栈炸穿没有递归这类组合分割问题又很难干净地给出方案。这篇就来聊聊我是怎么从测试视角把这个“离谱需求”拆成可落地、可验证、可维护的小工具的。这类需求最大的价值不是“离婚协议”这个业务名而是它背后典型的组合优化问题一堆房产每套不能拆分要分给两边尽量让总估值接近某个目标比例。你可能会说这种需求直接用贪心算法排个序不就完了还真不行后面我会用一个反例说明为什么非得上递归。文章适合正在学递归算法、或者想看看测试思维怎么反哺代码设计的同学不需要有法律背景我也不会给任何法律建议只聊代码和测试。1. 需求拆解当“离婚协议”变成一个技术需求1.1 别被业务场景吓到先画输入输出任何需求到了测试手里第一步都不是写代码而是把“人话”翻译成“输入输出”。这个项目翻译过来其实很朴素输入是一份房产清单每条房产有名号、估值、产权编号输出是一份分配方案注明甲方名下分哪几套、乙方名下分哪几套附带总估值和差额说明最后再渲染成协议文本草稿。难点在哪里在于“房产不可拆分”这个硬约束。它意味着你不能说“这套房子估值300万双方各拿150万”只能整套餐从A给到B或者从B给到A。这就像分一块不能切的披萨你只能在“给你”和“给我”之间反复做抉择。而“抉择”恰好是递归最擅长表达的每一步面对一套房产考虑“给甲方”还是“给乙方”走完所有房产后比较哪种分法更接近目标比例。输出也不是只有一个数字那么简单必须能从算法结果反推决策过程。比如最后方案里甲方拿到A套房、C套房估值合计580万乙方拿到B、D、E三套估值合计620万总价差40万这个40万要在协议里写清楚。没有这种可解释性算法算得再准也没法交付。所以我在需求文档里写了四条硬性要求房产不可拆分每条记录必须整体归属于一方。分配比例可配置默认五五开也要支持比如甲方60%、乙方40%的非对称场景。算法结果必须可解释、可复现同一份输入不能每次跑出不同结果。输出不是一堆数组而是要能直接填充到协议模板里的结构化数据。这样做的好处是测试用例的设计边界一下子就清晰了。后面不管是写递归还是调试都不会跑偏。1.2 为什么是递归而不是普通循环很多人第一反应是“排序后轮流分”或者“从大到小贪心分”。这两种方案确实简单但都有致命伤。轮流分太机械完全无视估值差异可能出现一边拿到三套小户型、另一边拿到一套大平层总价天差地别的结果。贪心从大到小分倒是把大额资产优先错开了但贪心是“短视”的它只看当前这一步不回头调整很容易陷入局部最优。我给一个简短的反例三套房产估值分别是85万、45万、40万目标比例是50%。如果按从大到小贪心分配第一套85万先给甲方剩下45万和40万无论怎么给乙方乙方最多85万两边勉强算均衡这个例子碰巧能过。但换一组60万、51万、49万贪心先把60万给甲方剩下51万和49万都塞给乙方乙方直接拿到100万甲方只有60万失衡非常明显。而递归回溯会尝试“60万给甲方”和“60万给乙方”两条分支最终发现“51万49万给甲方、60万给乙方”的方案也就是甲方100万、乙方60万和贪心结果正好相反。没有递归想这种组合场景就只能手写大量循环嵌套、维护一堆状态变量代码复杂度会比递归高得多。递归的价值在于它天然呈现了一棵决策树每套房产就是一个决策节点“给A”和“给B”就是两个分支。测试视角下这种结构特别好定位问题出偏差时只要沿着分支一路排查就能找到是哪套房产的归属判断错了。2. 递归函数设计合约、终止条件和剪枝2.1 接口定义先于实现先把函数签名定下来不少新手一上来就写递归体写着写着就忘了函数该返回什么。我的习惯是先用类型把契约钉死递归里每一步是“不带返回值地维护全局最优”还是“带着返回值逐层上报”必须在动手前想清楚。这个项目里我选择的是“深度搜索维护全局最优”模式核心接口长这样def split_properties(properties, target_ratio0.5, tolerance0.05): 将不可拆分的房产按目标比例分配给两方。 :param properties: list[dict]每项含 name、value 字段 :param target_ratio: float甲方期望分配比例默认0.5 :param tolerance: float允许的总价差占比用于结果判定 :return: dict包含 side_a、side_b、gap、total、selected等 内部递归函数我用了一个很克制的签名def dfs(idx, cur_sum, selected): idx: 当前处理到第几套; cur_sum: 甲方当前累计估值; selected: 甲方选中的房产下标为什么不用“返回值”而是“维护全局变量”因为这个问题要的是一整条路径不是简单的布尔值或数字。如果你让递归一层层把“选中的房产列表”返回上来列表在每一层都要复制一次空间开销会很难看。用全局最优 当前路径的方式到叶子节点时只做一次判断和替换效率高得多。测试时我也会针对契约单独写断言返回值必须包含 side_a 和 side_b 两个列表必须包含 gap 字段且 gap 非负必须包含 total 且 total 等于入参估值总和。先把契约测住后面怎么改内部实现都不怕。2.2 终止条件与边界设计这是递归最容易翻车的地方递归函数有三件事必须在一开始就写清楚终止条件、循环体内的分支逻辑、以及“回头路”。终止条件错了轻则结果不对重则直接栈溢出。这个项目里的终止条件是idx len(props)也就是所有房产都过了一遍。每次走到这里我把甲方当前累计估值和 target 比较差值更小就更新最优解。但这里有个容易被忽略的点递归分支里“选当前房产给甲方”和“不选当前房产给甲方”都要覆盖到。漏一条分支结果就会偏。边界情况我列了一串测试清单空列表没有任何房产可分函数不能崩溃应该返回空方案。单套房产整栋归属一方gap 就是这套房产的总估值。两套价值完全相同的房产两边各拿一套gap 为0。多套价值相同的房产递归会面对大量重复组合必须靠排序和剪枝规避无意义搜索。估值带小数比如 135.6万这种浮点运算的误差会影响 gap 判定后面单独说。超大批量房产比如1000套默认递归深度只有1000不处理会爆栈。Python 里我补了一句sys.setrecursionlimit(max(10000, len(properties) * 4))但这只是兜底手段更好的做法是让递归深度受控。如果房产数量真到了几千套可以考虑把递归改成显式栈的迭代式遍历这是后话。至少对常规家庭资产规模来说几十套已经是极限了递归完全够用。2.3 剪枝与排序别让递归变成“全枚举”递归唯一的缺点就是慢因为它在指数级地铺开搜索空间。我实测过如果完全不剪枝30套房产就是2的30次方也就是约10亿个分支这已经超出“能等”的范围。所以“排序 剪枝”是递归能不能实际用的关键。我的做法是先把房产按估值降序排序。为什么要降序因为先处理大额资产能更快逼近 target剪枝条件更容易触发。排序之后在递归函数入口处加一个剪枝判断# 甲方累计估值已经超过目标并且差值大于当前最优差值时 # 再继续选房只会让差距更大没必要往下走了 if cur_sum target and cur_sum - target best[diff]: return注意这个剪枝成立的前提是“房产估值都非负”。如果哪天业务里允许负资产基本不可能这个剪枝会剪错。我给这条写了一行注释防止后人踩坑。还有一个小优化提前计算剩余房产的总估值用于判断“就算把剩下所有房子都选给甲方依然追不上当前最优解”的情况可以直接剪掉。不过这会引入额外的前缀和数组代码可读性稍微下降我在这版里没有加只保留了最安全的剪枝。剪枝策略是测试重点我会专门构造几个“逼疯老式递归”的用例比如10套房价值从1万到1000万不等验证它能在几毫秒内返回再加一组100套验证它不会把机器跑死。递归的优雅一定要建立在可控的复杂度上否则就是纸上谈兵。3. 软件测试视角从用例设计到缺陷定位3.1 测试分层先测什么、后测什么算法类项目最忌讳“一把梭”上来就调用完整函数看最终输出对不对。那样一旦出错你根本不知道是排序的问题、是递归逻辑的问题、还是模板渲染的问题。我把测试分成了三层第一层是纯函数正确性测试直接给定一个小型房产列表断言返回结果里的 side_a、side_b 是否满足“两边不相交”“并集覆盖全部房产”“总价差符合预期”。这层测的是核心逻辑。第二层是算法对比测试我会写一个暴力全排列解法在小数据量下和递归解法做对拍。比如6套房、8套房暴力枚举所有2的N次方组合绝对最优解是确定的然后断言递归解法的 gap 和暴力解一致。这一步能抓住绝大多数“剪枝剪过头”的问题。第三层是集成测试把递归结果丢给协议模板渲染检查最终文本里是否包含每套房产的名称、估值、归属方是否把甲乙双方的名字搞反是否在多套房产时正确生成顿号分隔。这三层测试的逻辑是先证明算法方向正确再证明性能可接受最后证明业务输出无误。任何一层挂了都能精确地定位到对应模块而不是对着几千字协议文本找Bug。3.2 等价类、边界值与判定口径在设计用例时我把房产估值分成了几个等价类小额资产、大额资产、相等值资产、带小数的估值、零估值。零估值是个很容易踩的边界很多人会觉得“价值0的房子有什么好分的”但业务上完全可能有一间估值接近0的车位它的存在会影响组合数量所以必须测。判定口径也很关键。你不能笼统地说“结果要尽量公平”因为测试没法断言“尽量”两个字。我定义了两个硬指标gap绝对差值 甲方总估值减乙方总估值取绝对值这个值要越小越好。gap_ratio gap / total必须小于等于调用方传入的 tolerance默认0.05。这两个指标都不难算但你必须在测试里明确断言。我见过好多项目把“差不多”挂在嘴边结果上线后产品经理和研发吵翻天就是因为“差不多”没有量化。下面是我整理的典型测试用例表测试场景输入样例测试重点预期结果空列表[]异常保护返回空分配方案不抛错单套房产[{name: A, value: 500}]唯一归属一方500万另一方0万gap500两套同值[{A:300}, {B:300}]精确分割各300万gap0三套经典反例[60, 51, 49]贪心失效递归必须找到最优组合带小数估值[100.5, 99.5, 50.25]浮点精度gap 计算稳定无误差大量房产100套随机估值性能与深度秒级返回不爆栈非对称比例target_ratio0.6参数化配置甲方约60%能容忍合理偏差3.3 三个典型缺陷的定位与修复这个项目虽然不大调试过程中踩的坑却一个比一个经典挑三个说说。第一个坑是可变对象默认参数。我早期的递归函数里写了def dfs(idx, cur_sum, selected[])看着省事结果不同分支之间 shared 了同一个列表跑出来的方案里甲方和乙方都“拥有”同一套房产数据直接乱了。排查时我先打印了 selected 的内存地址发现两条完全不同的递归分支拿到的是同一个对象马上意识到是默认参数的问题。修复方式很简单不在默认参数里放可变对象而是在函数内部初始化递归中通过“先 append 再递归、递归结束后 pop”来维持同一路径的状态。这也是递归回溯最常见的写法。第二个坑是浮点比较。估值里出现了0.1 0.2 ≠ 0.3这种老问题导致 gap 明明相同的两套方案被误判成好坏不一。我排查的方式是打日志看到精确值0.30000000000000004然后决定不直接拿原始浮点数做差而是统一以“万元”为单位、放大成整数处理或者在比较时用round()到小数点后两位。后来我干脆把估值换算成以“元”为单位的整数彻底绕开浮点误差。第三个坑是排序污染了入参。我在函数内部做了props sorted(properties, keylambda x: x[value], reverseTrue)以为这样就安全了但列表里的字典还是原来的对象有的分支会直接改里面的字段导致回归测试第二次跑的时候输入已经被改了。排查时我发现同一套用例第一次跑出 gap20第二次跑出 gap18完全说不通。修复方法是排序时对每一条字典也做一次浅拷贝或者强制不做任何原地修改只读不写。这个教训让我后面写任何递归函数都养成了“谁污染谁修复”的习惯。4. 协议文本生成当递归结果要翻译成人话4.1 中文模板与数据格式化算法结果是一堆下标和数字但用户要的是一段能读的协议草稿。中文文本拼接是个特别细碎的活我一开始用 Python 的字符串 format 手搓结果动不动多个顿号、少个换行测试用例一多直接崩溃。后来改用模板字符串把协议结构固定下来def render_agreement(split_result, party_a_name, party_b_name): side_a_props split_result[side_a] side_b_props split_result[side_b] total_value split_result[total] gap_value split_result[gap] lines [] lines.append(f甲方{party_a_name}) lines.append(分得以下房产) for idx, prop in enumerate(side_a_props, 1): lines.append(f{idx}. {prop[name]}估值{prop[value]:.2f}万元) if not side_a_props: lines.append(本协议项下无房产分配。) lines.append(f甲方分得房产合计估值{sum(p[value] for p in side_a_props):.2f}万元) lines.append() lines.append(f乙方{party_b_name}) lines.append(分得以下房产) for idx, prop in enumerate(side_b_props, 1): lines.append(f{idx}. {prop[name]}估值{prop[value]:.2f}万元) if not side_b_props: lines.append(本协议项下无房产分配。) lines.append(f乙方分得房产合计估值{sum(p[value] for p in side_b_props):.2f}万元) lines.append() lines.append(f双方房产总估值{total_value:.2f}万元分配差额{gap_value:.2f}万元。) return \n.join(lines)模板化之后测试点就清晰多了。我需要针对模板本身写测试空列表时有没有输出“本协议项下无房产分配”、列表不为空时序号是不是从1开始、估值有没有统一保留两位小数、甲乙双方的合计值是否和算法结果完全一致。4.2 格式化过程中最容易出错的细节第一处是单位不统一。算法内部我改成了整数“元”但渲染到协议里用户习惯看“万元”。如果模板里忘记格式化就会输出一个巨大数字比如3500000.00万元这种错误在纯代码测试里发现不了只有做文本快照测试才暴露。第二处是名字与归属的顺序。甲方和乙方在算法里只是一个抽象概念但渲染时必须保证输出顺序稳定。我踩过的坑是列表被排序后甲方可能分到的是“第1、3、5套”乙方分到“第2、4、6套”模板里如果只遍历 sorted 之后的 props 而不是用 split_result 中存好的 props生成顺序就会和算法结果对不上。所以我把算法结果的“选中集合”直接在渲染时映射回原始房产清单不做二次排序。第三处是全角标点问题。中文协议里数字和百分号前后经常需要全角逗号、顿号我一开始用半角逗号被测试用例直接打回。后来在渲染函数里统一用中文标点并在测试里专门搜一下半角字符防止手滑。第四处是合计值校验。模板里出现了合计估值这个数字不能光靠计算最好在集成测试里断言“甲方合计 乙方合计 总估值”一旦不相等说明渲染的数据和算法结果对不上协议文本拿到手就是废纸。5. 回归测试与持续保障让这个“偏门项目”也能长期维护5.1 固定样本与快照测试这类偏门项目最容易犯的毛病是“跑完一次就丢没有用例沉淀”。我给自己的硬性要求是每一类典型输入都要固化成 JSON 样本文件放到 tests/fixtures 目录里每次改动递归或模板只要跑一遍 pytest就能看到有没有回归。快照测试也是个好东西。简单说就是把第一次生成的协议文本存成 golden file后续跑测试时做全文对比。协议这类输出文本结构非常稳定快照测试的价值特别大任何格式上的微小变化都能即时暴露。我特意造了一批“奇怪”的 fixture单套房产、0套房产、12套估值相同的房产、估值相差巨大的房产把渲染结果全部冻成快照改代码之前看一眼 diff心里就有底了。5.2 参数化测试与统计指标使用 pytest 的parametrize可以非常优雅地覆盖多种目标比例。我把 target_ratio 参数化成 0.5、0.6、0.4、0.55每次都断言gap_ratio小于等于 tolerance。这种参数化测试的另一个好处是它不是只断言“通过不通过”而是能把每次的 gap 和 gap_ratio 打印出来形成一组统计指标。我后来发现单次用例通过不代表整体稳定有些极端输入下 gap 会偏高如果只测一组正常用例很容易漏掉。我还做了一个更狠的测试随机生成200组房产数据每组5到20套房估值范围从5万到800万不等然后批量跑算法最后统计所有 gap_ratio 的分布。如果某个区间的 gap_ratio 明显偏高说明递归的剪枝可能筛掉了潜在最优分支。这种“模糊测试”思路用到算法项目上比我手写的十个固定用例能发现的问题多得多。5.3 写给自己和后来者的几条经验这个项目让我把递归和测试的关系想明白了很多。递归看起来像是算法的事但它真正能稳定上线全靠测试把边界、终止条件、浮点精度、文本格式一层层焊死。我一开始把递归写得跟教科书一样工整但真正让它变成可交付工具的是那些反例用例和一个一个踩出来的修复乐趣。现在我再写任何递归工具都会先问自己三个问题终止条件是什么输入能不能保证收敛数据量大到爆栈时怎么办这三个问题如果都能用测试用例给出明确回答代码通常就能安心运行。我也习惯在自己的工具项目里永远保留一套“暴力解法对拍测试”虽然正式代码不可能用暴力解但它就是那面照妖镜能照出花里胡哨的剪枝是不是真牺牲了正确性。做软件测试久了你会知道算法最容易骗人的地方恰恰是它看起来太完美的时候。