随笔点滴

                                 ——第47期51Testing深圳软件测试沙龙

差点杯具

之前深圳沙龙也有报名，但是由于种种原因没能去成。这次原本计划也是要加班了，但由于进度有点延迟，没有测试版本，测试不用加班。所以能参加第47期51Testing深圳软件测试沙龙非常庆幸。

王老师的风采

本次沙龙由51Testing创始人之一王威老师担任主讲，在之前单位的时候上过几次王老师的课 ，渊博的知识、丰富的经验与诙谐讲课风格，让人非常受教，所以沙龙通知出来我就在祈祷，千万不能加班啊。再加上这里主题“高效的测试需求分析和测试用例设计”是我比较关注的方向。这次，王老师渊博的知识在51Testing自主研发的全球首款测试分析设计工具TestPlatform（TP）演示下，将“高效的测试需求分析和测试用例设计”这个抽象的主题讲的更清晰明了。

TestPlatform（TP）

把这个工具作为一个小标题不知道会不会被人认为给51Testing作广告的嫌疑，但是个人觉得，这真是一款很不错的工具。因为我之前也上过“测试需求分析和测试用例设计”的课，也做个这方面的工作。那时候上课和工作中都是用的表格，自己把分析的规格复制粘贴，相当不方便，还有一些逻辑或者方法的问题，给学习和分析带来不少困惑，至少让我很困惑。什么继承分析，交互分析，正交集成，都需要人去思考分析。而这款工具把这些复杂的东西作为算法，做到工具里面了，在使用的时候只要舒服分析的内容，很多东西都可以让工具本身去解决了。这就使得工作变得非常方便。具体的其他好处就不说了，不然真的成了打广告的了。

测试的技术含量

这款工具让我更加肯定，软件测试有技术含量的不是自动化工具或者会编程，会使用LR，而是测试思想。这种思想是站在产品一定的高度，对整个测试过程进行统筹规划和设计，这些完成了就是实现问题了，就是LR高手，编程高手（测试编程）就开始忙了。打个比方说，之前的工具、写在纸上的设计方发都是招式，而测试思想就是口诀，没有口诀的招式，就会是些花架子，对付一般的（表面上的东西，如简单的功能测试），遇倒高手（比较复杂的问题）就束手无策了。很多人可能会有这样的感受，从书上看到的设计方法或者工具使用法，感觉也精通了，但是真正用到实际上，尤其复杂系统的测试上，就感到无从下手。我想这个跟软件架构师的设计思想可以类比一下吧，架构师属于技术类较高级别的职位，他们在长期的实践中积累了一套设计思想，让他们在设计中如鱼得水，东西设计好了，那就是程序人员去实现的问题了。当然这是要不断的学习、实践和积累的。

两个小故事

    在王老师的演讲过程中，我想到两个小故事，应该绝大多数都听过，一则是《庖丁解牛》，另一则叫《磨刀不误砍柴工》。不知道为什么会想到这两个故事，但是我觉得其中还是有一定的联系的吧。等哪天参详透了，再跟大家分享吧，有高手也可以点拨一下俺……

沙龙内容

    沙龙过程中，对沙龙内容简单了做了笔记，因为以后51还有把胶片和录音上传的，所以只简单的罗列一下王老师PPT中的内容（见附录）。

现场问答

     按照惯例，在主讲奖完后，是现场提问环节。个人觉得，本次沙龙更适合高级测试工程师和测试经理或者主管参加，从提问环节更可以看出来，提出的问题多数跟本次主题无关，主要都是多数人常问的问题，比如测试的职业发展，进度紧，留给测试时间少的情况下怎样保证产品质量，没有需求怎么做测试设计等……对此环节没多少印象了，只对王威老师关于职业发展的一个问题的回答印象比较深刻，主要意思是干一行爱一行，打好基础，以后无论往哪个方向发展都能够胜任……具体可以听现场录音。

其他：

1、沙龙开始前，来了一个嘉宾，被邀请到第一排的位置，而他觉得显得太高调了，不愿意。后来有幸得到一张名片，才发现乃某某公司研发总监，果真低调。

2、有幸跟一些公司测试方面的负责人进行测试发展和个人职业方面的交流，还有幸认识了51testing深圳负责就业工作的两位美女老师……

3、还跟嘉宾就当今社会形势和经济等作了热烈讨论

(是不是越来越像新闻稿了……不要打我啊，马上打住)

小结：总得来说，此次沙龙收获蛮多的，不仅仅是与沙龙主体相关的，还有许多与主体无关的……测试界需要沙龙，需要百家争鸣，在争鸣中推进测试的发展和个人素质提高，希望以后能多参加这种活动……

附录：

（沙龙内容，笔记不是很完整，见谅）

一、测试用例质量的判定

       1、对需求的覆盖率

  2、用例的精确程度

  3、测试用例发现缺陷率

  4、可执行性和执行效率

二、测试分析设计常见问题

     1、方法、技术

1）测试需求分析

2）用例设计方法

3）被测是产品的可测试性

4）产品相关的业务知识

2、流程、工具

  1）测试用例设计的合理性和测试用例设计的效率

  2）测试需求分析工程师和测试设计工程师分工

  3）对需求到测试用例的全面跟踪和变更管理

  4）针对多个版本继承的测试用例的搞笑裁剪和补充

3、人

1）基本素质

2）技能培养

3）业务知识

三、典型测试分析模式

1、与开发分析过程相对应的测试过程

业务需求分析       需求项管理

需求规格分析       测试项分析

概要设计           测试用例规划

详细设计           测试用例实现

编码               执行

2、典型的测试分析模式

（具体内容请看胶片）

ZZ FROM  金鑫的日志  测试窝




（一）

长期游走各类测试论坛，当然包括测试窝啰。同时工作实践中，带过的测试新人朋友也不少了。给我一个较为普遍的感受，作为一个新人，想要尽快掌握被测产品业务，尽快提升
测试相关技能。是否具备知识积累的能力？与此同时，是否具备一套行之有效的积累方法。显得格外重要了

身处软件这一行，在这个资讯爆炸的时代，大家单凭脑袋要记住所有的信息，几乎是不可能的。(除非有记忆面包可以吃) 。而在工作、学习的过程中，我们通常不会要求自己或
别人一定要具备怎样的理论或技能之后，方能开展某种具体的工作。

实际上大家都是先碰到问题，再开始有针对性学起来，经过一系列的搜索资料，学习、实践直至处理完手头的问题之后。很多朋友往往是如释重负、“挥挥衣袖”，倘若很长时间之
后又遇到类似问题。不得不再一次的搜集你的记忆神经，不好彩！！！自离破碎的记忆不足以支撑问题的处理，试想又一次的检索、学习、实践的 Action(貌似回放脚本时，还得
稍上int&end)只怕在所难免。甚者，往往不惜透支自己的"知识积累"，处处寻求高人解围、或是发帖求助等诸如此类的做法，比比皆是起来...

