如何快速上手编写测试用例（一文讲透测试基本概念）

如何快速上手编写测试用例（一文讲透测试基本概念）单元测试主要测试内部数据结构、逻辑控制、异常处理等2、测试重点不一样单元测试属于白盒测试范畴集成测试属于灰盒测试范畴系统测试属于黑盒测试范畴

测试的基本概念和分类

软件测试阶段分类

软件测试按阶段，可划分以下几类：

• 单元测试
• 集成测试
• 系统测试
• 回归测试

单元测试、集成测试、系统测试的比较：

1、测试范畴不同

单元测试属于白盒测试范畴

集成测试属于灰盒测试范畴

系统测试属于黑盒测试范畴

2、测试重点不一样

单元测试主要测试内部数据结构、逻辑控制、异常处理等

集成测试主要测试模块间的接口与接口数据传递关系，以及模块组合后的整体功能

系统测试主要测试整个系统相对于需求的符合度

3、检验基准不一样

单元测试主要通过逻辑覆盖率来评估

集成测试主要通过接口覆盖率来评估

系统测试主要通过测试用例对需求规格的覆盖率来评估

测试人员要编写的主要文档有哪些？

• 测试计划：测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档；
• 测试方案：为完成软件集成特性的测试而进行的设计测试方法的细节文档；
• 测试用例：为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档；
• 测试报告：执行测试结果的文档；
• 测试日报：每天测试执行情况的记录和总结。
• 用户指导手册：教用户怎么使用软件的文档，用途与我们平常买家电的时候附带的说明书类似，一般情况下这个不归测试人员编写，但是有一些小公司可能会让测试写这个文档。

软件测试过程的几个模型，简单了解一下：

V模型：左到右，描述了开发与测试过程之间的阶段对应关系，缺点是不适用于需求变化，灵活性差。

双V模型/W模型：

优点：测试伴随整个产品开发周期，测试对象不仅是程序还有需求、设计文档测试介入较早，及早发现问题，降低修复成本

缺点：实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试设计要求较高（计算机技术、业务知识、管理能力、测试素质等）

为什么要尽早进行测试工作？

按照被测对象的不同，可以分为：

• 白盒测试
• 灰盒测试
• 黑盒测试
• 
  

白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。白盒测试是基于程序结构的逻辑驱动测试。白盒测试发现问题后解决问题的成本较低。

黑盒测试把被测对象看成一个黑盒，只考虑其整体特性，不考虑其内部具体实现。黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块等。测试人员不需要了解实现的细节，包括特定的编程语言；从用户的视角进行测试，很容易被大家理解和接受；有助于暴露任何与规格不一致或有歧义的问题；压力测试和负载测试都属于黑盒测试。

灰盒测试就是介于白盒和黑盒之间的一种。既要关注整体特性，又要关注内部具体实现。

按照是否运行被测对象，可以划分为：

• 静态测试
• 动态测试

静态测试：不运行被测试的软件系统，而是采用其他手段和技术对被测试软件进行检测的一种测试技术。例如：代码走读、文档评审、代码扫描等都是静态测试的范畴。

动态测试：按照预先设计的数据和步骤去运行被测软件系统，从而对被测软件系统进行检测的一种测试技术。

按照是否借助工具划分：

• 手工测试
• 自动化测试

人工测试：测试活动（如评审、测试设计、测试执行等）由人来完成，狭义上是指测试执行由人工完成，这是最基本的测试形式

自动化测试：一般是指通过计算机模拟人的测试行为，替代人的测试活动，狭义上是指测试执行由计算机来完成

自动化测试的意义：

提高回归测试的效率，可以运行更多更频繁的测试，比如冒烟测试。可以执行手工测试困难或不可能做的测试，比如大量的重复操作或者集成测试。

自动化测试的限制：

不能取代手工测试，自动化测试只能提高测试效率，不能提高测试有效性，即不可能发现更多缺陷，手工测试比自动测试发现的缺陷更多；

对测试设计依赖性极大，测试设计的不好会遗漏问题；工具本身并不具备想象力，自动化测试对软件开发具有很大的依赖性，开发上出现变更可能导致前面的自动化测试完全失效。

测试用例设计方法（等价类 边界值）

常见的用例设计方法

• 等价类划分法（适用于输入项少，输入项的属性或者特性相同）
• 边界值分析法（适用于有范围约束的情况）
• 判定表法（适用于有明显的条件及其对应的动作的情况）
• 因果图法
• 状态迁移图法（适用于状态随事件而改变的情况）
• 场景分析法（适合于由事件触发而形成的使用场景，同一事件不同的触发逻辑形成不同的场景，从而形成不同的业务流程（路径），根据覆盖不同的路径来设计测试用例）
• 正交实验法（适用于多条件或多输入情况）
• 异常分析法（适用于大多数软件，从经验上判断容易出现错误或缺陷的地方设计用例）
• 错误猜测法

