让开发自动化: 部署和配置持续集成Apache Continuum(转)
Apache Continuum 是最新的 CI 服务器之一，也是值得关注的一个新进入者。Continuum 的安装和配置很简单：只要下载和释放 ZIP 文件，运行命令行程序，就可以运行了。基于 Web 的界面使得配置项目很容易。而且，还不需要安装 Web 服务器，因为 Continuum 内置了 Jetty Web 服务器。并且，Continuum 可以作为 Windows 服务运行，还在应用程序的某些部分嵌入了上下文敏感的文档，从而提供了很多帮助。
Apache Continuum的特性：       与Maven 2.x的紧密集成
      与Maven SCM的紧密集成，支持Subversion/CVS/Starteam/Clearcase/Perforce
      基于web的容易使用的安装和配置接口
      Quartz-based scheduling
      简单的添加新的项目工程的方法
      用于 integration, automation and remoting的XML-RPC interface
      邮件提醒和IM（即时通讯）提醒IRC/Jabber/MSN
1.下载安装包：http://maven.apache.org/continuum/download.html 目前最新的是1.0.3的版本，相信不久的将来会有更新的版本发布，有更多的功能可以使用
 continuum-1.0.3-bin.tar.gz 放到/java目录下
2. 解压并安装
tar zxvf continuum-1.0.3-bin.tar.gz
生成continuum-1.0.3 目录，它下面的目录结构：apps  bin  conf  core  logs  services  temp
bin下的是可执行文件，有linux  macosx  solaris  win32下相应的启动服务脚本
apps下是continuum 的web应用程序
continuum-1.0.3/apps/continuum/conf/application.xml下的文件就是该web程序的配置文件，可以修改端口，mail发送的host和数据库相关的配置文件
3.启动web应用程序
运行脚本 continuum-1.0.3/bin/linux/run.sh 提供{ console | start | stop | restart | status | dump }这样的参数，意思就不用我介绍了吧！
运行脚本run.sh start启动web应用程序。
4.浏览器访问http://localhost:8080/continuum/servlet/continuum
就进入管理界面，需要设置管理员用户名和密码和公司的一些基本信息。
然后用管理员用户名和密码登录就可以管理和设置了。
5.对continuum进行初始化设置
需要添加Project 有
Maven 2.0+ Project
Maven 1.x Project
Ant Project
Shell Project 四种类型可以选择。
我这里选择的是Ant Project，需要填写项目名称，版本，版本控制url，版本控制服务器的用户名和密码
我们使用的是subversion的版本控制的服务器。url为scm:svn:http://192.168.1.1/e-learning/trunk
其他的地址到http://maven.apache.org/scm/scm-url-format.html这里查看。在管理栏目中有
Schedules ：Cron Expression的填写可以查看http://www.opensymphony.com/quartz/api/org/quartz/CronTrigger.html 默认的schedule是一个小时执行一次
Configuration 对项目工程取出的地址和日志生成的目录的修改
User Groups Management （用户组）
Users Management（用户） 配置完成后，就可以让它自动build或是我们手工build一下。还可以设置是否增加邮件或其他形式的提醒。
总结的特点：容易使用，界面美观，功能合适，支持ant，maven，subversion等开源项目，还有就是此项目是大名鼎鼎的apache旗下的开源项目。
其他的持续集成服务器可以参考ibm的文章

