软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。

　　中国软件评测中心的测试原则就是从用户和开发者的角度出发进行软件产品测试的，通过我们的测试，可以为用户提供放心的产品，并对优秀的产品进行认证。

　　为了达到上述的原则，那么需要注意以下几点：

　　1．应当把“尽早和不断的测试”作为开发者的座右铭

　　2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

　　3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

　　4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

　　5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

　　6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

　　7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。

　　8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

                                          来源:中国软件评测中心

软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

1 数据和数据库完整性测试

数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。

数据库完整性原即：

主码完整性：主码不能为空；

外码完整性：外码必须等于对应的主码或者为空。

数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。

在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。

比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。

员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。

2 白盒测试

白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试

2.1 静态白盒测试

利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下：

Function NameGet(){

….

}

这是属于不符合开发规范的错误。

有这样一段代码:

if (i<0) & (i>=0)

…

这段代码交集为整个数轴，IF语句没有必要

I=0;

while(I>100){

J=J+100;

T=J*PI;

}

在循环体内没有I的增加,bug产生。

2.2 动态白盒测试

利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。

看一段代码

if(I<0){

P1

}else{

P2

}

在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷

3.功能测试

功能测试指测试软件各个功能模块是否正确，逻辑是否正确。

对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。

比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。

4.UI测试

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等

用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关

比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。

5.性能测试

性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试

5.1负载测试

负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？

5.2强度测试

强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。

实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。

5.3数据库容量测试

数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。

数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。

比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。

5.4基准测试

基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。

如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。

5.5竞争测试

软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

6. 安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面：

应用程序级别的安全性，包括对数据或业务功能的访问

系统级别的安全性，包括对系统的登录或远程访问。

6.1应用程序级别的安全性

可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。

比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？

6.2系统级别的安全性

可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。

比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

7.故障转移和恢复测试

故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。

故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。

故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。

恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份

比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？

8.配置测试

又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）

下面列出主要配置测试

8.1浏览器兼容性

测试软件在不同产商的浏览器下是否能够正确显示与运行；

比如测试IE，Natscape浏览器下是否可以运行这套软件？

8.2操作系统兼容性

测试软件在不同操作系统下是否能够正确显示与运行；

比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？

8.3硬件兼容性

测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.

比如在INTER,舒龙CPU芯片下系统是否能够正常运行？

这样的测试必须建立测试实验室，在各种环境下进行测试。

9.安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。

安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

10.多语种测试

又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。

本地化测试还要考虑：

l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度

l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。

l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。

11.文字测试

文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。

比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。

12.分辨率测试

测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

13发布测试

主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试

13.1说明书测试

主要为语言检查，功能检查，图片检查

语言检查：检查说明书语言是否正确，用词是否易于理解；

功能检查：功能是否描述完全，或者描述了并没有的功能等；

图片检查:：检查图片是否正确

13.2宣传材料测试

主要测试产品中的附带的宣传材料中的语言，描述功能，图片

13.3帮助文件测试

帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。

13.4广告用语

产品出公司前的广告材料文字，功能，图片，人性化的检查

14 文档审核测试

文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：

文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。

14.1需求文档测试

主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；

14.2设计文档测试

测试设计是否符合全部需求以及设计是否合理。

总结

据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型。

即使是很好的实现了TCP/IP协议，由于它本身有着一些不安全的地方，从而可以对TCP/IP网络进行攻击。这些攻击包括序列号欺骗，路由攻击，源地址欺骗和授权欺骗。本文除了介绍IP欺骗攻击方法外，还介绍怎样防止这个攻击手段。
 
上述攻击是建立在攻击者的计算机（包括路由）是连在INTERNET上的。这里的攻击方法是针对TCP/IP本身的缺陷的，而不是某一具体的实现。
 
实际上，IP 欺骗不是进攻的结果，而是进攻的手段。进攻实际上是信任关系的破坏。
 
第一节　IP欺骗原理
 
信任关系
 
＞ ～/.rhosts' ；从主机B上，在你的home目录中输入'echo " A username ＞～/.rhosts' 。至此，你能毫无阻碍地使用任何以r＊开头的远程调用命令,如：rlogin，rcall，rsh等，而无口令验证的烦恼。这些命令将允许以地址为基础的验证，或者允许或者拒绝以IP地址为基础的存取服务。
 
