你的用例其实就是三个参数，用户名密码和校验码，每个有正确、错误、空三种取值的任意组合。
楼上还给补充了不少，都很有用的。
领导要求你给出具体的测试用例数据是有道理的，具体的数据更能看出问题，更有可操作性。
但你的工作也没有白费，其实属于测试用例的不同阶段，你现在做的仅仅是设计，领导要求的是实现。
当然，设计很多时候是很必要的步骤，最好不要省略，这样，在进一步修改或变更时，你才能作得更好更快。 思路是很清晰的，从这一个模块方面，覆盖也是很强的,其他嘛,看不出有什么特点来，不过第一次也能写成这样，那么逻辑思维能力是很好的，呵呵.拙见!
谢谢大家！
最后写成了1． 需求功能：用户登录安全验证
需求描述：用户登录安全验证是为了保证登录到系统中的所有用户都是在系统数据库中存在有用户名和密码的，在用户名，密码或校验码任何一个不正确的情况下都无法登陆到系统中，当用户使用了不存在的用户名，密码或者校验码输入错误时，系统给出适当的提示。如果用户输入正确的用户名，密码和校验码登录到系统，则退出登录界面，转到与登陆用户权限相应的界面。
测试需求：
检查能否使用正确的用户名，密码和校验码登录系统。
检查能否使用错误的用户名，密码和校验码登录系统。
测试条件：
假定用户Admin，密码123，校验码5678，有系统管理用户角色和业务管理用户角色。
假定用户Xianji，密码456，校验码1234，有业务管理用户角色。
假定用户Waibu，密码789，校验码3456。
测试用例：
序号 用户名 密码 校验码 测试目的
1 Admin 123 5678 正确的系统管理用户名和密码能否正确进入系统管理用户界面
2 Xianji 456 1234 正确的业务管理用户名和密码能否正确地进入业务管理用户界面
3 Waibu 789 3456 正确的外部用户名和密码能否正确地进入外部用户界面
4 Ad ‘12’ 5678 错误的用户名能否登陆系统，密码中加入字符程序是否会出错
5 Admin <236> 5678 与用户名不匹配的密码能否登陆系统，密码中加入字符是否会出错
6 Xianji (789) 1234 与用户名不匹配的密码能否登陆系统，密码中加入字符是否会出错
7 Waibu 3456 与用户名不匹配的密码能否登陆系统，密码中加入字符是否会出错
8 Admin 123 1234 正确的用户名和密码，错误的校验码能否登陆系统
9 Xianji 456 4567 正确的用户名和密码，错误的校验码能否登陆系统
10 Waibu 789 6789 正确的用户名和密码，错误的校验码能否登陆系统
11 {123} 1234 用户名为空能否登陆系统
12 Admin 5678 密码为空能否登陆系统
13 Xianji 456 校验码为空能否登陆系统
14 Admin ‘123 4569 密码前加入单个字符能否登陆系统
15 Xianji 123’ 1234 密码后加入单个字符能否登陆系统
16 ‘Admin 123 5678 用户名前加入单个字符能否登陆系统
17 Admin’ 123 5678 用户名后加入单个字符能否访问系统
18 Admin 123 ‘5678 校验码前加入单个字符能否登陆系统
19 Xianji 456 1234’ 校验码后加入单个字符能否登陆系统
20 #Admin 123 5678 用户名前加入单个字符能否登陆系统
21 Admin# 123 5678 用户名后加入单个字符能否登陆系统
22 Admin #123 5678 密码前加入单个字符能否登陆系统
23 Admin 123# 5678 密码后加入单个字符能否登录系统
不知道还有什么没想到的地方，请指教！ 其实我觉得没有那么麻烦：
1。正确的用户名和密码和校验码
2。不正确的用户名，密码，校验码
1） 符合编码规范（数字，字母，一些允许的字符）但输入错误数据库不存在的（一般情况）
2） 包含特殊字符的：～！◎＃￥％……※×（）《》。？、/\|等等
3） 输入为空，或者输入有左空格或有空格的
除了这些检查基本的登陆是否正确外，因为你的测试需求里提到了输入错误系统会给予适当的提示，以及“如果用户输入正确的用户名，密码和校验码登录到系统，则退出登录界面，转到与登陆用户权限相应的界面。 ”
所以还应当检测： 1。是否登陆到了正确的界面
2。 提示信息是否正确
3。 确定错误提示信息后，回到当前的登陆页面？状态怎样？ （eg:所有输入栏都是空白,或者默认了刚才的username....)
4。退出后是否正确回到了初始的登陆页面？还有状态？
个人意见，有什么问题恳请指正。 多谢楼上的指教,我在修改修改~ 高手好多！ 24楼的不错，赞！！！ 更高级一点，在用户名编辑框中输入：
1.单引号‘ 和<--，看能不能通过；
2.插入一个sql字符串，如"；selcect * from user"，注意加上前面那个分号！ 各类型的错误情况都罗列出来了。
我觉得，除了正确错误的数据，特别对错误数据要进一步分析。24楼的说的没错，特殊字符，空格等特别容易出错。
常见，密码输入中空格算一个密码。
查询中，数据前后存在空格，常查找不到匹配的数据。
有的算合法数据但数据库中不存在匹配数据
[ 本帖最后由 小月三木 于 2006-5-15 11:30 编辑 ] 测试用例要写预期结果和实际结果的
预期结果是你自己填写
测试结果由测试人员测试后填写
以你的预期为参照分析是不是BUG 还有用户名要测试255个字符以上的一个用例
因为一般输入要求是255以内
一个溢出可能会有不知道的结果 写得不错.觉得应该加一些特殊字符和考虑字符的长度 写的太多,没有必要,一个登陆搞成这样,以后的业务你不是要写几十页.测试用例编制的时候也要注意程序容易出错的地方，有些地方不可能出现就不要做。 楼上的，测试不是想象
不永远不会知道哪里会出现错误
又不是代码走查，实在太简单的可以不管
别误导小姑娘 真的很冗长,你在执行的时候会很累,而且按照你写的,等你做完这个测试就会立刻感到枯燥无味的.
同意4楼说的,用流程图的方式简化繁琐的步骤. 不错
挺好的呢
24楼的条理很清楚噢！ 个人觉得是不是该考虑一下边界值。 是啊，一个登录写了这么多，以后的业务呢？特别是权限配置那块，哈哈，我个人觉得还是有重点的吧，不过这只是一个思路，写的不错，就是有点多了。精简些。
我也是新手
我觉得你这个是个等价类表，也许具体到每一个用例应该有具体数据和具体操作，而且每一个测试用例应该只包含一个测试数据，这是我的想法 楼主说了是新手对新手练习来说，写的越细越多，越好
冗长怕什么，你现在写的越冗长，日后，你会写的越简洁
还没学会走，就要求别人跑，可能么
