软件测试是软件开发的重要、必要部分，是通过找出缺陷和问题评估产品质量并间接改进产品质量的手段。从软件工程的观点看，预防程序问题要比改正问题重要得多，因此，必须首先把软件测试看做是检验预防程序错误的机制是否有效的主要手段，同时又是找出程序异常的手段。

从一段对话谈起

甲、乙、丙三人对“所有奇数都是质数”这个假设进行测试。

甲说：“3是质数，5是质数，7是质数。看起来这个假设没错。”

乙说：“3是质数，5是质数，7是质数，9是质数，11是质数……”

丙说：“错！9就是一个非质数奇数。”

　　软件测试就是从一个错误陈述（“系统能正常运行”）开始，从无限种可能中选出与该陈述矛盾的输入。必须避免甲犯过的错误（没有验证合适的值），也要避免犯乙犯过的错误（验证了合适的值，但是没有发现矛盾之处），需要像丙那样，用最小工作量找出合适的反例。

　　IEEE把软件测试定义为:从通常是无限大的执行域中恰当地选取一组有限测试用例，对照程序已经定义的预期行为，动态地检验程序的行为。

　　从这个定义可以看出软件测试的四个特点：首先是“动态”，软件测试总要通过一组输入执行程序。但是，单靠输入值并不总能充分地确定一个测试，因为对于复杂、非确定的系统，由于系统会处于不同的状态，因此对于同样的输入可能产生不同的响应。所以，特定的输入通常还要指定系统的特定状态。其次是“有限”，在测试中实际能够观察的执行数量是有限的。测试永远都意味着有限资源和计划进度与本质上是无限测试需求之间的折衷：正是这种矛盾带来了大家经常提到的技术（测试充分性评判准则）和管理（测试工作量估计）两个方面的测试问题。接着是“选取”，很多测试手段的本质区别就是如何选择有限的测试集。针对特定条件确定最合适的选取准则是一个非常复杂的问题，在实践中需要运用风险分析技术和测试工程专门知识。最后是“预期”，必须能够确定所观察到的程序执行输出是不是可接受的，否则测试工作就是无用的。

　　软件测试通常要在不同层次上执行，大体上划分为三大阶段：单元测试、集成测试和系统测试。单元测试检验独立软件模块的机能，软件模块可以是独立子程序，也可以是由紧密相关的数个单元组成的较大构件，单元测试一般需要对被测代码进行访问并借助调试工具的支持，并且可能需要被测代码编程人员的介入; 集成测试检验系统各部件间的交互性。经典的集成测试策略有自顶向下或自底向上两种，用于传统的、分级的结构化软件系统。现代的集成测试策略更多是结构驱动的，这意味着对软件部件或子系统的集成是基于确定的功能线程，因此集成测试是一个连续活动，在每一阶段测试人员必须抽象出低一级的情况并集中于正在处理的这一级的状况; 系统测试关注的则是整个系统的行为，它需要将系统与非功能性系统需求进行比较，非功能性系统需求指系统的安全性、速率、精确性、可靠性等。系统与其它软件、应用程序、硬件设备或操作环境的外部接口评估也在系统测试中进行。

测试技术分类

　　从软件生产发达国家来看，20世纪60年代，软件测试主要以代码调试为主；70年代主要以演示软件系统的正确性为主；80年代到90年代中期，主要以检查程序错误为主；90年代中期以后，软件测试开始更注重软件质量特性的整体评估。目前软件测试最主要的目标是评估软件功能，但一般也要测试软件的非功能属性。

　　目前应用于软件测试领域的技术有很多，而且差别很大，大致有两种分类方法。

　　第一种是按测试的生成来源划分，即基于测试人员的直觉和经验（即兴测试）、需求规格说明（包括等价类划分、边界值分析、判定表、基于有限状态机、形式化语言转换和随机测试等）、代码结构（基于流程图、调用关系图等参考模型、基于控制流标准、基于数据流的标准）、发现的错误（以过去经验为基础的错误推测法、增加一个被测程序变种的变异测试）、被测程序的使用领域（操作剖面、软件可靠性工程测试）和被测程序类型（面向对象、基于构件、网站、GUI、并发程序、协议一致性、分布式系统、实时系统、科学计算软件测试）的测试技术。

　　第二种是经典的分类方法，即黑盒测试和白盒测试。依赖于被测软件设计及编码信息进行的测试称为白盒测试（基于代码测试的参考模型、基于控制流标准、基于数据流标准和变异测试等），只依靠被测软件输入/输出行为而没有关于输入/输出之间信息状况的测试称为黑盒测试（等价类划分、边界值分析、判定表、基于有限状态机、源于形式化需求规格说明、错误推测法、随机测试、操作剖面和软件可靠性工程测试等）。

　　在实际测试中，往往综合采用这些技术。

测试过程有章可循

　　过程是一组把输入转换为输出的相关活动。不同层次上的测试活动必须与人员、工具、政策、度量一起组织于一个良定义的过程中，这一过程是软件生命周期的完整组成部分。测试过程需要加以控制并进行持续改进。

　　软件测试过程的决定性因素是人。对于成功的测试来说，一个必要条件是人员对测试活动所采取的积极和相互协作的态度。另外，应该使软件产品涉及的所有人员都认识到：及早发现软件错误是大家共同的目标，而不仅仅是测试人员的责任。

　　文档是测试过程规范化的一个完整组成部分。IEEE 829完整描述了各种测试文档、文档间关联及文档与测试过程间的关联。测试文档包括测试计划、测试设计说明、测试过程说明、测试案例说明、测试日志和测试事件或问题报告等。用于测试过程控制与改进的度量包括:设计的测试用例数、执行的测试用例数、通过的测试用例数、失败的测试用例数等。

　　测试管理的一个关键性任务是决定什么样的测试是充分的，某个测试阶段何时可以终止。对此，充分性度量和错误密度估价、操作可靠性评估都可提供有益支持，但只有这些还不充分。决策还应考虑潜在的遗留失效可能造成的损失和风险，并将之与进一步测试所需成本进行对比。为使测试和维护工作有组织、成本效益高，应将各测试手段系统化地加以重用。为此，应在测试的各个层次，对测试脚本、测试用例和预期结果进行精心定义并记录。

　　用于特定环境、特定类型程序的测试方案，以及决策动机，构成了测试模式。测试模式本身也可文档化，并可重用于以后的类似项目。

Dan在一个有着其他四个成员的项目中做开发人员。他们在项目开始的前八个月只开发产品，不修复任何缺陷，除非缺陷阻塞他们继续开发。Dan和他的团队认为同时修复所有缺陷是更节省成本的。因此在第九个月，即预期发布的前一个月，他们觉得是时候修复缺陷了。

　　Avery在一个与市场实际同步的公司当项目经理。由于受到限制，所以每个客户都马上要一个β版本，这样他们可以尽快开始使用软件。考虑到一个有着许多缺陷的β版本将使他们的客户愤怒，Avery认为，让开发人员在系统测试之前就开始查找和修复严重缺陷是更节省成本并且是低风险的。

　　两个项目对于查找和修复缺陷使用两种完全不同的方法。我们对于修复缺陷都有不同的看法，尤其是什么时候修复哪些缺陷。选择是否修复缺陷取决于很多因素，如：开发的产品类型；携带已知或未知缺陷的风险；开发过程；当确定修复缺陷时，需要多少成本。

