要因分析法

作为黑盒测试的一个重要阶段，功能测试毋庸置疑是不可缺失的。

功能测试的相关话题很多，无论是测试的形式，例如手动测试和自动化测试，还是测试方法，例如数据驱动和关键字驱动，都有大量的研究文章。

我这篇博文里却打算从国别不同的角度来讨论一下功能测试的差异，原创文章可能有一些谬误的地方，请读者指摘。

日式循规蹈矩
日本人给世界其他民族的印象是做事认真严谨，对待问题一丝不苟，犯了错误按严重程度该下跪的下跪，该剖腹的剖腹。

他们的这种一贯行事方式也带到了软件行业，而软件行业的摩尔定律，技术的日新月异，代码、框架的多变，都似乎与他们的性格格格不入。

日本制造的东西一向以坚固耐用著称，给我印象最深的一个细节是，在日本工作的时候，发现他们的垃圾袋居然都坚固无比，用来逛超市买东西拎重物也是屡用不坏。

然而，对于遵从摩尔定律的计算机行业来说，投入大量的精力来尽可能的发现bug以及解决问题是否很值，这真的是有待商榷的问题。

但，话虽如此，日企采用的测试用例的设计方法还是非常值得我们学习的，这其中又首先要提一下要因分析法（网上有些说法把鱼骨图等同于要因分析法，我并不赞同此说，后面会有详述）。

要因分析法的精髓在于，以产品的某一特性为因子，以这个特性的不同表现（根据等价类划分、边界值分析等方法）为状态，一一列举后，采用二维组合的方式来确定测试用例。

下面我举一个简单的例子“我打算从南京去北京”来说明。

表1
这即是一张简单的要因表，值得注意的是，因子和状态的确定是必须规定范围的，而这个范围在这个例子中则为“正常人的思考”范围。

譬如说，“交通方式”我没有写“步行”，因为这不符合常人从南京去北京的思考方式，当然有人为了挑战吉尼斯纪录，这里非要采用步行方式从南京前往北京，那么状态里添加这项显然是可以的。

此外，因子和状态的另一个隐性的确定方针为详细度，这个度如何把握，我们可以从下表来理解：
表2
表2将表1的“交通方式”进一步细化，此时状态的选择将进一步增多。

如果要求详细度更加提高，例如因子为“动车”，那么可以加上状态为“一等座”和“二等座”，这种组合很灵活，取决于我所需的详细级别。

要因确定之后，便是组合，以表1所列要因为例，二维组合有下列共18种：
飞机-晴-白天，飞机-雨-白天，飞机-雪-白天，飞机-晴-夜晚，飞机-雨-夜晚，飞机-雪-夜晚
火车-晴-白天，火车-雨-白天，火车-雪-白天，火车-晴-夜晚，火车-雨-夜晚，火车-雪-夜晚
汽车-晴-白天，汽车-雨-白天，汽车-雪-白天，汽车-晴-夜晚，汽车-雨-夜晚，汽车-雪-夜晚对于表2来说，二维组合则有2*4*2*3*2=96种，貌似有点多，当然你想分析的越详细，那么组合数量自然会相应的增加。

回到表1得出的18种用例，假如我的通过条件是从南京到北京的时间越短越好，在实际的外界环境下（例如晴天，预期花费有限额），这18个用例中，就会出现有的测试通过，有的测试失败的情况了。

在不同的实际外界环境下，测试通过的情况还会发生变化（例如下雪天，飞机会发生班次延误）。

要因分析法的好处在于“事无巨细，滴水不漏”，坏处在于过程“繁琐冗长，枯燥乏味”。

即使如此细致的要因分析，依然存在一定的用例遗漏的风险，这个风险来自于对因子和状态潜在的考虑不周。

随着详细级别要求或者系统复杂度的提高，使用要因分析法组合出详尽的测试方案则成为了QA的一种折磨，每一个QA遇到复杂的测试对象，都将成为酷刑下折翼的天使，欲哭无泪的在心中默默呐喊“坑爹啊”（因此要对要因法做一定程度的改良，如何改良，后文将详述）。

前文伏笔“要因分析法不是鱼骨分析法”，鱼骨分析法的另一个更加正式的书面称呼是“根本原因分析法”（日本管理大师石川馨先生发展出来的，故又名石川图）。

根本原因分析法同样有着折磨常人的地方（题外话：为什么日本人使用的方法总是那么坑爹？），它要求分析者们集中精力寻求发生问题的任何一种可能性（头脑风暴），将这些可能性绘制在鱼骨图上，再寻求所有可能性的根源，其本质上不是一种用于设计测试方案的方法（仅仅用于追溯问题，例如发现bug后追溯引起bug的根源）。

