项目管理9大知识体系与5个具体阶段(zz)

驱动21世纪新型商务企业发展的原动力是什么？有人答曰：项目管理。的确，项目管理作为一门新兴的学科，发展之快已超过了我们的想象。美国Fortune杂志甚至预言，项目经理将是21世纪的首选职业。让我们共同走近项目管理。
“金字塔工程”到“北极星导弹计划”

论起项目管理的起源，其实很早。古代诸如金字塔、长城等著名的伟大工程项目的成功，都得助于当时对工程项目进行的严密和科学的管理。20世纪60年代初，在著名数学家华罗庚教授的倡导下，将项目管理的概念引入了我国，并在当时的国民经济各个部门进行试点应用，将这种方法命名为“统筹法”。之后，中国科学院管理科学与科技政策研究所，还牵头成立了“中国统筹法、优选法与经济数学研究会”。改革开放后，项目管理在水利、建筑、化工等领域开始被大量地应用起来。2000年底，联想在“天麒”、“天麟”两款计算机产品的开发过程中，结合业务对项目管理的需求，配合项目管理相关理论、方法编制软件方案，使该项目在8个月的时间内便全部完成，并达到了国际上PC生产技术的最高水平。
现代项目管理的概念起源于美国。上个世纪五十年代后期，美国的Booz-Allen

Lockheed公司首次在北极星导弹计划中运用了PERT技术。同一时期，美国的Dupont and

RamintonnRand公司创造了CPM方法，用于研究和开发、生产控制和计划编排，结果大大缩短了完成预定任务的时间，之后它们分别被称为“计划评审技术”和“关键路径法”。现代项目管理科学便是从这两项技术的基础涎杆俜⒄蛊鹄吹模 诤狭撕罄捶⒄蛊鹄吹腤BS工作分解技术、蒙特卡罗（Monte Carlo）模拟技术和EV挣值分析技术，形成了一门关于项目资金、时间、人力等资源控制的管理科学。著名的阿波罗登月计划、曼哈顿计划等都是采用项目管理的理论和方法而取得成功的经典案例。
9大知识体系与5个具体阶段
早期的项目管理主要关注的是成本、进度(时间)，后来又扩展到质量。最近十几年间，项目管理逐渐发展成为一个涵盖9大知识体系、5个具体阶段的单独的学科分支。9大知识体系包括：
·集成管理在项目分析中，项目管理人员必须把各种能力综合起来并加以协调利用。
·范围管理定义项目的边界，着眼于“大画面”的事物。例如项目的生命周期、工作分工结构的开发、管理流程变动的实施等。
·时间管理要求培养规划技巧。有经验的项目管理人员应该知道，当项目出现偏离规划时，如何让它重回规划。
·成本管理要求项目管理人员培养经营技巧，处理诸如成本估计、计划预算、成本控制、资本预算以及基本财务结算等事务。
·人力资源管理着重于人员的管理能力，包括冲突的处理、对职员工作动力的促进、高效率的组织结构规划、团队工作和团队形成以及人际关系技巧。
·风险管理需要管理人员在信息不完备的情况下作决定。风险管理模式通常由三个步骤组成：风险确定、风险影响分析以及风险应对计划。
·质量管理要求项目管理人员熟悉基本的质量管理技术。例如：制作和说明质量控制图、实施80：20规则、尽力达到零缺陷等。
·采购管理项目管理人员应掌握较强的合同管理技巧。例如，应能理解定价合同相对于“成本附加”合同所隐含的风险。应了解签约中关键的法律原则。
·沟通管理要求项目管理人员能与他们的经理、客户、厂商及属下进行有效的交流。
5个阶段是：项目启动、项目计划、项目执行、项目控制和项目收尾。
除此之外，作为一个称职的项目管理专业人员，还必须具有相应的通用管理知识和经验、相关的业务知识背景以及精深的风险管理经验。也就是说，项目经理应当是一个具有相当丰富的知识并具有合理知识结构的高级复合型人才。
现在，项目管理在全球范围内被政府、大型公司、企业以及小型非赢利组织广泛地采用。与此同时，具备项目管理经验和项目领导才能的管理者，在职场上变得炙手可热。因为全球化的竞争要求新项目和新业务的发展都要在预算范围内按时完成。
向项目管理要高效
项目是一项为了达到一个特殊目的而进行的临时性活动。每一个项目有明确的开始和结束时间，项目能够由组织的各个层次创建；涉及的人数可以是一个人，也可以是上千人；可以只涉及一个单独的部门，也可以是跨部门的合作。项目管理可以应用于任何项目，而不受它的大小、预算或期限的限制，例如：
·开发一个新产品或服务；
·设计一个新车型；
·运作一次政治竞选；
·建一座大桥；
·发射火星探测器；
·建立一个电子商务站点。
那么，什么是项目管理呢?按照PMBOK2000的定义，项目管理是运用相关的知识、工具和技术管理的活动，目的是满足客户对特定项目的要求。项目经理负责管理整个项目，他的工作主要是：
·在项目范围、时间、成本、风险和质量之间做出最佳平衡；
·满足不同项目干系人的不同需要和期望；
·实现既定的需求目标。
        理想情况下，所有的企业都能够从项目管理中获益，特别是在管理资本投入和间接活动的花费上。在当今快速多变、全球化的市场环境下，所有类型的企业都需要看到它们投资在固定资产设施、房地产建设以及一些设备的升级上面的回报和收益，或者要对一些内部功能的管理和跟踪，如IT项目、市场项目等。无论什么行业，项目管理都可以使企业通过更好的信息共享来提高生产率和降低成本，在有限的资源条件下更快地以更低的成本交付产品和服务，从而增加营收。
