测试用例 用例目的：该用例用来测试在登录界面用户能否正常登录；
若出现错误的信息系统将给出正确的示信息；
前置条件：存在正确的用户名和密码；
登录页面正常装载；
用例设计：
1界面测试
用例类型 关注数据 通过标准
界面正常装载后，检视页面是否符合规范 1．页面title是否正确；
2．页面的默认焦点是否控制在用户名输入框中；
3．TAB键能否控制；
4．未登录状态下，页面的
其他按钮（非登陆/取消按钮）不可选或选择无效 1．页面title正确；
2．默认焦点控制在用户名输入框中；
3．TAB键正常控制；
4．取消按键不可用；
2登录测试
用例类型 关注数据 通过标准
输入正确的用户名和正确的密码
用户名：mm
密 码：mm
鼠标点击登录 正常登陆，转入对应的系统页面
用户名：mm
密 码：mm
直接回车键（Enter）进行登陆 正常登陆，转入对应的系统页面
输入正确的用户名和正确的密码，但未区分大小写
用户名：Mm
密码：Mm
区分大小写，显示出错信息，不能正常登陆
输入正确的用户名和错误的密码
用户名：mm
密 码：dw54f
出现密码错误的提示并清空输入框
用户名：mm
密 码：¥§£（即在密码中输入特殊符号）
提示密码中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入
输入错误的用户名和正确的密码
用户名：jiew11
密 码：mm
出现用户名不存在或错误的提示并清空输入框
用户名：jie¥§（在用户名中输入特殊符号）
密 码：mm 提示用户名中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入
输入错误的用户名和错误的密码
用户名：jiew11
密 码：dw54f
出现用户名不存在或密码错误的提示并清空输入框
不输入用户名和密码/或均为空格，直接点击登录 用户名：
密 码： 出现“请输入用户名、密码”的提示框
只输入用户名，密码为空/或为空格 用户名：mm
密 码： 出现“请输入密码”提示框
用户名为空/或为空格，只输入密码 用户名：
密 码：mm 出现“请输入用户名”提示框
3异常测试
用例类型 关注数据 通过标准
输入用户名或密码；点击取消； 用户名：jiew11
密 码：dw54f
清空输入框
4备注说明
1． 在登录WEB页面也可以进行变态性的测试，比如不停的点击登录按扭，或多个人同时登录（可用loadrunner进行压力模拟）
2． 现在的一般登录页面都会有验证码，同样的可以和上面类似的设计测试用例，但是由于在安全性上影响不大，故不在详说。（验证码测试用例举例：大小写，空值，错误输入等等）
3． 登录的安全性测试：
a) 是否可以不登陆而直接浏览某个页面等。
b) Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
c) 为了保证Web应用系统的安全性，
日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪，以防止被黑客截取。
d) 当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
e) 服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
f) 有的在线登录系统会有“找回密码”，这样我们在测试是就一定要注意找回密码的条件（找回密码条件安全级应等同于或高于密码安全级）和此时的网络安全性。
4． 登录在易用性上要求也是较高的，以次我们也可以参照用户的观点以及安全性上考虑给出一个标准：
a) 界面的美观程度
b) 按扭的设置和排列
c) 输入提示的人性化考虑
d) 错误提示的准确性
e) 验证码的清晰度和复杂程度
进一步的信息 关于
自动化测试工具在登录
性能测试上的缺陷及解决办法
现在越来越多的网站为了安全性或是防止Spam的侵害，采用了验证码的校验技术。简单地说，验证码就是在进行登录或是内容提交的时候，页面上会随机出现一 个人工可识别，但机器不可识别的验证字符串（一般是采用背景、扭曲等方式产生的图片），要求登录或是提交内容时同时输入这个验证码。
验证码可以有效防止对口令的刺探和所谓的网络推广软件带来的大量的Spam内容，目前已经被许多Internet或是Intranet应用接受为标准的实现方式。但对性能测试来说，这种验证码又带来了很大的问题。
最突出的问题是，性能测试工具本身是自动化工具，由于这种验证码采用的是“防止自动化工具尝试”的方法，因此，在录制了脚本之后会发现，很难对脚本进行调整，以使其适应验证码验证的需要。对这个问题，我个人的看法是，基本上可以考虑从三个途径来解决该问题：
1、第一种方法，也是最容易想到的，在被测系统中暂时屏蔽验证功能，也就是说，临时修改应用，无论用户输入的是什么验证码，都认为是正确的。这种方法最容 易实现，对测试结果也不会有太大的影响（当然，这种方式去掉了“验证验证码”这个环节，不过这个环节本来就很难成为系统性能瓶颈）。但这种方法有一个致命 的问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险，因此，对于已上线的系统来说，用这种方式就不 合适了；
2、第二种方法，在第一种方法的基础上稍微进行一些改进。第一种方法带来了很大的安全性问题，那么我们可以考虑，不取消验证，但在其中留一个后门，我们设 定一个所谓的“万能验证码”，只要用户输入这个“万能验证码”，我们就验证通过，否则，还是按照原先的验证方式进行验证。这种方式仍然存在安全性的问题， 但由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内，而且只在性能测试期间保留这个小小的后门，相对第一种方法来说，在安全性方面已经有较 大的改进了；
3、如果安全性对应用来说真的是至关重要的，不容许有一丝一毫的闪失，那我们还可以用更进一步的方法来处理这个问题。一般的性能测试工具 （loadrunner等）都能够调用外部的组件接口，因此，可以考虑获得“验证码验证”部分的实现，写一个验证码获取的代码，在测试脚本中进行调用即 可。
在我看来，第二种方法用得比较多，对未上线系统系统的内部性能测试，有时候也用第一种方法。但要提醒的是，如果针对的是已上线系统，无论用哪种方法，测试 完成后，都必须立刻将应用恢复，并对系统进行一次安全审计，以免在测试期间被他人入侵。第三种方法用得比较少，而且具体上还依赖于验证组件是否能提供这样 的接口，以及获取验证码开发的难度。
