天行健，君子以自强不息

自动化测试到底是不是银弹？ 关于银弹的说法，有这么一个传说：
美国人相信在月圆之美国人夜, 狼人便会出没, 而杀死狼人的唯一方法便是用银制的子弹(Silver Bullet)贯穿它的心脏.
[There is no silver bullet]: 意为没有致命, 有效, 一击命中的方法
下面这篇文章，作者 Dawn Haynes 来自：IBM，2005年的一篇经典文章，分享给大家。

没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。Brooks鼓励我们将技术和方法视作一种演进手段，而并非革命。将自动化技术引入测试工作时，我倾向于支持相同的观点。
阅读全文 »

Share This

第四阶段，也是最后一个阶段了。在开始这个阶段之前，还想多说几句，今天又有朋友说他们公司打算实施自动化测试了，开发经理主导的。他们对测试自动化的认识还是停留在自动化测试工具上。只是十分要命的。自动化测试的初衷是要缩短测试周期，出发点是好的，但是步骤明显有问题，测试周期的缩短是可以靠提高测试效率，改进测试方法和引进测试工具来达到的，但是不是决定因素。测试流程的规范才是最根本的，如果一个组织测试流程不规范，想通过引入自动化测试来规范这一流程是很不现实的。

好了，现在开始正题。

自动化测试的第四阶段是收获和ROI（投资回报）
阅读全文 »

Share This

回归测试做为测试中最重要，同时也是最复杂的一种测试类型。一直都是大家关注的焦点。转载一篇关于回归测试的概述，这篇文章从回归测试的基本概念定义、回归测试的测试策略包括测试用例的维护和更新，回归测试用例的选择、回归测试的实施步骤等都做了较为详尽的描述。更从回归测试的角度阐述了自动化测试对于回归测试的重要性。如果要详细了解回归测试，强烈推荐此文。

一、 概述

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。

阅读全文 »

Share This

进入到自动化测试的第三阶段，此时距离当初开始实施自动化测试的决定，两年三个月已经过去了，可见自动化测试的实施不是一蹴而就的，更不可急功近利。第三个阶段的标志是有点到面的全面铺开。

自动化测试开展的初期，可以是一个小组，几个人进行小面积的试点，这样投入的成本不是很大，即使失败了，也是可以理解和接受的，而要想取得投资回报或者大面积的试用和推广，前提的试点也是必须的。 但是仅仅靠几个人是不可能把自动化测试做起来的。自动化测试的开发工作是一个持续的过程，又是一个矛盾体。

持续的过程体现在：随着回归测试的不断进行，老的功能不断被自动化起来，就有一定的维护工作量，另外，新功能的测试不断完善和稳定，又变成可以进行自动化测试的老功能。所以自动化测试是一个持续进行的过程，另外，又是一个持续改进的过程，随着自动化测试技术的不断成熟和测试业务的不断丰富，以前的老功能的测试用例或者测试脚本也同样需要进行更新和维护。

矛盾体体现在两个方面：首先自动化测试的开发和维护本身需要对测试脚本和测试业务有一定的熟悉。实际情况往往并非如此，精通测试业务的测试工程师一般情况下对测试脚本甚至自动化测试一无所知。而对测试开发非常熟悉的自动化测试工程师又不熟悉业务，所以矛盾就这样产生了。另外，从整体来看，自动化测试工程师的数量肯定远远小于手工测试工程师，这样，对业务测试工程师熟悉自动化测试知识，了解测试平台和测试脚本就提出了更高的要求。如果有一半的测试工程师都能熟悉测试脚本，可以试用测试平台进行相关的自动化测试开发，那么可以肯定的说：自动化测试已经成功了一大半。

阅读全文 »

Share This

自从上个月介绍了自动化测试的计划和实施第一阶段，这阵子一直都在忙别的事情，加上博客访问断断续续，所以没有接下去。打算利用这几天的时间把剩下的几个阶段完整的记录下来。也对打算实施自动化和已经在实施自动化过程中的朋友有点帮助吧。另外，也完成自己的承诺，五一之前完成这几篇文章。嘻嘻。

第二阶段的副标题：从烦杂到豁然开朗

其实这是我们经历的真实的过程，从一开始的没有完整的自动化平台和对平台重要性的认识不足，加上缺乏相关的经验，这个过程可谓吃尽了苦头。这这个阶段，即使有了测试平台的支持，随着脚本技术的进步，我们仍然要为以后的维护和扩展付出很大的代价。

