QA 是否应该从严格的黑盒角度进行测试？答案

【问题标题】：Should QA test from a strictly black-box perspective?QA 是否应该从严格的黑盒角度进行测试？
【发布时间】：2008-10-02 19:39:15
【问题描述】：

假设单元测试由开发人员处理，那么 QA 是否有理由了解产品工作原理的详细信息？我的意思是，他们是否需要知道后台发生了什么？他们是否应该在不使用正常 UI 的情况下测试产品的各个部分？例如，测试人员进入数据库并手动更改值以查看会发生什么是否有意义？

编辑：
假设我们正在处理一个供非开发人员使用的应用程序，我们不是在处理附加 API 的东西。

【问题讨论】：

标签： qa black-box

【解决方案1】：

这取决于您编写的方法和软件类型。有不同类型的 QA。如果软件应该是容错的，QA 应该模拟故障。此外，了解产品的工作原理可以帮助 QA 考虑潜在的问题案例并更彻底地对其进行测试。

另一方面，了解产品的工作原理可能会阻止 QA 从用户的角度进行完全测试。因此，也许首先应该在不了解内部结构的情况下设计基本测试，然后根据潜在问题进行更深入的测试。

【讨论】：

【解决方案2】：

当然，这取决于架构。我在一个项目中工作，其中 db 层由不同建筑物中的一个完全独立的团队开发、管理和测试。他们的 QA 肯定会使用数据来查看程序、查询等是否都在一系列测试条件下运行。

如果您在 UI 端，那么有两个级别，一个是简单的功能测试，QA 不需要应用程序的工作知识（并且所有这些都应该是自动化的），然后是 QA，它说应用程序是否做了它应该做的事情。对于第二种情况，如果 QA 团队知道它是如何工作的，那真的很有帮助。一开始就拒绝愚蠢的错误可以节省大量时间，但更重要的是，它们需要像用户一样行事，并且有端到端的用例来尝试一些更复杂的覆盖场景。要设计此类测试，他们必须对应用程序有很好的了解。

【讨论】：

【解决方案3】：

让测试人员尽可能多地了解软件的实现是绝对有意义的。这将帮助他们更好地进行测试。

黑盒测试是一种有用且必要的技术，但对幕后发生的事情有所了解可以更轻松地定义真正有趣的测试用例。

依赖开发人员的单元测试来满足您的所有白盒测试需求的问题在于，总的来说，开发人员并不是非常彻底的测试人员，尤其是在他们编写的代码方面。

【讨论】：

【解决方案4】：

在我参与过的项目中，QA 从用户的角度进行测试，他们的测试是从满足要求的角度进行的。他们的测试是黑盒测试。白盒测试由开发人员完成。我们从没想过 QA 人员会打开数据库查询工具并手动更改值。这是开发者单元测试的职责。

【讨论】：

我会说您的 QA 团队在这种情况下可能进行了相当糟糕的测试 - 甚至可能根本没有测试，而只是确认。它确实发生了，但它肯定不是值得向往的。

【解决方案5】：

我认为这取决于您的 QA 团队在给定项目中所扮演的角色。我认为您可以提出一个论点，即由数据库中存在的特定值引起的情况应该由测试用例表示，如果它们可以以这种方式表示，那么开发人员应该为这些情况编写（应该编写）单元测试.

如果您还使用代码检查来识别和修复缺陷，则可能没有必要将 QA 暴露给幕后的任何内容。我想有些项目可能对他们在用户体验之外测试代码有所帮助，但我可能会使用 QA 团队进行黑盒测试，而不是白盒或明盒测试。

【讨论】：

【解决方案6】：

我认为混合方法效果很好。如果您结合使用白盒测试（单元测试）和黑盒测试，您最终会获得更好的覆盖率。各有优缺点，但它们确实部分掩盖了对方的弱点。

了解代码的内部工作原理会导致您以某种方式进行测试，这并不总是发现某些问题的最佳方式。

【讨论】：

【解决方案7】：

我想说，QA 人员完全有理由不了解您的应用程序如何工作的详细内部知识。 QA 人员的计算机能力应与您的目标受众大致相同。

原因很简单：QA 人员对您的应用程序的构建方式了解得越多，他们就越有可能避免普通用户遇到的正常可用性问题。

QA 不仅仅是测试应用程序是否正常工作。它还应该用于测试您的普通用户是否可以理解并因此实际可用。

更新
这太长了，无法放入评论框中。

关于@testerab 的问题。

我将 QA 定义为负责确保 1. 满足业务需求的个人或团队；并且，2. 与这些要求相关的应用程序功能没有错误。因此，绰号“质量保证”。我认为属于 QA 的第三个项目就是可用性。

