昨天看了测试大侠pent翻译的一篇文章《基于用户体验的性能测试》，原文名称为《User Experience, Not Metrics》，直译为《用户体验，而不是度量》，大侠翻译的很准确，不愧为前辈。这篇文章的观点很好，最近我正好也想谈谈类似的话题。

　　看坛子里多数网友都在谈压力测试，讨论LoadRunner的使用，气氛热烈而又和谐，但我今天可能要给很多人泼一盆冷水了，“你做的压力测试“准确”吗？”，这里我说的

　　“准确”有两层含义：

　　符合现实：你模拟的负载测试真的能反映实际运行的负载吗？

　　精确：你模拟测试中采集的度量数据足够详细、粒度够小吗？

　　当然，借助于专业的压力测试工具，只要添加足够多的monitor，“精确”应该不难，但“符合现实”吗？以我作为过来人的经验，大多数的压力测试并不准确。为什么这么说，请往下看这张图。

　　上图是大多数人得到的一个典型的测试结果，看上去很美，但它不符合现实情况。你的计算机、测试脚本有足够的耐心等待，但实际用户没有。在这个讲究效率、信息爆炸、社会高速运转的现实世界是什么样呢？

　　另外用户对网站的熟悉程度、网络速度，甚至用户的计算机水平，都会影响用户的操作速度，进而对实际的负载形成不同的影响。

　本文是我在“第十届中国系统与软件过程改进年会广东会场”所作演讲的整理稿，主要分享单元测试的一些要点、单元测试实践的主要问题，以及如何来解决这些问题。

　　一、单元测试概述

　　1.1 什么是单元测试

　　单元测试，就是针对代码单元的独立测试。为什么需要单元测试呢？这是代码的基本特性决定了的。代码有一个基本特性，就是对数据分类处理。

　　代码通常会有很多的判定。一个判定，就是一次分类。嵌套的判定，会使分类次数的翻倍。

　　如果我们在写代码的时候，有一个分类漏掉了，就会产生一个Bug；如果一个分类，虽然写了代码，但是处理不正确，也会产生一个Bug。一个函数要没有错误，必须做到两点：1，对数据的分类必须完整；2，每一个分类的处理必须正确。做到了这两点，就可以说，代码的功能逻辑是正确的。

　　那么，如何检测代码的功能逻辑是否正确呢？

　　调试，是临时的，且不完整的，例如，一个函数有十种输入，调试能覆盖五六种就不错了。而系统测试，并不针对某个具体的函数，不关注某个函数的功能逻辑是否正确。

　　要检测某个函数的功能逻辑，就必须要依照分类列出数据，检测代码是否对每一个分类都做了处理，而且每一个分类的处理是否正确。

　　——这就是单元测试。

　　1.2 单元测试的基本方法

　　由上面的分析可以看出，单元测试的基本方法就是：依数据的分类列出输入，执行被测试程序，然后，判断输出是否符合预期。

　　单元测试能达到什么样的效果呢？那就是：无论别人怎么样，我总是对的！

最近在执行C/S控制客户端安装卸载的测试，通过自己的测试经历和网上的资料，总结以下安装卸载测试点：

　　安装测试：

　　1、GUI测试：安装过程中所有的界面显示，提示信息等是否正确

　　2、兼容性测试：在不同的操作系统，不同配置的主机上能否正常安装

　　3、安装路径测试（软件不能自动安装的情况下）：

　　软件默认路径安装（一般是当前系统盘）；

　　自定义路径安装：缺省路径安装；手动输入路径（包括存在的和不存在的路径）安装；  包含特殊字符的路径安装；中文路径或者中英文路径安装；包含空格、下划线等合法路径安装；不同硬盘格式分区（FAT16，FAT32，NTFS）路径上安装；网络路径，移动设备，虚拟机等安装路径安装；小于软件安装所需的磁盘空间路径上安装等

　　4、不同安装环境下测试：包括没安装过的系统；已安装过老版本（系统正在使用，系统未使用）；已安装最新版本；卸载后重新安装；重复安装；多次安装；修改安装；修复安装（完好软件和有部分文件受损的软件）；在未达到最低硬件配置下安装等

