QTP使用中的陷阱

上一篇 / 下一篇  2012-09-12 09:08:06 / 个人分类：QTP

查看( 691 ) / 评论( 0 ) / 评分( 0 / 0 )
51Testing软件测试网Z IW7y7D

　　不要使用Reuable Action

3fBL V3An8L0

5[._ p5D5^#r V+l0　　用Function，不要用Reusable Action。没有一种通用的语言里有Reusable Action这个概念。而且通过Function等一些标准的程序设计语言的元素，你能够实现任何Reusable Action可以实现的功能，而且更好，更快，更易于维护。51Testing软件测试网~ C\3\Yw

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

.vF Qr I8vC051Testing软件测试网1JoQ]fp

　　不要用Smart Identification51Testing软件测试网5odD}9L#y

51Testing软件测试网$c@ @%kj9L

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

51Testing软件测试网iNe:yc8r5d6U^+YTL

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

q4x*`O\A,o g051Testing软件测试网/c9_T7fi

　　不要在base目录里添加两个或以上目录51Testing软件测试网Ofbq2_n5ZP!e

g ^4Y"pI\0　　Base目录是用来只能识别相对路径的目录。其配置在Menu: Tools->Options->Folders。我的建议是这里只放项目根目录。其他目录都不要放进去。51Testing软件测试网Ig[ A!F@

51Testing软件测试网C aZ$Xk

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

1ZwZ6B5JW#v+S051Testing软件测试网V c^TLF

　　QTP作为一种工具，或许需要提供这种灵活性。但我们除非有必要，不要去用它。如果必须要用，也要很好的document这点。51Testing软件测试网'cn7C GO

!H'zB-mTPf0　　不要用keyword view，而是提供业务逻辑封装层

&u8}"xF:kI0

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

R0m%@ ^R gB4ja0

8A(H+TW^0w r0　　不用Reporter.ReportEvent而用Assert51Testing软件测试网|V1aj)~+Jd,i

51Testing软件测试网 E]Kphk1`p

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

51Testing软件测试网T#O c(r:N&^kY

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

*o,{PIi0

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

)i4u1rZ/K0

n6Y|7F2T"o0　　Reporter.ReportEvent micFail, stepName, errorMsg51Testing软件测试网q)i6p i#e wP

51Testing软件测试网~\ coU"llF

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

51Testing软件测试网N"i8Zf2yx u{n3t

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

j S Gyo+p0

c5] k5o?x Is0

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

B;D:N-SY4O0

　　为了更好的支持checkpoint，我在framwork里定义了一套Assert函数，可以对大多数情况下的断 言语义提供直接的支持，比如“相等”，“不等”，“包含”，“匹配”，等。在Assert函数里面，会抛出一个Error。下面是一个从popup窗口读 取信息，然后验证信息是否正确的例子。51Testing软件测试网:E@0q&C6|nz ^:@3m

51Testing软件测试网~Ne.n!rZ2s.ZB

51Testing软件测试网SQ2uS:v$J1}#g"n

AssertMatch GUI_MsgBox_Msg("Information"),_51Testing软件测试网-C\~,GfW.A9Q

@1W.u XwA(w2mt0    ".*is invalid or you don't have the permission.", _51Testing软件测试网9ox ^8m W

Y7O,R0B1zU @O0    "Error message not displayed or correct"

\!Q(A"V vEQ!G0

　　如果该Checkpoint失败，那么在HTML report里看到的信息像下面的样子。51Testing软件测试网'm-Ak6Z1F6X6Ju6NU%t

51Testing软件测试网t-}Bn0tb

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

　　总结一下。在错误处理上，采用"stop run"的方式，这也是所有程序设计里采用的方式。在写checkpoint的时候，用Assert而不要用Reporter.ReportEvent，因为前者会帮助你更快的分析错误。51Testing软件测试网,M;jS${"ajP

版权声明：本文出自 lifr 的51Testing软件测试博客：http://www.51testing.com/?76451Testing软件测试网0[Y/}:U%][P:\kPJ


收藏 举报

TAG:

 

评分：0

我来说两句

Open Toolbar