早上啊，睡懒觉呢。家里小萝莉醒了，为了不让她吵我睡觉，就把手机拿给她玩。谁知道这货啊，拿了手机直接拨了个电话给她爷爷奶奶，说妈妈不起床啊，肚子好饿啊，奶奶你给送点早餐来吃啊。然后我就听到电话那头的咆哮啊，这熊孩子！有宝贝的家庭引以为戒啊，引以为戒啊！
white'>你为了国外的生活，就可以这么抛弃我么？连最后的一面都不肯见我就偷偷跑掉，有种你走了就被他妈的回来！”一名工作人员走过来扶起姑娘，帮他拍掉身上的泥土：“对不起姑娘，这是国内航班……那啥，你哭错口了。”
三、性能测试
会接手性能测试项目的原因是在刚进项目的前几周我每个周六和周日都请假参加培训了<当时项目很急，版本基本上是周五出的，周六就必须加班测试了，由于我是新手，所以主管允许我请请假，这个主管是不是特好呀？>，后来主管就对我说，你参加过性能测试培训，就试着做一下VBM的性能测试吧（就这样刚进项目1个月不到，就接手性能测试工作了）。
之前的想法一直是要测试性能就必须使用Loadrunner工具，一个项目结束之后，只让我领悟到一点“工具都是浮云，计算机综合知识才是王道”。下面是我自己再两次性能测试实战后总结的性能测试具体步骤：
1、 需求调研：“测试RAID6模式下磁盘IO的读写性能，验证同时从PSM备份到VBM的性能达到60MB/s，从DVR备份到VBM的性能达到40MB/s，从VBM上实时预览的性能达到50MB/s”；
2、 分析需求：分析性能需求得到如下几个测试点：同时满足PSM的读盘速率是60MB/s，VBM的写盘速率是100MB，VBM的读盘速率是50MB/s的压力测试；在以上条件满足的时候长时间多天运行软件的长时间性能测试；超过上述读写盘压力时VBM的负载测试；
3、 测试计划：由于这是单个指标性性能测试，所以计划简单罗列了一下需要达到的性能目标、组网图、需要的时间、人员、环境，以及使用的软件。
4、 测试方案：主要是设计了多个性能测试场景，以及画了业务流程图；单独测试PSM写入VBM时60MB的压力；单独测试DVR写入VBM时40MB的压力；单独测试VBM上实时预览50MB的压力；以上三个场景同时测试VBM的压力。
5、 搭建环境：两台PSM服务器(单CPU+4GB)+一台VBM服务器(双CPU+16GB)+PC机上的Loadrunner9.5(模拟多用户预览)+Suse10下nmon工具+secureCRT+ Softlens（模拟多个摄像机）+DVRSDK(模拟多个DVR)。在PSM服务器上安装PSM+Softlens+nmon；在VBM服务器上安装VBM+nmon；在PC机上安装Loadrunner9.5+secureCRT+DVRSDK
a) 单独测试PSM写入VBM时60MB的压力：由于PSM本身性能限制的原因，因此在两个PSM上分别搭建Softlens,使备份的时候写入VBM的压力达到60MB/s
b) 单独测试DVR写入VBM时40MB的压力：使用模拟DVR，模拟写入VBM的压力达到40MB/s
c) 单独测试VBM上实时预览50MB的压力：使用Loadrunner模拟多用户并发登陆并发预览的压力达到50MB/s
d) 以上三个场景同时测试VBM的压力：上述三个场景同时并发对VBM达到的压力。
6、 执行测试：使用Softlens+DVR模拟了PSM和DVR写入VBM的压力，同时使用loadrunner模拟了VBM读出的压力，其中使用Vuser录制了一个用户在VBM上预览备份视频的情形，之后用Controller模拟多个用户同时并发预览的场景，最后使用nmon工具获得了性能测试过程中的CPU、内存、网络的使用情况（本次未使用loadrunner自带的analysis）
7、 分析调优：测试的过程中，瓶颈分析的工作做了多次，开发组也一起调优了多次。问题如下：
a) 第一次的问题是系统无响应，根据分析后得出的原因是视频备份到VBM以后，再进行预览的话需要一次格式转化，转换时的临时文件时放置在根目录/下面，同时多个用户并发实时预览的时候，存在20多个1G的临时文件放置在根目录下，而VBM的根目录只设置了20GB，这样就导致格式转换的结果失败，根目录由于占满空间而使系统无响应；解决办法是把临时文件的目录位置放到/vbm/data目录下。
b) 第二次的问题是无法实时预览，临时文件设置/vbm/data目录下以后，整个VBM的RAID6中其中一个RAID A组的vbm LUN（每个RAID组都划分了两个LUN，一个用来备份数据vbm
LUN，一个用来临时存放DVR的数据tmp LUN，PSM的数据直接写到vbm LUN里）由于承受不住100多MB（PSM的60MB+DVR的40MB+格式转换的nMB压力）的压力而无法实时预览；解决办法是让格式转换的临时文件放到RAID B组的vbm LUN里，而100MB的压力放到RAID A组的vbm LUN里。
c) 第三次的问题是视频转换机制问题，由于视频格式转换机制使用的是队列的形式，因此导致每次只能有一个视频进行格式转换（虽然会同时又多个并发过去，但是这里的格式转换必须一个排着一个，就像排队买车票一样，只有前面一个完成了后面一个才能完成），后来想多种办法都无法解决，最后的解决办法是不要视频格式转换，另外开发了一个很丑的C/S架构来查看某些特定的视频（真的很丑，我才会说的，那软件一来，我直接提了二十多个问题单上去）
d) 第四次的问题是软件架构存在问题：PSM写入VBM的步骤比较简单，直接从PSM服务器里写入到/vbm/data/1(这里采用的是多目录多层次的存放方法，命名采用随机的，下同)目录下，这个性能没问题；但是DVR写入VBM的步骤就存在软件架构方面的多次写入，第一次是DVR上的录像写入到VBM的tmp LUN(/vbm/tmp)目录中<对RAID组A已经产生了一个写压力>，第二次是从tmp LUN（/vbm/tmp）读出，然后写入到vbm LUN(/vbm/data/1)<对RAID组A产生了一个读压力和写压力>，第三次是从vbm
LUN(/vbm/data/1)读出，然后写入到vbm LUN(/vbm/data/process)目录中<对RAID组A产生了一个读压力和写压力>，第四次是从vbm
LUN(/vbm/data/process)读出，最后写入到vbm LUN(/vbm/data/1)目录中<因为DVR是其他厂家的与我们的PSM、VBM软件格式不一致所以要有这一步，增加了RAID组A的读压力和写压力>。一段1GB的视频数据，从开始到最后要经过5次写，4次读才能最终达到VBM中，如果要实时预览还要再进行一次格式转换，又是一次读和写，这就是软件架构设计的问题。解决方法是暂缓该软件的发布（一直暂缓到我们项目组整个搬迁到杭州，这个项目都没有发布过，明显胎死腹中了）。
8、 输出报告：每个版本的测试结束之后，都陆续出了性能测试报告（第一次写性能测试报告吧，我写的4个报告，前三个报告的格式都不一样，因为每写一次报告，我都觉得不够完美，就一直在修改，第三个报告是我自己觉得比较漂亮的一个模版，而且主管也喜欢，所以最终报告是以第三个报告的模版出的）。性能报告中罗列了项目背景、目的、性能指标、测试场景、环境需求、组网图、业务流程图、测试结果分析、遗留问题、测试过程中的数据附件<这些附件可是给专业人士看的，不专业的看看测试结果分析就可以了，哈哈>。
在接手了VBM项目的性能测试以后，后续还接了华为平安城市平台的性能测试（测试该项目，在项目组里分配了6个人跟踪测试，我负责的主要是故障诊断、图像检测两大模块的功能测试以及整个系统中需要测试性能地方进行整体的规划），具体操作方法就不详细述说了，毕竟做一次性能测试了解清楚所有的步骤，后续不管是做几次性能测试都可以按照这个步骤来做，在做的过程中可以不断进行过程优化，找到一个最适合自己的性能测试步骤。
性能测试总结：两次的性能测试实战让我体会到了工具仅仅是辅助，计算机的综合知识才是王道，记得当时分析性能瓶颈的时候，nmon工具中生成的很多子项都不知道是什么意思，都是一个个在百度上搜索，查询出来的。比如说wait%、IOPS、idle%、free、user、Read、Write、Rece、Trans等等。为了分析系统瓶颈，在工作期间学习了操作系统、网络原理、数据库系统原理、大话存储、TCP/IP协议详解、计算机系统结构、重新学习了鸟哥的私房菜、Loadrunner、Shell编程等知识。在做性能测试的时候，业务知识的熟悉程度是必须的，因为只有熟悉的流程了才能做出正确的性能测试场景，还需要的知识面还是很广的，没有足够的广度和深度，根本无法分析出系统瓶颈在哪里，最后一点很重要，就是要和开发多多交流，因为有些模块之间的调用是需要沟通才能知道那里会出现性能瓶颈。
零测试