　　5、测试各种不同的安装组合，并验证各种不同组合的正确性（包括参数组合，控件执行顺序组合，产品安装组件组合，产品组件安装顺序组合）等）。如在安装CS客户端前先安装服务器与CS客户端安装后再安装服务器，这两种组合，对CS客户端的安装是否有影响。

　　6、异常情况下安装测试：安装过程中取消；安装过程中关机/断电；系统进入待机，休眠等状态；数据库终止；网络终止等

　　7、至少要在一台笔记本上进行安装/卸载测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品；

　　8、安装后测试项：安装后是否能产生正确的目录结构和文件，文件属性正确；安装后动态库是否正确；安装后有没有生成多余的目录结构，文件，注册表信息，快捷方式等；桌面是否有快捷方式，【程序】列表是否有启动和卸载选项，安装目录是否为安装时设置的路径，安装后的程序能否正常启动；安装成功后是否会对其他常用软件有影响等。

　　卸载测试：

　　1、GUI测试：卸载过程中界面显示，提示信息是否正常等

　　2、兼容性测试：在不同的操作系统，不同配置的主机上能否正常卸载等

　　3、通过不同方式能否正常卸载：控制面板中卸载；安装包卸载；程序自带程序卸载；第三 方卸载工具卸载（360，优化大师，RevoUninstaller等）

　　4、异常情况下卸载测试：卸载过程中取消；卸载过程中关机/断电系统进入待机，休眠等状态；数据库终止；网络终止；程序在运行/暂停/终止等状态时的卸载；多次卸载等

　　5、在可以选择组件卸载的情况下，测试各种不同的卸载组合，并验证各种不同组合的正确性（包括参数组合，控件执行顺序组合，产品卸载组件组合，产品组件卸载顺序组合等）

　　注：CS客户端不可以选择组件卸载

　　6、卸载后测试项：是否删除了全部的文件：安装目录里的文件及文件夹，非安装目录（向系统其它地方添加的文件及文件夹），包括exe，dll，配置文件等；是否同步去除了快捷方式——桌面，菜单，任务栏，系统栏，控件面板，系统服务列表等；复原方面－卸载后，系统能否恢复到软件安装前的状态（包含目录结构、动态库，注册表，系统配置文件，驱动程序，关联情况等）（专门的测试工具regsnap）；卸载后是否对其他的应用程序造成不正常影响（如操作系统，常用应用软件等）等

　　有什么遗漏的，望各位同仁指出。

　1、什么情况下会使用mock技术

　　（1）需要将当前被测单元和其依赖模块独立开来，构造一个独立的测试环境，不关注被测单元的依赖对象，只关注被测单元的功能逻辑

　　----------比如被测代码中需要依赖第三方接口返回值进行逻辑处理，可能因为网络或者其他环境因素，调用第三方经常会中断或者失败，无法对被测单元进行测试，这个时候就可以使用mock技术来将被测单元和依赖模块独立开来，使得测试可以进行下去。

　　（2）被测单元依赖的模块尚未开发完成，而被测单元需要依赖模块的返回值进行后续处理

　　----------比如service层的代码中，包含对Dao层的调用，但是，DAO层代码尚未实现

　　（3）被测单元依赖的对象较难模拟或者构造比较复杂

　　----------比如，支付宝支付的异常条件有很多，但是模拟这种异常条件很复杂或者无法模拟，比如，查询聚划算的订单结果，无法在测试环境进行模拟

　　2、Mock技术分类

　　（1）手动构造mock对象

　　---------------比如，可以自己写某个接口方法的实现，根据需要编写返回值，测试代码中使用该实现类对象

　　缺点：会增加代码量，在写mock对象代码时，有可能引入错误

　　（2）使用开源代码提供的构造mock方法

　　--------------比如easyMock，提供了对接口类的模拟，能够通过录制、回放、检查三步来完成大体的测试过程，可以验证方法的调用种类、次数、顺序，可以令Mock对象返回指定的值或抛出指定异常

　　3、EasyMock使用

　　（1）引入easyMock

　　------------在maven工程中，通过pom配置依赖关系

　　------------在普通java工程中，通过添加外部包的方式

　　（2）使用easyMock过程

　　1）使用EasyMock生成Mock对象；
　　pingJiaDao = mockControl.createMock(IPingJiaDao.class);

