操作步骤:因为winsocket  协议录制的脚本输入的数据都被录入到data.ws里的,所以我是在data.ws里进行的参数化.右键选择要参数化的数据->选择"replace with parameter"->输入列名->在"parameter properties"进行了一些相关设置: ⑴在生成的文档里输入参数化数据 ⑵.select next row:unique ⑶.update value on:every iteration ->保存脚本. 

尽管我们的测试是需要按照一定的级别进行，但资源和时间是有限的，实际上我们不可能无休止的进行测试，因此在有限的时间和资源下如何有重点的进行测试是测试管理者需要充分考虑的事情。例如，在单元测试的时候，对于哪些函数我们需要重点测试，哪些函数可以粗略测试，哪些函数可以不测试；而对于系统测试，则要考虑首先应当保证哪些功能的测试，其次应当保证哪些功能的测试等等。测试的重点选择需要根据多个方面考虑，包括测试对象的关键程度，可能的风险，质量要求等等。这些考虑与经验有关，随着实践经验的增长，你的判断也会更有效。

本来我的arcgis用得好好的，不料由于系统崩溃只能重新安装。距离第一次安装半年多，忘得也差不多了，再装的时候出现过坛子里网友门遇到的大多数问题。花了我一天时间四处取经总算ok了！现在把重新安装的过程写出来大家分享分享，供大家参考。有不对的地方请大家指出，本来是盗版软件，跟电脑硬件、软件关系有一定个体差异。

1. 运行“regedit”进注册表，把arcgis或者esri相关的所有文件手动删除。如果是第一次安装可以跳过。

2. 在“我的电脑－属性－高级－启动－编辑”里将"=optin"改为“=alwaysoff”，确定，重启电脑。

3. lincense manager 安装：

3.1 Select "I received the license by fax" then click on CREATE & EDIT

    Enter "CATTLE WE LOVE YOU" & click on OK (ignore the following errors)click next and finish the installation

    此时别重启电脑

3.2 将破解文件中的 Licence.dat打开，并将“hostname”换成你自己的计算机名，例如：SERVER w2w ANY 27000，其中的w2w就是我的计算机名，切记，这里是计算机名，不是用户名。保存

3.3 将破解文件夹中的arcgis.exe & license.dat(该文件刚才已经编辑过)拷贝到License Manager的安装目录(如c:\program files\ESRI\license\arcgis9x) 覆盖原文件

3.4 启动并配置Licence manager。打开“开始菜单\程序\ArcGIS\License Manager (9.x)\License Manager Tools”，选择 “Configuration using Services”，接着选"ArgGIS license manager"，然后点“ Configure Services ”并设置license文件路径:“如c:\program files\esri\license\arcgis9x\license.dat” “path to lmgrd.exe file”不用修改 “path to license file”处点“browse”，文件类型选“*.dat”，然后选择license.dat即可；“path to debug log file”可以随便指定一个.log文件，不过最好在 License Manager目录下！选择“start server at power up & ues services”，点“save service”，最后，切换到 Start/Stop/Reread 并“start server”             在server diagnostics里点perform，如果显示“....can be checked out”表示安装成功。

4. ArcGIS Desktop安装，一路next，到Licence manager时，选择第一项；然后一路next，“complete”，等待安装完成，最后出来的三个玩意，根据自己需要选择安装。

5. 运行“开始菜单\程序\ArcGIS\Desktop Administrator”，选择“Licence manager”；点“change”，输入你的计算机名并“ok”

6. 进电脑属性高级里将“alwaysoff”改回“optin”，重启电脑。

arcgis应该可以正常运行了！

