点击这里给我发消息

我的ITblog我作主  关注→ 『伊波拉』→ 测试 SzDlinXie- ITblog     

·√· 本ITblog站点记录相关的软件技术文档、网络技术杂志、测试技术杂谈等技术文档的管理站点.联系方式:MSN:dowling@sunlike.cn QQ:94595885

统计

积分与排名

测试技术网站链接

最新评论

《测试之道》

《测试之道》第一篇——道可道
1、道可道
    老子《道德经》:道可道,非常道;名可名,非常名。
    其实你一切都会,只是看你有没有悟到你的确会。
    说到测试,无论是专业的测试专家还是对策是一无所知的门外汉,首先要提到的肯定是“测试有什么
用?”花那么多的人力物力和金钱做的测试到底是为了什么?”很多所谓的专业书籍对此讲了很多让人眼
花缭乱的理论。
    然而其实很简单,测试就是为了让产品在交付给最终用户以后,在产品生存周期(或提供有效服务的
期限以内),不让最终用户发现其所不能接受的现象。只要能不让用户发现其不能接受的一切现象,至于
产品是否存在bug,用户不会关心;因此IT企业也就没有必要关心。
    最后再补充一点:世界上最浩瀚的是大海,比大海更浩瀚的是天空,比天空更浩瀚的是人的心灵。
    人的心灵里其实什么都知道,什么都会做。
    随心所欲,不滞于物;行云流水,任意所至。独孤九剑的总则便是如此。
 
 
原始连接:http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!145.entry?_c=BlogPart

《测试之道》第二篇——大道如一,过犹不及
2、大道如一,过犹不及
    为了让bug不被用户发现,测试是不是用该做的越深入越好?不止门外汉会这样认为,即便测试业界
的很多一些人也会这样认为。
    《论语》有言:子贡问,“师与商也孰贤?”子曰,“师也过,商也不及。”曰,“然则师愈与?”
子曰,“过犹不及。”
    译为现代汉语就是:
  子贡问曰,“子张和子夏哪个能干?”孔子说,“子张过头了些,子夏不够了些。”子贡说,“那么
是子张强一些了?”孔子说,“过分和不及,同样都不好。”
    所谓大道如一,测试亦然。投入的不够,则会不能在交付给用户之前发现bug;投入的过多,则会影
响收益。过犹不及,二者都不不够好的。
    然而把握这个度还是极难的,没有一个可量化的标准。通常可以做到的就是两害相权取其轻了,对于
容忍力较强的客户,使用“不及”就可以了,用户发现了bug,召回产品打个补丁再重新发布就行了。
“XX产品存在重大隐患,被XX厂商召回”这样的新闻怕是在国内并不少见吧,其他行业如此,IT业能例外
乎?对于重要的客户,就不得不采用“过”的方式了。尤其一些需要“算政治账,不要算经济账”的项目
上更是如此了。
 
《测试之道》第三篇——吴钩霜雪明
3、吴钩霜雪明
    李白《侠客行》:赵客缦胡缨,吴钩霜雪明。银鞍照白马,飒沓如流星。十步杀一人,千里不留行。
事了拂衣去,深藏身与名。闲过信陵饮,脱剑膝前横。将炙啖朱亥,持觞劝侯嬴。三杯吐然诺,五岳倒为
轻。眼花耳热后,意气素霓生。救赵挥金槌,邯郸先震惊。千秋二壮士,煊赫大梁城。纵死侠骨香,不惭
世上英。谁能书閤下,白首太玄经。
    各个待测试的目标系统就是世间各个芸芸众生,测试工程师(TE)就是IT业的侠客。TE离不开测试用例
(TC)就如同侠客离不开剑。无剑不成侠;无合格的测试用例没法做好测试。
    测试十大原则第二条:测试用例必须有明确的预置条件、操作步骤以及与之对应的预期结果。
    IT业界的人员流动,那是相当快的。A先生设计了测试方案,到写TC的时候可能A先生已经另谋高就,
