编写单元测试用例说明书的依据是啥

Posted 2023-04-13

编写单元测试用例说明书的依据是什么

一、 单元测试的概念

单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。

测试的覆盖种类

1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。

2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。

3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。

4.判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。
5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。

6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。

二、开始测试前的准备

在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。穷举测试是不可能的。所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。

三、开始测试

基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。

函数说明 ：当i_flag=0；返回 i_count+100
当i_flag=1；返回 i_count *10
否则 返回 i_count *20

输入参数：int i_count ，
int i_flag
输出参数： int i_return;

代码：

1 int Test(int i_count, int i_flag)
2
3 int i_temp = 0;
4 while (i_count>0)
5
6 if (0 == i_flag)
7
8 i_temp = i_count + 100;
9 break;
10
11 else
12
13 if (1 == i_flag)
14
15 i_temp = i_temp + 10;
16
17 else
18
19 i_temp = i_temp + 20;
20
21
22 i_count--;
23
24 return i_temp;
25

1.画出程序控制流程图

圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8......作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。让我们看程序中；第2行，第3行是按顺序执行下来的。直到第4行才出现了循环操作。而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。其他的也是照这个规则合并，然后就有了上面的流程图。

2.计算圈复杂度

有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。

这里有有了一个新概念——圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少执行一次的测试数量的上界。
公式圈复杂度V（G）=E+N+2，E是流图中边的数量，N是流图中结点的数量。

公式圈复杂度V（G）=P+1 ，P是流图G中判定结点的数量。

通俗的说圈负责度就是判断单元是不是复杂，是不是好测试的标准。一般来说如果圈复杂度如果大于20就表示这个单元的可测试性不好，太复杂（也许有人觉得无所谓，但是如果你们公司实行了 CMMI5的话，对这个是有规定的）。

从图中我们可以看到，

V（G）=10条边-8结点+2=4
V（G）=3 个判定结点+1=4

上图的圈复杂图是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。

3.导出程序基本路径。

现在我们知道了起码要写4个测试用例，但是怎么设计这4个测试用例？

导出程序基本路径，根据程序基本路径设计测试用例子。

程序基本路径：基本独立路径就是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边。（看起来不好理解，让我们看例子）。
让我们看上面的流程图：从结点4到24有几条路径呢？

1 B（4，24）
2 C，E，J（4，6，8，24）
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
还有吗？？

5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算吗？

不算，为什么？因为上面的4条路径已经包括了所有的边。第5条路径已经不包含没有用过的边了。所有的路径都遍历过了。

好了，现在我们有了4条基本独立路径根据独立路径我们可以设计测试用例。

1 B（4，24）
输入数据：i_flag=0，或者是i_flag<0的某一个值。
预期结果：i_temp=0.

2 C，E，J（4，6，8，24）
输入数据： i_count =1; i_flag=0
预期结果：i_temp=101.

3 C，D，F，H，A，B（4，6，13，15，22，4，24）
输入数据： i_count =1; i_flag=1
预期结果：i_temp=10.

4 C，D，G，I，A，B（4，6，13，19，22，4，24）
输入数据： i_count =1; i_flag=2
预期结果：i_temp=20.

这里的输入数据是有路径和程序推论出来的。而要注意的是预期结果是从函数说明中导出，不能根据程序结构中导出。

为什么这么说？
让我们看程序中的第3行。
int i_temp=0; 假如开发人员一不小心写错了，变成了int i_temp=1; 根据程序导出的预期结果就会是一个错误的值，但是单元测试不出来问题，那单元测试就失去了意义。

有人也许会问这么简单的函数就有4个测试用例，如果还复杂一些的怎么办？上面的测试用例还可以简化吗？答案是可以。

我们来看 路径 1 B（4，24）和 4 C，D，G，I，A，B（4，6，13，19，22，4，24），路径1是路径4的真子集，所以1是可以不必要的。上图的圈复杂度是4。这个结果对我们来说有什么意义呢？它表示我们只要最多4个测试用例就可以达到基本路径覆盖。所以说圈复杂度标示是最多的测试用例个数，不是一定要4个测试用例才可以。不过有一点要申明的是测试用例越简化代表你的测试越少，这样程序的安全性就越低了。

四、完成测试

接下来根据测试用例使用工具测试NUNIT，VS2005都可以。

