本站内容均来自网络转贴内容,如涉及版权问题,请及时联系我,我会及时删除。。。

发布新日志

  • 小布老师 LoadRunner系列培训视频

    2010-06-30 15:07:16

    转载叶筱珊——IVY

  • 测试用例&测试粒度

    2010-06-30 15:04:11

    本文出自叶筱珊的51Testing软件测试博客,转载请保留出处及链接


    用例执行百分比=项目完成百分比???
        时常会有人通过用例执行的百分比来宏观的去看一个项目的测试进度情况。
        但是遇到这种情况的时候测试工程师会说,用例的执行的百分比不足以展示一个项目的测试进度。
       
        为什么会有这种矛盾呢?
       
        其实这个等式成立有一定的前提条件,那就是测试工程师写的测试用例的测试粒度是否合理
       
        怎样的粒度才是合理?


        1、测试粒度不宜过细,测试用例分解的测试粒度过细会给测试工程师带来成倍的额外工作量,对于项目管理来讲,这样是不合算的。


        2、测试粒度不宜过粗,这是因为如果一个测试用例,里面包含了太多验证点。比如在写取钱的用例时,要检查余额查询,用户最大额度查询类似的本可以单独一个用例的东西都硬拼到了一起,那么用例的执行进度和项目的进度肯定不能划等号。简单说就是有的用例简单有的用例复杂,所以有的也许要验证半天,有的只需要10分钟。这样的话,文章开头的等式就当然不相等了。
        粒度过粗还有个麻烦就是,发现很多bug都对应着一个用例。这样给缺陷管理和统计起来也带来麻烦。在项目后期的报告中不能清晰的统计缺陷。
       

                                                         
        如何划分测试粒度?
       
        1、使用功能点划分,细化每个功能点,到这个功能点不能再拆分。
         2、所要测试模快对该系统的整体影响.看其重要性。
       
        3、最好在用例编写前,项目的测试工程师可以讨论出一个适合项目的统一测试粒度。


       
        就写这么多了,以后想起什么了在来补充,朋友要是发现有什么不对的地方可以留言哦~
       
  • 软件测试管理之工作流程及技能(转)(二)

    2010-06-25 21:55:20

     

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      要想解决这个问题,最终取决于这整个团队的管理者及整个团队工作的氛围。

      曾记得在某一本书上看到这么一个观点:要想看一个公司管理者的能力、整个团队的管理水平及氛围;可以从问题角度去观察。

      当出现问题时,整个团队是互相推卸,还是积极反馈、查找原因和解决办法;整个团队是否愿意去发现和寻找工作中的问题,能否有正确的方法去面对问题;这就要求管理者在组建和管理一个团队时,对团队成员的要求;工作流程很重要,执行工作流程的人更重要。

      没有做过测试工作的人,会不知道测试工作过程中的困难和难度;没有做过开发工作的人,会不知道开发工作过程中的困难和难度;没有做过管理工作的人,会不知道管理工作过程中的困难和难度;前不久有位同事说过:有些东西你没有做过就你没有发言权。

      当某些工作需要大家配合去完成时,只有足够的尊重(学会换位思考、学会沟通)、责任心才会让事情做起来比较顺利。

      上面这些牵扯出另一个问题:工作技能,应该说是综合技能。

      做技术的,大家都知道,牛人通常不会推卸责任;牛人知道自己会哪些,不会哪些,不会瞎指挥;牛人会根据实际情况结合自身的经验给予对方建议和帮助,而不是刁难和嘲笑;牛人会用你能接受的方式让你知道自己在哪个地方出问题了。

      关于现象3中的自动化测试工具的局限性,如何让开发明白,我给的建议如下:

      1)让一部分开发人员来干干测试的工作,让他做过后,就会明白了;这个方法耗费的成本代价较大,属于内耗。

      2)如果公司还有其它团队,让其它团队测试工作有影响力的人给开发团队管理者进行引导。

      3)收集数据,准备材料,用足够的数据(自动化测试提升了XXXX测试执行工作效率;自动化发现的bug数据;手工测试发现的bug数据XXXX等等)来说服对方,当然在说服的过程中,要得到更上一层管理者的支持和理解。

      上面3点是治标不治本,最终还是要把工作流程整理顺畅,要有个合适的人在合适的位置上选择一堆合适的人,然后带这堆合适的人一起做事。

      在我测试工作的7个年头里,经过在不同公司和不同团队配合做事后,让我感触最深的是:测试工作要做好很不容易。

    22/2<12
  • 软件测试管理之工作流程及技能(转) (一)

    2010-06-25 21:51:48

     

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      同行在来信中提到的问题现象是:

      问题现象1:测试完成后,出现需求变更(如:增加、修改、删除),此时的测试该如何做(如:测试执行该如何做、测试文档该如何写)?

      问题现象2:开发人员和用户直接交互,出现需求变更,开发修改后没有经过QA测试,直接提交用户,导致用户发现很多bug,因此开发人员说测试组发现不了bug,要求引入自动化测试工具。

      问题现象3:开发人员理解的自动化测试工具,就是能够自动发现Bug,并且能发现所有Bug的工具,让测试人员引入这类的自动化测试工具;如何让他们开发人员明白自动化测试工具的局限性,似乎不是一个简单的问题。

      站在测试管理角度看上面的问题现象,我总结为三点问题:测试工作流程、测试工作技能、团队协作沟通,现在一一对这些现象进行分析和探讨。

      现象1和现象2都遇到了需求变更。

      由于缺少需求变更处理流程,问题1的测试人员不知道该怎么办;问题2的测试人员很冤枉的背负漏出去的bug,被开发强求引入自动化测试工具。

      老中医的一个观点我很认同:最终目标是要治本而不是治标;公司一位大牛的一句话我很认同:要用科学的态度看问题。

      当需求发生变更后,测试该怎么办?我给的建议是:

      1)需求变更,不光牵扯到的是测试、里面还有开发和后期负责维护的相关部门;需求变更时,需求负责部门(或产品部门)、开发部门、测试部门、技术支持维护部门之间要对这个情况进行沟通协调,通过一个合适的工作流程让团队之间的工作效率和质量能有效的得到保障和提升。

      2)需求变更出现时,我认为测试能做的、应该做好的是:

      a)测试管理者对待需求变更等同于测试一个版本的流程一样,需要进行版本控制和资源协调;也要相应的对变更需求做分析(如:需求变更的影响范围、紧急程度、资源能否相应、工期的影响和风险),制定相应计划、评审相应测试用例

      b)测试人员需要根据变更的需求以及开发设计文档,编写用例、执行测试、测试日报……等等执行相应的测试工作流程。

      有的人会说,但现实情况是,有的团队就没有这么个变更处理流程、有的团队有了这个流程会要求特殊情况给予特殊处理,测试能怎么办?

      1)没有变更处理流程的,需要各个相关部门的管理者给予重视并商讨建立一个合适的,大家好才能是真的好!

      2)有了流程,需要考虑特殊情况特殊处理:

      a)例如:时间紧任务重,可否跳过QA?可以跳过QA,但QA不承担这种情况出现的质量问题,由决策者来承担。

      b)例如:时间紧任务重,QA资源紧,但必须要QA测试,测试管理者要让相关兄弟部门老大知道,在这样的情况下,QA能保障的也是必须要保障的是主要业务和功能的测试,其它的无法保障,同时要让相关兄弟部门做好这个任务的风险评估及应对配合工作。

      c)在特殊情况下的测试任务,测试有权力说出自己当前的版本质量情况及是否上线的建议。

      现象2和现象3都遇到了团队协作沟通的问题。

      这是测试工作中最难、也是最累的;有过测试工作经验的人都有体会,测试和开发配合的好坏直接影响工作的进度、质量和团队发展。

      要想解决这个问题,最终取决于这整个团队的管理者及整个团队工作的氛围。

  • 回归测试思考(转)

    2010-06-25 21:47:38

     

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁。

      回归测试包的选择:软件生命周期中,即使一个得到良好维护的测试用例库也可能变得相当大,这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例,时间和成本约束可能阻碍运行这样一个测试,不得不选择一个缩减的回归测试包来完成回归测试。

      选择回归测试策略应该兼顾效率和有效性两个方面。

      (1)、基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试用例,这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级。一般而言,测试从主要特征到次要特征。

      (2)、基于操作剖面选择测试 。如果基线测试用例库的测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况。回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。

      (3)、再测试修改的部分。当测试者对修改的局部化有足够的信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上。通常,一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下,回归测试尽可能覆盖受到影响的部分。

  • 浅谈项目测试需求分析(二)转帖

    2010-06-25 21:39:42

     

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      任何一套软件都会有一定的业务流,也就是用户用该软件来实现自己实际业务的一个流程。简单的来说,在做测试需求分析时需要列出以下类别:

      1)  常用的或规定的业务流程

      2)  各业务流程分支的遍历

      3)  明确规定不可使用的业务流程

      4)  没有明确规定但是应该不可以执行的业务流程

      5)  其他异常或不符合规定的操作

      然后根据软件需求理出业务的常规逻辑,按照以上类别提出的思路,一项一项列出各种可能的测试场景,同时借助于软件的需求以及其他信息,来确定该场景应该导致的结果,便形成了软件业务流的基本测试需求。

      在做完以上步骤之后,将业务流中涉及的各种结果以及中间流程分支回顾一遍,确定是否还有其他场景可能导致这些结果,以及各中间流

      程之间的交互可能产生的新的流程,从而进一步补充与完善测试需求。

      5. 测试需求的优先级

      优先级别的确定,利于测试工作有的放矢的展开,使测试人员清晰了解核心的功能、特性与流程有哪些,客户最为关注的是什么,由此可确定测试的工作重点在何处,更方便处理测试进度发生问题时,实现不同优先级别的功能、模块、系统等迭代递交或取舍,从而缓和测试风险。

      通常,需求管理规范的客户,会规定用户需求/软件需求的优先级别,测试需求的优先级可根据其直接定义。如果没有规定项目需求的优先级,则可与客户沟通,确定哪些功能或特性是需要尤其关注的,从而确定测试需求的优先级。

      6. 测试需求的覆盖率与覆盖程度

      测试需求的覆盖率通常是由与软件需求所建立的对应关系来确定的。如果一个软件的需求已经跟测试需求存在了一对一或一对多的对应关系,可以说测试需求已经覆盖了该功能点,以此类推,如果确定了所有的软件需求都建立了对应的测试需求,那么测试需求的覆盖率便是测试需求覆盖点/软件需求功能点=100%,但并不意味着测试需求的覆盖程度高。因为测试需求的覆盖率只计算了显性的(即被明确规定的功能与特性)因素,而隐性的(即没有被明确规定但是有可能或不应该拥有的功能与特性)因素并未计算在内。因此根据不断的完善或实际测试中发生的缺陷,可以对测试需求进行补充或优化,并更新进测试用例中,以此来提高测试需求的覆盖程度。

  • 浅谈项目测试需求分析(转帖)

    2010-06-25 21:37:21

     

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      1. 什么是测试需求

      确切地讲,所谓的测试需求就是在项目中要测试什么。我们在测试活动中,首先需要明确测试需求(What),才能决定怎么测(How),测试时间(When),需要多少人(Who),测试的环境是什么(Where),测试中需要的技能、工具以及相应的背景知识,测试中可能遇到的风险等等,以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。

      就像软件的需求一样,测试需求根据不同的公司环境,不同的专业水平,不同的要求,详细程度也是不同的。但是,对于一个全新的项目或者产品,测试需求力求详细明确,以避免测试遗漏与误解。

      2. 为什么要做测试需求分析

      如果要成功的做一个测试项目,首先必须了解测试规模、复杂程度与可能存在的风险,这些都需要通过详细的测试需求来了解。所谓知己知彼,百战不殆。测试需求不明确,只会造成获取的信息不正确,无法对所测软件有一个清晰全面的认识,测试计划就毫无根据可言。活在自己世界里的人是可悲的,只凭感觉不做详细了解就下定论的项目是失败的。

      测试需求越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,就更有把握保证测试的质量与进度。

      如果把测试活动比作软件生命周期,测试需求就相当于软件的需求规格,测试策略相当于软件的架构设计,测试用例相当于软件的详细设计,测试执行相当于软件的编码过程。只是在测试过程中,我们把”软件”两个字全部替换成了”测试”。这样,我们就明白了整个测试活动的依据来源于测试需求。

      3. 测试需求的依据与收集

      测试需求通常是以待测对象的软件需求为原型进行分析而转变过来的。但测试需求并不等同于软件需求,它是以测试的观点根据软件需求整理出一个checklist,作为测试该软件的主要工作内容。

      测试需求主要通过以下途径来收集:

      1)  与待测软件相关的各种文档资料。如软件需求规格、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。

      2)  与客户或系统分析员的沟通。

      3)  业务背景资料。如待测软件业务领域的知识等。

      4)  正式与非正式的培训。

      5)  其他。如果以旧系统为原型,以全新的架构方式来设计或完善软件,那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。

      在整个信息收集过程中,务必确保软件的功能与特性被正确理解。因此,测试需求分析人员必须具备优秀的沟通能力与表达能力。

      4. 测试需求的分析

      目前不少的书籍与网站资料开始重视测试需求的分析,同时也提出了一些测试需求分析的方法。这里也提出一些自己的看法。

      测试需求需要考虑几个层面的因素:

      第一层:测试阶段。系统测试阶段,需求分析更注重于技术层面,即软件是否实现了具备的功能。如果某一种流程或者某一角色能够执行一项功能,那么我们相信具备相同特征的业务或角色都能够执行该功能。为了避免测试执行的冗余,可不再重复测试。而在验收测试阶段,更注重于不同角色在同一功能上能否走通要求的业务流程。因此需要根据不同的业务需要而测试相同的功能,以确保系统上线后不会有意外发生。但是否有必要进行这种大量的重复性质的测试,不过也是见仁见智的做法,要看测试管理者对测试策略与风险的平衡能力了。

      目前,大多数的测试都会在系统测试中完成,验收测试只是对于系统测试的回归。此种情况也是合理的,关键看测试周期与资源是否允许,以及各测试阶段的任务划分。

      第二层:待测软件的特性。不同的软件业务背景不同,所要求的特性也不相同,测试的侧重点自然也不相同。除了需要确保要求实现的功能正确,银行/财务软件更强调数据的精确性,网站强调服务器所能承受的压力,ERP强调业务流程,驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型,并将其列入测试需求当中。

      第三层:测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解,从而得出 的着重于某一方面的测试,如界面、业务流、模块化、数据、输入域等。目前关于各个焦点的测试也有不少的指南,那些已经是很好的测试需求参考了,在此仅列出业务流的测试分析方法。

  • 新工作

    2007-09-07 16:09:58

     

       来到新单位,有诸多的不适应,离家远,身体素质不适应,加上英语环境,来了新单位,没有一个人带,也不适应,诸多的不适应,现在也因迫不得已,慢慢的在适应,不过,现在也差不多适应了。

  • 心情驿站

    2007-07-26 18:15:57

    换工作了,离开了我喜欢的公司,不过也是迫于无奈。真舍不得离开公司啊,来到新公司,4天没有上51Testing就感觉好陌生啊,真是感觉一下子就落后,无奈,老了。。。。
  • 最近有点烦

    2007-07-12 09:49:32

    想换份自己喜欢的并且向往的工作,可是又舍不得离开这里的同事,朋友。郁闷。
  • LoadRunner 中如何进行关联

    2007-07-05 10:23:51

    http://zhidao.baidu.com/question/19338536.html

    为了避免该网页失效,内容粘贴如下,以备自己在做关联时遇到问题有所准备。该内容来自网络。

    什么是在 LoadRunner 脚本中做关联

    悬赏分:0 - 解决时间:2007-2-6 09:31
    网上的教程看不太懂,能否具体说说再什么情况下该做关联
    提问者: 想想_100 - 助理 二级
    最佳答案
    如何在 LoadRunner 脚本中做关联 (Correlation)
    当录制脚本时,VuGen会拦截client端(浏览器)与server端(网站服务器)之间的对话,并且通通记录下来,产生脚本。在VuGen的Recording Log中,您可以找到浏览器与服务器之间所有的对话,包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于,脚本只记录了client端要对server端所说的话,而Recording Log则是完整纪录二者的对话。

    当执行脚本时,您可以把VuGen想象成是一个演员,它伪装成浏览器,然后根据脚本,把当初真的浏览器所说过的话,再对网站伺服器重新说一遍,VuGen企图骗过服务器,让服务器以为它就是当初的浏览器,然后把网站内容传送给VuGen。
    所以纪录在脚本中要跟服务器所说的话,完全与当初录制时所说的一样,是写死的(hard-coded)。这样的作法在遇到有些比较聪明的服务器时,还是会失效。这时就需要透过「关联(correlation)」的做法来让VuGen可以再次成功地骗过服务器。
    何谓关联(correlation)?
    所谓的关联(correlation)就是把脚本中某些写死的(hard-coded)数据,转变成是撷取自服务器所送的、动态的、每次都不一样的数据。
    举一个常见的例子,刚刚提到有些比较聪明的服务器,这些服务器在每个浏览器第一次跟它要数据时,都会在数据中夹带一个唯一的辨识码,接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为Session ID。对于每个新的交易,服务器都会产生新的Session ID给浏览器。这也就是为什么执行脚本会失败的原因,因为VuGen还是用旧的Session ID向服务器要数据,服务器会发现这个Session ID是失效的或是它根本不认识这个Session ID,当然就不会传送正确的网页数据给VuGen了。
    下面的图示说明了这样的情形:
    当录制脚本时,浏览器送出网页A的请求,服务器将网页A的内容传送给浏览器,并且夹带了一个ID=123的数据,当浏览器再送出网页B的情求时,这时就要用到ID=123的数据,服务器才会认为这是合法的请求,并且把网页B的内容送回给浏览器。
    在执行脚本时会发生什么状况?浏览器再送出网页B的请求时,用的还是当初录制的ID=123的数据,而不是用服务器新给的ID=456,整个脚本的执行就会失败。

    要对付这种服务器,我们必须想办法找出这个Session ID到底是什么、位于何处,然后把它撷取下来,放到某个参数中,并且取代掉脚本中有用到Session ID的部份,这样就可以成功骗过服务器,正确地完成整个交易了。
    哪些错误代表着我应该做关联(correlation)?
    假如脚本需要关联(correlation),在还没做之前是不会执行通过的,也就是说会有错误讯息发生。不过,很不幸地,并没有任何特定的错误讯息是和关联(correlation)有关系的。会出现什么错误讯息,与系统实做的错误处理机制有关。错误讯息有可能会提醒您要重新登入,但是也有可能直接就显示HTTP 404的错误讯息。
    要如何做关联(correlation)?
    关联(correlation)函数
    关联(correlation)会用到下列的函数:
    • web_reg_save_param:这是最新版,也是最常用来做关联(correlation)的函数。
    语法:
    web_reg_save_param ( “Parameter Name” , < list of Attributes >, LAST );
    • web_create_html_param、web_create_html_param_ex:这二个函数主要是保留作为向前兼容的目的的。建议使用 web_reg_save_param 函数。
    详细用法请参考使用手册。在VuGen中点选【Help】>【Function reference】>【Contexts】>【Web and Wireless Vuser Functions】>【Correlation Functions】。
    如何找出要关联(correlation)数据
    简单的说,每一次执行时都会变动的值,就有可能需要做关联(correlation)。
    VuGen提供二种方式帮助您找出需要做关联(correlation)的值:
    1. 自动关联
    2. 手动关联
    自动关联
    VuGen内建自动关联引擎(auto-correlation engine),可以自动找出需要关联的值,并且自动使用关联函数建立关联。
    自动关联提供下列二种机制:
    • Rules Correlation:在录制过程中VuGen会根据订定的规则,实时自动找出要关联的值。规则来源有两种:
    o 内建(Built-in Correlation):
    VuGen已经针对常用的一些应用系统,如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等,内建关联规则,这些应用系统可能会有一种以上的关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】中启用关联规则,则当录制这些应用系统的脚本时,VuGen会在脚本中自动建立关联。
    您也可以在【Recording Options】>【Internet Protocol】>【Correlation】检视每个关联规则的定义。
    o 使用者自订(User-defined Rules Correlation):
    除了内建的关联规则之外,使用者也可以自订关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】建立新的关联规则。
    • Correlation Studio:有别于Rules Correlation,Correlation Studio则是在执行脚本后才会建立关联,也就是说当录制完脚本后,脚本至少须被执行过一次,Correlation Studio才会作用。Correlation Studio会尝试找出录制时与执行时,服务器响应内容的差异部分,藉以找出需要关联的数据,并建立关联。
    Rule Correlation
    请依照以下步骤使用Rule Correlation:
    1. 启用auto-correlation
    1. 点选VuGen的【Tools】>【Recording Options】,开启【Recording Options】对话窗口,选取【Internet Protocol】>【Correlation】,勾选【Enable correlation during recording】,以启用自动关联。
    2. 假如录制的应用系统属于内建关联规则的系统,如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等,请勾选相对应的应用系统。
    3. 或者也可以针对录制的应用系统加入新的关联规则,此即为使用者自订的关联规则。
    4. 设定当VuGen侦测到符合关联规则的数据时,要如何处理:
     【Issue a pop-up message and let me decide online】:跳出一个讯息对话窗口,询问您是否要建立关联。
     【Perform correlation in sceipt】:直接自动建立关联
    2. 录制脚本
    开始录制脚本,在录制过程中,当VuGen侦测到符合关联规则的数据时,会依照设定建立关联,您会在脚本中看到类似以下的脚本,此为BroadVision应用系统建立关联的例子,在脚本批注部分可以看到关联前的数据为何。

    3. 执行脚本验证关联是OK的。
    Correlation Studio
    当录制的应用系统不属于VuGen预设支持的应用系统时,Rule Correlation可能既无法发挥作用,这时可以利用Correlation Studio来做关联。
    Correlation Studio会尝试找出录制时与执行时,服务器响应内容的差异部分,藉以找出需要关联的数据,并建立关联。
    使用Correlation Studio的步骤如下:
    1. 录制脚本并执行
    2. 执行完毕后,VuGen会跳出下面的【Scan Action for Correlation】窗口,询问您是否要扫描脚本并建立关联,按下【Yes】按钮。

    3. 扫描完后,可以在脚本下方的【Correlation Results】中看到扫描的结果。

    4. 检查一下扫瞄的结果后,选择要做关联的数据,然后按下【Correlate】按钮,一笔一笔做,或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。
    注意:由于Correlation Studio会找出所有有变动的数据,但是并不是所有的数据都需要做关联,所以不建议您直接用【Correlate All】。
    5. 一般来说,您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前,将无法执行到后面需要做关联的部份。
    有可能有些需要做关联的动态数据,连Correlation Studio都无法侦测出来,这时您就需要自行做手动关联了。
    手动关联
    手动关联的执行过程大致如下:
    1. 使用相同的业务流程与数据,录制二份脚本
    2. 使用WinDiff工具协助找出需要关联的数据
    3. 使用web_reg_save_param函数手动建立关联
    4. 将脚本中有用到关联的数据,以参数取代
    接下来将详细的说明如何执行每个步骤
    使用相同的业务流程与数据,录制二份脚本
    1. 先录制一份脚本并存档。
    2. 依照相同的操作步骤与数据录制第二份脚本并存盘。注意,所有的步骤和输入的数据一定都要一样,这样才能找出由服务器端产生的动态数据。
    有时候会遇到真的无法使用相同的输入数据,那您也要记住您使用的输入数据,到时才能判断是您输入的数据,还是变动的数据。
    使用WinDiff工具协助找出需要关联的数据
    1. 在第二份脚本中,点选VuGen的【Tools】>【Compare with Vuser…】,并选择第一份脚本。
    2. 接着WinDiff会开启,同时显示二份脚本,并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本,并且以红色的字体显示真正差异的文字。(假如没看到红色字体,请点选【Options】>【View】>【Show Inline Differences】)。
    3. 逐一检视二份脚本中差异的部份,每一个差异都可能是需要做关联的地方。选取差异的脚本,然后复制。
    在复制时,有时并不需要取整行脚本,可能只会选取脚本中的一部分。
    注意:请忽略lr_thik_time的差异部份,因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间。

    4. 接着要在Recording Log(单一protocol)或是Generation Log(多重protocol)中找这个值。将鼠标光标点到Recording Log的第一行开头,按下Ctrl+F,开启【Find】窗口,贴上刚刚复制的脚本,找出在Recording Log第一次出现的位置。

    结果会有二种:
    o 在Recording Log中找不到要找的数据,这时请先确认您找对了脚本,毕竟现在开启了二个几乎一样的脚本,很容易弄错。
    o 在Recording Log中找到了要找的数据,这时要确认数据是从服务器端传送过来的。首先可以先检查数据的标头,从标头的Receiving response可以知道数据是从服务器端传送到client端的。假如此数据第一次出现是在Sending request中,则表示此数据是由client端产生,不需要做关联,但是有可能需要做参数化(parameterized)。
    您要找的标头格式如下:
    *** [tid=b9 Action1 2] Receiving response from host astra.merc-int.com:80 ( 25/11/2002 12:04:00 )

    5. 现在您已经找到录制二次都不一样,而且是由服务器所产生的动态数据了,而此数据极有可能需要做关联。
    使用web_reg_save_param函数手动建立关联
    在找到是由服务器所产生的动态数据之后,接下来要做的就是找出适当的位置,使用web_reg_save_param函数,将这个动态数据撷取到某个参数中。
    1. 要在哪里使用web_reg_save_param函数?
    在之前的步骤,我们已经在Execution Log找到可能需要关联的动态数据。在Execution Log中选取动态数据前的文字然后复制,我们将会利用这段文字,来帮助我们找出要关联的动态数据。

    不过在这之前我们要先找出使用web_reg_save_param函数的正确位置,所以我们要再重新执行一遍脚本,而且这次会开启所有的Log。
    1. 在VuGen中点选【Vuser】>【Run-Time Settings】。
    2. 点选【General】>【Log】。
    3. 勾选【Enable logging】、【Always sends messages】、【Extended log】,以及【Extended log】下的所有选项。
    4. 按下【OK】就可以执行脚本了。
    执行完脚本之后,在Execution Log中搜寻刚刚复制的字符串。找到字符串后,在字符串前面会有A.tion1.c(7),这个7就是到时候要插入web_reg_save_param函数的位置,也就是要插入到脚本的第7行。
    在脚本的第7行前插入一行空白行,然后输入
    web_reg_save_param(“UserSession”,
    “UserSession” 这个 “UserSession” 就是到时要使用的参数名称,建议给个有意义的名字。
    注意:到这里整个web_reg_save_param函数还没完成。

    2. 找出web_reg_save_param中要用到的边界
    web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串,来辨识要撷取的动态数据的,所以我们还需要找出动态数据的边界字符串。
    找出左边界字符串
    再回到Execution Log中,选取动态数据前的字符串并且复制它。
    这时会有个问题,到底要选取多少字符串才足以唯一识别要找的动态数据呢?建议是越多越好,但是尽量不要包含到特殊字符。
    在这边我们选取「input type=hidden name=userSession value=」字符串。选好之后,还要再确认一次这段字符串真的是可以唯一识别的,所以我们在Execution Log中透过Ctrl+F的搜寻,找找看这段字符串是否可以找到要找的动态数据。假如找不到,web_reg_save_param函数还有个ORD参数可以使用,ORD参数可以设定出现在第几次的字符串才是要找的字符串。
    将这个边界字符串加到未完成的web_reg_save_param函数中:
    web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”,
    找出右边界字符串
    接下来要找出动态数据的右边界字符串,这个字符串就比较好找了,从动态数据的最后一个字符开始,通常就是我们要找的右边界字符串了。
    以这个例子来看,就是「>」,所以再把右边界字符串加入,web_reg_save_param函数中,这时web_reg_save_param函数已经快完成了。最后再加上「LAST);」就完成整个web_reg_save_param函数了。
    web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”, “RB=>”, LAST);

    将脚本中有用到关联的数据,以参数取代
    当使用web_reg_save_param建立参数后,接下来就是用“UserSession”参数去取代脚本中写死的(hard-coded)资料。
    范例:

    “Name=userSession”, “Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf”, ENDITEM,
    换成
    “Name=userSession”, “Value={UserSession}”, ENDITEM,

    到这里您已经完成了一个关联了,接下来就是执行脚本,是否能成功运行,假如还是有问题,就要检查看看是否还需要再做另一个关联。
    关于 web_reg_save_param 函数
    对于关联(correlation)来说,web_reg_save_param是最重要的一个函数,其功能是在下载的网页内容中,透过设定的边界字符串,找出特定的数据并将其储存在一个参数中,以供后续脚本使用。
    接下来将针对web_reg_save_param做比较详细的说明。
    Service and registration type function
    web_reg_save_param是一个Service function。service function主要是用来完成一些特殊的工作的,如关联、设定proxy、提供认证信息等,当其作用时,不会对网页的内容做任何的修改。
    web_reg_save_param同时也是一个registration type function (只要函数名称中包含_reg_的字眼,表示其为registration type function)。registration type function意味着其真正作用的时机是在下一个action function完成时执行的。举例来说,当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据,则必须将web_reg_save_param放在此web_url之前,则web_reg_save_param会在web_url执行完毕后,也就是网页内容都下载完后,再执行web_reg_save_param找寻要做关联的动态数据并建立参数。
    所以要记住一点,要使用registration type function时,要注意其放置的位置必须在要作用的action function之前。
    语法
    int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);
    参数说明
    ParamName:存放动态数据的参数名称
    list of Attributes:其它属性,包含 Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, 以及 SaveLen。属性值不分大小写,例如 Search=all。以下将详细说明每个属性值的意义:
    • Notfound:指定当找不到要找的动态数据时该怎么处置。
    o Notfound=error:当找不到动态数据时,发出一个错误讯息。假如没设定此属性,此为LoadRunner的默认值。
    o Notfound=warning:当找不到动态数据时,不发出错误讯息,只发出警告,脚本也会继续执行下去不会中断。在对角本除错时,可以使用此属性值。
    • LB:动态数据的左边界字符串。此属性质是必须要有的,而且区分大小写。
    • RB:动态数据的右边界字符串。此属性质是必须要有的,而且区分大小写。
    • RelFrameID:相对于URL而言,欲搜寻的网页的Frame。此属性质可以是All或是数字,而且可有可无。
    • Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分,不搜寻header)、Noresource(只搜寻body部分,不搜寻header与resource)或是All(搜寻全部范围,此为默认值)。此属性质可有可无。
    • ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无,默认值是1。假如值为All,则所有找到符合的数据会储存在数组中。
    • SaveOffset:当找到符合的动态数据时,从第几个字符开始才开始储存到参数中。此属性质不可为负数,其默认值为0。
    • Convert:可能的值有二种:
    o HTML_TO_URL: 将HTML-encoded数据转成URL-encoded数据格式
    o HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式
    • SaveLen:从offect开始算起,到指定的长度内的字符串,才储存到参数中。此参数可有可无,默认值是-1,表示储存到结尾整个字符串。
    范例
    web_reg_save_param("A", "LB/ic=<a href=", "RB='>", "Ord=All", LAST);nner会搜寻网页中所有以 「<a href=」 开头,且以 「’>」结束,当中包含的字符串,并且储存在「A」参数中。
    Tips and Tricks
    以下提供一些关联的常见问题:
    • 如何打印出参数值?
    lr_output_message这二个函数来做到。例如:
    lr_output_message(“Value Captured = %s”, lr_eval_string(“{ParameterName}”));
    lr_eval_string与lr_output_message函数的使用说明请参考LoadRunner Online Function Reference。
    • 在脚本的data目录下找不到路制时的快照(snapshot)
    造成在脚本的data目录下找不到路制时的快照(snapshot)的可能原因如下:
    o 脚本是由VuGen 6.02或更早的版本所录制的
    o 汇入的Action不会包含快照(snapshot)的档案
    o 脚本是储存在只读的目录下,早成VuGen无法储存执行时撷取的快照(snapshot)
    o 某些步骤并不会产生快照(snapshot),如浏览某个资源
    o 快照(snapshot)功能被取消
    【Tools】>【General options】>【Correlation】tab >【Save correlation information during replay】
    • 开启WinDiff时出现「File no longer available」的错误讯息
    WinDiff这个工具有些限制,无法开启包含空格符的目录或是脚本,所以建议命名时不要使用空格符,并且尽可能将名称取短一点。
    • 录制时突然跳出【Correlation warning】对话窗口
    当你有勾选自动关联的【Issue a popup message and let me decide online】选项,当VuGen发现有可能要做关联的数据时,就会跳出【Correlation warning】的窗口,询问你要做关联(Correlation in scrīpt)还是要忽略(Ignore)。
    另外你也可以勾选【Perform correlation in scrīpt】,让VuGen自动作关联,不会再跳出询问窗口。
    或是勾选【Disable correlation engine】,关闭自动关联的功能。

    • 如何手动启动「Scan action for correlation」的功能
    要手动启动「Scan action for correlation」的功能,请先执行脚本一次后,点选【Vuser】>【Scan Action for Correlation】。

    • 执行完脚本后并未出现【Scan Action for Correlation】窗口
    要启用【Scan Action for Correlation】功能,
  • 正则表达式用法

    2007-06-19 09:28:41

    2007-06-18 15:10:29 / 个人分类:转贴

    正则表达式的概念

      什么是UBB代码?什么是正则表达式?

      UBB代码是HTML的一个变种。一般情况下,UBB论坛不允许你使用HTML代码,而只能用UBB代码替代HTML代码。
      UBB代码是一套由流行的UBB标签组成了固定代码,代码有统一的格式。用户只要遵循代码规则就可以实现用户想要的功能。如:
      想要显示粗体的how are you 字样,就应该输入 how are you而不是输入<b>how are you</b>

      你也许会问:ASP是怎样把 how are you转换为<b>how are you</b>的呢?
      回答这个问题就是:用正则表达式。

    三、正则表达式的用途

       有时我们在制作网站表单数据处理的时候,都需要进行数据验证和字符串替代,特别是UBB论坛要进行大量的数据安全性和字符串替代

    邮于一般的论坛不支持HTML语法这就使得用户不能修改字体,不能贴图等等一些功能。这样使得论坛失去了吸引用户的一个强有力的途径。可能说一个强大的论坛在吸引用户数量上还是很重要的。这样就出现了一个UBB解决方案,即在论坛不支持HTML语法的情况下用户仍然可以定制自已贴子的样式,贴图,增加链接,转贴网页等等诸多的功能,可能达到支持HTML语法同样的效果,而且这样可以使得论坛相对于HTML的论坛安全性大大提高。用户基本不能对论坛过行任何恶意攻击。

    四、正则表达式的语法规则和标记

      
      字符描述:

      ^符号匹配字符串的开头。例如:
        ^abc 与“abc xyz”匹配,而不与“xyz abc”匹配

      $符号匹配字符串的结尾。例如:
        abc$ 与“xyz abc”匹配,而不与“abc xyz”匹配。
        注意:如果同时使用^符号和$符号,将进行精确匹配。例如:
           ^abc$ 只与“abc”匹配   

      *符号匹配0个或多个前面的字符。例如:
        ab* 可以匹配“ab”、“abb”、“abbb”等

      +符号匹配至少一个前面的字符。例如:
        ab+ 可以匹配“abb”、“abbb”等,但不匹配“ab”。

      ?符号匹配0个或1个前面的字符。例如:
        ab?c? 可以且只能匹配“abc”、“abbc”、“abcc”和“abbcc”

      .符号匹配除换行符以外的任何字符。例如:
        (.)+ 匹配除换行符以外的所有字符串

      x|y匹配“x”或“y”。例如:
        abc|xyz 可匹配 “abc”或 “xyz”,而“ab(c|x)yz”匹配 “abcyz”和“abxyz”

      {n}匹配恰好n次(n为非负整数)前面的字符。例如:
        a{2} 可以匹配“aa“,但不匹配“a”

      {n,}匹配至少n次(n为非负整数)前面的字符。例如:
        a{3,} 匹配“aaa”、“aaaa”等,但不匹配“a”和“aa”。
        注意:a{1,}等价于a+
           a{0,}等价于a*

      {m,n}匹配至少m个,至多n个前面的字符。例如:
        a{1,3} 只匹配“a”、“aa”和“aaa”。
        注意:a{0,1}等价于a?

      [xyz]表示一个字符集,匹配括号中字符的其中之一。例如:
        [abc] 匹配“a”、“b”和“c”

      [^xyz]表示一个否定的字符集。匹配不在此括号中的任何字符。例如:
        [^abc] 可以匹配除“a”、“b”和“c”之外的任何字符

      [a-z]表示某个范围内的字符,匹配指定区间内的任何字符。例如:
        [a-z] 匹配从“a”到“z”之间的任何一个小写字母字符

      [^m-n]表示某个范围之外的字符,匹配不在指定范围内的字符。例如:
        [m-n] 匹配除从“m”到“n”之间的任何字符

      \符号是转义操作符。例如:
        \n 换行符
        \f 分页符
        \r 回车
        \t 制表符
        \v 垂直制表符

        \\ 匹配“\”
        \/ 匹配“/”

        \s 任何白字符,包括空格、制表符、分页符等。等价于“[ \f\n\r\t\v]”
        \S 任何非空白的字符。等价于“^\f\n\r\t\v]”
        \w 任何单词字符,包括字母和下划线。等价于“[A-Za-z0-9_]”
        \W 任何非单词字符。等价于“[^A-Za-z0-9_]”

        \b匹配单词的结尾。例如:
          ve\b 匹配单词“love”等,但不匹配“very”、“even”等

        \B匹配单词的开头。例如:
          ve\B 匹配单词“very”等,但不匹配“love”等

        \d匹配一个数字字符,等价于[0-9]。例如:
          abc\dxyz 匹配“abc2xyz”、“abc4xyz”等,但不匹配“abcaxyz”、“abc-xyz”等

        \D匹配一个非数字字符,等价于[^0-9]。例如:
          abc\Dxyz 匹配“abcaxyz”、“abc-xyz”等,但不匹配“abc2xyz”、“abc4xyz”等

        \NUM匹配NUM个(其中NUM为一个正整数),引用回到记住的匹配。例如:
          (.)\1 匹配两个连续相同的字符。

        \oNUM匹配n(其中n为一个小于256的八进制换码值)。例如:
          \o011 匹配制表符

        \xNUM匹配NUM(其中NUM为一个小于256的十六进制换码值)。例如:
          \x41 匹配字符“A”


    五、实例分析

    1)在字符串中精确查找链接地址

    ((http|https|ftp)\/\/|\\\\)((\w)+[.]){1,}(net|com|cn|org|cc|tv|[0-9]{1,3})(((\/[\~]*|\\[\~]*)
    (\w)+)|[.](\w)+)*(((([?](\w)+){1}[=]*))*((\w)+){1}([\&](\w)+[\=](\w)+)*)*)

    我们知道,链接地址一般以http或者https或者ftp等形式出现。初步总结一下就是,链接地址必须符合如下条件:

    条件1
     以http://或者https://或者ftp://等开头(当然还有其它形式,这里只列出主要的)

    条件2
     http://后面必须跟一个单词字符,紧接着单词字符后面的是"."(这样的组合必须出现一次或多次)。紧跟着“.”后面的是域名后缀(如net或者com或者cn等,如果是以IP地址的形式出现就可以是数字)

    条件3
     出现完整的链接地址后,还可以出现下一级或者更多级的目录(还要注意个人主页的地址有可能出现"~"符号)

    条件4
     链接地址末尾可以带参数。如典型的页数?PageNo=2&action=display等

    现在我们用下面的代码来逐个匹配上面的条件——

    1、((http|https|ftp)\/\/|\\\\) 满足条件1
    表示http:// http:\\ https:// https:\\ ftp:// ftp:\\都匹配(在这里考虑了某些用户可能把"//"输成“\\”的易发性错误)
    注意:"|"表示“或者”,"\"是转义字符。“\/\/”表示"//",“\\\\”表示"\\"

    2、((\w)+[.]){1,}(net|com|cn|org|cc|tv|[0-9]{1,3}) 满足条件2
    “((\w)+[.]){1,}”表示一个单词字符加一个点号可以出现1次或者多次(这里考虑了某些用户喜欢省略www而将http://www.w3c.com写成http://w3c.com
    “(net|com|cn|org|cc|tv|[0-9]{1,3})”表示必须要以net或者com或者cn或者org或者cc或者tv或者三位以下的数字结束
    [0-9]{1,3}表示三位以下的数字,因为ip地址的任何段不能超过255

    3、(((\/[\~]*|\\[\~]*)(\w)+)|[.](\w)+)* 满足条件3
    “(\/[\~]*|\\[\~]*)”表示可以出现"/~"或者是"\~",(其中“[\~]*”表示 ~ 可以出现也可以不出现),因为不是每个链接地址都有下一级目录
    “(\w)+)|[.](\w)+)”表示必须出现一个单词字符(即目录或者是一个带有扩展名的文件)
    注意:最后还有一个“*”表示上面括号内的可以出现也可以不出现,否则就只能匹配有下一级目录的链接地址了。

    4、(((([?](\w)+){1}[=]*))*((\w)+){1}([\&](\w)+[\=](\w)+)*)*)满足条件4
    “((([?](\w)+){1}[=]*))*((\w)+){1}”表示形如"?PageNo=2"的字符串可以出现也可以不出现,如果出现则只能出现一次(因为不可能有两个“?”号出现)。

    “([\&](\w)+[\=](\w)+)*)”表示形如“&action=display”的字符串可以出现也可以不出现(因为并不是每个网页都带有两个以上的参数。

    整个“((([?](\w)+){1}[=]*))*((\w)+){1}([\&](\w)+[\=](\w)+)*)*”表示形如“?PageNo=2&action=display”的字符串可以出现也可以不出现(即链接地址可以有参数也可以没有参数)


    把上面的组合起来,我们就可以匹配一个比较全面的链接地址了。比用简单的“(http:\/\/\S+)”来匹配一个链接地址要好,读者可以自行行测试比较。当然,这段代码还有很多不足之处,希望大家能够继续改进。

    2)替代典型的UBB标签:
    我们的目的就是要把成对的替换成<b></b>下面来看我们实现它的模板
      (\[b\])(.+)(\[\/b\])
    这里用了"(.+)"来配匹到之间的整个字符串,在替代的时候我们要写成这样
      str=checkexp(re,str,"<b>$2</b>"
    (注意:checkexp是我自定义的函数,将在后面给出。这个函数将把按照我们提供的模板进行替代。)

    也许你会问这里出现一个"$2"是什么东东,呵注意了这个$2可是很重要的,它代表了"(.+)"所配匹的整个字符串。
    为什么是$2而不是$1、$3呢?因为$1代表(\[b\])所匹配的""字符串,$3代表(\[\/b\])所匹配的""字符串,显然这里我们需要的是$2而不是$1$3。

  • 感慨

    2007-06-13 10:43:01

    今天看51论坛中的LoadRunner版块,感觉灌水的好多啊,稍微有点技术含量的就以附件上传上去,别人下载的时候就减少综合技术积分,这样真的很不厚道,以后真的有可能会成为灌水论坛了,为了增加自己的综合技术积分,会有好多的比如“顶”,“”,“DDD”......,我现在基本上不点附件,一是公司有代理下载不下来,二是感觉人越来越不厚道了,再就是可能对自己的帮助也不是很大。感慨一下,希望51的人能根据这种情况来改善一下手段,既能提高跟贴量,也能提高51的名气。
  • WScript.CreateObject和CreateObject 的区别

    2007-04-10 16:34:25

     

    首先要明白 Wscrīpt.CreateObjectCreateObject 的区别(转贴)
    前者的描述方式是基于windows来识别和调用的,所以假如你在一个vbs文件里这么描述,然后双击执行这个文件是没有问题,因为windows存在Wscrīpt这个对象,它遇到这个对象的时候会调用 C:\windows\system32\wscrīpt.exe 这个 应用程序去执行它。
    而后者则是不直接调用Wscrīpt这个对象来进行后期绑定WSH对象的。比如你在ASP中、QTP中,都必须用这个方式。因为ASP也好,QTP也好,里面都不存在Wscrīpt这个对象,所以你用Wscrīpt.CreateObject肯定会失败。

    明白了这个原因,你就很清楚为什么要这么写,该怎么修改了。

  • 关于计数器的解释

    2007-04-10 15:24:49

     
    计数器的解释(引用duola1119)
    Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁,说明内存不足。“页交换”是使用称为“页面”的单位,将固定大小的代码和数据块从 RAM 移动到磁盘的过程,其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存,也是可以接受的,但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况,请从以下的对象计数器开始:
    Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
    page/sec: 表明由于硬件页面错误而从磁盘取出的页面数,或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百,那么您应该进一步研究页交换活动。有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec 的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。
    page read/sec:页的硬故障,page/sec的子集,为了解析对内存的引用,必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
    由于过多的页交换要使用大量的硬盘空间,因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此,在研究内存不足不太明显的页交换的原因时,您必须跟踪如下的磁盘使用情况计数器和内存计数器:
    Physical Disk\ % Disk Time
    Physical Disk\ Avg.Disk Queue Length
    例如,包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。
    要确定过多的页交换对磁盘活动的影响,请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1,那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况,那么您可能需要更多的内存。
    Page Faults/sec:每秒软性页面失效的数目(包括有些可以直接在内存中满足而有些需要从硬盘读取)较page/sec只表明数据不能在内存的指定工作集中立即使用。
    Cache Bytes:文件系统缓存(File System Cache),默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时,它会自动整理缓存。需要关注该计数器的趋势变化
    如果您怀疑有内存泄露,请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes,以观察内存行为,并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露,则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。
    Pages per second :每秒钟检索的页数。该数字应少于每秒一页。
    Process:
    %Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
    Page Faults/sec:将进程产生的页故障与系统产生的相比较,以判断这个进程对系统页故障产生的影响。
    Work set: 处理线程最近使用的内存页,反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存,页就会被留在工作集中,当自由内存少于一个特定的阈值时,页就会被清除出工作集。
    Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低,则此计数器可以是内存泄漏的最佳指示器。Processor:监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息,帮助您决定是否存在瓶颈。
    %Processor Time:如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
    %User Time:表示耗费CPU的数据库操作,如排序,执行aggregate functions等。如果该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值。
    %Privileged Time:(CPU内核时间)是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM,减低"max async IO","max lazy writer IO"等措施都会降低该值。
    此外,跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值,而不是一段时间的平均值。
    % DPC Time:越低越好。在多处理器系统中,如果这个值大于50%并且Processor:% Processor Time非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。
    Thread
    ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小,你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数,这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高,就应该减小线程字节池的大小。
    Physical Disk:
    %Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%,则可能是内存泄漏。
    Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘。注意:一个Raid Disk实际有多个磁盘。
    Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
    Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加,应小于磁盘设备最大容量。
    Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
    Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
    Network Interface:
    Bytes Total/sec :为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较
    SQLServer性能计数器:
    Access Methods(访问方法) 用于监视访问数据库中的逻辑页的方法。
    . Full Scans/sec(全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高,应该分析你的查询以确定是否确实需要全表扫描,以及S Q L查询是否可以被优化。
    . Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
    Buffer Manager(缓冲器管理器):监视 Microsoft? SQL Server? 如何使用: 内存存储数据页、内部数据结构和过程高速缓存;计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。 监视 SQL Server 所使用的内存和计数器有助于确定: 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
    SQL Server 需要从磁盘读取数据的频率。与其它操作相比,例如内存访问,物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。
    .Page Reads/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大,可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,使开销减到最小。
    .Page Writes/sec (.写的页/秒) 每秒执行的物理数据库写的页数。
    .Buffer Cache Hit Ratio. 在“缓冲池”(Buffer Cache/Buffer Pool)中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后,这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多,一般希望这一数值高一些。通常,可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定,但比率最好为90% 或更高。增加内存直到这一数值持续高于90%,表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
    . Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
    Cache Manager(高速缓存管理器) 对象提供计数器,用于监视 Microsoft? SQL Server? 如何使用内存存储对象,如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。
    . Cache Hit Ratio(高速缓存命中率,所有Cache”的命中率。在SQL Server中,Cache可以包括Log Cache,Buffer Cache以及Procedure Cache,是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效,这是一个非常好的计数器。如果这个值很低,持续低于80%,就需要增加更多的内存。
    Latches(闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况,有助于查明性能瓶颈。
    . Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒)) 一个SQL Server线程必须等待一个闩的平均时间,以毫秒为单位。如果这个值很高,你可能正经历严重的竞争问题。
    . Latch Waits/sec (闩等待/秒) 在闩上每秒的等待数量。如果这个值很高,表明你正经历对资源的大量竞争。
    Locks(锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。例如,如果一个排它 (X) 锁被一个事务加在某一表的某一行上,在这个锁被释放前,其它事务都不可以修改这一行。尽可能少使用锁可提高并发性,从而改善性能。可以同时监视 Locks 对象的多个实例,每个实例代表一个资源类型上的一个锁。
    . Number of Deadlocks/sec(死锁的数量/秒) 导致死锁的锁请求的数量
    . Average Wait Time(ms) (平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
    . Lock Requests/sec(锁请求/秒) 每秒钟某种类型的锁请求的数量。
    Memory manager:用于监视总体的服务器内存使用情况,以估计用户活动和资源使用,有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定:
    是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL Server 必须从磁盘检索数据。
    是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
    Lock blocks:服务器上锁定块的数量,锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
    Total server memory:sql server服务器当前正在使用的动态内存总量.
    监视IIS需要的一些计数器
    Internet Information Services Global:
    File Cache Hits %、File CacheFlushes、File Cache Hits
    File Cache Hits %是全部缓存请求中缓存命中次数所占的比例,反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站,该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值,File CacheFlushes 是自服务器启动之后文件缓存刷新次数,如果刷新太慢,会浪费内存;如果刷新太快,缓存中的对象会太频繁的丢弃生成,起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值,可以得到一个适当的刷新值(参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize)
    Web Service:
    Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
    Connection Refused:数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
    Not Found Errors:显示由于被请求文件无法找到而无法由服务器满足的请求数(HTTP状态代码404)
  • 录制一些键盘操作的语句

    2007-04-04 15:32:10

    在测试过程之,可能会录制一些需要键盘操作的语句,比如回车键,此时可以采用类似下面的语句

    用回车键查询
    Browser("用回车键查询
    Browser("系统登录").Page("贵阳市新型农村合作医疗信息管理系统").Frame("main").WebEdit("ylzh").FireEvent("onfocus")//定位鼠标焦点的位置
    set WshShell =CreateObject("Wscrīpt.Shell")
    WshShell.SendKeys "{ENTER}"系统登录").Page("贵阳市新型农村合作医疗信息管理系统").Frame("main").WebEdit("ylzh").FireEvent("onfocus")
    set WshShell =CreateObject("Wscrīpt.Shell")//创建键盘事件
    WshShell.SendKeys "{ENTER}"//按回车

  • QTP的登陆脚本设计(转贴)

    2007-04-04 14:29:43

  • 基于C/S结构的应用程序的性能测试(转)

    2007-04-03 13:40:22

  • 性能测试及性能调整概述(转贴)

    2007-04-03 13:32:56

    明确了具体的性能要求后,可以开始进行测试,确定应用程序是否满足这些要求。性能测试假定应用程序稳定、可靠地运行。因此,在测试中消除尽可能多的变数很重要。例如,代码中的错误可以导致出现性能问题,甚至掩盖性能问题。要精确地比较不同性能测试的结果,应用程序必须正确地工作。如果调整过程修改了组件的实现,则重新测试应用程序的功能尤其重要。应用程序必须通过功能性测试后才可以测试性能。除了应用程序更改外,硬件、网络通信量、软件配置、系统服务等诸多方面也会发生意外的更改。控制应用程序更改很重要。

    测量性能

    要正确地调整性能,必须准确完整地记录每次测试的结果并进行维护。记录应包括:

    • 精确的系统配置,尤其是与前几次测试的不同之处
    • 原始数据和性能监视工具计算的结果

    这些记录不仅指示应用程序是否达到性能目标,而且有助于识别未来性能问题的潜在原因。

    性能调整是与性能管理相关的主要活动。当性能降到最基本的水平时,性能调整由查找和消除瓶颈组成,瓶颈是在服务器中的某个硬件或软件接近其容量限制时发生和显示出来的情况。

    在开始性能调整循环之前,必须做一些准备工作,为正在进行的性能调整活动建立框架。您应该:

    • 识别约束 - 站点的业务实例确定优先级,而优先级又设立边界。约束(如可维护性和预算限制)在寻求更高的性能方面是不可改变的因素。必须将寻求性能提高的努力集中在不受约束的因素上。
    • 指定负载 - 这涉及确定站点的客户端需要哪些服务,以及对这些服务的需求程度。用于指定负载的最常用度量标准是客户端数目、客户端思考时间以及负载分布状况;其中客户端思考时间是指客户端接收到答复到后面提交新请求之间的时间量,负载分布状况包括稳定或波动负载、平均负载和峰值负载。
    • 设置性能目标 - 性能目标必须明确,包括识别用于调整的度量标准及其对应的基准值。总的系统吞吐量和响应时间是用于测量性能的两个常用度量标准。识别性能度量标准后,必须为每个度量标准建立可计量的基准值与合理的基准值。 51testing软件测试博客:j*r^p|ej!h"^
      注意   由于性能和容量的关系如此密切,因此您识别的约束、负载和目标也适用于容量规划。

    建立了性能调整的边界和期望值后,可以开始调整循环,这是一系列重复的受控性能试验。

    调整循环

    重复以下所示的四个调整循环阶段,直到获得在开始调整过程前建立的性能目标。

    调整循环

    收集

    收集阶段是任何调整操作的起点。在此阶段,只是使用为系统特定部分选择的性能计数器集合来收集数据。这些计数器可用于网络、服务器或后端数据库

    不论调整的是系统的哪一部分,都需要根据基准测量来比较性能改变。需要建立系统空闲以及系统执行特定任务时的系统行为模式。因此,可以使用第一遍数据收集来建立系统行为值的基准集。基准建立在系统的行为令人满意时应该看到的典型计数器值。

    注意   基准性能是一个主观的标准:必须设置适合于工作环境且能最好地反映系统工作负荷和服务需求的基准。

    分析

    收集了调整选定系统部分所需的性能数据后,需要对这些数据进行分析以确定瓶颈。记住,性能数字仅具有指示性,它并不一定就可以确定实际的瓶颈在哪里,因为一个性能问题可能由多个原因所致。某个系统组件的问题是由另一系统组件的问题导致的,这种情况也很普遍。内存不足是这种情况的最好示例,它表现为磁盘和处理器使用的增加。

    以下几点来自“Microsoft Windows 2000 资源工具包”,提供了解释计数器值和消除可能导致设置不适当的调整目标值的错误数据或误导数据的指南。

    • 监视名称相同的进程 — 监视某个实例而没有监视另一个实例的异乎寻常大的值。有时,系统监视器将多个实例的组合值报告为单个实例的值,这就错误地报告了同名进程的不同实例的数据。可通过按进程标识符对进程进行跟踪来解决此问题。
    • 监视多个线程 - 当监视多个线程而其中一个线程停止时,一个线程的数据可能似乎被报告成了另一个线程的数据。这是由于线程的编号方式所导致的。可通过将进程线程的线程标识符包含在日志或显示中来解决此问题。为此,请使用“线程/线程 ID”计数器。
    • 数据值中的不连续峰值 - 不必太重视数据中偶尔的峰值。这些峰值可能是由于进程的启动,并不是该进程随时间改变的计数器值的准确反映。尤其是平均计数器可以导致峰值随时间停留的效果。
    • 监视一段延长的时期 - 建议使用图形代替报告或直方图,因为后两种视图仅显示最后的值和平均值。结果,当查找峰值时,可能得不到这些值的准确反映。
    • 排除启动事件 - 除非有特殊的原因需要将启动事件包含在数据中,否则排除这些事件,因为它们产生的临时性高峰值往往歪曲了整体性能结果。
    • 零值或缺少的数据 - 调查所有出现的零值或缺少的数据。这些零值或缺少的数据会妨碍建立有意义的基准。

    配置

    收集了数据并完成结果分析后,可以确定系统的哪部分最适合进行配置更改,然后实现此更改。

    实现更改的最重要规则是:一次仅实现一个配置更改。看起来与单个组件相关的问题可能是由涉及多个组件的瓶颈导致的。因此,分别处理每个问题很重要。如果同时进行多个更改,将不可能准确地评定每次更改的影响。

    测试

    实现了配置更改后,必须完成适当级别的测试,确定更改对调整的系统所产生的影响。在这一点上,这是确定更改是否有如下影响的问题:

    • 性能提高 - 更改提高了性能吗?如果是,提高了多少?
    • 性能下降 - 更改在其他位置导致了瓶颈吗?
    • 对性能没有影响 - 更改对性能到底有何显著的影响?

    如果幸运,性能提高到预期的水平,这时便可以退出。如果不是这样,则必须重新逐步进行调整循环。

    提示   可以从监视日志文件(可导出到 Microsoft Excel)和事件日志中获取测试所产生的监视结果。

    测试时务必要:

    • 检查用于测试的应用程序的正确性和性能,查找内存泄漏和不正常的客户端请求响应延迟。
    • 确保所有测试都正常进行。
    • 确保可以使用相同的事务混合和相同的客户端生成相同的负载来重复所有测试。
    • 文档更改和结果。

    在每遍测试中,运行一系列完全相同的性能测试;否则,无法分辨不同的结果是由于测试中的改动还是应用程序更改造成的。使尽可能多的性能测试操作自动进行有助于消除因操作者造成的差异。

    其他表面上是良性的因素影响性能测试的结果,如应用程序在测试开始前运行的时间。正如冷的汽车引擎与热引擎的性能不同,长时间运行的应用程序由于内存碎片这样的因素,其性能可能与刚启动的应用程序不同。

    定义性能测试

    性能测试期间,测量和记录性能目标中指定的度量标准值。达到全部性能度量标准(如思考时间、事务混合等)很重要。在这些约束下,测试应尽可能实际。例如,对应用程序进行测试,确定它在许多客户端同时访问它时的性能。多线程测试应用程序可以用可复制的方式模拟多个客户端,每个线程表示一个客户端。如果应用程序访问数据库,则数据库应包含实际数目的记录,并且测试应使用数据项的随机(但有效)值。如果测试数据库太小,数据库服务器的缓存效果将产生不符合实际情况的测试结果。如果输入或访问数据的方式不符合实际情况,则结果也可能不符合实际情况。例如,在主键上按字母顺序创建新数据是不太可能的。

    通常,测试装置必须接受用户指定的输入参数,如事务混合、思考时间、客户端数目等。然而,测试装置本身可以规定创建实际的随机数据的规则。

    创建了驱动应用程序的测试装置后,应该将所有运行测试的不变条件记入文档。最起码,这些条件应包括运行测试装置所需的输入参数。另外,应将如何设置运行测试的数据库记入文档。说明中应指定数据库不应包含前一遍测试所做的更改。说明中还应指定用于测试的计算机配置。在不同于应用程序所在的另一台计算机上运行测试装置,因为这样设置更接近生产环境。

    确定基准性能

    确定了性能目标并制定了性能测试后,运行一次测试以建立基准。验证环境与生产环境越相似,应用程序部署后的性能令人满意的可能性就越大。因此,一开始有一个符合实际情况的验证环境很重要。

    幸运的话,基准性能将符合性能目标,并且应用程序不需要任何调整。但更可能的情况是,基准性能不令人满意。然而,记录初始测试环境和基准结果可以为调整工作提供坚实的基础。

    压力测试

    压力测试是性能测试的一种专门形式,它与其他工程领域的破坏性测试相似。压力测试的目的是使应用程序产生故障,通过增加处理负载使其超过性能的降低,直到由于资源饱和或发生错误而使应用程序开始出问题。压力测试有助于揭示细微的错误,这些错误本来要到部署应用程序时才会被发现。由于此类错误通常是因设计缺陷所致,压力测试应该早在开发阶段便在应用程序的每个区域上开始进行。在其源头修复这些细微的错误,而不是忽视这些错误,直到它们可能在应用程序中的其他位置表现出症状时才修复它们。

    解决性能问题

    通常可将性能问题归结于不止一个因素。因此,查找性能恶化的解决方案与进行科学实验极为相似。科学实验传统上遵循一个分六步进行的过程,包括观察、初步假设、预测、测试、控制和结论。结论由该过程积累的最佳证据集合所支持的假设组成。可以遵循同样的过程来解决性能问题。

    当观察到 ASP 应用程序的性能比期望的低时,您假定 ASPProcessorThreadMax 元数据库属性设置得太低。当“ASP 排队请求”性能计数器上下移动,并且处理器的运行效率低于 50% 时,可能会发生这种情况。您预测增加 ASPProcessorThreadMax 元数据库属性的数值可以提高性能。

    活动线程设置现在已经变成控件。一次仅进行一个设置更改,直到观察到满意的性能改变。如果在几次调整 ASPProcessorThreadMax 元数据库属性之后获得了更令人满意的性能,则结论是某个属性设置与所有当前变量(所需内存的总量、正在运行的应用程序数、已升级的软件等)组合,可提供最佳服务器性能。变量中的任何更改就会形成进一步的实验。

     

    源文档 <http://www.51testing.com/html/8/640.html>

  • 性能测试之协议分析(转贴)

    2007-04-03 13:30:39

     

    最近在论坛上的一些朋友问脚本方面的问题,比如用lr的winsock协议录制的脚本遇回放过程中遇到如下错误

    Action.c(20): Error : callConnect - Can't assign requested address. Error code : 10049.

    Action.c(20): Error : Timeout expired while trying to connect. Error code : 9017.

    这里的10049是udp协议错误,是脚本没有和服务器同步,这说明什么问题呢。下边我用一个协议进行分析,来看看到底是什么问题,

    smtp协议分析:

    1.SMTP工作方式有两种情况:一是电子邮件从客户机传输到服务器;二是从某一个服务器传输到另一个服务器.

    2.SMTP是个请求/响应协议,命令和响应都是基于ASCII文本,并以CR和LF符结束。响应包括一个表示返回状态的三位数字代码.

    3.SMTP在TCP协议25号端口监听连接请求

    4.连接和发送过程:

    a.建立TCP连接

    b.客户端发送HELO命令以标识发件人自己的身份,然后客户端发送MAIL命令

    服务器端正希望以OK作为响应,表明准备接收

    c.客户端发送RCPT命令,以标识该电子邮件的计划接收人,可以有多个RCPT行

    服务器端则表示是否愿意为收件人接受邮件

    d.协商结束,发送邮件,用命令DATA发送

    e. 以.表示结束输入内容一起发送出去

    f.结束此次发送,用QUIT命令退出。

    5.另外两个命令:

    VRFY---用于验证给定的用户邮箱是否存在,以及接收关于该用户的详细信息。

    EXPN---用于扩充邮件列表。

    6.邮件路由过程:

    SMTP服务器基于‘域名服务DNS中计划收件人的域名来路由电子邮件。SMTP服务器基于DNS中的MX记录来路由电子邮件,MX记录注册了域名和相关的SMTP中继主机,属于该域的电子邮件都应向该主机发送。

    若SMTP服务器mail.withub.org收到一封信要发到pcl@withub.org

    a.Sendmail请求DNS给出主机withub.org的CNAME记录,如有,假若CNAME到mail.withub.org,则再次请求mail.withub.org的CNAME记录,直到没有为止.

    b.假定被CNAME到mail.withub.org,然后sendmail请求@withub.org域的DNS给出mail.withub.org的MX记录,

    shmail MX 5 mail.withub.org

    10 shmail2.withub.org

    c. Sendmail最后请求DNS给出shmail.withub.org的A记录,即IP地址,若返回值为1.2.3.4

    d. Sendmail与1.2.3.4连接,传送这封给pcl@withub.org的信到1.2.3.4这台服务器的SMTP后台程序

    这里是协议的一个解析过程,我们要看看,利用lr录制脚本后然后回放,录制的过程中mail.withub.org返回客户端服务器上有多少给用户的邮件,lr把这个数字保存下来,最为下次回放的时候对比。当你第二次回放的时候,lr模拟客户端发送请求,这时候服务器上没有了新邮件,返回可能是0,lr把这个返回值和当时录制的脚本保存的返回值进行对比(那个时候可能服务器上有3个新的邮件,服务器返回的值是3),明显这个值是动态变化的。你的脚本如果没有经过修改,肯定是回返不成功的。

    那么上边提到的错误信息,同样的道理,我们要分析一下到底是什么问题,从协议上分析,从系统环境上分析。

    解决方法,动态关联

    1.用同样的用户操作同样的步骤两次,然后用lr工具wdiff进行脚本对比,找出不同的地方!

    2.用lr自动关联

    3.手工关联,找到要替换的动态数据进行替换

     

    源文档 <http://www.51testing.com/html/8/1094.html>

381/212>
Open Toolbar