浏览量：网站所有页面被点击的总次数。一个IP点击N次，按N次统计。

• 从技术层面讲，指浏览器加载网页的次数总和。

访问量：从来到网站到离开，算一次统计。你访问一个网站，离开后，再次重新访问，访问量按2次算。

• 关掉浏览器，或直接关掉网站，算离开网站。（一次访问结束）
• 如果一直没有关掉网站，访问网站的不同页面，算一次访问。
• 一天内不同时间访问网站N次，算N次访问。

PV：Page View 指的是以上的浏览量。很多时候，大家说的PV也指浏览量/访问量。比如本站：PV=8.7，说明平均每次访问，用户点击阅读了8.7页。

绝对唯一访问者：（英文UV，Unique Visitor）如果你统计的是一天，那么一天内同一台只算一次。统计访问你网站的人数，而不是访问次数。

• 从技术层面上讲，用Cookie 来确定绝对唯一访问者，而不是IP。
• 办公室内N台电脑访问，虽然同一个IP，统计时，按N次算。
• 同一个电脑访问，即使IP换了，但电脑没换，按一次算。

以上统计，时间可以选择。

比如，我统计近30天内，本站的绝对唯一访问者，不管某用户在这30天内访问了多少次，主要它用同一个电脑（保存着 Cookie），就只算一次。

有的时候Tomcat跑Web应用会慢慢死掉，CPU 100%占用。一般情况下是程序哪里出了问题，慢慢的DEBUG，几乎翻遍所有的代码，是不是很累？这里介绍一下JProfiler，比较优秀的性能监控和分析工具。
JProfiler我用的是4.3.3版本，他是收费的，不过google上面很多注册码可供使用。
安装的时候会提示一些比如寻找JVM等过程，这里就不多说了。安装完JProfiler，运行，出现如下界面：

由于我们是要创建对本地tomcat的监控，选择an application server,locally or remotely.
在接下来的窗口中，选择tomcat及版本，

下一步，选择本地：

下一步，选择启动批处理文件

下一步，选择JVM类型：

接着选择JProfiler的监听端口：

接着，选择直接启动：

下面会有一个很重要的提示，可能很多人在这里都没有注意而总是配置不好JProfiler：

第一，需要把
-agentlib:jprofilerti=port=8849,nowait,id=103,config=C:\Documents and Settings\stefanie_wu\.jprofiler4\config.xml"
"-Xbootclasspath/a:D:\Program Files\jprofiler4\bin\agent.jar" -Xbootclasspath/a:D:\usr\agent.jar
两个参数加载启动项中，
第二，要把D:\Program Files\jprofiler4\bin\windows放在PATH中。

我是使用.bat来启动tomcat的，所以在startup.bat中加入一段代码：
set JAVA_OPTS=%JAVA_OPTS% -agentlib:jprofilerti=port=8849,nowait,id=103,config=C:\Documents and Settings\stefanie_wu\.jprofiler4\config.xml -Xbootclasspath/a:D:\Program Files\jprofiler4\bin\agent.jar" -Xbootclasspath/a:D:\usr\agent.jar
但是这样启动会有问题，因为其中路径包含了空格，
所以拷贝comfig.xml和agent.jar到一个新的路径下面，比如：
set JAVA_OPTS=%JAVA_OPTS% -agentlib:jprofilerti=port=8849,nowait,id=102,config=D:\usr\config.xml -Xbootclasspath/a:D:\usr\agent.jar

这里的jprofilerti=port=8849就是刚才设置的jprofiler监控端口。
设置完这些，通过startup.bat启动tomcat，然后

点OK

WEB安全测试所需的基础知识

来自：http://bbs.51testing.com/thread-121779-1-1.html

第一章：BS架构体系安全渗透测试基础
1. HTTP协议基本概念
（1）介绍HTTP标示URL
（2）HTTP响应状态码
（3）HTTP协议传输内容
2. WEB应用认证基本概念
（1）HTTP常见认证机制
（2）BASE64编码介绍
3. BS架构常见安全问题
（1）拒绝服务攻击基础
（2）Smurf攻击模型
（3）Fraggle攻击模型
（4）SynFlooding攻击模型
（5）碎片攻击
4. 嗅探理论基础
（1）网络嗅探原理
（2）密码嗅探介绍
（3）协议分析基础介绍
第二章：BS架构体系安全渗透测试攻击基础
1. BS架构结构端口扫描分析
（1）SuperScan工具
（2）Nmap端口扫描工具

2. 输入验证攻击基础知识
（1）输入验证攻击基本概念
（2）Unicode漏洞介绍
（3）输入验证二次解码漏洞介绍
3. ASP脚本注入基础知识
（1）ASP脚本注入基本概念
（2）ASP脚本注入检测
（3）ASP脚本注入信息获取
（4）AASP脚本注入提权
4. PHP脚本注入基础知识
（1）PHP脚本注入基本概念
（2）PHP脚本注入检测
（3）PHP脚本注入信息获取
（4）PHP脚本注入提权
5.跨站脚本原理及防御
（1）跨站脚本基本概念
（2）跨站脚本实例
（3）跨站脚本解决方法
6、 Web权限提升分析
（1）Web权限提升基本概念
（2）WeBShell上传方法
（3）Web权限提升7大方法：密码破解、本地提权、Gina木马…
7.APR嗅探基础
（1）APR协议概念
（2）APR欺骗攻击
（3） 交换域网络嗅探
第三章：BS架构体系安全渗透测试攻击与测试工具
1、 攻击工具介绍
（1）注入攻击工具原理
（2）注入攻击工具分析
（3）攻击测试平台搭建
2.注入攻击工具使用练习（ASP+SQL Server注入攻击实战）
（1）注入攻击工具使用
（2）域名检查攻击工具使用及域名信息查询用
3.拒绝服务攻击工具使用练习
（1）SynFlooding攻击工具测试
（2）UDPflood攻击工具测试
（3）畸形DDOS攻击工具
4.嗅探攻击工具使用练习
（1）ARP欺骗攻击工具 密码嗅探练习
（2）嗅探协议分析练习
5. BS安全评估工具使用练习
（1）Web脚本评估工具安装
（2）BS架构扫描
（3）评估报告分析撰写模版

　1. 数据验证流程：一个好的web系统应该在IE端，server端，DB端都应该进行验证。但有不少程序偷工减料，script验证完了，就不管了；app server对数据长度和类型的验证与db server的不一样，这些都会引发问题。有兴趣的可参看一下script代码，设计一些case，这可是你作为一个高级测试人员的优秀之处哦。我曾修改了页面端的script代码，然后提交了一个form，引发了一个系统的重大漏洞后门

　　2. 数据验证类型： 如果web server端提交sql语句时，不对提交的sql语句验证，那么一个黑客就可暗喜了。他可将提交的sql语句分割，后面加一个delete all或drop database的之类语句，能将你的数据库内容删个精光！我这一招还没实验在internet网站上，不知这样的网站有没有，有多少个。反正我负责的那个web系统曾经发现这样的问题。

　　3. 网络加密，数据库加密不用说了吧。

　　WEB软件最常碰到的BUG为：

　　1、SQL INJETION

　　2、对文件操作相关的模块的漏洞

　　3、COOKIES的欺骗

　　4、本地提交的漏洞

　　●SQL INJETION的测试方法

　　原理：

　　如有一新闻管理系统用文件news.asp再用参数读取数据库里的新闻譬如

　　http://www.xxx.com/news.asp?id=1这一类网站程序

　　如果直接用

　　rs.open "select * from news where id=" &

　　cstr(request("id")),conn,1,1

　　数据库进行查询的话即上面的URL所读取的文章是这样读取的

　　select * from news where id=1

　　懂得SQL语言的就知道这条语言的意思是在news读取id为1的文章内容。