他们必须了解业务需求，这意味着他们应该与任何业务分析师和最终用户（如果有的话）携手合作。与我共事过的最好的 QA 成员都是从这些领域聘用的。我见过的最差的 QA 成员是开发人员，或者接受过这样的培训。从技术支持离职的人也往往会成为优秀的 QA 成员，因为他们确切地知道最终用户会尝试的垃圾类型。

有许多不同类别的应用程序。其中最常见的是美化数据输入。您有一些屏幕可以输入信息并按下按钮。然后将信息存储和/或路由到它需要去的任何地方。从 MS Word 到 CRM 的一切都属于这一类。

因此，QA 人员的工作是首先确保应用能够接受所需的输入并执行所需的功能。第二步是提交错误的输入并验证应用程序以所需的方式响应。例如它不会爆炸或允许不良信息通过。自动化测试工具在这些情况下工作得很好。最后一部分是决定该功能是否应该隐藏在三个菜单级别深处，还是应该更容易获得。

以上都不需要 QA 人员阅读代码或摆弄比特。

有些系统没有 UI 组件。对于这些，由开发人员提供一个测试工具，允许 QA 团队提交数据并审查结果。这涵盖了 Web 服务和您可以想象的任何类型的 EDI。

其他系统本身就是 API。这些要求要么有足够知识的 QA 人员来自己实现此类 API 调用，要么需要开发人员提供轻松调用它们并记录结果的方法。在这种情况下，最好让 QA 团队自己进行编程，但同样不能访问底层代码。

查看实际代码的问题在于，它往往会导致人们只关注他们所看到的内容。这是不好的。相反，他们应该在精神上摆脱那些人为的限制，以便他们可以在需要输入数字的文本框中盲目地输入“ABC”。

就“查看”代码以了解要测试的内容而言，这是一个完全不同的问题，在代码审查环境中训练有素的开发人员可以更好地解决这个问题。此处的目的是识别可能的错误、最佳实践、安全故障等。QA 人员很少能够进行这种级别的分析，因为这需要有人成为活跃的开发人员。

关于 SDET：如果您的产品拥有或现在是开发人员用来构建其他东西的 API 或基础，那么您可能需要一个或多个人专门围绕它实施软件，以支持常规 QA 小组。我对这个角色的必要性持观望态度，并相信这可能是一个逐个项目的决策。

我相信有两组更适合测试 API。这些是已经在实施的最终用户以及构建它的公司中的其他开发人员。狗食现在是一种常见的做法，而且非常划算。毕竟，如果它不起作用，您可以确定它会很快得到修复。对于最终用户，只要他们将其视为开发团队响应的真实对话，他们就会很乐意为您“测试”它。

这三种情况我都经历过，作为最终用户，我觉得接触原始开发人员对于解决问题大有帮助。特别是当他们也在使用该产品时。通常与这些项目相关的 QA 人员的误译数量非常可怕。

总之，我曾与各种 QA 人员合作过。从您想知道他们如何设法开车上班的超级明星到非常善于发现导致应用程序阻塞的那些极端情况的超级明星。

最好的人的特点是： 1. 从来不是程序员； 2.了解业务； 3. 准确了解最终用户每天所做的事情。 4. 真诚地关心那些受到软件影响的人。

最差的特征包括： 1. 曾经是程序员或认为他们是程序员； 2. 不懂业务； 3. 从未见过最终用户； 4. 过于频繁地使用“白痴”这个词； 5. 关注它的工作原理，而不是它是否可用。

【讨论】：

这表明对 QA 角色的严重无知。
@testerab：每家公司对其 QA 团队都有不同的需求。一般来说，最好的 QA 人员只会比被测试应用程序的普通用户高出一级。区别应该仅仅在于他们在看到失败时知道失败并知道如何报告失败的能力。调试应用程序或对其内部结构进行修改以导致无法通过应用程序本身看到的故障是在浪费他们的时间和公司的资源。
@testerab：这里有一半的答案是说“白盒”测试会引导 qa 团队走上一条特定的道路，而这正是你应该避免的。接受的答案甚至到了那么远。如果 QA 团队没有因为知道幕后的实际代码是什么而受到阻碍，那么他们将提出真实世界的测试场景。这也是为什么 QA 团队不应该由开发人员组成，除非他们正在测试 API。
感谢您澄清您的答案 - 现在更容易看到您的来源。我仍然不同意你的一些观点，但你现在已经提供了足够的信息来阐明你的观点。
@testerab：SO 的伟大之处在于它非常容易并且非常鼓励提供反意见。添加您自己的答案，即使它与其他人已经说过的任何内容重叠。考虑到你的历史，它甚至可能会被赞成。