当然本文的初衷并不是摒弃“勤学好问”的优良传统，只是寄语更多测试新人、或是工作经历不长的朋友：软件测试行业与其他的IT行业岗位一样，需要持续充实大量的计算机、互
联网、工具使用、各种理论等，量级庞大的信息。掌握好一套适合自己知识积累方法，可以帮组大家少走弯路。

所以，有机会去interview新人的时候，我一定会问的问题，就是“请问你常在哪些网站搜集，跟学习，而又通过过怎样的方式记录下来”。身为一个靠IT 吃饭的人，如果他的回答
是“我会用纸笔记下来”，或是“用Word、笔记本记下来”，我接着就会问，那你遇到重复的问题，怎么找。如果答不出来这两个相关的问题，除非他是白纸一张新人，不然我会对他
简历上的"积极好学、学以致用..."大打折扣啰。

那么如何做到的知识积累有效性呢？分享我自己的习惯，具备一些特性：
1、要能操作便利以便迅速的纪录下我要记的东西；
2、要能具备检索功能（大言不惭的说，有些文章，还能让搜索引擎收录了），以便我可以在最短时间通过关键字找到我想找的内容；
3、要能容易分享，通过过分享才能与其他人讨论，或是接受别人的拍砖、批评，或是可以解决了人家的问题；
4、要能跨机器，跨地域。也就是这些信息可以网路存储的 ；



（二）

接着上篇，本文介绍一下个人觉得适合整理知识的一些常用工具，供大家参考：

A、写博客，身为一个软件测试工程师，又或软件从业人员，每每碰到问题后，解决问题的方法，就如同测试过程发现缺陷时的信息，是最佳的Test Case一样，这么有价值的资讯，
一定要想办法记录下来，因为你会碰到这问题，一定会有其他人也会碰到。如同每次测试完成更新用例一样，记录下来，可以让自己经过知识管理内化、外显的过程，更深深的了
解这问题的本质， 可以让其他碰到问题的人快速找到解决方式，可以让下次自己在碰到这问题时，马上有sample code可以用，可以 证明自己学习是有方法的，可以证明自己是
有分享的热忱的。有着很多热心助人的博客前辈们，我们没必要害怕自己的文章没有价值，不要害怕人家的指导或是指正，因为最后的受益者，还是自己。关于博客站点，很多了，
想必不用我说大家应该知道的比我多吧？有条件的朋友还可以使用 WordPress  或 GoogleSite搭建功能强大的个性化的博客或站点

B、FreeMind,FreeMind是一款跨平台的、基于GPL协议的自由软件，用Java编写，是一个用来绘制思维导图的软件。其产生的文件格式后缀为.mm 。可用来做笔记，脑图记录，脑力
激汤等。个人常用来，对于多头绪的工作任务安排，可以非常有效梳理。类似的还有Xmind :http://www.xmind.net/拿来随手记录想法，或是整理读书心得、会议记录、
Roadmap跟task清单相当不错的工具。格式可转换相当多，包括转成freemind的格式、HTML、图档、Open Office格式。而Freemind可以额外转成pdf，以及可互动式的XHTML，还有
提供xslt的自订导出格式，以及一些wiki的格式。

C、书签，习惯用Firefox的Xmark，除了把记录都记在server端以外，还会有同步书签的功能，建立自己的帐号后，还可以在Xmark的网站上通过网页搜寻、整理、分享和预览。请
见：http://www.xmarks.com/(目前本人觉得chrome的Google书签，也不错，可以随时随地通过网络同步最新的个人收藏)

D、文件同步，之前很长一段时间使用Google文档 功能，可以很有效的同步、编辑与分享各类常用文档、表格、PPT等。而且通过Google表格自带的表单功能，设计表单，还可以作
为部门内部一些日常工作的记录与入库（非数据库，指的是在线表格），不过目前Google的产品使用起来很麻烦。至于如何能顺利使用，FQ的功夫，大家比我熟练吧，呵呵

E、RSS，RSS客户端工具有很多，目前个人认为还是Google Reader最为靠谱，强大的同步功能，可以选择喜爱或是分享。实现了知识共享的集群效应。个人认为这也是Google中国
离开后，仍然没有yan割这个功能的原因吧！不过maybe你常见到，现在的Google Reader有时无法打开你之前的某些订阅吧，不妨试着更改一下协议试试，哈哈
最近看到一款工具Feedly（http://www.feedly.com/）还没试用，不过据说，提供很强大的介面跟user experience，UI很好用。当然除了UI好用之外，提供了Firefox的plug-in，
可以随时在浏览网页的时候，都可以把相关的信息submit回去feedly或其他方式share出来。另外，feedly也会根据你订阅网站的内容，提供一些相关你可能也有兴趣的网站供你
订阅。而每一篇文章，又可以通过很多不同的方式在上面直接share，例如Gmail, Facebook,Twitter等一堆在当下很是杯具接口中发布，而且这款工具目前还有了支持chrome的插
件下载，值得大家尝试。

F、另外，习惯经常阅读PDF资料的朋友，可以使用PDF-XChange Viewer工具，这是一款我用过最好用的PDF reader，重点是可以额外在上面加注记的功能，简直快可以媲美word里
面的批注了，同时PDF-XChange Viewer搭配DropBox，还可以实现何时何地都可以继续阅读同一份PDF啦!



结论


每次发现了不错的文章，有用的资料，或是从问题中学到了技巧，没有纪录下来，就错失了增加知识积累极高价值的机会。

千万千万不要相信自己的记忆力，通过最近的两篇短文，希望能帮组大家寻找适合自己的学习方式，这条路上，不仅自己会很有成就感，还且也会有很多贵人相助。试想一下，
这样的习惯外加一段时间的积累，不成专家，你都难哦！！！

抛砖引玉一下，如果你还常常为不知如何积累知识而苦恼，不知道该如何记录、分享、搜寻知识，也算是我的建议了。

http://www.cnblogs.com/stbchina/ ... o-Owns-Quality.html
原文地址： Who Owns Quality?

作者：Alan Page， 微软卓越测试工程总监，How We Test Software at Microsoft (中文翻译为《微软的软件测试之道》)一书的作者之一。

