前些日子看电视时看到一条新闻：上海福利彩票因为更新系统，导致上海福利彩票的销售终端在将近3天的时间内，无法进行销售。作为一名测试，我的第一反应是，这套系统在更新前后是否做过更新前后的数据，系统等等的兼容性测试？也就是在看到这条消息没多久之后，我们部门也在提交版本时发生了意外，幸运的是这个版本在最后部署到生产环境中去的过程中，更新人员发现了问题，及时得到了修正（我要说明的一点是，版本的测试已经在测试环境中通过，问题出在了数据库的更新脚本上）。这件事发生后，我一直在思考问题到底出在什么地方？

我想讨论的是“提升从搭建测试环境开始”，可能很多人很疑惑，这个题目似乎和我开头说的有点搭不上边，而我却不是这么看待的。我问过相关人员，你是怎么看待“搭建测试环境”这个事情的，你觉得你能从中学到什么？你觉得这个对你后面的工作有帮助吗？你觉得测试环境的更新除了替换版本外还应该考虑什么问题？很多人都会这么回答，我觉得能学到很多东西，但具体说不上来，对后面的工作有帮助，但具体有哪些帮助同样说不上来，测试环境的更新，除了保证更新成功外，似乎没有什么需要再考虑的了。

一个负责搭建测试环境的人的意识，如果不得到更进一步的提高，我想，生产环境中发生任何事情就变得不奇怪了（这里不探讨系统设计本身的问题）。

从搭建测试环境，我们到底能提升什么呢？

第一，             是更进一步的了解我们的待测试项目的系统架构。现在对我们测试人来讲的大环境中，测试介入项目的时间往往是项目即将完成开发进入测试环境的阶段。很多测试在拿到项目的后往往关注的是用例，执行，以及最后的结果，似乎没有更多的时间去考虑其他。对于为什么采用这么一个框架，可能很少关注，往往就是按照要求，把环境部署完毕后，联调成功，就算完成了第一步，然后就急急忙忙的开始我们的后面的工作。在我看来，这个是非常错误的，在部署测试环境的过程中，除了能更进一步的了解各个部分采用的技术外，在这个过程中，应该更多的了解一下，为什么会采用这样的方式。说直白一点就是，采用这样的方式的优势是什么？这么说可能还是有很多人不明白，我再举一个简单一点的例子把，我们现在有些项目会做成C/S的模式，有些项目是采用B/S的模式，为什么采用这样的模式？在比如B/S模式的系统中，有些必须考虑性能测试，有些则不需要，为什么？其实，通过部署的过程，你在了解系统设计的原理，你明白了这些，最后我们的用例必然会得到更多的充实。

第二，             更新过程中是否会对原有的数据产生破坏？大家必须注意到一点，测试环境和生产环境的最大区别在于，生产环境是一个延续性的行为过程，而测试环境则没有这么一个延续性行为过程，所以，作为测试环境的部署者，在部署环境的过程中要充分考虑到这个因素，什么样的更新版本才是符合要求的。这点我想可能能解决我开头提到的两个案例。

第三，             在部署中测试环境的复用。这点也非常的关键，资源的合理应用对于任何一个公司来讲都非常的重要，如果这个过程中忽略了这个问题，测试环境可能会变得非常的臃肿，对于维护起来可能会非常的困难。

今天下班的早，
本来想晚上出去活动活动筋骨，
可是风婆婆却不给我这个机会～
今天心情出奇的平静，
索性想起了我的柳宗全的《玄秘塔碑》
好久没有练书法了，
具体算算应该是好几年了。。。
时间过的真快呀。。。
“非静无以成学，非学无以广才”
多经典的话呀～～
耳边伴着《可尼的蝴蝶》
。。。。
《可尼的蝴蝶》好美
心里无比的充实与平静
。。。
写着写着，
我突然想起了小时候练书法的时候经常写的一个字“家”
可是，等我落笔完才发现，
时间好像过去了很久很久，
什么时候，我连“家”是怎么写的都忘记了。。。
现在自己马上将有个家了
不知道会把它“写”成什么样子
。。。。。
每个家庭都是一部小说，
作者不能只通过那些文邹的修饰让他显示与众
要用心写，才能使他深入每个读者的心里。。。：）
每个人一生都要写一部关于自己家的小说，
加油了：）