　　但是在SQL SERVER里select是支持子查询和多句执行的。如果这样提交URL的话

　　http://www.xxx.com/news.asp?id=1and 1=(select count(*) from admin

　　where left(name,1)=a)

　　SQL语句就变成了

　　select * news where id=1 and 1=(select count(*)

　　from admin where left(name,1)=a)

　　意思是admin表里如果存在字段字为name里左边第一个字符是a的就查询news表里id为1的内容，news表里id为1是有内容的，从逻辑上的角度来说就是1&P。只要P为真，表达式就为真，页面会返回一个正确的页面。如果为假页面就会报错或者会提示该id的文章不存在。黑客利用这点就可以慢慢得试用后台管理员的用户和密码。

测试：

　　测试存不存在SQL INJETION很简单如果参数为整数型的就在URL上分别提交http://www.xxx.com/news.asp?id=1and 1=1　和http://www.xxx.com/news.asp?id=1and 1=2

　　如果第一次返回正确内容，第二次返回不同页面或者不同容内的话表明news.asp文件存在SQL INJETION。如何利用就不多说了，毕竟我们都不是为了入侵。

　　● 对文件操作相关的模块的漏洞在测试

　　原理：

　　如一上传文件功能的程序upload.asp如果程序员只注重其功能上的需求没有考虑到用户不按常规操作的问题。如上传一个网页木马程序上去，整个网站甚至整个服务器的架构和源码都暴露而且还有一定的权限。

　　测试：

　　试上传asp,php,jsp,cgi等网页的文件看是否成功。

　　补充：

　　还有像　http://www.xxx.com/download/filespath.asp?path=../abc.zip

　　下载功能的软件如果

　　http://www.xxx.com/download/filespath.asp?path=../conn.asp

　　很可能下载到这些asp的源码数据库位置及用户密码都可能暴露。

　　其它还有很多，就不一一举例了。

　　● COOKIES的欺骗

　　原理：

　　COOKIES是WEB程序的重要部分，COOKIES有利有弊。利在于不太占用服务器的资源，弊在于放在客户端非常容易被人修改加以利用。所以一般论坛前台登陆用COOKIES后台是用SESSION，因为前台登陆比较频繁，用SESSION效率很低。但如论坛程序管理员用户在前台也有一定的权限，如果对COOKIES验证不严的话，严重影响了WEB程序的正常工作。如前期的LEADBBS，只有后台对COOKIES验证严格，前台的位置只是从COOKIES读取用户的ID，对用户是否合法根本没有验证。

　　测试：

　　推荐使用MYBROWER浏览器，可即时显示及修改COOKIES。尝试一下修改里面的对应位置。

　　● 本地提交表单的漏洞

　　原理：

　　Action只接爱表单的提交，所以表单是客户WEB程序的接口。先举一个例子，一个投票系统，分A，B，C，D各项的VALUE是100,80,60,40。

　　但是如果先把些页面以HTML形式保存在本地硬盘里。然后修改其VALUE，再向其ACTION提交，ACTION会不会接受呢？

　　测试：

　　如一投票系统，把投票的页面保存在本地硬盘，用记事本打开，找到对应项的VALUE值，对其修改，然后提交。

　　强制后台浏览：绕过登陆页面，直接提交系统文件夹或文件页面。不完善的系统如果缺少index.html就可能被绕过登陆验证页面。在系统文件夹中保留一些公司机密内容也会造成不可估计的损失。

　　跨站脚本攻击：基本上这个我只是在论坛——各种形式的论坛里看到过，具体的一个例子，比如这段代码可以被填在任何输入框里 “<script>alert("attacking!");</script>”，如果未对一些字符，如 “<”、">"进行转换，就会自动执行这个脚本。百度快照所提供的网页都自动将代码执行了。不信大家搜一点JS的代码，看看你能不能看到。

　　堆栈溢出攻击：完全的不了解，只是在某个网站上看到，可以对现在的2000、XP、2003进行攻击，非常恐怖，MS应该打了补丁了吧？

一、等价类法

1.定义

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

 

2.划分等价类

等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

1)有效等价类

是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

2)无效等价类

与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

 

3.划分等价类的标准

1)完备测试、避免冗余;

2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;

3)并是整个集合：完备性;

4)子集互不相交：保证一种形式的无冗余性;

5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

 

4.划分等价类的方法

1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。

如：输入值是学生成绩，范围是0～100；

 

 

 

2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；

3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；

6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

5.设计测试用例

在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：
1)为每一个等价类规定一个唯一的编号；
2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步， 直到所有的有效等价类都被覆盖为止；
3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

 

二、边界值法

 

1.定义

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。 

2.与等价划分的区别

1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

 

3.边界值分析方法的考虑

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

 

4.常见的边界值

1)对16-bit 的整数而言 32767 和 -32768 是边界

2)屏幕上光标在最左上、最右下位置

3)报表的第一行和最后一行

4)数组元素的第一个和最后一个

5)循环的第 0 次、第 1 次和倒数第 2 次、最后一次

 

5.边界值分析

1)边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

例：测试计算平方根的函数

--输入：实数

--输出：实数

--规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。

2)等价类划分：

I.可以考虑作出如下划分：

a、输入 (i)<0 和 (ii)>=0

b、输出 (a)>=0 和 (b) Error

II.测试用例有两个：

a、输入4，输出2。对应于 (ii) 和 (a) 。

b、输入-10，输出0和错误提示。对应于 (i) 和 (b) 。

3)边界值分析：

划分(ii)的边界为0和最大正实数；划分(i)的边界为最小负实数和0。由此得到以下测试用例：

a、输入 {最小负实数}

b、输入 {绝对值很小的负数}

c、输入 0

d、输入 {绝对值很小的正数}

e、输入 {最大正实数}

4)通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

5)相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、 空/满等情况下。

6)利用边界值作为测试数据 

7)内部边界值分析：
在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。
内部边界值条件主要有下面几种：
    a)数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。

 

b)字符的边界值检验：在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

 

c)其它边界值检验

 

6.基于边界值分析方法选择测试用例的原则

1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

例如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。

3)将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。

例如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。

再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑的测试用例包括1和4，还应包括0和5等。

4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

5)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

6)分析规格说明,找出其它可能的边界条件。

三、因果图法

1.定义

是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

2.因果图法产生的背景

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

3.因果图介绍

1) 4种符号分别表示了规格说明中向4种因果关系。

 

 

2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。

3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

 

4.因果图概念

1) 关系

①恒等：若ci是1，则ei也是1；否则

查看(762) 评论(0) 收藏 分享 管理

一，Session：含义：有始有终的一系列动作\消息 1， 隐含了“面向连接”和“保持状态”两种含义 2， 一种用来在客户端与服务器之间保持状态的解决方案 3， 也指这种解决方案的存储结构“把××保存在session里” 二，http协议本来是无状态的，所以引进了cookie和session机制来保持连接状态 cookie与session机制之间的区别与联系： cookie机制采用的是在客户端保持状态的方法 session机制采用的是在服务器端保持状态的方案，由于在服务器端保  持状态的同时必须要求客户端提供一个标识， 三，关于cookie机制 Cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的，浏览器会检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的http请求头上发送给服务器。 存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而保存在内存里的cookie，不同的浏览器有不同的处理方式，对于IE，在一个打开的窗口上按CTRL＋N（从文件菜单）打开的窗口可以与原窗口共享cookie，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie。 Cookie的内容包括：名字，值，过期时间，路径和域 四，关于session的机制    当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个请求是否含了一个session标识（session id），如果有，则说明以前为该客户创建了一个session，服务器就按照session id把这个session检索出来用，一般一个cookie的名字就是类似于session ID，如果cookie被禁止的时候（cookie可以被人为的禁止），经常使用重写URL的方式，把session ID附加在URL路径后面，为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。     人们以为：“把浏览器关闭了，session就小时了”其实不对，除非程序通知服务器删除一个session，否则服务器会一直保留，而程序一般都是在用户作log off的时候发个指令去删除session。人们之所以会产生这种错觉，是因为大部分session会采用cookie来保存session，而关闭浏览器后这个session就消失了，如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的http请求头，把原来的session id发送给服务器，则再次打开浏览器，其实是可以再次找到之前的session id的。所以设置失效时间可以起到一定的保护作用。 五，关于session的一些问题 1， session何时被创建：不是在客户端访问时就被创建，而是在服务器端调用httpservletRequest.getSession(true)时才被创建。 2， session何时被删除： A，程序调用httpSession.invalidate(),B距离上一次收到客户端发送的session id时间间隔超过了session的超时设置C， 服务器进程被停止（非持久session） 3， 如何做到关闭浏览器同时关闭session： 严格说做不到，可以让所有的客户端页面使用window.onclose来监视浏览器的关闭东西，然后向服务器发送一个请求来删除session，但是对于浏览器崩溃或者强行杀死进程时仍然无能为力。