翻译：樊聪、林俊彦


       应Adam Goucher的要求，再贴一篇《微软的软件测试之道》的文摘。顺便说一句，Adam写了一篇关于《微软的软件测试之道》的书评， 但Linda Wilkinson的书评以标题胜出（译者注：Linda比Adam早用了同样的书评标题）。

       这是第16章的一部分，有关于质量的。我对这部分内容深信不疑，也希望能够听到你的观点。

       多年前，当我提出“谁应对质量负责”这个问题的时候，得到的答案几乎都是“测试团队应该对质量负责”。现在我再问这个问题，答案通常是“每个人都应该对质量负责”。有些人或许觉得这是个不错的答案，然而软件工程研究所（SEI）的W.Mark Manduke曾这样写到“当质量被宣布成为每个人的责任时，就意味着没有人真正被指定为它负责，质量问题也就淹没在如今各种紧急情况之中，无人搭理了。”他得出结论：“当管理层真正确立了一个质量文化，每个人才会确确实实地对质量负责。” [1] 建立一个人人都真正对质量负责的体系需要一种质量文化。没有这样一种文化，所有团队都会在质量上作出牺牲。开发团队可能会为了节约时间而省略代码审查；项目管理团队可能会在需求规格说明书上偷工减料，或者对“完成”的定义敷衍了事；而测试团队可能在开发周期里更改他们对测试通过率和覆盖率的目标。不管在建立质量保证流程上花多少精力，工程团队总是习惯于在质量实施过程中制造一些例外，以便在最后期限到来时完成产品或者达成其他目的。为了赶上产品发布日或其它期限而灵活变通固然重要，但质量常常也因为没有明确的负责人而受到损害。

       整个测试团队可能负责质量保证的各个方面，但是在倡导或者影响整个组织接受质量文化上，他们不太会是最好人选。高级经理可以提倡重视质量，但他们有充分理由将重心放在团队管理、产品发布和业务运作上。虽然他们可能也把质量目标放在心上，却很难成为质量文化的倡导者。在大部分团队中，管理领导团队（通常是开发、测试和项目管理部门的领导者）承担着对质量负责的重任。这些部门领导负责并推动团队的软件工程，并且站在团队首要位置上评估和实施基于质量的工程实践。不幸的是，高质量软件和高质量软件开发工程实践看上去很少是他们在任何产品开发周期中的所关心的主要问题。

       有高级管理团队对质量文化的支持还不够。在质量文化中，每位员工都能对质量有影响。在制造业中，很多最重要的质量改进都来自工人的建议。比如在汽车制造业，日本的汽车工人平均一年提出28个建议，而其中80%都被采纳了[2]。

       理想情况下，微软中所有专业工程师都在提出如何提高产品质量的建议。一个没有质量文化的团队，这些建议非常少，其中得到采纳的更是凤毛麟角。对质量文化的淡漠也将影响团队成员在应对工作中其他挑战上的激情与投入。




[1] STQE Magazine. Nov/Dec 2003 (Vol. 5, Issue 6)

[2] The Visionary Leader, Wall, Solum, and Sobul

习惯一：成功者清楚地了解他做每一件事情的目的。

 成功者虽重视事情的结果，但更重视事情的目的，而目的的清楚则有助于他达到结果并且享受过程；

    习惯二：成功者下决定迅速果断，之后若要改变决定，则慎思熟虑。

 一般人经常在下决定时优柔寡断，决定之后却有轻易更改；成功者之所以能迅速下决定，因为他十分清楚自己的价值层级和信念，了解事情的轻重缓急，因此能有系统的处理；

     习惯三：成功者具有极佳的倾听能力。

倾听并非是去听对方说的话，而是去听对方话中的意思。倾听的技巧包括：一、倾听时不打断对方的谈话；二、把对方的话听完；三、即使不需要记录，你都可以听出来对方的意思；四、把所有的问题记在脑海，等对方说完后在一同发问。

    习惯四：成功者设定“当日计划“。

 成功者在前一天晚上或一早就会把当天要处理的事情全部列出来，并依照重要性分配时间。他管理事情而非管理时间。

     习惯五：写日记。 写日记的法则：一、保持弹性，重表达思想，而不用太多严格规则；二、持续；三、用来设计你的生命价值和中心思想；四、记录每件事情的差异化；五、记录特殊时刻及事件；六、解决问题；七、学习问更好的问题；八、在日记上写下自己的宣言；九、把每日写下的东西在月底复习；十、深刻自己的记忆和经验。

     习惯六：做喜欢的事。

    习惯七：勤于练习基本动作。

     习惯八：运用自我暗示的力量。

 自我暗示就是把目标用强烈语气不断念出声音，告诉自己，让潜意识无法分辨真假，因此相信它。

     习惯九：运用冥想的技巧。

 当你不断想象自己达成目标是情景，潜意识会引导身体作出那些效果。

     习惯十：保持体力或创造更多精力。

     习惯十一：成功者人生的目的通常超越自我，立志为大多数人贡献自己的力量。

 使命而非为金钱工作。

     习惯十二：成功者有系统。

 成功者都有一套方法来整理思想、行为，因此能不断实践在自己身上，并且教导别人。

     习惯十三：成功者找方法，失败者找理由。

 成功者愿意做失败者不愿意做的事情。

 

    如果你能断采取以上做法，进而养成习惯的话，这些习惯对你可能不只是百万元的价值，更可能带给你金钱和心中的富有。

创办创新工场的两个月里，我每天都在不同场合感受到国内创业者及有志于创业的大学生的热情与朝气。我们发出了大约三十封邀请，大多数也决定加入创新工场。这多多少少证明了我当初的想法：中国有着足够多的和我们志同道合的、人品好、有创业精神、扎实的计算机基础和团队合作精神的青年人。

 

不过，在我和很多青年朋友交谈时，我也看到很多人的疑惑——特别是那些尚未毕业但怀揣梦想的大学生。一些非常聪明的学生朋友也会有一些极为朴素的好奇：如果我可以加入一家已经成功的公司，直接过上很舒适的生活，为什么要创业？大学毕业后，是不是只有大公司才能帮助我成为一个卓越的技术人员？如果创业失败了，而我在这几年里又做出了很大的个人收入及私人时间的牺牲，是不是很亏？

 

其实，我一直这样告诉青年朋友们：毕业后第一份工作最重要的是你是否能够学习到最多，而不是其他。虽然很多人在学校里已经非常优秀，但你的第一份工作还是能给你带来很多震撼教育：它会潜移默化影响你究竟想过上怎样的一种人生。毕竟，我们每个人都没有聪明到可以计算到未来的每一步起伏变化，那么，你未来在面对那些重大而艰难的决策时，帮你做出决定的除了你个人的才智、经验，还有你的世界观。这些观念除了从小养成的部分，还有很大部分来自于你刚刚进入社会那几年受到的身边人的影响、遇到的工作挑战。那么，如果你希望成为一个优秀、健康的人，你应该让自己在毕业时就能置身于一个由正直而聪明的人组成的、有挑战的环境中去。这正是我在创新工场所希望营造的。

 

很多年轻人愿意加入一些成熟的公司。无论中国过去三十年成长起来的优秀公司，还是外国那些财富500强，都很有吸引力：不错的薪酬、良好的福利、健全的体系，以及大众熟悉的品牌……我当然知道这些东西都很好，但它并非适用于每一个人。有一些人，他们是天生的“创业者”，天生的“特殊的人”。

 

看看你自己是否属于这些“特殊的人”：你相信可以通过自己的努力来让这个世界变得更好；遇到各种现实生活中的问题与困难时，你更多思考的是解决问题的方法、积极地去让现状变好，而不是抱怨与忍耐；你更愿意将工作视为一次激动人心的旅途，而非日复一日的庸常无聊的糊口方式；你愿意用自己的方式去尝试、探索这个世界，而不是人云亦云，遵循常规……

 

