第一次专题讨论LR基础及性能测试测试模型.docx

第一次专题讨论LR基础及性能测试测试模型.docx

《第一次专题讨论LR基础及性能测试测试模型.docx》由会员分享，可在线阅读，更多相关《第一次专题讨论LR基础及性能测试测试模型.docx（9页珍藏版）》请在冰豆网上搜索。

第一次专题讨论LR基础及性能测试测试模型

远走高飞14:

35:

03首先，初学LoadRunner需要一定的编程基础，至少有一些C语言的基础。

因为LoadRunner使用的是ansic语言，使用的是lccRetargetableCCompiler。

远走高飞14:

37:

05所以如果以前没有接触过编程或者C语言的兄弟姐妹们如果想学LoadRunner，首先建议你们看看C语言入门的书。

不需要很深，明白C的基本语法，一些变量的定义，还有一些分支语句的使用即可。

tian00di0014:

38:

34给些掌声％……※×

远走高飞14:

39:

48在有了这些C的基础之后，我们就开始来看看LoadRunner套件的组成。

虽然我们总在说LoadRunner是一个性能测试工具，其实它是一个套件。

LoadRunner有VirtualUserGenerator,Controller,Analysis,LoadGenerator四个重要组件。

远走高飞14:

40:

17首先，我们讲讲VirtualUserGenerator。

远走高飞14:

41:

49VirtualUserGenerator我们简称VuGen，其实就类似于MSVisualStudio一样的一个IDE的开发环境。

是我们用来开发和调试脚本用的。

远走高飞14:

44:

30Controller，是整个LoadRunner的核心，也是这个软件中最贵的部分。

只有这个东东是需要花钱买License的。

它负责控制整个测试中每个虚拟用户的行为，监控各种服务器资源的状况，收集诸如响应时间之类的测试指标。

远走高飞14:

45:

58Analysis，负责对测试执行结束后各种相关数据的处理和展现。

帮助我们测试人员对系统进行分析，查找系统可能存在的性能瓶颈。

颢子（1111）14:

47:

39讲的不错

远走高飞14:

47:

50LoadGenerator是我们真正发起压力的组件。

所有对服务器发起的压力都是从LoadGenerator发起的。

远走高飞14:

48:

41上面讲的是LoadRunner的组成和个组件的作用。

下面我们来讨论一下怎么使用LoadRunner来作一个简单的性能测试。

远走高飞14:

49:

51一个性能测试的项目，我们现在基本上已经有一套规范化的流程了。

远走高飞14:

51:

51可能每个人在作性能测试项目的时候都有不同的方法，我这里只是介绍一下我们是怎么作的，给大家一个参考。

远走高飞15:

03:

33一般来说，我们接到一个性能测试的项目之后，首先需要作的，也是最重要的的事情是需求分析。

远走高飞15:

04:

09这部分的工作主要有以下几个内容：

技术调研、业务调研。

远走高飞15:

07:

04技术调研，主要是了解项目被测项目的技术特点，比如说是什么架构的？

客户端与服务端的连接使用了什么样的协议。

作这部分的工作主要是为了确定我们进行性能测试的技术方案。

使用什么样的工具，使用什么样的协议，是否需要开发工具进行模拟等等。

远走高飞15:

08:

32技术调研结束之后，我们就可以初步的制定我们性能测试的技术方案了。

远走高飞15:

10:

15一般来说，对于大部分的应用而言，LoadRunner都是可以支持的。

这就是为什么LoadRunner会成为性能测试市场占用率第一的工具了。

当然，它还有其他的很多优点。

随着使用的深入，大家会越来越觉得LoadRunner确实是一款非常优秀的软件。

远走高飞15:

10:

44之后，我们要对被测系统进行业务调研。

目的是建立我们的性能测试模型。

远走高飞15:

11:

20到这里，我需要强调一下，业务建模在性能测试过程中是非常非常重要的。

远走高飞15:

12:

24为什么这么说，我们可以这样想，比如新浪网，它提供了很多的服务：

新闻浏览、邮件服务、软件下载、用户聊天。

。

。

等等等等。

远走高飞15:

14:

52每种服务对服务器的消耗是不一样的。

比如说新闻浏览和软件下载，它对服务器的要求就是：

需要高速的存储。

对CPU的处理能力和内存的需求不是很大。

