51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

楼主: lsekfe
打印 上一主题 下一主题

[你问我来答第20期]:如何编写好的测试用例?(已结束)

[复制链接]
  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    161#
    发表于 2012-3-27 09:03:44 | 只看该作者
    回复 59# zbj793989849
    公司说性能测试大部分要男生
    是这样吗
    刚毕业也不让我们学性能测试
    我之前有问个一位专家
    他说性能测试和功能测试没多大关联
    没必要先学功能测试再学性能测试。。我都糊涂了
    我知道性能测试要求挺高的。个人挺喜欢性能测试




    其实性能测试并没有趋向于男生,就像开发人员也没有男生优先的招聘条件一样。之所以有这个说法,无非是大多数男生比女生更喜欢逻辑推理而已。

    性能测试与功能测试还是有关联的。有些性能测试还必须在一定功能测试基础上测试

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    162#
    发表于 2012-3-27 09:05:46 | 只看该作者
    回复 63# yimei

    您好:
    我做测试也有几年了,但是感觉还是没有什么太大的变化,没觉得有什么提升。始终是在做一些手工测试,项目来了是先不写测试用例而是先测试,等以后项目不紧张了再补充测试用例。我个人认为这样是很规范的。我一直都认为写测试用例是最关键的,但是这几年好像没写怎么写过测试用例。还有面试的时候考官也会给你出一道题,让你大概说下你设计测试用例的思路。这些总让我感到脑子里好像空空的,没什么思路。您能指点下吗?

    1.      项目来了是先不写测试用例而是先测试,等以后项目不紧张了再补充测试用例 其实这种方式并不规范。如果你们已经有基础测试用例组,那么在项目需求确认后,第一时间开始用例的筛选和更新适用的用例组,并在项目前期交付于项目组各个部门评审。这样的操作无论对于项目质量控制还是项目出现问题后,对于测试人员的责任分摊,都是有极大的利益的。

    2.      测试用例的设计本身是测试技能中最重要的技术之一。但是由于它本身涉及整个测试系统的其他各个技能,所以对用例的理解,实际上就是测试人员对测试的理解。若发现无法再写出更好的用例,可多看看业务相关的资料,同时学习测试流程,将自身的测试思想涉及相关业务的边边角角,并融入到实际使用的测试流程中。这时你将发现之前的测试用例设计思想存在较大的提升空间,也逐渐能开始通过分析测试环境(不仅仅包括执行测试环境),熟练驾驭测试框架,制定测试策略。而之前设计用例欠缺的立足点,也会相应得到补足。有理有据,自然用例设计逻辑就清晰起来了。

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    163#
    发表于 2012-3-27 09:09:54 | 只看该作者
    回复 65# 407227813
    现在手机测试在整个测试行业中慢慢的占着重要的位置,也是一个好的方向,对于手机软件测试这快,大家都有不少的问题。希望能本选上。
    问题:
    请问手机软件测试的性能考察方向?

    从手机产品来看,手机性能测试可分为两部分:硬件测试和软件测试

    1.硬件测试操作简单,但目前国内很多手机硬件测试人员都处于初级阶段,即可执行测试,但无法提出优化解决方案,故普遍待遇较低。而要发展为高级硬件测试人员,必须掌握手机硬件测试设计原理,而掌握这部分的测试人员,大多都转为硬件开发

    2.手机软件性能测试目前在国内也比较麻烦,主要由于以下几点:

           1)嵌入式平台受于开源程度,自动化工具大多还是不足。勉强凑合的开源自动化工具无法应对多元化的客户和测试人员需求,往往需要二次开发

    2)由于市场竞争过于激烈,低成本的硬件器件无法达到最好的性能指标,导致在测试后期,测试人员还在纠结于如何平衡客户需求指标与实际测试性能指标。软件性能指标的不断变更同样也导致某些测试团队无法正确评估性能测试结果到底是通过还是失败

    3)软件性能测试周期长,投入资源较多,收益较功能测试少,故很多手机设计公司对这一块持观望态度


    补充:手机上的软件我们测试的是环境是系统比如android ios 等等主流系统,所以针对手机上客服端性能这块应该从这个方向来考虑,当然也包括手机的交互。希望大家来讨论哈这个问题!


    这个范围很广,此处不解答,抱歉。以后有时间多交流

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    164#
    发表于 2012-3-27 09:14:11 | 只看该作者
    回复 66# hqp1105


    1
    试用例有很多模版,到底选择那个好呢?写测试用例是根据以前测试的积累步骤写还是要根据写测试用例的方法写。

    测试用例模块,可自己根据实际测试的环境来选择。建议选择表格式的模板,比如excel,比较好统计。


    不同的测试人员,写测试用例的方法各不一样。并没有哪种方法就绝对好,都需要根据实际情况来看。如项目本身就很紧,若大张旗鼓的重新按照测试方法设计用例,必然导致中后期测试执行时间短缺,无法达到预定的迭代次数,而对项目产生更大的风险。所以,先分析环境,才可能设计出好的测试用例


    2老师还有功能测试做多久才可以做性能测试?
    功能入门易简单,性能偏难。有一些功能测试基础,学学性能也无妨,这个没有时间的约束,看你自己的能力、是否感兴趣或者工作的需要
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    165#
    发表于 2012-3-27 09:17:19 | 只看该作者
    回复 74# pycctv

    我有两个问题想请教下:
    1
    、测试用例的细度如何把握?什么样的功能点可以考虑放在同一条用例验证?什么样的功能点必须是一条验证一个功能点?
    我个人理解编写测试用例的原则是:最好一条用例验证一个功能点,但是在实际工作中经常会遇到,如果每个很细小的功能点编写为一条用例的话,会增加测试用例的执行成本。如果多个细小的功能点放在一条用例验证的话,对于后续的用例整合,以及回归用例的挑选会有一定的影响。
    2
    、如何挑选回归用例?什么样的用例可以作为回归用例?如果在备选的用例库里边没有可作为回归用例的测试用例时我们应该怎么处理?

    1、基本就如你说的一样,用例粒度无论选择什么方法,都存在利弊,所以在实际测试用例设计中,如何选取,需要结合整个测试团队和产品未来发展来看,而非简单的只分析测试用例原理就能得到结果。提供一个用例粒度供参考。单个quick check test 单个测试人员在2小时完成,组成的用例组要求覆盖产品所有功能,而每个用例都可从System cases中直接提取。以此为标准,可评估出每个用例的覆盖粒度。

    2、回归用例和第一个问题提到的QCT 用例差不多,满足2个要求:一是功能覆盖率,二是可在规定的执行时间内完成。

    如果备选的用例库里没有相应的回归用例,则需要更新备选用例库。

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    166#
    发表于 2012-3-27 09:19:08 | 只看该作者
    本帖最后由 楠族开心果 于 2012-3-27 09:20 编辑
    目前我在找测试岗位的工作,新手该如何做好测试呢?
    王雅 发表于 2012-3-9 16:28

    测试对新手的要求很简单:

    1.只相信实际测试的结果

    2.不懂就问,问完就想,想不通再问。切记重复的问题莫多次提问

    3.没事就多看资料,不管是否觉得和自己的业务相关,先看先了解,说不定以后哪天就用上了

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    167#
    发表于 2012-3-27 09:20:32 | 只看该作者
    我是个测试新手,刚刚从开发转做测试。
    想问问版主怎样才能将测试用例设计的全面.........
    zenghuimin 发表于 2012-3-9 16:59

    有个很简单的方法,你先按照自己的思路把用例写一次。然后用1倍的时间给自己的用例找茬,然后将泄**分类,再思考当初设计用例的时候,怎么可以将这些用例泄**预先设计进去。

    如果其他测试人员有时间,强烈建组织用例评审。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    168#
    发表于 2012-3-27 10:39:30 | 只看该作者
    如何提高测试用例的需求覆盖率,
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    169#
    发表于 2012-3-27 11:06:33 | 只看该作者
    很简单的问题,但是我纠结了好久
    如果X属于区间[3,100]上的整数,设计用例时应该怎么取值?为什么?
    1)取值:2,3,4,40,99,100,101
    2)取值:2,3,40,100,101
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-5-5 09:03
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    170#
    发表于 2012-3-27 16:05:16 | 只看该作者
    自动化不是每个公司都需要和都适合。自己努力了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    171#
    发表于 2012-3-27 17:52:31 | 只看该作者
    回复 28# woainini


        不建议这样做,由于测试用例粒度大,测试人员的可操作性差,导致最后测试过程不好控制,测试结果评估依据少,评估结果偏差大;建议用例仍采用细粒度的形式,用例多的话没关系,可以在测试策略的安排上
    给衡量一下取舍,也可以才测试执行策略上给出粗一点的执行粒度。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    172#
    发表于 2012-3-28 15:31:45 | 只看该作者
    回复 129# 木雨轩源雪


        这个测试工作量就大咯!你这样笼统的说,不好回答!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2017-2-22 14:28
  • 签到天数: 5 天

    连续签到: 1 天

    [LV.2]测试排长

    173#
    发表于 2012-3-29 16:54:53 | 只看该作者
    测试用的评审,需要注意一些什么?主要是针对那些人群?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    174#
    发表于 2012-3-30 09:08:32 | 只看该作者
    庄姐V5
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2015-4-9 17:10
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    175#
    发表于 2012-3-30 09:35:28 | 只看该作者
    回复 170# 柯卓
    要这么多干什么,你只要取 2.99,3,50.5,100,100.01 就可以了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    176#
    发表于 2012-3-30 15:34:46 | 只看该作者
    题目:
    1.软件测试按照测试层次可以分为(   C  )
    A.黑盒测试、白盒测试
    B. 功能性测试和结构性测试
    C.单元测试、集成测试和系统测试
    D、动态测试和静态测试

    2、软件测试是采用(A  )执行软件的活动。
    A.测试用例
    B.输入数据
    C.测试环境
    D.输入条件

    3.软件测试是软件开发过程的重要阶段,是软件质量保证的重要手段,下列哪个(些)是软件测试的任

    务?答案:(  D  )
    1预防软件发生错误 2发现程序错误 3提供诊断错误信息
    A.只有1
    B.只有2
    C.只有3
    D.都是

    4、导致软件缺陷的最大原因是:(A    )
    A.软件需求说明书                    B.设计方案
    C.编码                              D.维护
    5、测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据,至少应该包

    括(   A  )
    A、测试输入、执行条件和预期的结果。      B、测试目标、测试工具
    C、测试环境                              D、测试配置

    简答题:请简述VBScript中ByVal和ByRef的区别

    ByVal是传递值 源数据不会被修改,可以把这个值当作自己的局部变量来使用;ByRef是传递地址,源数

    据可能被修改,对这个变量的操作,传入的那个变量产生影响,像指针。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    177#
    发表于 2012-3-31 09:16:59 | 只看该作者
    回复 81# 湖畔的倒影

    有业务流程的测试用例该怎么写比较能够覆盖测试要点呢?比如增加不是简单的输入几个选项,点保存就OK,其中涉及到流程



    我没看明白你问的意思。为什么要等有了测试用例再去写测试要点?一般测试用例都是根据需求、测试要点来写的

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    178#
    发表于 2012-3-31 09:19:20 | 只看该作者
    回复 84# gesangniao
    您好!
      
    有几个问题想向您请教一下:
      1.
    怎么能提高软件测试用例的测试点覆盖率?
    有时候在设计case的时候,总是想把每种情况都测到,但这又会导致我的用例太多。如果不测试或是减弱对某些部分的测试,又担心会出问题,我应该怎样来处理这样问题呢?

      2.
    我刚入软件测试半年多的时候,不是很清楚自己的发展方向,能不能给指导一下?

    谢谢


    1可以考虑在用例模板最后加一个备注,将此用例需要额外关注的其他细节标注在里面,以方便执行过程中,选择性的进行测试

    2静下心来,补足测试基础理论1~2后再谈发展的问题



    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    179#
    发表于 2012-3-31 09:20:51 | 只看该作者
    本帖最后由 楠族开心果 于 2012-3-31 09:24 编辑
    你好我是刚开始学习的新人,请问怎样才能写出覆盖面广的测试用例呢?
    d1988920 发表于 2012-3-11 20:14


    请参考http://bbs.51testing.com/viewthread.php?tid=533885&extra=&page=9第168楼的回答
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    7 天前
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    180#
    发表于 2012-3-31 09:24:27 | 只看该作者
    回复 101# shj2010

    看不懂代码可以慢慢学,其实并不难,看你自己是否有这个决心下这个功夫了。黑盒测试来说其实研究透了,你也非常厉害,像自动化测试、性能测试它们有时候还是需要有些功能测试的功底的。作为研发体系的一员,代码功底是必须的,否则没有发展通路。测试和开发同属于研发体系,研发体系的通用语言就是编程语言,就像你到国外工作,其他人都说英语,就你只会说中文,虽然别人也能听懂一二,但是总觉得你是个异类。想要做好测试,不逊色于任何开发人员的代码功底是必要的。。。。。。

    想下决心学习代码,从哪里下手呢
    先学哪种语言呢,望庄姐指点一下,有没有入门的资料,谢谢


    不知道你们公司用什么语言开发的,一般跟着自己的公司学比较好。还有就是看你喜欢什么语言了。现在比如流行的还是java.net,还有python。不过测试的话,最好还是掌握些脚本吧


    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-5-1 12:40 , Processed in 0.085884 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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