测试自动化框架

这是一篇老博文(Test Automation Frameworks)的中文翻译。 度量测试自动化,可以有不同视角的标准。其中一个度量测试自动化的可行标准是将它分为如下5级: 线性 结构化 模块化 数据驱动 关键字驱动 要实现上述后3个自动化等级,必需用到测试自动化框架(Test Automation Framework,简写TAF)。TAF为框架和被测应用(Application Under Test,简写AUT)提供了一组可重用的支持功能。针对框架的支持功能主要是与应用无关的,可以很容易地用于其他产品的自动化脚本或程序,例如,字符串处理、文件处理、变量处理等等。针对AUT的支持功能应该是与框架无关的,将针对应用的特定实现隐藏起来,提供抽象层级的接口,以便TAF可以识别为库例程(Routine)或脚本。 这些支持功能可以以两种形式来提供:库例程或关键字。库例程实现了可被不同自动化测试用例调用的那些常用基础功能;关键字就是可以被TAF识别和执行的文本字串,它的底层就是针对AUT的支持功能,或者换句话说就是模块函数。 可重用性在TAF中扮演着重要角色,我们最好能重用函数,甚至是能重用自动化测试用例。关键字驱动型(有时也叫做表格驱动型)TAF主张将自动化测试用例抽象为三个层级:步骤(Step)表格、套组(Suite)表格、循环(Cycle)表格。 步骤表格包含的是使用单个关键字及其参数来执行特定任务的步骤。一个步骤表格可能代表的是一个测试用例,或者是拥有相同操作组合的更大测试用例(体现为套组表格或循环表格)的一部分; 套组表格主要是将步骤表格纳入作为其操作步骤,同时也可以是更大测试用例(体现为循环表格)的一部分; 循环表格可能会纳入套组表格或步骤表格作为其操作步骤。 这种划分只是一种可选方案而已,基本上来说它也就是让表格可以被重用的一种方式,不管是步骤、套组还是循环表格。 设计TAF的时候,万万不可忽视软件研发生命周期其他方面,尤其注意要跟测试策略一起考虑,推荐大家在制定整体测试策略时遵守如下这些重要指导原则: 测试自动化是一个全职工作,不是兼职副业。 测试设计和测试框架是完全独立的实体。 测试框架应该是应用无关的。 测试框架必须易于扩展、维护和持久。 测试策略及设计的词汇表应该是框架无关的。 测试策略及设计应该让大部分测试人员可以无需操心测试框架的复杂性。 我们无法脱离测试的范畴来谈TAF,就像我们无法脱离软件研发生命周期来谈测试一样。不同的TAF代表了对TA的不同看法,有不同的抽象层级及职责,同样也有着不同的适用场景。 使用模块化类型的TAF可能会需要工程师具备很多能力,包括框架开发、支持库的功能实现以及测试用例实现等能力,他们需要熟悉或掌握一些编程语言,有软件研发实践的经验,还应该知晓产品特性。只有这样才能保证我们的自动化能够把代码(自动化代码)构建正确,同时也构建了正确的代码。 当我们使用数据驱动型TAF时,至少我们可以把职责区分为两类,一类负责要验证的测试数据,一类负责前述职责的剩余部分。但目标没有变,我们要提供可靠的自动化测试用例。 关键字驱动将职责分得更细。有些人负责开发和维护框架本身,有些人负责支持功能或称模块函数,同时其他工程师应该去实现实质性的自动化测试用例,例如步骤、套组、循环表格等。

What are Next Practices of Test Automation?

Again, I’m here blogging about the Test Automation Day 2016, get more information at http://www.testautomationday.com/.   During the 6th edition of Test Automation Day we focus on sharing insights and experiences with a theme of “Next Practices”. All aspects of

敏捷书籍推荐

