一、编写测试用例的目标：
保证系统在各种应用场景下的功能是符合设计要求的
二、设计测试用例是测试工程师的必备基本功，最常用的编写测试用例的方法：
2.1 等价类
等价类划分方法，是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
有效等价类：对于需求是有效的
无效等价类：对于需求是无效的
2.2 边界值
边界值分析方法，是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
从方法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试方法经常结合起来使用。
2.3 场景设计法
分析软件的应用场景，从实际应用场景的角度来设计测试用例，是一种面向用户的测试用例的设计方法；
关心用户做什么，而不关系产品做什么；
2.4 判定表
判定表是分析和表达多种输入条件下，系统执行不同动作的工具；
将复杂的逻辑关系和多种条件组合的情况表达的清晰明了；
2.5 因果图
用于描述输入与输入、输入与输出之间存在的约束关系；
输入与输出之间的关系有：恒等、与、或、非；
输入与输入之间的关系有：异、或、唯一、要求；
ps：等价类、边界值、场景设计是最常用的设计用例方法
三、显性功能性需求
显性功能性需求（Functional requirement）的含义从字面上就可以很好地理解，指的是软件本身需要实现的具体功能， 比如“正常用户使用正确的用户名和密码可以成功登录”、“非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。
四、隐性功能性需求
从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面，这些往往是决定软件质量的关键因素。
五、以“用户登录”功能作为测试对象进行测试用例编写
5.1 显性功能性需求
5.1.1 基于等价类划分和边界值分析方法设计的测试用例包括：
（1）输入已注册的正确用户名和正确的密码，验证是否登录成功；
（2）输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
（3）输入已注册的错误用户名和正确的密码，验证是否登录失败，并且提示信息正确；
（4） 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
（5）用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
（6）用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
（7）如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
（10）如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。
5.1.2 基于场景方法设计的测试用例包括：
（1）用户名和密码是否大小写敏感；
（2）页面上的密码框是否加密显示；
（3）后台系统创建的用户第一次登录成功时，是否提示修改密码；
（4）忘记用户名和忘记密码的功能是否可用；
（5）前端页面是否根据设计要求限制用户名和密码长度；
（6）如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
（7）刷新页面是否会刷新验证码；
（8）如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
（9）用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
（10）不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
（11）页面默认焦点是否定位在用户名的输入框中；
（12）快捷键 Tab 和 Enter 等，是否可以正常使用。
5.2 隐士功能性需求
5.2.1 安全性测试用例：
（1）用户密码后台存储是否加密；
（2）用户密码在网络传输过程中是否加密；
（3）密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
（4）不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
（5）密码输入框是否不支持复制和粘贴；
（6）密码输入框内输入的密码是否都可以在页面源码模式下被查看；
（7）用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
（8）用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
（9）连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
（10）同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
（11）同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
5.2.2 性能压力测试用例包括:
（1）单用户登录的响应时间是否小于 3 秒；
（2）单用户登录时，后台请求数量是否过多；
（3）高并发场景下用户登录的响应时间是否小于 5 秒；
（4）高并发场景下服务端的监控指标是否符合预期；
（5）高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
（6）长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
5.2.3 兼容性测试用例：
（1）不同浏览器下，验证登录页面的显示以及功能正确性；
（2）相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
（3）不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
（4）不同分辨率的界面下，验证登录页面的显示以及功能正确性。
六、总结
6.1 测试的不可穷尽性，即绝大多数情况下，是不可能进行穷尽测试的。
所谓的“穷尽测试”是指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。 因为如果有未知的软件缺陷，你可以通过做更多的测试来找到它们，也就是说你的测试还没有穷尽。
但是，在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。
6.2 对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。
6.3 优秀的测试工程师必须具有宽广的知识面，才能设计出有针对性、更易于发现问题的测试用例。
6.4 软件测试的用例设计是不可穷尽的，工程实践中难免受制于时间成本和经济成本，所以优秀的测试工程师需要兼顾缺陷风险和研发成本之间的平
