Java的历史可以追溯到1991年4月，Sun公司的James Gosling领导的绿色计划(Green Project)开始着力发展一种分布式系统结构，使其能够在各种消费性电子产品上运行，他们使用了C/C++/Oak语言。由于电子产品种类繁多，运行环境各不相同，使得用这些语言进行开发的软件必须为不同的电子产品而专门设计，所以项目组疲于奔命，消费性电子产品软件环境的发展无法达到预期的目标，绿色计划也陷于停滞状态。

直至 1994年下半年，由于Internet的迅猛发展和环球信息网 WWW的快速增长，第一个全球信息网络浏览器Mosaic诞生了；此时，工业界对适合在网络异构环境下使用的语言有一种非常急迫的需求；Games Gosling决定改变绿色计划的发展方向，他们对Oak进行了小规模的改造，就这样，Java在1995年的3月23日诞生了！Java的诞生标志着互联网时代的开始，它能够被应用在全球信息网络的平台上编写互动性及强的Applet程序，而1995年的Applet无疑能给人们无穷的视觉和脑力震荡。

但没有相应的开发库而只靠Java语言来进行开发肯定是困难重重，所以Sun公司在1996年的1月23日发布了JDK1.0来帮助开发人员的开发。JDK包括两大部分：运行环境和开发工具。而运行环境包括五大部分：核心API，集成API，用户界面API，发布技术，Java虚拟机(JVM)。Java能够在信息网络时代快速发展，得益于它独特的组成结构，它并不直接被编译成所在平台的机器语言然后执行，而是先被编译成字节码，然后才到装有JVM的硬件上运行，所以它能够跨平台运行；而且，不是一定要使用Java语言来写程序才能编译成Java字节码，我们用C/C++/Javascript等语言来写程序也可以编译出JVM要求的字节码文件。在这个时期，人们使用最多的 Java API 无疑地就是 AWT，因为 JDK 1.0 时只有 AWT 称得上是一组完整的 framework，其它 Java API 都比较偏向个别的 class。

紧跟着，Sun公司在1997年2月18日发布了JDK 1.1。JDK 1.1相对于旧版本最大的改进，是推出了JIT(Just-In-Time)编译器。传统的JVM收到一道字节码指令后，解释成机器码，马上执行该机器码，然后丢掉该机器码，再接收下一道字节码指令……即便是以前执行过的字节码指令，依然需要重新解释成机器码才能执行。而JIT编译器会把常执行的部分先解释好放在内存，以后再次执行该指令时，不用再解释，直接从内存中取出机器码就可以执行了，这样提高了不少的效率。

在JDK 1.1时代，Java平台分为PersonalJava与EmbeddedJava，前者比较适用于运算资源和内存丰富的设备，而资源有限者适用于后者。这样的分类明显不符合时代发展的潮流，所以，Java平台处处蕴藏着新的翻天覆地的革命……

 J2SE 1.2的诞生与Java2时代三大革命

JDK1.2在1998年12月4日的隆重发布，标志着Java2平台的诞生。Java2的J2SE 1.2时代是一个大变革时代，它进行了如下的三大革命：

* 市场推广革命

在Java1.0或者1.1中，称API库为JDK，但为了方便市场推广，Sun公司在Java1.2版以后将JDK1.2改名为J2SDK，将Java改名为Java 2。在99年Sun公司还将Java2平台分为三大块：J2SE，J2EE，J2ME。这次市场推广革命顺应了网络急速发展的潮流，对Java2平台的发展起到了很好的催化剂的作用。

* API供应标准革命

而随着供应商的不同，Java的API分为三大类：

Java Core API：由Sun公司制定的基本的API，所有的Java平台都应该提供。这就是我们平常所说的Java核心类库。

Java Optional API：由Sun公司制定的扩充API，Java平台可以有选择地提供。比如， JFC以前是Sun对JDK的功能扩展，不是Java的公共规范。Java2平台则包含了JFC技术,不需要再扩展了。

特殊API：由特殊厂商或者组织提供的API。比如，美国法律对出口中国的加解密算法的安全强度有一定的限制，Java平台中不能包括一些安全强度较高的加密解密算法，所以部分其它国家的公司，如加拿大的BouncyCastle公司等，可以提供一些自己的安全API。

* API制定过程的革命

如果你有需求不能通过遵循标准的API来实现,可以向 www.jcp.org 提出制定新的API的请求,经过审核,你的请求可能被通过或者驳回;如果是被通过,则开始进入制定该API的程序。

J2SE 1.2时代进行的这些革命形成的制度一直沿用到现在,对Java技术的发展形成了深远的影响。

