在软件测试领域，"测试充分度"一直是一个备受关注的难题。本文探讨了如何提升业财系统测试的充分度，以减少线上问题的发生。文中介绍了测试充分度的概念及其重要性，并提出了测试充分度的建模方法，包括测试场景的建模和用例设计模型等。

认识测试充分度

网上曾经统计过测试领域的“Top Hard Problems”，其中“测试充分度（Test Sufficiency）”高居榜首。软件测试行业发展到今天，测试充分度一直是软件测试领域的终极问题之一。每一次线上变更测试人员都要回答一个问题“测充分了吗？”，过去业界有一些测试充分度的衡量手段，例如：代码覆盖率，但代码覆盖率只是衡量测试充分性的起点，但远远不是终点。代码100%覆盖不代表场景100%覆盖，提升代码覆盖率是软件测试的必要条件，但不是充分条件。要达到“完美”的覆盖，至少需要考虑所有用户场景、所有事件、所有可能数据、所有可能配置、所有状态、所有异常等等，即使如此测试充分度也未必能达到100%，可能最终只能做到趋近100%，如下图所示用例与覆盖率的关系。

软件测试充分度除了受上述各种不确定性的变量因子制约，还受时间和成本的制约，环境的限制导致无法完美解决，但我们可以朝着那个反向靠拢。本文讨论的方向是：如何提升结算系统的测试充分度，降低线上问题发生的概率。

测试充分度建模

▐1. 测试充分度公式定义

当我们讨论“测试充分度”的时候更多的是一个感性的表达，表示“测试的程度”究竟有多深，但要想提升需要对其进行量化表达。下面尝试着定义测试充分度公式：

其中A、B、C、D...代表影响软件系统的变量因子，全集定义为S={A,B,C,D...}，每个变量因子又是一个枚举变量集，例如A={a1,a2,a3...an}，所有变量因子的笛卡尔乘积就代表了测试充分度的分母。

从公式中可以看出“需求 -> 场景 -> 用例”每一层转换都是1对多的关系，只是站在不同角色的视角看测试充分度，测试作为研发的下游，更多的是从场景出发来设计用例，所以接下讨论如何对“场景”进行建模，从而更方便的转换成测试用例。

▐2. 被测系统分析

“业务场景”、“测试场景”、“用户场景”等是产研过程中接触比较高频的词汇，本质上表达的是同一个意思，为了方便理解本文统称“测试场景”。“变量因子”是从“被测对象”中提取出来的，“被测对象”本质上就是“测试场景”，所以测试活动是围绕“测试场景”展开的，这也是为什么要给测试场景建模的原因。

软件系统可以被抽象成如下的“输入-输出”模型，所以“软件测试场景”是指要开展测试活动所需要素总和：

▐3. 测试场景建模

确定被测系统模型后：如何圈定测试场景范围？有人认为测试场景覆盖范围是整个全链路，也有人认为测试场景覆盖范围某个局部链路，虽然各自有道理，但我们还是需要一个模型来对链路切分进行指导，因为测试链路越长，带来不稳定因素越多：执行时间长、用例不稳定、排查时间长、硬件成本高。这些缺点带来的技术成本是无法忽视的。

结论：抛弃全链路，将有明确上下游契约关系一个单元圈定为一个测试场景覆盖范围，这样更有利于测试充分度提升。

上述观点建立在抛弃另外一个观点：不做全链路测试会导致某些场景覆盖不全。只要系统之间有服务契约，且双方都是完全遵守这个契约的，局部覆盖完全可以替代并超越全链路覆盖的效果。理论层面上应用了“分治思想”，从理论推导层面是完全可行的。事实上国外大型软件厂商（Google、微软、Amazon）对此早有探索，并通过实践证明是完全可行。

如何保障两个系统单元之间是否遵守契约？需靠两个系统单元各自的测试人员保障。

补充思考：

现状是每个系统都有一个owner，owner有在同一个团队，也有在不同团队，环境约束，每个owner都有各自的目标和利益，这就形成了非合作博弈均衡，根据"纳什均衡"理论，每个局部系统无需关心其他系统的情况，只要基于"契约"追求局部系统内最优，最终就能达到整个全链路系统最优解，这里的"契约"就是支配性策略。

▐4. 用例设计模型

确定了测试场景覆盖范围，接下来讨论提升测试充分度模型。美国国家标准与技术研究院（NIST）经过长期研究，提出通过提升“组合覆盖密度”可以大幅提升软件质量，降低软件缺陷发生的概率。本节内容以NIST发表的 Combinatorial Coverage Measurement Concepts and Applications 这篇论文为基础展开讨论。

简单t路（t-way）组合覆盖的定义：

假设被测系统有n个变量输入，每个变量有多个取值，t-way表示n变量中抽取t个变量。例：系统有a,b,c,d四个变量，每个变量有两个可能取值0,1，设计如下表用例组合：

1-way 覆盖率100%，a,b,c,d每个变量都覆盖了0和1，所以1路覆盖率为100%

2-way 覆盖率33.3%，只有bd和cd覆盖了所有取值组合，2路覆盖所有组合为C(4,2)=6，覆盖率为2/6=33.3%

3-way 覆盖率0%，无任意3个变量的组合完全覆盖了C(4,3)中的其中一个

4-way 覆盖率0%，同上。

