性能测试高级工程师培训总结

 在做性能测试的时候，发现自己原来写的有些东西还是有参考价值的，特共享给大家。 

1.1.1.      培训时间、地点

时间：2008-3-19日至2008-3-23日，共5天，每天上课时间：900－12：30  1：30-5：30 。

地点：海淀区企业培训中心 ，北京市海淀区中关村南大街3号海淀科技大厦5层。

1.1.2.      培训单位、人员构成

本次培训参与的单位有四川某国防物理研究院、大唐、北大方正、大连东软、解放军某部队、海关总署信息中心、安徽软件测评中心、成都软件测评中心等16家单位。

这次培训人数共21人次（中间临时增加2人次）。大家总体水平相当，大部分人员从事性能测试有1－2年经验，除了个别学员对工具应用不熟练以外，大部分学员都已经熟练使用Loadrunner性能工具，主要问题在于故障定位上面；大家共同有一个概念就是：软件越来越复杂、测试越来越难、问题越来越难定位。

1.1.3.      培训内容

培训时间

培训内容

2008-3-19

软件测试管理

（关于测试的基本流程、软件生存周期各阶段的测试管理。包括QC测试管理工具的使用。）

2008-3-20

软件性能测试基本理论和loadrunner的使用。

（介绍各种性能测试类型和性能测试策略。）

2008-3-21

数据库的基本理论、Oracle数据的优化和loadrunner的高级应用。

2008-3-22

J2EE系统的性能测试

（J2EE系统架构介绍和常用的J2EE架构测试工具介绍和应用。）

2008-3-23

软件性能测试案例剖析、测试经验交流、测评培训考试。

1.2.    培训收获和感受

通过这次培训，总体感受有如下几点：（下面简要描述，详细内容会在“问题和建议方案”中说明）

1，  老师的理论和实际应用水平相当高，测试工作的流程很清晰，测试什么，怎么测试一清二楚 。

2，  软件测试工作是一个系统工程，每一种测试类型都可以划分测试需求分析、测试计划、测试执行、缺陷管理几个阶段，为此，我们需要有一套合乎自己的测试流程，按部就班，绝对不能随意浮躁。

3，  测试过程中，测试人员心中一定要有一根弦，时刻想到软件的质量、项目的进度、项目的成本、测试的风险。

4，  性能测试是软件测试的一种，同样有软件测试的几个阶段，在性能测试过程中，我们一定要在测试之前，对系统有个很好的分析，充分和用户、开发人员、实施人员沟通性能低下的有关症状，不要测试一开始就对系统加压，导致事倍功半，性能测试分析重于测试过程。

5，  通过这次培训，个人掌握了一些常用的软件性能测试工具，测试工具对于初学者来说，是相当有用的，能够很好的辅助测试人员诊断系统问题的大致方向。尤其是oracle的性能监控，不需要测试人员编写大量的SQL脚本。本次培训也对loadrunner的高级应用有了较好的掌握，如：关联技术和web组件分析。

1.3.    问题和建议方案

通过这次培训，也认识到公司测试工作中存在的一系列问题，主要如下（因为个人水平等原因，中间表述不当之处，恳请谅解）：

1.3.1.      测试工作流程不清晰

“测试工作流程不清晰”大家可能已经意识到这个问题，但是个人认为有必要去强调。目前往往系统一上来，直接进入测试执行阶段，测试工作阶段不明确，在前期的测试需求分析、测试计划的设计工作上下的功夫不够，没有很好的执行测试需求分析＝》测试计划＝》测试执行＝》缺陷管理这样一个过程。这样将导致测试会出现遗漏和过多的反复。该测试的地方没有测试到，而部分模块可能反复无意义的测试。

对于这个问题：

1，  目前部门领导要求测试人员在TestDirector上编写测试用例，保证测试覆盖率。

2，  建议经常性的对测试人员灌输测试阶段、测试流程意识，减少测试工作的随意性。

3，  建立阶段性检查机制，对于阶段性检查不通过的，不能进入下阶段工作，否则上阶段存在的问题会带入下阶段。

1.3.2.      测试需求与测试计划阶段要加强

上面提到了测试流程不清晰的问题，主要还是体现在测试前期工作没有得到重视，测试人员对测试需求与测试计划阶段工作做得不好，测试人员对需求的可测性、测试点把握不够，不知道系统预期要是个什么样子，一旦系统原型出来了以后，测试人员容易被系统所限制住，没有去从用户的角度思考问题；在做测试计划的时候，没有从项目的进度、质量、成本、风险的全局去考虑，往往只关注测试的时间点，没有去考虑测试的重点、测试的目的、测试结束的准则、测试的技术难点在哪里、具体的测试策略、每个测试阶段应该关注哪些内容？在培训期间，老师多次讲述了一个概念，就是测试需求和测试计划的成败决定了整个测试工作的成败。

对于这个问题，建议：

1，  加强对测试需求分析、测试计划编写的培训工作，选取有经验的测试人员对个别系统进行测试需求分析、测试计划讲解，提高测试人员的测试需求分析能力、测试计划编写能力；

