51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6198|回复: 14
打印 上一主题 下一主题

[原创] 测试用例的编写方法 给新来的朋友们

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-3-15 21:34:16 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
从事测试工作了一段时间,对开始书本中的理解和实际工作的经验写了这篇文章希望能帮助新来的朋友吧。如果你想进一步与我交流可以浏览的我的BLOG  http://www.ml570.com/blog 希望能与大家共同进步

     测试用例的编写,对于每一个Tester来说都是不可避免的,平时很一部分的工

作内容就是编写测试用例,如何写一个好的用例呢?如果你的用例只是用于ISO的

审核,那没必要再这里探讨这个问题。好的Case,是Tester的劳动成果,它应该

是充满智慧的,具有可复用性,启发性,能充分体现一个Tester的水平。很多人

的Case虽然写的很不错,可惜只有他自己才能看懂其中的内容和体会Case的意

思,为什么?因为它写的Case描述不清楚,只有他自己看了才明白,一个好的

Case必须有良好的书写格式与习惯,能让所有看的人都能理解,也就是说,当你

离开这个项目,其他人来接受你的工作时,只要看你的Case就能明白项目的目标

与需求。如果做到这一点呢?

    第一步,我想应该是Case格式的确立,拥有好的,清晰的格式,有利于帮助

Tester来组织他的Case,会让你事半功倍,反之亦然,一个结构不合理的格式,

会让你觉得蹩手蹩脚,影响你的发挥。如果选择一个良好的结构,要根据具体工

作的情况,项目的结构,以及用例的目标(功能测试用例,性能测试用例以及其

他)我认为不同的测试手段要使用不同的用例结构。确定好这些因素后,在来谈

谈测试用例中涉及到的一些东西,理解Case所需要的东西,我认为这些东西是比

不可少的,1:软件版本编号。2:测试用例编号,编号的格式可根据软件版本号

+用例号来确定,这样不会应为Case的日积越累或软件版本的不停升级而混乱。

3:用例的优先级,在一个时间紧凑的测试环境下,为了跟效率的完成测试用例,

我们所能做的是完成那些优先级高的用例,至于优先级如何来确定,可以根据项

目需求,或者用户那边的需求来确定,也可以根据实际经验对那些很容易产生缺

陷的模块设置为高优先级。4:用例步骤。5:输入数据。 6:实际输出数据。

7:期望输出数据。某个步骤下,输入了某条数据,你期望程序会输出什么数据。

可以一来可以与实际输出的数据相比较。8:备注。为什么要备注,可能你在思考

这个Case的时候有一个好的点子或者思路,可以写在备注里面。或者对这个用例

还有一些必要的补充说明等。9:测试环境。10:用例编写人/日期。11:测试执

行者/日期。可能根据不同的项目还需要一些补充,可以根据具体情况具体分析。

  第二步。设计测试用例,通常情况下在你编写测试用例之前,你必须要有一个测

试计划,这里我只讨论测试用例。嗯,开始设计之前还有一些准备工作,必须熟

读软件需求说明,一定要清晰的了解每一条需求,明白软件的性能指标,综合考

虑测试环境,人员配置,要根据自己的实际能力,测试工具使用状况写出符合自

己测试团队的用例。用例的划分有很多种方法,根据测试的类型,比如功能性测

试,你可以按照功能模块划分用例,划分科学的模块你可以组织这些用例直接进

行集成测试,组合部分模块或者所有模块来测试。性能测试,可以根据性能指标

来确定用例划分,对于用例环境的不同来划分用例等等。也可以根据测试工具在

组织测试用例,比如那些Case可以在测试工具上完成,那些需要手动去完成,划

分的方法很多,但是有一点必须保证,就是测试覆盖率,是否覆盖了所有的需

求。写好一个用例,需要工作经验的积累,需要对项目需求的了解,我觉得

Tester应该是公司里最了解软件需求与功能的人。测试的技术很多,可以在Case

中体现出来,比如说边界值测试,溢出测试,等价类划分测试法,等等。按照这

些来编写你的Case也可以提高你的技能。

  第二步。审核你的Test Case,怎么样才能完美你的Case呢?最好的办法就是

进行同行评审,也就是让你的同事来看你的Case,同时与开发部门负责人进行沟

通,讨论你的Case。进行这两步后可能要对你的Case进行一些修改。但并不是

这样一个好的Case就产生了,在执行测试用例的过程中,你可能还会发现很多问

题,这也是一个Case的完善过程。对于从一个项目中成长起来的Tester,会随着

对项目的不停理解与思考而随时修改自己的Case,我是这样理解的。

   嗯!以上就是我对Test Case的理解,还有很多东西没有写进去,其实要写的

东西太多太多,我想尽力过一段时间的测试工作后你也会有我同样的思考吧,在

这里希望能帮助一些在编写测试用例中遇到问题的朋友。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

该用户从未签到

15#
发表于 2010-4-8 15:09:55 | 只看该作者
恩  学习了 顶啊
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2010-4-6 14:40:45 | 只看该作者
受益
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2010-4-1 09:15:40 | 只看该作者
学习ing
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2010-3-31 15:57:21 | 只看该作者
好!正要用到呢!呵呵
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2006-3-28 20:42:50 | 只看该作者
看了,谢
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2006-3-28 14:58:11 | 只看该作者
楼主写的真好。
我进公司已经有半年了,公司正好有个项目,我是作为唯一的测试员从头做到尾的,作为一个大本刚毕业的新鲜社会人,我觉得我从这半年的测试工作中学到了很多的东西,但是我又一时讲不出个所以然来,看了楼主的这篇文章,给我理清了许多思路。

我再补充几点:1.写case时,还要善于利用公司已有的其他相关项目的test case的成品,因为这些成品已经有了比较清晰的测试归类,条理本来就清晰,可以方便我们编写新的项目测试case;
                            2.要善于分析利用客户发回的bug report,以使我们的test case 更完整,更充实。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2006-3-28 13:27:00 | 只看该作者
谢谢了,,,楼主~
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2006-3-28 00:46:38 | 只看该作者
谢谢``````  学习中``````
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2006-3-27 19:10:01 | 只看该作者
good.
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2006-3-27 15:53:57 | 只看该作者
顶sdlkfj
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2006-3-17 10:32:55 | 只看该作者
支持
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2006-3-17 10:06:03 | 只看该作者
写的真好,支持!!!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2006-3-16 17:12:04 | 只看该作者
收益非浅啊
回复 支持 反对

使用道具 举报

该用户从未签到

2#
发表于 2006-3-16 11:22:34 | 只看该作者
谢谢,受益颇多
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-27 17:52 , Processed in 0.078774 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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