分析被测系统的结构
　　系统的结构和系统的业务一样重要，不知道系统的网元结构可能没有办法进行监控，没有办法知道瓶颈在哪个节点，不能进行优化。
　　分析系统的结构，好的方法是项目组提供系统的部署和构成图；如果项目组不能提供或者没有项目组，那需要用TCPDUMP等抓包工具，分析数据流向。
　　TCPDUMP的使用：
　　tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap
　　(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型
　　(2)-i eth1 : 只抓经过接口eth1的包
　　(3)-t : 不显示时间戳
　　(4)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包
　　(5)-c 100 : 只抓取100个数据包
　　(6)dst port ! 22 : 不抓取目标端口是22的数据包
　　(7)src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24
　　(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析
　　从第一个节点分析流向到哪，确定第二层的节点；
　　然后从第二层每个节点分析第三层节点，逐层分析，完善系统的数据流向的所有机构层次和节点；
　　然后再弄明白每个节点部署的应用程序或者进程队列；
　　对每一个节点的应用程序或者进程队列进行测试监控；
　　后才能得出哪些应用或者进程队列需要进行优化。
　　弄明白系统的节点构成之外，还需要弄明白各个节点之间的通讯协议和数据格式，后面的测试工具选择和测试数据准备以及测试脚本开发需要你明白这些。
　　这一切的基础是要分析和弄明白系统的所有节点，也是要分析清楚系统的结构。
　　分析系统可能的性能瓶颈
　　分析系统的业务需求和系统的结构组成，同时预判系统可能存在的性能瓶颈，这是分析中的一个目标；得到预判的性能瓶颈后我们后面需要在监控的时候多注意一下这些节点。
　　当然有一些常见的可能会是系统瓶颈的节点我们需要注意:
　　（1） 登录，一般系统登录要进行多种校验，可能数据交互比较频繁；
　　（2） 下单，抢单、抢红包这个时候会有一定量的并发需求；
　　（3） 大数据的查询、统计和报表分析，会对系统产生压力；
　　（4） 视频、动画等会对网络产生压力；
　　（5） 消息比较集中的系统功能节点，会对系统产生压力；
　　（6） 一些特殊的业务需求会对系统产生压力；
　　常见的瓶颈：
　　（1） 数据库的瓶颈一般在磁盘IOPS过高造成进程阻塞
　　（2） 系统进程数过多一般会消耗系统的内存空间
　　（3） 消息队列和缓存服务，开启持久化后会需要考察磁盘IOPS，不开启持久化则需要考察内存占用
　　（4） 频繁的管道开辟和销毁会导致CPU占用较高
　　（5） 有部分程序结构上不能利用多个CPU
　　等等
　　在分析业务和系统结构的过程中，我们需要考虑这个业务点或者结构点会不会有大量的数据访问，会不会产生压力，我们的设计会不会产生性能瓶颈。
　　方案和案例设计
　　测试方案的以及后测试方案文档的形成，实际是上面所有分析工作的总结。
　　你写测试方案的过程是明确测试目的目标、分析业务需求、系统结构以及评估测试方法、测试安排、测试风险等等的过程总结。而这些全部来源于你在测试执行之前的分析，有时候可能你在测试过程中还需要做出一些分析和调整。
　　测试方案包含了这些你分析和整理的各个方面。
　　一个好的测试方案包含的内容：测试目的目标、内容（可能包含业务性能、可靠性、稳定性等等），业务需求目标，系统业务构成，系统节点构成，测试方法流程，需要监控的指标要求和节点等等。
　　测试案例，实际上一般需要包含在测试方案中；测试案例，实际上是普通的业务操作流程，用测试工具或者其他测试手段来模拟大的数据量业务操作，并对系统的各个节点进行监控，获取监控数据。预期的监控数据和实际监控数据的对比，满足要求是预期要求，实际对比结果是测试结果。