1.一定要有自己的人格、自己的思想。一个经过自己思考而坚持错误观点的人比一个不假思索而接受正确观点的人更值得肯定。不要成为灌输教育的牺牲品。
　　
2.仕途，商界，学术。大致说来，每个人都注定要走上三条道路中的某一条。在进行职业生涯规划的时候，不妨以此作为思考的出发点。根据不同的职业生涯规划来塑造各自的核心竞争力。只有知道自己以后要做什么，才能知道自己应该学什么。
　　
3.专业无冷热，学校无高低。没有哪个用人单位会认为你代表了你的学校或者你的专业。千万不要因为你是名牌大学或者热门专业而沾沾自喜，也大可不必因为你的学校不好或者专业冷门而自卑。
　　
4.千招会，不如一招熟。十个百分之十并不是百分之百，而是零。如果你有十项工作每项都会做百分之十，那么，在用人单位眼中，你什么都不会。所以，你必须要让自己具备核心竞争力。“通才”只有在“专才”的基础上才有意义。
　　
5.不逃课的学生不是好学生。什么课都不逃，跟什么课都逃掉没什么两样。一定要掌握学习的主动性，不要像读中学一样被老师牵着鼻子走。逃课没有错，但是不要逃错课。同时，既要逃课，又要让老师给高分。
　　
6.一定要学会理财。对于贫困生来说，首先要做的不是挣钱，而是省钱。很多大学生读书的时候一掷千金，可是，毕业以后一个月的工资还不够交半个月的房租。
　　
7.大部分女生将电脑当成了影碟机，大部分男生将电脑当成了游戏机。大学生要掌握必要的计算机操作能力，但是，很多时候电脑会成为浪费时间的堂而皇之的借口。有电脑的大学生非常多，可是，这中间很多人可能大学毕业的时候还不会Excel，不会做一个像样的PPT
　　
8.做事不如做人，人脉决定成败。一个人有多少钱并不是指他拥有多少钱的所有权，而是指他拥有多少钱的使用权。一个人具备多少能力，不只是说他一个人的时候能做什么，还包括他能通过别人做什么。一个人*的*，12.5%是靠自身的知识，87.5%则来自人脉关系。三十岁以前靠专业**，三十岁以后拿人脉**。所以，请好好珍惜大学期间建立起来的人脉关系。这几年你认识的朋友可能会是你毕业以后最可宝贵的财富。
　　
9.互联网固然威力无穷，但是，如果你沉迷于网络聊天，或者沉迷于网络游戏，浪费的金钱倒是可以弥补，荒废的青春就无可追寻了。轻舞飞扬已经红颜薄命了，而痞子蔡却继续跟别的女孩发生着一次又一次的亲密接触。对于很多大学生而言，网吧就是一个血淋淋的黑洞。
　　
10.爱情是不期而至的，可以期待，但不可以制造。花开堪折方须折，莫让鲜花败残枝。一个有一万块钱的人为你花掉一百元，你只占了他的百分之一；而一个只有十块钱的人为你花掉十块，你就成了他的全部。
　　
11.研究生扩招的速度是30%，也就意味着硕士学历贬值的速度是30%。千万不要以为考研究生就是积极进取的表现。对于很多人而言，考研不过是一种消极逃避的方式罢了。对于绝大多数人而言，读研究生纯粹是浪费时间浪费金钱，立志从事科研、学术的人及其他少数人除外。
　　
12.不要一门心思想着出国，更加不要迷信外国的月亮比中国圆。削尖脑袋记GRE词汇很可能是一件非常愚蠢也非常可悲的事情。既然全世界的公司都想到中国的市场上来瓜分蛋糕，为什么中国人还要一门心思到国外去留学然后给外国人打工？
　　
13.人才市场就是一个地雷阵。通过多种方式求职固然没有错，但是千万不要饥不择食。只要用人单位一说要你交钱，你掉头就走便是了。
　　
14.求职简历必须突出自己的核心竞争力。求职的时候大可不必像严守一那样“有一说一”，
必要的时候恰到好处地说一些谎言是非常有用的。一份求职简历只要用一张A4纸做个表格就足够了。很多女生的求职简历就像是写真集，不但浪费钱，而且对求职毫无用处。面试其实是有规律的，每次面试的时候只要背标准答案就行了……

15.垃圾是放错位置的人才。所以，在找工作的时候一定要把自己放到那个让你成为人才而不是垃圾的职位上。当然，前提是你要知道自己究竟想做什么、究竟适合做什么。