这里的信任关系是基于IP地址的。
 
Rlogin
 
Rlogin 是一个简单的客户/服务器程序，它利用TCP传输。Rlogin 允许用户从一台主机登录到另一台主机上，并且，如果目标主机信任它，Rlogin 将允许在不应答口令的情况下使用目标主机上的资源。安全验证完全是基于源主机的IP 地址。因此，根据以上所举的例子，我们能利用Rlogin 来从B远程登录到A，而且不会被提示输入口令。
 
TCP 序列号预测
 
IP只是发送数据包，并且保证它的完整性。如果不能收到完整的IP数据包，IP会向源地址发送一个ICMP 错误信息，希望重新处理。然而这个包也可能丢失。由于IP是非面向连接的，所以不保持任何连接状态的信息。每个IP数据包被松散地发送出去，而不关心前一个和后一个数据包的情况。由此看出，可以对IP堆栈进行修改，在源地址和目的地址中放入任意满足要求的IP地址，也就是说，提供虚假的IP地址。
 
TCP提供可靠传输。可靠性是由数据包中的多位控制字来提供的，其中最重要的是数据序列和数据确认，分别用SYN和ACK来表示。TCP 向每一个数据字节分配一个序列号，并且可以向已成功接收的、源地址所发送的数据包表示确认（目的地址ACK 所确认的数据包序列是源地址的数据包序列，而不是自己发送的数据包序列）。ACK在确认的同时，还携带了下一个期望获得的数据序列号。显然，TCP提供的这种可靠性相对于IP来说更难于愚弄。
 
序列编号、确认和其它标志信息 
 
由于TCP是基于可靠性的，它能够提供处理数据包丢失，重复或是顺序紊乱等不良情况的机制。实际上，通过向所传送出的所有字节分配序列编号，并且期待接收端对发送端所发出的数据提供收讫确认，TCP 就能保证可靠的传送。接收端利用序列号确保数据的先后顺序，除去重复的数据包。TCP 序列编号可以看作是32位的计数器。它们从0至2^32－1 排列。每一个TCP连接（由一定的标示位来表示）交换的数据都是顺序编号的。在TCP数据包中定义序列号（SYN）的标示位位于数据段的前端。确认位（ACK）对所接收的数据进行确认，并且指出下一个期待接收的数据序列号。 
 
TCP通过滑动窗口的概念来进行流量控制。设想在发送端发送数据的速度很快而接收端接收速度却很慢的情况下，为了保证数据不丢失，显然需要进行流量控制，协调好通信双方的工作节奏。所谓滑动窗口，可以理解成接收端所能提供的缓冲区大小。TCP利用一个滑动的窗口来告诉发送端对它所发送的数据能提供多大的缓冲区。由于窗口由16位bit所定义，所以接收端TCP 能最大提供65535个字节的缓冲。由此，可以利用窗口大小和第一个数据的序列号计算出最大可接收的数据序列号。 
 
其它TCP标示位有RST（连接复位，Reset the connection）、PSH（压入功能，Push function）和FIN （发送者无数据，No more data from sender）。如果RST 被接收，TCP连接将立即断开。RST 通常在接收端接收到一个与当前连接不相关的数据包时被发送。有些时候，TCP模块需要立即传送数据而不能等整段都充满时再传。一个高层的进程将会触发在TCP头部的PSH标示，并且告诉TCP模块立即将所有排列好的数据发给数据接收端。FIN 表示一个应用连接结束。当接收端接收到FIN时，确认它，认为将接收不到任何数据了。 
 
TCP序列号预测最早是由Morris对这一安全漏洞进行阐述的。他使用TCP序列号预测，即使是没有从服务器得到任何响应， 来产生一个TCP包序列。这使得他能欺骗在本地网络上的主机。
 
通常TCP连接建立一个包括3次握手的序列。客户选择和传输一个初始的序列号（SEQ标志）ISN C，并设置标志位SYN=１，告诉服务器它需要建立连接。服务器确认这个传输，并发送它本身的序列号ISN S，并设置标志位ACK，同时告知下一个期待获得的数据序列号是ISN=1。客户再确认它。在这三次确认后，开始传输数据。整个过程如下所示：(C:Client S:Server)
C---S: SYN(ISN C ) 
S---C: SYN(ISN S ) ,ACK(ISN C ) 
C---S: ACK(ISN S ) 
C---S:数据 或S---C:数据
 
