📅  最后修改于: 2021-01-10 15:46:15             🧑  作者: Mango
软件测试的盒子测试方法包括黑盒测试和白盒测试。我们在这里讨论白盒测试,也称为玻璃盒测试,结构测试,透明盒测试,开盒测试和透明盒测试。它测试软件的内部编码和基础结构,重点是根据预期和期望的输出检查预定义的输入。它基于应用程序的内部工作原理,并围绕内部结构测试。在这种类型的测试中,需要编程技能来设计测试用例。白盒测试的主要目标是专注于通过软件的输入和输出流,并增强软件的安全性。
由于系统的内部视角,因此使用了“白盒”一词。透明框,白框或透明框的名称表示能够从软件的外壳看透其内部功能。
开发人员进行白盒测试。在这种情况下,开发人员将测试程序代码的每一行。开发人员执行白盒测试,然后将应用程序或软件发送给测试团队,在该团队中,他们将执行黑盒测试,并与要求一起验证应用程序,并确定错误并将其发送给开发人员。
开发人员修复了这些错误,并进行了一轮白盒测试,并将其发送给测试团队。此处,修复错误意味着已删除该错误,并且该特定功能在应用程序上正常运行。
在此,出于以下原因,测试工程师将不包括在修复缺陷中:
白盒测试包含各种测试,如下所示:
在路径测试中,我们将编写流程图并测试所有独立的路径。在这里写流程图意味着流程图代表了程序的流程,并且还显示了每个程序是如何相互添加的,如下图所示:
并且测试所有独立路径意味着假设从main()到函数G的路径,首先设置参数并测试该程序在该特定路径中是否正确,然后以相同的方式测试所有其他路径并修复错误。
在循环测试中,我们将测试诸如while,for和do-while等循环,并检查结束条件是否正常工作以及条件的大小是否足够。
例如:我们有一个程序,开发人员给出了大约50,000个循环。
{
while(50,000)
……
……
}
我们无法在所有50,000个循环中手动测试此程序。因此,我们编写了一个小程序,它可以帮助所有50,000个周期,如下面的程序所示,测试P用与源代码程序相似的语言编写,这被称为单元测试。它仅由开发人员编写。
Test P
{
……
…… }
如下图所示,我们有各种要求,例如1、2、3、4。然后,开发人员针对并行条件编写了程序1,2,3,4。这里的应用程序包含100几行代码。
开发人员将进行白盒测试,并且他们将逐行代码测试所有五个程序以查找错误。如果他们在任何程序中发现任何错误,他们将予以纠正。然后他们再次必须测试系统,然后此过程将花费大量时间和精力,并减慢了产品发布时间。
现在,假设我们有另一种情况,客户想要修改需求,那么开发人员将进行所需的更改并再次测试所有四个程序,这将花费大量的时间和精力。
这些问题可以通过以下方式解决:
在此,我们将为类似的程序编写测试,其中开发人员以相关语言编写这些测试代码作为源代码。然后,他们执行这些测试代码,也称为单元测试程序。这些测试程序链接到主程序并实现为程序。
因此,如果对代码有任何修改或错误的要求,则开发人员会在主程序和测试程序中进行调整,然后执行测试程序。
在此,我们将测试所有逻辑条件的真值和假值;也就是说,我们将同时验证if和else条件。
例如:
if(condition) - true
{
…..
……
……
}
else - false
{
…..
……
……
}
上面的程序对于这两个条件都可以正常工作,这意味着如果条件正确,则其他条件应该为假,反之亦然。
由于以下原因,代码的大小正在增加:
例如,
Int a=15;
Int b=20;
String S= "Welcome";
….
…..
…..
….
…..
Int p=b;
Create user()
{
……
……
….. 200's line of code
}
在上面的代码中,我们可以看到从未在程序中的任何位置调用整数a ,并且从未在代码中的任何位置调用函数Create user 。因此,这导致我们消耗内存。
由于代码很大,我们无法通过验证代码来手动记住这种类型的错误。因此,我们有一个内置工具,可以帮助我们测试不必要的变量和函数。并且,这里有了名为Rational purify的工具。
假设我们有三个程序,例如程序P,Q和R,它们向S提供输入。然后S进入程序并验证未使用的变量,然后给出结果。之后,开发人员将单击多个结果,然后调用或删除不必要的函数和变量。
该工具仅用于C++编程语言;对于另一种语言,我们在市场上还有其他相关工具。
由于以下原因,该应用程序可能很慢:
我们知道开发人员正在执行白盒测试,他们知道代码运行缓慢,或者程序的性能也变得刻意。开发人员无法手动浏览程序并验证代码的哪一行使程序变慢。
为了在这种情况下恢复,我们提供了一个称为Rational Quantify的工具,该工具可以自动解决此类问题。一旦完整的代码准备好了,理性的量化工具将遍历代码并执行它。我们可以在结果表中以粗线和细线的形式看到结果。
在这里,粗线指定了哪段代码比较耗时。当我们双击粗线时,该工具将自动将我们带到该行或一段代码,并以另一种颜色显示。我们可以再次更改该代码并使用此工具。当行的顺序全部变细时,我们知道程序的表示已得到增强。开发人员将自动执行白盒测试,因为这样可以节省时间,而不是手动执行。
白盒测试的测试用例来自软件开发生命周期的设计阶段。数据流测试,控制流测试,路径测试,分支测试,语句和决策覆盖率所有这些由白盒测试使用的技术均作为创建无错误软件的准则。
白盒测试遵循一些工作步骤,以使测试易于管理并易于理解下一步任务。有一些执行白盒测试的基本步骤。
Data Flow Testing | Data flow testing is a group of testing strategies that examines the control flow of programs in order to explore the sequence of variables according to the sequence of events. |
Control Flow Testing | Control flow testing determines the execution order of statements or instructions of the program through a control structure. The control structure of a program is used to develop a test case for the program. In this technique, a particular part of a large program is selected by the tester to set the testing path. Test cases represented by the control graph of the program. |
Branch Testing | Branch coverage technique is used to cover all branches of the control flow graph. It covers all the possible outcomes (true and false) of each condition of decision point at least once. |
Statement Testing | Statement coverage technique is used to design white box test cases. This technique involves execution of all statements of the source code at least once. It is used to calculate the total number of executed statements in the source code, out of total statements present in the source code. |
Decision Testing | This technique reports true and false outcomes of Boolean expressions. Whenever there is a possibility of two or more outcomes from the statements like do while statement, if statement and case statement (Control flow statements), it is considered as decision point because there are two outcomes either true or false. |
以下是白盒测试和黑盒测试之间的重大区别:
White-box testing | Black box testing |
---|---|
The developers can perform white box testing. | The test engineers perform the black box testing. |
To perform WBT, we should have an understanding of the programming languages. | To perform BBT, there is no need to have an understanding of the programming languages. |
In this, we will look into the source code and test the logic of the code. | In this, we will verify the functionality of the application based on the requirement specification. |
In this, the developer should know about the internal design of the code. | In this, there is no need to know about the internal design of the code. |