大家好，我是一名测试开发工程师，今天跟大家分享下测试用例设计方法。
在做软件测试时，最容易忽略但却最重要的知识点，那就是测试用例设计。用例设计就是软件测试工程师的灵魂，体现了你的测试思维，以及对业务需求的熟悉程度。有时侯出现线上事故，可能就是测试用例没有覆盖全面。
考虑部分同学是刚入行做测试的，我先说一下测试用例是什么：
看到测试用例的定义是不是有点晕，通俗的来讲，测试用例就是一个参照物，在测试过程中，会按照测试用例来逐条执行测试。测试用例最主要是有 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 跳转到评论页面，点击评论按钮，进行评论，评论完成后，查看评论列表，这就一个用户操作的基本流程，再举一个场景化的例子，我们都用过淘宝，从挑选商品->加入购物车->从购物车付款，这就是购买商品的核心场景。
场景法偏重于大的、复杂的业务流程，目的是用业务流把各个孤立的功能点串起来，所以在用场景法设计用例时，测试人员必须非常熟悉整体业务流程，才能设计出完整的场景化测试用例，想要彻底弄懂业务流程我们可以细看需求文档、多和产品经理沟通交流还可以亲自体验功能。
好了，能完整的看到这里，说明你已经是一个非常想学好设计测试用例设计的同学了，想要设计好测试用例，掌握了测试用例的设计方法，还需要勤加练习，你设计出的测试用例体现出你的测试思维，而测试思维的养成也不是一天两天就能形成，它需要不断的积累和大量的测试实践。