这样的痛苦过程经历了大概半年左右的时间，当随着脚本技术的探索思路越来越清晰的时候。其中最关键的里程碑是API概念的提出，就是一个分层的概念。其实也没有多少创意而言，只是在自动化测试概念中提出来，颇有一些不同。

阅读全文 »

Share This

你还在为QTP的昂贵license费用而发愁吗?

你还在为web的自动化测试而担忧吗?

现在隆重向大家推荐一款开源的web自动化测试框架Watir, 周六的时候跟Jackei老兄探讨,他跟我推荐的这个Web测试框架非常灵活小巧,而且功能也不弱. 大家如果有时间可以试试. 下面是转载Jackei的一篇试用手记,原文链接:

Watir 是一个使用 Ruby 实现的开源Web 自动化测试框架，相对于那些庞大的商业工具来说，它很小巧，也很灵活，提供的功能也足够用。最近抽时间试用了一下，感觉还不错，准备下一步在公司推广使用。

因为 Watir 的网站上用户手册、示例代码以及 FAQ 都维护的不错，所以已有的东西我

阅读全文 »

Share This

关于自动化测试的一些挑战,之前我根据自己的浅薄经验也总结了一些,这篇是转载的Randall的一篇文章。G_Win翻译的。其中很多观点跟我们之前经历的是一致的。不过本文更侧重于从测试工具的角度来阐述自动化测试面临的问题和挑战。废话少说，现在开始。

十大挑战

1-购买了错误的工具

2-不适合的测试团队

3-缺少管理层的支持

4-测试类型覆盖不全面

5-不适合的工具培训

6-对测试工具认同度不够

7-对被测目标缺乏基本的认识和理 解

8-脚本维护和配置管理上的问题

9-测试工具的兼容性及协作能力不 足

10-测试工具缺乏实用性

接下来分别阐述10大挑战及其应对办法

阅读全文 »

Share This

从自动化测试决策的制定到决定进行实施,这中间有很多工作要做.包括说服你的老板,自动化是一个持续投入的过程,而且初期投入很大,短期内无法看到回报,而且要持续进行投入,不能半途而废,投入的过程中需要各个部门的通力合作,上至包括系统分析师,研发人员特别是研发部门经理,项目经理.下至系统测试部门等等,每个环节都跟自动化测试有着直接和间接的关系. 一旦决定开始进行实施自动化测试,就基本上没有回头的道路,因为前期的巨大的投入,导致如果想要中途终止,那么前期的巨大投入就是严重的资源浪费.

开头讲了一点题外话,现在开始介绍实施的第一阶段-从无序到有序.

我参与的这个产品的自动化项目开始于二零零三年初,从一开始就缺少经验, 我们走过的每一步现在回想起来都是痛苦的经历.因为大家都没有类似的自动化经验,加上团队的每个成员基本上都是开发出身,加上项目进度紧张,缺乏必要的自动化测试理念和自动化测试的相关培训.更严重的事,这个时候,自动化刚刚起步,没有一个自动化的平台支持. 结果是每个工程师把一个单独的自动化测试项目(一个模块)作为一个独立的工具进行开发.结果导致自动化测试用例的混乱,而且无法进行维护.不同工程师开发出来的东西也是千奇百怪.自动化团队的工程师慢慢的失去了耐心和信心,产生了抵触情绪,这个为以后的自动化测试的顺利开展带来了一定的障碍.

这个时候的教训就是不能急于求成,不能为了一味的追求速度和效率. 自动化团队的经理应该控制项目的节奏,不能妥协于项目的巨大压力. 逐步培养自动化开发工程师的兴趣和探索动力.

另外就是自动化团队成员没有系统全面的培训和严格的规范约束,即使每个人都有能力开发出来自动化测试脚本,但是却难于维护和执行.这个时候我们就认识到自动化测试平台或者架构的重要性不仅仅在于使得测试脚本的开发更加容易进行,而且可以统一大家的思想和测试脚本的一致性. 在这之前我们对自动化测试平台的认识比较肤浅.

在不同的阶段,自动化团队的成员构成也不尽相同. 在这个阶段,自动化团队的成员基本上都是自动化开发工程师.就是把手工的测试模块进行脚本化. 然后可以自动化进行执行.

Share This