测试用例概述
考虑部分同学是转行做软件测试，我先说一下测试用例是什么。
看到测试用例的定义是不是有点晕，通俗的来讲，测试用例就是一个参照物，在测试过程中，会按照测试用例来逐条执行测试。测试用例最主要是有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. 将软件的输入或者输出参数进行等价类划分；
2. 在等价类的基础之上进行边界值分析。一般情况下，假如边界值已经由等价类划分覆盖，则可以不予考虑；
3. 将边界值进行组合，作为测试用例的输入数据。
再回顾一下上述介绍等价类时的例子，测试两个1-100整数（包含1和100）相加，现在我们将等价类和边界值用例设计法结合起来，用例1 可以改成输入整数1，2，99，100，用例2改成 输入整数0，用例3改成输入101。经过这样的改造，我们的用例既经过了等价类划分覆盖有效和无效等价类，也进行了边界值分析，覆盖到边界值的测试。
细心的小伙伴会问，为什么我们要用边界值去设计测试用例呢？这个是由大量的测试实践经验得出，大量的Bug往往发生在输入定义域或者输出值域的边界上，而不是在内部。因此，我们针对边界情况设计测试用例，一般能发现更多的问题。
再看看为什么要用等价类去设计测试用例，对于一个程序，往往可以输入的数据非常多，就拿一个可输入11位的密码框来说，我们不可能实现穷举测试，可以从大量的可能数据中选取一部分具有代表性的数据作为测试用例，这样极大提高测试效率同时保证了测试的质量，因为经过等价类划分后，每一类的代表性数据在测试中的作用都等价于这一类中的其他值。
更多用例设计方法
·功能图
· 场景法
· 因果图
· 错误推测
· 判定表
· 正交试验
· 状态迁移
除了等价类和边界值，还有很多测试用例的设计方法，在上面已经列出来了。我这里再讲讲错误推测法，这个方法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例。在企业里面，当你熟悉业务以后，就可以根据业务的特点去定制化的设计测试用例作为补充了。
用例设计考虑层面
前面我们介绍了等价类和边界值的用例设计方法，这两种黑盒用例设计方法所产生的用例都是属于功能测试层面，除了功能方面，我们在设计测试用例时，还应该考虑到兼容性、性能、安全这三个层面。
功能测试用例
还是登陆功能举一个例子，对于我们测试人员该怎么设计用例呢，先从功能层面考虑，我们比较容易能想到以下用例：
· 输入已注册的用户名和正确的密码，验证是否登陆成功
· 输入已注册的用户名和不正确的密码，验证是否登陆失败
· 输入未注册的用户名和任意密码，验证是否登陆失败
· 用户名和密码两者都为空，验证是否登陆失败
· 用户名和密码两者之一为空，验证是否登陆失败
· 如果登陆功能启动了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，是否登陆成功
· 如果登陆功能启动了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登陆失败
列出这些测试用例后，你是不是感觉上面的测试用例已经涵盖了主要的功能测试场景，但是在高级测试工程师眼中，这些用例还不够，再看看下面这些测试用例你是否考虑到：
· 用户名和密码是否大小写敏感
· 页面上的密码框是否加密显示
· 后台系统创建的用户第一次登录成功时，是否提示修改密码
· 忘记用户名和忘记密码的功能是否可用
· 前端页面是否根据设计要求限制用户名和密码长度（若有限制长度位数，则可以根据边界值设计测试用例）
· 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用
· 刷新页面是否会刷新验证码
· 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性
· 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面
· 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确
· 页面默认焦点是否定位在用户名的输入框中
· 快捷键 Tab 和 Enter 等，是否可以正常使用
· 鼠标光标是否只在固定位置才显示可点击或编辑状态
看完以后你是不是觉得原来一个简单的登陆功能可以考虑这么多测试点，用户登录功能的测试用例设计还没结束。我们应该知道软件的需求包含显式功能性需求（指的是软件本身需要实现的具体功能）和隐式功能性需求（即非功能性需求），所以除了功能以外，我们还要考虑安全、性能、兼容性层面的用例。
安全性测试用例
1. 用户密码及个人信息是否加密存储；
2. 用户密码及个人信息在网络传输过程中是否加密；
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4. 不登录的情况下，在浏览器中直接输入登录后的 URL 地址，验证是否会重新定向到用户登录界面；
5. 密码输入框是否不支持复制和粘贴；
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看；
7. 用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；
8. 用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串，验证系统行为是否被篡改；
9. 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
12. 登录接口返回的数据是否对用户信息进行加密显示
13. 登录UA获取，确保是用户本人登录
性能测试用例
1. 单用户登录的响应时间正常网络环境下是否小于 2 秒；
2. 单用户登录时，后台请求数量是否过多；
3. 高并发场景下用户登录的响应时间是否小于 5 秒；
4. 高并发场景下服务端的监控指标是否符合预期；
5. 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
7. 防止同一用户恶意并发。
兼容性测试用例
1. 不同浏览器下，验证登录页面的显示以及功能正确性；
2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。
复杂系统如何设计用例
对于复杂系统的用例设计，有着非常重要的一步，就是拆解功能点。那应该怎么拆解功能点呢，就拿B站的播放页面来说，别看只有一个页面，但是上面包含了非常多的功能点，通过这张图片，我们至少能拆出如下功能点：
·点赞
· 投币
· 收藏
· 分享
· 评论
· 弹幕
· 播放页面Tab、文案与信息展示
拆解完功能点以后，我们就可以依据各自的功能点利用等价类、边界值、错误推测等方法设计测试用例，单功能的用例设计完成以后，还需要使用场景法设计场景化的测试用例，覆盖到用户的操作流程，比如：
这就一个用户操作的基本流程，再举一个场景化的例子，我们都用过淘宝，从挑选商品->加入购物车->从购物车付款，这就是购买商品的核心场景。
场景法偏重于大的、复杂的业务流程，目的是用业务流把各个孤立的功能点串起来，所以在用场景法设计用例时，测试人员必须非常熟悉整体业务流程，才能设计出完整的场景化测试用例。
结尾
好了，能完整的看到这里，说明你已经是一个非常想学好设计测试用例设计的同学了，想要设计好测试用例，掌握了测试用例的设计方法，还需要勤加练习，你设计出的测试用例体现出你的测试思维，而测试思维的养成也不是一天两天就能形成，它需要不断的积累和大量的测试实践。
