到了下午五点，经理放下手头的工作，给每一位员工打电话订餐。不一会儿，香喷喷的比萨就送到了办公室，大家一边吃着可口的比萨，一边加班，其乐融融。原本计划加班到晚上8点，由于员工热情高涨，提前半个小时就完成了任务。而且，没有一位员工有怨言。

　　我们工作的环境不是真空的，人具有社会属性，需要与其他人协作。而要实现预期的目标，就必须依赖所有的员工，即使管理者再优秀，也不可能一个人包干所有的事。这就需要管理者运用适当的方法，调动员工的积极性，挖掘工作潜力。

　　尊重员工劳动成果

　　早期，我曾在一家连锁售药公司负责员工的招聘。当时，这家售药公司正处于发展期，在公司的计划书里已经确定了扩大公司规模的方案，公司正在筹建更多的新药店。因此，每一个新药店需要两名药剂师。我们认真研究了91位应聘者的资料，并筛选出27名比较优秀的应聘者。

　　当时，公司缺乏药剂师，如果招聘不到足够的药剂师，新药店就开不成。在这种严峻的形势下，我投入了很多的精力研究公司的招聘，很快发现了3个问题。

　　首先，别的竞争对手给药剂师的工资比我们公司高一些，虽然仅高一点点，但对药剂师还是有一定的诱惑力。其次是心理的因素。在过去，我们公司要求药剂师在上岗之前必须接受测谎仪检测，许多人看到这一条时，就放弃了应聘的念头。我们去掉了这一应聘条件，但因为这是行业惯例，仍然有人认为公司招聘新员工时要用测谎仪检测，这对公司的负面影响很大。最后，我所在的公司与大学毕业生的联系不够密切，不了解他们的就业倾向。当我们到医药大学去招聘时，大学里的60个毕业生中只有几个人来面试。医药大学的毕业生根本没把我们公司作为一个理想的工作单位。

　　为了解决这些问题，我说服高级管理层，为员工增加工资。接着，我单枪匹马地展开公关活动，到其他公司的连锁药店里与药剂师们交流与沟通，告诉他们我们公司再也不进行测谎仪检查。同时，向这些药剂师们宣传公司的发展平台，让他们转变对我们的看法。然后，我到医药大学与大学教师和行政人员沟通，让他们帮助宣传公司的优厚招聘条件。

　　付出得到了应有的回报，最后，有近50名大学毕业生到我们公司应聘，原来的27个空缺职位都找到了合适的人选，后来增加的12个新职位也找到了应聘者。公司再也不会因为人才缺乏而窘迫了。

　　当我扬扬自得地沉浸在成功的喜悦之中时，却听到人力资源部总管对外宣称他是这次招聘的头号功臣。一周之后，在一次公司大会上，人力资源部总管得到公司总裁的嘉奖，参加大会的公司管理层称赞他力挽狂澜，促进了公司发展。当我忿忿不平地看着他时，他把脸扭过去，看都不看我一眼。

　　从那以后，我就像被打败的落汤鸡一样，再也打不起精神，再也没有勇气与动力主动解决公司机制性的问题。总管的伎俩让我失去了对公司的忠诚与投入。

　　其实，当时如果我的总管说一句话，哪怕是告诉与会的所有人：“我认为我们应该感谢Lynda在招聘中所作的努力。”我也会继续忠诚并充满激情地为公司工作。

　　如果员工取得了很好的业绩，就应该及时认可并予以奖励。只有这样，工作优秀的员工在以后的工作中才会产生更高涨的热情，才会加倍为公司效力。

　　激励应因人而异

　　我们还应该对症下药地针对不同员工制订不同的激励计划，采取不同的激励手段。许多管理者向我抱怨：“我寻找不到始终充满激情与动力的员工。有时候，招聘来的员工在开始工作时热情高涨，但过了几个月后，他们的工作热情与动力就逐渐消失。”我在与从事专业咨询服务的吉姆一起工作时，曾经讨论过这一话题。

　　吉姆采取了许多提高员工工作动力的方法，他使用过赞扬、奖状、为员工提供更多的休息时间、比萨派对，甚至用现金作为奖励。虽然吉姆煞费苦心，但员工并不买账，他们并没有因为他的奖励而提高工作动力。

　　也许有人会问，为什么会这样呢？因为他犯了激励管理中的一个通病：没有因人而异地激发员工的动力。

　　最后，吉姆不得不与所有员工面对面地沟通，询问每个员工希望从工作中获得什么。他非常认真地调查研究，最后确定每个员工在工作中寻找到的最有意义的动力源泉。他与4位员工沟通交流后，得到了三种答案。

