一定不要把qtp神话了，所谓的框架是忽悠人的

heqingbluesky

最讨厌GUI改来该去。

heqingbluesky

原帖由 hsjzfling 于 2009-7-8 11:00 发表


如你所说，QTP自动化的最大作用就在于替代繁杂的重复性劳动。比如有个产品需要在4个不同的操作系统，3种主流浏览器，10个操作流程的组合，15组操作数据的情况下进行测试，自动化的作用就非常明显了。再比如每次发 ...

是的，用QTP主要是在测试软件的功能更改很小，界面更改很小的情况下使用。只能作为手工测试的一个补充。我们公司取消的专职的自动化职位，要求测试组基本都会操作这个软件。

框架的东西仁者见仁，智者见智。

heqingbluesky

原帖由 xiaoyaoke 于 2009-7-9 11:26 发表
首先：我是坚定的站在shanxi的这个阵营的
然后说说我的理解：自动化测试理论上相当于用软件测软件，这里面分为两个层次，如果你是是从产品的层次角度去考虑来写测试脚本，这就说明你基本上是在干研发的活，因为你要 ...

可能你说的框架是为了实现某个C/S或者B/S结构的软件来说的。对于QTP而言，我们要说的框架，业务的逻辑不在框架内实现，是在每个脚本中实现的。只有这样，你框架的通用型才强，不会每个软件一个框架。

heqingbluesky

原帖由 xiaoyaoke 于 2009-7-9 16:30 发表
请问你所说的框架主要包含的功能有哪些?

就是可以让QTP在不同的架构的软件下运行，有入口，输入/输出，错误处理，日志，数据比对等等。

具体业务的实现在不同的case中。不知道这个是否可以称为框架？

heqingbluesky

原帖由 volvoo 于 2009-7-13 20:11 发表
使用 IBM Rational Functional Tester（RFT）测试 Windows 应用程序: 如何构建结构良好的测试框架  

  文档选项
  打印本页

   将此页作为电子邮件发送




级别： 中级

陈 昱旻, 测试工程师,  ...

是的，框架就是这些东西了，我们公司的也有自定义的testresult,不需要qtp自带的。我们也有error handling,自己写的，我们也有自己的log日志，可以轻易知道脚本运行时候的错误。

框架就是这样一种东西而已，没有什么过多的api定义，重载，继承..........................，过于复杂的东西你也不想用，也不愿意去弄，毕竟qtp是一个回归测试工具而已。