除了上述的三大革命，Java2 还支持并新增了许多新特性，最受追捧的当属Swing库。Swing 是轻量级 的 API，它不但有各式各样先进的组件，而且连组件风格都可抽换。Swing 出现之后，大家很快地就不太使用 AWT 了。但请不要以为 Swing 是用来取代 AWT 的，其实 Swing 是架构在 AWT 之上的， Swing 的出现只是减少程序员直接使用 AWT 的机会，而不会让 AWT 消失。Java2 还废弃了一些API，最重要的莫过于Thread类中对suspend(),resume()和stop()等方法的废弃。由于JDK1.1的集合类库中的Vector类和HashTable类都考虑了同步，在平常的使用中影响效率，所以Java2专门添加了对应的非同步类，并完善了集合类库。

Java2平台能够得到广泛的应用，还应归功于这个时期的一些优秀书籍，比如著名的《Core Java2》（卷一和卷二），该书随着JDK版本的变化已经出到第八版。

J2SE 1.3时代：寻找盈利和开源的平衡

Java2平台推出后，得到了市场的强烈反响，所以，在2000年5月8日推出的J2SE 1.3对J2SE1.2的改进，主要是对各种已有API的加强和对新API的拓展。

数字运算： 加入了java.lang.StrictMath,方便我们的一般的数字运算。

新的Timer API：相信大家对其中的java.util.Timer和java.util.TimerTask一定不陌生。

Collections包：??加入了一些新的API，方便我们的使用。

虚拟机停止钩子：J2SE1.3还加入了一个强大的功能，那就是虚拟机停止钩子(Virtual Machine Shutdown Hooks)，这个功能使得我们能够在虚拟机停止时完成我们自己的操作，比如关闭网络连接或者保存会话状态或者清除临时文件等等。

DNS服务：在JNDI接口方面，加入了一个DNS服务的实现。

Jini实现：J2SE1.3包含了一个Jini实现，这使得我们可以方便地把诸如打印机、摄像机和磁盘驱动设备插入现有网络中，并且能自动搜索已在网上的设备可以提供的服务并享用这些服务。

XML支持：由于计算机网络和XML技术的快速发展， J2SE1.3在Optional API中引入了Java API for XML包。

HotSpot虚拟机：J2SE1.3引入了HotSpot虚拟机。在solaris版的JDK1.3中，已经不支持传统的虚拟机，而windows版的JDK1.3同时支持传统虚拟机和HotSpot虚拟机。

从上面的分析可以看出，J2SE 1.3主要是对J2SE 1.2查漏补缺和拓展新的API。从应用领域方面考虑，J2SE 1.3已经涵盖了数据库、WEB、多媒体、网络、电话、影像、加解密、图形等等大部分的信息技术领域。

在这个时期Java2还有一个重要活动就是推出SCSL(Sun社区源代码许可)许可协议。Sun公司开放源代码项目的“女1号”Danese Cooper在1999年加入公司，负责Sun（包括Java）和开放源代码社区之间的协调工作。Sun一直尽可能在赢利和开放源代码之间寻求更好的平衡。

在J2SE 1.3时代，Java2平台得到了充分的发展，各大应用服务器在这个时代渐渐成熟并被广泛采纳，而Java2相关的培训和书籍更是如火如荼，《Thinking in Java》当属不得不推荐的一本。

性能改善达到巅峰的J2SE 1.4

J2SE 1.4平台的推出发生在2002年2月13日，由于此前在Java平台和.Net平台间发生了规模浩大的孰优孰劣的论战，而论战中，Java平台最大的缺点就是性能问题，所以J2SE 1.4平台把性能的改善放在了最重要的位置。

HotSpot虚拟机： HotSpot虚拟机能够很大程度上提高性能，所以J2SE 1.4已经不支持传统的虚拟机。现在，启动应用程序应该通过-client或者-server选项来启动，如果你还是通过-classic选项来启动，会收到这样的错误提示：”Error： Classic VM no longer supported。”

锁机制： 由于旧版的HotSpot虚拟机的锁机制会导制严重的性能和功能问题，J2SE 1.4已经改写了该锁机制。

安全API： Java Cryptography Extension(JCE),Java Secure Socket Extension(JSSE)和Java Authentication and Authorization(JAAS)这三大安全API从optional API移到了core API中。这样，J2SE 1.4的安全域(SecureRandom)实现可以利用操作系统提供的安全机制，以便缩短应用程序的启动时间。同时从optional API移到core API的功能还有XML处理API和JDBC2.0 API。

RandomAccess标记接口： 加入了RandomAccess标记接口，如果一个List实现了该接口，则表示它支持快速的随机访问，这样可以提高List访问的速度。

LinkedHashMap： 加入了LinkedHashMap，这是一个插入排序的Map实现，但它的运行速度和HashMap一样快。

反射： 很多产品中都要使用反射(Reflection)机制，但大家知道，反射是相当耗时的，所以，J2SE 1.4中重写了java.lang.reflect.Field、java.lang.reflect.Method.invoke()、java.lang.reflect.Constructor.newInstance()和Class.newInstance()等方法，使得我们利用反射也能写出高性能的应用程序。