世界上最大的悲剧莫过于有太多的年轻人从来没有发现自己真正想做什么。骑驴找马固然没错，可是，并非随便找一头驴就能找到千里马。所以，一定要重视第一份工作。
　　
16.大公司是做人，小公司是做事。进入公司工作以后，必须尽快融入写字楼政治。职员能否得到提升，很大程度不在于是否努力，而在于老板对你的赏识程度。在写字楼的政治斗争中，一定要学会自我保护。（具体技巧就不多说了，书中每一条都说得非常具体）
　　
17.瘦死的骆驼比马大。撑死胆大的，饿死胆小的。一定要有创业的勇气和魄力。如果你一只满足于给别人打工，那么，不管你工资多高，永远都只能是一个可怜的穷光蛋。就算月薪2万，在深圳上海那种地方，一年的存款还买不来一个小小的洗手间。
　　
18.大学期间一定要多去图书馆多去自习室。很多书你现在不读，一辈子就再也没有机会去读了。虽然不是每本书看了都一定有用，但是，因为你不知道究竟哪本书以后会有用，所以只好多看书，并且抛弃那些过于功利的想法。尽管每次网到鱼的不过是一个网眼，但要想捕到鱼，就必须要编织一张网。

测试是一个过程它是为了证明程序在运行过程中是有错的。

我想很多同学在面试的时候都有过类似经历，某家公司通知你去面试，在你去了以后，公司会先给你一套题做笔试，然后才是面试。我也不例外，在此我想和大家分享一下我笔试时的答题情况和几个面试时常遇到的问题。

　　我那次笔试的时间大约是一个小时，估计其他的公司也都差不多。所以，你要先把握好时间的尺度，在整套题目中选择有代表性的来做。我当时大概做了四个大的题目吧。

　　记得第一道题是让写在工作经历中做的比较典型的一个模块的测试用例。拿到这道题的时候，如果对只有理论基础，而从没有接触过测试项目的人，肯定写不出来，不过我想大家和我一样多少都做过些项目，因为我们在新科海软件测试就业班学习的时候安排的有项目实战。当时我就根据那些项目经验，简单的写了十个吧，大概有功能、用户登陆等的测试用例。

　　第二道题是让你根据一副图来写测试用例，看到这样的题目后，你要结合文字提示来做，我当时那道题是一个工资单的查询，可以单条件查，也可以复查。这样一看，其实这就是一个有关工资系统的查询用例。我当时就是针对单条件和多条件查询来写，写了大概有15个用例，然后，就是在查询这一栏可以正确显示，实际结果就是正确显示，预期结果是可以正确显示。

　　第三道题，是写项目的测试过程。其实就是把你自己假设成一个测试经理，当你接到测试任务的时候，你如何安排和开展工作。有关这类的工作我觉得其实和我们在课堂上分组做项目的时候差不多。第一步就是接受测试申请后根据需求来写测试计划，然后根据需求写测试用例，在写测试用例的时候因为此时手头的信息所限只能写出一个大概，这些都没关系，可以在测试的过程中根据实际情况增加或者删减，进行完善。第三步，就是根据测试用例对软件进行测试，做bug记录，写测试报告，做初步的测试总结。最后，还要进行评估测试，还要再写一份报告，就是对这个项目做完后，你的看法是什么，符合不符合要求发布及交到客户手里。这些流程我们在课堂上都学过，不过是在实际工作中因地制宜的运用而已。

　　第四道题，就是谈个人对测试的想法，如何能很好的保证软件的质量。对这个问题的认识我想大家在选择到就业班学习软件测试课程的时候，和在学习的过程中经老师的引导已有了很好的认识。结合我自己的工作心得，无外乎还是那三点：首先，对于测试工作，你必须得认真、细致；第二，要有良好的表达能力，不论是书面文字，还是讲话，都要表达清楚。因为你测试完以后提交bug记录，或者向领导汇报工作，你都要能很好的表达出来。所以说很好的表达能力是很重要的。第三，就是要尽职尽责。如何能很好的保证软件的质量呢，你就是要好好的测试。

　　最后顺便提一下在面试时会遇到的几个问题：一、为何选择测试行业？二、你觉得自己是最适合做测试的吗？三、会使用哪些测试工具，工具间的区别。诸如此类的问题，只要大家对自己所掌握的知识充满信心，在面试的时候自信而诚恳的表现自己，这道测试路上最初的门槛就一定能越过！

