测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求

测试用例可以认为就是一个参照物，在测试过程中，会按照测试用例来逐条执行测试。测试用例最主要是有4部分组成：
-   用例标题
-   前置条件
-   操作步骤（输入）
-   预期结果（输出）

对于测试用例的第3部分，操作步骤可以理解成是输入，比如我们在手机键盘上输入数字或者字母，除此之外，常见的输入还有点击按钮、长按、滑动屏幕等等，注意这里的输入需要满足前置条件

在完成输入以后会有一个预期的结果，可以理解成输出，常见的输出有（1）弹窗（2）跳转新页面（3）tosat 提示（4）展示文字、图片等

看看下面这个例子，现在我需要测试某个网站的登陆功能，我设计的1条测试用例如下：

这条用例是为了验证登陆功能当中成功登陆的情况，所以用例标题为01_登陆功能_成功登陆，标题里面加入编号是为了方便管理。操作步骤是在符合前置条件下进行，即在用户已注册并且未登陆的情况下，输入指定位数的用户名和密码，预期结果就是有弹窗提示，跳转主页。

常见用例设计方法

介绍2种黑盒测试用例设计方法，分别是等价类和边界值，这是实际工作当中最常用的2种。

等价类

等价类从字面上来理解就是相同的种类，下面为等价类的定义：

等价类是把用户所有可能输入的数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例
使用等价类设计测试用例时，要同时考虑有效等价类和无效等价类
有效等价类：对于程序的规格说明（需求文档）来说，是合理的、有意义的输入数据所构成的集合；
无效等价类：对于程序的规格说明来说，是不合理的、没有意义的输入数据所构成的集合

现在我要测试两个1-100整数（包含1和100）相加，请你利用等价类设计测试用例，按照题目先划分出有效等价类和无效等价类。

有效等价类：

【1】输入的都是1-100的整数

无效等价类：

【2】输入小于1的整数
【3】输入大于100的整数
【4】输入空
【5】输入字母和特殊字符
【6】输入空格

边界值

边界值分析法就是对输入或者输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。一个输入的文件应包括1~255个记录, 那么可以分析出6个边界点，分别是略小于最小值0，最小值1，略大于最小值2，略小于最大值254，最大值255和略大于最大值256，这6个点即可作为测试用例的输入数据。

等价类和边界值往往结合起来使用，边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例；

将软件的输入或者输出参数进行等价类划分；
在等价类的基础之上进行边界值分析。一般情况下，假如边界值已经由等价类划分覆盖，则可以不予考虑；
将边界值进行组合，作为测试用例的输入数据；测试两个1-100整数（包含1和100）相加，现在我们将等价类和边界值用例设计法结合起来，用例1 可以改成输入整数1，2，99，100，用例2改成输入整数0，用例3改成输入101。经过这样的改造，我们的用例既经过了等价类划分覆盖有效和无效等价类，也进行了边界值分析，覆盖到边界值的测试。

为什么要用边界值去设计测试用例呢？这个是由大量的测试实践经验得出，大量的Bug往往发生在输入定义域或者输出值域的边界上，而不是在内部。因此，针对边界情况设计测试用例，一般能发现更多的问题。

为什么要用等价类去设计测试用例，对于一个程序，往往可以输入的数据非常多，就拿一个可输入11位的密码框来说，我们不可能实现穷举测试，可以从大量的可能数据中选取一部分具有代表性的数据作为测试用例，这样极大提高测试效率同时保证了测试的质量，因为经过等价类划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。

用例设计考虑层面

前面介绍了等价类和边界值的用例设计方法，这两种黑盒用例设计方法所产生的用例都是属于功能测试层面，除了功能方面，在设计测试用例时，还应该考虑到安全、性能、兼容性这三个层面。

功能测试用例

对于登陆功能，我们测试人员该怎么设计用例呢，先从功能层面考虑，我们比较容易能想到以下用例：

输入已注册的用户名和正确的密码，验证是否登陆成功
输入已注册的用户名和不正确的密码，验证是否登陆失败
输入未注册的用户名和任意密码，验证是否登陆失败
用户名和密码两者都为空，验证是否登陆失败
用户名和密码两者之一为空，验证是否登陆失败
如果登陆功能启动了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，是否登陆成功
如果登陆功能启动了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登陆失败

列出这些测试用例后，你是不是感觉上面的测试用例已经涵盖了主要的功能测试场景，但是在高级测试工程师眼中，这些用例还不够，再看看下面这些测试用例你是否考虑到

用户名和密码是否大小写敏感
页面上的密码框是否加密显示
后台系统创建的用户第一次登录成功时，是否提示修改密码
忘记用户名和忘记密码的功能是否可用
前端页面是否根据设计要求限制用户名和密码长度（若有限制长度位数，则可以根据边界值设计测试用例）
如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用
刷新页面是否会刷新验证码
如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性
用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面
不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确
页面默认焦点是否定位在用户名的输入框中
快捷键 Tab 和 Enter 等，是否可以正常使用
鼠标光标是否只在固定位置才显示可点击或编辑状态

原来一个简单的登陆功能可以考虑这么多测试点，用户登录功能的测试用例设计还没结束。软件的需求包含显式功能性需求（指的是软件本身需要实现的具体功能）和隐式功能性需求（即非功能性需求），除了功能以外，还要考虑安全、性能、兼容性层面的用例。

安全性测试用例

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

性能测试用例

单用户登录的响应时间正常网络环境下是否小于 2 秒；
单用户登录时，后台请求数量是否过多；
高并发场景下用户登录的响应时间是否小于 5 秒；
高并发场景下服务端的监控指标是否符合预期；
高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
防止同一用户恶意并发

兼容性测试用例

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

对于复杂系统的用例设计，有着非常重要的一步，就是拆解功能点。那应该怎么拆解功能点呢，就拿B站的播放页面来说，别看只有一个页面，但是上面包含了非常多的功能点，通过这张图片，我们至少能拆出如下功能点：

点赞
投币
收藏
分享
评论
弹幕
播放页面Tab、文案与信息展示

拆解完功能点以后，我们就可以依据各自的功能点利用等价类、边界值、错误推测等方法设计测试用例，单功能的用例设计完成以后，还需要使用场景法设计场景化的测试用例，覆盖到用户的操作流程，比如

从主页点击视频，跳转到视频播放页面，在播放页面点击评论Tab跳转到评论页面，点击评论按钮，进行评论，评论完成后，查看评论列表

这就一个用户操作的基本流程，再举一个场景化的例子，我们都用过淘宝，从挑选商品->加入购物车->从购物车付款，这就是购买商品的核心场景

场景法偏重于大的、复杂的业务流程，目的是用业务流把各个孤立的功能点串起来，所以在用场景法设计用例时，测试人员必须非常熟悉整体业务流程，才能设计出完整的场景化测试用例，想要彻底弄懂业务流程我们可以细看需求文档、多和产品经理沟通交流还可以亲自体验功能

测试用例设计方法