项目管理可以帮助企业通过把日常工作标准化、减少可能被遗忘或被忽略的任务，来达到客户的期望值；
项目管理也能使可利用的资源以最有效的方式得到最佳的利用；项目管理还能使高级管理者洞察到组织内正在发生的和将要发生的事件。
项目管理原则的应用能够帮助高级管理层做到：
·建立成功的衡量指标；
·以客户为中心并与客户保持一致；
·量化体现价值的成本；
·优化组织资源的使用；
·贯彻质量原则和标准；
·实施战略计划；
·缩短新产品的研制周期并快速进入市场。
  相关小知识
IPMA：国际项目管理协会，是一个在瑞士注册的非赢利性组织，是项目管理国际化的主要促进者。IPMA创建于1965年，最早是一个在国际项目领域的项目经理之间交流各自经验的论坛。1967年，IPMA在维也纳主持召开了第一届国际会议，项目管理从那时起即作为一门学科而不断发展。
IPMA的成员主要是各个国家的项目管理协会，到目前为止共有29个成员组织。这些国家的组织用他们自己的语言服务于本国项目管理的专业要求，IPMA则以广泛接受的英语作为工作语言提供有关需求的国际层次的服务。为了达到这一目的，IPMA提供了大量的产品和服务，包括研究与发展、培训和教育、标准化和证书制以及有关广泛的出版物支撑的会议、学习班和研讨会等。
PMI： Project Management

Institute（美国项目管理学术组织），成立于1969年，是一个有近5万名会员的国际性学会。它致力于向全球推行项目管理，是项目管理专业最大的由研究人员、学者、顾问和经理组成的全球性专业组织，在教育、会议、标准、出版和认证等方面发起技术计划和活动，以提高项目管理专业的水准。PMI正在成为一个全球性的项目管理知识与智囊中心。

前言
CMM（Capability Marurity Model，软件能力成熟度模型）是于1984年美国国会与美国主要的公司和研究中心合作创立的一个由联邦资助的非盈利组织——软件工程研究所（Software Engineering Institute,SEI）的一个早期研究成果。该模型提供了软件工程成果和管理方法的框架，自90年代提出以来，已在北美、欧洲和日本成功地应用。现在该模型已成为事实上的软件过程改进的工业标准。下面我们来一起学习有关CMM的一些基础知识。 
一、 CMM基本概念 
过程（Process）：为实现既定目标的一系列操作步骤[IEEE-STD-610]. 
     软件过程（Software Process）：指人们用于开发和维护软件及其相关产品的一系列活动、方法、时间和革新。其中相关产品是指项目计划、设计文档、编码、测试和用户手册。当一个企业逐步走向成熟，软件过程的定义也会日趋完善，其企业内部的过程实施将更具有一致性。 
     软件过程能力（Software Process Capability）：描述了在遵循一个软件过程后能够得到的预期结果的界限范围。该指标是对能力的一种衡量，用它可以预测一个组织（企业）在承接下一个软件项目时，所能期望得到的最可能的结果。

软件过程性能（Software Process Performance）：表示遵循一个软件过程后所得到的实际结果。
    软件过程成熟度（Software Process Maturity）：是指一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度。所谓成熟度包含着能力的一种增长潜力，同时也表明了组织（企业）实施软件过程的实际水平。随着组织软件过程成熟度能力的不断提高，组织内部通过对过程的规范化和对成员的技术培训，软件过程也将会被他的使用者关注和不断修改完善。从而使软件的质量、生产率和生产周期的到改善。

CMM是软件过程能力成熟度模型（Capacity Maturity Model）的简称，是卡内基－梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应商能力的要求，于1986年开始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自问世以来备受关注，在一些发达国家和地区得到了广泛应用，成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。

CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，这也是美国国防部的一个设想，他们想把现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去。这个框架有两个功能，第一，软件获取方法的改革；第二，建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。

