2012软件设计师复习的综合资料

1、 上学吧（）第 PAGE183 页，共 NUMPAGES183页上学吧为您提供“软件设计师”资料下载：http:/ 在远古的尧、舜时代，黄河流域经常发生了大水灾，洪水横流，五谷不收，家破人亡。所以尧派鲧去治水，鲧沿用了过去的传统法子，水来土挡，用土筑堤，堵塞漏洞。但由于洪水凶猛，不断冲击土墙，结果弄得堤毁墙塌，洪水反而闹得更凶了。鲧治水九年，劳民伤财，并没有把洪水制服，是一事无成。 舜接替尧后，就把鲧办罪处死，随后命鲧的儿子禹继续治水。大禹领命之后，寻找到了以前治水失败的教训，最后决定用疏导的办法来治理水患。大禹带领百姓是凿了一座又一座大山，开了一条又一条河渠，把黄河的主流加深加宽，把支流疏通

2、与主流相接。同时，把原来的高处培修得更高，把原来的低地疏濬得更深，便自然形成了陆地和湖泽。把这些大小湖泽与大小支流连结起来，洪水就能畅通无阻地流向大海了。 相传大禹三过家门而不入，把整个身心都用在开山挖河的事业中。大禹用疏导的办法治水终于获得了成功。大禹治水，为民造福，永受华夏子孙所称颂，永为炎黄后裔所怀念。 集成与构件 “集成”是看到了信息化建设中的一个个信息孤岛，数据不能交换，资源不能共享，业务不能协同，如同洪水泛滥一样。传统的应用集成EAI是典型的“堵”法，可以说总是在事后解决问题，是头痛医头、脚痛医脚，治标不治本的办法。碰到了集成问题，才去想办法去解决,而解决眼前问题的同时又带来更多和

3、更复杂的其它集成问题。所以，就如同鲧治水一样，鲧没有把洪水制服，EAI当然也不可能从根本上解决信息资源共享利用的问题。 因此解决信息孤岛，要学大禹治水，“疏”比“堵”更重要。“堵”是一时的、眼前的，“疏”是长远的，一劳永逸的。与集成的事到临头相比，构件就是“疏”的方法，是从源头上去堵。在构件体系下，信息资源将按标准、有层次的通过构件展开，数据是构件、展现是构件、流程是构件、服务是构件，一切皆构件。好比大禹治水，开山凿渠是构件库，主流支流是大小构件，贯通无阻是统一标准。 所以，构件可以实现信息资源的大“治”，用计算机术语来讲，就是“同构”，标准统一，架构统一，建设统一，管理统一，开发、部署、运行

4、与维护实现同构，信息孤岛从设计源头上被消灭。 从测试角度看用户手册在软件质量中的地位 对于软件，开发者往往只注意到其功能和性能，而忽略了用户手册。其实用户手册也是衡量软件好坏的一个重要标准。好的用户手册可以帮助用户快速入门，是用户正确、充分使用软件的前提。对于开发者来说，好的用户手册可以减少培训和售后服务的费用。所以在测试中，不能忽略用户手册的重要性，应从以下多个方面考察用户手册的质量。 用户手册的完整性重点考察用户手册内容的全面性与完整性，从总体上把握用户手册的质量。这一项看似简单，但在实际测试中我们发现，很多开发商还是无法做到这一基本标准。很多软件由于开发过于仓卒，在付诸使用时，用户手册中

5、缺少关于某些模块的说明，让用户使用起来比较困难。在测试工程师的眼里，优秀的用户手册内容应该是包括软件的所有功能模块。 用户手册的描述与软件实际功能的一致性考察用户手册与软件实际功能的一致程度。当确认用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。这种问题往往是由用户手册跟不上软件版本的更新速度造成的。对用户来说，容易造成对描述不一致的功能的误解和苫螅?进而影响用户对软件的使用。优秀的用户手册应该根据软件的升级而及时更新，手册描述应该与软件实际功能保持一致。 用户手册的易理解性考察用户手册对关键、重要的操作有无图文说明，文字、图表，是否易于理解。对于关键、重要的操作仅仅只有文字说

6、明肯定是不够的，应该附以图表使说明更为直观、明了。优秀的用户手册应该是图文并举，易于理解。 用户手册提供学习操作的实例考察对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。当前大量软件的用户手册只有简单的图文说明，而无应用实例。这样的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。例如财务软件，用户手册就应该提供具体建帐实例及具体帐务处理的实例，这样才能使用户看完用户手册后，能够独立完成新帐套的建立并逐渐学会使用软件处理帐务信息。优秀的用户手册不仅要对主要功能和关键操作提供应用实例，而且对实例的描述应做到详细、充分，易于用户理解。 用户手册的印刷与包

7、装质量考察用户手册包装的商品化程度，印刷质量。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的用户手册应提供商品化包装，并且印刷精美。软件的质量是由各个方面构成的，用户手册就是其中重要的一环。特别是在当前软件业快速增长的时期，软件开发者过于注重功能与性能而忽略用户手册，使得用户手册的质量问题尤显突出。所以对于测试人员应该充分认识到用户手册的重要性，严把用户手册的质量关，以促使软件整体质量有一个提高。 从菜鸟到大师细看程序员的五种层次软件界一个无可争议的事实是，不同程序员的效率有差别，而且差别很大。许多专家将优秀程序员和一般程序员区分地很清楚。大多数研究得出结论认为，一般程序员