　　教师点评：汪隽是个很用功的学员，而且领悟能力非常强。在软件测试班学习的时候，他就非常善于动脑子思考问题。老师讲了一个知识点，他总能再拓展为三四个知识点。这样的举一反三和很强的自学能力，都是进入IT企业所必须具备的素质。软件测试班的培训目标不仅仅是教会学员们一些技术和工具的使用，最关键的是通过艰苦的学习和项目实战，使学员养成自学和独立解决问题的能力。在IT企业的招聘过程中，应聘者的IT技能起到50%的作用，剩下的就看个人的职业素养、自学和解决问题的能力了。汪隽在以上的应聘考试中的情况很有普遍性，测试部门的考试题目，就是要考察应聘者是否真的很了解测试工作流程，是否有实际的测试经历，是否有测试用例的设计能力，如果应聘高级测试工程师以上的职位，还会考察应聘者是否有一定的测试团队管理经验。以上问题的回答比较到位，符合招聘公司选人的要求。汪隽经过自己的努力，已经成功就职于神州数码公司，我在此对他表示衷心的祝贺，希望他在今后的工作中始终跟踪测试技术发展趋势，不断的提高技能，与我们新科海学校软件测试班这个大团队一起成长，事业蒸蒸日上。

1.熟悉ESRI的ArcGis产品
  1.1熟悉ArcGis产品的体系结构
  1.2熟悉ArcGis服务器软件
2.ArcGis-server企业级gis服务器

3.参与ISO质量管理体系课程的培训
4.熟悉ISO 9000：2000 标准

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

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

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

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

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

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

1  测试团队中的“人”

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

1.1 不同类型的员工

l  老虎

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

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

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

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

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

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

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

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

1.2 不同类型员工的对策

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

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

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

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

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

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

1.3 团队成员的默契

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

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

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

2 测试团队的“规则”和“氛围”

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

  另外，“氛围”也是测试团队的一个重要因素。所谓测试团队的氛围，就是一种置身其中的感

