《登录测试用例.docx》由会员分享，可在线阅读，更多相关《登录测试用例.docx（6页珍藏版）》请在三一办公上搜索。
1、登录测试用例登录测试用例 用例设计： 一。界面测试测试用例 用例目的：该用例用来测试在登录界面用户能否正常登录； 若出现错误的信息系统将给出正确的示信息； 前置条件：存在正确的用户名和密码； 登录页面正常装载； 用例设计： 一。界面测试 界面正常装载后，检视页面是否符合规范 1.页面title是否正确； 2.页面的默认焦点是否控制在用户名输入框中； 3.TAB键能否控制； 4.未登录状态下，页面的其他按钮不可选或选择无效 5. 取消按键不可用； 二。登录测试 输入正确的用户名和正确的密码 用户名：mm 密 码：mm 鼠标点击登录 正常登陆，转入对应的系统页面 用户名：mm 密 码：mm 直接回
2、车键进行登陆 正常登陆，转入对应的系统页面 输入正确的用户名和正确的密码，但未区分大小写 用户名：Mm 密码：Mm 区分大小写，显示出错信息，不能正常登陆 输入正确的用户名和错误的密码 用户名：mm 密 码：dw54f 出现密码错误的提示并清空输入框 用户名：mm 密 码：$ 提示密码中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入 输入错误的用户名和正确的密码 用户名：jiew11 密 码：mm 出现用户名不存在或错误的提示并清空输入框 用户名：jie$ 密 码：mm 提示用户名中存在特殊符号或者在输入特殊符号时系统自动消除/不能输入 输入错误的用户名和错误的密码 用户名：jiew1
3、1 密 码：dw54f 出现用户名不存在或密码错误的提示并清空输入框 不输入用户名和密码/或均为空格，直接点击登录 用户名： 密 码： 出现请输入用户名、密码的提示框 只输入用户名，密码为空/或为空格 用户名：mm 密 码： 出现请输入密码提示框 用户名为空/或为空格，只输入密码 用户名： 密 码：mm 出现请输入用户名提示框 三。异常测试 输入用户名或密码；点击取消； 用户名：jiew11 密 码：dw54f 清空输入框 四。备注说明 1.在登录WEB页面也可以进行变态性的测试，比如不停的点击登录按扭，或多个人同时登录 2.现在的一般登录页面都会有验证码，同样的可以和上面类似的设计测试用例，
4、但是由于在安全性上影响不大，故不在详说。 3.登录的安全性测试： a） 是否可以不登陆而直接浏览某个页面等。 b） Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内没有点击任何页面，是否需要重新登陆才能正常使用。 c） 为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪，以防止被黑客截取。 d） 当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 e） 服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 f） 有的在线登录系统会有找回密码,这样
5、我们在测试是就一定要注意找回密码的条件和此时的网络安全性。 4. 登录在易用性上要求也是较高的，以次我们也可以参照用户的观点以及安全性上考虑给出一个标准： a） 界面的美观程度 b） 按扭的设置和排列 c） 输入提示的人性化考虑 d） 错误提示的准确性 e） 验证码的清晰度和复杂程度 进一步的信息 关于自动化测试工具在登录性能测试上的缺陷及解决办法 现在越来越多的网站为了安全性或是防止Spam的侵害，采用了验证码的校验技术。简单地说，验证码就是在进行登录或是内容提交的时候，页面上会随机出现一个人工可识别，但机器不可识别的验证字符串，要求登录或是提交内容时同时输入这个验证码。 验证码可以有效防止
6、对口令的刺探和所谓的网络推广软件带来的大量的Spam内容，目前已经被许多Internet或是Intranet应用接受为标准的实现方式。但对性能测试来说，这种验证码又带来了很大的问题。 最突出的问题是，性能测试工具本身是自动化工具，由于这种验证码采用的是防止自动化工具尝试的方法，因此，在录制了脚本之后会发现，很难对脚本进行调整，以使其适应验证码验证的需要。对这个问题，我个人的看法是，基本上可以考虑从三个途径来解决该问题： 1、第一种方法，也是最容易想到的，在被测系统中暂时屏蔽验证功能，也就是说，临时修改应用，无论用户输入的是什么验证码，都认为是正确的。这种方法最容易实现，对测试结果也不会有太大的
7、影响。但这种方法有一个致命的问题：如果被测系统是一个实际已上线的系统，屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险，因此，对于已上线的系统来说，用这种方式就不合适了； 2、第二种方法，在第一种方法的基础上稍微进行一些改进。第一种方法带来了很大的安全性问题，那么我们可以考虑，不取消验证，但在其中留一个后门，我们设定一个所谓的万能验证码,只要用户输入这个万能验证码,我们就验证通过，否则，还是按照原先的验证方式进行验证。这种方式仍然存在安全性的问题，但由于我们可以通过管理手段将万能验证码控制在一个小的范围内，而且只在性能测试期间保留这个小小的后门，相对第一种方法来说，在安全性方面已经有较
8、大的改进了； 3、如果安全性对应用来说真的是至关重要的，不容许有一丝一毫的闪失，那我们还可以用更进一步的方法来处理这个问题。一般的性能测试工具都能够调用外部的组件接口，因此，可以考虑获得验证码验证部分的实现，写一个验证码获取的代码，在测试脚本中进行调用即可。 在我看来，第二种方法用得比较多，对未上线系统系统的内部性能测试，有时候也用第一种方法。但要提醒的是，如果针对的是已上线系统，无论用哪种方法，测试完成后，都必须立刻将应用恢复，并对系统进行一次安全审计，以免在测试期间被他人入侵。第三种方法用得比较少，而且具体上还依赖于验证组件是否能提供这样的接口，以及获取验证码开发的难度。 补充汇总： 功能
9、测试： 1.正确的用户名和密码登陆 2.错误的用户名错误的密码、正确的用户名错误的密码、错误的用户明错误的密码，弹出相应的提示信息 3.提示信息是否正确，比如我密码错了提示无此用户那就瞎了 4.页面跳转的测试，人家输错了直接关闭就不好了或者人家输对了自动跳转到相应页面 5.多用户同账号登陆的情况嘿嘿没多少人想到吧至于是否允许，那要看需求了 6.账号和密码位数的检查，强制输入超过规定长度的字符，比如利用复制粘贴等 7.就像51testing论坛我以为登陆账号和昵称是两码事呢结果在这里昵称只能用账号 8.出现各种情况再次进行登陆，比如用户关闭网页，有的系统点x关闭浏览器和点击系统提供的登出是不一样
10、地再用户进行ie清理，看看会出现啥状况？3楼的竟然想到断电用得着么？ 9.cookie或者其他技术保留登陆信息的时间检查，别人家选择保留1个月，结果1周就没了 界面测试： 1.账号和密码的字符检查，是否允许双字节？这就涉及到本地化测试了 2.各控件的布局是否整齐，控件的大小是否合适，文字字体大小格式颜色是否美观等等 3.提示信息是否友好美观，总不能带脏字吧 性能测试： 1.无非就是响应时间，页面显示时间，资源的占用要像迅雷那样页面显示半天，资源又占那么多不说了郁闷 安全性： 1.cookie的安全性检查 2.错误次数的控制 3.密码的安全性，是否用*号隐蔽或者别的类似的隐蔽方式，并且考虑密码被盗去的可能性，比如在注册的时候我们就对其密码进行强中弱鉴定并提示用户