一、什么是oracle字符集 　　 Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储，处理，检索数据。它使数据库工具，错误消息，排序次序，日期，时间，货币，数字，和日历自动适应本地化语言和平台。 　　 影响oracle数据库字符集最重要的参数是NLS_LANG参数。 它的格式如下: 　　NLS_LANG = language_territory.charset 　　 它有三个组成部分(语言、地域和字符集)，每个成分控制了NLS子集的特性。 其中: 　　 Language 指定服务器消息的语言，territory 指定服务器的日期和数字格式，charset 指定字符集。如:AMERICAN _ AMERICA. ZHS16GBK 　　 从NLS_LANG的组成我们可以看出，真正影响数据库字符集的其实是第三部分。 所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据，前面影响的只是提示信息是中文还是英文。 二.查看数据库字符集 这涉及三方面的字符集， 一是oracel server端的字符集; 二是oracle client端的字符集; 三是dmp文件的字符集。 在做数据导入的时候，需要这三个字符集都一致才能正确导入。 　 　1、查询oracle server端的字符集 　　        有很多种方法可以查出oracle server端的字符集，比较直观的查询方法是以下这种:       SQL>select userenv(‘language’) from dual; 　　       结果类似如下:AMERICAN _ AMERICA. ZHS16GBK 　　    2、如何查询dmp文件的字符集 　　       用oracle的exp工具导出的dmp文件也包含了字符集信息，dmp文件的第2和第3个字节记录了dmp文件的字符集。如果dmp文件不大，比如只有几M或几十M，可以用UltraEdit打开(16进制方式)，看第2第3个字节的内容，如0354，然后用以下SQL查出它对应的字符集: 　　       SQL> select nls_charset_name(to_number('0354','xxxx')) from dual; 　　         ZHS16GBK 　　      如果dmp文件很大，比如有2G以上(这也是最常见的情况)，用文本编辑器打开很慢或者完全打不开，可以用以下命令(在unix主机上): 　　       cat exp.dmp |od -x|head -1|awk '{print $2 $3}'|cut -c 3-6 　　      然后用上述SQL也可以得到它对应的字符集。 3、查询oracle client端的字符集 　　 这个比较简单。 在windows平台下，就是注册表里面相应OracleHome的NLS_LANG。还可以在dos窗口里面自己设置，比如: 　　set nls_lang=AMERICAN_AMERICA.ZHS16GBK 　　 这样就只影响这个窗口里面的环境变量。 　　 在unix平台下，就是环境变量NLS_LANG。 　　 $echo $NLS_LANG 　　 AMERICAN_AMERICA.ZHS16GBK 　　 如果检查的结果发现server端与client端字符集不一致，请统一修改为同server端相同的字符集。 补充： (1).数据库服务器字符集 select * from nls_database_parameters 来源于props$，是表示数据库的字符集。 (2).客户端字符集环境 select * from nls_instance_parameters 其来源于v$parameter，表示客户端的字符集的设置，可能是参数文件，环境变量或者是注册表 (3).会话字符集环境 select * from nls_session_parameters 来源于v$nls_parameters，表示会话自己的设置，可能是会话的环境变量或者是alter session完成，如果会话没有特殊的设置，将与nls_instance_parameters一致。 (4).客户端的字符集要求与服务器一致，才能正确显示数据库的非Ascii字符。如果多个设置存在的时候，alter session>环境变量>注册表>参数文件 字符集要求一致，但是语言设置却可以不同，语言设置建议用英文。如字符集是zhs16gbk，则nls_lang可以是American_America.zhs16gbk。 三、修改oracle的字符集 　　 上文说过，oracle的字符集有互相的包容关系。如us7ascii就是zhs16gbk的子集,从us7ascii到zhs16gbk不会有数据解释上的问题,不会有数据丢失。在所有的字符集中utf8应该是最大,因为它基于unicode,双字节保存字符(也因此在存储空间上占用更多)。 　　 一旦数据库创建后，数据库的字符集理论上讲是不能改变的。因此，在设计和安装之初考虑使用哪一种字符集十分重要。根据Oracle的官方说明，字符集的转换是从子集到超集受支持,反之不行。如果两种字符集之间根本没有子集和超集的关系，那么字符集的转换是不受oracle支持的。对数据库server而言，错误的修改字符集将会导致很多不可测的后果，可能会严重影响数据库的正常运行，所以在修改之前一定要确认两种字符集是否存在子集和超集的关系。一般来说，除非万不得已，我们不建议修改oracle数据库server端的字符集。特别说明，我们最常用的两种字符集ZHS16GBK和ZHS16CGB231280之间不存在子集和超集关系，因此理论上讲这两种字符集之间的相互转换不受支持。 　　 1、修改server端字符集(不建议使用) 　 　在oracle 8之前，可以用直接修改数据字典表props$来改变数据库的字符集。但oracle8之后，至少有三张系统表记录了数据库字符集的信息，只改props$表并不完全，可能引起严重的后果。正确的修改方法如下: $sqlplus /nolog 　　 SQL>conn / as sysdba; 　　若此时数据库服务器已启动，则先执行SHUTDOWN IMMEDIATE命令关闭数据库服务器，然后执行以下命令: 　 SQL>STARTUP MOUNT; 　　 SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION; 　　 SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; 　　 SQL>ALTER SYSTEM SET AQ_TM_PROCESSES=0; 　　 SQL>ALTER DATABASE OPEN; 　　 SQL>ALTER DATABASE CHARACTER SET ZHS16GBK; 　　 SQL>ALTER DATABASE national CHARACTER SET ZHS16GBK; 　　 SQL>SHUTDOWN IMMEDIATE; 　　 SQL>STARTUP 注意：如果没有大对象，在使用过程中进行语言转换没有什么影响，（切记设定的字符集必须是ORACLE支持，不然不能start） 按上面的做法就可以,但是可能会出现‘ORA-12717: Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists’ 这样的提示信息 要解决这个问题有两种方法 一个是,利用INTERNAL_USE 关键字修改区域设置, 还有一个是利用re-create,但是re-create有点复杂,所以请用internal_use, SQL>SHUTDOWN IMMEDIATE; SQL>STARTUP MOUNT EXCLUSIVE; SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION; SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0; SQL>ALTER SYSTEM SET AQ_TM_PROCESSES=0; SQL>ALTER DATABASE OPEN; SQL>ALTER DATABASE NATIONAL CHARACTER SET INTERNAL_USE UTF8; SQL>SHUTDOWN immediate; SQL>startup; 如果按上面的做法做,National charset的区域设置就没有问题 2、修改dmp文件字符集 　　 上文说过，dmp文件的第2第3字节记录了字符集信息，因此直接修改dmp文件的第2第3字节的内容就可以‘骗’过oracle的检查。这样做理论上也仅是从子集到超集可以修改，但很多情况下在没有子集和超集关系的情况下也可以修改，我们常用的一些字符集，如US7ASCII，WE8ISO8859P1，ZHS16CGB231280，ZHS16GBK基本都可以改。因为改的只是dmp文件，所以影响不大。 　　 具体的修改方法比较多，最简单的就是直接用UltraEdit修改dmp文件的第2和第3个字节。 比如想将dmp文件的字符集改为ZHS16GBK，可以用以下SQL查出该种字符集对应的16进制代码: 　　SQL> select to_char(nls_charset_id('ZHS16GBK'), 'xxxx') from dual; 　　 0354 　　 然后将dmp文件的2、3字节修改为0354即可。 　　 如果dmp文件很大，用ue无法打开，就需要用程序的方法了。

质量衡量标准 (标尺)

可清晰量化的衡量产品质量
测试覆盖率-代码块覆盖,功能覆盖,用例覆盖.... 这么多覆盖率,每个覆盖率,合理的目标是多少? 50%? 80% 100%
按照找到的缺陷数目,多少是被用户找到的,多少是被内部非测试团队找到的,多少是被测试团队找到的,以此为衡量质量的标尺之一?
重复发生的回归性缺陷数目 
补丁和Service package数量,来衡量质量 
我们有这么多可以用来衡量质量的标准,那么,哪些应该是核心的标准,最重要的普遍标准.怎么把各个标准和质量关联上?
制定发布的质量指标,怎样才是正确的指标,可以指导我们决定发布还是延迟发布产品直到我们达到该指标.
怎么定义测试效率?包括怎么衡量s变化对测试的影响..
怎么定义测试"完成"了?

复杂领域产品测试:

音频和视频质量测试
"看起来效果对吗?"
"听起来效果对吗?"
效果"好"吗?
各种主观类型的测试判断

测试工具对系统本身的影响(测不准原理?):

性能测试工具本身对机器性能的影响所导致的测不准效果.

测试要素的各种组合(测试范围庞大):

测试要素组合, 覆盖各种可能组合,将变得庞大: 操作系统 vs. 调试/发布 vs. 硬件配置 vs. 各种语言 vs. etc. vs. etc.
无穷无尽的用户可能输入.
有时间相关性的产品的测试.各种时间可能的穷举是无限的.

整个产品范围测试中的问题

整个产品的压力测试 
这个产品性能测试 vs. 各个开发组对自己模块所作的性能测试
集成测试.

测试集优选:

由时间和进度影响决定?
由用户影响决定?
由平均测试用例所找到的缺陷数决定? (或者考虑其他投资回报因素而决定)
挑选测试用例覆盖了所更改的代码,依此决定?
由所要测试的代码复杂度决定?

项目计划安排:

准确估计测试所需要的时间.
测试团队如何参与决定项目整体进度计划.
敏捷快速迭代测试的计划安排.

测试对项目的影响:

争取修复缺陷– i.e. 比如要求开发组修复缺陷,而他们回答"没人会这么做!", 这个时候怎么有理有据的坚持要求修复缺陷.
设计阶段的测试团队参与 – 可测试性的分析/设计.
是否该拥有对发布/不发布的决策的影响.

测试自动化:

自动化测试用例的后期维护梦魇.
怎么模拟人眼人耳来做自动化测试(音频/视频测试)
产品代码中缺乏足够的接口来支持自动化测试(比如开发人员自己画出来的控件)
模拟N用户操作的自动化测试(N非常大)
模拟真实的用户-- [随机的用户行为]

集成测试:

集成测试中的自动化测试
调试的责任,谁做集成测试,谁负责调试整个产品中的问题?
集成测试应该包含哪些测试用例?

其他普遍的难题:

几个版本发布之后,积累的测试代码变得臃肿和难以维护.
设计不好的测试代码,重复的测试代码,各个测试自动化队伍之间缺乏总体的设计和架构避免冗余工作
冗余的测试用例
留住有经验的测试人才

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/omomo/archive/2007/06/10/1646233.aspx

1、  测试计划和实际情况的偏差过大

在项目开发中，这个问题并不是我们测试管理个别问题，几乎每个项目的计划都和实际存在偏差，而对于这个问题，很多的团队都是采用滚动式计划方式，及时根据环境条件和实际完成情况定期或者临时的来进行小范围的调整计划，对于大范围的计划变更，即测试管理团队无法解决的，应该上报风险；

2、  测试策略的制定没有达到其效果

在说明其问题之前，我们先清楚一下几个名词的概念：测试方案，测试策略和测试用例

测试方案是对测试工作上的总体描述，测试方案我个人认为是测试的系统架构；

测试策略可以分为粗放型和精细型，我个人任务粗放型的测试策略可以相当于概要设计，而精细型的测试策略可以相当于详细设计；

测试用例比较好理解，这个相当于程序代码了；

所以说我们在进行测试策略的设计时，我们的目标是什么，是详设还是概设？当我们定下目标后，我们就非常清楚的知道，测试策略在测试用例设计中的作用和其应用的效果了；

3、  测试阶段的划分

关于测试阶段划分不明确的问题，我个人认为这点是第一个问题中的一个具体问题展现，同时其测试阶段的划分除了其计划时的划分外，还需要根据其测试的情况适当的调整其测试周期，如根据bug的多少趋势或者达到某个标准时，退出此阶段进入下一阶段；

4、  测试团队沟通

在上次测试总结中，说此问题是个人和组员的问题，我认为那个说法是片面的，其主管不仅负责自己和下属的沟通，还要负责组织组员和组员之间的沟通；同时团队中的沟通不仅仅是工作信息之间的传输，还包括其他方面之间的信息流通

5、  测试报告总结

系统第一阶段的测试报告总共有80多页，而测试BUG汇总的信息就占了30多页，而BUG汇总信息在缺陷管理工具中已经存在，同时这些信息，领导们不会关心这么详细，个人认为在测试报告中不需要体现了，在测试报告中更多是统计汇总的信息，还有通过统计汇总的信息对前一阶段工作进行总结和对其版本的质量进行评估

6、  测试工作总结

在我们团队中，对于此类的总结会议上，大家谈论的都是我们工作中存在的问题，而对我们取得成绩和付出的努力，大家都没有去表扬；问题应该去讨论并解决，但我们取得的成绩也不能忽略不提。所以我建议在工作总结上还是先肯定大家的成绩，然后在讨论问题；

对于自己想要什么，自己要清楚……你究竟是要过谁的一生？……人的一生不是父母一生的续集，也不是儿女一生的前传，更不是朋友一生的外篇……只有你自己对自己的一生负责，别人无法也负不起这个责任。

两个不如意的年轻人，一起去拜望师父：“师父，我们在办公室被欺负，太痛苦了，求你开示，我们是不是该辞掉工作？” 两个人一起问。

　　师父闭着眼睛，隔半天，吐出五个字 ：“不过一碗饭”。就挥挥手，示意年轻人退下了。

　　才回到公司，一个人就递上辞呈，回家种田，另一个什么也没动。

　　日子真快，转眼十年过去了。回家种田的以现代方法经营，加上品种改良，居然成了农业专家。另一个留在公司的，也不差。他忍着气，努力学，渐渐受到器重，成了经理。

　　有一天两个人遇到了。

　　奇怪，师父给我们同样“不过一碗饭”这五个字，我一听就懂了。不过一碗饭嘛， 日子有什么难过？何必硬巴在公司?所以辞职，农业专家问另一个人：“你当时为何没听师父的话呢?”

　　“我听了啊，”那经理笑道：“师父说‘不过一碗饭’，多受气，多受累，我只要想不过为了混碗饭吃，老板说什么是什么，少赌气，少计较，就成了，师父不是这个意思吗?”

　　两个人又去拜望师父，师父已经很老了，仍然闭着眼睛，隔半天，答了五个字，“不过一念间”然后挥挥手……

　　是不是很有意思呢？很多事， 真的是一念之间啊，所以在决定什么事时， 要多想想哦

　　抉择固然是重要的，可是抉择后的坚持更是重要的。无论你做什么样的选择，你一定要坚持下去，你总有成就的。

 

Test Director 8.0 修改好的字体文件 tdclientui80.ocx

[TD服务器]
首先把下载的控件后缀名改变命名为TDClientUI80.xco
然后备份TDBIN\Install\TDClientUI80.xco文件改为 TDClientUI80.xco_bak
拷贝下载后的TDClientUI80.xco控件到TDBIN\Install\文件目录下
[TD客户端]
第一种方法：删除这个路径下整个文件夹 C:\Program Files\Common Files\Mercury Interactive\重新打开浏览器下载(如果浏览器是开着，系统会提示控件正在使用)
第二种方法：删除这个路径C:\Program Files\Common Files\Mercury Interactive\TD2000_80下的tdclientui80.ocx
这里主要区分一下：服务器BIN文件下的后缀为[ XCO ]，而客户端文件下的后最是[ OCX ]