8、跟优秀程序员之间在工作效率和质量上存在10：1的关系：优秀程序员和水平较差的程序员的编码时间比例为1：20；debugging时间比为1：25；代码数量比是5：1；程序执行速度比例是10：1。而且发现，程序员的代码质量和效率跟工作经验没有关系。让我们看看一些软件大腕们是如何看待优秀程序员和一般程序员的：Randall E. Stross：无论是从软件标准、创造性、开发速度、还是设计思路或者解决问题的能力上来说，优秀程序员比差的程序员都何止好一点。Bill Gates：一个优秀的机床工值一个一般机床工的好几倍，而一个优秀程序员值一个一般程序员的10000倍。Robert C. Martin：90

9、%的代码是由10%的程序员写出来的。程序员因此被分为五大类：1. 大师级程序员（Visionary/Artist Programmer/）大师级程序员是软件界绝对的稀有种族，他们可以创造出99.9%的程序员所创造不出来的东西。他们发明新的应用和软件模式来驱动软件产业的发展。Napster, Netscape以及World Wide Web都是大师级程序员创造的。对他们而言，软件更多的是艺术而非科学。在这个级别，速度和质量不是最重要的，他们创造出的财富才是最重要的。许多开发团队或者公司顶多也就一个大师级程序员，通常是这个公司的技术创始人或者CTO。2. 开拓者程序员（Trailblazer Pr

10、ogrammer）开拓者程序员通常带来很好的主意和趋势。他们通常是最终产品的原型创作者，他们一天做出的事情大部分程序员需要几周甚至几个月。开拓者程序员总是在尝试新工具、新技术，不断地学习和搜寻方法来提高工作效率，并通常是其他程序员的导师和老师，而且你经常会发现当其他程序员早已离开的时候他们却依然工作到深夜。尽管这样级别的程序员工资很高，但是每个成功的公司或团队还是应该配备一两个开拓者程序员。3.骨干程序员（ Workhorse Programmer）骨干程序员是一个公司或者开发团队的脊柱，这些人尽管不是很有创新性，但往往比较高效且值得信赖。给一位骨干程序员一套模板和合适的工具，他们总能以最短的

11、时间交出错误最少的代码。4.机械程序员（ Drone Programmer）许多程序员就是朝九晚五地为了填塞下自己钱包的机械程序员。他们不愿意接触新技术、避免学习新事物。许多公司或者开发团队都有许多这样的机械程序员，因为他们很便宜，但岂不知更贵的程序员才真正地更便宜。5.白痴程序员（ Idiot Programmer）林子大了什么鸟都有，软件领域也不例外。编程需要抽象和逻辑思维，然而一些尚不具备此能力者由于向往着不错的薪水而加入了该领域。白痴程序员总是对最简单的算法也搞不清楚，他们总是错过软件截止日期，终日无所获。白痴程序员最好的出路就是换行。 从三十六计看软件测试之计1三十六计是根据我国古代

12、卓越的军事思想和丰富的斗争经验总结而成的兵书，古人用兵最讲究谋略，在中国古代战争史上，精彩的谋略计策层出不穷，令人眼花缭乱，但万变不离其宗，大抵都逃不过这三十六计的范围。时至今日，“三十六计”在我们日常的工作和生活中，同样可以有很广泛的应用。我是一名软件测试工程师，并热爱软件测试这一职业，目前从事测试已有一段时间，我很愿意将自已在从事软件测试工作中积累的一些经验，以及一些心得体会，借助三十六计中的若干计谋加以说明，与诸位同行分享。总说【原文】 六六三十六，数中有术，术中有数。阴阳燮理，机在其中。机不可设，设则不中。 【解析】“兵以诈立”，多谋者胜。用兵要讲究谋略，“运筹帷幄，决胜千里之外”。同

13、样的道理，无论从事什么样的工作，都需要讲究方式、方法。有了正确的方式方法，或者适时的运用一些小技巧，往往可以收到事半功倍的奇效。第一计瞒天过海【原文】 备周则意怠；常见则不疑。阴在阳之内，不在阳之对。太阳，太阴。 【译文】 防备周全时，更容易麻痹大意；习以为常的事，也常会失去警戒。秘密潜藏在公开的事物里，并非存在于公开暴露的事物之外。公开暴露的事物发展到极端，就形成了最隐秘的潜藏状态。 【解析】long,long ago,there is a 很厉害的程序员，名叫关羽，他是计算机专业科班出身，又拥有二十几年的编程开发经验，是当之无愧的资深软件工程师。虽然关羽的专业水平无庸置疑，但是他有一个缺点

14、，就是自视过高，骄傲不可一世，他常常认为自己写的代码十分完美，几乎已经到了自恋的程度。他看不起测试人员，对他们提出的程序错误不仅不屑修改，甚至于不肯承认，并经常与测试人员起争执。有一年他在湖北荆州负责一个十分重要的大型系统的开发，而负责这个系统测试工作的正是关羽向来都瞧不起的吕蒙。这个吕蒙原本学历不高，只有中专文化程度，并且还不大注重学习，提高自己的能力。直到有一次被他的上司孙权教育了一顿，从此发奋图强，进步神速，技术能力迅速提高，早已不是当日的吴下阿蒙。起先吕蒙将发现的错误上报给关羽，关羽并不理会，还是如同以往一样，找出许多理由来搪塞，一会儿说这是个技术难点，无法修改，一会儿又说这是当初的需

15、求没有写清楚。这吕蒙早就清楚关羽的为人，从此也不与关羽多加争辩，只是兢兢业业的做着自己的工作，将自己在测试过程中发现的所有小错误一一如实记录了下来。等到测试报告出来的时候，关羽傻了眼。由于他一时疏忽而犯下的一个小错误，并且错误扩散到整个系统的每个角落，已经无法修改。客户大为不满，项目终于失败！而老板一气之下也把关羽炒了鱿鱼。关羽的一世英名就这样毁在自己的大意上面。这就是在IT业界流传很广，十分有名的“关羽大意失荆州”的故事。从这个故事中我们可以得到以下几个教训：1、越是厉害的人物，越容易阴沟里翻船，水平很高的程序员，也很容易因为不注意细节而犯下一些低级的错误。所以身为一名测试者，不能迷信权威或

