51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: lbzhong
打印 上一主题 下一主题

小弟做黑盒测试及测试用例的一点心得,写出来原和大家一起分享。

[复制链接]

该用户从未签到

141#
发表于 2006-6-8 18:27:16 | 只看该作者
好,谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

142#
发表于 2006-6-10 23:32:31 | 只看该作者
技持
回复 支持 反对

使用道具 举报

该用户从未签到

143#
发表于 2006-6-27 18:07:17 | 只看该作者
这样的测试用例粒度是不是有点大了,最好的测试用例就是一个用户后面就应该有一个bug。如果有业务流程的话,应该针对业务流程也写一些测试用例,不能简单地按照功能测试点去测试。这是我在做测试的时候总结的一点。因为我们做的是网上支付,相对于功能来说业务流程是最重要的。并且现在很多的java开发都要从面对对象的开发转入面对业务的开发,所以我们的测试应该也有一个过渡的。
     以上是我的一点愚见,如果有想法的可以和我沟通。谢谢!!
回复 支持 反对

使用道具 举报

该用户从未签到

144#
发表于 2006-7-6 09:35:03 | 只看该作者

顶!!

很爽哈!!谢谢楼主
回复 支持 反对

使用道具 举报

该用户从未签到

145#
发表于 2006-7-9 20:41:56 | 只看该作者
我们做测试的,千万不能凭自己的想像来测试,这点前面的兄弟姐妹都提到了.我有一个小建议,你可以先把测试的要点写出来,找开发和你模块的专家评审一下,根据评审的结果来修改你的测试要点,这样比较好一点
回复 支持 反对

使用道具 举报

该用户从未签到

146#
发表于 2006-7-19 11:41:00 | 只看该作者

需求很重要呀!

看来  首先就要明确需求,然后在进一步的工作!!!!!
回复 支持 反对

使用道具 举报

该用户从未签到

147#
发表于 2006-7-19 13:44:23 | 只看该作者
原帖由 ruben78 于 2005-3-5 14:36 发表
但是要什么样才能写出一份好用例,虽然到现在我有写这一些测试用例,但是在实际中的应用不大


好的 testcase 是能发现 bug 的 case,sdlkfj5
回复 支持 反对

使用道具 举报

该用户从未签到

148#
发表于 2006-7-20 16:40:54 | 只看该作者
目前所在的公司也完全没有需求文档,测试用例还是后来才补写的.
回复 支持 反对

使用道具 举报

该用户从未签到

149#
发表于 2006-7-26 10:21:59 | 只看该作者
楼主写的很好,我要多加学习了......
回复 支持 反对

使用道具 举报

该用户从未签到

150#
发表于 2006-7-27 14:50:59 | 只看该作者
原帖由 森林一木 于 2004-10-23 21:44 发表
有时候并不是单单以需求为主的,我现在的做法是以需求为根本,以软件界面,详细设计文档为辅助来编写测试用例。


和我现在的做法一样,需求是基础,没有详细的交互设计和界面设计测试用例是不能编写完善的。另外,对一些数据、公式计算方面的测试用例,我一般是在excel中列出输入项,算出结果,然后和测试对象对照,而不是用几个用例来固定测试。个人感觉有时候这样做更灵活。
回复 支持 反对

使用道具 举报

该用户从未签到

151#
发表于 2006-7-31 12:17:13 | 只看该作者
我个人的想法:
1、从需求文档中摘取测试需求,也就是那些菜单模块要测试(按目录例出),这个菜单(模块)提供了那些功能(分子目录)。
2、每个功能的输入值有多少种情况。(考虑等价类划分、边界值方法)各输入值的预期结果应该是怎样的。
3、在写完整个测试用例树,再根据测试用例的优先级划分同级执行顺序。
4、如果有业务更改,再及时补充用例。

实践过程中碰到很多问题:
如:测试用例如何分配;
       用例的详细程度;(我按照我的思路写的话,每次都写很多,但对于输入值我只给范围,因为不想局限其他测试人员的思路)。
       工作量,有时测试时间紧,我写的用例大家就看不懂了(比如,我只例出有多少种情况,情况组合由测试人员自己组合)
        不知道各位对我的想法有何看法?