如果你认为自己符合以上这些标准，那么进入一家成熟公司对于你很可能将成为漫长的消磨。毕竟，无论多么伟大的公司，当它的体系已经形成，初出茅庐的年轻人是不可能参与到最核心的创新工作中的，也更难突破既有的规范。就像你不能想象比尔·盖茨在IBM里开发出Windows，如果拉里和谢尔盖从斯坦福毕业之后加入了雅虎，他们也就不可能创造出Google。

 

还有一些人可能会问，开复你自己也曾经在苹果、微软、Google这些大公司工作，为什么今天反过来说它们并不适合一些人？我非常乐于承认，我在这些了不起的公司学到了很多东西，但就像我加盟微软是开创其中国研究院，加盟Google是为了创建Google中国，这种经历已经很像创业，可并非每个人都能获得类似的机会。而且，我以前的太多同事已经证明：创业者就是创业者。我在每一家公司都有很多极为优秀的同事最终告别了令人羡慕的生活，去从零开始创建属于自己的天地。比如我在苹果的同事Andy Rubin后来去创办了Danger手机公司最后成为Android，我在SGI的同事Mike Ramsay创立了Tivo，我在微软的同事Rob Glaser创立了RealNetworks，而今年热门的创业公司FourSquare和RedBeacon都是前Google员工创建的，还有谷歌中国的员工也创立了Babytree、Light-in-the-box、浪淘金、欧酷、Papaya Mobile等公司。那些不安于室的人总会去接受使命的召唤，只是早晚问题。

 

有些人认为，大公司能让他们专心于技术开发，能够获得更多的培训机会。但他们没有意识到，工作并非读书，毕业后最好的学习不是来自课堂式的“培训”，而是来自“learning by doing”的实践。工科的同学，毕业后最好的学习就是投入一个有用户价值，有商业模式的产品的研发。在这样的环境中所学的技术是真本领，不是纸上谈兵，解决的是真问题，而不是toy problems。那些真正有意义的产品是能最大程度上影响最多人的生活的，它们绝不仅仅因为技术先进，还因为它们是人们最需要、最在意的。想想那些真正的“颠覆式创新”，个人电脑刚刚诞生时，效率远远不如大型机，而YouTube的视频效果也大大不如电视，但它们契合了大众所需，并彻底的改变了世界。如果你想创造最好的技术，你一定要被推到用户面前，理解他们所想所需，尽你所能满足他们。

 

对于那些感叹“为什么创业公司为什么没有五星大厨和龙虾鲍鱼？”，我希望你们看得更远一点。创业公司拿着代表投资者信任的资本，花每一块钱时必须问问自己：“如果是我自己的钱，我会这么花？”，因为作为公司股东和主人翁，这个公司确实是自己的。在创新工场，我们没有五星大厨和美食，但是我能够承诺的是我会和你们一起住二星酒店，吃十元的盒饭。我也会把你们当我的家人，带来公司我回台湾买的美食，或者我自己做的烧饼或牛肉面。

 

对那些感叹“为什么创业公司薪水不如最高的跨国企业？”，我也希望你们看得更远一点。选择创新工场，你走的是盖茨、拉里和谢尔盖的路，而他们是这世界最富有的人。我从来不建议人们为发财而创业，但不妨反过来想，钱本身就是一个由市场机制做出的评判：你创造的价值越大越稀缺，人们就越愿意为之付费。因此，我们只给员工合理的薪水，却相当慷慨的给他们相当多的干股和股权，这才是未来价值最大的部分。虽然这种回报并不确定，但我真心相信每名工程师都可能成为创业者和企业的主人，也可能为自己创造巨大的财富。

 

当然，商业世界并非充斥着光辉灿烂的成功者，还有很多失败者。即使最乐观的说法，就算创新工场帮助你提升成功概率，缩短产品周期，失败的概率依然远远大于成功。真的应该用自己人生最宝贵的几年时光参与到一次前途未卜的创业旅途中吗？

 

这是一个你必须自己回答的问题。有些人只用几秒钟就可以得出答案，有的人则会思索一生也无法说服自己。但当你确信自己真的愿意走上这样的旅程，并以正确的、正规的方式创业，无论你最终取得了何种程度的商业成功，相信你一定能够学到非常多的东西。当你全心投入创业，每天你都要解决大大小小的种种问题，这会帮助一个富有才智的年轻人迅速成长。

 

退一万步说，即使失败了，会怎么样呢？别忘了，即使今天被全球商界视为偶像的乔布斯，在他30岁到45岁期间，也有过被苹果驱逐、创建NeXT失败，经营Pixar动画公司被好莱坞无情打击的连续的挫败经历，但他扪心自问，自己依然热爱科技业，依然愿意以创建公司的方式改变这个世界，并坚持前行，他才成为日后那个创造iPod和iPhone的乔布斯。

 

乔布斯的一生，就和梭罗说的一样：“我希望活得深刻，并汲取生命中所有的精华。然后从中学习，以免让我在生命终结时，却发现自己从来没有活过。”

 

也可以反过来说，如果你希望过上一个安稳的生活，如果你每天考虑的都是如何还上房贷和车贷，如果你安于现状，如果你畏惧失败，那即使你既聪明又有商业头脑，可能你也不应该接受那些创业公司的邀请。这样你可以得到安稳的一生，但是也放弃了让自己人生更丰富多彩的一种可能性。

 

最近的两个月，我自己也在寻找走上一条与以往不同的道路的方法。我和我的同事们每星期工作70个小时，去优化创业公司的每一个环节（比如和很多一般创业公司只能仰视的大公司谈成合作），致力于减少影响创业者的外力（比如招聘、工商注册、税务、法务甚至房屋租赁……），去挖掘每一个人才（数次我写信给毕业生的父母），从而让创业者可以最大程度的专注。而我由此获得的，是和许许多多拥有一流想法的人进行深入而有趣的探讨，一起探索让这个世界与以往不同的可能性。所以，如果你符合我在前面说的标准，又愿意得到和我一样的头脑上与精神上的丰富收获，那么，你应该重新做一道算术题：“知名大公司+优厚的薪水+安稳的工作+舒适的生活”，和“属于你的公司+丰厚的股票+快乐的打拼+改变世界的机会”，究竟孰轻孰重？

当前问题：如何保证测试用例的广度？

如何保证测试用例的广度？

 

http://bbs.51testing.com/viewthread.php?tid=280759&pid=1668722&page=1&extra=#pid1668722

 

鄙人浅薄的认识：

 

 

尊重作者知识产品，您若喜欢并转载，请标明出处：http://www.javaeye.com/topic/692657

 

作为芸芸众程序员的一员，我对软件开发中的一切都有着自己的问题。今天是关于测试，作为一名唯物主义者，我相信众物都有其神，于是我找到了测试之神。

我问：神仙哥哥，为什么我们需要测试呀？

大神用他那一贯充满怜悯的眼神看着我，说到：我可怜的孩子们啊，愿上帝保佑你们。之所以需要测试，都是上帝的错啊，上帝创造了你们，但是因为没有测试，所以你们都是不完美的、不理智的，你们会犯错。

我说：我明白了，因为我们每个人都各不相同，我们会被情绪、环境左右，不理智、价值驱动，而我们的大脑也是有限的，更糟糕的是那狭小的大脑只有该死的5%得到了开发，所以我们需要测试。