1. 不登录系统，直接输入登录后的页面的url是否可以访问

　　2. 不登录系统，直接输入下载文件的url是否可以下载，如输入http://url/download?name=file是否可以下载文件file

　　3. 退出登录后按后退按钮能否访问之前的页面

　　4. ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数字混合，不能包含ID，连续的字母或数字不能超过n位

　　5. 重要信息（如密码，身份证号码，信用卡号等）在输入或查询时是否用明文显示；在浏览器地址栏里输入命令javascrīpt:alert(doucument.cookie)时是否有重要信息；在html源码中能否看到重要信息

　　6. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e，高级用户对应的url中的参数为l=s，以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面

　　7. url里不可修改的参数是否可以被修改

　　8. 上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行

　　9. 注册用户时是否可以以'--,' or 1=1 --等做为用户名

　　10. 传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（','and 1=1 --,' and 1=0 --,'or 1=0 --）时是否可以正常处理

　　11. 执行新增操作时，在所有的输入框中输入脚本标签（<scrīpt>alert("")</scrīpt>）后能否保存

　　12. 在url中输入下面的地址是否可以下载：http://url/download.jsp?file=C:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/passwd

　　13. 是否对session的有效期进行处理

　　14. 错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等

　　15. ID/密码验证方式中，同一个账号在不同的机器上不能同时登录

　　16. ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定

　　17. 新增或修改重要信息（密码、身份证号码、信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete=off来关闭自动完成功能

<Context path="/myjsp" docBase="c:\myjsp" debug="0" reloadable="true" crossContext="true"></Context>
其中，path为我们要建立的虚拟目录，docBase为实际目录在硬盘上的位置。

<Host>元素

目.默认值为200
7>acceptCount设定在监听端口队列的最大客户请求数量,默认值为10.如果队列已满,客户必须等待.
8>connectionTimeout定义建立客户连接超时的时间.如果为-1,表示不限制建立客户连接的时间
JkConnector的属性
1>className实现Connector的类
2>port设定AJP端口号
3>protocol必须设定为AJP/1.3

1、测试过程中往往容易忽略最简单的测试，比如：系统的单词拼写，界面的显示与兼容性，易用性测试等。测试人员认为将单词放在最后测试，会出现测试疲劳，导致忽略这部分的测试。（建议：测试人员在针对一个需求进行验证的时候，应该明白存在哪几个方面的测试，比如：功能测试，业务需求测试，兼容性测试，安全性测试，界面测试，易用性测试等，将这几种融入到自己的意识里，每次测试过程中检查是否覆盖或遗漏了上述测试）

2、测试用例里没有区分用例的重要级别，输入数据及预置条件不是很准确。（建议：在写测试用例的时候，要注意分清楚测试用例的重要等级（H、M、L），在后期的测试执行中可以根据重要等级来划分执行的先后顺序，在时间不充足的情况下，可以安排只执行High与Medium级别的用例。说明：跟业务流程或 需求紧密相关的测试用例可以定义为High，一般的功能点及异常检查或数据内容显示的测试用例可定义为Medium，对于界面性显示的测试用例可定义为 Low。同样预置条件与输入数据对于在测试执行的时候起了很大的帮助作用，测试人员应该根据实际需要准确的定义预置条件与输入数据。
3、测试人员编写测试用例不能把握编写的粒度，到底写到哪个程度用例应该算恰到好处的。（建议：测试人员首先应根据项目组的要求，允许投入的时间及不同类型的业务系统去着手编写测试用例，其次测试人员每针对一个需求点编写测试用例的时候，尽量从以下几种测试类型去考虑测试点的覆盖：用户界面、数据的初始化、数据的同步性、数据的一致性、数据的有效性、出错处理测试、关键功能点、权限检查、业务数据流、业务状态转换、系统间接口集成、可用性、安全性、性能。因为测试用例的粗细同样决定着后续的测试执行工作以及测试用例维护工作的投入时间，不能因为测试用例而导致整个测试工作的后延。）

4、测试人员编写的测试用例没有注意到每种测试用例类型的排列先后顺序，以及测试用例执行的连贯性，同时没有与实际的测试执行结合起来。（建 议：一个需求所扩展出来的测试用例应尽量按照一定的顺序进行排列，如：界面显示检查 -> 数据内容检查 -> 功能点的出错处理检查 -> 功能点的正常处理检查 -> 业务流程的检查 -> 权限检查，这样可以让用例看起来条理清晰，可读性较强。同时测试用例更应该与测试执行时所做的操作相吻合，比如测试人员首先登录系统，进入某一个页面，先检查界面文本显示，然后查看数据内容是否正确，接着检查某个功能是否进行了出错处理，它是否达到了正常的可用性，最后提交数据，检查业务流程流转是否正确等。所以用例应该根据上面的这些检查操作来编写，通过一连串测试用例来实现这些操作.

5、一旦测试任务较多时，测试人员不能较好的把握测试的主次及优先顺序。不知道业务集中在哪些地方，哪些场景用户操作比较多。（建议：测试人员应该了解业务人员的基本操作习惯以及业务集中区域，对于业务人员经常操作的模板及业务，或者业务人员依赖性很强的功能点，测试人员应该重点对待，认真测试，比如：创建合同，邮件通知等。同时对于的不同的业务流程，测试人员应该与需求人员进行咨询，得出测试的优先级，比如：在某系统里，合同的业务单数最多，其次为开票，站点。） 6、测试过程中提交问题单的占用的时间过多，导致测试的时间不够。 （建议：测试人员在前期提单尽量标准化，规范化。随着测试的深入以及工作量的增加，测试人员可以通过标题准确来描述问题单，让开发人员通过标题就可以知道问题所在。其次测试人员对于比较容易重现的问题单或者容易理解的，可以尽量忽略问题描述，但还是需要提供截图。对于组合操作发现的问题单，描述里面需要写明重现步骤及测试数据与条件。）

7、问题单的严重级别定义不准确。在测试过程中，测试人员往往对于系统权限，流程错误等问题单给予提示或一般的严重级别，这样可能导致开发经理在分发问题的时候产生误导，或者导致项目质量分析报告中出现误差。（建议：测试人员应该根据缺陷给用户所带来的影响，以及与业务操作的关系等多方面去考虑，实事求是的给出准确的定义。bug严重级定义请参考缺陷填写规范V0.2.doc
8、测试人员的沟通积极性不足。测试人员在整个软件开发生命周期里需要跟各种不同的角色进行沟通，比如需求人员，开发人员，开发经理，项目经理，架构师，运维人员及编辑人员等，与各种不同角色的人员进行沟通可以更好的支撑测试人员顺利的完成测试工作。（建 议：测试人员在熟悉需求及编写用例的时候，应该主动与需求人员进行沟通，明确需求，解答需求疑惑。主动与开发人员进行沟通，咨询系统原型，获取开发人员的 开发思路，从而完善测试用例，更全面的覆盖测试执行；应主动向项目经理或开发经理，提出风险问题或者自己的建议，如测试的面太广，测试时间不够等问题。性能测试人员更应该向系统架构师咨询系统的设计与架构，为后面的性能测试打下结实的基础，尽早的发现测试过程中的难点与问题点）  

