软件测试相关知识01

（1）TCP状态转移要点：

1、LISTENING状态
FTP服务启动后首先处于侦听（LISTENING）状态。

2、ESTABLISHED状态
ESTABLISHED的意思是建立连接。表示两台机器正在通信。

3、CLOSE_WAIT

对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭

4、TIME_WAIT

我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期)，以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情况下，尽量不要主动断开连接，以减少TIME_WAIT状态造成的资源浪费。

目前有一种避免TIME_WAIT资源浪费的方法，就是关闭socket的LINGER选项。但这种做法是TCP协议不推荐使用的，在某些情况下这个操作可能会带来错误。

（2）为什么A还要发送一次确认呢？可以二次握手吗？

　　答：主要为了防止已失效的连接请求报文段突然又传送到了服务器，因而产生错误。如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务器，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务器，此时服务器误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务器发出确认，就建立新的连接了，此时客户端不理睬服务器的确认且不发送数据，则服务器一致等待客户端发送数据，浪费资源。

（3）Server端易受到SYN攻击？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

防范SYN攻击措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求。

（4）为什么A在TIME-WAIT状态必须等待2MSL的时间？

MSL最长报文段寿命Maximum Segment Lifetime，MSL=2

答：　　两个理由：1）保证A发送的最后一个ACK报文段能够到达B。2）防止“已失效的连接请求报文段”出现在本连接中。

（5）为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

（6）为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间，windows为2分钟)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

（7）CCB由哪些人员组成？

变更控制委员会CCB到底是不是只能设置一个呢，还是说可以设有多个？

可以按不同的需要，组成不同的CCB。

变更控制委员会CCB也可称为配置控制委员会(ConfigurationControlBoard)，是配置项变更的监管组织。其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，完全可以根据工作的需要组成。例如，按变更内容和变更请求的不同，组成不同的CCB。小的信息系统项目CCB可以只有1人甚至只是兼职人员。如果CCB不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的审定、标志的审定，以及产品的审定，并且可能实际的工作需要分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。

CCB可以由一个小组担任，也可以由多个不同的组担任，负责做出决定究竟将哪些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会会同样决定在哪一些版本中纠正哪些错误。
CCB的成员应当能代表变更涉及的团体。其可能包括如下方面的代表：
1.产品或计划管理部门
2.项目管理部门
3.开发部门
4.测试或质量保证部门
5.市场部或客户代表
6.制作用户文档的部门
7.技术支持部门
8.帮助桌面或用户支持热线部门
9.配置管理部门
当组建包含软硬件两方面项目的CCB时，还应当包含来自硬件工程、系统工程、制造部门或者硬件质量保证和配置管理的代表。
CCB是系统集成项目的所有者权益代表，负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
ccb作用
1、批准配置项的标识，以及信息系统的基线建立
2、制定访问控制策略
3、建立更改基线的设置，审核变更申请
4、根据配置管理员的报告决定相应的对策
配置控制委员会（CCB）是一个高级团体，对项目的所有方面都有所了解。它是一个专制的团体，由主席和顾问组成。它不是一个选举的团体。主席独自决定对所有提交的变更请求的最终安排；但是，CCB成员对变更的可行性提出建议。每个项目组需要建立项目级的配置控制委员会（即CCB）作为变更权威[5] 。
正式基线（需求基线、概要设计基线、详细设计基线、代码基线、测试基线、运行基线）的改变必须由项目组的CCB审查和批准。正式的基线，如客户需求和运行基线。正式基线的控制权威是CCB，CCB的主席通常由组织中的高层经理来担任。工程过程期间建立的开发基线，如设计和代码基线、测试基线由项目经理和/或项目技术负责人非正式地控制。
在配置管理计划中，对基线的建立时机有明确的时间表，当某基线按照评审流程通过评审后，就可以纳入到配置库中。在项目启动后，一些管理文档将陆续产生，如项目计划、SQA计划等，这些文档纳入配置库的项目管理区域。