换成B先生在做了,再等到测试执行的时候可能B先生也远走高飞,必须让没有任何测试经验的C同学来做
了。
    这时候如果TC写的不是妇孺皆能看懂,C同学十之八九无法顺利执行。后面最有可能的结果是什么?
    不言而喻。
    不良的TC导致糟糕的测试执行(C同学职业道德如果不是很好,甚至可能故意漏测一些TC,反正这些
TC具体的执行没有人懂,C同学不必承担责任),糟糕的测试执行导致三个结果:其一,不能按计划的方
案验证重要功能导致bug没有在用户面前“躲”起来,进一步企业不论经济还是声誉都受到损害;其二,C
同学为了保证发现足够的bug,于是乎一定会专心致志于寻找一些诸如单词拼写错误,界面错误之类的细
枝末节问题,给coding的工程师们带来一种印象:他们做测试的什么也不会……;其三,在版本不断更新
的过程中,TC肯定需要不断维护,不断进行相应更新,不良的TC导致C同学没有真正去运行这些TC,也就
无从发现这些TC的问题了,从而不良的TC一直被保留到产品发布,然后这些不良的TC又被下一个产品所继
承……继续这些恶性的循环。
    TC如剑。十年磨一剑。花时间细致地写好TC并不是浪费时间和精力。

《测试之道》第四篇——胡马大宛名
 
4、胡马大宛名
    上回书说到TE如侠。侠客离不开剑,也离不开马。就好比郭靖有了汗血宝马,想去哪就去哪,从来不
必担心路程问题;而胡斐追捕南霸天雷老虎,没有宝马良驹,从广东一直追到北京才算完。侠客离不开马
,尤其需要骐骥骅骝,千里良驹。
    杜甫《房兵曹胡马》:胡马大宛名,锋棱瘦骨成。竹批双耳峻,风入四蹄轻。所向无空阔,真堪托死
生。骁腾有如此,万里可横行。
    然则对于TE而言,能够“风入四蹄轻”的千里马何在呢?
    人的精力总是有限的,即便再伟大的TE,对于无穷无尽的测试任务,也总会有感到疲惫不堪,难以为
继的时候。这不是因为TE本身功力不够,也不是因为TE掌中剑(TC)不好,而是缺少了一匹良骥。人力有
时而尽,只有非人力的才可持久;因此这良骥便是且只能是自动化测试(Automation testing)。
    虽然《荀子·劝学》有云:骐骥一跃,不能十步;驽马十驾,功在不舍。然而完全由机器所执行的自
动化测试,不论骐骥还是驽马,全都能够做到功在不舍。因此这时候TE如果只是埋头编写自动化代码便有
失明智了。
    TE可以针对每一条TC编写一段测试代码,然后通过执行这段代码完成对测试目标内容的覆盖;此为驽
马的方法,虽然劳而有功,然而工程浩大,且成本不菲,后续项目的继承性也难以保证。
    TE还可以先创建框架,从测试需求分析开始,与coding的CMM的流程同步,采用迭代的方法渐增完成
测试代码;“随风潜入夜,润物细无声。”当测试执行开始的时候,测试代码的架构已经完成,只需对细
节进行后续维护即可。
    然而还有更可取的方式:TE不要针对每个测试例编码,而是每个STEP编写更小的一段代码。不同的测
试例有可能使用相同的STEP。这种等价于STEP的每一段小的代码(记为cell)可以用STEP的简述进行封装
。例如BS结构的web页面,第一步通常是登录,登录之后跳转到首页。可以采用如下封装:
    login {
        /*input username & password*/
            input_username "xxxxxx";
            input_password "xxxxxx";
        /*check*/
            if (get_new page "//main.htm")
                output "step xxx is pass"
            else
                output "step xxx is fail"
    }
若干个此种简易封装的函数(例如完成了login,download_source,edit_source,upload_source等)完成之
后,TE对于某个测试例(step1:登录xx网站;step2:下载xx文件;step3:编辑刚才下载的xx文件;
step4:把编辑过的xx文件再上传回xx网站。)可以如下编写:
    login;
    download_source;
    edit_source;
    upload_source;
对于使用函数编写测试代码的TE而言,完全不是在编码,只是写一篇简单至极的短文。如果测试例的管理
工具足够强大,甚至可以自动组装函数。至于今后的类似项目,同样可以直接使用这些函数;如果测试例
的管理工具足够强大,甚至可以第一次编写函数之后,一切的测试代码都自动生成。
    只不过到那时,说不好TE是完全被解放了,还是完全被淘汰了。就好似汽车的出现代替了千里马,而
火器的出现淘汰了剑,剑与马都失去了价值的那一天,侠客也就消失了。
 

posted on 2006-12-18 10:19 szdlinxie 阅读(201) 评论(0)  编辑 收藏 引用 所属分类: 测试技术杂志软件测试管理

只有注册用户登录后才能发表评论。
点击这里给我发消息