关键过程（区）域（Key Process Area）是指一系列相互关联的操作活动，这些活动反映了一个软件组织改进软件过程时所必须满足的条件。也就是说，关键过程域标识了达到某个成熟程度级别时所必须满足的条件。在CMM中一共有18个关键过程域，分布在第二至五级中。 
     关键实践（Key Practices）：是指关键过程域中的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关键过程域的目标。

软件过程评估（Software Process Assessment）是用来判断一个组织当前所涉及的软件过程的能力状态，判断下一个组织所面向得更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对该组织的软件过程进行有效的改进。 
     软件能力评价是（Software Capability Appraisal）用来判断有意承担某个软件项目的软件组织的软件过程能力，或是判断已进行的软件过程所处的状态是否正确或是否正常。 

软件工程组（Software Engineering Group）：负责一个项目的软件开发和维护活动的团体。活动包括需求分析、设计、编码和测试等。 
     软件相关组（Software Related Groups）：代表一种软件工程科目的团体，它支持但不直接负责软件开发或维护工作，如软件质量保证组、软件配置管理组合软件工程过程组等等。在CMM的关键实践中，软件相关组通常应该根据关键过程域和组织的上下文来理解。

软件工程过程组（Software Engineering Process Group）：是由专家组成的组，他们推进组织采用的软件过程的定义、维护和改进工作。在关键实践中，这个组织通常指“负责组织软件过程活动的组”。 
     系统工程组（System Engineering Group）：是负责下列工作的个人的团体：分析系统需求；将系统需求分配给硬件、软件和其他成分；规定硬件、软件和其他成分的界面；监控这些成分的设计和开发以保证它们符合其规格说明。

系统测试组（System Test Group）：是一些负责策划和完成独立的软件系统测试的团体，测试的目的是为了确定软件产品是否满足对它的需求。

     软件质量保证组（Software Quality Assurance Group）：是一些计划和实施项目的质量保证的团体，其工作目的是保证软件过程的步骤和标准是否得到遵守。

软件配置管理组（Software Configuration Management Group）：是一些负责策划、协调和实施软件项目的正式配置活动的团体。

     培训组（Training Group）：是一些负责协调和安排组织培训活动的团体。通常这个组织负责准备和讲授大多数培训课程并协调其他培训方式的使用。
CMM 的分级
任何一个软件的开发、维护和软件组织的发展离不开软件过程，而软件过程经历了不成熟到成熟、不完善到完善的发展过程。它不是一朝一夕就能成功的，需要持续不断的对软件过程进行改进，才能取得最终的成效。CMM就是根据这一指导思想设计出来的。该模型为了正确和有序地引导软件过程活动的开展，建立一个能够有效地描述和表示的软件过程的改进框架，使其能够对各阶段软件过程的任务和管理起指导作用。该模型以产品质量的概念和软件工程的经验教训为基础，指导企业如何控制开发、维护软件的生产过程和如何制定一套与之相适应的软件过程及管理体系。
（一）、分级标准
CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。一方面软件组织利用它可以评估自己当前的过程成熟度，并以此提出严格的软件质量标准和过程改进的方法和策略，通过不断的努力去达到更高的成熟程度。另一方面，该标准也可以作为用户对软件组织的一种评价标准，使之在选择软件开发商时不再是盲目的和无把握的。

CMM的分级结构可以描述为：
     ①、初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。
     ②、可重复级：已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。
     ③、已定义级：用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。

④、已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
     ⑤、优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地对促进过程进行改进。
除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，自然可以向下一级别迈进。CMM体系不主张跨级别的进化。因为从第二级开始，每一个低级别的实现均是高级别实现的基础。
（二）CMM的主要内容
CMM为软件企业的过程能力提供了一个阶梯式的进化框架，它采用分层的方式来解释其组成部分，如图示。在第二至第五个成熟等级中，每个等级包含一个内部结构的概念。      每一级向上一级迈进的过程中都有其特定的改进计划，具体情况如下。

初始级的改进方向是：建立项目过程管理，是使规范化管理，保障项目的承诺；艳进行需求管理方面的工作，建立用户域软件项目之间的沟通，使项目真正反映用户的需求；建立各种软件项目几乎，如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划及过程改进计划等；积极开展软件质量保证活动（SQA）。
     可重复级的改进方向是：不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为权利组织的标准软件过程，把改进软件组织的整体软件过程能力的软件过程活动，作为软件开发组织的责任；确定全组织的标准软件过程，把软件工程及管理活动集成到一个稳固确定的软件过程中，从而可以跨项目改进软件过程效果，也可以作为软件过程剪裁的基础；建立软件工程过程小组（SPEG）长期承担评估域调整软件过程的任务，以适应未来软件项目的要求；积累数据，建立组织的软件过程库及软件过程相关的文档；加强培训。

