🌊 黑盒测试方法

💦 原句

那什么是等价类划分和边界值分析方法呢？首先，这儿则都隶属于最常用、最典型、也是最重要的黑盒测试方法。 等价类划分方法，是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意 一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测 试输入取得较好的测试覆盖结果。

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

从方法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试方法经常结合起来使用。

💦 思考

1. 对于等价类的划分是很需要的想象里，要求尽可能想出都有哪些等价类。
2. 边界类划分方法，一般是用来解决边界限制的问题。

🌊 针对“用户登录”功能，进行编写测试用例

💦 原句

现在，针对“用户登录”功能，基于等价类划分和边界值分析方法，我们设计的测试用例包括：

1. 输入已注册的用户名和正确的密码，验证是否登录成功；
2. 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
3. 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
4. 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
5. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
6. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码， 验证是否登录成功；
7. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码， 验证是否登录失败，并且提示信息正确。
8. 用户名和密码是否大小写敏感；
9. 页面上的密码框是否加密显示；
10. 后台系统创建的用户第一次登录成功时，是否提示修改密码；
11. 忘记用户名和忘记密码的功能是否可用；
12. 前端页面是否根据设计要求限制用户名和密码长度；
13. 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否 可用；
14. 刷新页面是否会刷新验证码；
15. 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
16. 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
17. 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
18. 页面默认焦点是否定位在用户名的输入框中；
19. 快捷键 Tab 和 Enter 等，是否可以正常使用。

........

一个质量过硬的软件系统，除了显示功能性需求意外，其他的非功能性需求即隐式功能性需求也是极其关键的。 显示功能性需求（Functional requirement）的含义从字面上就可以很好地理解，值得的是软件本身需要实现的具体功能，比如，“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显示功能性需求描述。 那什么是非功能性需求（Non-functional requirement）呢？从软件测试的维度的来看，非功能需求主要设计安全性、性能以及兼容性三大方面。在上面的测试用例中，我们完全没有考虑非功能性需求的测试，但这些往往是决定软件质量的关键因素。

......

安全性测试用例包括：

1. 用户密码后台存储是否加密；
2. 用户密码在网络传输过程中是否加密；
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4. 不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户 登录界面；
5. 密码输入框是否不支持复制和粘贴；
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看；
7. 用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页 面；
8. 用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为 是否被篡改；
9. 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

性能压力测试用例包括:

1. 单用户登录的响应时间是否小于 3 秒；
2. 单用户登录时，后台请求数量是否过多；
3. 高并发场景下用户登录的响应时间是否小于 5 秒；
4. 高并发场景下服务端的监控指标是否符合预期；
5. 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

兼容性测试用例包括：

1. 不同浏览器下，验证登录页面的显示以及功能正确性；
2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。

💦 文末讨论补充

1. 来自用户“夸夸狗”
   1. 网络延迟或者弱网或者切换网络或者断网时正常登录是否正常
   2. 是否支持第三方登录
   3. 是否可记住密码，记住的密码保存是否加密
   4. 记住密码是否有有效期，有效期过期之后是否会清空密码
2. 来自用户“文大头”
3. 常规用例中，用户名密码是否支持特殊字符和中文等
4. 是否可以使用登录的API发送登录请求，并绕开验证码校验
5. 是否可以用抓包工具抓到的请求包直接登录 4
6. 截取到的token等信息，是否可以在其他终端上直接使用，绕开登录。token过期时间…
7. 来自用户“ 小叶榕 ”
   1. GDPR相关的测试偏少，比如用户登录后存储在数据库中的用户个人信息是否加密；用 户登录过程中log中是否有个人信息明文打印；
   2. 登录用户限制：比如同时支持10个用户登录，同时9个或者11个用户登录是否正常或者 提示信息正确
8. 来自用户“ Mr.Z ”
   1. 密码强弱性校验，数据库设计和数据操时候合理等。
9. 来自用户“ 阿莲 ”
   1. 未激活的用户登录
   2. 被停用的用户登录
   3. 登录的操作日志记录是否准确
   4. 登录有实效性是否控制正确
10. 来自用户"双子"
    1. 为空和输入空字符串时的校验是否一致；
    2. 使用中文键盘输入字母时和使用英文键盘输入字母时传给后端的字符长度是否一致；
    3. 登录成功后的session时效设置；
    4. 安全性方面异地登录校验、更换设备登录校验、登录信息异常是否考虑账号冻结停用
    5. 输入账号密码时对键盘格式是否有要求比如数字键盘；
    6. 密码一栏是否需要设置明暗码切换按钮；
    7. 输入账号密码格式不规范时是否将按钮设置为不可点击；
    8. 输入栏是否设置快速删除按钮
11. 来自用户”luosj“
    1. 涉及资产风险的，对登录设备和地区检测
12. 来自用户” 白天黑夜 “
    1. 是否用到缓存
13. 来自用户” bubblehead “
    1. 用户名和密码是否对空格敏感
    2. 密码是否有明文和暗文显示两种模式(有时候只有暗文显示真的不知道自己的密码是否输 入正确)
    3. 更改密码后是否还能用之前的密码登录
    4. 一个用户是否具备多种登录方式(用户名，手机号，邮箱...）

💦 思考

1. 识别显示功能性需求是基本，识别隐式功能性需求才是考验一个测试人员是否优秀的门槛。 而用户体验往往与非显示功能性需求强相关。为什么苹果的产品那么受欢迎，是它的功能真的强大吗， 个人感觉，是因为苹果很重视用户体验，重视那些隐式功能性需求，例如光一个苹果手机屏幕的调色 就很舒服，而中国手机的屏幕调色就很差强人意，这就是不重视细节。

🌊 在编写测试用例时，千万不想着“穷尽”

💦 原句

另外，通过这些测试用例的设计，你也可以发现，一个优秀的测试工程师必须具有很宽广的 知识面，如果你不能对被测系统的设计有深入的理解、不明白安全攻击的基本原理、没有掌 握性能测试的基本设计方法，很难设计出“有的放矢”的测试用例。

看完了这些测试用例，你可能会说还有一些遗漏的测试点没有覆盖到，这个功能的测试点还 不够全面。那么，接下来我再跟你说说测试的不可穷尽性，即绝大多数情况下，是不可能进 行穷尽测试的。

所谓的“穷尽测试”是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽 测试的系统里应该不残留任何未知的软件缺陷。 因为如果有未知的软件缺陷，你可以通过 做更多的测试来找到它们，也就是说你的测试还没有穷尽。

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

💦 思考

1. 测试一定要根据业务有所侧重，不要完美主义，有完美主义的心是好的，可以在侧重的地方测完之后，如果还有时间再去测其他方面，千万不要因大失小。业务驱动技术。

🌊 文末总结

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

其次，优秀的测试工程师必须具有宽广的知识面，才能设计出有针对性、更易于发现问题的 测试用例。

最后，软件测试的用例设计是不可穷尽的，工程实践中难免受制于时间成本和经济成本，所 以优秀的测试工程师需要兼顾缺陷风险和研发成本之间的平衡。