文 / STEM Career 编辑部
调试面试给你一段陌生代码时，马上改几行看结果，可能会修正一个样例，却留下另一个问题。更有效的顺序是确认契约、稳定复现、缩小原因、做必要修复，再用能发现旧错误的检查验证。
本文提供一套原创Python订单净额练习，包含故障版本、参考实现和测试。它不是真实招聘原题，也不代表加拿大软件岗位都会采用这一形式；具体考核与工具规则以职位说明和面试邀请为准。
下载练习包 先不看参考答案
下载订单净额调试练习包，使用Python 3.10或更高版本，无需第三方依赖。先读README与buggy.py，自行写出预期，再运行检查；fixed.py留到解释完问题以后再对照。
故障版本测试失败属于练习设计，不能把失败当成安装错误后直接跳过。参考实现已按包内八项测试检查，覆盖正常、退款、重复、状态和输入边界，但这不等同于验证生产支付系统。
你也可以只读本文完成纸笔推演。面试如果限制外部资料或辅助工具，应遵守当次规则。准备阶段可以练方法，正式考核不能擅自使用未获准的工具。
先把正确行为写在代码外
本例接收订单列表，每条包含标识、状态、实付与退款。只统计paid订单，按订单标识去重，计算实付减退款之和，返回两位小数的Decimal。pending与cancelled均不进入净额。
同一标识内容相同只计一次，内容不同则报错，不猜哪条更新。金额是非负、有限、最多两位小数的字符串，退款不能超过实付；未知状态、空标识和不合法金额也需要明确报错。
这些规则来自本题设定，不是所有订单系统的通用设计。真实系统可能使用事件、版本或多币种，而本文是一个小列表练习。先尊重当前契约，再讨论扩展，能够避免修错问题。
故障代码看起来为什么能运行
故障版遍历订单，只排除cancelled，把实付转换为浮点数累加，最后保留两位小数。它在一条没有退款的paid订单上可能得到预期数值，因此单一正常样例无法揭示问题。
你应先问：pending是否也会被加进去，退款在哪一步处理，相同订单出现两次会怎样，返回类型是否符合契约。每个问题都能变成一个具体输入，不必一开始就猜底层运行时出错。
代码没有异常，不等于业务结果正确；异常出现，也不代表异常处理就是根因。调试需要比较实际行为与契约，不能只看程序是否打印了一个数字。
用最小样例复现退款遗漏
先给一条paid订单，实付10.00、退款2.00。预期净额8.00，故障版得到10.00。此时输入很小，可以直接看出退款未参与计算，无需搭数据库或添加大量日志。
记录输入、命令、实际、预期与环境。面试口头说明可以是：“我已经用单条退款订单复现偏高，接下来检查计算路径是否使用退款字段。”它比“结果不对，我再试试”更便于交流。
不要为了尽快看到8.00而直接在最后减一个固定数。修复要回到规则：每条合格订单减去该订单退款，然后才汇总。一个特定样例的补丁不能表达一般行为。
再分开复现状态与重复问题
仅有一条pending订单，预期为零，但故障版只排除cancelled，仍会计入。它说明条件应围绕本题允许计入的paid，而不是假设“未取消就代表已支付”。
接着将同一条paid订单完全复制两次。预期只计一次，实际却重复累加。这个问题与退款遗漏不同，即使已经减退款，重复记录仍会使总额偏高。
把几个问题拆成独立样例，能够分别验证修复。不要一开始用一个同时含退款、重复、未支付和错误金额的大列表，只看最后总额差多少，难以判断每项改动是否有效。
一个完整复现的纸笔答案
设订单甲实付10.00、退款2.00、状态paid，同样记录出现两次；订单乙实付5.00、退款0.00、状态pending。按当前契约，甲只计一次并扣退款，乙不计，预期净额8.00。
故障版会把10、10和5全部相加，得到25。差额来自三条具体规则：重复甲、多计pending、没有扣退款。解释这些来源，比只说“总数多了17”更能支持修复方案。
如果你先修退款，仍会得到21；再排除pending，得到16；去重后才得到8。中间改善不是完成证据，应将三个独立失败样例分别保留，最后一起回归。
假设需要能够被验证或推翻
可以先提出“退款字段未使用”，再观察单条退款样例；提出“状态判断过宽”，再用只有pending的列表。若结果不符合假设，就回到输入与执行路径，不必坚持最初猜测。
日志或断点应帮助确认某个具体条件，例如某条订单是否被计入、某个标识是否已经出现。打印所有变量可能增加噪音，也可能让你忽略最重要的状态变化。
面试官希望听到推理时，简短说明正在验证哪一项。没有必要每敲一个字符都旁白，但关键假设、观察和选择应当清楚，让对方能够追问或纠正题目条件。
金额类型属于契约的一部分
本题要求Decimal与两位小数，不只是输出看起来有两个小数位。二进制浮点类型与十进制表示存在区别，使用格式化字符串也不会自动满足返回Decimal的约定。
Python decimal文档可以帮助核对十进制类型。练习中从题目规定的字符串创建金额，检查有限、非负与小数位，再计算。本文没有用它推断所有金融业务都应采用相同实现。
返回类型、舍入与允许输入应该写清。若题目允许超过两位的小数，就需要另行约定舍入方式；本题选择拒绝这类输入，避免在没有规则时自行决定。
去重不等于忽略所有相同标识
相同标识且内容相同，可以视为重复导出。若同一标识实付不同，直接保留第一条会掩盖冲突。本题没有版本时间，因此参考实现选择报错，让调用方处理资料问题。
存储已见标识时，同时记录规范化后的状态、实付与退款。这样能够判断是相同内容还是冲突。只使用一个标识集合，无法发现第二种情况。
真实订单如果一条标识下有多个商品或状态事件，当前逻辑就不适用。面试官改变粒度时，应重新确认规则，而不是把本题去重方式当作无需讨论的最佳实践。
修复输入边界要与范围一致
空列表应返回零，零金额可以是合法值，全额退款的paid订单净额为零。不要用一个“金额必须大于零”的判断误伤题目允许的情形。
空标识、未知状态、退款超过实付、非有限金额或非法格式，则按契约报ValueError。错误结果应该明确，不能在捕获所有异常后悄悄返回零，让坏数据看起来像没有收入。
如果输入要求尚未明确，应先提问。没有必要为一个小练习实现所有可能格式，但你支持与拒绝哪些情况必须一致，并有相应样例支持。
回归测试需要能抓住原来的错误
修复后保留退款、重复和pending的失败样例，再加正常订单、空列表、全额退款与冲突。测试的预期值来自契约或独立手算，不要调用同一段实现来生成答案。
包内使用Python unittest组织检查。默认运行参考实现，设置TARGET_MODULE为buggy时运行故障版。两种命令的目的不同，README已分别说明。
测试通过只能支持已覆盖的有限行为。如果没有做并发、持久化、币种或外部接口验证，就不宣称这些能力已经可靠。调试汇报要同时说明解决的问题和仍然存在的边界。
改动范围为什么不宜突然扩大
发现净额错误时，先修当前计算与必要验证，不必同时重写整个程序、替换所有命名或引入新的框架。改动太多，会让你难以确认究竟哪一步解决了原问题。
如果发现另一个独立问题，可以记录影响和下一步。只有它阻碍当前正确性、属于题目要求或获得进一步范围时，才继续处理。合理控制范围也能体现工程判断。
当然，若根因来自不合适的数据模型，就需要调整结构。最小修复不是机械追求行数少，而是让改动覆盖原因，并且容易解释和验证。
练习时怎样安排时间
先留一段时间读契约并手算，再建立最小复现；随后修一个原因并检查，再覆盖其他原因，最后留出汇报与边界检查。不要把全部时间花在试错，直到结束才第一次思考预期。
速度应从重复练习中提高。第一次慢一点把记录完整，下一轮换一段小函数或不同数据，观察自己能否沿相同方法独立定位，而不是记住这份代码的答案。
如果没有伙伴，可以先录下自己的推理，完成后回听哪些假设没有证据、哪些改动没有验证。录音的价值是发现过程断点，不是评价声音是否听起来像资深工程师。
面试最后怎样汇报
可以按四句展开：复现了哪些错误，根因是什么，改了什么，怎样检查。然后补充明确限制，例如本题是单次列表汇总，没有覆盖事件流与多币种。
若时间不足，没有完成修复，就说明已验证的部分、尚未完成的假设和下一步检查。不要将准备写的测试说成已通过，也不要将程序运行成功等同于所有问题解决。
Microsoft技术面试指导可以作为技术沟通准备参照，实际环节仍需核对。比起背诵一个修复，持续练习怎样建立证据，更容易迁移到陌生代码。
对照两个看似合理的错误修法
第一种修法是把所有相同标识都跳过，却没有比较内容。它能通过完全重复样例，但面对同一标识金额不同会悄悄丢掉资料。本题明确要求冲突报错，因此需要另一个样例推翻这种修法，不能只看正常去重是否通过。
第二种修法是捕获所有异常并返回零。它让非法金额不再造成报错，却把输入问题变成合法的零净额。调用方可能据此误判没有支付记录，既失去错误信息，也不符合题目契约。
请先在纸上写出两种错误修法各会通过什么、失败什么，再看参考测试。这样能理解为什么测试需要有不同性质的输入，而不是只增加更多相似正常订单。
最后尝试从测试反推业务含义：全额退款仍是paid状态，但净额为零；空列表没有订单，但同样返回零。相同输出不代表输入状态相同，若后续任务需要订单数，就必须另外设计返回结构，而不是从零净额推断没有订单。
本题不要求你扩展这个结构。把需要变化的地方说明白就足够，再回到已经约定的函数，保证修复、测试和说明一致。能够控制这条边界，也能避免在限时练习中不断增加未验证功能。
如果自己修改了故障文件，请保存改动前后版本，再运行同一组检查。记录哪个输入曾经失败、现在得到什么，能让下一次复盘看见真实修复过程，而不只剩一个干净的最终函数。
带一份调试记录来讨论准备重点
完成练习后，保留一次错误输入、你的假设、修复与测试结果。点击本页按钮添加蒸汽顾问微信，可以说明目标软件岗位、面试形式和当前最容易卡住的步骤。
如果看不懂代码，先补语言与基础；如果能定位却讲不清，则练过程表达；如果总修一个问题又引入另一个，需要加强契约与回归。三类困难不必使用完全相同的训练安排。
蒸汽技术面试与求职服务可围绕真实岗位讨论专项准备。带具体记录来沟通，会比只说“刷题不够”更容易找到下一轮值得练的动作。
常见问题（FAQ）
故障版测试失败是安装问题吗？
通常是本练习的预期现象，先按README复现并分析；参考版有独立检查命令。
修完一个样例就能结束吗？
还需检查相关规则、旧失败样例与必要边界。
八项测试通过能证明生产可靠性吗？
不能，只支持当前有限教学契约及已覆盖情景。
- unittest Unit testing framework· Python Software Foundation
- decimal Decimal fixed point and floating point arithmetic· Python Software Foundation
添加顾问微信，说明软件岗位与考核形式，带一份调试记录，讨论复现、修复、测试和表达。