1.测试用例的基本要素（4个）——测试环境、操作步骤、测试数据、预期结果

（测试用例的基本要素不需要执行结果）

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合。

这组集合包含：测试环境、操作步骤、测试数据、预期结果（标题、序号、重要性、优先级、操作方式）等要素。

eg：就像在线oj里面的用例

测试环境：LeetCode提供给我们一个测试环境：如Windows系统+Chrome浏览器。

测试数据：牛客网可以自己输入测试数据，后台也提供了测试数据。

操作步骤：写代码，点击提交。

预期结果：点击提交，通过率为100%。若预期结果和实际结果相同，说明测试用例通过，否则不通过。

测试用例解决了两大问题：测什么，怎么测。

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

评价测试用例的标准：

用例表达清楚，无二义性。

用例可操作性强。

用例的输入与输出明确。

一条用例只有一个预期结果。

用例的可维护性好。

用例对需求的覆盖率高。

2.测试用例的带来的好处

一个项目写多少测试用例不确定，根据项目难易程度、需求而定。

但测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多。那为啥还要写？原因：

测试用例是测试执行者的依据。
测试用例可评估需求覆盖率。
测试用例可以提高测试人员的工作效率 / 降低测试人员工作的重复性问题。复用性，借鉴意义。
测试用例是建立自动化测试的基础。【自动化就是把测试人员双手解放，让代码代替人来执行测试】

3.测试用例的设计方法（基于黑盒测试）

3.1.基于需求进行测试用例的设计

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性、逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。

在分析测试需求时，一般分为功能测试需求和非功能测试需求。

3.1.2.功能需求测试分析

对于功能测试中，可以借助功能框图来帮助进行测试的需求分析。概括起来，功能测试需求通常包括以下几个方面。

系统各个功能界面的验证。
借助业务把功能串起来进行测试。
功能的一致性，交互性（多功能交互操作）的测试。
系统的不同输入，结果输出的业务数据测试。
功能的错误操作，异常操作的测试（属于负面测试）。
功能实现用到的算法验证，有时需要运用代码评审。
用户操作的易用性，用户体验，往往结合功能测试同时验证。

针对具体的需求，可以根据业务分类，用户角色或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。

例1：下面对一个简单的日历系统的需求进行分析

对日历根据web界面的功能布局分析出的功能框图如下：

也可以采用思维导图的方式，更方便、有效，只管呈现测试需求的分析结果，可以更好地支持测试分析思路的连贯性。

例2：下面以百度云盘手机端为例进行分析功能

在进行需求分析的时候，还要考虑业务规则如：上传文件的大小有没有限制；一次性上传多少数量的文件，比如小于100个；文件夹最多有多少层等等。

例3：

3.1.3.非功能需求测试分析

非功能需求测试主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。

这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。

纯客户端软件，比如文字处理软件（Word，PPT)，媒体（音频/视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。
企业内部的客户端/服务端（C/S)应用系统。比如电子邮件，即时通信系统（飞Q，企业QQ）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。
外部大型复杂网络应用系统，比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

此外，对于大型企业级应用系统，由于应用模式，系统架构的不同（分布式，微服务等），我们必须结合架构和应用模式来具体分析非功能性测试需求，特别是可扩展性，可靠性，安全性等。技术架构对功能的影响小，但是非功能性测试就要深入架构分析，才能更好的把我测试范围和测试方法。

例：

如何模拟网络？

借助工具：

Charles（公司里使用较多）

Fiddler

3.2.具体的设计方法

①等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

等价类分类：

有效等价类：满足用户需求的输入集合。
无效等价类：不满足用户需求的输入集合。

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

等价类思想设计测试用例的步骤：

充分理解需求。
划分有效等价类、划分无效等价类。
从有效等价类中抽取一个数据进行设计测试用例、从无效等价类中抽取一个数据进行设计测试用例。

例：

②边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

6 < username.length < 15
7 <= username.length <= 14

(二者等价)

边界点划分：

上点：边界上的点。
内点：边界内的点(其中任意一个点)。
离点：边界值附近的一个点(闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点)。

例1：[6, 15]

上点：6，15
内点：12（7~14都可）
离点：5，16

例2：(6, 15]

上点：6，15
内点：12（6~14都可）
离点：7，16

边界值设计测试用例的步骤：

充分理解需求。
找边界点。
针对边界点设计测试用例。

例：

③判定表法（因果图）

判定表是另一种表达逻辑判断的工具。

关系：

与：
或：
恒等：
非：

3-测试用例（CASE）