在无忧测试上看到这样一篇文章,关于自动化测试流程的讨论,其中的大部分观点我是认同的,比如自动化测试的适应对象,自动化测试脚本的质量保证. 有些观点有待商榷,希望有机会和这几位版主切磋.
下面是讨论原文:
早上看到我们的学员发的一个贴子是关于自动化测试流程的一些问题。我也参与了讨论，感觉还不错，呵呵，就整理了一下搬到博客上来，和大家一起分享、交流。
==============================================
wssgily:
我想请教几个自动化测试流程.
请问大家,你们公司的自动化测试是什莫阶段开始介入的?
自动化测试的入口和出口准则是怎样定义的？
大家又是如何保证自动化测试的质量的？
从自动化测试决策的制定到决定进行实施,这中间有很多工作要做.包括说服你的老板,自动化是一个持续投入的过程,而且初期投入很大,短期内无法看到回报,而且要持续进行投入,不能半途而废,投入的过程中需要各个部门的通力合作,上至包括系统分析师,研发人员特别是研发部门经理,项目经理.下至系统测试部门等等,每个环节都跟自动化测试有着直接和间接的关系. 一旦决定开始进行实施自动化测试,就基本上没有回头的道路,因为前期的巨大的投入,导致如果想要中途终止,那么前期的巨大投入就是严重的资源浪费.
开头讲了一点题外话,现在开始介绍实施的第一阶段-从无序到有序.
我参与的这个产品的自动化项目开始于二零零三年初,从一开始就缺少经验, 我们走过的每一步现在回想起来都是痛苦的经历.因为大家都没有类似的自动化经验,加上团队的每个成员基本上都是开发出身,加上项目进度紧张,缺乏必要的自动化测试理念和自动化测试的相关培训.更严重的事,这个时候,自动化刚刚起步,没有一个自动化的平台支持. 结果是每个工程师把一个单独的自动化测试项目(一个模块)作为一个独立的工具进行开发.结果导致自动化测试用例的混乱,而且无法进行维护.不同工程师开发出来的东西也是千奇百怪.自动化团队的工程师慢慢的失去了耐心和信心,产生了抵触情绪,这个为以后的自动化测试的顺利开展带来了一定的障碍.
这个时候的教训就是不能急于求成,不能为了一味的追求速度和效率. 自动化团队的经理应该控制项目的节奏,不能妥协于项目的巨大压力. 逐步培养自动化开发工程师的兴趣和探索动力.
另外就是自动化团队成员没有系统全面的培训和严格的规范约束,即使每个人都有能力开发出来自动化测试脚本,但是却难于维护和执行.这个时候我们就认识到自动化测试平台或者架构的重要性不仅仅在于使得测试脚本的开发更加容易进行,而且可以统一大家的思想和测试脚本的一致性. 在这之前我们对自动化测试平台的认识比较肤浅.
在不同的阶段,自动化团队的成员构成也不尽相同. 在这个阶段,自动化团队的成员基本上都是自动化开发工程师.就是把手工的测试模块进行脚本化. 然后可以自动化进行执行.
测试自动化的计划和实施系列文章,最近开始酝酿思路,初步打算分为四个部分来组织, 这也是我亲身经历的一个自动化项目的四个阶段,大家可以对号入座,看看你所在的公司或者组织处于自动化实施的哪个阶段?
第一个阶段: 从无序到有序
这个阶段主要是自动化测试的引入,从一开始的无序的自动化测试,摸着石头过河, 到慢慢找到一些窍门,其中的关键点/转折点是自动化测试系统或者说自动化测试平台的出现. 这个时间大概持续了1年左右. 这部分重点介绍如何找到通往有序的方法和思路.
第二个阶段: 从烦杂到豁然开朗
这个阶段主要介绍基于原始的自动化测试系统开发积累到一定程度的问题显现. 逐步暴露的问题在这个阶段到了非解决不可的程度,主要的问题是什么? 解决的思路是什么? 到也是我们自动化测试进展最艰难的时候.希望能对你有所帮助.
第三个阶段: 从点到面铺开
这个阶段主要介绍自动化测试系统和平台的推广, 好的平台是推广和大面积使用的前提和保证.如何保证平台在推广过程中能顺利? 推广过程中我们遇到了哪些阻力? 我们是如何解决这些阻力和克服困的?
第四个阶段: 收获和ROI
这个阶段分析在自动化测试推广以后的一些问题,我们应该如何计算我们的产出和投入,投资回报应该如何计算? 这个阶段我们会遇到什么问题? 如何解决?
最近一直比较忙,可能时间不是很连续,初步打算再五一之前能完成这几篇文章. 希望大家有耐心 ^_^ ,同事也希望能多听听大家的意见和对文章的期望.
昨天测试同行讨论会的时候陈华的一番话,使我收益颇多,很多时候我们做一件事情的,并不是不知道我们需不需要做,我们事实上知道我们需要. 我们需要做什么很清楚,需要做成什么也可能很清楚.问题的根本是我们应该如何做? 我们在做的过程中可能会遇到什么问题? 我们应该解决这些问题? 更进一步,我们应该如何避免这些问题? 我理解为这也许就是我们经常说的最佳实践吧. 就比如说测试自动化的计划和实施吧. Grand问我应该注意哪些,我当时随机的列了大概七八条注意的因素.这些都是可能会遇到问题或者至少需要注意的地方.
我接触测试自动化也算比较久了,参与过几个比较大的产品的测试自动化的计划和实施,也积累了一些经验,我们在实施的过程中曾经也遇到了很多的挫折和困难,走过了一些弯路,也算总结了有些教训. 另外,在不同的阶段我们曾经了遇到的问题也不同,而且解决问题的方式也多种多样的. 技术上的问题,组织上的问题,管理上的问题,流程上的问题等等.
就如Grand所说,如果能把这些问题加以提炼,总结,升华,对自己是一个总结. 对别人也许能带来帮助. 所以我打算从下次开始,把我这几年来从事自动化测试的一些实施过程中遇到的问题加以总结和汇总. 并在测试同行交流会中跟大家交流. 同时在会陆续把一些反馈和讨论的过程发表在这里. 希望大家多多支持和关注.
最近几个朋友都在聊,他们公司打算进行自动化测试了,头让他们负责来弄这个东西. 貌似这两年测试自动化比早三年前收到重视的程度大有提高,好像大家不提自动化测试跟不上潮流似的,测试没有做好,质量没有改善就是没有做测试自动化一样. 其实很多公司是真心想把测试最好,他们进行了一些探讨,做了一些研究之后才得出的结论. 有些人做测试自动化完全是另外的目的的.其实我在这里并不关心他要引入测试自动化的动机,只是想说,大家都意识到测试自动化的重要性了,而且觉得这是一个提高测试覆盖,改善产品质量的途径. 其实国外早在20年前就已经在研究测试自动化了. 并不是所有的公司都适合做测试自动化,也并不是所有的产品都适合,不同的行业,不同规模的公司做测试自动化,也不能照搬别人的经验,而是要根据自己公司的实际情况,实际的测试流程进行规划.否则失败的可能性很大.
Double Think Before Action. 三思而后行, 测试自动化是一个系统的工程,根据我以前的经验,我们在进行测试自动化之前,要自己问一些问题给自己,如果能很好的回答,或者能做一些风险评估,有充分的思想准备:
1.我们公司的测试流程完备吗?不要指望测试自动化能改善你的测试流程,如果没有很好的手工测试流程,测试自动化一定会失败.
根据我以前的经验,测试自动化最适合的测试类型应该是系统测试,特别是系统的回归测试.但是最近看的一本书<Just Enough Test Automation>中的有些观点,改变了我的一些看法,在这里跟大家分享一下.
对于单元和集成测试,自动化测试是不必可少的.为什么?因为如果没有自动化,用于测试的构建版本质量就会很差.结果本该在开发阶段发现的问题,留到了系统测试工程师了.(其实这里我认为有一个错误的观点,那就是认为系统的缺陷是测试出来的,其实这个问题的正确认识应该是系统的缺陷是设计和开发出来的,另外一个方面,单元测试和集成测试级别引入自动化,还需要保证系统的功能足够稳定,否则在这个阶段进行自动化测试,频繁的改动就会造成系统的自动化测试脚本维护成本很高,我在以前的自动化测试过程中曾经吃过这方面的亏,我们是在系统测试阶段引入的,可是产品本身不够稳定,付出了高昂的维护代价).
三年前,Rosa领导我们刚开始做自动化的时候,故事和历程跟文章描述的如出一辙,大家都是摸着石头过河,走过了不少的弯路,也取得了不少的进步. 现在想想,真的要感谢那段日子,使大家学到不少的教训,而且总结了不少的经验,这对于我后来做测试大有好处.
Overview
Over the last five years, I’ve had the opportunity to work in a group who writes
automated tests using retail Windows applications to ensure compatibility in future
releases of Windows, and to find bugs in the operating system. During that time, we
have transitioned from having no standards to having a strict set of guidelines to follow
when writing new automated tests. We have seen many benefits as a result of developing
standards. In this paper, I will talk about these three areas:
1. Why there is a need for standards in test automation
2. Things to consider when developing test automation standards
3. Methods to ensure everyone adopts and follows the standards once they’re written
With the exception of my first project team out of college, in every project team since, I¡¯ve had to explain either what automated testing is, why we need to do it, or what value it brings to the project. This can be difficult as each time I explain automation, I have to battle different preconceptions and experiences. Sometimes I even find myself having to develop a basic understanding of testing and software development. Wouldn¡¯t it be great if every project manager had to have a testing background or at least actual development experience? Probably not, I¡¯m sure that would introduce all sorts of other problems. The point is it is a unique and difficult battle every time.
你正在浏览的汇总是: 测试自动化
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Oct | ||||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
