等价类划分和边界值分析方法是最常用、最典型并且是最重要的黑盒测试方法。

一、功能测试用例

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

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

        上述都是登录功能的功能性测试用例；但是，在一个质量过硬的系统里，除了显式的功能性需求需要验证外，其他隐式的非功能性需求也需要做。

二、非功能性测试：

        非功能性测试主要涉及安全、性能及兼容性；

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

性能测试用例：
        1、验证单用户登录的响应时间是否短于3s;
        2、验证单用户登录时，后台请求数量是否过多;
        3、验证高并发场景下用户登录的响应时间是否短于5s；
        4、验证高并发场景下服务器端的监控指标是否符合预期；
        5、验证高集合点并发场景下，是否存在资源死锁和不合理的资源等待;
        6、同一时间大量用户连续登录和登出，验证服务器端是否存在内存泄露。

兼容性测试用例：
        1、不同浏览器下，验证登录页面的显示以及功能正确性;
        2、相同浏览器的不同版本下，验证登录页面的显示以及功能正确性;
        3、不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性;
        4、不同分辨率的界面下，验证登录页面的显示以及功能正确性。

三、测试的不可穷尽性：

“穷尽测试”指包含了软件输入值和前提条件的所有组合的测试方法，但是在软件工程设计中，由于时间、经济成本的限制，不可能穷尽所有的测试组合，只能采取基于风险驱动模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。

四、“好的” 测试用例：

好的测试用例，不是一条用例，而是一个完备的用例集合；它能够覆盖所有等价类以及各种边界值，涵盖功能性和非功能性的测试用例集；而与能否发现缺陷无关。

好的测试用例一般具有以下特征：

1、整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

2、等价类划分的准确性：指的是对每个等价类都能保证只要其中一个输入测试通过。其他输入也一定测试通过。

3、等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。做到了以上3点，就可以说测试是充分且完备的，即做到了完整的测试需求覆盖。

测试用例设计方法：

测试用例设计方法很多，如等价类划分、边界值分析方法、错误推测法、因果图法、判定表驱动分析方法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、拓展有限状态机方法等；在实际工作中，最常用的是前三种。

等价类划分方法：等价类中任意一个输入数据对于披露程序中存在的错误具有同等效果，只需要从每个等价类中任意选取一个值进行测试，就可以用少量具代表性的测试输入取得较好的覆盖效果。如：学生成绩是0-100分。

考虑有效、无效等价类，最终测试用例如下：

有效等价类1：0-100的任意数

无效等价类1：小于0的负数

无效等价类2：大于100的整数

无效等价类3：0-100的任意浮点数

无效等价类4：其他任意非数字字符

边界值分析方法：是对等价类分析方法的补充，大量程序错误发生在输入/输出的边界值上；需要对边界值重点测试。如：学生成绩0-100 ；则边界值数据包括： -1、0、1、99、100、101

错误推测方法：基于对测试系统设计的理解、过往经验、个人直觉，推测系统可能存在缺点的地方，从而针对性设计测试用例的方法。 缺点是：难以系统化，并且过度依赖个人能力和经验。

在设计具体测试用例时，首先要搞清楚每一个业务需求所对应的的多个软件功能点，然后分析出每个软件功能点对应的多个测试需求点，最后针对每个测试需求点设计测试用例。概念之间的映射关系如下：

两个关键点要特别注意：一、从软件功能需求出发，全面地、无遗漏地识别出测试需求至关重要，这关系到测试用例的测试覆盖率，否则会造成测试遗漏。二、对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析方法和错误推测方法全面的设计测试用例，综合运用，不是单一运用。

五、测试用例设计其他建议：

1、只有深入理解被测试软件的架构，才能设计出有的放矢的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。作为测试工程师，切忌把整个被测系统看作一个大黑盒，必须对内部的架构有清禁的认识，比如，数据库连接方式、数据库的读写分离、消息中间件Kafka的配置、缓存系统的层级分布、第三方系统的集成等。

2、必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。单单根据测试需求点设计的测试用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就可能出现测试遗漏。在具体实践中，测试人员可以通过代码覆盖率指标找出可能的测试遗漏点。同时，切忌以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以应该根据原始需求设计测试用例。

3、需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。

作为测试人员，需要注意以下几点。

1、需要明白，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。

2、设计测试用例的方法有很多种，但综合运用等价类划分方法、边界值分析方法和错误推测方法，可以满足绝大多数软件测试用例设计的需求。

3、在设计时，“好的”测试用例需要从软件功能需求出发，全面地、无遗漏地识别出测试需求。

4、如果想设计一个“好的”测试用例，必须要深入理解被测软件的架构设计，深入理解软件内部的处理逻辑。

最后，一个优秀的测试工程师需要具备很广的知识面，如果不能深入理解被测系统的设计、不明白安全攻击的基本原理、没有掌握性能测试的基本设计方法、不真正理解原始业务需求，是很难设计出具有针对性的测试用例。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取