　　2）设定Mock对象的预期行为和输出；
　　EasyMock.expect(pingJiaDao.getGoodPingJiaRate(storeId)).andReturn(0.11);

　　3）将Mock对象切换到Replay状态；
　　EasyMock.replay(pingJiaDao);

　　4）调用Mock对象方法进行单元测试；
　　storeService.setStoredao(pingJiaDao);
　　double rate = storeService.getStoreGoodRate(storeId);

　　5）对Mock对象的行为进行验证。
　　EasyMock.verify(pingJiaDao);

　　4、其他easyMock功能

　　（1）特殊的mock对象：niceMock
　　（2）参数匹配器
　　（3）重置mock对象
　　（4）模拟异常抛出
　　（5）设置调用次数

　上面分析了很多测试用例颗粒度粗、细的特点，那么，常规的测试来讲，如何大致定位测试用例颗粒度的粗细呢？

　　下面以单一的应用环境来体现。

　　还是要强调那句话：相同的机构也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试。

　　单一条件：

　　1、时间因素：

　　时间短、项目紧、编写用例评审时间较短时，适合粗颗粒度用例。

　　项目周期较长时，适合细颗粒度用例。

　　比如规划六个月的项目，计划阶段和设计阶段有一个半月，测试前期进入，有足够的时间来进行人员培训、测试用例编写，需要细颗粒度。如果项目是一个月，测试准备时间只有五个工作日，那么可能在第三天就要完成第一轮的测试用例评审，建议以粗颗粒度为主，覆盖功能和体现思路。

　　2、项目人员：

　　测试人员中熟手多，思路和基础技能扎实，或测试人员构成责任心高时，可以采用粗颗粒度用例。

　　测试人员新手多，需要再指导下进行基础测试工作，或责任心一般时，需采用细颗粒度用例。

　　测试人员熟手和新手的区别，大家一目了然。在这里，特意把责任心作为测试用例编写粗细的一个判别标准。实际上，测试人员的职业素质中，就有责任心一项，这种品质方面的要求因人而异——而且每个人都肯定对自己的责任心还自我感觉良好。

　　举个例子，比如安装测试：

　　粗的写法：在微软的各种操作系统下进行遍历安装，确认setup安装成功。——那么责任心好的人，可能会去翻阅规格书，确认setup支持的操作系统，再依次安装测试。责任心一般的人，可能就想当然的认为visia这种过渡版本很少人用/server 2000 不是个人用户的菜，就直接跳过这两种系统。

　　所以面对责任心一般的人，就必须写成细的用例：安装测试：A、在window XP 的 SP2 环境下安装；B、在xp的SP3 环境下安装；C、在win server 2000 下安装；……。

　　3、项目质量性质

　　项目质量要求一般，或项目为过渡项目，生命周期短；项目为临时项目时，可采用粗颗粒度用例。

　　项目质量要求高，客户或公司对质量的定位为第一位，品牌工程项目，采用细颗粒度用例。

　　难道不是所有的项目都是高质量高要求的么？当然不是。

　　不同国家和民族的人对质量的要求是不一样的：美国是够用就好，德国是精益求精，中国是当场不挂就行。

　　不同产业链位置的公司对质量要求是不一样的：顶级公司做完美的产品，中级公司做性价比高的产品，底层公司做廉价的产品。

　　不同定位的公司对质量的要求是不一样的：在火车站门口的饭店吃的是客流量，在市区偏远地方的饭店吃的是回头客。

　　不同目的的单子对质量的要求是不一样的：做账拉回扣的虚项目，中标后无人使用，三年后设备升级，质量就没有要求。做重点项目，质量要求苛刻等。

　　所以，肯定会有不同的项目质量性质。也自然有不同的测试策略和测试目的，顺序导出的就是不同颗粒度的测试用例。

如何有效实现软件的需求管理（6）

　在我们公司，获取了一个需求以后，

　　首先，相关人员会先在DevSpec建立一个条目，添加相应的一些属性信息，比如标题，内容描述，状态，对应文档，优先级，紧急程度，负责人，对应版本，对应浏览器，对应数据库等等。。。

　　提交完了条目以后，由于这个条目设置了一个负责人，所以那个负责人登录系统就可以马上看到自己名下有这个条目，他就会马上去处理这个需求。（可能有些人没登录系统去看，我们也可以设置Email或者手机短信的自动提醒功能）