　　一名员工希望自己在工作中，不断提高自己的服务水平，成为服务水平最高的员工，这是她工作的最大动力；有两位员工说，如果有自主决定工作方式的权力，他们才会感到自己在工作中的地位与作用；另外一名员工不仅喜欢自己从事的工作，还喜欢与工作有关的社交活动。

　　吉姆在收集到这些信息后，开始针对不同的员工制订不同的激励计划，采取不同的激励手段。现在，他所领导的团队具有非常高的工作动力与热情。

　　人类有一种与生俱来的渴望，渴望拥有看得见摸得着的财物（当然，也包括对一些无形的财产的占有欲）。员工在公司也有占有欲，希望占有与支配公司的物质与材料，希望自己的观点能够得到别人的认可，希望能够支配自己的工作，并拥有劳动成果。

　　此外，尊重员工也很重要。作为管理者，应该帮助员工创造与发掘机会，这种机会能够帮助员工释放出自尊的动力，让员工体验到工作的意义，感觉到自己这个工作岗位的重要性。

　　从本性来说，人是一种合群的动物，喜欢在某一个群体中生活。办公室也是一个交际的平台，在这里，管理者应该鼓励员工进行交流，培养员工的团队精神，让他们产生归属感。在工作中，员工都喜欢向某一个设定的目标发起挑战，在实现了一个目标后，就会向更高的目标前进。管理者要及时地认可与赞扬员工所取得的成就。

　　以小见大

　　如果你想激发员工的动力与创造力，就需要认真地观察员工在工作之余所做的事情。在办公室里，管理者应该如何因势利导地利用员工的工作热情，发挥他们的才能与创造力呢？

　　几十年的管理经验告诉我，员工有机会聚在一起一边品尝美食，一边交流与沟通，是建立良好公司人际关系的最好方法。在人际交往过程中，食物往往扮演着亲善大使的身份，它能促进人与人之间的联系。

　　在美国橄榄球超级比赛期间，食物成为人们一起观看球赛时分享的重要物品。一起分享食物，表现了人与人之间的联系，它反映了人与人有福同享、有难同当的一种情感纽带。在工作之余，一起品尝甜美可口的食物，可以大大改善办公室的气氛。

　　有一家公司曾巧妙地把食物作为提高员工责任心、增进对员工背景多样化的包容与理解的工具。这家公司的员工每周举行一次午餐会，而且每一周的午餐都是非常独特的。例如，这一周的午餐是墨西哥风味的，下一周午餐可能是日本风格的，再下一周可能就是牙买加特色的午餐……

　　这家公司尊重不同员工的民族背景与饮食习惯。在午餐聚会时，公司有时从饭店预订饭菜，有时让员工亲手在家里做好饭菜后带到公司与其他员工一起分享。每一个人品尝了特色午餐后，公司会进行一个小节目，介绍午餐会上的特色午餐所代表的民族文化特色。在这个小节目中，可以播放有民族文化特色的录像，也可以展开小小的讨论，或者是聚在一起讲讲笑话。最重要的一点是：员工有机会聚在一起，一边品尝美食，一边交流与沟通。在沟通中，员工在了解同事的文化背景的同时，也会更深刻地理解公司尊重文化多样性的价值理念。

　　如果你是一个管理者，是如何改善办公室工作气氛的？如果心里没谱，就虚心地询问一下自己的员工，员工的建议是最实用的。

一、问题：

　许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

　当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

从此几乎很少被执行
已经与程序的实现发生了冲突（界面变动，功能变动）
执行用例发现的bug很少
根本没有时间为新的功能需求增补用例
有时间补充，但用例结构越来越乱，
特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）
知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）
通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。
但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。

二、原因：

　事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

1、没有适合的规范

　“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？

　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？

　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往?的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。

　我们有太多经验，但却没有形成适合的规范。

2、功能与业务的分离

　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

　用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

3、测试未能跟上变化

　变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

　对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

　疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。

　永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能的解决办法：

　在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

1、测试驱动开发，用例指导结果，数据记录变化

　“测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

　首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

　如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导过程和结果。

　开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

　业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

　我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

　再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

2、为用例标明时间（版本）和优先级

　为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

　为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

3、功能用例与业务用例分开组织

　将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。

4、审核用例，结对编写

　测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。

　测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加

如今却非常热爱软件测试，包括软件测试工具，方法，理论，技术。因为我在3年的测试工作中，深刻体会到软件测试的重要性和趣味性。此时，我已经跳出了“小程序员”的圈子，以软件系统工程的更大视角审视软件测试这项工作。

很长时间以来我一直被下面的问题而困惑，有些问题至今仍然只是具有肤浅的认识，而且，我感觉我做的测试项目越多，阅读的测试书籍越多，我越感到我对软件测试理解的越肤浅。因为我越来越感受到软件测试的广度和深度的无限性，它像大海宽广，像宇宙那样深邃。 为什么要进行软件测试？软件测试的前途如何？软件测试的工具和思想谁更重要？软件测试的最高境界是什么？