而对于用户聊天服务则对服务器的CPU处理能力和内存的要求较高。

远走高飞15:

16:

07既然每种服务对服务器的资源需求是不一样的，每一种业务同样也会存在这个问题。

远走高飞15:

17:

49而我们进行性能测试的目的就是要在尽可能真实的模拟实际情况下对系统的服务器施加压力，从而获取系统在实际生产环境中的性能表现。

远走高飞15:

25:

15讲到为什么要建立测试模型了是吧。

远走高飞15:

26:

26刚才讲的那么多，都是为了说明测试模型很关键，如果没有一个正确的测试模型，那么我们作的测试工作是不可靠的。

说的更直接一些，就是这样测试得到的数据是不具备参考价值的。

非洲黑驴15:

26:

49啥叫测试模型

大山15:

27:

26听完再问问题好吗？

远走高飞15:

27:

45测试模型，就是描述我们系统的运行特点的模型。

伊伊15:

28:

30远老师我可否打扰一下

远走高飞15:

28:

53还是举新浪的例子。

比方说（数据没有考证，我只是想通过它来举个例子）新浪每天访问的用户中有70%是在看新闻，20%在使用邮件系统，10%在使用聊天服务。

远走高飞15:

28:

56什么问题？

伊伊15:

28:

59什么叫系统的运行特点的模型？

谢谢！

！

远走高飞15:

29:

11我正在举例说明。

：

）伊伊15:

29:

30好的BUG工作室15:

30:

05不要打断嘛，问题等他讲完了慢慢问。

远走高飞15:

30:

09那么我们在进行性能测试的时候，就要依照这样的模型对系统施加压力，在这种情况下，我们测试得到的数据才是可靠的，可参考的。

远走高飞15:

30:

58如果说我们在测试的时候没有依照上面的模型，测试出来的数据就是不可靠的。

伊伊15:

31:

28理解，谢谢老师！

！

远走高飞15:

31:

42举个极端的例子，我们在测新浪网的时候，如果所有的用户我们都使用了看新闻的脚本。

那么测试出来的结果会是什么样的呢？

非洲黑驴15:

33:

41是100％的用户都在看新闻。

。

。

远走高飞15:

33:

44结果就会是：

我们发现，IBM的顾问给我们提的硬件配置方案根本就不对！

他们给我们建议安装了32颗Power5的CPU，内存使用了128G，结果我们测试的时候发现了CPU使用根本没超过10%，而内存也非常的空闲。

但是磁盘确异常的忙碌。

大大超过了我们配置的存储的能力。

远走高飞15:

34:

42于是，测试结束之后，我们给运行部分了一个建议，减少CPU和内存数量，增加存储的投入，换更高档更快的存储。

远走高飞15:

34:

59运行部分采纳了我们的建议。

最后系统上线运行了。

远走高飞15:

35:

53运行之后发现，实际情况和我们测试的情况根本不是一会事。

CPU很忙，而且也发现大量的内存/磁盘交换操作。

远走高飞15:

36:

27产生所有这些错误的原因就是因为我们的测试模型和实际生产情况出入太大！

远走高飞15:

37:

00所以说，正确建立测试模型非常非常的重要。

远走高飞15:

37:

17这样说，还有哪位兄弟姐妹不明白吗？

Dick15:

37:

34建立测试模型,这个要客户主要提供数据吧

远走高飞15:

37:

58呵呵，一会儿就告诉大家怎么去建立一个正确的测试模型。

非洲黑驴15:

38:

07测试模型是不是就是要要得到测试的性能指标

远走高飞15:

38:

29性能测试指标是测试需求的一部分。

远走高飞15:

38:

36而不是测试模型。

非洲黑驴15:

38:

52嗯呢，明白了，谢谢

远走高飞15:

39:

10明白了测试模型的重要性之后，我们来看看怎么去建立一个测试模型吧。

远走高飞15:

39:

43这方面说实话，我没看到过一个成型的文档去告诉我们怎么作。

远走高飞15:

39:

55我这里讲的。

都是一些经验而已了。

远走高飞15:

40:

27在这里，我把测试模型分成了两种：

用户行为模型、业务特点模型。

远走高飞15:

41:

36用户行为模型，描述的是用户行为特点的一种模型。

简单的说，就是在高峰时刻，我们去看每个用户到底在干什么？