16、专家，对就是对，错就是错，要勇于怀疑一切。时刻牢记我们代表的是最终用户，并建立这样一个观点：即使一个错误不是程序本身的原因，而是因为操作不便而使用户造成，严格说来，那仍然是一个错误。从三十六计看软件测试之计22、测试者与开发者的地位是相对独立，但绝不是势同水火，双方彼此同样是项目组的成员，在保证软件产品质量这个大方向上是一致的，彼此都应该互相尊重对方的劳动成果，虚心对待。关羽的直接领导诸葛亮早就告诫过他这一点，让他一定要尊重测试组的劳动成果，不要双方闹翻。可关羽硬是不听，于是造成项目失败。 3、在测试工作中，测试者与程序员的沟通是十分重要的。在双方互相尊重的基础上，彼此都要本着对事不对人的原则

17、，保持严谨的科学态度，共同完成软件的开发。上面的故事中，吕蒙的做法其实也不是十分的正确，不仅遭到了大量关羽的fans的指责，而且长久背负着做人不厚道的骂名，这些倒不重要，更为重要的是，最终整个系统、整个开发团队失败了，他同样是个失败者。更好的做法是在测试的工作中，就要注重沟通问题，当一个错误一直不被修改的时候，与开发人员沟通失败后，应该及时上报给项目的管理者，尽早寻求解决的方法，而不是将错误一直留到测试结束后才暴露出来，此时的错误可能已经造成十分严重的后果，测试报告写得再漂亮也已经没有多大的意义。基于以上陈词，本庭宣判：本案关羽负主要责任，吕蒙负次要责任。关羽斩首，吕蒙打五十大板！_4、想要做

18、好测试工作，学历和技术并不是最重要的，重要的是要有责任心和细心，中专毕业证书是中专学校发的，大学毕业证书是大学发的，而有了责任心和细心的测试员，就不再是普通的测试工程师，而是优秀的测试工程师了。在开发一个软件产品的过程中，每一个程序员都需要跟成千上万行的代码打交道，他们自己写的代码就像大宝SOD蜜一样的天天见，看多了难免叫人头昏眼花胸闷心烦再加上每天都看见的东西，很容易就会产生思维定式。一个人偶尔犯错并不可怕，可怕的是他对错误熟视无睹，错啊错啊的就习惯了，于是很自然的把错的当成对的。俗话说“老虎也有打盹的时候”，水平再高的程序员也会有犯错误的时候，因此必然会有一些错误和缺陷是很难被自身发现的，

19、其原因可能是他在阅读需求规格的时候惦记着那天和女朋友吵架的事情开了小差，从而没有好好地理解需求；也可能是他那天正好失恋心情不好而犯迷糊，更可气的是他居然说女朋友都跟别人跑了我的程序写得那么好有什么用，我偏要这么写所以说没有BUG的软件是不存在的（否则广大和我一样的软件测试工作者靠什么混饭吃？_）。“阴在阳之内，不在阳之对”，我们那些无比智慧而英明的祖先在这里清楚的告诉我们，一个软件产品中最大、最致命的BUG，往往不是如你想象的那么隐蔽、那么难找，而经常是潜伏在你最没有防备、以为最不可能出错的那些地方。这便再一次的证明了这样一个道理：在软件的世界里，不是缺少BUG，而是缺少发现BUG的眼睛！初学

20、者福音C语言的编程风格 缩进格式 Tab是8个字符,于是缩进也是8个字符.有很多怪异的风格,他们将缩进格式定义为4个字符(设置为2个字符!)的深度,这就象试图将PI定义为3一样让人难以接受. 理由是:缩进的大小是为了清楚的定义一个块的开始和结束.特别是当你已经在计算机前面呆了20多个小时了以后,你会发现一个大的缩进格式使得你对程序的理解更容易. 现在,有一些人说,使用8个字符的缩进使得代码离右边很近,在80个字符宽度的终端屏幕上看程序很难受.回答是,但你的程序有3个以上的缩进的时候,你就应该修改你的程序. 总之,8个字符的缩进使得程序易读,还有一个附加的好处,就是它能在你将程序变得嵌套层数太多

21、的时候给你警告.这个时候,你应该修改你的程序. 大符号的位置另外一个C程序编程风格的问题是对大括号的处理.同缩进大小不同,几乎没有什么理由去选择一种而不选择另外一种风格,但有一种推荐的风格,它是Kernighan和Ritchie的经典的那本书带来的,它将开始的大括号放在一行的最后,而将结束大括号放在一行的第一位,如下所示: if (x is true) we do y 然而,还有一种特殊的情况:命名函数:开始的括号是放在下一行的第一位,如下:int function(int x) body of function 所有非正统的人会非难这种不一致性,但是,所有思维正常的人明白: (第一) K&R

22、是_对_的,(第二)如果K&R不对,请参见第一条. (:-)另外,函数也是特殊的,不一定非得一致. 需要注意的是结束的括号在它所占的那一行是空的,_除了_它跟随着同一条语句的继续符号.如while在do-while循环中,或者else在if语句中.如下: do body of do-loop while (condition); 以及if (x = y) . else if (x y) . else 理由: K&R. 另外,注意到这种大括号的放置方法减小了空行的数量,但却没有减少可读性.于是,在屏幕大小受到限制的时候,你就可以有更多的空行来写些注释了. 命名系统C是一种简洁的语言,那么,命名也

