我为了研究测试思维，曾经同一个被测对象和不同的人结对分别做测试执行（我们做的是探索性测试，实际上还不能称为结对测试，因为只是别人在测试的同时，我在一旁观察），慢慢地，发现一些很有趣的现象。

　　尽管我自己也事先测试了一回，发现了一些bug，对被测对象有了一些了解，不过，我发现，每次我和一个新的人员结对测试时，总是能带给我一些关于被测对象质量的新的信息：比如又发现了一个新的功能，或者又发现了一个新的缺陷。久而久之，每当要开展一次新的结对测试时，我充满了期待：“这次又能发现什么新的我不知道的信息呢？” 我不知道这种状况会持续多久，至少目前为止，对同一个被测对象测试了7、8轮了，仍然不断地有惊喜冒出来，我还没有碰到过一次“测试执行结束了，没有任何新的有价值的信息涌现出来”的情形。

　　我想，在实际项目中，很少有团队会对同一个特性连续测试7、8轮吧，也是说，在实际项目中，我们几乎可以确信，每一轮测试执行都会带来一些新的、有价值的、关于产品质量的信息出来。

　　假设，我上述的这些实验不是采用的探索性测试方法（ET），而是采用脚本化测试方法（ST），事先编写好测试用例，然后依次让7、8个人依据测试用例开展测试，每一轮测试结束后，是否也会带来额外的新的信息呢？我不得而知。不过，我想，当你希望通过测试执行收获更多的新的你所不知道的信息时，ET显然比ST更具有优越性。

　　当然，每一次测试执行带给我的信息，他们的“质量”还是有所不同的。有的信息很重要，比如我知道了“原来用户正常情况下使用这个被测对象还有可能导致程序崩溃掉”，而有的信息不那么重要，比如“在使用这个特性的某个功能时，界面显示的格式有可能不正确”。假如我是测试经理，拿到这些信息，会作出相应的测试策略的调整 －基于风险的测试，不同的信息对后续测试策略的影响程度是不同的。不过，反观实际项目中的测试情况，很多并不是这样。在采用某个正规的项目开发流程时，比如PRINCE2或者CMMI，管理者们一般习惯于在项目的阶段点上（GATE点或者TR评审点）考虑这些质量相关的风险，制定或调整下一个阶段点的测试策略。而在两个阶段点之间，可能有多轮测试执行发生，每一轮测试结束后，管理者们会看看发现了哪些bug，是否有根据这些bug（客观的质量信息）和测试员的感受（主观的质量信息）及时调整下一轮的测试策略呢？是调整测试用例的优先级，调整测试用例执行顺序的优先级？还是，缺陷回归测试完，继续按照原有的计划开展用例的测试，只关注什么时候已经设计的用例可以被执行完？是的，发现的这些bug会被修复、重新测试，但是这些bug带给我们的信息可远不止这些bug本身。应该及时利用bug（客观的质量信息）和测试员的感受（主观的质量信息）这些信息，这些是产品质量相关的风险，是我们开展基于风险测试的很重要的基础。

　　一般而言，比较有经验的人员善于发现一些重要的信息。同样是开展一轮测试的时间，我是安排一个有经验的人去测试，还是安排一个测试新手去测试呢？何时安排什么样的人员？这取决于我的目的以及项目的进展。假如当前已经测试了几轮，我希望再获得一些关于被测对象更多的质量的信息 ，这时安排一个有经验的人比较合适。因为，缺乏经验的测试人员很可能提供的都是你所知道的信息。所以，为了发现更多有价值的信息，后期不易采用测试新手。假如你想对一个测试新手进行辅导，提升其测试技能，那么比较好的方式是，先通过自己测试或者通过让有经验的人测试获得一些信息后，带着这些信息，去观察这个测试新手的测试，看他/她能否发现你已经知道的这些信息、能发现多少你所不知道的信息，通过对比的方式，很容易发现他/她的测试优缺点。所以，为了培养新人的目的，前期不易采用测试新手。

　　有些人发现的bug影响很严重，比如程序的崩溃，但是他是在一系列非常复杂的操作后才触发的。如果我的程序在测试几轮后要交付用户使用，我是不建议优先安排这类异常的测试的 － 因为缺陷发生的可能性很小。而对那些用户经常使用的功能和操作，要优先安排测试、优先探索，尽管缺陷影响不是那么大。所以，考虑测试的优先级时，包括探索性测试的优先级，当你用高、中、低来衡量一个风险的可能性和影响程度时，“可能性为H×影响程度为L”的风险要比“可能性为L×影响程度为H”的风险高些。

　　如果说你是通过测试早期的活动比如review、test design获得一些风险的认识，基于这些风险设计用例，制定测试计划；那么，测试执行开始后，你获得的风险更加真实，要及时地利用这些风险信息，调整你的测试策略－Utilize the information after each test run！