51Testing软件测试论坛

标题: 如何构建自动化测试框架？（10-05-24）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2010-5-24 14:47
标题: 如何构建自动化测试框架？（10-05-24）（获奖名单已公布）
自动化测试之初，业界并无框架一说，某日，江湖传闻“自动化测试框架”，其为何物不得而知，只知其能助软件企业一臂之力。顿时，江湖掀起“框架”狂潮，“自动化测试框架”百花齐放，百家争鸣。尤以“测试模块化”，“业务流程测试”，“数据驱动”，“关键字驱动”，“智能测试自动化”等曝光率最高。江湖中人个个擦亮眼睛，欲窥其真谛，然框架始终以面纱罩之，亦朦胧亦神秘。
今欲邀天下测试之士，共商框架大事，如能聚天下之言，掀其神秘面纱，甚喜，甚幸!

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	san	50元话费充值卡	12#
二等奖	liaoxj	300论坛积分	21#
三等奖	dennyqiang	100论坛积分	22#

作者: msnshow 时间: 2010-5-25 08:48
先占位，关注中。。。。。

作者: 兰兰 时间: 2010-5-25 10:55
标题: qc与qtp结合的自动化测试框架构成
在公司尝试启用自动化测试已经有三年的时间了，但是一直似乎都是口号式的，年初计划的很好，但是在实际的操作过程中，遇到的技术难题较多，可值得交流人和借鉴的经验很少，在加上公司项目较多，测试人员较忙，几乎没有专门的时间去研究自动化测试，因此每年都是不了了之。如此反复两年，真的是浪费呀。
年初研究出的自动化测试框架是：<qc的业务组件与qtp相结合的自动化测试框架>，具体操作时将被测系统中的模块按功能进行划分---将划分出的功能设计成组件---由qtp去实现组件的功能---qc测试计划中选择组件实现业务流程的覆盖并设置相关的测试数据--在qc测试集中选择业务流程进行自动执行进行自动化测试。
在具体的实现过程中牵扯到很多的技术细节，在这里不再一一介绍，算是抛砖吧，希望大家能将自己使用的自动化框架共享出来了。

作者: flying-kite 时间: 2010-5-25 11:11
QC与QTP结合得很好，可以把共同的功能模块设计好，调用就行了

作者: linlili1985 时间: 2010-5-25 15:24
关注中。。。

作者: rojer521 时间: 2010-5-25 20:39
推荐http://relevantcodes.com/category/automation-frameworks/，值得学习

作者: JamesHao 时间: 2010-5-25 22:43
我这方面有些心的，但是落地纸面上没有时间。：）

PS:我的部门项目里已经做到60%是自动化，其中引擎类接近100%，UI相对低一些。自动化用例数量大概在10000+
如果大家很关心这个问题，我们可以安排一个讨论，因本人在上海，以及工作原因，可以安排在周末。
如果大家不关心，那就算了，就当我没有说。

[ 本帖最后由 JamesHao 于 2010-6-3 13:54 编辑 ]

作者: xuzengle 时间: 2010-5-26 01:26
我qtp 学了一年多了，也没有搞出个所以然了，真是杯具。

作者: TIB 时间: 2010-5-26 08:56
自动化测试工程师的开发水平和技术没有提高的话，谈框架是空谈！

http://www.cnblogs.com/testware/archive/2010/05/02/1726041.html

作者: 51mobile 时间: 2010-5-27 12:37

原帖由 TIB 于 2010-5-26 08:56 发表
自动化测试工程师的开发水平和技术没有提高的话，谈框架是空谈！

赞同这个，我现在就深有体会，还得继续努力啊

作者: shanxi 时间: 2010-5-27 13:16
标题: 说点不同的意见
对于大部分人来说，由于并没有机会开发界面自动化的核心组件，所以开发框架成为了自动化脚本开发人员的主要提升方式。