　　其中最容易理解的一个因素是修复一个缺陷的实际成本。这个成本反映到选择的开发生命周期、开发过程，并帮助你在可以承受的风险内决定提交或不提交产品。然而，事实上很多人都不知道修复一个缺陷需要花费多少成本。如果你也没有把握，那么这里有一个用来测量这项成本的估算方法。

　　在系统测试的时候，人们全身心投入于查找和修复缺陷，可以计算出缺陷的数量。你知道多少人（开发人员、测试人员以及其他任何人）在做这个项目，你也知道系统测试的持续时间。有了这些数据，你就可以计算出项目在这个阶段修复一个缺陷的成本。可以通过下面的公式计算查找和修复一个缺陷的平均成本。

　　修复一个缺陷的平均成本＝（人员数量×天数）×平均人日成本/修复的缺陷数量

　　注意：“发现”的缺陷数量不具备足够的信息，而应该使用“修复”的缺陷数量。发现缺陷只是第一个步骤。定位错误、决定如何修复、开发人员测试（又名单元测试）修复的内容、系统测试修复项、寻找由这个缺陷引起的其它缺陷，所有这些都是为什么使用“修复”数值是如此的重要。让我们看一些例子。在这些例子中，我假设每人日成本是500美元。

　　Dan的项目在系统测试时，暴露了大量的缺陷，虽然大部分缺陷是容易修复的，但是还有一些缺陷需要花很长时间。Avery的项目在系统测试时暴露出非常少的缺陷，但是由于发现每个缺陷的时间间隔是如此的长，所以似乎是花很长时间在修复一个缺陷。使用上面提到的计算公式，表1是Dan和Avery项目系统测试的数据。

　　只要你回顾一下项目的整个框架，就可以看出这项度量对系统测试修复缺陷成本的估算是有益的。但是，我们注意到Avery项目的修复成本是很高的。实际上，Avery的项目是以非常低的让客户失望的风险到达β发布日期（在系统测试的20个工作日）。Dan的项目花了两个月（40个工作日）的测试时间，虽然修复了125个缺陷，但是他们仍然有超过300个的缺陷没有修复。因为Dan的团队在系统测试前很努力地在预防缺陷，所以Avery的项目是节省成本的。因为Avery的团队预先发现并修复了大部分的缺陷，所以实际上使用上面的估算技术，他们修复缺陷的成本在系统测试中被大大放大。因为Avery的项目在系统测试之前发现并修复了大部分的缺陷，所以上述估算技术是不合理的。Avery项目能够用计算出实际查找和修复缺陷的成本来代替估算值。Avery平均使用了8个小时的系统测试时间来查找和修复一个缺陷。表2是对Avery系统测试成本更实际的估算。

　　使用更新后的数据，表3是一张Dan和Avery项目修复一个缺陷所需成本的更清晰的图表。

　　因为Avery的项目查找缺陷比修复缺陷花费了更多的时间，所以Avery有高的系统测试成本。虽然如此，Avery这个较大的项目的总缺陷修复成本比Dan这个较小的项目低。并且Avery的修复缺陷的版本发布成本比Dan的项目低许多。

　　因为成本不仅取决于在项目里执行的活动和什么时候开始跟踪缺陷，也取决于修复缺陷上的花费，所以每个项目有它自己修复一个缺陷的成本。你可以使用修复成本来决定如何继续这个项目或进行下一个项目。如果你的成本太高，而且你还没有在系统测试阶段，那么可以尝试一些缺陷发现和预防技术。如果每个人一起查找和修复缺陷，那么不仅仅只计算修复时间，也计算了查找缺陷的时间。

　　如果你在系统测试阶段的查找和修复缺陷的成本很高，那么发布初期的风险是什么?Avery可能在查找和修复缺陷成本为3333美元时选择早一些结束系统测试并早一些发布，同时他知道项目版本发布成本将上升。只有Avery和他的管理部门能够评估发布初期的风险。

　　可以使用发布前的修复成本来了解你和你的职员在项目发布前的活动是否有成本效益。我发现每个组织不紧密依赖于项目而有各自特定的版本发布成本。因而我使用版本发布成本来帮助定义发布标准。这帮助你管理在发布后有太多缺陷需要修复的风险。

　　了解查找和修复一个缺陷需多少成本使得你可以对查找、修复、验证缺陷的过程提出疑问。这是使用合适质量建立一个系统的另一个方法.

这个阶段平时处理的好的，比较细心的人在这边正常情况下是不会发生什么问题。但是也难免。所以这个release testing也是非常重要的一个步骤。不要小看之。

　　这个阶段正常会发生什么情况呢：

　　开发人员少放了一个文件，或者多放了一个文件，没影响功能。（你说是不是问题？）

　　开发人员放错了文件。

　　还有的开发人员可能会把以前的版本放进来了。

　　程序的名字写错了。在微软，有一次错的比较厉害的是：Window Live Hotmail 写成了 Window Live Hotmal，这个问题就比较大啦。

　　原来我在一家软件公司，开发人员会把自己的公司名字也错过。

　　有些很明显的地方的标题是不是错了。

　　还有一些问题，开发人员说已经改好了，但还是错的。（在规范的软件的过程中，正常不会出现这样的问题。但一些不是很规范的公司，还是会出现这样的问题。）

　　有的时候，在自己的机器上，一点问题都没有，但到了客户那边问题就是100％出现。（我原来就出现过这样的问题，调一个函数中有一点错误，在自己的机器上怎么也不出现，清空在build，还是没问题，但是到了canon，问题就是出现。后来还是直接在客户那边调试的。真怪啊。）

　　会不会有不一致的地方。

　　产品安装，不是多了东西，就是少了东西。（安装程序哦）

　　调试版本。（这个我出现过的，有次不小心把调试的版本发上去了，搞得安装包特大，不说了，脸红了。）

　　客户可能会要求做一些修改的地方，是不是都修改了。（这肯定要达标啊，不然客户怎么给你钱？）

　　你的环境很好，但客户的机器就不同了。（是不是再确认一下在各个环境下的测试呢？）

　　你的版本是不是13或者250。（也许，你觉得无所谓，但是客户可能不这么考虑。）

　　安全漏洞测试。（这块我接触不多。如果您有这方面的经验，我们可以讨论一下。）

　　病毒测试。（呵呵，这是最呕心的。你的安装包里携带病毒。别觉得自己的机器没问题啊。我一朋友就发生过这样的问题。）

　　这么多问题，release testing 重要吧？

在CMMI4体系的测试过程中定义了四个度量指标：测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率。为了使专/兼职测试人员理解这四个度量指标，了解如何利用现有资源收集度量数据，本文介绍这四个指标的含义及数据收集方法。

　　1 测试覆盖率

　　测试覆盖率是指测试用例对需求的覆盖情况。

　　计算公式：已设计测试用例的需求数/需求总数。

　　测试覆盖率从纬度上说包括广度覆盖和深度覆盖；从内容上说包括用户场景覆盖、功能覆盖、功能组合覆盖、系统场景覆盖。

　　首先说广度，是否需求规格说明书中的每个需求项都在测试用例中得到设计。其次说深度，通俗的说，是不使我们的测试设计流于表面，是否能够透过客户需求文档，挖掘出可能存在问题的地方。例如：重复点击某个按钮10次，或者依次执行新增、删除、新增同一数据的记录、再次删除该记录操作。在笔者的实际工作中碰到过这么一个例子，一个使用PL/SQL编写的系统，在某个查询界面，重复点击《查询》按钮6次后，系统就会出现查询功能失效的问题。经调试，开发人员发现是由于gdi资源未完全释放的缘故。

