软件功能测试指的是根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本文我们为大家介绍软件功能测试的测试流程、测试方法以及会用到的软件测试工具，帮助大家快速建立属于自己的测试体系。

首先我们先为大家介绍一下软件功能测试流程。软件功能测试流程包括任务接收、测试计划制定、测试需求分析、测试用例设计、测试准备、测试执行、测试报告编制这几个环节。

首先是需求分析部分，我们需要对软件产品的整体结构进行分析，以及软件产品的部署环境。还需要对功能的处理进行分析，如输入数据的规格、输入数据的状态、操作权限、业务规则等。在业务流程方面，我们同样需要对流程、数据类型、操作权限、业务规则进行分析。在数据接口方面，我们需要对外部数据接口、数据输出的数据、接口处理的权限以及业务规则进行分析。

从软件产品的八大特性角度我们还可以以这样的思路去提取测试点： 1）对于功能性测试部分，分析系统的功能结构、各功能的界面要素、界面操作、业务流程、业务规则、数据接口等，提取功能测试点；2）对于可靠性测试部分，分析系统功能的数据输入规格要求、业务规则要求等，提取可靠性测试点；3）对于易用性测试部分，分析系统功能操作的帮助信息、演示功能，会引起严重后果的关键功能操作等，提取易用性测试点。

需求分析之后的环节是测试用例的设计环节。众所周知，测试用例设计是最能体现测试工程师水平的一个环节，也是功能测试的灵魂所在。正确、全面的软件测试用例是测试执行正确、有效和完整的重要保障，因此该环节也是整个软件功能测试的一个核心环节。下面我们就详细为大家介绍一下，功能测试用例设计的方法。

等价类划分法

等价类划分法是指依据需求对输入的范围进行分类，然后在分出的每一个区域内选取一个有代表性的测试数据开展测试。等价类划分法是比较容易理解的，我们现在设计测试用例用等价类划分法比较多，它适用的场景也比较多。它适合于任何一个测试过程，不受局限。等价类是指某个输入域的子集合。分为有效等价类和无效等价类。

有效等价类 : 符合需求说明，合理地输入数据集合
无效等价类 : 不符合需求说明，无意义地输入数据集合
我们也可以把无效等价类看作反向用例，也可以看作在健壮性测试时我们设计的一个测试用例。有效等价类是用来验证需求的，无效等价类是用来经受考验的。

（需要详细的方法介绍、步骤和案例可在我的功能测试专栏中查看）

边界值分析（boundary value analysis）

接下来我们来介绍一下第二大常用的方法，边界值分析法。由于程序的错误经常在定义域和等价类的边界处被发现，所以在等价类分析还应该对于每个测试的变量加上边界值的分析。一般情况下我们会设计5组边界值，取一个中间值，一个最小值，一个最大值，一个略小于最小值，一个略大于最大值。

如何设计边界值测试用例：
首先确定边界情况，通常输入或输出等价类的边界就是应该着重测试的边界情况。
正常选取（正向）：最小值、略高于最小值、正常值、略低于最大值和最大值处变量值。
健壮性测试（反向）：还需考虑小于最小值，大于最大值
例如，在某程序的需求规格说明中，对输入条件的限制为：
“…… 年龄可以输入从15到60的整数 ……”
边界值正常用例分析：输入应选择15、16、30、59、60

同时我们还要考虑它的健壮性或者容错性，就需要设置健壮测试（反向用例），一个是小于最小值，一个是大于最大值，所以输入还需考虑：14、61

常见的边界值：
并不是所有的值都需要考虑边界值，通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、质量、大小、速度、方位、尺寸、空间等。
相应的，以上类型的边界值应该在：
最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最长/最短、空和满等情况
一旦我们的需求说明书里对这些方面有相关的描述的时候，就一定要考虑，这个时候是不是需要增加边界值的测试。
（需要详细的方法介绍、步骤和案例可在我的功能测试专栏中查看）

错误推测法

错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。带有破坏性的输入错误的值或方法去进行测试，如果程序要求输入数字，那么我们就输入特殊字符，如果软件只接受正数，我们就输入负数。
例如：输入数据和输出数据为0的情况；
           输入表格为空格
           输入超长字符
           删除全部数据或记录为空的情况
          ......
这个方法没有太大的规律，就是靠经验和直觉，我们做测试工作时间长了，就可以积累出这方面的能力了。

例如：如对某个公司的销售工作人员某一天的销售额进行排序。可推测列出以下几项需要特别的测试的情况：
分析：
当天所有销售工作人员均无销售额；
当天所有销售工作人员只有一人有销售额；
当天所有销售工作人员的销售额均相同；
当天销售额均已升序排列好；
当天销售额均已降序排列好。

因果图法

这种方法是有适用条件的，不是所有的场景都可以用这种方法的。它是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。等价类划分方法和边界值分析方法，都未过多考虑输入条件之间的联系，相互组合、相互制约等。

考虑输入条件间的相互组合不是一件易事, 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（ Cause一Effect Graphics ）方法。

采用因果图方法能够帮助我们按一定步骤，高效率地选择测试用例，同时还能为我们指出，程序规格说明描述中存在着什么问题。

（需要详细的方法介绍、步骤和案例可在我的功能测试专栏中查看）

场景法

场景法也就是事件流，现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。流，是指一系列的步骤。

一般情况下我们会分基本流和备选流，所谓的基本流是能够顺利执行的一个场景，从开始到结束一切都顺利的场景。备选流是指除基本流之外的另外一些正常场景、偶尔发生的场景、异常或错误处理。

基本流和备选流如下图所示：

图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。

备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

（需要详细的方法介绍、步骤和案例可在我的功能测试专栏中查看）

测试用例设计完成后，便是测试数据的准备环节，需要按照设计的测试用例，准备各种类型的数据、各种状态的数据以及各种角色的用户，以备测试时使用。

测试数据准备完毕后，就进入了测试执行环节。测试执行环节主要是依据我们前面设计好的测试用例执行测试。在接口测试的部分，我们可以借助相应的软件测试工具去执行。通常比较常用到的有Postman、SoapUI 、Fiddler等。最后参照测试模版，编制软件功能测试报告，整个流程就完成了。

以上内容就是我们为大家分享的软件功能测试流程和方法以及可能会用到的软件测试工具的全部内容，如需测试模版、操作案例等内容可私信我获取。