一个小测试点就可以写很多内容
比如测一个窗口
先看界面,这里可以写上你所想到的所有界面要求
按钮,也可以写很多
有输入的话,可以写输入字符限制:空、任意字符(中文、英文、数字、特殊字符、全角字符、半角字符);输入项之间的约束关系等
总之分成很多小的测试点,直到认为无法在细化为止
在加上一些异常的操作,也可以在测试时,随时发现问题,随时补充测试用例
其实,在测试的时候,发现的问题多了,就不怕写用例了。用例也是在测试过程中不断补充积累起来的 恩!同意楼上的! 回qinbob:预置条件我认为是执行该用例的前提条件,比如测登录界面的用户名,前提条件是打开登录界面。 最近好烦 写用例其实就是测试设计工作中一个比较靠后的程序了,我认为一般针对某一个功能来考虑:
1、先要分析熟悉这个功能的特点、组网要求、应用场景等等,提取测试需求
2、然后设计一个可行的测试方案,分析好该功能的所有的独特测试点以及跟其他功能交互的测试点以及异常测试
点!当然也逃考虑好测试周期、成本,选择软件工程里面最适合的一种或者几种方法!
3、根据测试方案设计用例,一般拿来专项测试的软件都不小,建议先分好测试项目:
1、项目编号
2、项目标题
4、在每一个测试项目里面写作具体的用例,楼上的一家已经说得无可挑剔了
“1、编号
2、标题
3、重要级别
4、预置条件
5、输入
6、操作步骤
7、预期输出”
不过我建议再加上一项
:7、说明——主要以被测试执行是加上一些说明,如相当特殊的地方,以及对该用例本身有异议都可以在这里注释一下!
——希望大家都说说,给他人共享一下! 关于测试,我经验不多,是从开发刚刚转做白盒,所以请问一下,单元测试的测试用例如何写,也和功能测试一样的吗,大家所说的覆盖率又是什么意思? 呵呵!大家都说的很好呀!我们公司的测试用例写的很简单,而且很粗陋(公司的模板一直是这样,我们都是照着写写)!真做测试的时候几乎没什么用,和看需求没什么不同!一般我都不看,测试路径全凭自己想:D 楼主:你这个问题(如何写好的测试用例);
我觉得可以从两个方面来回答
第一:从形式上,也就是应该包括必须包括的,如:用例编号,输入,输出………………
第二:从思想上,有句话说的好,好的测试用例是发现了别人没有发现缺陷的 测试用例。所以用例的设计思想上更加重要。当然不要看了 这句话就绞尽脑汁去想一些刁钻的问题,记住一点:测试的最终目的是为了提高软件质量,而不是发现bug:) 叙述清楚,过程和步骤,预期的输出和实际结果都很重要。我觉得黑盒测试主要还是软件功能上的测试,要想更加深入就必须对系统有个清楚的了解,实现原理,整个流程,这会帮助你从多个方面考虑用例的设计,也才更能发现深层次的问题。当你对系统已经很清楚了,你可以考虑从代码逻辑上去考虑测试的流程。 另外在测试前,有一个测试模型是很重要的,他可以是你的测试一直围绕一个问题来展开,不致于迷失方向,同时也可以有效地保证测试的覆盖率,不致于有太多的遗漏。 楼上所说的测试模型指什么? 谢谢了!!!! 预置条件就是你要执行这个测试用例之前要准备的工作,比如测试软件的基本功能,首先要把软件成功地安装好,在接着做他的功能测试,就是执行这个测试用例的前提. 做为一个新人,很感谢你们分享的这个宝贵的经验 为什么不要写很详细的操作步骤呢?
我一开始操作步骤也写得很笼统,可使被告知,一定要写很详细的操作步骤,不然开发人员会找不到错误,或者说他们在执行的时候没有发生错误。
能不能给解释一下。 看了各位的回帖,受益匪浅 原帖由 阿珊 于 2006-3-24 15:51 发表
为什么不要写很详细的操作步骤呢?
我一开始操作步骤也写得很笼统,可使被告知,一定要写很详细的操作步骤,不然开发人员会找不到错误,或者说他们在执行的时候没有发生错误。
能不能给解释一下。
这个牵涉到 bug的重现问题,很多时候,你第二次再去找这个bug会出现逃逸现象,当然,随时开着桌面捕捉程序是一个必须的习惯,文字永远没有图形来的直观。
另外,正规体系 测试设计和测试执行时分开的,不知道你们公司怎么样,你写的用例只有自己能够操作的话,那么那些做执行的就比较郁闷了。当然了,目前大环境貌似用例执行都是一个人做的-____- 我也是新到公司做测试不久的,也做的是功能测试,自己感觉这东西刚开始是写不出什么的,就象刚来发现的BUG都比较浅显,过了两个礼拜,就可以发现一些逻辑错误上的BUG了。
我很想进行一下系统的培训,可惜真的是没有时间啊~~~~~~ 我想了解一下大家对于每一次测试后的总结是如何进行的,我觉得测试后总结是很重要的,但好像很难下手 恩,你说很好哦,支持你!
页:
1
[2]