已定义级的改进方向是：着手软件过程的定量分析，已达到定量地控制软件项目过程的效果；通过软件的质量管理达到软件质量的目标。
     已管理级的改进方向是：防范缺陷，不仅在发现了问题能及时改进，而且应采取特定行动防止将来出现这类缺陷；主动进行技术改革管理、标识、选择和评价新技术，是有效的新技术能在开发组织中实施；进行过程变更管理，定义过程改进的目的，经常不断地进行过程改进。
     优化级的改进目标方向是：保持持续不断的软件过程改进。
（三）CMM的内部结构
CMM为软件过程能力的提高提供了一条改进的途径。CMM由5个成熟度等级组成，每个成熟度等级有着各自的功能。除第一级外，CMM的每一级按完全相同的内部结构构成的。成熟度等级为顶层，不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。 在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域，一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。
（四）软件过程评估和软件能力评价
软件过程评估所针对的是软件组织自身内部软件过程的改进问题，目的在于发现缺陷，提出改进方向。评估组以CMM模型为指引调查、鉴别软件过程中的问题，翻过来将这些问题与CMM关键实践活动所提出的指导一起用于确定组织的软件过程改进策略。
     软件能力评价是对接受评价者在一定条件下、规定时间内能否完成特定项目的能力考核，即承担风险的系数大小。评价包括承包者是否有能力按计划开发软件产品，是否能按预算完成等。通过利用CMM模型确定评价结果后，就可以利用这些结果确定选择某一承包商的风险。也可以用来判断承包者的工作进程，推动他们解决软件过程。

CMM为评估和评价提供了一个参考框架，指出了在评估和评价中通常采用的步骤。      具体来说，评估过程是：选择一个工作组；完成问卷调查和取样工作；结果分析；现场访问；与CMM模型对照分析；依据关键过程域的基本情况列出评估提纲。以上步骤在软件过程评估和软件能力评价题勾勒很有参考价值的方法，但在具体操作时以下这些特点也值得考虑：

     ①、在现场访问和考察中，充分运用成熟度问卷和结果分析为依据。
     ②、以CMM模型作为现场调查的路线图。
     ③、利用CMM中的关键过程域定义软件过程中的优点和缺陷，从中发现差异。
     ④、对关键过程域目标是否是满足的实际情况出发，分析满意程度，写出书面报告。
     尽管软件过程评估和软件能力评价有很多相似之处，但由于其目的和结果的不同，它们之间的差异也是必然存在的，如：

①、软件过程评估和软件能力评价在出发点和目标上的不同，使得会谈目的、调查范围、收集的信息和输出的表示方式上有着本质的不同。尤其在一些细节规范方面，评估和评价的方法有很大差异。      ②、软件过程评估和软件能力评价的结果和结果所起的作用不同。因为两者的侧重点不一样，即使是对同一个应用项目，运用相同的方法，也不会得出相同的结果。      ③、被评估和评价单位的态度对评估和评价活动的影响。评估在某种意义上被评估单位的态度较积极，而评价在某种意义上被评价单位的态度可能比较慎重。软件过程评估是在一个开放的、互相协作的环境中进行的，而软件能力评价往往是在有较大的阻力的环境中进行的。

（五）CMM的组织保证

    当人们面对CMM实施时，首先想到的就是人员的构成和各种小组的划分。它是实施CMM的组织保证，是一切活动的基础。CMM在制定软件过程实施中本着尽量不和具体的组织机构和组织形式相联系的原则，为的是提供一个独立于具体企业而又有广泛指导意义的模型框架。但在实施各种软件关键实践中，不可避免地要涉及到角色和组织结构。所以为了使CMM能够适用各种级别和各种规模的企业，SEI提出了一个相对抽象的组织结构，它与组织、项目、人员（角色）相关联，具有自己特定的术语，而且可能不同于其他组织所用的名词。例如基本概念中提到的主要的软件工作组的概念。

三、 正确的态度看待CMM

    SEI的CMM并不是软件开发的方法学，也不是产品模板，更不是过程法律。CMM是过程改进的途径，是一套指南，帮助你通过持续的重复、测量和提炼，稳步创造与净化开发环境。CMM的假定是：如果你实施一个不断重复、测量和提炼的大纲，作为环境改进的副产物，质量便会自然的提高。不要把CMM设想为一套规则，而应将它理解为一个学科，做事的一般方法。在这套指南下运作，你会发现这里有着广阔的空间，让你剪裁和塑造自己的大纲，以适应组织的特定要求。

CMM不采用“用这种方法做这类事”的风格，它也不对由问题的IT组织提供快速的纠正方案。CMM是一个指南针，指导你如何逃离暴风雪。CMM是一个大纲，要求你对整个IT组织的有关部分，从高层领导到软件生产的第一次线工作者，都做出坚定的、长期的实施承诺。成熟的过程不可能在它之间实现。
     在如何解释CMM建议时，它允许极大的灵活性。CMM意识到，IT组织之间存在着很大的差别。他们的客户不同，使用的工具不同，人员智力和专业背景不同，从事的项目属于不同的类型，规模大小不同，要求也各不相同。因而，他们应当以自己的方式走向成熟。在一处活用的东西，在另一处未必适用。这一点非常重要，中国部分软件公司的前车之鉴也从某种程度上给了我们建议和经验教训，那就是，要灵活应用CMM，不要幻想一夜就有成效。
