精华内容
下载资源
问答
  • 2021-07-25 01:21:43

    1、单元测试的基本方法

    单元测试的基本方法有:人工静态分析、自动静态分析、自动动态测试,人工动态测试。

    人工静态分析:通过人工阅读代码来查找错误,一般是程序员交叉查看对方的代码,可能发现有特征错误和无特征错误。

    自动静态分析:使用工具扫描代码,根据某些预先设定的错误特征,发现并报告代码中的可能错误,自动静态分析只能发现语法特征错误。

    自动动态测试:使用工具自动生成测试用例并执行被测试程序,通过捕捉某些行为特征(如产生异常/程序崩溃等)来发现并报告错误,自动动态测试只能发现行为特征错误,对无特征错误完全无能为力,例如,前面所说的加法函数,代码可以说是最简单的,错误也是最简单的,但是自动动态测试仍然无法发现,因为测试工具不可能自动了解代码的功能。

    人工动态测试:人工设定程序的输入和预期的正确输出,执行程序,并判断实际输出是否符合预期,如果不符合预期,自动报告错误。这里所说的"人工",仅指测试用例的输入和预期输出是人工设定的,其他工作可以由人工完成,也可以借助工具自动完成。人工动态测试可以发现有特征错误和无特征错误,例如,前面所说的加法函数,只要人工建立一个测试用例,输入两个1,并判断输出是否等于2,运行测试,就可以发现代码中含有错误。

    以上四种方法还可以进一步细分,例如,人工动态测试又有多种设计测试用例的方法,如果根据程序的功能来设计测试用例,就是黑盒测试,如果根据代码及代码的逻辑结构来设计测试用例,就是白盒测试。

    2、测试方法的选择

    工作中是不是把各种测试方法不分轻重都做一遍呢?显然不行,项目工期和预算不会允许这么做,也不符合效益原则,应该选择一种方法作为主要测试方法,其他视情况取舍。

    自动静态分析、自动动态测试只能发现有特征错误,这两种方法加起来,做到最好也仅限于发现有特征错误,而多数语法特征错误编译器就能发现,很多行为特征错误会在开发过 程中,或集成测试和系统测试中自动暴露出来,所以这两种方法不宜作为主要测试方法。

    人工静态分析虽然可能发现有特征错误和无特征错误,但是要彻底找出所有错误来,显然太难了。

    人工动态测试可以发现有特征错误和无特征错误,并且具有广阔的发挥空间,可以作为主要测试方法。

    3、黑盒测试与白盒测试

    常常见到"单元测试是白盒测试","单元测试也有黑盒"之类的说法,容易引起混乱。黑盒与白盒其实是测试方法,黑盒就是针对系统的外部特性进行测试,把目标系统看作一个黑盒子,不考虑内部结构;白盒就是针对系统的内部结构进行测试。各个测试阶段都可以使用黑盒方法和白盒方法,即无论是单元测试、集成测试、系统测试阶段都可以使用黑盒方法和白盒方法。

    黑盒测试又叫功能测试,我们首先要测试程序是否实现了基本功能,因此,黑盒测试是基本测试。黑盒测试的主要缺陷是难于衡量完整性,而白盒测试正好可以弥补个缺陷。

    白盒测试通过逻辑覆盖率来衡量完整性,具有可以精确统计的数字指标。逻辑单位主要有:语句、分支、条件、条件值、条件值组合,路径。语句覆盖就是覆盖所有的语句,其他类推。另外还有一种判定条件覆盖,其实是分支覆盖与条件覆盖的组合。跟条件有关的覆盖就有三种,解释一下:条件覆盖是指覆盖所有的条件表达式,即所有的条件表达式都至少计算一次,不考虑计算结果;条件值覆盖是指覆盖条件的所有可能取值,即每个条件的取真值和取假值都要至少计算一次;条件值组合覆盖是指覆盖所有条件取值的所有可能组合。与条件直接有关的错误主要是逻辑操作符错误,例如:||写成&&,漏了写!什么的,采用分支覆盖与条件覆盖的组合,基本上可以发现这些错误,而条件值覆盖与条件值组合覆盖往往需要大量的测试用例,因此,条件值覆盖和条件值组合覆盖的效费比偏低,比较有价值的覆盖率是语句覆盖、条件覆盖、分支覆盖、路径覆盖。

    4、测试用例

    人工动态测试需要人工设计测试用例。一个测试用例,就是设定输入数据,执行被测试程序,并判断输出是否符合预期。输出符合预期,则测试通过,否则测试失败。一般来说,测试工具要能自动报告失败的测试。

    测试用例的主要内容是输入数据和预期输出,简称输入输出,其中输入是核心,输入确定了,再根据程序的功能设定预期的正确输出。

    如果我们把函数看作测试单元,那么,输入数据就是被测试函数所读取的外部数据及这些数据的初始值。"外部数据"是对于被测试函数来说的,就是除了局部变量以外的其他数据,分为几类:参数、成员变量、全局变量、IO媒体。IO媒体是指文件、数据库或其他储存或传输数据的媒体,例如,被测试函数要从文件或数据库读取数据,那么,文件或数据库中的原始数据也属于输入数据。

    31/3123>

    更多相关内容
  • 在这篇文章中,我们将讲解白盒测试的基本概念,以及四大常用的白盒测试方法

     在这篇文章中,我们将讲解白盒测试的基本概念,以及四大常用的白盒测试方法

    一、白盒测试基本概念

    1、白盒测试的定义

    白盒测试又称为结构测试逻辑驱动测试,它是把测试对象看成一个透明的盒子,它允许测试人员利用程序内部的逻辑结构设计测试用例,对程序所有逻辑路径进行测试。

    2、白盒测试的测试对象

    白盒测试的测试对象是基于被测试程序的源代码,而不是软件的需求规格说明书。

    使用白盒测试方法时,测试人员必须全面了解程序内部逻辑结构,检查程序的内部结构,从检查程序的逻辑着手,对相关的逻辑路径进行测试,最后得出测试结果。

    3、白盒测试的原则

    采用白盒测试方法必须遵循以下原则:

    • 保证一个模块中的所有独立路径至少被测试一次

    • 对所有的逻辑判定均需测试取真和取假两种情况。

    • 在上下边界及可操作范围内运行所有循环。

    • 检查程序的内部数据结构,保证其结构的有效性。

    4、白盒测试的分类

    白盒测试方法有两大类:静态测试方法动态测试方法

    静态测试 不要求在计算机上实际执行所测试的程序,主要以一些人工的模拟技术对软件进行分析和测试,如代码检查法静态结构分析法等;

    动态测试 是通过输入一组预先按照一定的测试准则构造实际数据来动态运行程序,达到发现程序错误的过程。白盒测试中的动态分析技术主要有逻辑覆盖法基本路径测试法。( ★ ★ ★

    下面将对两种白盒测试方法进行讲解。

    二、静态白盒测试

    1、代码检查法

    (1)代码审查的定义

    代码审查(Code Review)是指对计算机源代码进行系统地审查,找出并修正在软件开发初期未发现的错误,提升软件质量及开发者的技术。

    (2)代码审查的目的

    代码审查的目的是为了产生合格的代码检查源程序编码是否符合详细设计的编码规定,确保编码与设计的一致性和可追踪性。

    (3)代码审查的方法

    代码审查包括桌面检查代码审查走查

    1)桌面检查(程序员自己检查)

    这是一种传统的检查方法,由程序员检查自己编写的程序。程序员在程序通过编译之后,对源程序代码进行分析、检查,并补充相关的文档,目的是发现程序中的错误。

    2)代码审查(审查小组通过读程序和对照错误检查表进行检查)

    代码审查是由若干程序员测试员组成一个审查小组,通过阅读、讨论和争议,对程序进行静态分析的过程。具体过程如下

    第一步, 小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员,作为审查的依据。小组成员在充分阅读这些材料后,进入审查的下一步。

    第二步,召开程序审查会。 每个成员将所发材料作为审查依据,但是由程序员讲解程序的结构、逻辑和源程序。在此过程中,小组成员可以提出自己的疑问;程序员在讲解自己的程序时,也能发现自己原来没有注意到的问题。

    注意: 在进行代码检查前应准备好需求文档、程序设计文档、程序的源代码清单、代码编码标准、代码缺陷检查表和流程图等。

    3)走查 (审查小组需要准备有代表性的测试用例沿程序逻辑运行)

    走查与代码审查基本相同,其过程分为两步:

    第一步: 把材料先发给走查小组每个成员,让他们认真研究程序。

    第二步: 开会。

    与代码审查不同的是,让审查小组成员“充当”计算机,即首先由测试组成员为所测程序准备一批有代表性的测试用例,提交给走查小组。走查小组开会,集体扮演计算机角色,让测试用例沿着程序的逻辑运行一遍,随时记录程序的踪迹,提供给最后阶段的分析和讨论使用。

    (4)代码检查规则

    在代码检查中,需要依据被测试软件的特点,选用适当的标准规则规范

    (5)代码检查项目

    • 目录文件组织

    • 检查函数

    • 数据类型及变量

    • 检查条件判断语句

    • 检查循环体制

    • 检查代码注释

    • 桌面检查

    • 其他检查

    2、静态结构分析法

    (1)定义

    在静态结构分析法中,测试人员通常通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构,生成函数调用关系图模块控制流图内部文件调用关系图等各种图形、图表,清晰地标识整个软件的组成结构。

    (2)目的

    通过分析这些图表,包括控制流分析、数据流分析、接口分析、表达式分析等,使其便于阅读与理解,然后可以通过分析这些图表,检查软件有没有存在缺陷或错误。

    (3)静态结构分析的两种方法

    1)通过生成各种图表,来帮助对源程序的静态分析

    常用的各种引用表主要有: 标号交叉引用表;变量交叉引用表;子程序(宏、函数)引用表; 等价表;常数表。

    常用的各种关系图、控制流图主要有:

    ①函数调用关系图: 列出所有函数,用连线表示调用关系,通过应用程序各函数之间的调用关系展示了系统的结构。

    ②模块控制流图:许多结点和连接结点的边组成的图形,其中每个结点代表一条或多条语句,边表示节点间的控制流向,用于显示函数的内部逻辑结构。★ ★ ★

    2) 错误静态分析

    静态错误分析主要用于确定在源程序中是否有某类错误或“危险”结构

    ①类型和单位分析: 数据类型的错误和单位上的不一致。

    ②引用分析: 引用异常,变量赋值先引用,或赋值未引用。

    ③表达式分析: 表达式错误,不正确使用括号,数组下标越界等。

    ④接口分析: 模块的接口,参数的一致性。

    三、动态白盒测试

    1、逻辑覆盖法

    (1)定义

    逻辑覆盖是以程序内部的逻辑结构为基础来设计测试用例的测试技术,通过对程序内部的逻辑结构的遍历来实现程序的覆盖。它属于白盒测试中动态测试技术之一。

    (2)6种逻辑覆盖方法

    从覆盖源程序语句的详尽程度分析,逻辑覆盖包括以下6种覆盖标准:

    • 语句覆盖(SC);

    • 判定覆盖(DC);

    • 条件覆盖(CC);

    • 判定-条件覆盖(CDC);

    • 条件组合覆盖(MCC);

    • 路径覆盖。

    接下来将对这6种逻辑覆盖方法进行一一讲解。

    1)语句覆盖(SC)

    ①定义: 语句覆盖(Statement Coverage)的含义就是设计足够的测试用例,使得被测程序中每条语句至少执行一次。又称行覆盖、段覆盖、基本块覆盖,它是最常见的覆盖方式。

    ②例子展示🌰

    Question:

    如下java语言程序语句和对应的程序流程图:

    public class Test{
        public void Test1(int x,int y,int z){
            if(y>1 && z==0){
                x=(int)(x/y)
            }
            if(y==2 || x>1){
                x=x+1
            }
        }
    }

    请使用语句覆盖来为该程序设计测试用例。

    Answer:

    为了使每条语句都能够至少执行一次,我们可以构造以下测试用例:

    输入: x=4 , y=2 , z=0

    执行路径为:sacbed

    语句覆盖虽然可以测试执行语句是否被执行到,但却无法测试程序中存在的逻辑错误。因此,语句覆盖是一种弱覆盖

    例如,如果上述程序中的第一个逻辑判断符号 “&&” 误写了 “||” ,使用测试用例同样可以覆盖 sacbed 路径上的全部执行语句,但却无法发现错误。同样,如果第二个逻辑判断符号 “||” 误写了 “&&” ,使用同样的测试用例也可以执行 sacbed 路径上的全部执行语句,但却无法发现上述逻辑错误。

    ③语句覆盖的目的:

    语句覆盖的目的是测试程序中的代码是否被执行,它只测试代码中的执行语句,这里的执行语句不包括头文件、注释、空行等。

    语句覆盖在多分支的程序中,只能覆盖某一条路径,使得该路径中的每一个语句至少被执行一次,但不会考虑各种分支组合情况

    2)判定覆盖(DC)

    ①定义:

    • 判定覆盖(Decision Coverage)又称为分支覆盖,其原则是设计足够的测试用例,使得程序中每个判定语句的取真和取假分支至少被执行一次

    • 除了双值的判定语句外,还有多值判定语句,如case语句,因此判定覆盖更一般的含义是:使得每一个判定获得每一种可能的结果至少一次

    ②例子展示🌰

    Question:

    如下java语言程序语句和对应的程序流程图:

    public class Test{
        public void Test2(int x,int y,int z){
            if(y>1 && z==0){
                x=(int)(x/y)
            }
            if(y==2 || x>1){
                x=x+1
            }
        }
    }

    请使用判定覆盖来为该程序设计测试用例。

    Answer:

    以上述代码为例,构造以下测试用例即可实现判定覆盖标准:

    输入:① x=1,y=3,z=0 ,执行路径为 sacbd

    (判断的结果分别为T,F

    输入:② x=3,y=1,z=1 ,执行路径为 sabed

    (判断的结果分别为F,T

    上述两组测试用例不仅满足了判定覆盖,而且满足了语句覆盖,从这一点可以看出判定覆盖比语句覆盖更强一些。所以只要满足了判定覆盖就一定满足语句覆盖,反之则不然

    判定覆盖仍然具有和语句覆盖一样无法发现逻辑判断符号 “&&” 误写了 “||” 的逻辑错误。

    判定覆盖仅仅判断判定语句执行的最终结果而忽略每个条件的取值,所以也属于弱覆盖

    3)条件覆盖(CC)

    ①定义:

    条件覆盖(Condition Coverage)指的是设计足够的测试用例,使判定语句中的每个逻辑条件取真值与取假值至少出现一次

    例如,对于判定语句 if(a>1 OR c<0) 中存在 a>1、c<0 两个逻辑条件,设计条件覆盖测试用例时,要保证 a>1、c<0 的“真”、“假”值至少出现一次。

    ②例子展示🌰

    Question:

    如下java语言程序语句和对应的程序流程图:

    public class Test{
        public void Test3(int x,int y,int z){
            if(y>1 && z==0){
                x=(int)(x/y)
            if(y==2 || x>1){
                x=x+1
            }
        }
    }

    请使用条件覆盖来为该程序设计测试用例。

    Answer:

    要使程序中每个判断的每个条件都至少取真值、假值一次,我们可以构造以下测试用例:

    输入:① x=1,y=2,z=0 ,执行路径为 sacbed

    (条件的结果分别为TTTF

    输入:② x=2,y=1,z=1 ,执行路径为 sabed

    (条件的结果分别为FFFT

    从条件覆盖的测试用例可知,使用2个测试用例就达到了使每个逻辑条件取真值与取假值都至少出现了一次,但从测试用例的执行路径来看,条件分支覆盖的状态下仍旧不能满足判定覆盖,即没有覆盖 bd 这条路径。相比于语句覆盖与判定覆盖,条件覆盖达到了逻辑条件的最大覆盖率,但却不能保证判定覆盖。

    4)判定-条件覆盖(CDC)

    ①定义:

    • 要求设计足够的测试用例,使得判定语句中所有条件的可能取值至少出现一次,同时,所有判定语句的可能结果也至少出现一次

    • 例如,对于判定语句 if(a>1 AND c<1) ,该判定语句有 a>1、c<1 两个条件,则在设计测试用例时,要保证 a>1、c<1 两个条件取“真”、“假”值至少一次,同时,判定语句 if(a>1 AND c<1) 取“真”、“假”也至少出现一次。

    ②例子展示🌰

    Question:

    如下java语言程序语句和对应的程序流程图:

    public class Test{
        public void Test3(int x,int y,int z){
            if(y>1 && z==0){
                x=(int)(x/y)
            }
            if(y==2 || x>1){
                x=x+1
            }
        }
    }

    请使用判定条件覆盖来为该程序设计测试用例。

    Answer:

    为满足判定-条件覆盖原则,我们可以构造以下测试用例:

    输入:① x=4,y=2,z=0 ,覆盖路径:sacbed

    (判断的结果分别为TT,条件的结果分别为:TTTT

    输入:② x=1,y=1,z=1 ,覆盖路径:sabd

    (判断的结果分别为FF,条件的结果分别为:FFFF

    判定-条件覆盖满足了判定覆盖准则条件覆盖准则,弥补了二者的不足。但是判定-条件覆盖不一定比条件覆盖的逻辑更强。

    ③判定-条件覆盖的缺点: 没有考虑条件的组合情况。

    5)条件组合覆盖(MCC)

    ①定义:

    条件组合(Multiple Condition Coverage)指的是设计足够的测试用例,使得每个判定中条件的各种可能组合都至少执行一次。满足了判定覆盖、条件覆盖、判定-条件覆盖准则。

    ②例子展示🌰

    Question:

    如下java语言程序语句和对应的程序流程图:

    public class Test{
        public void Test4(int x,int y,int z){
            if(y>1 && z==0){
                x=(int)(x/y)
            }
            if(y==2 || x>1){
                x=x+1
            }
        }
    }

    请使用条件组合覆盖来为该程序设计测试用例。

    Answer:

    为满足条件组合覆盖原则,我们可以构造以下测试用例:

    输入:① x=4,y=2,z=0 ,覆盖路径: sacbed (条件的结果分别为:TTTT

    输入: ② x=1,y=2,z=1,覆盖路径: sabed (条件的结果分别为:TFTF

    输入:③ x=2,y=1,z=0 ,覆盖路径: sabed (条件的结果分别为:FTFT

    输入: ④ x=1,y=1,z=1,覆盖路径: sabd (条件的结果分别为:FFFF

    由于这4个条件每个条件都有取“真”、“假”两个值,因此所有条件结果的组合有2^{4}=16种。但是,当一个程序中判定语句较多时,其条件取值的组合数目也较多。需要设计的测试用例也会增加,这样反而会使测试效率降低。

    6)路径覆盖

    ①定义:

    路径覆盖指的是设计足够的测试用例,使得程序中的每一条可能组合的路径都至少执行一次

    ②例子展示🌰

    Question:

    如下java语言程序语句和对应的程序流程图:

    public class Test{
        public void Test5(int x,int y,int z){
            if(y>1 && z==0){
                x=(int)(x/y)
            }
            if(y==2 || x>1){
                x=x+1
            }
        }
    }

    请使用路径覆盖来为该程序设计测试用例。

    Answer:

    为满足路径覆盖原则,我们可以构造以下测试用例:

    输入:① x=4,y=2,z=0 ,覆盖路径:sacbed

    (判定的结果分别为:TT

    输入:② x=1,y=2,z=1,覆盖路径: sabed

    (判定的结果分别为:FT

    输入:③ x=1,y=3,z=0 ,覆盖路径: sacbd

    (判定的结果分别为:TF

    输入:④ x=1,y=1,z=1 ,覆盖路径: sabd

    (判定的结果分别为:FF

    2、基本路径测试法

    (1)独立路径

    独立路径是指包括一组以前没有处理的的语句或条件的一条路径。

    从控制流图来看,一条独立路径是至少包含一条在其他独立路径中从未有过的边的路径。

    (2)程序控制流图

    1)程序控制流图的定义

    控制流程图是描述程序控制流的一种图示方式。(有向图)

    2)控制流图的两种图形符号

    • 图中的每一个圆圈称为流图的结点,表示一个或多个无分支的语句或源程序语句。

    • 流图中的箭头称为边或连接,表示控制流线。

    3)程序控制流图的5种基本结构

    4)程序控制流图的描述

    • 程序控制流图实际上可以看作是一种简化了的程序流程图。

    • 在控制流图中,只关注程序的流程,不关心各个处理框的细节

    • 因此,原来程序流程图中的各个处理框(包括语句框、判断框、输入/输出框等)都被简化为结点,一般用圆圈表示,而原来程序流程图中的带有箭头的控制流变成了控制流图中的有向边

    5)举个栗子🌰

    下图是典型的程序流程图转换为相对应的流图。对(a)图所示的程序流程图进行简化,得到(b)图所示的流图。

     6)注意事项

    在将程序流程图简化成控制流图时,应注意如下几点:

    • 一组顺序结构可以映射为一个单一的结点

    • 在选择多分支结构中分支的汇集处时,即使没有执行语句也应该添加一个汇聚结点

    • 边和结点圈定的范围叫做区域,当对区域计数时,图形外的区域也应记为一个区域(开放区域)

    • 如果判断中的条件表达式是由多个逻辑运算符(OR,AND…)连接的复合条件表达式,则需要改为一系列只有单个条件的嵌套的判断

    (3)软件复杂度

    • 软件复杂度是指理解和处理软件的难易程度。

    • 程序复杂度是软件度量的重要组成部分

    • 度量方法: McCabe 度量法(环路度量)

    (4)程序复杂度

    环路复杂度又称为圈复杂度,是一种为程序逻辑复杂度提供定量尺度的软件度量。它可以提供程序基本路径集的独立路径数量,这是确保所有语句至少执行一次的过程所必须的最少测试用例数。常用于基本路径测试法

    (5)环路复杂度

    McCabe 复杂性度量方式有如下三种:

    ⭐️⭐️⭐️

     1)通过控制流图的区域个数来计算

    公式:V(G)=区域数

    程序的环路复杂性为控制流图的区域数(即封闭的区域数+1)。

    在下图中可以看到,有 12 两个封闭区域,因此,环路复杂度V(G)=2 + 1 = 3。

    (2个封闭的区域+1个开放区域) 

    2)通过控制流图的边数和结点数来计算

    公式:V(G) = e - n + 2

    其中, eedge ,表示图中边的数目nnode ,表示结点个数

    下图中V(G)= e - n + 2 = 7条边 − 6个结点 + 2 = 3。

    因此,环路复杂度V(G)=3。

     3)通过控制流图中的判定结点个数来计算

    公式:V(G) = P + 1

    其中,P表示判定结点的数目。所谓判定节点数,即有多个分支的节点,比如下图中的节点 2 ,它可以走3或者5,这个时候它就需要做判断了。所以, 2 是一个判定节点。同样地,下面的 节点3 也像节点 2 一样分析。

    因此,图中V(G)=2个判定结点+1 = 3,所以环路复杂度为3。

    讲到这里,我们来给环路复杂性做个小结。事实上,程序的环路复杂性给出了程序基本路径集中的独立路径条数,这是确保可执行语句至少执行一次所必需的测试用例数目的上界。

    通过对以上三个例子的了解,相信大家对环路复杂度的三种求解方式有了一个新的认识。有了上面一系列内容的铺垫,我们来开始讲解基本路径测试法

    (6)基本路径测试法

    1)基本路径测试法是什么

    路径测试就是从一个程序的入口开始,执行所经历的各个语句的完整过程。从广义的角度讲,任何有关路径分析的测试都可以被称为路径测试

    完成路径测试的理想情况就是做到路径覆盖,但对于复杂性较大的程序要做到所有的路径覆盖(测试所有可执行路径)是不可能的。

    在不能做到所有路径覆盖的情况下,如果某一程序的每一个独立路径都被执行到,那么就可以认为程序中的每个语句都已经检验过了,即达到了语句覆盖。这种测试方法就是通常所说的基路径测试法

    基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径的集合,从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

    2)基本路径测试法的4个步骤

    基本路径测试法包括以下4个步骤:

    • 详细设计源代码作为基础,绘制程序的控制流图

    • 计算得到的控制流图G的环路复杂性V(G)

    • 确定独立路径的集合。通过程序控制流图导出基本路径集,列出程序的独立路径。所谓独立路径,是指至少包含一条新边的路径,也就是包含一些前面的路径未包含的语句,当所有的语句都包含了,基路径集就够了。(线性无关路径)

    • 设计测试用例,确保基本路径集中每条路径的执行。

    3)例子阐述1 🌰

    依据以下代码,用基本路径测试法,设计该程序的测试用例。

    if(a>8 && b>10)   //1,2
        m=m+1;       //3
    if(a=10 || c>5)  //4,5
       m=m+5;       //6
    解答:

    ①绘制程序控制流图,如下图所示。

    ②计算环路复杂度

    V(G)=4(3个封闭区域+1个开放区域)

    ③确定线性无关路径:

    路径1:1、4、6

    路径2:1、4、5、6

    路径3:1、2、4、5、6

    路径4:1、2、3、4、5、6

    ④设计测试用例

    编号输入数据预期输出覆盖路径
    1a=2,b=3,c=4m=01、4、6
    2a=2,b=3,c=8m=51、4、5、6
    3a=10,b=6,c=8m=51、2、4、5、6
    4a=10,b=15,c=8m=61、2、3、4、5、6

    4)例子阐述2 🌰

    依据以下代码,用基本路径测试法,设计该程序的测试用例。

    class Test{
        static void permute_args(int panonopt_start, int panonopt_end, int opt_eng, int ncycle){
            int cstart, cycle, i, j, nnonopts, nopts, pos; //1
        
            nnonopts = panonopt_end - panonopt_start;
            nopts = opt_end - panonopt_end;
            cyclelen = (opt_end - panonopt_start)/ncycle;
        
            for(i = 0; i < ncycle; i++){ //2
                cstart = panonopt_end + i; //3
                pos = cstart;
                for(j = 0; j < cyclelen; j++){ //4
                    if(pos >= panonopt_end){ //5
                        pos -= nnonopts; //6
                    }else{
                        pos += nopts; //7
                    }
                }
            }
        } //8
    }

    【问题1】请针对上述java程序给出满足100%DC(判定覆盖)所需的逻辑条件。

    【问题2】请画出上述程序的控制流图,并计算其控制流图的环路复杂度V(G)。

    【问题3】请给出问题2种控制流图的线性无关路径。

    解答:

    【问题1】

    满足100%判定的逻辑条件为:

    i<ncycle;
    i>=ncycle;
    j<cyclelen;
    j>=yclelen;
    pos>=panonopt_end;
    pos<panonopt_end; 

    【问题2】

    控制流图如下图所示,V(G)=4。

     【问题3】

    线性无关路径:

    路径1:1、2、8

    路径2:1、2、3、4、2…

    路径3:1、2、3、4、5、6、4…

    路径4:1、2、3、4、5、7、4…

    四、写在最后

            对于软件测试中的白盒测试来说,主要需要了解白盒测试的基本概念,静态和动态白盒测试的方法,内容较黑盒测试来说逻辑性会更强一些。同时,值得注意的是,在动态测试中的基本路径测试法中,线性无关路径的识别要尤为小心,在计算过程中很容易出现多写的问题。因此,在此基础上,大家可以再多找几道相关的题目进行练习,举一反三。

    展开全文
  • 探索式测试方法的实践

    千次阅读 2021-09-08 09:14:02
    经过长期的发展,软件测试方法不断完善,探索式测试方法也是其中的一种。本文将结合实际工作谈谈对探索式测试方法的理解。 任何一个软件公司发布的产品都有缺陷,所以软件测试是产品开发过程中必不可少的一部分...

    作者:中国移动云能力中心  ——周煜澄

    概要:任何一个软件公司发布的产品都有缺陷,所以软件测试是产品开发过程中必不可少的一部分。经过长期的发展,软件测试方法不断完善,探索式测试方法也是其中的一种。本文将结合实际工作谈谈对探索式测试方法的理解。

        任何一个软件公司发布的产品都有缺陷,所以软件测试是产品开发过程中必不可少的一部分。经过长期的发展,软件测试方法不断完善,探索式测试方法也是其中的一种。本文将结合实际工作谈谈对探索式测试方法的理解。

        探索式测试方法主要分为两类:局部探索式测试法针对测试人员在运行任何一个测试用例时所需要作出的细微决定;全局探索式测试法针对测试人员在编制测试计划和测试用例设计时所需要考虑的广泛的战略性问题。 

    一、局部探索式测试法 

    1、输入:合法输入、非法输入
          1)输入筛选器
          第一,开发是否正确的实现了该功能?
          第二,是否可以绕过屏蔽器?或者当输入值进入系统后还可以修改?
          2)输入检查
          测试时必须仔细阅读每一条错误信息,检查该信息是否写错了,错误信息还可以透漏开发编程时的一些想法。
          3)异常处理
          如果测试看到一个通用出错信息,建议测试再反复测试同一段函数,继续使用刚才引发异常的输入数据,或稍微修改一下,看看会不会导致出错。尝试运行其他一些要调用该函数的测试用例,看看会发生什么情况。
          4)常规输入和非常规输入
          例如:和Ctrl、Alt、Esc按键组合的字符,操作系统、编程语言、浏览器和运行时环境的特定保留词或按键。
          5)使用输出来指导输入选择
          ①首先确定希望程序产生的输出结果,然后考察所有用户场景,来确定输入;
          ②先观察输出结果,再选择新的输入,使新的输出为重新计算后的结果。
    2、状态
          软件的一个状态就是状态空间中的一个点,它由所有内部数据结构的取值来唯一确定。
          ①使用状态信息来帮助寻找相关的输入,如果两个或更多个输入在某种程度上关联,那么它们应该放在一起测;
          ②使用状态信息来辨识重要的输入序列,当一个输入导致状态信息被更新时,紧接着再多次使用同样的输入会导致一连串的状态变化。
          例如,对数据库中的表进行多次更新,查看数据是否会溢出。
    3、代码路径
          测试需明确知道代码的所有选择结构,并理解哪些输入会导致软件走这条分支而不走另一条。
    4、用户数据
         ①如何模仿真实的用户数据
         ②使用真实的用户数据时,应考虑如何解决“隐私问题”。
    5、执行环境
         是指测试使用的操作系统及其当前的配置,还包括运行在同一操作系统上会和被测试软件进行交互的其他一些应用程序,以及会间接或直接影响被测试软件本身或影响被测试软件运行的任何驱动程序、代码、文件、设置等,还包括软件当前连接的网络情况、网络的可用带宽、性能等。

    二、全局探索式测试法(漫游测试)

        在软件测试中,我们可以把整个测试过程比喻成游客在城市中旅游的过程,测试类型对应城市中的不同区域,针对每个区域制定不同的游览路线。以下将结合实际测试过程中的案例,来简单阐述全局探索式测试法的应用。
    1、商业区测试类型(软件的重要功能模块)
        1)指南测试法:
        测试严格遵照用户手册的建议执行操作。在测试一个全新的软件之前,测试人员需要详细阅读需求文档或使用手册,积极与开发人员沟通以充分了解产品功能;在测试产品的新版本之前,查看jira中的新特性描述、新的需求文档以及之前版本存在bug的用例。
        2)地标测试法:
    通过指南测试法确定关键的软件特性(地标),再确定地标的前后顺序,然后从一个地标执行到另一个地标来探索应用程序,直到访问了所有的地标。在这个过程中,需要记录已经使用过哪些地标。
        例如,在BC-ETL的某次测试过程中,需要测试数据流中的多个流程,此时每个流程都作为一个地标,通过多次调换、添加或删除流程的来测试整个数据流能否顺利执行。

        3)极限测试法
        也称找麻烦测试法,即故意设置各种障碍来观察软件如何反应。
        例如,在罗网项目某次迭代中,测试基站查询模块,选择使用基站名称查询,在搜索框中输入覆盖范围很大的区域名称(如:南通)进行查询,页面因加载时间过长导致卡死。

         4)深夜测试法:当下班之后软件执行各种维护任务,将数据归档,备份文件等,程序不自动执行的时候,测试人员强制程序执行。
    2、历史区测试类型
        历史区:指遗留的代码,或是在前几个版本就已经存在的软件特性,也指那些用于修复已知bug的代码。
        1)恶邻测试法:某个区域代码bug很多,建议对邻近区域进行详细的测试,以此来验证那些修复已知bug的代码没有引入新的缺陷。
        2)博物馆测试法:找出遗留代码和老的可执行文件,并确保它们在测试中受到和新代码同样的待遇。在实际测试过程中,可以理解为对新版本中没有改动的功能进行回归冒烟测试。
        例如,在罗网项目的某次回归冒烟测试中,测试研判模型的多案时空碰撞模块,正确创建分析任务,在任务列表中查看分析结果,页面右上角提示出错,无法查看。

    3、娱乐区测试类型(辅助特性)
        1)配角测试法:鼓励测试专注于某些特定功能,特别是紧邻主要功能的辅助功能。
        罗网项目的主要功能为通过研判模型对各类案件及人员进行分析,然而每次审批几乎都离不开新建工单的过程,所以测试时对研判模型的每个模块都增加了许多新建工单的用例。

        2)通宵测试法:即使程序长时间运行,不去关闭,观察程序是否会发生异常。
    4、旅游区测试类型(快速访问软件的各种功能)
        1)收藏家测试法:收集软件的输出,越多越好。确保能观察到软件能生成的任何一个输出。此方法庞大,通常以小组为单位进行。
        例如,在广西上网行为分析项目中,为确保接收到的数据格式和内容都正确,需提前造出大量用户数据,模拟实际的运行环境批量发送数据,批量查看输出结果。
        3)超模测试法:只测试界面显示。
        例如,在采购部供应链大数据平台的某次测试中,由于前端页面没有设置按比例缩放,导致页面在小屏幕上无法显示完全。

    5、旅馆区测试类型(经常被忽略或者在测试计划中较少描述的次要及辅助功能)
        1)取消测试法:启动操作然后停止它。可以对任何提供取消功能或者需要较长时间才能完成的功能做同样的操作。如果没有取消按钮,对于在浏览器中运行的程序可以试着按Esc键或是程序中的回退按钮。
        2)懒汉测试法:测试人员做尽量少的实际工作。接受所有默认值,保持输入字段继续为空,在表单中尽可能少填数据,在进入下一个界面时不点击任何按钮或者输入任何数据等等。
        传统的手工测试方法需要提前编写测试用例,然后严格地依次执行每一个用例,引入探索式测试方法可以在测试过程中更及时地发现问题并补充用例,两种方法相结合才能更有效地把控产品的质量。
        如果未来开发技术大幅进步,也许会有一天,测试人员不再是必需的了。这当然是软件厂商和用户的福音,但是在可预见的未来,检测软件缺陷的最好方法还是使用测试技术,而不是开发技术。原因很简单,太多的不确定因素,太多的场景,可能导致自动化测试失效的情况太多了,无法一一跟踪。这一切都需要“人脑”的介入,现在如此,下个十年不会变,再过几十年可以依然如此。

    版权声明 (原创):本文内容由移动云用户自发贡献,版权归原作者所有,移动云开发者社区不拥有其著作权,亦不承担相应法律责任。如果您发现本社区有涉嫌抄袭的内容,可填写举报信息,一经查实,本社区将立刻删除涉嫌侵权内容。

    展开全文
  • 测试方法之Java白盒测试(一)

    万次阅读 2019-12-20 22:13:53
    说明:该篇博客是博主一字一码编写的,...一、测试方法的分类 静态测试方法 动态测试方法 1.静态测试方法 不执行程序的测试方法。 主要用于测试文档和代码(文档)。 2.动态测试方法 通过运行程序来...

    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家!
    接着上一篇博客继续往下写 :https://blog.csdn.net/qq_41782425/article/details/103602467

    一、测试方法的分类

    • 静态测试方法

    • 动态测试方法

    1.静态测试方法

    • 不执行程序的测试方法。

    • 主要用于测试文档和代码(文档)。

    2.动态测试方法

    • 通过运行程序来发现缺陷的测试方法。
      √     黑盒测试方法
      √     白盒测试方法

    2.1黑盒测试

    • 也称为功能测试、数据驱动测试、基于规格说明书测试。
      在这里插入图片描述

    • 从用户观点出发,主要以软件规格说明书为依据,对程序功能和接口进行测试,对
      输入输出数据之间的对应关系进行测试。

    • 它不涉及到程序的内部结构,如果外部特性本身有问题或规格说明书有问题,则无
      法察觉。
      √     安全性测试、互操作性测试也属于功能测试。
      √     方法如大纲法、场景法、等价类、边界值、决策表、错误猜测等。

    • 黑盒测试方法还用于测试软件的非功能性特性。
      √     非功能测试用于测试系统工作的怎么样,包括但不限于
             ✰     可用性/可靠性/稳定性/健壮性/可恢复性测试
             ✰     可维护性测试
             ✰     易用性测试
             ✰     可移植性/兼容性测试
             ✰     配置测试
             ✰     文档测试
             ✰     国际化测试/本地化测试
      √     当不涉及程序内部结构时,上述测试类型也使用黑盒测试方法。

    2.2白盒测试

    • 也称结构测试、逻辑驱动测试、基于程序本身的测试、程序员测试。
      在这里插入图片描述
    • 结构测试需要完全了解程序结构和处理过程,按照程序内部逻辑测试程序,检验程
      序中每条通路是否按照预定要求工作。

    2.3黑盒测试与白盒测试的区别

    在这里插入图片描述

    二、静态测试方法

    静态测试方法包括评审和静态分析方法。

    1.评审

    1.1评审的含义、过程和目的

    在这里插入图片描述

    1.2评审的角色

    在这里插入图片描述

    1.3评审的分类

    • 文档审查
    • 代码审查
    • 代码走查

    1.4代码审查

    1.4.1代码审查的含义、过程和目的

    在这里插入图片描述

    1.4.2代码审查的方法和范围

    • 具体做法方法
      √     互查
    • 通常合格的代码应具备正确性、清晰性、规范性、一致性和高效性,概括起来,
      代码审查的工作涵盖下列方面
      √     业务逻辑的审查
      √     算法的效率
      √     代码风格
             ✰     if(1j)与 if(j1),问:以上哪种代码风格较好?
             ✰     if(j>MAX_NUM)与 if(j>2000),哪个好?
      √     编程规则

    1.5 代码走查

    在这里插入图片描述

    2.静态分析方法

    在这里插入图片描述

    2.1数据流分析

    • 使用了未声明/定义的变量
    • 变量声明了没有使用

    2.2控制流分析

    在这里插入图片描述

    2.3复杂度分析

    • 复杂度分析给出一组能描述程序代码的复杂度特征的度量。
      在这里插入图片描述
    • 计算复杂度
      在这里插入图片描述
      复杂度为:边(17)- 点(13)+ 2 = 6

    3.静态测试的意义

    在这里插入图片描述

    4.静态测试可以发现的缺陷

    • 引用一个没有定义值的变量;
    • 从未使用的变量;
    • 模块和组件之间接口不一致;
    • 不可达代码(unreachable code)或死代码(dead code);
    • 违背编程规则;
    • 安全漏洞;
    • 代码和软件模型的语法错误等。

    5.一些静态分析工具

    [OSS]代表开源软件,[PROPRIETARY]代表付费软件。
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    三、白盒测试方法

    1.单元测试用例的设计方法

    • 白盒测试方法
    • 黑盒测试方法
    • 以白盒测试方法为主,并适当地结合黑盒测试方法

    2.白盒测试方法

    • 逻辑覆盖法
      √     语句覆盖
      √     判定覆盖
      √     条件覆盖
      √     判定-条件覆盖
      √     条件组合覆盖

    • 路径覆盖法

    3.白盒测试方法的步骤

    3.1获得需求、获得/画出程序流程图/算法图

    在这里插入图片描述

    3.2画出控制流图

    • 根据需求来画
    • 根据算法图/流程图来画
    • 弄清预期结果
      在这里插入图片描述

    3.3选择覆盖方法设计测试用例

    3.3.1语句覆盖法 C0

    • 目标
      √     程序中的每个可执行语句至少被执行一次。

    • 度量(覆盖率)
      √     被执行的语句数/所有可能的语句数。
      √     被执行的路径数/所有可能的路径数。
      在这里插入图片描述

    • 用例
      √     a=2,b=1,c=6
      √     用例对语句的覆盖率:100%
      √     用例对路径的覆盖率:25%

    • 语句覆盖能发现语句错误
      在这里插入图片描述

    • 语句覆盖不能发现逻辑错误/条件错误
      在这里插入图片描述

    3.3.2 分支/判定覆盖 C1

    • 目标
      √     程序中的每个判定的取真分支和取假分支至少执行一次。
      在这里插入图片描述

    • 用例
      √     a=2,b=1,c=6
      √     a=-1,b=1,c=1
      √     用例对语句的覆盖率:100%
      √     用例对路径的覆盖率:50%

    • 分支/判定覆盖能发现逻辑错误
      在这里插入图片描述

    • 分支/判定覆盖不能发现组合判断中的条件错误
      在这里插入图片描述

    3.3.3 条件覆盖 C2

    • 目标
      √     程序每个判定中每个条件的可能取值至少满足一次。
    • 未必比 C1 更全面。
    • 不能发现逻辑错误。
      在这里插入图片描述
    • 用例
      在这里插入图片描述
    • 思考:覆盖率?

    3.3.4 判定-条件覆盖 C1+C2

    • 目标
      √     每个条件中的所有可能取值至少执行一次,同时,每个判定的可能结果至少执行一次。

    • 可能会导致某些条件掩盖了另一些条件。
      在这里插入图片描述

    • 用例
      在这里插入图片描述

    3.3.5 条件组合覆盖/多条件覆盖 C3

    • 目标
      √     每个判定中的所有的条件取值组合至少执行一次。

    • 比 C2 全面。
      在这里插入图片描述

    • 用例
      在这里插入图片描述

    3.3.6 路径覆盖 C4

    • 目标
      √     用例覆盖程序中的所有可能的执行路径。

    • 不切实际
      √     因为涉及到相当长和几乎无穷尽的路径数。
      √     任何可能的循环在程序段中都被视为是可能的路径。

    • 用例
      在这里插入图片描述

    • 路径覆盖优化
      √     McCabe 的基路径方法
      在这里插入图片描述
      √     从源节点到汇节点的线性独立路径数(根据圈复杂度计算)
             ✰     V(G)=e-n+2p=10-7+2=5
             ✰     当规模很小时,我们可以直观地标识独立路径。
      √     以下给出的是用节点/边序列表示的路径:
             ✰     p1:A,B,C,G/1,4,9
             ✰     p2:A,B,C,B,C, G/1,4,3,4,9
             ✰     p3:A,B,E,F,G/1,5,8,10
             ✰     p4:A,D,E,F,G/2,6,8,10
             ✰     p5:A,D,F,G/2,7,10

    • 案例
      在这里插入图片描述

    四、白盒测试工具

    • 内存资源泄漏检查工具
      √     如 Numega 中的 BounceChecker,Rational 的 Purify 等;

    • 代码覆盖率检查工具
      √     如 Numega 的 TrueCoverage , Rational 的 PureCoverage , TeleLogic 公司的 Logiscope;

    • 代码性能检查工具
      √     如 Logiscope 和 Macabe 等。

    • 静态源代码分析工具
      √     类似于编译器,能够检查源代码,发现违反编程语言语法规则和大量定义编程规范的代码。

    面试题:
    在这里插入图片描述
    答案:

    • 语句覆盖:
      √     要求:A<5 & B=5 & A=2 | X>2
      √     用例:A=2,B=5,X=3(此时X=多少都无所谓,因为A=2已经满足了条件)

    • 判定覆盖
      √     要求:
                      A<5 & B=5 对一次,错一次
                      A=2 | X>2 对一次,错一次
      √     用例:
                      A=2,B=5,X=3
                      A=6,B=6,X=1

    • 条件覆盖
      √     要求:
                      A<5 对错各一次
                      B=5 对错各一次
                      A=2 对错各一次
                      X>2 对错各一次
      √     用例:
                      A=2,B=5,X=3
                      A=6,B=6,X=1

    • 判定-条件覆盖
      √     要求:
                      A<5 对错各一次
                      B=5 对错各一次
                      A<5 & B=5 对一次,错一次
                      A=2 对错各一次
                      X>2 对错各一次
                      A=2 | X>2 对一次,错一次
      √     用例:
                      A=2,B=5,X=3
                      A=6,B=6,X=1

    • 多条件覆盖
      √     要求:
                      A<5对,B=5对
                      A<5对,B=5错
                      A<5错,B=5对
                      A<5错,B=5错
                      A=2对,X>2对
                      A=2对,X>2错
                      A=2错,X>2对
                      A=2错,X>2错
      √     用例:
                      A=2,B=5,X=3
                      A=6,B=6,X=1
                      A=2,B=6,X=1
                      A=6,B=5,X=3

    • 路径覆盖
      √     要求:
                      A<5 & B=5 对,A=2 | X>2 对
                      A<5 & B=5 对,A=2 | X>2 错
                      A<5 & B=5 错,A=2 | X>2 对
                      A<5 & B=5 错,A=2 | X>2 错
      √     用例:
                      A=2,B=5,X=3
                      A=6,B=6,X=1
                      A=2,B=6,X=1
                      A=4,B=5,X=1

    • 最终的用例:(按照一条用例尽可能多的去覆盖其他测方法)
      A=2,B=5,X=3
      A=6,B=6,X=1
      A=2,B=6,X=1
      A=4,B=5,X=1
      A=6,B=5,X=3

    五、使用 JUnit 进行单元测试

    1.JUint 简介

    • JUnit 是一个开放源代码的 Java 测试框架,用于编写和运行可重复的测试。

    • JUnit 测试是程序员测试,即所谓白盒测试,是一个 Java 语言的单元测试框架,多数 Java 的开发环境都已经集成了 JUnit 作为单元测试的工具。

    • JUnit 在极限编程和重构(refactor)中被极力推荐使用,因为在实现自动单元测试的情况下可以大大的提高开发的效率。

    • 每编写完一个函数之后,都应该对这个函数的方方面面进行测试,这样的测试我们称之为单元测试。
      √     在编写大型程序的时候,需要写成千上万个方法或函数,也许我们在程序中只用到该函数的一小部分功能,并且经过调试可以确定,这一小部分功能是正确的。但是,我们同时应该确保每一个函数都完全正确,因为如果我们今后如果对程序进行扩展,用到了某个函数的其他功能,而这个功能有 bug 的话,那绝对是一件非常郁闷的事情。

    2.JUnit 中的注解

    • JUnit 使用注解进行单元测试。
      √     注解用于修饰测试方法或测试类,写在测试方法或测试类的前面。同时,使用这些注解时,需要导入相应的包。

    • 比较重要的注解大致有 Fixture 注解、@Test 注解、@Ignore 注解、@Parameters 注解、@RunWith 注解。

    2.1 Fixture 注解

    • 表示“在某些阶段必然被调用的代码”。

    • 一般包括@Before 注解、@After 注解、@BeforeClass 注解、@AfterClass 注解,这些注解一般用于修饰测试方法,测试方法名随意。

    • @Before 注解
      √     @Before 修饰的方法在每个测试方法之前执行。

    • @After 注解
      √     @After 修饰的方法在在每个测试方法之后执行。

    • @BeforeClass 注解
      √     @BeforeClass 修饰的方法在所有测试方法执行之前执行。

    • @AfterClass 注解
      √     @AfterClass 修饰的方法在所有测试方法执行之后执行。

    2.2 @Test 注解

    • @Test 注解
      √     用于修饰测试方法,表示要对被测试类的某个或某些方法进行测试。

    • @Test(timeout=xxx)注解
      √     xxx 表示时间,以 ms 为单位;
      √     一般称为限时测试或超时测试,用于设置当前测试方法在一定时间内运行完,否则返回错误。
             ✰     对于那些逻辑很复杂,循环嵌套比较深的程序,很有可能出现死循环,因此一定要采取一些预防措施,限时测试是一个很好的解决方案,给测试函数或方法设定一个执行时间,超过了这个时间,程序就会被系统强行终止,并且系统还会汇报该函数结束的原因是因为超时,这样就可以发现这些Bug 了。

    2.3 @Ignore 注解

    • @Ignore 注解用于修饰测试方法,表示忽略测试用例;
    • 其含义是“某些方法尚未完成,暂不参与此次测试”。这样的话测试结果就会提示你有几个测试被忽略,而不是失败。一旦你完成了相应函数,只需要把@Ignore 标注删去,就可以进行正常的测试。

    2.4 @Parameters 注解

    • 用于修饰产生数据集合的方法,用于参数化。
    • 测试时,可能需要测试大量不同的路径,从而要使用大量的数据,使用@Parameters注解只需要编写一个测试代码即可众多数据进行多次测试。

    2.5 @RunWith 注解

    • 用于指定一个测试运行器(Runner),@RunWith 用来修饰类,而不能修饰函数。

    • 要对一个类指定了 Runner,那么这个类中的所有函数都被这个 Runner 来调用。

    • 常用的内置测试运行器有 Parameterized(参数化数据)和 Suite(测试集)。

    3.JUnit 中的方法

    3.1 断言

    • 用来断定程序中是否存在缺陷。

    • assertEquals(预期结果,实际结果)
      √     用于测试期望结果的断言,即测试两个对象是否相等,这个方法使用非常多。

    • fail(错误消息内容)
      √     其中错误消息可选,假如提供,将会在发生错误时报告这个消息。该断言会使测试立即失败,通常用在测试不能达到的分支上(如异常)。

    3.2 setUp 和 tearDown

    说明: JUnit中的setUP和tearDown跟Python中的unittest框架的setUP和tearDown是一个道理;setUpBeforeClass和setUpAfterClass与setUpClass和tearDownClass同理

    • 在实际的测试中我们测试某个类的功能是常常需要执行一些共同的操作,完成以后需要销毁所占用的资源(例如网络连接、数据库连接,关闭打开的文件等),JUnit提供了 setUp 方法、tearDown 方法、setUpBeforeClass 方法、tearDownAfterClass方法。

    • setUp方法
      √     在每个测试方法之前都会运行。
      √     主要实现测试前的初始化工作。

    • tearDown方法
      √     在每个测试方法结束以后都会执行。
      √     主要实现测试完成后的垃圾回收等工作。

    • setUpBeforeClass方法
      √     在所有测试方法执行之前执行。

    • tearDownAfterClass方法
      √     在所有测试方法执行之后执行。

    • 实际使用时,setUp 方法可用@Before 注解代替,tearDown 方法可用@After 注解代替,setUpBeforeClass 方法可用@BeforeClass 代替,tearDownAfterClass 方法可用 @AfterClass 代替。

    展开全文
  • 白盒测试方法 一、概念 白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件或程序验证。它可以形象得用下图表示: 二、白盒测试方法...
  • 软件测试方法

    万次阅读 多人点赞 2019-04-16 14:49:22
    ...软件测试方法 编辑讨论 软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样化,针对性更强;选择合适的软件测试方法可以让我们事半功倍。 用户界面...
  • 常见的软件测试方法

    千次阅读 2020-10-25 00:00:34
    软件测试作为一个技术岗位,也是有自己的技术划分的,按照市场上常见的分类,可以分为白盒测试技术、黑盒测试技术以及介于二者之间的灰盒测试技术,每种测试技术更有自己独特的分析方法。 1.白盒测试技术 1)代码...
  • 软件测试——白盒测试方法

    千次阅读 2021-10-20 13:25:19
    白盒测试法检查程序内部逻辑结构,对所有的逻辑路径进行测试,是一种穷举路径的测试方法,但即使每条路径都测试过了,但仍然有可能存在错误。因为:穷举路径测试无法检查出程序本身是否违反了设计规范,即程序是否是...
  • 白盒测试方法

    万次阅读 多人点赞 2019-08-12 19:27:47
    白盒测试法检查程序内部逻辑结构,对所有逻辑路径进行测试,是一种穷举路径的测试方法。但即使每条路径都测试过了,仍然可能存在错误。因为: 穷举路径测试无法检查出程序本身是否违反了设计规范,即程序是否是一个...
  • 八大黑盒测试方法总结【超详细】

    千次阅读 2020-09-20 23:53:23
    实例说明8、三角形问题的边界值分析测试用例三、错误推测方法1. 定义2. 错误推测方法的基本思想:四、因果图方法1.定义2.因果图法产生的背景:3.因果图介绍4. 因果图概念5. 采用因果图法设计测试用例的步.
  • 常见的黑盒测试方法

    千次阅读 2022-02-24 15:03:10
    常见的黑盒测试方法
  • 白盒测试是测试人员常用的一种测试方法,越来越受到测试工程师的重视。白盒测试并不是简单的按照代码测试用例而走,需要根据不同的测试需求,结合不同的测试对象,使用适合的方法进行测试。本文介绍六种白盒测试方法...
  • 常见的二十种软件测试方法详解(史上最全)

    千次阅读 多人点赞 2021-01-27 22:15:57
    测试方法:白盒测试(因为要测源码) 测试内容:模块接口测试(测试模块里面的参数传递是否正确)、局部数据结构测试(测试变量的作用域范围)、路径测试(if-else 判断必须覆盖所有分支)、错误处理
  • 常见的系统测试方法

    千次阅读 2021-09-10 16:10:13
    上述三种方法当中的“盒”指的就是被测对象。 2、按测试对象是否执行分类 ①静态测试(指的就是测试不执行,类似于界面形式,说明文档等) ②动态测试(将软件运行在真实的使用环境中进行测试) 3、按测试手段进行...
  • 485串口测试 RS485口测试方法

    千次阅读 2021-07-23 05:47:27
    1, RS485口测试方法应该可以,用 真实 的 通信线路 来 测试可以用 电脑 + RS232/RS485转换器 连接 ,形成一个 串口通信线路再 做 实际 的 串口通信 试验当然,不同的 RS485仪器,具体的指令、格式以及对某一指令的...
  • 常用的4种黑盒测试方法

    千次阅读 2021-10-22 18:09:17
    等价类划分是一种典型的黑盒测试方法,使用这一方法时,完全不考虑程序的内部结构,只依据程序的规格说明来设计测试用例。等价类划分方法把所有可能的输入数据,即程序的输入域划分成若干部分,然后从每一部分中选取...
  • 测试方法之Java白盒测试(二)

    万次阅读 2019-12-21 19:09:44
    说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家!...文章目录五、使用 JUnit 进行单元测试4.JUnit 的安装和使用流程4.1 第 1 步,安装 eclipse 及 jre4.2 第 2 步,新建 Java 项目4.3 第 3 ...
  • 白盒测试主要包含如下测试方法: 1.语句覆盖 语句覆盖要求必须编写足够多的测试用例,使得每一个可执行的语句都至少被执行一次,语句覆盖常常被称为“最弱的覆盖”,因为它只考虑了可执行语句,但是无法测试隐式...
  • 等价类划分测试方法 在很多情况下,很多人想到的测试方法是穷举测试,穷举测试是最全面的测试,但是数据量很大的情况下不太现实,测试效率太低 实现目标:用最少的测试数据,比较高的效率,以达到最好的测试质量 ...
  • 一些基本的测试方法

    万次阅读 2018-08-09 16:55:22
    接下来我们要讨论的就是怎么做的问题了,即具体的测试方法。 图描绘的质量属性的六大类和测试类型之间的关系,并没有深入到各个质量子属性和各个子属性对应的测试类型中去(大家不妨自己动手绘制一下“质量子属性...
  • 黑盒测试方法之等价类划分

    千次阅读 多人点赞 2020-10-22 16:40:48
    1. 概述 等价类划分是一种典型的黑盒测试方法,这一设计方法完全不用考虑程序的内部结构,也就是说其只根据需求规格说明书。 2. 定义 等价类划分的方法就是将程序的输入域划分为若干部分,也可以说是若干个等价类,...
  • 黑盒测试方法(全)

    万次阅读 多人点赞 2019-07-02 18:13:00
    测试用例的设计方法(全) 目录: 等价类划分方法 边界值分析方法 错误推测方法 因果图方法 判定表驱动分析方法 正交实验设计方法 功能图分析方法 场景设计方法 等价类划分方法: 一.方法简介 1.定义 ...
  • (1)白盒测试:又称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构,设计测试数据并完成测试的一种测试方法。 (2)黑盒测试:又称为数据驱动测试,把测试对象当做看不见的黑盒,在完全不考虑...
  • 测试方法-等价类划分

    万次阅读 多人点赞 2020-04-06 23:36:39
    测试方法测试方法1、黑盒-等价类例1:测试一个两位数的加法计算器例2:余额宝提现例3:三角形测试用例设计 测试方法 软件测试方法 经典定义: 软件测试(Software Testing),在规定的条件下对程序进行操作,以发现程序...
  • App接口测试的流程和测试方法以及工具的使用

    万次阅读 多人点赞 2020-06-29 14:03:08
    App接口测试 使用工具 Fiddler、Jmeter、postman 测试设计: 通过性验证: 首先肯定要保证这个接口功能是好使的,也就是正常的通过 性测试,按照接口文档上的参数,正常传入,是否可以返回正确的结果。 参数组合: ...
  • 黑盒测试的测试方法

    万次阅读 多人点赞 2017-12-19 11:35:22
    一般我们在做软件测试的时候,会遇到黑盒测试,白盒测试,我们今天主要说的是黑盒测试的 主要测试方法有那些。接下来就是干货了。 最常见的是  边界值 等价类 错误推测法 场景法 因果图法 判定表组成法 正交实验...
  • 车载毫米波雷达测试方法

    千次阅读 2020-08-25 15:01:13
    车载毫米波雷达测试方法文件摘录测试条件4.3 测试目标性能测试5.1 探测范围5.2 探测速度范围5.3 多目标分辨能力 2020年《车载毫米波雷达测试方法》规定了车载毫米波雷达测试的测试条件、性能测试、发射机测试和电气...
  • 人工智能(AI)测试方法

    千次阅读 2020-05-12 17:26:21
    人工智能利用机器学习技术,通过对现有的经过处理(筛选、消噪、过滤等)的数据,不断进行矫正(设置阀值等方法)机器模型的输出,此过程称为训练,期望通过训练可以得到在未来新数据上有良好表现的模型,从而投入...
  • 黑盒测试用例测试方法

    万次阅读 2018-05-25 17:55:21
    黑盒测试用例设计方法一、等价类划分法 等价类划分法是一种典型的、重要的黑盒测试方法,是指某个输入域的子集合。在该子集合中,所有的输入数据对于揭露软件中的错误都是等效的。 等价类划分有效等价类和无效等价类...
  • 性能测试方法

    千次阅读 2019-04-26 09:53:39
    备注:以下是常用的测试方法,当然我们还是要根据项目的需要而定,不同项目,不同业务,压测方法不同。比如长连接和短链接不同,协议不同,测试方法不同,大家要根据情况而定。 负载测试:通过在被测系统上不断加压...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,886,461
精华内容 1,554,584
关键字:

测试方法