交叉测试之苹果理论

Posted 2020-06-09

　第一部分：苹果理论

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

图1 优劣苹果

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

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

图2 发现缺陷数和回归次数的关系

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

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

• 项目前期测试阶段：

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

• 项目中期测试阶段：

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

• 项目后期测试阶段：

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

　　第三部分：总结

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

转载：http://www.51testing.com/html/81/n-210181.html