作为黑盒测试的一个重要阶段，功能测试毋庸置疑是不可缺失的。功能测试的相关话题很多，无论是测试的形式，例如手动测试和自动化测试，还是测试方法，例如数据驱动和关键字驱动，都有大量的研究文章。我这篇博文里却打算从国别不同的角度来讨论一下功能测试的差异，原创文章可能有一些谬误的地方，请读者指摘。
日式循规蹈矩
日本人给世界其他民族的印象是做事认真严谨，对待问题一丝不苟，犯了错误按严重程度该下跪的下跪，该剖腹的剖腹。他们的这种一贯行事方式也带到了软件行业，而软件行业的摩尔定律，技术的日新月异，代码、框架的多变，都似乎与他们的性格格格不入。日本制造的东西一向以坚固耐用著称，给我映像最深的一个细节是，在日本工作的时候，发现他们的垃圾袋居然都坚固无比，用来逛超市买东西拎重物也是屡用不坏。然而，对于遵从摩尔定律的计算机行业来说，投入大量的精力来尽可能的发现bug以及解决问题是否很值，这真的是有待商榷的问题。
但，话虽如此，日企采用的测试用例的设计方法还是非常值得我们学习的，这其中又首先要提一下要因分析法（网上有些说法把鱼骨图等同于要因分析法，我并不赞同此说，后面会有详述）。
要因分析法的精髓在于，以产品的某一特性为因子，以这个特性的不同表现（根据等价类划分、边界值分析等方法）为状态，一一列举后，采用二维组合的方式来确定测试用例。
下面我举一个简单的例子“我打算从南京去北京”来说明。
表1
这即是一张简单的要因表，值得注意的是，因子和状态的确定是必须规定范围的，而这个范围在这个例子中则为“正常人的思考”范围。譬如说，“交通方式”我没有写“步行”，因为这不符合常人从南京去北京的思考方式，当然有人为了挑战吉尼斯纪录，这里非要采用步行方式从南京前往北京，那么状态里添加这项显然是可以的。
此外，因子和状态的另一个隐性的确定方针为详细度，这个度如何把握，我们可以从下表来理解：
表2
表2将表1的“交通方式”进一步细化，此时状态的选择将进一步增多。如果要求详细度更加提高，例如因子为“动车”，那么可以加上状态为“一等座”和“二等座”，这种组合很灵活，取决于我所需的详细级别。
要因确定之后，便是组合，以表1所列要因为例，二维组合有下列共18种：
| 飞机-晴-白天，飞机-雨-白天，飞机-雪-白天，飞机-晴-夜晚，飞机-雨-夜晚，飞机-雪-夜晚 火车-晴-白天，火车-雨-白天，火车-雪-白天，火车-晴-夜晚，火车-雨-夜晚，火车-雪-夜晚 汽车-晴-白天，汽车-雨-白天，汽车-雪-白天，汽车-晴-夜晚，汽车-雨-夜晚，汽车-雪-夜晚 |
对于表2来说，二维组合则有2*4*2*3*2=96种，貌似有点多，当然你想分析的越详细，那么组合数量自然会相应的增加。
回到表1得出的18种用例，假如我的通过条件是从南京到北京的时间越短越好，在实际的外界环境下（例如晴天，预期花费有限额），这18个用例中，就会出现有的测试通过，有的测试失败的情况了。在不同的实际外界环境下，测试通过的情况还会发生变化（例如下雪天，飞机会发生班次延误）。
