1、System:%Total process time:

系统中所有处理器都处于繁忙状态时的百分比，对于多处理器来说，该值可以反映所有处理器的平均繁忙程度。

2、Processor %Processer time：

单个进程CPU利用率

3、System:Process Queue length:

线程在等待分配CPU资源所排队列的长度，此长度不包括正在占有CPU资源的线程。一般要<=处理器个数+1

4、Process:Private Bytes:

进程无法与其他进程共享的字节数量，该计数器的值比较大时，有可能是内存泄漏的征兆；也可以理解为只被本进程所占用的虚拟地址空间，不包含其他共享的内存。包含引起和不引起Page fault和引起Page fault的内存。

5、Process:Working set:

最近处理线程使用的内存页；或者称为一个进程可以用到但不一定会使用的物理内存，这个值也包含了其他进程也可以访问的内存，所以加起来会大于系统实际内存。只包含不引起Page fault的内存。

6、Process:Virtual Bytes:

一个进程可以占用的全部虚拟地址空间，32bit操作系统一般到2G，但可以通过修改Boot.ini扩展修改到3G

Private Bytes 一般大于 Working set ，任务管理器中看到的内存使用量一般等于Working set（实际测试时不等，待纠）

另外看内存泄漏的工具推荐使用VMMap和Proxp

以前跟人讨论有关软件开发中业务或技术方面问题的时候，总会说技术向来不是软件开发的难点，而且一直都很认同。但现在在**，随着性能测试工作的深入、DBA新鲜血液的加入、标准版逐步暴露出来的各类问题等的进展，这种观点逐步被打破，因为在目前的**，技术难点逐步被一 一暴露了出来。不是技术出身，也不是架构师，对于**系统架构了解很浅，所以，对于这块只能谈些**系统架构对于性能测试方面的影响之类的浅薄理解。

1、 多层加密和数据压缩以及非标准协议引起的第三方性能测试工作应用困难的问题：

加密的目的为了安全，压缩的目的为了效率，B/S是为了与时俱进，很多业界ERP或其他管理类软件的的产品性能测试用的是LR等专业性能测试工具，业界此类产品应该也考虑到了安全性、效率等各方面，人家能用起来，如果我们的系统架构提供支持，也是应该可以用起来的，这个支持意味着重构或方案重新选定，挑战不小。

2、 不支持数据库升级导致分析用户数据后通过脚本来实现构库困难重重：

目前之所以无法把**或以前**里面的数据导过来或者通过升级来实现，除了业务变更的影响外，还有就是**系统架构或者数据库以及表结构在变，导致无法处理升级；因为**比较年轻，以后的路还很长，用户的需求也会一直在变，系统架构随着业务变是不可避免的。这块对性能测试的直接影响就是数据怎么来？写脚本和构库花费大量的工作，不过这个目前倒是有方案，只是投入会比较多。以后**如果重构或新产品上线，在技术层面上这些应该都要纳入考虑范围的。

3、 **工具的继续开发维护被搁浅：

**是当初解决问题1的一个很好的东东，测试这个阶段也完善了一些对此工具的需求，如：

目前这块的需求被搁浅，其实这是个很好用的工具，借用业界第三方专业的性能测试工具的功能，当易用性及相关功能完善后，可以针对这段时间发生的各类问题设计一些测试场景，快速的发现一些问题，部分问题的复现有时比**要快捷多了，浪费了就可惜了。

**系统技术架构对于性能测试的影响分析跟业务架构相同，都需要经历逐步积累的过程，不经历不知道，经历之后才能改进，测试人员会跟上产品的步伐，与时俱进。

软件即服务，注定软件的开发过程是围绕所服务行业、公司或部门业务来转的；无论是需求分析、编码还是测试，任何一项脱离了业务，都是没有意义的。对于测试，脱离业务的测试，无论是功能还是性能都没有徒劳无功的。测试讲究Good-Enough原则，或者叫做适用性原则，过少的测试是不负责任的表现，过多的测试也是一种资源的浪费，在**，如何做到Good-Enough，关键点仍然在基于用户业务应用模式或者叫用户应用场景的分析。

功能测试我们已经做了很多年，从**到**，我们基于用户应用场景的分析尽量想做到覆盖全且精，测试人员通过与需求、产品、实施、运维人员沟通、直接去现场或电话、远程处理用户反馈问题等各种方式了解业务，这里的业务不仅包含需求文档里面能找到的东西，更多的是对于用户究竟如何应用以及可能如何应用的思考。但当**逐步需要支撑规模化应用，需要像业界ERP/CRM系统那样支撑大、中、小型企业级应用的时候，我们又有些迷茫，因为没有人，需求？产品？实施？销售，甚至即使是现有客户能够直接告诉我们：

要做更合理的性能测试，针对不同规模的企业级应用：

（1）    如何构造合理的数据库？

（2）    如何区分大/中/小型企业？如何区分大/中/小型项目？分别是什么样规模？分别如何管理及应用？不同规模的项目如何在系统中分布？不同的应用规模，对于业务的应用有哪些不同，或不同侧重点？

（3）    一个**系统，不同应用的规模，每天甚至每小时会多少个用户同时在线？分别在做哪些操作？每天或每小时一个人最多可以干多少活？（录入多少数据）

（4）    对于现有用户还没有应用起来或不稳定的业务，如生产，数据如何构造？

（5）    集团、公司、项目同时使用系统的角色比例情况如何？

（6）    哪些业务或模块、操作会被用户会经常使用？哪些是已经熟透的需求哪些还处于探索阶段？

…..

一系列的问题，均为**业务应用的范畴，对这些问题的解答来自于对客户应用模式的真正了解，不了解的情况下所做的猜测都是徒劳的，想不到要了解这些对管理类软件的长远发展的影响是可悲的。

对于**测试，接下来对业务的理解范畴，对于用户业务场景的分析，需要加入这些，这些不仅是对性能测试场景设计有用的逻辑，对于功能测试场景设计以及版本质量标准的定义，做到Good-Enough的测试，制定版本质量标准等等也是极具有指导意义的。

**还很年轻，我们逐步从分析用户应用日志、尽量找能了解一些的人沟通，找寻业界管理类软件测试等种种方式期望能发现一些马脚，相信后续的**，**业务，**测试，均会具有极其广阔的发展空间。

**业务分析与了解，我们，任重道远。