软件测试是保证软件质量的重要活动，是软件项目实施的不可缺少的环节。软件测试的直接目的是发现软件中存在的缺陷。此为测试的有效性。

在软件项目没有结束之前的全部软件缺陷主要由软件开发人员负责，因为软件缺陷来自程序员的编程。软件项目结束后的软件缺陷主要由软件测试人员负责，因为软件测试人员没有在软件发布之前的测试中没有发现隐藏的错误。 但这不是绝对的，因为软件项目是一个系统工程，软件质量牵扯到多个部门和人员，以及需求分析，设计，编码等各个环节和过程。软件测试只能证明软件存在缺陷，不能保证软件没有错误。

软件测试不是万能的，因为不可能发现全部的软件缺陷，而且软件的功能和性能不是由测试决定的。此为测试的有限性。

软件测试目前主要以手工测试为主，自动测试工具虽然很多，但实际应用的广度和深度还有很大潜力，自动将有很大的发展空间！。

软件驱动开发的观点说明了测试与编程的关系，测试应该贯穿于软件开发的整个生命周期，编程只是软件开发的一个环节。但往往大家非常重视软件编程，把测试作为编程后的一个辅助环节。这是典型的本末倒置。 软件测试的缺陷管理流程非常重要，报告的软件缺陷的质量，应该由他人验证，做到责任明确，方法简便可行。

软件测试技术不断进步，但总体来看，国内的测试重视程度还不够，但已经发展很快。差不多两年之前，国内计算机书店中关于软件测试的书籍非常稀少，如今却琳琅满目，异彩纷呈。

软件测试是个可以很快入门的职业，门槛不高，但是，不要认为什么人都可以做好软件测试。因为会做和做好是两个概念。软件测试人员最好具有软件开发经验，理解软件工程的知识。这是提高软件测试能力的基础。对于刚刚毕业的学生，如果希望今后从事软件开发，那么，先从事一段时间的测试可能更有利于今后的编程。而对于具有多年编程经验的程序员，如果改行做测试，更容易提高技术。 软件测试不是孤立的活动或过程，需要开发和市场人员的参与和交流，需要软件质量保证人员SQA的积极配合和沟通。

软件测试的技术不断进步，与具体测试技术相比，掌握测试的核心思想比具体技术更重要！测试的最高境界在于运用最简单有效的测试技术，最大限度的发现软件缺陷!

应当承认，目前国内的软件测试工程师的地位和待遇仍然很低，而且不少测试人员存在浮躁的心态（我甚至感到整个软件行业始终存在着浮躁的泡沫）。如何改变这种局面，这应该是个漫长的过程。当整个IT业真正以客户为上帝时，当软件质量成为决定企业生存和发展的决定因素时，当软件测试工程师的测试工作给软件企业带来更大的经济效益时，软件测试工程师才会得到应有的尊重！

软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣，所以程序员们才会乐此不疲，前仆后继。首先、这种快乐源于一种创造事物的快乐。其次、这种快乐来自于一种开发出对别人有用的东西时所带来的满足感。第三、快乐源自开发过程中，亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力。第四、快乐源自开发过程中持续学习的快乐。最后、快乐源自开发过程中，我们能象诗人一样，仅凭自己的想像，来建造自己的城堡时带来的快乐。编程的快乐在于它不仅满足了我们内心深处进行创建的渴望，而且还唤醒了每个人内心的情感。不幸的是，同样作为游戏它也有苦恼的一面：首先、苦恼来自追求完美主义。其次、苦恼来自总是由他人来设定目标、供给资源、提供信息。第三、苦恼来自于寻找琐碎的BUG却是一项枯燥的、重复性的活动。第四、人们通常希望在项目接近结束时，能收敛得快一些，然而，情况却是越接近完成，收敛得越慢。最后、苦恼来自当投入大量的辛苦劳动后，产品发布时却面临着陈旧过时的危险。作为软件开发者，我们别无选择，只有适应它们，就这样痛并快乐着地面对每一天。

来自领导的信息只有25%被下级知道并正确理解，从下到上的反馈信息不超过10%，平等交流的信息则可达到90%以上。平等造就信任，信任增进交流。有效地进行适当的意见交流，对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流，才是蠃得市场的关键。

管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：

第一、风险识别：

从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。

第二、风险分析：

对风险出现的可能性和潜在的危害性进行量化分析。

第三、应急计划：

如果识别出的风险真的出现，你将采取的应急措施。

第四、风险缓解：

为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。

第五、持续的监控：

跟踪需要管理的风险，寻找风险出现的迹象。

项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：

第一、缺乏合理的进度安排

这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。

第二.它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。

第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。

最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。

第二、需求的变化

从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。