　　这里提到的“负责人”，在不同的过程里，负责人都是不同的，比如“评审”阶段就有专门的评审负责人，普通人无法成为评审负责人，哪些人在哪些过程里能成为负责人是可以在流程中设置的。而上面提到的提交完条目后，一般情况第一个过程就是要审核刚获取的需求，负责人审核通过后就可以把这个需求从“审核”状态改到“需求分析”阶段了，当然负责人也会改变，“需求分析”过程的负责人就会马上知道自己有事情干了。

　　就这样，经过一个一个的过程，经手了一个一个的负责人，这个需求就逐渐从一个只有一个思想，到有了轮廓，再设计出里面的框架，然后最后被实现。

　　其实，大家都是这么来处理需求的，不同的是，我们通过一个工具来管理这个过程，而有些公司只是就人工来做一下。我们这么做，好处和坏处其实都有，正如之前有个客户问，你们这么做的话，是不是每一个需求的处理效率会降低？对，的确会降低，我们承认，因为这些都是严格的流程，而且是在一个系统中管理，肯定没有他们口头直接说一下快。但是，我们考虑的是我们是在卖产品，牺牲一部分的效率来确保产品的质量，我们觉得划得来，毕竟质量才是最重要。人家虽然速度快，但是问题也来得多，需求多的时候，这个忘做了，那个做错了，或者相互责任推来推去的事情多着了，最终导致产品质量出问题的事情比比皆是。但是我们用了系统以后，就避免了这些事情，实践也证明了我们这么做以后，产品质量是得到保证了的。

　　当然，产品的质量也不是简简单单像我说上面说的“经过一个一个的过程，经手了一个一个的负责人”就能马上实现了，这里还会涉及到很多细节注意点了，待我一一道来。

我之前说过需求管理有几个严格的要求，流程化和审核机制大家其实已经看到了，其实在某种程度上，审核是流程化的一部分，因为审核过程本身就是需求处理过程中一个过程而已，我们只要在流程中设置了这种过程，安排负责人去负责就行了，当需求进入这个过程，就自然有人会去审核了。

　　如果把上面两个要求看成是需求管理的基础的话，那其他几个严格的要求：欢迎变更、版本控制、可跟踪性，就可以看成是确保产品质量成功的关键点了。有了基础才有可能成功，有了关键点才能保证成功！

　　欢迎变更：

　　欢迎变更的重要性大家应该知道了，变更其实也就是需求经常变，从某种程度上也就意味着产品的质量下降，因为这个需求你不断变化，今天刚写好这段代码，明天要改成那样，后天又要大改，谁都知道有潜在风险，而且还有与之有关联的功能呢？你突然改了个接口参数，人家可能还不知道了。靠测试？测试人员也没法很好解决这个问题，因为今天刚测完这个功能，明天却大改了，但是那个测试人员虽然看到这个功能需要测试，但是他却可能认为昨天已经测好了，是不是忘记关闭了，所以就去测其他功能了。

　　那怎么解决呢？也很简单，当有变更的时候，

　　首先，尽量让相关的人知道，让开发知道，让测试知道，让需要我们接口的人知道，这样子大家就都会同步就完成自己要做的事情，不会出现需要做的人却不知道他要去做这个事的情况。在DevSpec中，我们可以采用变更自动通知功能来实现，因为在DevSpec中一个需求总是和它的开发任务和测试任务关联在一起的，所以当需求有了变更以后，只要发送一个通知，开发人员和测试人员就能马上看到变更，就能及时去做他们的工作了。

　　第二点就是，尽量把影响的范围搞得清楚点，让开发知道哪些地方可能会影响到，做的时候小心点；让测试知道这个改动会造成哪些地方有潜在的Bug，需要重点测一下。在DevSpec中，我们会有专门的功能让设计人员和开发人员注明影响到的地方，需要重点测的地方，而且这个功能可以设置成强制，只要有变更，设计人员和开发人员就必须注明，甚至可以要求测试人员也注明测了哪些点，可以让设计与开发人员检查是否有遗漏。