覆盖比例完整度(p, t)-completeness

(p, t)-completeness的定义：p代表组合覆盖率，t代表t-way，(50%, 2)-completeness表示2-way覆盖中，所有覆盖比例大于50%的占比情况。

还是上面例子，2-way覆盖一共有C(2, 4)=6种组合：ab,ac,ad,bc,bc,cd，每个2-way完整覆盖共有2*2种情况：00,01,10,11，所以2-way覆盖的所有组合元组数量为：C(2,4)*2*2=24。

simple 2-way coverage = 2/6 = 0.333

total 2-way coverage = 19/24 = 0.791

(.50, 2)-completeness = 6/6 = 1.0

(.75, 2)-completeness = 5/6 = 0.833

(1.0, 2)-completeness = 2/6 = 0.333

假设S(t)表示t-way的全局覆盖，下图展示了2路覆盖图，Y轴表示变量覆盖率，X轴代表组合占比。

图表中Φ代表100%变量覆盖值，M代表最小覆盖比例。沿着 Φ->M刻画一条线路，线路左下方代表区域表示已覆盖，线路右上方表示未覆盖，因此可以大致算出全局S(t)覆盖率。

当Φ和M两点之间的区域为矩形时，上述公式取等号。

▐5. 覆盖率目标模型

先看一个例子：某系统提供了7000个用例，如此庞大的用例库如何验证它的覆盖度？下图是根据用例推导出的2、3、4路覆盖率路径，红色:2-way，蓝色：3-way，绿色：4-way。图中（1）点显示82%的用例覆盖了100%的变量值，（2）点显示98%的用例覆盖了75%的变量值。

结论：覆盖公式可以为各种测试策略的覆盖率目标提供指引，根据长期研究表明，t+1-way覆盖率占t-way覆盖率大于75%时，就没有必要耗费精力做更高t-way的覆盖「t+1-way 覆盖）/(t-way覆盖) > 75%」，因为更高组合数的覆盖并不能发现更多的系统问题。绝大部分系统做2-way覆盖就能达到发现99%缺陷的目标。

如何设计测试用例

根据前面对测试场景的建模以及2-way覆盖理论展开讨论：

▐1. 契约变更分析

本需求核心修改：结算账款同步付款域--> 结算对账单确认后同步付款域，因此重点关注结算与支付之间的契约。

▐2. 变量因子与取值分析

除了同步账单号等基础数据，核心同步税率、资金方向、发票方向、金额方向，要与产品和研发同学确认清楚契约要素有没有遗漏，同时要确认每个要素的合理取值范围。这一步其实就是TC评审。

▐3. 测试场景拓展

根据测试经验进行要素拓展和，覆盖异常、性能、配置开关等等场景，需结合实际业务场景进行拓展，没有必要的场景无需过度拓展。

▐4. 用例设计

根据2-way覆盖设计测试用例，设计的目标是用更少的用例做更多的场景覆盖。

为了方便表达，做字母化税率-a、资金方向-b、发票方向-c、金额方向-d

覆盖完整比例表如下：

覆盖统计如下：

simple 2-way coverage = 6/6 = 1.0

total 2-way coverage = 30/30 = 1.0

(.50, 2)-completeness = 6/6 = 1.0

(.75, 2)-completeness = 6/6 = 1.0

(1.0, 2)-completeness = 6/6 = 1.0

组合覆盖率图表：

S(t) = Φt + Μt – Φt Μt = 1.0

如何配合

要想达到理想的测试充分度需产品、研发、测试配合，并达成以下共识：

结算系统链路需要按契约进行切分产品prd和技术细分文档里要单独体现契约部分的改动用例评审重点评审契约以及契约中变量取值范围

action：

1、梳理结算链路，按契约进行切分；

2、后面的prd和技术系分文档中要体现契约的部分；

3、设计新的用例评审模板，评审重点评审契约变动部分。

实践

▐组合覆盖工具

基于“组合覆盖”理论自动化生成用例，业内已经有很多的工具（工具列表），做得比较好的：

https://hexawise.com/https://kiwitcms.org/

包括Jenkins和Junit都有相关的插件。目前Atest2平台上的自动化用例就是基于组合覆盖理论设计的，减少人工设计用例的遗漏。

推荐一个简单的开源Python库：https://github.com/thombashi/allpairspy

输出：

▐在团队的落地

今年来团队花了大量工作在自动化用例覆盖度上，主要对结算系统所有模块进行了接口契约梳理，定义影响系统覆盖的关键因子，基于组合覆盖理论设计自动化用例，目前每个模块均沉淀了基线用例，有效保障了上线前测试遗漏的风险。

结语

本文探讨了提升业财系统测试充分度的方法与实践。通过引入组合覆盖理论，我们展示了如何高效地设计测试用例，以实现更高的测试覆盖率。我们强调了产品、研发和测试团队之间的紧密配合对于提升测试充分度的重要性。希望本文的内容能够为读者在提升测试充分度方面提供有价值的参考和借鉴。

参考资料

Combinatorial Coverage Measurement Concepts and Applications：https://csrc.nist.gov/CSRC/media/Presentations/Combinatorial-Coverage-Measurement-Concepts-and-Ap/images-media/kuhn-et-al-iwct13.pdfhttps://www.pairwise.org/tools.htmlhttps://github.com/thombashi/allpairspy