这几天不知道怎么搞的
早上怎么就是醒不来,
今天早上起来时已经8点十分了,
哎
也不是昨晚睡的晚呀,
睡的挺早的嘛
11点多就睡啦!
今天晚上再早点,
争取11点就呼呼了
明天早上说什么也6点多就起床
我!不!是!懒虫!!!!!
从昨天开始就和牛牛测试新疆的项目
前一大段时间都在看文档,
昨天今天做冒泡测试,
还好,不是很麻烦,
比上几个项目业务简单点,
可是今天让我很郁闷的一件事就是
我们公司的开发人员在新疆
跟他们沟通个问题都超级费劲
想想还是之前审计那个项目,虽说是在楼下
但也是在北京呀
好歹活动活动就把问题给说了,
这可倒好~~
哎,
是bug就提吧
不想那么多啦~
啦啦啦啦~~~

  在一份好的简历获得了面试的机会下，心情肯定是要激动一番，但不要忘了，人家给你机会面试，并不是确定这样就要你了。但有一点可以确定的是，至少你的简历已经符合了这个公司的要求。所以，还要复习一下自己的基础知识和准备要忽悠的“经历”。
    通常公司给面试通知至少会提前两天，那么这两天，就要“临阵磨刀”了，虽不快，但也亮呀！那么怎么来“磨”这个刀呢？
    一、上面说过了，公司给通知让你去面试，首先是你的简历是合格的，也就是你所掌握的知识和技能与公司的要求相符，那么主要针对就是简历上所写的内容进行巩固。尽量不要让面试官在简历的范围内将你问住，
    笔试注重基础知识，包括基本的概念、应用，
    面试，看你的技术，看你的能力、思维；
    二面，看你的人。（本人就经过这几次，有的公司更多，还有五次的捏...）
    就比如当初我面试中软国际的时候，我在简历上写的很保守，但是，笔试的时候有很多都是不在我简历范围内的，自然有的就没有答上；而面试时，面试官又彻头彻尾的考察，竟问到具体知识应用，工具的详细操作步骤，还问到数据调用了，我记得当时只有QTP参数化数据后那些数据保存在哪里，当时一紧张，没有想起来，其他的还好，不过那已经是超过我简历的水准了，可能这也是面试官同意我二面的其中一个理由吧。（后来偷偷觉得自己很幸运，面试的问题基本都是我会的嘿嘿～～）
    可是后来想想，面试官即使问到简历外的知识，你不懂的话，不要着急，他也许只是看看你的知识面，所以不要紧张，不懂就是不懂，不会就是不会，但要给人一种很好学很谦虚的样子，这样面试管就会认为你这个人很要强，很积极...
    二、再有就是考虑到当面试官问你在简历上“忽悠”的经验时该怎么办，如果你简历中写的“经验”属实，那么最好着重准备介绍下做过的项目，还有在做这个项目时运用到哪些知识和技术，都如何应用的。介绍项目的主要流程，如果“忽悠”的经验不属实，那么请准备“清笔一过”的语言，不要刻意强调，处于被动，问一句，“忽悠”一点，但一定要忽悠的得体，别到头来自己都不知道自己在说什么。（这纯粹是自己的经验，我面试的几个公司对我以前做过的项目都很“感兴趣”，问的也很仔细，这个要自己把握好度）
    准备好之后，面试前一晚上好好的睡一大觉做个甜甜的梦.....：）
（累了，改天再续～）

给别人打工，就是在给自己沉淀不给别人打工的经验！从最底层做起，从最基本做起！如何才能有这个机会？作为应届生来说，首先，一定要有一份自己独立的毕业设计，再一个，一定要把简历写好！因为它的好坏决定了你是否赢得去面试的机会！我只凭借自己的经验说几方面：
    一，简历，顾名思义，就是对个人学历、经历、特长、爱好及其它有关情况所作的简明扼要的书面介绍。