等价类划分法

是把所有可能的输入数据 即程序的输入域划分成若干部分子集 然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的 常用的黑盒测试用例设计方法。

• 有效等价类：有效等价类是程序规格说明有意义，合法的输入数据
• 无效等价类：无效等价类是程序规格说明无意义，不合法的输入数据。

等价类法设计测试用例的步骤:

1、为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号

2、设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类。重 复这一步骤，使得有效等价类均被测试用例所覆盖

3、设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被覆盖

等价类划分的原则

1、在输入条件规定了取值范围或值的个数的情况下 则可以确立一个有效等价类和两个无效等价类.

2、在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下 可确立一个有效等价类和一个无效等价类.

3、在输入条件是一个布尔量的情况下 可确定一个有效等价类和一个无效等价类.

4、在规定了输入数据的一组值假定n个 并且程序要对每一个输入值分别处理的情况下 可确立n个有效等价类和一个无效等价类.

5、在规定了输入数据必须遵守的规则的情况下 可确立一个有效等价类符合规则和若干个无效等价类从不同角度违反规则.

6、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下 则应再将该等价类进一步的划分为更小的等价类.

等价类表可以参考下图所示：

等价类划分法用例设计实战：

根据下面给出的规格说明，进行测试用例的设计。

一个程序读入3个整数，把这三个数值看作一个三角形的3条边的长度值。程序输出：说明这个三角形是普通的、是等腰的、还是等边的。

等价类划分如下：

3条边分别为A，B，C。满足：A>0，B>0，C>0，且A B>C，B C>A，A C>B；

等腰需满足A=B，或B=C，或A=C ；

等边需满足A=B，且B=C，且A=C ；

最终输出的场景如下：

边界值分析法

边值分析方法的理论基础，是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其它的取值导致程序错误的可能性也很小。

边界值分析使用条件

输入条件明确了一个值的取值范围，或是规定了值的个数

边值点的定义

上点：边界上的点，不区分开闭区间。

离点：就是离上点最近的一个点，如果域的边界是封闭的，离点就在域范围外，如果域的边界是开放的，离点就在域范围内

内点：顾名思义，就是在域范围内的任意一个点

可通过下面这张图更形象的理解：

再举个案例：

• 正整数值域[66 88]：

上点就是66，88，并且都是在域内。内点就是域内得任意点，离点是65，89。

• 正整数值域(66 88]

这种情况上点是66，88，其中一个是域内，一个是域外，内点就是域内的任意点，离点是：67，89。

• 正整数值域(66 88)

这样的情况上点还是66，88，只是都是在域外，内点还是域内的任意点，离点此时为：67，87。

边界值分析的原则

1、如果输入（输出）条件规定了取值范围，或是规定了值的个数，则应该以该范围的边界内及边界附近的值作为测试用例

2、如果输入（输出）条件规定了值的个数的取值范围，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据

3、如果程序规格说明中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试用例

4、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例

边界值分析方法是对等价类划分方法的补充。长期的测试工作经验告诉我们 大量的错误是发生在输入或输出范围的边界上 而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例 可以查出更多的错误。使用边界值分析方法设计测试用例 首先应确定边界情况.通常输入和输出等价类的边界 就是应着重测试的边界情况.应当选取正好等于 刚刚大于或刚刚小于边界的值作为测试数据 而不是选取等价类中的典型值或任意值作为测试数据。

因果图（Cause-Effect Graphing）提供了一个把规格转化为判定表的系统化方法，从该图中可以产生测试数据。其中情况，原因是表示输入条件，结果是对输入执行的一系列计算后得到的输出因果图方法最终生成的就是判定表。它适合于检查软件输入条件的各种组合。

因果图法设计测试用例的步骤：

1、把大的系统规格划分解成可以测试的规格片段

2、分析分解后待测的系统规格，找出哪些是原因，哪些是结果

3、画出因果图

4、把因果图转换成判定表

5、简化判定表

6、用判定表中的每一项生成测试用例

缺点：

1、输入条件与输出结果的因果关系，有时难以从软件需求规格说明书得到

2、即使得到了这些因果关系，也会因为因果关系复杂导致因果图非常庞大，测试用例数目及其庞大

场景分析法

场景分析法是用例设计中比较常用的一种方法，它区别于等价类和边界值的方法，是以列举各种场景的方式去编写测试用例。

异常分析法

系统异常分析法就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，依此设计测试用例。主要针对系统的容错能力、故障恢复能力进行测试。比如输入特殊字符、断网等操作。

错误猜测法

列举出程序中所有可能有的错误和容易发生错误的场景。这个一般取决于测试人员的经验。

其他用例设计方法

还有一些相对复杂一些的用例设计方法，比如因果图、判定表、正交实验法等，大家可以先从网上找简单的资料自行了解一下。

测试用例综合设计策略1

