4. 配置测试

        配置测试方式是指在测试前、测试中、测试后三个时间段通过对被测系统的软件/硬件环境的调整，了解各个不同环境对系统性能影响的程度，从而找到系统各个资源的最优分配原则。它具备以下特点：

        （1） 该方法的目的是了解各个不同的因素对系统性能影响的程度、从而判断出最值得进行的调优操作。该方法不同于与“功能测试”中涉及到的“配置测试”。

        （2） 该方法存在很大的灵活性、可以在测试环节的各个时间进行、但是什么时候开始、什么时候暂停、什么时候结束才是运用这个方法的关键。同时也是HNDLZCGLXT考量性能测试服务供应商的关键。

    5. 并发测试

        该方法通过模拟用户的并发访问，测试多用户环境并发访问同一个应用、同一个模块或者数据记录时系统是否存在死锁或者其他性能问题。该方法特点是：

        （1） 可以发现应用系统的全局性性能问题。

        （2） 该方法可以在开发工作的各个环节使用可以使用多个工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。

        （3） 并发测试一般关注的问题是：

    6. 可靠性测试

        这里说的“可靠性测试”并不等同于“获得软件的可靠性”，软件的可靠性是一个很大的命题，这里指的可靠性测试是通过给系统加载一定的业务压力（例如：资源在80%~90%的使用率），让应用系统运行一段时间、测试系统是否稳定运行。这里有三点需要注意：

        （1） 在使用该测试前需要目的系统的资源使用率已经达到70%~90%。即在这样的苛刻环境下运行该应用系统。

        （2） 应用系统运行起来后，加载业务压力使应用系统资源达到90%。比如：该J2EE系统中设置的JDBC数据库连接池定义为30，那么加载业务压力使连接达到27。

        （3） 应用系统运行起来后结合业务情况来设定一个运行时间。比如：电力资产系统要求MTBF（平均无故障时间）达到10000小时、那么我们可以认定该系统的运行时间至少需要达到三年重新启动一次。超过这个数字我们就可以认为“不可靠”。一般情况下对于这个要求、我们让J2EE系统在资源使用率90%~100%状态连续稳定的运行3天左右没有错误就可以认定该MTBF指标已经达到。

    7. 失效恢复测试

        该方法是针对有HACMP等冗余备份和Edge Server for LB等负载均衡的J2EE系统设计的。该方法考量系统失效恢复的时间、用户受到多大程度、多大范围的影响，并将其量化。该方法有以下特点：

        （1） 一般的关键业务都会采用双机热备或负载均衡方式来实现。

        （2） 该方法回答两个问题：当问题发生的时候“能支持多少用户访问”，“有多少功能不能使用”

        （3） 需要说明的是，对于HNDLZCGLXT的这个项目来说，负载均衡需要仔细考虑其实现方式，这影响到性能的调优。可以考虑使用F5等硬件技术方式、也可以考虑使用 IBM WebSphere Edge Server等商业版本的软件技术方式。否则单纯对EJB 容器Weblgoic Server作集群没有意义。

    性能测试分析方法

        该部分着重于PTGM方法论

    1. 能力验证

        能力验证一般采用这样的描述：“该系统是否能在A条件下具备B能力？”。这里强调以下内容：

        （1） 充分准备以下内容：硬件设备、软件环境、网络条件、基础数据

        （2） 充分准备测试场景、典型的场景包括操作序列、并发用户数量条件、用例。

        该部分包括使用到上述测试方法：性能测试方法、可靠性测试、压力测试、失效恢复测试

    2. 规划性能

        该分析方法关心的是“应该如何才能使系统具有我们要求的性能能力”，“应该如何调整系统配置，使系统能够满足增长的用户数的需要”等问题。这个部分常常使用到的测试方法是：负载测试、配置测试、压力测试。

    3. 性能调优

        一个标准的性能调优过程是：

        （1） 确定基准环境、基准负载和基准性能指标。

        （2） 调整系统运行环境和实现方法，执行测试。

        （3） 记录测试结果、进行分析

        在J2EE性能测试中有很多常见的错误，比如：对于某些建立在J2EE/EJB技术上的应用，在服务启动的时候，没有注意到测试之前首先进行一段时间的预热。这是因为JAVA语言的hot-spot技术特性决定的，这种技术允许weblogic第一次运行应用的时候将字节码编译为本地代码并执行，这样在后续的执行过程中执行过程会大大加快，但第一次由于存在一个编译过程会比较慢。如果使用这个时间来作为基准那么就容易得出错误的结论。

        我对第2个过程比较擅长、具体下来包括硬件环境的调优、Weblogic调优、Oracle调优。这个过程中也是使用工具最多的测试环节。

    4. 发现缺陷

        这个环节中是交付给用户的主要工作成果。需要多和开发人员作沟通、多次迭代发现问题、根据用户的需求定义与缺陷的涉及范围、制定一个解决缺陷的优先级。由于软件永远有BUG这一真理，所以发现缺陷不是一次就能结束的工作。比较适合作为服务外包。持续进行。

    性能测试文档

        以下作为我对性能测试完整内容的建议，表格模板不作赘述

    1. 《性能测试成员职责技能描述表》

    2. 《性能测试工具需求规划表》

    3. 《性能测试环境调查表》

    4. 《典型业务逻辑列表》

    5. 《业务用例描述表》

    6. 《测试场景列表》

    7. 《测试计划》

    8. 《测试环境检查表》

    9. 《测试执行记录日志》

    10. 《性能测试分析报告》