既然是简明扼要的介绍，那么我们就不能长篇大论的介绍自己近“几十”年的种种，也不能大过夸赞自己适应能力如何如何好，自己的性格如何如何好，自学能力多多强等等...抓住精华，一两句概括OK！看看面试公司有没有必要说明的条件，没有必要说明的一些与技术与学历无关的尽量不写。一定要遵循简洁！
    二，格式，个人爱好而已。但个人角度来看表格的方式不可取，乱，不明了；
    三书面语言一定要斟酌后再用，模糊的词语一定不要用，例如：比较了解SQL。这给人的概念很模糊。用人单位看你的简历主要就是看你技术知识究竟如何，是否符合他们的要求。这样一个比较了解，了解什么程度，了解数据库的哪方面？是设计开发还是维护？还是使用？这个了解，实在是太模糊了，这样的简历，用人单位是不会考虑请你去面试的；标点符号统一，使得书面整洁；联系方式等要写在明显的位置，这样有益于用人单位与你联系；
      用人单位选择应届生原因无非是，在应届中挑选出来底子好的，学习能力高的，不用花很多精力去培养的，而且给的工资不高，公司相对与成本低啊。那么他通过什么来判断应届生的能力依据什么来进行选择的呢？毕业设计就占了很大一个方面。毕业设计技术含量高，那么获得面试的机会相对来说就会高。应届生没有过工作经验的，凭借自己的能力在琢磨后，最好“写”上一个经验，这样会在同等环境下占取更大的优势！
    四，有些公司要求在简历上写明薪资的数目。不要写太多。薪资的数目要与你在简历上写的符合公司技术知识的范围来决定。例如一个广告设计的人去应聘软件开发。他广告设计的时候一个月5000，会的技术很多，平面设计，动画设计，制作3D等等，但是他来应聘软件开发，软件开发需要的是语言，需要的是软件开发技术，他如果还写5000，那他找不到工作，活该。简历上一个应届生，基础知识好，懂得的技术多，完全符合公司要求，但是薪资写3000，公司不要？那就开玩笑了！商人，永远做的都是对自己有利的事！他要的就是这种低成本，高回报的人！
    五，简历要准备多份，不同的公司要求的技术知识不同，如果想用一份简历涵盖所有的企业的要求，那就实在是太困难了！
    六，投简历，要有针对性的广投！个人认为在招聘网上写简历不如直接用自己的个人邮箱投，使用个人邮箱，标题要简单明了，如××－应聘软件测试－1年工作经验 (尽可能明了，让企业一眼就从N个简历中挑出来).正文处也可把你的简历直接复制进去，切记不要用附件形式，因为公司会当作是垃圾文件删掉的！
    （不好意思，快下班了改天有时间继续～～）

    毕业半年了，突然有很多感想，就把他们写出来，算是给自己一个经验的沉淀吧！
    刚迈出校门,可能会突然迷失了方向.因为我们之前在学校里,纵然也想过宏伟远大的理想,但在学校里,虽然会遇到各种困难,碰到
过很多的难题,但前面有导师帮你指明方向,身边有朋友助你解决难题,生活有父母亲人的照顾...等到真的踏出校门迈入社会,仿佛可
以支撑你的一切突然消失.前方的路不再有人为你指明,遇到困难要一个人顶着头皮去面对...当然我这里不包括那些家里条件好的,那
些家长为了不让孩子吃苦,在学生时期就已经把所有的路为他铺好!但如果是这样,那么我个人认为这样的孩子不幸福,并且可怜!财富
只有自己的双手创造出来,前途只有自己去开拓,这样人生才有价值!
    刚毕业的学生,至少我身边的朋友们,不再是以前那种大学生毕业"高不成低不就"的就业情形了,只要是正规的工作给多少钱我都
干!所以导致了很多学计算机的出来做销售,卖软件,卖电脑,卖润滑油,甚至卖方便面...
    也许是现在人民生活水平提高了,需求量增加了,导致销售方面特别缺人.注意,这里指的是人,而不是人才!所以,不管大学毕业,高
中毕业,甚至初中水平的人都来做销售!但这也不能排除有人学历低,卖东西又卖的好的.
    刚毕业就做这行其原因我想大多都报着"先就业再择业"的观念.但是
    朋友们,这个"先就业再择业"并不是就什么业都行,当然更不可能是择什么业都成!
    我建议:毕业前,在校期间就把自己以后的方向选择好,衡量一下自己的专业,兴趣,自己的专长和以后的理想,权衡得出自己努力的
方向.
    就拿计算机专业的来说.我们在大学学的这几年,书本厚实的从二楼下来能砸死人,说要在毕业找工作之前把所有知识都要搞定,一
般人来说有点难度.而且就算是我们把所有书本知识都搞定,也不见得能运用"聘场自如".所以,我们既要找到一份对口的工作,又不用
死读书,读死书的点灯熬夜那么就需要开发下大家自己的右脑.
    首先,大家可以在各大招聘网上搜搜现在用人单位需要的人才是如何的,需要此人才掌握什么知识什么技能.要有针对性的学习和