从 CMM 到 CMMI 的映射
CMM 到 CMMI 的映射是一个复杂的体系，它涉及到 KPA 重构， KP 的再组织。图 1 只是从总体上描述了 CMM 到 CMMI 的映射关系。

映射分析
CMMI 虽然是建立在 CMM 基础之上，两者大部分相似，但还是有很大差异。从总体上讲， CMMI 更加清晰的说明各过程域和类属实践（ generic practice ）如何应用实施，并指出如何将工作产品纳入相应等级的配置和数据管理基线，风险管理策略，验证策略等。 CMMI 包含更多工程活动，如需求开发，产品集成，验证等过程域；过程内容的定义更加清晰，较少强调文档化规程。
如图，在 CMMI2 级中增加了测量和分析 KPA （ Measurement and analysis ），将各测量分析实践（ KP ）归结为一个正式的关键过程域，而在 CMM 中测量分析实践是散落在各等级中的。因此在 CMMI 中更加强调了量化管理，管理的透明度和软件开发的透明度得到了升级。

CMMI3 级中增加了需求开发（ Requirements Development ）、技术解决方案（ Technical Solution ）、产品集成（ Product Integration ）、验证（ Verification ）、确认（ Validation ）、风险管理（ Risk Management ）、决策分析和决定（ Decision Analysis and Resolution ） KPAs 。 CMM 中的软件产品工程 KPA 被需求开发，技术解决方案，产品集成，验证，确认 KPAs 所取代；同行评审 KPA 被融入到验证 KPA 中； CMM 中集成软件管理 KPA 所阐述的风险管理在 CMMI3 中形成了一个独立风险管理 KPA 。同时集成软件管理和组间协调 KPAs 合并成集成项目管理 KPA 。合成团队、决定分析和解决方案、组织的一体化环境 KPAs 是全新的，其过程内容在 CMM 中没有提及。
CMMI4 中没有新的过程域，只是对原来的定量过程管理，软件质量管理 KPAs 重新构建为定量项目管理和组织过程性能 KPAs 。
CMMI5 中的技术变更管理和过程变更管理 KPAs 合并为组织革新与技术推广 KPA ，缺陷防范 KPA 重新构建为原因分析和解决方案 KPA 。
CMM 到 CMMI 的升级
升级前的准备工作
(1) 回顾 CMMI 模型和其他的 CMMI 信息，确定如何使 CMMI 最好的满足组织需要（ 2 ）拟订升级策略。（ 3 ） 在升级过程中确保以前用于 CMM 改进的投资得到维持和运用（ 4 ）将升级事项通告客户（ 5 ）将对现有过程域和新增过程域的改进费用编入预算，并提供有关改进需要的培训。（ 6 ）确定组织升级计划的风险表并管理这些风险，关键要识别 CMM 和 CMMI 之间的差异以及这些差异如何得到支持。

升级的方法：
一旦做好了升级前的准备工作，弄清了升级可带来的利益和成本，可执行下列活动进行升级，这些活动是迭代的。
（ 1 ） 选择适合组织最好的 CMMI 模型。 CMMI 覆盖各种知识体，包括项目管理，软件工程，系统工程，集成产品，过程开发供应商来源。按组织的商业目标选择模型。
（ 2 ）选择最适合组织的表示法。 CMMI 有阶段式表示法和连续式表示法，由于 CMM 采用的是阶段式的表示法，许多组织都采取 CMMI 阶段式表示法，若组织对连续式表示法较熟悉，也可以采取连续式表示法。
（ 3 ）将选择的 CMMI 模型与 CMM 对比，确定需要变更的范畴。具体的对比见上文。 变更的主要活动是对 CMMI 中重组的 KPA 及 CMMI 中新增的 KPA 进行更新。

