51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

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

[你问我来答第11期]:怎样设计实用性的测试用例(已结束)

[复制链接]
  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    81#
    发表于 2011-5-13 22:25:39 | 只看该作者
    我是新手 顶一下 大家也多和我沟通啊 我还不怎么会呢!请大家 多多帮忙呢!
    宝儿_C 发表于 2011-5-4 17:42



        一起沟通一起交流,也要学会主动沟通。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    82#
    发表于 2011-5-16 09:17:27 | 只看该作者
    问下楼主:
    对MTK平台,短信测试您是从哪几个方面进行考虑的?包括测试用例的编写。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    83#
    发表于 2011-5-17 13:20:50 | 只看该作者
    好题目,这两天正在思考这问题。我的观点如下:
    1、分析需求、UI设计,并评审需求和UI;保证UI设计全面覆盖需求,且UI多于功能,也需要补充在;
    2、整理测试需求;
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    84#
    发表于 2011-5-17 13:39:18 | 只看该作者
    对不起,没写完就发表了;
    好题目,这两天正在思考这问题。我的观点如下:
    1、分析需求、UI设计;保证UI设计全面覆盖需求,且UI多于功能,也需要补充在需求中;
    2、整理测试需求,将同类型需求合并,这样减少测试用例冗于;
    3、将功能性测试用例进行分类,包含基本功能、复杂功能、健壮性用例;并有明确的测试优先级别。(根据项目进展,可调整测试优先级)--功能性用例必须前面覆盖需求,且有清晰层次关系,便于审核测试用例覆盖是否全面?是否冗于。
    4、另外,将独立性强的部分整理成专项用例,比如压力、兼容性、性能等;

    总体来说,要测试用例实用有效,我个人观点如下,欢迎讨论。
    1)、测试用例是可执行的;
    2)、通过测试用例运行结果,知道当前软件的质量状况。
    3)、测试人员提交的BUG,85%以上的BUG是通过执行用例发现的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    85#
    发表于 2011-5-17 17:08:00 | 只看该作者
    关注下。。等待大神的回答。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    86#
    发表于 2011-5-17 17:08:13 | 只看该作者
    关注下。。等待大神的回答。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    87#
    发表于 2011-5-17 17:08:21 | 只看该作者
    关注下。。等待大神的回答。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    88#
     楼主| 发表于 2011-5-17 17:25:08 | 只看该作者
    对不起,没写完就发表了;
    好题目,这两天正在思考这问题。我的观点如下:
    1、分析需求、UI设计;保证UI设 ...
    zyhuestc 发表于 2011-5-17 13:39



    感觉这位兄弟把你问我来答当成每周一问了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    89#
    发表于 2011-5-18 11:24:06 | 只看该作者
    回复 1# 默默巫


        MTK平台有哪些测试工具啊?关于与性能测试和白盒测试的、
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    90#
    发表于 2011-5-19 16:20:08 | 只看该作者
    手机软件的整个开发和测试流程是什么?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    91#
    发表于 2011-5-19 17:31:31 | 只看该作者
    回复 15# 楠族开心果


        我怎么没感觉到我到帝王时代了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    92#
    发表于 2011-5-19 17:34:21 | 只看该作者
    BS架构的软件,我只是从开发部拿到了html语言写的系统的原型,和一些国家相关的法律法规。根据原型系统的基本功能都能看到,也没有需求说明之类的资料,现在我写出了测试大纲,也基本了解了相关法律,那么我在测试前还要做什么准备工作呢?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    93#
    发表于 2011-5-19 18:03:21 | 只看该作者
    回复 91# narsolo


        这只是个比较理论的描述,当然还要根据自身技术而言的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    94#
    发表于 2011-5-19 21:54:45 | 只看该作者
    回复 8# weiwei911909

    "1. 传统软件测试和游戏测试在设计测试用例上的区别?"

    答:
    从本质上说,传统的软件测试和游戏测试在设计测试用例上并没有区别。
    游戏测试只是在传统的用例设计方法基础上,根本其自身特有的属性(也就是业务属性),追加了局部功能用例设计粒度而已。而为了让局部功能达到更高的用例设计粒度,很自然的就使用了一些特殊的设计方法。

    打个比方,把传统软件测试比作“面食制作”,那么游戏测试就像是做“包子”,而web测试就可以比作做“面条”了。虽然包子和面条有些许不同。但是它们同是在“将面粉发酵后加工并加入辅料”这个原理中完成的。加工方法和选择的辅料则就是依据它们自身的特性而决定的(也就是测试业务决定细节)。
    测试过程如此,测试用例设计原理也是如此。


    我对游戏不是很熟悉,简单说一下知道的3个在游戏测试中被加强的测试项目:

    1. 数字测试

    游戏测试中,经常会涉及很多数学算法的测试,如,伤害计算,人物属性/经验成长计算…..这类数字计算的测试内容,在设计用例时,除了单纯的检查各个算法公式的计算结果是否正确外,还需结合用户体验方面考虑算法本身是否合理。比如,人物升级过慢可能导致用户在使用过程中失去耐心,而升级过快则可能降低用户的使用时间….如何让目标算法达到一个合理的曲线,是游戏测试用例设计中的一门独特的学问,需要长时间的业务累计才能做出正确的判断。

    2. 组合测试

    游戏测试中,单个功能的测试大都和传统测试差不多。但是游戏测试比其他测试更开放,它的各个功能相互连接很紧密。在传统测试中,1个功能可能与10个其他功能存在交互;而在游戏测试中,1个功能则经常会与几十个,上百个其他功能交互。所以游戏测试更强调了功能的组合测试。
    处理组合这类问题时,可以先分为“逻辑组合”和“条件组合”两个方面着手。逻辑组合可以画出流程图,根据路径覆盖得到可用用例(也可分类测试元素后,直接使用因果法);条件组合可以整理出测试元素后,用正交/结对等方法得到用例。当“逻辑组合”和“条件组合”两者需要同时测试时,可先分别设计用例,再将两个用例组的各个用例再一次使用正交/结对 组合合在一起,得到最终用例。

    3. UI测试

    游戏测试中,有多次重复使用某个UI的特点。如树木图标,它可能是有5个不同的图标,这5个不同的树木图标将出现在游戏中50个UI位置上,每个图标都被多次复用了。
    所以,在游戏测试中,UI测试可以分为两个方面:个体测试和整体测试。
    个体测试主要主要负责各个单个UI元素的检查;而整体测试则是对整个UI的检查,也就如通常的“跑地图”一般。

    在用例管理时,UI个体测试用例,可以单独分类出来;
    而UI整体测试用例,一部分可以放到功能测试中,当对切换新UI,需要测试新功能时,则先使用一组UI整体检查用例,再使用功能测试用例;另一部分,则需要独立管理,如纯粹的“跑地图”UI。

    当然,也可以把整体UI用例与功能用例结合起来,比如测试背包系统时,将背包使用的UI场景作为1个新的前置条件,那么背包的不同功能测试,将在不同的UI场景完成。这样既可以覆盖不同UI,也可以测试不同功能。但是,不建议这么设计用例,主要原因还是游戏测试本身就具有复杂的功能组合逻辑,即使只增加1个新的前置条件,都将大大增大用例设计的难度。用例设计难度越大,也就意味着设计出的用例出现泄露的风险越大。
    所以,“跑地图”这类整体UI测试用例设计,还是以选择UI场景为主,在各个不同的UI场景中,检查不同的主要功能即可。

    "2. 日常工作中,也了解很多设计测试用例的方法,为什么总觉得用到的比较少呢?还是我们在潜移默化中已经用到了那些方法,只是没有书面化呢?"

    答:
    其实这是自由测试(探索测试)与常规测试(根据用例执行测试)的区别问题,它们都存在各自的优势的缺陷。自由测试的成本更低,符合低投入,高回报的目标,但是它比较难控制,受人为因素影响比较大。常规测试则比较容易控制,但是成本过高是它的硬伤。

    在自由测试中,测试人员通常无法使用一些计算复杂的高级测试方法,如正交,比对等。但是可以使用其他的方法,如等价、边界、场景。这些也都是因人而异的。而实际的自由测试过程中,是否使用了这些方法,还需要分析实际执行的测试内容才能清楚。

    另外,其实这个问题牵连另一个测试概念:测试的最终目标是100%覆盖测试需求,但是不同阶段的测试的目标并不一样,比如,版本验收使用回归测试,测试目标验收使用产品测试,测试目标主体检查使用功能测试….所以测试用例的目标也是多元化的,测试用例设计的粒度与方法选择取决于当前的测试目标。

    在日常工作中,设计一组用例,首先需要清楚它的使用目的,如果只是大致检查一下测试目标的主要功能,那只需要按照需求文档一一罗列即可,又何需使用复杂的测试方法呢?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    95#
    发表于 2011-5-19 22:21:52 | 只看该作者
    回复 9# geogon

    "我想请教一个问题,就是针对配置文件中的以下需求,如何设计测试用例进行测试? <add key="BankAccountInfoCheck" value="YLY#YYA-Y-0.00|YNA-L-100.00|NYA-L-100.00|NNA-N-0#A#01000000,01004900#00|#0"/>  "

    答:
    不明白”#”符号的意思,也就不太清楚“#A#01000000,01004900#00”是什么意思,先说说前面的“YLY#YYA-Y-0.00|YNA-L-100.00|NYA-L-100.00|NNA-N-0”

    首先,解释一下其中的一个关键需求“交易规则可设置多个,且不在规则内的结果,拒绝交易”,它的意思简单来说就是,交易规则默认是N状态,可手动设置其为Y或L状态。

    这类数据组合的问题使用正交法能很好解决

    1.先分类测试元素
    测试目标中存在4个测试元素,每个测试元素都有3个测试水平,如下:

    手机号码:  Y N A
    身份证:     Y N A
    姓名 :       Y N A
    交易规则 : Y N L


    2.可以通过网上查找和正交表生成工具,找到合适的标准表,这个问题可以使用标准表L9(34)
    列号
    1
    2
    3
    4
    试验号
    1
    1
    1
    1
    1
    2
    1
    2
    2
    2
    3
    1
    3
    3
    3
    4
    2
    1
    2
    3
    5
    2
    2
    3
    1
    6
    2
    3
    1
    2
    7
    3
    1
    3
    2
    8
    3
    2
    1
    3
    9
    3
    3
    2
    1


    把测试目标中的测试元素和其属性套入上表:
    列号
    手机号码
    身份证
    姓名
    交易规则
    试验号
    1
    Y
    Y
    Y
    Y
    2
    Y
    N
    N
    N
    3
    Y
    A
    A
    L
    4
    N
    Y
    N
    L
    5
    N
    N
    A
    Y
    6
    N
    A
    Y
    N
    7
    A
    Y
    A
    N
    8
    A
    N
    Y
    L
    9
    A
    A
    N
    Y


    上表中每一列即为一个测试用例,得到9个主要的逻辑用例。

    3.针对上一步得到的9个主要用例,根据需求补充其他用例,也就是传统的业务用例
    1)UI检查,如语句格式,命令名
    2)特殊业务检查,如当交易规则为“L”时,需增加额度的测试数据,既第3,4,8组用例都需要增加额外的用例来对限制额度进行测试,如限制金额测试数据为-1,0,999...等(当然,30天有效期限也属于特殊业务范畴,可是前半段语句中,并没有期限设置)
    3)容错检查,如数字部分的字符类型检查,重复定义相同用户数据或交易规则等
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    96#
    发表于 2011-5-20 09:30:00 | 只看该作者
    虽然已有1年的测试经验,可是我还是觉得自己是个新手,以后多多来这里学习。请大家指导指导啊。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    97#
    发表于 2011-5-20 11:53:09 | 只看该作者
    想问下,要测试linux BSP,是把驱动描述转换成相应的应用测试,去找应用程序测试?还是直接写程序调用驱动接口?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    98#
    发表于 2011-5-21 14:36:18 | 只看该作者
    jackc真年轻,
    jackc啊,我们写的测试用例写的也不少,但是往往用以执行的却很少,我身边做测试的朋友也是有这样的情况,在我们看来无效的测试用例确实很多几乎感觉没有用了,但是我还是觉得用例写好了对测试执行会起相当关键的作用,现在我不知道用例应该怎么写了,用例的版本也相当泛滥,jackc能不能告诉我怎么很好的设计用例啊,有典型的用例最好,谢谢了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    99#
    发表于 2011-5-23 10:58:09 | 只看该作者
    jackc

    我刚开始学测试,想请问一下,应该从哪方面开始着手??很茫然
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    100#
    发表于 2011-5-23 18:09:40 | 只看该作者
    测试用例设计确实是一个很难平衡的问题,到底是设计的细点好呢还是设计的粗点好呢?粗细是指测试用例的粒度哈~~细了花费的时间多,但是可能发现的问题少,粗了,花费的时间少又不能保证细的部分不执行没问题!jackc关于这个问题是怎么考虑的呢?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-6-5 01:08 , Processed in 0.088982 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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