关于根本原因分析法的讨论，由于和本文的重点有偏离，因此不做进一步描述，题外话就此打住。

欧美式头脑风暴
众所周知，欧美企业的风格是强调人性和自由，对于测试来说，自然不可能采纳日式那种条条框框的做法。

测试方案设计的基本方法和准则，例如边界值分析、等价类划分、因果图等，被QA们牢牢的记在心中，功能测试方案设计时，根据需求分析或用户手册，众人在一起集中进行头脑风暴，此时包括RD也将参与进来，对于测试合理或者不合理的地方提出建议。

因此，
方案设计的时候，更强调的是经验和阅历以及对需求的关注程度。

测试方案设计是有偏重的，对于一些重要的feature强烈关注，用例也将根据feature的重要性而详略有别。

头脑风暴式的测试用例设计的辅助工具往往以思维导图为主，还是以“我打算从南京去北京”为例，其中一种思维导图设计如下：
思维导图的灵活性很高，因此设计出的导图每次都会有所不同，跟随着与会者偏重点的不同而产生不同的设计方案。

好比欧洲的菜肴大多以整块烹制为主，而中国人的菜肴则基本上都是切碎的。

这是因为受限于传统使用的餐具。

而测试方案的设计方法也同样受到西方和东方文化差异的影响，例如Agile 首先在欧美出现并迅速得到推广和应用，而Agile绝对不会首先出现于日本。

对于头脑风暴式的测试方案设计，这颇有Agile的风格，项目参与者进行充分的思想交流，QA们将每一个闪现于头脑的想法都记录在案，同时根据别的QA和RD的建议来不断地修正或弥补方案，直到完成设计。

这种设计方法的好处是拥有很好的灵活性，且可以避免精力被耗费到旁枝末节上。

用例可以是很多步骤组合起来的（表现为思维导图的层次较多），通过一个用例测到多个feature，这在进行具体的自动化测试代码编写时可以节省大量劳动力。

由于交流足够充分，某些不易被想到的测试用例也可以被挖掘出来（好比绘制清晰的思维导图）。

然而，这种方法的缺点也是显而易见的，某些测试用例有可能在头脑风暴中被忽视或遗忘，且受限于人的思维的不严密性，未设计在案的测试用例，往往也没有人会关注到“为什么这些测试用例不用测”这个问题。

欧美与日式的比较
其实从上述的两个篇章，我已经阐述了二者之间的差异。

日式苦行僧般的要因分析法，几乎可以遍历穷举所有可能的组合方式（除非因子有遗漏），设计完毕后，到了具体测试实施阶段，无论是手动测试还是自动化测试，对于QA来说，都是一个比拼耐力的考验，测试用例数动辄过千，大量的测试用例之间甚至只有细微的差别。

QA将完全体验不到创作的乐趣，转而成为一名不折不扣的体力劳动者。

一个测试对象的测试周期也被大大拉长，所需的人月数也很多。

完成这些繁琐的工作之后，测试对象将趋于完美，细微的bug也将被找出并修正。

此时不排除测试对象可能已经是一个落后的甚至被淘汰的产品了。

当然，这对于用户忠诚度极高的日本人来说，这不算什么问题，他们不厌其烦的强调产品品质，但是对于这颗星球上的其他民族来说，大多宁可忍受一些小bug，也不愿使用一个过期的技术落后的产品。

对于欧美式的测试设计，显然比较契合当前的飞速发展的计算机业，但产品中留下的bug数量往往也会比日式测试法多的多。

这尤其表现在产品的一些局部的、次要的功能上，这些功能往往将成为bug集中营。

两者融合的思考
欧美与日本，两者采用的方法各有长处。

一者的缺点往往恰是另一者的长处。

那么该如何从两者中取长补短，去粗取精以至互相融合呢？这也是我在工作中一直不断思考的一个问题。

我认为有一种可行的解决方案可以按照如下的做法进行：
1. 列出要因表，因子和状态的列举方式可以采用思维导图进行
2. 根据deadline来划分测试的详略程度，制订测试计划
3. 头脑风暴，将要因表的二维组合放在参与者的头脑中进行
4. 在列举测试用例的同时，对不测的用例也要追究一下不测的原因
5. 归纳测试用例之间的共性，对于差别较小的测试用例，要考虑如何整合到一起，对于可以串行的用例，要考虑是否可以合并为一个多步骤的用例
通过以上5个步骤，我想既可以避免要因分析法的要因组合阶段带来的让人抓狂的繁琐和用例数量过多的缺陷，又可以避免头脑风暴带来的某些用例的考虑不周。

是否还有其他更好的取长补短的方法呢？这个问题将依然萦绕在我的日常测试工作中，也期待您对本文的看法能够给予我茅塞顿开的启迪。