回复 17# 的帖子
在ST中 通过一功能可以直接录制出在对象下所有的public方法和属性 然后就可以直接调用了 我曾经在51测试杂志上看到有人通过QTP测试DEVEXPRESS对象（第三方对象，无法正确识别）的例子 其实调的就是那对象公用的方法和属性来实现的 你可以找下这里的接口 其实就是公用的方法和属性 但通过特殊机制 也可以访问私有和保护的方法和属性
还有我说的这些方法和属性是直接定义在对象下的 所以可以直接调用
回复 20# 的帖子
似乎对象无法识别和描述性编程无直接联系回复 20# 的帖子
::yiwusuoyou:::如蓝天伟说的。没关系。 原帖由 lantianwei 于 2009-12-24 16:55 发表 http://bbs.51testing.com/images/common/back.gif
个人认为自动化的成败取决于以下几个方面：
1。被测产品的可自动化测试性 如果基本无法识别对象，那么做自动化没什么太大意义，除非开发提供接口
2。产品/项目的周期 如果太短，没等用上产品周期已结束，做等于白做 ...
分析的犹如教科书，记下啦~
回复 21# 的帖子
多谢lantianwei我会找找看的!:)请大家留个QQ号
大家，可不可以留个QQ号啊？以后遇到什么问题，可以向各位请教一下！谢谢 原帖由 feiyunkai 于 2009-12-25 17:38 发表 http://bbs.51testing.com/images/common/back.gif对象无法识别,可以使用描述性编程,网上有很多例子,可以搜下看看
费兄，对象无法识别，你描述性编程就能识别了？呵呵，建议还是先打好基本功:) 不错，学习了 个人认为自动化的成败取决于以下几个方面：
1。被测产品的可自动化测试性 如果基本无法识别对象，那么做自动化没什么太大意义，除非开发提供接口
2。产品/项目的周期 如果太短，没等用上产品周期已结束，做等于白做，自动化的前期投入还是挺大的
3。产品的变更 如果产品隔三差五的变，那么自动化进行起来会比较累，当然小范围的变是应许的
4。自动化测试的人 一个优秀的自动化测试人员 可以保证可靠高效的脚本 同时可以减少后期的维护成本
5。自动化的规范 流程也很重要
我们公司有一小产品，该产品组总共有3，4K个CASE， 而自动化率已达到95%，每次版本发布 只需运行下脚本可以基本确定产品的情况公司一般周五发布新版本，可以利用周末的时间运行那个3K多个CASE 然后周一一般可以得到测试结果 周一来了 测试人员分析测试结果这应该算是一个比较成功的案例
1、不一定要用UI测试的方式，接口测试或者接口测试模拟器界面上的自动化测试也是可行的；
2、这个观点要挺……好多人都这么想，不过如果考虑到系统上线之后如果还在为市场变化不停地作补丁需求开发，基线上开发出来的自动化程序在频繁的版本发布过程中的冒烟和回归测试作用还是挺大的，对保证产品质量还是有一定好处的，当然有些类型的系统完全没必要这么做；
3、自动化开发过程中如果发现项目经理变更控制不做好，那就要随时喊停，千万别再继续开发咯……不然结局注定是杯具……
4、框架好才是真的好，也不能太过依赖某些人，人员流动的风险在业界还是无法避免的；
5、相当的重要，等同甚至高于于CMM测试领域规范的重要性，至少对于自动化开发和维护是这样
我们两个测试部门，每天无人值守近3万个脚本的执行，可惜执行完毕没有结果分析，只是对成功率和系统版本变更程度做监控，根本不作为测试缺陷发现的手段……不知道算是成功的案例还算是失败的，智能锁不同的公司对自动化的需求完全不一样吧。
页:
1
[2]