希望大家给与一些意见。
回复 支持 反对

使用道具 举报

该用户从未签到

152#
发表于 2006-8-1 12:12:13 | 只看该作者
豆腐干
回复 支持 反对

使用道具 举报

该用户从未签到

153#
发表于 2006-8-4 08:59:11 | 只看该作者
楼上的楼上说的“用例的详细程度”问题真的是个很令人困惑的问题,写的太详细浪费时间且容易给后来看测试用例的人造成思维定式,不太详细吧别人又看不明白.
回复 支持 反对

使用道具 举报

该用户从未签到

154#
发表于 2006-8-15 17:02:57 | 只看该作者

测试感想

测试有一段时间了,感想就是:幸亏数学的排列组合学的不错。
回复 支持 反对

使用道具 举报

该用户从未签到

155#
发表于 2006-8-19 10:42:28 | 只看该作者
原帖由 土豆泥 于 2004-9-13 11:50 发表
但是我有一个不解点,就是写测试用例时,是根据需求规格说明书来写,我想知道 的是,如果需求说明书里没有写的比较细的话,怎么办?如:有什么按钮,输入些什么数据,数据类型的限制什么的,这样的话,我在写测 ...


我们公司是这样的,需求说明书和UI设计书是先后出来的。然后测试用例就根据需求说明书和UI来写,同时,开发人员根据需求说明书和UI来进行开发。这样比如有什么按钮啦什么的,就有谱了。如果需求变化了,那么UI和测试用例,开发代码一起变。
回复 支持 反对

使用道具 举报

该用户从未签到

156#
发表于 2006-8-19 15:37:29 | 只看该作者
楼主讲解的还是有一定的首理的,但是有个疑问:如果项目需要录入大量的数据,例如现在的ERP软件,里面就有很多需要录入大量的数据,如果按这种方式进行测试用例的编写,可以想像有多大的数据量?而且这样编写对于以后的系统测试有什么用呢?

有这样的疑问很久了,在需要录入大量数据的情况下设计测试用例,单就特殊字符、非标准时间、字段长度加长就需要很多测试用例,如果把用例和测试数据分开,有没有这样的实例贴出来参考一下。
还有很多查询模块,是否所有的各查询条件都要进行组合起来测试?比如说3个查询条件,就有8种组合情况,是这样的吗?
回复 支持 反对

使用道具 举报

该用户从未签到

157#
发表于 2006-8-21 13:13:31 | 只看该作者
大家讲得不错!
回复 支持 反对

使用道具 举报

该用户从未签到

158#
发表于 2006-8-27 18:36:38 | 只看该作者
原帖由 lbzhong 于 2004-8-20 11:39 发表
小弟认为做黑盒测试的基本条件是需要清楚你负责的模块的功能和与其它模块的联系及相互之间的关系、影响、数据流向。拿到一个模块后1、分析(需求文档和测试分析文档)2、大体查看3、在大体查看基础上与分析做对比实 ...

简单点了吧.
回复 支持 反对

使用道具 举报

该用户从未签到

159#
发表于 2006-9-2 15:51:39 | 只看该作者
原帖由 njalic 于 2005-1-10 19:10 发表
楼主讲解的还是有一定的首理的,但是有个疑问:如果项目需要录入大量的数据,例如现在的ERP软件,里面就有很多需要录入大量的数据,如果按这种方式进行测试用例的编写,可以想像有多大的数据量?而且这样编写对于以后的 ...


软件测试最忌讳的就是永无休止的测试下去,如果这样的话,那测试就可以不用去做了。测试软件要先了解目前你测试的软件用户最关心的功能是什么,还有此软件的风险较大的部分在哪里,那么测试就应该重点在此。目前有些软件要录入大量的数据,那么你可以运用黑盒测试中的等价类、边界值……测试!!
回复 支持 反对

使用道具 举报

该用户从未签到

160#
发表于 2006-9-20 13:44:27 | 只看该作者
我从事测试已经半年了,我感觉没学到东西,请帮我指点一下,
要做一个好的测试员应该具备些什么?
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-9-28 02:15 , Processed in 0.089531 second(s), 22 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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