　　在设计测试用例时，我们很少单独设计广度或深度方面的测试用例，而一般是结合在一起设计。为了从广度和深度上覆盖测试用例，我们需要考虑设计各种测试用例，如：用户场景（识别最常用的20%的操作）、功能点、功能组合、系统场景、性能、语句、分支等。在执行时，需要根据测试时间的充裕程度按照一定的顺序执行。通常是先执行用户场景的测试用例，然后再执行具体功能点、功能组合的测试。

　　测试覆盖率数据的收集，我们可以通过需求跟踪矩阵RTM来实现。在需求跟踪矩阵，测试人员填写的“系统测试用例”列的数据。测试人员通过计算RTM列出的需求数量，和已设计测试用例的需求数量，可以快速的计算出测试覆盖率。通过RTM，测试人员，包括项目组成员都可以很清楚的、快速的知道当前这个项目测试的测试覆盖情况。

　　注：本RTM例子中，笔者将“概要设计”、“详细设计”、“编码”等列隐藏，只显示与测试覆盖率计算有关的内容。

　　2测试执行率

　　执行率，顾名思义，就是指实际执行过程中确定已经执行的测试用例比率。

　　计算公式：已执行的测试用例数/设计的总测试用例数。

　　读者肯定觉得很奇怪了，我们设计的测试用例肯定都是要执行的，即使是按模块来执行测试，那该模块的测试执行率肯定是100%，为什么还要设置这个指标？

　　其实不然。在实际测试过程中，经常有如下这种情况发生。一种情况是，因为系统采用迭代方式开发，每次Build时都有不同的重点，包含不同的内容；第二种情况是，由于测试资源的有限，不可能每次将所有设计的测试内容都全部测试完毕。由于这两种情况的存在，所以在每次执行测试时，我们会按照不同的测试重点和测试内容来安排测试活动，所以就存在了“测试执行率”这个指标。

　　通常，我们的测试目标是确保100%的测试用例都得到执行，即执行率为100%。但是，如前面所提到的，实际中可能存在非100%的执行率。如果不能达到100%的测试执行率，那么我们需要根据不同的情况制定不同的测试执行率标准——主要考虑风险、重要性、可接受的测试执行率。在考虑可接受的测试执行率时，就涉及到了测试用例执行顺序的问题。

　　在设计测试用例时，我们需要从广度和深度上尽可能的覆盖需求，所以我们就需要设计各种测试用例，如正常的测试用例、异常的测试用例、界面的测试用例等。但是在执行时，测试人员需要根据项目进度和测试时间的充裕程度，参考测试执行率标准，将测试用例按照一定的顺序执行。通常是先执行用户场景对应的测试用例，然后再执行具体功能点、功能组合的测试，完成这些测试后，再进行其它测试，如系统场景、性能、语句等测试。

　　例如，某项目共设计了280个测试用例。该项目某一阶段的测试共分四个版本，其中有一个版本执行了134个测试用例，那么该版本的测试执行率为47.9%。

　　3测试执行通过率

　　介绍了执行结果定义后，我们来看测试执行通过率。测试执行通过率，指在实际执行的测试用例中，执行结果为“通过”的测试用例比率。

　　计算公式：执行结果为“通过”的测试用例数/实际执行的测试用例总数。

　　我们可以针对所有计划执行的测试用例进行衡量，可以细化到具体模块，用于对比各个模块的测试用例执行情况。

　　为了得到测试执行通过率数据，我们在测试执行时，需要在测试用例副本中记录下每个测试用例的执行结果，然后在当前版本执行完毕，或者定期（如每周）统计当前测试执行数据。通过原始数据的记录与统计，我们可以快速的得到当前版本或当前阶段的测试执行通过率。

　　4 缺陷解决率

　　缺陷解决率，指某个阶段已关闭缺陷占缺陷总数的比率。缺陷关闭操作包括以下两种情况：

　　正常关闭：缺陷已修复，且经过测试人员验证通过；

　　强制关闭：重复的缺陷；由于外部原因造成的缺陷；暂时不处理的缺陷；无效的缺陷。这类缺陷经过确认后，可以强制关闭。

　　计算公式：已关闭的缺陷/缺陷总数

　　在项目过程中，在开始时缺陷解决率上升很缓慢，随着测试工作的开展，缺陷解决率逐步上升，在版本发布前，缺陷解决率将趋于100%，如图二所示。一般来说，在每个版本对外发布时，缺陷解决率都应该达到100%。也就是说，除了已修复的缺陷需要进行验证外，其他需要强制关闭的缺陷必须经过确认，且有对应的应对措施。可以将缺陷解决率作为测试结束和版本发布的一个标准。如果有部分缺陷仍处于打开或已处理状态，那么原则上来说，该版本是不允许发布的。

　　缺陷关闭数据，可以通过缺陷跟踪工具定期（如每周）收集当前系统的缺陷数、已关闭缺陷数，通过这两个数据，即可绘制出整个项目过程或某个阶段的缺陷解决率曲线。

　　当然了，测试度量指标不仅仅只包括上述四个，在实际工作中，还会用到如：验证不通过率、缺陷密度等指标。收集这些数据目的是为了能对测试过程进行量化管理。但是，简单收集度量数据不是目的，通过对数据的分析、预防问题、对问题采取纠正措施，减少风险才是目的。

问题：一个关于项目管理的通俗讲解

想首先问大家一个问题：你觉得中国人聪明还是美国人聪明？ 我见过最好的回答是美籍华人。