第三、人员的变更

在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。

另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。

同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。

第四、规约崩溃

这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。

第五、低效率

对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。

正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。

精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。

企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益。

就象那篇文章所说的，我们需要返回菜鸟（新手）的情绪，我习惯用激情。让所有的事情看起来充满未知的可能，那么有希望而令人兴奋。

如何让我们的情绪激动起来，让事情变的富有希望呢？

1、了解新的东西。测试领域不过是一棵树。我们在其他方面的兴趣呢？时势、财经、体育、教育、医疗、衣着、饮食或者明星八卦，去尝试了解这些领域的内容。看看那些不是IT圈子内的人，那些技术以外的五彩生活。我们可以成为另一棵大树上的树枝，另一个摘香蕉的猴子。我喜欢足球、篮球、下棋，也愿意看动画片，研究一下mm呵呵，那么朋友你呢？

2、做点自己不擅长的事情。寻找学习一样新事物时的激动，重温菜鸟看问题的感受，把自己以前的学习体会翻出来看看，把新奇古怪的想法加到工作中。侍弄下鲜花、学习照相或是踢个足球都成。我个人习惯胡思乱想，记得曾经学过折叠纸、数独等等。

3、脚踏实地。无论是工作还是生活，都不会一日千里。你需要一步一步的做每件事情，哪怕事情很小，比如复印个文件，下楼取个东西。再写一个测试用例，再追踪一个新问题，再看一篇测试文章。不断重复并坚持，总有一天，如同文章中所说，你会看到一些新鲜和令人激动的东西像幼苗一样慢慢发芽。虽然还没有在测试领域崭露头角，但相信总会拥有自己的一片天空。

引用该文的一段话，“一定要记得，那些幼苗相对于那些已经完全成熟的同类来说，是青涩的、渺小的、可怜的。要知道哪一株才能健康的长大，并孕育出芳香的花朵。不管怎样，还是要尽力帮助这些幼苗的成长，并清除周围的杂草。”

4、时常转换到别人的角度看问题。想像自己在别人的位置上，透过别人的眼睛观察世界，感受别人的痛苦。遇到事情不要先抱怨，考虑如果你是当事人你会怎么办．你有什么好的解决方法，怎么协调众多的关系．这能让你时刻感到新鲜，并让大脑获得更多的刺激，避免总是固执己见而忽略全方位真实的世界。时常想想假如我是女生的情况，或者当左脚受伤变肿，反而说右脚减肥成功，是不是会很有意思呢？

5、不要轻易的下结论。如果我们是一个富有经验的测试者，时常不深入分析而草率的表现你的鄙夷，贬低他人所作的任何努力（即使这种努力并没有解决实际问题）。当评论好坏的行为习惯成自然，固定的思维方式会让我们看不到很多东西，时常考虑新鲜的或激动人心的想法会有收获的。任何成熟的或不成熟的，完善的或缺憾的想法都有可取之处，或引发你的思想或让我们引以为戒。幼儿园小朋友的想法会让你大吃一惊的！

6、享受现在的一切。把我们所知的东西放在一边，注意力集中在现在。当看到一个新问题，也许会想起１０个看起来差不多的问题，不要管这些。好好的感受当前的这个新问题，专心的分析让它描述的更清晰，看起来更舒服。享受思绪流动的感觉。陶醉在畅想的空间里，我们越来越感到自信、变强，我们正在不断成长，我们拥有激情，我们浑身都散发着活力。这都是真的存在......

一、根基不牢
问题：利用等价类划分的方法，对某问题设计测试用例。

分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

问题：根据事件描述，画出对应的因果图。

分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

★ 小结：

上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

二、专业不精

问题：音视频文件都有哪些格式，这些格式之间有什么差别？

分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式的？”，面对这些问题，应聘者默默无语，只是无奈的笑笑。不去看别人，想想自己测试涉及的专业，是否把那个行业知识搞清楚了呢？

问题：测试脚本运行不畅如何调试？

分析：此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员，但是当真正问到他们关于脚本的具体调试时，有7成以上人员表示他们只是参加测试培训时老师讲过，或者自己在网上看过相关资料，另外有2成以上人员表示他们虽然用过，但是只是简单的录制回放，根本不会自己调试。可能是迫于无奈吧，简历里面什么都不写，可能面试的机会都没有，但是简历如此夸大的来写，终归是浪费自己的面试时间和路费。

★ 小结：

从事测试仅1-2年时间，要想测试也精通，专业也精通确实不易，但是不说精通，至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废，静下心来反思一下，身边还有哪些技能我们应该掌握扎实一点呢。

三、无测试体系概念，忽视理论

问题：请说出软件测试的定义，BUG的定义。