大神点点头，他对5%这个数字充满了怜悯，当然，他对任何事情都充满怜悯。我想，我该叫他怜悯之神。

我接着问：我们需要测试，可是，为什么我看测试人员只是天天敲键盘而已啊？

怜悯之神说：你的工作难道不也是天天敲键盘吗？

我想了一下，说：那不一样，我敲键盘是在写代码，那些漂亮的页面、增删改查都是代码实现的。

怜悯之神说：开发人员敲键盘是在写代码，测试人员敲键盘是在获取当前系统的信息，这两者真正的工作都是那些脑力活动，是在敲击键盘这个物理行为之前以及伴随这些物理行为的脑力活动。如果你敲击键盘的时候没有进行思考，那么你就不是在进行开发和测试；而且，如果你在思考但是没有敲击键盘，你还是可能在进行开发和测试。

我说：关键是思考。

怜悯之神说：是的。他显然对后半句犹豫了一下，但是还是说了，人类一思考，上帝就带领我们发笑。

我想，这有什么好笑的吗，连朝鲜昨晚都进球了。我说，其实对软件开发人员来说，我们也应该通过使用自己的产品来对他进行测试。

怜悯之神点点头，说，如果你都对自己的产品感到担心和鄙夷，别人为什么要买它？

我说，可是，除非我们开发的是开发工具，否则我们根本不可能用它。地球人都知道，在某个神奇的地方，做减肥药的从来不喝自己的减肥药，买火腿肠的从来不吃火腿肠....人人都需要是化学家。

怜悯之神说：完全由软件开发人员构成的测试样本不太可能代表整个用户群。

我自言自语道，所以我们需要测试人员，需要另一个角度的思考。

等等，我说，尽管测试人员测试了，但是为什么系统还是存在缺陷哩，难道他们不对所有可能性都进行测试的吗？

怜悯之神翻了我一个白眼，他叹了口气，说道，该死的5%啊。作为报复，在下面的叙述中，我将称他为白眼之神。

白眼之神说，对任何程序而言，可能进行的测试数据都是无限的。测试也许可以令人信服的表明存在缺陷，但是永远无法表明不存在缺陷。

我想了想，说，你说的有道理，我们现在的系统需要导入客户的遗留数据，光报表就多达20万，如果一张张的校验报表内容和样式，那么一定会死人的。

白眼之神说，那你们是怎样测试的哩？

我说，抽取样本测试哈。我说，我明白了，由于我们无法测试所有的可能性，那么任何测试实际上都是某种程度的样本测试，这些样本以某种方式代表整个可能测试集合的一个部分或者片段。测试只是采样！

白眼之神点点头，说，实际上，采样也是一个心理过程，而且是一个感性过程，令某人满意的样本也许会让另外一个觉得一点都不满意。

我接着说，由于不可能进行穷举测试，所以我们往往在两个目标间徘徊：希望测试能够覆盖所有令人感兴趣的条件，希望测试集减少到可以管理和承受的程度。就像吃自助餐，希望吃到所有东西，但是又要不把肚皮撑破。

白眼之神说，所以我们需要尽可能选择那些具有最强代表性的样本进行测试，而这是专业测试人员的优势。另外，多样化样本发现的问题可能超过大样本发现的问题，同样，测试团队多样化也可能发现更多的问题。

我说，我想想，我们现在也在进行测试，在开发中，我们采用了TDD的方式，我们单元功能测试的覆盖率很不错，这样，我想单元测试可以减少测试人员？减少系统测试？

神说，你会因为一架飞机保证它所有的部件在组装前都进行了测试而乘坐它的处女航吗？

我说，哦，罗老号发射失败了。

神说，但是，良好的单元测试能够为系统测试去除噪音。

我说，缺陷都不是自己钻进去的，而是开发人员放前去的。单元测试能够在一定程度上阻挡开发过程中缺陷的进入，同时阻挡一些简单的缺陷，系统测试不能捕获所有缺陷，相对单元测试，会花费更长的时间和成本，这些时间和成本能够通过单元测试得到部分节约。

神说，开发人员的测试保证了他对需求的理解和实现的一致，但是开发人员对需求的理解和真正的需求一定一致吗？

我说，所以需要测试人员来即时验收。

神说，另外，从心理学的角度说，一个人很难发现自己的错误，所以TDD和结对编程一起实践会有比较好的效果。

我说，好吧，测试很重要，可是为什么很多项目最后的集成测试阶段会那么长哩？这总是导致我们的项目延期。

神说，说说你们的集成测试阶段都在做些什么？

我说，噢，我们拉出一个发布分支，冻结代码提交，开始进行测试，查明缺陷原因，根据重要性修改缺陷，然后重新测试，以此循环。恩，问题在于我们每修复一些缺陷总会引入新的缺陷，所以这个时间拉得很长。

神说，修复缺陷的同时引入新缺陷，这叫做故障反馈率（FFR），也就是一个修复让系统中产生了另一个缺陷的情况所占的百分比。这个数值如果在50%以下就很幸福了，另外，压力和试图提高缺陷修复速度都会提高FFR。

我说，也就是修复缺陷的同时引入新缺陷是个正常情况。恩，可是我的问题是为什么最后的测试阶段需要花费这么长时间？

神说，难道你不觉得是你们经理错误的估计了最后集成测试阶段所应该花费的时间？

我说，oh。

神说，测试不等于除错，把整个集成测试阶段归于测试是不公平的。

我说，是的，如果区分开，相比测试，除错占据了更多时间。恩，我们现在的一个项目特性，由于开发时没有考虑性

能问题，导致上线时花费了大量时间。

神说，项目延期的主要问题在于测试推迟。

我说，是的，这个给我的印象很深，如果在开发阶段就进行大数据的测试，那么会节省很多时间。

神说，所以要测试先行，并且测试往往在项目开始开发前都已经开始了，测试需要贯穿于整个开发过程，而是不推迟到最后的集成测试阶段。TDD和持续集成是很不错的实践，但是它们仅仅是一部分。

我说，还好，我们还有测试，不像某些疫苗，直接上市。那么，测试保证了质量？

神说，你觉得蒙牛没有测试吗？

我说，....

神说，测试只是提供信息。至于这些信息的定义、重要性以及所要采取的反应都取决于人，而人做出的决定都是感性的，利益驱动的。

我叹口气，说，测试能够保证软件质量。

神说，如果开发的产品本身就质量低劣，进行测试你不觉得是浪费大家的时间吗？一段时间发现的缺陷越多，并不意味着剩下的缺陷越少，而是意味着会出现更多的缺陷。

我说，我明白了，测试只是反馈信息，除此之外，并不能做其他任何事情。正如我们去体检，体检报告只能反映当时我们的身体状态，至于健不健康，则取决于我们平时的生活习惯，这是两个分开的事情，体检并不保证我的健康。

神说，是的。

