51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3951|回复: 6
打印 上一主题 下一主题

[原创] 浅谈测试用例设计

[复制链接]
  • TA的每日心情
    开心
    2015-12-30 00:05
  • 签到天数: 7 天

    连续签到: 1 天

    [LV.3]测试连长

    跳转到指定楼层
    1#
    发表于 2012-7-27 17:09:30 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    一个好的测试用例是每个人都能执行的测试用例,不管你是否是测试人员,不管你是否了解整个软件的工作流程,你都能顺利的执行完测试用例,并对这个测试用例覆盖到的功能点有了大概的了解。


      好的测试用例的设计相当于软件开发中的详细概要设计,要写出好的测试用例首先要对所测试的软件很熟悉,熟悉软件的每个功能点和系统的整个业务流程。其次,对整个测试用例有个好的规划,理清主线,功能点的在哪个地方被覆盖都是需要考虑的。最后,需要良好的心态,写测试用例是个繁琐的过程,测试用例不是随随便便就能写出来的,好的测试用例更需要你在写的过程中不断去理清思路,并把每个功能点都恰当的写进去。


      测试用例的规划:


      用例的规划非常的重要,它决定整个测试用例的思路、风格、覆盖率。即对整个测试用例的成败都有直接的响。对测试用例的规划我个人总结出两条思路:一条是用例的线性规划,另一条是功能点覆盖型。这两条思路的侧重点各不相同,各有优缺点。线性的测试用例的要点是在理清每一条思路,即以业务线和流程线为主,每一条线都是一个流程,然后把功能点穿插到每条线里去。把每条业务流程比作竖线,功能线比作横线,那么功能点就是横线和竖线的节点,这样整个用例就是一张大网,我们可以随时向网中添加横线或竖线,使得覆盖率不断增加,“漏网之鱼”越来越小。

      另一种思路是功能点覆盖型。在设计之前把要整套软件的功能点理清楚,这当然是非常的难的。但我们可以参考系统设计的功能流程图,软件的需求来进行分析和提取。还有一点就是测试人员的经验来完善所需要的功能点。这种思路的重点是把每个功能点都要在设计中体现出来,以功能点覆盖为主,不管工作的业务流程。也就是说是按照各个功能模块进行划分的,分模块进行用例的设计。


      两种思路相辅相承,各有各的优点。在实际的执行过程中,有时以业务流程来编写比较容易,有时以功能模块编写比较容易。一个是以线为主,一个是以块为主。


      测试用例的设计:


      规划好测试用例的整体思路之后,就是测试用例的具体设计设计了。用例的设计的格式主要由测试环境,准备数据,前置条件,用例ID,预期输入值,期望输出结果,测试执行结果和优先级等几个部分组成。其余的还有一些统计页,打印输出的模板等。个人认为用excel设计比较简便,excel可以有多个页面,一个页面为统计测试结果和用例维护,一个为测试用例的主页面,还有一个页面可以放一些打印后的模板。这样的设计有利于用例的维护。


      用例的预期输入值和操作步骤是用例设计最重要的部分。设计好这两个部分对经后测试用例的执行至关重要,特别是操作步骤的描述,要描述清楚每一步的操作步骤,这样才能让测试的执行者准确操作,不会产生歧义。用例所写的每一句话都应该清晰的,没有歧义的,否则就会出现用例维护时,其他测试人员看不懂你写的是什么,测试用例执行的时候,看着很费力,达不到文中刚开始的要求。


      测试用例的维护:


      每个测试用例都要在经后执行的过程中去维护修改,使得测试用例的覆盖率不断提高。特别的测试用例的第一个版本时,需要维护的量是非常大的。我们可以边测试边修改测试用例,也可以根据需求添加测试用例。每维护一次测试用例,就必修记录下你修改的内容,以便于经后的阅读和别人的维护。


      以上是我近期对于测试用例设计的理解,也是我近期工作的一个总结和体会,测试用例设计是一门高深的技术,也是软件测试的重要组成部分,我们需要经验来不断提升用例的质量,设计出好的测试用例。

    评分

    参与人数 1综合技术指数 +5 收起 理由
    Jackc + 5

    查看全部评分

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    该用户从未签到

    2#
    发表于 2012-7-31 19:01:23 | 只看该作者
    谢谢LZ的分享,话说excel成为目前中国较为平凡的测试用例管理工具,还是公司投入测试的成本有关。
    通常,若公司具有多个跨区的测试部门,则需要对测试设置各种权限,这时excel就会显得力不从心了。但对于一般公司来说,excel不失为性价比较高的用例管理工具利器。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2012-8-1 23:54:09 | 只看该作者
    学习,楼主总结的很到位,最近也在思考一个问题:以业务为主和以模块为主来设计测试用例到底区别在哪里?以业务为主的话,必须把一个业务流走通才算测试用例通过,那么这个过程肯定也要关注这个业务流的各个点,这样即时出问题了也好定位问题;那么这个各个点是不是就可以看做是测试点呢?
    验证一个功能,也应该是通过一系列操作,走过多个业务,这个是不是也是业务流的体现呢?
    期待交流,谢谢
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-12-30 00:05
  • 签到天数: 7 天

    连续签到: 1 天

    [LV.3]测试连长

    4#
     楼主| 发表于 2012-8-3 16:46:34 | 只看该作者
    回复 3# 没翅膀的飞鱼


       很多时候我们的用例都把按模块和按业务流程设计的用例是混合在一起的,这两块其实区别还是蛮大的,按模块设计,因为是模块所以它完成的只是实现业务的某一块功能,也许还要A,B,C或D等其他模块通过数据接口才能完整的实现某一业务,所以说按模块设计用例很重要的是关注一些细节功能,测试用例细节部分的功能很大一部分在这里体现,而根据业务设计测试用例是更重要的内容,既然是重点就不可能有太多,所以他没有按模块设计的详细。你说的要关注的业务流的各个点应该和按模块设计中测试的功能点是有重叠的,因为只要你按模块设计的够详细,应该就覆盖了这些业务流中穿插的各个测试点。以上我的观点,感谢关注,也期待更多的交流,谢谢
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-12-30 00:05
  • 签到天数: 7 天

    连续签到: 1 天

    [LV.3]测试连长

    5#
     楼主| 发表于 2012-8-3 16:49:53 | 只看该作者
    回复 2# Jackc


        国内很多公司还是使用excel,excel还是很方便的,只要不是太大的项目。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2012-8-6 23:23:55 | 只看该作者
    回复 4# likang2005608

    谢谢你的回答,对按模块分和按业务分有了更一步的认识;这个感觉要是过分人为的区分是按模块分还是按业务分有点多余,也没必要;我们大多数测试用例都是两者的混合,具体说是按业务分的还是按模块分的有时还真说不清,呵呵
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2012-12-14 15:30:59 | 只看该作者
    回复  Jackc


        国内很多公司还是使用excel,excel还是很方便的,只要不是太大的项目。
    likang2005608 发表于 2012-8-3 16:49



        我一直以为大的项目才用excel诶 …… 借鉴楼主知识,谢谢!!!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-25 13:43 , Processed in 0.071720 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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