　　第三点就是，针对任何变更（特别对于瀑布模式那种公司），因为关系到了可能会影响质量、进度及成本，风险很大，所以对于变更的内容需要专门的评审流程，评审通过后才能开始开发。在DevSpec中，我们针对这种情况，就会经常启用变更管理视图，在这个视图中，会有特别的流程对变更做评审，在次期间，这个需求是没办法被任何人转到开发环节的，也避免了有些人不清楚情况，直接就把没审核的需求直接让开发去做了。（当然，我们现在很多产品已经是用敏捷开发的模式了，所以这个功能就用得比较少了）

　　这样子做的话，我们还是能把质量掌握在自己的手中，也就是把公司的前途掌握在自己手中。

　　（未完待续）

　　一、民航与软件

　　随着全球经济一体化的发展，民航业务将会以更加多样化的形式出现，企业间的各种业务将会更加复杂和频繁，民航业的竞争也越来越多地体现在运用新的科技手段之上。怎样能将民航机构原有的计算设备和网络系统进行改造和更新，并建立一套更加先进、稳定而又具有较大的业务扩展空间的民航业务处理系统来满足当前及未来很长一段时期内的业务需求，提高工作效率是很多民航机构需要解决的当务之急。

　　因为民航的企业性质，决定了民航业对软件的依赖。民航业的软件素来以高安全、高质量、高可靠、高效率著称。依赖于质量、成本和进度的客户满意度，质量则是重点支撑之一，因此软件质量是民航业最为关心的问题之一。

　　二、软件质量管理的重要性

　　我们都知道pmbok把项目管理划分为9个知识领域，即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理。质量管理作为9大知识领域之一，可见其重要性。

　　质量管理包括：质量计划编制、质量保证和质量控制三个过程域。质量计划是质量管理的第一过程域，它主要结合各个公司的质量方针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略，其内容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，它是一个PDCA循环过程。

　　通常的情况是：软件组织的最高管理层根据组织所面临的形势和社会需要，制定出一定时期内组织经营活动所要达到的质量目标，然后层层落实，要求下属各部门管理者以至每个员工根据上级制定的质量目标制定出自己工作的质量目标和相应的保证措施，形成一个质量目标体系，并把质量目标完成的情况作为各部门或个人工作绩效评定的依据。然而，企业的质量目的和任务必须转化成质量目标，各级管理者必须通过质量目标对下级进行领导并以此来保证企业质量目标的实现。简言之，软件质量目标管理就是通过组织的管理者和员工亲自参与质量目标的制定，并在工作中实行“自我控制”以完成工作目标的一种管理制度或方法。

　　三、软件行业质量标准

　　目前业界认同的软件质量标准主要有两个：CMM和ISO 9001标准。

　　CMM：

　　1986年美国卡内基？梅隆大学软件工程研究院（SEI）应联邦政府的要求，着手研究一种对软件承包商过程能力进行评估的方法。1987年9月SEI发布了软件过程能力成熟框架的大纲，在大纲中定义了软件过程评估、软件能力评价两种方法及相应的问卷调查表。经过4年的实践，SEI将其发展成软件能力成熟模型SW-CMM （Capability Maturity Model for Software）。

　　SW-CMM描述了一个软件组织进行软件过程定义、项目实施与测试、过程控制与改善时必须经历的5个渐进的成熟等级及每一成熟等级相应的关键过程域（key process area）和关键实践（key practice）。软件组织可以依据SW-CMM标识现有软件过程中存在的关键问题，制定相应的软件过程改善策略，使软件组织的过程能力不断成熟，从而提高一个软件组织始终如一地、可预见性地生产高质量软件产品的能力。

　　六西格玛（Six Sigma） 　　又称：6σ，6Sigma，6Σ

　　6σ管理法是一种统计评估法，核心是追求零缺陷生产，防范产品责任风险，降低成本，提高生产率和市场占有率，提高顾客满意度和忠诚度。6σ管理既着眼于产品、服务质量，又关注过程的改进。“σ”是希腊文的一个字母，在统计学上用来表示标准偏差值，用以描述总体中的个体离均值的偏离程度，测量出的σ表征着诸如单位缺陷、百万缺陷或错误的概率性，σ值越大，缺陷或错误就越少。6σ是一个目标，这个质量水平意味的是所有的过程和结果中，99.99966% 是无缺陷的，也就是说，做100万件事情，其中只有3.4件是有缺陷的，这几乎趋近到人类能够达到的最为完美的境界（详见右图）。6σ管理关注过程，特别是企业为市场和顾客提供价值的核心过程。因为过程能力用σ来度量后，σ越大，过程的波动越小，过程以最低的成本损失、最短的时间周期、满足顾客要求的能力就越强。6σ理论认为，大多数企业在3σ～4σ间运转，也就是说每百万次操作失误在6210～66800之间，这些缺陷要求经营者以销售额在15%～30%的资金进行事后的弥补或修正，而如果做到6σ，事后弥补的资金将降低到约为销售额的5%。