（ 4 ） 确定升级会带来的影响。
（ 5 ）向 CMMI 升级因该报高级管理层的认可。
（ 6 ）变更组织目前的过程改进计划以支持 CMMI 升级。过程改进计划要反映出工作的优先级、组织所需增加的新部门。将该计划送交评审，得到关键储金保管者（ key stakeholders ）的许诺和认可，计划要说明升级可能带来的管理风险和进度风险，所需的培训，工具，和服务支持。传达这个计划并保持更新。
（ 7 ）确保对工程过程组，技术工作组及其他相关的员工进行 CMMI 的培训。
（ 8 ）获取 SCAMPI 评估支持。
（ 9 ） 修改每个项目已定义的过程使其与项目改进计划一致。
（ 10 ）给每个项目制定升级进度表 不同的项目升级进度表可能不同，如果有的升级工作已经完成则该工作可以抛弃。
（ 11 ）执行 SCAMPI 评估，看是否所有的目标过程域和目标得到支持。
处于 CMM 不同成熟等级的组织所做的具体工作
（ 1 ） CMM1 级：
如果组织正使用 CMM 模型致力于过程改进而并处于 CMM1 级，那么组织应该继续用 CMM 模型。在改进的同时，组织将 CMM2 与 CMMI2 进行对比和差异确认，分析这些差异中哪些是对组织有价值的。当组织刚达到 CMM2 级时其主要工作时立即从 CMM2 向 CMMI2 升级。
（ 2 ） CMM2 级，
组织应该把其当前的过程改进向 CMMI2 级映射，填补两者之间的差距，从 CMM2 升级到 CMMI2 完成后，在下一步的工作中采用 CMMI 模型进行过程改进。主要有一下几方面

(1) 将 CMM 中分散的测量分析活动集中到 CMMI2 级测量分析 KPA 中，形成一个独立的过程域，提高开发的透明度。
(2) 重定位测量分析 KPA （ Measurement and Analysis ）的共同特征（ common feature ）
测量分析 KPA 重组见表 所示。

表示符说明： QPM Co 2 Ac1,3,4,5,6 表示定量过程管理（ Quantitative Process Management ）过程域执行的约定（ Commitment to perform ） 2 和执行活动（ Activities to perform ） 1,3,4,5,6 。
Co 表示执行的约定； Ab 表示执行的能力； Ac 表示执行的活动； SG 表示特殊目标（ Special Goal ）； GG 表示一般目标（ Generic Goal ）；其他可类推。

（ 3 ） CMMI3 级
①将 CMM 软件产品工程 KPA 分解为需求开发、技术解决方案、产品集成、认证、确认 KPAs ，并进行扩充。
②了解 CMMI3 级中新增的决定分析和解决方案、合成团队，组织一体化环境 KPAs ，并填补。
③迭代 CMM2 级的工作。
说明
卡内基梅隆大学软件工程研究所推出 CMM Version 2.0 draft C 后就停止了在 CMM 的改进。 CMM 被 CMMI 所取代是大势所趋。许多正在运用 CMM 模型进行软件过程改进的组织纷纷向 CMMI 升级。而 CMMI 模型迄今还没有成熟，卡内基梅隆大学软件工程研究所 推出了 CMMI-SE/SW 1.1 和 CMMI-SE/SW/IPPD ，在目前的产品集中没有关于软件采购方面的内容，估计以后还会推出这个科目。而且从 CMM 向 CMMI 升级也只是处于尝试阶段。组织升级的操作过程，运用 CMMI 模型所带来的效益等信息还很匮乏，这些信息也为未能及时反馈到卡内基梅隆大学软件工程研究所，这也给 CMMI 模型的改进及向 CMMI 的升级工作带来了一定的难度。

关于CMM评估的一些背景资料
CMM评估包括5个等级，共计18个关键过程域，52个目标，300多个关键实践。每一个CMM等级评估周期（从准备到完成）约需12-30个月。每一级别的评估由美国卡内基梅隆大学的软件工程研究所授权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。评估过程包括员工培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等。评估结束由主任评估师签字生效。国外CMM等级评估生效，只需要主任评估师的签字，既没有某主管单位的批准，也没有盖上公章的证书。显然，国外更看重主任评估师及公司的信誉。

取得主任评估师的资格的条件： § 首先要有10年以上的软件开发经验； § 其次要在美国卡内基梅隆大学的软件工程研究所接受培训，培训费用每人约需数万美元，非美国人加倍； § 第三要经过两次以上CMM评估的全过程实习； § 第四要得到已有主任评估师资格的人推荐。主任评估师的资格并非终身制，如要继续保持，每年至少要参加两次CMM评估。 目前全世界一共只有313个主任评估师，大部分在美国，而我国大陆还没有一个主任评估师。由于我国在CMM评估中要聘请外籍主任评估师，所以费用较高。据估计，要通过一个级别的CMM评估，费用是通过ISO9001认证的十多倍。
作业
1、请用图表的形式描述CMM的分级结构？
2、软件过程性能和软件过程能力的主要区别是什么？
3、关键实践的主要描述的是什么？
4、CMM和CMMI的主要区别有哪些？
5、假如你是SQA，你应该具有什么样的心态去看待CMM的评定？

软件工程的七条基本原理

       自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。美国著名的软件工程专家 Boehm 综合这些专家的意见，并总结了TRW公司多年的开
发软件的经验，于1983年提出了软件工程的七条基本原理。

Boehm 认为，这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。

