你真的会测试用户登录吗？

话题

什么选择"用户登陆"这么简单的测试对象？

是的，你没看错，今天的测试对象就是功能非常简单的用户登录功能。之所以选择"用户登陆"是因为该测试对象功能单一、用户普遍常见、非常适合考察一个测试工程师的测试功底。有时候看似简单的事物并非那么简单，只有看到别人看不到的地方才是过人之处，如何做到测试点更全面覆盖，这就需要提升自己工作经验和技术层的知识面。好了，废话不多说，下面转入正题。下面就是大家最常见的用户功能界面，页面元素包括：用户名、密码、验证码、登陆按钮。

普通测试

测试用例

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

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

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

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

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

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

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

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

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

10. 后台系统创建的用户第一次登录成功时，是否提示修改密码；

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

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

13. 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；

14. 刷新页面是否会刷新验证码；

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

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

17. 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；

18. 页面默认焦点是否定位在用户名的输入框中；

19. 快捷键Tab和Enter等，是否可以正常使用。

关注点

• 测试角度

显式功能性需求，指的是软件本身需要实现的具体功能， 比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。

优秀测试

不仅会关注显式功能需求，而且会关注隐式非功能需求，那什么是隐式非功能需求呢？从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。包括安全、性能、兼容、异常等方面的测试内容。

测试用例

DB表设计测试用例包括：

1. redis中用户token失效时间是否符合需求

2. Mysql表结构字段类型是否正确

3. 表结构字段长度是否足够

4. 表是否分表分库，规则是否正确合理

安全性测试用例包括：

1. 用户密码后台存储是否加密；

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

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

4. 不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；

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

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

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

8. xss风险测试，页面输入框输入<script>alert('hello，gaga!');</script>，验证是否有alert弹框。

9. 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；

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

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

性能压力测试用例包括:

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

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

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

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

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

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

兼容性测试用例包括：

1. 不同浏览器下，验证登录页面的显示以及功能正确性；

2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；

3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；

4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。

异常测试用例包括：

1. 服务器宕机容灾措施是否考虑（负载均衡，其中一台服务器）

2. 回滚方案是否考虑

关注点

• 测试角度

考虑产品功能的显式需求、测试用例有效性、测试点是否覆盖全面等

• 用户角度

重点考虑业务的显式功能需求，也会联想到非功能性测试点，会站在用户角度思考产品设计的合理性。比如这样设计好不好用、能否满足xx人同时登陆、用户能否接受多长的响应时间等

• 开发角度

站在开发角度考虑产品在技术层面实现的整体架构，比如DB表结构设计、负载均衡、分表分库规则设计等

关于测试的不可穷尽性

        看完了这些测试用例，你可能会说还有一些遗漏的测试点没有覆盖到，这个功能的测试点还不够全面。穷尽测试是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。

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

如何保证测试全面性、产品质量

首先，测试的全面性要基于测试工程师的广度的知识面，测试工程师不能仅仅满足于测试知识的学习，更多要拓宽自己的面，多学习开发、架构、项目管理的知识，将自己打造成多方面发展的互联网多面手、全能王。

其次，产品质量的保证不能完全寄托于测试人员，测试也不只是产品质量保障的最后一环，要更多地从整个项目流程出发，要联合产品同学、开发同学、甚至运维同学共同制定产品质量保障规范。

（1）产品同学作为业务发起方，可以说一艘轮船的舵手，指明前进方向。所以前期务必做好市场调研、挖掘用户真实需求、产品定义明晰，避免后期频繁变更需求。

（2）开发同学作为产品的实现方，俗话说bug发现的时间与修复bug消耗的质量成本(PONC)成正比，因此开发同学做好单元测试、同事间进行Code Review可以在一定程度上减少很多不必要的成本消耗。

（3）测试同学作为质量保障一环，是质量保障投入最多的一方，所以如何更快更有效保障产品质量显得尤为重要。下面我也会重点介绍这块。

（4）运维同学作为项目交付后产品质量的跟进者，要做好线上监控，第一时间发现产品暴露的问题并及时跟进解决，避免缺陷（产品规则导致的薅羊毛漏洞）带来的公司损失进一步扩大甚至要做到将缺陷（产品规则的薅羊毛漏洞）扼杀在摇篮之中。

测试前

（1）评审前提前熟悉需求，站在用户角度考虑需求的合理性，评审多做会议记录以及实时追踪问题解决情况

（2）构建需求对应的业务模型、领域模型、画业务/技术流程图

（3）白盒测试，提前review核心代码

（4）用例设计基于显式、隐式需求测试点、自动化用例

（5）用例评审

（6）制定提测门禁

（7）提前准备测试数据的脚本

测试中

（1）度量测试用例覆盖业务覆盖率

（2）度量测试用例覆盖代码覆盖率

测试后

（1）核心功能场景做好监控，比如业务临界点、涉及资损场景等

（2）对测试过程遇到的问题进行复盘并制定解决方案，避免下次踩同样的坑

总结

    首先，对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。

    其次，优秀的测试工程师必须具有宽广的知识面，才能设计出有针对性、更易于发现问题的测试用例。最后，软件测试的用例设计是不可穷尽的，工程实践中难免受制于时间成本和经济成本，所以优秀的测试工程师需要兼顾缺陷风险和研发成本之间的平衡。