个人经验以为，界面自动化测试框架并不需要太高深的技术，它是一个逐步完善提高改善的过程。这里列举一些通用事例子：当你在脚本开发中，经常用到一些工具类方法时，你为了以后少写代码会集成成util类；当你使用核心组件识别对象发现比较困难时，你会在框架内封装该组件的属性、操作等；当你测试工具需要生成一个比较固定格式的报告时，你会在框架内集成report类；当你手工的测试流程已经证实了所有对一个对象的操作都类似时，你会在框架内体现该操作的逻辑。。。。所有的这些，都在项目做好手工测试充分掌握手工测试经验的前提下，为了提高测试效率而进行的过程改良和提高，所以不同的项目会用不同的框架。

作者: san 时间: 2010-5-27 15:30
自动化测试知识分两个方面
1. 使用策略
2. 工具
我们自由学习和讨论时候更多的是讨论工具使用。但其实从工具演变的历史看，都是为了某个目的，且配合能在项目高效使用的具体策略服务。工具一直在发展在变，策略也是在变，但我们使用自动化的原因和目的不变。测试框架和工具的不同，是在工具本身提供的功能上，集成了相应部分策略的系统。为了了解他们的不同，要从工具发展和演变说起。
我们在这里先讨论GUI层面的自动化：
1). 最初的GUI自动化工具只提供了录制和回放的功能，记录底层鼠标和键盘的操作轨迹，并回放，但并不能以某种方式(例如某种语言/脚本)展现出来。
2). 而后大家发现这样做的不灵活和不稳定性，于是考虑不仅仅从底层的鼠标键盘模拟，而且从识别并控制GUI底层所采用的技术对象来模拟。并且把录制的结果以某种方式解析出来。这样做的好处显而易见，有了可展现且易于用编程语言展现的平台，直接为模块化，参数化提供了条件。于是有了大家通常看到的UI自动化工具：能识别和操作界面对象，提供录制回放功能，且通常提供某种过程化语言的展示和修改平台。
3). 在此之后进入类似百家争鸣时期，大批的商业和open source的UI自动化工具涌现。他们在对象识别方面各有偏向和优劣，提供的展现平台也各有差异。在工具选择上我们正是依据他们在这两方面的表现作出决策。但同样工具在不同公司使用上差异也很大。正如同样一门语言，做出来的东西和使用效果迥异一样。依据工具提供的展现平台/语言，具体公司在使用上定制出自己的代码规范，积累自己的函数库。于是在具体使用上出现了数据参数化/外部化，过程化和模块化，包括独立出环境初始化库/异常处理库/报告处理库等等。尔后在这些细节处理方法总结和实际目的上，萃取提炼出通用性和方向性的策略，如数据脚本分离，数据驱动，对象脚本分离，关键字驱动等等。一时风云涌动，依据需求而变的东西呼之欲出。
4). 某些工具提供商和使用工具的公司本身，于是考虑是否能把某些使用策略和思想集成到工具本身，从而提高易用性和效率。于是自动化测试框架被提出。这时候的自动化框架并不仅仅提供对象识别和控制，录制回放，脚本展示，且常常集成了test case的管理，对象库的管理，与CI系统集成等等。人们不仅仅追求对象捕捉的精准，更多的开始分析test case类型本身，更多的开始分析展现的其他更直观和易维护的形式，更多的开始分析系统在真实项目过程的需求。

作者: Andy_wang122 时间: 2010-5-27 23:34
自动化测试的框架很重要，好的框架可以省下很多工作，比如用户名，密码，日期都可以在框架中设定，现在都是数据驱动测试，当然通过框架可以定义很多默认值，只需要关注我们需要测试的情况。

作者: 小米啊 时间: 2010-5-28 13:49
1.要考虑测试适不适自动化。
2.适合自动化的项目，有没有选择好自动化工具。
3.自动化不是口号，是能给自己或其它人带来效率。
4.自动化框架不能太单调，也不能限制成是某一种测试工具。
5.不要一来就要开发什么测试框架，其实“你想做的，别人早就开始了或做好了”。开发一个新的框架，大多数测试时间是浪费在框架本身上。至少我现在觉得是这样。

以前也参加过框架的开发。开发出来自己都不想用，更何况其它同事呢？（就是本着测试人员很傻瓜，不用写代码，只要拖拉就可以完成）。把简单的事想的太复杂了，一直想着写代码是测试人员的大山。现在觉得测试人员，写代码都不是问题。
最近看到开源的东西SHE，随便组合下，也能达到以前的几个人开发了一年的框架的效果，开源的还更加有扩展性。也达到了自己的需求。

