Finger 说明：其实这次测试的性质很模糊。我自己把它当做是一次用户体验的实践。但是，一来这个测试方案本身的出发点还是要获得软件兼容性测试数据，测试的时间又 非常紧迫，二来我自己也很清楚软件工程和可用性工程的方法差异巨大，因此在本文中采用新方法的唯一目的是满足实际情况需要，并不代表哪种方法更好。

软件兼容性测试：不可能完成的任务？

前天被头儿叫过去开会，要求我们UE组两个人对公司一款产品的软件兼容性测试方法重新评估。事件起因是这样的：

产品部领导想要了解我们产品（下面都用A产品指代）和其他产品（分别是B、C、D、E、F、G、H）对某主流软件的兼容性，于是公司需求组的同事制 订了一 份详细功能点列表，总数大约是1000多项，交给测试部门。可怜的测试工程师们，他们一看就傻眼了：1000多项功能点，乘以7个产品，这就是7000多 次测试了。再加上，测试工程师们有他们自己的测试方法，他会根据你列出的功能点，编制出对应的测试用例。比方说，你告诉测试工程师我要测知道软件是否能正 常显示段间距，那么测试工程师就是编出1倍、2倍、10倍甚至317.8倍行距这样奇怪的数值，以确保是否正常显示。但是这样一来，从功能点到测试案例， 要测试的次数呈几何级数爆炸式增长了。进行到这个份上，软件兼容性似乎变成了不可能完成的任务。最后这个光荣的任务就落到了UE小组的头上，于是一段传奇 经历就此展开。

敌情侦察

孙子曰：“知己知彼，百战不殆。”我们打算先把当前的战场情况搞清楚。我们找到了需求组的同事，向她们详细了解为何要进行这项测试以及期望的输出物是什么，最后得到了这样一张战场态势图。

战棋推演

根据目前掌握的情况，我们迅速制订了这次的作战目标：       
1) 快速有效地获得A产品与其他几款软件对某著名软件兼容程度的比较数据
2) 获得软件各组件用户使用权重的客观数据
3) 确定一套可重复执行的方法论，反映软件产品的兼容性

作战目标一旦明确，我们就开始制订具体的作战计划。我们的思路很明确，既然是一套可重复执行的方法论，那么它的数据收集一定是客观的（可测量的定量 数 据），它的处理方法也是自动化的。换句话说，在传统软件兼容性测试中靠人工逐一排查问题的方法将在本次测试中被无情抛弃。那么可行的方法是什么呢？

首先确定测量指标，这个指标必须是客观、简单、并且可重复测量。我们首先想到的是对某个任务是否通过做二项判断：通过或者不通过。要知道之前我们是要求测试工程师们对每个功能点的兼容性做从1—5的打分的，这中间就掺杂了很大的主观性。做二项判断后，工程师的判断难度是降低了，但是又一个问题来了：如果一个功能点上有3个测试用例通过，5个没通过，该给1分还是0分呢？A作战计划失败！

于是我们又想到：计算单个功能点的通过率。这下总没有问题了吧？包三哥曰：非也非也。计算出通过率后，暮然回首，我发现自己完全被大大小小通字辈给包围了，大通（测试用例较多的功能点）和小通（测试用例较少的功能点）完全没有可比性（因为分母不同）。B作战计划失败！

没办法，只有启动我们的C作战计划了。这时候我们突然想到：既然Google可以用PageRank一项指标来反映网页的流行程度，我们为什么不找一个合适的指标呢？我的脑海中这时灵光一闪：任务时间和鼠标点击次数。我的假设是这样的：
产品对该著名软件的兼容性反映在用其他软件打开后内容显示的相似程度（Ho）
由此又得出一个扩展推论是：
兼容性差的软件，用户打开后需要较多的步骤才能达到著名软件的显示效果（H1）

因此我们的实验任务就很简单了：随机找到100篇测试材料（或者你可以自己制作），先用该著名软件打开，然后在依次用待测试软件打开，要求用户判断二者显示是否相同，如果不同则手动调到相同，任务即算完成。由H1我们可以反推：当用户操作时间过长并且鼠标点击次数过多（这些数据都可以通过相关软件实时获得）时，反映出软件兼容性较差。并且，由于我的测试指标都是可测量的客观指标，可以进行统计推断，这就保证了我可以用较少的样本推论较大总体的情况，从而节省了时间。

我为自己天才的想法而沾沾自喜，下午跟头讨论的时候似乎底气也足了写，胜利就在眼前了。然而不幸的是，头对我这种想法并不认可，他需要的仍然是逐项 排查并 且得出每个功能点的具体情况的汇总表。正好测试部门同事说大部分测试案例已经排查完了。于是，事情又回到了它最初的原点，按原计划测完所有功能点。C计划彻底失败！

作战总结
我不是很了解软件工程的测试流程，但是我的出发点是想找到一种简便、快捷并且抽样的自动化算法代替传统的排查法。这次实践虽然失败了，但是我会继续探索下去。希望计算机专业和其他专业背景的朋友看的本文后不要吝啬发表你的高见。

打印  |  相关话题：测试评估   |  类别：设计思想  |  源地址