测试一个登陆界面,如何设计测试用例 从简单的用户登录来谈如何设计测试用例

一、案例背景

1、“用户登录”介绍

可能你会说，“用户登录”这个测试对象也有点太简单了吧！

我可是多年资深测试工程师呀！

我只要在登录界面上输入用户名和密码，然后点击“登录"按钮，能不能登录一点便知，我都不屑于来测试。

但真的是这样吗？

的确，这种输入用户名和密码点击登录过程，构成了一个最基本、最典型的测试用例，这也是前端用户在使用软件系统时最典型的登录场景。

但是作为测试工程师，我们站在用户的角度来测试软件产品，但是比一般的用户更深入、更专业。

要保证软件产品能在各种应用场景下符合设计要求，那么需要考虑的测试用例就需要更全面、更丰富。

那你很可能会想到等价类划分和边界值分析这两个方法来设计。

2、测试用例设计方法

等价类划分：将所有可能的输入数据划分成多个子集合，在每个子集中，如果任意个输入数据对于掲露程序中潜在错误都具有同等作用，那么这样的子集就构成了一个等价类。

边界值分析：是选取输入、输出的边界值进行测试。

因为通常大量的软件错误是发生在输入或输出范围的边界上,所以需要对边界值进行重点测试,通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。

这两种分析方法往往会结合在一起时，才会有更好测试覆盖率。

二、测试用例设计

1、入门级用例设计

a.输入已注册的用户名和正确的密码，验证是否登录成功；

b.输入已注册的用户名和不正确的密码，验证是否登录失败，提示信息是否正确；

c.输入未注册的用户名和任意密码，验证是否登录失败，提示信息是否正确；

d.用户名和密码两者都为空，验证是否登录失败，提示信息是否正确；

e.用户名和密码两者之一为空，验证是否登录失败，提示信息是否正确；

f.如果登录功能启用了图片验证码功能，在用户名和密码正确的前提下，输入正确的图片验证码，验证是否登录成功；

d.用户名和密码两者都为空，验证是否登录失败，提示信息是否正确；

g.如果登录功能启用了图片验证码功能，在用户名和密码正确的前提下，输入错误的图片验证码，验证是否登录失败，并且提示信息正确。

在一个优秀的测试工程师眼中这些用例只能达到勉强及格的标准。

那还可以做哪些补充呢？

2、中级用例设计

a.用户名和密码是否大小写敏感；

b.页面上的密码框是否加密显示；

c.用户名和密码是否大小写敏感；

d.忘记用户名和忘记密码的功能是否可用；

e.前端页面是否根据设计要求限制用户名和密码长度；

f.点击验证码图片是否可以更换图片验证码，更换的图片验证码是否可用；

g.刷新页面是否会刷新图片验证码；

h.如果图片验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；

i.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；

j.不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否符合要求。

改进之后的用例，测试覆盖率提高了很多，但是在资深测试工程师眼里，差距还非常大。

3、高级用例设计

兼容性测试用例：

a.在相同浏览器的不同版本中，验证用户登录页面的显示以及功能是否正确；

b.在不同浏览器中，验证用户登录页面的显示以及功能是否正确；

c.在不同移动设备的不同浏览器中，验证用户登录页面的显示以及功能是否正确；

d.在不同分辨率的界面下，验证用户登录页面的显示以及功能是否正确；

性能压力测试用例：

a.单用户登录的响应时间是否小于3秒；

b.单用户登录时，后台请求数量是否过多；

c.高并发场景下用户登录的响应时间是否小于5秒；

d.高并发场景下服务端的监控指标是否符合预期；

e.高集合点并发场景下，是否存在资源死锁和不合理的资源等待；

f.长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

安全性测试用例：

a.用户密码在网络传输过程中是否加密；

b.后台数据库存储的密码是否加密；

c.密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；

d.密码输入框内输入的密码是否可以在页面源码模式下被查看；

e.密码输入框是否不支持复制和粘贴；

f.用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；

g.不登录的情況下，在浏览器中直接输入需要登录后才能访问的URL地址，验证是否会重新定向到用户登录界面；

h.用户名和密码的输入框中分別输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改，连续多次登录失败情況下，系统是否会阻止后续的尝试，以防止暴力破解；

i.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性；

j.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期。

三、总结

哪怕是最常用最小的一个登录功能，其实涉及到的测试用例也是非常多的。

不仅要考虑功能性需求，还要考虑众多的非功能性需求，而这些非功能性需求是产品稳定、安全的关键。

绝大多数情况下，由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。

如果想成为优秀的测试工程师，必须具有宽广的知识面，才能设计出非常完备的测试用例，提高测试覆盖率。

,