准备.
    应聘了几家公司后。个人总结出：现在用人单位最喜欢要的就是有经验.人品不赖,薪资水平要求又不高的人.所以呢，你如何把
自己推销出去，就是一门学问了。。。
  （由于时间关系暂且到着，如需更多请看下版）

分析以及监视场景在运行过程中， 可以监视各个服务器的运行情况（DataBase Server、Web Server 等）。监视场景通过添加性能计数器来实现。这一章非常的重要， 确定系统瓶颈全靠它了。下面重点讲讲需要添加那些计数器， 以及那些计数器代表什么意思。由于Win2000 Professional、Server 以及Advanced Server 提供的计数器不完全相同， 这里我们讨论将以Server 为基准。监视场景需要在Run 视图中设置然后， 出现添加计数器的对话框其他的操作就和控制面板“ 性能” 中添加性能计数器的操作一样， 这里不再详细说明。本章主要说明一下各个系统计数器的含义（ 数据库的计数器不做重点， 只是拿SQL Server2000 作为例子进行说明。因为数据库各个版本之间差异比较大， 请参考您使用的数据库系统的帮助）。

1 Memory相关内存是第一个监视对象， 确定系统瓶颈的第一个步骤就是排除内存问题。内存短缺的问题可能会引起各种各样的问题。 Object（ 对象） Counters Descrīption（ 描述） 参考值 Memory Available MBytes 物理内存的可用数（单位 Mbytes）。默认情况下IIS5.0 使用50%的可用物理内存， 作为IIS 的文件缓存（file cache）。IIS 基本占用 2.5 MB，每个附加连接将在此基础上占用 10 KB 左右 至少要有10% 的物理 Memory Page/sec Page Faults/sec Pages Input/sec Pages Input/sec Page Reads/sec Transition Faults/sec 物理内存的可用数（单位 Mbytes）。默认情况下IIS5.0 使用50%的可用物理内存， 作为IIS 的文件缓存（file cache）。IIS 基本占用 2.5 MB，每个附加连接将在此基础上占用 10 KB 左右。至少要有10% 的物理内存值当处理器向内存指定的位置请求一页（ 可能是数据或代码） 出现错误时， 这就构成一个Page Fault。如果该页在内存的其他位置， 该错误被称为软错误（ 用Transition Fault/sec 数器衡量）； 如果该页必须从硬盘上重新读取时， 被称为硬错误。许多处理器可以在有大软错误的情况下继续操作。但是， 硬错误可以导致明显的拖延。Page Faults/sec 是处理器每秒钟处理的错误页（ 包括软错误和硬错误）。Pages Input/sec 是为了解决硬错误页， 从硬盘上读取的页数， 而Page Reads/sec 是为了解决硬错误， 从硬盘读取的次数。如果 Page Reads/Sec 比率持续保持为 5， 表示可能内存不足。Pages/sec 是指为解析硬页错误从磁盘读取或写入磁盘的页数。 Page/sec 推荐00-20（ 如果服务器没有足够的内存处理其工作负荷， 此数值将一直很高。如果大于80，表示有问题）。这些计数器的值比较低， 说明Web服务器响应请求比较快， 否则可能是服务器系统内存短缺引起（ 也可能是缓存太大， 导致系统内存太少）。Page Input/sec 的值可以衡量出硬错误页发生的速率， 通常它的值会于或者等于Page Reads/sec。Memory Cache Bytes Memory Cache Bytes 文件系统缓存（File System Cache） 默默认情况下认情况下为50%的可用物理内存。如为50%的可IIS5.0 运行内存不够时， 它会自动整理用物理内存缓存。需要关注该计数器的趋势变化 Internet File Cache Hits % File Cache Hits %是文件缓存命中全部（ 对于一个Information File Cache 缓存需求的比例， 反映了IIS 的文件缓大部分是静Services Flushes 存设置的工作情况。而File Cache Hits 态网页组成 Global File Cache Hits 是文件缓存命中的具体值，File Cache 的网站）File Flushes 是自服务器启动之后文件缓存Cache Hits% 刷新次数， 如果刷新太慢， 会浪费内存； 如果刷新太快， 缓存中的对象会太频繁属于非常好！ 的丢弃生成， 起不到缓存的作用。通过File Cache Hits 和File Cache Flushes 可以得到一个适当的刷新值（ 参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize） Memory PoolPaged BytesPool Nonpaged Bytes Pool Paged Bytes Pool Nonpaged Bytes 这两个计数器监视服务器上各个进程的分页池字节数和非分页池字节数。 在访问数比较固定的情况下， Pool Nonpaged Bytes 是比较定的， 如果访问数逐步增加， 该值会缓慢的增加 Process Virtual Bytes Working Set 计数器 Virtual Bytes( 实Virtual Bytes 数器监视IIS5.0 保留的例inetinfo 、虚地址空间的数量， 实例化为inetinfo dllhost) Working Set（ 实例进程(IIS 运行的核心)和Dllhost 进程（ 隔离/ 连接池的应用程序必需的）。inetinfo 、dllhost） Working Set 计数器反映了每个进程使Dllhost#n 进程都用的内存页的数量。系统的内存页（pool 要添加计数器Page） 只能由操作系统的核心模块直接访问， 用户进程不能访问。运行IIS5.0 的服务器上， 负责web 连接的线程以及它需要的一些对象都保存在未分页的池中（nonpaged pool）， 比如文件句柄和socket 连接 Process Private Bytes 指这个处理不能与其他处理共享的、已分配的当前字节数 Memory Committed Bytes 是指以字节表示的确认虚拟内存。(确认内存是指为磁盘分页文件在磁盘上保留的空间以便在需推荐不超过物理内存的75% 要将其写回磁盘时使用) 推荐部超过物理内存的75％ 内存问题主要检查应用程序是否存在内存泄漏。如果发生了内存泄漏，Process\Private Bytes 计数器和Process\Working Set 计数器的值往往会升高， 同时Available Bytes 的值会降低。内存泄漏应该通过一个长时间的， 用来研究分析当所有内存都耗尽时， 应用程序反应情况的测试来检验。