接下来根据测试结果编写测试报告，测试人，时间，结果，用例，是否通过，格式网上一大把，每个公司的格式也不一样就不说了。 参考技术A 相关的标准，比如GB之类，还有项目的研制要求如研制任务书等，还有具体的测试来源，详细设计文档以及一些其他文档。 参考技术B 详细设计说明

七分钟教会你如何编写一个合格的测试用例

1、测试用例编写依据

测试用例编写应严格根据PRD（产品说明书）

没有PRD应根据与客户的沟通和确认结果编写

开发的技术文档和流程图

2、测试用例的组成元素

【用例编号】测试用例的编号。

【用例等级】测试用例的重要级别，一般核心功能的用例登录即冒烟用例，非核心功能的测试用例但是使用频率高的级别是高，其次是中，使用频率不高功能要求低的级别是低。

【测试模块】一般可以分成功能，性能，安全，兼容，稳定性等。

【测试项目】用例的测试相关的主要功能名称。

【测试点】能够清晰表达测试用例的测试目的和关键测试要素。

【前提条件】需要描述测试所需要处于的外部环境和测试前测试对象及辅助对象所需要处于的状态和配置。需要保证在完成预置条件中所描述的状态和配置以及外部环境后，测试执行的正确性、一致性。

【操作步骤】为了达到测试用例的测试目的，所需要执行的操作；每个操作步骤对应一个预期结果。

【预期结果】针对测试用例的测试目的，测试步骤中操作后对应的预期输出状态。

【实际输出】根据测试用例操作的实际结果。

【结论】测试用例的测试结果，一般分为Pass，Fail，Block（暂时阻塞的功能），N/A（不需要的功能）。

【执行方式】选手动或者自动。

3、测试用例编写规则

1、用例名称要求

（1）包含测试模块和功能点，体现测试要点

（2）不要包括具体操作步骤

（3）简洁明了，一句话能描述出测试点，一般不超出15个字

2、用例重要性要求

（1）高，产品基本的核心功能验证，即关键路径的测试用例，包括最常执行的功能、基本流程的输入（正向流程+正向数据）

（2）中，产品非核心功能验证，包括界面数据有效性校验、默认值、边界值

（3）低，建议执行的测试用例，包括不常执行的功能、异常流程的输入以及异常数据的输入

3、前置条件

测试执行前需准备的相关操作，如测试数据、角色权限，或登入系统某页面等

4、测试步骤要求

（1）用例描述中不允许出现二义性语句

（2）操作和结果是一一对应的，但操作中不要包含结果的检查

（3）用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等

（4）用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）

（5）操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚

5、预期结果要求

（1）结果中只能包含结果，不能有步骤

（2）一个结果有多个检查点时，确保检查点完整

（3）原则上每个用例必需要有预期结果，结果不能为空

（4）结果涉及消息：需明确关键查看内容

（5）结果涉及页面，需明确页面提示结果、数据变化

（6）结果对应不同输入数据有差别时需分别对应描述清晰

（7）结果含需要验证的所有结果输出，如页面检查、存储检查、消息检查等

（8）结果涉及存储：需明确关键值变化、数据库具体的表和关键字字段值变化

4、测试用例设计方法

1、等价类

等价类划分法是把所有可能输入的数据，即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

例如：

我们要测试一个用户名是否合法，用户名的定义：8位数字组成的字符。
我们可以先划分子集：空用户名，1-7位数字，8位数字，9位或以上数字，非数字。
然后从每个子集选出若干个有代表性的值：
空用户名：“” （无效等价类实例，指对于软件规格说明而言，没有意义的、不合理的输入）
1-7位数字：“234” （无效等价类实例）
8位数字：“00000000” （有效等价类实例，能检验程序是否实现了规格说明中所规定的功能和性能）
9位或以上数字：“1234567890” （无效等价类实例）
非数字：“abc&!!!” （无效等价类实例）

2、边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

例如：

假定 X 为整数，10≤X≤100，那么 X 在测试中应该取的边界值为：10，11，99，100。
注：上面只是说边界值，如果是完整的测试，除了边界值外，还需要一个正常值，即12-98之间的任意值。

3、因果图

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

4、判定表

判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

5、正交分解法

从大量的（实验）数据（测试例）中挑选适量的,有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。

6、错误推测法

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

7、场景法

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

---

资源分享【这份资料必须领取~】

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】