摘要：高手过招，手中无需用剑，只要轻描淡写地以口代手，三两句话便高下立判，胜者胜得痛快，输者也输得潇洒。然而，除了在武侠小说之内，恐怕很难有地方让你感受到这种“会当凌绝顶”的痛快。本文根据作者在测试工作中的体会，提出了一种被称为“测试用例预演”的方法，用模拟的测试用例执行发现程序中潜在的问题，这种方法究竟有何神奇呢?请见内文。

　　武侠小说中的高手大抵有三个层次，第一个级别是“静若处子，动如脱兔，身负成名绝技”的高手，印象中这一个级别的基本是杀手或是性情豪爽的江湖侠客，这种人一旦遇到，打杀的场面为宏伟，刀枪之声不绝，各出奇招，直到一方倒地或是被制;第二个级别是“落叶飞花，片叶支花均可伤人”的高手，这个级别的高手相遇，少了宏伟的场面，却在看似不经意的凝重中展开残酷的厮杀，胜负只在一念之间;第三个级别的高手寥寥无几，多是成名已久、文武双修的名宿，已至“手中无刀，心中无刀”的高境界，这种高手若是过招，全不闻金戈之声，全无杀伐之意，轻描淡写的以口代手，三两句话便高下立判，赢的赢得痛快，输的输得潇洒，在武侠中看到此，常不免心潮澎湃，艳羡不已，巴不得自己也能有这个机会一尝绝顶高手之间的这种至高默契。可惜身为开发或是测试工程师，又出生在这个真实的世界，恐怕实在是不太会有机会领会这种至高的境界。

　　所幸，我们虽不能飞进武侠小说尝试这种生活，却能在我们的测试工作中体会到这种乐趣。真耶?假耶?且与我一起，探究个究竟。

　　回到我们的题目“高手过招的乐趣 ?? 测试用例预演”，这里我要提出的是一种可以让你体会到高手过招乐趣的方法：“测试用例预演”。且慢试图在头脑中搜索你对这种方法的印象，因为这是我自创的名词(申明：如果很不幸你通过其他途径确实听到或是见过这种描述，请一定告知本人，本人会慎重考虑，至少到目前为止，我还能有把握地说这是我首先命名和以正式文档描述的一种方法)。之所以把这种算不上十分复杂的方法写下来，是因为本人在实际的工作中发现该方法确实能起到比较大的作用，而且更重要的是，那种高手过招的感觉，很希望能和更多有高手梦的朋友能够感受得到。

　　测试用例预演是一种非正式的测试用例执行方法，概括说来，这种方法是无需通过测试用例的真正执行(静态或是动态执行)，而只需要开发人员和测试人员之间的口头交流，能发现被测系统中存在的问题。设想一下，无需动手(测试执行)，通过以口代手(开发和测试人员之间的口头交流)，能实现我们的目标(发现缺陷)，这不是高手过招是什么?

　　测试用例预演的一般步骤是：

　　测试工程师与开发工程师以某种方式坐在一起，进入交流状态，这个过程中需要尽可能避免干扰，比较好的时机是坐在一起进餐的时候;

　　测试工程师根据测试用例进行提问，甚至可以临时扩展测试用例，但要注意三点：

　　1). 不要偏离测试用例太远，以免偏离实际的业务;

　　2).可以考虑一些在测试用例中没有明确写明的异常情况处理;

　　3).提问的方式是“如果我这么操作，你的系统会如何反应?”;

　　开发工程师根据测试工程师的问题，做出应答，对每个问题都只需要回答系统的响应即可，不需要描述具体的实现方法;

　　测试工程师仔细聆听开发工程师的回答，需要对开发工程师的答复敏锐反应，不放过任何一个开发人员的迟疑，对拿不准的问题应该记录并需要马上验证;

　　双方继续预演直到预期的预演时间结束或是有一方感到疲倦;

　　记录预演过程中发现的问题到缺陷跟踪库。

　　当然，要说明的是，参与交流的开发和测试工程师不是比武双方，真正的敌人只有一个：系统的缺陷，这点务必要牢记，以免弄错了对手，伤了和气。

　　测试用例预演不是一种复杂的方法，但根据我的经验，要想在实际工作中应用这种方法并取得较好的效果，必须了解这种方法的适用范围，遵循一定的使用方法，并需要注意一定的技巧。这里我以FAQ的方式提供秘笈一部，各位请留意：

　　Q：测试用例预演可以取代测试执行吗?