也就是说对一个会话，C必须得到ISN S确认。ISN S可能是一个随机数。
 
了解序数编号如何选择初始序列号和如何根据时间变化是很重要的。似乎应该有这种情况，当主机启动后序列编号初始化为1，但实际上并非如此。初始序列号是由tcp_init函数确定的。ISN每秒增加128000，如果有连接出现，每次连接将把计数器的数值增加64000。很显然，这使得用于表示ISN的32位计数器在没有连接的情况下每9.32 小时复位一次。之所以这样，是因为这样有利于最大限度地减少旧有连接的信息干扰当前连接的机会。这里运用了2MSL 等待时间的概念（不在本文讨论的范围之内）。如果初始序列号是随意选择的，那么不能保证现有序列号是不同于先前的。假设有这样一种情况，在一个路由回路中的数据包最终跳出了循环，回到了“旧有”的连接（此时其实是不同于前者的现有连接），显然会发生对现有连接的干扰。
 
假设一个入侵者X有一种方法，能预测ISN S。在这种情况下，他可能将下列序号送给主机T来模拟客户的真正的ISN S：
X---S: SYN(ISN X ) ,SRC = T 
S---T: SYN(ISN S ) ,ACK(ISN X ) 
X---S: ACK(ISN S ) ,SRC =T 
 
尽管消息S*T并不到X，但是X能知道它的内容，因此能发送数据。如果X要对一个连接实施攻击，这个连接允许执行命令，那么另外的命令也能执行。
 
那么怎样产生随机的ISN？在Berkeley系统，最初的序列号变量由一个常数每秒加一产生，等到这个常数一半时，就开始一次连接。这样，如果开始了一个合法连接，并观察到一个ISN S在用，便可以计算，有很高可信度，ISN S 用在下一个连接企图。
 
Morris 指出，回复消息
S---T:SYN(ISN S ) ,ACK(ISN X )
事实上并不消失，真正主机将收到它，并试图重新连接。这并不是一个严重的障碍。
 
Morris发现，通过模仿一个在T上的端口，并向那个端口请求一个连接，他就能产生序列溢出，从而让它看上去S*T消息丢失了。另外一个方法，可以等待知道T关机或重新启动。
 
下面详细的介绍一下。
IP欺骗
 
IP欺骗由若干步骤组成，这里先简要地描述一下，随后再做详尽地解释。先做以下假定：首先，目标主机已经选定。其次，信任模式已被发现，并找到了一个被目标主机信任的主机。黑客为了进行IP欺骗，进行以下工作：使得被信任的主机丧失工作能力，同时采样目标主机发出的TCP 序列号，猜测出它的数据序列号。然后，伪装成被信任的主机，同时建立起与目标主机基于地址验证的应用连接。如果成功，黑客可以使用一种简单的命令放置一个系统后门，以进行非授权操作。
 
使被信任主机丧失工作能力 
 
一旦发现被信任的主机，为了伪装成它，往往使其丧失工作能力。由于攻击者将要代替真正的被信任主机，他必须确保真正被信任的主机不能接收到任何有效的网络数据，否则将会被揭穿。有许多方法可以做到这些。这里介绍“TCP SYN 淹没”。
 
前面已经谈到，建立TCP连接的第一步就是客户端向服务器发送SYN请求。 通常，服务器将向客户端发送SYN/ACK 信号。这里客户端是由IP地址确定的。客户端随后向服务器发送ACK，然后数据传输就可以进行了。然而，TCP处理模块有一个处理并行SYN请求的最上限，它可以看作是存放多条连接的队列长度。其中，连接数目包括了那些三步握手法没有最终完成的连接，也包括了那些已成功完成握手，但还没有被应用程序所调用的连接。如果达到队列的最上限，TCP将拒绝所有连接请求，直至处理了部分连接链路。因此，这里是有机可乘的。
 
黑客往往向被进攻目标的TCP端口发送大量SYN请求，这些请求的源地址是使用一个合法的但是虚假的IP地址（可能使用该合法IP地址的主机没有开机）。而受攻击的主机往往是会向该IP地址发送响应的，但可惜是杳无音信。与此同时IP包会通知受攻击主机的TCP：该主机不可到达，但不幸的是TCP会认为是一种暂时错误，并继续尝试连接（比如继续对该IP地址进行路由，发出SYN/ACK数据包等等），直至确信无法连接。
 