概念理解：

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具

a、可配合因果图后期使用；

b、适合于多逻辑条件下的组合分析 ；

 

掌握判定表的结构：

1)条件桩：列出了问题的所有条件

2)动作桩：列出了问题规定可能采取的操作

3)条件项：列出针对它左列条件的取值。如Y或N

4)动作项：列出在条件项的各种取值情况下应该采取的动作。如X表示

 

实践方法：

Step1：确定规则的个数（假如有n个条件。每个条件有两个取值（0,1）,故有2的 n次方 种规则）；

Step2：列出所有的条件桩和动作桩；

Step3：填入条件项（如Y或N）；

Step4：填入动作项（X）；

Step5：简化.合并相似规则（整列）

 

实践心得：

1、列出所有的条件桩和动作桩

2、前几步大家都很容易执行得出，但是关键在于最后的规则合并；

   合并原则一般为：1、以相同动作项出发；2、相同的条件项直接合并；3、相反的条件忽略（注意：此处为一般情况，需结合业务再次明确其必要性，否则不予合并）

 

示例：

昨天本来计划是学LR呢，今天因为要对网站安全性进行测试，所以，学习了一些sql注入的知识。

 

  庆贺一下，在网上看一些sql注入的东东，于是想到了对网站的输入框进行一些测试，本来是想在输入框中输入<script>alter("abc")<script>,但是输入框有字符限制，只好输入<script>,结果网站出大问题了，呵呵，终于又出现了个bug。高兴。。。。。。。

 

  另一个就是在URL最后随意输入一些字符或数字，结果，新闻模块那出现了问题，暴露了网站的一些信息，又一个bug，高兴下。。。。。。。

 

   下面把今天看到的有关sql注入方面的知识整理如下：

 

   SQL注入是一种攻击方式，在这种攻击方式中，恶意代码被插入到字符串中，然后将该字符串传递到SQL Server的实例以进行分析和执行。任何构成SQL语句的过程都应进行注入漏洞检查，因为SQL Server将执行其接收到的所有语法有效的查询。一个有经验的、坚定的攻击者甚至可以操作参数化数据。

 

   SQL注入的主要形式包括直接将代码插入到与SQL命令串联在一起并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态SQL命令中时，将执行该恶意代码。

   注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串，因此攻击者将用注释标记“--”来终止注入的字符串。执行时，此后的文本将被忽略。

 

   以下脚本显示了一个简单的SQL注入。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个SQL查询：

 var Shipcity;

    ShipCity = Request.form. ("ShipCity");

    var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

 

用户将被提示输入一个市县名称。如果用户输入Redmond，则查询将由与下面内容相似的脚本组成： 

 

   SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

但是，假定用户输入以下内容：

 

    Redmond'; drop table OrdersTable--

 

此时，脚本将组成以下查询：

 

    SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

 

   分号(;)表示一个查询的结束和另一个查询的开始。双连字符(--)指示当前行余下的部分是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。SQL Server处理该语句时，SQL Server将首先选择OrdersTable中的所有记录（其中ShipCity为Redmond）。然后，SQL Server将删除OrdersTable。

 

     只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造SQL命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。

 

    验证所有输入

    

   始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：

 

   如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个10 MB的MPEG文件，应用程序会做出什么反应？

 

   如果在文本字段中嵌入了一个DROP TABLE语句，应用程序会做出什么反应？

   测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。

输入字符	在Transact-SQL中的含义
;	查询分隔符。
'	字符数据字符串分隔符。
--	注释分隔符。
/* ... */	注释分隔符。服务器不对/*和*/之间的注释进行处理。
xp_	用于目录扩展存储过程的名称的开头，如xp_cmdshell。

很久很久以前，搜索引擎还不象今天的百花齐放，人们对它的要求较低，只要它能把互连网上相关的网站搜出来，搜到的网站尽量多一点，无关的网站能少一 点就能满足。所以那时候，人们评测搜索引擎的方法是用几个关键词，测试对比它们的搜索速度、搜索数量和无关网站的多少。简单说就是全快准。而那时的搜索引 擎技术大家差别不大，所以这样的评测方法是可行的。

　　此后，独特的搜索引擎技术此起彼伏，层出不穷，到现在明显处于战国时代。但是，人们的评测方法却没多大变化，现在常见的评测还是简单的用几个关键词比较搜索速度、搜索结果数量和各自介绍的搜索准确性。

　　远的不说，就在2001年第一季度升级后的askjeeves，你既可以象打普通电话一样在任何地方用手中的任何电话拨通askjeeves的电话号码，也可以在线惦记页面上的标记进入在线语音状态，用你电脑上的话筒和音箱交流。 然后你随便口头向它提一个要求，它会把你的语音转换成文字，然后分析你的要求，到它的700万标准问题答案、200万多媒体和其他储备库以及internet上去寻找答案，找到后再转换成语音回答你。

　　想象一下，如果你问它：“最近美国大选悬而未决，美国人怎么想？”过了一会儿，电脑或电话回答你：“根据最新的调查，假如最后是布什当选，80%的美 国人会接受他为合法总统，假如最后是戈尔当选，79%的美国人会接受他为合法总统。”如果你问它：“上届世界杯决赛的球都是谁进的？“ 它在回答你姓名的同时还调出决赛进球的音视频片段让你欣赏（当然音视频片段的前提是你用的不是电话而是电脑）。

　　虽然，askjeeves认为它们的语音转换功能和搜索速度已经到了可以商业化的程度，但它还是会有很多不成熟之处的，如果拿几个关键词来测试它的搜 索速度和查准率、查全率，和众多的普通搜索引擎相比，该把它排在哪里呢？如果排在很后边，难道它就是很差劲的搜索引擎吗？

　　单是评测internet搜索引擎已是件很难的事，而很多评测结果是给普通网民看的，势必要把Yahoo，新浪等门户包括进去，对于它们而 言，internet搜索只是一部分，其它各种搜索功能怎么办？你要是不算，偏偏网民用得多；要是算吧，更是一团乱麻，何从比起？

来，我们先分析一下几个重要评测要素的能力缺陷：

一：查全率

　　既然是搜索引擎，首先比搜索范围是天经地义的事，如果这条不及格，后边的评测好象也不用参加了。由于收录网页的数量都是各搜索引擎自己宣布的，未可全信，而同一个关键词的搜索结果却是显而易见的，所以一般的评测都以这个为准。
　　但以这个为准还是有很多毛病，多数象样一点的搜索引擎我都可以找出一批关键词来证明它的搜索结果是最全的。因为网页索引数量虽然有大小，但robot 和spider程序不同，索引范围和索引标准也不尽相同，在最大的搜索引擎上搜不到的有可能在小得多的搜索引擎上搜到。

　　有的搜索引擎支持“的，about，了，of，啊，么”等虚词助词搜索，有的不支持，这又如何来比？哪次评测提到过？
关键词除了内容难选择，在长短上也不好定。有的搜索引擎完全不支持单个汉字搜索，怎么算它？一般都只比较单关键词搜索，而多关键词的搜索呢？长句的搜索 呢？甚至有搜索引擎能支持任意文章或片段作为关键词，这样比较出来的结果跟单关键词搜索出来的可是不一样的，更别提没法比的功能了。象excite这样语 义搜索的引擎，还有支持模糊搜索的引擎，别的搜索引擎搜索结果极少甚至为零的关键词它们可以搜出一大堆结果，这又如何比较？

