多测一步，少很多漏测：0、1、多场景的测试逻辑

缺陷分享

        最近遇到个挺有意思的问题 —— 港股通交易时，在个股委托页面双击带出的委托数量，偶尔会 “跑偏”。明明选的是 A 股票，算出来的委托数量却跟 A 没关系，反而像照着另一只股票的规矩算的。这到底是咋回事？​

        先说说问题本身：港股通交易里，在个股委托页面双击带出委托信息时，委托数量经常不对。比如刚看了股票 B，再双击股票 A，A 的委托数量竟然是按 B 的规矩算的，结果自然错得离谱。​

        为啥会这样？罪魁祸首是代码里的一个 “全局变量”。这个变量本来是想存同一类证券（比如同市场、同委托方向）的最小委托数量，结果把从行情里拿到的数值存成了静态值。可港股通的股票特别 “个性”—— 就算是同一类证券（比如同属港股通、同买卖方向），不同股票的最小买卖单位也可能不一样。​

        举个例子：先选股票 B，系统把 B 的最小委托数量存进了这个全局单例；接着选同类型的股票 A，系统没重新查 A 的最小委托数量，直接用了 B 的数值。A 和 B 的最小单位不一样，算出来的委托数量能对吗？​

        再说说为啥测试时没发现。当时测试只拿了一只股票试了试，算出来的委托数量是对的，就没多想。但没考虑到港股通里不同股票的最小委托数量不一样，也就没测试 “连续双击不同股票，委托数量会不会跟着变对”。其实委托数量是靠金额、费用、最小委托数量这些要素算出来的，当时没切换不同代码多试几次，就漏掉了这个问题。​

        说到底，测试得把 “单个、多个” 这类基础场景考虑到，不能只靠一条数据验证。尤其是涉及到 “不同个体可能有不同规则” 的业务，必须多换几个例子测。​

        这个问题的影响可不小。交易系统连委托数量都算错，客户肯定会质疑团队的专业性。这种正常用就能发现的问题，难免会被问：“你们到底测没测过？” 对产品和测试团队的信任度打击不小。

为什么不能只测一条典型数据

        上述案例揭示了 “只测一条典型数据” 的隐患。系统缺陷多藏在数据变化中，单条数据验证如同用一张快照判断电影完整性，必然漏掉关键情节。不能只测一条数据，源于需求、设计、开发中存在需多场景验证的 “暗礁”：​

其一，需求中 “共性与个性并存” 易被单测忽略​

        需求常规定同类型数据有通用规则但允许特例，如只要市场、证券类型、买卖类型相同，最小委托数量都相同，但是港股通股票却是根据证券代码来确定最小委托数量。单条测试若选中符合通用规则的样本，会漏掉对 “个性数据” 的验证。​

其二，设计的 “数据量级适配性” 需多场景验证​

        设计师会针对不同数据量做差异化设计，如多数据显分页、0 数据显提示。只测单条数据，难发现 “数据量变化时设计是否适配” 的问题，例如翻页按钮，当0条、1条、满足翻页的条数时，系统有不同表现。​

其三，开发的 “条件分支” 需要多数据覆盖​

        代码逻辑常含多个条件分支，单条数据测试可能只走通一个分支，掩盖其他分支的错误。比如计算委托数量时，若单测数据刚好符合 “最小委托数存在” 的分支，会漏掉对 “不存在时默认值” 的验证。​

其四，开发对 “数据依赖关系” 的处理需多场景校验​

        功能依赖数据间的联动，如委托数量计算依赖最小委托数、金额等。单条测试只能验证一组数据的依赖关系，测不出数据变化时依赖链是否断裂，就像港股通缺陷中依赖项被错误复用。​

其五，需求中的 “边界值规则” 需跨数据验证​

        需求里的边界值是问题高发区，如 “最大委托数量不超 1000 手”。单条数据若在边界内，测不出 “等于边界值是否生效”“超边界值是否拦截” 等情况。​

其六，开发中 “全局变量污染” 需多数据排查​

        开发可能用全局变量存临时数据，单条测试时变量值不会被覆盖，看似正常；多数据切换时，前次数据可能残留污染后次计算，如港股通中全局变量存储的数值被复用。​

        这些 “暗礁”，单条数据验证无法触及。测试不能只靠一条数据下结论，多场景、多数据验证才是避开系统缺陷的 “导航系统”。

如何设计0、1、多的测试策略

        需要测试 0、1、多场景的原因有多个，可能在仅测试单条数据时被掩盖。而我们往往不清楚自己的系统会存在什么具体问题，所以就需要设计通用的测试策略，以覆盖尽可能多的潜在问题。​

        通用测试策略可以采用 “动态数据链” 覆盖 0、1、多场景，同时通过 “变量控制法” 精准捕捉差异。具体可按以下四步落地：​

第一步：建 “基础 - 变体” 数据组​

先选取 1 条 “标准数据”（即符合通用规则的典型值），再围绕它生成变体：​

• 0 数据：直接清空当前数据组​

• 1 数据变体：修改 1 个关键属性（例如港股通股票修改最小委托数量）​

• 多数据组合：包含 “标准数据 + 1 个变体数据”“2 个不同变体数据”​

这样的设置既能覆盖 “共性与个性”（变体数据体现个性），又能验证 “全局变量是否污染”（多数据切换时属性是否串用）。​

第二步：按 “连续操作流” 执行场景​

按照固定顺序运行场景，并记录每个节点的结果：​

1. 0 数据状态：检查空值提示、默认按钮状态​
2. 录入 1 条标准数据：验证基础计算逻辑​
3. 不改参数直接切换到另外 1 条变体数据：观察是否沿用前次数据（测试全局变量）​
4. 同时加载标准 + 变体数据：检查排序、筛选、计算是否混乱（测试数据依赖）​
5. 批量删除至 0 数据：验证状态重置是否彻底​

这套流程能够覆盖 “条件分支”（0、1、多分别对应不同分支）、“边界值”（批量操作时容易触及边界），还能模拟用户高频切换的真实习惯。​

第三步：用 “单一变量法” 定位差异​

在多数据测试时，每次只修改 1 个变量（比如只修改最小委托数量，保持其他参数不变）。如果结果出现异常，就可以直接锁定该变量对应的逻辑 —— 既能发现 “数据依赖关系断裂”（变量变化未触发关联计算），也能验证 “设计适配性”（变量变化时界面是否异常）。​

第四步：加 “反向操作” 补充场景​

在上述流程中插入反常识操作：​

• 刚删完数据（0 状态）立刻新增 1 条​

• 多数据状态下强行输入边界值（如超过最大委托数）​

• 连续快速切换 3 个不同变体数据​

这类操作能暴露 “边界值规则失效”“全局变量重置延迟” 等隐藏问题，且无需了解底层设计细节。

总结

        本次分享的港股通委托数量计算错误缺陷，凸显仅测单条数据的局限。因需求共性与个性、设计适配性等多原因，必须测试 0、1、多场景。而通过 “基础 - 变体” 数据组等四步策略，既能覆盖多类问题，又能精简场景，高效保障系统质量，避免类似缺陷。