当然，这时已流逝了大量的宝贵时间。值得注意的是，黑客们是不会使用那些正在工作的IP地址的，因为这样一来，真正IP持有者会收到SYN/ACK响应，而随之发送RST给受攻击主机，从而断开连接。前面所描述的过程可以表示为如下模式。 
1 Z （X） －－－SYN －－－> B
　 Z （X） －－－SYN －－－＞ B
　 Z （X） －－－SYN －－－＞ B
 
2 X ＜－－－SYN/ACK－－ B
X ＜－－－SYN/ACK－－ B
 
3 X ＜－－－ RST －－－ B
　　
在时刻1时，攻击主机把大批SYN 请求发送到受攻击目标（在此阶段，是那个被信任的主机），使其TCP队列充满。在时刻2时，受攻击目标向它所相信的IP地址（虚假的IP）作出SYN/ACK反应。在这一期间，受攻击主机的TCP模块会对所有新的请求予以忽视。不同的TCP 保持连接队列的长度是有所不同的。BSD 一般是5，Linux一般是6。使被信任主机失去处理新连接的能力，所赢得的宝贵空隙时间就是黑客进行攻击目标主机的时间，这使其伪装成被信任主机成为可能。
 
序列号取样和猜测 
 
前面已经提到，要对目标主机进行攻击，必须知道目标主机使用的数据包序列号。现在，我们来讨论黑客是如何进行预测的。他们先与被攻击主机的一个端口（SMTP是一个很好的选择）建立起正常的连接。通常，这个过程被重复若干次，并将目标主机最后所发送的ISN存储起来。黑客还需要估计他的主机与被信任主机之间的RTT时间（往返时间），这个RTT时间是通过多次统计平均求出的。RTT 对于估计下一个ISN是非常重要的。前面已经提到每秒钟ISN增加128000，每次连接增加64000。现在就不难估计出ISN的大小了，它是128000乘以RTT的一半，如果此时目标主机刚刚建立过一个连接，那么再加上一个64000。再估计出ISN大小后，立即就开始进行攻击。当黑客的虚假TCP数据包进入目标主机时，根据估计的准确度不同，会发生不同的情况： 
 
·如果估计的序列号是准确的，进入的数据将被放置在接收缓冲器以供使用。 
 
·如果估计的序列号小于期待的数字，那么将被放弃。 
 
·如果估计的序列号大于期待的数字，并且在滑动窗口（前面讲的缓冲）之内，那么，该数据被认为是一个未来的数据，TCP模块将等待其它缺少的数据。如果估计的序列号大于期待的数字，并且不在滑动窗口（前面讲的缓冲）之内，那么，TCP将会放弃该数据并返回一个期望获得的数据序列号。下面将要提到，黑客的主机并不能收到返回的数据序列号。 
 
1 Z（B） --－－SYN －－－> A
2 B ＜－－－SYN/ACK－－－ A
3 Z（B） --－－－ACK－－－＞ A
4 Z（B） －－－——PSH－－－＞ A
 
攻击者伪装成被信任主机的IP 地址，此时，该主机仍然处在停顿状态（前面讲的丧失处理能力），然后向目标主机的513端口(rlogin的端口号)发送连接请求，如时刻1所示。在时刻2，目标主机对连接请求作出反应，发送SYN/ACK数据包给被信任主机（如果被信任主机处于正常工作状态，那么会认为是错误并立即向目标主机返回RST数据包，但此时它处于停顿状态）。按照计划，被信任主机会抛弃该SYN/ACK数据包。然后在时刻3，攻击者向目标主机发送ACK数据包，该ACK使用前面估计的序列号加1（因为是在确认）。如果攻击者估计正确的话，目标主机将会接收该ACK 。至此，连接正式建立起来了。在时刻4，将开始数据传输。一般地，攻击者将在系统中放置一个后门，以便侵入。经常会使用 ′cat ＋＋ >> ～/.rhosts′。之所以这样是因为，这个办法迅速、简单地为下一次侵入铺平了道路。
 
一个和这种TCP序列号攻击相似的方法，是使用NETSTAT服务。在这个攻击中，入侵者模拟一个主机关机了。如果目标主机上有NETSTAT，它能提供在另一端口上的必须的序列号。这取消了所有要猜测的需要。
 