教你DIY

来源：http://bbs.btestsky.com/redirect.php?tid=1041&goto=lastpost

TD8.0中不清楚的（尤其是中文）字体似乎是8磅，改成9磅就很清楚。但是TD8.0并没有提供改字体的功能。在高人的指导下，我找到并修改了字体的设置。

在第一次连接TD8.0服务器时，会下载一些文件，其中就包括控制字体的文件。下载后的文件控制TD8.0字体。

客户机上的这个文件就是位于文件夹C:\Program Files\Common Files\Mercury Interactive\TD2000_80的tdclientui80.ocx。要修改其中的字体设置，需要先解开文件然后修改设置，最后还要重新压缩。

1、解开文件 -- 使用stripper（可以下载）
========================
这个OCX文件必须解开才能编辑，解压缩后的文件变得很大。

2、修改文件 -- 使用PE Explorer（可以下载）
==========================
用PE Explorer打开这个OCX文件后，找到RC数据。接下来就要在这些数据中边找边猜了。

在RC数据中，字体不是FontSize而是FontHeight，8磅字的对应数值是-11，9磅对应的是-12。因此可以在RC数据中搜索“-11”，确认是需要修改的字体大小就把-11改成-12，这样能减少很多翻看查找的时间。

3、重新压缩 -- 使用ASPack（可以下载）
========================
修改了RC数据之后（就是FontHeight从-11改为-12，如果需要改字体也可以，不过当心不要输错了字体名字；需要汉化标题也可以，不过更要小心），要压缩这个OCX文件才能再使用，压缩之后OCX又恢复了原来的大小。

以上是在客户机上修改ocx文件的方法。

修改好的ocx文件也可以放在服务器上，方法如下：

服务器(TD8.0的宿主机)的目录C:\Inetpub\TDBIN\Install中有一个文件名为tdclientui80.xco，俺猜这个文件 下载到客户机之后后缀就改成.ocx了，于是我就把修改好的tdclientui80.ocx文件改了后缀，覆盖了这个服务器上的文件。

按理说现在在客户机上登录TD8.0应该自动更新ocx文件，可有些客户机并不是这样，道理我也不清楚。不过我在客户机上删除了tdclientui80.ocx之后，就自动下载了新的文件，字体也改大了。

Web应用防火墙正日趋流行，过去这些工具被很少数的大型项目垄断，但是，随着大量的低成本产品的面市以及可供选择的开源试用产品的出现，它们最终能被大多数人所使用。在这篇文章中，先向大家介绍Web应用防火墙能干什么，然后快速的概览一下Web应用防火墙最有用的一些特征。通过这篇文章的阅读，大家能清楚地了解web应用防火墙这个主题，掌握相关知识。

什么是web应用防火墙？

    有趣的是，还没有人能真正知道web应用防火墙究竟是什么，或者确切的说，还没有一个大家认可的精确定义。从广义上来说，Web应用防火墙就是一些增强 Web应用安全性的工具。然而，如果我们要深究它精确的定义，就可能会得到更多的疑问。因为一些Web应用防火墙是硬件设备，一些则是应用软件；一些是基于网络的，另一些则是嵌入WEB服务器的。

国外市场上具有WEB应用防火墙功能的产品名称就有不同的几十种，更不用说是产品的形式和描述了。它难以界定的原因是这个名称包含的东西太多了。较低的网络层（Web应用防火墙被安置在第七层）被许多设备所覆盖，每一种设备都有它们独特的功能，比如路由器，交换机，防火墙，入侵检测系统，入侵防御系统等等。然而，在HTTP的世界里，所有这些功能都被融入在一个设备里：Web应用防火墙。

总体来说，Web应用防火墙的具有以下四个方面的功能：

  1. 审计设备：用来截获所有HTTP数据或者仅仅满足某些规则的会话

  2. 访问控制设备：用来控制对Web应用的访问，既包括主动安全模式也包括被动安全模式

  3. 架构/网络设计工具：当运行在反向代理模式，他们被用来分配职能，集中控制，虚拟基础结构等。

  4. WEB应用加固工具：这些功能增强被保护Web应用的安全性，它不仅能够屏蔽WEB应用固有弱点，而且能够保护WEB应用编程错误导致的安全隐患。

但是，需要指出的是，并非每种被称为Web应用防火墙的设备都同时具有以上四种功能。

由于WEB应用防火墙的多面性，拥有不同知识背景的人往往会关注它不同方面的特点。比如具有网络入侵检测背景的人更倾向于把它看作是运行在HTTP层上的 IDS设备；具有防火墙自身背景的人更趋向与把它看作一种防火墙的功能模块。还有一种理解来自于“深度检测防火墙”这个术语。他们认为深度检测防火墙是一种和Web应用防火墙功能相当的设备。然而，尽管两种设备有些相似之处，但是差异还是很大的。深度检测防火墙通常工作在的网络的第三层以及更高的层次，而 Web应用防火墙则在第七层处理HTTP服务并且很好地支持它。

直接更改WEB代码解决安全问题是否更好？这是毋庸置疑的，但也没那么容易（实现）。

    因为，通过更改WEB应用代码是否一定就能增强系统安全性能，这本身就存在争论。而且现实也更加复杂：

    * 不可能确保100%的安全。人的能力有限，会不可避免地犯错误。
    * 绝大多数情况下，很少有人力求100%的安全。如今的现实生活中那些引领应用发展的人更多注重功能而不是安全。这种观念正在改变，只是有点缓慢。
    * 一个复杂的系统通常包含第三方产品（组件，函数库），它们的安全性能是不为人知的。如果这个产品的源代码是保密的，那么你必须依赖商品的厂商提供补丁。即使有些情况下源代码是公开的，你也不可能有精力去修正它们。
    * 我们不得不使用存在安全隐患的业务系统，尽管这些旧系统根本无法改进。

    因此，为了获得最好的效果，我们需要双管齐下：一方面，必须提高管理者和开发者的安全意识；另一方面，尽可能提高应用系统的安全性。

Web应用防火墙的特点

    Web应用防火墙的一些常见特点如下。

