如何破解快速变化的web网站测试自动化困境？

liangjz

网站业务复杂度倍增，为了改善由于开发改动一点内容，而QA需要大面积验证相关受影响的模块导致工作量剧增的状况，故引入网站自动化测试。
  目前针对网站主干流程核心业务做了粗粒度的验证。技术： qtp + 页面验证 + 数据库验证，业务流采用excel管理。 运行了一段时间，发现了一些BUG（自动化目的不是找BUG，而是一种质量保证手段），但更多的问题也引爆出来.

  经过和微软技术专家的交流，产品线的自动化测试特征如下：

1) 微软强调单元级的验证粒度非常细致
2) 微软强调每一个业务模块的数据输入都是全新创建而非利用系统原有数据；自动化退出时环境RESET


  我们问题主要集中在几块

1) 业务经常变更，导致页面元素发生变化，需要及时调整自动化脚本。这个成本居高不下
2) 自动化采用的脚本是依赖数据库原有的定制化的数据，有时候被QA测试时修改，干扰脚本运行。
但如果全新创建，需要跨别的系统且需要人工审核的环节，这个成本也很高昂
3) 目前的验证点粒度比较少， 但如果页面验证点颗粒很细，大多数时候页面元素不发生变化，这种验证效用大么？验证点增加也会带来脚本运行速度下降，维护成本增强等问题
4) 自动化测试脚本主要用于项目发布前的回归验证。没有用到项目测试中，原因有需要更换一批新的数据、脚本需要更快速和业务变化同步等

不知道其他业务型的互联网公司如何运作，让自动化脚本最大化发挥功效的？

目前开发尚无单元测试代码，无法做到daily test。而开发没有清晰的API接口说明，开发和测试的工作边界不够清晰导致测试无法写单元测试。

[ 本帖最后由 liangjz 于 2008-7-5 19:18 编辑 ]

liangjz

还补充一点：
QTP运行大量脚本的时候，有时会随机出现页面元素识别出错的问题，但手工刷新网页就正常往下执行的情况。

陈能技

2) 自动化采用的脚本是依赖数据库原有的定制化的数据，有时候被QA测试时修改，干扰脚本运行。

对于第二点，建议自动化测试用的数据库要与手工测试的数据库分离。

zte_boy

1) 业务经常变更，导致页面元素发生变化，需要及时调整自动化脚本。这个成本居高不下
对于这个，我想每个实施自动化的公司都是这样，自动化测试的前置条件就是要求被测系统相对稳定，但系统更改又不可避免，可以要求开发设计demo的时候就提供相应修改的UI元素的属性，后续的开发基于这个demo开发

2) 自动化采用的脚本是依赖数据库原有的定制化的数据，有时候被QA测试时修改，干扰脚本运行
这个也没什么好办法，我的办法就是源头数据用excel保存，同时增加一个过滤条件，脚本中根据条件判断去获取相应的数据并产生新的测试数据

3) 目前的验证点粒度比较少， 但如果页面验证点颗粒很细，大多数时候页面元素不发生变化，这种验证效用大么？验证点增加也会带来脚本运行速度下降，维护成本增强等问题
目前验证点我也只是对金额计算等一些很重要的功能进行，呵呵

4)QTP运行大量脚本的时候，有时会随机出现页面元素识别出错的问题，但手工刷新网页就正常往下执行的情况
这种问题碰见过，也着实查找过很久，后来发现我实际需要的对象竟然丢失了，后来只好执行前都自动去刷新其父对象

liangjz

目前脚本发挥最大功效的地方就是 在发布环境上验证(连接正式的生产DB)。没法切分测试DB了。

liangjz

4)QTP运行大量脚本的时候，有时会随机出现页面元素识别出错的问题，但手工刷新网页就正常往下执行的情况

这个问题排查分析，页面元素没有问题的。打HP电话，没有建设性建议。
我们用QTP9.2。

