石无言

J2SE历史回顾：JDK 1.1时代开始

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开发时，应该能够明显的体会到它的易用性。

无法识别的属性"type"

“/”应用程序中的服务器错误。
--------------------------------------------------------------------------------

配置错误
说明: 在处理向该请求提供服务所需的配置文件时出错。请检查下面的特定错误详细信息并适当地修改配置文件。

分析器错误信息: 无法识别的属性“type”。

源错误:
行 10： <configuration>
行 11：  <configSections>
行 12：   <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
行 13：    <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
行 14：     <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" allowDefinition="MachineToApplication"/>
 

源文件: E:\TIANJIAN Project\MobileWebService\MobileWebSrv\web.config    行: 12
--------------------------------------------------------------------------------
版本信息: Microsoft .NET Framework 版本:1.1.4322.2443; ASP.NET 版本:1.1.4322.2407
解决方法: 将部署的该站点属性的ASP.NET选项卡中的ASP.NET版本改为2.X以上的版本.

无法找到该页

解决方法: 将IIS的 "WEB服务扩展" 的相关服务进行启用.

当前标识(NT AUTHORITY\NETWORK SERVICE)没有对“c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files”的写访问权限。

“/Websrv”应用程序中的服务器错误。
--------------------------------------------------------------------------------

当前标识(NT AUTHORITY\NETWORK SERVICE)没有对“c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files”的写访问权限。
说明: 执行当前 Web 请求期间，出现未处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。

异常详细信息: System.Web.HttpException: 当前标识(NT AUTHORITY\NETWORK SERVICE)没有对“c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files”的写访问权限。

源错误:
执行当前 Web 请求期间生成了未处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。 

堆栈跟踪:
[HttpException (0x80004005): 当前标识(NT AUTHORITY\NETWORK SERVICE)没有对“c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files”的写访问权限。]
   System.Web.HttpRuntime.SetUpCodegenDirectory(CompilationSection compilationSection) +748
   System.Web.HttpRuntime.HostingInit(HostingEnvironmentFlags hostingFlags) +223

[HttpException (0x80004005): 当前标识(NT AUTHORITY\NETWORK SERVICE)没有对“c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files”的写访问权限。]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +940
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +70
   System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +275
--------------------------------------------------------------------------------
版本信息: Microsoft .NET Framework 版本:2.0.50727.1433; ASP.NET 版本:2.0.50727.1433

解决方法:

"开始->运行"中执行 C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -i -enable

Microsoft Windows [版本 5.2.3790]
(C) 版权所有 1985-2003 Microsoft Corp.

C:\Documents and Settings\Administrator>C:\WINDOWS\Microsoft.NET\Framework\v2.0.
50727\aspnet_regiis -i -enable
开始安装 ASP.NET (2.0.50727)。
...............................
ASP.NET (2.0.50727)安装完毕。

C:\Documents and Settings\Administrator>

*.  关于ASP.NET IIS 注册工具 (Aspnet_regiis.exe)

在一台计算机上并行执行多个 .NET Framework 版本时，映射到 ASP.NET 应用程序的 ASP.NET ISAPI 版本决定了该应用程序所使用的公共语言运行库 (CLR) 版本。使用 ASP.NET IIS 注册工具 (Aspnet_regiis.exe)，管理员或安装程序可以方便地更新 ASP.NET 应用程序的脚本映射，使其指向与该工具关联的 ASP.NET ISAPI 版本。该工具还可以用于显示所有已安装的 ASP.NET 版本的状态，注册与该工具耦合的 ASP.NET 版本，创建客户端脚本目录，以及执行其他配置操作。
http://msdn.microsoft.com/zh-cn/library/k6h9cz8h(VS.80).aspx

(这次安装的系统,由于是先安装的.net 框架,最后才装的IIS,因此IIS没有对该框架进行访问的限制; 在执行完该命令后,查看v2.0.50727\Temporary ASP.NET Files目录的安全权限中多了ASP.NET、IIS_WPG、Local_Service、Network_Service这几个用户及组)

生梨润肺化痰好， 苹果止泻营养高。

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

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

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

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

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

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

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

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

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

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

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

让薪水翻番的秘诀 

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

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

一、全心投入工作

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

二、工作步调快

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

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

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

四、熟练工作

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

五、集中处理

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

六、简化工作

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

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

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

BVT（Build Verification Test）