前言：针对如何推进员工士气营造良好的企业氛围这一问题，TechRepublic成员提供了五个实例供大家参考。 

    1.比萨饼、炸面圈、幽默和警告：

    Dilbert-Tom 在我早期的IT职业生涯工作中，曾接触到一位优秀的经理。当一项“几乎不可能完成”的任务摆在整个团队面前时，经理认识到在非常短的时间内团队很难使用太多的规范从事开发工作；这位经理在随后的工作中设计了一种“系统下的附属系统”，通过使用最少的标准和规范进行专业化程序的开发。利用这种系统，我们的团队能够把一个庞大项目拆分成5 个项目同时进行开发，各自完成其独立任务，这花费原来时间的20%.显然，这是行之有效的一条捷径并能迅速突破时间限制的瓶颈。 

    正是这件事让我学习到，如何在白天工作中采取变通的方法更迅速的完成工作。同时，夜间为配合团队的整体工作进展只让少数员工随时待命，进行的一些修复和重新启动工作（通过电话联系，确保能够随时掌握项目进度）。 
 
    2.新技术产品：

    David Ford公司重新改组后难免会出现“士气低落”的现象，在此期间，管理应该集中于如何激发员工的士气方面。我们公司在解决这个难题时，采取了一种稳定人心的做法，他们购买了一种结合PDA 和移动电话的通讯工具发放给每名在职员工。于我而言，利用这个工具不仅能进行寻呼（比如公司方面的呼叫），满足私人移动电话的需要，而且能够方便地使用PDA 的各项功能。 由此可见，新技术产品确实能够博得人们的喜爱。了解并满足员工的实际工作需要，将更有效地激发员工的士气。 

    3.咖啡和谈话：

    bvitale为提高员工士气，我们设法在工作环境中营造出一种“Espresso Social ”的氛围。每隔四周或六周，办公楼的每个人都成为我们邀请的客人。下午三点下班以后，大家聚集在一起品尝咖啡糕点并友好的交谈。这种活动每次大概持续30分钟。由于办公楼大厅的空间不足，我们将活动设立在走廊附近。为表示对人们的尊重，每次活动通常都有预先的计划和安排，比如针对不同节日、民族团体、或取得成就举行的庆祝。活动中不时穿插演奏不同的音乐，包括：古典乐、爵士乐、酒会音乐、意大利音乐、西班牙音乐、德国音乐、印度音乐，等等。在这种愉快的氛围下，我们还经常将一些富有感染力的事情引入活动中，例如庆祝中国的传统中秋节；以及每年举办一次烘烤比赛和摄影比赛。 

    人们通过浏览我们的网页可以观看到聚会活动的相关照片。一张新照片上传到网上只需花费20秒钟的时间。同时，我们在网页上公布了一个电话号码，便于人们打电话询问是否有新照片的更新。每30秒钟浏览器会推出新的图片。利用这个简单的系统，可以使那些不熟悉多媒体视频会议（Video Conference）的用户也能参与到我们活动中来。 

   从我自身来说作为公司IT部门的一员，在参加公司举办的“Espresso Social ”活动后，我明显感受到活动所带来的深刻影响，我们整个部门的士气都显得焕然一新。
 
    活动结束后，每个人精神振奋地回到自己的工作岗位，并以更好的状态和心情投入工作。 

    4.激励机制:

    Tom Carlisle有效的激励人们的工作热情并非我的首创观点，我从内布拉斯加州奥马哈市的Bruce Botkin那里学习到一些实用技巧：首先购买一辆玩具卡车或拖拉机和一辆玩具赛车，然后向你的全体员工宣布相关规则： 

    只会有一名员工有资格获得这辆赛车，这是作为他良好工作业绩、不懈努力和乐于助人的一种赞许和嘉奖。这辆赛车将放置在获奖者的办公桌上，直到大家想要将它授予另一名有资格接受这项殊荣的人。此外，在颁发这辆赛车时，获奖者将向全体员工分享他的成功经验。 

    尽管都是玩具，但授予卡车的意义和授予赛车的意义并不相同。卡车必须由新的接受者亲自从目前拥有者的办公桌上取下，并放置在自己的办公桌上。授予某个人卡车的标准，意味着他的工作出现了问题或错误，暗示着需要用一辆卡车来激发他的智慧和才能。同样，当新的接受者从他的前任那里拿走卡车并放置在自己办公桌上时，他需要向全体员工陈述自己的失误并总结经验教训。需要注意的是，卡车的授予只能是通过自我提名方式进行，目的是激发员工勇于承认错误和总结经验教训。 

    概括地来说，通过授予赛车和卡车的方法可以让员工们获得两方面的宝贵经验：首先，授予赛车能够激励员工之间相互督促、相互学习的良好风气；其次，卡车的授予则能鼓励员工们保持开阔的心胸和诚实的态度，并且帮助其他人从自己的失败中吸取经验教训。 

    5.荣誉奖励：

    Prefbid II在过去几年中，我们公司设立了一个专门的“荣誉”计划。公司的任何一名员工或客户都可以填写并投出一张选票，注明他们认为值得表扬的某个人。选票最终由两名经理负责做出公正的统计，然后将其结果公告给所有员工。被推选出的优秀员工将获得一张支票作为奖励。如果一名员工在一年中多次胜出，那么他将有资格获得公司每年度设立的一项最高金额的奖励。 

    最初，荣誉这项奖励制度并未受到领导层的重视。公司的重大奖励往往是通过提供旅游、电脑等方式进行。直到CIO 建议管理者设立一些更有意义奖励项目。 