　　为了达到6σ，首先要制定标准，在管理中随时跟踪考核操作与标准的偏差，不断改进，最终达到6σ。现己形成一套使每个环节不断改进的简单的流程模式：界定、测量、分析、改进、控制。

　　真正流行并发展起来，是在通用电气公司的实践，即20世纪90年代发展起来的6σ（西格玛）管理是在总结了全面质量管理的成功经验，提炼了其中流程管理技巧的精华和最行之有效的方法，成为一种提高企业业绩与竞争力的管理模式。该管理法在摩托罗拉、通用电气、戴尔、惠普、西门子、索尼、东芝行众多跨国企业的实践证明是卓有成效的。为此，国内一些部门和机构在国内企业大力推6σ管理工作，引导企业开展6σ管理。

　Solaris小技巧，虽然不常用，但很有用。

　　1、当用telnet访问另外一台工作站时，回格键不能用，Del键变成了回格键，如何使回格键恢复使用？

　　用如下命令：Stty erase ^H

　　2、当用telnet登录另外一台工作站时，如何使登录工作站的图形界面显示在本机上？

　　使用如下方法：

　　在telnet之前，先使用以下命令

　　#set |grep DIS 用于查本机终端编号，如5.0

　　#xhost +登录机主机名或IP地址

　　在telnet之后，使用：

　　#DISPLAY=本机主机名或IP地址：本机终端编号

　　#export DISPLAY

　　3、当root口令忘记时，怎么办？如何登录到root？

　　办法如下：

　　利用SOLARIS的启动盘来启动，然后把硬盘mount上去，修改硬盘上原etc目录下的shadow文件， 把root下的密码用一已知的用户密码代替，该密码就成为了root用户密码；或者干脆删除密码，变成无密码。然后重新启动主机，用该已知的用户密码就可登录root用户。

　　步骤如下：

　　（1）把你的solaris光盘放进cdrom

　　（2）键入stop+a

　　（3）当出现"ok"字样时,键入boot cdrom -s

　　（4）cd /tmp/root

　　（5）mkdir /tmp/root/xxx （xxx是什么鬼东西就无关紧要了）

　　（6）mount /dev/dsk/c0t0d0s0 /tmp/root/xxx （在这里c0t0d0s0是你的root盘）

　　（7）运行csh

　　（8）setenv TERM vt220

　　（9）cp /tmp/root/xxx/etc/shadow /tmp/root/xxx/shadow/shadow.bak

　　（10）vi /tmp/root/xxx/shadow,并且将root项里的password域删除即可。

　　（11）重启动，你就可以以无密码的root登陆了，这时更改你的密码。

4、如何动态改变SWAP区的大小？

　　方法是：先用mkfile建一个空文件，然后用Swap 命令即可；具体步骤，举例说明如下：如利用/export/home磁盘片中的空间，把swap区扩大200m（当然你可以要求更大）：

　　（1）#mkdir /export/home/swap

　　#cd /export/home/swap

　　该步可以没有，只是为了把扩充的交换区文件放在一个统一的目录（/export/home/swap）里面。

　　（2）#mkfile SIZEm swap1.file

　　（SIZE大小根据你的需求，该例中是200；swap1.file是一个SIZEm的空文件，名称可以随便你自己定）

　　（3）#swap -a /export/home/swap/swap1.file

　　（把交换区扩充SIZEm）

　　（4）建立/etc/rc2.d/S99swap并将第三步的内容写入。

　　（该步使系统重新启动时，可以自动把扩充的交换空间加上；如果没有该步，在系统重新启动后，需要手工加上，否则交换空间不会扩充）。

　　5、DOS文本文件到SOLARIS下的使用问题

