在做性能测试的时候,发现自己原来写的有些东西还是有参考价值的,特共享给大家。
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 | |
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, 最后一点,也是最重要的一点:性能测试的大忌就是急躁,对测试结果需要仔细的分析,找出相应的原因。