测试用例预演及其优点

           测试用例预演的一般步骤是：测试工程师与开发工程师以某种方式坐在一起，进入交流状态，这个过程中需要尽可能避免干扰，比较好的时机是坐在一起进餐的时候；测试工程师根据测试用例进行提问，甚至可以临时扩展测试用例，但要注意三点：1）。 不要偏离测试用例太远，以免偏离实际的业务；2）。可以考虑一些在测试用例中没有明确写明的异常情况处理；3）。提问的方式是“如果我这么操作，你的系统会如何反应？”；开发工程师根据测试工程师的问题，做出应答，对每个问题都只需要回答系统的响应即可，不需要描述具体的实现方法；测试工程师仔细聆听开发工程师的回答，需要对开发工程师的答复敏锐反应，不放过任何一个开发人员的迟疑，对拿不准的问题应该记录并需要马上验证；双方继续预演直到预期的预演时间结束或是有一方感到疲倦；记录预演过程中发现的问题到缺陷跟踪库。
　
　　当然，要说明的是，参与交流的开发和测试工程师不是比武双方，真正的敌人只有一个：系统的缺陷，这点务必要牢记，以免弄错了对手，伤了和气。
　
　　测试用例预演不是一种复杂的方法，但根据我的经验，要想在实际工作中应用这种方法并取得较好的效果，必须了解这种方法的适用范围，遵循一定的使用方法，并需要注意一定的技巧。这里我以FAQ的方式提供秘笈一部，各位请留意：Q：测试用例预演可以取代测试执行吗？
　
　　A：这个问题是我捏造出来的，我想大概不会有人真的这么认为：），不过在这个问题的回答中，我希望能尽可能准确地描述测试用例预演方法的适用范围：如前面所提到的，测试用例预演是一种“虚拟”的测试用例执行方法，因为主要是通过口头交互的形式，也就限制了该方法适用的深度，一般来说，针对业务逻辑的较为直观的用例可以采用这样的方法，尤其是那些涉及大量用户复杂交互的用例，采用这种方法非常有效，测试工程师模拟用户或是设备提出各种可能的正常异常情况，很容易发现程序处理中的漏洞。但是，对于那些需要涉及大量地层处理的用例，测试工程师一般不太可能对其机制了解得十分清晰，因此采用这种方式也很难发现问题。
　
　　Q：测试用例预演可以在哪些场合下使用？
　
　　A：测试用例预演的应用场合没有特殊要求，但至少要保证是一个适合双人沟通的场合，没有过多的被打扰，双方都处在能积极思考的状态，这样就可以了。根据我的经验，一起就餐、双方暂时没有明确的工作内容，或是在对设计进行非正式评审的时候是一个比较好的时机，但还要充分考虑双方的喜好，譬如，有人不喜欢在吃饭的时候展开讨论。总之，一个适合双人沟通的场合是最低要求。
　
　　Q：测试用例预演方法可以用在其他地方吗？
　
　　A：中子炮刚发明的时候，科学家们狂热地将中子炮对准任何可以找到的东西；按照这种趋势，测试用例预演方法也必须要考虑是否可以应用在其他地方：）实际上，预演这种方法在评审或是思维游戏的过程中一直都是被广泛应用的，测试用例预演只不过将预演这种方法用到了以往需要真正执行的领域中，除了在测试执行环节，设计评审过程中我们也可以采用这种方法针对设计进行审查，关键在于提问的技巧：“如果我们这么做，你的设计将会怎样反应？”。
　
　　Q：好像我用测试用例预演方法很难达到预期的目标？
　
　　A：测试用例预演方法并非不需要前提条件，至少要保证以下条件才能使测试用例预演发挥较大的作用：开发工程师具有良好的配合意识；测试工程师对产品具有良好的熟悉程度；提问者的提问必须从“如果我这样做，程序会怎样反应”开始；参与预演的开发工程师对用于预演的用例涉及的模块要非常熟悉；其中，测试工程师对产品具有良好的熟悉程度是非常必要的，测试用例预演的主要对象是针对业务逻辑的用例，这就要求测试工程师熟悉产品，熟悉业务。所谓“棋逢对手”，

原文转自：http://www.ltesting.net