如何构建自动化测试框架？（10-05-24）（获奖名单已公布）
自动化测试之初，业界并无框架一说，某日，江湖传闻“自动化测试框架”，其为何物不得而知，只知其能助软件企业一臂之力。顿时，江湖掀起“框架”狂潮，“自动化测试框架”百花齐放，百家争鸣。尤以“测试模块化”，“业务流程测试”，“数据驱动”，“关键字驱动”，“智能测试自动化”等曝光率最高。江湖中人个个擦亮眼睛，欲窥其真谛，然框架始终以面纱罩之，亦朦胧亦神秘。今欲邀天下测试之士，共商框架大事，如能聚天下之言，掀其神秘面纱，甚喜，甚幸!
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单奖项获奖名单奖励答案链接
一等奖san50元话费充值卡12#
二等奖liaoxj300论坛积分21#
三等奖dennyqiang100论坛积分 22#
先占位，关注中。。。。。
qc与qtp结合的自动化测试框架构成
在公司尝试启用自动化测试已经有三年的时间了，但是一直似乎都是口号式的，年初计划的很好，但是在实际的操作过程中，遇到的技术难题较多，可值得交流人和借鉴的经验很少，在加上公司项目较多，测试人员较忙，几乎没有专门的时间去研究自动化测试，因此每年都是不了了之。如此反复两年，真的是浪费呀。年初研究出的自动化测试框架是：<qc的业务组件与qtp相结合的自动化测试框架>，具体操作时将被测系统中的模块按功能进行划分---将划分出的功能设计成组件---由qtp去实现组件的功能---qc测试计划中选择组件实现业务流程的覆盖并设置相关的测试数据--在qc测试集中选择业务流程进行自动执行进行自动化测试。
在具体的实现过程中牵扯到很多的技术细节，在这里不再一一介绍，算是抛砖吧，希望大家能将自己使用的自动化框架共享出来了。 QC与QTP结合得很好，可以把共同的功能模块设计好，调用就行了 关注中。。。:victory: 推荐http://relevantcodes.com/category/automation-frameworks/，值得学习 我这方面有些心的，但是落地纸面上没有时间。：）
PS:我的部门项目里已经做到60%是自动化，其中引擎类接近100%，UI相对低一些。自动化用例数量大概在10000+
如果大家很关心这个问题，我们可以安排一个讨论，因本人在上海，以及工作原因，可以安排在周末。
如果大家不关心，那就算了，就当我没有说。
[ 本帖最后由 JamesHao 于 2010-6-3 13:54 编辑 ] 我qtp 学了一年多了，也没有搞出个所以然了，真是杯具。 自动化测试工程师的开发水平和技术没有提高的话，谈框架是空谈！
http://www.cnblogs.com/testware/archive/2010/05/02/1726041.html 原帖由 TIB 于 2010-5-26 08:56 发表 http://bbs.51testing.com/images/common/back.gif
自动化测试工程师的开发水平和技术没有提高的话，谈框架是空谈！
赞同这个，我现在就深有体会，还得继续努力啊
说点不同的意见
对于大部分人来说，由于并没有机会开发界面自动化的核心组件，所以开发框架成为了自动化脚本开发人员的主要提升方式。个人经验以为，界面自动化测试框架并不需要太高深的技术，它是一个逐步完善提高改善的过程。这里列举一些通用事例子：当你在脚本开发中，经常用到一些工具类方法时，你为了以后少写代码会集成成util类；当你使用核心组件识别对象发现比较困难时，你会在框架内封装该组件的属性、操作等；当你测试工具需要生成一个比较固定格式的报告时，你会在框架内集成report类；当你手工的测试流程已经证实了所有对一个对象的操作都类似时，你会在框架内体现该操作的逻辑。。。。所有的这些，都在项目做好手工测试充分掌握手工测试经验的前提下，为了提高测试效率而进行的过程改良和提高，所以不同的项目会用不同的框架。 自动化测试知识分两个方面
1. 使用策略
2. 工具
我们自由学习和讨论时候更多的是讨论工具使用。但其实从工具演变的历史看，都是为了某个目的，且配合能在项目高效使用的具体策略服务。工具一直在发展在变，策略也是在变，但我们使用自动化的原因和目的不变。测试框架和工具的不同，是在工具本身提供的功能上，集成了相应部分策略的系统。为了了解他们的不同，要从工具发展和演变说起。
我们在这里先讨论GUI层面的自动化：
1). 最初的GUI自动化工具只提供了录制和回放的功能，记录底层鼠标和键盘的操作轨迹，并回放，但并不能以某种方式(例如某种语言/脚本)展现出来。
2). 而后大家发现这样做的不灵活和不稳定性，于是考虑不仅仅从底层的鼠标键盘模拟，而且从识别并控制GUI底层所采用的技术对象来模拟。并且把录制的结果以某种方式解析出来。这样做的好处显而易见，有了可展现且易于用编程语言展现的平台，直接为模块化，参数化提供了条件。于是有了大家通常看到的UI自动化工具：能识别和操作界面对象，提供录制回放功能，且通常提供某种过程化语言的展示和修改平台。
3). 在此之后进入类似百家争鸣时期，大批的商业和open source的UI自动化工具涌现。他们在对象识别方面各有偏向和优劣，提供的展现平台也各有差异。在工具选择上我们正是依据他们在这两方面的表现作出决策。但同样工具在不同公司使用上差异也很大。正如同样一门语言，做出来的东西和使用效果迥异一样。依据工具提供的展现平台/语言，具体公司在使用上定制出自己的代码规范，积累自己的函数库。于是在具体使用上出现了数据参数化/外部化，过程化和模块化，包括独立出环境初始化库/异常处理库/报告处理库等等。尔后在这些细节处理方法总结和实际目的上，萃取提炼出通用性和方向性的策略，如数据脚本分离，数据驱动，对象脚本分离，关键字驱动等等。一时风云涌动，依据需求而变的东西呼之欲出。
4). 某些工具提供商和使用工具的公司本身，于是考虑是否能把某些使用策略和思想集成到工具本身，从而提高易用性和效率。于是自动化测试框架被提出。这时候的自动化框架并不仅仅提供对象识别和控制，录制回放，脚本展示，且常常集成了test case的管理，对象库的管理，与CI系统集成等等。人们不仅仅追求对象捕捉的精准，更多的开始分析test case类型本身，更多的开始分析展现的其他更直观和易维护的形式，更多的开始分析系统在真实项目过程的需求。 自动化测试的框架很重要，好的框架可以省下很多工作，比如用户名，密码， 日期都可以在框架中设定，现在都是数据驱动测试，当然通过框架可以定义很多默认值，只需要关注我们需要测试的情况。 1.要考虑测试适不适自动化。
2.适合自动化的项目，有没有选择好自动化工具。
3.自动化不是口号，是能给自己或其它人带来效率。
4.自动化框架不能太单调，也不能限制成是某一种测试工具。
5.不要一来就要开发什么测试框架，其实“你想做的，别人早就开始了或做好了”。开发一个新的框架，大多数测试时间是浪费在框架本身上。至少我现在觉得是这样。
以前也参加过框架的开发。开发出来自己都不想用，更何况其它同事呢？（就是本着测试人员很傻瓜，不用写代码，只要拖拉就可以完成）。把简单的事想的太复杂了，一直想着写代码是测试人员的大山。现在觉得测试人员，写代码都不是问题。
最近看到开源的东西SHE，随便组合下，也能达到以前的几个人开发了一年的框架的效果，开源的还更加有扩展性。也达到了自己的需求。
个人意见。有错必改 构建自动化测试框架
[ 本帖最后由 nanice 于 2010-7-9 13:04 编辑 ] 持续关注中
非常赞同
原帖由 shanxi 于 2010-5-27 13:16 发表 http://bbs.51testing.com/images/common/back.gif对于大部分人来说，由于并没有机会开发界面自动化的核心组件，所以开发框架成为了自动化脚本开发人员的主要提升方式。
个人经验以为，界面自动化测试框架并不需要太高深的技术，它是一个逐步完善提高改善的过程。 ...
非常赞同 去某公司面试过，被那测试经理说他们的什么开源自动化框架说得头晕转向大为惊叹，其实不好意思揭破他们就是开源的QC+QTP！ 框架只是解决一类问题的一个通用的模型，只是起一个支撑作用
做了多年的我还是回到行业业务上去了
要做什么，才是关键的
好比建座大厦，也都是先做框架，
而这个大厦到底要做成什么样，是开发商决定的
也就是测试需求决定的 高效引入测试才是根本
页:
[1]
2
