相信不少人参加面试的时候，会遇到设计测试的题目。比如面试官问：给你一个“用户登录”功能，你会如何测试它？
what？瞧不起谁呢？用户登录这也忒老生常谈了，看我用【等价类】和【边界值】快速搞定它。
于是，拿起笔就开始写测试用例：
1. 输入已注册的用户名和正确的密码，验证是否登录成功 2. 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确 3. 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确 4. 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确 5. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确 6. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功 7. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确
搞定收笔，自信地递给面试官看，只见面试官面带微笑，继续问到：还有要补充的吗？
在我看来，上来就直接写测试用例，可能不是最好的表达方式。
如果能先概述一下你的设计思路、考虑的维度，再开始逐个用例的设计，应该会更合适些。这样不仅面试官听的清楚，接下来你自己设计测试用例的时候也会有条不紊。
通常主要有 2 个大类：功能性需求 和 非功能性需求。
一、功能性需求
其实就是软件本身需要实现的具体功能。上述列举的7条测试用例，就是属于功能性需求。通常它们是这个功能的最直接体现。
在设计这种用例的时候，我们基本会用【等价类】和【边界值】这两种方法。
二、非功能性需求
很多时候，仅做了功能性需求的测试覆盖还是不够的，因为还存在一些其他"隐藏"的需求，比如：安全性、性能、兼容性。这些往往是决定软件质量的关键因素。
这些需求往往不容易优先想到，需要仔细深入场景、设身处地的考虑才能很好的构思出来。
1. 安全性测试
考虑登录的安全性，可能还需要增加以下的测试用例：
1. 用户密码后台存储是否加密 2. 用户密码在网络传输过程中是否加密 3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码 4. 不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面 5. 密码输入框是否不支持复制和粘贴 6. 用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面 7. 用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改 8. 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解 9. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期 10. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性
2. 性能测试
考虑到性能，可能还需要增加以下的测试用例：
1. 单用户登录的响应时间是否小于 3 秒 2. 单用户登录时，后台请求数量是否过多 3. 高并发场景下用户登录的响应时间是否小于 5 秒 4. 高并发场景下服务端的监控指标是否符合预期 5. 高集合点并发场景下，是否存在资源死锁和不合理的资源等待 6. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏
3. 兼容性
1. 不同浏览器下，验证登录页面的显示以及功能正确性 2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性 3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性 4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性
这下方方面面应该都全了，看面试官你还怎么说？
结果面试官仍然问：你还有要补充的吗？
三、测试的不可穷尽性
这时候，就需要表述一下测试的不可穷尽性了。我不知道各位童鞋是怎么样的，反正我不敢说我设计的测试一定是无遗漏的，也就是说不可能做到穷尽测试。
什么是穷尽测试：指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。
通常在实际工作中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
所以，这也是为什么要在测试前，与项目成员确定好本次的测试范围。