个人意见。有错必改

作者: nanice 时间: 2010-5-28 14:24
构建自动化测试框架

[ 本帖最后由 nanice 于 2010-7-9 13:04 编辑 ]

作者: 0o夜星o0 时间: 2010-5-28 14:39
持续关注中

作者: kakamissyou 时间: 2010-5-28 16:14
标题: 非常赞同

原帖由 shanxi 于 2010-5-27 13:16 发表
对于大部分人来说，由于并没有机会开发界面自动化的核心组件，所以开发框架成为了自动化脚本开发人员的主要提升方式。

个人经验以为，界面自动化测试框架并不需要太高深的技术，它是一个逐步完善提高改善的过程。 ...

非常赞同

作者: 健歌 时间: 2010-5-28 17:40
去某公司面试过，被那测试经理说他们的什么开源自动化框架说得头晕转向大为惊叹，其实不好意思揭破他们就是开源的QC+QTP！

作者: jiangdl 时间: 2010-5-28 18:09
框架只是解决一类问题的一个通用的模型，只是起一个支撑作用
做了多年的我还是回到行业业务上去了
要做什么，才是关键的

好比建座大厦，也都是先做框架，
而这个大厦到底要做成什么样，是开发商决定的
也就是测试需求决定的

作者: jiangdl 时间: 2010-5-28 18:11
高效引入测试才是根本

作者: liaoxj 时间: 2010-5-31 15:26
不可否认，随着系统架构越来越复杂，带来测试技术的冲击是越来越大，公司测试架构形成对提高测试效率和质量，一定会是行之有效的手段。
   做测试架构前期需投入很大成本和时间，问：在很多公司连程序架构的思路都没有很好理清的情况下，我们如何去做测试架构。
   我是从公司只有两个测试人员的基础上，通过6年的努力发展到12人，我深有感触，测试架构形成要分三分走，首先人员架构，知识库架构，技术架构。
   人员架构建立是整个测试架构形成基础，当公司只有两个人做测试，何谈测试技术架构。记得我们两个人测试的时候，我们没有分工所有产品大家一起来。发展到四个人的时候，我按大产品线分两小组，当我们发展到7个人的时候我们按项目分组，发展到10个人的时候我们又回归产品线，今年我们发展到12个人时候，我们组建了自动化测试小组。
   知识库架构的建立是整个测试架构形成的资源的方向，并需要不断积累的完善。记得刚开始的时候我们所有测试都是功能测试而且全墨盒，但是我们积累了详细的业务知识，并整理了详尽的测试案例，后面根据产品线进行分类，并且获取了公用测试用例，并配合开发组形成了界面规范，数据库规范，代码规范等。后面由测试业务需要我们进行性能测试，尝试使用很多测试工具，jmeter,loadrunner, JProfile等，我们整理了工具的特性，什么时候应该使用工具，并且顺便整理了一些监控工具，有操作系统的OmniPeek、Aports等，网络监控工具TCPMonitor等，网页监控工具HttpWatch，Xenu等，也顺便整理了一个测试辅助工具如DataFactory, jsunit。形成了自己公司独有知识库体系和知识库管理流程。
   技术架构需要根据公司的测试团队规模和测试技术实力，目前还没有到哪家公司的测试技术框架能够照搬，参照也很难，做到借鉴已经不错，现在只通过自己公司知识库积累，搭建符合自己测试技术框架。小公司现阶段不适宜搭建什么测度技术框架平台，那很不务实的，但是小公司我们整理自己的“公用类库”，如QTP的公用类库，jsunit的公用类和方法。并在项目中执行，结束后，然后不断不完善。最后时机成熟了，就可以很好嵌入到所谓的平台

自己看了一遍，好像没有回答问题似的，大家看看，只是我一些想法和现在做的事！

[ 本帖最后由 liaoxj 于 2010-5-31 15:27 编辑 ]

作者: dennyqiang 时间: 2010-5-31 15:40
谈框架，谈的就是个思想，要谈思想，先要解放思想。

