登录界面是大部分软件的入口，只有通过这里的用户才能正常地使用软件。我们公司的大部分系统也都有各具特色的登录界面。
一个登录界面是从功能和界面上看都是比较简单的，大家都接触过数不尽的登录界面。最基本的登录界面都会包括账号输入框、密码输入框、验证码输入框、登录按钮、重置按钮，复杂一点的还会包括记住账号、注册账号、忘记密码、安全登录等操作按钮或操作链接，个别的还会有相应的温馨提示的文字内容，不一而足。
用例描述
常规
测试用例：
1． 验证登录界面标题、输入框标题等静态文字信息是否正确。
2． 验证按钮名称是否合理。
3． 验证用户名和密码都正确时，用户通过登录验证。
4． 验证用户名错误而密码正确时，用户不能通过登录验证，并给出相应提示信息。
5． 验证用户名正确而密码错误时，用户不能通过登录验证，并给出相应提示信息。
6． 验证用户名和密码都错误时，用户不能通过登录验证，并给出相应提示信息。
7． 验证登录成功，能够出现正确的主页面。
8． 验证登录失败，主页面不能显示出来。
临界值测试用例：
9． 验证用户名和密码都为空时，用户不能通过登录验证，并给出相应提示信息。
10．验证用户名为空时，用户不能通过登录验证，并给出相应提示信息。
11．验证密码为空时，用户不能通过登录验证，并给出相应提示信息。
12．验证用户名字符长度为19、20、21时的情况（假设用户名长度为20）。
13． 验证密码字符长度为9、10、11时的情况（假设密码长度为10）。
易用性测试用例：
14． 验证是否支持常规的快捷键。（输入完用户名和密码后直接按Enter键进行登录、Ctrl+X、Ctrl+C、Ctrl+V（有些网页的密码输入框不支持粘贴的）、Ctrl+A等等）
15．验证登录失败时，对已填用户名和账号的处理情况。（用户名和密码都清空？还是选中两者以方便用户再次输入？还是不做处理？比较好的做法是清空密码、保留用户名，用户一点击用户名会全选中用户名。）
16．验证登录成功后，再次登录时，是否有记住上次登录的用户名，以方便用户省去再次输入用户名。
17．验证首次打开登录界面，鼠标的输入焦点是否在用户名的输入框以方便用户直接输入。
18．验证再次打开登录界面时如果记住了用户名，鼠标的输入焦点是否在密码的输入框以方便用户直接输入。
安全性测试用例：
19． 验证登录系统是不是有做好防范
SQL注入，使用特殊字符或SQL关键字作为用户名和密码进行登录。
20．验证用户登录成功之后，是否真的保存了用户名和密码。
21．验证保存在哪里，是否做了保护。如果是明文保存的话，将是一个安全大漏洞。
示例实战
我们公司很多系统由于特殊需要都有提供使用数字证书（key）进行登录的，由于条件限制无法对这种登录方式进行测试，这里不作讨论。
在这里想以自己公司的XX系统的登录界面作为一个例子，根据上面的测试用例进行测试，要说明的是，并不是自己专门要找XX的茬，只是觉得以我们公司的系统作为例子更具贴切性，再者，自己对XX系统也比较熟悉，而且XX系统具有外网测试地址。
XX的登录界面简洁、明朗，对于“一般登录方式”就只有“用户名”文本输入框、“密码”文本输入框、“登录”、“重置”按钮。
使用上面的各个测试用例，一一进行测试，得出的如下结果：
1． 常规测试用例和临界值测试用例，都得到了预期输出结果。
2． 在易用性测试用例中，用例14得到了预期输出结果。
3． 在易用性测试用例中，用例15得到的输出结果是，当登录失败时，清空了密码，保留了用户名，以方便用户再次输入密码。
4． 在易用性测试用例中，用例16没有得到预期输出结果，也就是下次重新打开登录界面时没有记住用户名。
5． 在易用性测试用例中，用例17、18没有得到预期输出结果，也就是没有对鼠标的输入焦点进行设置。
6． 在安全性测试用例中，用例19没有得到预期输出结果，没有做好防范SQL注入，例如：如果在用户名和密码的输入框中直接输入“' or 1=1--”，就可以绕过后台的登录验证，直接成功登录系统；再如：只在用户名输入框中输入“' or”，然后登录，得到的页面就是“执行SQL语句错误”的提示页面，下面就有一大堆的
数据库的信息。
结果分析
根据上面的测试结果可以发现，XX系统的登录界面在界面美观和基本功能上都实现得比较好，正常情况下都不会有问题。
在系统的易用性上还做得还不是很够，考虑得不够详尽，因为这方面确实容易忽略，所以很多人都不会太在意这方面，更别说开发时间是那么紧张。但现在社会对软件产品质量的要求是越来越高了，很多时候这些细小的方面就会软件产品竞争力的体现了，因为这也是软件产品为用户着想，从用户角度出发的体现，是人性化的体现。其实这方面的实现并不是很难的技术问题，只是想法问题，所以我觉得我们有必要在易用性上多动点脑筋，当然，这是我们每个人的责任！
对于安全性，SQL注入，并不是新鲜的问题，但在这里确实还存在着，而且这是个严重的问题。需要承认，我对这方面的了解非常浅薄，之前也没有特意设计用例测试过，只是在这次总结过程中，就专门去看了些书和查找了一些资料，结果发现确实可以用网上流传已久的例子“' or 1=1--”（还有很多，不止这一个）作为用户名和密码成功登录系统，这个问题的严重性大家都知道，需要承认我的失职，我之前并没有查出这个bug！对于这个问题的解决方法，网上同样有很多例子。要防范SQL注入，也不是难事，在于我们的思想。