　　最后一点，搜索引擎是可以针对特定的关键词进行结果优化的，评测的公正性谁来保证？如果其中某个被评测搜索引擎事先知道所用的关键词，那么只要轻松优化一下，冠军就非它莫属了。

二：搜索速度

　　比完了查全率，就该比搜索速度了，如果有搜索引擎索引的网页虽多，但是搜索一次要五、六秒或更长，直接请它出局吧，没有比下去的意义了。

　　速度的问题首先还是在关键词，单关键词搜索快的不一定多关键词搜索快。
　　然后是访问量的问题，对一个日访问量一亿以上的搜索引擎和一个日访问量几万的搜索引擎作同样的测试本身已是不公平。
　　还有网页索引数量的问题，一个搜索引擎索引了10亿的网页，另一个搜索引擎索引了一千万的网页，让它们对同一个关键词在各自的数据库里搜索比搜索速度，这样的结果如何让人信服？

　　除了事先优化的问题外，有的搜索引擎本就具有记忆搜索结果加速调用的能力，一个关键词哪怕第一词搜索花了10秒，第二次搜索也许就2秒了，第三次，第 四次，到你去测试的时候已经永远是0.0001秒了。这样，如果你选常见词测试，它快得惊人，如果来个偏僻词，也许老半天出不来，到底该选什么关键词？常 用和偏僻各占多少？这真是一笔糊涂帐。

　　搜索引擎不是放在实验室的本地机上测试用的，而是给普通网友用的，所以这搜索时间应该还包括搜索界面和搜索结果的传输过程在内。一个搜索引擎搜索时间 花了0.0001秒，但是传输结果网页花了3秒，另一个搜索花了0.5秒，但是传输网页结果花了一秒，你说哪个搜索引擎算快？真正用的时候，你选那个 3.0001秒以后看到搜索结果的还是1.5秒以后看到搜索结果的？

三：查准率

　　这个相当重要，搜 到的东西即使又多又快，但你想要的那条结果不知道要翻多少页才能找到，那这搜索结果要来何用？这样的搜索引擎只有在查稀罕东西时才有用，但是要查稀罕东西 应该去元搜索引擎呀，干吗要用它？查准率的评价标准很难定，得看你查什么，你要查一个特定的网站和找一群相似网站根本就是两回事。查准率的关键还是在于要 搜什么和选择什么关键词，评测人可以随意定夺的，然后影响到评测结果的可靠性。

四：死链接

　　普通搜索引擎总有些 搜索结果是点不进去的，少到百分之一二，多到百分之八九，这个也常被用作评测条件之一。但是象google使用了网页快照功能，几乎不存在死链接问题，就 算搜索结果中的那个网站已关闭，你还是可以看到google自己储存的网页。这种死链接怎么计算？

五：用户负担

　　还没见过国内搜索引擎评测有谁用过这一项，但它是评价搜索引擎优劣的重要因素，包括很多方面。搜索引擎是给人用的，一定要让人用得舒服方便快捷，任何妨碍和延迟用户到达最终搜索结果的都算用户负担。

　　首先是搜索界面，一个只有搜索框的纯粹搜索引擎界面跟一个带有广告和大量网页内容的门户相比，它们带给用户的搜索负担是高下立判的。

　　其次是搜索结果描述，搜索结果网页的文字描述是长还是短，网页文字描述采用索引带关键词的部分还是索引网页的开始几行还是索引网页的主要内容，关键词是否高亮显示又采用什么颜色，是否显示网页地址，还有搜索结果页面的布局，这些对于用户的搜索负担区别大大的有。

　　再者就是对用户操作步骤的影响，是否可以用鼠标启动搜索，搜索结果每页显示数量是否只有10条，翻页的便捷与否，搜索框是两个还是一个，放在上边还是下边，一次搜索后关键词是否还在搜索框中显示，这些每一条都会影响搜索效率。

六：其它还有

是否支持本目录下搜索，
internet索引数据库更新时间长短，
搜索引擎的稳定性，
对高级搜索的支持能力强弱等也应该加以评测。

　　一个人想得不一定周到，可能还有其它重要评测要素没被我提及，网友若想到，望告知。看到这里，大家对目前常用搜索引擎评测方法的局限性一定有所了解了，当然最可笑的是，不知是无知还是猫腻还是选择标准比较特别，有的中文搜索引擎评测今年才做竟然没有包括google ，就好象排一长串小提琴名人却漏了帕格尼尼，呵呵。

评测搜索引擎实在是件很难的事。

搜索引擎，大家一定非常的熟悉，在工作生活中 经常遇到，比如你想知道怎么去你要去的地方，那么你先要搜索；你想知道周末有什么歌剧上演，那么你还是要搜索；你想知道这周全市商场打折情况，那么你依然 离不开搜索，…………生活在网络时代的你，几乎离不开搜索，那么搜索靠的是什么？当然就是搜索引擎，搜索引擎的重要性自然体现出来了。大家最熟悉的专业搜 索引擎有yahoo!、Google、百度…………然后搜索引擎并不止这些，一些大型的网站也有自己的搜索引擎，如淘宝。你想在淘宝上买东东，那么大多数人先是直接搜索想要买的东东的名字，然后在list中按照一定的条件进行筛选，然后就可以和卖家联系货比三家了。

　　上面说了这么多废话，我们现在言归正传，那就是搜索引擎我们怎么测试呢？

　　搜索引擎的测试也分为功能与性能测试，我在下面依次来分享：

　　首先，我们把整个测试计划分为线下测试与线上测试。线下与线上测试都要分功能测试与性能测试，先说现线下的测试。

　　一、线下功能测试分为两个部分，一部分为搜索引擎本身的功能测试，一部分为嵌套在前台应用中的功能测试：

　　1、搜索引擎本身的功能测试，主要就是按照用例，通过不同的搜索关键字、属性的组合（按照搜索引擎的规则）来直接访问搜索引擎，查看返回的数 据、参数是不是符合原先预计的结果。可以编写脚本来批量执行，判断每一个搜索的返回结果数与内容，相对应的参数是否一致。也可以手工执行，使用浏览器或者 命令行（如 curl）来做，用肉眼来观察结果。

　　2、嵌套前台应用的功能测试，只要就是按照用例通过前台的操作，来测试搜索引擎的相关的功能，测试搜索引擎与前台的接口是否正确应用，至于如何测试，这个地球人都知道了，我就不在这里多说了。

　　二、线下性能测试也分为两个部分，一部分为直接对搜索引擎进行加压的性能测试，另一部分为通过前台应用进行加压的性能测试：

　　1、直接对搜索引擎进行加压，可以测试出搜索引擎本身最真实的性能状况。可以把搜索引擎的有效负荷，最大承受的压力测试出来。具体的方法是，使 用工具如 loadrunner使用一个web_url直接加压，加压的内容其实就是你在功能测试中，直接测试搜索引擎时使用的那些搜索关键字、属性的组合（按照搜 索引擎的规则），具体的规则可以通过log来查看，也可以询问开发人员。需要注意的是，数据准备一定要海量，至少10万条以上的搜索数据（注意，就是你访 问搜索引擎的那些关键字组合，至于被搜索的数据，越大越好，最少多大，看你实际需要了）。当一切都准备完毕后，就可以启动工具来进行加压了。

　　2、通过前台应用进行加压，主要的压力都集中在前台应用上面，对于搜索引擎本身的压力并不会很大，但是这种测试也是必须的，因为你的搜索引擎是离不开前台应用的，这种测试可以模拟最真实的终端用户使用。所以不要怕麻烦，这个才是最后真正有意义的测试结果。

　　三、线上的功能测试，其实就是功能回归了，使用预发布环境（一套独立的缩小的线上的架构）来跑回归，手工或者自动化随便，这是不能缺少的。

