本人在“极客时间”上购买了一套“软件测试52讲”的课程，本文为该课程第一节《01 | 你真的懂测试吗？从“用户登录”测试谈起》的课程笔记及自己的一些思考。
针对“用户登录”功能，可以从如下方向进行设计
1.显性功能性需求方向
（1）等价类划分、边界值分析等方法设计
输入已注册的用户名和正确的密码，验证是否登录成功；
输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
（2）补充设计
用户名和密码是否大小写敏感；
页面上的密码框是否加密显示；
后台系统创建的用户第一次登录成功时，是否提示修改密码；
忘记用户名和忘记密码的功能是否可用；
前端页面是否根据设计要求限制用户名和密码长度；
如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
刷新页面是否会刷新验证码；
如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
页面默认焦点是否定位在用户名的输入框中；
快捷键 Tab 和 Enter 等，是否可以正常使用。
2.非功能性需求方向
从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。
（1）安全性用例
用户密码后台存储是否加密；
用户密码在网络传输过程中是否加密；
密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
密码输入框是否不支持复制和粘贴；
密码输入框内输入的密码是否都可以在页面源码模式下被查看；
用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
（2）性能压力测试用例包括:
单用户登录的响应时间是否小于 3 秒；
单用户登录时，后台请求数量是否过多；
高并发场景下用户登录的响应时间是否小于 5 秒；
高并发场景下服务端的监控指标是否符合预期；
高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
（3）兼容性测试用例包括：
不同浏览器下，验证登录页面的显示以及功能正确性；
相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
不同分辨率的界面下，验证登录页面的显示以及功能正确性。
【重要观点】
（1）我们在进行用例设计的时候，除了考虑显性功能性需求，也需要考虑到性能、安全性、兼容性等非功能性需求，因为这些非功能性需求对于产品质量而言也同样重要！
（2）我们应该尽可能的去扩展自己的知识面，这样才能设计出更有效，更全面的测试用例
（3）由于测试的不可穷尽性，我们要在缺陷风险和研发成本之间找到一个平衡点。
【反思】
工作久了，整个团队中对于用例设计的能力是趋于稳定的，很难发现太多的惊喜，没有人会刻意去锻炼用例设计的能力，从而间接体现为产品质量会存在一些惯性思维导致的风险。面对这种情况，我们应该如何让自己的能力得到有效的提高？? 如何激活团队成员的发散思维、创新能力？？欢迎大家一起来讨论！
网友评论