danielle758 发表于 2006-5-23 21:48:48

回复 #40 rockday 的帖子

同意，写得越细越好

CAnDO 发表于 2006-5-24 11:51:42

看完这贴 学习到了 谢谢~~俺也是新人sdlkfj3

jihuli5 发表于 2006-6-1 20:56:10

好象不符合测试用例的书写格式吧。。。。

superhenry 发表于 2006-6-2 16:26:38

小结

Step Name                                                       Description                                   Expected Result
Step 1正确输入账号、密码、验证码、安全问题回答等        输入项符合本文中A.2数据校验部分的各项        能进入正确的界面作正确的操作
Step 2输入step1中的各项的错误组合                不能登录成功；提示信息正确；光标定位到错误位置
Step 3 对特殊输入的处理是否正确        1.左空格、有空格的字符。2.字符过长。3. 包含特殊字符的：～！◎＃￥％……※×（）《》。？、/\|        有特殊字符处理
Step 4是否有sql注入攻击的缺陷        输入如’1=1’ or 2=2’、‘;select * from user’（注意前面的分号）        登录不成功
Step 5登录系统后、后退、前进，能否登录成功        系统是否允许用户登录校验        按预置
Step 6登录不成功        1.是否退回到登录界面。2.是否所有登录录入栏都为空白，或者保留原有输入        1.返回到登录界面。2.按预置

大の头 发表于 2006-6-7 11:01:48

能不能有这种想法，在输入用户名和密码后，点击进入，如果前两个输入有误，给出提示，正确后在给验证码，这样不省事了？~~~~~~~~~~~~~~~~~
我是新手，请大家不要见怪！

大の头 发表于 2006-6-7 11:07:33

我有个想法不知道行不？先输入用户名和密码，如果正确后在给验证码，之后进入。
如果前面任何一个有误，就不可以进入下一个程序。
不置可否

kokahkhk 发表于 2006-6-8 15:43:08

写一组正确数据
然后用边界值弄几组缺陷数据
一个登陆写这么多，日后业务还怎么做啊，项目上的时间风险是不允许的

hmilyjch 发表于 2006-6-9 10:27:18

我同意40楼的说法！！
新人，想得越多写得越多，为了以后写得越简洁！

也很喜欢楼主 的 钻研精神~

rockyou 发表于 2006-6-10 14:29:13

对，刚开始就是要写得约详细越好，以后才会归纳总结。

JPeanut 发表于 2006-6-11 17:03:53

书面一点的说法,,就是bug具有免疫性
把测试数据放到用例里面,,虽然可以把测试做的全面,,但是,,很容易是bug免疫你的测试数据和用例
而且,,要考虑开发人员的惰性,,他们很容易就直接把你的测试用例的数据作为他们修改完的测试,,这样很容易出问题的

Wjq5523075 发表于 2006-6-13 11:57:05

还是学了不少东西!顶

xingzunxi 发表于 2006-6-15 10:08:01

j今天看了这个帖子，很受启发阿？输入空格算一个密码么，如果多输入了一个空格应该提示错误吧？

hu7 发表于 2006-6-19 16:28:03

学习中：）欣赏楼主钻研精神。一起努力

ps：楼主的头像好可爱，嘿嘿

阳光岁月 发表于 2006-6-20 16:37:30

呵呵.我是新手中的新手.刚开始接触测试工作.不过我们是面向网络游戏的.不知道以后会让写些什么样的测试报告....请问各位大虾们,有在做网络游戏这方面的测试的吗??

JPeanut 发表于 2006-6-20 19:58:56

to xingzunxi ，这个当然算bug拉，你去看看 小蚂蚁 大姐的blog的一个帖子，就说空格的bug

elsie520 发表于 2006-6-23 11:45:56

好象缺少了点什么啊预期结果没写啊 边界值也没有测试啊

枫飞林 发表于 2006-6-23 16:52:18

你写的怎么是这样的 ！你考虑约束条件了吗 ？你写的只用正常流程和分支流程
测试用例只写正确的结果，不写错误的 ！

lily_liuyun 发表于 2006-7-13 11:40:05

原帖由 slide 于 2006-4-25 23:03 发表
对于描述可以简化一些，
你的用例其实就是三个参数，用户名密码和校验码，每个有正确、错误、空三种取值的任意组合。
楼上还给补充了不少，都很有用的。

领导要求你给出具体的测试用例数据是有道理的，具体的 ...

探讨一下。
我自己一直觉得如果可以不写具体用例数据的，尽量不写具体用例数据，这样更灵活一点。
我觉得写成 “正确的用户名“，测试的时候，可以更随意一些。但是如果写成”admin“，那么到时候一定要保证数据库里有这条数据，这样各CASE之间的数据依赖会更多，不是很灵活。

以前也看到网上有一篇关于测试用例设计的文档里有讲到这个问题，也是用这个login功能做例子的，但是原文找不到了。

不知道大家是怎么理解这个问题的。

slide 发表于 2006-7-13 13:02:42

灵活性和确定性都是必要的。
可以考虑这样进行划分：

在用例设计时，可以保留一定的灵活性，明确设计的方法和原则，如果能够保证根据原则直接设计具体用例而不会出现问题，就不用给出具体例子了，如果不能，也可以考虑给出一个具体例子，方便理解和执行。保持灵活性对于用例的修改和重复使用是比较有帮助的，也可以一定程度上减小工作量。

在用例执行的时候，要记录实际执行的详细数据，包括具体的步骤和详细的结果，这样才能保证有效的执行信息不丢失。有的时候，执行过程中会有些灵感，临时做一些变更，要把它们详细记录下来，出现问题的时候，才好进行定位和分析，否则没有了具体的内容，后面的分析工作就没法做了。


原帖由 lily_liuyun 于 2006-7-13 11:40 发表
探讨一下。
我自己一直觉得如果可以不写具体用例数据的，尽量不写具体用例数据，这样更灵活一点。
我觉得写成 “正确的用户名“，测试的时候，可以更随意一些。但是如果写成”admin“，那么到时候一定要保证 ...

sky_bj 发表于 2006-7-13 16:18:44

原帖由 slide 于 2006-7-13 13:02 发表
在用例执行的时候，要记录实际执行的详细数据，包括具体的步骤和详细的结果，这样才能保证有效的执行信息不丢失。有的时候，执行过程中会有些灵感，临时做一些变更，要把它们详细记录下来，出现问题的时候，才好进行定位和分析，否则没有了具体的内容，后面的分析工作就没法做了。

恩。说的有道理。
页: 1 2 [3] 4
查看完整版本: 小妹早上刚写的一个测试用例,初次写,还请多多指教!