典型攻击工具和攻击过程:hunt
 
IP欺骗的防止
 
防止的要点在于，这种攻击的关键是相对粗糙的初始序列号变量在Berkeley系统中的改变速度。TCP协议需要这个变量每秒要增加25000次。Berkeley 使用的是相对比较慢的速度。但是，最重要的是，是改变间隔，而不是速度。
 
我们考虑一下一个计数器工作在250000Hz时是否有帮助。我们先忽略其他发生的连接，仅仅考虑这个计数器以固定的频率改变。
 
为了知道当前的序列号，发送一个SYN包，收到一个回复：
X---S: SYN(ISN X ) 
S---X: SYN(ISN S ) ,ACK(ISN X ) (1)
第一个欺骗包，它触发下一个序列号，能立即跟随服务器对这个包的反应：
X---S: SYN(ISN X ) ,SRC = T (2)
序列号ISN S用于回应了：
S---T: SYN(ISN S ) ,ACK(ISN X )
是由第一个消息和服务器接收的消息唯一决定。这个号码是X和S的往返精确的时间。这样，如果欺骗能精确地测量和产生这个时间，即使是一个4-U时钟都不能击退这次攻击。
 
抛弃基于地址的信任策略 
 
阻止这类攻击的一种非常容易的办法就是放弃以地址为基础的验证。不允许r＊类远程调用命令的使用；删除.rhosts 文件；清空/etc/hosts.equiv 文件。这将迫使所有用户使用其它远程通信手段，如telnet、ssh、skey等等。 
 
进行包过滤 
 
如果您的网络是通过路由器接入Internet 的，那么可以利用您的路由器来进行包过滤。确信只有您的内部LAN可以使用信任关系，而内部LAN上的主机对于LAN以外的主机要慎重处理。您的路由器可以帮助您过滤掉所有来自于外部而希望与内部建立连接的请求。 
 
使用加密方法 
 
阻止IP欺骗的另一种明显的方法是在通信时要求加密传输和验证。当有多种手段并存时，可能加密方法最为适用。 
使用随机化的初始序列号 
 
黑客攻击得以成功实现的一个很重要的因素就是，序列号不是随机选择的或者随机增加的。Bellovin 描述了一种弥补TCP不足的方法，就是分割序列号空间。每一个连接将有自己独立的序列号空间。序列号将仍然按照以前的方式增加，但是在这些序列号空间中没有明显的关系。可以通过下列公式来说明： 
 
ISN =M＋F（localhost，localport ，remotehost ，remoteport ） 
M：4微秒定时器 
F：加密HASH函数。 
 
F产生的序列号，对于外部来说是不应该能够被计算出或者被猜测出的。Bellovin 建议F是一个结合连接标识符和特殊矢量（随机数，基于启动时间的密码）的HASH函数。

TPC_C基准是联机事务处理工作量的一个衡量标准。它是一种读操作和更新事务操作剧烈交互执行的处理，它模拟了被复杂的联机事务处理应用环境创建的活动，它是通过把很多的系统组成部件和特定环境相关联来实现的，这种特定环境的表现是：

能够并行执行多种具有一定复杂度的事务 具有可在线延时处理事务执行的模式 支持多个在线终端活动 能够很好的协调系统运行和应用程序执行的时间 支持大容量磁盘的输入输出 事务处理的正确性(ACID 特性) 能够识别分配高低优先级数据访问 组成数据库的基本表包含的数据可以具有各种大小、属性和关联 有数据访问和更新的争夺

由TPC-C提出的执行公制是用每分钟的命令处理数量来对“交易吞吐量”进行测量的。多种事务用来模拟交易活动中的要求在一定时间限制范围内作出响应处理请求。这种标准的执行公制被描述为事务每分钟-C（tpmC即transactions-per-minute-C）。为了和TPC-C标准一致，所有关于tpmC的引用结果必须包括tpmC评估，包括关联价格每tpmC和配置的定价的有效日期。

虽然这些规格明确执行在相关数据的模型和传统的连轴配置之间，但是数据库有可能会利用一些商用的数据库管理系统（DBMS）、数据库服务器、文件系统或者其他能够提供机能上等价执行的数据仓库。"table"、"row"和 "column"这些术语是被引用的，例如用在具有合理的数据结构的文件中。