23、应该是简洁的.同MODULE-2以及ASCAL语言不同的是,C程序员不使用诸如ThisVariableIsATemporaryCounter之类的命名方式.一个C语言的程序员会将之命名为tmp,这很容易书写,且并不是那么难以去理解. 然而,当混合类型的名字不得不出现的时候,描述性名字对全局变量来说是必要的了.调用一个名为foo全局的函数是很让人恼火的.全局变量(只有你必须使用的时候才使用它) ,就象全局函数一样,需要描述性的命名方式.假如你有一个函数用来计算活动用户的数量,你应该这样命名-count_active_users()-或另外的相近的形式,你不应命名为cntusr(). 有一种称为H

24、ungarian命名方式,它将函数的类型编码写入变量名中,这种方式是脑子有毛病的一种表现编译器知道这个类型而且会去检查它,而这样只会迷惑程序员. -知道为什么Micro$oft为什么会生产这么多臭虫程序了把!. 局部变量的命名应该短小精悍.假如你有一个随机的整数循环计数器,它有可能有i,如果没有任何可能使得它能被误解的话,将其写作loop_counter是效率低下的.同样的,tmp可以是任何临时数值的函数变量. 如果你害怕混淆你的局部变量的名字,还有另外一个问题,就是称function-growth-hormone-imbalancesyndrome. 函数函数应该短小而迷人,而且它只作一件事

25、情.它应只覆盖一到两个屏幕(80*24一屏),并且只作一件事情,而且将它做好.(这不就是UNIX的风格吗,译者注). 一个函数的最大长度和函数的复杂程度以及缩进大小成反比.于是,如果你已经写了简单但长度较长的的函数,而且你已经对不同的情况做了很多很小的事情,写一个更长一点的函数也是无所谓的. 然而,假如你要写一个很复杂的函数,而且你已经估计到假如一般人读这个函数,他可能都不知道这个函数在说些什么,这个时候,使用具有描述性名字的有帮助的函数. 另外一个需要考虑的是局部变量的数量.他们不应该超过5-10个,否则你有可能会出错.重新考虑这个函数,将他们分割成更小的函数.人的大脑通常可以很容易的记住7

26、件不同的事情,超过这个数量会引起混乱.你知道你很聪明,但是你可能仍想去明白2周以前的做的事情. 注释注释是一件很好的事情,但是过多的注释也是危险的,不要试图区解释你的代码是注释如何如何的好:你应该将代码写得更好,而不是花费大量的时间去解释那些糟糕的代码. 通常情况下,你的注释是说明你的代码做些什么,而不是怎么做的.而且,要试图避免将注释插在一个函数体里:假如这个函数确实很复杂,你需要在其中有部分的注释,你应该回到第四章看看.你可以写些简短的注释来注明或警告那些你认为特别聪明(或极其丑陋)的部分,但是你必须要避免过多.取而代之的是,将注释写在函数前,告诉别人它做些什么事情,和可能为什么要这样做.

