 测试程序开发中，测试条件（电压、电流、时序、判断限）的写法有两种选择：直接以数值形式写在代码中，或者定义为符号常量后再引用。前者称为硬编码，后者称为参数化。两者在功能执行上等价，但在工程维护层面存在本质差异。对于量产程序，参数化不是建议，而是必须。  一、硬编码的三个代价 1. 数值语义丢失 孤立数字无法表达其物理含义。代码中的10是10ms延时、10µA电流限还是寄存器地址？维护者无法判断。参数化后，变量名本身就是注释：WAIT_MS、LEAKAGE_LIMIT_UA、REG_ADDR，含义一目了然。 2. 变更传播风险 规格变更时，需要在代码中定位所有出现该数值的位置。遗漏一处就会导致测试标准不一致。参数化将数值定义在一处，所有引用自动同步。 3. 复用性受限 硬编码程序与特定芯片、特定测试平台强耦合。移植到新项目时，修改工作量与代码规模成正比。参数化程序将逻辑与条件分离，跨平台时只需替换参数定义层。 二、参数化的三种实现方式
三、哪些参数必须参数化
四、参数化的边界 以下场景可适度放宽： 临时调试代码 物理常数（0、1等） 协议固定值（I2C设备地址等） 循环计数中语义明确的边界值 判断标准：该数值在程序生命周期内是否可能变更？若可能，则参数化。 五、工程成本对比
硬编码与参数化的选择，本质上是将测试程序视为“一次性脚本”还是“长期资产”的判断。 参数化不改变程序的执行结果，但改变程序的可理解性、可维护性和可复用性。在量产环境中，这是区分“临时能用”与“可持续维护”的关键分界线。  |