3) 目前的验证点粒度比较少。

这个问题的后果就是用户对脚本的置信度依然不够高，还需要手工执行结合。
但怎么样的验证点数量算合理呢？如何度量验证点多少与自动化效果间关系呢？

lantianwei

QTP运行大量脚本的时候，有时会随机出现页面元素识别出错的问题，但手工刷新网页就正常往下执行的情况
>>那就在代码里(在最底层的代码)增加当验证元素失败时自动进行一个刷新,然后进行二次识别
目前的验证点粒度比较少。
>>只是一个想法:拿一整个正确的页面做基线,然后通过代码自动解析每一个元素并进行验证,这样验证的覆盖率基本可以达到100%.

zte_boy

4)QTP运行大量脚本的时候，有时会随机出现页面元素识别出错的问题，但手工刷新网页就正常往下执行的情况
确实，我说的并不是页面元素有问题，而是脚本在获取对象时或者已经获取过的对象，在运行时报找不到对象错误
ToString后发现对象丢了，呵呵

目前我也遇到几个问题：
1）用vbs调用自动化模型对象启动QTP运行测试时，加载的设置过多，导致初始化速度过慢，可个人感觉那些设置又是必须的
2）我的错误处理和日志记录都封装在了对象的每个操作步骤中，一定程度上降低了脚本执行的效率
3）由于我采用的是Action组合方式来形成测试流程，而这些原子Action有一部分又是公用的，在脚本执行时，在一个Case中其中某个Action出错，那在其他Case中实际上出错的概率也很大，但目前我的组织形式，无法检测到那些case
包含了该Action，脚本执行做了一部分重复而又无意义的工作
4）正是因为错误处理、日志记录封装在了对象的具体某一个操作中，如果脚本中的某些代码没有采用对象操作，如set
、click等，就无法记录日志，就像对于设置的内置检查点，有可能验证出错，但我的错误处理无法捕获到，还是会记录结果正确。哎，这个是当时考虑不周全，设计失误，呵呵，正在着手改这部分
5）需要考虑测试运行后如何进行环境的清理

liangjz

1   随机出现页面元素识别出错。
---------在代码里(在最底层的代码)增加当验证元素失败时自动进行一个刷新,

呵呵，这个从道理上说这个做的。但这样对于每一个对象识别动作都要判断是否成功。对于大量对象的网站而言，运行速度必然下降。这个不能容忍的。

不知道QTP9.5是否还存在这个问题？

2  我们的页面是经常变化的，所以没有办法做到保存正确页面基准。

本质上，速度、维护成本都是最大的制约因素

lantianwei

1. 还有的方法是用场景恢复实现或增加机器配置，但效果究竟如何也无法估计，如果想从根本上解决该问题，还得靠HP，让他们增强工具的稳定性。这种情况在其他工具也时常出现，比如WR和ST，但不知道他们的原因是否一样。
2. 看来只能先找到那个页面元素的验证度，然后再从技术入手了

liangjz

现在的web页面自动化，最核心的难题不在于脚本怎么写。

而在于怎么样运营管理自动化系统追求自动化最大化发挥功效、最小化维护成本、QA架构组和业务脚本需求引导、脚本开发间合作模式、...

Jimmyshao

原帖由 liangjz 于 2008-7-5 18:54 发表
1) 业务经常变更，导致页面元素发生变化，需要及时调整自动化脚本。这个成本居高不下
2) 自动化采用的脚本是依赖数据库原有的定制化的数据，有时候被QA测试时修改，干扰脚本运行。
但如果全新创建，需要跨别的系统且需要人工审核的环节，这个成本也很高昂
3) 目前的验证点粒度比较少， 但如果页面验证点颗粒很细，大多数时候页面元素不发生变化，这种验证效用大么？验证点增加也会带来脚本运行速度下降，维护成本增强等问题
4) 自动化测试脚本主要用于项目发布前的回归验证。没有用到项目测试中，原因有需要更换一批新的数据、脚本需要更快速和业务变化同步等