2 Processor相关 Object（ 对象） Counters Descrīption（ 描述） 参考值 Sytem Processor Queue Length Processor Queue Length 是指处理列队中的线程数。即使在有多个处理器的计算机上处理器时间也会有一个单列队。不象磁盘计数器， 这个计数器仅计数就绪的线程， 而不计数运行中的线程。如果处理器列队中总是有两个以上的线程通常表示处理器堵塞 小于2。显示在由 Web 服务器所有处理器共享的队列中等待执行的线程数。处理器瓶颈会导致该值持续大于2 Processor %Processor Time CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%，则表示此测试的负载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 0 到 x 个实例 小于75%。排除内存因素， 如果该计数器的值比较大， 而同时网卡和硬盘的值比较低， 那么可以定CPU 瓶颈 System Context Switches/sec Context Switches/sec 指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。当正在运行的线程自动放弃处理器时出现上下文转换， 由一个有更高优先就绪的线程占先或在用户模式和特权(内核)模式之间转换以使用执行或分系统服务。它是在计算机上的所有处理器上运行的所有线程的Thread: Context Switches/sec 的总数并且用转换数量衡量。在系统和线程对象上有上下文转换计数器 如果切换次数到5000*CPU个数和10000*CPU 个数中， 说明它忙于切换线程而不是处理ASP 脚本 Processo %Privileged Time % Privileged Time 是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时， 此服务经常在特权模式运行， 以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit)， 例如页面错误或中断。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统保护模式之外， 还使用处理边界作为分系统保护。某些由Windows 为您的应用程序所做的操作除了出现在处理的特权时间内， 还可能在其他子系统处理出现 Time Switches/sec （ 实例化inetinfo 和dllhost 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（ 包括上面的一个）。增加线数可能会增加上下文切换次数， 这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高， 就应该减小线程字节池的大小 Processor Interrupts/sec %DPC Time Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断处理器一次， 形成了间15%， 则处理隔活动的后台 如果处理器使用率超过90％，且Interrupts/sec time大于15％则处理器可能负载过重，并发生中断 Processor Interrupts/sec %DPC Time 这两个计数器能够反映处理器用在处理中断以及推迟处理调用的时间。如果处理器使用率超过Interrupts/sec 指处理器每秒钟接收并维90% 且 硬件中断的平均值。正常的线程操作在中断时悬停。大多数的系统时钟每Interrupt Time 大于隔 10 毫秒中断处理器一次， 形成了间15%， 则处理隔活动的后台。器可能负荷过重， 并发生中断。判断应用程序是否存在处理器瓶颈的方法： 如果Processor Queue Length 显示的队列长度保持不变（>=2） 个并且处理器的利用率%Processor Time 超过90%， 那么很有可能存在处理器瓶颈。如果发现Processor Queue Length 显示的队列长度超过2， 而处理器的利用率却一直很低， 那么或许更应该去解决处理器阻塞问题， 这里处理器一般不是瓶颈。如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换（Context Switches/sec 显示的上下文切换次数比较大）， 那么就会占用大量的系统资源。如果系统的吞吐量降低并且CPU 的使用率很高，并且此现象发生时切换水平在15000 以上， 那么意味着上下文切换次数过高同时还可以比较Context Switches/sec 和%Privileged Time 来判断上下文切换是否过量。如果后者的值超过40%， 且上下文切换的速率也很高， 那么应该检查为什么会产生这样高的上下文切换。