我们说美国人很愚蠢，为什么呢？
　你们都考过T或G吧，他们经常会出这么一道题1/3+1/2=？
　50%的人回答是2/5，这可是美国研究生入学考试的试题呀！
　通常在这个问题之前还有一个1/2+1/2=？为什么？
　他们怕太难了，先给个容易的热身一下。
　我在美国的时候见过很多的PHD，对于美国人来说if…else…是逻辑，而if…if…else…就成了哲学，也是美国这么多哲学博士的原因：）
　我们说美国人很愚蠢，那我们为什么还要学习他们呢？这个问题稍候我们会回答。
　再问一个问题：如果你刚买了一个豪华的房子，可你三岁的儿子把整个墙壁上都写上“我爱长城永不到，我爱北京天安门”，你该怎么做？
　有的女孩子说暴打，呵呵，这个答案从女生的嘴里说出来还是比较少见。
　美国人怎么办？
　他们会对孩子说：“你老人家真有绘画的天赋，简直就是毕加索的毕加索，你这一幅画至少能卖100万美金”你们知道美国人喜欢钱，用金钱来量化一定是效果明显。
　但显而易见，您老人家把画画在墙壁上是不能永久保存的，所以我明天给你买一个画布，你就尽情的画吧。否则我们要损失多少个毕加索呀！
　于是我们就可以看见我们的小宝贝在画布上快乐的滚来滚去。墙面也干净了。
　中国人很聪明，从大家就可以看出来，但中国人聪明做工作就有了聪明的做法，他们往往是每个项目都是按照自己的见解来做。
　而美国人如何来操作呢，他们就象洗澡，会在面前挂一张纸，上面写着先洗头，再洗耳朵，再细脸，，，这样做事情就有了一定的流程，渐渐的就形成了一套体系。
　所以这也是我们今天来探讨项目管理的目的所在。
　项目管理分九个知识领域，分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。
　其中时间，质量和成本管理构成了三角形
　大家在纸上画一个三角形
　在各个边上标上时间、质量、成本（等边三角形）
　任何一方的移动必定带动其他的变形，如果时间缩短，怎么样？就是我们常说的“献礼工程”，同时必定会影响质量和成本。问大家一个问题，这个三角形中间是什么东东？
　对，是范围管理，也就是我们说的项目范围。这也就是我们常说的项目“项目管理三角形”
　下面介绍一下项目管理的“项目管理三角形“
　项目三角形中的成本，主要来自于所需资源的成本，自然也包括人力资源的成本。这个相信很好理解。
　为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
　为了节约项目成本（资源），可以减少项目范围或延长项目时间；
　如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间
　通过“项目管理三角形“我们了解了项目成本、时间，质量和范围的简单定义。
　我们说一个项目经理有多少时间是用来做沟通的工作的？
　应该不少于75%的时间是用来沟通的，所以项目管理将项目沟通管理单独列了出来。
　所有这些领域都有一个主线就是项目的整体管理来统一的。
　由于时间的限制我们不详细讨论其他的知识领域，因为今天是入门的，哈哈
　另外项目管理除了九个知识领域，还应该了解5个过程组
　5个过程组就是：启动，计划，执行，控制，收尾。
　这5个过程组贯穿于每个知识领域的始终，你们了解吗？
　举个例子字来说
　某人（比喻）好不容易找了个女朋友，为了增进进一步的距离，他想来个欧亚8日游，于是他把自己多年的积蓄——3万元，一次性投入。
　但在旅游过程中，他的MM看上了另外一个帅哥，于是人财两空，说明什么问题？
　说明他的项目启动的时候就出现了问题，没有很好的做市场调研，结果过程就没有办法控制。
　根据PMI的解释，接单之后项目自然转入启动阶段
　于是他刻苦的工作，终于又攒了3万，这次他不和美女旅游了，考虑到自己的费用，他请这个姑娘看了场电影。
　于是他带这个这个姑娘看了——《第一滴血》
　看的那叫爽，姑娘看的也很爽，看看完后她觉得这个家伙有暴力倾向，于是又分手。说明什么问题？
　对，没有进行有效的需求调查，也就是在计划的时候没有明确的需求定义。
　于是他下次的时候知道了姑娘爱看歌舞剧，于是他就请一个靓女看了《天鹅湖》，可是以外有发生了——
　进去后发现座位不在一起，等他们把位子换到一起的时候歌舞剧结束了，这说明什么？
　对，说明没有很好的执行，起码在执行过程中没有进行有效的监督。
　其他的过程不一一解释，我在这里强调的是收尾的重要性。
　我们往往非常注重合同性收尾，却总是忽略管理性收尾。什么是管理性收尾呢？
　某人同志吸取了所有的经验教训，终于领了结婚证，还应该干些什么呢？
　对了，还应该把所有的经验教训总结一下，以书面的形式汇报给老妈，并张贴于门后。
　然后在中堂挂一幅对联：欲谈恋爱者需先阅读门后之——《恋爱指南》
　以后凡是自己的兄弟姐妹要谈恋爱的，必须先参阅门后的恋爱指南。
　这样能起到什么效果呢，对，以后他们的恋爱项目操作至少能停留在这个水平。
　这个过程怎样来保证呢，对，还需要我们的QA人员，也就是他的妈妈负责质量控制。
　家规一条，不参阅者或不照此操作者不许谈恋爱！
　大公司一般有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班人的有力争夺者：）
　这也是我们说一个失败的项目会培养一批优秀的项目经理的原因。
　哪个门后的《恋爱指南》我们称之为文档，文档重要吗？我们说在电信科技处的同志们说重要，为什么因为他们管这个，但对于我们呢？
　大家拿起你身边的一只笔，告诉我他多长？
　有的说10厘米，有的说10。0987厘米。
　我们说他的估算很精确，但不准确！！
　这是我如果拿一只笔告诉你正好10厘米，然后和你的笔比对你是不是就比较容易得出测算？
　这说明文档是非常重要的，有的人认为文档是最无聊的，项目结束后做个总结不就是了吗。
　错，文档的整理应该贯穿于项目管理的始终。
　文档的管理是对项目进行良好的跟踪和监控的一个手段，简单的讲就是根据你的项目计划进行你的文档管理。
　一般档案分类主线是：立项、计划、执行、结束4大类；然后在每大类中，再根据任务或者团组分类管理，根据哪个需要根据你项目复杂程度和管理习惯，总之原则是方便你对整个项目进度的追踪。
　以上我们讲了项目管理的九个知识领域，五大过程组，还有“项目管理三角形“，下面我们讲PMBOK。

---

回复：
PMBOK是项目管理圣经，也就是Project management body of knowledge,项目管理知识体系指南
　它是美国项目管理协会（PMI）的核心指导出版物
　但它象一本字典，往往你看到第三页会睡着：）
　在此简单介绍美国项目管理协会（PMI）和国际项目管理协会（IPMA）
　美国项目管理协会只有PMP一个证书，而IPMA有四级，你可以一毕业就可以考试，这个我们后面详细的讲。
　下面讲几个名词，如果你掌握了，一和人讲项目管理你就抛出来，一定没有人敢小看你。
　他们是WBS、甘特图、基准（BASELINE）、项目干系人和关键路径
　WBS是WORK BREAKDOWN STRUCTRE ，工作分解结构
　WBS的定义还是很麻烦的，PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员 进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。
　比如我们要结婚了，怎么来分解呢
　无非是办酒席，拍结婚照，，等等，这个在论坛上曾有人做了详细的分解，大家都可以找到。
　我们说为什么WBS重要，而且大部分项目管理的咨询都是针对WBS的咨询
　因为WBS做好了，以后工作就有了参考物，你就知道在不同的阶段你应该干什么，完成到什么进度。
　其实WBS的划分是没有规则的，主要的考虑角度是方便你做各类的统计工作，为管理服务。
　同样的一个项目其管理的侧重点不同，WBS结构的划分也可能是完全不同的。
　衡量划分好坏的标准应该是看其是否满足你管理的需要。
　甘特图也叫横道图等，很多名称，我们说它是甘特在第一次世界大战时开始使用，它就是在WBS的基础上将WBS形象化老控制进度
　对于基准，我象举个例子。
　我们在没有结婚之前，你脚踩几只船？
　我们说法律允许但道德不允许，但你可以脚踩N只船：）
　但当有一天你和你的朋友进了一个小黑屋子，然后带了两个盖章的本本的时候，你还可以脚踩N只船吗？
　我们说此时就不允许了，因为你过了一个基准线（BASELINE）
　如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。
　那我们的项目要越轨怎么办，也就是项目变更？
　我们说对这样的项目变更会影响各要素比如时间，成本，质量等
　我们应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。
　在客户提出变更请求时，要建立变更申请登记表和变更申请 表，并让客户签字。
　有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要 卖面子，但是也别卖的太干脆，不要让他们得到的太容易。
　PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
　如果一个项目进行过程中，比如现在的点心的3G项目，你发现如果再多花一点时间就可以编写出对以后非常有用处的程序，但这个程序不在本项目范围之内，你要不要做？
　对，我们说不能做，你可以重新起一个项目来做，但不能在这个项目里做，这样会是我们的项目成本超出，风险增加，而且和其他的项目缺少比对性和参照的价值。
　这也是我们说现在有大约80%以上的项目失败的原因，我们说项目失败并不是项目进行不下去了，彻底破产，在PMI有明确的定义，凡是项目　的成本超出预算，质量没有得到保证，时间超过预计等等都在失败的范围之内。
　这个在华为做的很好，华为有个有名的增量开发的名声。
　只用20%的功能先满足你80%的需求，其他的功能我可以开发升级的版本，于是就在小数点后平明的增加数字，于是就是了V1，V1.1，　V1.11….等版本
　它从来不一下子满足你所有的需求，我们大家想想，谁没有事情拿出自己的手机把所有的PING码都试用一下，我们说没有，我们大部分的需　求是在打电话，发消息，打打游戏，对不对？
　这点在项目管理中非常重要，请大家结合资料好好研究。
　项目干系人是什么东东，谁给我举一个例子？
　对，包括项目人员的老婆孩子，正确
　我们说有的项目需要的时间很紧张，如果你的项目成功了，但项目的程序员们都成了光棍，那项目还是非常失败，至少不是丧心病狂的PM这么想。
　合理解决项目干系人的冲突是个很累的问题，其中还包括你的只能经理们，你的董事长，你的客户，等等，等等，有的说没用？
　好，如果你的项目进展不下去，你该怎么办？
　对，开会，把你的高层找一个坐到会议室，不用他说话，只让他暧昧的看着大家，大家一定会想，这个家伙一定和领导有关系，我们还是好好的做这个项目，下一个项目再给他使拌子吧：）
　所以为了不累死好好分析一下你的项目干系人吧
　我们上次讲了一些基础的知识，包括什么是项目管理，项目管理包括什么？
　你说项目管理有几个知识领域？
　你说项目管理有几个过程组？
　让我们想起了泡MM的例子是不是？
　还有老母亲做QA的比喻
　几天我们着重强调的是

