前言：我想把博客当作一个记录自己学习与成长的地方，会摘抄一些自己认为重要的内容记录下来，希望大家可以一起学习一起交流。如有雷同的文章，请见谅~
============================================分割线=================================================
对于测试来说，编写测试用例是十分重要的一步环节。从需求确定——到编写测试用例——测试用例评审——执行测试，测试用例始终是作为测试的一个“命脉”。
那么如何编写好的测试用例呢？让我们先从简单的用户登录功能来设计一个测试用例吧！
首先编写测试用例最主要的几个方法：等价类划分和边界值分析。这两个都隶属于最常见、最典型、也是最重要的黑盒测试方法。
- 等价类划分方法，是将所有可能的输入数据划分若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都有同等效果，那么这样的子集就构成了一个等价类。后续只要从每一个等价类中任取一个值来进行测试，就可以用最少的工作量完成较好的测试覆盖结果。
- 边界值分析方法，是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于和刚刚小于边界的值作为测试数据。
从方法论上来看，边界值分析是对等价类划分的一个补充，所以这两种测试方法经常结合起来使用。
现在，针对“用户登录”功能，基于等价类划分和边界值方法，我们设计的测试用例包括：
1.输入已注册的用户名和正确的密码，验证是否登录成功；
2.输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
3.输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
4.用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
5.用户名和密码有一个为空，验证是否登录失败，并且提示信息正确；
6.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
7.如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
上面的测试用例集涵盖了主要的功能测试场景。但是在一个优秀的测试工程师眼中，这些用例只能达到勉强及格的标准。
有经验的测试工程师会再增加的测试用例（当然不是我，我是只菜鸟）：
1.用户名和密码是否大小写敏感；
2.页面上的密码框是否加密显示；
3.后台系统创建的用户第一次登录成功时，是否提示修改密码；
4.忘记用户名和忘记密码的功能是否可用；（有忘记用户名功能的项目接触的比较少）
5.前端页面是否根据设计要求限制用户名和密码长度；
6.如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
7.刷新页面是否会刷新验证码；
8.如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
9.用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
10.不同级别的用户，比如管理员和普通用户，登录系统后的权限是否正确；
11.页面默认焦点是否定位在用户名的输入框中；
12.快捷键Tab和Enter等，是否可以正常使用。
我觉得其中的3、8和10条，应该是属于产品需求方面的。如果有对应的需求那无可厚非，但是就我目前接触到的项目而言，这些需求不一定每个项目都具有。开发基本不会去做产品没有设计的需求点。
以上所有的测试用例都是围绕功能性需求的验证展开的，但是大佬又会说了，一个质量过硬的软件系统，除了一些功能测试外，还有安全性、性能和兼容性三大方面的测试要涵盖。
安全性测试用例包括：
1.用户密码后台存储是否加密；
2.用户密码在网络传输过程中是否加密；
3.密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4.不登陆的情况下，在浏览器中直接输入登录后的URL地址，验证码是否会重定向到用户登录界面；
5.密码输入框是否不支持复制和粘贴；
6.密码输入框输入的密码是否可以在页面源码模式下被查看；
7.用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；
8.用户名和密码的输入框中分别输入典型的“XXS跨站脚本攻击”字符串，验证码系统行为是否被篡改；
9.连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10.同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11.同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
性能压力测试用例包括：
1.单用户登录的响应时间是否小于3秒；
2.单用户登录时，后台请求数量是否过多；
3.高并发场景下用户登录的响应时间是否小于5秒；
4.高并发场景下服务端的监控指标是否符合预期；
5.高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6.长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
兼容性测试用例包括：
1.不同浏览器下，验证登录页面的显示以及功能正确性；
2.相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3.不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4.不同分辨率的界面下，验证登录页面的显示以及功能正确性。
测试用例除了要覆盖明确的功能性需求，还需要考虑其他诸多的非功能性需求。
通过这些用例的设计，一个优秀的测试工程师必须具有很宽广的知识面，如果不能对被测系统的设计有深入的理解，不明白安全攻击的基本原理，没有掌握性能测试的基本设计方法，很难设计出“有的放矢”的测试用例。
其实还有一些遗漏的测试点没有覆盖到，这个功能的测试点还不够全面。接下来谈一谈测试的不可穷尽性，即绝大多数情况下，是不可能进行穷尽测试的。
所谓的“穷尽测试”是指包含了软件输入值和前提条件的所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。因为如果有未知的软件缺陷，你可以通过做更多的测试来找到它们，也就是说你的测试还没有穷尽。
但是在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基本风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
总结
首先，对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。
其次，优秀的测试工程师必须具有宽广的知识面，才能设计出有针对性、更易发现问题的测试用例。
最后，软件测试的用例设计是不可穷尽的，工程实践中难免受到时间成本和经济成本，所有优秀的测试工程师需要兼顾缺陷风险和研发成本之间的平衡。