顺势而为,无为而无不为

发布新日志

  • 想作为一个管理者需要提高以下八项能力

    2008-03-07 13:32:55Top 1 Digest 1

    中层经理人不论是作为一名执行者、还是一名领导者,都必须通过别人来完成任务。要做个“服众”的经理人,应该有意识地提高以下八项能力:

    1. 领悟能力
    做任何一件事以前,一定要先弄清楚上司希望你怎么做,然后以此为目标来把握做事的方向,这一点很重要,千万不要一知半解就开始埋头苦干,到头来力没少出、活没少干,但结果是事倍功半,甚至前功尽弃。要清楚悟透一件事,胜过草率做十件事,并且会事半功倍。

    2. 计划能力
    执行任何任务都要制定计划,把各项任务按照轻、重、缓、急列出计划表,一一分配部属来承担,自己看头看尾即可。把眼光放在部门未来的发展上,不断理清明天、后天、下周、下月,甚至明年的计划上。在计划的实施及检讨时,要预先掌握关键性问题,不能因琐碎的工作,而影响了应该做的重要工作。要清楚做好20%的重要工作,等于创造80%的业绩。

    3. 指挥能力
    无论计划如何周到,如果不能有效地加以执行,仍然无法产生预期的效果,为了使部属有共同的方向可以执行制定的计划,适当的指挥是有必要的。
    指挥部属,首先要考量工作分配,要检测部属与工作的对应关系,也要考虑指挥的方式,语气不好或是目标不明确,都是不好的指挥。而好的指挥可以激发部属的意愿,而且能够提升其责任感与使命感。要清楚指挥的最高艺术,是部属能够自我指挥。

    4. 控制能力
    控制就是追踪考核,确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉,然而企业的经营有其十分现实的一面,有些事情不及时加以控制,就会给企业造成直接与间接的损失。但是,控制若是操之过急或是控制力度不足,同样会产生反作用:控制过严使部属口服心不服,控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制,就是让部属通过目标管理方式实现自我控制。

    5. 协调能力
    任何工作,如能照上述所说的要求,制定完善的计划、再下达适当的命令、采取必要的控制,工作理应顺利完成,但事实上,主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调,也包括与外部客户、关系单位、竞争对手之间的利益协调,任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。

    6. 授权能力
    任何人的能力都是有限的,作为高级经理人不能象业务员那样事事亲历亲为,而要明确自己的职责就是培养下属共同成长,给自己机会,更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子,也是延伸自己智力和能力的载体,要赋予下属责、权、利,下属才会有做事的责任感和成就感,要清楚一个部门的人琢磨事,肯定胜过自己一个脑袋琢磨事,这样下属得到了激励,你自己又可以放开手脚做重要的事,何乐而不为。切记成就下属,就是成就自己。

    7. 判断能力
    判断对于一个经理人来说非常重要,企业经营错综复杂,常常需要主管去了解事情的来龙去脉因果关系,从而找到问题的真正症结所在,并提出解决方案。这就要求洞察先机,未雨绸缪。要清楚这样才能化危机为转机,最后变成良机。

    8. 创新能力
    创新是衡量一个人、一个企业是否有核心竞争能力的重要标志,要提高执行力,除了要具备以上这些能力外,更重要的还要时时、事事都有强烈的创新意识,这就需要不断地学习,而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的,它要求大家把工作的过程本身当作一个系统的学习过程,不断地从工作中发现问题、研究问题、解决问题。解决问题的过程,也就是向创新迈进的过程。因此,我们做任何一件事都可以认真想一想,有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限,唯有创新,才能生存。

     

  • 英语学习网站资料

    2008-10-13 18:02:15

    希望大家好好利用: 1. http://www.texun.cn/addrso/index.htm 特训网:English Learning Websites
    2. http://broadcast-live.com/ Live Radio and TV from Around the World
    3. http://www.nxenglish.com/voa01_1.aspx VOA Special English Introduction
    4. http://www.vocaboly.com/vocabulary-test/ Various Vocabulary Test online 20-40 quick- medium – thorough different levels of test
    5. http://www.tomx.com/listen/vocabulary/1402.html VOA Special English Vocabulary 1500
    6. http://tv.etshow.net/ ETSHOW 网络电视其次推荐我和同事们一起收集的网址:(特别要强调一点:希望大家对这些资源要取之,学之,用之!因为If you don’t use it, you will lose it!)
    adventuretv,提供视频资料,内容多是各地的风土人情,很不错:http://www.adventuretv.com/
    纽约时报,网上看新闻的好地方 http://www.nytimes.com/
    英文MP3下载的好地方 http://www.mp3raid.com/archive/archive/m/2/
    英文剧本下载的好地方 http://huajun.com/juben.htm
    一个个人主页,从这里可以在线收听新东方的25盘磁带 http://www.intron.ac/study/toefl.html
    英文锁定,每日读图 http://www.icansay.com/index.php?ChannelID=12
    英文锁定,综合学习网站,全面的英语教堂 www.icansay.com
    旺旺英语网,英语语音电子杂志 www.wwenglish.org
    Englishtown ,专业英语培训 www.englishtown.com
    新东方网络课堂,名校在线 class.tol24.com
    疯狂英语俱乐部,李阳疯狂英语 www.crazyenglish.org
    天英语,词汇中心 english.chinaschool.net
    时尚英语,丰富的学习资料 www.oh100.com/huayuan/english
    当当当,免费英语学习资料 www.downdowndown.net
    英语时空,英语文章大全 www.yysk.net
    英语麦当劳,英语教学快餐 english23.6to23.com
    听世界,各级听力训练 www.icanlisten.com
    Be Beyond,英美风土人情 www.bebeyond.com.cn
    洪恩,英语学习的好去处 www.hongen.com
    空中美语 http://www.englishtide.com
    英国教育部和中国教育部联合搞的免费学习网站,适合初学英语者 http://www.in2english.com.cn/
    GARFIELD官方网站 www.garfield.com
    语法 http://www.dailygrammar.com/
    大量的資料﹐非常不錯 http://www.english.ac.cn/
    无忧雅思 http://211.147.1.40 ;
    雅思的官方网站 http://www.ielts.org/
    雅思考试网东西不多 http://www.ieltsnet.net/index.htm
    关于雅思的一些资料 http://www.rotolife.com/cgi-bin/newarticle/list.cgi?class=1&type=4 ;
    英文电影剧本站专题 提供14部电影英文剧本 http://snowbear.3322.net/spelling/film.htm
    提供了24部英文电影剧本 http://www.c2000.com.cn/mov/m4.asp
    提供了10部英文电影剧本 http://goldnets.myrice.com/navi/50250.html
    子曰电影网的电影剧本下载太多了 http://www.ziyue.com/downloads/s.php?type=s | http://www.21zx.net/movie/m4.htm
    银海网 下载电影剧本好多啊 http://www.filmsea.com/download/_index.asp?swzm=a
    Screenplay电影剧本 http://www.babelcn.com/ebook/screen/index1.htm
    这里的囊括了现在流行电影的剧本 http://www.english.ac.cn/movies/playwright.htm
    一个教育网站提供的英文剧本下载 http://www.dreamabroad.net/chinese/html/download/movie_01.html
    看电影学英语 http://211.154.143.185/gate/gb/www.chenhen.com/html/english/speech/movie-english.htm
    听力专题
    一个很不错的英语学习网站,VOA资料很全 http://zflyingbird.myetang.com/index.htm
    http://www.quancheng.org/tabwork/catelist.asp?cateid=23 一些VOA新闻的文本
    http://www.icanlisten.com/standard_english/index.htm 有一部分听力
    http://www.englishabc.net/ae/ 《美国习惯用语 Words & Idiom》是Voice of America推出的免费广播讲座
    http://mpfree.org/english/voamain.htm 自由MP3的VOA资料下载不少哦
    http://edu.china.com/zh_cn/elearn/second/test/index.html 中华网关于VOA的听力技巧的一些文章,当然也有别的好东东
    http://www.cgeng.com/memberarea/listen/listen.asp 很不错的听力网站,有初级中级高级
    http://www.22av.net/ 免费的听力新闻,带文本
    http://www.xsrtvu.com/jiao/lgs/wangye/VOA1.htm VOA 英语广播收听技巧听VOA的朋友可以看看
    http://www.100steps.net/newsshow.php?serial=311&good=%CA%C7 2002年全国硕士研究生入学考试英语听力样题录音下载
    http://www.xsrtvu.com/jiao/lgs/wangye/VOA1.htm VOA英语广播收听技巧很不错的技巧文本
    http://www.english.ac.cn/listen/index.htm 超酷的英语听力站,也是个老站点了,有如下内容:新概念英语 听力入门 现代文阅读 ESL-Lab分级测试 CNNSF新闻测试 《圣经》在线 ,强烈推荐
    http://putclub.6to23.com/ 普特英语听力网站
    http://www.oeol.net/ “牛津英语在线” ( Oxford English On line )
    http://www.putclub.com/ 英语新闻听力Put English Club,网站主要由五个部分组成: A. 新闻英语;B. 英语教程;C. 资料下载; D. 科技英语; E. 普特论坛
    通用英语百句(视频)*** http://www.ol.com.cn/class/train/english.htm
    CNN英语学习资源***** http://literacynet.org/cnnsf/
    现代交际英语(视频)**** http://www.gz.supergnet.com/local_content/zhang/edu/index.html
  • 为bug预防奠定基础

    2008-09-01 15:37:53

     

    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,而不是仅仅是尽快修正它,我们就可以从中得到经验。这样,因为一个缺陷所浪费的时间也可以转化为投入:确保类似的错误永远不会再发生。


  • RUP

    2008-09-01 15:36:54

    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. 提供用户支持

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

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

    2. 达成计划
            “产品的质量只会和产品的计划一样好。” (2) 在RUP中,软件开发计划(SDP)综合了管理项目所需的各种信息,也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。 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进行补充和完善。
  • QA 与 QC的性质和区别(转载)

    2008-09-01 15:33:20

    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活动范围。
  • 如何揣摩他人心理

    2008-06-30 17:18:31

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


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

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

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

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


    1.能辨风向才会使好舵


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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

        ①由话题知心理。

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

    (3)由听话方式看破对方心理。


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

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

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

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

        3.脸上的表情,天上的云彩

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

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

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

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

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

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

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

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

        ①没表情不等于没感情。

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

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

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

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

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

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

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

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

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


    4.透过“眼神”辨人心


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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

        ②座位的方向意味深长

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

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

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


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


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

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

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

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

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

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

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

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


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


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

        6.从穿戴看透内心

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 好可爱的星座!(转)

    2008-06-20 12:02:41

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

    金牛座
    卖瓜小贩: " 快来吃西瓜,不甜不要钱! "
    饥渴的牛牛: " 哇!太好了,老板,来个不甜的! "
    (持家、想出轨又顾全自己的金牛)

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

    巨蟹座
    公车上,蟹蟹说: " 今晚我要和妈妈睡! "
    妈妈问道: " 你将来娶了媳妇也和妈妈睡阿? "
    蟹蟹不假思索: " 嗯! "
    妈妈又问: " 那你媳妇怎么办? "
    蟹蟹想了半天,说: " 好办,让她跟爸爸睡! "
    妈妈: " !@#$%︿&*( ……-"
    再看爸爸,已经热泪盈眶啦!
    (恋母情结、依恋的巨蟹)

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

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

    天秤座
    父亲对天天说: " 今天不要上学了,昨晚...你妈给你生了两个弟弟。你给老师说一下就行了。 "
    天天却回答: " 爸爸,我只说生了一个;另一个,我想留著下星期不想上时再说! "
    (聪明、权衡利弊的天平)

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

    射手座
    射射: " 爸爸,为什么你有那么多白头发? "
    爸爸: " 因为你不乖,所以爸爸有好多白头发阿。 "
    射射: …… (疑惑中)
    射射: " 那为什么爷爷全部都是白头发? "
    爸爸:!@#$%︿&*( ……
    (喜欢思考的射手)

    摩羯座
    一天,羯羯跟妈妈上街;走在路上,突然下起雨来。
    妈妈拉过羯羯的小手,说: " 下雨了,快往前跑阿! "
    羯羯慢条斯理地问: " 那前面就不下雨喽!? "
    (明白现实懒得改变的摩羯)

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

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

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

    2008-06-05 22:29:19

  • loadrunner录制下载文件

    2008-06-05 22:21:12

     

    转载

    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中保存着一个随机生成的文件名,然后使用文件函数以该文件名保存文件

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

    2008-06-05 13:20:21

    成功测试管理的九大原则

                        三原编译 yesky论坛
      简介

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

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

      1 为工作雇佣最好的员工

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      5.重视结果而非时间

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      8.计划定期的培训

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

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

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

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

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

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

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

      9.计划测试

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

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

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

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

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

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

  • WebLOAD Open Source 从入门到精通

    2008-03-14 11:36:05

     在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如果想进行测试工具的开发也是不错的参考

    •  

       二.WebLOAD教程

       WebLOAD动画教程地址 
      http://radview.cachefly.net/Tutorials/menu_page.html

       1. Recording an Agenda

      2. Debugging an Agenda

      3. Correlation Adjustments

      4. Parameterization

      5. Load Template Definitions

      6. Cruise Control Wizard (Goal-Oriented Testing)

      7. Mix of Agendas

      8. Running the Test

      9. Functional Testing

      3.WebLOAD总结:利用一天时间把这个系列教程学习完毕,来谈谈收获吧。

      1.学会了利用WebLOAD来录制测试脚本,脚本可以进行编辑,WebLOAD IDE分为脚本编辑模式和脚本调试模式,对WebLOAD映象不错,工具做的不错挺专业的。

      2.学会了利用WebLOAD IDE进行脚本调试,用过VS的程序员都很容易上手,调试的快捷键都与VS相同,支持断点,查看调用栈,查看变量等功能。

      3.Correlation Adjustments在WebLOAD Open Source版本中没有找到这个功能挺遗憾的,这个地方是专业版与Open Source版本的差别之处。

      4.学会了在WebLOAD中如何使用参数,在Web Application测试过程中,不同的客户端的Session是不同的,需要将Session变量化,WebLOAD介绍了智能拷贝和参数化Session的方法,我个人的理解一个Session对应着一个虚拟的客户端,必须将Session变量化才能模拟多个客户端同时在线的场景。

      5.从Load Template Definitions就开始讲解WebLOAD的另一个重要的组件 WebLOAD Console,WebLOAD IDE侧重于脚本的录制及编辑调试等功能而WebLOAD Console侧重于加载生成的脚本,定义LOAD客户端的策略,例如线性提高,随机变化加载虚拟客户端的数量,设定LOAD时间,而且可以生成随着时间和LOAD数量的报告,帮助我们找出系统瓶颈,在测试时可以动态加载监视对象,例如相应时间,CPU处理时间,内存占用率等等

      6.Cruise Control Wizard (Goal-Oriented Testing)  这个功能WebLOAD中没有,挺可惜的。

      7.Mix of Agendas可以在一个测试方案中添加多个测试脚本,这样可以模拟多个客户端的使用,例如:我们可以模拟10个客户端在登录,10个客户端在浏览网页,10个客户端在添加商品到购物车,然后每种功能的客户端还在不断的增长,这样的测试方案可以尽量的接近真实的环境,WebLOAD这个功能确实不错。值得夸奖。

      8.运行测试脚本,进行综合设置

      9.WebLOAD不仅可以进行性能测试,而且可以进行功能测试,功能测试的原理是可以查找相应的Html中的信息来判断测试脚本是否成功,例如:如果用户登录失败会显示为登陆失败,我们可以查找如果发现失败在Html的响应文本中我们就认为测试例失败了。另外对Html的学习也有帮助的。
  • 开源性能测试工具 - Apache ab 介绍

    2008-03-14 10:34:56

    版权声明:本文可以被转载,但是在未经本人许可前,不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载,请在转载是保留此版权声明,并保证本文的完整性。也请转贴者理解创作的辛劳,尊重作者的劳动成果。

    作者:陈雷 (Jackei)

    邮箱:jackeichan@gmail.com

    Blog:http://jackei.cnblogs.com

     

    引子

    按照原定计划,今天开始研究 JMeter,一天的时间看完了大半的 User Manual,发现原来只要沉住气,学习效率还是蛮高的,而且大堆的英文文档也没有那么可怕 ^_^

    本来想顺便把文档翻译一下,不过后来想了想,看懂是一回事,全部翻译出来又是另外一回事了,工作量太大,而且这也不是我一开始要研究 JMeter 的本意。不如大家有兴趣一起研究的遇到问题再一起讨论吧。

    开源工具通常都是为了某个特定的目的而开发出来的,所以如果想找到一个开源的性能测试工具去与LoadRunner 或者 QALoad 之类去比较,实在有些勉强。但是开源工具也有它自己的优势:小巧、轻便,在自己擅长的领域可以提供优秀的解决方案。所以,我们可以考虑准备一个自己的“开源测试工具箱”,平时利用空闲时间了解各种工具所适用的环境和目的,知识慢慢积累下来以后,就可以在遇到问题时顺手拈来轻松化解 ^_^

    另外,如果8月份和9月份的空闲时间足够多,我想我会写一个系列文章来讲述在实际的开发和测试过程中引入开源性能测试工具的情况。如果有朋友感兴趣,希望大家可以一起研究和讨论。

    简介

    ab的全称是ApacheBench Apache 附带的一个小工具专门用于 HTTP Server benchmark testing可以同时模拟多个并发请求。前段时间看到公司的开发人员也在用它作一些测试,看起来也不错,很简单,也很容易使用,所以今天花一点时间看了一下。

    通过下面的一个简单的例子和注释,相信大家可以更容易理解这个工具的使用。

    一个简单的例子

    /*在这个例子的一开始,我执行了这样一个命令 ab -n 10 -c 10 http://www.google.com/这个命令的意思是启动 ab ,向 www.google.com 发送10个请求(-n 10) ,并每次发送10个请求(-c 10)——也就是说一次都发过去了。跟着下面的是 ab 输出的测试报告,红色部分是我添加的注释。*/

    C:\Program Files\Apache Software Foundation\Apache2.2\bin>ab -n 10 -c 10 http

    ://www.google.com/

    This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0

    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

    Copyright 1997-2005 The Apache Software Foundation, http://www.apache.org/

     

    Benchmarking www.google.com (be patient).....done

     

     

    Server Software:        GWS/2.1

    Server Hostname:        www.google.com

    Server Port:            80

     

    Document Path:          /

    Document Length:        230 bytes

     

    Concurrency Level:      10

    /*整个测试持续的时间*/

    Time taken for tests:   3.234651 seconds

    /*完成的请求数量*/

    Complete requests:      10

    /*失败的请求数量*/

    Failed requests:        0

    Write errors:           0

    Non-2xx responses:      10

    Keep-Alive requests:    10

    /*整个场景中的网络传输量*/

    Total transferred:      6020 bytes

    /*整个场景中的HTML内容传输量*/

    HTML transferred:       2300 bytes

    /*大家最关心的指标之一,相当于 LR 中的 每秒事务数 ,后面括号中的 mean 表示这是一个平均值*/

    Requests per second:    3.09 [#/sec] (mean)

    /*大家最关心的指标之二,相当于 LR 中的 平均事务响应时间 ,后面括号中的 mean 表示这是一个平均值*/

    Time per request:       3234.651 [ms] (mean)

    /*这个还不知道是什么意思,有知道的朋友请留言,谢谢 ^_^ */

    Time per request:       323.465 [ms] (mean, across all concurrent requests)

    /*平均每秒网络上的流量,可以帮助排除是否存在网络流量过大导致响应时间延长的问题*/

    Transfer rate:          1.55 [Kbytes/sec] received

    /*网络上消耗的时间的分解,各项数据的具体算法还不是很清楚*/

    Connection Times (ms)

                  min  mean[+/-sd] median   max

    Connect:       20  318 926.1     30    2954

    Processing:    40 2160 1462.0   3034    3154

    Waiting:       40 2160 1462.0   3034    3154

    Total:         60 2479 1276.4   3064    3184

     

    /*下面的内容为整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间,其中 50 的用户响应时间小于 3064 毫秒,60 的用户响应时间小于 3094 毫秒,最大的响应时间小于 3184 毫秒*/

    Percentage of the requests served within a certain time (ms)

      50%   3064

      66%   3094

      75%   3124

      80%   3154

      90%   3184

      95%   3184

      98%   3184

      99%   3184

     100%   3184 (longest request)

     

    更多信息

    ab 不像 LR 那么强大,但是它足够轻便,如果只是在开发过程中想检查一下某个模块的响应情况,或者做一些场景比较简单的测试,ab 还是一个不错的选择——至少不用花费很多时间去学习 LR 那些复杂的功能,就更别说那 License 的价格了。

    下面是 ab 的详细参数解释,大家有兴趣的可以研究一下,最近没有足够多的时间研究,如果哪位朋友有兴趣希望可以帮忙翻译一下每个参数的含义,有问题讨论也欢迎在这里回帖 ^_^

    ab [ -A auth-username:password ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file ] [ -P proxy-auth-username:password ] [ -q ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -v verbosity] [ -V ] [ -w ] [ -x <table>-attributes ] [ -X proxy[:port] ] [ -y <tr>-attributes ] [ -z <td>-attributes ] [http://]hostname[:port]/path

     

    -A auth-username:password

    Supply BASIC Authentication credentials to the server. The username and password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the server needs it (i.e., has sent an 401 authentication needed).

    -c concurrency

    Number of multiple requests to perform at a time. Default is one request at a time.

    -C cookie-name=value

    Add a Cookie: line to the request. The argument is typically in the form of a name=value pair. This field is repeatable.

    -d

    Do not display the "percentage served within XX [ms] table". (legacy support).

    -e csv-file

    Write a Comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentage of the requests. This is usually more useful than the 'gnuplot' file; as the results are already 'binned'.

    -g gnuplot-file

    Write all measured values out as a 'gnuplot' or TSV (Tab separate values) file. This file can easily be imported into packages like Gnuplot, IDL, Mathematica, Igor or even Excel. The labels are on the first line of the file.

    -h

    Display usage information.

    -H custom-header

    Append extra headers to the request. The argument is typically in the form of a valid header line, containing a colon-separated field-value pair (i.e., "Accept-Encoding: zip/zop;8bit").

    -i

    Do HEAD requests instead of GET.

    -k

    Enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive.

    -n requests

    Number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representative benchmarking results.

    -p POST-file

    File containing data to POST.

    -P proxy-auth-username:password

    Supply BASIC Authentication credentials to a proxy en-route. The username and password are separated by a single : 查看(495) 评论(0) 收藏 分享 管理

  • 性能测试模型分析

    2008-03-10 12:02:47

    性能测试模型分析(转载)

    2008-03-09 21:56:18 / 个人分类:性能测试

    对于应用系统的性能测试,测试模型的建立至关重要,性能测试模型要以实际生产环境为标准搭建,只有模型符合实际的生产环境,性能测试的结果才能真实有效的反映将来上线的生产环境的实际性能情况。根据长期测试关键核心业务系统的经验,应用系统系统的性能测试模型分析应当按照下面几个步骤来实施:

     业务模型建立

      全面分析应用系统系统上线后所面临的性能压力的来源和类别,并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例,后台批处理业务的数据规模和类别等。最终目的是建立一个能够逼真模拟应用系统系统实际运行场景的业务模型。

     测试数据模型建立

      根据业务模型准备测试数据和基础数据,确保系统数据库中数据容量和真实性符合实际运行情况。

     监控模型建立

      性能测试的目的不仅仅是获得关键业务的性能指标,同时也要通过性能测试监控主机、数据库、中间件的各个性能指标,从而发现性能瓶颈,为进一步的性能调优提供准确的参考数据。

     测试模型建立

      对应用系统系统的测试,因该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。这样做的好处,在单业务负载测试是就可以发现各个系统本身的性能缺陷,而混合负责测试时将重点检查各个业务相互影响导致的性能缺陷。

     执行模型建立

      应用系统系统的性能测试必须要局方客户、系统开发商、第三方测试服务商紧密配合,才能保证整个测试工作的成功。因此,只有建立一套规范的性能测试流程,明确各个角色的工作职责,才能使性能测试工作有序、高效的开展。

     风险模型建立

      由于性能测试的特殊性,因此在整个测试过程中,会遇到很多导致整个性能测试失败的风险。丰富性能测试经验是必须的,能够提前分析可能遇到的各种风险并制定相应的规避措施。这样才能将性能测试的风险降到最低,最终圆满完成应用系统系统的上线性能验收测试。

      上面的步骤或者说方面只是性能测试项目实施中要完成的工作方面的的概述,不同的项目可能有不同的实施方法或步骤要视项目而具体实现。要完成一个有效的应用系统的性能测试,从需求调研到测试分析的各个阶段,有很多工作需要完成,在以后的文章中,会对性能测试项目的分阶段工作进行讲解,适当的时侯会搭配一些项目实施的例子来进行讲解。
  • 如何制定成功的测试计划

    2008-03-10 12:02:02

    如何制定成功的测试计划


    不错的文章,推荐大家看看。
    --------------------------------------
    如何制定成功的测试计划

       “工欲善其事,必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的,但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括:产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。

       产品基本情况调研:

      这部分应包括产品的一些基本情况介绍,例如:产品的运行平台和应用的领域,产品的特点和主要的功能模块,产品的特点等。对于大的测试项目,还要包括测试的目的和侧重点。

      具体的要点有:

      目的:重点描述如何使测试建立在客观的基础上,定义测试的策略,测试的配置, 粗略的估计测试大致需要的周期和最终测试报告递交的时间。

      变更:说明有可能会导致测试计划变更的事件。包括测试工具改进了,测试的环境改变了,或者是添加了新的功能。

      技术结构:可以借助画图,将要测试的软件划分成几个组成部分,规划成一个适用于测试的完整的系统,包括数据是如何存储的,如何传递的(数据流图),每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求,比如运行平台、需要什么样的数据库等等。

      产品规格:就是制造商和产品版本号的说明。

      测试范围:简单的描述如何搭建测试平台以及测试的潜在的风险。

      项目信息:说明要测试的项目的相关资料,如:用户文档,产品描述,主要功能的举例说明。

      测试需求说明:

      这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题,你应该很高兴你有这个记录在案的文档,可以证明你测了什么没测什么。具体要点有:

      功能的测试:理论上是测试是要覆盖所有的功能项,例如:在数据库中添加、编辑、删除记录等等,这会是一个浩大的工程,但是有利于测试的完整性。

      设计的测试:对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

      整体考虑:这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

      测试的策略和记录:

      这是整个测试计划的重点所在,要描述如何公正客观地开展测试,要考虑:模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节,越详细越好,并制作测试记录文档的模板,为即将开始的测试做准备,测试记录重要包括的部分具体说明如下:

      公正性声明:要对测试的公正性、遵照的标准做一个说明,证明测试是客观的,整体上,软件功能要满足需求,实现正确,和用户文档的描述保持一致。

      测试案例:描述测试案例是什么样的,采用了什么工具,工具的来源是什么,如何执行的,用了什么样的数据。测试的记录中要为将来的回归测试留有余地,当然,也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

      特殊考虑:有的时候,针对一些外界环境的影响,要对软件进行一些特殊方面的测试。

      经验判断:对以往的测试中,经常出现的问题加以考虑。

      设想:采取一些发散性的思维,往往能帮助你找的测试的新途径。

      测试资源配置:

      项目资源计划:制定一个项目资源计划,包含的是每一个阶段的任务、所需要的资源,当发生类似到了使用期限或者资源共享的事情的时候,要更新这个计划。

      计划表:

      测试的计划表可以做成一个多个项目通用的形式,根据大致的时间估计来制作,操作流程要以软件测试的常规周期作为参考,也可以是根据什么时候应该测试哪一个模块来制定。

      问题跟踪报告:

      在测试的计划阶段,我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质,问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的,以及明确问题产生时的测试环境。

      问题描述尽可能是定量的,分门别类的列举,问题有几种:

      1、严重问题:严重问题意味着功能不可用,或者是权限限制方面的失误等等,也可能是某个地方的改变造成了别的地方的问题。

      2、一般问题:功能没有按设计要求实现或者是一些界面交互的实现不正确。

      3、建议问题:功能运行得不象要求的那么快,或者不符合某些约定俗成的习惯,但不影响系统的性能,界面先是错误,格式不对,含义模糊混淆的提示信息等等。

      测试计划的评审:

      又叫测试规范的评审,在测试真正实施开展之前必须要认真负责的检查一遍,获得整个测试部门人员的认同,包括部门的负责人的同意和签字。

      结果:

      计划并不是到这里就结束了,在最后测试结果的评审中,必须要严格验证计划和实际的执行是不是有偏差,体现在最终报告的内容是否和测试的计划保持一致,然后,就可以开始着手制作下一个测试计划了。
     
     
     

    推荐几本经典的软件测试方面的书


    http://blog.csdn.net/jackei/archive/2004/10/24/149391.aspx

    读者仁者见仁,智者见智吧。



    鉴于CSDN的Blog服务总是出现问题,大家还是访问下面的链接吧。

    http://www.cnblogs.com/jackei/archive/2004/12/26/82012.html
  • 建立高效的测试团队

    2008-03-07 15:43:12

     

    [转载]建立高效的测试团队

    2008-03-05 17:42:33 / 个人分类:test

    作者 : 段念

              曾经和一位担任测试经理不久的朋友和我谈到过他们部门建设的问题。刚开了个头,这位经理就急不可耐地倒起了苦水: 部门的工作真是不好开展,员工没有劲头 ……”“ 某某员工简直是不可救药,总是把事情办砸 ……” 某某员工真是让人着急,来公司三年了,对业务也熟悉,你想要提拔她吧,她就是不上进,让她去做一点以前没做过的事情她都会惊慌失措 老员工都死气沉沉,新员工都没有上进心 ……” 某某最近要辞职了,我也不明白怎么回事,我还一直以为他工作得很愉快呢 ……” 。足足在发了半个多小时的牢骚以后,他仍然沉浸在自己的痛苦中。

            说实在的,我真的很同情他,也很同情他现在的处境。作为一个新上任的测试经理,自然会有一股子劲头,恨不能一夜之间就让部门面貌焕然一新,恨不能让所有的员工一夜之间突飞猛进 …… ,可惜,罗马不是一天建成的,部门管理的问题也绝对不会解决得那么轻易。

            管理是一种艺术,对测试团队的管理更是一种需要小心的艺术。测试工程师一般都敏感且自尊,他们有发现缺陷的能力,自然也能轻易发现你在管理工作中的疏忽;他们能够评价应用系统,评价你的管理工作对他们来说也不是难事。

            那么,真的就那么难建立一个高效的测试团队吗?实际上,管理工作的核心是 ,作为测试部门的负责人,只要抓住了这点,就能很顺利地把整个团队调动起来。我在不同的公司经历过不同的测试团队,在我的感觉中,测试工程师其实都是很好相处的人。测试工程师不是纯粹的技术人员,他们一般来说都敏锐、有耐心、有责任心、能承受工作压力,也具有比较好的沟通能力。但是, 测试工程师 这个对他们的统称掩盖了太多他们之间的不同。

            回到我们在文章最初的例子,当我问那位新测试经理 你觉得你理想中的测试工程师是什么样子的呢? 这个问题的时候,他的回答是 我希望他们都能有上进心、积极进取、有高的技术水平,同时能够承担工作压力。 我想,他的回答可能是用对自己的要求来要求部门所有的测试工程师了。一个全是将军的团队绝对不会比一个分工明确、高效协作的团队更加有战斗力。

            那么,究竟如何来建立一个高效的测试团队呢?这个问题,一定是 仁者见仁,智者见智 的问题。不过在这里,我不揣冒昧,说一些自己的看法。

    1    测试团队中的

            首先,高效的测试团队需要不同角色的 。根据我的经历,一般来说,测试团队中经常都有些这样类型的员工:

    1.1    不同类型的员工

    l         老虎

            测试部门的老虎是那些有活力、有冲劲的人。他们聪明、能干、敏锐、不惧怕压力。每个我见过的测试经理都期望能找到这样的人才,可惜,这样的人才并不多见,而且,这样的人才大多都是依靠测试组织自己培养出来的,一只 外来的 虎不一定能在新的组织中也发挥虎的威力。

            不过,即使在部门中有了老虎的存在,还必须为老虎创造出适合他的空间。很多测试经理都会为部门中能人的离去而烦恼,但在烦恼的同时,你有没有想过为什么他要离去?纯粹为了薪酬待遇? —— 实际上,老虎是很有上进心的,一旦他发觉自己只能在一个固定的环境中做固定的事情,他就会选择离开。要想留住这种类型的人才,必须为他创造一个时刻充满挑战的环境 —— 让他开拓一片天地,让其他角色来 守城 ,最可能是最合适的搭配。

    l      

            牛是最勤勤恳恳的,踏实、勤劳、敬业是牛最好的写照。这样的员工能完成你交给他的明确的任务,把明确的任务交给他是最让人放心的。但美中不足,这样的员工往往缺少主动的创造性,明明他对业务很熟悉,明明他经验很丰富,但一旦要他跳出自己习惯的工作氛围和角色,创造性地完成一些工作,他们就束手无策了。这种类型的员工让人又爱又恨,爱的是他勤勤恳恳的态度,恨的是他不肯进取的心态。

    l        猴子

            猴子是聪明的代名词,这种类型的员工聪明、大胆、活跃。在部门里,这类员工总是在鼓捣各种新工具、新技术、新名词。他们是工具引入的主要建议者和新技术采用的主要倡导者。这类员工对新事物有执着的热情,愿意去了解每一种他们所能接触到的新东西。对于解谜,这类员工有着天生的爱好,他们最大的兴趣就是从谜团一样的系统中找到能证明自己聪明的证据。然而,这类员工的缺点几乎和优点一样明显 —— 缺乏持之以恒的耐心,一旦他们不得不长期进行一些重复性强的工作(例如,手工的回归测试),他们就会表现出不耐烦和由此因为疏忽产生错误。

    l        长颈鹿

            长颈鹿在这里并不是 迟钝 的同义词。长颈鹿通常是一个部门中最有前瞻能力的人。他们具有对软件测试深入的理解和认识,能够对测试部门的发展提出非常好的建议(而不仅仅是意见),唯一的问题是,对细节上他们总是缺乏关注,能够给出漂亮的流程图或是建议书,但如果由他来执行,则一定是一场灾难。

    l       狐狸

            测试部门中也会存在一些狡猾的人,我们可以把他们称为 狐狸 。狐狸这种类型的员工总是整个部门看上去最为忙碌的一个 —— 他们为自己揽下一个又一个的工作,却用一个工作去掩饰在另一个工作上投入的无效劳动。每当你问起这类员工 “A 事情进行得如何? ,他们总能用 我正在忙着 B 事情(或是 C 事情) 这样的回答搪塞你。最终的结果是,经过几个月时间的忙碌,他们可能拿不出任何有效的工作成果。

    l        鼹鼠

            当然,这种类型的员工可能是我们都不希望见到的。他们永远都想没有睡醒一样,更多时候看到的是他们茫然的眼神。交给他的任何工作都可能没有理由地失败,而且,更可怕的是,他们很少能够从失败中学习到教训。

            对这些不同类型员工来说,重要的不是改变他们的性格类型,而是要了解他们的性格类型,再根据他们的性格类型为他们分配不同的工作,让他们能够在一个能顺利施展自我和自我前进的环境中工作。

    1.2     不同类型员工的对策

    l         老虎 —— 给他挑战,把部门最重要的、最困难的工作交给他,你只需要充分发挥他的主动性,定期让他汇报工作的进展就可以。让老虎觉得最安全的方法是让他能够充分证明自己的能力。当然,要注意的是,如果一个团队中有几只老虎,合理分配他们的工作(负责不同的方面)可能是一个好主意。

    l         —— 让他做自己最擅长的事情。牛会很高兴自己在某个方面可以一直发展,直到成为这方面业务或是实施方面的专家。让他接手老虎开拓的工作范围,做一个好的执行者对组织是最有利的。当然,牛有时候也会提出想要一些 挑战 ,这时候最好先为他准备好退路。

    l         猴子 —— 部门新技术研究的不二人选。无路是在测试自动化、测试工具引入、新的测试方法和测试技术引入方面,都可以仰仗猴子。不过,最大的风险来自于他们的不确定性和其天生地乐观心态,因此,如果让他们主导某个项目(例如,测试工具引入项目),要他们更加频繁地汇报工作进展和为他们规划细节。

    l         长颈鹿 —— 参谋。在规划部门发展的时候,可以多听听他们的意见,但最好不要让他们去完全承担部门测试过程改进的任务,在执行方面,他们可能并不会照顾到太多的细节。

    l         狐狸 —— 拿掉他用来隐藏自己的 多任务 。明确交给他一个任务,例如 完成某项目的测试 ,时刻关注他们在任务进行过程中的报告,一旦发现他们主动承担不属于自己的任务,就要立刻分析,看他们是否又犯了老毛病。

    l         鼹鼠 —— 怎么说呢?给他一个机会吧。可能是他并不真正热爱这个工作,也或者是他有些心理上的疙瘩没有解开,不管怎么说,找出他这样糟糕表现的原因,如果真的没有办法改变他的工作,很可能只能选择让他离开现在的团队了。

    1.3      团队成员的默契

            没有一个测试团队可以依靠一个人取得成功,成功必然是大家共同努力的结果。在短时间内建立一支成功的团队非常困难,因为你必须按照部门的规划去了解每个团队成员、对他们进行培训、在必要的时候重新培训等等。

            然而,由于种种原因,一个团队不可能总保持在建立之初的状态,有老成员的离开、也有新成员的加入。团队规模可能在变化,团队承担的职责也可能在发生变化。那么,在这些变化的同时,我们怎样让一个团队始终保持人员上相对的成功呢?答案就是 默契

            一个团队必须依靠制度才能建立这种默契。比如,建立员工之间的定期的沟通会、强制的培训和接受培训的机制、人员的定期轮换、岗位角色的互相备份等等。这方面没有定式可以遵循,每个人都可以按照自己团队的特点来建立体系,但必须要有这样的体系,才能将团队的成果和发展以某种形式固定下来。

    2       测试团队的 规则 氛围

            除了人员之外,最重要的就是团队的 规则 ,也就是团队赖以生存的规范土壤了。一个团队的战斗力更多地体现在 令行禁止 上,因此,对成功的测试团队而言,必须要有明确的角色分工和明确的团队规则。

            另外, 氛围 也是测试团队的一个重要因素。所谓测试团队的氛围,就是一种置身其中的感受,一个高效的测试团队,必然有良好的氛围。

    2.1      学习和交流的氛围

            一个高效的团队必然是一个持续学习的团队。测试团队中每个测试工程师其实都会对自己的未来有自己的规划,也会希望自己能够在团队中学习到更多的知识和技能。高效团队依赖团队中的每一个人来达到 高效 的目的,也要求每个团队成员都具有良好的技能,因此,学习的氛围是高效的测试团队必不可少的。

            但是,要建设学习型组织,并不是一件轻易的事情。组织不可能把学习作为一个任务来下达,因此学习必须要与工作进行结合;另外,如何调动组织中 能者 带动 暂时不能者 进行学习,也是很有技巧的事情。

    l         部门讲师制度

            部门讲师制度是一种比较有效的制度。在我的实践中,部门讲师是一种权利,也是一种责任: 部门讲师 认证是获得 高级测试工程师 级别的必要条件;同时,要保留住 部门讲师 的认证,必须保证每月至少 4 个小时的内部课程,而且,内部课程获得的评价要大于平均 8 分。

            除此之外,每年评选一次年度的 最佳内部讲师 ,每年对内部讲师进行一次重新认证,内部讲师可以优先获得一些外部交流的机会等等,这些都进一步将内部讲师变成了一种荣誉,从而使更多的成员愿意为整个团队奉献自己的知识和经验。

    l         专题

     

    首先个人觉得公司成立软件测试部门或小组的必要性和必然性,不需要进一步的探讨。但是具体的情况一定要按照公司的情况来实施,所谓情况主要指的是不同公司的特殊性:包括项目的情况,客户的情况,公司结构体制的情况。楼主说的情况和我现在的公司十分类似,稍有不同的是我们的测试组是在公司的老部门质量工程部门衍生出来的。至于上面所提到的什么时候建立专门的测试组,我想既然已经有了这样的计划,那么在大多条件满足后,就尽量越快越好。5个不同小组的情况,就会联带出很多的不同行业的项目,这里对测试人员就有着更多的要求,这里不仅仅是测试方法、理论知识的掌握、测试工具的熟练程度,更重要的是对行业应用领域知识的了解,会要求测试组所有成员对各部门的项目都要有个自己的概念,但是毕竟你不能让任何人都成为超人,根据测试成员的不同条件可有不同侧重的分工,互相协助工作。再一点,测试组搭建之初要以较高的姿态介入十分必要,公司的领导层和相关人员一定要保证在这一领域的强制性和权威性,为以后的工作模式流程提前做好规划。考虑到楼主公司的项目基本为对日软件外包的项目,具有其特点,本人接触的日本项目极其有限,测试方面只是停留在根据需求上的一些功能测试,和与日语翻译共同测试关于一些提示性文档和项目内部涉及到的语法问题进行维护。据我了解很体系的对日项目,很多规程都是由日方提供,具体的工作模式及管理制度除了坚持自己的内部观点外还要更多的考虑到日方提供的资源和要求。

  • 专心,专注,耐力,平心!

    2008-02-18 21:52:01

      人生其实很多事情都是相通的,但是要想做好点事情,首先要把自己状态调整到正确,而且心态是最重要的,至少现在我的状态不是很好,所以我如果想做好自己的话,首先要把心态调整,不能太着急,也不能太浮躁了,还要有耐心,其实我耐心是有的,但有时候莫名其妙就会受到外界影响而对一件事情失去耐心(工作一般不会)!

      第二:要把目标树立正确,其实是否正确很难判断(自己),如果实在判断不出来的时候,可以找个比你有经验的同事或者长辈聊聊,看看能有什么收获的时候在立自己的目标,如果已经确定的目标最好不要改动,要不会影响自己的士气!

      第三:那就是之前说的耐心了,目标已经明确了,那就是要自己有耐心坚持的去做完这件事情,不管遇到什么困难或者遇到什么事情的情况下都要完成这件事情!这样一件一件的做完后,你的自信心也会跟随你壮大,久了,你就会发现自己原来是这么的伟大! 哈哈

      第四:平心,做事情的时候要心平气和,不要动肝火,对身体不好,而且对做的事情也有不利的方面! 所以我们要养成做什么事情的时候,先想想,要先心平气和,对这件事情也能起到好的影响!

      告戒自己的四点! 切记切记

数据统计

  • 访问量: 7551
  • 日志数: 16
  • 图片数: 1
  • 建立时间: 2008-02-18
  • 更新时间: 2008-10-13

RSS订阅

Open Toolbar