51Testing软件测试论坛

标题: 测试用例怎么编写? [打印本页]

作者: zccsict    时间: 2004-7-27 16:55
标题: 测试用例怎么编写?
我是一个初学者,什么也不太懂  多多指教!
论坛上研究测试的多,讲用例的也有!但是谁能告诉我具体 测试用例怎么编写?
作者: 天网    时间: 2004-8-5 17:36
这么大的概念在这里怎么说的清楚?
作者: 东方一华    时间: 2004-8-16 17:57
个人认为
主要是把握测试的要点:
这次测试的目的,需求,过程,等等!
作者: alfra    时间: 2004-8-17 15:34
标题: 我现在用的是这一套。按照这个写用例。
感觉是等价划分法和因果法结合了。

前面登陆窗体等安全测试时,用等价划分法考虑的比较多。后面窗体复杂操作复杂的时候,为了不遗漏,把因果法揉进了这种用例写法。

测试设计人员需要给测试人员提供一个标准化文件。便于交流。在公司内部制定一个统一的用例书写规范也是很必要的。

[ Last edited by alfra on 2004-8-17 at 15:35 ]
作者: jackei    时间: 2004-9-12 00:18
感觉alfra朋友的用例文档模板还是用了比较多的基于UI的方式来书写的,不知道楼上诸位现在都是测试哪方面软件的。个人感觉这个测试用例的格式如果应用在一个业务复杂,规模庞大的系统中,会产生大量的测试用例文档,在进行测试用例文档维护时有比较大的困难。不知道alfra是否可以具体说说这个模板在实际工作中应用的情况,并且上传一部分其他方面的测试用例来看一下,比如对于业务逻辑的测试。
作者: alfra    时间: 2004-9-15 20:48
标题: 楼上的说对了
一个功能复杂的c/s软件,功能测试这块的测试用例很大很大,以前我在qq群里也提到了这个问题,我当时写的那个功能测试用例达到了1m以上。没有图全是字。后面把应该出现的提示框都用截图的方式放进去。。。。。
达到了。。。。2m

老天啊,这么大。
作者: alfra    时间: 2004-9-15 21:18
标题: 不过也有一个好处就是复用性强。
比如打印功能,不管其中的元素如何命名,打印需要实现的功能就是那么几个,需要预览,需要定义页面设置等。

我设计一个打印用例,就改项目名称等一点儿内容就可以一直用下去。

业务逻辑的测试现在没法给文档。我就先说说。
比如,
一个简单的投标、中标管理的例子
假设,a公司在已注册公司表单中
         a公司参与投标b项目
         查看b项目可以看到备选投标公司表单中有a公司投标信息
         查看a公司可以看到投标项目里有b项目信息介绍
设计用例如下:
删除a公司,查看b项目是否还有该公司的投标信息,预期的结果,a公司不能被删除,弹出对话框“参与投标公司不能被删除”。

这个也是我实际的测试用例。。。。赫赫,这个用例也用了好几遍,测试的实际结果,好象一般程序员不考虑我反着来,先用这个公司投标,然后又把这个公司删除了怎么办这个问题,测试结果大抵都是很奇怪的一大片空白。因为a公司删除了。

删除项目b,查看a公司是否还有项目b信息,预期的结果,有,显示b项目状态为撤销。

jackei说的业务逻辑测试是不是指这种???

当然还有更改等操作,言多纸短。打住打住。
作者: jackei    时间: 2004-9-15 23:00
alfra,个人感觉您上面说的这个用例所针对的是一条业务规则或者说一个特性,还并不是一个完整的有效的业务。
另外,想问一下,您的测试项目中对于这样的用例有多少个?您的测试团队中有多少人?其中多少人负责维护这个文档?您所测试的是项目还是产品?
作者: alfra    时间: 2004-9-16 00:18
项目还是产品,对啊,这个是个问题,多是项目,而非产品,产品化过程很少履行,一般而言,测试报告,验收报告就截至。没有正规的产品化过程。

我是土学生,都是从网上和我自己摸索出来的用例设计方法

最正规的产品化测试,最近才碰到。

不说了,再说,我就露馅了。

[ Last edited by alfra on 2004-9-16 at 00:28 ]
作者: jackei    时间: 2004-9-16 12:15
您别客气,其实我们现在都是摸着石头过河,不过还是想请您回答那几个问题,了解一下您那边现在的使用情况。
您的测试项目中对于这样的用例有多少个?您的测试团队中有多少人?其中多少人负责维护这个文档?
作者: alfra    时间: 2004-9-16 16:52
标题: 斑竹有令,那我就回答。
测试项目中对于这样的用例有多少个?
举一个简单的例子,一个财务软件,功能模块有8个,用例达到400左右。

测试团队中有多少人?
五个到四个人测试(有项目可以临时借调),三十人左右的开发团队。

其中多少人负责维护这个文档?
一个到两个


看了你写的测试需求与测试用例

我觉得我要说明的是一点,现在写的测试用例全都是以手动测试为主的测试用例。我认为要尽可能做到遍历,测试用例写的傻瓜易懂,因为有可能需要让用户或者一个压根计算机什么都不知道的人测试。
举了例子,我最近才参与测试完成的一个维哈柯文化软件,全公司除了那个开发的人,就只有一个会计是维族人。我的测试用例达到的目标就是,她拿着我的测试用例和用户手册可以遍历所有的界面,提示框。检查是否符合需求分析说明书要求。

