以上是我的一点愚见,如果有想法的可以和我沟通。谢谢!!
顶!!
很爽哈!!谢谢楼主 我们做测试的,千万不能凭自己的想像来测试,这点前面的兄弟姐妹都提到了.我有一个小建议,你可以先把测试的要点写出来,找开发和你模块的专家评审一下,根据评审的结果来修改你的测试要点,这样比较好一点需求很重要呀!
看来首先就要明确需求,然后在进一步的工作!!!!! 原帖由 ruben78 于 2005-3-5 14:36 发表但是要什么样才能写出一份好用例,虽然到现在我有写这一些测试用例,但是在实际中的应用不大
好的 testcase 是能发现 bug 的 case,sdlkfj5 目前所在的公司也完全没有需求文档,测试用例还是后来才补写的. 楼主写的很好,我要多加学习了...... 原帖由 森林一木 于 2004-10-23 21:44 发表
有时候并不是单单以需求为主的,我现在的做法是以需求为根本,以软件界面,详细设计文档为辅助来编写测试用例。
和我现在的做法一样,需求是基础,没有详细的交互设计和界面设计测试用例是不能编写完善的。另外,对一些数据、公式计算方面的测试用例,我一般是在excel中列出输入项,算出结果,然后和测试对象对照,而不是用几个用例来固定测试。个人感觉有时候这样做更灵活。 我个人的想法:
1、从需求文档中摘取测试需求,也就是那些菜单模块要测试(按目录例出),这个菜单(模块)提供了那些功能(分子目录)。
2、每个功能的输入值有多少种情况。(考虑等价类划分、边界值方法)各输入值的预期结果应该是怎样的。
3、在写完整个测试用例树,再根据测试用例的优先级划分同级执行顺序。
4、如果有业务更改,再及时补充用例。
实践过程中碰到很多问题:
如:测试用例如何分配;
用例的详细程度;(我按照我的思路写的话,每次都写很多,但对于输入值我只给范围,因为不想局限其他测试人员的思路)。
工作量,有时测试时间紧,我写的用例大家就看不懂了(比如,我只例出有多少种情况,情况组合由测试人员自己组合)
不知道各位对我的想法有何看法?
希望大家给与一些意见。 豆腐干 楼上的楼上说的“用例的详细程度”问题真的是个很令人困惑的问题,写的太详细浪费时间且容易给后来看测试用例的人造成思维定式,不太详细吧别人又看不明白.
测试感想
测试有一段时间了,感想就是:幸亏数学的排列组合学的不错。 原帖由 土豆泥 于 2004-9-13 11:50 发表但是我有一个不解点,就是写测试用例时,是根据需求规格说明书来写,我想知道 的是,如果需求说明书里没有写的比较细的话,怎么办?如:有什么按钮,输入些什么数据,数据类型的限制什么的,这样的话,我在写测 ...
我们公司是这样的,需求说明书和UI设计书是先后出来的。然后测试用例就根据需求说明书和UI来写,同时,开发人员根据需求说明书和UI来进行开发。这样比如有什么按钮啦什么的,就有谱了。如果需求变化了,那么UI和测试用例,开发代码一起变。 楼主讲解的还是有一定的首理的,但是有个疑问:如果项目需要录入大量的数据,例如现在的ERP软件,里面就有很多需要录入大量的数据,如果按这种方式进行测试用例的编写,可以想像有多大的数据量?而且这样编写对于以后的系统测试有什么用呢?
有这样的疑问很久了,在需要录入大量数据的情况下设计测试用例,单就特殊字符、非标准时间、字段长度加长就需要很多测试用例,如果把用例和测试数据分开,有没有这样的实例贴出来参考一下。
还有很多查询模块,是否所有的各查询条件都要进行组合起来测试?比如说3个查询条件,就有8种组合情况,是这样的吗? 大家讲得不错! 原帖由 lbzhong 于 2004-8-20 11:39 发表
小弟认为做黑盒测试的基本条件是需要清楚你负责的模块的功能和与其它模块的联系及相互之间的关系、影响、数据流向。拿到一个模块后1、分析(需求文档和测试分析文档)2、大体查看3、在大体查看基础上与分析做对比实 ...
简单点了吧. 原帖由 njalic 于 2005-1-10 19:10 发表
楼主讲解的还是有一定的首理的,但是有个疑问:如果项目需要录入大量的数据,例如现在的ERP软件,里面就有很多需要录入大量的数据,如果按这种方式进行测试用例的编写,可以想像有多大的数据量?而且这样编写对于以后的 ...
软件测试最忌讳的就是永无休止的测试下去,如果这样的话,那测试就可以不用去做了。测试软件要先了解目前你测试的软件用户最关心的功能是什么,还有此软件的风险较大的部分在哪里,那么测试就应该重点在此。目前有些软件要录入大量的数据,那么你可以运用黑盒测试中的等价类、边界值……测试!! 我从事测试已经半年了,我感觉没学到东西,请帮我指点一下,
要做一个好的测试员应该具备些什么?