　项目是什么?

　人们常用“时间”，“资源(或缺乏资源)”，“某种工作努力”，“交付物或者产品”，“综合工程”，“缺乏凌驾其他班组的职权”，以及“预算”来给它下定义。实际上，项目是一种独特的工作努力，即遵照某种规范及应用标准去导入或生产某种新产品或某项新　服务。这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成。
　首先给大家一个项目的定义，到底什么是项目？
　根据PMPBOK的定义，项目是在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程。
　这个过程受到时间、人力、资源、成本、质量上的限制
　项目有几个特征：1.临时性 2.独特性 3.一次性
　下面大家告诉我下面哪个是项目：A惠普与康柏机构重组惠普与康柏机构重组。B建造一座新工厂 C改建道路 D工程材料采购 E开发软件包 F结婚典礼 G寻找拉登
　有人说是寻找拉登，大家说寻找拉登有明确的结束时间吗？
　当然我们可以假设寻找拉登50年如果找不到，项目就结束是不是？
　所以说我们今天不讨论哪个到底是项目，所有的问题都要放到具体的环境下，否则没有意义。
　下面大家可以开始提问了。

　什么是WBS呢？
　WBS是工作分解结构，就象一张道路交通图，它能够指引你如何从当前位置到达想去的地方。没有它，你可能就要迷路了。

　怎样来做一个好的WBS呢？
　有时候在接受新项目时前无例子可借鉴感觉分解时真困难, 因为每个人的解决问题思路不同,同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解, 但我觉得有一条很重要的原则应该注意,那就是麦肯锡的精髓,他们在分解工作时非常强调的就是MECE, muturally exclusive, collectively exhaustive, 即相互独立,完全穷尽的原则, 也就是现在较流行的说法"横向到底,纵向到边" , 如果分解时坚持了这个原则, 我想一定会有Perfect 的WBS, 其实WBS并非是PMI的"真传", 只是被PMI起名为WBS, 有时候工作中我们也会用类似的方法解决问题无非是没有提升到理论高度, 但WBS确实是做事的核心步骤。

　做一个WBS需要注意一些什么问题呢？
　·第一级通常与项目生命周期相同(如需求分析，设计，采购，施工……)
　·第一级应在项目进一步分解前完成
　·WBS的每一级都是其上一级的片断(Segment)
　·一个工作单元只与一个上层单元相关
　·上层单元的工作内容应该等于其所有直接下层工作单元的总和
　·一个工作单元由一个人负责
　·在整个WBS中使用同一种定义，在整个组织中亦然
　· 通过将人员包括进WBS来激励他去完成计划

　什么是甘特图呢？
　1.以图形或表格的形式显示活动。
　2.现在是一种通用的显示进度的方法。
　3.构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内

　什么是风险呢？

　首先问一个问题
　你们说在一个项目中，初始阶段和结束阶段哪个时候项目的风险大？
　对，是开始的时候，因为在开始的时候我无数的不可控制的因素。
　那什么阶段的损失大呢？
　对，在结束的时候，所以说两者是相反的/
　所以说在项目的启动阶段成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的。
　想想广州和深圳很多烂尾楼？损失会有多少？？？！！！！！

　另外我们要明确几个定义：
　1是确定性。具有明显的可能性，比如中国和韩国对抗赛，胜负是很明显的：）
　2是风险。韩国队能赢中国队几个球是一种风险的预测。
　3是未知性。中国和美国比赛门球那就是未知的。

1、在项目发布后发现和修复Bug的成本是需求和设计阶段所需的一百倍！

10、大约40-50%的用户程序都存在着很大的缺陷。

企业业务软件工程项目和商业软件产品项目上项目无论是需求重点，实现方式，项目管理等方面都有极大不同。现在的软件工程有关研究并没有关注此中的区别，实际上，其中绝大部分还集中在较简单的产品项目上。对于需求变动要大得多的企业软件项目来说，对需求进行分级管理是非常必要的，也是生死悠关的。

企业化软件项目和商业软件的（承包开发）还是有很大的不一样的，最大的区别就在于项目需求的重点不一样，以致于这两种同样称为软件工程，就其项目过程管理是几乎完全不一样的。商业软件的开发最大的特点是就是基本功能非常明确，只在细节上有多种选择，所以商业软件开发的项目管理重在源代码管理和算法的优化，以及测试严格，就测试要求的强度上单纯软件代码的质量来说，要强于企业信息化的软件工程项目。

企业信息工程项目一般来源于企业某一特定的业务软件需求，象要上一个仓库管理系统，从进货到定期定标出仓平衡责任追踪等；或者是一个生产流程配料系统，象MRP2；或者是一个购销一体计划系统，象ERP（资源管理），等等。这种软件有时侯会象国产的那些变相的会计软件式的ERP一样当成商业软件开发，显然，这时侯与上述的成形商业软件没有太大的区别，但在企业实际上千差万别的应用需求上，几乎就是一堆电子垃圾。企业业务软件是一种必须适应同时能够优化企业流程的计算机辅助运营系统，真正起作用的，通常只能是一对一实现定制；这种需求是如此广泛，以致于大型企业如果不是聘有一两家软件咨询顾问公司就是自建一个计算机部门专门负责这一方面的工作；最典型的例子就是沃尔玛特。

正由于企业用的软件都存在着强烈的需求一对一定制的要求，所以这种项目其一是不便宜；如果一个企业客户以购买商业成形软件的理解水平来购买一个"项目"洽谈的话，在他理解什么叫企业项目前，最好不要打算做他的生意。一个企业项目动辄数百万上千万是不奇怪的，上亿也寻常，而一套商业软件，无论名称多么好听，什么第几代ERP，都只不过是一万几千大洋就可以打发的；实在不愿意给钱又不怕给罚盗版的话，还可以花五个铜板上街买一套盗版光盘现装现用。

