• 1. 性能测试
  • 2. 性能测试 1. 对性能测试的理解 2. 性能测试的类型有哪些? (这些类型是属于方法,还是属于管理流程) 3. 某在线购物系统使用前,要做性能测试,如何入手? 4. 通过性能测试解决的问题
  • 3. 对性能测试的理解 性能,就是执行软件某一功能所消耗的时间。 从代码级别来看,如果功能都消耗在代码级别上,则从后台CPU来测,从用户角度来看,会发现CPU内存的占用和整个带宽的占用都会进行消耗,这些可能就是需要监控的目标,去查找在CPU内存上或者别的什么部件上有消耗,就在这些消耗的地方查找性能瓶颈。 从整个代码的执行效率来看,如果1个功能模块中有10个功能函数,每个功能函数实现了1个功能,这些功能叠加,也会产生时间的消耗。
  • 4. 对性能测试的理解 可以从各方面来理解性能. 思考:有哪些因素在影响性能?
  • 5. 对性能测试的理解 可以从单元级别去查找相应的性能问题。整个软件产品集成后,还会对性能进行测试,此时是针对不同模块进行组合。另外,在整个企业级的部署下,每个功能点,每个瓶颈点,都会被测试。
  • 6. 对性能测试的理解 比如一个简单集成,前台是IE,中间是Web层,后台有应用服务器,DB服务器,则每一个点上,都可能产生性能瓶颈。 再比如Web Logic,作为一个应用服务器,它有自身的配置,线程池,数据连接池,有在不同操作系统上的不同配置条件,只有对每个部分都了解,才能做好性能测试。
  • 7. 对性能测试的理解 可看出,在性能的含义里,还隐含着一些内容,也即整个测试结束后,要进行诊断。而诊断可以从代码级别和整个系统应用级别来着手。调优也是这两方面工作的综合。 所以,性能测试贯穿整个软件系统的生命周期,从单元测试,集成测试,到最后的系统测试。
  • 8. 对性能测试的理解 如果是从代码级别来看,更多的是倾向于单元测试。 如果是从整个系统的各个功能点,各个不同的应用,和从服务器的一些设置来看,是更多倾向于模块集成后,对整个系统运用进行调试。 所以,在不同阶段,针对软件产品,都要进行相应的性能测试,而不仅仅局限于系统测试阶段。
  • 9. 性能测试的类型一个小问题,如果发生在客户端,则不会影响到其他用户。而如果发生在服务器端,则问题会呈现几何级增长,并且会影响到系统上的每一个用户。所以,在做性能测试的时候,判断是什么性质的性能问题,非常重要。
  • 10. 应用举例比如,连Access时,用ADO进行连接,响应时间很慢,CPU占用达到90%以上.通过对ADO的实验,还有通过对后台的企业级应用了解到,当时所用的数据库,最大存储量是8万到10万条数据,而系统的实际运行数据远远超过了这个限制,系统运用达到了100万条数据,远远超过了数据库所能承受的量,所以,如何提高相应速度?如何降低CPU占用资源率? 当时,在代码级别上进行了测试.在大量用户访问的情况下, CPU和内存上升,系统基本无法工作.然后,调用了ADO连接代码,发现了瓶颈问题,就是在进行调用后台数据库时,占用了大量的CPU时间.因为ADO有两种连接方式,在ADO的Connection对象中,用Record Set直接读取数据库的数据,也就是直接select所有符合条件的记录.即使简单数据,从百万条记录中去取,也有将近1G的数据量,这些数据读取到内存中,再显示到界面上,相应速度非常缓慢.当时的解决方法是,对整个调用的数据(因为是同步连接,而ADO提供了另一种连接方式,即异步连接.在调用系统相应的数据时,只要把后台数据库调用出来,即使所有的数据都在提取,也可以同时进行下一步操作,而不需要等数据都下载到本地后,才能执行下一步)对整个代码进行了优化.用异步连接的方式,性能上升, CPU使用率下降,且满足了当时的性能需求.
  • 11. 性能测试的类型性能测试的类型有负载测试,压力测试,容量测试,还有基准测试和配置测试,可靠性测试,安全测试等等。
  • 12. 负载测试 Load Testing: 在不同负载情况下,一个系统能否正常运用。 比如运用大量的不同用户,200,400,或者800等,用Windows 2000/2003 系统,CPU P3/P4,内存1G/512兆等等,看在不同的条件下,软件系统是否都能达到预期结果。
  • 13. 压力测试 Stress Testing: 在系统资源很少的情况下,查看整个系统的运用是否能满足用户的要求。 甚至,在系统达到极限的情况下,查看系统的可接受度。 比如,要求200个在线用户,100个并发,则在压力测试下,会做120-150个并发用户。200个在线用户就用300,400个在线用户来模拟,即超过系统的极限来进行测试,看系统的反应是否正常。
  • 14. 容量测试 Volume Testing:对整个系统来说,是针对未来软件系统的应用进行的测试。 比如数据库,具有一定容量。从小方面来说,就是数据库测试,从大方面来说,就是针对整个系统应用的一个未来规划而做的性能测试。 着重于用每秒钟处理的事务数量(t/s)来衡量整个系统的运用。
  • 15. 容量测试 Volume Testing:比如,在现有的硬件环境下,系统能否承载未来的发展?比如3月份有200用户,到5月份,即为1000用户,在此基础上,可规划软件系统承受量的曲线。在将来,要增加哪些硬件,哪些配置,来达到预期的目标,这就是一个容量测试。 容量测试分小和大两种概念。“小”就是对数据库进行的容量测试。而从“大”的方面来讲,就是对软件系统进行长远的规划。
  • 16. 基准测试 Benchmark Testing:做性能测试时,更多的是测试,分析,诊断,这是简单的性能测试流程。每次进行性能测试时,我们都会把它作为一个基准,看调优之后,会发生什么情况。比如在用户不同负载的情况下,选择了负载测试,分别用了200,500,600个用户。200个用户的时候,作测试,采集数据,然后进行整理,把它作为基准。但是在它之前,还有一个目标,这个目标就是基准。比如此时,200个用户的具体响应时间为1秒,但200个用户真正做性能测试时,发现响应时间达到了3秒,和前面定义的1秒有偏差。这时就要分析,是系统的哪一个环节出了问题。找到相应的原因,进行修改,再做第二轮测试,同样是200个虚拟用户。此时,再把搜集到的数据与前面的相对比,如果达到目标,就把前面两次的数据作为不同基准,再与以后每次的测试结果相对比。
  • 17. 配置测试 Configuration Testing在不同的系统配置下,系统级别的每个应用是否能保证测试的结果。
  • 18. 可靠性测试/稳定性测试也就是长期运行,观察其可靠性。比如微软在发布新产品前,会将产品运行72小时。这也是一种压力测试。
  • 19. 性能测试的类型性能测试的类型有负载测试,压力测试,容量测试,还有基准测试和配置测试,可靠性测试,安全测试等等。 思考:在这些类型中,哪些属于从方法上告知如何进行性能测试,哪些是侧重于从流程上来控制性能测试?
  • 20. 性能测试的类型性能测试的方法有负载测试,压力测试,容量测试,还有其他方法,就是基准测试和配置测试,可靠性测试,安全测试等等。前三种侧重于从方法上告知如何进行性能测试,而后面的更多是从流程上来控制测试的方法,并且,基本包含在前三种测试方法中。
  • 21. 思考讨论 :某大型网站,系统每天用户访问量6000 人,业务处理每天10万笔. 问题:网站服务器CPU过高;后台数据库死锁 思考:根据前面的内容, 此时应该选用怎样的测试方式,流程?
  • 22. 可能答案因为这里假设的系统有上限,而且用户访问量已经达到极限,业务量也相当大,所以导致了CPU过高,数据库死锁,所以这时应该选用压力测试.了解客户系统运行的平台,后台数据库,web服务器,应用服务器分别是什么?每天6000人访问量,具体访问了哪些模块?了解了这些信息,就可以建立相对应的场景,针对数据库和整个的企业级应用来做性能测试.
  • 23. 思考 某在线购物系统在应用前,要做一个性能测试,如果由你负责,你如何入手?
  • 24. 可能答案这里可能有很多用户场景,每一个场景,都可以作为自动化脚本测试的开发依据。而如果测试了错误场景,则测试不会有结果,也不会达到预期的效果。 在测试方法上,可以选择压力测试。因为在线购物系统,用户的访问量很可能会达到极限,需要处理的业务量也会很大。 需要了解客户运行的平台,软件开发的语言,后台数据库,Web服务器,应用服务器分别是什么。系统架构如何?运用了哪些技术?具有哪些功能?每天大约有多少用户访问?用户访问了哪些模块?了解了这些信息,就可以建立相对应的场景,针对数据库和整个的企业级应用来做性能测试。
  • 25. 可能答案如果不知道系统的上限,也可以完成,但最好要模拟用户的实际使用场景,这样更能体现实际情况。可以找一些同类型的软件;在系统的升级运用下,也可以找一些前面系统的相关运行情况,然后把它设计成相应的案例,在系统中进行测试;或者了解系统有哪些功能其中哪些是用户经常使用/访问的,这些都可以作为实际测试用例的设计依据。 对不同用户的访问量,超过极限的访问量,在做测试时,除了场景的设计,还要不断调整虚拟用户数.此时,就是压力测试/负载测试在工具中的体现.
  • 26. 注意点 --- 应该如何判断需求? 用户往往会提出三个问题: 我要系统执行的越快越好 我这个系统能支持多少用户? 我的系统要支持一天十万笔业务 这也就是从三个角度描述了软件系统的性能问题,即: 系统的响应时间;系统的并发量; 系统的吞吐量。 其中,系统的并发量,是指在同一个时刻内,系统同时处理的交易个数。 必须有这三方面,客户的需求才能成立,并设计相关的测试用例。 注意:在线用户数不等于并发量. 在LoadRunner中,用集合点这项功能,模拟用户对系统的密集型操作,从而模拟大量用户的并发操作.
  • 27. 测试步骤概括1. 选择好性能测试的类型. 2. 应用工具,怎样把性能测试类型体现在工具上. 3. 了解系统的整体运用,了解用户的实际使用情况,把所有的应用开发成相应的脚本,再移植到整个的用例场景上进行组合,就可以进行相应的性能测试. 4. 最后,采集数据. 这便是性能测试的一个简单流程.
  • 28. 通过性能测试解决的问题 .内存泄漏 .数据库死锁 可以通过模拟大量用户来访问系统操作.不同用户在不同情况下使用不同的模块,这是调用后台程序,就会抢占后台资源等.用单用户测试发现不了的问题,比如在单用户下,整个软件系统的运行很正常,二三十个用户也没问题,但当系统达到一百个用户,并且进行长时间的性能测试,给系统造成压力的时候,此时后台爆发出了严重的内存泄漏问题,也就是在一定用户量的访问下,系统占用了大量资源,即在代码中生成了很多对象.这些对象由于各功能都在被使用,抢占系统资源,而在等待的过程中,用户没有释放相应的对象.这时就出现了内存泄漏.而在几个用户访问的情况下,很难发现. 像数据库死锁这些问题,也是在大量用户访问的情况下,才会发现(并非少数用户就不能发现,只是大量用户的情况下,更易发现).
  • 29. Thanks!