3 网络吞吐量以及带宽 Object Counter Descrīption 参考值 Network Interface Bytes Total/se Bytes Total/sec 为发送和接收字节的速率， 包括帧字符在内。判断网络连接速该计数器的值和目前网度是否是瓶颈， 可以用该计数器的值和络的带宽相目前网络的带宽比较 改计数器的值和目前网络带宽相除，结果应该小于50% Web Servic Maximum Maximum Connections Maximum Maximum Connections ：“ 最大连接数” Attempts Total Connection Attempts ：“ 连接尝试总数” 是从服务启动时利用 Web 服务尝试连接的总数。该计数器应用于全部所列的实例。

4 磁盘相关 Object（ 对象） Counters（ 计数器名称） Descrīption（ 描述） 参考值 Object Counters Descrīption 参考值 Network Bytes Total/sec Bytes Total/sec 为发送和接收字节的速Interface 率， 包括帧字符在内。判断网络连接速度是否是瓶颈， 可以用该计数器的值和目前网络的带宽比较 Processo %Processor Time % Privileged Time CPU 使用率该计数器对应于处理器执行Windows. 2000 内核命令（ 如处理SQL Server I/O 请求） 所用时间的百分比。如果 Physical Disk 计数器的值很高时该计数器的值也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。 PhysicalDisk %Disk Time % Disk Time 指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大， 那么硬盘不是瓶颈。如果只有%Disk Time 比较大， 另外两个都比较适中， 硬盘可能会是瓶颈。在记录该计数器之前， 请在 Windows 2000 的命令行窗口中运行 diskperf -yD 。若数值持续超过 80%， 则可能内存泄漏。 PhysicalDisk AverageDisk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。 PhysicalDisk PhysicalDisk 指在此盘上读取操作的速率 PhysicalDisk Disk Writes/sec 指在此盘上写入操作的速率 判断磁盘瓶颈的方法是通过以下公式来计算： 每磁盘的I/O 数 = [读次数 + （4 * 写次数）] / 磁盘个数如果计算出的每磁盘的I/O 数大于磁盘的处理能力， 那么磁盘存在瓶颈。

5 Web应用程序这里以ASP.NET 开发的Web 应用程序为例进行说明。 Object Counters Descrīption 参考值 ASP.NET Applications Request/Sec Request Executing 每秒执行的请求数。 如果Request/Sec ApplicationsRequest Executing 当前执行的请求数。的值比较小， 你的Web 程序可能是瓶颈 ASP.NET ASP.NETRequestWait Time Request Executing Time 最近的请求在队列中等待的毫秒数。执行最近的请求所用的毫秒数。Queued 在理想状况下应该接近0， Request Queued 等候处理的请求数。该计数器应保持接近 0。超过 IIS 队列长度会出如果这两个值太大， 那么需要重现“服务器太忙”错误