经常会有很多人问我推荐敏捷相关的书籍,我总是会告诉他们,去我的豆瓣页面,看看我的读书评价,凡是评5星的那些书籍,都是我强烈推荐大家阅读的,不限于敏捷。我读书不善速读,甚至可以很“惭愧”的说,我并不会速读,我只会挑选一本很棒的书,沉浸其中,感受它带给我的冒险,当我离开的时候,我的身心都已升华,这才是我想要的读书。而不是冲到门口,买本旅游宝典,到所有旅游景点都去拍照留念,回来还可以跟大家念念有词,sorry,这不是我的读书风格。 我认为,读书除了有所用,还要能够提升我们的心灵和悟。也正因为此,对于读书帮的那种理念,我有些难以接受。 好书太多,无法一一推荐,后续有更多好书,我也会再补充进来,逐步完善。如果你想知道有更多书目,可以参考别人的一些推荐书籍(注:仅供参考,不代表我支持他们的观点): 2013年度Jurgen Appelo的100本推荐书 敏捷书籍推荐 – Vikas Hazrati  敏捷书籍推荐 豆列 – 敏捷开发书籍 Scrum中文社区 – 敏捷书籍 UPerform – 书籍推荐 敏捷书籍推荐 – ShineScrum 知乎 – 敏捷开发有哪些经典书籍?  知乎 – 关于敏捷方法的实践,有什么书值得推荐? 敏捷南京俱乐部 – 敏捷ABC 如果你的敏捷旅程刚刚起步,我建议你从如下内容入手,它们都是短小精悍的小书,读起来很容易,又能够帮助你快速地了解敏捷长什么样子: Scrum要素 [美] Chris Sims、Hillary Louise Johnson / 徐毅

Fruitful Program of Test Automation Day, isn’t It?

Program Page at http://www.testautomationday.com/program/ Look at the program, I have to say, it’s a very good one! Would it be a fruitful experience? What you say? Fee? Sure you need to pay, € 295,- (excl. VAT) per person. When and where?

Test Automation Day 2015: Call for Papers!

Test Automation Day 2014, developed by and for the international Test Community, was again a successful edition. We are already preparing the next edition on June 18th 2015 in Rotterdam, the Netherlands. Central theme of the 2015 edition is: Improving Test

See you at Test Automation Day 2014!

As written in http://kaverjody.com/test-automation-day-2014/, I really want to be there, while the visa, schedule, flights and other trivial issues may block me from attending the Test Automation Day 2014 at Rotterdam, but it may not be the same for you,

Lets go Test Automation Day 2014!

I’ve blogged about the Test Automation Day 2013, and now I’m going to blog for the Test Automation Day 2014, which will happen at Rotterdam the Netherlands. I’m trying to coordinate my calendar to go there, will you be with me?

The Day of Test Automation at 2013

I still remember the days at 2008, that NSN has held an internal Test Automation conference at Finland, kind of all NSN Test Automation professionals from all over the world gathered together and share their experiences and learns. That’s so

Tagged with:

阅读推荐 20130412:管好你的隐形员工、大声牛、商学院杂志

近段时间读的一些书和杂志文章,再不记下来就要忘记了…… 《管好你的“隐形员工”》 所谓的“隐形员工”就是:由于感到自己被忽视或不被欣赏,而躲在公司的角落里,发泄着抱怨和不满,以得过且过的态度消极地对待工作的员工,他们渐渐地成为了“隐形人”,还将这些消极情绪传染给新员工。本书就是通过一些实例来说明,优秀的管理者是如何通过建立明确的工作目标、发现员工的杰出表现和庆祝员工的成就来激发员工的热情和活力,从而最终将“隐形员工”转变为企业的优秀员工的。 其实本书主旨挺简单的,到最后就是落到前面段落里的那些加粗显示的文字。如下将记录本书中给出的一些数据和提到的一些书籍: 《Achieving Total Quality》 by Wayne H. Brunetti:你能为员工提供的最大回报就是认真倾听他们的想法以及认可他们的贡献。 第7页:《时代周刊》在2005年2月份曾报告说,80%的员工坚信他们在工作中得不到任何尊重。 第12页:盖洛普民意调查组织对30种行业中10000家公司进行的一项支持性研究中,盖洛普发现那些被认可的员工通常能:提高他们的个人生产力;带动同事的献身精神;更有可能与公司共患难;顾客满意度更高;工作中安全操作记录更多,事故发生率更小。 第16页:2005年65%的美国人认为自己杰出的工作表现没有得到认可。 第27页:据人力资源管理协会调查发现,79%的人是因为不被认可和欣赏而离职的。 《How Full is Your Bucket?》 by Tom Rath & Donald Clifton,《你的水桶有多满》:要想获得良好积极的工作氛围,表扬至少要比批评多5倍。 第40页:“根据我们的记录显示,人员更替的花费其实是每名员工年收入的150%。”布利斯(新泽西州的布利斯联盟公司老板)说道。 《Does God Play Dice? The Mathematics of Chaos》 by Ian Stewart,《上帝掷骰子吗-混沌之数学》 《The One

诺记敏捷之前世今生

