51Testing软件测试论坛

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

作者: twinsczl    时间: 2009-4-17 16:41
标题: 怎么设计测试用例?
有两个文本框,第一个文本框是标识框,要求输入内容由字母、数字和下划线组成,但首字符必须是字母;
第二个文本框是数据框,要求输入合法数据,界面上还有一个确定、取消按钮,请你针对两个文本框写出测试用例。
作者: twinsczl    时间: 2009-4-19 18:01
这个论坛人气太晕人了!~·
作者: freedliweiyuan    时间: 2009-4-20 11:34
第一个    有效的                无效的
          字母+数字+下划线      全是数字
          字母+数字              数字+字母+下划线
          字母+下划线             下划线+数字+字母
           字母                     字符

尽量用少的数据覆盖 多的有效数据,每一个无效数据选一个测试数据,大概有6个测试用列
作者: twinsczl    时间: 2009-4-28 19:52
首先谢谢你的回答!

假设这个是一个登陆的页面!

6个测试用例实在是勉强了点,如果是对安全性比较高的系统,还需要更细致的划分等价呀!

对于没有任何的文档的说明,我们是否需要探索性的测试下,登陆界面的检查的方式,或者文本框具体能处理的字符个数等???

要保证合法用户进去,非法用户进不去!

[ 本帖最后由 twinsczl 于 2009-4-29 21:48 编辑 ]
作者: june.diny    时间: 2009-4-29 09:53
这个写用例的话,MS会很多唉,我就说下自己的想法吧
a、输入字符包含字母、数字、下划线(以字母为首字符进行排列组合,如字母+数字,字母+下划线等)
b、输入字符包含字母、数字、下划线(不以字母为首字符,如数字+字母+下划线、数字+数字等)
c、输入非法字符,即除字母、数字、下划线以外的常用字符,如汉字、标点符号、日期、时间等
d、输入特殊字符集,如NULL、\n、%d、@一类的特殊字符集,看系统是否做异常处理
e、输入超长字符,假设文本框最多255个字符,尝试输入256个字符,检查程序能否正确处理;
f、输入默认值,空白,空格;
g、利用复制,粘贴等操作程序是否对输入做合法性检查;
h、在输入过程中,按下回车、Tab、Esc等键是跳出文本框,还是接受字符;

新手上路,有不对的地方,请各位大侠指出啊,共同学习

[ 本帖最后由 june.diny 于 2009-4-29 09:58 编辑 ]
作者: june.diny    时间: 2009-4-29 09:57
对了,针对a设计用例时应分成两部分:
1、资料库里已经存在的用户名
2、资料库里不存在,但符合规则(由字母、数字和下划线组成,首字符为字母)的用户名
作者: twinsczl    时间: 2009-4-29 21:52
标题: 回复 6# 的帖子
谢谢你的回答~·!

你考虑的十分的周全,很仔细,我相信一定能做的更好的。

测试这个工作很容易偷懒,呵呵,希望大家共同进步。
作者: june.diny    时间: 2009-4-30 21:54
原帖由 twinsczl 于 2009-4-29 21:52 发表
谢谢你的回答~·!

你考虑的十分的周全,很仔细,我相信一定能做的更好的。

测试这个工作很容易偷懒,呵呵,希望大家共同进步。


呵呵,共同学习
作者: june.diny    时间: 2009-5-5 21:09
补充一点,如果这是一个登陆页面的话,在设计用例的时候,特别需要考虑针对SQL注入设计用例,如'1=1'这种恒等式,是否会透过数据库,而成功登陆页面~
作者: 爱小鱼    时间: 2009-6-17 13:40
我也来补充一点。要是登陆页面,是否要考虑登陆次数的限制。比如登陆三次不成功。不可以在登陆等!
作者: 千里    时间: 2009-6-17 14:39
楼主所述不就是因果图测试用例设计的一个经典案例吗?
作者: 千里    时间: 2009-6-17 14:40
原帖由 爱小鱼 于 2009-6-17 13:40 发表
我也来补充一点。要是登陆页面,是否要考虑登陆次数的限制。比如登陆三次不成功。不可以在登陆等!

在测试的时候加上三次不成功的用例就行了吧。。。
作者: 147318902    时间: 2009-6-18 13:39
2个字段,如果写那么详细的话,整个系统的用例会写累死你。




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