异常检测协议

    如果阅读过各种RFC，就会发现一个被反复强调的主题。大多数RFC建议应用自己使用协议时要保守，而对于接受其他发送者的协议时可以自由些。Web服务器就是这样做的，但这样的行为也给所有的攻击者打开了大门。几乎所有的WAF对HTTP的请求执行某种异常检测，拒绝不符合Http标准的请求。并且，它也可以只允许HTTP协议的部分选项通过，从而减少攻击的影响范围。甚至，一些WAF还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。

增强的输入验证

    就频繁发生的Web安全问题而言，有些是源于对Web设计模型的误解，有些则来自于程序师认为浏览器是可信的。很多WEB程序员用JavaScript在浏览器上实现输入验证。而浏览器只是一个用户控制的简单工具，因此攻击者可以非常容易地绕过输入验证，直接将恶意代码输入到WEB应用服务器。

有一个解决上述问题的正确方法，就是在服务端进行输入验证。如果这个方法不能实现，还可以通过在客户和应用服务器之间增加代理，让代理去执行Web页面上嵌入的JavaScript，实现输入验证。


消极的安全模型VS积极的安全模型

    曾经设置过防火墙规则的人，可能会碰到这样的建议：允许已知安全的流量，拒绝其他一切访问。这就是一种很好的积极安全模型。恰恰相反，消极安全模型则是默认允许一切访问，只拒绝一些已知危险的流量模式。

每种安全模型方式都存在各自的问题：

    消极安全模型：什么是危险的？

    积极安全模型：什么是安全的？

    消极安全模式通常使用的更多。识别出一种危险的模式并且配置自己的系统禁止它。这个操作简单而有趣，却不十分安全。它依赖于人们对于危险的认识，如果问题存在，却没有被意识到（这种情况很常见），就会为攻击者留下可趁之机。

积极安全模式（又称为白名单模式）看上去是一种制定策略的更好方式,非常适于配置防火墙策略。在Web应用安全领域中，积极安全模式通常被概括成对应用中的每一个脚本的枚举。对枚举的每一个脚本，需要建立一个相应列表，表中内容如下所示：

    * 允许的请求方式（比如，GET/POST或者只POST）
    * 允许的Content-Type
    * 允许的Content-Length
    * 允许的参数
    * 指定参数和可选参数
    * 参数类型（比如，文本或整数）
    * 附加参数限制

    上述列表仅仅是个例子，实际的积极安全模式通常包括更多的要素。它试图从外部完成程序员本应从内部完成的工作：为提交到Web应用的信息验证每一个比特。如果肯花时间的话，使用积极安全模式就是一个比较好的选择。这个模式的难点之一，在于应用模式会随着应用的发展而改变。每当应用中添加新脚本或更改旧脚本，就需要更新模式。但是，它适用于保护那些稳定的、无人维护的旧应用。

    自动开发策略可以解决以上问题：

    * 一些WAF能够监视流量，并根据这些流量数据自动配置策略，有些产品可以实时进行这样的工作。
    * 通过白名单，可以标识特定的IP地址是可信的，然后，依据观察的流量，配置WAF，更新安全策略。
    * 如果通过一个全面的衰减测试，（仿真正确的行为，）来创建一个应用，并且在WAF处于监控状态时执行测试，那么WAF可以自动生成策略。

    可见，没有哪个模式是完全令人满意的。消极安全模式适用于处理已知问题，而积极安全模式则适用于稳定的Web应用。理想的做法是，在现实生活中，将二者结合使用，取长补短。


及时补丁

    积极安全模式理论上更好一些因为浏览器和WEB应用程序之间的通信协议通过HTML规范进行了很好的定义。现在的Web开发语言都可以处理带有多个参数的 HTTP请求。因为这些参数在Web应用防火墙中都是可见的，因此WEB应用防火墙可以分析这些参数判断是否存在允许该请求。，

当一个应用中的漏洞被发现时大多数情况下我们会尽可能在代码中修补它。受诸多因素的影响（如应用的规模，是否有开发人员，法律问题等等 ），开发补丁的过程可能需要几分钟，或者一直到无限长的是时间。这些时间正是攻击者发起攻击的好机会。

如果开发人员能够在非常短的时间内在代码中修补好漏洞，那你就不用担心了。但如果修补这个漏洞需要花费几天，甚至几周来修复呢？Web应用防火墙就是处理这个问题的理想工具：只要给一个安全专家不错的WAF和足够的漏洞信息，他就能在不到一个小时的时间内屏蔽掉这个漏洞。当然，这种屏蔽掉漏洞的方式不是非常完美的，并且没有安装对应的补丁就是一种安全威胁，但我们在没有选择的情况下，任何保护措施都比没有保护措施更好。

及时补丁的原理可以更好的适用于基于XML的应用中，因为这些应用的通信协议都具规范性。


基于规则的保护和基于异常的保护

    现在市场上大多数的产品是基于规则的WAF。其原理是每一个会话都要经过一系列的测试，每一项测试都由一个过多个检测规则组成，如果测试没通过，请求就会被认为非法并拒绝。

基于规则的WAFs很容易构建并且能有效的防范已知安全问题。当我们要制定自定义防御策略时使用它会更加便捷。但是因为它们必须要首先确认每一个威胁的特点，所以要由一个强大的规则数据库支持。WAF生产商维护这个数据库，并且他们要提供自动更新的工具。

    这个方法不能有效保护自己开发的WEB应用或者零日漏洞（攻击者使用的没有公开的漏洞），这些威胁使用基于异常的WAF更加有效。

异常保护的基本观念是建立一个保护层，这个保护层能够根据检测合法应用数据建立统计模型，以此模型为依据判别实际通信数据是否是攻击。理论上，一但构建成功，这个基于异常的系统应该能够探测出任何的异常情况。拥有了它，我们不再需要规则数据库而且零日攻击也不再成问题了。但基于异常保护的系统很难构建，所以并不常见。因为用户不了解它的工作原理也不相信它，所以它也就不如基于规则的WAF应用广范。


状态管理

    HTTP的无状态性对Web应用安全有很多负面影响。会话只能够在应用层上实现，但对许多应用来说这个附加的功能只能满足业务的需要而考虑不到安全因素了。Web应用防火墙则将重点放在会话保护上，它的特征包括：

强制登录页面。在大多数站点， 你可以从任何你所知道的URL上访问站点，这通常方便了攻击者而给防御增加了困难。WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。

