自动化：唯规范设计方能言及节约成本

lyscser

--------------鄙人不认为自动化框架存在重量级或者轻量级，只是适应不同的运作模式而已……抛开这点可以继续阅读。
--------------不使用QC的企业也很多，但是本文只讨论QC中的自动化设计规范，所以不能保证与绝大多数看官做法相同。

核心思想是：花力气和成本设计、规划，降低自动化编码的难度，力求降低自动化脚本开发、维护的成本（我个人验证结果尚可，鉴于道德，无法提供确切的数据）。
所以呢，我就不在这里论述为什么把成本花在设计上后面维护成本就会降低了，想必大家拍脑袋空想也能想明白的。
内容基本很简单，都是QTP最基础的操作，综合了一下，我觉得这样的管理方式比较安逸，不见得最好……欢迎大家拍砖。

参考内容：http://bbs.51testing.com/thread-99681-1-1.html

[ 本帖最后由 lyscser 于 2009-5-11 22:28 编辑 ]

virgolong

实践证明,后期维护成本比前期的设计开发成本大太多了

angek

现在也研究自动化框架，支持楼主一下，感谢分享

zte_boy

不错，很详细，呵呵

ls_721521

没用过qc
下来看看。

dreamever

很精彩的文档，楼主强人，赞一个，并鲜花送上

[ 本帖最后由 dreamever 于 2009-5-6 09:20 编辑 ]

52042722

已经阅读完了LZ的文章，我觉得相当的好，但是我还是有些疑问，
1：如果按照LZ的说法和QC结合的如此的紧密，是否是在QC服务器移植或者想做脚本的移植您是怎么考虑的。
2：楼主的框架对错误的处理讲的不是很多呀，仅仅说的场景恢复，后面自己又不推荐使用，不知道LZ在使用这个框架的时候，有没有遇到过一些异常情况。
3：还有就是对LZ的关键点使用截图功能有疑问，什么情况下使用这个截图功能 是不是每步操作都截图呢？还是仅仅在发生错误的时候截图呢，一般一张截图是1.3M 如果超过1000张截图 我觉得就不太好了
希望楼主能帮我解惑

walker1020

对于第三个问题，我的建议是：
如果出错了那么一定需要截图。至于运行正常时是否需要截图，可以根据需要来作决定。至于你说的图片占用太多空间的问题，我想你需要注意截图的文件格式。我试验过，同样一张图片，如果文件格式不同，文件格式可能相差很大；保持为JPEG格式，只有170K；保持为BMP 格式，却有3841K. 目前，我都是把它们保持为PNG格式，最大只有243K，从来没有超过1M，更没有到1.3M。

[ 本帖最后由 walker1020 于 2009-5-6 12:01 编辑 ]

walker1020

如果你使用了CaptureBitmap 进行截图，那么文件格式不要保存为BMP格式，最好保存为PNG 格式。

[ 本帖最后由 walker1020 于 2009-5-6 12:07 编辑 ]

52042722

  walker1020 果然实践是检验真理的唯一标准 撒，，我已经修改了我的公共函数全部都为PNG格式了 省了不少空间，呵呵

lyscser

原帖由 52042722 于 2009-5-6 09:58 发表
已经阅读完了LZ的文章，我觉得相当的好，但是我还是有些疑问，
1：如果按照LZ的说法和QC结合的如此的紧密，是否是在QC服务器移植或者想做脚本的移植您是怎么考虑的。
2：楼主的框架对错误的处理讲的不是很多呀，仅 ...

呵呵，我只是想抛砖引玉，希望大家能够深入讨论一下对自动化的成本效益的分析，这点请大家好好思考一下：-）
1、QC服务器的迁移原因是什么呢？这个是人为能够控制的，其次即使迁移，也可以通过备份恢复重新得到与原来一模一样的域和项目，最多是QC的数据库表空间不同而已
2、错误处理的确是没有说清楚，因为平常都把脚本内部容错写了很多，Reusable Actions这部分也有专门的错误处理Action，内容没有细说而已，具体内容与系统容错处理机制特点保持一致
3、斑竹已经解说了，多谢版主……

zte_boy

heqingbluesky

我们主要用的是Function或者Sub实现QTP的自动化回归测试，Action使用很少。

流程跟LZ的差不多了，基本上都是这样的。

walker1020

原帖由 52042722 于 2009-5-6 14:15 发表
  walker1020 果然实践是检验真理的唯一标准 撒，，我已经修改了我的公共函数全部都为PNG格式了 省了不少空间，呵呵

不送鲜花倒也罢了（如果你怕花银子的话）， 连声谢谢 也不说！ 太伤心了！    

52042722

别伤心啦。。。哈哈  有人替我送了哈哈  还是要谢谢啊