原文发表于2008-12-27 11:55:26
上回讲到在测试人员与开发人员“斗争”的泥淖中出现了一线曙光，看了这篇的题目千万不要误会我真是看医生去了，只是去做另外一项工作了。
还是测试，还是这个项目，不过战场还是不太一样：由“功能测试”改作“性能测试”了。或许有前辈会说怎么会让一个连功能测试都做得乱七八糟的毛头小子做性能测试这么神圣的事情呢？只能说大千世界无奇不有啊，其实现在应该也会有类似的人出现在类似的场合做类似的事情吧，所谓类似的人就是一个对于基本的功能测试都不熟悉的测试新手（或许是像我当时一样有了半年的草根测龄的测手，甚至就是一个刚进公司刚接触测试什么都不会的新手），所谓类似的事情就是比较麻烦的如性能测试之类的测试活儿，所谓类似的场合就是（头儿自己都不知道测试为何物，或者知道一点皮毛然后就按照自己的理解交代给测试人员“测试工作”）。我相信，类似的情况在目前的中国小软件作坊里面大有“况”在。
我呢，反正就一毛头小子又是“一人吃饱全家不饿”的类型，也就不怕什么难不难，反正想着“组织这么信任我，我一定不能让组织失望”再加上初生牛犊不怕虎的豪气，竟然乐呵呵地接受了任务。
现在想起这件事，真有点佩服当时的自己，虽然整个过程跌跌撞撞，但是那一段时间学到了不少东西——
在接受了任务之后，我立马开始Google性能测试，一不小心直接Google到性能测试定义以及性能测试计数器上面去了，然后在性能测试是什么上面纠结了几天的时间，可是事情不能没有进展报告啊，于是乎我凑了一份性能测试相关的资料作为进度报告挡了一阵子。说实话，当时虽然看了好多天，但是一直没有搞清楚性能测试是怎么回事，但是项目进度要紧，只能硬上弓，直接拿VSTS来试，幸亏是一个简单的Web页面操作，更幸亏微软的VSTS还不错（当然比较起专业的如LoadRunner来讲，VSTS中的Web测试工具录制的脚本的效率并不高也显得啰嗦），我刷刷刷地录制了一份脚本。接着还是靠着VSTS自身的负载测试工具照着我心目中想的样子“性能测试”。
结果怎么样呢？“一个停摆的钟一天中也有两次是正确的”，这次还真让我碰上了，我竟然奇迹般的发现了一个性能节点。别嫉妒我运气这么好，要怪就怪那个性能节点太明显了，是一个并发测试很容易发现的问题：开发人员在设计的时候给每个用户开了一个监听器，这样导致了服务器端的内存CPU占用率狂飙不止。其实我是通过查看“任务管理器”看出来的，压根没管什么性能计数器，当时那水平看不懂这些啊。
性能节点找出来了，这次性能测试的目标在大家看来也达到了，可是事情还没有完。还缺一份测试报告啊。
没想到自己第一次整测试报告就直接整一性能测试报告。一开始还是老方法，先到网络上找性能测试报告的模板，然后东拼西凑整到一块儿。提交上去的报告很快被打回来了，原因是与项目有关的数据没有。
马不停蹄的赶制了第二份报告，在第一份报告中加入了项目数据表格，罗列了一大堆我自己都看不懂的数据到报告中，一时间报告看起来漂亮多了，也貌似有点专业的味道了。于是信心满满地提交了第二份测试报告，这次拿到的回复是：报告很详细，但是报告中不必要的套话太多，报告中表格过多而没有图表，不利于数据的分析。
再改。删掉了在网络上找的大部分资料，将表格全部替换为图表的形式，十几页的报告一下子改成了六页的报告，看起来清楚多了，这回终于等到了我想要的回复了：这份报告目前来看可以了。
报告通过了，我的使命终于完成了。虽然在现在看来，我当时做的算得上乱七八糟了，而且报告很不专业，也不合理，但是在当时看来，已经是非常高兴的事情了，毕竟我又完成了一件从来没有完成过的事情，而且在这一过程中我又学到了很多新的东西。成长其实就是这个样子，磕磕碰碰，这些都是成长所必需的。