为了应付企业业务软件项目的强烈的定制需求，供应商都提供了广泛的基础组件和嵌套工具，以便可以由二三级的程度员可以在现场为用户一对一的进行定制试用更改再定制等项目实现。典型如SAP，有朋友问我拿SAP的盗版玩玩，保证不外流。我费了很大的工夫才让他明白，SAP有的只是基础组件库，还很丰富，涉及到27个项目常用业务场合的组件库，包括与之配合的数据库预制定义（表定义），但绝不是象国内那些ERP那样装起来可以玩的东东。一个SAP项目要求用户按自已需求定购这些组件库，以及必须的支持软硬件，数据库操作系统什么的，最经常的就是ORACLE和SOLARIS了；然后SAP项目组要到企业里蹲点，听各个部门讲流程故事；然后是写需求文档，建原型，让企业的项目组试用部门流程，基干流程确定合乎需求了，下一步的工作就是简单了，找几个三流的程序员用ABAP/4这种比javascript还简单的脚本语言把各个组件的功能连成一个统一的流程。这个工作就完成了一大半了。——可别小看这些三流程序员，在软件蛮荒年代他们凭这一招可以拿到每个月两万人民币的工资呢！其实呢，那是一个高中生就可以完成的工作。

由此可见，企业软件项目的关键在于需求管理和流程建模，相反，算法和基本功能以及BUG什么的，那是作为商业软件开发的组件保证的，那一般以外包的形式由印度这些公司早早做了出来。企业软件需求最大的困难就是用户根本不知道自已要干什么，最常犯的错误就是把现有的落后流程要求电脑重复一遍，拿了机关枪，总是要求上面没有装刺刀，还抱怨不比红缨枪好用。另一个常见的错误就是随着企业项目主管，（职业最低成是电脑科主任，高点就是一二把手了）知识开始丰富后，总是把有用没有用，暂时有用或永远没有用的需求要项目组一一实现，反正，每条要求都是振振有词，仿佛都是非立刻实现不可的。作为承包方的人员是没有办法与之争业务上有没有用的，（谁是这一行业的专家啊？人家已经是霸主了才上软件，你算那们子专家啊？），但如果真的一一跟着他的点子走，就算累死了，这个项目也是永远没有法子完成的。而在商业需求明确的商业软件开发中就不会碰上这种事情。

这时侯需要对客户的需求进行分级管理，简单地说，把需求分成五级：urgent(必须立刻优先实现)，necessary(必须实现,但不一定马上进行)，needed(需要的，不过没有也还凑合)，better(现在似乎也可以，但可以更好一点)，useful（总会有用的）。一个需求等级的确认需要两个过程，首先是从正面论证它是不是必须的，是不是好得多；然后从反而论证，不要他是不是可以回避的，天会不会塌下来？这样，一个软件需求就可以相当定一个级别。毫无疑问，如果一个项目各项需求验证下来只是useful的，不但赚不了多少钱，而且，这个项目未必有必要存在；但如果都是urgent的话，如果不是大幅度加价的话，就叫神仙来做好了。显然，无论客户是如何那般的行业专家，他的需求只能是平均地分配在这五个级别，否则就说明他不是专家，（呵呵，也算是个逻辑陷阱），在实现时，当然就挑urgent&necessary来实现，其余的，升级再说了。

对于那些身处SOA大潮中的CIO而言，构想和建设一个敏捷、灵活、模块化和可扩展的IT系统是他们的最终梦想。分布式SOA能给他们带来的不仅仅是惊喜。

　　当今，无论你走到哪里，都会看到一些关于SOA的东西，以及关于用“适当”的方式执行它的争辩。笔者认为这一点也不奇怪，因为伴随着每一个IT行业相关的新趋势的出现，都会有争辩，并且卖主会尽力说服顾客相信，他们的技术才是适当的技术、产品。

　　当卖主为了迎合消费者对于信息技术一个新趋势的兴趣，试图重新配制他们现有的产品组件时，抢夺开始了。但是很不幸，这种行为通常会引起许多混乱局面，因为卖主的诺言一般是不会实现。当然，面向服务架构适当的技术方案，也可能并不像他们说的那样好。

　　为了对此建立正确的观点，重要的是应该注意到，像定义所说，SOA是分布式的。一项服务的目的就是，通过远程线路跟另一项服务相通，以共享数据为特色。而其整体的目的是，改变信息技术的途径，由原来的制定辐射中心的小部分应用软件，到制定另一系列的应用软件，它可以通过集合共享的并且可以再度利用的功能性，即各种服务，开发和汇集越来越多的应用资产。

紧耦合VS松耦合

　　现在宣传SOA的厂家非常之多，但是真正提出分布式SOA架构的并不多。因为很多大型软件厂商习惯了以紧耦合的方式提供SOA架构的主要功能，SOA紧紧地和他们的数据库、操作系统、服务器和存储绑定，这种紧耦合方式缺乏与其他系统的互操作性，初期需要大量的资金投入，往往会导致用户对某个厂商的依赖。紧耦合式SOA架构导致用户对采用SOA处于犹豫状态，因为还未看到成功的希望时就需要大量的投资。

　　面向服务的体系结构最重要的一个思想就是实现软件间的松耦合。松耦合的软件结构可以降低软件的复杂性，提高重用性，使软件能够更好地适应需求的变换。

　　其实，用户更需要低成本的SOA解决方案，令他们可以从小规模SOA做起，并随着业务的增长逐步扩大规模，同时根据自身的需求增加服务质量和其他功能等。

　　与此同时，用户可以使用点到点的通信方式，避免新增加昂贵的服务器。简而言之，SOA用户需要的SOA架构必须真正具备SOA架构的固有特性也就是分布式的特性，如图1所示。

　　SOA的本质是通过松耦合的方式实现服务的重用。分布式SOA则是把松耦合的优势发挥得淋漓尽致。它可以帮助用户摆脱紧耦合的束缚，以较少的投资开始SOA建设，用户只配置需要的功能，并根据需要以渐近的方式扩大整合的规模。分布式SOA可以在运行环境中动态配置,也就是说用户的业务无需中断。分布式SOA基础架构，具备今天SOA所涉及的全部元素。

　　一个分布式SOA的基础结构，代表着配制和吸收可共享和再度利用的服务最简易的方法，促进对服务的应用，提高部署的灵活性、适应性和持久性。

　　不幸的是，到达SOA基础结构的途径被集中化，并不断被开发和提议。

　　对于卖主来说，说服购买技术的群众相信提供给他们的技术已经是跟SOA相适应的，以前是，以后也是，设计这项技术的初衷就是加快顾客走向SOA的步伐，将是一个更艰难的过程。卖主也不管它最初是以J2EE应用服务器还是EAI系统的形式设计出来的。
　
　　换言之，对分布式SOA持对立态度的卖主通常这样做，因为途径集中化是他们已经拥有的软件基础构架的特征。一个更新了的企业应用集成或一个基于JEE的堆栈，或其他任何在通过中控点时需要发送请求的方案，都不能被看成是真正的分布式，因为它们所有通向服务路径的前提都是必须首先进行集中处理。将通往SOA途径集中增加了成本，限制了再利用，降低了灵活性，且暗中引入了一个昂贵的瓶颈。最坏的情形是，它将在第一时间否定到达SOA的理由。如果SOA的基础构架的灵活性没有满足他们的要求，人们一定会感到很失望。

　　只要上网查，就可以了解分布式应用软件满足其用户需求的成功案例。网络是目前最大的分布式应用程序，由特征决定其分布模式，SOA是同样的道理。

　　当你在浏览器上点击一个链接到某一个具体网址时，你的需求并不需要经由某个配制在一个服务器或者网络中心的中控系统，而是直接从你的浏览器传达到网络服务器，这种模式在企业的SOA运作得也非常好。