64位计算： J2SE 1.4支持64位计算。64位支持使J2SE 1.4可以使用超过几百GB的内存，而以前的版本仅可以使用4G以内的内存。内存使用的扩大可以提高程序的运行效率。

新的I/O API： J2SE 1.4在API层面最大的变动，就是它更新了原有的java.io包，以及加入了一组更有效率更多功能的新的I/O API。旧的I/O处理是以串流(stream)的方式来存取的，以字节为单位，而新的I/O处理是以块(block)的方式来存取的。一个块可能包含了512字节，而磁盘的存取本就是一个块一个块来进行的，所以新的I/O处理方式对于底层底数据存取更自然更有效率。

断言和日志处理： J2SE 1.4版本在Java语言层面上加入了断言（assert关键字），在API层面上加入日志处理API，这些为程序的调试提供了强有力的支持 。

从上面的分析可以看出，Java 2平台在经过数年的发展后，已经比较成熟稳定，J2SE 1.4主要是对平台的性能进行较多的考虑和修改。在分布式程序方面，1.4版比1.3版的运行效率提高了一半以上；而在客户端程序方面，1.4版比1.3版的效率提高了1/3。当然,除了考虑运行效率，J2SE 1.4还有其它方面的改进，如推出了一个全新的运行Java应用程序的方法Java Web Start，该方法克服了Java Applet的安全性限制的问题和Java Application的软件发布难的问题，并结合了上面两种方法的好处，为Java软件客户提供了非常友好的使用体验。

J2SE 1.4版是J2SE 第一个参与了 Java共同体过程(JCP)的J2SE 版本。 象Borland、Compaq、Fujitsu、 SAS、 Symbian、 IBM这样的公司，和Sun一起定义并发展了J2SE  1.4规范。在开放、良好的文档编撰与管理的过程中，形成了一个高质量的、代表了Java共同体的多样性的规范。J2SE 1.4的Specification Lead是Doug Kramer。Doug Kramer是优秀的Java开发人员和著名的教育培训专家，他同时还是J2SE 1.4.2的Specification Lead 和J2SE 1.5的JVM的Specification Lead。

改名换姓：意义深远的J2SE 5.0诞生史

在2004年十月J2SE 5.0发布的时候，SUN公司这样解释这次版本名称不是J2SE 1.5而是J2SE 5.0的原因：“从Java诞生至今已有9年时间，而从有J2SE 算起也有5个年头了；在这样的背境下，将该版本号从1.5改为5.0可以更好的反映出新版的J2SE 的成熟度、稳定性、可伸缩性、安全性。”

J2SE 的这次变更之重大和意义之深远，的确也值得我们为之把版本号变换到J2SE 5.0。我们再看看Sun公司网站对J2SE 5.0的features描述：“通过增强Java平台的力量，允许开发者更容易地使用，Java编程语言的这些改进将吸引大量各种Java开发者”，这是“Java技术发展历程的一个重要里程碑” 。从这个描述我们可以看出，J2SE 5.0最大的目标是通过提供易用性而吸引各种开发者(当然包括以前的C/C++开发者) ，而它对以前版本的修改并不仅仅是API的升级，而且包括对Java语言层面的改进。

访问环境变量： 最初的Java语言有一个访问环境变量的方法System.getenv()，但因为Java宣称的”Write Once,Run AnyWhere”特性，所以在JDK1.0中去掉了这个能够访问平台专有信息的方法。在J2SE 5.0中，它又来了，并有所扩充。由此可见J2SE 5.0对编程方便性的重视程度。

泛型 J2SE 5.0提供了强大的泛型机制，让程序员可以减少代码重复，这个变化应该可以吸引小部分的C#开发人员吧。

增强的for循环 为了克服普通for循环的代码臃肿特点，J2SE 5.0提供了增强的for循环，我们现在可以这样写一个for循环：

public void printAll(Collection< String> coll)  
{  
for(String str : coll)  
{  
System.out.println(str);  
}  
} 

怎么样？是不是简单了很多？

自动的装箱/拆箱 我们以前手工的做装箱(Boxing)/拆箱(unBoxing)操作时，是不是很烦?放心，J2SE 5.0提供了自动的装箱/拆箱操作，我们现在可以写如下的代码：

public void boxing(int i)  
{  
ArrayList< Integer> list=new ArrayList< Integer>();  
list.add(0,i);  
System.out.println(“i的值是”+list.get(0));  
} 

可变参数数目 J2SE 5.0 开始支持Varargs(不固定自变量个数)，J2SE 5.0中还加入了以前抛弃的枚举和C风格的格式化输出，这应该是为了吸引以前的C开发者吧。毕竟,在C开发中枚举和格式化输出用的是太多了。

