51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6397|回复: 23
打印 上一主题 下一主题

[讨论] 黑盒测试中的典型问题

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-3-7 17:36:45 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
大家好:工作了一段时间了,遇到一个问题,自己想的不是太明白请大家来交流一下!


          在对一个有将近20个子模快(每个子模块的大小不相同,但之间的关联相当紧密)的系统软件进行黑盒测试时,会遇到这样一种情况:相关的模块间的测试用例在编写时,按关联关系会很复杂,但在按功能点编写时,模块间的逻辑结构不容易体现。两者之间怎样均衡会比较好呢?请教高手来指点一下!

[ 本帖最后由 ouling168 于 2007-3-7 17:40 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

24#
发表于 2007-4-14 21:10:11 | 只看该作者

回复 #1 ouling168 的帖子

个人理解:黑盒测试主要关注功能测试、性能测试、GUI测试。所以针对你所说的考虑功能点情况,是要设计测试用例验证系统软件能否正确实现需求规格说明书中要求的功能点,这是属于系统测试的范畴;
    而对于系统内部相关模块间的测试,应该属于集成测试的范畴,是灰盒测试。可以采用大爆炸、自顶向下、自底向上等测试策略组合模块,设计测试用例以关注模块之间的接口关系以及组合后的功能。       不妥处,望赐教~!
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2007-4-14 13:34:10 | 只看该作者
sdlkfj6
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2007-4-14 10:52:45 | 只看该作者
不错,学到了。。。。
回复 支持 反对

使用道具 举报

该用户从未签到

21#
发表于 2007-4-14 09:59:18 | 只看该作者
大家说的都有道理啊,黑盒测试是基于功能的测试,主要还是看功能的实现问题,逻辑关系的话主要是白盒关注的内容
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2007-4-13 22:41:03 | 只看该作者
个人感觉像比较复杂的功能,应该以流程书写为重点,但是不会写得很细,细节的地方需要测试人员自己依据自己公司的测试标准进行测试把握

[ 本帖最后由 sunrubo2008 于 2007-4-13 22:43 编辑 ]
回复 支持 反对

使用道具 举报

  • TA的每日心情
    慵懒
    2019-4-10 17:57
  • 签到天数: 35 天

    连续签到: 1 天

    [LV.5]测试团长

    19#
    发表于 2007-4-13 16:03:20 | 只看该作者
    个人觉得黑盒测试主要是功能方面的测试,其他的可以补充
    而关于各个模块间的接口问题和其整体功能方面的测试应属于集成测试所关心的,做黑盒测试的话应该不必那么注重接口方面的测试
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2007-4-4 11:23:36 | 只看该作者
    黑盒测试的话,应该不用关注模块间的接口问题,那是属于灰盒测试的范畴,你应该主要针对功能进行测试,毕竟功能的正确实现才是黑盒的主要着眼点,个人意见,不妥处,望赐教~!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-4-3 13:47:26 | 只看该作者
    我觉得,黑盒测试用例的编写,可以分为功能测试用例、流程测试用例、接口测试用户;功能测试用例注重的是每个独立模块的功能;流程测试用例注重的是整个系统的流

    程;也就是集成测试,就像楼主所说的你要测试的项目是一个比较复杂的系统,那就应该整理一份比较清楚的流程示意图,并且应该尽可能的罗列出所有业务操作中存在的特殊情况

    的特殊处理;这里的接口测试用例侧重于,在web页面是否能看到从其他系统的接口读过来的数据,并且判断一下数据是否符合要求,是否能够参与系统中的统计功能。
       
        以上是我个人的一点小小的心得,有什么地方说错的,请多多指教
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2007-4-3 13:16:44 | 只看该作者
    主要是功能方面,考虑要全面 不拉下每个环节
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2007-4-3 11:00:26 | 只看该作者
    sdlkfj8 /......................
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2007-4-2 16:15:35 | 只看该作者
    我觉得是以功能测试完成为主 先不考虑关系
    完成后 在设计一个关系的测试用例
    虽然会有重复 但是覆盖率会很好 我觉得是
    lz可以在考虑考虑
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2007-4-2 16:09:59 | 只看该作者

    努力学习!

    好复杂,看来要努力努力再努力!!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
     楼主| 发表于 2007-4-2 15:28:57 | 只看该作者
    谢谢各位了!我主要还是说测试用例的编写,这下有点眉目了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2007-3-11 16:06:33 | 只看该作者
    我觉得虽然黑盒测试主要是功能测试但是我们做的是整个系统的功能测试,所以模块之间的关系还是需要关心的,我觉得在编写用例的时候,可以编写以下功能之间的冲突,那样用例编写起来应该会清楚明了些吧
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2016-3-31 10:22
  • 签到天数: 6 天

    连续签到: 1 天

    [LV.2]测试排长

    10#
    发表于 2007-3-10 14:55:17 | 只看该作者
    可以尝试写两种测试用例,1.功能测试用例 2.流程测试用例,侧重点不同。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2007-3-9 18:33:33 | 只看该作者
    应该是集成测试吧,那么重点应该在各模块的接口和整体性能上,思路还得自己动脑筋。..
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2007-3-9 12:53:11 | 只看该作者
    可以采用OAT技术进行编写
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2007-3-9 12:03:16 | 只看该作者
    个人感觉楼主的意思是:编写测试用例的思路是按照单个功能的验证还是按照业务逻辑的验证(某一流程也许会使用到多个功能模块)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2007-3-8 13:47:32 | 只看该作者
    LZ说的应该是集成测试吧,基本上算 灰盒 的。我建议可以把所有模块分成几个大一点的模块。测好大模块里面的接口以及功能,然后再把大模块集成为系统,最后按需求来进行功能测试。(当然是时间够用的情况下)
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-15 16:47 , Processed in 0.084044 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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