为了保证系统的稳定上线，功能测试是一个不可缺少的环节。但在所有功能点测试通过后，系统就能稳定的运行吗？答案是否认的。因为系统上线后不但需要满足用户功能点的使用要求，同时也需要满足大量用户的并发使用请求。这些请求包含了各种的业务逻辑，各种的功能使用的场景。可能一个小小的循环，又或者是一段简单代码都会导致系统异常，如：内出溢出，CPU资源100%，系统请求超时，应用服务崩溃等现象。

　　在问题暴露后，大多数问题都可以通过重启操作系统或者应用服务恢复系统。与此同时，用户的投诉也随之而来，频繁的投诉会使得用户的感知度下降，甚至会对开发商失去信心。这样的问题究竟是谁的错误呢？是测试的没测试出来？是开发人员编码问题？设计师的设计问题？

　　要百分百避免系统出现异常的问题，是一件极其困难的事情，也不是单方面的努力可以达到。退而求之，如何减少系统出现异常的次数呢？提高系统的稳定性呢？

　　加强系统测试是一个最直接而有效的方法，如何提高测试的质量则成为一个不可忽视的问题，以下将讨论下如何提高我们的测试质量与从测试过程中如何寻找出系统隐藏的问题点。

　　功能测试：

　　1、单元测试报告，单元测试报告让开发人员对自己开发的功能进行一次测试，减少一些基本错误。也可以减轻测试人员的负担，毕竟测试是一个很枯燥的过程。

　　2、测试方法规范化，让测试人员和需求人员根据业务情况制定测试方法，文档化的测试方法，让开发人员也悉知这些测试方法，加强测试人员与开发人员之间的沟通，让测试方法更加完善，进一步提高测试的质量。

　　3、录制功能测试脚本，进行自动化测试，减轻测试人员的负担。可考虑一些持续集成工具，如CruiseControl进行自动测试，不过这里对测试人员与开发人员都有一定要求。

　　压力测试：

　　根据系统业务功能点，与实际系统使用情况，通过压力测试工具，如LoadRunner、Rational Performance Tester压力测试工具都可录制测试脚本，模拟实际生产环境，对系统进行各种场景的测试，测试每个功能点的性能情况。通过组合测试，模拟实际生产使用情况，对系统进行全面的压力测试。

　　在压力测试过程中寻找系统的性能问题或者一些隐藏的Bug(这里建议压力测试环境尽量保持和生产环境一致，避免系统环境不一样导致测试结果出现偏差)。

　　压力测试情况下，我们可以采集以下数据进行性能分析:

• 　　Cpu，在压力测试情况下，每台服务器的Cpu使用情况，包括应用服务器与数据库服务器
• 　　内存，在压力测试情况下，每台服务器的内存使用情况，包括应用服务器与数据库服务器
• 　　吞吐率，每秒完成事务数
• 　　完成事务数
• 　　事务响应时间
• 　　事务出错率

　　这些数据可以直接说明系统现在的一个性能情况，可是并不能帮助我们找个系统所隐藏的系统的问题。

　　另外我们还需要加强监控手段进一步去发掘系统所隐藏的性能问题。依赖一些工具，监控组件进行分析：

　　Jwebap监控组件

　　分析应用程序各个功能点的实际运行情况，通过分析请求的执行时间频度寻找性能问题

　　Websphere监控，Websphere6.0以上版本都可在控制台中打开监控并记录系统运行情况，根据监控数据分析：

　　Jvm堆使用情况

　　实时通过监控，查看系统Jvm堆的使用情况，判断当前Jvm堆是否符合实际使用。如：系统运行时，Jvm堆不断增大，并且全局GC后，堆大小的变化不大。此时我们可以根据压力测试场景的情况判断，并且检查GC日志，同时手工生成Heapdump文件分析，确认堆里的对象使用是否合理，根据大对象集合，根据堆栈找到相应的业务代码，分析是否可以优化，或判断这里是否会在大并发下存在影响系统系统的问题点。

　　线程池情况

　　实时通过监控，查看系统线程池的资源分配与回收情况，判断当前线程池是否需要需要调整。当系统线程资源持续达到峰值时，我们可以手工生产根据Javacore进行分析，确认线程资源是否充分使用，如无则需要根据相应的程序堆栈进行分析与优化。

　　数据源连接池资源分配情况（如使用Websphere Application Server作为中间件，建议使用其自身的数据源,这样我们可以通过websphere监控功能查看连接的使用情况）

　　实时通过监控，查看连接池的资源分配与回收情况，分析程序获取连接的等待时间与连接平均的执行时间等数据，判断当前连接池是否需要需要调整，根据数据库监控与Jwebap监控，分析当前运行的Sql是否存在性能问题，后台数据库是否需要添加索引，调整数据库参数。

　　数据库报告（数据库是Oracle可通过Statspack,Awr的工具获取数据库运行情况报告.DB2也有相关的工具生产报告；下来就可以根据报告判断数据库是否需要优化，及其资源的使用情况。）

　　如：数据库是ORACLE。这可以分析报告中以下几项，寻找性能问题：