　　四、线上的性能测试，这个也是使用预发布环境（记得一定要和线上一样哦，只不过是缩小的），分流线上的一部分压力到这里，观察线上与预发布环境 中的各服务器的情况，如果是第一次发布，线上没有流量，那么就自己来模拟，或者靠运营来宣传了（有点想网络游戏的公测）。记录下服务器的各性能指标，如 load，cpu，队列，最大并发连接数，log等等。

　　特别需要注意的是，不同层次服务器之间的数据传输方式，正确率以及配置，多试试不同的配置，寻找性能最优点。

5. 安全测试

    5.1 目录设置

测试目标： 每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。

  测试方法： 选中一幅图片，单击鼠标右键，是否找到该图片所在的路径。若找到，然后在浏览器地址栏中手工输入该路径，是否发现该站点的信息。

    5.2 SSL

测试方法： 站点使用 SSL 进行安全传送。进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS 。开发部门使用了 SSL ，测试人员需要确定是否有相应的替代页面 ( 适用于 3.0 以下版本的浏览器 ) ，这些浏览器不支持 SSL 。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

    5.3 登录

 

 

测试目标：

验证系统阻止非法的用户名 / 口令登录，而能够通过有效登录。用户登录是否有次数限制 ? 是否限制从某些 IP 地址登录 ? 如果允许登录失败的次数为 3 ，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗 ? 口令选择有规则限制吗 ?   是否可以不登陆而直接浏览某个页面？ 是否有超时的限制，用户登陆后在一定时间内（例如 15 分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

    5.4 日志文件

测试方法： 在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理 ? 是否记录失败的注册企图 ? 是否记录被盗信用卡的使用 ? 是否在每次事务完成的时候都进行保存 ? 记录 IP 地址吗 ? 记录用户名吗 ?

 

    5.5 脚本语言

6. 接口测试

    6.1 服务器接口

链接测试和表单测试都是此处的接口测试。

测试方法：测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

    6.2 外部接口

   测试方法： 要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。 ( 简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express ， 4 表示 Visa ， 5 表示 Mastercard ， 6 代表 Discover 。 ) 通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。  

    6.3 错误处理

测试目标 ： 尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。

七．测试工作计划

 

阶段	开始时间	结束时间	负责人	输出文档
理解项目需求	2009-5-5	2009-5-8	测试组 开发人员 / 项目经理	《测试需求》
编写测试计划	2009-5-5	2009-5-9	测试组长	《测试计划》
评审测试计划	2009-5-9	2009-5-11	测试组长 / 项目经理 /QA	《评审测试计划报告》
设计测试用例	2009-5-12	2009-5-26	测试组长 / 测试员	《测试用例》
评审测试用例	2009-5-26	2009-6-15	测试组长 / 项目经理 /QA	《评审报告》
集成测试	2009-6-16	2009-7-16	测试人员	《集成测试报告》
搭建测试环境	2009-7-16	2009-7-17	测试人员
性能测试	2009-7-17	2009-7-28	测试人员	《性能测试报告》
分析测试报告	2009-7-29	2009-8-4	测试组长 / 测试人员	《测试分析报告》
用户验收测试	2009-8-4	2009-8-10	项目经理 / 客户 /QA	《用户验收测试报告》

3. 用户界面测试

3.1 导航测试

（ 1）用户管理： 部门管理 | 用户管理 | 密码修改

（ 2） 资源管理： 号码管理 | 设备管理

（ 3） 呼叫设置： 拨号规则查询 | 计费号码设置 | Qos 设置

（ 4）增值服务： 服务模板管理 | 服务管理

（ 5）统一消息： Atendance | Voice Mail | 短消息 | 通知

（ 6）故障管理

（ 7）通讯录管理

（ 8）系统管理： 角色管理 | 操作员管理 | 日志查询 | 常见问题

（ 9）话单查询： CDR 查询

（ 10）区号查询： 国内长途号码 | 国际长途号码 | 特服号

测试方法： Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容，内容在什么地方。

3.2 图形测试

（ 1）首页－图片 /登陆按钮

（ 2）用户管理－图片

（ 3）用户管理－部门管理－ query/add/go!/bank按钮 /下拉框

   (4) 用户管理－用户管理－ query/add/go!/bank按钮 /下拉框

（ 5）用户管理－密码修改－ SAVE/CANCEL按钮

（ 6） 资源管理－号码管理－查询结果复选框

（ 7）资源管理－号码管理－ query/start/stop/go/update按钮

（ 8）资源管理－号码管理－设备 /状态 /原分机模式 /新分机模式下拉框

（ 9）资源管理－设备管理－类型 /showpage下拉框

（ 10）呼叫设置－拨号规则查询－集团拨号规则列表框 /设备 ,showpage下拉框 /查询结果数据表 / Query,Go 按钮

(11) 呼叫设置－计费号码设置－查询结果 数据表

(12) 呼叫设置－ QOS 设置 -查询结果 数据表

   (13) 增值服务－服务模板管理－模板名称 /服务名称 /Goto/查询结果数据表格

   (14) 增值服务－服务管理 -号码查询 /查询结果 /服务模板批量修改

   (15) 统一消息－ Atendance管理－设备 /状态 /page show

（ 16）系统管理－角色管理－修改权限 － Role Info 标签

    （ 17）区号查询－国内长途号码－数据表格

测试方法： （ 1 ）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
　　（ 2 ）验证所有页面字体的风格是否一致。
　　（ 3 ）背景颜色应该与字体颜色和前景颜色相搭配。
　　（ 4 ）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩，最好能使图片的大小减小到 30k 以下

（ 5 ）验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

3.3 内容测试

（ 1）用户管理－ Main Functions ， Support Services

（ 2 ）用户管理－部门管理－ Operation Tips

（ 3 ）资源管理－号码管理－ Operation Tips

（ 4 ）资源管理－号码管理－查询结果

（ 5 ）呼叫设置－ Operation Tips

（ 6 ） 增值服务 － Operation Tips

（ 7）统一消息 － Operation Tips

（ 8）故障管理 － Operation Tips

（ 9）通讯录管理 － Operation Tips

（ 10）系统管理 － Operation Tips

（ 11）话单查询 － Operation Tips

（ 12）区号查询 － Operation Tips

测试方法： 检验系统提供 Operation Tips 的正确性、准确性。

3.4 表格测试

（ 1）用户管理－ 用户管理

（ 2 ）用户管理－部门管理

（ 3 ） 资源管理－号码管理－查询结果

（ 4 ） 资源管理－设备管理－查询结果

（ 5 ）呼叫设置－ 拨号规则查询 －查询结果

（ 6） 呼叫设置－ 计费号码设置 －查询结果

（ 7 ） 呼叫设置－ Qos 设置 －查询结果

（ 8 ） 增值服务 － 服务模板管理 －查询结果

（ 9 ） 增值服务 － 服务管理 －查询结果

（ 10）统一消息 － Atendance | Voice Mail | 短消息 | 通知 － 查询结果

（ 11）故障管理 －故障查询

（ 12）通讯录管理 － 通讯录查询

（ 13）系统管理 － 角色管理 －查询角色列表

（ 14 ） 系统管理 － 操作员管理 －操作员列表

（ 15）话单查询 － 话单查询结果

（ 16）区号查询 － 国内长途号码 | 国际长途号码 表单

测试方法： 验证表格是否设置正确。每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长 ?

3.5 整体界面测试

测试方法：

对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

4. 兼容性测试

    4.1 平台测试

测试方法：分别在 Windows 、 Unix 、 Linux 上，使用 IE 浏览器登陆本系统，测试系统能否正常运行。

    4.2 浏览器测试

测试方法： 创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

    4.3 分辨率测试