是在看新闻，收邮件还是在聊天？

远走高飞15:

42:

44经过调查，我们发现70%的用户在看新闻，20%的用户在收邮件，10%的用户在使用聊天服务。

那么这就是我们的用户行为模型。

远走高飞15:

43:

59那么将来我们在作性能测试设计场景的时候，我们就需要使用70%的用户去模拟看新闻，20%的用户收邮件，10%的用户聊天。

在这种情况下测试得到的结果才是可靠的可参考的。

远走高飞15:

44:

26另外一种模型就是业务特点模型。

远走高飞15:

45:

42业务特点模型，描述的是系统业务量特点。

也就是说我们通过对系统的调研，得到系统高峰期的业务特点。

远走高飞15:

47:

35举个简单的例子，我们在对系统进行观察后发现，系统每天的高峰期在早上10点到12点。

在两个小时内，我们发现系统总共处理了10000笔交易。

其中7000笔是查看新闻，2000笔是收邮件，1000笔是聊天。

那么，这就是我们系统的业务特点模型。

远走高飞15:

48:

38现在大家自己讨论一下，当我们得到系统的业务模型之后，应该怎么样去设计我们的性能测试场景？

：

）

Dick15:

49:

58知道了系统的高峰期的数量，那就跑这个数量的虚拟用户，如果在最高峰系统的速度都可以接受，那这个系统的性能是没有什么大的问题的

远走高飞15:

50:

13呵呵，还有什么别的意见么？

云萧萧15:

50:

42按照用户模型，去分配高峰用户的数量

伊伊15:

51:

12主要用压测，得出它的负载

远走高飞15:

51:

33还有谁有什么建议？

：

）

大山15:

51:

46使用主要业务脚本，不懂。

。

Dick15:

51:

53业务模型，让我知道用户总共要跑多少，用户行为模型，让我知道总共这么多用户，多少录制看新闻的，多少录制看邮件的

云萧萧15:

52:

30先看那些模块需要进行性能测试可以先单独做一下

云萧萧15:

52:

59然后在从用户行为的角度进行虚拟用户的分配

沉默风云15:

54:

45应该结合两个来考虑

远走高飞15:

56:

16大家讲的都有道理。

不过还是欠考虑了一个很重要的问题。

远走高飞15:

56:

33看看还有谁有什么意见？

：

）

远走高飞15:

57:

17云萧萧讲的就很有道理，再深入一些。

远走高飞15:

58:

34没人说话了？

加菲猫15:

59:

18还要考虑多少并发的？

颢子（1111）15:

59:

51TaskDistributionDiagram，TransactionProfile，UserProfile3种方法建立测试模型

远走高飞16:

00:

47呵呵，那是Mercury标准培训教程里面的东西了。

不过我觉得它讲的不是很好。

非洲黑驴16:

01:

28我知道，下一步是不是该录脚本了

远走高飞16:

01:

47现在我们有了业务特点模型描述我们系统的业务特点了。

那如何将这个模型转化成我们的场景呢？

Dick16:

02:

52录脚本

远走高飞16:

03:

23呵呵，还没到录脚本的时候呢。

远走高飞16:

03:

37我们的设计还没完成。

颢子（1111）16:

03:

51是啊任何理论上的东西都需要通过真实的项目进行学习不管好和坏其实都是方法需要我们在真正的工作中灵活运用

以今天的名义16:

03:

52录脚本可以同步做，但与远老师讲的没有关系

沉默风云16:

04:

05应该考虑用户使用的各种情况

远走高飞16:

04:

15现在我来讲讲如何将我们的业务模型转化成我们的测试场景。

大山16:

04:

18描述使用场景

远走高飞16:

05:

11这一点很关键，因为说实话，用户行为模型是很难建立的。

我们很难有这种时间和条件去统计在任一时刻的用户行为。

远走高飞16:

05:

35所以，大部分的性能测试项目，我们测试模型的设计都是基于业务特点模型的。

远走高飞16:

06:

58因为不同的业务，系统处理的时间是不一样的。

对于服务器来说，处理一笔看新闻的交易，它需要0.5秒的时间，而对于收邮件，则需要1秒的时间，而聊天可能对实时性的要求更高一些，它只需要0.2秒的时间。

远走高飞16:

07:

52如果说我们仍然以70%的用户去作看新闻的交易，20%的用户收邮件，10%的用户聊天。