版本验证测试 (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测试。

http://space.100e.com/myspace/Diary-271154

rather than 是一个并列连词，用法比较复杂，现归纳如下：

1. rather than 与would 连用时，构成“would rather...than...”句式，意思是“宁愿……而不愿……”，表示主观愿望，即在两者之中选择其一。例如：

She'd rather die than lose the children. 她宁愿死也不愿失去孩子们。

2. rather than 不与would连用时，表示客观事实，意为“是……而不是……；与其……不如……”。它连接的并列成分可以是名词、代词、形容词、介词(短语)、动名词、分句、不定式、动词等。现分述如下：

(1) 连接两个名词或代词

He is an explorer rather than a sailor. 与其说他是一个海员，不如说他是一个探险者。

You rather than I are going to go camping. 是你而不是我要去要野营。

注意：rather than 连接两个名词或代词作主语时，谓语动词应与rather than 前面的名词或代词在人称和数上保持一致。

(2) 连接两个形容词

The sweater she bought was beautiful rather than cheap. 与其说她买的这件羊毛衫便宜不如说它漂亮。

(3) 连接两个介词(短语)或动名词

We will have the meeting in the classroom rather than in the great hall. 我们是在教室里开会，不是在大厅里。

She enjoys singing rather than dancing. 她喜欢唱歌，而不喜欢跳舞。

(4) 连接两个分句

We should help him rather than he should help us. 是我们应该帮助他而不是他应该帮助我们。

(5) 连接两个不定式

I decided to write rather than (to) telephone. 我决定写信而不打电话。

注意：rather than 后接不定式时，不定式可以带to，也可以不带to, 如上句。但rather than位于句首时，则只能接不带to 的不定式。如：Rather than allow the vegetables to go bad, he sold them at half price. 他唯恐蔬菜烂掉，把它们以半价卖掉了。

(6) 连接两个动词

He ran rather than walked. 他是跑来的，而不是走来的。

注意：这里rather than 后用了walked，而没有用walk，表示客观事实，而不是主观愿望。如果换成walk，则作“宁愿……而不愿 ……”解。

would rather的用法
一、would rather意思是“宁愿、宁可、更、最好、还是为好”，后接动词原形,常省略为’d rather，表示优先选择的一种方式
其否定形式是would rather not do sth。would rather没有人称和数的变化，所有的人称一律用would rather。
“would rather+动词原形”是英语中常见的一个惯用句式，美国英语中多用had rather。would (had)在此决无“过去”之意，它是一个情态助动词，且无词性、时态变化。
例 Mr Li would rather not listen to rock music. 李先生不愿意听摇滚音乐。
If you’d rather be alone, we’ll all leave here. 如果你宁愿独自呆着，那我们都离开这儿。
He’d rather work in the countryside. 她宁可到农村去工作。
You would rather stay at home and do some reading this evening. 今晚你最好呆在家中读点书。
二、如果在两者中进行取舍，表示“宁愿……而不愿……，与其……宁可……”的意思时，则可用would rather…than…或would…rather than…的句型
例 I would rather watch TV at home than go to the cinema. 我宁可在家看电视而不愿去看电影。
The children would walk there rather than take a bus. 孩子们宁愿步行去那里而不愿乘公共汽车。
请注意 1） would rather…than…/would…rather than…也可以颠倒为：rather than…would…。Would(rather)和than后都接不带to的动词不定式，若选用的动词相同，那么than 后的动词可以省略。
例 I would rather have noodles than rice. 我宁愿吃面条也不吃米饭。
He would rather drink wine than beer． 他喜欢喝红葡萄酒而不喜欢喝啤酒。
Rather than work in such bad condition, he would give up. 与其在这样差的条件下工作，他宁愿放弃。
2)使用would rather…than…句型时要注意“平行结构”，即在than 的前后要用两个同类的词或词组，如两个名词、两个不定式、两个介词短语等。
例 I would rather go to work by bike than by bus. 我宁愿骑自行车也不愿乘公共汽车去上班。
I would rather talk with his mother than with his father. 我宁愿和他妈说话而不愿和他爸说话。
三、在疑问句式中，would rather 与would rather…than…中的would要放在主语之前
例 Would you rather stay here or go home? 你愿意呆在这里，还是回家？
Which would you rather have, apples or bananas? 你喜欢吃苹果还是香蕉？
Would you rather read a novel than read a poem?你宁愿看小说而不愿朗读诗歌吗？
四、would rather+从句，是一个常用的虚拟语气句型 Would rather+从句,谓语一般用过去时来表示现在或将来。其意为“宁愿……,还是…… 好些”“一个人宁愿另一个人做某事”。引导从句的that常省略。在谈到过去的动作时，谓语则用过去完成时。
例 John wants to see me today. I would rather he came to tomorrow than today. 约翰今天想去看我。我宁愿他明天来看我而不是今天。(句中came不是表示过去而是表示将来)
We’d rather he paid us the money tomorrow. 我们宁愿他明天付给我们那笔钱。
Don’t come tomorrow. I’d rather you came next weekend. 明天别来。我希望你下周末来。
请注意 1） 如果谈到过去的动作，也就是表示过去已经发生的事情在选择上不恰当。此时，主句一般为I had rather ,其（that）从句则用过去完成时。 例 Would rather you had not done that. 我真希望你没有做那件事。
2）如果只涉及主语本人而不涉及另一个人，则would rather之后不接that从句而接have done结构。
例 I would rather have gone to the theatre than stayed home night. 我真希望昨天晚上去看了戏而不是呆在家里。 He would rather be poor than have got money by dishonest methods． 他宁可穷也不愿意用不诚实的手段获取金钱。
Henry would rather that his girlfriend worked in the same department as he does．亨利希望他的女朋友和他在一个部门工作。
五、would rather/sooner和prefer/would prefer的区别 would rather和would sooner之间一般没有区别，但经常接触到的是would rather。
例Tom would rather/sooner read than talk． 汤姆宁可读书而不愿谈天。 Tom prefers reading to talking．汤姆喜欢读书而不喜欢谈天。
请注意 1）would rather后跟不带to的不定式+than+不带 to的不定式，而prefer后跟动名词+to+动名词。有时prefer后面也可跟名词，而在would rather之后要求只带动词原形。
例 He prefers wine to beer．= He would rather drink wine than beer． 他喜欢喝红葡萄酒而不喜欢喝啤酒。
I prefer tennis to golf．= I’d rather play tennis than golf． 我喜欢打网球而不喜欢打高尔夫球。 2）某些 prefer+名词的情况不能用 would rather完全确切地表达出来：He prefers dogs to cats．（他喜欢狗而不喜欢猫。）和 He would rather have dogs than cats．（他宁可养狗而不愿养猫。）很明显，这两句的意思并不完全相同。
3） would rather+不带to的不定式有时可代替 would prefer+带 to的不定式。
例 I’d rather fly than go by sea．=I’d prefer to fly． 我宁愿乘飞机也不愿乘船。
这两个结构后面带名词时情况也一样：
例 —Would you like some gin？
—I’d prefer a coffee．=I’d rather have coffee than gin．
—您想喝点杜松子酒吗？
—我想喝点咖啡。/我想喝点咖啡，不想喝杜松子酒。
4）would rather/sooner和would prefer后面都可跟完成式，但后者带to。
例 We went by sea but I’d rather have gone by air=I’d prefer to have gone by air． 我们是乘船去的，可我本想乘飞机去。（我愿意乘飞机去，可我的愿望未能实现。）这和 would like+不定式的完成式有点相似，would like+带to 的不定式的完成式也表示未能实现的愿望。

