多测师是一家拥有先进的教学理念,强大的师资团队,业内好评甚多的接口自动化测试培训机构!

17727591462

联系电话

您现在所在位置:接口自动化测试培训 > 新闻资讯

QTP使用中的陷阱-自动化测试

更新时间:2022-05-18 09:21:33 作者:多测师 浏览:139

  不要使用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这点。

QTP使用中的陷阱-自动化测试

  不要用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,因为前者会帮助你更快的分析错误。

  以上内容为大家介绍了自动化测试中的QTP使用中的陷阱,本文由多测师亲自撰写,希望对大家有所帮助。了解更多自动化测试相关知识:https://www.aichudan.com/xwzx/

联系电话

17727591462

返回顶部