　　A：这个问题是我捏造出来的，我想大概不会有人真的这么认为：)，不过在这个问题的回答中，我希望能尽可能准确地描述测试用例预演方法的适用范围：如前面所提到的，测试用例预演是一种“虚拟”的测试用例执行方法，因为主要是通过口头交互的形式，也限制了该方法适用的深度，一般来说，针对业务逻辑的较为直观的用例可以采用这样的方法，尤其是那些涉及大量用户复杂交互的用例，采用这种方法非常有效，测试工程师模拟用户或是设备提出各种可能的正常异常情况，很容易发现程序处理中的漏洞。但是，对于那些需要涉及大量地层处理的用例，测试工程师一般不太可能对其机制了解得十分清晰，因此采用这种方式也很难发现问题。

　　Q：测试用例预演可以在哪些场合下使用?

　　A：测试用例预演的应用场合没有特殊要求，但至少要保证是一个适合双人沟通的场合，没有过多的被打扰，双方都处在能积极思考的状态，这样可以了。根据我的经验，一起餐、双方暂时没有明确的工作内容，或是在对设计进行非正式评审的时候是一个比较好的时机，但还要充分考虑双方的喜好，譬如，有人不喜欢在吃饭的时候展开讨论。总之，一个适合双人沟通的场合是低要求。

　　Q：测试用例预演方法可以用在其他地方吗?

　　A：中子炮刚发明的时候，科学家们狂热地将中子炮对准任何可以找到的东西;按照这种趋势，测试用例预演方法也必须要考虑是否可以应用在其他地方：)实际上，预演这种方法在评审或是思维游戏的过程中一直都是被广泛应用的，测试用例预演只不过将预演这种方法用到了以往需要真正执行的领域中，除了在测试执行环节，设计评审过程中我们也可以采用这种方法针对设计进行审查，关键在于提问的技巧：“如果我们这么做，你的设计将会怎样反应?”。

　　Q：好像我用测试用例预演方法很难达到预期的目标?

　　A：测试用例预演方法并非不需要前提条件，至少要保证以下条件才能使测试用例预演发挥较大的作用：

　　开发工程师具有良好的配合意识;

　　测试工程师对产品具有良好的熟悉程度;

　　提问者的提问必须从“如果我这样做，程序会怎样反应”开始;

　　参与预演的开发工程师对用于预演的用例涉及的模块要非常熟悉;

　　其中，测试工程师对产品具有良好的熟悉程度是非常必要的，测试用例预演的主要对象是针对业务逻辑的用例，这要求测试工程师熟悉产品，熟悉业务。所谓“棋逢对手”，至少要能和开发工程师是一个级别上的。另外，参与预演的开发工程师必须对用于预演的用例涉及的模块很熟悉，如果参与预演的开发工程师是模块的开发者自然没有问题，如果不是，要求开发工程师必须能够准确了解模块的行为和实现。

　　Q：测试用例预演发现的问题需要记入缺陷库吗?

　　A：答案是肯定的，测试用例预演是一种“虚拟”的测试执行，预演过程中发现的问题同样要被记录、跟踪。当然，为了标识测试用例的发现阶段，可以专门在缺陷管理系统中增设一个“预演”阶段，统计预演在缺陷发现方面提供的效果。

　　Q：如果开发人员不配合，怎么办?

　　A：这个问题……我只能说具体问题具体分析了。关键是弄清楚开发人员为什么不配合，可能是开发人员个性羞涩，不喜欢这样面对面的交流方式;也可能是开发人员觉得这种方式浪费时间;又或者是开发人员对测试人员抱有不信任的态度。不管怎样，发挥你的个人所长，让开发人员放下顾虑和成见，认识到这种做法能给他和项目带来的好处，自然可以解决这个问题。

　　Q：还有哪些在测试用例预演过程中应该主要的问题?

　　A：当然还有一些需要注意的问题，沟通的技巧、对对方反馈的及时分析等等，这些都可以在实际运用测试用例预演方法的过程中逐渐体会。我总结的几点需要注意的问题包括：
　　对每一个开发人员的犹豫都不能放过，一个犹豫很可能是一个缺陷隐藏的地方;

　　如果可能，好能和开发人员一起，确定那些不确定的问题，以防开发人员一时马虎放过了本来存在的问题;

　　预演的方式不适合在正式评审会议上应用，因为预演主要是两个人之间的协同思考，在正式评审会议上容易浪费其他人的时间;

　　预演时要注意记录，头脑风暴产生的火花如果不及时记录的话，很可能会在短时间后被遗忘。