一.界面测试测试用例
用例目的：该用例用来测试在登录界面用户能否正常登录；
若出现错误的信息系统将给出正确的示信息；
前置条件：存在正确的用户名和密码；登录页面正常装载；用例设计：一.界面测试界面正常装载后，检视页面是否符合规范1．页面title是否正确；
2．页面的默认焦点是否控制在用户名输入框中；3．TAB键能否控制；4．未登录状态下，页面的其他按钮（非登陆/取消按钮）不可选或选择无效5. 取消按键不可用；
二.登录测试输入正确的用户名和正确的密码
用户名：mm密 码：mm鼠标点击登录 正常登陆，转入对应的系统页面用户名：mm密 码：mm直接回车键（Enter）进行登陆 正常登陆，转入对应的系统页面输入正确的用户名和正确的密码，但未区分大小写用户名：Mm密码：Mm区分大小写，显示出错信息，不能正常登陆 输入正确的用户名和错误的密码用户名：mm密 码：dw54f出现密码错误的提示并清空输入框
用户名：mm密 码：￥§￡（即在密码中输入特殊符号）提示密码中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入 输入错误的用户名和正确的密码用户名：jiew11密 码：mm出现用户名不存在或错误的提示并清空输入框用户名：jie￥§（在用户名中输入特殊符号）密 码：mm提示用户名中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入
输入错误的用户名和错误的密码用户名：jiew11密 码：dw54f出现用户名不存在或密码错误的提示并清空输入框不输入用户名和密码/或均为空格，直接点击登录用户名：
密 码：出现“请输入用户名、密码”的提示框
只输入用户名，密码为空/或为空格用户名：mm
密 码：出现“请输入密码”提示框
用户名为空/或为空格，只输入密码用户名：
密 码：mm 出现“请输入用户名”提示框三.异常测试
输入用户名或密码；点击取消；用户名：jiew11
密 码：dw54f清空输入框
四.备注说明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等）都能够调用外部的组件接口，因此，可以考虑获得“验证码验证”部分的实现，写一个验证码获取的代码，在测试脚本中进行调用即可。在我看来，第二种方法用得比较多，对未上线系统系统的内部性能测试，有时候也用第一种方法。但要提醒的是，如果针对的是已上线系统，无论用哪种方法，测试完成后，都必须立刻将应用恢复，并对系统进行一次安全审计，以免在测试期间被他人入侵。第三种方法用得比较少，而且具体上还依赖于验证组件是否能提供这样的接口，以及获取验证码开发的难度。
补充汇总: 功能测试：(这个肯定要先说的咯) 1.正确的用户名和密码登陆 2.错误的用户名错误的密码、正确的用户名错误的密码、错误的用户明错误的密码，弹出相应的提示信息 3.提示信息是否正确，比如我密码错了提示无此用户...那就瞎了~ 4.页面跳转的测试，人家输错了直接关闭就不好了~或者人家输对了自动跳转到相应页面(是相应页面不是单纯的跳到主页呦~) 5.多用户同账号登陆的情况...嘿嘿~没多少人想到吧...至于是否允许，那要看需求了~ 6.账号和密码位数的检查，强制输入超过规定长度的字符，比如利用复制粘贴等 7.就像51testing论坛~我以为登陆账号和昵称是两码事呢~结果在这里昵称只能用账号... 8.出现各种情况再次进行登陆，比如用户关闭网页，有的系统点x关闭浏览器和点击系统提供的登出是不一样地~再用户进行ie清理，看看会出现啥状况？3楼的竟然想到断电...用得着么？ 9.cookie或者其他技术保留登陆信息的时间检查，别人家选择保留1个月，结果1周就没了... 界面测试： 1.账号和密码的字符检查，是否允许双字节？这就涉及到本地化测试了~ 2.各控件的布局是否整齐，控件的大小是否合适，文字字体大小格式颜色是否美观等等... 3.提示信息是否友好美观，总不能带脏字吧... 性能测试： 1.无非就是响应时间，页面显示时间，资源的占用...要像迅雷那样页面显示半天，资源又占那么多~不说了~郁闷~ 安全性： 1.cookie的安全性检查 2.错误次数的控制(像工行的网银3次密码不对当天就进不去了...哼) 3.密码的安全性，是否用*号隐蔽或者别的类似的隐蔽方式，并且考虑密码被盗去的可能性，比如在注册的时候我们就对其密码进行强中弱鉴定~并提示用户...