6 SQL Server 这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。 Object（ Counters Descrīption 参考值 Processor %Processor time CPU 使用率 SQL Server: Logins/sec 这是每秒登录到 SQL Server 的计数 SQLServer:CacheManage Cache Hit Ratio (all instances) 显示在高速缓存中找到数据的命中率。如果数值持续小于 85%， 则表示内存有问题。 SQL Server General Statistics User Connections 显示当前 SQL 用户数。与 Active Server Pages：Requests/Sec 计数器进行比较， 可帮助了解脚本对 SQL Server 的影响程度。如果差别过大， 则表示测试脚本不能有效地对SQL Server 进行应力测试。 SQLServer:Locks Lock Waits/sec 显示在当前进程完成之前强制其他进程等待的每秒锁定请求的数量。如果该值始终大于 0， 则表示事务有问题。 SQLServer: BuffeManage Buffer Manager Hit Ratio 计数器值依应用程序而定， 但比率最好为 90% 或更高。增加内存直到这一数值持续高于 90%， 表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。 SQLServer SQL Statistics Batch Requests/sec 每秒收的Transact-SQL 命令批数。这一统计信息受所有约束（ 如I/O、用户数、高速缓存大小、请求I/O、用户数、高速缓存大小、请求的复杂程度等） 影响。批请求数值高意味着吞吐量很好。 SQL Server: Buffer Manager Lazy Writes/sec 每秒被缓冲区管理器的惰性写入器写入的缓冲区数。惰性写入器是一个系统进程， 其主要任务是刷新成批的老化的脏缓冲区（ 指包含更改的缓冲区， 这些更改必须写回磁盘， 才能使该缓冲区由其它页重新使用）， 并使之可由用户进程使用。惰性写入器消除了为创建可用缓冲区而频繁执行检查点的需要。 SQL Server: Buffer Manager Page Reads/sec 每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理I/O 的开销大， 可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法， 使开销减到最小。 SQL Server:Databases Transactions/sec 每秒为数据库启动的事务数 这里针对SQL Server2000， 而且只是列出比较关键的几个。更加详细的信息可以参考SQL Server 的联机文档。

 7 Network Delay 如果要监视的两台计算机在同一个局域网络内， 建议不要使用Network Delay Monitor。因为在同一局域网内，Network Delay 会非常的小， 网络监视器会有足够的时间在每秒钟内发送成百上千的请求， 这样会导致源计算机（source machine） 的CPU 和内存超负荷工作。默认情况下“Enable display of network nodes by DNS names” 选择是没有选中的， 因为选中它会明显的降低该监视器的速度。

7 分析实时监视图表这一章仅仅介绍几个最重要的图表。 Q1 事务响应时间是否在可接受的时间内？ 哪个事务用的时间最长？ 看Transaction Response Time 图， 可以判断每个事务完成用的时间， 从而可以判断出那个事务用的时间最长， 那些事务用的时间超出预定的可接受时间。 Q2 网络带宽是否足够? “Throughput”图显示在场景运行期间的每一秒钟， 从Web Server 上接受到的数据量的值。拿这个值和网络带宽比较， 可以确定目前的网络带宽是否是瓶颈。如果该图的曲线随着用户数的增加， 没有随着增加， 而是呈比较平的直线， 说明目前的网络速度不能够满足目前的系统流量。 Q3 硬件和操作系统能否处理高负载? “Windows Resources” 图实时地显示了Web Server 系统资源的使用情况。利用该图提供的数据， 可以把瓶颈定位到特定机器的某个部件。

8 经常遇到的问题

 8.1 VuGen的问题在使用VuGen 中经常会遇到的问题。

 8.2 Controller的问题在使用Controller 中经常会遇到的问题。 1. 在添加完Load Generators 机器时， 连接老是失败； 添加的机器明明已经安装了 loadrunner， 并且网络通讯正常。解决方法： 在安装loadrunner 的第七步骤， 应该选择第2 项， 如果选择了第一项， 就会有这种问题。重新安装一下即可。 2. 在VuGen 中运行良好的脚本， 到Controller 中运行却出问题。这种问题可能会遇到。为了确定问题出在Controller 中的场景，而不是脚本的问题， 你应该在所有的Load Generators 机器上使用VuGen 运行测试脚本， 确保都能够运行正确。因为VuGen 和Controller 运行的机制不一样。在VuGen 中运行时使用的是完整的浏览器， 而在Controller 中运行时使用的只是浏览器的基本的部分。

 8.3 计数器的问题在使用性能计数器中经常会遇到的问题。 1. 添加了Windows Resources 计数器后， 却看不到实时的数据。解决方法： 要得到监视的数据， 必须要在被监视的服务器（Web Server） 上获得管理员权限。最简单的方法是在“ 网络邻居”中以administrator 身份登陆Web Server。当然使用下面的控制台命令也可以：net use \\< 机器名> 然后登陆用户名和密码即可。（登陆的用户名必须具有管理员权限） 2. 添加了一些默认的性能计数器后， 出现了错误。解决方法： 可能是一些LoadRunner 默认的计数器在WebServer 上已经不存在的原因， 尤其是数据库的计数器方面。简单的解决方法， 就是删除有问题的计数器， 添加比较接近的计数器（ 可能需要参考Windows 帮助或者数据库的帮助）