人们当然不能用数学方法严格证明它们是一个完备的集合，但是可以证明，在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。

下面简要介绍软件工程的七条原理：

1 用分阶段的生命周期计划严格管理

这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

2 坚持进行阶段评审

统计结果显示： 大部分错误是在编码之前造成的，大约占63%; <2> 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。

3 实行严格的产品控制

开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。

4 采纳现代程序设计技术

从六、七时年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。

5 结果应能清楚地审查

软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。

6 开发小组的人员应少而精

开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多； 当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。

7 承认不断改进软件工程实践的必要性

遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
　　1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

　　3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

　　4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

　　5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

　　6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

　　7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

　　8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

　　9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

　　10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

　　11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

　　12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

　　14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

　　15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

　　16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

　　19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

　　20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.
 

 

   此文是对我个人测试思想的一个总结，由于经验不够，知识浅薄，如果有什么不合理的地方请一笑了之。
一、面向对象的概念
    所谓的面向对象是软件开发的一种重要的思维方式，是把软件开发过程中出现的事物,用一个个的对像来分析.一般一张数据表可以封装为一个对像。用个形象的比喻：我们现在要做一张桌子，首先我们考虑到的是我们要做的是什么？是桌子；桌子是用来干什么的呢？是用来吃饭、喝茶、看书、打麻将的；然后就要考虑桌子由哪些部分组成？由桌面和桌腿来组成；接着我们需要考虑我们采用什么材料呢？纸？不行...那可什么都干不成，OK，用木头；接着就可以开始把组成桌子的组件做为对象开始分析--桌面如何做是用刀砍的还是用刨子刨呢？桌腿又如何做...
一套完整的方法成形了就可以具体实现了，在做的过程中桌面要做多大，桌腿要做多长都要事先考虑到是不是要留出接口，这些就是我们给组成桌子的组件赋予的属性。OK，现在可以做出具体的实物了，做好实物组件（对象）以后就要将做好的桌面桌腿进行组装，由于我们事先考虑好了组件的属性，考虑到了必须预留接口，因此我们可以很轻易的组合成功，桌子做出来了。以上就是面向对象的思想的一个简要的比喻

了解面向对象必须了解的几个名词：对象、方法、属性、继承、多态

二、游戏测试
    游戏测试是整个软件测试行业中比较特殊的一部份，他有着大多数软件测试的共性，也具备自身的特性，而相对于许多通用软件的测试来说，游戏测试所具备的特性是非常明显的。现在就简要的说说上面提到的共性和特性。
共性：
1、测试的目的就是为了尽可能的发现软件存在和潜在的问题。
2、测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书、需求文档、产品文件、或是用户手册、源代码、或是工作的可执行程序。
3、每一种测试都需要产品运行于真实的或是模拟环境之下。
4、每一种测试都要求以系统方法展示产品功能， 以证明测试结果是否有效， 以及发现其中出错的原因， 从而让程序人员进行改进。
    总之，软件测试就是对产品进行尽可能的全面检查，尽可能的发掘bug，提高软件质量，从而为企业创造利润。
特性：
    网络游戏世界从某种意义上说是另一个人类社会，只是人们在网络游戏世界中进行着在被允许的范围内的活动，包括了修炼、交流、合作、经商、欺诈、情感、冲突等等。而在游戏制作时这些进行这些行为的部分就是一个个完整的功能，我们在进行测试的时候，需要考虑的不仅仅是能否实现功能，要考虑更多的是人们在进行操作时会如何做，可能有多少种做法，这些做法应该有什么样的响应，哪些做法是被禁止的，在进行了被禁止的操作后应该有什么的响应。因此这里就是涉及到了游戏世界的测试方法：
1、游戏情节的测试，主要指游戏世界中的任务系统的组成， 有人也称为游戏世界的事件驱动， 我喜欢称为游戏情感世界的测试。
2、游戏世界的平衡测试，主要表现在经济平衡,能力平衡（ 包含技能， 属性等等）,保证游戏世界竞争公平。
3、游戏文化的测试，比如整个游戏世界的风格， 是中国文化主导,还是日韩风格等等，大到游戏整体，小到N P C（ 游戏世界人物） 对话， 比如一个书生，他的对话就必需斯文， 不可以用江湖语言。

以上陈述中关于游戏特性的部分概念是曾在金山公司的测试人陈卫俊提出来过的,在此引用

