QTP使用中的陷阱

QTP使用中的陷阱

不要使用Reuable Action

　　用Function，不要用Reusable Action。没有一种通用的语言里有Reusable Action这个概念。而且通过Function等一些标准的程序设计语言的元素，你能够实现任何Reusable Action可以实现的功能，而且更好，更快，更易于维护。

　　以前我还不能肯定这一点。现在我能肯定的告诉你，因为有好几个QTP项目，上千个Testcases在支持我的观点。

　　不要用Smart Identification

　 　有一天，我发现一个奇怪的现象，一个testcase里某一个点击logout button的步骤运行非常慢，大概要20秒，但是最终它还能成功点击。不巧的是每一个testcase几乎都会点击这个button，所有我还必须把这 个问题找出来。最后发现这是因为button的name有了变化，但是因为Smart Identification是被enable，所以QTP会试图去适应这个变化，但是这个“适应”的效果非常不理想。

　　我认为测试开发者应该完全控制对象的识别。把选择权交给对被测程序业务一无所知的工具是毫无道理的。我想不到任何使用SmartIdentification的原因。所以，从那之后，任何Testcase的Smart Identification我都禁止了。

　　不要在base目录里添加两个或以上目录

　　Base目录是用来只能识别相对路径的目录。其配置在Menu: Tools->Options->Folders。我的建议是这里只放项目根目录。其他目录都不要放进去。

　　曾经，我接手了一个QTP项目。开始的时候我根本就不能把哪怕一个testcase成功跑起来。于是我去问起开发者，他告诉我需要把某一个特定的Reusable Action添加到"folders"里面。这种坑是在是让人哭笑不得。

　　QTP作为一种工具，或许需要提供这种灵活性。但我们除非有必要，不要去用它。如果必须要用，也要很好的document这点。

　　不要用keyword view，而是提供业务逻辑封装层

　　如果你要让你的testcase简单，直接，那么你应该通过合理的抽象提供完善的业务逻辑封装层，它会使得你的testcase script读起来像testcase descript一样。这个时候，你根本不需要keyword view。

　　不用Reporter.ReportEvent而用Assert

　 　当执行一个Testcase时候，如果遇到错误，QTP支持两种操作。"stop run"和"proceed to next step"。（注意，其实还有另外两个选项。"pop up message box"是针对开发时使用。"proceed to next action iteration"不常用。所以不讨论。）

　　基本上，QTP鼓励"proceed to next step"这种方式：如果出现了错误，那么记录错误，但testcase仍旧会执行下去。

　　对于QTP检查到的错误是这样，对于测试脚本自己检查到的错误也是如此。QTP提供了一个错误报告机制。

　　Reporter.ReportEvent micFail, stepName, errorMsg

　　这种处理方式违背了一个程序设计的基本原理：如果出现不能处理的错误，那么就抛出错误。通常来说如果出现了错误，执行下去是没有意义的。我猜想 QTP之所以会支持这种方式是因为，如果出现错误马上退出，那么testcase里的负责cleanup的代码就无法执行。想想看JUnit里的 Setup和Teardown机制，在VBS里是无法实现的。

　　即使考虑到这点，这样做还有一个问题，导致我不采用它的原因。那就是不能在batch run的结果报告里显示错误。如果采用"stop run"的方式，那么batch run脚本能够获得导致testcase退出的错误信息。然后在产生report的时候，能够呈现出来。再结合错误时刻的screenshot，实践表 明，大多数错误都能在阅读report的时候确定原因。下面是一个Report里一个失败Testcase的呈现情况。

　　如果使用Reporter.ReportEvent的方式，那么在Report里你看不到任何错误消息，只能在 Result View里面打开result xml。这是一个耗时的操作，因为Result View很慢。大多数时候，你是在等待Result View把测试结果渲染出来。

　　为了更好的支持checkpoint，我在framwork里定义了一套Assert函数，可以对大多数情况下的断 言语义提供直接的支持，比如“相等”，“不等”，“包含”，“匹配”，等。在Assert函数里面，会抛出一个Error。下面是一个从popup窗口读 取信息，然后验证信息是否正确的例子。

AssertMatch GUI_MsgBox_Msg("Information"),_     ".*is invalid or you don't have the permission.", _     "Error message not displayed or correct"

　　如果该Checkpoint失败，那么在HTML report里看到的信息像下面的样子。

AssertMatch: Error message not displayed or correct. Expected<,".*is invalid or you don't have the permission.>, Actual<>

　　总结一下。在错误处理上，采用"stop run"的方式，这也是所有程序设计里采用的方式。在写checkpoint的时候，用Assert而不要用Reporter.ReportEvent，因为前者会帮助你更快的分析错误。

版权声明：本文出自 lifr 的51Testing软件测试博客：http://www.51testing.com/?764

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。