TPC-C 用的术语和公制类似于由TPC或者其他组织发明的基准。这种在术语学中的相似处并不意味着可以拿TPC-C的结果与其他基准的结果相做比较的。唯一可以和TPC-C的基准结果相比较的是由其他修订本所构造的TPC-C结果。

尽管这种基准提供了一个很好的环境来模拟许多联机事务处理设备，但是这种基准不能反映全部的联机事务处理所涉及的必要条件。另外客户可以获得的由卖主提供的结果的范围依赖于客户的请求与TPC-C的接近程度。来自于这个基准相关系统的性能不是可以被其他的工作量和外界因素所控制的。对其他环境的外推法是不被推荐的。

基准的结果主要决定于工作量、明确的应用要求和系统的设计和执行。相关的系统执行情况将会导致这种或者那种的因素的不同。这就意味着当预期容量编织鉴定和/或者预期产品估价的时候，TPC-C不应该被用作特定用户应用基准的替代。

网络瓶颈指的是影响网络传输性能及稳定性的一些相关因素，如网络拓扑结构，网线，网卡，服务器配置，网络连接设备等，
简单分析：
1．组网前选择适当的网络拓扑结构是网络性能的重要保障，这里有两个原则应该把握：一是应把性能较高的设备放在数据交换的最高层，即交换机与集线器组成的网络，应把交换机放在第一层并连接服务器，二是尽可能减少网络的级数，如四个交换机级联不要分为四级，应把一个交换机做一级，另三个同时级联在第一级做为第二级；
2．网线的做法及质量也是影响网络性能的重要因素，对于100M设备(包括交换机，集线器和网卡)，要充分发挥设备的性能，应保证网线支持100M，具体是网线应是五类以上线且质量有保障，并严格按照100M网线标准(即568B和568A)做线；
3．网卡质量不过关或芯片老化也容易引起网络传输性能下降或工作不稳定，选择知名品牌可有很好的保障；
4．对某些如无盘网络，游戏网络等对服务器的数据交换频繁且大量的网络环境，服务器的硬件配置(主要是CPU处理速度，内存，硬盘，网卡)往往成为影响网络性能的最大瓶颈，提升网络性能须从此入手；
5．选择适当的网络连接设备(交换机和集线器)同样也是网络性能的重要保障，除选择知名品牌外，网络扩充导致性能下降时应考虑设备升级的必要性。

Unit testing（单元测试），指一段代码的基本测试，其实际大小是未定的，通常是一个函数或子程序，一般由开发者执行。

Integration testing（集成测试），被测试系统的所有组件都集成在一起，找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

Acceptance testing（验收测试），系统开发生命周期方法论的一个阶段，这时相关的用户和／或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。 

Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

Black box testing（黑盒测试），指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。

White box testing（白盒测试），根据软件内部的工作原理分析来进行测试,基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。

Automated Testing（自动化测试），使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试中用得较多。 

Bug (错误)，有时称作defect（缺陷）或error（错误），软件程序中存在的编程错误，可能会带来不必要的副作用，软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为：软件未达到产品说明书标明的功能；软件出现产品说明书指明不会出现的错误；软件功能超出产品说明书指明的范围；虽然产品说明书未指出但是软件应达到的目标；软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。 Bug report（错误报告），也称为“Bug record（错误记录）”，记录发现的软件错误信息的文档，通常包括错误描述、复现步骤、抓取的错误图像和注释等。

Bug tracking system（错误跟踪系统，BTS），也称为“Defect tracking system，DTS”，管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

Exception（异常/例外），一个引起正常程序执行挂起的事件。

Crash（崩溃），计算机系统或组件突然并完全的丧失功能，例如软件或系统突然退出或没有任何反应（死机）。

Build（工作版本），软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本，也可以是展示要在最终产品中提供的部分功能的部分系统。

Functional testing (功能测试)，也称为behavīoral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。

Load testing（负载测试），通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

Pilot testing（引导测试），软件开发中，验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中，引导测试通常是客户检查软件测试公司测试能力的一种形式，只有通过了客户特定的引导测试，软件测试公司才能接受客户真实软件项目的软件测试。

Portability testing（可移植性测试），测试软件是否可以被成功移植到指定的硬件或软件平台上。

Compatibility Testing（兼容性测试），也称“Configuration testing（配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

Installing testing（安装测试），确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

