织雀教育性能测试规划建议书.docx

性能测试规划建议书
想获取更多测试资料，请访问织雀教育官网。
性能测试的几个术语
1. 响应时间
我把“响应时间”的概念确定为“对请求作出响应所需要的时间”，把响应时间作`为用户视角的软件性能的主要体现。响应时间划分为“呈现时间”和“系统响应时间”两个部分。
其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间、而“响应时间”指J2EE应用服务器从请求发出开始到客户端接受到数据所消耗的时间。性能测试一般不关注“呈现时间”，因为呈现时间很大程度上取决于客户端的表现。在这里我们没有使用很多性能测试定义中的概念——“系统响应时间”定义为“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”，没有使用这种标准的原因是，可以使用一些编程技巧在数据尚未完全接收完成时进行呈现来减少用户感受到的响应时间，对于HNDLZCGLXT的这个项目中，我们针对C/S系统采用前者标准，对于B/S我们依然采用后一种标准。
2. 并发用户数
我把“并发用户数”与“同时在线数”进行区别对待，我的“并发用户数”的标准是：并发用户数取决于测试对象的目标业务场景，因此，在确定这个“并发用户数”前，必须（必要）先对用户的业务进行分解、分析出典型的业务场景（也就是用户最常使用、最关注的业务操作），然后基于场景采用某些方法（有多种计算并发用户数的数学模型与公式）获得“并发用户数”。
这样做的原因是：假设一个应用系统、最高峰有500人同时在线、但这500人却不是并发用户数、因为假设在一个时间点上、有50%的人在填写复杂的表格（填写表格动作对服务器没有任何负担、只有在“提交”动作的时候才会对服务器系统构成压力）、有40%的人在不停的从一个页面跳转到另外一个页面（不停发出请求与回应、产生服务器压力）、还有10%的人挂在线上，没有任何操作在发呆：）（没有对服务器构成压力的动作）。因此只有那40%的人真正对服务器产生了压力，从这里例子可以看出、并发用户数关心的是不但是业务并发用户数、还取决于业务逻辑、业务场景。因此我们需要本文第六部分性能测试文档4、5、6。
3. 吞吐量
我把吞吐量定义为“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力，对于交互式应用系统来说、吞吐量反映的是服务器承受的压力、在容量规划的测试中、吞吐量是一个重要指标、它不但反映在中间件、数据库上、更加体现在硬件上。我们在以下方面利用这个指标：
（1） 用来协助设计性能测试场景，衡量性能测试是否达到了预计的设计目标、比如J2EE应用系统的连接池、数据库事务发生频率、事务发生次数。
（2） 用来协助分析性能瓶颈、参照本文第二部分总的RBI方法。
4. 性能计数器
性能计数器式描述服务器或操作系统性能的一些数据指标、例如对WINDOWS来说使用内存数、CPU使用率、进程时间等都是常见的计数器。
对于性能计数器这个指标来说、需要考虑到的不但有硬件计数器、web服务器计数器、Weblogic服务器计数器、Servlet性能计数器、EJB2的性能计数器、JSF性能计数器、JMS性能计数器。找到这些指标是使用性能计数器的第一步、关键是找到性能瓶颈、确定系统阀值、提供优化建议才是性能计数器使用的关键。性能计数器复杂而繁多、与代码上下文环境、系统配置情况、系统架构、开发方式、使用到的规范实现、工具、类库版本都有紧密的联系、在此不作赘述。
5. 思考时间
我把思考时间确定为“休眠时间”。从业务系统的角度来说，这个时间指的是用户在惊醒操作时、每个请求之间的时间间隔、从自动化测试的角度来说、要真实的测试模拟用户操作、就必须在测试脚本中让各个操作之间等待一段时间、体现在脚本上就是在操作之间放置一个Think的函数，体现为脚本中两个请求语句之间的间隔时间、不同的测试工具提供了不同的函数或方法来实现思考时间、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。
性能测试方法论
1. SEI负载测试计划过程
目标：产生一个清晰、好理解、可验证的负载测试计划。
内容：关注6个区域：目标、用户、用例、生产环境、测试环境、测试场景。
工具：IBM、HP、OpenSource工具都支持。需有文档配合。
2. RBI方法
目标：快速识别性能瓶颈。
内容：重点测试“吞吐量”指标，因为RBI认定80%的系统性能瓶颈由吞吐量造成。按照网络、硬件、数据库、应用服务器、代码的顺序自上而下分析性能。
工具：IBM、HP、OpenSource工具都支持。需使用分析模块、根据Weblogic、Oracle区别有专门的工具实现RBI。
3. 性能下降曲线分析法
目标：性能随着用户数的增加而出现下降趋势的曲线分析、查看性能下降的环境点与上下文。确定性能阀值。
内容：通过单用户区域、性能平坦区域、压力区域、性能拐点进行监控和分析。
工具：IBM、HP、OpenSource工具都支持。IBM报表功能更强。
4. HP（LoadRuner）性能分析法
特点：侧重于该厂商的性能分析方法、主要体现在需求收集、VU脚本。
缺点：没有对测试计划阶段、测试设计阶段的具体行为、方法、目的进行描述,方法局限于LoadRuner产品的特性上,不能通用。
5. IBM（Rational UP）软件测试方法
特点：软件产品生命周期RUP的实现、侧重于迭代测试、宽广的方法论。可适合任意测试环境及方法、工具。
缺点：需要根据测试环境进行剪裁、难以掌握、但掌握后非常成熟、高品质工具：涉及到IBM Rational 测试环境的所有软件、功能强大。
6. PTGM性能测试模型
内容：一个非常适合行业用户（电力、金融、政务、制造）的性能测试过程模型。规范化的测试模型、每个环节都做到迭代测试、每一个过程的工作产品明显可察、测试流程、测试上下文方面很优秀。包括以下环节：前期准备、工具引入、测试计划、测试设计与开发、测试执行与管理、测试分析。
工具：可以使用任意商业工具全新部署测试流程、不限于任何厂商工具的局限、也可以使用部分工具即可完成整个流程、或结合自己需要基于OpenSource工具进行定制。个人倾向使用多个产品的整合、综合使用、扬长避短。
性能测试方法
1. 性能测试
性能测试方法通过模拟生产运行的业务压力量和使用场景组合测试性能是否能够满足需要。具备三个特点：
（1） 这种方法的目的是验证系统是否具有系统宣称具有的能力。
（2） 这种方法需要事先了解被测试系统典型场景、并确定性能目标。
（3） 这种方法要求在已确定的环境下运行
使用IBM Rational Performance Tester、HP Mercury LoadRuner、OpenSTA、Apache ab、Jmeter、QALoad 、TagUnit、Java Test Runner。
2. 负载测试
负载测试用来测定系统饱和状态、确定阀值。其特点有
（1） 这种方法的目的是找到系统处理能力的极限；通过“检测、加压、阀值”手段找到如“响应时间不超过10秒”，“服务器平均CPU利用率低于65%”等指标。
（2） 这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景、另外HP Mercury LoadRuner在使用该方法进行“加压”的时候必须选择典型场景。
（3） 这种性能测试方法一般用来了解系统的性能容量，或者是配合性能调优的时候来使用。特别是该项目的Weblogic Server和Oracle数据库的性能调优。
3. 压力测试

压力测试方法测试目标系统在一定饱和状态下，例如CPU、内存等在饱和状态下、系统能够处理的session的能力，以及系统是否会出现错误。该方法需要在系统cache调优与pool优化方面着手。该方法具备以下特点：
（1） 该方法的目的是检查系统处于压力情况下的，应用的表现。如增加VU数量、节点数量、并发用户数量等使应用系统的资源使用保持一定的水平，这种方法的主要目的是检验此时的应用表现，重点在于有无错误信息产生，系统对应用的响应时间等。
（2） 该方法通过模拟负载在实现压力。这种模拟需要考虑的层面很多、首先、模拟必须是有效的，我的经验是需要结合业务系统和软件架构来定制模拟指标、我测试过一些国内生产的压力测试工具、他们使用通用的指标来考量、造成很多信息反馈有很大的水分。需要考虑的层面如：Oracle I/O、JVM GC、Conn Pool等。
（3） 该方法还可以测试系统的稳定性。这里的技巧在于“什么样的平台定义一个多长的压力测试时间让其稳定运行才是科学的？”
4. 配置测试
配置测试方式是指在测试前、测试中、测试后三个时间段通过对被测系统的软件/硬件环境的调整，了解各个不同环境对系统性能影响的程度，从而找到系统各个资源的最优分配原则。它具备以下特点：
（1） 该方法的目的是了解各个不同的因素对系统性能影响的程度、从而判断出最值得进行的调优操作。该方法不同于与“功能测试”中涉及到的“配置测试”。
（2） 该方法存在很大的灵活性、可以在测试环节的各个时间进行、但是什么时候开始、什么时候暂停、什么时候结束才是运用这个方法的关键。同时也是HNDLZCGLXT考量性能测试服务供应商的关键。
5. 并发测试
该方法通过模拟用户的并发访问，测试多用户环境并发访问同一个应用、同一个模块或者数据记录时系统是否存在死锁或者其他性能问题。该方法特点是：
（1） 可以发现应用系统的全局性性能问题。
2） 该方法可以在开发工作的各个环节使用可以使用多个工具的配合。如：Compuware公司的DevPartner工具、EJ-Technologie公司的J Profile工具，QUEST公司的J Probe工具等。
（3） 并发测试一般关注的问题是：
问 题 类 别 问 题 描 述
内存问题 是否有内存泄露（COM+，JAVA）
是否有太多的临时对象（JAVA）
是否有太多不合理声明的超过设计生命周期的对象
数据库问题 是否有数据库死锁
是否经常出现长事务
线程/进程问题 是否出现线程/进程同步失败
其他问题 是否出现资源争用导致的死锁
是否没有正确处理异常（如超时）导致的系统死锁
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. 《性能测试分析报告》