1.测试背景

公司属于创业型公司，由于人手关系，我一人负责该系统的测试。本系统是为某大企业而做的安全系统的某个子系统
为期一年的测试大概可以分 3 个阶段:

1：验证系统的分析功能准确程度；（2015 年 4 月至 7 月）

2：对系统分析能力进行性能测试，找出瓶颈口（2015 年 8 月至 11 月）

3：真实的客户现场的问题处理（2015 年 12 月至 2016 年 3 月）

2.系统架构

2.1.架构详情介绍

①　蓝盾服务器作用：使用 whireshark 抓取并保存流量数据包，其镜像口与交换机的镜像口相连，经过交换机的流量同时会流向蓝盾服务器。蓝盾服务器每 5 分钟保存一个数据包，当数据包数量达 20 个后，自动删除最旧的数据包，保存最新的数据包，从而保障磁盘容量。

②　流量分析服务器以 FTP 的方式，从蓝盾服务器下载数据包并进行分析。

③　管理服务器：用户的日常操作都在此进行，包括新增、编辑、删除、查看规则及查看分析的结果。

④　数据库互为同步：流量分析服务器与管理服务器的数据库为主从同步。

管理服务器为主，流量分析服务器为从：用户在管理服务器对流量规则进行新增后，记录马上同步到流量分析服务器，同理，编辑、删除也会马上同步，流量分析服务器根据其数据库的记录进行分析流量。

流量分析服务器为主，管理服务器为从：流量分析服务器分析得到的结果是保存在其数据库中。当结果写入库中，马上同步到管理服务器，用户就能够马上知道分析结果。

3 .功能演示（其中一个功能作演示）

功能介绍：分析并统计模型源 IP 段中的 IP，在设定时间段内访问目标 IP 的端口的次数。

3.1.实例

3.1.1.规则设置

该规则统计源 IP 段 192.168.11.1-192.168.11.230 中的 IP 在 2015-05-02 16:10 至 2015-05-02 16:15 期间访问系统 172.16.30.240 的情况。

3.1.2.结果

分析完数据包后，结果如下图，192.168.11.171 在此时间段内访问 172.16.30.240 的 80 端口 11 次。

3.1.3.质疑

得出结果后，相信会有好多疑问，例如：

①　是不是 IP 段 192.168.11.1-192.168.11.230 中只有 192.168.11.171 访问过目标 IP？

②　会不会有其他 IP 也访问过，但是系统没有分析出来？

③　是不是 192.168.11.171 根本没有访问过？

④　192.168.11.171 是不是只访问 80 端口？其他 8080,21,22 等端口其实有访问，但是没有分析出？

⑤　统计出 192.168.11.171 在此时间段内访问 172.16.30.240 的 80 端口 11 次，为什么结果是 11 次？而不是 2 次，20 次？有没有分析失误？

等等好多问题

3.1.4.验证结果

论点：源 IP 访问目标 IP 的某个端口，成功三次握手为 1 次的访问。所以多少次三次握手成功，就是访问目标 IP 多少次。

方法：过滤出访问 172.16.30.240 的所有三次握手数据包，为了验证方便，只需过滤出三次握手的第二次握手的记录就可以了，过滤语句如下：

tcp.flags.syn == 1 and tcp.flags.ack == 1 and tcp.flags.fin == 0 and ip.src==172.16.30.240

结果如下，确实存在 11 条访问记录，则证明 192.168.11.171 在此时间段内访问 172.16.30.240 的 80 端口 11 次。

3.1.5.测试结果

192.168.11.171 在此时间段内访问 172.16.30.240 的 80 端口 11 次 ，分析结果无误。

4.其他注意事项

确保服务器之前的通信，例如数据库是否同步，有时因为一个表结构改动了，导致数据库无法同步。