测试方法： 将显示器的分辨率分别调整在 640x400 、 600x800 或 1024x768 的模式下，浏览系统的所有页面是否显示正常 ? 字体是否太小以至于无法浏览 ? 或者是太大 ? 文本和图片是否对齐 ?

    4.4 Modem/ 连接速率

    4.5 打印机

    4.6 组合测试

    测试方法： 将分辨率分别设置为 640x400 、 600x800 ， 1024x768 和浏览器 Netscape ， Fox 和 IE ，进行测试，测试 WEB 页面显示是否正常。

1.3数据校验

   （1）首页－登陆－登陆ID/密码/域

   （2）用户管理－部门管理－部门名称/部门地址

    (3)用户管理－用户管理－用户名称/部门名称/电话号码/分机号码

   （4）用户管理－密码修改－旧密码/新密码/确认新密码

    (5)资源管理－号码管理-设备/电话号码/状态/端口号/分机/原分机模式/新分机模式

    (6)资源管理－设备管理－设备ID/ IP地址/ MAC/类型/域名/设备地址

    (7)资源管理－设备管理－查询结果

   （8）呼叫设置－拨号规则查询－集团拨号规则/部门/设备/电话号码/姓名/端口号/分机

   （9）呼叫设置－计费号码设置－部门/电话号码/姓名/分机/Goto/新计费号码

（10）呼叫设置－计费号码设置－部门/电话号码/姓名/分机

（11）呼叫设置－QOS设置－部门/电话号码/姓名/分机

（12）增值服务－服务模板管理－模板名称/服务名称/Goto

(13)增值服务－服务管理－部门/电话号码/设备/姓名/分机/ GoTo

(14)统一消息－Atendance管理－部门/姓名/端口号/分机/电话号码/ GoTo

（15）统一消息－Voice Mail管理－呼叫号码/起始呼叫时间/结束呼叫时间/原密码/新密码/新密码确认

 (16)统一消息－短消息管理－发送号码/起始发送时间/结束呼叫时间/短信内容/发送号码/接收号码/ GoTo

(17)统一消息－通知－标题/起始发送时间/发送者/结束发送时间/通知内容/接收人/ GoTo

(18)故障管理－故障标题/提交人/起始日期/故障内容/终止日期/ GoTo

（19）通讯录管理－姓名/手机/单位名称/单位电话/ E-Mail/单位地址/邮政编码/ GoTo

（20）话单查询－部门名称/用户名称/ Calling Number/ Called Number/通话起始时间/通话结束时间/时长上限/时长下限

(21)系统管理－角色管理－Name/Remark/goto

（22）系统管理－操作员管理－Login ID/Password/ Confirm Password/ Operator Name/Phone/ Email/ Remark/ GoTo

(23)系统管理－日志查询－Operation Date (From)/ Operation Date (To)

测试目标：对用户输入进行校验，需要保证这些校验功能正常工作

测试方法：在表单中输入依据数据库设计中在数据类型，长度，格式不合理的非法的数据，

       检验系统是否有相应的错误提示信息。

1.4 cookies测试

测试方法：Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作；测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在cookies中保存了注册信息，请确认该cookie能够正常工作而且已对这些信息已经加密。如果使用cookie来统计次数，需要验证次数累计正确。

1.5数据库测试

测试目标：在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。

数据一致性错误主要是由于用户提交的表单信息不正确而造成的，

输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

测试方法：1.在表单中输入相应的合理的信息，点击提交，检验返回信息是否正确和完整；

     2.在表单中输入依据数据库设计中在数据类型，长度，格式不合理的非法的数据，

       检验系统是否有相应的错误提示信息。

   1.6应用程序特定的功能需求

2. 性能测试

2.1 连接速度测试

测试目标： 系统 TPS达到 40。
  测试方法： 1. 选择系统某个重要业务作为一个事务；

 2. 基准测试，记录处理完一个事务需要的时间 ; 测试三次记录每次花费时间，最后计算平均时间；

               3. 测试处理 5 个事务花费的时间；（目标： 125ms ）

           ……….

           测试处理 40 个事务花费的时间。

                   最后将测试结果和目标分解结果比较，检验是否达到要求。

2.2 负载测试

2.2.1 并发测试

测试目标： 20 个用户同时登录系统，测试能否全部成功登录。

测试方法： 1. 1 个用户登录系统，测试是否成功登录，若成功，则

          2.2 个用户同时登录系统，测试是否全部成功登录，若成功，则

          3.3 个用户同时登录系统，测试是否全部成功登录，若成功，则

          …

          20 个用户同时登录系统，测试是否全部成功登录。若有不成功登录的，则中止测试。

2.2.2 稳定性测试

测试目标： 登录本系统，持续业务（ 用户的新增－查询－修改－删除 ）处理 8小时，系统是否出现异常。

测试方法： 登录系统，依照 新增－查询－修改－删除流程，每隔 5 分钟对用户信息进行一个流程处理，持续运行 1 小时，若有异常，则中止；若运行正常，同样方法继续 2 小时， … 同样方法持续运行 8 小时，测试系统是否稳定。

2.3 压力测试

测试目标： 10000 个用户同时登录系统，测试能否全部成功登录。

测试方法： 1.1 个用户登录系统，测试是否成功登录，若成功，则

      2.500 个用户同时登录系统，测试是否全部成功登录，若成功，则

      3.1000 个用户同时登录系统，测试是否全部成功登录，若成功，则

      …

10000 个用户同时登录系统，测试是否全部成功登录。若有不成功登录的，则中止测试。

一．测试概述

二．测试背景

三．测试范围

1. 功能测试

    1.1 链接测试

    1.2 表单测试

    1.3 数据校验

    1.4 cookies 测试

    1.5 数据库测试

    1.6 应用程序特定的功能需求

    1.7 设计语言测试

2. 性能测试

    2.1 连接速度测试

    2.2 负载测试

    2.3 压力测试

3. 用户界面测试

    3.1 导航测试

    3.2 图形测试

    3.3 内容测试

    3.4 表格测试

    3.5 整体界面测试

4. 兼容性测试

    4.1 平台测试

    4.2 浏览器测试

    4.3 分辨率测试

    4.4 Modem/ 连接速率

    4.5 打印机

    4.6 组合测试

5. 安全测试

    5.1 目录设置

    5.2 SSL

    5.3 登录

    5.4 日志文件

    5.5 脚本语言

6. 接口测试

    6.1 服务器接口

    6.2 外部接口

    6.3 错误处理

四．测试手段

    80% 手工完成功能测试， 20％用 Loadrunner工具完成性能测试。

五．测试环境

1. 软件环境：

  客户端：

浏览器： Internet Explorer6.0

        操作系统： Microsoft Windows XP/2000/me

  服务器：

应用程序： IP Billing System

                 数据库： SQL Server2000

              操作系统： Microsoft Windows 2003 server

2. 硬件环境：

  客户端： CPU： Intel Celeron 2.26GHz

          内存： 2.26GHz， 256MB

  服务器： CPU： Intel Celeron 2.26GHz

          内存： 2.26GHz， 1G

六．测试策略

1. 功能测试

    1.1 链接测试

    （ 1）用户管理－ Customer | Card | System | Product | Rate&Region | Account | Query | Statistic

      (2) 用户管理－部门管理－部门名称（ 开发部 ， 销售部 ， 人事 部 ， 采购部 ， 测试部 ）

    （ 3）用户管理－用户管理－ First/prev/Next/Last/del

    （ 4）用户管理－用户管理－用户名称（用户姓名）

    （ 5）资源管理－号码管理－查询结果－电话号码列

    （ 6）资源管理－号码管理－ First/prev/Next/Last

    （ 7）资源管理－设备管理－设备 ID/ First/prev/Next/Last

    （ 8）呼叫设置－拨号规则查询－ First/prev/Next/Last

     (9) 呼叫设置－计费号码设置－ First/prev/Next/Last

    （ 10）呼叫设置－ QOS设置－ First/prev/Next/Last

    （ 11）增值服务－服务模板管理－ First/prev/Next/Last/模板名称

    （ 12）增值服务－服务管理－ First/prev/Next/Last/电话号码