分析：99%的人不能说出这两个测试名词的定义，只是在给我解释测试是为了发现bug之类的片面理解，残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义，但是无论是对是错，身为测试人员已经数年，自己竟然说不出这两个词的概念，多少也说不过去啊。有些人和我说，理论名词概念不重要，我会做测试就是了。想想金庸老先生早就告诉我们，武功仅有招式是不够的，必须配合上什么心法口诀才能行。你只会测试执行的招式，却不懂测试理论的心法，怎么能够修炼成上乘的软件测试呢？

问题：请介绍一下你们的测试流程，流程和过程有什么不同，为什么好的测试需要好的流程？

分析：但凡做过1、2年测试的人都能给我说出他们先做什么后做什么，但是当我继续问“这是否可以叫做过程？流程和过程有什么差别”，应聘者一棒子被打晕，继续追问“为什么好的测试需要好的流程”的时候，早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么，让你怎么做你就怎么做，完全不管不顾为什么，那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做，自己的优势不就没有了吗。

★ 小结：

目前测试业内流传着学院派和实践派的说法，学院派的理论给人的感觉往往是好听但不实用，而实践派的知识，往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用金庸先生的观点，练武分练内气宗，练外剑宗，但是真正的高手是内外兼修。如果我们不想只做普通的测试小弟子的话，就要理论实践并重，方能有所作为。

四、周边知识知之甚少

问题：能给我介绍一下软件工程中的瀑布模型吗？

分析：又是8成应聘者不会回答，都是曾在遥远的学生时代有所耳闻，现今早已忘得一干二净了。软件测试因何而生——软件危机，软件危机导致软件工程的兴起，软件工程中又包含软件测试，就好像鱼儿活在水里，如果没有软件工程这个水，哪里能够养活这软件测试的鱼，如果我们对于身边的软件工程不够了解，怎么可能在里面自由的畅游呢。

问题：用你最熟悉的开发语言实现sum=1+2+3+…+100

分析：保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误，更少有人能够一气呵成，而且精准。这道编程题难吗？肯定不难，那么为何答错，自己没有真正写过程序，即使写过几行，也早就是如烟往事了。做测试一定需要懂开发吗？这个问题讨论以久，当然不一定，但是如果要做好测试，做深测试，分析问题原因，提出问题解决方案，编写测试脚本或工具，哪一个又能离开软件开发呢？

★ 小结：

我们学习测试也应该有个先后顺序，有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说，学校里面学到的知识不应该丢，之后的发展中，周边知识的学习也应该开始了。周边知识的范畴其实很广，还包括各种其他测试理念的学习，机械工业出版社翻译的那套测试丛书就很不错，观点众多而新颖，博众家之长，集大成，向来都是大家风范。

五、缺乏必要的责任心、细心、耐心、虚心等

问题：请数出下图中三角形的个数（平面图，有几根弧线做干扰）

分析：我总是问自己，这道题真有这么难吗？连中小学生都能数对的十几个三角形，到了我们这二十几岁的年轻人手中，正确率才1%，为什么？其实就是现在我们已经很少有人能够静下心来，耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实，坐的住，正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人，而是需要能够按时保质量完成测试工作的测试人员。

问题：你离职的原因？

分析：这是面试中最常见的问题了。应聘者往往也是充分准备，理由多种多样，但是看看应聘者的工作记录统计，70%应聘者平均跳槽频率是1年/次（实习情况除外），不会都那么凑巧吧，赶上什么公司倒闭，每隔一年就会想一次自己学不到东西，需要去外面看看。而在我看来，真正的原因更多的应该是希望通过跳槽提高工资，或者因为自身水平不足被公司炒鱿鱼吧。

★ 小结：

我并不认为所有的人都适合做测试。非技术素质方面，这点或者那点不足够优秀也很正常，心浮气躁也可以理解。但是作为用人单位，理解归理解，却也不会用不胜任岗位，或性价比不高的人员。那么对于此类应聘者，我的忠告就是，要么你另谋高就，要么你就放低姿态，培养好你必备的素质后再谈。

六、缺乏诚信

这一点本应该被归在上一条素质中，但是这点的重要性我认为远超过了上一条所列各项，因此单独提出。相关表现主要体现在：

○ 报自己历史工薪；

○ 笔试题目作弊；

○ 编造离职原因；

○ 虚报学历，工作经验；

○ 夸大自己工作技能等。对于严重缺乏诚信的，一旦发现，其他表现再好，也无济于事了。

软件质量重于泰山

软件质量重于泰山，软件质量是核心竞争力之一。现在和未来软件企业的竞争力不仅体现在产品类型的多样性，产品功能的先进性，更多的体现在产品质量的稳定性和可靠性。软件应用的领域不断深入，设计的复杂程度逐步扩大，开发的周期不断缩短，质量的要求水涨船高，软件企业面临着巨大挑战。