分别检测每一个用户会话。如果能够区分不同的会话，这就带来了无限的可能。比如，我们能够监视登陆请求的发送频率和用户的页面跳转。通过检测用户的整个操作行为我们可以更容易识别攻击。

对暴力攻击的识别和响应。通常的Web应用网络是没有检测暴力攻击的。有了状态管理模式，WAF能检测出异常事件（比如登陆失败），并且在达到极限值时进行处理。此时它可以增加更多的身份认证请求的时间，这个轻微的变化用户感觉不到，但对于足以对付自动攻击脚本了。如果一个认证脚本需要50毫秒完成，那它可以发出大约每秒20次的请求。如果你增加一点延时，比如说，一秒种的延迟，那会将请求降低至每秒不足一次。与此同时，发出进一步检测的警告，这将构成一个相当好的防御。

实现会话超时。超出默认时间会话将失效，并且用户将被要求重新认证。用户在长时间没有请求时将会自动退出登录。

会话劫持的检测和防御。许多情况下，会话劫持会改变IP地址和一些请求数据（HTTP请求的报头会不同）。状态监控工具能检测出这些异常并防止非法应用的发生。在这种情况下应该终止会话，要求用户重新认证，并且记录一个警告日志信息。

只允许包含在前一请求应答中的链接。一些WAF很严格，只允许用户访问前一次请求返回页面中的链接。这看上去是一个有趣的特点但很难得到实施。一个问题在于它不允许用户使用多个浏览器窗口，另一个问题是它令使用JavaScript自动建立连接的应用失效。


其他防护技术

    WAF的另外一些安全增强的功能用来解决WEB程序员过分信任输入数据带来的问题。比如：

    隐藏表单域保护。有时，内部应用数据通过隐藏表单变量实现，而它们并不是真的隐藏的。程序员通常用隐藏表单变量的方式来保存执行状态，给用户发送数据，以确保这些数据返回时未被修改。这是一个复杂繁琐的过程，WAF经常使用密码签名技术来处理。
原文：www.iisutm.com
    Cookies保护。和隐藏表单相似的是，cookies经常用来传递用户个人的应用数据，而不一样的是，一些cookies可能含有敏感数据。WAFs 通常会将整个内容加密，或者是将整个cookies机制虚拟化。有了这种设置，终端用户只能够看到cookies令牌（如同会话令牌），从而保证 cookies在WAF中安全地存放

    抗入侵规避技术。基于网络的IDS对付WEB攻击的问题就是攻击规避技术。改写HTTP输入请求数据（攻击数据）的方式太多，并且各种改写的请求能够逃避IDS探测。在这个方面如果能完全理解HTTP就是大幅度的改进。比如，WAF每次可以看到整个HTTP请求，就可以避免所有类型的HTTP请求分片的攻击。因为很好的了解HTTP协议，因此能够将动态请求和静态请求分别对待，就不用花大量时间保护不会被攻击的静态数据。这样WAF可以有足够的计算能力对付各种攻击规避技术， 而这些功能由NIDSs完成是很耗时的。

    响应监视和信息泄露保护。信息泄露防护是我们给监视HTTP输出数据的一个名称。从原理上来说它和请求监视是一样的，目的是监视可疑的输出，并防止可疑的 http输出数据到达用户。最有可能的应用模式是监视信用卡号和社会保险号。另外，这个技术的另一项应用是发现成功入侵的迹象。因为有经验攻击者总会给信息编码来防止监测，所以防止这样有决心并技术熟练的攻击者获取信息是很困难的。但是，在攻击者没有完全掌控服务器而仅仅尝试WEB应用的安全漏洞的情况下，这项技术可以起到防护效果

软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

用户认证安全的测试要考虑问题：

1.         明确区分系统中不同用户权限

2.         系统中会不会出现用户冲突

3.         系统会不会因用户的权限的改变造成混乱

4.         用户登陆密码是否是可见、可复制

5.         是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）

6.         用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统

系统网络安全的测试要考虑问题

1.         测试采取的防护措施是否正确装配好，有关系统的补丁是否打上

2.         模拟非授权攻击，看防护系统是否坚固

3.         采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ）

4.         采用各种木马检查工具检查系统木马情况

5.         采用各种防外挂工具检查系统各组程序的客外挂漏洞

数据库安全考虑问题：

1.         系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）

2.         系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）

3.         系统数据可管理性

4.         系统数据的独立性

5.         系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

 

安全性测试是一项迫切需要进行的测试，测试人员需要像黑客一样攻击软件系统，找到软件系统包含的安全漏洞。
    1．网页安全漏洞检测
    一些设计不当的网站系统可能包含很多可以被利用的安全漏洞，这些安全漏洞如同给远程攻击者开了一个后门，让攻击者可以方便地进行某些恶意的攻击。例如，公共漏洞和披露网站CVE（Common Vulnerabilities and Exposures）公布了Element InstantShop中的Web网页add_2_basket.asp的一个漏洞项，允许远程攻击者通过隐藏的表单变量“price”来修改价格信息。这个表单的形式如下所示：

<INPUT TYPE = HIDDEN NAME = "id" VALUE = "AUTO0034">
<INPUT TYPE = HIDDEN NAME = "product" VALUE = "BMW545">
<INPUT TYPE = HIDDEN NAME = "name" VALUE = "Expensive Car">
<INPUT TYPE = HIDDEN NAME = "price" VALUE = "100">

    利用这个漏洞，不怀好意者可以任意设定price字段的值，然后提交给InstantShop网站的后台服务器，从而可能用100美元就可以获得一部BMW545。
    技巧：发现类似的安全漏洞的最好方法是进行代码审查。除了代码审查，测试人员还可以利用一些测试工具进行检查，例如：Paessler Site Inspector、Web Developer等。

    2．SQL注入
    SQL注入是另外一个经常忽略的安全漏洞，但是SQL注入同时也是一种非常普遍的代码漏洞，它会导致数据库端的敏感数据泄漏，或者服务器受到黑客的控制。例如，下面的一段代码就存在SQL语句的注入漏洞。

SqlConnection sqlcon = sqlconnA;

//打开连接
sqlcon.Open();

//组合一条查询语句
SqlCommand cmd = "select count(*) from User where LogonName = ‘" + this.textBox1.Text +”’ and Password = ‘”+this.textBox2.Text;

SqlDataAdapter adpt = new SqlDataAdapter(cmd, sqlcon);