不久前诺基亚宣布停产生产塞班智能手机,业内人士和媒体开始热议塞班之败的原因。微博上也有很多网友开始将塞班甚至是诺基亚之败跟“诺基亚不是最早做敏捷的么”关联起来,甚至得出一些类似于“敏捷害死了诺基亚”或者“敏捷也没能救得了诺基亚”之类的结论。作为几乎较完整地经历了诺记(包括前诺基亚网络也即现在的诺基亚西门子通信,简称诺西;以及诺基亚手机部门)。 我叫徐毅,现在在诺基亚功能手机北京研发部门担任敏捷及精益教练,在此之前,我短暂地供职过上海惠普的企业服务业务部门,再往前,就是我至今为止职业生涯中经历最长时间的前诺基亚网络(现称诺西)杭州3G研发中心。诺西杭州最早是在2005年底开始第一个Scrum及敏捷试点项目,我在第二个月以专职测试人员身份加入;2008年开始转为内部的专职敏捷教练;如今在诺基亚功能手机部门。所以,我自认为还是有一定的资格可以跟大家介绍一下诺记敏捷的历史。 当然了,诺基亚和诺西都有着好几万的雇员,业务遍及全世界,而研发中心也有很多个, 业务线也很多,而且诺西除了前诺基亚网络的部分还有合并进来的前西门子通信的人员和业务,所以我不可能可以概括全部,但至少我可以从我所见所闻和所知道跟大家闲聊几句。关于我自己的职业生涯信息,或者其他个人信息,可以通过如下链接深入了解: LinkedIn职涯档案:https://www.linkedin.com/in/kaveri 在下的个人网站:http://kaverjody.com/ about.me页面:http://about.me/xuyi 故事正式开讲。 2005~2006年 前诺基亚网络,IPA 年初我还是一名小小的测试工程师,刚刚被母公司前纬创杭州(=前士通资讯,=前杭州超软)派遣到前诺基亚网络杭州研发中心,作为一名外包方员工加入其3G传输平台系统的软件测试工作。主要担当测试及测试自动化方面的工作,而且也主动加入了当时新成立的Linux平台部门,这也为后来加入试点项目买下了伏笔。 2005年底,吕毅找到我问我要不要加入正在进行中的一个叫ATCA-IPA的项目,他们正在尝试一种叫做Scrum的新式软件开发方式,目前有三名开发人员,需要一名专业测试人员的加入。搜索阅读了大量文章,我并未犹豫多久,就决定加入这个项目。后来我慢慢地才知道,这竟然是敏捷大转型的开端;而且以我所了解的情况,这应该也是国内最早的Scrum试点项目,可能敏捷的个人实践者很多,但一则多是尝试XP实践,二则规模不大,总之,在Scrum这一块,我们应该是最早的先行者了。 项目一直延续到2006年底,我们团队(团队名:Grid;集体投票得出,取意当时热门的网格计算技术)还获得了项目的公开表扬,因为我们不但保证了高产出,而且还很好地探索了当时所知的各种敏捷实践(主要是XP范畴内的诸多实践,包括单元测试、TDD、结对编程等等)。如今我还依然记得在Greenwich会议室里,和李程远、孟贤、周函一起奋斗的场景,也记得我和ScrumMaster许俊因为测试自动化策略和Scrum做法而争得面红耳赤的样子,真是一段美好的时光。 能够在敏捷试点方面有好的成果,后来观察了很多其他组织实施敏捷之后,我才意识到,当年我们能够成功的关键在于我们有极其强大的支持团队。它包括, 业内专家:Craig Larman,Bas Vodde(时任内部敏捷转型团队负责人),和其他我未曾见面的大牛。 内部专家:主要是指我后来也加入的Flexible Company团队,全球范围内支持诺西内部所有敏捷转型。成员包括Petri Haapio等;以及来自内部测试卓越团队的Jukka Savela。 里应外合:吕毅曾师从Ken Schwaber;而我则是对Scrum有着极大的兴趣;后来加入的@秦之远和@hanzhi窦也都对敏捷有着非常积极的态度。 后来团队也变成了两个,项目增加了很多新鲜血脉,没记错的话,@秦之远和@hanzhi窦都是在这个时候加入的。项目将近尾声时,@terry尹哲短暂地担当了一阵子我们团队的ScrumMaster。 遗憾的是,虽然我们在技术、产品(传输平台系统,非面向消费者的终端产品)和敏捷实践方面有着令人瞩目的成绩,但在当时前诺基亚网络和前西门子通信合并的大环境之下,诺记ATCA-IPA产品在权衡之中被领导层决定放弃,转为使用前西门子通信据说已经达到商用水平的系统(不过貌似后来也取消了……),我们的敏捷试点项目也就就此告一段落。 对我来说,个人收获主要在于:体验了Scrum、敏捷开发模式;理解了测试人员如何在敏捷环境下工作(参考我2010年敏捷中国大会的演讲《Be Modern Agile Tester》);参与制定了DI(Development Item)流程中的测试(DIT)流程;尝试了和开发结对,也尝试了和测试结对;等等。 2007~2008年 诺西,3G传输平台研发部 虽然前面的Scrum试点项目因为大环境缘故被取消,但高层很认可其试点效果,于是才有了后续的大范围推广。时任该产品线研发老大的Tero Peltola下定决心,要通过敏捷提升软件研发实力,影响多达五六百人的产品线敏捷转型就此拉开帷幕。时至今日仍在延续,并以扩散至其他产品线,但各个产品线的实施效果则有很大不同,这是后话,这里先不讲。 话说这个敏捷大转型,我后来认为至少有一个极大的失误,那就是,之前的Scrum试点团队人员被直接安排进入下一代新产品研发,而没有被整体考虑放入老产品的600多人里面去散播敏捷知识和经验、促进转型顺畅进行。与之相反,我们采取的是一种Big-Bang形式的转型,直接转为基于Scrum的敏捷模式,就像我常说的,一夜之间,所有的项目经理岗位全部消失,他们必须再选择担纲其他角色,例如ScrumMaster、产品负责人等等(这段记忆或许不对,如有朋友仍记得内情,请不吝告知)。 我自己则跟随着前试点团队直接进入了下一代新产品FemtoGW的研发,和产品线分属两条线各自进行自己的敏捷实践和转型。诺西属于全球性企业,加之刚刚合并,因而也导致FemtoGW面临着三线开发的局面:我们在杭州负责传输平台的开发,意大利米兰负责驱动层部分的开发,而印度班加罗尔则负责应用层的开发。更复杂的是,杭州采用了完全敏捷化的开发方式,而和我们有较强依赖关系(平台依赖驱动)的米兰则选择跟随采取了半敏捷的方式,位于班加罗尔的印度同仁们则依然是瀑布型(应该是CMMI吧)的传统开发方式。 敏捷和瀑布对接所面临的问题,我们就曾经历过一次事件,我个人对此印象很深刻。某天中午时分收到印度同事来信,说他们发现了一个bug,需要我们团队的帮助。我时任团队(团队名:Thunder;取意雷霆一击)ScrumMaster,我判断认为不需要现在打扰团队,可以等到Scrum日会时再告知团队成员并商量处理方案,于是乎,从班加罗尔-杭州这个角度来看的话,我们并未作出回应。让我吃惊的是,下午大概2~3点的时候,又收到对方的一封邮件催促,邮件内容大意是,要求我们尽快或立刻调试解决此bug,他们有50多名测试人员因为这个bug的阻碍而无法继续干活…… FemtoGW项目扩张很快,我们很快又填充了很多前西门子的同事,也增加了很多新招聘进来的同事。不得不说,就我所接触过的那几位前西门子的同事,的确能力很强,包括丁俊华、滕帆(两人最开始都在Thunder,后来去其他团队担当ScrumMaster,也是我们虚拟架构师团队的成员)等,以及和我不争不相识的测试同仁刘哲文。当然,我还见识了出自华为的卢红旭同学敢加班敢熬夜的牛逼精神,就是可惜这小子花了太多时间在炒股上。 王婆卖瓜,自卖自夸。要问我谁最棒,我一定告诉你,那就是我们Thunder团队的兄弟们(包括几位姐妹)最棒!虽然一直都是人来人往,但Thunder的精神却一直延续着。我还记得他们都是(如有遗漏,敬请谅解,并联系我加进来):李程远、丁俊华、滕帆、陆宏斌(后继任ScrumMater至今)、胡振东、张博涛、胡笳、Zhao Congxin(女)、张翠香。我依然记得,曾经,因为Sprint即将结束,我们却被一个小bug给困扰无法通过持续集成,我和陆宏斌、胡振东一起加班奋战到凌晨3点多终于搞定,带着极大的满足感打车回家,但是……等我到家门口一掏裤兜才发现忘记拿钥匙,兜里总共只有100来块前,刚好够打车到公司往返的路费……

Tagged with:
Top