9．结果分析根据不同的场景设计，配置脚本后进行测试得到如下结果测试环境 LMM: CPU：4x2.7G RAM:4G Websphere 5.0 + IBM Http Server 线程池：100 JDBC连接池：100 会话超时：30分钟 DS: CPU：4x2.2 RAM:4G Websphere 5.0 + IBM Http Server 线程池：100 JDBC连接池：100 会话超时：30分钟 DB&LDAP: CPU：2x2.2G RAM:4G Oralce 8.1.7 + LDAP 测试工具：Load Runner 7.8 用户数据：用户名test1 – test100； 口令与用户名相同。 测试用例1 测试场景描述用户登录的lmm模块，总共登陆24个用户，所有用户都同时并发操作。 用户点击“登记的教程” 用户点击“启动”，进行课程学习，进入DS模块在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。点击“返回LMS” 按钮，返回到lmm模块点击“退出”按钮，退出系统测试结果 LMM与DS模块CPU平均利用率在10%以下。LMM服务器CPU利用率峰值为20%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为7秒），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过5秒，所有交易成功。 测试用例2 测试场景描述用户登陆lmm模块，总共登录48个用户，每1秒登录1个用户用户点击“已登记教程” 用户点击“启动”，进行课程学习，进入DS模块在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习；点击“返回LMS” 按钮，返回到lmm模块点击“退出”按钮，退出系统测试结果 LMM与DS模块CPU平均利用率在5%以下。LMM服务器CPU利用率峰值为10%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为8%，其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户操作响应时间不超过3秒，所有交易成功。测试用例3 测试场景描述用户登录的lmm模块，总共登陆48个用户，所有用户都同时并发操作。 用户点击“登记的教程” 用户点击“启动”，进行课程学习，进入DS模块在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。点击“返回LMS” 按钮，返回到lmm模块点击“退出”按钮，退出系统测试结果 LMM与DS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为10秒），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过10秒，所有交易成功。测试用例4 测试场景描述用户登录的lmm模块，总共登陆48个用户，每秒同时登录10个用户。 用户点击“登记的教程” 用户点击“启动”，进行课程学习，进入DS模块在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。点击“返回LMS” 按钮，返回到lmm模块点击“退出”按钮，退出系统测试结果 LMM与DS模块CPU平均利用率在10%以下。LMM服务器CPU利用率峰值为10%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为2秒），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户平均操作响应时间不超过5秒，所有交易成功。测试用例5 测试场景描述用户登录的lmm模块，总共登录100个用户，每1秒登录一个用户。 用户点击“登记的教程” 用户点击“启动”，进行课程学习，进入DS模块在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。点击“返回LMS” 按钮，返回到lmm模块点击“退出”按钮，退出系统测试结果 LMM与DS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为10%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为2’20分钟），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户最大操作响应时间30秒，所有交易成功。测试用例6 测试场景描述用户登录的lmm模块，总共登陆100个用户，所有用户同时并发操作。 用户点击“登记的教程” 用户点击“启动”，进行课程学习，进入DS模块在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。点击“返回LMS” 按钮，返回到lmm模块点击“退出”按钮，退出系统测试结果 LMM与DS模块CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为3分钟），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户超时1个。测试用例7 测试场景描述用户登录的lmm模块，总共登陆200个用户，所有用户同时并发操作。 用户点击“登记的教程” 用户点击“启动”，进行课程学习，进入DS模块在DS模块中进行学习，过程包括：首先，点击一次课程结构树；然后，进行课程内容的学习。点击“返回LMS” 按钮，返回到lmm模块点击“退出”按钮，退出系统测试结果 LMM CPU平均利用率在20%以下。LMM服务器CPU利用率峰值为40%，其阶段为LMM处理多个用户同时的登录请求与点击“已登记教程”的学习课程查询。DS服务器CPU利用率峰值为100%（持续时间为5分钟），其阶段为DS处理多个用户单一登录验证和同时对课程结构树查询。用户超时108个。