微信号:grzlwx

介绍:光荣之路官方资讯

软件测试之性能测试:大促带来的灾难 (续)

2015-09-22 08:36 光荣之路


执行测试:

执行测试从测试用例的实现开始,包括测试脚本和测试数据集的开发、测试执行、测试过程中的系统监视、收集测试结果、分析测试等。

性能测试的特点决定了性能测试的执行与其他类型测试相比要复杂得多。性能测试执行过程中至少要监视待测系统各方面的运行状况,所以性能监视技术是性能测试人员必备的技能。

一个明确的测试执行清单有助于测试执行过程的规范化,且测试执行清单应该像测试脚本和数据一样被实时和定期维护。

与功能测试不同,性能测试结果如果不满足通过标准不一定是应用系统本身的缺陷,因此,执行测试用例得到的结果需要进行分析。

执行测试的步骤:

  1. 熟悉测试计划与测试用例:由于性能测试的复杂性,反复阅读测试计划中队测试方法和测试用例直至彻底理解是开始执行测试的前提。

  2. 搭建或检验测试客户端:性能测试的运行通常需要依赖于一定的自动化测试工具或框架,测试工具通常运行在测试客户端的计算机上,并检验客户端的相关配置是否满足要求。

  3. 搭建或检验测试服务器环境:待测系统的软/硬件配置及正常工作状态时得到有效测试结果的前提。

  4. 设置调优参数:不要因为片面追求调优带来的好的性能而掩盖了应用程序代码本身的性能问题,因此,参数调优应该只作为一种必要的辅助手段。

  5. 编写或校验测试脚本和数据:测试脚本的执行需要配合测试所需要的数据。

  6. 预热执行及逐步增加并发用户负载:预热执行还可以弥补自动测试数据生成工具的不足。对于大并发用户数下的压力测试一般不采用将大量并发用户同时开始的方法,而是采用从少到多逐步增加的方式。

  7. 配置监视工具:在测试执行清单中应该对各种类型的测试需要对监视工具做何种配置有明确规定。

  8. 执行测试:定期通过监视工具检查服务器和测试客户端的运行状态,同时注意监视工具的开销。

  9. 收集、分析测试结果并整理测试报告:不论测试是否通过,都应该按照测试执行清单的要求收集各种结果信息。收集测试失败的日志反而对于分析解决问题至关重要。

--->测试系统的性能监视一般有性能测试人员或开发人员进行。测试系统的系统运行时间短而压力大。

--->生产系统的性能监视一般由系统维护人员进行。系统长时间运行,出现性能问题的可能性较小,但一旦出问题,产生的影响大。

以上两种系统上进行性能监视的目的都是为了尽早地发现性能问题。

性能监视一般采取从前到后的监视顺序。监视系统的性能运行指标,在测试环境中一般通过测试工具进行。找到问题出现的时间点往往很重要,因为系统日志很多时候是先从引起问题的根源处开始记录出错的。

一般来说,基于应用服务器的系统一般需要做以下几个级别的监视:操作系统级别,数据库级别,应用服务器级别

操作系统的监视

监视各种系统资源的使用状况:CPU占用情况,内存占用情况,I/O使用情况

--->当系统性能出现瓶颈时,查看系统的I/O情况也是确定问题的重要手段。

数据库的监视

使用DB2快照监视其时,一个典型的过程如下:

  a. 首先查看数据库监视对象开关状态

1

db2 GET MONITOR SWITCHES

  b. 查看数据库管理系统监视对象开关状态的命令

1

db2 GET DBM MONITOR SWITCHES

  c. 打开指定的数据库监视对象开关的命令

1

db2 Update MONITOR SWITCHES USING switch-name ON/OFF

  可以一次打开一个或多个开关

1

db2 Update MONITOR SWITCHES USING LOCK ON BUFFERPOOL ON

  d. 再执行

1

db2 GET MONITOR SWITCHES

  此时,会发现缓冲池监视开关和锁的监视已经打开了

  e. 执行命令

1

db2 GET SNAPSHOT

---> 数据库上发生死锁是并发访问时很常见的问题,尤其是压力测试用例这种比较极端的用例。因此监视死锁也是对数据库监视很重要的一部分。