1)在任何情况下都必须使用等价类分析方法，经验表明用这种方法设计出的测试用例，发现的问题比较多。

2)必要时用边界值方法补充一些测试用例。

3)用错误推测法（异常分析法）再追加一些测试用例。

4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

5)如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

测试用例综合设计策略2

• 测试用例的设计步骤

1)构造根据设计规格得出的基本功能测试用例；

2)边界值测试用例；

3)状态转换测试用例；

4)错误猜测测试用例；

5)异常测试用例；

6)性能、安全等专项测试用例；

• 优化测试用例的方法

1)利用设计测试用例的几种常用方法 经验，不断的对测试用例进行分解与合并；

2)在测试时利用发散思维和根据以往测试经验，构造测试用例；

小伙伴看到这，是不是觉得这样写用例写起来很麻烦呢？每次还要画很多的图表之类的，画图表只是一个分析的过程，等熟练之后，在实际工作中，可以根据自己的实际情况忽略某些步骤，只要在最终的测试点中能将这些测试点都考虑进去就行。详细的编写过程只是在初级测试找工作的时候，可能会在笔试题中考到，对相关的概念有个简单的了解就行。

在工作中是如何编写测试用例的？

我们学会了一些用例设计的常用用法，比如等价类、边界值，以及场景法和错误推测法，这些是在日常工作中使用的比较多的方法。那么，学了用例设计方法之后，测试用例到底是什么呢？

测试用例是什么？

测试用例的话，可以理解为是一种针对软件质量的检查规则，经过一系列规则的检查后，最终评估一个软件质量的好坏。（只是自己的一个解释，仅供参考，不要拿来直接去背喔）

测试用例包含哪些要素呢？

经常遇到很多人都在找测试用例的模板，我想说的是，模板其实网上一百度就可以找到一大堆，我们只需要弄清楚一条测试用例里面应该包含哪些内容就可以了，至于模板的格式，可以根据自己的喜好去进行适当调整，一般在公司也都有自己的模板。

以禅道的用例模板为例，一条测试用例一般包含以下这些因素：

所属产品、所属项目、所属模块、用例类型、适用阶段、相关需求链接、用例编号、用例标题、前置条件、操作步骤、用例等级/优先级、预期结果、实际结果、关键词等。（实际结果只有在执行用例的时候才能确定）

用例设计注意事项
1、用例标题要描述清楚测试点，标题不宜过长，并且标题中不能明确体现出执行结果，标题要尽可能的让别人一看就知道这条用例要验证的是哪一个场景

2、用例要设置优先级，类似bug的严重程度一样，用例要区分优先级，标注哪些是冒烟测试的用例，这一部分用例在开发转测的时候，需要冒烟验证通过才能转测。冒烟测试的用例数量不宜过多。

3、用例的预期结果要与操作步骤一一对应，如果操作步骤设计多个步骤时，在预期结果里面要用序号区分分别是第几个步骤对应的预期结果。

4、一条完整的测试用例可能包含很多字段，有些是非必填的，必填字段的话要牢记，初级测试的话在面试的时候很容易被问到。一条用例最起码应该包含用例标题、步骤、预期结果、模块、优先级和类型。至于那些用例编号、关键字之类的根据自己平常写用例的风格可以自己进行斟酌。

在公司中一般用什么编写用例？

在工作中的话，每个公司针对用例的管理都有不同的标准，但归根结底无非就是录入和存储的位置和格式不一致罢了。一般看公司用什么样的缺陷管理系统。常见的缺陷管理系统有：禅道、jira、TAPD等。肯定还有一些其他的系统，这里我没接触过的就不列举了。像禅道和jira上是都支持用例管理的，并且禅道上还支持用例的导入导出以及批量创建等功能。有的公司可能还会自己开发一套测试平台，其中会有单独的模块去写用例等。也有一些测开大佬搭建的平台，直接在线用脑图的形式写用例。

一般具体写用例的话，可以先用脑图列举一下一些常见的测试点，根据需求文档进行测试点的分析和提取，然后再根据脑图，将细化的用例录入平台或者excel中。

用例一般写完之后，需要组织相关人员进行用例的评审，转测后，需要将用例的执行情况进行标注。如果只写用例而不是执行，那用例写了也没什么用。用例的细化程度要测试人员根据公司和项目的实际情况去衡量，比如测试时间短，那就可能没这么多时间写很细致的用例，这个时候可以就用脑图代替。用例的作用主要是提醒测试人员有哪些测试点要注意，避免在测试的时候临时去想测试点，容易造成场景漏测。

希望本文对你有所帮助~~如果对软件测试、接口测试、自动化测试、性能测试、面试经验交流感兴趣可以私聊我或关注公众号“特斯汀软件测试”。免费领取最新软件测试大厂面试资料和Python自动化、接口、框架搭建学习资料！技术大牛解惑答疑，同行一起交流。