日历

« 2008-10-11  
日 一 二 三 四 五 六
   1234
567891011
12131415161718
19202122232425
262728293031 

最新来客

音乐欣赏

统计信息

  • 访问量: 1054
  • 日志数: 15
  • 图片数: 1
  • 建立时间: 2008-02-18
  • 更新时间: 2008-09-01

RSS订阅

顺势而为,无为而无不为

我的最新日志

  • 为bug预防奠定基础

    2008-9-01

     

    1．引言：
    生产软件的企业安排很多人来测试它们的软件产品。测试的目的就是发现bug（缺陷，defect）以便修正它们。正常情况是尽快处理可能的bug，从而减少修正bug的成本。因为，众所周知，bug越早被发现并修正，所消耗的资源越少。
    问题是在很多情况下，由于修正已发现的bug，测试过程不得不停顿下来。
    那么，以目前正忙于软件产品测试的同样资源来促进组织长期的质量目标不是更好？为了做到这一点，我们应该尽快地提前发现可能的bug。就像克劳士比（Philip Crosby）几年前所说的那样，我们应该努力预防bug，而不仅仅是修正它们。这就是真正的质量。
    2．目标：预防bug
    预防的重要性
    正如我们所知，bug应该尽早地在开发过程中被发现。修正处于开发阶段的产品的bug的成本远远低于修正处于QC（Quality Control，质量控制）阶段的产品的bug，而相对与修正已经发布给客户的产品的bug的成本更是可以忽略不计。原因就是当你修正一个bug的时候，相当于把你之前做的事情重做一次。因此，越晚修正bug，你所重做的事情就越多。如果bug修正是在产品测试之前，那么重做的工作只有代码实现。如果bug修是在测试阶段，那么重做的工作就包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程（process），随着项目的进行，产品依赖的组件和流程也会随之增加。
    接下来，从另一个层面来讨论这个问题。如果bug发现和修正越早，开发成本越少，那么在第一时间就避免bug引入是不是成本消耗得更少？如果bug可以被完全预防，那么在开发过程中就不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义，而且在很多情况下已得到严密的证实。然而，并不是所有的生产软件产品的组织都试着去避免bug。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的bug。在某些情况下，软件企业并不试着去达到这样的目标。在产品发布之后，企业通过迅速修正产品中的bug来处理客户的抱怨。这是因为，这样的企业始终处于“问题解决模式”，它们并不试图发现问题的根本原因，而只是把局部的大火扑灭。
    这种模式并不仅仅导致重复工作直接带来成本的增加，而且会带来一个长期效应，而这将影响企业的业务。首先，发布带有bug的产品将给企业的声誉造成影响，并可能造成对潜在客户的影响——他们在是否建立合作关系上拿不定主意。另外，由于企业需要资源来不断解决现有产品中的问题，那么开发新产品的资源势必减少。
    对很多人来说，零缺陷的软件产品似乎是不切实际的。我们总是听到软件开发者说：“软件永远有bug”。产品进入QC阶段时含有bug并不奇怪，因为我们“期望”开发人员制造bug。不幸的是，发布一个包含很多bug的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。
    事实上，每个软件企业都可以通过一些简单的方法，在不增加任何额外资源的情况下预防bug。bug预防在于一个简单的道理：最好的方法是适当借鉴我们自己的经验。
    今天的发现就是明天的预防
    为了能够预防bug，我们必须首先了解bug的来源。软件bug可以分为几个类别（可能相互之间有所重叠）。第一类bug可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些bug可能由于其随机性很难预防，但是，适当的分析将有助于避免这些bug。
    另一类的bug来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类bug共同的特点是都来自于开发人员。除非被发现，否则这些bug将一直存在。例如，一个还不完全理解需求的开发工程师在单元测试阶段可能无法发现这些问题，只有当产品被其他组织（如QC组）测试时才会发现产品实现与需求不一致。这使得在前期避免类似问题的出现更加重要。
    一个好消息是，软件中的bug往往倾向于重复出现，即使是一个随机出现的bug。软件bug的不断出现不仅表现在同一个开发人员的工作上，而且表现在一个项目甚至是企业的层面上。这当然不是说公司中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。所以，为什么我们认为重复的错误是一个好消息？因为可以预见的bug更容易预防。事实是我们可以找到一些常见的问题，并采取相应的措施去预防它（或至少减少类似错误出现的次数）。
    人为bug的子集？那么这些bug被预防的可能性更大。域bug？域bug和产品的问题域或解决方案域紧密相关。这样的bug有更大的机会重现，因为开发人员、项目组甚至企业不断地在这个域上工作。
    现在的问题是如何预防各种bug的产生。基于这次讨论的目的，我建议我们设定一个更加实际的目标。让我不要考虑完全预防某个bug，而是将目标设为——预防我们已经知道有一定可能性产生的Bug。这意味着我们可以通过我们各种发现bug的活动来促进将来的bug预防。当某个bug被发现时，我们就有了一个很好的机会来阻止类似问题的发生。
    前提：记录bug
    前提条件是持续跟踪发现的bug并正确地记录它们，离开了这个前提条件将不能将bug发现作为一个工具来预防bug。不论你使用bug跟踪系统,还是只手写了一个报告总结测试的结果，重要的是保存这些数据以便用于后来的分析。
    在分析bug时，bug记录的问题值得注意。bug的定义越广泛，bug分析的数据越有用。报告bug的测试人员应该明白这一点，并不限于狭义上的bug。可能的话，测试人员应该运用他们的经验对bug产生的原因做最初的假设。我们将稍后在阐述分析过程时讨论这个问题。
    和记录bug同样重要的是bug分析的第一步。仅仅跟踪过去的bug不能预防bug的发生，因为许多不同的bug可能来源于同一个核心问题。不同于信息收集，适当地分析bug的原因对bug预防非常有用。
    3．缺陷分析
    目标
    在上一节，我们说明了bug分析的理由。如上所述，最终目标是预防bug
    而不是修正它们。然而，我们可以定义一个重要的子目标，这就使不断提高整个开发团队（包括QC组）的技能和实践经验。当然，这两个目标是息息相关的。离开了不断的知识累积，也不能实现bug预防。不过，我觉得有必要提及这个子目标以强调持续性的过程。bug预防并不是一个不切实际的目标。但是，你不能期望它在一夜之间发生。你应该为开发小组提供教育和知识，以使他们逐渐改善他们的工作。
    策略
    本次讨论的焦点——bug预防策略非常简单和容易实现。秘诀就是使用在大多数开发环境中已经存在的过程元素。我们不会介绍任何新的花费昂贵的活动，也不会引入一些新的角色到开发过程中。
    我们的策略是发现bug，找出bug的根源，然后寻找一个方法来预防类似的bug在将来出现。因为QC过程已经用于在目前的产品中发现bug，因此该策略的大部分工作实际上已经执行，大多数开发过程缺少的正是分析在QC过程中发现的bug。正如你将看到，尽管策略的这一部分并不需要昂贵的花费，但是却带来了极大的额外价值。
    分析过程
    (1) Bug发现和初步分析
    如前所述，bug分析的第一步是发现bug。然而，发现bug的QC工程师（注：测试工程师）不应该满足于记录bug的表面症状。QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时，不应该将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。熟悉了产品的代码，QC工程师就可能推测出bug的根本原因。
    我要强调是下面这个短语的本质：bug的根本原因？bug的根本原因并不是产生这bug的源代码所在，尽管这些信息可能和分析过程关系密切。但是，发现bug的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。
    让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的应用程序需要同步地访问某个数据结构。被指派测试这个产品的QC工程师发现在某种情景下，应用程序尽管没有Crash，但是会停止响应。正常的QC过程是，这个bug被记录在bug跟踪系统中，并描述了测试情景和停止响应的实际结果。然而，如果这个QA工程师熟悉源代码，就可以进行bug产生原因的初步分析。例如，这个QC工程师可能断定这个bug产生的原因是之前的线程没有释放mutex，从而造成了冲突。这些分析可以记录在bug的详细说明中，作为bug分析的一个基础。
    (2) Bug修订和进一步分析
    一如既往，发现一个bug之后，开发人员应该负责处理它。但是，如果bug的发现过程包含了bug根本原因的初步分析，那么关于如何解决这个bug，开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的，但是它可能为开发人员提供了更多的观点。
    除了修正缺陷以及记录实现的具体步骤，开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。
    在线程同步的例子中，开发人员不应该仅仅记录增加了一个调用来释放mutex（注：Mutal Exclusion = 互斥锁，保证了共享数据不会同时被多个线程访问，只向一个线程授予对共享资源的独占访问权）。反之，开发人员应该找出没有释放mutex的原因。假设分析的原因是：因为需要同步的方法超过一个的返回点，因此开发人员在某些控制路径上忘记清理代码。
    这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法，我们现在有了可以解决许多情况的经验，有些情况甚至并不涉及到线程同步和释放mutex。但是，分析过程并没有结束，我们需要进一步的分析来将收集的所有数据转换为实践，从而帮助在将来避免类似bug的发生。
    (3) bug预防分析
    分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师，还涉及到不直接负责代码编写的资深开发人员。
    这一阶段的成果是一些有用的实践经验，开发人员可以通过这些实践预防bug而不是修正bug。这些实践不应该是某个具体问题的解决方案。在我们线程同步的例子中，可能得到这样一个实践：是否有审计范围机制来获取和释放资源？这种实践 （不一定适合所有编程语言）可以指导开发人员用一个类（class）封装资源, 这样构造(constructor)函数容易分配和而与析构(destructor) 函数释放资源。如果遵守这样的约定, 当程序结束这方法时，不管控制路径是怎样的，资源（上述例子中获得的mutex）总能被释放。
    Bug预防分析是整个bug分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体问题的投入将很容易被收回。
    非常重要的是我们前面所举的例子是一个随机性的bug。开发人员由于疏忽而忘记了释放资源。在代码实现时，这样的bug是随机产生的，但是类似bug产生的几率却非常高。所以，尽管这一类bug是随机的，但仍然可以被预见并防止发生。
    (4) 发布经验
    分析得出的实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库。这将使得新的知识在组织内流动并被相关的开发人员所学习。
    如果不将分析结果传达给组织内相关的其他人员，那么分析的目的就没有达到。避免下一个bug出现的唯一办法就是让开发人员知道如何避免它，并鼓励他们这么做。
    Bug分析实例
    让我们研究另外一个例子，以便更好地理解bug分析的益处。在这个事例中，QC工程师进行了如下的操作：当输入一个长字符串到应用程序时造成其崩溃(crash)。这一结论本身就需要一定程度的分析，但这个QC工程师并不满足于这样的分析，进一步研究了相关的代码，发现crash的原因是输入字符串时的处理有问题。其中一个步骤是将输入的字符缓存在一个固定大小的数组中，而这个数组有时候显得太小了。
    和线程同步的例子一样，QC工程师的初步分析带来了很大的价值，开发可以更容易的发现和修正这个bug。此外，记录缺陷的真正原因而不是表象，将帮助其他人避免类似的bug。
    接着，开发人员开始修正这个bug。当修正的时候，她不仅记录了解决措施，并说明了导致缺陷产生的原因。在这个例子中，造成bug的原因是在操作未经处理的C/C++缓冲区时，没有经常检验缓冲区的大小是否不够。然而，这个结论甚至可以被进一步总结为更广泛应用的经验以便帮助开发人员在以后避免类似的缺陷发生。所以，在分析的最后阶段，开发人员在组内更资深的开发人员的帮助下，得到了下面的实践经验：避免使用未经处理的C/C++缓冲区，尽量使用安全的collections和strings，如标准模版数据库中提供的可用collections和strings。这样就完全可以避免前面发现的这个bug。
    益处
    Bug分析带来了很多的好处。第一个好处就是帮助产生错误的开发人员总结经验，并使他在将来避免类似的错误。有时，只修正一个具体的bug而不去分析它产生的原因并不会帮助在日后得到提高。在这种情况下，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。
    更广泛的好处是使得其他开发人员从同事的错误中吸取教训。分析总结的实践经验可以预防bug的产生，这样的知识在组织内的成员间共享。某个开发人员产生的bug可以帮助组织内的其他人避免类似的bug出现。
    从更一般的角度来看，发布最佳实践（如bug分析总结的实践）促进了组织内成员的学习和自我提高。这样看来，Bug分析的价值还不仅仅是缺陷的预防。
    另一个好处是通过从更广的角度上记录bug，组织内的其他QC工程师将知道如何发现类似的错误。除了分享组织内的测试知识和经验，bug分析过程可以促进开发更好的测试技术和工具，从而帮助发现类似的bug。所以，就算缺陷没有被完全预防，也能更容易被发现。
    作为上面所有好处的结果，QC在一轮测试中将有更多的时间来测试更复杂的情景并发现更“狡猾的”bug。如果类似的bug都已经被预防而不容易产生，而且QC都有更好的技术来发现类似的bug，就有了更充裕的时间来进行更高级的测试。当然，组织所生产的产品的质量也将得到提高。
    最后，我想强调的是bug分析不仅收集了执行中的问题，而且从这些问题中总结了实践经验。举例来说，导致一个bug产生的原因可能是需求不够清楚。这样，通过bug分析得到的经验提供了一种方法来预防需求不清楚。这个经验可能不会对组织中的开发人员产生效果。所以尽管QC工程师开始验证开发人员的实现结果，但是还需要改善开发流程，如需求收集、设计流程等。
    4．总结
    真正的质量是生产没有bug的产品。任何其他目标都使组织内的成员从思想上接受软件缺陷是正常工作流的一部分。所以，第一步就是防止相同的bug再次发生。我们可以很轻易地执行这个目标。我们可以通过某个开发人员产生的一个bug提高整个组织的实践经验。
    通过深入产品分析一个bug，我们可以明白这个bug的机制：为什么会产生？如何去预防它？下一次我们如何更容易地发现它？只要花一点时间去理解我们的bug，而不是仅仅是尽快修正它，我们就可以从中得到经验。这样，因为一个缺陷所浪费的时间也可以转化为投入：确保类似的错误永远不会再发生。


    查看(20) 评论(0)

  • RUP

    2008-9-01

    RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者， 它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。 RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。

    一、六大经验

          1、迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程都可以执行版本结束，可以鼓舞开发人员。

          2、管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。

          3、基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

          4、可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

          5、验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

          6、控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。


    二、统一软件开发过程RUP的二维开发模型

          RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图1：


    三、统一软件开发过程RUP核心概念

          RUP中定义了一些核心概念，如下图：

          角色：描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。
          活动：是一个有明确目的的独立工作单元。
          工件：是活动生成、创建或修改的一段信息。

    四、统一软件开发过程RUP裁剪

          RUP是一个通用的过程模板，包含了很多开发指南、制品、开发过程所涉及到的角色说明，由于它非常庞大所以对具体的开发机构和项目，用RUP时还要做裁剪，也就是要对RUP进行配置。RUP就像一个元过程，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。RUP裁剪可以分为以下几步：

    1) 确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以取舍。

    2) 确定每个工作流需要哪些制品。

    3) 确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。

    4) 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容。

    5) 规划工作流内部结构。工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。

    五、开发过程中的各个阶段和里程碑

    　　RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

    1． 初始阶段

    　　初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。 初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。

    2． 细化阶段

    　　细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。 细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

    3． 构造阶段

    　　在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。 构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

    4． 交付阶段

    　　交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。 在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

    六、统一软件开发过程RUP的核心工作流(Core Workflows)

    　　RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

    1． 商业建模(Business Modeling)

          商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

    2． 需求(Requirements)

    　　需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

    3． 分析和设计(Analysis & Design)

    　　分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。 设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

    4． 实现(Implementation)

    　　实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

    5． 测试(Test)

    测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确　　认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

    6． 部署(Deployment)

    　　部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

    7． 配置和变更管理(Configuration & Change Management)

    　　配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

    8． 项目管理(Project Management)

    　　软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

    9． 环境(Environment)

    　　环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

    七、RUP的迭代开发模式

    　　RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。 传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期（见图2）。这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。

    　　一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目（见图3）。



    图3 RUP的迭代模型

    　　与传统的瀑布模型相比较，迭代过程具有以下优点：

    　　降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

    　　降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

    　　加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

    　　由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

    八、统一软件开发过程RUP的十大要素

    1. 开发前景
    2. 达成计划
    3. 标识和减小风险
    4. 分配和跟踪任务。。
    5. 检查商业理由
    6. 设计组件构架
    7. 对产品进行增量式的构建和测试
    8. 验证和评价结果
    9. 管理和控制变化
    10. 提供用户支持

    让我们逐一的审视这些要素，看一看它们什么地方适合ＲＵＰ，找出它们能够成为十大要素的理由。

    1. 开发一个前景
          有一个清晰的前景是开发一个满足涉众真正需求的产品的关键。 前景抓住了ＲＵＰ需求流程的要点：分析问题，理解涉众需求，定义系统，当需求变化时管理需求。 前景给更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样，它是软件项目的一个清晰的、通常是高层的视图，能被过程中任何决策者或者实施者借用。它捕获了非常高层的需求和设计约束，让前景的读者能理解将要开发的系统。它还提供了项目审批流程的输入，因此就与商业理由密切相关。最后，由于前景构成了“项目是什么？”和“为什么要进行这个项目？”，所以可以把前景作为验证将来决策的方式之一。 对前景的陈述应该能回答以下问题，需要的话这些问题还可以分成更小、更详细的问题： ? 关键术语是什么？（词汇表） ? 我们尝试解决的问题是什么？（问题陈述） ? 涉众是谁？用户是谁？他们各自的需求是什么？ ? 产品的特性是什么？ ? 功能性需求是什么？（Ｕｓｅ Ｃａｓｅｓ） ? 非功能性需求是什么？ ? 设计约束是什么？

    2. 达成计划
            “产品的质量只会和产品的计划一样好。” (2) 在ＲＵＰ中，软件开发计划（ＳＤＰ）综合了管理项目所需的各种信息，也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。 ＳＤＰ定义了项目时间表（包括项目计划和迭代计划）和资源需求（资源和工具），可以根据项目进度表来跟踪项目进展。同时也指导了其他过程内容（原文：process components）的计划：项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划以及产品验收计划。

          在较简单的项目中，对这些计划的陈述可能只有一两句话。比如，配置管理计划可以简单的这样陈述：每天结束时，项目目录的内容将会被压缩成ZIP包，拷贝到一个ZIP磁盘中，加上日期和版本标签，放到中央档案柜中。 软件开发计划的格式远远没有计划活动本身以及驱动这些活动的思想重要。正如Dwight D.Eisenhower所说：“plan什么也不是，planning才是一切。” “达成计划”—和列表中第3、4、5、8条一起—抓住了RUP中项目管理流程的要点。项目管理流程包括以下活动：构思项目、评估项目规模和风险、监测与控制项目、计划和评估每个迭代和阶段。

    3. 标识和减小风险
          RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。

    4. 分配和跟踪任务
          有一点在任何项目中都是重要的，即连续的分析来源于正在进行的活动和进化的产品的客观数据。在RUP中，定期的项目状态评估提供了讲述、交流和解决管理问题、技术问题以及项目风险的机制。团队一旦发现了这些障碍物（篱笆），他们就把所有这些问题都指定一个负责人，并指定解决日期。进度应该定期跟踪，如有必要，更新应该被发布。（原文：updates should be issued as necessary。） 这些项目“快照”突出了需要引起管理注意的问题。随着时间的变化/虽然周期可能会变化（原文：While the period may vary。），定期的评估使经理能捕获项目的历史，并且消除任何限制进度的障碍或瓶颈。

    5. 检查商业理由
          商业理由从商业的角度提供了必要的信息，以决定一个项目是否值得投资。商业理由还可以帮助开发一个实现项目前景所需的经济计划。它提供了进行项目的理由，并建立经济约束。当项目继续时，分析人员用商业理由来正确的估算投资回报率(ROI，即return on investment)。 商业理由应该给项目创建一个简短但是引人注目的理由，而不是深入研究问题的细节，以使所有项目成员容易理解和记住它。在关键里程碑处，经理应该回顾商业理由，计算实际的花费、预计的回报，决定项目是否继续进行。

    6. 设计组件构架
          在RUP中，件系统的构架是指一个系统关键部件的组织或结构，部件之间通过接口交互，而部件是由一些更小的部件和接口组成的。即主要的部分是什么？他们又是怎样结合在一起的？ RUP提供了一种设计、开发、验证构架的很系统的方法。在分析和设计流程中包括以下步骤：定义候选构架、精化构架、分析行为（用例分析）、设计组件。 要陈述和讨论软件构架，你必须先创建一个构架表示方式，以便描述构架的重要方面。在RUP中，构架表示由软件构架文档捕获，它给构架提供了多个视图。每个视图都描述了某一组涉众所关心的正在进行的系统的某个方面。涉众有最终用户、设计人员、经理、系统工程师、系统管理员，等等。这个文档使系统构架师和其他项目组成员能就与构架相关的重大决策进行有效的交流。

    7. 对产品进行增量式的构建和测试
          在RUP中实现和测试流程的要点是在整个项目生命周期中增量的编码、构建、测试系统组件，在先启之后每个迭代结束时生成可执行版本。在精化阶段后期，已经有了一个可用于评估的构架原型；如有必 要，它可以包括一个用户界面原型。然后，在构建阶段的每次迭代中，组件不断的被集成到可执行、经过测试的版本中，不断地向最终产品进化。动态及时的配置管理和复审活动也是这个基本过程元素（原文：essential process element）的关键。

    8. 验证和评价结果
          顾名思义，RUP的迭代评估捕获了迭代的结果。评估决定了迭代满足评价标准的程度，还包括学到的教训和实施的过程改进。 根据项目的规模和风险以及迭代的特点，评估可以是对演示及其结果的一条简单的纪录，也可能是一个完整的、正式的测试复审记录。 这儿的关键是既关注过程问题又关注产品问题。越早发现问题，就越没有问题。（原文：The sooner you fall behind, the more time you will have to catch up.）

    9. 管理和控制变化
          RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模，并且贯穿整个生命周期。其目的是考虑所有的涉众需求，尽可能的满足，同时仍能及时的交付合格的产品。 用户拿到产品的第一个原型后（往往在这之前就会要求变更），他们会要求变更。重要的是，变更的提出和管理过程始终保持一致。 在RUP中，变更请求通常用于记录和跟踪缺陷和增强功能的要求，或者对产品提出的任何其他类型的变更请求。变更请求提供了相应的手段来评估一个变更的潜在影响，同时记录就这些变更所作出的决策。他们也帮助确保所有的项目组成员都能理解变更的潜在影响。

    10. 提供用户支持
          在RUP中，部署流程的要点是包装和交付产品，同时交付有助于最终用户学习、使用和维护产品的任何必要的材料。 项目组至少要给用户提供一个用户指南（也许是通过联机帮助的方式提供），可能还有一个安装指南和版本发布说明。 根据产品的复杂度，用户也许还需要相应的培训材料。最后，通过一个材料清单（BOM表，即Bill of Materials）清楚地记录应该和产品一起交付哪些材料。 关于需求 有人看了我的要素清单后，可能会非常不同意我的选择。例如，他会问，需求在哪儿呢？他们不重要吗？我会告诉他我为什么没有把它们包括进来。有时，我会问一个项目组（特别是内部项目的项目组）：“你们的需求是什么？”，而得到的回答却是：“我们的确没有什么需求。” 刚开始我对此非常惊讶（我有军方的宇航开发背景）。他们怎么会没有需求呢？当我进一步询问时，我发现，对他们来说，需求意味着一套外部提出的强制性的陈述，要求他们必须怎么样，否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时，产品需求从头到尾都在演化。 因此，我接着问他们另外一个问题：“好的，那么你们的产品的前景是什么呢？”。这时他们的眼睛亮了起来。然后，我们非常顺利的就第一个要素（“开发一个前景”）中列出的问题进行了沟通，需求也自然而然的流动着（原文：and the requirements just flow naturally.）。 也许只有对于按照有明确需求的合同工作的项目组，在要素列表中加入“满足需求”才是有用的。请记住，我的清单仅仅意味着进行进一步讨论的一个起点。

    九、总结

    　　RUP具有很多长处：提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。但同时它也存在一些不足： RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；此外，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美，在实际的应用中可以根据需要对其进行改进并可以用OPEN和OOSP等其他软件过程的相关内容对RUP进行补充和完善。

    查看(8) 评论(0)

  • QA 与 QC的性质和区别(转载)

    2008-9-01

    QA 与 QC的性质和区别（zz）
    1. QA、QC的定义
    QA英文全称：Quality Assurance ，中文含义：质量保证；QC英文全称：Quality Control，中文含义：质量控制。
    按照ISO9000:2000，QA的定义是“质量管理的一部分，致力于提供质量要求会得到满足的信任”，QC的定义则是“质量管理的一部分，致力于满足质量要求”。简言之，QC是对人事、对物，直接致力于满足质量要求：QA则是对人、对过程，致力于使管理者、顾客和其他相关方相信有能力满足质量要求。
    在软件/信息化方面的一些标准中，QA的定义包括：“质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作。”(GB/T 12504-1990计算机软件质量保证计划规范)；“为使某项目或产品符合已建立的技术需求提供足够的置信度，而必须采取的有计划和有系统的全部动作的模式。”(GB/T11457—1995软件工程术语)。在这两个标准中都没有直接关于QC的定义。
    按照不同的目的、从不同的角度对同一个术语的定义往往存在差异，例如GB/T 12504-1990、GB/T11457—1995分别对QA的定义就存在差异，按照GB/T 12504-1990的QA定义涵盖的范围较宽，包含了QC的内容。
    2. QA与QC的侧重点比较
    一个软件组织或项目团队中存在QA和QC两类角色，这两类角色工作的侧重点比较如下：
    角色         QC             QA
    工作对象     产品           过程
    工作方式     事后反应       事先预防
    功能类型     生产功能       人员功能
    缺陷应对     发现缺陷       预防缺陷
    工作风格     被动务实       主动务虚

    QA与QC的其他区别还包括：
    从在组织中的地位来看，QA，具备一定资质的人才往往成为组织的高级人才，他需要全面掌握组织的过程定义，熟悉所参与项目所用的工程技术；QC则既包括软件测试设计员等高级人才，也包括一般的测试员等中、初级人才。国外有软件企业要求QA应具备两年以上的软件开发经验，半年以上的分析员、设计员经验；不仅要接受QA方面的培训，还要接受履行项目经理职责方面的培训。
    从在组织中的权限方面看，项目组中，QA独立于项目经理，不由项目经理进行绩效考核；QC受项目经理领导，通常在项目运行周期内QC的绩效大部分由项目经理考核决定。
    从组织活动上看，QA活动贯穿项目运行的全过程；QC活动一般设置在项目运行的特定阶段，在不同的控制点可能由不同的角色完成。
    从工作职责方面看，对称职的QA，跟踪和报告项目运行中的发现(Findings)只是其工作职责的基础部分，更富有价值的工作包括为项目组提供过程支持，例如为项目经理提供以往类似项目的案例和参考数据，为项目组成员介绍和解释适用的过程定义文件等；QC的活动则主要是发现和报告产品的缺陷。
    3. QA的工作内容
    国际标准、国家标准都是通用的，软件组织是具体的、鲜活的。不同组织中QA的工作职责和内容会有共同性，也会有特异性，可以分层次考虑QA的工作内容和特点：
    3.1 过程遵从性
    保证过程遵从性是QA的根本职责，即保证项目组按组织规定的过程运行。通常各类组织，不仅是软件组织中的QA都致力于保证过程遵从性，以证实能以稳定的质量提供产品和服务，得到具备满足质量要求能力的信任。
    3.2 计划符合性
    保证项目的计划符合性首先是项目经理的责任，不是QA的根本职责。有些组织中QA不必认真关注计划符合性；但是，项目的规模、工作量、进度、缺陷等方面的计划符合性是高层管理者的关注重点，QA作为高层管理者的耳目有必要跟踪和报告计划符合性。在许多软件组织中跟踪和报告计划符合性是QA的常规工作内容。
    3.3 工件正确性
    工作产品(Work Product)简称工件，指项目运行中产生的各种文档、代码、程序等。在多数软件组织中，QA通常不直接跟踪和报告工件正确性。其根本原因是这样做将会导致QA在项目工作中陷得太深，不利于保持QA的独立性和客观性。其他原因还包括QA的能力、时间资源都可能不足以支持其去跟踪和报告工件正确性。
    4. 基于实际情况理解和处理QA的工作内容
    怎样定义QA的具体职责范围是各组织自己的事，质量管理标准和过程改进模型都只会要求某个职责要有机构、角色履行，不会要求组织一定要设立某个机构、某种角色，或某种角色必须是怎样的职责。即使在同一个组织中，根据不同的应用目的也可以作不同的处理。
    例如，在一个通过了SW-CMM三级的软件组织， QA计划的最小范围只包括支持、跟踪和报告项目组的活动，当项目工件中存在外包部件时要跟踪和报告外包部件开发方的相关活动，当项目与特定顾客的需求、部署和实施有关时要负责与该顾客就质量管理问题，包括产品和服务缺陷等问题进行沟通。组织内部使用的QA与需求管理计划、配置管理计划、工件评审计划、沟通计划、风险管理计划、培训计划、测试计划、开发计划等是分离的；但对大型的企业信息化建设项目，如果顾客需要，提交给顾客以展示本组织质量保证能力的QA计划需要包括包括QA、QC的多方面计划，例如评审计划和测试计划，比较接近GB/T 12504-1990中的QA活动范围。

    查看(42) 评论(0)

  • 如何揣摩他人心理

    2008-6-30

    察言观色是一切人情往来中操纵自如的基本技术。不会察言观色，等于不知风向便去转动舵柄，世事国通无从谈起，弄不好还会在小风浪中翻了船。


    　　　　直觉虽然敏感却容易受人蒙蔽，懂得如何推理和判断才是察言观色所追求的顶级技艺。言辞能透露一个人的品格，表情眼神能让我们窥测他人内心，衣着、坐姿、手势也会在毫无知觉之中出卖它们的主人。

    　　　　言谈能告诉你一个人的地位、性格、品质及至流露内心情绪，因此善听弦外之音是“察言”的关键所在。

    　　　　如果说观色犹如察看天气，那么看一个的脸色应如“看云识天气”般，有很深的学问，因为不是所有人所有时间和场合都能喜怒形于色，相反是“笑在脸上，哭在心里”。

    　　　　“眼色”是“脸色”中最应关注的重点。它最能不由自主地告诉我们真相，人的坐姿和服装同样有助于我们现人于微，进而识别他人整体，对其内心意图洞若观火。


    1．能辨风向才会使好舵


    　　　　一个举人经过三科，又参加候选，得了一个山东某县县令的职位。第一次去拜见上司，想不出该说什么话。沉默了～会，忽然问道：“大人尊姓？”这位上司很吃惊，勉强说了姓某。县令低头想了很久，说：“大人的姓，百家姓中所没有。”上司更加惊异，说：“我是旗人？”贵县不知道吗？”县令又站起来，说：“大人在哪一旗，”上司说：“正红旗。”县令说：“正黄旗最好，大人怎么不在正黄旗呢？”上司勃然大怒，问：“贵县是哪一省的人？”县令说：“广西。”上司说：“广东最好，你为什么不在广东？”县令吃了一惊，这才发现上司满脸怒气，赶快走了出去。第二天，上司令他回去，任学校教职。究其原因，便是不会察言观色。

    　　　　我们如能真的在交际中察言观色，随机应变，也是一种本领。例如在访问中我们常常会遇见一些意想不到的情况，访问者应全神贯注地与主人交谈，与此同时，也应对～些意料之外的信息敏锐地感知，恰当地处理。

    　　　　主人一面跟你说话，一面眼往别处看，同时有人在小声讲话，这表明刚才你的来访打断了什么重要的事，主人心里惦记着这件事，虽然他在接待你，却是心不在焉。这时你最明智的方法是打住，丢下一个最重要的请求告辞：“您一定很忙。我就不打扰了，过～两天我再来听回音吧！”你走了，主人心里对你既有感激，也有内疚：“因为自己的事，没好好接待人家。”这样，他会努力完成你的托付，以此来补报。

    　　　　在交谈过程中突然响起门铃、电话铃，这时你应该主动中止交谈，请主人接待来人，接听电话，不能听而不闻滔滔不绝地说下去，使主人左右为难。

    　　　　当你再次访问希望听到所托之事已经办妥的好消息时，却发现主人受托之后尽管费心不少但并没圆满完成甚至进度很慢。这时难免发急，可是你应该将到了嘴边的催促化为感谢，充分肯定主人为你作的努力，然后再告之以目前的处境，以求得理解和同情。这时，主人就会意识到虽然费时费心却还没有真正解决问题，产生了好人做到底的决心，进一步为你奔走。


    人际交往中，对他人的言语、表情、手势、动作以及看似不经意的行为有较为敏锐细致的观察，是掌握对方意图的先决条件，测得风问才能使舵。例如和上司打交道时，对其眼手的观察，能够让我们洞悉其内心：


    　　　　①上司说话时不抬头，不看人。这是一种不良的征兆——轻视下属，认为此人无能。

    　　　　②上司从上往下看人。这是一种优越感的表现——好支配人、高傲自负。

    　　　　③上司久久地盯住下属看——他在等待更多的信息，他对下级的印象尚不完整。

    　　　　④上司友好和坦率地看着下属，或有时对下属眨眨眼——下属很有能力、讨他喜欢，甚至错误也可以得到他的原谅。

    　　　　⑤上司的目光锐利，表情不变，似利剑要把下属着穿。这是一种权力、冷漠无情和优越感的显示，同时也在向下属示意：你别想欺骗我，我能看透你的心思。

    　　　　③上司偶尔往上扫一眼，与下属的目光相遇后又如下看，如果多次这样做，可以肯定上司对这位下属还吃不准。

    　　　　①上司向室内凝视着，不时微微点头。这是非常糟糕的信号，它表示上司要下属完全服从他，不管下属们说什么，想什么，他一概不理会。

    　　　　③双手合掌，从上往下压，身体起平衡作用——表示和缓。平静。

    　　　　②双手插腰，肘弯向外撑，这是好发命令者的一种传统人体语言，往往是在碰到具体的权力问题时所做的姿势。

    　　　　①上司坐在椅子上，将身体往后靠，双手放到脑后，双肘向外撑开，这固然说明他此时很轻松，但很可能也是自负的意思。

    　　　　③食指伸出指向对方——一种赤裸裸的优越感和好斗心。


    ③双手放在身后互握，也是一种优越感的表现。


    　　　　③上司拍拍下属的肩膀——对下属的承认和赏识，但只有从侧面拍才表示真正承认和赏识。如果从正面或上面拍，则表示小看下属或显示权力。

    　　　　＠手指并拢，双手构成金字塔形状，指尖对着前方——一定要驳回对方的示意。

    　　　　①把手捏成拳头——不仅要吓唬别人，也表示要维护自己的观点，倘用拳头敲桌子，那干脆就是企图不让人说话。

    　　　　当然，要做好社交中的“天气预报”，需要更为详尽的“气象”知识，在接下来的小节中，我们将分门别类介绍给读者。

    　　　　2．善于捕捉“弦外之音”

    　　　　有个穷人患病，病情渐渐沉重，医生说他没有希望了。病人祷告众神，说如果能病好下床的话，一定设百牛祭，送礼还愿。他妻子正站在旁边，听他这么说，便问道：“你从哪儿弄这笔钱来还愿呀？”他回答说：“你以为神让我病好下床，是为了向我要这些东西吗？”

    　　　　这故事是说，实际上不想做的事情，人们倒最容易答应下来，人有时候心口不一。由此看来，察言是很有学问的技巧。人内心的思想，有时会不知不觉在口头上流露出来，因此，与别人交谈时，只要我们留心，就可以从谈话中深知别人的内心世界。

    　　　　①由话题知心理。

    　　　　人们常常将情绪从一个话题里不自觉地呈现出来。话题的种类是形形色色的，如果要明白对方的性格、气质、想法，最容易着手的步骤，就是要观察话题与说话者本身的相关状况，从这里能获得很多的信息。

    　　　　与中年妇女交谈时，她们的话题多是她们自己，因为她们觉得自己才是她们最大的关心对象。有时也谈论文夫或孩子，那是她们把丈夫或孩子看成了自己的化身，谈论他们也等于在谈论自己。对于这样的中年妇女，你要作为一个倾听者的形象出现，承认她们是贤惠的妻子、伟大的母亲。

    　　　　在年轻小伙子的世界里，他们最爱谈论的话题是车子。关于车子的杂志也跟音乐、足球杂志一样畅销。小伙子的话题几乎都涉及与车子的品牌、行程距离、速度等有关的话题，虽然，他们中的大多数人都暂时买不起车。其实，他们那么热衷于车的话题，无非在表示自己将来有能力购车，或者是自己对这些懂得很多，这也是一种时髦的话题罢了，无非是显示自己。因此，你要聚精会神地听他们侃车，最好不要摆出讨厌或不耐烦的脸孔，你的耐心就可以满足他们的虚荣心。

    　　　　②措词的习惯流露出的“秘密”。

    语言表明出身，语言除了社会的、阶层的或地理上的差别外，还有因个人的水平而出现差别的心理性的措辞。人的种种曲折的深层心理就会不知不觉地反映在自我表现的手段——措辞上。即使同自己想表现的自我形象无关，通过分析措辞常常就可以大体上看出这个人的真实形象，在这种意义上，正是本人没意识到的措辞的特征比词语的内容远为雄辩地告诉我们其人自身。


    　　　　使用第一人称单数的人，独立心和自主性强，常用复数的人多见于缺乏个性，埋没于集体中，随声附和型的人。

    　　　　人们总是认为是在用自己的话说话，写文章。实际上无意中在借用别人的话，有自我扩大欲，反过来探寻这一点，就能窥见其人的内心深处。例如，对说话者是使用难懂的词和外语的人多会感到困惑，其实，这种人多是将词语作为掩饰自己内心弱点的盾牌。择业时，充分显示自己的才能是必要的，但若过分矫饰，反而画蛇添足，让别人如坠云雾的效果是最不利的。这种情形常常不过是反证了对自己的智能的自卑意识，将词语作为盾牌，掩饰自己的自卑感。《围城》中的张先生在方鸿渐面前大肆卖弄自己的洋文，以显示自己博学，实际上只反映出其知识的贫乏。

    　　　　③说话方式才能反映真实想法。

    　　　　一般说来，一个人的感情或意见，都在说话方式里表现得清清楚楚，只要仔细揣摩，即使是弦外之音也能从说话的帘幕下逐渐透露出来。

    　　　　（l）说话快慢是着破深层心理的重要关键。

    　　　　如果对于某人心怀不满，或者持有敌意态度时，许多人的说话速度都变得迟缓，而且稍有木油的感觉。如果有愧于心或者说谎时，说话的速度自然就会决起来。

    　　　　假如说有一个男人每天下班都按时回家，而这一天他下班后却留在办公室与同事打扑克，回到家时，他就马上跟老婆说他加班了，而且还要诅咒现在为什么有这么多的活儿干不完等等之类的话。他的说话语调也一定会比平常快，这样，他可以解除内心潜在的不安。

    　　　　遇到男人这样时，做老婆的一定要慎重，什么事一旦有了开头，就会有下次，不可掉以轻心。

    　　　　（2）从音调的抑扬顿挫中看破对方心理。

    　　　　上述的那位“加班”的男人，当他回到家时，他说话的语调不仅快，而且慷慨激昂，好象今天的“加班”的确让他很反感——他是很不愿意“加班”的。

    　　　　当两个人意见相左时，一个人提高说话的音调，即表示他想压倒对方。

    　　　　对于那种心怀企图的人，他说话时就一定会有意地抑扬顿挫，制造一种与众不同的感觉，有一种吸引别人注意力的欲望，自我显示欲隐隐约约地透露出来了。

    （3）由听话方式看破对方心理。


    　　　　构成谈话的前提包括了两种不同立场的存在者，即说话者与听话者。我们可以根据对方对自己说话后的各种反应，来突破对方的深层心理。

    　　　　如果一个人很认真地听话，他大致会正襟危坐，视线也一直瞪着对方。反之，他的视线必然会散乱，身体也可能在倾斜或乱动，这是他心情厌烦的表现。

    　　　　有些人仔细倾听对方的每一句话，等到讲述者快说完时，他也会透露自己的心声，由此看来，这位倾听者完全依靠坚强的耐心J再配合一股好奇心，才能最终突破讲话者的秘密。

    　　　　如果你想套知某人某方面的消息，你就会和他从一个平常的话题切入，然后认真倾听、提问、倾听……一步步达到自己的目的，对方在高兴之余，也忘了提防，相反还会认为你是一个很好的倾听者，善解人意呢。

    　　　　3．脸上的表情，天上的云彩

    　　　　观色是指观察人的脸色，获悉对方的情绪。这与老猎人靠看云彩的变化推断阴晴雨雪，是一个道理。

    　　　　丈夫小A和妻子小B刚结婚时，感情很好，常常形影不离。可是，随着生活的日渐平淡，彼此都熟悉了婚后的生活，再也没什么新鲜感了，却常常为柴米油盐酱醋茶的琐事而吵架了。

    　　　　起初小A和小B一有不满，就互相争吵，各不相让，但吵过后，两人坚持不了几个小时又和好了。可是，随着吵架次数的增加，这好象成了家常便饭了，小A和小B谁也不愿再理睬对方，他们经历了一个冷漠的阶段。

    　　　　但这也不是办法，小A和小B还要面对家人和朋友，为了不让别人看出来，他们逐渐过渡到有别人在场的时候，彼此显得关系还不错、很恩爱，而一旦只有他们独处时，家里则静悄悄的，互不打扰。渐渐地，没人在的时候他们也开始说话了，但这并不是尽弃前嫌，只是有时候有一些不得不说的话而已。随着彼此间的不调和发展到极端时，不快乐的表情反而逐渐消失，他们的脸上反而呈现出一种微笑，态度上也显得卑屈又亲切。

    　　　　怪不得一位经常办理离婚案的法官说，当夫妇间任何一方表现出这种态度时，就表明夫妻关系已到了不可调和的地步了。

    　　　　人类的心理活动非常微妙，但这种微妙常会从表情里流露出来。倘若遇到高兴的事情，脸颊的肌肉会松驰，一旦遇到悲哀的状况，也自然会泪流满面。不过，也有些人不愿意将这些内心活动让别人看出来，单从表面上看，就会让人判断失误。

    　　　　比如，在一次洽谈会上，对方笑嘻嘻地完全是一副满意的表情，使人很安心地觉得交涉成功了，“我明白了，你说得很有道理，这次我一定考虑考虑。”可是最后的结果却是以失败而告终。

    　　　　由此看来，我们不能只简单地从表情上判断对方的真实情感。在以表情突破对方心理时要注意以下两方面：

    　　　　①没表情不等于没感情。

    　　　　生活中，我们有时会看到有些人不管别人说了什么，做了什么，他都一副无表情的面孔。其实，没表情不等于没感情，因为内心的活动，倘若不呈现在脸部的筋肉上，那就显得很不自然，越是没有表情的时候，越可能使感情更为冲动。

    　　　　例如，有些职员不满主管的言行，只是敢怒不敢言，只好故意装出一副无表情的样子，显得毫不在乎。但是，其实他内心的不满很强烈，如果你这时仔细地观察他的面孔，会发现他的脸色不对劲。碰到这种人，最好不要直接指责他，或者当场让他难看。最好这样说：“如果你有什么不满，不妨说出来听听！”这样可以安抚部属正在竭力压抑着的感情。

    　　　　但是这种时候也不宜说话过多，避免正面交锋，而应另择时间，开诚布公地与下属交换意见，这样就可以圆满解决与下属的这种低潮关系，主管的好形象就树立起来了。

    　　　　毫无表情有两种情形，一种是极端的不关心，另一种是根本不看在眼内。

    　　　　例如，这里在谈话，有人就很茫然地看到这边来，表现不知如何是好的模样，这就是一种根本不看在眼内的表情，这有可能代表的是一种好意。尤其是女性，倘若太露骨地表现自己的好意，反而不妥，不如就显现出一种近乎漠不关心的表情来。

    　　　　③愤怒悲哀或憎恨至极点时也会微笑。

    　　　　这种情况眼光表情不同，通常人们说脸上在笑，心里在哭的正是这种类型。纵然满怀敌意，但表面上却要装出谈笑风生，行动也落落大方。

    　　　　人们之所以要这样做，是觉得如果将自己内心的欲望或想法毫无保留地表现出来，无异于违反社会的规则，甚至会引起众叛亲离的现象，或者成为大众指责的罪首，恐怕受到社会的制裁，不得已而为之。

    　　　　由此可见，观色常会产生误差。满天乌云不见得就会下雨，笑着的人未必就是高兴。很多时候，人们去苦水往肚里咽着，脸上却是一副甜甜的样子。反之，脸拉沉下来时，说不定心里在笑呢。


    4．透过“眼神”辨人心


    　　　　希腊神话里有这样一个故事：若被怪物三姐妹中的美杜莎看上一眼，立刻就会变成石头，说白了，这是将眼睛的威力神化了。

    　　　　从医学上来看，眼睛在人的五种感觉器官中是最敏锐的，大概占感觉领域的70％以上，因此，被称“五官之王”。孟子云：“存之人者，莫良于眸子，眸不能掩其恶。胸中正，则眸子降，胸中不正，则眸子眩。”从眼睛里流露出真心是理所当然的，“眼睛是心灵之窗”。

    　　　　深层心理中的欲望和感情，首先反映在视线上，视线的移动、方向、集中程度等都表达不同的心理状态，观察视线的变化，有助于人与人之间的交流。爬上窗台就不难看清屋中的情形，读懂人的眼色便可知晓人们内心状况。

    　　　　眼睛看人的方法由来已久。人的个性是一成不变的，无论其修养功夫如何深远。俗语说：江山易改，本性难移，看人的个性还是简单的，而值的表现则不然。性为内，情为外，性为体，情为用，性受外来的刺激，发而为情，刺激不同。情所表现最显著、最难掩的部分，不是语言，不是动作，也不是态度，而是眼睛，言语动作态度都可以用假装来掩盖，而眼睛是无法假装的。我们看眼睛，不重大小圆长，而重在眼神。

    　　　　你见他眼神沉静，便可明白他对于你着急的问题，早已成竹在胸，定操胜算。只要向他请示办法，表示焦虑，如果他不肯明白说，这是因为事关机密，不必要多问，只静待他的发落便是。

    　　　　如果你见他眼神散乱，便可明白他也是毫无办法，徒然着急是无用的，向他请示，也是无用的。你得平心静气，另想应付办法，不必再多问，这只会增加他六神无主的程度，这时是你显示本能的机会，快快自己去想办法吧！

    　　　　如果你见他眼神横射，仿佛有刺，便可明白他异常冷淡，如有请求，暂且不必向他陈说，应该从速借机退出，即使多逗留一会儿也是不适的，退而研究他对你冷淡的原因，再谋求恢复感情的途径。

    　　　　你见他眼神阴沉，应该明白这是凶狠的信号，你与他交涉，须得小心一点。他那一只毒辣的手，正放在他的背后伺机而出。如果你不是早有准备想和他见个高低，那么最好从速鸣金收兵。


    你见他眼神流动异于平时，便可明白他是胸怀诡计，想给你苦头尝尝。这时应步步为营，不要轻近，前后左右都可能是他安排的陷阱，一失足便跌翻在他的手里。不要过分相信他甜言蜜语，这是钩上的饵，是毒物外的糖衣，要格外小心。


    　　　　你见他眼神呆滞，唇皮泛白，便可明白他对于当前的问题惶恐万状，尽管口中说不要紧，他虽未绝望，也的确还在想办法，但却一点也想不出所以然来。你不必再多问，应该退去考虑应付办法，如果你已有办法，应该向他提出，并表示有几成把握。

    　　　　你见他眼神似在发火，便可明白他此刻是怒火中烧，意气极盛，如果不打算与他决裂，应该表示可以妥协，速谋转机。否则，再逼紧一步，势必引起正面的剧烈冲突了。

    　　　　你见他眼神恬静，面有笑意，你可明白他对于某事非常满意。你要讨他的欢喜，不妨多说几句恭维话，你要有所求，这也是个好机会，相信一定比平时更容易满足你的希望。

    　　　　你见他眼神四射，神不守舍，便可明白他对于你的话已经感到厌倦，再说下去必无效果，你如果不赶紧告～段落，或乘机告退，或者寻找新话题，谈谈他所愿听的事。

    　　　　你见他的眼神凝定，便可明白他认为你的话有一听的必要，应该照你预定的计划，婉转陈说，只要你的见解不差，你的办法可行，他必然是乐于接受的。

    　　　　要是你见他眼神下垂，连头都向下倾了，便可明白他是心有重忧，万分苦痛。你不要向他说得意事，那反而会加重他的苦痛，你也不要向他说苦痛事，因为同病相怜越发难忍，你只好说些安慰的话，并且从速告退，多说也是无趣的。

    　　　　如果他的眼神上扬，便可明白他是不屑听你的话，无论你的理由如何充分，你的说法如何巧妙，还是不会有高明的结果，不如奚然而止，退而求接近之道。

    　　　　总之，眼神有散有聚，有动有静，有流有凝，有阴沉，有呆滞，有下垂，有上扬，仔细参悟之后，必可发现人情毕露。

    　　　　5．用座位画一张“人心地图”

    　　　　在人与人之间的关系中，坐什么座位，怎样坐，都反映了人的深层心理。首先，坐什么位置，直接反映出社会、集团传统的上席下席或优势、劣势的意识，就是现在，拘泥于形式的聚会或老年人多的聚会上，谁坐什么位置就使主持者头痛，在会议参加者之间常常发生不必要的相互推让或争执。其次，是所有的人都有在自己身体的周围保持自己专用空间的心理，如果被侵犯就会不悦，并产生不安。这个空间称为“身体范围”。通常，人是互不侵犯这种范围的。

    　　　　不难看出，对一个人的坐的位置、坐姿进行标记、分析，简直就可以画出一张人心的“地形图”来。下面让我们具体看看。

    　　　　①座位的物理距离也表示着跟对方的心理距离。

    　　　　这种距离的大小，可以表示主观上想侵犯对方身体领域的程度，从而能判断出他的一些心理想法，知道他想干什么。例如：一对以身相许成卿卿我我的情侣，即使在很宽阔的沙发里，他们必然也会靠近对方的身边坐下，这当然并不是没有足够的空间，而是反映了他们如胶似膝的心态。像这种情况，如果是你身边的一对情侣，如果你不想让人烦，你就识趣点儿，给别人留一点空间，走开。

    　　　　又如在大学的教室里，如果有人想积极参与讨论，这些学生大多数会坐在教室前面的位置上，反之，有些学生不常来上课，占用上课的时间出去打工，他们一定会坐在后头的，对于本科目不感兴趣的人，也会选择坐在后面。

    　　　　②座位的方向意味深长

    　　　　座位的方向有两方面：一个是坐在对方的正对面或旁边，另一个是坐在背向房间的人口与里面的某处位置。

    　　　　坐在正对面或旁边，其表现的心理状态就不同，面对面坐着有一种距离感，这时，两人之间有一张桌子或什么东西之类的障碍物会感觉比较舒服。

    　　　　而坐在侧旁的时候，就没有如此的限制，大多数人采用亲密的距离并肩而坐，彼此朝着同一个方向，注视相同的对象，在这种情况下，很容易产生某种连带感。而面对面的坐姿，双方都处于可以观察对方的最佳位置上，很容易产生视线冲突，产生一种对峙的感觉。


    在男女关系方面也一样。中间放着一张桌子，两人面对面地坐着谈话，这也许是相当亲热的镜头了，不过，这种坐式说明他们彼此间的深度还不够，表现出他们在心理上存在着一种相互理解的意愿。反之，并肩而坐的两个人，在一般情况下，他们会比面对面而坐的男女少说些话，因为他们彼此早已相互了解，甚至在某种情况下早已以身相许也是很可能的事。


    　　　　所以，我们可以通过他们坐的方向来推测别人的心理活动和与之相关的信息，这样你若想采取什么行动就有了对策。看到一对男女相拥而坐，你就别再有夺人之爱的非份念头了，只有祝福他们有情人早成眷属，他们还会对你产生好感。若是看到一对男女相对而坐，则表明他们还尚待进一步沟通，你若有意于其中一方，也许还有希望。

    　　　　③以深坐与浅坐的坐姿来识破对方的心理。

    　　　　对于人类来说，立姿是最适合活动的一般状态，因此，人们在坐的时候会以立刻可以站起姿势为前提。在椅子上采取浅坐，即是其中的一个例子。也有人是因为紧张只敢钱坐在椅子上，常常处于将要采取行动的紧急状态里。

    　　　　人一旦松懈下来时，就会坐稳在椅子上，同时伸出脚，很悠闲，表示不会立刻站起。

    　　　　这可以从狮子和马身上看到这种观点：狮子很凶猛、强大，所以它可以整天睡觉，似乎这代表着一种自信。狮子喜欢捕食马，所以这种马类就整天很神经质地站着，但仍然逃不了厄运。

    　　　　因此深坐的人在精神上占有优势，至少他希望自己居高临下。而浅坐的人，坐在位置上常感不安，显示出一种屈居劣势的状态。

    　　　　浅坐的人，无意识中会表现出一种服从对方的心理来，在这种人面前，你千万不要显得自己太强大、傲慢，因为他们内心会有反抗。相反，你若表现了对他的友好或关心，他一定会在心里喜欢你。愿意与你接近，这为拓展以后的关系奠定了基础，其实，什么人都是可以利用的。如果很多人都愿意与你接近，这就给你造成了一种优势，起码在人际关系上你已经胜了，你的工、作、学习就很容易走向成功，离得到别人乃至上司的赞赏就不远了。

    　　　　④由人类的坐姿而表现出来的深层心理现象。


    有些人一坐下来就会跷起二郎腿，据说这种人深沉、不服输。


    　　　　不过，这是男人的情况，女性则就稍有不同了。女人大胆地跷起双腿，这就表现了她对自己的容貌或衣着服饰相当自信。这样的坐姿，很有把握吸引男人的注意，同时也表示她显示自己的强烈欲望，这种女人自尊心很强，热衷于做老板，她～面很轻松地跟男人来往，一面也不轻易倾心于一个男人。

    　　　　6．从穿戴看透内心

    　　　　人本来是赤裸裸地来到这个世界上的，为了隐藏自己的庐山真面目，才穿衣服。

    　　　　其实，人类不曾想到，为了要穿上自己喜爱的衣服，包括颜色、质料，反而把自己毫无掩饰地呈露出来了。因为每个人所选购的衣服把自己的心理状态表现得袒露无遗。

    　　　　①衣着华丽者自我显示欲强，爱出风头。

    　　　　在大庭广众之中，我们可以发现某些人总是穿着引人注目的华美服饰，这种人大体上有强烈的自我显示欲。同时这种人对于金钱的欲望特别迫切。所以，当你看到这类身着华服的人，或同事中有这样的人时，你就能洞察到他（她）们的这种心理，多夸奖他（她）们的服饰，满足其膨胀的显示欲是一个好办法，这种人就不会轻易与你为敌。

    　　　　③衣着朴素者缺乏自信，喜欢争吵。

    　　　　有一种人穿着朴素，不爱穿华美的衣服，这种人大多缺乏主体性格，对自己缺乏信心。希望对别人施予威严，想要弥补自己自卑的感觉。

    　　　　遇到这种人，就别与他们争执不休，因为越是自卑的人，越想掩饰自己的自卑，越会与人喋喋不休地争吵，以期保存剩下的一点点面子，这反而不利于和他人维系关系。

    　　　　这时候，你大可以大大方方承认他的观点，他反而会感到你的宽容大度，你会取得意想不到的效果。

    　　　　③喜欢时髦服装者有孤独感，情绪常波动。

    　　　　有一种人，完全不理会自己的嗜好，甚至说不知道自己真正喜欢什么，他们只以流行为嗜好，向流行看齐。这种人在心底里常有一种孤独感，情绪也经常不安。

    　　　　④不理时尚者常以自我为中心，标新立异。

    　　　　有一种对于流行的状况毫不关心，这种人的个性可以说是十分强硬，但也有一些人是不敢面对外面的花花世界，而一味地把自己关在小黑屋里。这种人认为，如果跟别人同调，岂不是等于失去了自我？这种人常常以自我为中心，经常弄得大家索然无味。

    　　　　⑤突变服装嗜好的人想改变生活方式，也有逃避现实的成分。

    　　　　一位公司职员小张，到目前为止一直穿戴固定式样与格调的西装。但有一天，他却改成了潇洒的夹克、鲜艳的长裤，带着完全不同颜色的领带来公司上班。从表相或精神方面说，小张的内心必然受到了某种刺激，使他在想法上发生若干变化，所以，在他们的深层心理里，通常怀有某种新的意思。同事们则好奇地猜测：“他今天有什么事吗？”“他遇到了什么问题？”

    　　　　对于这种突然改变自己服装嗜好的人，你若想与他保持良好的关系，应当显得不当一会儿事，或者赞美他穿什么都很不错之类的话，相信他的心灵大门一定会向你敞开，你的承认的态度比别人的质疑的态度要强，你会赢得别人的回报——赞美。

    　　　　③有一类人对流行既不狂热，又不会置之不理，改变穿衣也是渐渐实行。

    　　　　这一类人处事中庸，情绪稳定，一般不会做什么出格的事。他们多有理性，不过于顺从欲望，也不盲从大众时尚。此种人比较可靠，值得结交。

    查看(50) 评论(0)

  • 好可爱的星座！（转）

    2008-6-20

    白羊座
    白羊妈妈经常叮嘱羊羊： " 穿裙子时不可以荡秋千；不然，会被小男生看到里面的小内裤哦！ "
    有一天，羊羊高兴地对妈妈说： " 今天我和小明比赛荡秋千，我赢了！ "
    妈妈生气地说： " 不是告诉过你吗？穿裙子时不要荡秋千！ "
    羊羊骄傲地说： " 可是我好聪明哦！我把里面的小内裤脱掉了，这样他就看不到我的小内裤了！ "
    （勇敢直率、敢做敢为的白羊）

    金牛座
    卖瓜小贩： " 快来吃西瓜，不甜不要钱！ "
    饥渴的牛牛： " 哇！太好了，老板，来个不甜的！ "
    （持家、想出轨又顾全自己的金牛）

    双子座
    妈妈叫双双起床： " 快点起来！公鸡都叫好几遍了！ "
    双双说： " 公鸡叫和我有什么关系？我又不是母鸡！ "
    （自我意识强烈、自行思维的双子）

    巨蟹座
    公车上，蟹蟹说： " 今晚我要和妈妈睡！ "
    妈妈问道： " 你将来娶了媳妇也和妈妈睡阿？ "
    蟹蟹不假思索： " 嗯！ "
    妈妈又问： " 那你媳妇怎么办？ "
    蟹蟹想了半天，说： " 好办，让她跟爸爸睡！ "
    妈妈： " ！＠＃＄％︿＆＊（ ……-"
    再看爸爸，已经热泪盈眶啦！
    （恋母情结、依恋的巨蟹）

    狮子座
    狮狮去参加奶奶的寿宴。到了吃寿包的时候，狮狮问： " 我们为什么要吃这种像屁股的寿包？ "
    众人听了脸色大变。
    接著狮狮拨开寿包，看看里面的豆沙，说： " 奶奶，快看！里面还有大便！ "
    众人晕的晕，吐的吐。
    （以自我感受、不怕旁人眼光的骄傲的狮子）

    处女座
    处处对肚脐很好奇，就问爸爸。
    爸爸把脐带连著胎儿与母体的道理简单地讲了一下，说： " 婴儿离开母体之后，医生把脐带减断，并打了一个结，後来就成了肚脐。 "
    处处： " 那医生为什么不打个蝴蝶结？ "
    （好奇心强又追求完美的处女）

    天秤座
    父亲对天天说： " 今天不要上学了，昨晚．．．你妈给你生了两个弟弟。你给老师说一下就行了。 "
    天天却回答： " 爸爸，我只说生了一个；另一个，我想留著下星期不想上时再说！ "
    （聪明、权衡利弊的天平）

    天蠍座
    蠍蠍刚睡著，就叫蚊子叮了一口。
    他起来赶蚊子，却怎么也赶不出去。没法，便指著蚊子说： " 好吧，你不出去我出去！ "
    边说边出了房间，把门使劲关严得意地说： " 哼！我今晚不进屋，非把你饿死不可 ！ "
    （搞不懂、不按常理出牌的天蝎）

    射手座
    射射： " 爸爸，为什么你有那么多白头发？ "
    爸爸： " 因为你不乖，所以爸爸有好多白头发阿。 "
    射射： …… （疑惑中）
    射射： " 那为什么爷爷全部都是白头发？ "
    爸爸：！＠＃＄％︿＆＊（ ……
    （喜欢思考的射手）

    摩羯座
    一天，羯羯跟妈妈上街；走在路上，突然下起雨来。
    妈妈拉过羯羯的小手，说： " 下雨了，快往前跑阿！ "
    羯羯慢条斯理地问： " 那前面就不下雨喽！？ "
    （明白现实懒得改变的摩羯）

    水瓶座
    瓶瓶问妈妈： " 为什么称蒋先生为『先人』？ "
    妈妈说： " 因为 ' 先人 ' 是对死去的人的称呼。 "
    瓶瓶说： " 那去世的奶奶是不是要叫『鲜奶』？ "
    （天生的另类、脑筋思考永远和常人不一样的水瓶）

    双鱼座
    爸爸给鱼鱼讲小时候经常挨饿的事。
    听完後，鱼鱼两眼含泪，十分同情地问： " 哦，爸爸，你是因为没饭吃才来我们家的吗？ "
    （富含丰富同情心、不分情况对象的双鱼）  

    查看(21) 评论(0)

  • LoadRunner资料下载-视频资料+文档资料

    2008-6-05

    查看(192) 评论(0)

  • loadrunner录制下载文件

    2008-6-05

     

    转载

    loadrunner录制下载文件，文件如何保存，如何获得服务器返回的文件名，保存文件时如何随机生成文件名

    在录制脚本的过程中，我们把下载文件的请求单独放到一个action中，我们先简单的分析一下录制下载文件的脚本，在脚本中只能看到这样一个下载的请求：

    web_url("download.php",
    3w+f}H|:kb\160521  "URL=http://211.147.208.141/cn/resources/download.php?id=386",
    LA&BC:}&RK160521  "Resource=1",51Testing软件测试网We;jnaZ X
      "RecContentType=application/force-download",
    {#j9t#d*aZY160521  "Referer=",51Testing软件测试网C y)I0Vz
      LAST);

    对于如何保存到本地，loadrunner是无法记录的，执行脚本时客户端发出这个请求，服务器端响应后，loadrunner接收到了服务器响应的文件内容（我们可以在日志中看到文件的内容，不过是乱码），既然loadrunner可以接收到文件内容，那么我们完全可以使用关联函数来获得该内容，在通过C语言的文件函数把获得的内容写在本地。

    那现在遇到这样一个问题，使用关联函数如何定义获得服务器响应内容的左右边界呢？因为我们把这个请求写在了一个单独的action中，所以在这里我们只要把服务器响应的所有内容均获取下来写到本地，也就完成了下载文件的保存。

    下面看代码：

    Action()
    x+g5b$Q]Yq160521{51Testing软件测试网4G~ WepuI Z
        int flen;        //定义一个整型变量保存获得文件的大小
    \-tH8cs@160521    long filedes;    //保存文件句柄
    D#| j+_2bD{160521    char file[256]="\0";  //保存文件路径及文件名


    2q"Tamd'{Qg OQ160521    web_set_max_html_param_len("2000000");//设置页面接收最大的字节数，该设置应大于下载文件的大小

     web_concurrent_start(NULL);

      web_reg_save_param("filecontent",51Testing软件测试网4C!@B"n|l"C
      "LB=",51Testing软件测试网2@8Q+c|"]Q*K
      "RB=",51Testing软件测试网;Kay\!P'j)D3c:s\2g
      "Search=BODY",
    P{?L+lN L VF160521  LAST);

    //使用关联函数获取下载文件的内容，在这里不定义左右边界，获得服务器响应的所有内容

    web_reg_save_param("file",
    lBHk2U/S160521  "LB=filename=\"",
    MK1el[160521  "RB=\"",51Testing软件测试网5n gJ!m7N%sO*`FG
      "Search=all",
    0mA3G6?/ga(t160521  LAST);

    //使用关联函数在服务器响应的头文件中获取下载文件名

     web_url("download.php",51Testing软件测试网wZ#@${+_,Q
      "URL=http://211.147.208.141/cn/resources/download.php?id=386",51Testing软件测试网V.e*M8d'E%h
      "Resource=1",51Testing软件测试网]c5C1bG9]3G@1fK
      "RecContentType=application/force-download",
    G K+{1l{[/r160521  "Referer=",51Testing软件测试网`&iwR&e+\iVp
      LAST);

    //发出下载请求

     web_concurrent_end(NULL);

    51Testing软件测试网A)w(u7WB/cFV
     strcat(file,"c:\\");    //将“c：\\”这个路径保存到file中
    @ zf,iPN9Q160521 strcat(file,lr_eval_string("{file}"));//将获得的文件名拼接在file这个变量字符串之后

    51Testing软件测试网 rFa;mj.gQ |'T
    flen = web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE); //获得文件大小

        if(flen > 0) 51Testing软件测试网0T3NTmygY
        {51Testing软件测试网4i!I.S\}3e9el
         if((filedes = fopen(file, "wb")) == NULL)
    |B!pW,^p0}g160521     {51Testing软件测试网Y)gd p'b)_B4{&c
          lr_output_message("Open File Failed!", lr_eval_string("{filecontent}"));
    ,e#G*X)I.P:i+Yv160521      return -1;51Testing软件测试网n'j&{,w/J^T
         }
    D.`BX{[5`D|160521     fwrite( lr_eval_string("{filecontent}"),flen,1,filedes );51Testing软件测试网movr(g@q
         fclose( filedes );51Testing软件测试网@ pc y)R#gXE
    }

     return 0;51Testing软件测试网/J4W,~dF ?
    }51Testing软件测试网*B*w&hU]q-F'\2gl,~

    好了，运行这段脚本完成文件下载并写到本地的操作

    如果我们需要重复保存这个文件到本地，如何解决重名问题呢，下面这段代码可以随机生成文件名

        char file[256]="\0";
    !T)}0p,{7K*~I g4t160521    char * chNumber

        chNumber=lr_eval_string("{Random}");  //生成随机数 

        strcat(file,"c:\\test");51Testing软件测试网)k:N4x*Lhd5nLV
        strcat(file,chNumber);
    d&e:p Oa#W F ]160521    strcat(file,".rar");

    此时file中保存着一个随机生成的文件名，然后使用文件函数以该文件名保存文件

    查看(49) 评论(0)

  • 成功测试管理的九大原则

    2008-6-05

    成功测试管理的九大原则

    　　　　　　　　　　　　　　　　　　　　三原编译 yesky论坛
    　　简介

    　　许多测试管理者是从技术部门进到管理阶层的。尽管他们有可能受过很多测试或软件工程的培训和指导，但他们还是很难经常从失败和错误中学到管理技巧。作为一个管理者，你有两项基本工作：找出为你工作的最好的员工并且建立一个能够使员工完成工作的环境（使他们最好地完成工作）。这篇文章讲述了一些我学过的关于这些管理工作的经验。

    　　总是那些人――帮助人们最好地完成工作

    　　1． 为工作雇佣最好的员工

    　　我遇到许多管理者，他们要雇佣的员工仅仅是他们上一个雇佣的翻版。作为一个测试管理者，你必须对你需要什么人做出评估。假设现在你的部门满是极好的探索型的测试员。如果你还要雇另一个探索型的测试员，也许比你现在的要好，但是他对你的空白领域有作用吗？也许有，也许没有。

    　　工作的最佳人选也许就是你现在这个小组里所没有的类型。最佳人选或许并不“适合”你通常的工作方式。作为一个测试管理者，雇佣一个最佳的员工要用发展的雇佣策略，面试时要检验他是否符合这个策略。这可以让你找到最适合这份工作的人员，他能够完成必要的工作。

    　　2.安排每周与你的每个小组成员在不被打扰的环境进行谈话

    　　最为一个测试经理，主要工作之一就是定期的评定你的组织做了些什么并且是怎样做的。你还要为你的员工做一个报告，关于充分了解他们正在做什么和他们是怎样做的，以此来给做他们正式的和非正式的工作成绩考核。如果你没有了解到每个人的动态你就不应该对你的报告满意。

    　　我定期地给我的小组成员每周在不被打扰的条件下做一对一的谈话。（当我管理12个员工的时候，我安排在另外一周会见另一些人）。我每周用30分钟来和每个员工谈谈他们的工作：他们工作中的问题或是意见；他们是否需要帮助，他们的表现和他们达到目标的兴奋。我一般安排一周的某天来进行一对一谈话。我事先安排出和每个人的特定时间，接下来我亲自会见他们每个人。如果我们不能把所有需要谈到的细节都包括，我们会安排另外一个时间来继续。

    　　许多管理者说他们没有时间在一周会见每一个员工来谈他们的工作。据我的经验，如果我不能安排时间和我的员工进行每周的谈话，他们会来打扰我的工作，因为他们无论如何还是必须要来找我。

    　　如果你安排和你员工的谈话，你必须减少计划外的打扰（既有他们的也有你自己的），并且更多的了解他们在做什么。当你清楚你的小组正在做的，你才能更有效率地帮助他们明确优先应该做的工作，重聚资源，重新计划工程的部分，排除障碍等等。
    　　 3.假定员工知道如何完成他们的工作的人员

    　　因为很多管理者起初做的是技术工作，他们知道他们的员工现在从事的工作。他们认为他们现在知道。如果你已经管理了两三年，你也许还没有你的技术员工知道的多，尤其是怎么样完成日常工作。

    　　你或者你的前任者雇佣你小组的员工。假设你雇佣这些人因为你认为他们能够完成工作，如果你设想每个人都知道如何完成他们的工作，你将得到比假设他们都不知道怎么完成的更好的效果。即使有些员工在无论你设想是否都能成功完成工作，但是有些员工将会被你对他们的想法所影响工作。

    　　因为我知道我的员工都知道怎样做他们的工作，我给他们分派任务。问他们是否需要帮助，然后留他们独自完成（除非他们寻求帮助）。我的意思并不是你不应该在他们工作的时候和他们说话，你只是不该打扰他。打扰可以分为几种不同的形式：

    　　· 如果你在不知不觉的情况下来到他身后，来到他的肩膀旁边，问他：“进行的如何了？”，尤其是在他们绞尽脑汁仍不得其解时, 这将仍然不能使你对他们的要求达到。。

    　　· 如果你每天都问，更糟的是每个钟头都问,他们是如何做的。这看起来就像对你员工进行微机管理，很惹人烦。毕竟,你没有工作要做吗？另外, 他们会以为你认为他们不知道该如何完成工作。

    　　· 如果当他们没有问你意见，你说“我会用这种方法”。这种予以打击的帮助不会有用。
    .    如果你不确定怎样能知道你的员工是否胜任，和每一个小组成员商讨寻求帮助的时机。每个人，包括你自己，应该选择一个规则来知道他或她什么时候成为了一个令人讨厌的家伙了。我的一个客户有一个15分钟法规。如果有人在某方面令人讨厌持续15分钟以上，他就必须停止并且和别人谈谈他的工作。

    　　当你分配工作时，问问你的员工是否明白该做什么，他或她是否有方法完成。确定工作进程，如果员工遇到麻烦，他应该主动找你寻求帮助，但是如果你坚决干涉，你的员工将会把找你寻求帮助作为最后的解决方法。

    　　4.对待你的员工要用他们能接受的方式,而不是你可以自己可以接受的方式“对待别人要用你愿意接受的方式”（己之不予，勿施于人）――这条黄金法则可能会对许多生活中的纯的社交因素有效，但是并不是总对工作有用。

    　　有效率的管理者知道他的每一个员工需要怎样的对待方式。当其他的人更乐意接受更多的信息。一些人去需要特定的任务和指示。一些因为解决新的，很棒的，复杂的问题而更有冲劲，但是还有一些只是对他们已经知道如何去处理的问题而感到舒服。

    　　另外，针对于不同的工作，我们都喜欢不同的认同方式。金钱不是表示认同的唯一方式，你可以用其他的方式来酬劳你的员工。有些人喜欢对他个人的感谢，有人乐意在公众面前的认可，一些喜欢以M﹠M方式，或者是奖励电影票，还有人希望有团队的排队来庆祝。记住无论什么的激励你的方式都不一定能激励你小组的每一个其他成员。和你的小组成员们通过讨论来了解他们每个人对奖励比较喜欢的给予方式。创造一个好的工作环境

    　　5．重视结果而非时间

    　　许多认可建立在员工完成工作的时间上，而不是他们最后的成绩上。但是，花费在工作上的时间不一定和创造性有必然的联系。如果你真的想改善对创作性和工作效率的认可的话，不妨考虑保证你员工每周只工作40个小时。 我常常听到一种表示对员工的异议就是“你整整一天什么都做不出来。”假设你自己处在一个巨大的障碍前，考虑你可以做什么来解决的时候，你是不是取消了会议？你的小组成员能否井然有序地安排他们的工作以至于能够最大限度发挥创造性？

    　　当人们每周工作超过40个小时的时候，他们开始在工作的时候关心他们自己的事。他们花钱，他们给很久没有联系的人打电话，因为他们一直都在工作。

    　　一旦你创造了一个环境，让员工在工作时间完成工作，开始鼓励他们每周不要超过40小时，接着你就可以基于他们在40个小时能够完成的工作量给他们酬劳。我总是发现这样能够提升创造力（因为员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己）。

    　　当你开始注意规律，不仅仅是时间，还包括更容易地给员工的表现给予精确的适度的评价。你的员工是否完成了他们的计划和测试设计？当他们开发测试的时候，他们还要修订那些他们需要的改进的部分？（如果你只是注意有多少测试可以使用，我可以重复地开展相同的测试）计划每周工作40个小时，并且为你要在这段时间完成的工作付报酬。
    　　 6.承认自己的错误

    　　每个人都会犯错。他们会因为忘记开会而使客户发怒。承认你犯错是令人尴尬的。我们中的许多人认为对小组承认自己犯错会失去尊严。

    　　如果你不是经常犯错，你承认错误的时候其实能够赢得尊敬。如果你忘记一次会议，你为此道歉，其他的人会理解你并且最终原谅你。

    　　不管你做了什么，不要否认或故意忽略你的失误。故意忽略不会让错误消失这只会让错误成长为怪物。最近，有一个委托人在会上对他的员工大声斥责。会后，他认识到他不应该那样在小组会上那样做。他只是想让他们安心工作，等过几天再道歉。

    　　我建议在他们对他积累怒气之前，应该用正确的方式和他的员工交谈。他起初不愿意，但是他后来还是温和地在两天后和他的每个员工单独进行了交谈。每个人都是这样对他说的：“我只是在会后才对你感到生气的。如果您能够立即和我谈谈，我就不会把它们积累起来。但是现在已经两天过去了,我仍然对您感到生气，事实上，我还更加恼火，我现在不能确信现在是否能相信您。我不介意你对我们大吼，但是我不能确定是否还会再这样做。

    　　我的客户不知道应该如何处理这种情况。他认为他的等待是正确的，但是却让问题变得更加严重。.他已经决定再也不会犯这样的错误了，而且会立刻和会员工交流。

    　　他的员工用了好几个月来重新相信他，但是我的这位客户的确通过承认过错而增加了他的个人魅力。现在，他和他的员工对这件事可以当做是玩笑来说。他们说这是他的认知和能力的巨大转折点。

    　　7.决定承担一个项目必须首先问你的组员是否有能力完成当你是一个下级的员工，你的老板对你说“我们是否可以在下个十月完成项目？”回答说“当然”会令人惊讶。但是，你的员工会因为你回答“我要考虑一下。”而表示赞赏。

    　　即使你已经在考虑这个问题，告诉了你的员工你们将来做它，你还是应该得到足够的信息来考虑。你应该从这几方面来看：

    　　·一段时间内，你也许会因为另一件工作而感到对这个问题迷惑。

    　　· 也许有你正被其它需要考虑的问题所累，因为你不再有相同的时间像你第一次看到它的时候。

    　　· 如果你“训练”你的上司让你的回答有漏洞，你的上司会继续给你让你回答他的压力。

    　　当你与你的员工在做决定之前讨论问题时，你应该把这些和他们说一说：

    　　· 我想知道是什么让你想做这个项目。

    　　· 我不怕告诉我的上司要怎么处置它。

    　　在决定做一个项目之前先好好做考虑是一种对你员工的尊重。另外，考虑他们的想法也会使你从他们那里赢得尊重和忠诚。

    　　8.计划定期的培训

    　　作为管理学的一部分，测试是一种挑战和对规则的经常性的改变。因为经常的改变，要制定定期的培训计划。如果你没有基于不断的变化而培训你的员工，你就会有损失。

    　　培训可以是关于特定项目或者是技术。你可以进行训练用不同的方法：

    　　· 提供一个简单的午餐，让每个你的每个组员讨论一个特定的领域。这特别对同时要做很多不同项目的小组有用。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。

    　　· 做一个对每个部门的阶段说明。无论幸运与否，每个部门都会有和你小组相仿的工作，但是一般来说其它部门都不知道另外的部门在做什么。

    　　· 如果你们有交叉利益的小组，你可以让两个小组都展现他们各自为公司所作的项目，或者只是针对你的测试小组。

    　　· 邀请外面的专家来讲一个特定的技术或者一种项目。这些专家或者是专业的顾问，善演讲的人，也或是一个博学的朋友或同事。

    　　· 如果你买了工具或者已经进行了培训，考虑组织一个内部的“使用者”会议。人们可以在那里分享他们使用这种工具的感受并且讨论它的问题，优点和恶作剧。这特别对有缺陷的追踪系统和构造管理系统有效果。

    　　9.计划测试

    　　作为一个测试经理，你不可能有时间去做所有你想做的事。所以，计划你和你小组能做什么。作为测试经理，首先应该确定自己的任务，是在发布之前找到大的缺陷？还是评估软件的状态？或者是帮助开发经理在发布之前做风险评估？你的任务有可能是其中一项又或者是其中几项结合。无论是怎样，在进入的玩命工作时期之前, 对测试进行计划, 你组里的每个人都要竭尽全力你不需要做所有的事。你不是对所有事都计划而是精简，你就会有时间, 然后你就可以计算出你能再做什么。

    　　测试的计划是对每个产品或是对各个开发阶段的产品开展测试的策略。测试要多严格？什么测试不用进行？你在测试里要用硬件和软件的那些组合？什么样的组合不能作为彻底的，可能的，在所有的测试里都运用到的。

    　　测试是一种危险的评估。你和你项目里的其它成员能够进一步做出决定：你乐意对产品的测试部分和非测试部分冒多大的的险？

    　　一旦你决定要测试什么，对每个产品发展发布标准。发布标准是对每一项发布挑剔的重要性评判的客观的标准。“如果那样将会不错”不是步伐标准。“如果不那样做客户将会置我们于死地”才是发布标准的组成部分。

    　　如果你计划一个测试并和你的组员一起开展项目, 你不能一直只扮演一个守门人的角色。你无须停止准许运用.你和你的项目小组或者你和项目经理一起制定评判的标准。当你们都通过了这些标准，就可以交货了。加入你们没有达成共识 ，诚实的，决定你下一步该做什么。我所有做过的项目当中，我们都必须对发布标准达成共识,所以我们为此一直工作.一些客户提出了很苛刻的标准，我们最后也达成了共识。他们更换了文件当中的发布标准,

    　　解释他们在项目小组里的位置, 并且支配管理, 最后交接工作。

    查看(100) 评论(1)

  • WebLOAD Open Source 从入门到精通

    2008-3-14

    WebLOAD Open Source 从入门到精通

     在jackei的博客上面看到了WebLOAD开源的消息，正好最近也有做自动化测试的需要，利用一天的时间学习了一下WebLOAD的使用方法。

     准备写一个简单的教程，一方面把自己的学习过程记录下来，另一方面把学习的经验分享给别人。

     首先在    http://www.webload.org/上面进行注册，下载WebLOAD Open Source安装文件。

     RadView     www.radview.com/ 是个不错的公司，教程做的非常的专业，不需要注册就可以打开教程来学习，非常方便，值得夸奖。

     先给WebLOAD Open Sourece做个简介，然后咱们开始教程（其实链接了RadView的教程），最后我自己总结了一下。

     一.WebLOAD简介

     1.可以进行Web Application性能测试
     2.可以进行Web Application功能测试
     3.可以进行Html的分析
     4.Open Source如果想进行测试工具的开发也是不错的参考