并发 J2SE 5.0中加入了java.util.concurrent包，并向集合框架中加入了Queue接口，J2SE 5.0还为各种集合提供了并发情况下的实现。
Properties类增强 由于XML的普及性应用，J2SE 5.0为java.util.Properties类加入了从XML文件中装载属性和把属性值存储到XML文件中的方法。

Annotation功能 J2SE 5.0提供了注解(annotation)/元数据（metadata）功能，相信以后的大部分应用产品都将充分利用它的注解而实现产品的各种特性。

其它 J2SE 5.0还在多线程（并发机制）、安全、国际化、UI等方面进行了大规模的变更，使得我们能够更方便地进行Java开发。

其实，上面的这些变更，并不是我们程序员非要不可的内容。我们完全可以通过自己的办法来达到这些变更实现的功能。但J2SE 5.0的目标就是让我们程序员能够更加方便地进行开发，所以，我们在基于J2SE 5.0开发时，应该能够明显的体会到它的易用性。

黄瓜减肥有成效， 抑制癌症猕猴桃。

番茄补血助容颜， 莲藕除烦解酒妙。

橘子理气好化痰， 韭菜补肾暖膝腰。

萝卜消食除胀气， 芹菜能治血压高。

白菜利尿排毒素， 菜花常吃癌症少。

冬瓜消肿有利尿， 绿豆解毒疗效高。

木耳搞癌散血淤， 山药益肾浮肿消。

海带含碘散淤结， 蘑菇抑制癌细胞。

胡椒驱寒兼除湿， 葱辣姜汤治感冒。

鱼虾猪蹄补乳汁， 猪肝羊肝明目好。

益肾强腰吃核桃， 健肾补脾吃红枣。

如果你希望在5年内、3年内甚至1年内使你的薪水加倍，必须先使你的生产力加倍，然后薪水加倍的美梦才可能成真。

如何使生产力加倍呢？美国生涯规划与时间管理专家Brian Tracy，集20年实务工作经验与研究，发现了使生产力加倍的七个工作秘诀：

一、全心投入工作

不要浪费时间，不要把工作场合当成社交场合，把头完全埋进工作里，如果你能长期实践这个秘诀，就能使你的生产力加倍。

二、工作步调快

养成一种紧迫的习惯，一旦投入工作，维持一种快速的习惯，一旦投入工作，维持一种快速的节奏，一次专心做一件事，并且用最快的速度完成。一件工作完成之后，立刻进入下一件工作。养成这习惯后，你会惊讶的发现，一天所能完成的工作居竟然是如此的惊人。

三、专注于高附加价值的工作

要记住工作时间的多寡，不见得与工作成果成正比例。精明的老板和上司，他们关心的是你的工作数量及工作品质，工作时间并非关切的重点。因此，聪明的员工会想办法找出对达成工作目标及绩效标准有帮助的高价值活动，然后投入最多的时间与心力在这些事情上面。投入的时间越多，每分钟的生产力就越高，工作绩效也越高，自然会赢得上司的赏识与重用，加薪与迁升必然在望。

四、熟练工作

当你找出最有价值的工作项目后，要通过不断的学习、应用、练习，直到熟练所有工作流程与工作技巧。当你工作愈纯熟，工作所需的时间就愈短，你就可以比经验不足的同事，更快完成相同的工作。

五、集中处理

一个有技巧的工作人员会把许多性质相近的工作活动，如收发E-mail、写信、填写工作报表、填写必忘录等等，集中在同一时段来处理。这样会比分开处理节省一半以上的时间，同时也能集中注意力，提高工作效率。

六、简化工作

尽量简化工作流程，将许多分开的工作步骤加以整理，变成单一任务，以减少工作的复杂度。另外，运用授权或是外包的方式，避免花费时间去做低价值的工作。

七、比别人工作时间长一些

早一点起床，早一点出门去办公室，避开早上的交通高峰时间；中午晚一点出去用餐，继续工作，避开中午排队用餐的人潮；晚上稍微留晚一些，直到交通高峰时间已过，再回家。如此一天可以比一般人多出2~3小时，而且不会影响正常生活的生活步调。善用这些多出来的工作时间，可以使你的生产力加倍，进而使你的薪水加倍。

版本验证测试 (BVT) 也称为"冒烟测试"，通常由一组广泛的测试组成，这些测试用于验证特定版本的总体质量。 BVT 通常根据设定的计划自动运行，经常在夜间进行。也可以手动运行，例如自动运行失败后。如果 BVT 中的所有测试均已通过，则认为该版本成功。就是拿到一个软件，首先不急于完全测试，而是在很短的时候内把软件的基本功能走一遍，看有没有什么大的问题，如果存在大的问题，就没有必要再进一步测试了。可以节约时间，提高测试效率。

