什么是黑匣子测试？功能和可用性测试它的类型吗？

Question

我写的是关于测试的文章，我对以下内容感到困惑：

黑匣子测试到底是什么？

功能测试和可用性测试是两种不同类型的测试，它们是黑匣子测试的类型吗？

我必须执行两种不同类型的测试程序。如果我做功能测试和可用性测试，可以吗？

Answer 1

黑匣子测试意味着测试人员不熟悉系统的内部工作，而白盒测试则由知道程序工作原理的人执行。两者各有优缺点。

功能测试是测试软件产品是否满足功能要求，例如“加载格式错误的文件时，程序必须输出错误消息”或“单击X时，程序必须关闭”。这种测试的结果是二进制“工作”或“不工作”。

然而，可用性很难用功能需求来描述。很难预先判断某个用户界面是否容易使用。你必须建立它，让人们测试它，并听取他们的主观反馈。一个测试人员可能很容易使用的东西可能很难用于另一个测试器。这意味着简单的“可用”或“不可用”的区分在这种情况下是没有用的。测试结果通常是更自由的形式和开放的解释。

此外，可用性测试在系统地发现缺陷方面并不像功能测试那样有用，因为可用性测试人员被鼓励在现实世界中如何使用该产品，而不是故意试图执行试图破坏它的非理性行为。这并不是说当可用性测试人员偶然发现任何明显的bug时，就会不鼓励他们提交错误报告(毕竟，它们确实会影响可用性)，但这并不是他们最关心的问题。当产品不按照功能需求运行时，也不会期望它们提交but，但结果实际上更好。

Answer 2

黑匣子测试(而不是白盒测试)是一个广泛的测试类别，它包括您不知道、也不需要知道实现是如何工作的测试，您只想测试结果。

例如:我单击网站上的“购买”按钮，选择的项目现在在我的购物车中。我不在乎程序员是如何做到这一点的，只是它确实发生了，并且正确的项目被放在购物车里。

在白盒测试中，您希望查看代码的内部并探测实现细节。这在较低级别的单元测试中更为常见。

功能测试可以是黑匣子测试，也可以是白盒测试，具体取决于要执行的测试类型。这两种分类并不是相互排斥的，它们指的是测试的不同方面。有很多分类测试的方法，每个人都有自己的解释，哪种是最好的，或者是在给定的情况下最合适的。

我会说可用性测试几乎肯定是黑匣子测试。有许多不同类型的可用性测试，在这些测试中，您应该执行您认为产品最能从中受益的测试。您可能是在批评用户界面设计，验证可能的客户端到端场景是否有效，或者测试可访问性法规要求是否满足。我会考虑所有这些可用性测试，虽然，正如我之前所说的，人们对不同类型的测试有不同的看法，但其他人可能不同意。

如果您认为这两种测试都会增加价值，那么这两种测试都是可以的。有时你通过支持你的团队发现错误来增加价值，有时你用一双新的眼睛来批评设计。有时，通过创建自动回归测试，使团队将来不会犯常见的错误，并且可以很容易地通过更改来验证他们没有破坏任何东西。如果您认为您再次测试的是相同的东西，那么您可能不会增加太多的价值，但是您可以在没有每次测试的情况下增加价值，最后在填写错误报告时结束。

Answer 3

白盒和黑匣子测试是一种自动测试，可以由计算机运行，并产生过关或失败的结果。“白盒”是指要求您“查看框内”并知道它是如何工作的测试(我相信回归测试和边界测试通常都算在内)，而黑匣子表示您正在测试外部接口，而不知道任何内部细节。

可用性测试绝不是自动化的，因为它涉及到找到一个人来尝试使用你的程序，并观察发生了什么。这种测试通常输出的结果是“用户没有意识到这个图标意味着.”或者“只有专家用户才意识到.”。您可以称它为“黑匣子”，因为您的测试对象不知道代码，但这有点像争辩C++是一种“动态”语言，因为它具有多态性；这不是我的经验中通常使用的词。

功能测试可能是自动化的，也可能不是自动化的，因为它是一个模糊得多的术语，它仅仅意味着测试“软件在我做Y时做X吗？”如果它是用自动化测试完成的，那么这些自动测试很可能是黑匣子的。如果不是，这很可能是由QA团队用英语编写的“测试脚本”完成的(同样，您也可以将其称为“黑匣子”测试，但通常不会)。

就像在测试中经常遇到的情况一样，您希望至少做一些这样的事情。如果出于某种奇怪的原因，你真的必须选择两种，我会选择可用性测试和任何一种自动测试。