发布新日志

  • 写给测试经理的话

    2008-03-04 21:25:22

    本来是想和您面对面地聊一下这半年来我工作上的想法以及表现等,不过正好有这次和我们毕业生综合评估的机会,我也就借着自己的这个总结报告和您谈下我对我们公司测试组遇到的一些问题、现状、还有未来的发展的一些看法;也许我的这些看法还不成熟,或者还欠缺很多理论依据的验证,但起码它代表了我的个人观点!最后,我也会借此机会和您坦开心扉的谈下我的个人工作态度上存在的误区等问题。
    我理解我们公司测试部门的现状,是任何一个创建初期的公司都会遇到的问题,也相信这些会随着了管理层的领导和我们全体员工的不懈努力与合作而改观并健康发展的。虽然我还谈不上对公司的测试部投入了一腔热血,但我也在时刻关注着公司对测试组的发展啊!在公司的项目测试中,我付出了我全部的精力,而且在工作之余不断的自我充实与加强,也希望有天可以真正象个测试骨干成员来给公司提出建设性的建议;但目前的测试组比我刚来时又少了2个人,而且没有了定期的例会,测试工作的管理流程和本身的测试流程也‘简化’了很多;举个例子,目前的项目测试工作只是凭着对项目业务的理解去反复的跑流程,而且我也感受过一个我从来没听说过的项目,然后有人跟我说‘我们这有个项目,你把它测一下吧…’我面对现状,倍感凄楚!
        不仅仅是上述的工作体会让我有此感慨,是这种现象让我不得不反思下子;其实这些话也许不是我应该说出口的,虽然我是一个普通的公司测试组成员,但我想我也有责任为我们测试组的发展过程中的问题积极思考;即便没有这次评估我们毕业生的机会,我也一直打算和您交流下;但我怕我总结的不好,或者没有说服力,所以一直在酝酿中,等待一个相对成熟的时候或我理解的比较深刻时。现在我就把我对我们公司测试组工作中的一起问题——当然有很多做的很好的地方,我们也有目共睹;不过我想主要谈下欠缺的地方,如果我说的不对或还欠缺考虑,也希望获得您的理解和原谅!
    1:我感觉公司对测试组的管理和支持的投入力度不够
    a、我觉得首先是我们很多同仁对测试这一职业了解的不够。目前国内相关的软件工程人士有85%以上的人对测试这个行业还处理不熟悉的状态(包括当初我自已),这种不熟悉表现在“测试人员技术素质不高”、“测试比开发要低一个档次”、“测试不能保证软件的质量,测试人员只是点按钮、跑业务流”…很显然,这些想法在某些同事的心理的确存在!而现实又何尝不是如此?!通过和很多从事测试的网友交流,我不得不承认目前国内的很多软件企业的情况与此相差无几;我觉得要改观这种现状,还必须要有漫长的路要走。首先是观念的改变,公司全体成员都要有充分的认识;从人员的任用标准,软件的需求、设计、开发、测试的投入比例开始考虑;再者就是测试从业人员自身的专业素养,要真正能够站在高于开发人员的角度甚至是客户的角度去判断和分析软件的业务流和实现的方便性和友好性,并且需要冷静的诊断问题能力和有力的说服开发人员或咨询人员的能力,另外还要掌握业界先进的测试管理工具及自动化测试工具。
    b、其次我们的测试组织管理不够完善。我们公司实行项目组制度,即测试组中的几个人分配到一个项目实施测试工作,有一个测试负责人;应该说这种方式是比较客观和正确的方式,但据我个人的体会,我们没有强调出测试负责人的作用。比如,一个项目初期指定的测试负责人应该制定测试计划、根据软件需求设计测试用例,测试实施中要分配测试人员测试任务,并定时跟踪着软件测试的进度与紧急问题的处理方案;而测试人员要定期报告测试实施中的bug记录,并按时完成被指配的测试任务。我觉得这些我们都做到了,但有点表面化!举例而言,我们的软件发生需求变更时,测试用例没有更新(当然有时是时间不允许,但为什么不允许呢?是因为需求变更了,但为什么了变更了一次又一次呢?为什么最初不需求细化些、全面些、设计好些呢?对此,我不想多说,我想这儿早已经引起领导的重视了,我只说测试方面的问题);项目的测试用例是否设计完整,覆盖功能点是否全面,测试人员写好测试用例是否有人评审并按照用例来测试,如果测试用例写的不好,是否考虑了当初给测试人员足够的时间来思考?我写过的几个项目测试用例,好像都是1、2个星期内的事情,我和**一人一半;试想,那么大的系统,需求调研了那么久,分析设计了那么久,那么多功能点让我们就1、2个星期写好;我想这些都是我们当引起重视并可以改观的地方。单单测试用例方面我列举了上述欠缺的地方,当然其他方面也有,比如一旦项目比较紧急的时候,没有严格按照notes的流程来实施(我觉得我们公司的bug管理流程采用notes是比较先进的,很多软件公司还没有这么好的工具,我想我们该严格采纳此流程并不断发扬);甚至在日常测试中,我们提交给开发人员的bug有时经常被他们打回来,当然有的确实是可以不改或不急待改正的地方,但他们的借口是需求不是我们测试人员决定,对于这些客户友好化的bug他们不予理睬;还有在项目例会上,很多时候讨论的是需求,是编码,对测试只是简单带过,换句话说,是公司的咨询、开发,而对测试认为只是做他们的后续工作,即验证需求、验证代码,而没有实质的参与到项目里;而一旦项目出现了质量方面的问题,好像对测试的责怪最多;我想追其原因,还是我们没有加强测试负责人、测试工程师在项目中的作用与地位,并能够科学的分配测试资源。这里我还想说一句话:项目出现了问题,原因是多方面的,并不是测试人员工作不努力,也不是测试人员素质不高,试问一个项目只配备了2个测试人员,而且没有合理的计划与适当的控制追踪,如何能真正做好!这里不是我们不敢承担责任,我只是说出了很多测试伙伴的一句心里话而已。
    c、再次我们的测试管理流程不够完善。我们公司已经通过了CMM二级,但并没有象标准说的那样让我们测试在需求阶段就涉入,不然也不会出现上述的情况:在我对该项目一无所知的时候,别人编码完成了,认为到了测试阶段就一句话让我去测试!另外,其实我们对这种b/s结构的软件目前只做了功能测试,这个还不够,当然软件的质量就不能得到足够的验证。功能测试,即业务流测试,只能满足客户的最基本需求,也是最根本的软件价值所在;但我们的软件产品还有很多其他的质量指标,比如很多的用户同时使用系统时系统(包括数据库)的稳定性与承受负载能力等。其实我觉得我们还需要软件的单元测试、功能测试、系统测试、数据库测试、性能测试、确认测试等等。这其中的道理,我想您和管理层比我对软件工程理解的透彻的多,我就不多说了。虽然我们在日常测试工作中有时也兼顾了这些,但一直没有完整的解决方案,来全面测试我们的产品。对于java的单元测试,年初打算推行junit、cactus等,但我们一直没有开展实施,当然这也是有其他原因的,我也一直期待着能够采用这些标准的测试流程;而刚才说的其他方面的测试,目前为止我还没涉入过,对此我也深报希望,为了真正提高我们项目的质量,也真诚希望公司能够加大测试这方面的投入。
    2、测试组工作分配不均衡,造成时而负荷较重时而显得轻松。这个问题在前面也有提及,主要表现在:
    a、    项目的测试人员配备不足,如果要完成一个软件的全面测试,目前的人员是肯定不够的,您也说过很多大型软件企业测试人员配备是和开发人员相当的,其作用自然也会提升的。
    b、    没有制定项目的整体计划或没有严格遵守,即项目开发任务不多时,测试任务也不多,开发任务排的很紧时,测试也自然紧张起来。
    c、    测试工作需要写很多文档,比如测试用例、测试报告,还有和项目中其他人员的交流文档等,而每次给的时间好像都很紧张,但发现写完了,也没有很棘手的任务,这就造成文档质量不过关,当然评审(或即将的评审)也通过不了。
    d、    测试计划跟着开发计划走,这不假,但开发那边要调整,这就意味着测试也要相应改动,而放弃手头可能测试人员认为比较重要的测试任务;但对此情况,没人给予支持,没有达到软工中开发与测试相辅相成的效果。
    3、学习与培训的机会不足。当初来到**做测试工作是有新鲜感,但半年多后,对大部分业务功能都会比较熟悉,知道测试工作就是每天按照分配的任务来反复跑流程,对个人而言就没有更多提高的机会和空间,自然丧失了一定的激情。这个的确是我心理的一些真实想法,所以我会在日常工作中给领导一些不努力工作的假相,针对这个问题我会在后续部分来谈。总之,我和我的测试组伙伴都热切希望公司能够为我们提供适当的测试方面的培训机会,如果我们真的需要在将来采取多方面软件测试的话,那我们现有的技术水平和测试水平远远不够。我参加过北京地区的两次测试行业交流会,深知很多做产品化软件的公司,对测试人员的技能要求会比开发人员还要高,比如在使用自动化测试工具的能力上,在对一个初期的软件功能的分析上,甚至可以充当系统分析员的角色来确定功能点,而不是追随在程序员的代码后面来验证别人的‘开发思想’。
    4、与其他好的软件公司相比,我们的测试部门哪些做得好,哪些又有不足
    a、 黑盒测试做得较好,对商业逻辑的理解能力强。
    b、 人员的凝聚力强,都敢于担当重任。
    c、 对白盒测试未曾涉及,不过我想会有这一天的。
    d、对自动化测试只停留在探索阶段,而且好像只有我在探索着,虽然**师姐   很支持我,但没有引起足够的重视。
    e、 测试用例做得不太好。
    f、 没有全面掌握、使用各种测试方法。
    g、 针对我们的项目,测试人员的行业知识了解的不够多。
    5、关于我们测试部门如何发展的一点建议,我这里只说测试技术方面的
    a、测试部为纯技术部门,所有的商业逻辑等知识只要能看懂文档即可;商业逻辑是否正确应该在需求阶段由项目中的各个相应角色定义下来,而不是靠测试部来发现,因为改需求的成本极高,而测试只是验证这些需求。
    b、从黑盒向黑盒加白盒,再转向白盒的测试方向,这就要求所有的测试人员必须掌据源代码读写的能力;这个估计实施起来比较困难,因为公司的测试组多是女性,而且很多人当初也没有软件开发的基础,或者也没有很高的热情去学习这些知识;但可以采取项目经理(开发经理)全权负责,配合系统分析员和测试负责人或测试骨干成员,带动整体的测试实施,比如由系统分析员写好测试代码,测试负责人指派测试人员编写完整的测试用例,修改测试代码,然后执行。
    c、一部分人必须掌握自动化测试的技术,以便提高工作效率。这个我觉得很重要,向来我们的项目就是不断的变更,不断的测试,这样一味反复跑同样的流程,不仅浪费时间,也湮灭了测试人员的积极性,造成成本的浪费和软件周期的延长,而对于软件质量呢,其实还是最后那一次变更后的测试是真正有用的!我们要充分利用软件工程中软件的精髓特性——复用性,所以需要开展自动化测试,一次编写测试代码,自动用计算机执行,需求变更了,我们只要修改测试代码即可,从而大大节约成本与精力。
    d、对于深层次的业务逻辑测试,我们公司的测试组还有很多的高手,她们对各个项目的业务理解能力的确很强,我想我们可以定期的交流下,比如在测试例会上,以提高我们测试组的整体技能。测试工具能节约人的工作量,但并不能代替人去完成深层次的商务逻辑测试工作,所以根本的还是要加强测试人员的技能提高。
    接下来我想和您谈下我自身的测试工作上的问题。
    1、 这半年来我做了些什么?
    a、 **项目的测试工作。和**一起,算是从头到尾的负责这个项目。
    b、学习了winrunner、loadrunner、robot、testmanager、was、jtest、junit等测试工具,了解了rational公司的rup软件工程理论,还看了写系统分析方面的知识,比如uml建模,以及简单了解了solaris操作系统,奠定了相对坚实的测试理论基础;如果需要,我很愿意分享给同事们。
    c、总结:去年半年是我掌握基本软件测试,适应公司的测试流程,并学习了j2ee开发的相关知识;这半年是我提高测试全方面技能,立志真正溶入并提高公司的测试部门,并认准了软件测试这一行业,不断向前发展。
    2、 工作中存在的抱怨和误区及对工作的一点不满
    既然是误区和不满,我想我说出来您也不要介意,因为这些本来就是错误的想法啊,只是我觉得它们是影响我的工作态度的原因;开文时我就说会开诚布公的和您谈下这些问题,既然我们公司是以人为本,那么领导也该倾听员工的心声啊!
    a、    公司重视**部门,重视**部门,但没有人足够的重视测试组,认为测试就是跟在别人后头点按钮,甚至连开发人员都可以驳回提交的bug
    b、    很多项目前期做的不好,到头来压缩的是测试的时间,削减的是测试的经费,不重视的是测试人员的地位
    c、    公司对我们毕业生没有提供一个比较完善的发展空间和培养机会,让我们理解成自己是廉价劳动力。比如,除了**给我讲些测试的方法和技巧,**给我一定的机会让我学学先进的测试技术外,好像这1年来也没有专门的测试方面的培训啊。
    d、    对于我们毕业生的薪酬待遇问题。后面cut了,呵呵
    e、    在测试任务不忙时,我会上些测试技术网站或论坛,学些新东西,但一般这种情况肯定是我保证了本身的测试任务之外的时间,但有时引起领导的误解;其实我根本没有时间上网玩,我有很多东西要学,正经的东西我都学不过来,怎么会那么做呢!我觉得应该平等的对待我们;其实我也亲耳听过公司的领导说过‘还是这些学生听使唤啊’的话,我觉得这样有违于公司的以人为本;不在其位不谋其职,这些事情总得有人做,我们也做到了,即便态度不是很端正,或偷下懒,但如果少了这个人,项目也不会进展到如今啊!
    f、     我想我工作上的误区不过这些,再有就是和您或项目成员交流的不够,从而导致不必要的误解或不明。这个我会注意的,同时还希望领导可以给予必要的指正和建议
    g、    cut 掉了
    h、    总结:我想不管是抱怨也好,工作误区也好,我想我既然都坦白的说出来,就希望您和领导可以给予指正,而且我会在这里提出自我批评,是我没有及时的向领导反映我的思想动态。
    3、 关于我个人的优点、缺点以及今后工作上的发展方向
    a、    优点:我觉得自小就养成了几个比较突出的优点吧;诚实守信是我最大的特征,知之为知之,不知为不知,无论在工作还是在学习上,我都脚踏实地的做人做事,不浮夸,不虚躁,保持谦虚谨慎的做人态度!
    其次,算是学习上永远坚持上下求索、勇攀高峰的精神吧,天行健,君子当自强不息;无论在工作上还是生活上,象我们这样初出茅庐的毕业生,都要时刻保持这种积极与主动学习的作风。
    再次,是我对事物敏锐的观察力和洞察力,是一种在工作上努力钻研、独立思考的精神,不然即便学了很多,但没有造诣,也称不上人才(据说这个是做一个合格测试工程师的重要情商之一啊!)。
    最后,我想我的团队合作精神还能得到项目组成员的认可和肯定,我们也都意识到工作中团队协作的重要性在日益增强,我也会在这方面努力加强!
    b、    缺点:首先是我的外在语言表达有些欠缺,所以有时可能在和同事与领导的交流中产生些不必要的误解。其次,好像自己的思想状态不够稳定,有时会因为工作之外的某些事情引起情绪的低落,不能时刻保持积极向上的乐观态度。最后,就是我没有主动和领导交流自己的思想动态,有时在感觉迷茫困顿时没有及时的恢复自我。
    c、    今后的发展方向:就是认准了软件测试这个行业,从基础的测试员做起,不断的走向提高;至于期间的发展路程,我离不开公司的耐心培养,更离不开您的积极指导!
    本来这份报告应该是谈些我个人工作的收获与个人评价,还有对自我发展的设想,不过我好像对公司和部门管理的意见说的多一点。我总觉得个人的发展离不开团体,如果我们公司的测试组整体水平提高了,那收获就不只是我个人的了,无论从公司的核心竞争力还是客户认可度,以及软件同行里的地位与形象的树立都会受益匪浅!关于我个人的收获与评价,在前面我也有了相应的总结,我想我能认识到这么多问题,本身就是一种收获啊!同时我觉得我在钻研某些新的测试技术方面有着一定的优越性,还希望您和领导可以给予我这样的机会,我也很愿意参与这些问题的讨论。也许前面我的某些言词过于偏激,但我想您也会理解年轻人的这些个性,也真诚希望领导就我个人工作中的误区与缺陷开展批评,并提出积极的指导与评价!
    诚挚感谢您
  • 测试部门经理工作感受

    2008-03-04 21:18:36

    我是在20065月到新单位工作的,如今已经工作了4个月,新单位是一个很不错的单位,项目饱满,资金等方面也没有太多的问题,但就测试部门工作的情况却很不乐观。具体表现是人员少,任务重,人员不稳定。领导对测试部门的工作很不满意,在面试我的时候就多次表示了对公司目前测试不满,期待我来之后能够带领测试部门有一个比较好的发展。

    首先说说我们公司测试部门在这四个月的变化吧

    1测试人员大量增加,原来的测试人员为3人,现在为14人,人员扩充了3倍,目前来说,测试人员的数量还不是很多,但相比原来部门的扩充速度还是很快的,另外一个方面,由于我们工作比较有成效,领导基本认可开发人员和测试人员比例可以达到10.81的比例。我想这个比例对一个国内的企业来说已经是很高的比例了。

    2个人素质的提高。具体的个人素质提高不是很好说,还是用项目来说吧,我刚来的时候,测试人员在一个系统测试的时候,一般测试需求点位500个左右,后来一个项目在作回归测试的时候,测试需求点达到15000个,第二次回归测试的时候测试需求点达到了49000个,这里要说明的是,我们测试需求点的增加不是为了增加而增加,而是对被测试需求各种使用情况分析的更详细,程序覆盖强度越来越大的结果,测试发现的问题深度逐步增强的反应。

    3机器设备的变化,测试人员是开发群体的弱势群体,他们的机器配置也是公司最低的,刚来的时候,全部测试人员都使用P4 1.7完全不能满足自动化测试的需要,目前,测试人员基本都是P4 3.0双核,液晶,测试人员很高兴。另外我们还有专门的测试流程管理服务器,一些淘汰下来的老机器作为专门跑测试用例的测试专用机。

    4开发人员对测试人员的态度改变。测试人员在开发过程中处于弱势地位,这是一个不可回避的现象,原来开发人员可以随意的让测试人员作自己认为需要的测试,而测试人员是没有办法拒绝的,甚至连具体测试的方法和手段开发人员都要干涉,而一旦出问题,首先怪罪测试人员,而不是找自己的责任,测试人员成了项目失败的替罪羊。而现在这种已经发生了很大的改变,至少测试人员有能力展示他们的特长。而不是开发人员的附属。

    5领导对测试工作的态度转变

    我刚到单位的时候,领导们对测试工作很不满意,给我印象最深的是领导说,测试部门的工作人员,可用的就留下,不可用的就直接开除,这对测试人员的工作评价实在不高,现在好多了,首先测试部门现在的工作得到了领导的认可(原来我们总是被批评,而现在总是被表扬),其次,人员、设备的配置在增加,最重要的是,我们要求的测试时间可以得到保证。

     

     

     

    到单位工作4个月了,测试部门出现这么多的变化,有很多原因,但最重要的就是那句话:做正确的事情,正确地做事情。

        个人认为做正确的事情比正确地做事情要重要,道理很简单,中国的一句成语----南辕北辙就是最好的解释了,如果不能了解什么事情是正确的事情,那么你做事情的效果越好,则整个项目失败的可能性越大。下边先说说我到单位做的几个事情。

    1和领导达成一个协议

    2了解单位的工作情况

    3了解单位工作的问题

    4订立规则

    5组建自己的团队以及核心团队

    6协助其他人员工作

     

    下边我具体的说一下:

    1、和领导达成一个协议:
       
    5月份我到公司正式上班,新到一个公司,人生地不熟。最先要作的事情是在和各位领导接触过程中了解公司的情况,并与领导达成一个大致的协议,我首先和领导达成的协议基本内容是测试部门的工作在3个月内有一个小变化,6个月内有一个大改观,1年之后形成良好的测试流程和测试队伍。领导们也基本同意我的设想。和领导达成这个协议为我以后的工作的开展取得了时间上的保证,(很多领导希望招聘一个高级开发管理人员后,开发或测试立刻有一个改观,在几天内开发和测试完全没有问题,这种心情是可以理解的,但实际上也是不可能的),我的领导在这方面给了我一定宽限,为以后的工作打下了一个良好的基础。

    2、了解单位的工作情况

        每一个单位都用自己的特点,有优点也有缺点,如果下车伊始就乱下命令,必然是瞎指挥,不但不能改善工作,而且原来单位一些好的做法也必然被你毁掉。所以,刚下车,一定要休息一下,看看周围的环境,再决定如何行动。来一个新单位也是这样,人生地不熟的自然要先看看,首先是有几个部门,各个部门主要方向,几个主管领导,比如人力资源对我们以后人员招聘会比较重要,研发部门有几个?哪个研发方向是单位的最主要的方向,后勤保障部门是那些人员,不要小看他们,部门以后是否可以获得好设备主要就看他们了,这些人职位不高,但属于现管。争取他们对工作支持是很必要的。最后,别忘了了解你的工作人员,无论怎么说,你的工作人员是和你打天下的人。

    3、了解单位工作的问题

        刚到单位,测试人员都很忙,我则在一边观察,前几天的问题总结了一下。

    A:测试人员人员少,队伍分散,由于以前的测试队伍管理比较乱,很多项目不放到测试部门测试,而是将测试人员直接从测试部门调出。在我到岗的时候测试部门只有4名测试人员。

    B:试部门机器的问题,由于测试部门一直不被重视,所有的机器很落后,自动化测试工具基本不可使用,

    C:开发人员对测试干涉过多,测试缺少独立性

    开发人员对测试工作干涉过多,主要表现在几个方面,

    C1:测试内容由开发人员规定,测试方法以及测试手段均由开发人员决定,在测试人员能力弱的情况下,这无疑是一个可行的方法,问题是这种方法要求开发人员对测试方法和手段比较了解,但单位的实际情况却不是这样,另外开发人员对测试工作质量不承担责任,说明白点就是测试人员按照开发人员的规定去做,即使完成了测试任务,也无法保证测试质量,而由于测试质量不好造成产品质量不好的问题,又需要测试人员来承担。

    C2:开发人员和测试人员在测试过程中交流过多,在测试过程中由于相关文档不全或者质量问题,测试人员经常需要开发人员进行交流,这种交流是必要的,但也容易产生问题,比如测试在发现一个问题的时候,开发人员总会用这样或那样的借口告诉开发人员这不是问题,不用写在问题报告里,结果很多问题即使被测试出来也被这种糟糕的交流给掩盖起来了。

    D:测试时间无法保证

    测试时间无法保证主要是以下几个原因

    D1:首先是开发人员来规划测试任务,而真正了解测试工作的开发人员很少,测试工作量占到整个开发量的30%-70%。基本上没有开发人员了解这个情况,所以他们给测试留得时间很少,往往是1、2天。这么短的时间根本不能做到完整的测试。

    D2:开发人员管理的混乱,软件版本的频繁升级,有时候一个版本和上一个版本的差别只有几行代码,这样不但造成软件配置管理的混乱,而且给测试人员带来了很大的麻烦,最讨厌的是,绝大部分的测试工作都变成了无效测试。除了浪费测试资源以外对开发没有任何好处。

    E:测试水平低,测试需求点少,测试强度不够

    测试时间的紧张,严重限制了测试人员的测试水平的发挥,单位许多测试人员测试水平是相当不错的,但他们根本没有时间编写测试需求报告,一个系统的测试需求点往往只有几百个点,这种测试需求强度根本无法保证测试质量。

  • 测试杂料

    2007-08-21 17:27:44

  • lr常见问题及精华归总结

    2007-07-16 17:35:45

  • TestDirector 8.0安装配置

    2007-07-16 16:28:04

  • 关于loadrunner安装和卸载的以下看法

    2007-07-06 10:04:55

  • 《Web性能测试实战》性能测试用例模板

    2007-07-03 14:23:48

  • LoadRunner监控Windows和Linux常见问题

    2007-07-02 18:09:44

  • loadrunner运行原理

    2007-07-02 15:40:30

  • 性能测试(并发负载压力)测试分析-简要篇

    2007-07-02 14:48:21

    分析原则:

    • 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
    • 查找瓶颈时按以下顺序,由易到难。
      服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
      注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

    分析的信息来源:

    • 1 根据场景运行过程中的错误提示信息
    • 2 根据测试结果收集到的监控指标数据

    一.错误提示分析

     分析实例:

    • Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
    • Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

    分析:

    • A、应用服务死掉。
      (小用户时:程序上的问题。程序上处理数据库的问题)
    • B、应用服务没有死
      (应用服务参数设置问题)
      例:在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%
    • C、数据库的连接
     (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数(跟硬件的内存有关))
       2 Error: Page download timeout (120 seconds) has expired

    分析:可能是以下原因造成

    • A、应用服务参数设置太大导致服务器的瓶颈
    • B、页面中图片太多
    • C、在程序处理表的时候检查字段太大多

    二.监控指标数据分析

     1.最大并发用户数:

     应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。

     在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

     如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK。否则,再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

    2.业务操作响应时间:

    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。
    • 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的?问题是否与网络或服务器有关?
    • 如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用“网络监视器”图确定导致性能瓶颈的网络问?/li>
     3.服务器资源监控指标:

     内存:
     1 UNIX资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。

    内存资源成为系统性能的瓶颈的征兆:
     很高的换页率(high pageout rate);
     进程进入不活动状态;
     交换区所有磁盘的活动次数可高;
     可高的全局系统CPU利用率;
     内存不够出错(out of memory errors)

    处理器:
     1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 合理使用的范围在60%至70%。
     2 Windows资源监控中,如果System\Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。

    CPU资源成为系统性能的瓶颈的征兆:
     很慢的响应时间(slow response time)
     CPU空闲时间为零(zero percent idle CPU)
     过高的用户占用CPU时间(high percent user CPU)
     过高的系统占用CPU时间(high percent system CPU)
     长时间的有很长的运行进程队列(large run queue size sustained over time)

    磁盘I/O:
     1 UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
     2 Windows资源监控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。

    I/O资源成为系统性能的瓶颈的征兆 :
     过高的磁盘利用率(high disk utilization)
     太长的磁盘等待队列(large disk queue length)
     等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
     太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
     过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
     太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)

    4.数据库服务器:
     SQL Server数据库:
     1 SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。
     2 如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高,则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
     3 Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器的值必须为0。
     4 Lock Requests/sec(锁请求/秒),通过优化查询来减少读取次数,可以减少该计数器的值。

    Oracle数据库:
     1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
    快存(共享SQL区)和数据字典快存的命中率:

     select(sum(pins-reloads))/sum(pins) from v$librarycache;
     select(sum(gets-getmisses))/sum(gets) from v$rowcache;
     自由内存: select * from v$sgastat where name=’free memory’;

    2 如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
     缓冲区高速缓存命中率:

     select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ; Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

    3 如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
     日志缓冲区的申请情况 :

    select name,value from v$sysstat where name = 'redo log space requests' ;

    4 如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序 。
     内存排序命中率 :

    select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where  a.name='sorts (disk)' and b.name='sorts (memory)'

     

    UNIX资源监控指标和描述

      监控指标 描述

      平均负载 系统正常状态下,最后60秒同步进程的

      平均个数

      冲突率 在以太网上监测到的每秒冲突数

      进程/线程交换率 进程和线程之间每秒交换次数

      CPU利用率 CPU占用率(%)

      磁盘交换率 磁盘交换速率

      接收包错误率 接收以太网数据包时每秒错误数

      包输入率 每秒输入的以太网数据包数目

      中断速率 CPU每秒处理的中断数

      输出包错误率 发送以太网数据包时每秒错误数

      包输入率 每秒输出的以太网数据包数目

      读入内存页速率 物理内存中每秒读入内存页的数目

      写出内存页速率 每秒从物理内存中写到页文件中的内存页数

      目或者从物理内存中删掉的内存页数目

      内存页交换速率 每秒写入内存页和从物理内存中读出页的个数

      进程入交换率 交换区输入的进程数目

      进程出交换率 交换区输出的进程数目

      系统CPU利用率 系统的CPU占用率(%)

      用户CPU利用率 用户模式下的CPU占用率(%)

      磁盘阻塞 磁盘每秒阻塞的字节数

    注:上述SQL Server和Oracle数据库分析,只是一些简单、基本的分析,特别是Oracle数据库的分析和优化,是一门专门的技术,进一步的分析可查相关资料。

  • WebLogic Server 性能调优 1——管理篇

    2007-07-02 13:45:48

  • 优化WebLogic 服务器性能参数

    2007-07-02 13:43:52

  • Breakdown Graph 中First Buffer是什么?

    2007-07-02 12:17:50

  • First Buffer非常大说明什么问题?

    2007-07-02 12:03:53

  • VUG运行时产生Error -27979

    2007-07-02 11:55:29

  • Controller运行完毕之后,日志文件在哪里保存的?

    2007-07-02 11:29:09

  • were not create hits per second,throughout

    2007-06-29 15:14:47

  • Loadrunner中参数设置详细分析

    2007-06-13 10:24:39

    Loadrunner中参数设置详细分析
    相信对大家会有用的,这个版本是基于7.8的。
    做负载或者压力测试时,很多人选择使用了Loadrunner测试工具。该工具的基本流程是先将用户的实际操作录制成脚本,然后产生数千个虚拟用户运行脚本(虚拟用户可以分布在局域网中不同的PC机上),最后生成相关的报告以及分析图。但是在录制脚本的过程中会遇到很多实际的问题,比如不同的用户有不同的使用数据,这就牵涉到参数的设置问题。本文就Loadrunner中参数的设置进行说明,希望对大家有所帮助。
       
    在录制程序运行的过程中,VuGen(脚本生成器) 自动生成了包含录制过程中实际用到的数值的脚本。如果你企图在录制的脚本中使用不同的数值执行脚本的活动(如查询、提交等等),那么你必须用参数值取代录制的数值。这个过程称为参数化脚本。
       
    本文主要包括如下内容:理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。
       
    除了GUI,以下的内容适合于各种类型的用户脚本。
    一、关于参数的定义

       
    在你录制程序运行的过程中,脚本生成器自动生成由函数组成的用户脚本。函数中参数的值就是在录制过程中输入的实际值。
        例如,你录制了一个
    Web应用程序的脚本。脚本生成器生成了一个声明,该声明搜索名称为“UNIX”的图书的数据库。当你用多个虚拟用户和迭代回放脚本时,也许你不想重复使用相同的值“UNIX”。那么,你就可以用参数来取代这个常量。结果就是你可以用指定的数据源的数值来取代参数值。数据源可以是一个文件,也可以是内部产生的变量。
       
    用参数表示用户的脚本有两个优点:
     可以使脚本的长度变短。
     可以使用不同的数值来测试你的脚本。例如,如果你企图搜索不同名称的图书,你仅仅需要写提交函数一次。在回放的过程中,你可以使用不同的参数值,而不只搜索一个特定名称的值。
       
    参数化包含以下两项任务:
     在脚本中用参数取代常量值。
     设置参数的属性以及数据源。
        参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。另外,不是所有的函数都可以参数化的。

     

    二、参数的创建
       
    可以指定名称和类型来创建参数。不存在对脚本中参数个数的限制。在Web程序的用户脚本中,你可以使用如下过程在基于文本的脚本视图中创建参数。或者,也可以在基于图标的树形视图中创建参数。
       
    在基于文本的脚本视图中创建一个参数:
    1、
     将光标定位在要参数化的字符上,点击右键。打开弹出菜单。
    2、
     在弹出菜单中,选择“Replace with a Parameter”。选择或者创建参数的对话框弹出。
    3、
     在“Parameter name”中输入参数的名称,或者选择一个在参数列表中已经存在的参数。
    4、
     在“Parameter type”下拉列表中选择参数类型。
    5、
     点击“OK”,关闭该对话框。脚本生成器便会用参数中的值来取代脚本中被参数化的字符,参数用一对“{}”括住。
        注意:在参数化
    CORBA或者General-Java 用户脚本的时候,必须参数化整个字符串,而不是其中的部分。另外注意:除了Web或者WAP,缺省的参数括号对于任何脚本都是 {}”。你可以在“General Options”对话框中的“Parameterization”标签(Tools>General Options)中定义参数括号种类。
    6、
     用同样的参数替换字符的其余情况,选中参数,点击右键,弹出菜单。从弹出的菜单中,选择“Replace More Occurrences”。搜索和替换对话框弹出。“Find What”中显示了你企图替换的值。“Replace With”中显示了括号中参数的名称。选择适当的检验框来匹配整个字符或者大小写。如果要搜索规则的表达式(.!?等等),选中“Regular Expression”检验框,然后点击“Replace”或者“Replace All”。
        注意:小心使用“
    Replace All”,尤其替换数字字符串的时候。脚本生成器将会替换字符出现的所有情况。
    7、
     如果想用以前定义过的参数来替换常量字符串的话,选中该字符串,点击右键,然后选择“Use Existing Parameter”,子菜单“Use Existing Parameters”弹出。从子菜单“Use Existing Parameters”选择参数,或者用“Select from Parameter List”来打开参数列表对话框。
        注意:如果用以前定义过的参数来替换常量字符串的话,那么,使用“
    Parameter List”非常方便。同时,还可以查看和修改该参数的属性。
    8、
     对于已经用参数替换过的地方,如果想取回原来的值,那么,就在参数上点击右键,然后选择“Restore Original value”。
        在
    Web用户脚本的树形视图中创建参数:
    1
    、将光标定位在企图参数化的地方,点击右键,从弹出的菜单中选择“Properties”。则相关的属性对话框打开。
    2、点击在要参数化的参量的旁边的“
    ABC”形状的图标。“Select or Create Parameter”对话框打开。
    3、在“
    Parameter name”中输入参数的名称,或者从列表中选择一个已经存在的参数。
    4、在“
    Parameter type”中输入参数的类型。
    5、点击“
    OK”关闭该对话框。用户脚本生成器会用参数来替换最初的字符串常量,并用一个表格形状的图标替换“ABC”形状的图标。
    6、要恢复参数化以前的值,点击图标,然后从弹出的菜单中选择“
    Undo Parameter”,则以前的值便会重现。

     

    三、定义参数的属性
       
    创建参数完成后,就可以定义其属性了。参数的属性定义就是定义在脚本执行过程中,参数使用的数据源。在Web用户脚本中,你既可以在基于文本的脚本视图中定义参数属性,也可以在基于图标的树形视图中定义参数属性。下面的过程将教你如何在基于本文的脚本视图中定义参数属性。
       
    在基于文本的脚本视图中定义参数属性步骤:
    1、
     在参数上点击右键,有菜单弹出。
    2、
     在弹出的菜单中,选择“Parameter Properties”。参数属性对话框打开,显示和当前参数类型相关的属性。
    3、
     输入参数的属性值。
    4、
     点击“Close”关闭参数属性对话框。
        在
    Web用户脚本的树形视图中定义参数的属性:
    1、
     将关标定位在参数上,然后点击右键,选择“Properties”。属性对话框打开。
    2、
     点击要定义属性的参数旁边的表格形状按钮,点击右键,选择“Parameter Properties”。参数属性对话框打开,和参数类型相关的属性显示出来。
    3、
     输入参数的属性。
    4、
     点击“Close”关闭参数属性对话框。
       
    使用参数列表:
      使用参数列表可以在任意时刻查看所有的参数,创建新的参数、删除参数,或者修改已经存在参数的属性。
    1、
     点击参数列表按钮或者用“Vuser>Parameter List”。参数列表对话框打开。
    2、
     要创建新的参数,点击“New”按钮。新的参数则被添加在参数树中,该参数有一个临时的名字,你可以给它重新命名,然后回车。设置参数的类型和属性,点击“OK”,关闭参数列表对话框。
        注意:不要将一个参数命名为“
    unique”,因为这个名称是用户脚本生成器本身的。用户脚本生成器创建新的参数,但是不会自动用该参数在脚本中替换任意选中的字符串。
    3、
     要删除已有的参数,那么,要先从参数树中选择该参数,点击“Delete”,然后确认你的行为即可。
    4、
     要修改已有参数,那么,要先从参数树中选择该参数,然后编辑参数的类型和属性。

    四、理解参数的类型
      在你定义参数属性的时候,要指定参数值的数据源。你可以指定下列数据源类型的任何一种:
    Internal Data――
     虚拟用户内部产生的数据。
    Data Files 
    ――存在于文件中的数据。可能是已存在的文件或者是用脚本生成器新创建的。
    User-Defined Functions――
     调用外部DLL函数生成的数据
      
    Internal Data包括以下几种:
    1
    、 Date/Time
      Date/Time用当前的日期/时间替换参数。要指定一个Date/Time格式,你可以从菜单列表中选择格式,或者指定你自己的格式。这个格式应该和你脚本中录制的Date/Time格式保持一致。
    2
    、 Group Name
      Group Name 用虚拟用户组名称替换参数。在创建scenario的时候,你可以指定虚拟用户组的名称。当从用户脚本生成器运行脚本的时候,虚拟用户组名称总是None
    3
    、 Load Generator Name
      Load Generator Name用脚本负载生成器的名称替换参数。负载生成器是虚拟用户在运行的计算机。
    4. Iteration Number
      
    Iteration Number用当前的迭代数目替换参数。
    5
    、 Random Number
      Random Number用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
    6
    、 Unique Number
      Unique Number用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。
    7
    、 Vuser ID
      Vuser ID用分配给虚拟用户的ID替换参数,ID是由Loadrunner的控制器在scenario运行时生成的。如果你从脚本生成器运行脚本的话,虚拟用户的ID总是-1

    五、数据文件
      数据文件包含着脚本执行过程中虚拟用户访问的数据。局部和全局文件中都可以存储数据。可以指定现有的ASCII文件、用脚本生成器创建一个新的文件或者引入一个数据库。在参数有很多已知值的时候数据文件非常有用。数据文件中的数据是以表的形式存储的。一个文件中可以包含很多参数值。每一列包含一个参数的数据。列之间用分隔符隔开,比如说,用逗号。
      对数据文件设置参数属性
      如果使用文件作为参数的数据源,必须指定以下内容:文件的名称和位置、包含数据的列、文件格式,包括列的分隔符、更新方法。
      如果参数的类型是“
    File”,打开参数属性(Parameter Properties)对话框,设置文件属性如下:
    1、
     在“File path”中输入文件的位置,或者点击“Browse”指定一个已有文件的位置。缺省情况下,所有新的数据文件名都是“parameter_name.dat”,注意,已有的数据文件的后缀必须是.dat
    2、
     点击“Edit”。记事本打开,里面第一行是参数的名称,第二行是参数的初始值。使用诸如逗号之类的分隔符将列隔开。对于每一新的表行开始一行新的数据。
      注意:在没有启动记事本的情况下如果想添加列,就在参数属性对话框中点击“
    Add Col”,那么“Add new column”对话框就会弹出。输入新列的名称,点击“OK”。脚本生成器就会添加该列到表中,并显示该列的初始值。
    3、
     在“Select Column”部分,指明包含当前参数数据的列。你可以指定列名或者列号。列号是包含你所需要数据的列的索引。列名显示在每列的第一行(row 0)。
    4、
     在“Column delimiter”中输入列分隔符,你可以指定逗号、空格符等等。
    5、
     在“First data line”中,在脚本执行的时候选择第一行数据使用。列标题是第0行。若从列标题后面的第一行开始的话,那就在“First data line”中输入1。如果没有列标题,就输入0
    6、
     在“Select next row”中输入更新方法,以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是:连续的、随机的、唯一的、或者与其它参数表的相同行。
      6.1、
     顺序(Sequential):该方法顺序地给虚拟用户分配参数值。如果正在运行的虚拟用户访问数据表的时候,它会取到下一行中可用的数据。
      6.2、
     随机(Random):该方法在每次迭代的时候会从数据表中取随机数
      6.3、
     使用种子取随机顺序(Use Random Sequence with Seed):如果从Loadrunner的控制器来运行scenario,你可以指定一个种子数值用于随机顺序。每一个种子数值在测试执行的时候代表了一个随机数的顺序。无论你何时使用这个种子数值,在scenario中同样的数据顺序就被分配给虚拟用户。如果在测试执行的时候发现了一个问题并且企图使用同样的随机数序列来重复测试,那么,你就可以启动这个功能(可选项)。
      6.4、
     唯一(Unique):Unique方法分配一个唯一的有顺序的值给每个虚拟用户的参数。
      6.5 、与以前定义的参数取同一行(
    Same Line As <parameter>):该方法从和以前定义过的参数中的同样的一行分配数据。你必须指定包含有该数据的列。在下拉列表中会出现定义过的所有参数列表。注意:至少其中的一个参数必须是SequentialRandom或者Unique
        如果数据表中有三列,三个参数定义在列表中:
    id1name1title1,如下:。
    ID Name Title
    132 Kim Manager
    187 Cassie Engineer
    189 Jane VP
        对于参数
    id1,你可以指示虚拟用户使用Random方法,而为参数name1title1就可以指定方法“Same Line as id1”。所以,一旦ID132”被使用,那么,姓名(Name)“Kim”和职位(Title)“Manager”同时被使用。

    7、
    Updta value on数据的更新方法

    7.1、
    Each iteration――每次反复都要取新值

    7.2、
    Each occurrence――只要发现该参数就重新取值

    7.3、
    Once――在所有的反复中都使用同一个值

    8、
    When out of values超出范围:(选择数据为unique时才可用到)

    8.1、
    Abort Vuser――中止

    8.2、
    Continue in a cyclic manner――继续循环取值

    8.3、
    Continue with last value――取最后一个值

    9、
    Allocate Vuser values in the Controller在控制器中分配值:(选择数据为unique时才可用到)

      9.1、
    Automatically allocate block size――自动分配

      9.2、
    Allocate()values for each Vuser――指定一个值

    六、从已存在的数据库中导入数据
      Loadrunner允许你利用参数化从已经存在的数据库中导入数据。可以使用下列两种方式之一:
    1、
     使用Microsoft Query(要求在系统上先安装MS Query)。
    2、
     指定数据库连接字符串和SQL语句。
        用户脚本生成器在从数据库中导入数据的过程中提供了一个向导。在向导中,你指明如何导入数据-通过
    MS Query创建查询语句或者直接书写SQL语句。在导入数据以后,以.dat为后缀并作为正规的参数文件保存。要开始导入数据库中数据的过程,在参数属性对话框中点击“Data Wizard”,则,数据库查询向导弹出。
      要创建新的查询
    1、
     选择“Create new query”。如果需要MS Query的帮助,选择“Show me how to use Microsoft Query”,然后点击“Finish”。
    如果你还没有安装
    Microsoft QueryLoadrunner会提示你这个功能不可用。在进行之前,从Microsoft Office中安装MS Query
    2、
     Microsoft Query中遵循以下步骤,导入期望的表和列。
    3、
     在完成数据的导入后,选择“Exit and return to Virtual User Generator”,然后点击“Finish”。在参数属性对话框中数据库记录以data文件的形式显示出来。
    要在
    MS Query中编辑并查看数据,选择“View data or edit in Microsoft Query”。若要结束,则选择“File>Exit and return to Virtual User Generator”返回到脚本生成器。
    4、
     在“Select Column”部分,指定包含当前参数数据的列可以指定列号或者列名。注意:列标题默认为第0行(row 0)。
    5、
     从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:SequentialRandomUnique或者Same Line As。其中每一项的含义文章前面已经讲述,就不再赘述。
    6、
     如果选择“Advance row each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
      要指定数据库连接或者
    SQL语句
    1、
     选择“Specify SQL Statement”,然后点击“Next”。
    2、
     点击“Create”指定一个新的连接字符串。选择数据源的窗口弹出。
    3、
     选择已有的数据源,或者点击“New”创建一个新的数据源。向导将提示你穿过创建ODBC数据源的过程。在完成后,连接字符串就会在连接字符串框中显示出来。
    4、
     SQL框中,输入或者粘贴SQL语句。
    5、
     点击“Finish”继续SQL语句并导入数据。数据库记录将以data文件的形式显示在参数属性框中。
    6、
     在“Select Column”部分中,指定包含当前参数数据的列。你可以指定列号或者列名。
    7、
     从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:SequentialRandomUnique或者Same Line As
    8、
     如果从Update out of values中,选择“each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。

     

  • 多个场景连续执行

    2007-06-12 18:15:50

    在control的Edit Schedule中选择Schedule by Group中定义start when group ***group finishes.
  • web性能-描述性统计与性能结果分析(续)

    2007-06-12 15:24:40

452/3<123>
Open Toolbar