冒烟测试，也有称作烟雾测试（smoke Test):一种用于验证系统基本功能的实现并达到一定程度的稳定性的测试。这种测试经常用作进入下一个等级的测试的入口准则的一部分。关于冒烟测试，应该是微软首先提出来的一个概念，和微软一直提倡的每日build有很密切的联系。具体说冒烟测试就是在每日build建立后对系统的基本功能进行简单的测试，这种测试强调功能的覆盖率，而不对功能的正确性进行验证。从这一点看和所谓的“接受性（验收）测试（Acceptance Test）”非常相似。不同之处就在于他们执行的频率和被测的版本不同。 至于冒烟测试这个名称的来历，大概是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟在进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正，测试人员测试的版本必须首先通过冒烟测试的考验。冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。

BVT测试内容：

单元测试，使用白盒测试，设计用例是针对详细设计文档产生的。

集成测试，设计用例是针对概要设计说明书产生的。

系统测试，设计用例是针对软件需求规格说明书产生的。

验收测试，测试用例正常情况下应该由客户给出，由客户进行验证，以便下结论是否可交付。

BVT测试的特点：主要是针对主体功能及各入口点，时间短，测试用例也只有正面的，负责人一般式项目经理或者技术经理。

何时应该进行BVT测试：从上面的BVT测试介绍中可以看出来，bvt测试当然是测试的次数越多越好，但是针对现实情况，测试部要求在送测之前，程序在vss上打了基线，然后项目经理或者技术经理从vss上拿下最新的版本，然后做bvt测试，如果测试通过，则才可以填写送测单，并将bvt测试情况写在其中，如果vbt测试没通过，则需要修改bug，然后重新打基线，从新做bvt测试。bvt通过的要求并不是说所有的bug全部都改掉，而是没有重大的bug，允许有小bug的存在。

bvt测试，以及测试用例的编写，都是需要时间成本的，故在最初制作项目计划时，就应该识别该任务，并充分考虑其工作量。

bvt测试用例，应该随着系统的不断扩展而不断扩展，它不应该是一成不变的。

bvt测试应该包含的内容：

1、业务流的测试，保证正常业务链路的通畅。

2、工作流的测试，主要是测试流程流转是否正常，至于流程步骤的表单内容是否正确则不关注。

3、关键功能的测试，至少要保证系统运转所需的启动数据，以及一些开关控制正常。

4、重要基本功能的测试，比如对核心业务有影响的一些增删改等。

bvt测试的过程：

1、各单元测试通过

2、打版本

3、拿最新版本

4、根据部署文档部署，尽量与用户环境一致

5、执行bvt测试用例

6、bvt测试结束后，如果成功，则填写送测单，并在送测单种写明bvt测试结果；如果不成功，则修改bug，重新进行bvt测试。

Examining Processor Time Data:
On multiprocessor systems, the Processor\% Processor Time value reported by System Monitor will never exceed 100 percent for any particular processor or thread. On the other hand, the value of the % Processor Time reported for the Process object can report values over 100 percent; if such values occur, this could indicate that threads of the process are cumulatively using more than 100 percent of a processor. To get more detailed information, use the Thread object counters to analyze the processor time each thread within a process is using. Investigating other data described in this section, such as DPC activity or context switching, might help you to interpret high processor-time values.
多处理器系统中，由系统监视报告的处理器Processor Time%值对任何个别处理器或线程不会超出100%。另一方面，进程对象Processor Time%报告值能超出100%，如果超出就意味着该进程的这些线程在累加地超出100%使用一个处理器。要得到更详尽的信息，使用线程对象计数器去分析该处理器在一个进程里使用每个线程的时间。调查在这部分描述的其它数据，如DPC活动或上下文切换，可能会帮助你去解释高Processor Time%值。

% Processor Time(Processor_Total)
指处理器用来执行非闲置线程时间的百分比。计算方法是:度量处理器用来执行空闲线程的时间，然后用100%减去该值。(每个处理器有一个空闲线程，该线程在没有其他线程可以运行时消耗周期)。此计数器是处理器活动的主要指示器，显示在采样间隔期间所观察的繁忙时间平均百分比。应注意，对处理器是否空闲的计算是在系统时钟的内部采样间隔期间(10ms)执行的。考虑到现在的处理器速度非常快，因此，在处理器可能会用大量时间为系统时钟采样间隔之间的线程提供服务时，% Processor Time 会低估处理器利用率。当恰好进行采样后即向计时器发出信号时，更可能对应用程序做出不准确地度量，基于工作负荷的计时器应用程序是一个这样的示例。

%Processor Time (Process _Total)
是所有进程线程使用处理器执行指令所花的时间百分比。指令是计算机执行的基础单位。线程是执行指令的对象，进程是程序运行时创建的对象。此计数包括处理某些硬件间隔和陷阱条件所执行的代码。