三、如何用面向对象的思想进行测试
    上面了解了面向对象的概念以及游戏测试和通用软件测试的区别以后我们可以进入正题了---如何用面向对象的思想进行游戏测试?
    首先,和所有通用软件以及硬件产品一样,我们的游戏是一个产品,是一个存在的实体,因此,我们把这个"实体"当做一个大的对象开始分析,整个游戏由哪些部分构成,而构成整个游戏的大的部分又由哪些组件构成,认真分析完这些以后就可以着手进行测试了,注意,这里说"可以进行测试了"意思不是马上就能进入测试,听我慢慢道来.
     "工欲善其事,必先利其器"---某位高人说的,我们做测试也是一样,分析完毕后,我们要做的还是分析 ^_^ 不过这里的分析和之前的分析有点点区别,这里我们需要分析的是具体功能的关键测试点和风险点,测试不能盲目,打蛇要打七寸.....在这里我们就是把某个具体的功能作为一个对象，我们要分析组成这个功能的是哪些因素，一共有哪些测试点，哪些测试点是关键点，哪些是高风险点，一一列举出来,这样我们就一目了然了，然后就是我们打算采用何种方式来进行测试，这里就是方法了.测试的方式可能有很多种(比如在不同的操作系统下进行测试等),因此我们也需要一一列举，此外我们需要分析的还有测试过程中我们需要用到的具体测试手法、具体的数值、特定的环境等等这些就是属性，当然这些我们也必须整理出来。
    将以上提到的对象、方法、属性整理成文档就是我们测试时所必须的测试用例了。当然，还是老话，测试用例的优劣是以覆盖面来评判的，这里就需要经验了，简单说就是靠累积以及学习。
     OK，测试用例我们完成了，剩下的就是实施测试了，实施测试时个人觉得一定要按照用例的描述去执行，如果在测试过程中觉得用例不完善可以先更新用例再进行测试，一定不要先测试再补用例！！
    接下来就是测试报告，报告中包含的应该有所有测试点的简述，包括了通过测试的部分和存在bug的部分。bug管理是很重要的一环，在这里不详述。
    关于测试流程在这里就不做具体说明，在这里希望阐述的是一种测试的思想，个人觉得测试除了要有扎实的相关基础知识以便更深入的了解产品以外，更重要的是测试思想，具备了完善的测试思想才能有计划的完成每一步测试，从而提高测试的效率，保证测试产出的质量，也更好的保证产品的质量。面向对象是一种思想，用面向对象的思想来组织、计划、实施测试工作，能让我们在测试工作中有很强的目的性，他能清楚地告诉我们今天要做什么，明天要做什么，我们要做的是哪些，说回游戏测试，游戏开发是一个迭带的开发模式，因此测试工作往往会有很大的随机性，因此当我们接到一个新功能时，首先要明确我们要测得这个功能是做什么的，有什么用，这个功能怎么使用。OK，我们了解了这个功能是什么，能做什么就可以开始细化分析了：这个功能共由哪些子功能组成，这些子功能是否有自己的子功能点，一层层的分析下去，然后就是从最底层的功能点分析：这个功能什么情况下要发挥其功效，发挥其功效的因素有哪些，怎么样去发挥具体的功效，该功能有没有相应的容错机制，这些就是我们的详细测试点和测试手法。然后向上一层一层分析，一直到最顶层就是我们的功能完整的测试方针。这样我们就把面向对象的思想完全用到了测试中。当然，在分析的过程中我们必须考虑到，与游戏情节、游戏风格、游戏平衡、玩家的易用性是否冲突等等因素，适时地给策划提出正确的建议。
    
    以上陈述的种种，无非是想将面向对象的思想用到测试中的好处列举出来，或许经验浅薄说的有些苍白，但是我坚信一点，测试是一种思想，是一种绝对不亚于开发思想的学问，要想做好测试就需要具备良好的测试思想，或者良好的测试思想不是一天两天能够形成的但是相信只要把测试当做一种职业，当作一种事业来做，把自己真正当成保证产品质量的最后一道关卡，成为一个BT（BestTester）就指日可待了！

软件测试用例的认识误区

软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量，增强测试过程的可管理性。
在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。

误区之一：测试输入数据设计方法等同于测试用例设计方法

现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。
这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试用例设计人员把这种认识拿来要求自己，则害了自己；拿来教人，则害了别人；拿来指导测试，则害了测试团队。听起来似乎是“小题大做”，但是绝不是“危言耸听”。

无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段（里程碑）、测试用例组织方法（是否采用测试用例的数据库管理）等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标；根据用户使用环境确定测试环境；根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤；根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

误区之二：强调测试用例设计得越详细越好

在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好；测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。

编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。

测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”（即执行这些测试用例的人员），以及测试用例执行人员的技能和产品熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试用例，或者软件测试外包给独立的第三方公司，那么测试用例的执行步骤最好足够详细。

误区之三：追求测试用例设计“一步到位”

现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。

这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。

“唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。

软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。

误区之四：让测试新人设计测试用例

在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例？”。因为他（她）们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。

让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。

软件测试用例设计是软件测试的中高级技能，不是每个人（尤其是测试新人）都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。

 

使用面向对象的思想进行测试（游戏测试相关）

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/csan/archive/2007/05/13/1606597.aspx