International testing（国际化测试），国际化测试的目的是测试软件的国际化支持能力，发现软件的国际化的潜在问题，保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型，针对任何区域性或区域设置检查产品的功能是否正常，软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语（可选）的混合字符。

Localizability testing(本地化能力测试)，本地化能力是指不需要重新设计或修改代码，将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本，提高测试效率，本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括：字符的硬编码（即软件中需要本地化的字符写在了代码内部），对需要本地化的字符长度设置了国定值，在软件运行时以控件位置定位，图标和位图中包含了需要本地化的文本，软件的用户界面与文档术语不一致等。

Localization testing（本地化测试），本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试，安装/卸载测试，当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分。

Ad hoc testing (随机测试)，没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

Smoke testing（冒烟测试），冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing（健全测试）”。

Sanity testing（健全测试），软件主要功能成分的简单测试以保证它是否能进行基本的测试。

User interface（用户界面，UI），广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

User interface testing (用户界面测试)，指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

Static testing（静态测试），不通过执行来测试一个系统。如代码检查，文档检查和评审等。

Regression testing（回归测试），在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，对软件的任何新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再现。

Capture/Replay Tool (捕获/回放工具)，一种测试工具，能够捕获在测试过程中传递给软件的输入，并且能够在以后的时间中，重复这个执行的过程。这类工具一般在GUI测试中用的较多。

Debug（调试），开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时，或者根据测试错误报告指出错误以后，开发人员需要执行调试过程来解决已存在的错误。

Deployment（部署），也称为shipment(发布)，对内部IT系统而言，指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。 Dynamic testing（动态测试），通过执行软件的手段来测试软件。

Garbage characters（乱码字符），程序界面中显示的无意义的字符，例如，程序对双字节字符集的字符不支持时，这些字符不能正确显示。

GB 18030 testing（GB 18030测试），软件支持GB 18030字符集标准能力的测试，包括GB 18030字符的输入、输出、显示、存储的支持程度。

Priority（优先权），从商业角度出发是指错误的重要性，尤其是从客户和用户的角度出发，是指错误对于系统的可行性和可接受性的影响。与“Severity（严重性）”相对照。

Severity（严重性），错误对被测系统的影响程度，在终端用户条件下发生的可能性，软件错误妨碍系统使用的程度。

Quality assurance（质量保证QA），采取相关活动，以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

Review（评审），在产品开发过程中，把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

Screen shot（抓屏、截图），软件测试中，将软件界面中的错误（窗口、菜单、对话框等）的全部或一部分，使用专用工具存储成图像文件，以便于后续处理。

Software life cycle（软件生命周期），开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。

Structured query language（结构化查询语句，SQL），在一个关系数据库中查询和处理数据的一种语言。

TBD(To be determined，待定)，在测试文档中标是一项进行中的尚未最终确定的工作。

Test（测试），执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同，并评价软件项的特性软件项的分析过程。软件工程过程的一个活动，它将软件在预定的条件下运行以判断软件是否符合预期结果。

Test case（测试用例），为特定目标而开发的一组测试输入、执行条件和预期结果，其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

Testing coverage（测试覆盖），指测试系统覆盖被测试系统的程度，一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

Testing environment（测试环境），进行测试的环境，包括测试平台、测试基础设施、测试实验室和其他设施。

Testing item（测试项），作为测试对象的工作版本。

Testing plan（测试计划），描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。

Testing procedure（测试过程），指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

Testing scrīpt（测试脚本），一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。

Testing suite（测试包），一组测试用里的执行框架；一种组织测试用例的方法。在测试包里，测试用例可以组合起来创造出独特的测试条件。 

一般地，基于开发周期中不同阶段对不同对象所进行的测试，可划分为： 

　　单元测试（unit test ）：

　　由编程的开发人员自行计划与完成的，针对单个或相关联的一组程序单元的测试。 

　　组装测试（inegration test ）：

　　计划于设计阶段，由开发人员与测试人员合作完成的，针对结合起来的不同单元以及它们的接口的测试。 

　　系统测试（system test ）：（可认为包括“可用性与图形用户界面测试”）

　　测试整个系统，以证实它满足要求所规定的功能、质量和性能等方面的特性。 

　　回归测试（regression test ）：

　　用于验证改变了的系统或其组件仍然保持应有的特性。 

　　验收测试（acceptance test ）：

　　测试整个系统，以保证其达到可以交付使用的状态。