多处理器系统中，对任何处理器或线程，系统监视器报告的Processor\% Processor Time值不会超出100%。另一方面，进程对象(也就是Process)Processor Time%值能超出100%；如果超出就意味着该进程的线程累计使用超出了一个处理器的100%。要得到更详尽的信息，使用线程对象计数器去分析在该进程中每个线程的Processor Time%值。调查在这部分描述的其它数据，如延迟过程调用(DPC)活动或上下文切换，可能会帮助你去解释高Processor Time%值。

1.“\Process(…)\% Processor Time” can go up to N*100 (where N is the number of CPUs) because it adds up the CPU usage of the requested process across all the CPUs.
2.“\Process(_Total)\% Processor Time” should always be around N*100 (where N is the number CPUs) because it adds up the CPU usage of each process, including the idle process.
3.“\Processor(…)\% Processor Time” can go up to 100 because it’s the CPU usage of the requested CPU.
“\Processor(_Total)\% Processor Time” can go up to 100 because it’s the average CPU usage across all CPUs.
Processor(_Total)\% Processor Time

This counter gives the total processor utilization figure for the server as a whole. For example, on a dual processor system with one processor pegged out at 100% utilization and the other processor standing idle, a figure of about 50% would be recorded.

This server metric is useful for gauging overall how busy a server is or, put in another way, how much spare capacity there is available (by subtracting from 100%).

If per-processor information is required to be monitored by Resource Manager, then additional server metrics may be configured for monitoring:

Processor(0)\% Processor Time

Processor(1)\% Processor Time

... etc.

(See the Resource Manager Administrator’s Guide and the help within the Presentation Server Console for information on Customizing Server Metrics).

Process Processor Utilization

In addition to monitoring server metrics Resource Manager also monitors process activity; one aspect of process activity monitored is the degree to which the processor(s) is being used.

Processor usage of each process on the server is sampled at regular intervals using a standard operating system call - note that the operating system call used returns the sum of processor time used by all threads within the process. Resource Manager expresses the processor time used during the sampled interval as a percentage by dividing this time by the elapsed time since the previous sample.

On a multi-processor system it is quite possible for the percentage reported to exceed 100% in the case of a multi-threaded process. For example, on a dual-processor system, a multi-threaded process in which two threads are performing lengthy processor intensive calculations would cause a value of about 200% to be recorded.

This process-specific processor utilization is useful for gauging the state (and possibly health) of the process; if a process which normally uses little processor time is seen to be consuming a figure approaching 100%, a likely explanation is that it has encountered a bug which has caused it to enter an uncontrolled looping state.

原文：http://www.51testing.com/?27242/action_viewspace_itemid_77655.html

翻译：skinapi

前言
因为已经带领和训练测试团队多年，所以按惯例我总有些东西确定需要传达给测试新手。不管你是一个测试新手还是一个经验丰富的测试专家，都有不少有益的东西需要牢记在心。

1、你是一个检查者，你不需要为质量负责
很多测试人员误入歧途，不明白他们是评测产品的而不是控制产品的。这两者之间有着天壤之别。例如，一个测试团队花费好几周时间测试并发现很多缺陷，只是为了看着管理层决定发布一个有已知严重缺陷的产品。测试团队经常会感到士气受挫，置疑他们测试的目的。

我询问团队中的成员他们是否被支付薪水了，通常得到的回答都是“是”。我又询问他们是否尽力去做工作了，再一次，通常得到的回答都是“是”。我于是告诉他们，“你们做了你们的工作。你们尽力测试，发现了缺陷并进行了上报。那么现在可以回家休息了。实际上，作为一名测试人员唯一失败的地方是不上报一个已知的缺陷。”

这不会提高士气，但却有助于事情向正确的方向发展，特别是能让人不用每天晚上都在家接着办公。

很多测试人员，包括我，当我们刚开始测试工作时，似乎会觉得自己对我们所测试的系统应用的质量负责。尽管这个工作的出发点是让人钦佩的，可实际上我们测试人员对于产品的质量基本没有控制能力。也是由于这个原因，测试人员不为质量负责。现在问题是管理层并不总是能看到这种区别。所以经常看见管理层提出类似于“我们付钱给这些人不是为了获得高质量的软件吗？”的问题。

2、缺陷都是有价值的
每一个缺陷都是深入了解和提高的机会。我们可能只有一次机会观察到一个缺陷，所以我总是告诉测试人员始终保持高度注意力，不要为测试的乏味所折磨。

缺陷信息可能是可获取的项目数据中最有效的资源之一。但是这都取决于我们能多好的捕捉和传达我们所发现的缺陷的相关信息。

每个缺陷都会花费整个组织的金钱。如果我们不能从中更进一步了解产品，我们会浪费大量时间和金钱。当我们把一个错误转换成一次深入了解的机会时杠杆作用就出现了。让我们面对它――有些教训只能通过经历来学习的。

由于一个缺陷而责备谁不会有任何好的作用。责备只会让士气低落、沟通中断。这就像不断鞭打一匹死马希望它能活过来一样。