　　网络终端能够以个体为单位进行升级，而不会打断客户机程序的运转，影响其他站点，或者导致中央集线路或服务器也需要更新，那是因为需求不需要首先通过一个中央集线路或者服务器。一个好的SOA的基础构架同样支持这些性能。

　　幸运的是，一个基础构架方案包含了SOA分布式的特征。到达SOA基础构架分布式的途径使用很精巧的终端，有可提供服务的应用软件，并使得这些软件能够直接跟其他服务相通。企业性质的服务，比如具有高度的实用性或者安全性的服务，也可以由终端系统提供，以确保现有的承担着重大使命的应用软件有所依靠。

　　分布式SOA的基础构架是关于创造信息技术环境的，这个信息环境是一个交流平台，标准高，灵活性强，所以它可以对不断更新的技术和商业前景做出更有效的反应。因此，一个分布式的SOA工作环境能够更好地支持一个以SOA为基础的应用软件的技术和经济需求。最后，到达SOA基础构架的分布式途径允许你以自己的速度进行，每次配制一个或两个服务，可以根据需要随时增加服务，注册/存储库，管理等功能，而不是事先就必须完全添加好的。

　　分布式SOA的好处与航空行业有相似之处，后者用成本低廉的操作系统挑战着已建造的航空器。已制定操作系统的方法是以一个成本很高的枢纽和辐射模式为基础，通过少数几个专业的旅游中心汇集乘客。操作大型飞机需要更多成本，从分支机场飞往枢纽机场，乘客在那里准备继续他们的旅程到达最终目的地。用这种模式，飞机需要更多成本，机场设备的费用也因此增加。当低成本航线—一个分布更广的，点对点的运作模式(较小的飞机直接飞往较小的机场)—被制定出来之后，被传统的枢纽模式所束缚的航线便在资金方面处于劣势。

　　SOA的消费者不需要再花钱买老式的昂贵的软件堆栈了。SOA设计需要一个好的方式来创造和配制可再利用性服务，无论何时何地只要有需要就能够很简易并且直接地拿出来用的方式。消费者需要成本低的选项，可以让他们从小规模开始，随需要逐渐增加对它的采用，运用点对点通讯方案可以避免使用昂贵的新服务器和集成线路，根据需求增加服务的质量和其他性能。总而言之，他们需要SOA的基础构架，它能够真正符合一个SOA固有的分布式特征。

　　SOA治理同等重要

　　随着服务数量的增加，管理服务成为SOA过程中的一项重要工作，与IT治理同等重要。

　　同样需要指出的是，IT系统在建立之日起就需要考虑IT治理的理念和方法一样，SOA也存在着类似的问题。随着大量服务的构建，系统也日益复杂，尤其是随着服务的可重用性日益提高，调用同一个服务的请求的个人和部门也越来越多。而Web服务的数量越来越多且被不同的部门调用和管理的时候，SOA治理问题就被提上了日程，对IT系统有灵活、可扩展和快速响应需求的企业尤其如此。所以说，SOA的构建和与治理几乎是同步的，这关系着一个企业能否从SOA上获得高收益，甚至也决定着SOA的成功与否。

　　SOA治理并不设计服务，而是指导将如何设计服务。这可以帮助回答和解决很多关于SOA的问题，包括:我们提供了那些服务？谁可以使用这些服务？它们的可靠性、安全性如何？……

　　因此，治理更多的是策略问题，而不是技术或业务问题。

Linux是一种类Unix的操作系统。从理论上讲，Unix本身的设计并没有什么重大的安全缺陷。但是因为它不属于某一家厂商，没有厂商宣称对它提供安全保证，因此用户只有自己解决安全问题。
　　Linux不论在功能上、价格上或性能上都有很多优点，然而，作为开放式操作系统，它不可避免地存在一些安全隐患。关于如何解决这些隐患，为应用提供一个安全的操作平台，本文会告诉你一些最基本、最常用，同时也是最有效的招数。

　　一般来说，对Linux系统的安全设定包括取消不必要的服务、限制远程存取、隐藏重要资料、修补安全漏洞、采用安全工具以及经常性的安全检查等。本文教你十种提高Linux系统安全性的招数。虽然招数不大，但招招奏效，你不妨一试。

　　第1招：取消不必要的服务

　　早期的Unix版本中，每一个不同的网络服务都有一个服务程序在后台运行，后来的版本用统一的/etc/inetd服务器程序担此重任。Inetd是Internetdaemon的缩写，它同时监视多个网络端口，一旦接收到外界传来的连接信息，就执行相应的TCP或UDP网络服务。

　　由于受inetd的统一指挥，因此Linux中的大部分TCP或UDP服务都是在/etc/inetd.conf文件中设定。所以取消不必要服务的第一步就是检查/etc/inetd.conf文件，在不要的服务前加上“#”号。

　　一般来说，除了http、smtp、telnet和ftp之外，其他服务都应该取消，诸如简单文件传输协议tftp、网络邮件存储及接收所用的imap/ipop传输协议、寻找和搜索资料用的gopher以及用于时间同步的daytime和time等。

　　还有一些报告系统状态的服务，如finger、efinger、systat和netstat等，虽然对系统查错和寻找用户非常有用，但也给黑客提供了方便之门。例如，黑客可以利用finger服务查找用户的电话、使用目录以及其他重要信息。因此，很多Linux系统将这些服务全部取消或部分取消，以增强系统的安全性。

　　Inetd除了利用/etc/inetd.conf设置系统服务项之外，还利用/etc/services文件查找各项服务所使用的端口。因此，用户必须仔细检查该文件中各端口的设定，以免有安全上的漏洞。

　　在Linux中有两种不同的服务型态：一种是仅在有需要时才执行的服务，如finger服务; 另一种是一直在执行的永不停顿的服务。这类服务在系统启动时就开始执行，因此不能靠修改inetd来停止其服务，而只能从修改/etc/rc.d/rc[n].d/文件或用Runleveleditor去修改它。提供文件服务的NFS服务器和提供NNTP新闻服务的news都属于这类服务，如果没有必要，最好取消这些服务。

　　第2招：限制系统的出入

　　在进入Linux系统之前，所有用户都需要登录，也就是说，用户需要输入用户账号和密码，只有它们通过系统验证之后，用户才能进入系统。

　　与其他Unix操作系统一样，Linux一般将密码加密之后，存放在/etc/passwd文件中。Linux系统上的所有用户都可以读到/etc/passwd文件，虽然文件中保存的密码已经经过加密，但仍然不太安全。因为一般的用户可以利用现成的密码破译工具，以穷举法猜测出密码。比较安全的方法是设定影子文件/etc/shadow，只允许有特殊权限的用户阅读该文件。

　　在Linux系统中，如果要采用影子文件，必须将所有的公用程序重新编译，才能支持影子文件。这种方法比较麻烦，比较简便的方法是采用插入式验证模块(PAM)。很多Linux系统都带有Linux的工具程序PAM，它是一种身份验证机制，可以用来动态地改变身份验证的方法和要求，而不要求重新编译其他公用程序。这是因为PAM采用封闭包的方式，将所有与身份验证有关的逻辑全部隐藏在模块内，因此它是采用影子档案的最佳帮手。

　　此外，PAM还有很多安全功能：它可以将传统的DES加密方法改写为其他功能更强的加密方法，以确保用户密码不会轻易地遭人破译; 它可以设定每个用户使用电脑资源的上限; 它甚至可以设定用户的上机时间和地点。