　　a)Top 5 Timed Events

　　b)Wait Events

　　c)SQL Statistics

　　手工生产javacore文件

　　使用Kill -3 pid或者wsadmin工具，手工生产Javacore文件。通过jca.jar工具分析当前Java进程中所有子线程运行情况。

　　1、检查当前系统GC次数，AF分配失败次数等信息

　　2、确认是否有阻塞线程，查看阻塞的线程的堆栈信息，判断问题点

　　3、确认正在运行的线程是在等待资源，还是在执行一些特殊操作，我们可以对这些线程进行分类。

　　4、确认所有线程池的线程的使用情况，进一步判断整个系统的运行情况。如：在大并发情况下，线程池分配了90个线程执行处理Web请求，在javacore中我们可以查看此时有多少个线程正在运行中，多少个线程在等待资源，根据线程堆栈判断线程的运行情况是否正常。
　　
　　手工生产Heapdump文件

　　可以在配置环境变量，或者在Websphere控制台配置环境参数，通过kill -3 pid 命令和wsadmin命令在系统运行时手工生存Heapdump文件，通过ha.jar工具分析heapdump文件。

　　i. 全局检查堆的使用率及目前堆的大小

　　ii.检查对象的大小

　　iii.分析排名前几位的大对象，可以通过堆栈信息得到具体对象使用情况，是那部分应用程序申请的资源，我们可根据该信息去分析业务代码，或者进行相应参数配置优化。

　　（Websphere内存溢出的Heapdump文件也可这样一步步分析，寻找溢出问题点）

　　Jwebap是纯Java应用，可以方便的部署于JDK14和以上，通过其监控的功能我们能更方便寻找系统的问题。

　　Http监控分析，时间阀值设置，平均时间，最长最小时间等等统计；

　　Jdbc执行监控，连接泄漏，Sql监控分析，帮助找出执行Sql的代码行数；

　　在压力测试前，将此组件引入应用中，然后在压力测试过程中，我们系统的资源情况配合Jwebap进行数据分析。

　　分析Http Traces中的Url请求，我们在这里查看所有访问系统的请求的执行情况。

　　1)查看执行状态：查看正在执行的请求的执行时间，通过时间的长短判断是否符合生产使用要求。如发现某请求执行时间过长，我们则可以根据Url推断出系统的功能点和动作。可根据Java进程ID，手工生成的Javacore文件，分析该请求的执行堆栈，分析请求正在执行什么操作或者等待什么资源。（可以在短时间周期内多次生成Javacore进行分析）

　　2)查看Http访问次数：访问频率高的Url，从应用程序角度再去分析该页面是否存在优化空间，是否可以使用Websphere高速缓存组件，进行页面缓存，或局部页面缓存，进一步优化性能，减轻系统压力。

　　3)查看Http执行时间：检查所有已执行完的请求的执行时间与次数，寻找一些执行时间长，访问次数少的Url，分析执行的时间是否合理，如不合理可以考虑进一步的优化。

　　分析Jdbc Traces的连接使用情况

　　1)查看所有未关闭的连接：查看未关闭的连接的执行时间与执行的sql，如执行过长，有可能出现资源争夺，数据库死锁，数据库异常的情况。因为我们需要根据实际情况进行分析。

　　执行时间长，执行Sql数不多，我们同样可以通过手工生成Javacore分析该运行程序的堆栈情况，应用程序在哪一步进行资源等待；同时也可到数据库端对数据库连接分析，查看数据库锁的使用情况；另外还可实时生成数据库报告查看数据库资源使用情况，确认问题点在哪，如何优化。

　　执行时间长，执行Sql数过多，则表明该请求主要的性能瓶颈出现Sql数上。在一次连接请求中执行上百或者更多的Sql，会使得性能大幅度下降。尤其在大并发请求下，更容易出现资源争夺情况，容易导致大多数请求都是在等待执行，占用系统的线程池资源，系统不得不分配更多资源管理这里请求，在资源分配超负荷后出现宕机，内存溢出等现象。因此我们在这里首要的优化任务就是减少Sql数；批量提交，修改Sql，更换业务实现方式都可以进一步帮助我们。

　　2)查看所有已关闭的连接：查看所有已管理的连接的执行时间与sql数，根据上面的分析思路检查这些顺利执行完毕的请求，性能是否合理，功能上是否存在优化的空间，是否会影响到其他功能点的使用。因为连接池的连接数是有限的，如果过多的连接执行时间过长，会导致系统资源紧张，从而降低系统的性能。

　　压力测试过程中，有了Jwebap组件的帮助，配合一些分析方法，我们可以更简便找到系统能够的隐藏的性能问题。根据执行时间频度配合堆栈的分析，可以让分析员更容易找到功能点的隐患。

　　另外在整个测试过程中，我们也不可忽视压力测试用例的定制，如何定制压力测试场景，如何模拟实际生产场景，都是相当重要的一个环节，一个完善的测试可以更协助让我们更容易查找出隐藏的问题，让系统在每次上线后都能运行的跟稳定。随着测试质量的提高，相信可以减少系统出异常的次数，从而提高用户的感知度。