测试对象：网上申报税系统（涉及到的货运发票模块、服务行业税控发票模块）
测试时间：2周
测试工具：loadrunner，spotlight for windows and for weblogic for oracle；
辅助工具：pl/sql、excel、Ue编辑器（主要用来造数据，编辑参数化的文件）；
涉及到的工作内容：
* 环境搭建（系统环境、测试压力工具环境、监控工具环境）;
* 录制脚本并且修改加强脚本；
* 参数化脚本，准备测试数据，（10000张发票数据量左右，货运发票模块、服务行业税控发票模块都准备）；
* 制定测试计划、设计测试案例和测试策略；
* 执行测试案例，并纪录各项测试的资源占用指标；
* 分析结果，写测试报告提交；
今天算是报告都提交完成了，两周的性能测试工具算是告一段落，抽空坐下来对自己的工作小节一下。目的在于回顾工作中遇到的一些问题，总结好的经验，看到不足地方，以便自己能不断提高，也欢迎同仁指点讨论。
1. 熟悉业务非常重要 性能测试和功能测试最大的不同就是，功能测试是按照树到枝遍历，倒要覆盖到，求得是通过。性能测试却是针对系统在时间和空间上的处理能力，具体体现在响应时间，处理容量（用户、数据等），所以性能测试不需要所有的点都测试，那那些点事一定要做性能测试的呢？这就要求你对系统业务非常熟悉，那些业务点是关键业务点，在实际的生产环境中哪些业务点是经常使用，需要处理大数据量的或者需要并发大量用户的；这些关键的业务点就是需要做性能测试的点，熟悉业务确定性能测试的业务点就会很明确，目标明确，就会知道高怎么下手业务点设计案例，录制脚本，针对关键点估算业务量准备测试数据的等等。
测试前我已经很熟悉这套系统的业务了，和主要的几个开发人员都在一起，所以在定关键测试业务点时非常明确，很快就定下测试业务点，然后去录制脚本了。
2、一定要很熟悉loadrunner，了解它的工作机制，录制脚本和完善脚本都是要围绕尽可能模拟真实的生产环境的情况，所以熟悉它对脚本的质量很有益处，脚本质量对测试本身的质量也是非常重要的。
这方面开始我可能还有些欠缺，比如开始对参数化设置select next row项和update ..项数据设置原理理解不到位，浪费了一些调试的时间，通过查资料具体的输出了一下参数数据算是了解了。
3、准备足够的数据 有些业务点是需要做大数据量测试的，数据量不够测试得到的结果就根本没有太大的意义了，尽可能模拟真实环境可能达到数据量极限。
4、负载测试机一定要有较好的性能配置，应为模拟大量用户需要消耗很大的资源，不要让本身测试机器就成为了瓶颈，经验值模拟一个用户大概消耗4m以内的内存资源，而且内存占用率最好不要超过 80%、最多不要超过85%，如果用户很多建议最好采用多个负载生成器均衡并发用户。在实际测试过程中我在一台pc机器上负载生成1000并发用户，结果这台负载生成机就已经运行很慢了，收集的测试的数据本身就不真实了。心里一定要牢牢记住，尽可能接近真实环境去模拟，让使测试环境尽肯能接近真实环境，得到的数据才能反映系统真实性能情况。
5、合理的设计测试案例 网上申报税系统有这样的业务特点，可能每天都会有用户在外网申报税务数据，某些天的某些时间段会突然爆发大量的用户并发，其它时间段可能就是总有用户申报，但每次的并发数不大；针对这样的情况，我设计了这样的测试案例，案例1：并发测试，200、400等阶梯上升用户数；记录结果到满足需求所能达到的极限用户数，案例2：大数量平分在长时间运行系统压入系统，每过一定时间加载一定用户和数据，长时间运行，记录结果；这两种情况基本符合实际环境的情况，所以测试的结果就更能评估系统的性能，从而发现问题。
6、通过调试反复的多次执行案例 性能测试是一个反复调试多次执行的过程，分析调试执行在分析，直到达到一个理想或者可接受的状态。为什么这么说呢，我在测试中遇到的，在压力测试并发录入发票信息这点上，很奇怪用户数超过20就失败的情况，通过spotlight监控weblogic得到的数据得知，weblogic执行线程出现严重的排队，已经发出红色警报了。于是赶紧去调试weblogic执行线程的参数配置，把初始线程数由25调高到40；然后执行，立马并发数就很快能上升到400 了，说明一个问题，weblogic初始线程数被初始应用和服务本身占据很多，所以需要调高，才能继续测试；还有就是oracle服务器也许要调优，根据服务器本身的硬件情况优化oracle参数，比如：sga设置为实际为内存的50%;pga为20%左右；share_pool_size一般设置为 25%内存；可能测试过程中还要不断的调试，这里这样说只是做个参考说明，要通过反复的执行测试案例并调试才能最后得到一个更好的测试报告。
7、熟悉关键参数指标的含义 事务平均响应时间、每秒事务数、成功率等，cpu平均使用率、内存平均占用mbytes、%disk time等等；明白这些参数具体反映出来的是什么意思，在什么范围内是属于正常的可接受的，这样当你得到测试的结果时分析数据会很有帮助，会指引你去调试或者告诉你瓶颈在什么环节。其实分析是比较难得一个环节，需要有很多方面的知识，而且需要你比较熟悉，要熟悉数据库、要熟悉weblogic、要熟悉服务器、熟悉操作系统、熟悉一定的程序；需要不断的积累，熟悉关键参数指标就是对这些方面的熟悉，积跬步致千里阿。
8、熟悉各种优秀的监控工具 测试的大都是java平台的系统比如我使用spotlight for windows and for weblogic for oracle等工具，监控图像化显示，会及时报警。这些工具的使用我还再进一步的熟悉当中，还有很多理解不到位的地方。
9、基本的程序功底也是必须的 非常熟悉LOADRUNNER工具等也许你只是一个好的自动化测试的执行操作人员，但却不能成为一个好的性能测试工程师；你必须熟悉一些基本的编程语言，比如C语言、JAVA、sql等；修改录制脚本时候根据实际情况运用一些程序脚本可以很好的收集执行效率的数据，比如测试FTP下载并发，收集响应时间，你可用C把执行的时间片按照自己设计的格式写到指定路径的LOG文件中，对接下来的分析大有好处的。
有个例子：我在测试一个并发大数据量压入税控发票时（基于j2ee的平台），当压到1千600多条数据时，出现很多java.lang.numberformateException:200等这样的错误；如果你了解java很快就知道这应该是数据格式类型转换等的问题；于是怀疑我参数化的参数文件中准备的参数是不是有错的地方，用ue打开察看，没有发现任何异常，和前面的数据一样，按理说不该出现这样的问题；怎么办，采用了这样一个办法，我去具体的jsp页面用 System.out.println("..."+数据+".........");把压入传递参数打出来，看看这一行和后面的参数又是那么差别，果然发现，每个参数的后面都多了一个" "空格；恍然大悟，赶紧使用ue打开把后面空格全部去掉，然后再次压入，一切ok。我想了下出现问题的原因，我是使用excel造的数据，因为excle 中使用一些函数批量的产生数据很方便，但是有个问题，就是这样产生的数据在拷贝到ue中就在末尾带一个空格了，不知为什么。但是这个空格在ue中看不出来，所以没能开始就发现。前面的1千多条是我用pl/sql从oracle中提取出来的，由于数据本身当时不够就需要自己想办法再造一些出来了。这个过程实际上用用到都是很基础简单的程序,不用什么都去找开发了，自己一样可以搞定。因为之前我一直做j2ee web开发，所以体会较深，对性能测试帮助还是非常大的。
由于做性能测试的经验尚浅，时间也不长，大都出自个人看法，也欢迎指正，补充。
