一个集合的一个或多个线程，准备好但不能够运行在处理器由于另一个活动线程正在运行的称为处理器队列。最明显的症状，一个处理器是一个持续或反复出现瓶颈两年多线程队列。虽然队列最有可能发展当处理器都很忙，他们可以发展时，利用远低于百分之90。这可以发生，如果请求处理器到随机如果线程需求不规则的时间从处理器。更多信息监测和调整线程调度，见“在瓶颈”在本章的后面。

该系统处理器队列长度计数器显示有多少线程准备在处理器队列，但目前不能够使用的处理器。图7.2显示了一个持续 处理器队列的利用范围从60到百分之90。注意，默认为处理器队列长度计数器的值是10。因此，系统监控图2线程队列长20。你可以改变比例因子使用数据在系统性能监测。

图7.2持续上升的处理器使用处理器队列

在图7.2中，该线在顶部代表处理器（_total）\ %处理器时间。低线系统处理器队列长度。

图7.3显示了一个持续 处理器队列伴随处理器使用在或接近百分之100。

图7.3持续处理器队列的最大处理器使用

图7.4说明了如何 处理器瓶颈干扰您的计算机的性能。结果表明，当一个处理器已经在百分之100的利用，启动另一个进程没有完成更多的工作。

图7.4饱和处理器

在图7.4中，黑色的线运行在顶部的图形处理器（_total）\ %处理器时间。下一行是系统处理器队列长度。中途通过采样间隔，一个过程的三个线程开始。该图说明了队列增加的结果，这增加了工作量。某些线程的过程可能是在队列中，或他们可能运行，有一个线程的优先级的进程流离失所。然而，由于处理器已经在最大容量，它可以完成没有额外的工作。

如果你的系统的计数器值出现类似于图 7.4，这表明一个瓶颈。测井，久而久之，就会发现任何模式与瓶颈。例如，您可能会发现瓶颈时发生的某些进程正在运行或在一天中的特定时间。在这种情况下，你也许能够消除瓶颈平衡工作量之间computers-that，运行过程中的另一个，少装电脑。

然而，如果持续队列中经常出现，你需要调查进程的运行时线程收集在队列。要确定这：

• 确定过程所消耗的处理器时间。确定是否一个或多个进程的过程是在一种积极的瓶颈。运行过程中出现实例当你选择过程\ %处理器时间计数器。更多信息，见“过程中的一个瓶颈”在本章的后面。

• 仔细研究密集的过程。确定有多少线程在运行过程中的观看模式线程的活动在一个瓶颈。

• 评价的重点在该进程及其线程运行。你也许能够消除瓶颈，只是通过调整基本优先级的进程或线程的当前优先级。然而，微软不推荐这样一个长期的解决方案。使用任务管理器找到基地进程的优先级。

注

不同的准则适用于队列长度的多处理器系统。在系统繁忙的（那些有处理器的利用率在80至百分之90范围），使用线程调度，队列长度范围从一个到三线程处理器。例如，在四处理器的系统，预期范围的处理器队列长度的系统，高活性是4 12。

在系统的低使用率，处理器队列长度通常是0或1 。

有其他物体跟踪处理器队列长度。服务器工作队列长度计数器报告数目的请求队列的处理器选择的服务器上的。更多信息监测服务器工作队列对象，见“网络性能监测”在这本书。

 

系统处理器队列长度计数器是一个粗略的指标，线程的数量，每个处理器是服务。处理器队列长度，有时被称为处理器队列深度，报告本计数器是一个瞬时值代表只有一个当前快照的处理器，所以它必须遵守本计数器超过一段很长的时间。此外，该系统处理器队列长度计数器报告队列长度为所有的处理器，每个处理器不是长度。

最佳处理器队列长度可根据不同处理器利用或其他因素如下：

• 在系统繁忙的经验处理器利用在80至百分之90范围和使用线程调度，队列长度范围从一个到三线程处理器。例如，在四处理器（4）系统，预期范围的处理器队列长度的系统，高活性是4到12。

• 在系统的低使用率，处理器队列长度通常是0或1。

• 系统运行的服务调度使用纤维，如微软® 服务器™版本7，典型的处理器队列长度将介于0和1，因为有一个单线程的处理器上，计划内的螺纹。（纤维调度时启用的轻型池”。）