明月出关山，苍茫云海间。长风几万里，吹度玉门关。汉下白登道，胡窥青海湾。由来征战地，不见有人还。戍客望边邑，思归多苦颜。高楼当此夜，叹息未应闲。

《关山月》为汉代乐府琴歌，“鼓乐横吹曲”之一。当时戍边将士经常在马上唱奏此曲。现行歌词为唐代大诗人李白填写，揭示了古代战争所造成的巨大牺牲和给无数征人带来的痛苦，借以抒发作者对唐代统治者穷兵黩武的感慨。最早在《关山月》曲谱刊于《魏氏乐谱》。1931年刊行的《梅庵琴谱》中有《关山月》一曲，无歌词，旋律也不同于《魏氏乐谱》，但调式，气韵相近。50年代初，夏一峰、杨荫浏等将李白的歌词重新填入《梅庵琴谱》的《关山月》中，得以广泛流传。这首歌曲纯朴自然，曲调舒展、宽广，既有琴歌的特色，又贴切地抒发了感伤的情怀。

音频片段：需要 Adobe Flash Player（9 或以上版本）播放音频片段。 点击这里下载最新版本。您需要开启浏览器的 JavaScript 支持。

唐朝的月亮那样又高又远地挂在天际，仿佛马背上戍边人吟唱的悲欢与它无关，萧瑟的西风裹挟着关外的沙砾吹来，瞬间迷蒙了望乡的双眼......

发现很多人将返回测试和回归测试的概念给弄混了，现在说说自己对这两个概念的理解。

返测：测试过程中，缺陷修改后由测试人员重新进行验证，以保证修改的正确性。(对特定的缺陷进行重新测试)

回归：指测试进行到某一阶段时，回过头来对重新执行以前的测试。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现、修复的错误是否引发新的问题。(全部重新测一遍)

在软件生命周期的任何一个阶段，只要软件发生了变化，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也可能是因为在集成或维护阶段加入了新的模块。因此，每当软件发生变化时，就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还要补充新的test case来测试新的或修改了的功能。为了验证修改的正确性及期影响，就需要进行回归测试。

使用记事本输入以下内容，然后文件名改为*.reg （注意后缀为reg），导入注册表，即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.txt]
@="txtfile"
"Content Type"="text/plain"
 
[HKEY_CLASSES_ROOT\.txt\ShellNew]
"NullFile"=""
 
[HKEY_CLASSES_ROOT\txtfile]
@="文本文档"
 
[HKEY_CLASSES_ROOT\txtfile\shell]
 
[HKEY_CLASSES_ROOT\txtfile\shell\open]
 
[HKEY_CLASSES_ROOT\txtfile\shell\open\command]
@="NOTEPAD.EXE %1"

QC9.0上导出的Word文档在中文系统中打开正常,在日文操作系统上打开为乱码.但是该日文操作系统中找开由Word创建的中文文档能正常打开,这说明由QC导出的文档和Word创建的文档还是有所差异的; 于是在Word中新建一文档,将QC创建的文档中的内容Copy到该新建文档,在粘贴选项中选择"匹配目标格式",保存后在日文操作系统中正常打开。