有时候没有出现死锁问题,而仅仅是怀疑某些操作使用的SQL语句不合理,因此可以监视特定操作使用的SQL语句。

性能问题定位的一般策略

确定性能问题一般有自顶向下分析和自底向上分析法。

自顶向下分析:指将应用系统划分为若干部分,采用排除法或归谬法首先确定问题出现的位置,然后再这个部分寻求问题的原因和解决方案。自顶向下分析在 确定问题属于哪一部分的时候,往往采取一种逐渐细分的方法,从比较粗的定位到非常细的功能模块划分,它分析重视文体产生的条件,即出现问题之前和出现问题 之后的不同,通过对产生问题条件的归谬确定存在问题的部分。

自底向上分析方法注重问题的现象。通过考察性能问题现象的各种细节与以往出现问题的现象进行对比,确定性能问题的类型。自底向上分析方法往往直奔问题的日志或其他细节。

找到性能问题出现的原因,就可以确定问题的解决方案了。并不是所有的性能问题都需要修改程序代码解决,有些可以通过调优性能参数解决,有些则必须通过修改软硬件配置解决。

--->既然我们知道性能问题的定位比较困难,在设计测试计划和用例的时候,对于一些新的功能,如果想要验证它的性能,最好能让用例的设计相对独立一些。换句话说,就是避免多个可能引起性能问题的新功能之间互相影响。

常见问题一览

并发:引起并发问题的原因有很多,大多数是由多个并发线程抢夺资源引起的:

  等待队列里的事务出现超时或回滚,从而导致访问出错
  竞争锁资源时导致了死锁

超时:使用监视工具得到监视结果并分析实际使用的资源数是否小于系统设置的最大资源数并作相应提高。

死锁:出现在多个进程相互持有对方需要的锁而得不到自己所需要的锁的情况下:数据库死锁、进程死锁。数据库死锁一般会在应用进程的日志中抛出异常,进程死锁指线程之间相互占用所需资源而不释放导致的死锁。

性能下降主要是指在负载没有变化的情况下,系统的性能指标随时间而逐渐下降。

在性能测试中发现或重现性能下降问题主要是通过可靠性测试用例,即通过较长的执行时间发现各种性能指标的变化趋势。

应用服务性能下降问题由以下单个或多个原因混合导致:

  应用程序资源使用问题,主要是内存使用问题:内存碎片、内存泄漏等
  应用程序设计问题,主要存在可扩展性或可靠性问题
  数据库访问问题

性能下降问题中做问题定位的一个重要手段是分段和比较。

性能参数调优是指通过调整配置参数改进应用系统性能的过程。性能参数调优的最低目标是避免由于不恰当的调优参数引起的性能问题。

性能参数调优的基本方法,就是通过反复的系统性能监测及分析,以配置参数调优为手段对系统资源进行合理的配置及调整,从而最大限度地提高系统性能,避免潜在性能问题的发生。

总结

性能测试的设计人员必须透彻理解产品的需求和设计,尤其是设计中关于性能目标的定义,之后设计出能够有效覆盖这些性能目标的性能测试计划。性能测试计划需要从产品的并发能力、响应时间、可扩展性、可靠性、安全性等多方面保证产品符合性能通过标准。

与其他测试不同,性能测试过程中不仅要看用例本身的执行情况,还要对测试系统和被测系统进行适当调优、实时监控,及时发现问题,合理收集所需要的监视日志,为后面的性能分析或问题定位做好准备。

(完)

(作者:Ribbon 来源:http://www.cnblogs.com/Ribbon/p/4634944.html)


 
            
 
            
 
            
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           

一字一句当思来之不易,感谢作者,传播测试知识、技能与正能量!

光荣之路软件测试培训

官网:http://www.gloryroad.cn/

微信公众号:gloryroadtrain

性能测试QQ群:415987441
软件测试招聘QQ群: 203715128
自动化3群QQ: 371211499


 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 精彩回顾 |成都工博会【互联网+】下的创新转型,有图有真相 使用PostgreSQL进行Redis的后台权限管理 你哭着对我说,做网赚都是骗人的…… 成为软件工程师最精彩的地方是什么? 安卓单元测试(九):使用Mockito Annotation快速创建Mock