自动化测试过程,那个是另一回事情了。

[ Last edited by alfra on 2004-9-16 at 19:44 ]
作者: jackei    时间: 2004-9-16 20:59
其实对于测试用例设计的方法和格式,对于不同的公司,还是有很大的区别的,原则还是要找到一个在自己的工作中有效的方法和格式。alfra,我还是觉得如果有一个针对实际业务进行测试的例子,大家看起来会效果更好。比如您说到财务软件,那我不知道您所测试的财务软件是否涵盖了财务工作的所有内容,有没有测试过财务报表之类的内容,如果有这方面的东西可以看到就太好了。
作者: wintersea    时间: 2004-11-19 17:15
请教alfra一个问题
在你给的测试用例中,会出现001_9, 002_2, 002_3这样的编号
应该是表示其中的一个对另一个的依赖吧
那要是其中的一个编号或者其它改变了,也要对另一个进行修改,
如果这种现象出现很多次,那工作量启不是很大
作者: newzxf    时间: 2004-11-23 08:59
测试用例不难写,但要写出高水平的可重用的测试用例就不那么简单了,愿意和大家多交流。my email:newzxf@sohu.com
作者: tyx0903    时间: 2004-12-10 12:33
标题: 测试用例还是不会写

作者: cwj007    时间: 2004-12-11 12:39
测试用例应该包含的内容,只是参考:
    编号:唯一编号
    前置条件:说明测试路径
    重要级别:对后期的测试用例执行的考核提供一个标准
    输入:输入的条件
    期望输出:期望输出的结果
    实际输出:实际输出的结果
    是否正确:是/否
    执行人:测试用例执行人标志
    执行时间:测试用例执行的时间
    备注:其他说明文字

当然设计用例的方法可就多了,可以多找几本测试方面的书看看,先打个基础
作者: alfra    时间: 2005-2-5 19:14
Originally posted by wintersea at 2004-11-19 05:15 PM:
请教alfra一个问题
在你给的测试用例中,会出现001_9, 002_2, 002_3这样的编号
应该是表示其中的一个对另一个的依赖吧
那要是其中的一个编号或者其它改变了,也要对另一个进行修改,
如果这种现象出现很多次 ...


我自己找不到这个帖子了。。。所以很久很久才给你回答,这个问题。。我使用了一个工具解决了。
原来这种方式的测试用例有问题,维护量太大,所以后期对这个问题作了一些更改,现在我的测试用例基本是以窗体事件为一个集合。
比如项目申请[新增],[]内指的是按钮事件。
也可以使别的什么鼠标事件或者键盘事件。

推荐测试团队的平台管理以及文档平台sharepoint2003,还有填写测试用例可以使用infopath,直接进入数据库。
作者: caohfei    时间: 2005-2-20 13:09
标题: 有没有关于测试软件的讲解
我是新手,我想知道有关测试软件都有哪些,大概讲一下就行
作者: zlwdimple    时间: 2005-2-21 16:45
标题: 请教alfra
公司让我自学软件测试,我现在所能做的也就只有黑盒测试,功能方面的
我设计的测试用例,有些和你给出的模板中的差不多,不过,我总是觉得考虑周全比较难,各种突发情况,可能出现的异常情况,测试起来,很繁琐。有没有一个比较规范的顺序或过程呢?

一个也试图摸着石头过河的新手
作者: xuerzj    时间: 2005-2-22 17:15
测试用例中一定要包含测试数据吗?严格按照测试数据来执行测试,会不会减少了灵活性?用描述性的语言来概括测试数据是否更好?
比如,对alfra例子中,一类数据是系统管理员用户与密码,一类是普通用户与密码。不写具体的用户名和密码。这样也会减少测试用例的维护量。

测试用例的详细程度如何把握,一直是我头疼的问题!
作者: 依伊卜舍    时间: 2005-2-25 10:21
测试用例的详细程度如何把握,这个问题我也有。当然我写的测试用例,我的建议是用描述性的语言来概括测试数据,但我们的项目经理认为用非常严格的测试数据来做。他的理由是可以让不会操作的人也可以操作,我的理由是由测试人员来操作可以增加灵活性。最后我还是按照他的想法去做了,这样做的结果是数据非常多,而且不一定能够全面。
作者: alfra    时间: 2005-3-7 10:49
Originally posted by 依伊卜舍 at 2005-2-25 10:21 AM:
测试用例的详细程度如何把握,这个问题我也有。当然我写的测试用例,我的建议是用描述性的语言来概括测试数据,但我们的项目经理认为用非常严格的测试数据来做。他的理由是可以让不会操作的人也可以操作,我的理 ...


我的做法同依伊卜舍。
但是一些特殊的测试数据,因为怕测试人员对商业逻辑理解和最初的测试目的不一致,必须要写出来。

如果实现了数据驱动的robot测试,把数据准备和测试用例就可以分开了。
测试用例设计者只需要做用例的设计,具体需要什么数据具体的测试者制定,过程中是否符合测试目的和过程是否规范需要测试经理监督。

附,数据驱动测试文档(应该也是51里下到的)
作者: cathering851004    时间: 2009-7-27 13:19
学习
作者: wdlcoke    时间: 2009-8-6 14:11
标题: 测试用例的详细程度如何把握,一直是我头疼的问题!
测试用例的详细程度如何把握,一直是我头疼的问题!
?????????????????????????????????




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2