我说，那么，很多大公司非常看重测试部门，原因其实是他们无法看清楚他们自己的开发过程，于是只能从测试里获取信息，而这些信息对整个软件开发来说只是一部分而已。我看到过有项目经理向测试人员询问是否可以交付，这根本上就是在推卸责任，信息和作出决定根本是两回事，如果是这样，不如让测试人员来当经理好了。

 

（未完待续）

测试的革命　 　 　 　
作者：Sam Guckenheimer
翻译：Blueski
日期：2003-1-20

　 爱因斯坦在1915年发表了广义相对论，当时这还只是一项伟大的科学猜想。4年后，Arthur Eddington和一个英国科学家组成的小组完成了一项重要的实验，在实验中他们拍摄了在日蚀过程中Hyades星云的图片， 该实验表明，因受日蚀影响，图片中产生了很大的误差幅度，由此证明了爱因斯坦关于空间的弯曲和光的重力效应的预测。大众媒体随即 给予爱因斯坦和Eddington很高的荣誉。同时也因为他们两人都是和平主义者，所以被一起推崇为在这个饱受战争沧桑的世界上 的英雄。
　　虽然媒体显得急不可待，但值得注意的是，广义相对论在当时的科学界仍受到广泛的争议。直到半个世纪以后，人们才终于迎来了具 有决定性的实验结果。当时Thomas Kuhn写下了《科学革命的结构（The Structure of Scientific Revolutions）》一书，相对论被作为是革命性变革的完美例子– 一种新的观念完全替代了一整套旧的信仰。

今年7月，我代表Rational Edge采访了Cem Kaner。当时他借用了Kuhn的结构对目前软件测试领域盛行的各种争议和尚未确证的理论进行了分类。

　　后来，Rational Edge发表了我和软件测试方面的其他专家的一些访谈。有些读者却质疑我的选择，他们会问：“这和我现在做的主要工作有什么关系 ？”
因此，在本文中，我想把所有这些课题放在一起，并对自己关于未来测试领域的发展的前瞻进行阐述。我可以断言的是，测试人员、开发 人员、项目管理人员、公司管理人员和最终用户们都期待着看到在这10年里软件测试实践方面将要发生的大变革。其原因很简单，– 软件质量的低下已经使美国经济蒙受巨大损失，NIST估计[注1] ，每年损失约600亿美元，而Standish组织的数据则是2000亿美元。所以改进软件质量已成为取得高投资回报率（ROI ）的直接途径，只有那些把握了软件质量的企业才会赢得胜利，其余的则将被人们所遗忘。
这些实践和工具又是什么呢？我认为随着时间的发展，以下五种趋势会得到发展和应用。
1. 测试驱动型的软件开发。在软件生命周期的各个阶段中，这些阶段包括测试、需求分析、使用形像化符号进行的规格说明，以及基于UM L和其它新标准的实践；
2. 探索性学习和发现，这将成为迭代开发过程的一个组成部份；
3. 组件测试和易测试性设计，这将成为软件开发不可分割的组成部份；
4. 更加重视适当的技能的应用，减少预先写好的文档，这将成为优秀软件过程的基本原则之一；
5. 使用自动化测试来取代目前严重影响测试效率的冗余繁复的人工过程。
下面让我来对这些趋势进行说明。

测试驱动型开发

　　这一实践在RUP过程中又称为“测试第一的设计（test-first design）”，而在很多XP( eXtreme Programming)文章中则称之为“测试第一的开发（test-first programming）”。这一设想的提出至今已有近十年了，但是直到最近才得以在开发这一层次上取得很大的支持，这要在很大 程度上感谢敏捷方法组织。他们的核心思想是，在你写一行代码之前，你要先写一行对其失效所进行的测试。在该测试的描述中应包含一 个程序代码实际运行的实例。Martin Fowler将这样的测试称为“带实例的规格说明（specification by example）”。
　　Brain Marick和其他一些敏捷测试的支持者已经提出建议，要把测试驱动开发的概念扩展到所有的层次，包括系统测试和产品级测试[注2] 。Marick很清晰地表述了他的观点：“我并不想写出一套用于捕捉用户愿望的需求，取而代之的是，我要写出一套测试，一旦这些 测试能够通过，产品就能使她满意。所以我放弃需求编写的步骤，而直接把需求分析加入到测试的创建过程中去。” [注3]这些测试脚本就象是可执行的规格说明，当程序代码通过了测试，那么这些程序代码也将和规格说明保持一致。
　　 如果你的代码是使用Java，而且你的测试也在Java中测试，那么测试很可能会基于JUnit，你可能要么是 一个人，要么是编写的两人组中的一个，不管是哪一种情况，都很容易看到，这时Marick的方法是可行的。Marick相信这是 可伸缩的，可以适合于小团体，或者在有一个用户在场的条件下进行“交谈式测试的创建（conversational test creation）”的实践。但是，如果有人要了解需求，这些需求却是在测试设计中被捕捉的，而你并不在场，无法直接为他们进行 解释，这样就存在明显的问题。在这种前提下，我并不认为测试一定要在程序语言中体现。即使对需求有了“精确”的表达，也不足以解 决可理解性的问题。对于这一问题，Leffingwell和Widrig有很好的描述 [注4]，下图即是基于他们的观点。

图1：可理解性问题（基于Leffingwell和Widrig的观点）

　　实际上，Leffingwell和Widrig并没有真正地考虑到测试的问题。他们的主要目的是想让需求具备很高的可理解性 ，以便于让用户和投资者能够充份理解。他们没有解决这样的问题，即如何把规格说明提交给其他投资者和生命周期的其它阶段。作为一 种争议，他们认为有必要保留一部份不明确性。而实际上，不明确的需求显然会让测试人员发疯。
Marick提出的测试驱动型开发方法则走向另一个极端：测试代表了需求，测试的表现形式是一些可编译、可执行的代码。但是，如 果测试（需求）的唯一表现形式是代码的话，你就很难和商务人员/投资者/客户进行有效沟通，甚至也很难和其他测试人员及开发人员 进行沟通。所有这些人都认为测试的形式本该是数据和流程，所以如果要以那种方式来做的话，你的测试必须变得非常容易进行交流。
　　一些公司正致力于为这种隔阂提供解决之道。Rational正积极参与一个OMG团体关于UML测试预定义项目，该项目可以 把测试表示为数据和可视化的流程，例如顺序图和活动图。我们正在开发一些工具来对待以下三种表示方法，代码，数据和流程，并取代 类似的测试视图。
　　在过去，我们制作了这些“实例化规格说明”，按照RUP的命名方法，可称之为“用例实现”。“实例化规格说明”和“用例实现 ”的相似性可以通过援引最近的一个使用Agile方法的工作团体的报告来说明：
　　 [一个参与者] 提到，和他一起工作的人都很喜欢使用“测试第一”的开发方式。当测试框架被开发好以后，特别是当用于组织运行的测试脚本被定义好 时，他们的工作变得更为容易。而用例在组织起来开发脚本时会有所帮助。他们的测试可以捕捉到用户的需要。人们之所以喜欢这样的方 法，其原因是它提供了他们工作所需的结构。在Agile方法中，需求以“案例(story)”的形式存在。于是，测试脚本将以接 口已明确定义好的形式把这些“案例”编织在一起。这意味着结对编程的人可以根据他们需要的顺序相互测试接口 [注5]。
类似地，OMG测试预定义工作组发现，将UML排列起来也很容易。你可以将一个用例实现转成为测试，这只需增加两件东西：验证工 作（例如，“现在用测试来检查这个软件中的条件。”）以及裁决（例如，通过、失败，或者暂不决定）。这样的信息在规格说明中随处 可以捕捉到，所以UML符号可以让我们测试人员有了表达的手段。
　　 于是，只需要额外做一点点努力，就可以使测试对客户来说变得很容易理解：数据表和可视化流程。然后，当有软件需 要测试的时候，测试已准备就绪。这一实践使测试驱动型开发在系统级测试上也具有实用的价值，因为在设计工件和测试设计工件之间确 实没有什么区别。仅仅只要增加验证的注解以及进行裁决就可以了。在比较容易理解的可视化流程和数据的帮助下，你不再需要把系统设 计从测试设计中分离出来。而且由于这些流程具有一个可执行的形式（生成的代码），因此可以把每一次创建作为测试来执行。这使整个 团队得到了解放，并成为Kent Beck和Erich Gamma所说的”受影响的测试（test infected）”:
“…这是一种测试的类型，只要使用非常小的投入即可使你成为一个更快的、更多产的、更具预见性的、压力更小的开发者。”
-Kent Beck和Erich Gamma《Test Infected: Programmers Love Writing Tests》[注6]

