Welcome to my space! I'm a software-testing engineer working at EMC Shanghai R&D center. I am currently interested in automation test, performance test and QA management. I have been as QA engineer over 5 years, and one goal driving me going forward all the way is to test more effectively. My technical background is mainly related to java and linux. You can get me contacted at MSN: lifr_nj@msn.com.

我的最新日志

  • 中秋千岛湖骑行流水账

    2008-9-20

    中秋千岛湖骑行流水账

     

    时间: 9/13-9/15(3天)

    总里程：270

    总骑行时间：15小时42分钟

    平均时速：18.23

    最高速度：51.7

     

    9/13 礼拜六 晴下午阵雨

    早上6点起床，骑车到上海南站21公里，1个小时3分钟。和andy会和后，进站遇到了一个小麻烦，一个穿白衣的中年人装13，非得不让我们进去。好说歹说根本没用。只好先出去，等他走了再进去。还好其他工作人员对我们都是一路放行，我和andy一路狂奔上了车，刚上车列车就启动了。


    一路无话到达杭州东站，然后骑车到浙大玉泉小区旁边著名的青支坞，andy推荐了一家店据说番茄鱼做的不错。吃下来感觉还不错，价格也比较实惠。


    然后在浙大校内留学生公寓住下。本来下午想出去逛逛但不期而遇的阵雨打消了我们的计划，天气预报说台风“森拉克”正在台湾登陆，不禁担心未来两天的天气，不过已经出来了，就且走且看吧。在房间一直呆到晚饭时间，吃完晚饭雨也停了。


    晚上的安排是爬龙井梅岭。夜晚的杭州骑车感觉很好，难得都是林荫道，东拐西拐，到后来就东西南北不分了，还好有人领路。:-)


    梅岭的爬坡不是太长，但也不短，在你到达极限之前就正好结束了，比较适合训练。第二天的爬坡才能真正检验你的爬坡水平的。说起来这也是我第一次骑车爬坡，虽然里程表已经超过5k公里了,---上海没有坡道啊！


    一路冲下来可要小心了，因为这一路车还是比较多的，再加上是夜晚，安全第一，几乎都是拉着刹车下来的。


    下来后开始夜游苏堤(白堤？就是长的那一条)，虽然看不到白天的景色，但两边的波光浆影也别有意思。一路还有市民在跑步锻炼，生活在杭州真是件幸福的事啊。

     

    9/14 礼拜天 晴，时有小雨

    早上一早起来，马上赶到汽车西站乘车到昌化。由于没有走杭徽高速，而且昌化段还在修路，所以到昌化已经9点多了。稍稍整理之后出发。直奔煜岭关。

     

    煜岭关在浙江和安徽的交界线上。开始一路都是平路，骑到白果村已经11点多了，村民介绍“白果”就是杏仁，而且村里还有一颗千年杏仁树王。顺便去参观了一下。出白果村是一段8公里的爬坡，这是第一次考验，在加上临近中午，肚中空空，更是体力的考验。


    然后到达煜岭关下的一个小镇，在路旁找了个小店一人吃了一晚面。面里加了本地的一种辣酱，很香。


    吃完午饭，就开始爬传说中的煜岭关了。


    爬煜岭关感觉还可以，第一个冲上关口。一路上来虽然感觉很累，但没有精疲力竭的感觉，也不用中途休息。


    艰难的上坡之后就是很爽的下坡。一路冲下来创造了最高的数据纪录51.8。下坡过程中可以看到高峡深溪，但由于速度太快，也没有停下来拍照，小小的遗憾。


    现在是在安徽境内骑行。这边风景不错但路面质量让人不敢恭维，都是年久失修的道路。2点多到达三阳镇。穿过镇，左拐又向浙江方向进发。本来以为爬完煜岭关就结束今天的爬坡“赛段”了，没想到当地人告诉我们还要爬比煜岭关更高的一个岭。真是晕菜！一点心里准备都没有。开始担心能否今天到达威坪。


    真正的考验才刚开始！这是一个盘山公路，比煜岭关更长，更陡。似乎绵延得没有尽头。每一次幻想弯道的尽头就是终点，又每一次都被现实无情的击碎。速度已经降到10以下，而且小腿开始跳动。体力已经完全没有了，屁股疼得要命，只能靠意志在坚持。最后，终于缴械投降，停下车来休息。停下来一次就有第二次。在第三次停车休息时，看到lixie也上来了。得知他一直没有休息时，不禁佩服他的体力。


    一般来说无论平路还是爬坡我的速度是车队里最快的，齿比也稍微高一些。但这并不是说我体力最好，lixie以前练过长跑，他的体力实际比我强。爬坡时间长了，他就能超过我了。突然明白了，环法有爬坡王，冲刺王还是有道理的。


    差不多两个小时才爬上来。岭的尽头没想到是一个小镇，叫金川。在这里rp大爆发，尽然爆胎了。被一根铁钉直接穿透。后悔没有多带几个备胎，而且补胎技术也不行，最后还是一个本地小伙子帮忙才把胎补好。前前后后耽搁了一个多小时，提心吊胆上路已经5点多钟了。


    以后几乎都是下坡居多。途中lixie摔车了，因为过弯速度没有降下来，发生侧滑。幸好只是一点小小的檫伤。其实这已经是第二次出情况了，在下煜岭关的时候，henry的车也是因为过弯速度快发生了侧滑，不过还好及时纠正了过来。当时路边就是悬崖，现在想想真是后怕...


    金川到威坪可能有50多公里,但我们骑了20公里不到天就黑了.这里是山区,路边几乎没有人,而且温度也下降得很厉害.在又冷又饿的骑行中,每个人都在想今晚会如何度过.


    沿着盘山路下来,终于看到了一些灯光.这是一个叫"合富"的村庄.本来希望能找一个地方住宿一晚,但这里没有旅店.没有办法,只有夜行. 夜行是非常危险的,因为看不清楚路面, 而且这里还是山路,但我们当时感觉这边路况还不错,比较平坦,2个多小时到威坪应该问题不大. 没想到这段路出了这次最大的情况。


    这时已经下起了雨,我们分成两个group,前面是andy,lixie和henry, jingming和我在后面.其中只有andy和jingming有前灯，但是jingming的前灯还不太亮。


    大约骑了几公里，雨越来越大，在一个下缓坡的路面，我们的速度可能在20左右，andy他们三个已经和我们拉开了约30米的距离，我和jingming有差不多5，6米距离的样子，突然我看到jingming一下子飞了出来，车也倒在了路旁。停车下来，我看到jingming已经躺在地上，表情比较痛苦。我把他扶起来发现手上有血，这个时候前面的andy也回过来了。情况还是比较严重的。有4处檫伤，而且手上虎口的伤口还比较深，好半天才止住血。lixie带来了酒精棉和创可贴。没有绷带，我把袜子剪了（没有穿过的*_^)。


    现在回头想想，当时jingming没有头盔也没有手套，几乎没有任何保护设备。没有头部受伤和骨折实在是大幸。


    andy果断决定马上回头，推车回到了合富村。首先找到了医生包扎了伤口，医生说没有大问题。我们都松了一口气。然后又找到了村支书，一个热心的中年人，他让他老婆给我们做了晚饭，又腾了个房间给我们过夜。第一天行程终于结束，不过无论是过程还是结果都是我们都没有想到的。

     

    9/15 礼拜一 晴

    早上合计了一下，lixie陪jingming乘车返回杭州，andy，henry和我继续骑行。


    从合富村到威坪这一段还是山区，气势比较雄伟，景色也很秀丽。到威坪后，转向千岛湖镇，这一路就是环湖公路了。这段路是理想的骑车路线。首先是路况好，能保持27以上，如果体力好的话平路保持30没有问题。第二是风景好，穿行于湖光山色之间，心情愉快。而且更绝的是间或还有隧道和少量的爬坡，想冲冲坡也有机会。要是没有第一天的高强度，骑这一段应该是比较休闲，比较惬意的。但因为第一天体力透支，而且当天气温也高了一点，所以骑到后面还是比较suffering.


    在这个过程中我还发生了一件比较囧的事情。我竟然把包丢在路边的一个候车亭了。发现的时候已经过了半个多小时。马上打的回去看到包竟然还躺在那里。以后不能再发生这种事情了。


    到淳安县城已经1点多。赶紧买了回杭州的大巴票。然后到KFC补充弹药。andy本来还打算到千岛湖边去玩玩水，但大家都累的动不了了，留待下次吧。


    下午4点10分的车回杭州。车还没有开出淳安城就下起了倾盆大雨，难到这就是传说中的台风“森拉克”？！不过我们也一点都不关心了。


    6点多到杭州，马上向火车站骑。在西湖边骑车发现杭州豪车真多，名不虚传。又看到西湖上面的月亮好圆好亮。下车随便拍了几张。


    杭州站自行车上火车一点问题都没有。再次在心里问候上海南站的装13男他家人。


    一路无话，到达上海南站，然后上地铁一号线到火车站站，出来后沿着周家嘴路平安到家。结束这次 中秋节千岛湖骑行。

     

    查看(11) 评论(0)

  • 编程对测试人员意味着什么？

    2008-8-31

    编程对测试人员意味着什么？


    老毛说“不破不立”，从我个人的看法我是完全否定当前“编程是测试人员的必备技能”的说法和后面的逻辑，我否定把编程能力拔的如此之高的说法，这是“破”。 那么在这篇文章我要“立”，从我个人经验出发说说“编程对测试人员意味着什么？”

     

    首先要说，我并不是狭隘的“QA主义“者，也并不反对测试人员学习编程，提高编程能力。而是我们要对编程对测试人员的作用有一个清晰的认识。

     

    从我个人来说，可以说我一直以来就是编程能力的受益者。

     

    我这6年的工作中，从职位来说5年是在做QA，只有最开始的一年在做Dev，但一直以来我就没有停止过编程的工作。开始是用c/c++,然后是java，ruby，现在用得比较多的是bash。我做过c51单片机程序，j2ee项目，用python和ruby开发过比较复杂的自动化测试系统。商业测试软件使用过robot，qaload，等等。我写的代码质量丝毫不比一个普通的开发人员差。

     

    但是我并不打算学好编程技术而转行去做Dev，也并不是为了做自动化测试而学习编程。大部分的时候我的职位是一名黑盒测试工程师，我热爱这个工作，并且一直干得也很出色。只有一段短暂的3个月我是全职的性能测试工程师，但当回到黑盒测试的时候，我发现我依旧非常享受发现bug的过程。

     

    最开始的时候，我只是因为喜欢编程而编程，就像我喜欢测试而去做测试一样。所以我把大量自己的业余时间花在学习编程和软件设计开发上，后来我渐渐发现，编程能力也是软件测试的能力的一个重要方面，因为编程能力能让你更高效的测试。

     

    即使你不是自动化测试工程师，也并不打算去做白盒测试，我仍旧强烈建议你学习一门通用的脚本语言，在ruby/python/perl中选一种，如果还有时间和经历，再学习一门通用的编译语言在c/java/c#中选一种。

     

    举一个例子，我现在测试的系统在安装好之后需要在命令行进行一些繁琐的配置工作，这些工作是重复而且容易出错的（我的记忆力不好）。后来我写了一个expect脚本来帮我完成所有这些工作，一个命令就搞定了。所以不但我节约了时间，而且我可以以最好的状态去开始真正的测试。

     

    这样的例子，太多了。毕竟，我们工作的对象和环境就是程序和程序构成环境，很多地方都有程序的用武之地。比如测试中需要一个包含100，000个文件的目录。几行代码就能完成手工不可能完成的任务。

     

    追求更高效的测试是一个测试人员不断提高自己水平的动力之一，在这一点上编程能力真的有意想不到的作用哦。

     

    作为总结，我想说我对编程能力对测试工程师的作用的看法是，它很重要，但并不是核心的能力。它，是为了让我们更高效的发现bug，那才是测试工程师最核心的能力。

    查看(85) 评论(0)

  • 编程是测试人员必备的技能吗？

    2008-8-31

    编程是测试人员必备的技能吗？

     

    现在经常能看到“编程是测试人员必备的技能”这样的观点被提出。支持它的理由是：编程能让你进入自动化或者性能测试领域，这样你才能成为一名高级的QA。

     

    我要说这个观点和后面的逻辑都是完全错误的。

     

    首先自动化测试对工程师能力的要求和黑盒测试几乎完全不同。优秀的自动化测试工程师，并不必然就是优秀的黑盒测试工程师。实际上我更愿意把自动化测试开发看成软件开发的一种。

     

    其次，优秀的自动化测试工程师，更不是必然就是高级的QA工程师。在企业里，高级QA工程师的一般要具备下面的能力或知识：


    • 寻找bug的能力 ---- 最核心的能力，其实是综合能力的体现
    • 系统分析的能力 ---  主要在设计testplan和testcase时候体现
    • 追踪问题的能力 --- 和dev的debug一样，QA需要从一个最表面的问题追踪到自己能到达的最贴近问题发生点的地方
    • 宽广和深厚的技术背景  --- 操作系统，编程能力，网络等，各个企业侧重点不一样


    在企业里，人们希望高级工程师能负责起一个产品的测试，带领一个team完成从testplan到最终release给客户这个过程中所有QA需要完成的工作。

     

    请注意，编程能力只是测试工程师众多能力要求的一个，而且还不是核心的功能，更不是必备的。其次，我并没有列出行业背景知识。对于高级QA工程师来说，行业知识就像剑客手中的剑，--重要的是剑术，而不是剑。在这里要顺便鄙视一下面试里全是自己公司产品相关内容的公司。

     

    抛开上面所有教科书里对高级QA工程师的要求。一名高级QA工程师的工作实际上能增强Dev，manager对产品的信心，能带动整个QA team的测试效率和激情。总之，他的工作是专业的，不可替代的和值得尊敬的，和常规印象里对黑盒测试工作的“低级，没有技术含量”的印象完全不同。

     

    所以，

     

    如果你只是被月薪XXX这样字样吸引进入软件测试行业，那么我要给你泼冷水，因为初级测试人员的工资肯定低于初级开发人员。

     

    如果你是Dev并因为某种原因被迫转到QA，但并不屑于干“简单，没有什么技术含量”的黑盒测试，那么你完全可以马上转到自动化测试，那里你可以重新找到coding的快乐。

     

    如果你是测试培训机构，那么我要说，忽悠吧，继续忽悠，你的QTP培训班生意肯定会更好。

     

    但是，如果你真的热爱QA这个行业，真的想成为一名受人尊敬QA工程师。那么抛开这些眼花缭乱的浮云，放低自己的心态，踏踏实实从一名黑盒工程师干起，你会在成长的过程中体会到QA工作给你带来的乐趣，收获你的工作为你带来的价值。

    查看(90) 评论(1)

  • 软件测试并不仅仅是按照testcase测试

    2008-7-12


    软件测试并不仅仅是按照testcase测试
    有一种普遍存在的看法是 软件测试 只是一个没有什么技术含量的工作，任何人只要能读懂testcase就能做软件测试。或多或少地，在我工作过的每一个公司都有人这样的观点，特别是规模小的公司更甚。

    当然，这是一种完全错误的观点。

    如果我们把软件看做是一个圆球，那么软件测试的目标就是尽可能的覆盖最多的球体表面。。

    所有的testcase的集合可以看做是一张试图包住整个球体的网，而一个testcase就是网上的一个节点。可见对于这张网来说，最重要的不是它的节点的数量而是节点的布局。testcase应该覆盖整个球体表面，但也不应该有太多的节点堆积在某一个区域。

    一个良好设计的testcase集合需要对软件的深刻理解，很高的抽象能力，还要在覆盖率和可执行性之间保持平衡。对这些能力的要求，相比于其他的设计工作，比如软件设计，并无二致。

    如果说testcase本身只是一个节点，它并不能覆盖更多的区域，那么一个测试人员实际的测试行为就像一块在围绕在点周围的布，才能填补网格中空白部分。有多大区域能被测试行为所覆盖，这是一个衡量测试人员能力的关键要素。

    好的测试人员在测试的时候所做工作远远超过testcase本身。实际上，这也是对测试人员的一个基本要求。测试人员应该通过各种方式扩展testcase，比如改变参数，调整前置条件，从多个角度来观察系统行为，使用不同的方法等等来尽力覆盖更多的内容。

    研究显示，在一个项目中，超过3/4的bug并不能仅仅根据testcase的descrīption得来。那也就是说，一个好的测试人员相对于一个仅仅根据testcase来测试的测试人员，其发现的bug数可以是后者的4倍之多。

    所以软件测试的工作也许看起来简单和直接，但事实是，实际的工作远远超过testcase本身。

    以下是本文的英文版。(following is the English edition)
    =========================================================
    Software Tester Offers More Than Just Test Cases

    Some people think that software testing is a low skill job, and that just any one can be a tester.  This is definitely not true.  Allow me to explain why.

    If we represent the software being tested as a ball, then the aim of the software testing is to cover as much of the space of the ball as possible.

    Test cases act together as a net, attempting to cover the ball.  Test cases act individually as a node in that net.  So the most important aspect of a test case is not its amount, but its structure.  The test case should cover the entire surface of the ball, but without too many nodes in any one place.

    A well designed test case requires a deep understanding to the software, high ability of abstraction, and skills to balance between the coverage and testability.  The requirements are not that different from other forms of design work.

    To continue the previous analogy, the actual test behavīor is like a piece of cloth wrapped around the node; there to fill spare space left by nodes.  How much space your real test behavīor can cover is one key standard to measure the capability of a tester.

    Good testers test far more than the test case descrīption.  In fact, it’s an essential requirement.  They will extend the test case descrīption by changing parameters, adjusting preconditions, and using many different means in order to try to wrap more space around a single test case.

    One investigation showed that over 3/4 of all bugs found, are not directly related to test case descrīptions.  That is to say, the number of bugs a good tester can find can be 4 times as many as that of a tester who simply follows the test case descrīption.

    So the job of software testing may seem simple and straightforward enough, but the truth is, the actual effort expended is much greater than just a simple test case.

    (Thanks to Kyle for fixing errors of the original version)

    查看(30) 评论(0)

  • Everbright, a tool kit helping build up test with Watir, hosted in Rubyforge.

    2008-5-10

    I'm glad to announce that a project "Everbright" has been lauched in Rubyforge aiming to provide a tool kit by using which it can become easier and more efficient to build up test with Waitir from scratch.

    As we know, Watir is a great library, but it does not mean to be a framework, a switss knife, an another "QTP". So a lot of extra assistant work must be done if you are going to test a web site with Watir, such as Loging, Reporting, handling xls document, etc.

    Yes, that' is exactly what Everbright will bring to you. Everbright is a collection of classes/utilities I wrote to resolving problems in my previous projects, and I'm sure very likely you will meet them again.

    Try it and enjoy Ruby&Watir. You are welcome to contrribute your code.

    The project url: http://rubyforge.org/projects/everbright/



    查看(24) 评论(0)

  • vimrc

    2007-12-19

    set nocompatible
    source $VIMRUNTIME/vimrc_example.vim

    "source $VIMRUNTIME/mswin.vim
    "behave mswin

    "-----------------------------------------
    " tab and indent
    "-----------------------------------------
    set softtabstop=4
    set shiftwidth=4
    set expandtab
    set smarttab
    set autoindent

    colorscheme darkblue

    "-----------------------------------------
    " edit
    "-----------------------------------------
    set ruler
    set backspace=2
    set nowrap
    set number
    set lbr
    set tw=500

    "quickly move cross/delete word in insert mode
    imap <C-Left>   <C-o>b
    imap <C-Right>  <C-o>w
    imap <C-BS>     <C-o>db
    imap <C-Del>    <C-o>dw

    map <C-Return>  $<Insert><CR><ESC>      

    "-----------------------------------------
    " search
    "-----------------------------------------
    set is
    set ic
    set hlsearch
    "set noignorecase
    nmap <F2> :nohlsearch<CR>


    "-----------------------------------------
    " move
    "-----------------------------------------
    " scroll
    map <c-j> <c-y>
    map <c-k> <c-e>

    "-----------------------------------------
    " tag
    "-----------------------------------------
    "taglist
    nnoremap <silent> <F8> :TlistToggle<CR>
    let Tlist_Show_One_File = 1

    "for develop everbright
    "set tags=c:\\ruby\\lib\\ruby\\ruby.tags,d:\\CVSProject\\projects\\app_testing\\auto_test\\main\\bin\\everbright.tags

    "-----------------------------------------
    "edit vimrc
    "-----------------------------------------
    map <F11>       <ESC>:edit $VIM\_vimrc<CR>
    map <F12>       <ESC>:source %<CR>

    "-----------------------------------------
    " buffer
    "-----------------------------------------
    set hidden

    map <C-Tab>     :bnext<CR>
    imap <C-Tab>    <ESC>:bnext<CR>
    map <C-S-Tab>   :bprevious<CR>
    imap <C-S-Tab>  <ESC>:bprevious<CR>
    map <C-D>       :w<CR>:bdelete!<CR>
    imap <C-D>      <ESC>:w<CR>:bdelete!<CR>

    "-----------------------------------------
    " leader command
    "-----------------------------------------
    "shotcut with mapleader
    let mapleader=","
    let g:mapleader=","

    nmap <leader>w :w!<cr>
    nmap <leader>f :find<cr> 
    nmap <leader>bn :bn<cr>
    nmap <leader>bp :bp<cr>
    nmap <leader>bd :bdelete<cr>

    " with 'dd', to add/delete new line in normal mode
    nmap <leader>o  A<cr><esc>
    nmap <leader>O  I<cr><esc>

    "-----------------------------------------
    " abbrevs
    "-----------------------------------------
    "general abbrevs
    iab xdate <c-r>=strftime("%Y-%m-%d %H:%M:%S")<cr>


    "-----------------------------------------
    " autocmd by FileType
    "-----------------------------------------
    " run scrīpt. not work. why?
    autocmd FileType vim    nmap <buffer> <F12> :w!<cr>:source %<cr>
    autocmd FileType ruby   map <buffer> <F12> :w!<cr>:!ruby %<cr>

    "-----------------------------------------
    " others
    "-----------------------------------------
    set nobackup "no backup. that's ~file
    set autowrite
    set go-=T "remove menu and boolbar
    "auto change dir to the file currently being edited
    set autochdir

    map <F5>        <C-l>

    "favourity filetypes
    set fileformats=unix,dos,mac

    "no sound on errors
    set noerrorbells
    set novisualbell
    set t_vb=

    "format statusline
    set statusline=\ %F%m%r%h\ %w\ \ CWD:\ %r%{getcwd()}%h\ \ \ Line:\ %l/%L:%c

    "-----------------------------------------
    " functions
    "-----------------------------------------
    set diffexpr=MyDiff()
    function MyDiff()
      let opt = '-a --binary '
      if &diffopt =~ 'icase' | let opt = opt . '-i ' | endif
      if &opt =~ 'iwhite' | let opt = opt . '-b ' | endif
      let arg1 = v:fname_in
      if arg1 =~ ' ' | let arg1 = '"' . arg1 . '"' | endif
      let arg2 = v:fname_new
      if arg2 =~ ' ' | let arg2 = '"' . arg2 . '"' | endif
      let arg3 = v:fname_out
      if arg3 =~ ' ' | let arg3 = '"' . arg3 . '"' | endif
      if &sh =~ '\<cmd'
        silent execute '!""C:\Program Files\Vim\vim70\diff" ' . opt . arg1 . ' ' . arg2 . ' > ' . arg3 . '"'
      else
        silent execute '!C:\Program" Files\Vim\vim70\diff" ' . opt . arg1 . ' ' . arg2 . ' > ' . arg3
      endif
    endfunction

    查看(32) 评论(0)

  • bash learning

    2007-12-19

    这两天读了 Advanced Bash scrīpt Guide和shell 十三问。有一些有意思但以前自己不懂或混淆的东西。记下来如下。


    *) local，在函数内部定义有限作用域的变量
    > function foo { A=aaa; echo $A;  }
    > A=bbb; echo $A; foo; echo $A
    bbb
    aaa
    aaa

    > function bar { local A=aaa; echo $A; }
    > A=bbb; echo $A; foo; echo $A
    bbb
    abc
    bbb

    *) {} and ()
    {} like a anonymous function
    () commands in () will be executed in subshell
    > A=aaa; { A=bbb; }; echo $A
    bbb
    > A=aaa; ( A=bbb; ); echo $A
    aaa

    *) (())和let，整数计算
    > a=1
    > ((b=a+1))
    > echo $b
    2

    *) 子进程与父进程的变量访问
        1）子进程可以 看到 父进程的变量，因为它有父进程变量的copy
        2）子进程不可以 访问 父进程的变量
        3）如果要让 子进程 可以访问父进程的变量，那么父进程要export该变量
        3）父进程既看不到也不可以访问 子进程的变量。

    *) source(或 .) 会在当前进程里执行，就象在命令行输入的一样

    *) 管道会以子进程来运行

    *) "-"可以替代 “标准输出”或标准输入“
    它在管道中特别有用，可以避免管道broken，比如
    > echo "xxx" | cat -

    注意，"-"是由应用程序解释的(这里是cat)，而不是bash

    *) 退出码
    0表示true，其他都为false


    *) CTRL 命令
    ctrl+c terminate a foreground job
    ctrl+z pause a foreground job

    ctrl+d 1) log out. similar to 'exit', 2) EOF, used in inputing HERE doc
    ctrl+g bell beep
    ctrl+l clear scree. similar to 'clear'
    ctrl+s freeze STDIN
    ctrl+q resume STDIN
    ctrl+u erase a line of input, from cursor to begin point


    *) 对${}的扩展
    一般来说${varName}是对变量的引用，但bash在此基础上提供了一些对字符串处理的扩展。

    替换
    1) ${varName/src/dst}是对变量字符串的替换，把第一个src用dst来替换
    2) ${varName//src/dst}是对变量字符串的替换，把所有src用dst来替换

    子串
    ${varName:pos}
    ${varName:pos:len}

    ${#varName} 取得字符串长度


    *) echo的参数
    -n 不要换行
    -e 可以使用'\'转义
        \a      bell beep
        \n      new line
        \t      tab
        \123    octal
        \x123   hex

     

    查看(45) 评论(0)

  • testcase的写法,重于"形"还是重于"意"

    2007-11-17

    做QA已经4,5年.看到的testcase也不少了.有自己写的有别人写的.testcas的风格很变化多端,有些步骤详细得让一个新人都可以没有任何困难得跑一遍,有些呢,可能仅仅是一段描述的语言加上一个matrix,精炼得让第一次跑它得人无从下手.

    那么到底有没有一种最优得写testcase得策略呢?

    现在这个公司得做法给我了一些启示.它得testcase有两个特点
    1) testcase    没有细节得描写.也就是说它重"意"得表达.

    testcase的任务是说明:做什么(summary),怎么做(steps), 得到什么(verify).在怎么做的描述上,尽量避免对细节的,特别是UI细节的描述.

     

    这样的好处是 testcase的表达更清晰了,避免了淹没于细节之中,第二个是可维护性增加了,特别说细节界面得修改不会导致testcase修改.

     

    这种风格的testcase第一次跑很困难,但以后就心领神会了,"只需痛苦一次"

    2)     有很多testcase是模版+matrix自动生成得
    可能设计者觉得,步骤表述加matrix简单的结合显得指导性不够,那么用一个模版+matrix,按照排列组合的方式生成testcase可以一定程度弥补不足.

    使用这种方法.testcase的维护性大大提高,而有不会太多的损失testcase的指导性.

    查看(65) 评论(1)

  • 再见锐柯：别了，金桥的船

    2007-9-29

    湖光荡漾，绿树匆匆，柿子红了，杨柳飘飘。引三五朋党，闲庭信步，看水鸟剪影于小岛building之间，轮卵石跳跃于湖面波光之上。斜坐木椅之上，高谈阔论，微风扑面，鸟语花香。各位，这不是公园，这是我们中午午餐后游湖的真实写照。

    有人说，有了水，风景才有了灵性。在上海这个寸土寸金的地方，金桥软件园竟然在园区中间有一个人工湖。怎一个NB了得。

    回头想想以前吃了午饭在电脑前发呆的场景，恍如隔世啊。

    一直就观测到湖边停了一艘小船，但从没有看到有人使用，此船何用？是不是软件园免费提供给大家游湖用的呢？那怎么没有人上去划船呢？终于有一天，咱们再也按耐不住，登得船来。

    在水上和在水边是完全不同的。一个是静止的看，一个是悠闲的划。粼粼水波，是那么的近啊。旁人羡慕的目光，让我们更是得意，湖面的空气，更清新，湖面的风，更轻柔，湖面的太阳，。。。。更晒人啊。还好，可以划到湖心小岛的后面，森森凉意扑面而来，沁人心脾，这里是水鸟的家，和它们问个好吧。

    突然，吆喝四起，狼奔豕突。原来是保安杀到了。没办法，弃船走人吧。以后在也没有机会划船了吧？

    别了，金桥的船。

    查看(291) 评论(0)

  • 再见锐柯：土法炼钢

    2007-9-29


    大公司做什么都是有板有眼，讲究流程。甚至锐柯专门有个Team就是搞流程相关的东西。佩服一下先。不过对我这样从小，中型的IT公司出来的人来说，有点不以为然：繁文缛节何其多也？！

    来公司一个月后，终于有活干了。做一个性能测试项目，而且还只有我一个人做，但后期需要别得team合作。兵马未动，plan先行。Manager说你搞个schedule吧。行，怎么做我心里也基本有数了，excel里填了几行把大概的阶段写在里面，发过去了。

    “你这个就是土法炼钢！“，一句话把我的schedule打回来了。然后乖乖的装上Project，细细谋划起来。几经折腾，最后发现原来一个schedule里面包括这么多内容啊。

    写代码，写文档，培训，试运行，准备环境，安装环境。。。。什么时候做什么事，全得写上。即使开发阶段也要写明那段时间实现那些功能。我抱怨“这些进度根本就是未来的事，未来的事怎么说得准呢？“， “也许现在定的时间并不准确，但这是一个基础，项目进行中可以调整。但没有这份文档，怎么调整？“。说得有道理哈，不愧是Manager。

    终于project schedule写好了，然后纠集几个人review一下，存档。前后花了几天时间，值得吗？
    虽然自己是散漫得人，对这种详细计划的东西比较天然的抵触；但做了第一个schedule后，对“计划“有了更多的认识。在做schedule的过程中，真的也能想到一些漏掉的事情。比如有些事要和别的team配合的，那么早点写出来，通知他们，比自己事情做好了，再去通知他们，等他们准备好了，再进行下一个步骤效率要高。提高效率是我最感兴趣的东西。这一招以后也要用下去。

    再来说做得很好看得schedule是给manager或boss看得。我们engineer是干活的，所以任务下来，脑筋一下子就跳到怎么做，用什么技术…，但怎么干Manager是根本不感兴趣的，能不能按时完成，多个项目间配置资源等才是他感兴趣的。所以详细的schedule能帮助他了解，掌握项目的进度。

    当然，我也觉得，有些东西还是不能安排太细。太细的安排往往都是要改动的，而且实行起来也繁琐，比如做一点点事，就要去修改或填充schedule，最终只会做了很多工作然后一次行填完了事。这样的schedule就是形式主义了。“形式主义害死人啊“，要不得。Schedule的粒度要适中，特别是多人，多team的事务安排是它的长处，可以充分利用。

    当然，以前一个人做什么事也有个大致计划，但这个计划自己心里清楚就行了，不必写出来。别人就看你一天忙来忙去。突然有一天，“嘭“，盖子掀开，所有的东西都做好了，任务完成，变魔法一样。这样的风格在锐柯这样的大公司是行不通的。

    查看(113) 评论(0)

Open Toolbar