武侠小说中的高手大抵有三个层次，第一个级别是“静若处子，动如脱兔，身负成名绝技”的高手，印象中这一个级别的基本是杀手或是性情豪爽的江湖侠客，这种人一旦遇到，打杀的场面最为宏伟，刀枪之声不绝，各出奇招，直到一方倒地或是被制；第二个级别是“落叶飞花，片叶支花均可伤人”的高手，这个级别的高手相遇，少了宏伟的场面，却在看似不经意的凝重中展开残酷的厮杀，胜负只在一念之间；第三个级别的高手寥寥无几，多是成名已久、文武双修的名宿，已至“手中无刀，心中无刀”的最高境界，这种高手若是过招，全不闻金戈之声，全无杀伐之意，轻描淡写的以口代手，三两句话便高下立判，赢的赢得痛快，输的输得潇洒，在武侠中看到此，常不免心潮澎湃，艳羡不已，巴不得自己也能有这个机会一尝绝顶高手之间的这种至高默契。可惜身为开发或是测试工程师，又出生在这个真实的世界，恐怕实在是不太会有机会领会这种至高的境界。
所幸，我们虽不能飞进武侠小说尝试这种生活，却能在我们的测试工作中体会到这种乐趣。真耶？假耶？且与我一起，探究个究竟。
回到我们的题目“高手过招的乐趣 —— 测试用例预演”，这里我要提出的是一种可以让你体会到高手过招乐趣的方法：“测试用例预演”。且慢试图在头脑中搜索你对这种方法的印象，因为这是我自创的名词（申明：如果很不幸你通过其他途径确实听到或是见过这种描述，请一定告知本人，本人会慎重考虑，至少到目前为止，我还能有把握地说这是我首先命名和以正式文档描述的一种方法）。之所以把这种算不上十分复杂的方法写下来，是因为本人在实际的工作中发现该方法确实能起到比较大的作用，而且更重要的是，那种高手过招的感觉，很希望能和更多有高手梦的朋友能够感受得到。
测试用例预演是一种非正式的测试用例执行方法，概括说来，这种方法是无需通过测试用例的真正执行（静态或是动态执行），而只需要开发人员和测试人员之间的口头交流，就能发现被测系统中存在的问题。设想一下，无需动手（测试执行），通过以口代手（开发和测试人员之间的口头交流），就能实现我们的目标（发现缺陷），这不是高手过招是什么？
l 测试用例预演的一般步骤是：
测试工程师与开发工程师以某种方式坐在一起，进入交流状态，这个过程中需要尽可能避免干扰，比较好的时机是坐在一起进餐的时候；
测试工程师根据测试用例进行提问，甚至可以临时扩展测试用例，但要注意三点：
1). 不要偏离测试用例太远，以免偏离实际的业务；
2).可以考虑一些在测试用例中没有明确写明的异常情况处理；
3).提问的方式是“如果我这么操作，你的系统会如何反应？”；
开发工程师根据测试工程师的问题，做出应答，对每个问题都只需要回答系统的响应即可，不需要描述具体的实现方法；
测试工程师仔细聆听开发工程师的回答，需要对开发工程师的答复敏锐反应，不放过任何一个开发人员的迟疑，对拿不准的问题应该记录并需要马上验证；
双方继续预演直到预期的预演时间结束或是有一方感到疲倦；
记录预演过程中发现的问题到缺陷跟踪库。
当然，要说明的是，参与交流的开发和测试工程师不是比武双方，真正的敌人只有一个：系统的缺陷，这点务必要牢记，以免弄错了对手，伤了和气。
测试用例预演不是一种复杂的方法，但根据我的经验，要想在实际工作中应用这种方法并取得较好的效果，必须了解这种方法的适用范围，遵循一定的使用方法，并需要注意一定的技巧。这里我以FAQ的方式提供秘笈一部，各位请留意：
Q：测试用例预演可以取代测试执行吗？
A：这个问题是我捏造出来的，我想大概不会有人真的这么认为：），不过在这个问题的回答中，我希望能尽可能准确地描述测试用例预演方法的适用范围：如前面所提到的，测试用例预演是一种“虚拟”的测试用例执行方法，因为主要是通过口头交互的形式，也就限制了该方法适用的深度，一般来说，针对业务逻辑的较为直观的用例可以采用这样的方法，尤其是那些涉及大量用户复杂交互的用例，采用这种方法非常有效，测试工程师模拟用户或是设备提出各种可能的正常异常情况，很容易发现程序处理中的漏洞。但是，对于那些需要涉及大量地层处理的用例，测试工程师一般不太可能对其机制了解得十分清晰，因此采用这种方式也很难发现问题。
