精华内容
下载资源
问答
  • 黑盒测试和白盒测试区别

    千次阅读 2020-10-19 16:24:16
    一、黑盒测试和白盒测试 黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。 白盒测试:已知产品的内部工作过程,可以进行测试证明每种内部操作是否符合设计规格要求,所有内部...

    一、黑盒测试和白盒测试

     黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。

    白盒测试:已知产品的内部工作过程,可以进行测试证明每种内部操作是否符合设计规格要求,所有内部成分是否经过检查。

     1. 第一认识:

      黑盒测试

    测试特点:测试功能;

    测试依据:需求规格说明书

    方法举例:等价类划分、边界值测试

    优点:能站在用户的立场上进行测试

    缺点:不能测试程序内部特定部位,如程序有误,则无法发现。

    白盒测试

    测试特点:测试程序接口与结构

    测试依据:软件程序

    方法举例:逻辑覆盖

    优点:对程序内部特定部位进行覆盖测试。

    缺点:无法检验程序外部特性。

     2.第二认识:

      黑盒测试把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,针对“软件界面”和”软件功能“进行测试,只检查功能是否符合需求规格说明书能正常使用。因此黑盒测试又叫功能测试或数据驱动测试。

      白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子,他允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为”结构测试“或”逻辑驱动测试“。白盒测试是按照程序内部的结构来测试程序,通过测试检验产品内部动作是否按照设计规格说明书的要求正常进行,检验程序中的每条通道是否都按照规定正常工作。

      3.第三认识:

      黑盒测试主要是为了发现以下错误:

     (1)是否有不正确或者遗漏了的功能;

     (2)在接口上,输入能否正确的接受?能否输出正确的结果?

     (3)是否有数据结构错误或外部信息(例如数据库文件)访问错误?

     (4)性能上是否能够满足要求?

     (5)是否有初始化或终止性错误?

    黑盒的测试用例技术设计有三种:  边界值分析、等价类划分、错误推测法。

     白盒测试主要是想对程序模块进行以下检查:

     (1)对程序模块的所有独立的执行路径至少测试一遍;

     (2)对所有的逻辑判定,取”真“与”假“的两种情况都能至少测一遍;

     (3)在循环的边界和运行的界限内执行循环体;

     (4)测试内部数据结构的有效性,等等;

     (5)静态白盒测试  :即代码审查,正式审查和检验设计和程序代码;

     (6)动态白盒测试 利用查看代码功能和实现方式得到的信息来设计和执行测试,也叫结构测试;

     白盒的测试用例技术包括逻辑覆盖和基本路径测试。

      逻辑覆盖:是以程序内在逻辑结构为基础的测试用例设计技术,这一方法要求测试人员对程序的逻辑结构有清楚的了解。

     基本路径测试:在程序控制流程图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。

    展开全文
  • 黑盒测试和白盒测试区别及测试案例.doc
  • 黑盒测试和白盒测试之间的区别软件测试任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。白盒测试:已知...
  • 黑盒测试和白盒测试区别

    万次阅读 多人点赞 2018-09-21 11:41:40
     白盒测试:是一种测试用例设计方法,在这里盒子指的是被测试的软件,白盒,顾名思义即盒子是可视的,你可以清楚盒子内部的东西以及里面是如何运作的,因此白盒测试需要你对系统内部的结构工作原理有一个清楚的...

    一. 软件测试方法

    1.        软件测试方法:白盒测试、黑盒测试、灰盒测试、静态测试、动态测试

    2.        白盒测试:是一种测试用例设计方法,在这里盒子指的是被测试的软件,白盒,顾名思义即盒子是可视的,你可以清楚盒子内部的东西以及里面是如何运作的,因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解,并且基于这个知识来设计你的用例。

    白盒测试技术一般可被分为静态分析和动态分析两类技术。

    静态分析主要有:控制流分析技术、数据流分析技术、信息流分析技术。

    动态分析主要有:逻辑覆盖率测试(分支测试、路径测试等),程序插装等。

    白盒测试优点:迫使测试人员去仔细的思考软件的实现;可以检测代码中的每条分支和路径;揭示隐藏在代码中的错误;对代码的测试比较彻底;最优化。

    白盒测试缺点:昂贵;无法检测代码中遗漏的路径和数据敏感性错误;不验证规格的正确性。

    3.        黑盒测试又叫功能测试,这是因为在黑盒测试中主要关注被测软件的功能实现,而不是内部逻辑。在黑盒测试中,被测对象的内部结构,运作情况对测试人员是不可见的,测试人员对被测产品的验证主要是根据其规格,验证其与规格的一致性。

    在绝大多数没有用户参与的黑盒测试中,最常见的测试有:功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。

    4.        灰盒测试:白盒测试和黑盒测试往往不是决然分开的,一般在白盒测试中交叉使用黑盒测试的方法,在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。

    最常见的灰盒测试是集成测试

    5.        静态测试:是一种不通过执行程序而进行测试的技术。它的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

    6.        动态测试:包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。

    单元测试属于白盒测试范畴;集成测试属于灰盒测试范畴;系统测试属于黑盒测试范畴

    二.  单元测试

    1.        概念:单元测试(Unit Testing)是对软件基本组成单元进行的测试,如函数或是一个类的方法。这里的单元,就是软件设计的最小单位。

    单元测试的两个步骤:人工静态检查法与动态执行跟踪法。

    人工静态检查是测试的第一步,这个阶段工作主要是保证代码算法的逻辑正确性(尽量通过人工检查发现代码的逻辑错误)、清晰性、规范性、一致性、算法高效性,并尽可能的发现程序中没有发现的错误。

    第二步是通过设计测试用例,执行待测程序来跟踪比较实际结果与预期结果来发现错误。

    2.      人工检查:

    (1)、检查算法的逻辑正确性:确定所编写的代码算法、数据结构定义(如:队列、堆栈等)是否实现了模块或方法所要求的功能。

    (2)、模块接口的正确性检查:确定形式参数个数、数据类型、顺序是否正确;确定返回值类型及返回值的正确性。

    (3)、输入参数有没有作正确性检查:如果没有作正确性检查,确定该参数是否的确无需做参数正确性检查,否则请添加上参数的正确性检查。

    (4)、调用其他方法接口的正确性:检查实参类型正确与否、传入的参数值正确与否、个数正确与否,特别是具有多态的方法。返回值正确与否,有没有误解返回值所表示的意思。最好对每个被调用的方法的返回值用显示代码作正确性检查,如果被调用方法出现异常或错误程序应该给予反馈,并添加适当的出错处理代码。

    (5)、出错处理:模块代码要求能预见出错的条件,并设置适当的出错处理,以便一旦程序出错时,能对出错程序重做安排,保证其逻辑的正确性,这种出错处理应当是模块功能的一部分。若出现下列情况之一,则表明模块的错误处理功能包含有错误或缺陷:出错的描述难以理解;出错的描述不足以对错误定位,不足以确定出错的原因;显示的错误信息与实际的错误原因不符;对错误条件的处理不正确;在对错误进行处理之前,错误条件已经引起系统的干预等。

    (6)、保证表达式、SQL语句的正确性:检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含二义性,对于容易产生歧义的表达式或运算符优先级(如:<、=、 >、 &&、||、 、 --等)可以采用扩号“()”运算符避免二义性,这样一方面能够保证代码的正确可靠,同时也能够提高代码的可读性。

    (7)、检查常量或全局变量使用的正确性:确定所使用的常量或全局变量的取值和数值、数据类型;保证常量每次引用同它的取值、数值和类型的一致性。

    (8)、表示符定义的规范一致性:保证变量命名能够见名知意,并且简洁但不宜过长或过短、规范、容易记忆、最好能够拼读。并尽量保证用相同的表示符代表相同功能,不要将不同的功能用相同的表示符表示;更不要用相同的表示符代表不同的功能意义。

    (9)、程序风格的一致性、规范性:代码必须能保证符合企业规范,保证所有成员的代码风格一致、规范、工整。例如对数组做循环,不要一会儿采用下标变量从下到上的方式(如:for(i=0;i ;i<10)),一会儿又采用从上到下的方式(如:for(i=10;i--;i>0));应该尽量采用统一的方式,或则统一从下到上,或则统一从上到下。建议采用for循环和While循环,不要采用do{}while循环等。

    (10)、检查程序中使用到的神秘数字是否采用了表示符定义:神秘的数字包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。在程序源代码里,一个具有原本形式的数对其本身的重要性或作用没提供任何指示性信息,它们也导致程序难以理解和修改。对于这类神秘数字必须采用相应的标量来表示;如果该数字在整个系统中都可能使用到务必将它定义为全局常量;如果该神秘数字在一个类中使用可将其定义为类的属性(Attribute),如果该神秘数字只在一个方法中出现务必将其定义为局部变量或常量。

    (11)、检查代码是否可以优化、算法效率是否最高:如:SQL语句是否可以优化,是否可以用1条SQL语句代替程序中的多条SQL语句的功能,循环是否必要,循环中的语句是否可以抽出到循环之外等。

    (12)、检查您的程序是否清晰简洁容易理解:注意:冗长的程序并不一定不是清晰的。

    (13)、检查方法内部注释是否完整:是否清晰简洁;是否正确的反映了代码的功能,错误的注释比没有注释更糟;是否做了多余的注释;对于简单的一看就懂的代码没有必要注释。

    (14)、检查注释文档是否完整:对包、类、属性、方法功能、参数、返回值的注释是否正确且容易理解;是否会落了或多了某个参数的注释,参数类型是否正确,参数的限定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释,如:类型参数 应该指出 1.代表什么,2.代表什么,3.代表什么等。对于返回结果集(Result Set)的注释,应该注释结果集中包含那些字段及字段类型、字段顺序等。

    3.        动态执行跟踪:动态执行测试通常分为黑盒测试与白盒测试。对于单元测试来说主要应该采用白盒测试法对每个模块的内部作跟踪检查测试。对于单元白盒测试,应该对程序模块进行如下检查:(1)、对模块内所有独立的执行路径至少测试一次;(2)、对所有的逻辑判定,取“真”与“假”的两种情况都至少执行一次;(3)、在循环的边界和运行界限内执行循环体;(4)、测试内部数据的有效性等等。

    4.      单元测试的目的:在于发现各模块内部可能存在的各种错误,主要是基于白盒测试。

    单元测试的目的主要有3方面:验证单元代码和详细设计文档的一致性;跟踪详细设计文档中设计的实现,发现详细设计文档中存在的错误;发现在编码过程中引入的错误。

    5.        单元的常见错误:(1)、单元接口;(2)、局部数据结构;(3)、独立路径;(4)、出错处理;(5)、边界条件。

    6.        单元测试策略:有三种,独立的单元测试策略,自顶向下的单元测试策略和自底向上的单元测试策略。

    独立的测试策略:不考虑每个模块与其他模块之间的关系,为每个模块设计桩模块和驱动模块。每个模块进行独立的单元测试。

    自顶向下的测试策略:先对最顶层的单元进行测试,把顶层所调用的单元做成桩模块。其次对第二层进行测试,使用上面已测试的单元做驱动模块。如此类推直到测试完所有模块。

    自底向上测试:先对模块调用层次图上最低层的模块进行单元测试,模拟调用该模块的模块做驱动模块。然后再对上面一层做单元测试,用下面已被测试过的模块做桩模块。依次类推,直到测试完所有模块。

    7.        单元测试过程:计划(测什么)、设计(测试方案、策略)、实现(写测试用例、代码)、执行(测试报告)四个阶段。

    8.        单元测试的原则:(1)、对全新的代码或修改过的代码进行单元测试;(2)、单元测试根据单元测试计划和方案进行,排除测试的随意性;(3)、必须保证单元测试计划、单元测试方案、单元测试用例等经过评审;(4)、当测试用例的测试结果与预期结果不一致时,单元测试的执行人员需如实记录实际的测试结果;(5)、只有当测试计划中的结束标准达到时,单元测试才能结束;(6)、对被测试单元需达到的一定的代码覆盖率要求。

    三.  测试用例

    1.        简介:测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。也指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。

    不同类别的软件,测试用例是不同的。

    2.        概述:测试用例构成了设计和制定测试过程的基础。测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流,因而,随着测试用例数量的增加,你对产品质量和测试流程也就越有信心。

    判断测试是否完全的一个主要评测方法是基于需求的覆盖,而这又是以确定、实施和/或执行的测试用例的数量为依据的。

    测试工作量与测试用例的数量成比例。最佳方案是为每个测试需求至少编制两个测试用例。一个测试用例用于证明该需求已经满足,通常称作正面测试用例。另一个测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这个测试用例称作负面测试用例。

    3.      设计方法:

    (1)、白盒技术:白盒测试是结构测试,所以被测对象基本上是源程序,以程序的内部逻辑为基础设计测试用例

    白盒测试的测试用例设计:一般采用逻辑覆盖法基本路径法进行设计。

    逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术,这一方法要求测试人员对程序的逻辑结构有清楚的了解。逻辑覆盖可分为:语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖与路径覆盖。

    语句覆盖:在测试时,首先设计若干个测试用例,然后运行被测程序,使程序中的每个可执行语句至少执行一次。

    判定覆盖法:在测试时,首先设计若干个测试用例,然后运行被测程序,使得程序中的每个判断的取真分支和取假分支至少经历一次,即判断的真假值均曾被满足。

    条件覆盖法:在测试时,首先设计若干个测试用例,然后运行被测程序,要使每个判断中每个条件的可能取值至少满足一次。

    判定条件覆盖法:在测试时,首先设计若干个测试用例,然后运行被测程序,使得判断中每个条件的所有可能至少出现一次,并且每个判断本身的判定结果至少出现一次。

    路径覆盖法:在测试时,首先设计若干个测试用例,然后运行被测程序,要求覆盖程序中所有可能的路径。

    基本路径覆盖法:是在程序控制流图的基础上,通过分析控制结构的环路复杂性,导出基本可执行路径集合,设计测试用例的方法。该方法把覆盖的路径数压缩到一定限度内,程序中的循环体最多只执行一次。设计出的测试用例要保证在测试中,程序的每一个可执行语句至少执行一次。

    循环路径测试:基本路径覆盖法将循环限制在最多一次,这样虽然大大降低了需要覆盖的路径的条数,但对循环的测试却不充分了,因此还需要对循环路径进行测试。循环路径测试包含,简单循环的测试和嵌套循环的测试。

    每一种覆盖方法都有其优缺点。通常在设计测试用例时应该根据代码模块的复杂度,选择覆盖方法。一般的代码的复杂度与测试用例设计的复杂度成正比。因此,设计人员必须做到模块或方法功能的单一性、高内聚性,使得方法或函数代码尽可能的简单;这样将可大大提高测试用例设计的容易度,提高测试用例的覆盖程度。

    基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。基本路径测试法包括以下5个方面:(1)、程序的控制流图:描述程序控制流的一种图示方法;(2)、程序环境复杂性:McCabe复杂性度量;从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界;(3)、导出测试用例;(4)、准备测试用例,确保基本路径集中的每一条路径的执行;(5)、图形矩阵:是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动地确定一个基本路径集。

    另外,对于测试用例的选择除了满足所选择的覆盖程度(或覆盖标准)外还需要尽可能的采用边界值分析法、错误推测法等常用地设计方法。采用边界值分析法设计合理的输入条件与不合理的输入条件;条件边界测试用例应该包括输入参数的边界与条件边界(if,while,for,switch ,SQL Where子句等)。错误推测法,列举出程序中所有可能的错误和容易发生错误的特殊情况,根据它们选择测试用例;在编码、单元测试阶段可以发现很多常见的错误和疑似错误,对于这些错误应该作重点测试,并设计相应的测试用例。

    (2)、黑盒技术:等价划分类、边界值分析、错误推测、因果图、综合策略

    4.        测试类设计:一个模块或一个方法(Method)并不是一个独立的程序,在考虑测试它时要同时考虑它和外界的联系,用些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种:

    (1)、驱动模块(driver):相当于所测模块的主程序。它接收测试数据,把这些数据传送给所测模块,最后再输出实际测试结果;

    (2)、桩模块(stub):用于代替所测模块调用的子模块。桩模块可以做少量的数据操作,不需要把子模块所有功能都带进来,但不容许什么事情也不做。

    打桩:一般在做单元或集成测试时,如果某个程序单元的某条语句,需要调用的一个外部函数还没有设计、编码、调试完成的话,可以只让它简单地返回几个支持测试用例的值就可以了,这种状态的外部函数一般就叫做“打桩”。

    所测模块与它相关的驱动模块及桩模块共同构成了一个“测试环境”。

    驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时并不作为产品的一部分一同交付,而且它们的编写需要一定的工作量。特别是桩模块,不能只简单地给出“曾经进入”的信息。为了能够正确的测试软件,桩模块可能需要模拟实际子模块的功能,这样桩模块的建立就不是很轻松了。

    编写桩模块是困难费时的,其实也是完全可以避免编写桩模块的;只需在项目进度管理时将实际桩模块的代码编写工作安排在被测模块前编写即可。而且这样可以提高测试工作的效率,提高实际桩模块的测试频率从而更有效的保证产品的质量。但是,为了保证能够向上一层级提供稳定可靠的实际桩模块,为后续模块测试打下良好的基础,驱动模块还是必不可少的。

    对于每一个包或子系统我们可以根据所编写的测试用例来编写一个测试模块类来做驱动模块,用于测试包中所有的待测试模块。而最好不要在每个类中用一个测试函数的方法,来测试跟踪类中所有的方法。这样的好处在于:(1)、能够同时测试包中所有的方法或模块,也可以方便的测试跟踪指定的模块或方法;(2)、能够联合使用所有测试用例对同一段代码执行测试,发现问题;(3)、便以回归测试,当某个模块作了修改之后,只要执行测试类就可以执行所有被测的模块或方法。这样不但能够方便得检查、跟踪所修改的代码,而且能够检查出修改对包内相关模块或方法所造成的影响,使修改引进的错误得以及时发现;(4)、复用测试方法,使测试单元保持持久性,并可以用既有的测试来编写相关测试;(5)、将测试代码与产品代码分开,使代码更清晰、简洁;提高测试代码与被测代码的可维护性。

    5.        跟踪调试:跟踪调试不但是深入测试代码的最佳方法,而且也是程序调试发现错误根源的有利工具。测试类设计完成后,最好能借助代码排错工具来跟踪调试待测代码段以深入的检查代码的逻辑错误。现有的代码开发工具(如:JBuilder)一般都集成了这类排错工具。排错工具一般由执行控制程序、执行状态查询程序、跟踪程序组成。执行控制程序包括断点定义、断点撤销、单步执行、断点执行、条件执行等功能。执行状态查询程序包括寄存器、堆栈状态、变量、代码等与程序相关的各种状态信息的查询。跟踪程序用以跟踪程序执行过程中所经历的事件序列(如:分支、子程序调用等)。程序员可通过对程序执行过程中各种状态的判别进行程序错误的识别、定位及改正。

    对于模块的单元跟踪调试最好能够做到:每次修改被测模块后,都将所有测试用例跟踪执行一遍以排除所有可能出现或引进的错误。在时间有限的情况下也必须调用驱动模块对所有的测试用例执行一次,并对出现错误或异常的测试用例跟踪执行一次,以发现问题的根源。

    排错过程往往是一个艰苦的过程,特别是那种算法复杂、调用子模块较多的模块,对于错误的定位来说并不是件容易的事情。尽管排错不是一门好学的技术(有时人们更愿意称之为艺术),但还是有若干行之有效的方法和策略,下面介绍几种排错时应该采用的方法策略:(1)、断点设置,设置断点对源程序实行断点跟踪将能够大大提高排错的效率。通常断点的设置除了根据经验与错误信息来设置外,还应重点考虑以下几种类行的语句:A、函数调用语句。子函数的调用语句是测试的重点,一方面由于在调用子函数时可能引起接口引用错误,另一方面可能是子函数本身的错误;B、判定转移/循环语句。判定语句常常会由于边界值与比较优先级等问题引起错误或失效而作出错误的转移。因此,对于判定转移/循环语句也是一个重要的测试点;C、SQL语句。对于数据库的应用程序来说,SQL语句常常会在模块中占比较重要的业务逻辑,而且比较复杂。因此,它也属于比较容易出现错误的语句;D、复杂算法段。出错的概率常与算法的复杂度成正比。所以越复杂的算法越需要作重点跟踪,如递归、回朔等算法。(2)、可疑变量查看,在跟踪执行状态下当程序停止在某条语句时可查看变量的当前值和对象的当前属性。通过对比这些变量当前值与预期值可以轻松的定位程序问题根源;(3)、SQL语句执行检查,在跟踪执行或运行状态下将疑似错误的SQL语句打印出来,重新在数据库SQL查询分析器(如:Oracle SQL Plus)中跟踪执行可以较高效的检查纠正SQL语句错误;(4)、注意群集现象,经验表明测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律,应当对错误群集的程序段进行重点测试,以提高测试投资的效益。如果发现某一代码段似乎比其他程序模块更多的错误倾向时,则应当花费较多的时间和代价测试这个程序模块。

    6.        测试用例设计的基本原则:(1)、一个好的测试用例在于能够发现至今没有发现的错误;(2)、测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成;(3)、在测试用例设计时,应当包含合理的输入条件和不合理的输入条件。

    7.      测试用例的具体做法:

    (1)、测试用例文档:编写测试用例文档应有文档模板,须符合内部的规范要求。

    (2)、测试用例的设置:按功能设置用例、按路径设置用例、按功能、路径混合模式设置用例;

    (3)、设计测试用例:测试用例可以分为基本事件、备选事件和异常事件。

    四.   白盒测试

    1.      白盒测试一般包括以下几项:

    (1)、目的:保证程序创建的类与接口的完整与正确,以及程序模块单独正常运行。保证局部模块功能完备性,运行正确性与稳定性。

             (2)、测试项:所要测试的类。

             (3)、测试依据:A、需求规格说明书、用例描述清单;B、设计文档;C、编码规范;D、开发命名标准。

             (4)、通过的准则:创建的类、接口、方法、属性应与《设计文档》保持一致;程序的各种命名、注释、代码行的格式等应符合《程序开发命名标准》和《编码规范》;程序模块能独立稳定运行。

             (5)、测试环境配置:A、测试工具;B、软件环境。

    2.      测试步骤:

    (1)、配置好测试环境;

    (2)、编写测试用例;

    (3)、静态测试、走查代码;

    (4)、动态测试;

    (5)、确定问题属性:分为四类,错误、缺陷、失效、故障。

    错误是指计算值、观测值、测量值之间,或条件与真值之间,不符合规定的或理论上的正确值或条件。

    缺陷是指与期望值或特征值的偏差。

    故障是指功能部件不能执行所要求的功能。故障可能由错误、缺陷或失效引起。

    失效是指功能部件执行其功能的能力丧失,系统或系统部件丧失了在规定限度内执行所要求功能的能力。

    (6)、确定问题类别;

    (7)、填写测试报告。

    3.        白盒测试和单元测试的区别:(1)、测试目的:一个是测试程序的整体逻辑,另一个是测试程序中一个独立的模块;(2)、通常的执行人员不一样:白盒一般由专门的白盒测试人员完成,单元测试一般由程序员自己完成。

    展开全文
  • 黑盒测试和白盒测试

    2017-08-28 12:24:34
    黑盒测试和白盒测试

    一、黑盒测试和白盒测试

     黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。

    白盒测试:已知产品的内部工作过程,可以进行测试证明每种内部操作是否符合设计规格要求,所有内部成分是否经过检查。

     1. 第一认识:

      黑盒测试

    测试特点:测试功能;

    测试依据:需求规格说明书

    方法举例:等价类划分、边界值测试

    优点:能站在用户的立场上进行测试

    缺点:不能测试程序内部特定部位,如程序有误,则无法发现。

    白盒测试

    测试特点:测试程序接口与结构

    测试依据:软件程序

    方法举例:逻辑覆盖

    优点:对程序内部特定部位进行覆盖测试。

    缺点:无法检验程序外部特性。

     2.第二认识:

      黑盒测试把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,针对“软件界面”和”软件功能“进行测试,只检查功能是否符合需求规格说明书能正常使用。因此黑盒测试又叫功能测试或数据驱动测试。

      白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子,他允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为”结构测试“或”逻辑驱动测试“。白盒测试是按照程序内部的结构来测试程序,通过测试检验产品内部动作是否按照设计规格说明书的要求正常进行,检验程序中的每条通道是否都按照规定正常工作。

      3.第三认识:

      黑盒测试主要是为了发现以下错误:

     (1)是否有不正确或者遗漏了的功能;

     (2)在接口上,输入能否正确的接受?能否输出正确的结果?

     (3)是否有数据结构错误或外部信息(例如数据库文件)访问错误?

     (4)性能上是否能够满足要求?

     (5)是否有初始化或终止性错误?

    黑盒的测试用例技术设计有三种:  边界值分析、等价类划分、错误推测法。

     白盒测试主要是想对程序模块进行以下检查:

     (1)对程序模块的所有独立的执行路径至少测试一遍;

     (2)对所有的逻辑判定,取”真“与”假“的两种情况都能至少测一遍;

     (3)在循环的边界和运行的界限内执行循环体;

     (4)测试内部数据结构的有效性,等等;

     (5)静态白盒测试  :即代码审查,正式审查和检验设计和程序代码;

     (6)动态白盒测试 利用查看代码功能和实现方式得到的信息来设计和执行测试,也叫结构测试;

     白盒的测试用例技术包括逻辑覆盖和基本路径测试。

      逻辑覆盖:是以程序内在逻辑结构为基础的测试用例设计技术,这一方法要求测试人员对程序的逻辑结构有清楚的了解。

     基本路径测试:在程序控制流程图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。

    展开全文
  • 黑盒测试和白盒测试的基本原理/区别是什么?

    首先我们来看,白盒测试跟黑盒测试,对于这两个概念,我在网上也经常看到有人提出类似的问题,那我今天就来写一篇关于两者之间的原理与区别VS。

    因为有很多朋友是刚刚接触软件测试行业的,多多少少都会有听过白盒测试、黑盒测试。

    在公司里面,或者经常听到有人说你是做黑盒测试还是做白盒测试?或者白盒测试包括哪一些范畴呢?黑盒测试又包括哪一些范畴。

    文章首发于公众号:程序员阿沐

    我们简单来介绍一下这两个概念

    黑盒测试
    黑盒测试:也称功能测试,测试中把被测的软件当成一个黑盒子,

    内部结构是什么,只关心软件的输入数据与输出结果。

    主要测试依据是需求文档、设计文档、用户手册

    1:业务能力

    2∶测试策略(功能测试、u测试,兼容性测试)

    3:设计用例–逻辑思维

    在这里插入图片描述

    这个图呢,我们就可以把整个程序,当做一个黑盒子,那么它的特点是什么呢?就是看不到程序里面实现的代码跟逻辑。其实这个就跟用户去使用这个软件是一样的道理。

    比如说你是一个用户,我要去使用这个百度,那么我看到的只是百度的这么一个首页。

    在这里插入图片描述

    页面会有很多的按钮、输入等等之类的一些链接信息。但是我根本就无法通过这个表面展示的信息,去看到它内部代码的一个实现。那么像对这个图标进行点击,

    在这里插入图片描述
    在这里插入图片描述

    在这个搜索框进行输入搜索,功能是否正常实现效果。

    那么像这一类测试,我们就把它就做黑盒测试。

    1.我不需要看到里面的这个代码实现是什么样子的,我也不管你里面是用Python实现的用Java实现的还是用其他编程语言实现的,我只要管我的功能有没有实现,就OK了。

    比如说,我搜索了程序员阿沐,我点击百度一下,我只要得到的结果中间是有关于程序员阿沐这样子的词条结果出现,那么我就认为这个功能是正确的。

    在这里插入图片描述

    因此对于黑盒测试来说的话呢,它也是入门级别的一种测试,也是最为简单的一种测试。因为它只需要根据咱们的测试文档、或者设计文档、或者用户手册等等这一系列的参考数据,参考文档来对这个软件功能进行验证就OK了。

    验证什么呢?

    1.验证它的功能业务有没有正确的实现

    2.验证它的UI是不是显示,是否美观正确,包括它的兼容性,等等之类的

    3.设计用例–逻辑思维

    只要这些内容实现了,符合需求文档、设计文档、用户手册。那么我们就认为这个功能没有问题,这个业务就是可以正常跑通的。所以这个就是对于咱们测试来说最为简单的一种方式,也是最快速入门的一种方式。

    那么真真正正在公司中间,我们第一个去做的也是这个黑盒测试中间的功能测试,其实黑盒测试它是一个很大的范畴,黑盒测试它并不仅仅只包括功能测试,它也包括UI测试,兼容性测试,还包括什么?

    其实我们常说的接口测试也是属于黑盒测试,或者功能测试的一个范畴。

    因为像接口的话,接口这个东西也很简单,我就只需要管我在接口左边传入数据之后,我要得到什么样的结果就OK了。

    在这里插入图片描述

    也就是说我不去管你在这个接口内部中间是用的什么样的协议,用的什么样的处理机制来进行处理的。我就只关心在这个接口的左边,就是我在发送之前我输入一些请求参数,输入完成后我要得到的一个结果,比如说是登录成功或者说是登录失败,或者说是提示什么样的信息。

    所以在一定程度上,我们也会把接口测试划分到黑盒测试的范畴里面来。

    那为什么我们又那么的重视接口测试,而且单独把它从这一块单独拎出来去学习,包括在企业中间呢,你去面试的时候。我相信十个公司去面试至少有九个公司会问到会不会接口测试,会不会接口工具,会不会抓包。

    那是因为接口它可以在咱们这一个功能测试之前,就进行。就在咱们的前一个阶段就开始执行,并且的话呢,它的这一个集成的程度以及管理的程度是相比于咱们这个功能跟UI方面来说,是要方便很多的。

    因为它有一个非常大的特点!就是只需要把接口集成了,调试好了之后,基本上它的接口就不会动了,但是想咱们UI前端的话呢,有时候随着用户的体验感不好,或者说友好性不好等等之类的,前端的变化会非常的多。

    因此在企业里面它会原来越重视这个接口,包括在接口的这一个阶段呢它可以发现你在功能阶段或者说在UI测试这个阶段很多的一些问题。

    通用的问题,既然我能够在前一个阶段能够发现,那我为什么不去做呢,因为在咱们测试的过程中间越早发现这个Bug的话呢,它修复的这个成本就越低。然后你的这个软件的稳定性就会越好。我的这个质量就会得到一个更加好的保障!

    这个就是接口在测试的一个比重,所以大家可以了解一下,所以说我们在这一块我们去做功能测试,接口测试基本上是你现在出去面试的时候必备问到的两个相关的这一个技能。(公众号程序员阿沐主页点击领取资料,领取最新大厂面试题)

    那么我们讲到黑盒的话呢,我们又不得不讲一下我们的

    白盒测试
    因为大家一开始讲到黑盒就会跟白盒来进行比较,那么白盒就是完全跟黑盒相反的。

    白盒测试:关心软件内部设计和程序实现,对内部实现逻辑进行测试的过程。

    主要测试依据是设计文档,伪代码,代码。–》开发

    测试开发(搭建自动化框架,开发自动化工具)–》自动化测试–》框架

    技能要求:看懂内部逻辑(语言: java,python, php…)
    在这里插入图片描述

    那么白盒就是我就直接可以看到里面的代码逻辑,然后根据里面的代码逻辑然后去选取对应的数据,来对它进行一个测试,去检查它的结果是不是正确。因为像这种白盒测试的话呢,我们又把它叫做什么呢?又把它叫做代码测试,或者叫做单元测试。

    像这一种测试的话呢,可想而知,它必须要的一个要求是什么?必须要看懂里面的内部逻辑,如果说你看不懂里面的一个内部逻辑,你怎么去选数据呢。或者说你看不懂里面的内部逻辑,你选了这个数据,你也不知道它对应得出的结果应该是什么。

    如果我在中间给你写一个高阶的函数,以你的能力没有达到这个层次,然后我x去输入一个1,那么我y得出的是多少,我自己都不知道,那么我怎么样去测试呢,我怎么去保证我这个测试的结果是正确的呢。

    因此在这一块,做白盒测试第一个要求就是你要懂内部逻辑,所谓的内部逻辑就是你要看懂开发写的这些代码,又回到我们百度的这个案例上来。

    在这里插入图片描述

    我们单元测试来说,我们看到的不再是百度首页这样子的一个东西,而是我看到的是这样子的一个Html的代码,那么在这样一个代码里面的,要去看它是否正确,div是什么意思,为什么要放到这里,为什么要这样子来写,这就是我们需要去学会一门编程语言非常重要的一个点。

    因为大家都知道,我们的编程语言有非常的多,比如说像Java、PHP、Python等等之类的,那么你这个程序是用什么语言写的,那你就必须要看懂这么语言。

    因此来说白盒测试工程师他的要求非常高。并不是仅仅说你掌握一门编程语言,你掌握一个框架就OK了,并不是这样子的。

    白盒测试因为他的要求比较高,而且相关的技术人员也是挺难找的,所以说一般在公司中间他白盒测试很少让测试去做,一般开发人员做单元测试,因为开发人员这个语言,内部的逻辑就是本人写出来的,所以他对这个语言是非常熟悉的。

    然后利用内部开发人员交叉的测试,从而来测它内部的代码逻辑是不是正确。

    白盒测试参考的一些文档就是,设计文档、伪代码、代码,这些东西。

    当然有些小伙伴就说我的目标就是要成为一个白盒测试工程师,那么我就建议你把这个目标改一改,因为像现在的话呢,大家都知道我们这个人工智能,我们的这一个Python,云储存,这些都非常的火。

    所以说像在这一块,我们要看到时代的一个发展,包括IT他往哪个方面重点发展。现在的话,你无论是走自动化还是走性能方向,或者走安全方向,其实在需求的程度上都比白盒测试要多一些。

    当然白盒测试也有他的一个需求市场,不是说没有,相对比较少。

    知识面拓展:

    黑盒测试产生的问题
    从理论上讲,黑盒测试只有采用穷举输入测试,把所有可能的输入都作为测试情况考虑,才能查出所有的错误。实际上测试情况是无穷多的,完全测试是不可能的。

    如何解决?

    必须将黑盒测试行为加以分类

    1、节约测试实施的时间和资源

    2、避免盲目测试、提高测试效率

    3、使测试的实施重点突出、目的更明确

    加油吧,测试人!路就在脚下,成功就在明天!

    未来的你肯定会感谢现在拼命的自己!

    愿你我相遇,皆有所获! 欢迎关注微信公众号:程序员阿沐

    1.免费领取一份216页软件测试工程师面试宝典文档资料。

    2.软件测试学习路线以及相对应的视频学习教程免费分享!

    文章首发于公众号:程序员阿沐

    转载请注明出处!

    展开全文
  • 实验1 黑盒测试 一实验目的与要求 1掌握等价类测试方法的原理步骤及应用 2掌握边界值分析法的原理步骤及应用 3掌握决策表测试方法的原理步骤及应用 二实验设备 1电脑PC 2office办公软件 三实验原理 一等价类测试法 1...
  • 黑盒测试和白盒测试定义及区别

    千次阅读 2020-07-05 11:50:26
    简单了解一下黑盒测试和白盒测试 一、定义 1.1黑盒测试 黑盒测试又称为功能测试,主要检测软件的每一个功能是否能够正常使用。在测试过程中,将程序看成不能打开的黑盒子,不考虑程序内部结构特性的基础上通过程序...
  • 黑盒测试与白盒测试区别黑盒测试白盒测试主要区别 黑盒测试 不考虑内部的逻辑结构具体运作,依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明要求,检测输出结果是否符合 白盒测试 与黑盒相反,把...
  • 黑盒测试用例设计 决策表法 概述 在一个程序中,如果输入输出比较 多,输入之间输出之间相互制约 的条件比较多,在这种情况下使用 决策表更合适,它可以清楚地表达 它们之间的各种复杂关系 决策表法是黑盒测试方法中最为...
  • 测试的方法;黑盒测试和白盒测试的优缺点比较
  • 黑白盒测试的原理,了解黑盒测试和白盒测试区别

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 25,465
精华内容 10,186
关键字:

黑盒测试和白盒测试的区别