假设单元测试是由开发人员处理的，那么质量检查有什么理由要了解产品工作原理的详细信息？我的意思是，他们是否需要知道后台发生了什么？是否应该在不使用常规UI的情况下测试产品细分？例如，对于测试人员来说，进入数据库并手动更改值以查看会发生什么有意义吗？
编辑：
假定我们正在使用供非开发人员使用的应用程序，而不是在开发带有API的东西。

解决方案

当然，这取决于体系结构。我参与了一个项目，在该项目中，数据库层是由位于不同建筑物中的完全独立的团队开发，管理和测试的。他们的QA肯定会缠满数据，以查看过程，查询等是否都在一系列测试条件下运行。

如果我们位于UI端，则有两个级别，一个是简单的功能测试，其QA不需要应用程序的工作知识(所有这些都应该是自动化的)，然后是QA，它说明应用程序是否做了应该做的事。对于第二种方法，如果质量检查团队知道其工作原理，则确实会有所帮助。这样做可以节省大量时间来拒绝愚蠢的错误，但是更重要的是，它们需要像用户一样表现并拥有端到端的用例，以尝试一些更复杂的覆盖方案。要设计这样的测试，他们必须对应用程序有充分的了解。

这取决于我们编写的方法和软件类型。质量检查有不同的种类。如果软件应具有容错能力，则质量检查人员应模拟故障。此外，了解产品的工作原理可以帮助质量检查人员考虑可能存在问题的案例，并对其进行更彻底的测试。

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

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

黑盒测试是一种有用且必要的技术，但是如果了解一些幕后操作，则可以轻松定义真正有趣的测试用例。

依赖开发人员的单元测试来满足所有白盒测试需求的问题在于，开发人员总体上不是非常全面的测试人员，尤其是在编写代码时。

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

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

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

我要说的是，质量检查人员完全有理由不了解应用程序的工作原理。质量检查人员应具有与目标受众几乎相同的计算机能力水平。

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

质量检查不仅仅是测试应用程序是否正常工作。还应该测试普通用户是否可以理解它，从而实际使用它。

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

关于@testerab的问题。

我将质量检查定义为负责确保1.满足业务要求的人员或者小组。 2.就这些要求而言，应用程序的功能没有错误。因此，绰号"质量保证"。我认为质量检查的第三项内容就是可用性。

他们必须了解业务需求，这意味着他们应该与任何业务分析师和最终用户(如果有的话)齐头并进。与我合作过的最好的质量检查成员是从这些地区雇用的。我见过的最差的质量检查成员是开发人员，或者接受过这样的培训。离开技术支持的人也往往会成为优秀的QA成员，因为他们确切地知道最终用户将尝试的垃圾类型。

有许多不同类别的应用程序。毫无疑问，最常见的是荣耀的数据输入。我们在某些屏幕上输入了信息并按下了按钮。信息然后被存储和/或者路由到它需要去的任何地方。从MS Word到CRM的所有内容都属于此类别。

因此，质量检查人员的工作是首先确保该应用程序将接受所需的输入并执行所需的功能。第二步是提交错误的输入，并验证应用程序是否以期望的方式响应。例如它不会炸毁或者允许不良信息通过。在这些情况下，自动化的测试工具非常有用。最后一部分是确定该功能应该被深埋在三个菜单级别中还是应该更容易使用。

以上所有都不要求质量检查人员读取代码或者用位来打转。

某些系统没有UI组件。对于这些，由开发人员提供测试工具，使质量检查团队可以提交数据并查看结果。这涵盖了Web服务以及我们可以想象的任何类型的EDI。

其他系统本身就是API。这些要求或者有足够知识的质量检查人员才能自己实现此类API调用，或者需要开发人员提供轻松调用它们并记录结果的方法。在这种情况下，质量检查小组最好可以自己进行编程，但又不能访问底层代码。

审查实际代码的问题在于，它倾向于使人们专注于他们所看到的内容。这不好。相反，他们应该在精神上摆脱那些人为的限制，以便他们可以在希望输入数字的文本框中盲目键入" ABC"。

就"查看"代码以知道要测试的内容而言，这是一个完全不同的问题，并且受过训练的开发人员可以在代码检查设置中更好地解决该问题。这里的目的是识别可能的错误，最佳实践，安全性失败等。QA人员很少能够进行这种级别的分析，因为它需要有人成为活跃的开发人员。

关于SDET：如果产品已经或者曾经是开发人员用来构建其他东西的API或者基础，那么我们可能希望一个或者多个人员专门围绕其实施软件，以支持常规的质量检查小组。我对担任此职位的必要性持谨慎态度，并认为这可能是由项目决定的项目。

我相信有两个小组更有资格测试API。这些是已经实施的最终用户以及构建它的公司中的其他开发人员。狗食现在是一种常见的做法，并且非常具有成本效益。毕竟，如果它不起作用，则可以确保将其快速修复。对于最终用户，只要他们将其视为开发团队做出响应的真实对话，他们就会很乐意为我们"测试"它。

我经历过这三种情况，作为最终用户，我觉得可以使用原始开发者来解决问题还有很长的路要走。特别是当他们也使用该产品时。通常与这些项目相关的质量检查人员被误解的数量真是太恐怖了。

总而言之，我与各种质量检查人员一起工作。从那些我们想知道他们如何设法推动工作的超级明星那里，他们非常擅长于发现那些导致应用程序停止运行的极端情况。

最好的特点是：1.从来都不是程序员； 2.了解业务； 3.准确了解最终用户每天的工作情况。 4.诚实地关心那些使用该软件的人。

最糟糕的特征包括：1.曾经是程序员或者认为他们是程序员； 2.不了解业务； 3.从未遇到过最终用户； 4.经常使用"白痴"一词； 5.了解它是如何工作的，而不是它是否可用。

我认为混合方法效果很好。如果将白盒测试(单元测试)和黑盒测试结合使用，则最终会获得更好的覆盖率。每种都有其优缺点，但它们确实部分弥补了彼此的弱点。

理解代码的内部工作原理将使我们以某种方式进行测试，这并不总是发现某些问题的最佳方法。