　　Linux系统管理人员只需花费几小时去安装和设定PAM，就能大大提高Linux系统的安全性，把很多攻击阻挡在系统之外。

　　第3招：保持最新的系统核心

　　由于Linux流通渠道很多，而且经常有更新的程序和系统补丁出现，因此，为了加强系统安全，一定要经常更新系统内核。

　　Kernel是Linux操作系统的核心，它常驻内存，用于加载操作系统的其他部分，并实现操作系统的基本功能。由于Kernel控制计算机和网络的各种功能，因此，它的安全性对整个系统安全至关重要。

　　早期的Kernel版本存在许多众所周知的安全漏洞，而且也不太稳定，只有2.0.x以上的版本才比较稳定和安全，新版本的运行效率也有很大改观。在设定Kernel的功能时，只选择必要的功能，千万不要所有功能照单全收，否则会使Kernel变得很大，既占用系统资源，也给黑客留下可乘之机。

　　在Internet上常常有最新的安全修补程序，Linux系统管理员应该消息灵通，经常光顾安全新闻组，查阅新的修补程序。

第4招：检查登录密码

　　设定登录密码是一项非常重要的安全措施，如果用户的密码设定不合适，就很容易被破译，尤其是拥有超级用户使用权限的用户，如果没有良好的密码，将给系统造成很大的安全漏洞。

　　在多用户系统中，如果强迫每个用户选择不易猜出的密码，将大大提高系统的安全性。但如果passwd程序无法强迫每个上机用户使用恰当的密码，要确保密码的安全度，就只能依靠密码破解程序了。

　　实际上，密码破解程序是黑客工具箱中的一种工具，它将常用的密码或者是英文字典中所有可能用来作密码的字都用程序加密成密码字，然后将其与Linux系统的/etc/passwd密码文件或/etc/shadow影子文件相比较，如果发现有吻合的密码，就可以求得明码了。

　　在网络上可以找到很多密码破解程序，比较有名的程序是crack。用户可以自己先执行密码破解程序，找出容易被黑客破解的密码，先行改正总比被黑客破解要有利。

　　第5招：设定用户账号的安全等级

　　除密码之外，用户账号也有安全等级，这是因为在Linux上每个账号可以被赋予不同的权限，因此在建立一个新用户ID时，系统管理员应该根据需要赋予该账号不同的权限，并且归并到不同的用户组中。

　　在Linux系统上的tcpd中，可以设定允许上机和不允许上机人员的名单。其中，允许上机人员名单在/etc/hosts.allow中设置，不允许上机人员名单在/etc/hosts.deny中设置。设置完成之后，需要重新启动inetd程序才会生效。此外，Linux将自动把允许进入或不允许进入的结果记录到/rar/log/secure文件中，系统管理员可以据此查出可疑的进入记录。

　　每个账号ID应该有专人负责。在企业中，如果负责某个ID的职员离职，管理员应立即从系统中删除该账号。很多入侵事件都是借用了那些很久不用的账号。

　　在用户账号之中，黑客最喜欢具有root权限的账号，这种超级用户有权修改或删除各种系统设置，可以在系统中畅行无阻。因此，在给任何账号赋予root权限之前，都必须仔细考虑。

　　Linux系统中的/etc/securetty文件包含了一组能够以root账号登录的终端机名称。例如，在RedHatLinux系统中，该文件的初始值仅允许本地虚拟控制台(rtys)以root权限登录，而不允许远程用户以root权限登录。最好不要修改该文件，如果一定要从远程登录为root权限，最好是先以普通账号登录，然后利用su命令升级为超级用户。

　　第6招：消除黑客犯罪的温床

　　在Unix系统中，有一系列r字头的公用程序，它们是黑客用以入侵的武器，非常危险，因此绝对不要将root账号开放给这些公用程序。由于这些公用程序都是用.rhosts文件或者hosts.equiv文件核准进入的，因此一定要确保root账号不包括在这些文件之内。

　　由于r字头指令是黑客们的温床，因此很多安全工具都是针对这一安全漏洞而设计的。例如，PAM工具就可以用来将r字头公用程序的功力废掉，它在/etc/pam.d/rlogin文件中加上登录必须先核准的指令，使整个系统的用户都不能使用自己home目录下的.rhosts文件。

　　第7招：增强安全防护工具

　　SSH是安全套接层的简称，它是可以安全地用来取代rlogin、rsh和rcp等公用程序的一套程序组。SSH采用公开密钥技术对网络上两台主机之间的通信信息加密，并且用其密钥充当身份验证的工具。

　　由于SSH将网络上的信息加密，因此它可以用来安全地登录到远程主机上，并且在两台主机之间安全地传送信息。实际上，SSH不仅可以保障Linux主机之间的安全通信，Windows用户也可以通过SSH安全地连接到Linux服务器上。

第8招：限制超级用户的权力

　　我们在前面提到，root是Linux保护的重点，由于它权力无限，因此最好不要轻易将超级用户授权出去。但是，有些程序的安装和维护工作必须要求有超级用户的权限，在这种情况下，可以利用其他工具让这类用户有部分超级用户的权限。Sudo就是这样的工具。

　　Sudo程序允许一般用户经过组态设定后，以用户自己的密码再登录一次，取得超级用户的权限，但只能执行有限的几个指令。例如，应用sudo后，可以让管理磁带备份的管理人员每天按时登录到系统中，取得超级用户权限去执行文档备份工作，但却没有特权去作其他只有超级用户才能作的工作。

　　Sudo不但限制了用户的权限，而且还将每次使用sudo所执行的指令记录下来，不管该指令的执行是成功还是失败。在大型企业中，有时候有许多人同时管理Linux系统的各个不同部分，每个管理人员都有用sudo授权给某些用户超级用户权限的能力，从sudo的日志中，可以追踪到谁做了什么以及改动了系统的哪些部分。

　　值得注意的是，sudo并不能限制所有的用户行为，尤其是当某些简单的指令没有设置限定时，就有可能被黑客滥用。例如，一般用来显示文件内容的/etc/cat指令，如果有了超级用户的权限，黑客就可以用它修改或删除一些重要的文件。

　　第9招：追踪黑客的踪迹

　　当你仔细设定了各种与Linux相关的组态，并且安装了必要的安全防护工具之后，Linux操作系统的安全性的确大为提高，但是却并不能保证防止那些艺高人胆大的网络黑客的入侵。

　　在平时，网络管理人员要经常提高警惕，随时注意各种可疑状况，并且按时检查各种系统日志文件，包括一般信息日志、网络连接日志、文件传输日志以及用户登录日志等。在检查这些日志时，要注意是否有不合常理的时间记载。例如：

　　·正常用户在半夜三更登录;

　　·不正常的日志记录，比如日志只记录了一半就切断了，或者整个日志文件被删除了;

　　·用户从陌生的网址进入系统;

　　·因密码错误或用户账号错误被摈弃在外的日志记录，尤其是那些一再连续尝试进入失败，但却有一定模式的试错法;

　　·非法使用或不正当使用超级用户权限su的指令;

　　·重新开机或重新启动各项服务的记录。

　　第10招：共同防御，确保安全

　　从计算机安全的角度看，世界上没有绝对密不透风、百分之百安全的计算机系统，Linux系统也不例外。采用以上的安全守则，虽然可以使Linux系统的安全性大大提高，使顺手牵羊型的黑客和电脑玩家不能轻易闯入，但却不一定能阻挡那些身怀绝技的武林高手，因此，企业用户还需要借助防火墙等其他安全工具，共同防御黑客入侵，才能确保系统万无一失。