DataSet ds = new DataSet();
adpt.Fill(ds);
//关闭连接
sqlcon.Close();

//如果返回数据不为空，则验证通过
If(ds.Tables[0].Rows.Count>0)
{
   retuen true;
}
else
{
   Return false;
}

    这段代码从textBox1获得用户输入的用户名，从textBox2获得用户输入的密码，然后执行数据库查询操作。假设在textBox1的输入框输入一个已知的用户名，然后再做一些手脚，则可以不输入密码也能登录系统。这个字符串利用了SQL Server对单引号的处理方式，只要简单地组合成类似下面的字符串并输入到textBox1的输入框中即可。

Admin' or '1' = '1

    这样就可以利用已知的Admin账号，不输入密码就能登录系统。因为给预期的SQL语句注入了额外的语句，所以实际上提交到SQL Server数据库执行的语句变成了如下所示的语句：

select count(*) from user where LogonName = 'Admin' or '1'='1' and Password=''

    由于1=1是恒等的，因此返回的结果肯定为真，从而干扰了用户信息的正常验证，导致能绕过密码验证而登录系统。
    技巧：检查是否存在SQL语句注入漏洞的最好办法是代码审查，查看所有涉及SQL语句提交的地方，是否正确处理了用户输入的字符串。

    3．缓冲区溢出
    不仅仅是连上Internet的软件系统才会有安全问题，个人软件系统或公司内部的软件系统也存在安全问题，这些安全问题不会导致信用卡密码的泄漏，但是可能导致工作成果的丢失。如果软件系统是采用C语言这类容易产生缓冲区溢出漏洞的语言开发的话，作为测试人员就要注意检查可能造成系统崩溃的安全问题了。
    例如，下面的两行C语言代码就可能造成缓冲区的溢出问题：

char buf[20];
gets(buf);

        如果使用gets函数来从stdin读入数据，则可能出现缓冲区溢出的问题。另外一个例子如下：

char buf[20];
char prefix[] = "http://";
strcpy(buf,prefix);
strncat(buf,path,sizeof(buf));

    这里问题出现在sizeof的参数不应该是整个buf的大小，而是buf的剩余空间大小。
    技巧：测试人员需要对每一个用户可能输入的地方尝试不同长度的数据输入，以验证程序在各种情况下正确地处理了用户的输入数据，而不会导致异常或溢出问题。或者通过代码审查来发现这些问题。还可以利用一些工具来帮助检查这类问题，例如AppVerifier等。

穿过幽暗地岁月
也曾感到彷徨
当你低头地瞬间
才发觉脚下的路

心中那自由地世界
如此的清澈高远
盛开着永不凋零
蓝莲花

   2008，我也穿行在幽暗的岁月中，对自己的未来感到迷茫，不知道自己的前途在何方；

2009年，我低头，低头不仅是要看看自己脚下的路，还是做人的低头，低调行事；

为了心中那永不凋零的蓝莲花

1. 错误的输入验证

2. 不正确的编码或转义输出

3. 维持SQL查询结构(SQL注入)错误

4. 维持网页结构(跨站点脚本)错误

5. 维持操作系统命令结果(操作系统命令注入)错误

6. 明文传送敏感信息

7. 跨站点请求伪造

8. 资源竞争(Race condition)

9. 错误信息泄露

10. 限定缓冲区内操作失败

11. 外部控制重要状态数据

12. 外部控制文件名或路径

14. 不可信搜索路径

15. 控制代码生成错误(代码注入)

15. 下载未经完整性检查的代码

16. 错误的资源关闭或发布

17. 不正确的初始化

18. 错误计算

19. 可渗透防护

20. 使用被破解的加密算法

21. 硬编码密码

22. 对核心资源的错误权限分配

23. 随机值的错误利用

24. 滥用特权操作

25. 客户端执行服务器端安全

一、人生是一种无法抗拒的前进

二、据说每个人一生中都能遇到两万个与自己相配的人，我的那两万人又在哪里？

三、命运是存在的，只不过有的人不敢去相信，有的人不屑去相信罢了

四、压力都是自己给的

 

我就像一只黑玻璃下的苍蝇，前途不光明，出路也没有

    由总后卫生部组织、军区总医院牵头制定的《网络成瘾临床诊断标准》近日通过专家论证，意味着我国医学界诊断“网瘾”将实行标准化，“网瘾”也首次被该标准列为精神疾病治疗范围。根据《网络成瘾临床诊断标准》，网络成瘾是指个体反复过度使用网络导致的一种精神行为障碍。症状界定有七项标准，其中一项量化的指标是平均每天连续使用网络达到或超过6小时，而且这种症状达到或者超过3个月。

　　网络成瘾，究竟如何界定？它是否是一种精神疾病？昨天，标准的主要制定者、北京军区总医院医学成瘾科主任陶然接受记者专访，对网络成瘾的概念、如何界定和预防治疗做出了解答。

　　《网络成瘾临床诊断标准》的最伟大成就是确定了网络成瘾的“6小时”标准。陶然介绍说，6小时是一个关键点。就是一个人使用网络的目的不是为了学习和工作或者不利于自己的学习和工作，平均每天连续使用网络时间达到或者超过6 小时，且此症状已经达到或超过3个月，即可诊断为网络成瘾。

