西西,留个测试的空间,新任务项目测试中 ................

发布新日志

  • 坚持软件开发,兼职做测试

    2007-05-24 20:22:15Top 1 Digest 1

     

         才刚刚开始做开发,还是非常喜欢做开发的。但是,由于进入的是一家不太正规的IT公司,所以,偶也成了一个不太正规的人。最近项目结束了,给了偶一个新任务,测试。可能因为自己是女生的缘故吧,谁知道呢?

         不过,有机会学习测试,也是不错的。老板说,以后有可能你就转向做测试,反正公司正好没有测试。他说他的,偶做我的。研究了两天的测试。还好搜索的时候,遇到了51testing这么好的测试交流地,感谢网络,感谢百度啊,还有感谢这两天来路遇的一些网络上的朋友,基本上已经入门了,初步简单地应用了下LoadRunner这个工具。但是,要深入还是需要年限了,况且自己没有测试方面的理论知识基础,要做测试没那么简单的事。还是坚持软件开发,兼职做测试。

  • LoadRunner 11性能测试环境搭建过程

    2015-03-13 15:50:32

    因项目需要,又有机会玩这个LR。与LR也算是有缘。领导下发任务的时候,还是有点小担心的,因为没有搭建过,所以心里没什么底。还好有51Testing,搭建过程的很多问题,都在这里找到答案了。汇总分享下。

    压测环境:

    有三台机子,都是windows系统。

    打算1台做控制机,录制脚本运行场景等,所以这台是全量安装。

    2台机子做负载机,只安装Load generator。

     

    1.软件

    在这个贴子里http://bbs.51testing.com/thread-484964-1-1.html

    HP LoadRunner 11下载地址

    http://www.genilogix.com/downloads/loadrunner/loadrunner-11.iso

    2.安装过程

    就是点这个界面上的按钮,按提示一步步走下去

    3.负载机设置及错误解决办法

    负载机的LoadRunner Agent Process 启动了,还是报以下错误:

    Failed to connect to the agent.
    Load Generator not responding after timeout
    Command line that was executed:
    -usr ..\dat\lr_trans_server.usr -lnch_interactive   -controllerhost "WIN-A6JC9OPII8V" -bridge -monitor_parent -extra_ext time_diff_ext -no_exception  -eve_file_version 3 -drv_log_file_under_cntrl lr_bridge.log -working_lang 0 -es_unique_id 3 -extra_ext SummaryDataTransExt -trans_server_extra_ext SummaryDataTransExt -trs_online_mode 0 -trs_timer_duration 5  -out_communication 0 -extra_ext LrHostBalance -supply_netdir -base_temp_dir "192.168.167.8" -extra_ext mft_server -lnch_priority normal -no_popups -lnch_interactive  -lnch_registry_key "HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner\CurrentVersion\RuntimeEnvironment"  -product_name "LoadRunner" -lnch_dont_remove_until_notify 
     
    最后的解决办法:
    我已经解决了,我实际验证验证过的,你到防火墙设置里面“允许程序和功能通过windows防火墙”,然后添加Loadrunner Agent Procss,到列表中,在“专用”和“公用”打勾,然后重启一下LR和Loadrunner Agent Procss就OK了,我试验过是可以的。
     
     
    这个编写软件太难用了,不写了。
     
     

     

     

     

     

     

     
  • 7年轮回

    2014-07-02 22:19:06

    7年前,我一定不会想到,7年后的现在,我又有机会玩LoadRunner.

    如果没有7年前的那一次无意的接受任务,也许也不会有今天的机会吧。


    机会不会等你。而是你自己要准备好最好的自己,随时去迎接机会。


    7年前,现在回想,真的玩的只是皮毛而已。

    这次,希望可以是一次进阶。从脚本录制,到修改脚本,实现动态,以及场景设置,场景负载的添加,再到分析。一路走下来,挺不容易的。

    为自己加油。
  • 软件测试之“软件测试用例设计原则”

    2011-06-28 15:39:53

      不管是从个人角度还是从公司角度,根据我这几年的经验我觉得case的设计应该符合以下几点:

      1、一个case一个功能点:每个case都要有个测点,找准一个测点则可,不能同时覆盖很多功能点,否则执行起来牵连太大;
      2、case的易读:从执行者的角度去写case,最好不要有太多的术语在里面,如果要有最好指明具体位置;
      3、case的执行粒度:粒度越小越好;软件
     
      4、步骤清晰:一个case多个步骤,可一个重点,步骤指名人们怎么去操作,expect则指明这样操作之后应该看到什么结果---最好不要用正确,正常,错误之类的含糊主观的字眼。
     
      5、总体设计:先正常,后异常,这样可以确保正常情况下功能能够走通。
      总之:对于一个新来的tester,给他个case和我们的软件,他就能顺利取执行case,这是最佳状态,也是我们case设计的标准,按照这个标准,我想出了以上几点要求。

      这样做的好处是:
     
      1、执行者不会因为case看不懂再三的去烦扰你,你也不会因为时间长了,业务忘了,看不懂case;
      2、如果原来的designer有事,公司可以很快请人顶上,测试可以继续进行,不会被block住;
      3、执行case的人能更快的去掌握业务系统流程,不会因为要看懂一个case而大伤脑筋,更别说去真正的执行它了。

      那么对于日常软件测试每个新功能,我们该怎么去构筑我们坚固的质量堡垒呢。
     
      根据开发过程的特点,总结了我们设计测试用例六个方面。
      一、功能

      关注页面单个功能点验证,充分考虑开发改动的每个点。这个是保证开发每个已知的修改点都能改对。

      二、关联
      重点考虑修改点对其他模块的影响,包括代码的影响和操作数据引起的影响。
      比如新增加的功能增加了数据库表的字段,必须关联的验证每个使用该表的该字段的模块是否正常工作。难点在于需要分析出已知和未知的影响模块,考虑的越多,往往遗漏的问题就越少。 
      三、流程
     
      很多系统是有流程的,比如工作流系统。当修改了一个点的时候,我们必须考虑整个流程是否能够正常运转起来。
      四、升级 
       我们大部分系统都是对已有的系统进行升级。对于升级前的数据,我们必须保证能够正常工作。升级之前,需要模拟好各种情况。也需要对升级的数据库脚本进行充分的检查。
     
      五、安全
      比如菜单功能权限等。

      六、性能
    http://www.ltesting.net/ceshi/ceshijishu/csyl/2011/0621/202716.html
     
  • 基于Web的系统测试方法

    2007-05-25 14:21:09

    摘要

      随着Internet和Intranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。范围广泛的、复杂的分布 式应用正在Web环境中出现。Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。

      Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科,提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则,用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前,对于web工程的研究主要是在国外开展的,国内还刚刚起步。

      在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机。并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

      在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

      一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

      一、功能测试

      1、链接测试

      链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

      链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

      2、表单测试

      当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

      3、Cookies测试

      Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

      如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

      4、设计语言测试

      Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

      5、数据库测试

      在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

      在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

    二、性能测试

      1、连接速度测试

      用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

      另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

      2、负载测试

      负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

      3、压力测试

      负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

      进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

      压力测试的区域包括表单、登陆和其他信息传输页面等。

      三、可用性测试

      1、导航测试

      导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

      在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

      导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

      Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

      2、图形测试

      在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

      (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

      (2)验证所有页面字体的风格是否一致。

      (3)背景颜色应该与字体颜色和前景颜色相搭配。

      (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。

      3、内容测试

      内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

      信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。

      4、整体界面测试

      整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

      对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

    四、客户端兼容性测试

      1、平台测试

      市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

      因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

      2、浏览器测试

      浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Netscape的产品,Java是Sun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

      测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

      五、安全性测试

      Web应用系统的安全性测试区域主要有:

      (1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。

      (2)Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

      (3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

      (4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。

      (5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

      六、总结

      本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

      基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。

  • 测试工具搜藏

    2007-05-25 09:11:32

    整理下,这两天搜罗的的工具资料.网络,给了人无限的可能,共享,让这个世界越来越大.感谢网络,感谢人间,感谢人类,感谢51testing.呵呵.

    LoadRunner 8.0 (工业级测试工具):
    Mercury LoadRunner 是一种预测系统行为和性能的工业级标准性能测试负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。


    目前企业的网络应用环境都必须支持大量用户,网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢,系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的LoadRunner能让企业保护自己的收入来源,无需购置额外硬件而最大限度地利用现有的IT资源,并确保终端用户在应用系统的各个环节中对其测试应用的质量,可靠性和可扩展性都有良好的评价。

    LoadRunner 是一种适用于各种体系架构的“负载测试工具”,它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。此外,LoadRunner能支持广泛的协议和技术,为您的特殊环境提供特殊的解决方案365dn电脑硬件站

    讯雷上的LoadRunner资源:

    http://so.xunlei.com/search?search=LoadRunner8&id=3

    电驴的8.0资源.

    http://lib.verycd.com/2005/10/01/0000067173.html

    搜罗下,万象世界便尽收眼底.要学的东西,真多啊!

    LoadRunner测试流程

    1 制定负载测试计划
    (分析应用程序, 确定测试目标,计划怎样执行LoadRunner)
    2 开发测试脚本
    (录制基本的用户脚本,完善测试脚本)
    3 创建运行场景
    (选择场景类型为Manual Scenario,选择场景类型,理解各种类型,场景的类型转化)
    4 运行测试
    5 监视场景
    (MEMORY 相关,PROCESSOR相关,网络吞量以及带宽,磁盘相关,WEB应用程序 ,IIS5.0,SQL SERVER,NETWORK DELAY等)
    6 分析测试结果
    (分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有用的功能)

  • 测试测试

    2007-05-24 08:44:52

     

        这周的任务,项目测试.于是,偶在这里成长中。

Open Toolbar