对于测试用例来讲，“好的”测试用例一定是一个完备的集合，能够覆盖所有的等价类以及各种边界值，而跟能否发现缺陷无关。
如果把测试软件看做一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕鱼网，“好的”测试用例集就是一张能够覆盖整个池塘的大鱼网，只要池塘里面有鱼，这个大渔网就一定能把鱼给捞上来。
如果渔网本事是完整的且合格的，那么捞不到鱼，就证明池塘里面没有鱼，而渔网的好坏与池塘中是否有鱼无关。
“好的” 测试用例必须具备哪些特征？
好的测试用例，必须具备一下三个特征：
1.整体完备性：“好的”测试用例一定是一个完备的整体，是有效用例组合的集合，能够完成全覆盖测试需求。
2.等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3.等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。
能做到以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。
三种最常用的测试用例设计方法
从理论层面上讲设计用例的方法很多：比如等价类划分，边界值分析法，错误推断法，因果图法，判定表驱动分析法，正交试验设计法，功能图分析法，场景设计法，形式化方法，扩展有限状态机方法等等，但是实际在企业的过程实践中，真正具有实用价值并且常用的只有前三种方法。
对于那些与生命相关的或者间接相关的软件，比如飞行控制，轨道交通的列车控制，医疗检测相关的软件或者系统，由于达到变态的测试覆盖率要求，会采用更多的设计方法。
对于大多数软件而言，综合使用等价类划分，边界值分析，和错误推断法这三大类的测试方法就足够了。
以下讲介绍这三类方法的核心概念和使用时要注意的问题：
举一个实际的例子来解释一下这三类方法的核心概念以及在使用时需要注意的问题
第一、等价类划分方法
我们知道等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果，后续我们只要从每个等价
类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
举一个具体的例子：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数
考试成绩及格的分数线是60
为了测试这个输入项，显然不可能用0~100的每一个数去测试，通过需求描述可以知道没输入0~59之间的任意整数
考试成绩及格的分数线是60
为了测试这个输入项，显然不可能用0~100的每一个数去测试，通过需求描述可以知道，输入0~59之间的任意整数，
以及输入60~100之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的
那么就可以在0~59和60~100之间各随机抽取一个整数来进行验证，这样的设计就构成了所谓的“有效等价类”
但是到这并没有完成等价类划分的工作，因为等价类划分方法的另一个关键点是要找出所以“无效等价类”，显然，
如果输入的成绩是负数，或者是大于100的数等都构成了“无效等价类”
在考虑了无效等价类后，最终设计的测试用例为：
1.有效等价类1:0~59 之间的任意整数
2.有效等价类2：59~100之间的任意整数
3.无效等价类1：小于0的负数
4.无效等价类2: 大于100的整数
5.无效等价类3：0~100之间的任何浮点数
6.无效等价类4：其他任意非数字字符
第二，边界值分析方法
边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上
所以需要对边界值进行重点测试，通常选取真好等于、刚刚大于或者刚刚小于边界的值作为测试数据
我们在看学生信息系统中“考试成绩”例子，选取的边界值数据应该包括：-1,0,1,59,60,61,99,100,101
第三，错误推断法
错误推断方法是基于对被测试软件系统设计的理解，过完经验以及个人直觉，推测出软件可能存在的缺陷
从而有针对性的设计测试用例的方法。这个方法强调的是对被策划思软件的需求理解以及设计实现的细节把握
当然还有个人能力
错误推断法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发
模式下的投入产出比很高，因此被广泛应用，但是，这个方法的缺点也是显而易见，那就是难以系统化，并且过度依赖个人能力
比如，web界面的GUI功能测试，需要考虑浏览器在有缓存和没有缓存的下的表现；Web Service的API测试，需要考虑被测试API
所依赖的第三方API出错下的处理逻辑；对于代码级的单元测试，需要考虑被测函数的输入参数为空情况下的内部处理逻辑等等，
由此可见，这些测试用例的设计都是基于曾经遇到的问题而进行的错误推测，很大程度上取决于个人能力。
在公司中，为了降低对 个人能力的依赖，通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表，
去帮助优化补充测试用例的设计
在中小企业中，可能最初的方法就是建立一个简单的wiki页面，让测试工程师完成测试用例的最初设计后对应这个wiki页面先做一轮自检
如果在后面测试中发现了新的点，就会继续完善这个wiki页面
对于测试基础架构比较成熟的中大型软件企业，通常会以改缺陷知识库作为数据驱动测试的输入来自动化生成部分的测试数据
如何才能设计出“好的”测试用例
在真实的工程实践中，不同的软件项目在研发生命周期的各个阶段都会有不同的测试类型
比如说，传统软件的开发阶段通常会有单元测试，软件模块集成阶段会有代码级集成测试，打包部署后会有
面向终端用户的GUI测试，在比如，电商网站的测试会分为服务端基于API测试，中间件测试前端GUI测试等
对于每一种不同的测试类型，设计出“好的”测试用例的关注点和方法论可能会有很大的差异，，有些可能采用黑盒放法
有些可能采用白盒方法，有些还会采用灰盒方法（比如，微服务架构中的测试），所以很难有一套放之四海而皆准的套路
所以，在这边文章中，以最简单，最容易理解的面向终端用户的GUI测试为例，聊聊怎么去设计一个“好的”测试用例
面向终端用户的GUI测试，最核心的测试点就是验证软件对需求的满足程度，这就要求测试工程师对被测软件的需求有
深入的理解，深入理解被测软件的需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解
和掌握软件的原始业务需求的最好时机
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户使用场景考虑的端到端（end-2-end）
的测试用例集，这个阶段的测试用例设计，主要目的是验证各个业务需求是否被满足，主要采用基于黑盒的测试用例设计方法
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点
最后在针对每个测试需求点设计测试用例。
在用例设计过程中，可能觉得会有点绕，但是没有关系，我以“用户登录”功能的测试用例设计为例，画出一张图来理清楚这些概念之间的映射关系
图中的业务需求到软件功能需求，软件功能需求到测试需求，以及测试需求到测试用例的映射关系，在非和互联网软件企业的实践中，通常会使用需求
追踪管理工具（比如ALM,DOORS,JIRA,Testink等）来管理，并以此来衡量测试用例对业务需求，软件功能需求的覆盖率
具体到测试用例本身的设计，有两个关键点需求你注意
1.从软件功能需求出发，全面地，无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
比如，如果你没有识别出用户登录功能的安全性测试需求，那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞
2.对于识别出每个测试需求点，需求综合运用等价类划分，边界值分析和错误推断法来全面地设计测试用例，这里需要注意的是，要综合运用这
三种方法，并针对每个测试需求点的具体情况，进行灵活的选择
以“用户登录”的功能测试需求为例，你首先应该对“用户名”和“密码”这两个输入项分别进行等价类划分，列出对应的有效等价类和无效等价类
对于无效等价类的识别可以采用错误猜测法（比如，用户包含特殊字符等），然后基于两者可能的组合，设计出第一批测试用例。
等价类划分完成后，你需要补充"用户名"和“密码”这两个输入项的边界值的测试用例，比如用户名为空（NULL）、用户名长度刚刚大于允许长度等
用例设计的其他经验
分享三个独家秘笈，来帮助设计出“好的”测试用例集
1.只有深入理解被测试软件的架构，才能 设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷
作为测试工程师，切记不能把整个被测试系统看做一个大黑盒，你必须对内部的架构有清楚的认识，比如数据库连接方式，数据库读写分离
消息中间件kafka的配置，缓存系统的层级分布，第三方系统的集成等等
2.必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑
单单根据测试下需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理、而没有覆盖到的部分就很可能出现缺陷遗漏
在具体实践中，你可以通过代码覆盖率指标找出可能的测试遗漏点
同时，切忌不要以开发代码的实现为依据设计测试用例，因为开发代码实现的错误会导致测试用例也出错，所以你应该根据2原始需求设计测试用例
3.需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
总结
首先，要明白，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能发现软件缺陷并不是衡量测试用例好坏的标准
其次，设计测试用例的方法有很多种，但综合运用等价类划分，边界值分析和错误推测方法，可以满足绝大数软件测试用例设的需求
再次，“好的”测试用例在设计时，需要从软件功能需求出发，全面地，无遗漏地识别出测试需求至关重要
最后，如果想设计“好的”测试用例，你必须深入理解被测软件的架构设计，深入软件内部的处理逻辑，需求覆盖率和代码覆盖率这两个指标可以帮你衡量测试执行的完备性。