用户对软件产品质量的要求不断提高，促使软件企业把提高软件质量作为增强竞争力的策略。提高软件质量要素在哪里？可以通过采用软件设计技术，加强软件过程管理，实施软件测试等方法。从提高软件质量的显著程度、投资回报率和可实施性等方面比较，实施有效的软件测试，提高软件测试的效率，是保证软件质量的最显著方法。

软件测试是通过技术、流程、工具、人员以及管理手段，检测软件文档、软件中间产品和最终产品，查找和报告软件缺陷、错误以及隐患的专业技术。通过跟踪缺陷、错误及隐患的修正过程，确保软件产品、中间产品和文档符合软件工程过程需求和用户的最终需求。

软件测试创新之道

软件测试在国内仍处于起步阶段，各种软件测试的方法、技术和标准都还在探索阶段。国内软件行业普遍规模偏小，缺乏大型软件产品经验，开发过程不够规范，这决定了国内软件质量和测试行业，必须根据国内行业现状，确定软件质量目标和测试策略方法，而不是照搬照抄国外成熟软件企业的测试方法。

1.观念创新

提高软件质量的决定因素不是软件测试技术，而是对软件质量和测试的思想观念。只有把提高软件质量上升到企业战略发展的高度，才能从根本上解决问题。长期以来，国内软件行业对软件质量重视程度不足，对于软件测试的作用认识不够，造成项目因质量问题造成进度推迟甚至失败。

为了彻底改变这种被动现象，企业高层管理人员必须从管理思想、资源支持等方面为软件质量和测试部门提供全力支持。软件项目经理必须坚持软件开发和软件测试并行处理并且互相协调。软件开发人员重视和配合软件测试人员。

观念创新不要仅停留在口头上，而要落实在具体行动上，通过软件质量和测试的有效流程进行推动，通过过程改进进行提高。通过有效组织管理，形成以重视软件质量为荣，以轻视软件质量为耻的工作氛围。

2.流程创新

测试流程决定软件质量。软件测试如同软件开发一样，需要经过收集测试需求、确定测试策略、设计测试、执行测试、分析测试等流程。软件测试不是软件开发的最后阶段，而是贯穿于软件项目的整个生命周期。决定软件测试成败的关键是软件测试需求是否完整、准确，测试策略是否有效和实用，测试设计是否覆盖了测试需求。

软件测试流程既不是僵化的生搬硬套，也不是随机的增添取舍。软件企业的质量管理部门和项目开发团队需要根据公司技术、资源现状，针对项目的特点和客户需求，从保证软件质量、项目进度和测试成本等方面，进行优化设计并且不断改进流程管理。对于项目周期长、应用领域广、对质量要求高的软件，必须制定和遵守严格的测试流程。

测试流程创新的目标是在公司内部制定和执行完善的项目质量管理体系。优化项目生产方式，跟踪和度量生产过程和产品，使得生产过程和各阶段产品处于可控制和可度量状态，保证产品符合客户的功能和进度需求。

3.技术创新

软件测试是一项软件工程领域的专业技术，而不是简单的把软件测试认为随便找个人运行几次软件，就可以发现全部的软件问题。前文已经提到，软件测试需求和测试设计是决定软件测试效果的关键因素，因此，加强测试技术创新的重点是在测试需求和设计设计的创新。

在软件测试技术创新方面，要避免陷入过渡追求自动化测试技术的误区。自动化测试确实可以在某些方面显著提高测试效率和准确性，但是自动化测试只适合测试软件的某些方面的质量（例如性能测试，回归测试等），80%左右的软件缺陷是靠测试人员手工测试发现的。

对于某些特别需要自动化测试的软件特性，需要加强开发软件测试工具，而不是全部依赖市场上的现有测试工具。这是因为商业工具功能繁多，价格昂贵，培训和学习周期很长，选择不当就会造成巨大浪费。

4.管理创新

软件测试管理的目标是实现软件质量、进度、成本之间的最佳平衡。有效的测试管理需要企业管理层、软件开发团队、质量保证与测试团队通力合作，采用计划、组织、领导、控制等手段，组建高效团队，制定完善的测试流程，做好测试设计，有效执行测试，加强过程跟踪，从而顺利完成质量保证和测试任务。

测试管理创新的核心是软件质量和测试的团队建设，软件质量和测试是技术密集型活动，团队的知识结构、创造力和凝聚力是保证测试流程、测试技术充分实施的基础。质量和测试团队建设的重点是设置和培养各类技术和管理人才，进行有效交流，形成良好的评估和促进机制。

测试管理创新的另一个重点是测试管理平台建设。包括构建测试项目管理的集成系统，实现公司产品和项目数据信息的有效管理和顺序控制，使项目数据透明化，技术知识有效传承，项目质量和进度数据化、图形化。可以根据公司的现状，购买软件测试管理的商业工具，也可以内部开发软件测试管理工具。

