下面是 ‘测试自动化’ 的汇总

自动化测试和性能分析文章汇总

Thursday, December 13th, 2007

以前总结过很多测试的文章,而且都是断断续续的,现在时隔很久,找起来不很方面,现在做个汇总,方面大家查阅。(此处所列文章全部为原创,转载请注明作者和出处)

自动化测试计划和实施

测试自动化的计划和实施
测试自动化的计划和实施总纲
自动化测试的计划和实施第一阶段
自动化测试的计划和实施第二阶段
自动化测试的计划和实施第三阶段
自动化测试的计划和实施第四阶段
测试自动化需三思而后行
何时以及对什么进行自动化

自动化测试开展

自动化测试的思考和总结之开篇
自动化测试的思考和总结之有的放矢篇
自动化测试的思考和总结之天时地利篇
自动化测试的思考和总结之天下三分篇
自动化测试的思考和总结之平台利器篇
自动化测试的思考和总结之工具利器篇
自动化测试的思考和总结之功利篇

LoadRunner结果分析

利用LoadRunner进行性能测试和结果分析(连载一)
利用LoadRunner进行性能测试和结果分析(连载二)
利用LoadRunner进行性能测试和结果分析(连载三)
利用LoadRunner进行性能测试和结果分析(连载四)
利用LoadRunner进行性能测试和结果分析(连载五)
利用LoadRunner进行性能测试和结果分析(连载七)

测试入门必读
软件测试和质量管理推荐书目

自动化测试不是银弹

Monday, August 6th, 2007

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

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

自动化测试的计划和实施第四阶段

Tuesday, April 24th, 2007

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

好了,现在开始正题。

自动化测试的第四阶段是收获和ROI(投资回报)
(more…)

自动化测试的计划和实施第三阶段

Monday, April 16th, 2007

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

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

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

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

(more…)

自动化测试的计划和实施第二阶段

Thursday, April 12th, 2007

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

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

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

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

(more…)

开源Web自动化测试框架Watir介绍

Monday, April 2nd, 2007

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

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

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

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

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

(more…)

自动化测试面临的十大挑战

Saturday, March 24th, 2007

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

十大挑战

1-购买了错误的工具

2-不适合的测试团队

3-缺少管理层的支持

4-测试类型覆盖不全面

5-不适合的工具培训

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

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

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

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

10-测试工具缺乏实用性

 

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

(more…)

实施自动化测试最合适的语言

Wednesday, March 21st, 2007

实施测试自动化,或者搭建测试自动化平台,完全靠买商业工具是远远不够的,必需要有自己的平台和开发语言,很多时候,开发语言的选择好坏,会直接影响到后期的自动化的顺利开展. TCL(Tool Command Language)作为一款优秀的脚本语言,对自动化的支持非常强大,而且有了Expect的支持,更加如虎添翼了. 下面是一个简单的不能再简单的例子了,作为学习TCL语言的入门足够. 就当是Hello world吧.

实现的功能就是登陆到远程的机器,然后查看一下目录结构.


#!/usr/local/ActiveTcl/bin/tclsh
package require Expect
# Procedure will be used to telnet to a remote machine automatically
proc telnet2Host {host {user wacos} {passwd wacos} {prompt “WACOS>”} } {
set timeout 15
spawn telnet $host
expect {
(more…)


Close
E-mail It