2012年给力新作《精通QTP——自动化测试技术领航》试读以及答疑专用贴

黑羽祭

初读了前100页，感觉很不错，没有以前技术类书籍的那种生硬感觉，很生动，有些地方作者写的很幽默，很能引起读者兴趣啊。
很值得一看的一本书。

yujie6832

楼主 建议如果书中再讲点QTP对flash的自动化测试就好了
haihai1005 发表于 2012-1-18 13:53

    如果有可能的话，在第2版中去增加，但是其实，只要有对应的插件，做flash也不难，只要你学会了本书中主讲的web插件，都是通的

yujie6832

Window("Microsoft Internet Explorer").WinObject("Internet Explorer_Server").Click 901,360
Window("M ...
317759580 发表于 2012-1-18 14:27

    这个原因就太多啦，既然是B/S录制，为什么会识别为win object，你需要重新加载插件，先启动QTP，在打开所要的网页，这个在书中也有详细介绍，还有哦，本贴只是用来回答有关书籍的相关的，谢谢

yujie6832

初读了前100页，感觉很不错，没有以前技术类书籍的那种生硬感觉，很生动，有些地方作者写的很幽默，很能引起 ...
黑羽祭 发表于 2012-1-18 17:57

    有人懂的感觉真好呀~

yujie6832

一定要看
jxm1220 发表于 2012-1-18 16:49

    目前在线销售平台貌似所有书都售罄了，你可以先看51testing的连载，我还是放了很多精彩章节上去的，没有藏着，噎着

snakeshiy

拿到书有一个多星期了，先通读了一遍，感觉两位作者真是非常用心！前半部分生动有趣，引人入胜；后半部分深入浅出，推陈出新，上升到模式设计和框架的高度。这本书目前在国内QTP的书里面应该算首屈一指了，现在还在细读中，有问题再来这里问哦~

yujie6832

拿到书有一个多星期了，先通读了一遍，感觉两位作者真是非常用心！前半部分生动有趣，引人入胜；后半部分深 ...
snakeshiy 发表于 2012-1-20 14:53

    非常感谢，同时也希望能在购书网站写一下评论哦~

archonwang

晕。。。。
看样子来得太晚了，这本书在国内来讲还是很少有的。感谢作者。

zzxxbb112

拿到书有一个多星期了，先通读了一遍，感觉两位作者真是非常用心！前半部分生动有趣，引人入胜；后半部分深 ...
snakeshiy 发表于 2012-1-20 14:53

    别忘记上你购买的网站上给予评论哦。好的坏的我们都接受。

xinxinxingxing

在亚马逊购到了我们的书。刚刚提交了评论~
没有传统教材的说教，语言生动幽默。作者们真心把经验分享给大家，每字每句都可以感受到诚挚。
虽不称完美，实是QTP最深入实用书籍。只是看了部分章节，却按耐不住感谢的情感。
期待深入阅读的过程中，有机会能得到两位作者的解惑。也更希望两位能够有更多杰出的作品，
给我们后辈们一盏明灯。
另外对作者们自身学习QTP的经历也颇感兴趣。如果有作者个人经历的分享，
除了知道如何做是正确的之外，还能了解如何避免学习还有做项目时候的弯路。
也许对大家有颇有借鉴意义.

yujie6832

在亚马逊购到了我们的书。刚刚提交了评论~
没有传统教材的说教，语言生动幽默。作者们真心把经验分享给大家 ...
xinxinxingxing 发表于 2012-1-21 10:20

    非常感谢你的肯定，所有书内的问题，可以发在这个帖子里，或者我的博客里，或者小赵的网站里，这些算是应有的售后服务。这是我们的第一本书，虽然已经竭尽全力，但是难免有很多疏忽，你的建议我们已经收到了，有机会发第2版的时候一定会更加好~

s_spume

以前学习QTP，基本都是通过F1，或者直接查看help中的文档来学习的。一直很希望有一本书可以系统的介绍QTP，关键是有实战经验，更关键是中文的。 哈哈哈。。

刚开始读连载，很开心，有这样一本让我很愿意读，也能读进去的书问世。看到第六节，发现一个小小的问题，见附件图片所示。

yujie6832

回复 57# s_spume
一个bug，呵呵，感谢你的提出

hankliu520

框架一章内容观后感想和疑问。今天上班第一天刚看完，以下内容不知道说的对不对。
一、框架是基于excel，用macros编写了一套GUI界面，进行主控操作。
包括但不限于（编写测试用例，转化测试脚本，执行测试脚本，其中也包括加载场景恢复，函数库，环境变量，生成测试报告，报表等内容）
对excel 宏了解不深，所以看这章确实有很多东西比较费劲，不过思想还是互通的，有了一个基本的概念认识。
一个基于关键字驱动形式的框架。
不过框架背后的代码量还是很可观的，我用C#弄得比这个简单很多的还写了很多很多代码。。
也让我认识到excel如此强大，还能开发一套GUI框架。
如果还有机会从头开发框架，可以按照书中的框架思想写一个C#版的，个人excel 宏方面太弱。
二、下面问几个个人疑问。
1、OR文件tsr用版本控制工具，比如TFS，SVN等管理，当团队共同协作时，分别进行各自的开发，最后交给总控自动化工程师进行merge，在提交版本管理器中。
和采用ORAOM形式相比各自优缺点是什么？这里假设没有采用QC工具，单纯的只拥有QTP情况下。
2、测试报表如果采用reporting service形式如何？测试结果按照日期存入数据库中，生成报表，便于历史性的查阅和比较。因为可以用sql语句进行各种条件的查询。
虽然我也采用的excel的报表，直观，简单，错误地方直接点击结果链接即可。
3、测试结果用html报告（优点体积非常小）如果一个脚本执行步骤非常多，因为有些业务逻辑确实有点复杂，尤其检查点特别多，所有数据都需要验证比对。这时html结果文件查阅错误位置是不是会显得不太方便？
要在滚动条中去查找红色fail的地方。不知道这个html文件是一条测试用例对应一个还是只有一个总的html结果文件，如果一对一的话，html文件会非常多。
到时针对失败的case是用excel报表的链接去查阅结果，还是分别打开失败case的html呢？
4、场景恢复代码是否可以给出，以前也用过自带的场景恢复，可能写的不是很好，所以不是很好用。后来才在自身框架中采用C#后台线程去监控结果文件夹大小，每5分钟检测一次，如果文件结果没有增大，且没有执行完毕
会自动杀掉qtp进程，继续执行下一条case内容。不知道和这种相比哪个更好些？
5、关于公共函数内容。想问一下可不可以直接都用注册函数呢，就是比如set行为，直接注册一个行为 函数，在该函数中加入report内容，记录执行情况方便后期出错查阅，
为什么又要用oSet呢？是因为可以自己选择是否需要使用行为函数吗？就是是否需要对该行为进行监控。
精华地方，测试用例转为脚本确实没弄过，还是不提问了。。

以上几点望解答。由于读的有点快，可能有些地方描述有误，请指证。
谢谢！
4、

hotivy

这书要不要这么火啊~

zzxxbb112

框架一章内容观后感想和疑问。今天上班第一天刚看完，以下内容不知道说的对不对。
一、框架是基于excel，用 ...
hankliu520 发表于 2012-1-29 17:20

问题1：ORAOM在框架里的作用主要是用脚本自动转化TSR为XML形式的对象库文件，对于版本控制，我觉得还是要像你说的交给总控工程师来进行merge。

问题2：这是一个很好的建议，历史数据查询还是非常重要的。

问题3：这个问题其实我倒觉得不是问题，因为如果出现fail的情况，都会有标红，很容易就能在页面里找到。不过如果觉得麻烦我觉得倒可以在html开头加上链接自动定位（这个是纯HTML知识了）。
HTML结果文件都是一个case对应一个html结果文件的，这个多少是跟着case走的，都是通过excel报表的链接点进去查看的。

问题4：场景恢复脚本不是我给你的，他是根据不同的项目进行定制。因为对象都是不一样的。你可以参见本书的场景恢复章节。你说的自动杀掉QTP进程继续之星下一条case，在框架里是有的，当用例执行fail后会自动停止当前case，自动执行下一条case。

问题5：框架本身就已经支持注册行为函数，书里讲到过，oSet就是Set方法的所指向注册函数名。只是为了区分名称所以前面加了o，常用方法里都已经加入了report内容，对于测试人员自行注册需要自己加入report。

本书框架章节主要还是希望能够通过展示这样一个实例来让大家对框架的思想有这样一个认识以及如何来通过这样一个思想来定制一套属于自己的框架，因此书中主要还是抓住了精华和重要的部分，一些比较细节上的内容可能会忽略，有说的不对的地方也请谅解。后续我会把此框架的源代码以及程序发布出来供大家下载学习。

sean007

感谢分享

hankliu520

这两天私事没上班出门了，才看到答复，很感谢给出的解答，已经比较清晰了。
刚又想到两个问题，还想在问一下：
1、关于ROI方面内容，书中貌似没有，不知道做过没或者有没有示例，刚开始做这方面，想有个参考，比较并补充一下自己的。
先给出我自己现有的，ROI=(C1*X-(C2+C3*X))/(C2+C3*X) X代表回归或者执行次数，C1，手工执行时间，c2，开发脚本时间，c3，维护脚本时间。
2、关于检查点方面内容，书中也没有专门涉及，因为每个项目的业务情况和实现方式确实不同，确实很难写。
这个有点啰嗦，我觉得自动化脚本中，功能代码量相对于检查点代码量还是有点少，可能我这里涉及的业务逻辑太复杂，导致检查点代码量非常多。
我一直也没想到一个好的方法来处理这方面，能更有效维护脚本。
我现在的所有checkpoint都是期望值放在datatable中的一个专门的checkpoint sheet中，纯动态的，
比如一个订单流程，当预订时，把一些预定方面的信息比如单价，数量，总价，类型，日期，会员等放入checkpoint sheet中作为期望值。
后面进行付款，或者查询订单，账务处理时，会进行getroproperty方式获取当前页面信息与该checkpoint sheet已存入的期望值进行比对，验证是否信息正确。
目前的实现方式是硬编码写在脚本中的。
但是感觉到如果脚本量太大的话，可能该方式在页面修改变动时会带来维护成本。
之前也和其他人讨论过，结果如下。
以下说的都是检查点方面内容，不涉及功能点脚本（功能点业务目前采用的是封装成独立的function。脚本直接调用即可，维护很方便。）
1、想用call exist action方式进行业务组件拆分，把相应的checkpoint放入各自的业务组件中，并进行调用，但是这样可能会带来一个业务组件逻辑非常非常复杂。
最后耦合性太高，也会给维护带来不便。
2、call copy action方式，也是目前正在采用的方式，好处是，每个脚本中可以进行自己的逻辑判断，坏处是，一旦页面某一个控件移除，可能会需要更改多个涉及到的脚本。
3、检查点也封装成function，传入dictionary参数，根据判断是否为空，来进行检查点比对，但是由于期望值是存入datatable中的，会导致比对时，datatable中的列名必须写死，
写脚本的人在命名datatable的列名时，必须与function中的列名一样才可以，会有一定的局限性。

其他的好的方式，暂时也没有想到，请问针对我的这种情况，有没有什么其他更好的解决方案。
来降低检查点的维护工作。
不知道我的描述清晰不，有哪边描述有问题，请指出，只想能找到一个更好的方案。
十分感谢。

yujie6832

问题1：其实ROI的东西我之前有考虑过要写，但是写出来我觉得真的只是一堆数据，没啥意义！其实投资回报率（Return On Investment）这东西怎么说呢，说实话，我真的没算过这些东西，也许很多时候，领导问我做自动化合算不合算的时候，我第一时间考虑的不是套公式，也从没写出一个公式出来过，我考虑的更多的是：做自动化能给我们带来什么？我不会去算ROI，因为我觉得即使有精确的数据，但是它一定能完全反应情况吗？我个人觉得不可以！再说这种东西留给老板去算，他们更加精通这些东西。举个最简单的例子，老板会问你，我们现在有一个设备要做可靠性测试，7X24小时的去跑，每天至少曝光500次等等（不是做性能测试哦，真的不是），你要不加班做下？那我当然不愿意啊，我肯定还是会让QTP去完成这些工作，然后尽快地抽时间把这个脚本写出来，花多少时间？其实我自己也只是大致心里有数，反正在一个drop，也就是规定的时间内完成就行了，我是每个月拿工资的，所以我只要按时完成任务就可以了。其实，说了那么多，我想得出个结论，我不善于算ROI，哈哈哈~不过以前不是一直传说一句话，一个公式，如果将来的回归测试次数将达到X次，就有自动化测试的意义了吗？通常情况，X至少等于10以上吧，我觉得，其实这个我已经在书里写到过了。^_^

问题2：其实你已经考虑了很多了，我也是在学习的，刚才看了你的描述，我个人建议你采取第3种，规范列名真的比前面2种简单的多，前面2种做到后来很“危险”的，每个项目情况都不一样，不过有一点，我觉得大多数项目，检查点的代码量的确是大于功能点的，不过我以前做的项目，并没有把检查点搞的那么复杂，我的脚本都比较独立的，功能都尽量独立开来，然后检查点应该就不会需要复用了，或者即使有复用，不会那么的多，多到难以维护，不知道我有没有描述清楚。

hankliu520

ROI是有点公式化，偶也不想弄，没办法，领导要搞，硬着头皮上了。
书里是提到过的，版本变更次数或者项目周期至少6以上，或者10以上，才有意义。
感谢对第二个问题的解答。
功能是可以独立开来的，但是比如我举得例子，商城购买一个商品，在下订单时会把很多商品信息先获取出来。
在后面支付或者购物车，或者查询物品列表时都需要比对这些信息。这样就很难把检查点独立开来了。
所以才会产生我那样的问题。
我会去试试第三种方式，只要规范了命名方式，封装脚本多花费一点时间，后期维护确实简单太多了。
还想问下，关于这种复杂逻辑的检查点还有没有更好点的方式，比如不用这种datatable形式，改用其他方式等。