软件测试技术路线图

如果把软件测试之道称为测试战略，要发挥测试战略的现实意义，需要把测试战略转化为测试战术。测试的“道”与“术”的无缝集成，才能显著地、持续地、逐步地提高软件产品质量。实施软件测试的战术是一系列过程的组合，涉及测试团队建设、流程设计、测试平台、测试管理等多个方面。

1.测试团队建设

测试团队可以是测试部，也可以是测试组。公司规模决定了测试团队的大小和组织形式。测试团队建设需要执行两个原则：第一，测试团队必须独立于开发团队，而不是附属于开发团队，实现测试的独立性和公正性；第二，测试团队必须具有明确的工作目标，即发现和报告软件缺陷，推动和确认缺陷修正，协助软件开发的过程改进，提高软件整体质量。

软件测试团队根据规模可以设置多个职位，每个职位具有明确的岗位职责，例如，测试部门经理、测试项目经理、测试组长、测试架构师、高级测试工程师、测试工程师等。对于刚刚成立的测试团队，可以一个人兼任多个职位，完成多项测试任务。测试人员的总数应该与开发人员相适应，最好在1：1到1：2之间。

2.流程设计

测试流程设计必须与软件设计流程相对应，基本测试流程包括测试需求分析，测试计划设计、测试用例设计、测试执行、测试评价、测试总结等。

根据软件需求和软件设计规格说明进行测试需求分析，测试需求分析的目的是明确需要测试的对象、特征、范围和方法，从而制定测试计划，确定测试策略。

测试计划设计是为了有效配置测试过程、人员和工具，充分利用现有的资源，按照项目计划进度，组织有效的测试。测试计划设计的输出结果是测试计划文档，它是指导软件测试活动的纲领性文档。

测试用例设计是指导具体测试内容和方法的关键内容，如果需要执行自动化测试，还需要依靠测试用例设计生成对应的测试脚本。测试用例设计的输出结果是不同类型的测试用例，这些测试用例必须以标准的、一致的形式设计、评审、存储、更新。

测试执行是发新和报告软件缺陷的阶段，根据软件计划的进度，分配测试内容，构建测试环境，依靠测试用例运行测试程序和程序文档。测试执行的输出结果是缺陷报告，测试进度报告等。

测试评价是度量软件测试执行效率和有效性的过程。测试评价的输入是测试用例的执行情况，软件缺陷的报告数据。测试评价的输出包括测试用例的有效性分析，软件缺陷的类型和有效性分析等，测试进度和有效性分析等。

测试总结包括测试过程每天或者每周的过程总结，也包括测试项目结束后的测试项目总结。测试总结的输出是测试总结报告，总体评价软件质量，指出测试存在的问题，提出改进的方法和进程，总计测试的有效经验。

3.测试平台设计

测试平台设计包括测试技术平台设计和测试管理平台设计。测试技术平台包括设计测试环境，设计或设置测试工具等。测试管理平台设计包括测试文档系统设计、测试版本配置管理、缺陷数据库设计、测试进度和质量分析系统设计。

测试技术平台设计需要根据测试计划的测试内容和测试环境要求，组织软件、硬件、数据库和网络等，这经常是一项较为耗时的工作，同时它影响着测试的正确性，必须尽快在测试开始阶段完成，最好采用有效的方法把搭建的测试环境进行备份保存，以便今后可以快速恢复，重复利用。

测试管理平台设计，影响测试管理的复杂度，好的测试管理平台可以使测试管理人员，方便的跟踪、查询、分析测试进度，评估测试人员的工作绩效，评价测试的总体质量。对于测试技术人员而言，可以方便的寻找测试对象和测试文档，报告和输出测试结果，共享测试数据，提高测试效率。

4.测试管理

测试管理关注人员、过程、产品三要素的互动与变化，测试管理包含项目计划和组织结构管理，测试阶段管理，时间、资源和质量管理，文档管理和团队管理等。测试部门经理、测试项目经理和测试组长是测试管理的主要执行者，需要与测试团队成员、开发人员、公司管理人员密切配合。

为了加强测试管理，需要确保测试数据信息流通畅，使测试团队、开发团队、质量保证团队之间有效交流。测试管理的其他内容包括团队成员参与各种培训，客观积极的绩效评估，识别项目测试风险，实现人尽其才，信息共享，进度可控，规避风险，降低成本，提高质量。

结论：