　　“6小时”是不可逾越的节点，就像非典时期人们说的“38度”，是判断病情的一个最重要最明显的标志。此前，各国对网瘾患者持续上网的时间没有统一的说法，认为是4个小时或5个小时的居多。陶然说，“我们用了4年的时间，对 3000名网瘾患者进行调查研究，确定时间标准为9.3±3.2小时，最终取其下线及其整数，定为6小时。”陶然说，这个时间恰巧和美国专家同天公布的研究数字不谋而合。” 任何人都可以按这个标准进行自测，接近6小时则是高危人群。但如果为了工作每天在网上逗留10个小时，不能算是网络成瘾。陶然举例说，暑假里一些孩子连续上了两个月的网，但是开学之后他能够把心收回来、走了出来，这也不能算是网络成瘾。有些孩子暑假结束后仍然走不出来，整个状态一直持续超过3个月，就有可能是网络成瘾。

  测了两年的项目，终于等到了所谓的项目奖金；

  提了几千个bug，一个bug才划几角钱，很郁闷！

 

Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
Physical Disk\\ % Disk Time
Physical Disk\\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\\ Avg.Disk sec/Transfer 和 Memory\\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 Memory\\ Available Bytes 和 Memory\\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\\Private Bytes、Process\\Working Set 和Process\\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs 和 Process(process_name)\\ Pool Nonpaged Bytes。
Pages per second :每秒钟检索的页数。该数字应少于每秒一页。
Process：
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinforivate Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"hysical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
% DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Network Interface：
Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
SQLServer性能计数器：
Access Methods(访问方法) 用于监视访问数据库中的逻辑页的方法。
Full Scans/sec(全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及S Q L查询是否可以被优化。
Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
Buffer Manager(缓冲器管理器)：监视 Microsoft® SQL Server? 如何使用：内存存储数据页、内部数据结构和过程高速缓存；计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。监视 SQL Server 所使用的内存和计数器有助于确定：是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
SQL Server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。
.Page Reads/sec：每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
.Page Writes/sec (.写的页/秒) 每秒执行的物理数据库写的页数。
.Buffer Cache Hit Ratio. 在“缓冲池”（Buffer Cache/Buffer Pool）中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90% 或更高。增加内存直到这一数值持续高于90%，表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
Cache Manager(高速缓存管理器) 对象提供计数器，用于监视 Microsoft® SQL Server? 如何使用内存存储对象，如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。
Cache Hit Ratio(高速缓存命中率，所有Cache”的命中率。在SQL Server中，Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效，这是一个非常好的计数器。如果这个值很低，持续低于80%，就需要增加更多的内存。
Latches(闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒)) 一个SQL Server线程必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题。
Latch Waits/sec (闩等待/秒) 在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。
Locks(锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它 (X) 锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视 Locks 对象的多个实例，每个实例代表一个资源类型上的一个锁。
Number of Deadlocks/sec(死锁的数量/秒) 导致死锁的锁请求的数量
Average Wait Time(ms) (平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
Lock Requests/sec(锁请求/秒) 每秒钟某种类型的锁请求的数量。
Memory manager:用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定：是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
Lock blocks:服务器上锁定块的数量，锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
Total server memory：sql server服务器当前正在使用的动态内存总量.
监视IIS需要的一些计数器
Internet Information Services Global:
File Cache Hits %、File CacheFlushes、File Cache Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例，反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）
Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）

我们可以使用fopen()、fscanf()、fprintf()、fclose()函数进行文件操作，但是因为LoadRunner不支持FILE数据类型，所以我们需要做以下修改：
1、文件的声明
    先定义一个int类型的文件指针：
     int MyFile;
2、文件的打开
     fopen(FILE * stream ,const char *format,....):返回一个FILE数据类型的指针。
     因为LoadRunner不支持FILE数据类型,所以我们要将返回值转化成int型。其中，第一个参数指定文件路径；第二个参数指定创建文件的模式。

      int MyFile;
      MyFile=(int)fopen("D:\\lr_log\\01.txt","r");

3、读文件
        fscanf(FILE * stream ,const char *format,....)
       自参数stream的文件流中读取字符串，再根据参数format字符串来转换并格式化数据：
实例一   读取数值型数据
        int MyFile;
        int number;
        MyFile = fopen("D:\\lr_log\\01.txt","r");
        fscanf(MyFile,"%d", &number);
实例二  读取字符串
Action()
{
  int MyFile;
  char *ch[10];
  MyFile = (int)fopen("D:\\temp\\data2.txt","r+");
  fscanf(MyFile,"%s", ch);
  lr_output_message("%s",ch);
    return 0;
}
4、写文件
        fprintf(FILE *stream,const char * format,va_list ap)
       根据参数format字符串来转换并格式化数据，然后将结果输出到参数stream指定的文件中，直到出现字符串结束(’\0’)为止。
            
Action()
{
int myfile;
char ch[] ="Hello World! My English name is Cheers_Lee";
myfile=(int)fopen("D:\\temp\\data2.txt","w");
fprintf(myfile,"%s",ch);
    return 0;
}
5、关闭文件
        fclose(FILE * stream)

下面贴一个简单的实例，从一个文件读取数据写入另一个文件中
Action()
{
        int MyFile1,MyFile2;
        int i;
        char data[80];       //defining a parameter，using for storing datas
        // Assigning the file path to a string
        char *addr="D:\\lr_log\\01.txt";
        char *addr1="D:\\lr_log\\user.txt";
 
        //if fail to open the file,print error message
        if((MyFile1 = fopen(addr,"r"))==NULL||(MyFile2=fopen(addr1,"w+"))==NULL)
          {
                lr_error_message("Can't open this file",addr);
                return -1;
                  }
        if((MyFile2= fopen(addr1,"w+"))==NULL)
          {
                lr_error_message("Can't open this file",addr1);
                return -1;
                  }

        for(i=1;i<=6;i++)
               {
               fscanf(MyFile1,"%s",data);    //reading the datas from MyFile to the string(data)
               lr_output_message("Line%d: %s",i,data);
               fprintf(MyFile2,"第%d个用户：%s\n",i,data);  //writing datas to the file(filename)
               }
 
        fclose(MyFile1);
        fclose(MyFile2);          
 
        return 0;
}

服务器资源监控指标：

内存：

1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数可高;

可高的全局系统CPU利用率;  

内存不够出错(out of memory errors)

处理器：

1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%  

合理使用的范围在60%至70%。

2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆:  

很慢的响应时间(slow response time)  

CPU空闲时间为零(zero percent idle CPU)  

过高的用户占用CPU时间(high percent user CPU)  

过高的系统占用CPU时间(high percent system CPU)  

长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：

1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization)  

太长的磁盘等待队列(large disk queue length)  

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)  

太高的物理I/O速率:large physical I/O rate(not sufficient in itself)  

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))  

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：

1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。  

3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率：  

select(sum(pins-reloads))/sum(pins) from v$librarycache;  

select(sum(gets-getmisses))/sum(gets) from v$rowcache;  

自由内存： select * from v$sgastat where name=’free memory’;  

2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：

select name,value from v$sysstat where name in (’db block gets’,

‘consistent gets’,'physical reads’) ;

Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = ‘redo log space requests’ ;

4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

 

    昨天LP打电话回家，娘说，小皮现在会拿着电话装模装样的打电话了。

    想一想他拿着电话说“喂”时那可爱的样子，心中充满了喜悦......

    周六回家，想儿子了！