（ 13）统一消息－ Atendance 管理 /短消息 /通知－ First/prev/Next/Last

（ 14）统一消息－ Voice Mail 管理－ First/prev/Next/Last/ 接听 /删除 /导出文件

 (15) 故障管理－ First/prev/Next/Last/撤销 /删除 /回退 /标题

（ 16）通讯录管理－ First/prev/Next/Last/删除 /姓名

(17) 系统管理－角色管理－ modify right/del/ First/prev/Next/Last

（ 18）系统管理－操作员管理－ First/prev/Next/Last/edit/del

（ 19）区号查询－ 国际长途区号－ 亚洲/ 欧洲/ 非洲/ 北美洲/ 南美洲/ 大洋洲

（ 20）系统管理－ 常见问题 －所有链接

     测试目标 ： 1.测试所有链接是否按指示的那样确实链接到了该链接的页面；

2 ．测试所链接的页面是否存在；

3. 保证 Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的 URL地址才能访问。

  测试方法 ：点击相关链接，检验链接的页面是否正确； 或 Xenu Link Sleuth 和 HTML Link Validator 工具

1.2 表单测试

    （ 1）首页－图片 /登陆按钮

    （ 2）用户管理－图片

    （ 3）用户管理－部门管理－ query/add/go!/bank按钮 /下拉框

     (4) 用户管理－用户管理－ query/add/go!/bank按钮 /下拉框

    （ 5）用户管理－密码修改－ SAVE/CANCEL按钮

    （ 6） 资源管理－号码管理－查询结果复选框

    （ 7）资源管理－号码管理－ query/start/stop/go/update按钮

    （ 8）资源管理－号码管理－设备 /状态 /原分机模式 /新分机模式下拉框

    （ 9）资源管理－设备管理－类型 /showpage下拉框

    （ 10）呼叫设置－拨号规则查询－集团拨号规则列表框 /设备 ,showpage下拉框 /查询结果数据表 / Query,Go 按钮

    (11) 呼叫设置－计费号码设置－ Query， Update， go按钮 / showpage下拉框

（ 12）呼叫设置－计费号码设置－查询结果、 Select all in this page， Select all search result复选框

    （ 13）呼叫设置－ QOS 设置－ Query ， Update， go按钮 / showpage，新 QOS下拉框

    （ 14）呼叫设置－ QOS 设置－ 查询结果、 Select all in this page， Select all search result复选框

（ 15）增值服务－服务模板管理－ Query， Add， Go按钮 /pageshow下拉框

（ 16） 增值服务－服务管理－ Query ， Update， go按钮 /号码状态 , 新模板 , PageShow下拉框 /查询结果、 Select all in this page， Select all search result复选框

（ 17）统一消息－ Atendance 管理 /短消息 /通知 / Voice Mail管理－ Query， Update， go，浏览 按钮 /缺省，自定义单选按钮 / 数据表格 复选框

（ 18）统一消息－ Voice Mail 管理－ Query， Update， go，试听，浏览 按钮 /接听状态，系统提供 下拉框 / 系统提供，用户定义单选按钮

（ 19）故障管理－ Query， add， go,save,cancel ,go 按钮 /pageshow 下拉框

(20) 通讯录管理－ Query， add， go,save,cancel 按钮

(21) 话单查询－ Query 按钮

（ 22）系统管理－角色管理－ add， save&right,save,cancel 按钮 / Type,showpage 下拉框

（ 23）系统管理－角色管理－修改权限－ save,cancel 按钮 / 数据表格所有权限复选框

 (24) 系统管理－操作员管理－ add， go， save,cancel按钮 /showpage 下拉框 / Sex, Operator Type单选按钮

(25) 系统管理－日志查询－ Operator Login ID,Operation下拉框 / Query按钮 / Both, Success, Fail单选按钮

测试目标：

1. 使用表单来进行在线注册，确保提交按钮能正常工作，当注册完成后应返回注册成功的消息；

2. 使用表单收集配送信息，应确保程序能够正确处这些数据；

3. 使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性；

4. 使用了默认值，还要检验默认值的正确性

测试方法： 在表单中输入相应的合理的信息，点击提交，检验返回信息是否正确和完整。

现在很多网站都用到Cookies，特别是用户的登陆以及购物网站的购物车。 Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies 访问了某一个应用系统时，Web 服务器将发送关于用户的信息，把该信息以Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

100   Continue   初始的请求已经接受，客户应当继续发送请求的其余部分。（HTTP 1.1新）  
101   Switching Protocols   服务器将遵从客户的请求转换到另外一种协议（HTTP 1.1新）  
200   OK   一切正常，对GET和POST请求的应答文档跟在后面。
201   Created   服务器已经创建了文档，Location头给出了它的URL。  
202   Accepted   已经接受请求，但处理尚未完成。  
203   Non-Authoritative Information   文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝（HTTP 1.1新）。  
204   No Content   没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。  
205   Reset Content   没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容（HTTP 1.1新）。  
206   Partial Content   客户发送了一个带有Range头的GET请求，服务器完成了它（HTTP 1.1新）。  
300   Multiple Choices   客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。  
301   Moved Permanently   客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。  
302   Found   类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。注意，在HTTP1.0中对应的状态信息是“Moved Temporatily”。
出现该状态代码时，浏览器能够自动访问新的URL，因此它是一个很有用的状态代码。
注意这个状态代码有时候可以和301替换使用。例如，如果浏览器错误地请求（缺少了后面的斜杠），有的服务器返回301，有的则返回302。
严格地说，我们只能假定只有当原来的请求是GET时浏览器才会自动重定向。请参见307。

303   See Other   类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取（HTTP 1.1新）。  
304   Not Modified   客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。  
305   Use Proxy   客户请求的文档应该通过Location头所指明的代理服务器提取（HTTP 1.1新）。  
307   Temporary Redirect   和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是POST，即使它实际上只能在POST请求的应答是303时 才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码：当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只 能跟随对GET请求的重定向。（HTTP 1.1新）  
400   Bad Request   请求出现语法错误。  
401   Unauthorized   客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。  
403   Forbidden   资源不可用。服务器理解客户的请求，但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。  
404   Not Found   无法找到指定位置的资源。这也是一个常用的应答。  
405   Method Not Allowed   请求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）对指定的资源不适用。（HTTP 1.1新）  
406   Not Acceptable   指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容（HTTP 1.1新）。  
407   Proxy Authentication Required   类似于401，表示客户必须先经过代理服务器的授权。（HTTP 1.1新）  
408   Request Timeout   在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求。（HTTP 1.1新）  
409   Conflict   通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功。（HTTP 1.1新）  
410   Gone   所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。（HTTP 1.1新）  
411   Length Required   服务器不能处理请求，除非客户发送一个Content-Length头。（HTTP 1.1新）  
412   Precondition Failed   请求头中指定的一些前提条件失败（HTTP 1.1新）。  
413   Request Entity Too Large   目标文档的大小超过服务器当前愿意处理的大?gt;>Ｈ绻 衿魅衔 约耗芄簧院笤俅 砀们肭螅 蛴Ω锰峁┮桓鯮etry-After头（HTTP 1.1新）。  
414   Request URI Too Long   URI太长（HTTP 1.1新）。  
416   Requested Range Not Satisfiable   服务器不能满足客户在请求中指定的Range头。（HTTP 1.1新）  
500   Internal Server Error   服务器遇到了意料不到的情况，不能完成客户的请求。  
501   Not Implemented   服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求。  
502   Bad Gateway   服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。  
503   Service Unavailable   服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头。  
504   Gateway Timeout   由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。（HTTP 1.1新）  
505   HTTP Version Not Supported   服务器不支持