发布新日志

  • TCL脚本的历史

    2007-02-01 23:11:32

    如果要做自动化测试,首选语言是Tcl,大家不要一提TCL就想到做电器的那个TCL公司,这个Tcl非那个TCL,这是一种功能强大的脚本语言,全名: Tool Command Language. 自从2003年初次接触自动化,我就跟这个语言结下了不解之缘. 做自动化,有Tcl还远远不够,Tcl的一个强大扩展Expect也是不能不提的, 想想看,如果没有这些个强大的交互式命令语言,怎么能真正把大家从电脑面前解脱出来.

    Expect提供的基本命令很少,spawn, send,expect应该是最最常用的三个了吧.依靠这三个简单的命令,可以完成非常强大的工作,写一个脚本,自动执行,是多少程序员,测试人员梦寐以求的事情啊.

    说Tcl的历史,就一定要看看下面这篇文章:
    Tcl脚本的历史

    Tcl的下载可以到官方地址

    另外,中文方面的资料也很多:
    Tcl的中文网站


    如果要系统学习Tcl,有一本权威的教材,一定要看,吐血推荐:


    上次团购,我们team的人现在可是人手一本啊, ^_^
  • 利用sed处理好看的报表

    2007-02-01 23:10:22

    前阵子做性能测试的时候,系统工程师有个要求,所有的性能测试项目提供一份vmstat的结果作为参考,最好能做出性能的曲线. 做曲线这么艰巨任务就只能由Excel去完成肋,我们所要做的就是把vmstat的结果输出为一个标准的格式文件,步骤如下:

    1. 首先利用vmstat -n 5 10 > vmstat.csv把结果输出到一个文本文件中. (不过solaris好像没有-n :) ,只能自己想办法去掉)
    2. 利用利器sed把其中的第一个空格去掉,命令如下:
    :1,$s/^ //
    我尝试了N次,都没能成功,居然把行首的^给忘记了,自责中...
    3. 利用sed把其中所有的空格替换成, 这样csv格式就可以直接被打开,利用如下的命令:
    :1,$s/ \+//g
    这个命令也有一段来历,刚开始尝试的时候用的不是+而是*,结果每次都把后面的所有内容都替掉了,后来在伟大的Grant同学指点下(一个冰淇淋换来的)用转义后的+解决. 不过为什么*不用转义,而+需要转义一直表示不解,直到看了如下解释:

    [grant@autotest16 test]$ man grep

    ……………………………

    In basic regular expressions the metacharacters ?, +, {, |, (, and )

    lose their special meaning; instead use the backslashed versions \?,

    \+, \{, \|, \(, and \).

    ……………………………


    4. 把替换好的格式文件,传到Windows,然后用Excel打开,并通过简单的操作,得到如下漂亮的图案.

  • 自动化测试总结和思考系列之平台利器(原创)

    2007-01-31 13:57:09

    上周休了一周的假, 在医院照顾老爸
    这周继续自动化测试的思考系列,今天谈谈平台建设.

    自动化测试一般来说,随着产品的不同,都会有不同的测试架构和测试平台,稳定和合适的平台对于一个产品的自动化测试来说,相对来说相当重要,有了合适的载体和工具,自动化测试就能很好的扩容和执行.

    一般来说,自动化测试的平台包含以下一些方面:

    测试管理部分--管理不同产品,不同版本的测试用例
    测试执行部分--执行测试用例
    测试维护部分--测试用例的维护,版本控制等
    测试资源部分--测试资源特别是实验室资源的管理
    测试调度部分--测试的调度,控制和执行中心

    一 般来说,这几个部分可以集成于一个平台本身,也可是独立的子系统,通过接口有机的结合起来,其实市场上也有很多商用的产品,比如Mercury的QC (Quality Center, Test Director的后续版本)就覆盖了其中的测试管理,测试执行等, Rational的Test Manager覆盖了另外一些部分等等.

    因为这些商业工具相对来说,价格比较昂贵,而且对具体产品的适应能力等方面的考虑,不一定适合所有的公司,因此我们自己开发了自己的相应的系统.

    测 试执行平台:我们的测试执行平台其实覆盖了测试执行部分,测试维护部分和测试调度部分,是一个很强大的平台,从最初的1.0版本,到现在的2.1.1版 本,基本可以支持我们公司的绝大多数的产品,另外测试管理的部分也有一些涉及,但是相对来说比较薄弱,特别是版本管理部分,目前是通过和测试管理工具的接 口来实现的,我们正在改进这些薄弱的环节.

    测试资源平台:我们也有一个自己开发的资源管理平台,可以预定实验室的各项资源,并用于测试,目前我们在测试执行平台预留了资源的相关接口.这部分跟具体的产品联系比较密切.

    总体来说,下面这个图能详细说明这些部分之间的一个关系和接口.




    下图是我们自己的测试执行平台的架构:



    其中
    ATS: automated testing system
    LRMS: lab resource management system
    TMS: test management system
    (转载请注明出处)
  • 自动化测试总结和思考系列之天下三分(原创)

    2007-01-31 13:55:52

    对于自动化测试的组织划分,一般来说,在企业内部,有两种结构: 隶属于系统测试部门或者专门的自动化测试部门.

    我所经历的自动化测试部 门,就经过这么一波三折的过程,首先始于系统测试部门的一个team,专门为这个产品的系统测试服务,自动化也就仅仅局限于这个产品的系统回归测试. 随着自动化程度的不断提高和管理层的重视,自动化测试也逐步发展壮大,服务的部门也从仅仅是系统测试部门的回归测试拓展到集成测试,单元测试等等. 服务的产品也从单一的产品扩大到整个公司的产品. 这是一个必然的过程. 专门的自动化测试部门有利于从整个公司的角度协调各种资源,所以是必然的.

    在 自动化测试独立成单独的部门,角色一般是这样:有一个经验丰富的自动化经理,负责全局的统筹和管理. 对于不同的产品或者不同的系统有资深的自动化测试专家/自动化测试主管, 下面会有专门的自动化测试工程师,对自动化测试工程师甚至资深自动化测试专家要求首先有过开发经验,并且有一定的测试经验,做过手工测试,这个必须的,另 外,对相关的产品要比较熟悉. 另外对资深自动化测试专家要求对被测系统的架构有全面和深刻的理解. 另外可能还有一些自动化测试工程师或者测试工程师, 来执行相关的自动化测试用例. 这些测试工程师要求对系统要相当了解,可以从手工测试部门抽调过来,也可以本身就属于系统测试部门, 这样就是一个虚拟的泛自动化测试部门.

    有了组织结构,就可以进行自动化测试了吗,当然不, 首先自动化测试需要以来很多的因素,自动化测试平台就是其中一个,下节重点介绍自动化测试的平台建设.
  • 自动化测试总结和思考系列之天时地利(原创)

    2007-01-31 13:54:14

    昨天谈到自动化适合的产品,今天简单聊聊何时开始引入自动化最有效.

    自动化测试的建设不是一蹴而就的,首先自动化测试的发展依赖于手工测试.
    一般来说,手工测试进展到比较成熟的阶段,公司有完整的手工测试流程,相应的手工测试工程师具有一定的编程经验或者脚本开发经验,这个时候引入自动化测试才会比较有效.

    相反,如果一个公司或者一个产品基本的手工测试都很不完善和规范,测试的质量也得不到保证,更谈不到测试的覆盖率,这个时候贸然的想通过实行自动化来提高测试的质量或者测试的效率.失败的机会就会非常大了.

    完 善的自动化测试流程和规范不是简单的几个文档就能解决问题的,而是要把这种流程或者规范彻底贯彻到每个测试工程师身上. 测试用例如何写? 产品规格说明书更新及时不及时?有没有符合本公司的测试管理系统? 测试报告能不能按时提交?等等一系列问题,不是简单停留在是否存在几篇文档或者开几次会议就能解决的问题.

    现在国内我知道好多朋友所在的 公司,看到自动化测试不错,可以提高效率,节省人力,老板就拍脑袋也要搞自动化,好像搞了自动化测试,公司的测试水平就能提高一个台阶,产品的质量就能得 到保证. 其实他完全没有看到自动化测试的另外一面. 另外,居然还有人理解我引入了几个自动化测试工具WinRunner, QTP, LoadRunner, 我就是自动化测试了. 大错特错了.
    关于测试工具和自动化测试的话题,后面会有讨论.

    一个公司或者一个产品在引入自动化测试之前,一定要进行详细和客观的评估.
  • 自动化测试总结和思考系列之有的放矢(原创)

    2007-01-31 13:52:01

    对于自动化测试适合的产品,或者更精确到哪些测试测试适合做自动化,已经被广泛的讨论过.总体来说, 有如下一些:

    1. 首先是回归测试,这是勿庸置疑的.
    利用自动化来进行回归测试,不仅可以把测试工程师从枯燥无味的繁琐测试中解脱出来,而且可以腾出更多的时间设计更多更好的测试用例,提供测试的覆盖率和测试的质量.
    2. 其次是部分性能测试
    对于一些性能测试,比如系统容量或者系统并发用户的测试,因为资源的限制,利用手工测试有很大的困难,有时候条件也不允许,充分利用一些自动化性能测试工具,就可以很好的完成测试目的.
    3. 还有就是利用手工很困难或者根本无法完成的.
    有的时候,需要进行一些压力测试,离开工具可能比较困难,这个时候就可以发挥自动化的长处.
    4. 还有就是产品趋于稳定,变化小,这样的产品更适合与自动化,我们就曾经在一个产品很不完善的时候进入到自动化,结果耗费了巨大的人力,最后产品变化了,自 动化测试脚本和测试用例重用性不好,基本全废了. 其实这也需要产品和软件本身应该满足一些可测性要求. 并在前后的版本之间保持接口的统一. 细节来说,就是配置哪怕是基本的日志都必须满足一定的规范. 否则自动化测试进展起来就比较困难.

    另外,无论针对任何产品的自动化测试,都会存在一些普遍的问题:
    1. 自动化测试不会比系统测试发现更多的bug,或者说自动化测试更重要的是帮助快速验证产品经过更新或者修改之后的质量.如果要发现更多的潜在问题,必须进行手工测试.
    2.对于频繁变化的产品,自动化测试的维护成本很高,这点反复强调,就是因为我们在这方面走过很多弯路,往事不堪回首啊~~
    3.通过自动化测试没有发现缺陷并不能代表说一定没有缺陷存在,没有权限的系统或者产品是不存在的.
    4.自动化测试对环境的依赖远远大于手工测试对环境的依赖,针对自动化测试的环境问题,因为牵涉到的问题比较多,后面打算专门讨论这个问题.
  • 自动化测试总结和思考系列之开篇(原创)

    2007-01-31 13:50:14

    自己从事自动化测试三年了,经历了很多的波折和教训,当然也积累了些许的经验,很久以来一直有想法把这些内容系统的记录下来,对自己来说,轻装上阵,更好的探索以后的自动化怎么走;对别人来说,也算提个醒,哪些错误最容易犯, 需要避免什么样的误区.
    最近看了很多的论坛文章,感觉大家都很茫然,测试怎么做, 刚入行的, 在这个行业打拼了几年的,大家对前途都没有太多的目标,也许只能好好反省自己的过去,总结一下自己过去犯过的错误,回过头去,才能更好的认识前面的路.
    罗嗦了这么多,现在开篇,本文打算以系列的形式连载,主要都是自己的经验和教训的回顾,所以有时候想到哪儿就说到哪里,不会刻意去组织很美的文字,不过我会尽量使文章能表达我的意思. 这个系列目前大致想分为几个大的部分:

    • 自动化测试的适合产品
    • 何时引入自动化
    • 自动化测试的组织结构
    • 自动化测试的平台建设
    • 自动化测试的支持和维护
    • 自动化测试和自动化测试工具
    • 自动化测试的管理保证
    • 自动化测试和回归测试

    下次着重讲讲自动化测试的适合产品.
  • 我的个人技术博客

    2007-01-30 13:30:15

    大家可以去访问我的个人技术博客,每天定时更新,尽在

    天行健,君子当自强不息


  • 在这地方也安营扎寨了

    2006-12-28 18:31:13

    在这地方也算安营扎寨了

    我的地盘

292/2<12

数据统计

  • 访问量: 38202
  • 日志数: 29
  • 图片数: 2
  • 书签数: 1
  • 建立时间: 2006-12-28
  • 更新时间: 2007-05-14

RSS订阅

Open Toolbar