探索性学习

　　这第二种趋势认识到了这样的现实，即我们通常很难把问题描述得十分正确：需求在演变，我们需要简化（扁平化）或者把著名的“ 错误-代价”曲线颠倒过来。这里的核心思想是：我所说的每一项，不管是在产品、测试或者跟踪排错的第一步，都在运行软件时通过探 索性发现，才使得可视化-可执行-设计-测试的整个过程和结果变得更为真实。
实时分析工具，例如Rational PurifyPlus就带有制作精良的非常明确的实例，例如发现内存错误和性能上的瓶颈。你还可以用它们来支持更广泛的探索，尤 其是在由各种不同组件所构成的系统中。80%的企业级行为都是对某些组件的重新组装，包括对遗留下来的成份进行更新或补充等等， 而不是从头开始设计。
　　在软件运行时你会发现很多新的信息，至少和设计时一样多。这也是RUP强调要把可运行的软件作为每一次迭代的组成部份的缘故 。你发现的每一样东西都应该是可视的，并且放在你用于设计的同样的工件中。对运行着的系统的跟踪是一种UML的迭代，经过验证和 裁决，可以转化为一种可复用的测试。数据也值得进行概括，并形成新的等价类的基础，等等。
　　当前，大多数探索性测试的提倡者，尤其是Kaner和Bach，都把这作为使用后即可放弃的行为[注7] 。但我认为，我们一旦把所探索到的内容无缝地加入到设计中去后，就会发现，这是高度可重用的。事实上，这是实时分析的一个新的应 用：通过探索而发现的有价值的东西的捕获和利用。

组件测试和易测试性设计

　　第三种趋势是关于理解测试人员和开发人员的相对角色，并为每种角色分配合适的工具。Rational把提供组件测试和易测试 性设计作为一种最佳实践，这已有很长的历史。我认为对这些做法的采纳源自于对质量的基本理解。当前，太多的测试人员的行为都受限 于规格说明的模式，其中有很多浪费。其实开发人员才有责任去保证所开发出来的软件和规格要求相一致，他们应该使用合适的工具和过 程来达到这样的目的。
Boris Beizer描述了2种不同角色的区别：
　　独立测试的目的是提供一种不同的观察点，由此产生了不同的测试，并且在比开发人员所采用的开发环境更丰富的环境中执行测试。 自我测试（self-testing）的目的是消除那些bug，这可以在相对更简单、更明确的单元/组件环境，或者低层次的系统 测试中进行，并且只需花费较低的代价。[注8]
　　测试驱动型开发提供更大的能力。如果规格说明就是可执行的测试，而测试进行没有产生别的问题，那么就可以认为软件和规格说明 相符。其它的单元测试过程也只是为了保证同样的事情：就规格说明而言，不管它们是什么内容，代码总是与之相符合的。如果不符合， 那么就是开发人员的问题。Kent Beck非常清楚测试驱动型开发所带来的效果：
如果测试驱动编码的缺陷密度达到足够低的话，那么专业测试的角色将不可避免地发生改变。以前的是“成人监护”方式，而现在更类似 于一种扩音器，它宣称测试要更多地验证的是系统必须做什么。[注9]
　　这需要整个团队接受这样的一个前提，即保证软件符合规格说明是开发人员的职责。这使得测试者可以有更多精力用于发现和避免一 些别的问题，从客户或者用户的角度来看，这些问题的存在可能会使软件所应有的价值有所降低。Brian Marick针对这些冗长烦琐做法的错误性写过一篇很著名的文章[注10]。那些文档通常已说明了一个系统中的多于一半的错误，他声称，因此你就需要专门有一个过程来让你的测试人员用来发现这些问题。
　　易测试性的设计在这里具有重要的意义。现在很多软件已改用基于服务的构架，这种构架是基于组件的构架的一种扩展，随之而来的 是新增加的复杂性，即组件可以在没有警告的情况下发生改变，其可靠性的问题是极为严重的。大多数IT经理会接受99%的可靠性， 我敢打赌，他们会认为这一标准甚至已经高于他们所用的买来或构建的组件。但是，如果你构建的系统有超过100个组件，每个组件具 有99%的可靠性，那么整个系统的可靠性是0.99的100次方，实际上仅有37%。顺便提一下，这也是为什么那些有高可靠性要 求的市场，例如电信业，会要求“5个9”的可靠性，即99.999%。在这样的情况下，你就可以使用100个组件，综合起来仍有 99.9%的可靠性。
　　这一基本原理实际上要求软件进行易测试性的设计，就象30年前市场形成时硬件所做的一样。 Bertrand Meyer是这一领域研究的领先者，他提出了按合约设计，其意思是把对类及调用该类的客户端之间的关系的检视作为一种正式的协议 ，这表达了每个团体的权利和义务[注11]。Meyer的概念已被广泛接受，其标志之一就是合约设计的规格语言WSDL的诞生，该语言是Web Service标准的核心[注12]。
　 我认为人们正越来越多地接受易测试性设计。易测试性已成为诸如Web Service等框架和标准的一个补充的组成部份。接口也正成为技术平台和操作系统的一部份。一个比较简单的例子是，J2EE和 .NET 中预定义开放式接口和API映射，可以允许工具来检查在运行时刻环境中发生了什么。另一个真实而有益的趋势是人们正使用象Rat ional XDETM这样的工具，通过设计模式的方法来构建应用–而易测试性已被置入在设计模式中。模式所构造的组件包括外在的用于测试 的接口 — 即组件的一些适当的getter和setter方法。
易测试性设计的一个实用的法则是，你已在GUI和表示层的后面对业务逻辑或软件的行为进行了访问。Bret Pettichord主张，易测试性设计应该是关于可见性和控制的设计[注13] 。你通过较低层获得其外在接口，从而得到所需要的可见性，在测试的时候，通过很多开放的接口来允许你直接看到软件中的声明。同样 地，你需要接口来让你能够控制应用，由此你才可以避免使用GUI，而是通过自动化框架来驱动应用。

