测试中的指数爆炸问题

 有这样一个故事，就是介绍指数问题的：一位数学家发明了国际象棋,国王十分感谢这位数学家，于是就请他自己说出想要得到什么奖赏。这位数学家想了一分钟后就提出请求——把1粒米放在棋盘的第1格里，2粒米放在第2格，4粒米放在第3格，8粒米放在第4格，依次类推，每个方格中的米粒数量都是之前方格中的米粒数量的2倍。国王欣然应允，诧异于数学家竟然只想要这么一点的赏赐——但随后却大吃了一惊。当他开始叫人把米放在棋盘上时，最初几个方格中的米粒少得像几乎不存在一样。但是，往第16个方格上放米粒时，就需要拿出1公斤的大米。而到了第20格时，他的那些仆人则需要推来满满一推车的米，可还是不够。国王根本无法提供足够的大米放在棋盘上的64格中。因为此时，棋盘上米粒的数量会达到惊人的18 446 744 073 709 551 615粒;事实上，这一堆米粒比过去1000年来全球大米的生产总量还要多得多。现实的产品测试中每天都在面临这种遍历不可能问题如何应对本文给出一些思考供相关设计人员参考。如一个产品交付有如下5个部件每个部件有不同的软件版本，设计时明确部件之间没有明显的耦合关系，但具体功能实现上部分部件之间的软件有依赖关系，使用中如配套部件版本不支持，其相应功能不可用，其他功能不受影响；可是产品上网后，经常出现配套功能性影响业务功能性问题，大领导就很着急为什么测试没有测试出来，经过分析发现这时一个典型的指数爆炸问题，想做到全覆盖无任何问题的遗漏几乎不可能，下图举例进行说明：

每个部件单独对外发布，有耦合关系时需要同步对外发布，说明对应版本关系。每个部件对外发布计划，有的部件每月发布2个发版本，有的每月发布1个版本，随着时间的推移网上的存量版本会越来越多；当5个部件上网有6个版本时，全覆盖测试的组合就有6*6*6*6*6=7776种组合，完成一个组合的测试10分钟：升级启动需要5分钟，进行基本的功能测试5分钟；7776的组合需要测试：7776*10=77760分钟=54天，不间断的持续测试也需要54天；当新发布1个部件A的版本时，测试组合就翻了1倍，时间增加为108天，随着时间的推移，测试组合增多，几乎是不可能完成这些组合覆盖，这时测试策略上就需要做取舍，部件版本兼容性取舍几种可行的参考策略：

1. 覆盖长周期版本；（生产主力发货版本，收编版本等，最好是半年周期的版本）
2. 自动化覆盖；（每个部件随机选取3中进行全组合覆盖，有243种组合，大约需要测试2天，维护版本转测试后一般有3~5天验证时间，还是可以满足发布需求的）。
3. 有接口关系的前后版本覆盖，保证接口功能的同时，要保证其他功能正常，无影响业务的问题；（PairWise覆盖策略，预计减少60%左右的工作量）；

3种策略可以并行选择综合确定测试部件版本。