QA应该从严格的黑框角度进行测试吗？

Question

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

编辑：
假设我们正在使用非开发人员使用的应用程序，我们不会处理附加了API的内容。

Answer 1

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

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

Answer 2

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

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

Answer 3

对于测试人员来说，尽可能多地了解软件的实现是绝对有意义的。这将有助于他们更好地测试。

黑盒测试是一项非常有用且必要的技术，但是了解一下底层发生的事情，可以更容易地定义真正有趣的测试用例。

依赖开发人员对所有白盒测试需求进行单元测试的问题是，开发人员基本上都不是非常彻底的测试人员，特别是涉及他们编写的代码时。

Answer 4

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

Answer 5

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

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

Answer 6

Answer 7

我认为混合方法效果很好。如果您使用白盒测试（单元测试）和黑盒测试的组合，您最终会获得更好的覆盖率。每个都有其优点和缺点，但它们部分地掩盖了另一个的弱点。

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