27、 你已经深陷其中了. 不要着急.你有可能已经被告之GUN emacs会自动的帮你处理C的源代码格式,而且你已经看到它确实如此,但是,缺省的情况下,它的作用还是不尽如人意(实际上,他们比随便敲出来的东西还要难看- ainfinite number of monkeys typing into GNU emacs would never make a good program) 于是,你可以要么不要使用GUN emacs,要么让它使用sanervalules.使用后者,你需要将如下的语句输入到你的.emacs文件中.(defun linux-c-mode() C mode with adjuste

28、d defaults for use with the Linux kernel.(interactive) (c-mode) (c-set-styleK&R) (setq c-basic-offset8) 这会定义一个M-x Linux-c-mode的命令.当你hacking一个模块的时候,如何你将-*- linux-c -*-输入在最开始的两行,这个模式会自动起作用.而且,你也许想加入如下(setq auto-mode-alist (cons (/usr/src/linux.*/.*.ch$ . linux-c-mode) auto-mode-alist) 到你的.emacs文件中,这样的

29、话,当你在/usr/src/linux下编辑文件的时候,它会自动切换到linux-c-mode . 但是,假如你还不能让emaces去自动处理文件的格式,不要紧张,你还有一样东西: 缩进 . GNU的缩进格式也很死板,这就是你为什么需要加上几行命令选项.然而,这还不算太坏,因为GNU缩进格式的创造者也记得K&R的权威, (GNU没有罪,他们仅仅是在这件事情上错误的引导了人们) ,你要做的就只有输入选项-kr -i8(表示K&R,缩进8个字符). 缩进有很多功能,特别是当它建议你重新格式你的代码的时候,你应该看看帮助.但要记住: 缩进不是风格很差的程序的万灵丹.成长的烦恼：初涉设计模式相信很多人

30、都喜欢看这部喜剧，我是很喜欢，里面包括了成长中的悲欢离合，你在其中可以寻找你成长的足迹。 编程成长之路何尝不是这样的呢？故事就是从这里开始的。小王是刚毕业的学生，进入一家软件公司，薪水不错。年轻人充满干劲，有着远大的目标。前三天参加了公司的培训，三天没写代码了，手痒。第四天，项目经理走过来说：“小王，写一个整型链表的排序算法吧，我们在项目中要用。”冒泡是小王在脑海中第一个浮现出来的。翻开某某圣经，摘了段冒泡算法，修改了一些代码的书写风格（有些圣经代码风格不咱的），代码大致如此： BOOL Sort(ListInt) 冒泡排序算法 比较语句 return TRUE； 小王检查了一下，还用测试用例

31、测试了一把，确保万无一失，交给了经理。经理说了句不错，乐坏了小王。第二天，经理跑过来说：“把你昨天的代码改一下，现在要比较浮点型了，还有能否速度上提高一点？”小王上网查了一下，选择了快速排序算法，不忘把昨天写的备份了一把，然后在昨天函数的基础上改。代码大致如此： BOOL Sort(ListInt) 快速排序算法 比较语句 return TRUE； Easy吗？测试交差。 一年后镜头切换小王坐在计算机前熟练的编写着程序，而且旁边还放着本设计模式的书。知道了面向对象编程，知道了设计模式，但理解还不够深刻。排序算法也演变成比较文件名了。一日经理过来说：“小王，现在我们的排序算法要用在嵌入式平台中，

32、你做一些算法的研究工作，给出一份报告。”这不是策略模式的典型应用吗？定义一系列的算法，把它们一个个封装起来，并且使他们可以相互转换。这样，小王把一些流行的排序算法都试了一遍，总共有七八种，换一种算法速度也很快，新的算法插入到系统中，老算法从系统中退休，实现插件式替换。 CSort *pSort new CBubbleSort; CClient.ListSort(pSort);如果要改成快速排序，只要如此： CSort *pSort new CQuickSort; CClient.ListSort(pSort);测试交差，当然经理自己也有想法，又让小王试了另外的几个算法，小王都能轻松的完成。策略

33、模式的作用在这里淋漓尽致的发挥了，小王心里特别有成就感。过了些日子，客户提出需要按文件名、日期进行排序，小王觉得这还是比较简单的，改代码的主要工作是copy-paste，就四个函数，也就很快完成了。客户的需求是不会停止的，为了加强功能，提出需要按文件大小、文件的类型排序，天知道客户还会提出什么要求。“再也不能这样活”，小王听着歌，陷入了沉思。“排序的算法和比较算法分开来会如何呢？把它们脱耦，使得二者可以独立地变化。这句话怎么这么熟悉，我肯定在哪里看到过。”小王忙翻开设计模式，开始查阅。“Got it，这不就是桥梁模式（Bridge）。”一阵欣喜，马上就干。 客户端代码如下： CSort *pS

34、ort = new CQuickSort; CCompareType *pType = new CNameCompare; pSort-SetType(pType); pSort-Sort(pList); 哈哈，客户们，你们尽管提要求吧。 测试之颠，必先利其器孔子曰：“工欲善其事,必先利其器”，其大体意思是：孔子告诉子贡，一个做手工或工艺的人，要想把工作完成，做得完善，应该先把工具准备好。时至今日想起此话很有道理，在我们的测试工作中又何尝不是呢！只是对其“器”即所谓的工具的范围更广了而也。在纷繁复杂和反复无常的测试工作中其所用的“器”那是至关重要的，其器可以从两方面来讲：一方面是测试时所具备的

35、工具；另一方面则是测试人员本身，这一点是对器的含义的衍生，相对前者就更加重要了。工具是基础，是开展一切事项的根本前提，在人类起源之初因为原始的高级动物具备了工具从而使之开始劳动，进而成为现在我们人类，可想而知其工具的魅力所在。在测试工作中使用一个好的测试工具是很有必要的，目前市场上所出现的测试工具不难分出如下几类：为减少重复测试工作的自动化测试工具高精度专业化的专用测试工具软件开发过程中各阶段使用的辅助测试工具面对如此繁多的测试工具我们应该如何对待呢？其实每一个工具均有其自身的特点，这也是每个工具存在的唯一理由，不可能有一种工具什么都能做，或者什么都不能做，要是真有什么都不能做的工具那就不叫工

36、具了。在这里需要强调的是并不是使用的工具越多测试工作就做得越好，其实即使在经济上允许的情况下使用了一些没有必要使用的工具也许是一种累赘，况且据我所知很多公司都不愿意把大把的钱花在买测试工具上，更何况该测试工具是一种累赘。简单来讲就是在当前环境下我们要使用适合当前项目和符合公司及团队运作的测试工具。所谓的当前环境是指目前在项目进度和项目预算这种前提下是否允许我们使用某个测试工具；所谓适合当前项目是指是否在这个具体的项目中使用这个测试工具能够提高测试效果和效率；所谓的符合公司及团队运作是指公司及团队的发展战略及相关规程是否能够使这个测试工具能够更好的运作起来以此来发挥其最佳效果。分析好以上所说的“

37、三个所谓”的问题，对于决定是否需要这个测试工具那是一件非常容易的事了，如果没有解决好以上“三个所谓”的问题那么就最好不要选用这个测试工具。关于如何选择一个测试工具请参考WAYNE先生的一文如何选择嵌入式白盒测试工具，在此文中对于测试工具的选择有非常精辟的阐述。那么拥有一个非常适合的在业界也是比较优秀的测试工具就够了吗？当然不是了，要不测试人员就要下岗了。测试人员是灵魂，工具毕竟只是个听从指挥和执行命令的一个实体，不能像人一样发挥主观能动性，不具思维，更不用说是发散思维了，不能执行一些创造性的工作。所以说除了有一个非常适合的在业界比较优秀的测试工具之外，更重要的还需要一个非常优秀的测试人员，需要

38、这个灵魂来*纵测试工作的一切。一个优秀的测试人员具备如下素质是很有必要的：一、软件开发和设计功底，这个是基础，如果一个不懂得开发的人员来做测试工作其实很容易想象测试工作是多么的糟糕，其道理也很简单，在此也不再提及，但很遗憾的是在这个观点上往往会有人知错犯错，导致总是会有一些测试人员不是很懂得开发的一些东西，这种现状希望在不久后会彻底消失；二、测试理论和测试思想，这点就很容易理解了，这也是作为一个测试人员的基础，要做到这点相对比较容一些；三、不仅要学会使用测试工具，更要在平时的测试工作中加以提炼创造测试工具，以至更好的为测试工作服务，提高测试效率和测试工作的共用性；四、测试人员个人的素养，这里主

39、要是指个人的沟通、交流等方面的能力，还有就是测试人员所具备的比较特殊的发散思维和逆向思维。在测试工作中除拥有一个好的测试人员外，更加拥有一个适合的比较优秀的测试工具，这两者相结合，那么做好一项测试工作就很容易了，只要拥有了这两项利器相信测试工作会获得更大的成功，需要说明的是并不是每一项测试工作一定需要测试工具来辅助完成，而是需要应该需要的工具。当然还需要组织及团队有效的推动和支撑，这样其测试工作将会发挥到极致，以至登上华山之颠！时至那时，测试行业的发展将会拔开云雾阳光普照。测试工程师的十二最测试工程师最开心的事:发现了一个很严重的bug,特别是那种隐藏很深,逻辑性的错误.偶第一次发现这种问题的

40、时候,听到上司和开发人员的表扬时,高兴的就想扭pp.不过现在慢慢矜持些了,呵呵. 测试工程师最提心吊胆的事:版本release出去后,客户发现了很多或很严重的bug.经过紧张的系统测试之后,好不容易可以轻松一下了,却又陷入了每天担心正在做验收或使用的客户一封邮件或一个电话说产品有问题.碰到好些的老板还会比较乐观的看这样的问题,最惨的就是有些人一顿臭骂,之前的辛苦,加班全部都给抹杀了.测试工程师最憎恨听到的话:为什么这个bug没有在测试的发现呢?这句话经常是客户发现bug后,老板对测试人员的质问.当然这里排除那种很明显的错误.其实谁都知道bug是不可能全部发现的,这句话其实也是客户对大头,大头对

41、小兵一级一级问下来的.除了希望测试人员警惕之外,还有更多的是一种踢猫的行为.对于这句话,偶第一次听到这句话的反映是我们怎么可能发现所有的bug呢,后来变成制造bug的人不是我们,是开发,到现在的让我查查我的日志,问问开发这个bug的原因,为什么我们会没有找到,下次我们会怎样的回复.测试工程师最郁闷的事:刚才那个版本打包打错了,你们要重测.新版本来了,马上投入紧张的测试,希望能够多找些bug.没想到辛苦了可能大半天,开发人员说打包打错了,你重测吧.这种情况虽然可以通过规范流程之类的办法控制发生的机率,但人总会犯错,多少而已.碰到这样,你除了提醒开发部门下次注意,你除了重测没有太多办法.测试工程师

42、最不想面对的事:在测试晚期或最新的版本里发现了以前一直存在的问题,特别是当问题很严重时决定到底报不报bug.报吗,开发人员肯定会问以前有没有这个问题,不报吗,客户发现更惨.毕竟客户或老板的责备比开发部门或主管的责备轻许多,最后还是会报到bug库里的.测试工程师最不想做的事:申请版本推迟发布.由于在版本发现了太多的问题,觉得产品不能达到发布的标准,建议公司推迟发布产品.这时虽然大家都知道产品有问题,尽管你自己也不希望这样,但谁都觉得你是一个制造麻烦的人,毕竟市场的压力很大呀.测试工程师最丢人的事:辛苦的发现了一个bug,居然是该配的参数没有配等一些自己的失误造成的.有些该注意的地方居然测试时忘了

43、,找出的问题给开发人员一顿臭扁,无比丢人啦.测试工程师最怕的事:一天,甚至几天都没有发现一个bug!经过一段时间的bug高峰期后,有段时间会发现bug数量的减少,最可怕的就是一天都没有发现一个bug.偶有时会难过的吃饭都没心情.搞得偶的开发朋友说了一句最让人吐血的话:要不要我在代码里放几个bug给你呀,hoho测试工程师最伤心的事:每年的调薪,发bonus或发股票时,测试工程师总比开发工程师少.偶有一同事在调薪的第二天就申请转开发,说测试太没前途了.测试工程师最有力的保护方法:把你认为是bug的问题都提交到一个正式的,可以追踪的地方(一般来说是bug库).有时总会碰到一些很小的或是很难判断的问

44、题,犹豫一定是否要报,特别是一些UI的问题.有时问开发人员,他们可能会轻描淡写的回复你导致你没有report它.但多年的经验一定要报,了解bug流程走向的人都知道,后面还有人verify,还有开发经理判断,如果不是bug,自然他们会回复,会写明原因.说白了,出了问题也不是你的事情.当然一开始经验不足时会收到一些白眼球,但慢慢经验多了,对系统熟悉了,自然这种情况会少些.人也可以从一些问题中发现自己的弱点.但如果不报,那天客户提出来,你除了懊悔还要面对指责,严重的炒鱿鱼.测试工程师最任重道远的事:测试驱动开发.碰到这种开发模式的项目,既是测试扬眉吐气的机会,也是可能会陷你于深渊的恶潭.你就必须打起

45、十二分的精神.等于你在引导开发,有什么问题一定要提出来,否则你就等着被盲目的牵着鼻子走了.测试工程师最期待的事:测试能够越来越受重视,测试工程师的考核越来越合理. 操作系统UML与面向对象数据库考试模块指导操作系统和数据库是程序员和软件设计师每年的必考内容，从1987年到2005年春季软考都少不了它们的身影。 近年来，程序员和软件设计师大纲虽做了一些大的改动，但操作系统部分变动并不是很大，上午分值多是1到5分之间，下午是不确定出题，也就是可能会出到，也可能没有。但不可大意，如2004年秋季下午题的第四题就是道操作系统题。另外，在出题形式上更趋于具体的分析，而不再是纯粹的概念题。如PV原语操作就

46、比较多偏向于对生产者/消费者问题的解答。大纲所列知识点虽不能全部都涉及到。不过再通过我们对历年题型的综合分析后(特别是1995到2005春季)，可以明确的是操作系统方面的题目，一般集中在进程，存储管理和作业管理这几个方面。1998年到2000年这几年的操作系统，有很多是重复出题，而且都集中在上面说的几个方面。希望各位考生在复习时把主要精力放在主要知识点上。数据库在程序员和软件设计师的出题中比重不小。分值上午一般会有5分左右，下午有和软件工程结合出题，或者与UML联合出题的情况。这种结合多是考查ER模型到关系模式的转换，以及用SQL来建立关系模式，2005年春季考试上下午都有数据库的题，且下午是

47、独立题目。而且我们思达网校的老师一致认为这是考生朋友们应该牢牢抓住分数的部分。具体的重点是很清晰的，ER模型和关系模式之间的转换，关系代数，关系演算，范式，SQL语言(查询的比重较大)。复习时应注意掌握以上这些知识点。面对对象和UML是新大纲的新要求，可以参考的并不多。不过对概念的考查火力比较强，考生很不容易在面对对象方面的众多概念中拿到分，这就要求考生朋友们一定要注意平时在复习时就把这些内容有意加强记忆。UML是在下午题中出现，从2004年春季考到2005年春季考的下午试题中发现出题UML的火力点多在对各种静态图和动态图。采用简化原型法进行需求分析顺序阶段的观点2，改变了传统的自顶向下的开发

48、模式，降低了软件需求的风险，因此得到了广泛的应用，特别是在致力于某一领域MIS开发的软件公司，如致力于电力MIS开发的公司。但作者在长期的MIS需求分析过程中，发现原型法有以下缺陷：1）原型的设计和修改工作量大，增加了系统的开发成本；2）由于用户不关心或不理解原型的概念和实现，而且存在较大期望，使得与实际系统差别较大的原型增加了需求分析人员与用户的交流难度；无论是水平原型，还是垂直原型都不能反映实际系统的全貌；3）软件需求主要包括：功能需求、界面需求、性能需求、环境需求、可靠性需求、安全保密需求、资源使用需求、软件成本消耗与开发进度需求和目标需求3。原型法中的原型难以表达软件的后七项需求；4）

49、原型法强调用户和开发人员不断对原型进行不断修改和补充，直到用户感到满意为止。在时间紧和任务重的大型MIS项目中，这种情况实际难以保证，特别是在用户单位和开发单位距离较远时。本文结合管理信息系统项目实施的实践，提出一种新的需求分析方法-简化原型法。这种方法根据数据库应用的特点，将需求分析分为两个阶段，并简化了作为需求分析工具的系统原型。 2 简化原型法需求分析的第一个阶段管理信息系统属于数据库应用。数据库应用需求分析应该围绕数据，而不是功能展开，因此应该首先解决有什么，然后再明确做什么4。第一个阶段就是要解决有什么，即由项目经理与用户进行协商，确定系统的技术协议，因此可以称为技术协议阶段。技术协

50、议需要开发方的项目经理与用户单位的技术主管签字并盖章，并以合同附件的形式存在。技术协议的主要内容有：系统的边界、系统处理的业务、与其它系统的接口、工程的进度控制、培训安排和技术服务承诺。 2.1 系统的边界系统的边界规定系统覆盖的作业范围，主要有地理边界（规定系统运行的部门、分支单位等）、操作员范围（规定操作系统的所有操作员身份、分布和大致权限）和业务范围（规定系统处理的业务，对于不处理的边沿业务特别明确指出）。 2.2 系统处理的业务系统处理的业务涵盖系统处理的所有业务，包括各种业务的描述、数据来源、实现要求。但是业务规定不要求过细，可以对应实际系统中的一个模块。如：电力MIS中输电设施管理

51、子系统中的线路设备管理，不详细描述线路设备管理中的所有功能。 2.3 与其它系统的接口与其它系统的接口明确规定接口的系统、功能和实施单位。在接口的实施单位中明确是由开发方完成，还是由开发方协助第三方完成。 2.4 工程的进度控制工程的进度控制规定工程的开始、结束日期和具体工程项目的名称、完成时间、地点、完成标志及责任分工。具体项目一般包括：采购设备到达现场、采购设备安装调试、完成网络布线、开发准备阶段、业务需求调查、系统分析和设计、软件编制、现场调试、数据准备及录入、功能确认、试运行和系统验收。责任分工规定双方对于具体项目的工作内容和配合方式。在配合方式中规定人员组织方式、人员素质要求、提供的

52、设备和场所。完成标志规定具体项目完成提供的文件名称和要求，如：网络布线验收报告和硬件设备验收报告等。 2.5 培训安排训包括操作员和系统维护人员的培训。培训安排包括每种培训的人员数量、培训内容、培训时间、地点、组织方式和教材，并规定教员和学员的素质要求，及培训后学员达到的水平。 3 简化原型法需求分析的第二个阶段如果说第一个阶段解决有什么的问题，那么第二个阶段解决做什么的问题。主要工作有需求调查准备、到用户单位进行需求调查分析和进行需求评审。 3.1 需求调查准备需求调查准备工作，在系统的技术协议签订后，严格依照技术协议进行，主要有向用户单位发放业务调查表、建立需求分析文档原型和建立系统简化原

53、型。业务调查表在系统的技术协议签订后，立即通过传真发送到用户单位，要求用户单位在需求调查人员到达现场之前完成。业务调查表内容包括：具体业务的名称、上级业务、下级业务、发生条件、处理的数据和详细流程（处理岗位、处理方式和审核细节等）。需求分析文档原型是根据技术协议编写的需求分析说明书原型，它的格式与标准的需求分析说明书相同。其中的状态迁移图和各种表证单书等不明确的内容，采用相似系统的或由系统分析人员根据技术协议和以往经验设计。系统的简化模型根据技术协议的要求，仿照相似系统设计。简化模型采用可视化的数据库编程语言设计，一般采用数据库应用开发人员熟悉的PowerBuilder(PB)或Delphi。

54、简化模型的主要设计要求有：1）充分考虑系统的设计与实现，不得与实际系统脱节；2）尽量仿真实际系统的操作界面，与实际系统的操作过程完全相同；3）可以单机安装运行，不与实际数据库连接；4）演示数据的存储可以通过文本文件、单机的数据库或PB外部数据源的数据窗口；5）对于界面中容易误解或难以理解的操作，在功能帮助按钮中给出说明；6）界面中难以实现或工作量很大的功能，以标注方式详细说明；7）运行稳定，并比实际系统对硬件要求低。 3.2 需求调查分析需求调查分析在确认需求调查准备的三项工作完成后，由开发单位的系统分析人员到用户单位进行。系统分析人员与用户单位安排的业务主管共同讨论业务调查表和系统简化原型，

55、并不断修改完善系统简化原型和文档原型，最终形成共识，并要求业务主管在需求分析说明书上签字。最终系统简化原型和源代码留在用户现场，便于系统的操作员进一步理解分析，直到最终掌握；而且有利于提出进一步的改进意见。改进意见可以随时通过邮件或传真直接发到开发单位，或由用户单位的系统维护人员修改简化原型后，随时发到开发单位，从而便于开发人员及时修改系统的设计和编码。 3.3 进行需求评审需求评审一般由用户单位组织，评审团成员由同行专家、系统分析、设计和测试人员组成。评审的依据不仅有需求分析说明书，还有系统简化原型；同时在评审过程中，系统简化原型不断进行优化。评审的目标是要求需求分析说明书具有正确性、可行性

56、、必要性、具有优先级属性、可验证性和无二义性5。需求评审报告作为对需求分析的补充和修正，由双方负责人签字，以需求分析说明书附件的形式存在，同样指导下一步的系统设计工作。 4 几点说明1、此方法适合各种MIS工程的需求分析，特别适合致力于某一领域MIS开发的软件公司。采用此方法，开发同类项目越多，需求分析工作的效率越高。2、在需求分析过程中，由于需要设计系统简化原型和文档原型，并充分考虑到系统的设计与实现，因此与其它需求分析方法向比，提高了对需求分析人员的要求。在实际工作中，一般由资深的软件分析和设计人员进行。3、此方法不仅适合MIS软件工程，同样适合其它大型软件工程。4、由于需求分析工作本身的

57、难度和重要性，此方法同样要求用户单位和需求分析人员对需求分析所有工作内容，引起足够重视；科学安排需求分析工作步骤，某些步骤可以同时进行；所有工作步骤不得应负或疏忽。 5 结束语目前简化原型法已经在多个电力MIS工程中应用，大大提高了需求分析的工作效率。实践证明，简化原型法具有以下特点：1）简化的系统原型开发工作量大大降低，修改和补充方便；2）简化原型大大缩短了需求分析人员与业务主管之间的距离，便于交流；并大大加强了需求分析人员与业务主管对系统的认识，有利于发现和解决问题；3）简化原型的设计提前考虑了系统的设计与实现，大大降低了软件工程的风险；4）简化原型增加了系统操作员对实际系统的认识，大大简

58、化了工程实施后系统的操作培训；5）简化原型可以直接指导工程的设计和编码，便于系统开发的组织。这种方法也可以用于其它软件工程，对于其它需求分析方法的改革也具有指导意义。不要将默契式管理和人性化管理划等号学而优则仕在中国还是一个挺普遍的现象，给批判得也很多！但是原话是“仕而优则学，学而优则仕”，见于论语子张，其真正含义并不是我们片面理解的“学习优秀的就去做官”。同样，“仕而优则学”难道是告诉管理者：“做好了官，有余力则学习！”如果你认定等我有余力才学习吗？呵呵，那你永远也没有有余力的一天。在IT行业，不少管理者都是技术出身，从论语这句话，我们应该学习到：当走上管理岗位，更加要“边干边学”，从工作中

59、学习提高业务知识和管理体系，持续改进，才能进入“仕而优则学，学而优则仕”的良性循环。（看来和CMMi的本质一致的！）案例一：某日抽检项目组O工作，检查项目经理L对任务的执行情况了解和把控，抽查本周内项目组成员C的工作任务时，发现项目经理L对C昨天的工作任务T1的工作完成情况并不了解。为了进一步了解C的工作完成情况，和项目经理L、同事C一起检查昨天C的全日任务T1，该任务是测试业主方的FTP上传、下载接口，而本日的任务T2是开发FTP上传模块。先是询问了同事C在昨天是否还开展了其他任务，答案是没有；接着询问任务T1除了使用java的.ftp程序包外，是不是还有特别的业务逻辑以及异常处理等处理，答

60、案是异常需要写日志记录；接着还告诉同事C，程序为了稳健性，处理正常的业务逻辑外，还有很多是针对异常的控制逻辑，除了使用log4j写入程序日志，还有什么特别的地方，C的回答是没有。事后和项目经理L分析，项目组O的工作方式，停留在按模块给成员派任务，成员将任务计划上报，项目经理L和技术经理LL则合并计划，解决人员间的任务冲突！但是任务的时间是否合理，没有进行评估和监控，小组评估法也好，专家评估法也好，总之没有评估监控环节，项目经理L和技术经理LL都缺位了。另外，工作的执行没有进行督促，没有每日的检查或者抽查，那么小组O里面，谁做到好，谁做得不好，只是拍脑袋；还有，项目组里面到底应该鼓励谁呢，谁是项