1) 我觉得QTP适合做比较稳定的回归测试以及在模块化的平台来做自动化，例如SAP，Siebel这类的
如果业务经常变化，经常导致前期做出来的脚本后期没办法用，或者需要一定Effort修改后才能用，成本比较高，用QTP比较不划算
2) 这个觉得还是全新创建比较好
3) 我觉得CheckPoint还是放在关键业务环节上来，太细了太难维护了；
4) 个人以为还是用到Regresstion Testing里面来用，项目测试中我觉得有的时候还不如Manual Testing来的好；

heqingbluesky

If the element of GUI change frequently, you have better use manual testing instead of AUT. Otherwise, the effort you pay in AUT will cost lots, lots of your time and manpower.

liangjz

非常感谢各位朋友的建议

关键手工测试本身的弊端也太显著了：没有知识传承下来、可信度不高、测试能力没有和系统代码同步增长。

我们的模式是一个组写框架、临时写业务脚本；另外一个测试组使用业务脚本、维护脚本。由于项目时间很赶，维护脚本就跟不上了。
不知道其他网络公司怎么运作的？

yuandjing

我来谈谈我们公司的运作模式加上我自己的看法：
我们的自动化运运作模式还是比较成熟的，因为每周都会有一个新的build，所以每周都跑自动化，由automation team监督完成
自动化采用Selenium Framework(自己研发的架构体系)，selenium是开源的自动化测试工具，里面也有很多验证点，验证方法比QTP多得多
（听说google也是用selenium作为主要自动化测试工具的）
每一个QA都有自己own的test case在selenium里面，等到自己的项目已经趋于稳定了就开始创建自动化测试用例进入selenium Framework，每周automation team都会跑所有的test case，把测试结果发给automation test case owner， owner分析自己fail掉的case，如果该case已经out of date了，那么可以retire掉case，在下个build就不会再被运行
其实这样在一开始的时候fail rate是很高的，但是随着owner不断的maintain，基本上每周的pass rate都在90%上下，test case 本身已经趋于稳定，而且case是自己own的，所以对于fail case 的analyze是很快的，所以维护成本会趋于缓和
以上回答了第一个问题

对于第二个问题，我觉得的确是一个两难的处境，但是平衡的办法就是QA和QA 之间达成某种共识，比如说只能修改数据库的测试数据，而且可能会干扰到别人的测试的情况下需要notify the whole relative QA team

第三个问题，我觉得验证点越细越好，这正是体现出自动化测试工具优越性的地方，因为它可以不疲备地自动验证所有的验证点。但是有些地方也是需要手工验证的，比如说assertElementPresent只能验证元素是存在的，但是不能验证元素在正确的位置，如果build的css出了问题，元素还是存在的但是页面却不是符合预期的。所以少量的手工验证+最大化的自动化验证是完美的搭配

另外我觉得单元测试必不可少，单元测试的每日测试倒是不一定需要，但是可以使用静态测试工具来完成，比如pclint，Logiscope等予以检查工具，可以自定义语义规则，运用在源代码管理服务器会起到很好的效果

yuandjing

呵呵，梁兄，最近项目比较多，简单先谈谈自己的看法
欢迎各路英雄继续探讨
谢谢

centurystone

学习了

testman

这个帖子内容非常好，也是很多人遇到的问题。受益了~~~
没有太多经验，顶一下！！

qaarchitech

现在我们的脚本告警支持邮件、短信、贸易通。

为了方便管理，测试结果分目录存放。

由于当下自动化效益度量不是最紧急的，故自动化WEB执行平台还没有做起来，呵呵，有比较多的认为参与环节

qaarchitech

将自动化脚本往项目前期移动，比如数据准备环节、 报表数据与DB数据比较等，这些收益比较大的环节是可以做的