与以前使用性能工具和终端性能测试做的方式不同，自己亲自部署的性能环境对性能测试的理解，还有测试的经验以及对性能测试开发的一些功底都是一个考验，因为这次是从一行代码都没有到个人发布的第一版性能测试程序（用例）间解决很多难题，所以趁现在有空闲时间备忘下这次做偏网络性能测试的经历。
设计阶段的时候一定需要弄清楚这次性能测试的目的和要点。与用lr的web网页性能测试不同，我是测试更底层或者说是网络层的性能。与手工测试不同，做性能测试务必有需求，即使没有需求都需要组织会议来自己定制一套需求。在做性能测试的经验中，70%~80%是做和开发组相似的工作，所以没有需求的话，写着写着就会融入自己的主观误区，很容易写出来的东西根本不符合项目组的要求，尤其是做socket的编程。对于网络相关的测试，不用太过于关注一些平常web性能的指标，最重点关注是每秒的处理数，服务器的极限值，模拟真实的流程还有根据这些设置值来定制出一个产品的性能说明书。主要的设计参考为同类产品的对比，主流服务器的性能指标，还有产品的峰值。
部署性能测试开发阶段需要根据你的设计和项目组或你自身水平（实际项目由我个人弄）来评定需要那些东西来做开发活动。对于测试开发来说，偏应用的语言和脚本是相对好用的。大多情况下我会选择做常链接不错的java和资料充足的python脚本来制作测试开发，假如是有图形界面的话C++和java是比较好的选择。为什么我会重点提这3个语言，我经历过的自动化组虽然不是全部都用以上的语言，但是在google强大的开源帝国中提供了很多自动化测试框架和模块（例如安卓的java robotium，C++的GoogleTest，支持很多API和多个linux支持的python）本身就带有优势。重点在于这3个语言对oracle或其他数据库都有很好的交互，性能测试很少不和数据库打交道。其次也可以选择你很熟悉的语言做自动化。
开发环境搭建阶段，做测试核心之一的就是返回结果来对期望结果进行匹配，你获取结果的地方最多就是在服务器端，很多时候我们在windows开发，获取结果在linux服务器，所以搭建开发环境对编译器，对打包的工具，对一些项目组现有的工具，还有各自操作系统带有的小工具都要进行考量。必要时甚至可以用lr和QTP来辅助。同时要对项目的协议进行分析，解析包，把底层交互的接口都编写完整，当然项目组做了给你更加好。
程序设计阶段，好比做C++开发和数据库开发的理念不同，做测试开发也有着不同的理念。我们本身是测试代码，在我此次项目经历考量的最多就是操作系统，编译器，公司网络，本身语言对网络方面的性能和限制。我们做的不是安全防御，不是应用系统，最终目的是提出一个说明书和提交bug，所以我们需要知道我们执行程序发现的问题是产品问题还是上述问题，即使用lr测试也是如此。这里说下几个理论：我们的程序做到什么程度？平台化？程序化？脚本化？因为负责的只有我一个人，所以只做到脚本化。还有脚本的分布。因为我们是用例，而且大多是性能用例，不像别的功能用例自动一个个串行执行。所以在我选择了功能强大的语言时我的测试脚本分为应用层（执行用例的函数），特性层（linux，windows，数据库，网络编程的特性函数），忽略底层（因为语言已经封装很好） ，然后因为性能用例的特征做了一个选择的接口层（每次每台测试机只执行一个性能用例），然后根据用例的目的进行分类，测试模拟真实环境的性能指标用例，测试负载的峰值指标用例，测试压力的用例（分测试客户端用例和备用客户端用例，往往压力挂了，自主开发的主用例很难再去给压坏的服务器做判断）
测试的部署阶段，当你的用例第一版正式投入测试的时候，需要关注的是：你实现压力的方式，综合客户端和综合服务器的限制。例如lr这样的性能工具是怎么做到超越一般的并发数的，是靠巧妙的编程方式还是通过提供的服务器，在我自己弄整个过程，我大概也摸清了一小部分lr的底。除了评估出各方面性能所需要准备的测试机外，最重要是如何以最小的代价抓出最多的bug日志，打印日志算是一个影响机子性能的关键点。
总结：下一步不管网页相关的性能是由我做还是使用lr工具，最重要还是要提高代码的函数通用性，我经历的测试组的代码很多封装的惨不忍睹，因为很多测试人员测试时抽空出来写自动化用例不可能会像开发那么专心。其次是继续提升自己对操作系统，数据库和网络本身的一些基本配置问题要更加了解，我提交很多致命单往往都是很简单的东西造成的。最后要按需求走，每做一个改动和新增要知道自己测试和发现的是自己的程序性能问题，还是局域网络问题，或者是原生产品操作系统问题，排除完后提交bug。
小数据：总编写时间3~4个星期的脚本在一个迭代中发现了15个严重级别或以上的单。自己编写性能脚本效率在初中期开发其实不比lr差。