如果处理器队列长度超过建议的价值在前面的列表，它通常表示有更多的线程，比目前的处理器可以服务的最佳方式。减少线程的数目或提供更多的处理能力，可以通过增加处理器或升级到更快的处理器，是可选的方法缩短处理器队列。

图10.2显示了一个长长的队列，在一段时间内，如处理器一直在容量。

图10.2的例子排队高处理器使用

当你开始看到排更长的队，监视器附加计数器缩节胺和中断活动，如下面的说明部分。

个人感觉很好,就转下来了

1）准备TestCase
        - 在进行自动化之前，将测试内容进行文档化，不建议直接录制脚本
        - 在录制脚本之前设计好脚本，便于录制过程的流畅
        - 由于测试用例设计和脚本开发可能不是同一个人完成，便于团队合作
        - 便于后期的维护
        - 文档化的方式：TD或者文档
 
2）配置QTP
        QTP支持不同的开发环境，在正式录制之前，需要根据被测程序的开发环境，选择合适的Add-In，并进行加载。
 
3）录制脚本
        启动QTP的录制功能，按照Test Case的操作步骤描述执行，QTP自动记录每一步操作，并自动生成VBscrīpt脚本。
 
4）修改增强脚本
        刚刚录制好的脚本可能包含错误，或者没有达到预期的目的，这就需要在录制脚本的基础上，进行修改增强
        - 删除录制过程中多余的以及错误的操作，以最少的脚本完成任务
        - 如果前面操作的输出是后面操作的输入，则需要使用变量或者输出值来进行替换
        - 不是所有的操作都可以通过录制产生的，有些需要通过手工编码实现这些功能
        - 录制产生的脚本是线性的，可以加入条件、循环控制语句，实现更复杂的流程
        - 对脚本进行结构化
        - 加入注释，便于阅读和维护
 
5）调试脚本
        - 回放通过的脚本，不一定是正确的，也可能会包含错误
        - 在测试脚本正式使用之前，要保证其本身的正确性
        - 避免测试脚本故障和被测程序故障搅在一起，不容易定位
 
6）回放脚本
        - 对于回放的错误，不要急于马上提交Bug，首先要判断是脚本本身的错误还是程序的错误，确认后再提交。
 
7）脚本维护
        - 随着工作的不断推进，脚本量会越来越多
        - 被测试程序的不断更新，也需要更新相应的测试脚本
        - 采用版本管理工具保存脚本，如CVS、VSS，可以随时获取历史版本
        - 采用统一的脚本架构
        - 采用统一的命名规范
        - 添加充分的注释，避免时间久了，自己都不能马上读懂脚本

Dim  user_name,user_pwd,status
user_name=DataTable("user_name", dtGlobalSheet)
user_pwd=DataTable("user_pwd", dtGlobalSheet)
Browser("用户登陆").Page("用户登陆").WebEdit("userId").Set (user_name)
Browser("用户登陆").Page("用户登陆").WebEdit("userPass").SetSecure (user_pwd)
Browser("用户登陆").Page("用户登陆").WebButton("登 录").Click
status= Browser("用户登陆").Page("通讯录").WebElement("D1").Exist(2)
If status=   "True"   Then
    Browser("用户登陆").Page("通讯录").Link("登出").Click
 Reporter.ReportEvent micPass,"用户名为："&user_name&",用户密码:"& user_pwd,"登录成功"
 else
  Reporter.ReportEvent micFail,"用户名为："&user_name&",用户密码:"& user_pwd,"登录不成功"
End if

 

 

上面使用到了 数据表的参数化  报告的优化等

来源：http://007.1010zz.com/blog.php?do=showone&uid=2&type=blog&itemid=7

作为测试人员，没有开发那样的工作成就感——在有些人的眼中，如一个系统，有很多的人在用，作为开发人员，她可以说：你看，你用的这个系统的XX的功能就是我开发的，说这句话的时候就有一种骄傲的感觉，使用软件的人耶向他投以敬佩的目光， 要是作为测试人员来说呢：她要是向使用这个软件的人说：你看，你用的XX功能就是我测试的；好的了，这句话要是说玩，或者还没有说完，这人就应该给你投了一个鄙视的目光，你说你还敢说嘛?，你还敢再在别人面前说你是做测试的吗？
测试的人啊，别别人更寂寞，更孤单：在公司中，如果公司的效益不好、或者是公司对测试的不重视，那作为测试人员更是倒霉，在你向开发人员报了一个bug后，遇到脾气不好的开发人员，就不不理睬你的bug，