2，  执行测试需求、测试计划的评审制度。

3，  要求测试人员严格按照测试作业指导书执行；

1.3.3.      测试人员定位不够明确

因为公司目前采用的是项目跟踪制，基本上是一个项目一个测试人员进行跟踪测试。这样，一个测试人员需要完成一个项目的测试需求、测试计划、测试执行、缺陷管理整个过程，实际上，这有不合理的地方。测试的前期工作是需要测试设计人员来做，后期工作是测试执行人员来做的。因为前期的测试设计工作需要有较高的分析能力，目前公司部分测试人员的水平是达不到的，如果水平较低的测试人员去做测试分析，势必影响了后面的测试执行，这样存在一个人员定位不明确的问题。

针对这个问题，个人建议：

1，  在相同人力资源的情况下，多个测试人员交叉测试一个项目，能力强的，做测试分析和计划工作，能力弱的做测试执行工作，相互检查和监督。就像多个程序员可以开发一套系统，多个测试员同样可以测试一个系统。

2，  尝试采用测试项目管理制度，把测试当作一个项目来管理，保证测试人员角色明确。

3，  测试人员能力提升、团队建设是当务之急。

1.3.4.      加强oracle方面的学习

在培训过程中，老师列举了大量的性能测试案例，有一大半是数据库上面出现了问题。特别是oracle数据库出现了性能瓶颈，大部分是开发人员在SQL编写的时候没有考虑周到。

    对于这个问题：

    1，除了加强oracle数据库的学习，没有别的办法；

1.4.    测试经验共享

通过课时和老师的互动，以及个人平时的经验，下面我对怎么做好性能测试做了一些经验共享：

1，  做性能测试之前，务必多了解客户要求的性能指标，找出系统的性能测试点。做性能测试需求时，一定要尽可能考虑最坏的情况。如分析出某个系统的“最大访问量日”后，还得分析出“最大访问量日”那天的高峰期。

2，  性能测试的主要策略有三个步骤（根据系统情况选择下面的几个步骤）：

A：模拟试验室环境，主要保证录制测试脚本的正确性；主要功能的正确性；录制出符合用户业务流程、访问习惯的脚本，因为一到了后面执行测试时，脚本录制往往就没有时间了。

B：上线前的机房环境，主要是避开网络的影响，找出系统的最优配置。

C：试运行环境，需要把网络的因素考虑进去，把防火墙、交换机等设备加上。同时需要考虑别的系统接口的性能，做联合调试和调优。

3，  在执行性能测试之前，先需要对系统的配置进行检查，包括硬件和软件，对于不合理的配置，需要先做调优以后再测试，否则对于性能本身很低下、系统配置不合理的系统，测试就失去意义。

4，  在用测试工具做性能测试时，先务必保证脚本的正确性，该做参数化处理的地方需要做参数化处理，对于服务器返回来的变量（如：sessionID）该做关联的做关联，脚本的正确性是后面测试成功的基础。

5，  对于不停机的系统，一定要做疲劳强度的测试，测试的重点一般主要在内存泄漏上。

6，  对于分布式部署系统的性能调优，先得确定问题的大方向，如：问题是出现在web服务器、还是应用服务器、还是数据库服务器，问题一层一层的排除。在确定了某一层以后，然后看是否是系统资源的问题，还是系统配置的问题，逐步深入找到瓶颈。

7，  在测试时，一定要考虑基数数据对系统性能的影响，数据库中有1万条记录和有100万条记录的性能肯定是不同的。在准备性能测试数据时，和功能测试的情况差不多，要分不同的数据类型、不同的数据大小（如：附件上传和下载）、不同的交易类型来准备，以保证最大限度的模拟实际情况。

8，  系统调优的重点：

    A：数据库方面：主要是数据库内存配置、SQL优化、SQL事件跟踪。SQL优化是先优化语法，在优化业务方面。大的数据表不要放到一个表/磁盘中，该分区就分区。部分表根据情况适当的建立索引。对于大数据量的历史数据表，该建立离线数据库的建立离线数据库。

    B：系统资源方面：一般还是从大方面入手，CPU利用率、可用物理内存、磁盘处理时间，只有大的方面有问题，才去跟踪下去。

    C：web服务器上面：主要是JVM的配置情况、线程池、数据库连接池的配置。

    D：网络：带宽和吞吐情况；

    E：应用程序：主要看事务处理时间，看大部分事务处理是否分布在平均事务处理时间附近。其他得问题则A-D入手。对于具体得类/方法处理效率可以通过BCI技术（字节码插入）跟踪，其他的就是系统设计的问题。

9，  性能测试需要重点关注几个指标：

A：并发用户数：反应的是用户容量；

B：平均响应时间：反应的是系统的服务等级（参照微软的：3-5-8原则）；

C：交易吞吐量：系统每秒处理的能力；

10，              最后一点，也是最重要的一点：性能测试的大忌就是急躁，对测试结果需要仔细的分析，找出相应的原因。