没有弄清楚工具前，谈方法，不可取。
没有弄清楚方法前，谈框架，不可取。
框架很空洞，实现起来很麻烦，不可取。
把框架神化，认为框架无所不能，不可取。
框架设计要花很多时间，所以不要也罢，不可取。

如果企业流程混乱，没有一个完全理解自动化的人来主导自动化，莫谈框架。
如果没有一个完整的规划和风险识别，莫谈框架。
如果连基本的自动化测试都没做起来，莫谈框架。
如果测试开发人员只会录制回放和一些基本的代码操作，莫谈框架。

框架是什么？框架无非就是一组封装好的类和方法，其目的在于统一企业的自动化测试流程和方法，并为具体的自动化测试项目提供可重用的，易于维护和扩展的架构。

框架不是一蹴而就的，而是在使用过程中逐步完善的。

不可将框架设计得很复杂，妄想用户编写测试代码变得简单方便，其结果是降低框架的灵活性，框架本身的维护成本会增加，得不偿失。

框架并不深奥，完全不必谈框架色变，任何一个组织，只要经过一些指导和培训，均能开展自动化测试。

框架的设计通常遵循如下原则进行：
a) 高度重用：重用测试用例，重用对象，重用各种组件，通过重用性设计来提高模块化程度。
b) 随需应变：通过分离对象与用例，用例与业务(一个业务或场景应该是由一个或多个单个的测试用例组成)，业务与数据来使自动化测试代码更加灵活，自适应性更强。
c) 简化开发：并非所有测试人员都是软件开发方面的专家，自动化测试的很多用例书写和后续维护工作还应该交给测试人员来进行，那么如何让一个没有多少软件开发经验的员工来开发或维护自动化测试用例呢？设计一个简单易用框架是最好解决方案。
d) 框架维护成本低：框架不但应该满足上面三个原则，同时还需要考虑到框架本身的复杂性，如果为了提升模块化，为了提升灵活性或是为了简化开发而将框架本身设计得非常复杂，将是一件得不偿失的事情。

作者: 蝈蝈5 时间: 2010-5-31 16:03

原帖由兰兰于 2010-5-25 10:55 发表
在公司尝试启用自动化测试已经有三年的时间了，但是一直似乎都是口号式的，年初计划的很好，但是在实际的操作过程中，遇到的技术难题较多，可值得交流人和借鉴的经验很少，在加上公司项目较多，测试人员较忙，几乎没 ...
在具体的实现过程中牵扯到很多的技术细节，在这里不再一一介绍，算是抛砖吧

很空泛的实心板砖

作者: 蝈蝈5 时间: 2010-5-31 16:04

原帖由 JamesHao 于 2010-5-25 22:43 发表
我这方面有些心的，但是落地纸面上没有时间。：）

那您打这几个字就有时间了，别累坏了您

作者: 蝈蝈5 时间: 2010-5-31 16:06

原帖由 shanxi 于 2010-5-27 13:16 发表
对于大部分人来说，由于并没有机会开发界面自动化的核心组件，所以开发框架成为了自动化脚本开发人员的主要提升方式。

个人经验以为，界面自动化测试框架并不需要太高深的技术，它是一个逐步完善提高改善的过程。 ...

很赞成您的观点，看了半天，就您的话有帮助

作者: archonwang 时间: 2010-6-1 15:33
标题: 回复 15# 的帖子
凶悍。。。。

测试和开发密不可分，即使在实现形式上也有很多类似。

做测试这么多年，发现其实还有很多东西要学。。

作者: JamesHao 时间: 2010-6-3 15:24

原帖由 蝈蝈5 于 2010-5-31 16:04 发表

那您打这几个字就有时间了，别累坏了您

说的很好。
其实并不是不能谈，试问自动化落地，真的是框架问题吗？
之所以不再这里谈，是我觉着在帖子谈不清楚。（可能是我的表达能力问题）
我可以安排在某周六或者周日，进行一次面对面的沟通，共同探讨这个问题。
地点：上海。

作者: konnie 时间: 2010-6-3 17:26
公司内部也在组织进行自动化测试，框架方面和楼上所说的大同小异。需要在过程中不断总结，抽取出可自动化的各种组件，资源消耗是比较大的，但这也是自动化测试必须付出的代价。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)