交叉测试之苹果理论

恭喜发财dife

第一部分：苹果理论

　 　清晨打开冰箱准备拿出牛奶吃早餐，猛然发现冰箱里已经累计有四瓶鲜奶了，这还不包含屋外奶盒中今天新
送到的两瓶。怎样解决？这使我想起了著名的苹果理论 也存在类似的问题。买了一袋苹果，持续数日后，有部分
苹果新鲜程度已经开始有了变化，且开始腐烂。传统的观念似乎是这样的：正确的做法是一直挑没有变质的 苹果
吃，这样的结果的是部分没有变质的苹果被你成功吃掉，另外一部分则彻底坏掉；错误的做法则是一直挑开始变
质的苹果吃，结果则是你一直吃的是变质的苹 果。这两种做法都有不科学的地方，前者成本太高，有一部分苹果
彻底毁掉后扔掉了，后者则对身体有害。那有没有一种办法既能使成本降到最小，又尽可能的避免 对身体的伤害
呢？思考了一下，或许折中是个不错的选择。对苹果的变质程度做升降排序，每次从队列中间部分进行选择。




　　第二部分：交叉测试之苹果理论应用

　　软件测试中 是否存在类似的问题？答案是肯定的。一个测试组中有多名测试员，分别负责对不同模块的测试。
经过多个版本的回归测试后，组员对手中的模块无论从整体到细节 都有了非常深刻的掌握，但这同时也带来人本
质上特性，疲态，即组员慢慢开始对手中模块的测试开始表现出倦意和缺乏兴趣，就如同图1中右边的那个苹果你
所看 到的感觉一样，发现的缺陷也开始呈下降的趋势，如图2所示。




　 　那有办法解决这样的问题吗？是的，可以让组员之间的模块进行交换测试，因为对于测试员自身来讲，别人
手中的模块更具备吸引力，如同图1中的左边那个苹 果，也具有更多未知的领域，从而也能发现更多的缺陷。这
就是传说中的交叉测试方法。那是经过几轮回归后就整体交换测试员手中的模块吗？不，那样带来的成本 太高，
因为采用这种方式，测试员对手中的新模块的完全了解需要花一定长的时间，从而使时间成本提升了。如果你告
诉项目经理，我们当前版本（与刚开始测试的 版本比没有添加额外的模块和功能点）的测试所需要花的时间和系
统刚开始测试的时候是一样的，项目经理肯定会觉得不可思议，因为测试组已经测试过多个回归版 本了，无论从
业务流程到功能点，肯定是熟悉了很多，正确的结果应该是测试的周期时间会慢慢减少啊。如果你告诉项目经理，
我们采用了交叉测试，以此想发现更 多的缺陷，或许在项目进度不是很紧的时候，项目经理会觉得可以接受，
那在进度很紧张的时候，可能就够呛了。

　　如何在有限的项目进度时间内，有效的实施交叉测试呢？本人抛砖引玉地提出三阶段实施法：

项目前期测试阶段：
　　在这一阶段，组内所有测试员对系统的功能和业务流程都没有比较深刻的认知，此时安排不同测试员负责不
同模块的测试。功能点和业务流程测试任务的分配通过测试用例进行。

项目中期测试阶段：
　　将功能点的测试，如外观，单个按钮或控件功能等测试任务通过测试用例分配进行逐步交叉，使得交叉测试
开始逐步推进。此过程中可通过测试用例中的优先级排序来进行逐步交叉，顺序为从低等级到高等级。

项目后期测试阶段：
　　引入业务流程的交叉测试。考虑到业务流程的熟悉和了解相对于功能点测试有一定的难度，特别是对金融
行业来讲。有了第二阶段功能点的熟悉的和了解，业务流程的了解也有了一定基础准备，所以放在项目的后期测
试阶段进行交叉比较合适。

　　第三部分：总结

　　如果你现在所在的项目已经开始实施这样的方法，那么本文只是想通过一个实际生活中的例子引出这样一
些步骤，从而使得体会更加深刻。如果你所在的项目还没有开始实施这样的方法，或许你可以尝试一下。