公司随后实施的奖励计划中，不再局限于只提供1000美元的旅行和电脑。一些与人们日常生活息息相关的事物被引入到奖励机制中，如：时钟、冷却器、热水瓶，等等。 
此外，在执行新的奖励计划中还遵守一条重要规则：即管理者不具备提名的资格。这是为了有效确保实际的荣誉奖励不会影响到领导者的管理水平。  这项奖励计划不足之处在于，卡片太小而且必须用手写填写选票。

  当同事们获得选票时，他们的欣喜和满足往往使其他人深受震撼。我也投出过许多选票，让我感到惊讶的是，当那些平时一贯保持稳重或缺乏活力的人们得到一张选票时，他们能够将这种喜悦延续很长时间。这像是在一场游戏中观看某人大叫“Bingo ”一样感到刺激。必须承认当得知CIO 对我投出了一张选票时，同样令我惊喜若狂（因为我作为一名主管本不应该得到推选，然而CIO 显然忽略了这一规则而将选票投给我。这意味着我的工作得到了他的认可和赞赏）。 

    对于项目经理来说，实施这种奖励计划并不适合。因为大多数项目经理的工作是分配任务，这将限制管理者对他们的工作进行评定。因此，评价项目经理工作业绩和荣誉的重要标志，取决于他们是否能与其他部门良好配合并顺利完成项目任务。 

    举例来说：我们公司前不久并购了一家相当大的竞争伙伴，我的工作是将IT基础设施进行合并和统一。尽管我一再安抚这家公司的职员不必担心被解雇的问题，但事实上并不能减轻他们的顾虑。与此同时，CEO 将一些合并方面的重要任务分配给我们。大家敏感地认为这似乎预示着将面临一个重要的转折。正如在所有项目中都存在情况一样，出现一次严重的错误就可能导致所有工作受到影响。人们相互推诿并指责对方的过错，竭力避免自己被看作是错误的制造者。通过大量地施加压力，最终我们修正了错误并按时完成了项目。然而，由于部门之间彼此认为应该由对方来承担错误责任，由此滋生出的不满和敌意情绪不得不令人感到担忧。 

    对于这种情形，我认为自己必须做点力所能及的事来缓和冲突。毕竟，我们还需要至少一年的时间共同致力于合并工作的开展。于是，我召集手下的项目管理人员坐在一起，每人推选出一位他们认为有资格获得荣誉奖励的员工，包括合并后的公司里所有参与项目工作的职员，以及被并购公司里所有为项目完成提供过帮助的非IT人员。随后，我们对接近80张的选票进行了统计。 

    通过这种做法，我们很快收到了令人感到满意的效果。员工之间相互指责和敌对态度发生了根本性转变，甚至开始主动要求负责团队的工作，他们的相互合作和共同努力使团队顺利地完成了接下来任务。

性能测试（并发负载压力）测试分析－简要篇
在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：
    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

分析的信息来源：
    •1 根据场景运行过程中的错误提示信息
    •2 根据测试结果收集到的监控指标数据

一．错误提示分析
分析实例：
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

  分析：
