黑盒或白盒测试-您首先要做什么?


14

在一个非常小的团队中,黑盒子和白盒子的测试是由同一个人完成的,测试人员应该首先做什么?


1
我认为这取决于上下文。您是否已大部分完成了规格说明并想开始进行最终测试,或者在开发周期的任何时候都在谈论?正如在回答中提到的那样,您的实现者通常会编写单元测试,这可以被视为您的盒子测试的一部分,因为这些编码人员了解内部工作原理,并希望在提交之前断言其实现的功能。
克里斯,2010年

Answers:


11

不管是最正确的。

认真地说,理想情况下,白盒测试(即测试代码内部)应该由编写代码的开发人员使用单元测试来完成。单元测试会随着时间的推移而建立,并且是构建过程的一部分,因此我们不会浪费可怜的测试人员的时间,因为我们知道代码无法正常工作。团队越小,单元测试就越重要-尤其是因为您没有大量的测试人员来解决问题。

黑盒测试(即通过用户/系统界面进行的测试)通常是大多数测试人员所做的。

所有测试都需要确定功能对成品的关键程度。如果任务是提供执行X的工具而产品不执行X,那么这是一个大问题。


1
好说,到目前为止,我读的最好的答案。
克里斯,2010年

5

黑色

黑盒测试以验证功能。如果发生故障,请根据需要进行白盒测试。如果所有黑盒测试均通过且覆盖范围良好,则无需进行白盒测试。


2
当然,除非黑盒测试错过了对关键功能或配置的关键测试:}
艾伦(Alan)2010年

3
@Alan:同样的论点适用于白盒测试,因此“覆盖范围是好的”警告
Steven A. Lowe 2010年

1
同意-我想我的发言取决于您对良好覆盖面的定义。
艾伦(Alan)2010年

1
@DocBrown我绝对不明白您所解释的是什么,就像白盒测试一样。白盒测试涉及遵循给定实现的分支路径,并编写将使用所有路径的测试用例。如果还没有实现,则无法按照定义进行白盒测试。使用TDD和BDD,您可以编写当时给出的一般形状的测试。您可以设置输入数据或前提条件状态,启动设备并检查输出数据,结束状态或第三方调用。这是黑盒测试的定义。
Sammi

1
@SamJudge:据我了解,当您查看实现代码并使用该信息设计非常具体的测试数据(然后通过公共接口传递)时,有理由将其称为白盒测试。如果结果不是人们期望的那样,这样的测试也会失败。如果以后再看测试,您可能无法清楚地说出“该测试是通过白盒(或黑盒)方法进行的”。
布朗

3

黑盒子。

白盒组件通常依赖于黑盒组件,因此我想先测试黑盒,然后再转到白盒。


2
我不确定“黑盒组件”和“白盒组件”是什么意思-对我来说,它们只是“组件”(可以在有或没有底层代码或体系结构知识的情况下进行测试。)
Alan

我不明白您在这里建议的“依赖”关系。白黑和黑匣子不是组件,而是Alan提到的一种测试任何组件的样式。区别在于测试相关组件的方法不同。
克里斯,2010年

2

首先,您以编码人员/开发人员的身份进行白色测试,以确保一切正常。然后,您通常会进行黑匣子测试,试图认为自己好像是最终用户,而不考虑程序的内部结构。有时,即使您正在进行黑色测试,也需要像编码员/开发人员一样思考,因为您可能正在测试由其他人编写的内部模块,而您无权访问代码。


2

如果您想拥有一个良好的测试周期,则应该让不同的人同时执行Both

  • 专注于白盒测试的开发人员知道代码最近发生了什么变化,哪些区域更复杂(因此可能会中断)等,并且可以将精力集中在这些区域上,这些区域最有可能引入新的缺陷。

  • 另一方面,专注于黑匣子测试的质量检查测试人员可以像最终用户那样更轻松地进行测试。没有代码的任何内部知识,他们可以采用全新的方法,并且不会对解决方案的不同部分的实现方式有所偏见。他们将捕获开发人员可能忽略的错误,或意外更改应用程序其他区域的代码更改引起的回归。

要回答您的问题,应该先进行白盒测试。但是,如果您想使黑匣子测试有效,则确实需要由其他人来进行黑匣子测试。


1

我喜欢从黑盒测试开始,然后使用代码覆盖率信息或调试器来确定我在做什么并分析正在发生的事情。

但是真正的答案取决于它。如果我正在进行API测试,那么我很可能会早点研究代码(甚至要先研究),但是如果我的目标是看一些大型的端到端方案,那么我可能会更晚。


1

我首先要说黑盒测试,这仅仅是因为作为TDD的支持者,测试是在代码(或盒)存在之前编写的:)

白箱测试(据我所知)是在调试心态更加有用。


-1,TDD 白盒测试。在TDD中,必须知道测试中涉及的代码做什么(不做什么)来编写下一个测试。黑盒测试意味着不了解代码的人(测试人员,甚至不需要知道如何编码的人)设计测试。
布朗

1
因此,我们不会以相同的方式练习TDD。对我来说,TDD是关于加强类/函数的规范的:编写测试以检查类/函数的行为是否符合指定的要求,但是只要坚持这些规范,就可以忽略代码在幕后的行为...鉴于测试是在功能之前编写的,因此这是必要的。
Matthieu M.

1

黑盒测试,因为您是在代码存在之前编写测试。测试人员需要在开发人员编写代码的同时开发耗时的自动测试,以在小型团队中高效地进行测试。

如果代码已经编写,我建议您花一些时间从黑匣子的角度勾勒出测试范围,以确保在实际代码杂乱之前有一些时间进行头脑风暴。但是,在进行实际测试之前,您可以切换到白盒并查看代码,以了解风险区域,并优先考虑您先前脑力激荡的那些测试(并通过考虑新的测试来增强它们)查看看起来复杂或有问题的代码部分)。


0

都不行 我尝试使用Right BICEP编写好的测试,并牢记正确的边界条件,无论它们遵循什么顺序。这些都是在“ 实用单元测试”中提出的首字母缩写词。

我的目标是专注于编写好的测试,而不是首先写哪种颜色。


“白色”和“黑色”不是单元测试术语,因此您当然不必担心。单元测试实际上是白盒。
Ethel Evans 2010年

@Ethel Evans:从定义上讲,它们不是白盒测试。绝大多数单元测试是白盒测试,但这不是必需的。将输入的域映射到函数的输出范围的任何测试都是单元测试,但无需了解实现的详细信息。
史蒂文·埃弗斯

0

首先要做白盒测试

其次进行黑盒测试。

>黑匣子测试

I.测试人员应检查应用程序的功能,例如文本框,单选按钮,列表框,命令按钮等,

二。测试人员应检查应用程序的功能是否正常,例如徽标,图片,拼写等。

三,测试人员应检查整个应用程序流程。

注意:检查正负条件。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.