51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: 默默巫
打印 上一主题 下一主题

[你问我来答第5期]:自动化测试如何帮助我们?(已结束)

[复制链接]

该用户从未签到

101#
发表于 2010-11-1 22:38:42 | 只看该作者
请教专家一个问题:近期在做一个项目遇到一个问题:使用python中的telnetlib库Telnet到一设备上后,使用其中write()执行相关命令后,调用一程序,进入另一种命令模式下,如Linux的isp>,无法再用write()写命令,怎么解决?
回复 支持 反对

使用道具 举报

该用户从未签到

102#
发表于 2010-11-2 10:10:29 | 只看该作者
现在公司有个任务,50个用户同时登陆一个地图网页,并能查看到这个地图的图片,并要保存这些图片到本地~
注:每个用户登陆到这个网页,服务端会生成一个临时图片供用户查看,也就是说,50个用户同时登陆的时候,查看的是不同的图片。

录制源码如下,请高手赐教:

/*这个是域验证用户名和密码,登陆到网页
web_set_user("tgms\\{user}",
                lr_decrypt("{pass}"),
                "192.0.1.124:80");
/*请求的是这个URL
web_url("data.asp","URL=http://192.0.1.124/gisrct/data.asp?clientMapWidth=822&clientMapHeight=414",
                "Resource=0",
                "RecContentType=text/html",
                "Referer=",
                "Snapshot=t1.inf",
                "Mode=HTML",
                EXTRARES,
"URL=images/TGMS.gif", "Referer=http://192.0.1.124/gisrct/data.asp?clientMapWidth=822&clientMapHeight=414", ENDITEM,

/*就是生成的这张图片名,要求保存到本地,最终50个用户取图片
"URL=http://webgissrv/output/SDEGIS_WEBGISSRV20362592484.png", "Referer=http://192.0.1.124/gisrct/data.asp?clientMapWidth=822&clientMapHeight=414", ENDITEM,

"URL=images/pixel.gif", "Referer=http://192.0.1.124/gisrct/data.asp?clientMapWidth=822&clientMapHeight=414", ENDITEM,
                LAST);

急啊急,请高手赐教
回复 支持 反对

使用道具 举报

该用户从未签到

103#
发表于 2010-11-3 17:20:34 | 只看该作者
您好~ 我最近在做一个web的项目测试,考虑使用 Selenium 这个测试工具,学习了基本的使用后,感觉工具提供的功能比较多,但是不知道具体项目如何入手,考虑主要使用RC 不知道您是否有这方面的经验和好的建议。谢谢~
回复 支持 反对

使用道具 举报

该用户从未签到

104#
发表于 2010-11-3 17:54:32 | 只看该作者
专家你好,下面是我一家公司工作了大半年关于单元测试的一些描述。我想请教的是,在发生了一下的情景后,怎么开展单元测试?

在上半年的时候,公司有两个项目在进行开发,作为公司招进去的第一个测试人员,在这两个项目进行中间,我加入公司,担任测试的工作,最初,给程序员们做了时间比较短的测试培训,重点在测试的理念和测试用例的设计上。
开发经理与我我当时商量的测试策略是,当他们的每一个迭代完成,就写本迭代的测试用例,然后开发者交换着测试,将发现的缺陷提交到mantis,采取的是手工测试的策略。
这种方式经过总结,
缺点是:
1、        测试的管理过程很复杂,因为我们的目的是想看到程序员们的测试过程,所以得要在测试中记录下所有的活动,这样的话,他们花费很多精力在测试上;
2、        前期每个单元的功能测试时每个人自己做的,后期我再次组织其他的人员三轮的系统测试,手工用例的书写和执行很花时间
优点是:
1、        这种测试的方式难度不大,对于刚毕业的大学生易于掌握
2、        缺陷发现的几率比较高,每天开发经理的邮箱都会受到许多邮件被告知是什么样的缺陷

针对上面的缺点,开发与测试者都认为是不是可以采取更有效的方式来提高测试的效率?所以,在下半年的另一个我们采用了junit来做单元测试,希望能够通过单元测试将缺陷早点解决,而不是等到系统测试的时候再来修改,因为测试与开发开展了如下工作:
1、        测试组为开发组的成员进行单元测试的培训,主要是讲在ssh下junit的使用;
2、        为了便于单元测试的开展,开发者将整个应用的框架进行的梳理
3、        开发组一共编写了700-800个单元测试用例,用junit实现,用Ant生成了单元测试报告,用emma完成了对测试覆盖率的统计
但是在上面的单元测试完成后,发现又有问题出现了:
1、        开发者费了很大的劲在框架之下进行了JUnit测试代码的编写
2、        用例的数量看上去很多,但是质量不好
3、        最致命的一点是,使用JUnit进行单元测试,发现缺陷的效率却明显的降低了
这样的结果是测试与开发都没有想到的,分析其中的原因有如下:
1、        开发者将单元测试的重心放在了编写测试代码上,而非测试用例设计上,测试用例的数量比较多,但是一般,开发者测试的数据一般都是不太会出错的数据
2、        当单元测试的代码写出来后,没有进行精简性的重构,导致测试代码的冗余度非常大,可读性不高,也就让开发者自己都觉得维护很难
3、        单元测试用例设计完毕后,没有进行用例的检查,导致用例质量失控
4、        在SSH下的单元测试,其单元的粒度和复杂度太大,应用架构上就是分层设计,层与层之间有千丝万缕的联系,而且SSH中三个框架中的上下文环境对每个单元的运行也是影响很深刻的;


这样的情况下,单元测试应该怎么开展呢?
回复 支持 反对

使用道具 举报

该用户从未签到

105#
发表于 2010-11-4 15:49:32 | 只看该作者
你好
我安装了QTP10.0,用自带的订票系统练习,为什么脚本录制不上呢,很郁闷,RUN是灰色
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2023-9-19 19:52
  • 签到天数: 7 天

    连续签到: 1 天

    [LV.3]测试连长

    106#
    发表于 2010-11-4 20:53:48 | 只看该作者
    茹老师 您好!
    我参加了10.31号的测试沙龙,在解答我的问题时你说你做过地铁信号系统方面的测试,真是感到幸运!
    请问能否给我一些相关信号相关的嵌入式测试资料,如ATO,ATP,联锁等系统的测试用例,或相关资料?
    万分感谢!!   t_hacker@163.com
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    107#
    发表于 2010-11-5 13:21:10 | 只看该作者
    楼上问的也是我要问的,等待答案。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    108#
    发表于 2010-11-5 14:08:03 | 只看该作者
    老师请问我要想做一名软件测试师!需要哪些技能???
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    109#
    发表于 2010-11-5 15:41:00 | 只看该作者
    48楼:你好
      我目前从事手工测试方面的,现在刚刚开始自学自动化测试工具winrunner,请专家给点意见,自学过程中学习注意些什么?或者有什么好的学习方法?谢谢



    回复48楼:


    对于自动化测试工具的学习,我认为最重要的并不在于工具本身的使用,而在于对自动化测试的方法论以及技术核心的理解。简单来说,就是需要明确知道具体的自动化测试的过程以及自动化测试过程中的关键技术,举例来说,我们必须明确知道对象的识别的概念以及对象识别在具体实现的时候是怎么做的;自动化测试的数据驱动以及关键字驱动概念等等;掌握了这些之后,无论学习哪种自动化测试工具都会事半功倍。


    至于工具本身的学习,无论是WinRunner还是QTP,或者是RFT都是很类似的。另外,在自学的过程中除了看相关文档外,还应该多多动手实践。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    110#
    发表于 2010-11-5 15:42:05 | 只看该作者
    49楼:茹老师 您好!
       我最近在学习QTP自动化测试工具,我想问下怎么将自动化工具合理运用到web项目的测试中,应用过程中应该注意哪些关键因素

    回复49楼:


    QTP非常适合用于WEB项目的自动化测试,但是到了实际应用阶段,还是会有很多问题的,其中包括技术层面的,也包括管理层面的。首先,从技术层面上看我想提以下几点:


    1.        应用于实际项目前,团队中的核心成员必须对QTP本身有很好的掌握,对数据驱动、关键字驱动、脚本的组织等有清晰的概念,明确地知道QTP适用的场景以及如何用。

    2.        团队中的核心成员必须就项目本身的QTP适用性进行分析,列出可能存在的技术风险,最典型的就是QTP的非标准对象的识别能力、稳定性和可操作性。

    3.        QTP不是简单的录制与回放,必须根据项目的业务特点规划测试脚本的粒度与组织结构,并提取公共的业务和非业务脚本进行封装。

    4.        自动化测试需要开发的技术支持,比如自定义控件的识别,验证码的输入等等,这就要求自动化测试人员对被测系统的整体技术架构有一个较全局的认识与掌控。


    从管理层面上看可以注意下面几点:


    1.        必须明确自动化测试团队的职责范围,比如说自动化测试人员除了负责自动化测试用例的实现和脚本的维护,是否还需要负责具体测试用例的设计。两者的差别是巨大的。

    2.        必须明确自动化测试团队与手动测试团队的合作模式,明确定义测试的流程以及自动化和手工团队在其中扮演的角色。

    3.        必须和开发人员,尤其是开发负责人达成共识,让他们明确知道我们的目标以及可以给他们带来的效率提升。

    4.        必须和老板就自动化测试应用初级阶段的投入产出比达成初期共识,说白了就是要让老板知道自动化测试的特点,在初期不要给自动化测试定义过高的要求和目标。

    5.        必须注重团队内部的经验交流与技术培训。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    111#
    发表于 2010-11-5 15:43:13 | 只看该作者
    57楼:
    您好,以下是我的几个问题:
    1、若一个公司测试报告没有通过标准,而且客户需求也没有明确要软件质量达到一个什么程度的时候,在测试报告上如何判断软件是否通过。



    回复57楼:


    1.       有以下3条途径可以解决你的问题,第一个是最规范的,越到后面越“灵活”:

    第一:对于具体项目而言必须要有软件质量保证计划,其中明确定义各个测试阶段的输入输出,并确定各阶段的出入口标准。这个软件质量保证计划(SQAP)必须经过各方评审并正式发布,这个文档就是以后所有测试验证相关工作的纲领性文件。


    第二:如果项目流程不正规,或者由于项目实际情况,没有软件质量保证计划的话,那么可以在各个测试阶段开始前,由测试部门制定具体的针对该阶段的测试规格说明书,其中明确定义测试的范围,策略,技术、对于上层需求的追踪要求以及测试通过的标准。该测试规格说明书必须由开发团队,用户组(也就是客户或者是需求组)进行评审并通过。这样对于的测试范围与要求都做到了有据可依。


    第三:既然没有通过标准,那么测试报告当然没有办法判断。这时测试报告只能尽可能详细罗列各个执行过的测试用例的情况和Bug情况,并提供尽可能全德统计数据,但不给出最终的结论。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    112#
    发表于 2010-11-5 15:44:22 | 只看该作者
    57楼:
    您好,以下是我的几个问题:
    1、若一个公司测试报告没有通过标准,而且客户需求也没有明确要软件质量达到一个什么程度的时候,在测试报告上如何判断软件是否通过。
    2、假如是外包测试,属于第三方的外包,是软件使用方外包你过去测试,而开发方是另外,测试环境中的程序等不能由测试控制,如何把握和监督版本的维护。
    3、还是以上的外包形式,假如被测软件还存在bug,测试没有明确软件已可以实施,但客户已对软件进行实施,作为测试人员如何应对。
    4、你觉得目前测试行业,那种测试类型的人更吃香。
    5、你觉得测试没有开发经验,不做白盒的是否有前途。
    6、如果测试已有几年经验,有一点编码能力,但是没有开发经验,你觉得要想做更高级的,该从何找突破口!
    问题有点多,不过真系想知道专家的意见,多涨见识,谢谢!



    回复57楼:


    1.       有以下3条途径可以解决你的问题,第一个是最规范的,越到后面越“灵活”:

    第一:对于具体项目而言必须要有软件质量保证计划,其中明确定义各个测试阶段的输入输出,并确定各阶段的出入口标准。这个软件质量保证计划(SQAP)必须经过各方评审并正式发布,这个文档就是以后所有测试验证相关工作的纲领性文件。

    第二:如果项目流程不正规,或者由于项目实际情况,没有软件质量保证计划的话,那么可以在各个测试阶段开始前,由测试部门制定具体的针对该阶段的测试规格说明书,其中明确定义测试的范围,策略,技术、对于上层需求的追踪要求以及测试通过的标准。该测试规格说明书必须由开发团队,用户组(也就是客户或者是需求组)进行评审并通过。这样对于的测试范围与要求都做到了有据可依。

    第三:既然没有通过标准,那么测试报告当然没有办法判断。这时测试报告只能尽可能详细罗列各个执行过的测试用例的情况和Bug情况,并提供尽可能全德统计数据,但不给出最终的结论。


    2. 这个问题比较简单,在你描述的情况下,作为外包的测试团队只要认送测版本的版本号就可以了。具体来说,送测软件版本会有详细版本号,那么我们所做的所有测试都是基于这个版本的,当发现Bug并提交的时候明确标明版本信息即可。但是这个过程中有一个很关键的地方就是你不能很随意的接收被测版本,不能改了几个Bug就升一下版,必须要完整做完一轮测试并且相应的Bug都修复了才能升版本进行下一轮测试。


    3. 这个问题,或者说责任超出了你们外包测试团队的范围了,出了问题是客户自己负责。


    4. 一类人是业务专家,也就是我们通常说的领域专家,他们非常明确系统的需求。另一类人就是测试专家,他们掌握各类测试技术,能够很好把各种测试策略与技术应用于具体的被测系统,同时他们也是测试用例的专家,积累了很多测试用例设计的精髓。


    5. 我不认为做白盒测试很有前途,如果白盒测试有前途,那么程序员不就更有前途了吗?当然测试人员能够读懂开发代码,也就是说有一定的开发背景对于更好的设计测试用例会有很大的帮助的。


    6.测试策略与测试整体的把握应该会更有帮助,当然学习自动化测试以及测试框架设计与开发也是很好的途径。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    113#
    发表于 2010-11-5 15:45:21 | 只看该作者
    58楼:
    请教几个问题:
    1、一个产品已经在使用中,目前是对其进行新功能的叠加或旧功能的改进。此时同时有多个团队在其进行开发,那么手工用例的复用性怎么维护比较好?(由于功能需求的变化很快,有可能1个月,一个原先的功能就被颠覆了,而且有多个测试在对同一模块的不同开发项目进行测试)。
    2、在快速开发上线的情况下,如果手工用例和自动化用例相结合,那么怎么来控制投入的成本,避免测试成为项目的时间瓶颈?
    3、在敏捷开发的情况下,自动化怎么提前跟进?
    4、自动化代码集成测试成为日版本测试的话,采用什么样的机制可以降低人工维护成本呢?



    回复58楼:


    1 这个问题很难回答,主要牵涉到你的软件整体架构和模块划分,必须具体问题具体分析。一个原则就是测试用例的裁剪与补充必须基于影响分析的结论。


    2 测试成为项目时间瓶颈的最好解决方法尽可能早的进行测试。对于快速开发和需求不稳定的项目不适合与自动化测试。


    3 通常而言,快速迭代或者敏捷的项目很难有效地进行自动化测试。当然有些基于后台协议的项目,由于接口层相对稳定,所以还是可以有效地在接口层面进行自动化测试的。


    4.可以采用持续集成Hudson

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    114#
    发表于 2010-11-5 16:34:45 | 只看该作者
    59楼:
    您好:
    我的问题是:
    1.如何确保自动化后的Case的质量?
    背景介绍:
      当前,我们开发了许多自动化的脚本,现在已经可以与手动的Case关联,并且所有脚本逻辑已被QA review过了,但是当我们进入集成测试阶段,手动测试的TL总是以某某理由,不信任自动化脚本, 仍然要求手动测试,结果,自动测试仍旧没有取代手动测试的effert。
    问题:
    请问您在实现了自动化之后,又做了哪些事情,保证自动测试Pass的case确实是没有问题的。



    回复59楼:


    很好很典型的问题,相信很多中小企业的自动化测试主管都会或多或少面临这样的困惑。


    第一个问题我想从技术层面和和管理层面谈下面几点:

    1.             首先,我们明确一点,自动化测试并不是也不能完全取代手工测试,毕竟自动化测试不能“创造性”地发现系统缺陷,自动化测试必须与创造性的手工测试一起来保证产品的质量。就这个层面上而言我是同意手工测试TL的观点的,只是手工测试和自动测试应该各自有所侧重,自动化用例主要实现常规的稳定的功能测试和新版本的回归测试,手工测试主要关注新功能和难以自动化(或者自动化代价较大)的测试。各司其职,各有分工。


    2.             毫无疑问,自动化测试用例的有效性是取决于手工测试用例的有效性的。也就是说我们会把高效清晰的手工测试用例转化为自动化用例,如果手工测试用例本身有问题,自动化用例的有效性就无从谈起。


    3.             其次,自动化测试用例本身的质量是取决于用例脚本实现的正确性和执行的稳定性,也就是说自动化测试用例脚本是否根据用例的设计对每个CheckPoint对了必要并且正确的检查,每个检查的结果是否有相应的记录,包括写Log或者截屏甚至屏幕录像,同时还必须考虑脚本执行的稳定性和普适性,这里的普适性是指一个测试脚本应该在各个满足测试环境要求的机器上都能正确顺利地运行。


    4.             至于你说的Manual TL不信任自动化测试这点是不太合理的,你可以通过presentation的方式将你们所做的工作告诉手工测试团队,并且可以进行演示和说明。至于自动化测试的过程可以采用屏幕录像的方式进行保留(QTP本身就是支持的),在有所怀疑和不确定的地方做到有据可依。


    5.             另外,如果是晚上跑自动化测试的话,可以将整个自动化测试多跑几次,时间允许的话一般可以跑3次,以此降低脚本不稳定性的影响。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    115#
    发表于 2010-11-5 16:35:51 | 只看该作者
    59楼:
    2. 关于自动化团队绩效的问题
    背景介绍:
    我们现在有一个独立的自动化团队,主要任务是编写自动化脚本。但是,被自动化的case比例迟迟无法上升。原因有两个:a. 团队人力有限,我们现在三个专职自动化工程师(QA有15~20个人)。b. 每个release,新增加的手动case数量远大于自动化的Case,我们自动化的比例不升反降。再有问题一造成的负面结果,外界也觉得自动化的投入没有收益。结果,我们辛苦工作了一年,团队在年中时差点解散,这次加薪也很少,郁闷....
    问题:
    如何体现自动化的价值?

    回复59楼:

    第二个问题我就简单说说吧,否则篇幅太多了。其实你说的自动化测试用例和手工测试用例的比例问题很好解决的,你必须给每轮测试的手工测试用例一个基线,然后统计这一轮测试中自动化测试用例对于这个手工测试用例基线的比例。TestLink可以支持这样的应用。另外对于数据驱动的自动化用例,自动化测试是绝对是占有先天优势的。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    116#
    发表于 2010-11-6 15:42:17 | 只看该作者
    5. 我不认为做白盒测试很有前途,如果白盒测试有前途,那么程序员不就更有前途了吗?当然测试人员能够读懂开发代码,也就是说有一定的开发背景对于更好的设计测试用例会有很大的帮助的。
    ---------------------------------------------------------------------------------------
    这样的说法太武断,白盒测试是个系统工程,而不是读代码!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    117#
    发表于 2010-11-8 18:27:50 | 只看该作者
    回复 50# charlen


        多谢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    118#
    发表于 2010-11-8 18:28:33 | 只看该作者
    回复 82# dhrbc


        多谢~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    119#
    发表于 2010-11-9 10:18:02 | 只看该作者
    呵呵
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    120#
     楼主| 发表于 2010-11-9 13:17:46 | 只看该作者
    本期你问我答结束,非常感谢茹炳晟的热心解答!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /2 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-6-24 14:51 , Processed in 0.086191 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表