　　如果在DOS下编的脚本文件，在SOLARIS下使用时，需要做一下变换，方法如下：在SOLARIS下用vi编辑器打开文件，按“shift+：”键进入命令模式，键入“1，$s/^M//g”，其中 ^ 是control+V键，M是control+M键。

　　6、内部网站上的Answerbook启动

　　用：/etc/init.d/ab2mgr start

　　7、当修改了SUN主机的PROM配置，想恢复缺省配置时

　　一个方法是直接用键盘敲入命令，但当输入设备设为非键盘时，该方法不行，请在重新启动机器时，按住“Stop+N”键，即恢复所有缺省配置。

　　8、answerbook的安装，进入……/product目录后，用如下命令：pkg -d .

　　9、SUN U60只能在单用户模式下运行，如何恢复？

　　问题描述：

　　为了将工作站设为从DHCP动态分配IP，并且将主机名由"unknown"改为原名

　　修改了/etc/init.d/rootusr，将dhcpinfo后面三行（不是四行）注释掉；

　先把要恢复的文件置于MS SQL里的DATA文件里，进入MS SQL主数据库服务器。

　　1、我们使用默认方式建立一个供恢复使用的数据库(如MHDYF2005)。可以在SQL Server里面建立。

　　2、停掉数据库服务器。

　　3、将刚才生成的数据库的日志文件MHDYF2005_log.ldf删除，用要恢复的数据库mdf（yu1.mdf）文件覆盖刚才生成的数据库数据文件MHDYF2005_data.mdf。

　　4、启动数据库服务器。（刷新之后）此时会看到数据库MHDYF2005的状态为“置疑”。这时候不要对此数据库进行任何操作。

　　5、设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。 use mastergosp_configure ‘allow updates‘,1goreconfigure with overridego

　　6、设置MHDYF2005为紧急修复模式，语句如下： update sysdatabases set status=-32768 where dbid=DB_ID(‘MHDYF2005‘)

　　此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读置疑脱机紧急模式”可以看到数据库里面的表，但是仅仅有系统表。

　　7、下面执行真正的恢复操作，重建数据库日志文件 dbcc rebuild_log(‘MHDYF2005‘,‘C:Program FilesMicrosoft SQL ServerMSSQLDataMHDYF2005_log.ldf‘)

　　执行过程中，如果遇到下列提示信息： 服务器: 消息 5030，级别 16，状态 1，行 1

　　未能排它地锁定数据库以执行该操作。

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了MHDYF2005库的系统表，那么退出SQL Server Enterprise Manager就可以了。

　　正确执行完成的提示应该类似于：

　　警告: 数据库 ‘MHDYF2005‘ 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

　　8、验证数据库一致性(可省略)，语句如下： dbcc checkdb(‘MHDYF2005‘)

　　一般执行结果如下：CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 ‘MHDYF2005‘ 中）。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　9、设置数据库为正常状态，语句如下： sp_dboption ‘MHDYF2005‘,‘dbo use only‘,‘false‘

　　如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

　　10、最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成： sp_configure ‘allow updates‘,0goreconfigure with overridego

下面这张图给出了nio类库的各个类之间的关系，这样你就能知道该怎样移动和转换数据了。举例来说，如果你想把byte数组写进文件，你得先用ByteBuffer.wrap( )方法把这个byte数组wrap成buffer，再用getChannel( )在FileOutputStream上打开一个channel，然后才能用ByteBuffer把数据写入FileChannel。

　　注意，ByteBuffer是往channel里读写数据的唯一途径，而且你只能创建这一种byte基本类型的缓冲器ByteBuffer，其余基本类型的缓冲器要用"as" 方法来获取 。另外你不能把基本类型buffer转换成ByteBuffer ，不过你可以用view buffer往ByteBuffer里读写基本类型数据 ，所以这实际上也不是什么限制了。

　　另外，视图是一种逻辑上的概念，通过视图操作实质上就是对ByteBuffer的操作，就像通过Iterator操作List一样。虽然我们可以用wrap() 直接把char数组转换成CharBuffer，但实际上它还是一个ByteBuffer，而CharBuffer只是它的view。由此可知，我们操控的对象永远都是ByteBuffer，因为只有它才能往channel里读写数据 ，其他基本类型数据缓冲器原理一样。