提高软件质量是提高产品竞争力的重要因素，加强软件测试创新是显著改善软件质量的实用方法。软件测试创新是循序渐进的过程，从建立完整的质量管理体系入手，通过团队建设、优化流程、技术创新，加强管理，实现人员、流程和技术的和谐统一，提高软件质量的可预测试性和可控制性。

        取得项目的成功无疑是项目经理的责任。因为我们绝大部分软件企业运行在相对混乱的状态（CMM一级），组织不大可能对项目以及项目经理的责任做出明确、合适的界定，所以，影响项目成功的一切因素都是项目经理的责任，包括客户、环境、考核、激励等等。有些项目经理把满足用户的需求作为项目成功的唯一标准，这一观念往往成为项目最终成功的障碍。结果通常是客户不满意（表面上是需求变了，实际上客户的需求并没有改变，只是陈述的需求变了），程序员抱怨多（工作没有成就感），系统没有扩展性、可维护性。项目经理只有把客户的满意和企业长期利益作为自己的责任，项目成功才有可靠的基础，对于公司的战略性项目尤其如此。 

    二、常识和直觉

        大多数有违常识和直觉的做法最终会被证明为错误的，项目经理要积累足够多别人已犯的错误充实自己的常识。如果发现项目中有违反常识的现象，应该把它作为一个问题来解决，看一看是自己的常识需要改变还是这个现象需要改变。项目经理要尽量使项目按照常规运作，不要故弄玄虚，或过多使用程序员不熟悉的新名词来表现自己的水平，这样不仅无助于程序员形成良好的心态，而且无谓增加了项目的混乱。

        有一本书叫做《微软项目求生法则》，其实国内的项目才更象是在丛林求生的猎人，项目经理面对的是不断变化的环境和未知的将来。早上去上班，也许某个关键程序员要辞职，客户的需求发生了重大的变化，或是老板又有了什么让你头疼的新主意。面对这样的环境，项目经理必须保持敏锐的嗅觉，准备弹性较大的项目计划和设计方案，在大部分变化到来之前有所准备，以免项目受到重大的打击。

    三、学习的心态

        软件技术的发展日新月异，项目经理必须了解最新的发展方向，如：J2EE或 .NET，UML等等，看看能否应用于项目之中。而且项目经理还得学习管理方面的知识，CMM，PMBOK或是RUP，学习这些理论体系对于国内的大部分小企业来说，最重要的不是完全的导入，项目经理首先应该从这些先进思想中看到差距，在关键问题上做好改善工作，逐步推动项目管理和技术的进步。每个程序员都有其独到之处，项目经理应承认程序员有强于自己之处，并尽力促进成员间知识、技能的交流。

    四、尽一切力量去维护项目团队

        国内的软件企业一般没有很好的文化和管理去构造一个富有凝聚力的团队。维持项目团队的稳定和战斗力更多成为项目经理的责任：|

        1、项目经理必须关心程序员：尽力让程序员专注于自己的工作，杂事造成的影响远比这些事本身花的时间多。相对说来，程序员在处理杂事的时候效率会比一般人更低，也更容易犯错误，从而导致情绪变坏，影响工作。项目经理有时候应勇于承担勤杂工作。

        2、要有宽容的心态，特别是对程序员。现在的程序员都比较年轻，自己觉得有点骄傲的资本，又处在一个浮燥的环境中，所以，有时候会做出一些过分的行为，项目经理千万不能太过在意。

        3、甘做幕后英雄，不斤斤计较。项目经理经常要在技术上支持程序员，但不能到处宣扬，而要把成绩更多归功于程序员。在项目紧张的时候，项目经理有时间的话要参与到繁琐的测试和调试工作中，或做一些代码工作。

        4、维护公平原则。项目经理在分配工作、对项目成员进行考核评估时必须做到公平合理，让大家心悦诚服。

    五、沟通与交流

        项目经理应该了解参与系统设计开发的成员，他们的特长和兴趣在哪里，以便更好地进行交流，这种非正式的项目外的交流对于团队的建设是至关重要的。此外，成功的项目经理也要善于与公司领导层的沟通，这是获得必要的资源支持的保证。有些优秀的软件项目经理可以与项目成员、相关部门或客户进行很好的交流，但没能与上级进行良好的沟通，他们在领导一个或几个项目取得成功之后，却发现在新的项目中缺少了基本的来自领导的支持。最终，有些项目经理选择了离开公司，而另一些则不得不放弃项目经理的角色。沟通与交流能力基本上是技术出身的大部分项目经理的致命伤。

        十年前，软件界最需要的是天才的开发人员，最近几年管理的重要性日益凸现，软件公司开始寻找优秀的天才项目经理。事实证明，天才总是可遇不可求的，而管理系统不能建立在小概率的基础上。解决软件企业的问题最终将依赖于组织管理水平的提高，比如说薪酬与激励政策、开发流程的优化、完善的培训制度，在一个管理良好的组织环境中，项目经理的责任以及履行责任的难度会大大降低，企业将不必再寻找天才的项目经理，相反，企业会成为优秀项目经理成长的基地。