3、你报告第一个问题之前一切都是美好的
这就是一个测试人员所面对的现实。你可以计划测试，获取所需要的资源，看起来所有人都站在你这边。可当你报告第一个问题之后，事情就开始变得紧张了。

出现这种态度上的突然变化的原因是现在你在批评某些人的工作了。自尊心使得自我收到伤害，关系变得紧张。有些情况下自尊心是值得期盼的，只要知道当你开始发现问题的时候态度有可能变化就可以了。

我经常建议测试人员做的一件事是读一读一些你过去写的缺陷报告，假设自己是接收缺陷报告的人。你会发现自己需要更老练一些。写一个没有任何挖苦语句的缺陷报告可能没什么乐趣，但它的确有助于和开发人员之间保持一个好的关系。

4、只能测试你能观察的
你可能总想测试一些真正有创造性的用例，但如果你没有办法观察到结果，那有什么意义？尽管有些应用让你能观察到很多，但仍然有你没办法接近的，例如结构、隐藏的对象、后台进程等。

5、别忘记你是怎样到一个地方的
我不是在谈论知道为什么你走进一个房间，而是在测试时执行的步骤。对于测试新手常见的是发现了一个重大的缺陷，但却无法复现它以便定位解决。这样你只会觉得不舒服，不知道自己到底是真发现了一个缺陷，还是说仅仅是错误的使用了应用。

你能用来跟踪你的测试步骤的方法有测试脚本、测试记录、敲键记录器如Spector和屏幕视频捕捉工具如Hypercam。

6、标准和流程是你的朋友
尽管标准和流程让一些人觉得受限，但它们为你的工作提供了有价值的指导。不要拒绝标准因为它们是详细的、具体的。因此用它们指导自己更快、更一致的完成自己的工作。

7、没有足够的时间用于测试
几乎每一个测试人员都抱怨没有足够的时间用于测试，但实际情况是测试任何东西到完整的程度都是不可能有充足时间的。当你充分考虑软件的特性如可用性、安全性、兼容性、互操作性等时这一点尤其正确。

不要再抱怨缺少时间，学会根据风险来进行优先级排序，把注意力都放在对管理层很重要的应用目标上。有时候我们测试的内容超出了我们需要测试的，因为我们的目标偏离了产品的价值。

8、你不可能发现所有的缺陷
如果你测试的东西后来有缺陷被发现，不要变得气馁。你可能已经做了非常全面的工作，获得了高水平的缺陷移除，但100%都是不可能的目标。

9、保持幽默感和对前景充满信心
经常微笑、保持健康可能是你最好的生存方式。如果你正处在困难条件下，请相信，这一切都将过去。

10、争取做到最好而不是完美
测试新手经常会陷入追求完美的过程中，认为100%的正确才是标准。我曾经也是受害者之一，但要为自己辩护的是，我以前深受80年代后期类似于“99.9%还不够好”的TQM帖子和文章的影响。

追求完美的问题在于它会让测试进程变慢，将担心引入你所做的一切，使得你对别人更挑剔，而且通常会让你的朋友和家人感到失望。

当然，没人愿意犯错误，但他们稍不注意就出现了。想不犯错误就是否认现实。争取做到最好是一种好的习惯，表明你对工作的态度和投入程度。如果你想努力做到最好，你就会往前再多走一点。

根据我的观察，大多数人看到错误或者经历失误时都是很宽容的。人们最关心的是你对待问题的反应。

11、开发人员不是敌人
需要整个项目团队的努力才能递交高质量的产品。有时候似乎开发人员不太关心质量，这个时候事情背后可能存在隐情。这时候你需要更好的和开发人员合作而不是反对他们。要始终牢记良好的交流是一个项目成功的关键因素。当你和开发人员站到对立面时，交流就停止了，你测试所需的很多信息也无法获取了。

12、建立和维护一个私人的交际网
你的私人和工作关系是一个很重要的资产。无论时当你有工作时还是当你没工作时他们都是一个很好的支持系统。找一个好的指导者，而当你学到足够的东西时成为别人的指导者。

13、持续锻炼自己的技能
你的技能把你和别人区分开。始终通过参加专业会议、获取认证、阅读专业资料等来不断学习。我给自己制定的目标是每周至少读一本和个人发展以及职业发展相关的书（测试、领导艺术、商业、IT等）。

一个个人发展方面的专家说过如果你每天在任何特定的主题上花费30分钟进行阅读，五年之内你肯定能成为这个主题方面的专家。这一点对我是起作用的――你也可以试试。

另一种让自己始终内行并建立网络的好的方式是活跃在一些QA或者测试论坛上。

14、当前进变得困难，懒惰就需要创造力了
当我第一次成为一个测试团队负责人时，我用这句话做了一个字条挂在我的桌上。它不断提醒我把创造力作为我解决问题的一个杠杆。