重视技能

　　第四种趋势是增进软件测试专业技术知识的水准。在.com流行的年代中有这样的误解，即使没有很深的测试技术知识、业务应用 方面的领域知识以及充份的培训，你也能有效地进行测试。但当你面对一个分布式的应用–例如，一个特别的基于Web的应用，就会 发生问题。Hung Nguyen关于基于Web应用的测试论著是这种观点最好的代表[注14] 。Nguyen认为，测试人员应该知道技术是如何对他们所看到的各种错误产生影响的。他们需要对技术问题有所理解，例如配置的问 题，以及他们所检查的技术本身内含的问题。各种细节上的理解，例如了解应用服务器中Bean和Container管理的持续性之 间的区别，可以直接影响到你发现特定缺陷的能力。
　 所以，现在的测试人员除了测试本身的技术以外，还需要理解开发技术和领域知识。例如，假设你在浏览器中看到一个错 误：“404 - Page not found”这样的错误可能是错误的链接所引起，也可能是因为某些服务失效而产生。一个好的测试人员并不会在出错页上就停下来， 他会进一步诊断出错的原因。他不仅需要对该失效的服务具备足够多的认识和理解，而且他要通过查看其它使用该服务的页面来验证自己 的猜测。这就是一种Bug隔离的重要技能。
　　另一种技能是成为一个很好的探索者。以前，测试方面的很多论述对计划和脚本有很多要求，但现实情况下，一个好的测试人员就是 一个好的探索者。他们喜欢在测试过程中发现一些暗示，并知道怎么来进行跟踪。这样的暗示有时很简单，例如一个页面要很长时间才能 加载。那么对于一个好的测试人员来说，他可能会想，这其中发生了什么？然后继续了解要通过什么路径可以进一步发现答案。Jame s Bach所写的一些内容可能是在探索性测试方面最好的材料[注15]，其中有该课题的最佳练习。我认为这显然也是一个重要的技能，每个团队都需要这样的技能。
　　我们在Rational学院的课程中已经非常重视如何去应用基本的软件测试技术。可以和Florida Tech的Cem Kaner一起开始那些专为测试人员提供的软件测试基本原理的新课程[注16] 。该课程并不专注于测试工具，而是专注于如何成为一名很好的软件测试人员，尤其是当你正在应用迭代开发过程的时候。最后，测试人 员的生产能力和开发人员的生产能力是同样重要的，只有富有经验的测试人员才能使产品让客户获得很高的投资回报率（ROI）。Ra tional已经发现，一个更快、更经济、更高质量的开发过程的关键就是迭代式开发过程。迭代式过程可以使测试在整个开发周期中 得以提前，从而可以更早地发现错误，修改错误也相对更加容易，其成本也相对更低。
　 但是，我认为现在的测试人员还没有得到很好的训练以胜任迭代开发过程中的测试工作要求，项目经理也没有得到很好的 训练以正确地认识测试在迭代项目中所扮演的角色，开发人员也没有得到很好的训练以得到他们需要了解的测试相关技术，例如基础等价 类划分。因此我们在RUP(Rational Unified Process)和Rational学院中增加了大量关于测试的材料。而且我们还将继续扩充这些材料以帮助测试人员、开发人员和 项目经理们在迭代过程的协同工作中做得更好。

自动化测试

　 第五种趋势是关于测试自动化方面。目前，为了实行测试自动化，测试人员和开发人员要花费80%的精力来使（自动化 ）测试成为可能，而只有20%被用于使（自动化）测试变得更有意义。这一可怕的事实使很多人最终放弃了测试自动化。同样，目前的 自动化软件质量(ASQ) 工具提供商正花费80%的精力用于重复工作，他们必须重新创建一个基础平台来支持相应的测试和排错工作，而仅有20%的精力来为 测试和开发人员提供可见的有价值的功能。
最近，Rational、IBM和其它一些公司开展了一个开发源码的项目，其目标就是要把这两个百分数颠倒过来。该项目被命名为 Hyades，取自Eddington用来校验爱因斯坦理论的星云的名字，并由Eclipse.org负责。它的目标也包括加强 实验性观察，测试过程及软件度量，最终实现更具实用性的测试自动化。

　　对于使用Eclipse的开发人员和测试人员来说，Hyades既是一种集成测试及跟踪，也是环境监控程序。Eclipse 为整个测试过程提供了标准、工具和互操作性，以使测试能更早地移植到应用生命周期中去。对ASQ提供商和集成商来说，Hyade s为自动化测试、跟踪、预定义、监控和资源管理提供了一个可扩展的架构和平台。和目前的测试与跟踪工具所不同的是，Hyades 将提供一个统一数据模型（实现了UML测试预定义），这是一种标准的用户工作的流程，包括一套统一的API及相关工具，可以在排 列的目标项之间连续地工作。

总结：测试实践的大变革

　 Rational和一些竞争对手尽管自己也提供商业测试工具，为什么还要加入到象Hyades这样的开放源码项目 中去呢？ 我的很多同事也问过这样的问题。其核心理由就是上面所说的80/20比例。所有人都很想改变这个比例。
80%的基础平台对用户来说是不可见的，它难以分辨，也难以维护。每当测试所用软件的环境条件更新的时候，(新的编译器，新的库 文件，新的操作系统补丁，等等），测试工具就必须随之更新。如果你是一位富有经验的实时分析或自动化工具的用户，你可能早已感受 到这种脆弱。你也许已经不止一次在考虑要更换开发环境，因为有些工具不支持一些新的版本。这一维护成本给工具提供商带来了巨大的 压力，因此工具商们决定无偿地为新的引擎工作，并分享其成果，进而满足用户的需要。Hyades项目必将为我们的用户提供其价值 。

　　对Hyades来说，它是由一系列分散的努力所组成。在我所归纳的五种趋势中，Hyades是其中的一个组成部份，它将同时 为测试人员和开发人员提供新的测试支持方式。这是一种技术，它可以在生命周期的一开始就推动测试，带来工具方面更好的协同性，通 过改进测试，新的效果会明显地加入到软件中去。它将为这10年里我能所能看到的在测试实践上的改革提供有力的支持。我相信这种技 术，以及其它有类似目标和基础的技术，代表着我们产业的未来。我们这些已被卷入到Hyades项目中的人都有一种使命感，我们不 能辜负Hyades这一名称：
　 让我们描画出金牛座的头部–Hyades星云中的恒星，这对我们来说意义重大，这将带给我们快乐，并使我们能够 测量整个宇宙

 

 

发布时间: 2010-5-14 15:12    作者: colen(Javaeye)    来源: 51Testing软件测试网采编

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问，答贴有奖