•A、应用服务死掉。
   （小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
   （应用服务参数设置问题）
    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
   (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
    1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:
    很高的换页率(high pageout rate);
    进程进入不活动状态;
    交换区所有磁盘的活动次数可高;
    可高的全局系统CPU利用率;
    内存不够出错(out of memory errors)

处理器：
    1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆:   
     很慢的响应时间(slow response time)
     CPU空闲时间为零(zero percent idle CPU)
     过高的用户占用CPU时间(high percent user CPU)
     过高的系统占用CPU时间(high percent system CPU)
    长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：
    1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :
     过高的磁盘利用率(high disk utilization)
    太长的磁盘等待队列(large disk queue length)
    等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
    太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：
SQL Server数据库：
    1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
   4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：
  1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
    快存（共享SQL区）和数据字典快存的命中率：
   select(sum(pins-reloads))/sum(pins) from v$librarycache;
    select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    自由内存：    select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
  缓冲区高速缓存命中率：
    select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ;
   
    Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 ：
     select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
   内存排序命中率 ：
     select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
   
    注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

转自51testing 发布时间: 2007-8-01 11:44    作者: Kiki    来源: Kiki的专栏

这一两年在浏览各大IT网站的人才相关栏目时，总能发现类似‘测试人员缺口大，未来前景好’的信息。着实让很多正在从事测试行业或即将要从事测试行业的同行们无限憧憬了许久。但日子天天的过去，很多测试人员也没看见自己的待遇有很大的改观，不禁也狐疑起来，真的是这样的吗？
        我是2001年进入测试行业的，可以说那时的国内测试还处于很初级的阶段，6年过去了，见证了测试行业的蓬勃发展，自己也由一个初级的软件测试人员升级成为了项目经理，从此也开始了人员招聘和人员培养的工作。这也成为了到目前为止我的项目经理生涯中最值得骄傲自豪的地方了（为什么呢？后面我会说）。
        在此，我要先声明，虽然我也曾在大公司做过，但毕竟作为项目管理人员是在小公司，为了避免不必要的争执，我此处提及的经验主要是小公司。而且从很多方面上看小公司确实和大公司在运作上有些区别，直接导致了在人才培养方面的区别。小公司一般人员配备远少于大公司，很多时候一个人要做两个或多个人的事情，但也正是由于这个原因，小公司的人相对独立的时间更短，学到的东西更多；小公司部门精炼，流程相对简单，培养的结果更高效。下面说说我的人才培养思路。
        1.人员配备－招聘刚刚毕业的大学生。本来这只是针对一个小项目的权宜之际，但没想到得到了不少甜头，当然也出现了一些问题。但相比较招聘有测试人员的成本和得到的收益，让我在以后的几年里都是招聘刚毕业的大学生。首先刚毕业的大学生，相对来说成本较低；虽然对测试可能一无所知（当然我们也有简单的面试去挑选一些有思想，仔细的学生），但是也正由于此，他们会更加积极的学习新东西，投入的工作。有些以前在大公司做过的测试人员，来到小公司以后，往往都喜欢比较，越比较越郁闷，导致工作没心情，直接影响了工作。
        2.人员早期培训－强化测试基本理论，讲解公司流程，并用以往有代表性的项目为案例快速进入测试。由于招聘的全部都是毕业生，还有些不是计算机专业的，所以就需要有效的培训让他们快速的了解测试。我们制定一套测试培训课程，有理论知识的讲解，公司流程的讲解，工作英语的培训，最主要的是选取一些以往的项目为案例进行培训，将以往出现的问题，经验告诉他们，以尽快的了解公司的运作，自己的角色及工作的内容等。
        3.工作中的培养方式－采用导师式培养。真正开始工作了，就需要自己多多的言传身教了。虽然多少知道了怎么做测试，但是测试过程中也会有许多异常情况，而且测试也有许多需要利用经验去发现错误的地方，所以在测试中多多的和测试人员一起工作，多多的沟通，有时测试人员测过的地方自己走一遍，看看有什么他们漏掉了没有，有的话就告诉他们，这样下一次他们就知道自己去发现此类问题了。这样相对成熟也会快很多。
        4.辅助活动－多展开讨论，项目总结或课题研究之类的活动。通过这些活动，不断的激发他们的求知欲，并且将成果又运用到工作中去，效果显著。出现问题的项目多多的总结经验，以确保下一次避免出现同样的问题。
        5.人员绩效评核－每个项目或版本结束时，做好项目中人员绩效评核。不要等到公司做评核的时候才去给你的测试人员做考核，因为那时你可能早就忘记了每个人在不同项目中的表现。所以最好在每个项目或版本结束的时候（那时也有充分的时间），可以伴着项目总结一起做一做人员绩效考核，记录结果，等到了公司评核的时候不至于又花脑袋回忆。当然如果有人表现突出，要及时的向公司提出。
        6.人员培养－重点培养项目中突出表现的人员。当发现有人表现突出，或有特殊的潜力时，应适时的调整工作或职位。这样才可以更有效的激发他们的潜能，更加的显现公平的原则。
        7.不要让你的团队成员失望。作为一个项目管理人员，尽可能的保证你的组员可以没有杂念的工作（当然，生活上的除外）。如果他真的做的好，为什么不尽力为他争取他应该得到的呢？
        经过这么几年的工作，招聘并培训的人不下于40个，虽然有的人离开了，有的人转行了，有的人继续深造了，有的人去别的项目了，但是他们的表现（不论是在公司，还是离开公司以后的表现）却是非常令我自豪。虽然刚开始会辛苦一些，但是随着培训机制的不断完善，人员的逐渐成熟，就会有那种看到自己种下的种子长成大树的那种欣慰。而且我还发现一个副产品，和他们年轻人在一起，自己也年轻许多呀，哈哈！

记得这个问题曾经到一家公司面试的时候一道笔试题目,哦,想起来了是"慧聪网有限公司",当时对自己的回答面试不是很满意.
现在从新整理了自己的思路来回答这个问题:
从需求角度考虑：
1、这个水杯的需求是什么？为什么要做这个印有广告的水杯，有什么要求？
测试时，先从对这个水杯的要求点进行测试；这时就出现了针对各个要求点的测试。

参考“我爱手机”中提到的一些测试点，假设，功能上的要求是：
1、这个水杯要印有广告，广告的位置、图片颜色、图片大小；
2、这个水杯要能装水，如：热水、冷水；
3、这个水杯是否要有手提，手提的样式是否有要求；
4、这个水杯的样式是圆的、方的、高的；厚度是否有要求，有什么样的要求；
5、这个水杯是否是透明的，制作材料是否有要求，有什么样的要求。

从用户友好性方面考虑：
1、这个水杯设计的是否方便清洁；
2、这个水杯是否耐摔；
3、这个水杯设计是否美观（从外观、颜色等）；
4、这个水杯在购买时，是否有详细说明它的制作材料和适用情况。

嘿嘿，每个人的思维有限，在测试的过程中，需要大家集体的思考测试点。这样才能想的更全。^_^

总结了一下在使用LR工具时使用不同的三种方式插入检查点，希望对大家有帮助。

检查点问题前提条件
插入方法1 （如图1） （图1）

在录制过程中选择要添加为检查点的文字，点选工具条上的红框所示图标（图１），即在脚本中加入了相应的检查点函数（文字检查点），当然你也可以通过菜单项NEW　STEP加入文字或者图片检查点（图２），还有一种方式就是根据服务器的响应信息添加检查点（图３），你自己在稍微了解一下图片和文字检查点函数的内容就行了，有问题我们再联系！

插入方法2 （如图2）（图2）

插入方法2 （如图3）（图3）

性能测试注意事项：

1．服务器端和客户端一定要同一个局域网内，否则网络因素会成为性能测试的瓶颈。

2．在性能测试脚本中要注意检查点的设置，否则都不清楚脚本是否真的成功执行操作。

3．设置参数化和关联是性能测试脚本调通的关键。

4．录制脚本时通常会包括一些think time,因此在回放脚本时，注意在runtime setting中设置忽略think time，否则会影响测试数据的准确性，如：响应时间的准确性。

5．尽量每个页面设置一个transcation,否则不知哪个页面最慢。

6．运行性能测试时在runtime setting中关闭日志功能，调试脚本时可以打开日志功能。

7．性能测试前的数据准备很重要：比如：系统数据库存在60000个用户和系统数据库存在60个用户，分别在两种情况下执行登陆性能测试，性能测试的结果也不会一样的。

8．在性能测试时用户登陆的用户名和密码，每个用户尽可能不要一样！

过程描述：

需求阶段：
形成基本稳定的需求文档后，测试介入需求评审，以便了解需求的相关内容以及测试工作的可行性分析（软件可测试性）。项目经理制定项目计划，测试部门测试
经理/测试团队负责人制定测试计划，项目组测试人员阅读相关测试需求文档，如果存在疑问或者发现需求缺陷及时与需求人员沟通，如果是需求缺陷，可以将相
关问题可以记录到bug管理工具以便进行跟踪。

设计阶段：
研发部门进行软件的概要设计、详细设计以及必要的单元测试工作；测试部门进行功能、性能测试用例的设计（用例不仅仅包括用例本身，还包括测试数据），测
试所需软、硬件资源申请、准备。用例编写完成以后，需求、研发的主要负责人、测试部门项目组相关成员组织对用例进行评审（验证当前用例是否能够达到覆盖
需求相应测试功能、性能点）。

测试阶段：
1.      每次提交新版本，必须提交测试项传递报告给测试负责人，并抄送给测试部门经理，（指出本版本提交的相应功能模块，测试环境，提供部署说明性文档
（目的：1.清楚当前测试的功能、性能内容；2.减少程序员和测试人员间重复性的沟通，方便其他测试人员对环境的部署工作）。
2.      开发人员在提交测试版本之前，需要对本次提交的功能模块做冒烟测试（保证本次提交的基本功能的实现且可用），测试人员在测试过程中如果发现版本错
误、提供的相应功能模块存在严重缺陷，导致后续工作无法进行时，有权将该测试版本打回。
3.      测试过程中按照测试用例执行测试，标记测试用例通过情况。如果进行了随机测试发现软件缺陷，需将该用例补充到用例中。测试过程中，发现缺陷后记录
到bug管理工具。

4.      测试工作完成后，测试负责人应提供测试总结报告，对测试过程予以总结，对遗留缺陷需要进行评审。评审人员包括：产品部门经理、产品经理、研发经
理、测试部门经理、测试主要负责人及其质控相关人员，对待有争议的缺陷综合考虑各方意见，符合测试计划的准出条件以后，产品可以做发行工作。