学着从一个新的有创造性的方式来看待问题。你可能有一个好的测试计划，但你如何应付各种变化呢？弹性是一个优秀的问题解决负责人的关键特性。

15、简单并不总是很容易
我们测试中做的很多工作看起来都很简单。但是，挑战在于保持努力的连贯性。

有些解决问题的方式刚开始看起来很简单，但不要由于它简单和明显就丢弃任何一种想法。同样，不要低估实现一个简单想法所需要付出的努力。

一些看过我和William E.Perry合著的书“Surviving the Top Ten Challenges of Software Testing”评论说这些挑战都很简单且很容易解决。这就让我奇怪为什么人们还在年复一年的提出“人的问题”。我认为在大脑中产生想法比实际实现出来要简单的多。

结论
智慧比知识更重要。你可能已经学习了大量测试技术，但如果你没有足够的智慧判断什么时候采用它们，没有从整体上理解它们，你应用它们的能力将受到很大限制。对任何都有涉猎的你存在的一个问题是“你不知道什么你不知道”。智慧帮助你明白你需要知道哪些东西才能成功。

　　1、逆向思维方式

　　● 逆向思维在测试中用的很多，比如将根据结果逆推条件，从而得出输入条件的等价类划分

　　● 其实逆向思维在调试当中用到的也比较多，当发现缺陷时，进一步定位问题的所在，往往就是逆流而上，进行分析

　　● 逆向思维是相对的，就是按照与常规思路相反的方向进行思考，测试人员往往能够运用它发现开发人员思维的漏洞

　　2、组合思维方式

　　● 很多东西单一的思考都没有问题，当将相关的事物组合在一起却能发现很多问题；如多进程并发，让程序的复杂度上了一个台阶，也让程序的缺陷率随之而增长

　　● 按照是否排序组合可以分为：排列（有序）和组合（无序）；针对不同的应用，可以酌情考虑使用“排列”或者“组合”

　　● 为了充分利用组合思维而不致于让自己的思维混乱，要注意“分维”，将相关的因素划分到不同的维度上，然后再考虑其相关性

　　3、全局思维方式

　　● 事物往往存在多面性，当我们掌握了越多的层面，我们对它的认识就越清楚，越有利于我们掌握其本质，全局思维方式就是让我们从多角度分析待测的系统；试着以不同角色去看系统，分析其是否能够满足需求

　　● 其实平常我们在软件开发过程中，进行的各种评审，就是借助全局思维的方式，让更多的人参与思考，脑力激荡，尽可能的实现全方位审查某个解决方案的正确性以及其他特性

　　4、两极思维方式

　　● 边界值分析是两极思维方式的典范

　　● 为了看系统的稳定性，我们采用了压力测试

　　● 两极思维方式，是在极端的情况下，看是否存在缺陷？

　　● 注意是两极，不是一极

　　● 测试人员做久了，往往容易走极端——职业病，不利于与人沟通

　　5、简单思维方式

　　● 剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”

　　● 针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向

　　6、比较思维方式

　　● 认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用

　　● 应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用

　　● 让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式

　　7、动起来，更精彩

　　● 关注程序的运行时状态

　　● 传统的基于结构的程序可以更多的在代码中反映将来程序的运行方式；而面向对象将代码和运行时显著分离

　　● 让我们在关注代码静态结构（如类结构）的同时，也要谨慎关注其动态（对象交互网）表现

　　其实这些思维方式，大家都在有意识或者无意识的使用着，它们各自都有自己的妙处，将我们的思维发散，有意识的将他们用在问题的思考上，有时可以给我们一种“柳暗花明又一村”的感觉。

　　最后想说，只是知道这些原则意义不是很大，如果真能让它们成为思考的血液，才能发挥它的真正价值。那真的需要很多的历练，其实成为一名出色的测试人员，远没有那么简单，需要简单，需要（不断的学习＋不断的经历＋不断的思考）。

原文：【聚杰网测试技术】

　　时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。　

　　某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。

　　下面讨论两种增量式集成方法。

　　一、自顶向下集成　　

　　自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。　　

　　自顶向下综合测试的具体步骤为：　　

　　1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；

　　2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；

　　3 每集成一个模块立即测试一遍；

　　4 只有每组测试完成后，才着手替换下一个桩模块；

　　5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。

　　从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。　

　　自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。

　　二、自底向上集成　　

　　自底向上测试是从原子模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。　　

　　自底向上综合测试的步骤分为：　　

　　1 把低层模块组织成实现某个子功能的模块群（cluster）;

　　2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；

3 对每个模块群进行测试；

　　4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。

　　从第一步开始循环执行上述各步骤，直至整个程序构造完毕。

　　下图说明了上述过程。首先原子模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对MaD3被去掉后，M3与模块群3直接接口，可对Mb进行集成测试，最后Ma、Mb和 Mc全部集成在一起进行测试。

　　自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。

　　此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：①对应几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。

原文:【聚杰网测试技术】