那么这样测试得到的结果和实际情况也是不太一致的。

远走高飞16:

09:

10想想看，我们在测试的过程中为了能够保证压力能够持续一段时间，我们需要设置我们的Iteration数量，或者场景执行时间。

这样一来就会出现，一个收邮件的交易作完了，其实已经有两个看新闻的交易完成了，同时有5笔聊天的交易完成了。

颢子（1111）16:

09:

20需要对每个业务进行分析也就是需要在侧试场景中分析他们的执行速度

远走高飞16:

10:

22如果我们的用户比例仍然按照这样的比例而不作任何处理，执行完了之后，我们会发现我们执行的交易数量和我们的业务特点模型不一致。

远走高飞16:

10:

52所以，我们需要引入一个Interval时间。

就是在每个Iteration执行完了之后等待一段时间。

远走高飞16:

01:

47现在我们有了业务特点模型描述我们系统的业务特点了。

那如何将这个模型转化成我们的场景呢？

Dick16:

02:

52录脚本

远走高飞16:

03:

23呵呵，还没到录脚本的时候呢。

远走高飞16:

03:

37我们的设计还没完成。

颢子（1111）16:

03:

51是啊任何理论上的东西都需要通过真实的项目进行学习不管好和坏其实都是方法需要我们在真正的工作中灵活运用

以今天的名义16:

03:

52录脚本可以同步做，但与远老师讲的没有关系

沉默风云16:

04:

05应该考虑用户使用的各种情况

远走高飞16:

04:

15现在我来讲讲如何将我们的业务模型转化成我们的测试场景。

大山16:

04:

18描述使用场景

远走高飞16:

05:

11这一点很关键，因为说实话，用户行为模型是很难建立的。

我们很难有这种时间和条件去统计在任一时刻的用户行为。

远走高飞16:

05:

35所以，大部分的性能测试项目，我们测试模型的设计都是基于业务特点模型的。

远走高飞16:

06:

58因为不同的业务，系统处理的时间是不一样的。

对于服务器来说，处理一笔看新闻的交易，它需要0.5秒的时间，而对于收邮件，则需要1秒的时间，而聊天可能对实时性的要求更高一些，它只需要0.2秒的时间。

远走高飞16:

07:

52如果说我们仍然以70%的用户去作看新闻的交易，20%的用户收邮件，10%的用户聊天。

那么这样测试得到的结果和实际情况也是不太一致的。

远走高飞16:

09:

10想想看，我们在测试的过程中为了能够保证压力能够持续一段时间，我们需要设置我们的Iteration数量，或者场景执行时间。

这样一来就会出现，一个收邮件的交易作完了，其实已经有两个看新闻的交易完成了，同时有5笔聊天的交易完成了。

颢子（1111）16:

09:

20需要对每个业务进行分析也就是需要在侧试场景中分析他们的执行速度

远走高飞16:

10:

22如果我们的用户比例仍然按照这样的比例而不作任何处理，执行完了之后，我们会发现我们执行的交易数量和我们的业务特点模型不一致。

远走高飞16:

10:

52所以，我们需要引入一个Interval时间。

就是在每个Iteration执行完了之后等待一段时间。

颢子（1111）16:

11:

08要是这么讲可真是讲不完了

远走高飞16:

11:

28呵呵，能讲多少算多少吧。

我手头也没有现成的资料。

远走高飞16:

22:

47刚才讲到，我们大部分的性能测试项目都是基于业务特点模型设计的测试模型。

而如何将业务特点模型转化成我们的场景，需要引入Interval的时间。

远走高飞16:

27:

16那我们究竟怎么去确定我们的Interval时间呢？

在后面我们会讲到会有一个单交易负载测试的测试策略。

我们就是通过这个测试得到每个交易的大致执行时间，然后通过调整我们的Interval时间，使用每个交易每次Iteration时间都大致相当，那么我们就可以通过用户比例来设计我们的场景了。

另外还有一点，我们要保证我们的交易发起速度要和实际情况相当，也就是TPS数要和实际相当。

这个可以通过调整我们的并发用户数来实现。

这样，我们测试得到的数据就可以说是和实际的情况相当接近了。

在这种情况下，我们就可以对系统进行分析。

远走高飞16:

27:

50今天就讲到这吧。

：

）