51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5904|回复: 9
打印 上一主题 下一主题

[原创] 你在撰写测试用例的时候思维清晰吗?-------测试用例撰写之架构

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-8-6 14:22:49 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
   从编程的角度来讲,架构的开发要比具体功能的实现重要的多,一个合理的架构会给以后的开发留有很好的发展空间,可是如果碰到一个不好的架构,后期的开发会变得寸步难行;同样一份好的测试用例架构也是很重要的,而通常你的架构需要与程序的架构相吻合,这样的case 才会合理,在开发领域有一个叫软件架构工程师,近几年在软件测试领域也出现了软件测试架构工程师,我相信在某种程度上,这俩个架构工程师在看待同一AP上会得到一份相似的架构。
     同样,我们先来看看研发,作为软件架构工程师,拿到一份FRS,进行DNS的时候,他也许会从2个方面着手:第一,模块的划分,第二,核心数据结构的建立,以及数据的流向规划。而模块的划分通常会以功能点或是UI为出发点来进行规划。核心数据我们这里就不讨论了。
  然后我们再来看看测试,一个软件测试架构师,同样拿到的也是一份FRS,进行STD的设计,而他呢,也是需要对FRS进行模块的划分,这部分的划分越趋近程序的架构越好,这样的好处在于日后AP发生改变的时候,Case也可以找到想对应的部分进行变化,而不至于需要对Case进行全面的修改。
  如此看来测试用例的撰写第一步遇到的与开发是同样的问题,那就是模块的划分,当然测试肯定还是有自己的特点。一般的情况下,我们认为Test Case 可以分为三级来划分:
第一级:正常情况下的测试,特殊场景下的测试,压力测试,性能测试等大类别的分开
第二级:基于UI或是功能对其进行模块的划分
第三级:第二级如果是UI模块,那么第三级需要按照功能点来划分,如果第二级为功能模块,那么第三级优先按照UI模块来划分
所以,从上面来看,最终会划分会到每个具体的功能点,那么每个功能点的测试又需要包含含下面几个要素的测试:
1.  Default status check
2.  当前动作所操作的对象划分(可以称为源分类)
3.  动作过程中的选项
4.  动作所要达到的目的(可以称为目标分类)
5.  确认不同方式可执行此动作

针对以上三个原则和几个要素,我们以系统的Explorer为例来讨论一下如何进行Case 的撰写:
首先我们会分为这几大类:Administration 用户测试,Limited 用户测试,压力测试,性能测试等,就Administration 用户测试又可以分为:ToolBarTreeViewListViewStatusbar (以上是按UI模块来划分的,有时候还需要添加一些按照功能来划分的)Search,收藏夹,同步,文件夹选项等,而展开TreeView第二级的Case,按照上面的原则,这是一个UI模块,第二级分类,需要按照功能来分,于是就出现NewCopy/Paste,Cut/Paste,Delete……;就具体的每个动作,我们进行具体Case 的撰写,按照上面提到的要素,Copy Case 需要有如下测试用例:Default Status,源分类(Copy 本地目录,网络目录,系统目录,只读目录,无权限访问目录,含子目录的目录,含有文件的目录….,目标分类(Paste 本地,网络,网络目录,系统目录,只读目录,无权限访问目录)。
   至于Limited 用户测试,我们可能需要根据Limited user 下一些特殊的限制进行有针对性的撰写,而不需要像Administration 那样面面俱到。

以上就是大概的一个思路,这些以文字的方式来描述,理解起来会比较费劲,我们可以借助思维导图类的软件来帮助我们更好的来呈现,下面就是我用MindManagerExplorer 一个局部的描述:




附件:

Explorer case架构图  [时间:2010-8-6 14:28]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2010-8-6 15:57:42 | 只看该作者
顶一下!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-8-6 16:02:01 | 只看该作者
支持一下
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    4#
    发表于 2010-8-6 21:19:23 | 只看该作者
    使用思维导图,不错
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-8-6 22:26:15 | 只看该作者
    确实,同感。
    用惯了思维导图,设计用例感觉挺顺手的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2010-8-9 09:10:45 | 只看该作者
    确实,而且使用思维导图也便于Case 的 Review
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2010-8-9 10:25:52 | 只看该作者
    恩,确实不错,逐层向下铺展测试点不仅能让自己思维清晰,也能为评审的提供一个清晰的思维空间。::ybaojc:::

    针对于LZ的例子,我经常还会再做一个功能模块交互关系图,为“特殊场景测试”提供用例设计指导。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
     楼主| 发表于 2010-8-9 11:31:16 | 只看该作者
    原帖由 Jackc 于 2010-8-9 10:25 发表
    恩,确实不错,逐层向下铺展测试点不仅能让自己思维清晰,也能为评审的提供一个清晰的思维空间。::ybaojc:::

    针对于LZ的例子,我经常还会再做一个功能模块交互关系图,为“特殊场景测试”提供用例设计指导。


    没想到版主大人也来了,深感荣幸呀
    另外,请教一下像这种情况,您的功能模块交换关系图,会是什么样子呢?如能简单勾画一下,不甚感激!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2010-8-10 13:01:48 | 只看该作者
    原帖由 ricmy 于 2010-8-9 11:31 发表
    另外,请教一下像这种情况,您的功能模块交换关系图,会是什么样子呢?如能简单勾画一下,不甚感激!


    通常会分为两部分,模块内部关系图和外部关系图。
    1、内部关系图
    内部关系图的结构元素基本与你提到的用例设计结构使用的元素基本一致,只是组成方式不同,着重强调各个子模块之间的相互调用关系。


    2、外部关系图

    外部关系图则强调测试模块与系统其它模块的相互调用以及OS对测试模块的调度策略(比如后台运行、同时运行等)




    PS:这些结构图都需要大量的时间来设计,而其作用也比较有限,只对交互和场景测试具有指导意义。所以不适合时间比较紧的项目。

    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
     楼主| 发表于 2010-8-12 10:21:33 | 只看该作者
    恩,有了这样的内外部关系图,对Case的设计确实是有很大的帮助
    而且从某种程度上来讲,这种关系图对研发也是有很大帮助的,便于对模块接口的划分与定义,非常不错,受益了,谢谢!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-7 23:46 , Processed in 0.075206 second(s), 30 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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