你会说哪种类型的测试应该是重点（对于测试者/ QA），为什么？
维基百科的一组快速定义：
黑盒测试
白盒测试
为了澄清一点，我意识到两者都很重要，但通常它们在开发和QA之间是分开的。
内部知识对测试人员/ QA很重要吗？我听说过用这些知识进行测试的论据使他们能够更好地测试问题，但我也听到过这样的论点，即这些知识会分散功能需求，促进“测试代码”而不是预期的解决方案。
黑盒测试是一种软件测试方法，其中测试项目的内部结构/设计/实现不为测试人员所知。白盒测试是一种软件测试方法，其中测试项目的内部结构/设计/实现是测试者已知的。
什么构成，“内部知识？”知道使用这样的算法来解决问题是否合格，或者测试人员是否必须看到每行代码都是“内部的”？
我认为在任何测试案例中，应该使用规范给出的预期结果，而不是由测试人员如何决定解释规范，因为这可能导致每个人认为他们是正确的问题并且将问题归咎于另一个。
这是我的5美分：
作为一名开发人员，我主要为方法（在一个类中）编写测试作为白盒测试，这很简单，因为我不希望我的测试因为我改变代码的内部工作而中断。
我只希望我的测试在我的方法行为发生变化时中断（例如，返回与之前不同的结果）。
在过去20年的开发过程中，我简单地厌倦了完成双重工作，因为我的单元测试与代码密切相关，我需要维护应用程序代码和测试代码。
我认为制作解耦代码（也就是代码测试时）是一种非常好的做法。
另外5美分：我几乎从不使用模拟框架，因为当我发现它必须模拟某些内容时我宁愿将代码解耦 - 而且在很多情况下这是非常可能的（特别是如果你不使用遗留代码）： - ）
*黑盒测试：如果源代码不可用，则测试数据基于软件的功能，而不考虑其实现方式。 -trong text黑盒测试的例子有：边界值测试和等价划分。
*白盒测试：如果被测系统的源代码可用，则测试数据基于此源代码的结构。 - 白盒测试的示例包括：路径测试和数据流测试。
简单...黑盒测试也称为集成测试或烟幕测试。这主要应用于依赖于事件驱动架构的分布式环境中。您可以根据其他服务测试服务以查看所有可能的方案。在这里，您无法完全预测所有可能的输出，因为SOA / Enterprise应用程序的每个组件都旨在自动运行。这可以称为高级测试
而
白盒测试是指单元测试。可以有效预测所有预期的情景和输出。即输入和预期输出。这可以称为低级测试
我只是部分同意这个问题的最高评价答案。你会说哪种类型的测试应该是重点（对于测试者/ QA），为什么？
我同意here的定义，该定义指出White Box测试方法适用于以下级别的软件测试：
白盒测试等于软件单元测试。开发人员或开发级别测试人员（例如另一个开发人员）确保他编写的代码在将其集成到系统之前根据详细级别要求正常工作。
黑盒测试等于集成测试。测试仪确保系统根据功能级别的要求工作。
在我看来，这两种测试方法同样重要。
完整的单元测试将在开发阶段捕获缺陷，而不是在软件集成到系统中之后。系统级黑盒测试将确保所有软件模块在集成在一起时表现正常。开发阶段的单元测试不会发现这些缺陷，因为模块通常是相互独立开发的。
黑盒子
1重点介绍系统的功能重点介绍系统的结构（程序）
2使用的技术是：
·等价划分
·边界值分析
·猜错
·比赛条件
·因果图
·语法测试
·州过渡测试
·图表矩阵
测试人员可以是非技术性的
有助于识别功能规范中的模糊性和矛盾性
白盒子
使用的技术是：
·基础路径测试
·流程图表示法
·控制结构测试
·循环测试
QA应该专注于黑盒测试。质量保证的主要目标是测试系统的功能（功能是否符合要求？），而不是它是如何做到的。
无论如何，QA应该很难进行白盒测试，因为大多数QA人员都不是技术人员，因此他们通常通过UI测试功能（如用户）。
更进一步，我认为开发人员也应该专注于黑盒测试。我不同意单元测试和白盒测试之间广泛的关联，但它可能只是一个词汇/规模的问题。在单元测试的规模上，被测系统是一个具有契约（通过其签名）的类/方法，重要的是测试它的作用，而不是如何。此外，白盒测试意味着你知道该方法将如何填补其合同，这似乎与TDD不兼容。
恕我直言，如果您的SUT非常复杂，需要进行白盒测试，那么通常是重构的时候。
“两者”已在上面说明，并且是明显的答案......但IMO，白盒测试远远超出了开发人员单元测试（尽管我认为它可能取决于你在白色和黑色之间画线的位置）。例如，代码覆盖率分析是一种常见的白盒方法 - 即运行某些场景或测试，并检查结果，寻找测试中的漏洞。即使单元测试具有100％cc，在常见用户场景上测量cc也可以揭示可能需要更多测试的代码。
白盒测试帮助的另一个地方是检查数据类型，常量和其他信息以查找边界，特殊值等。例如，如果应用程序具有采用数字输入的输入，则仅bb方法可能需要测试人员“猜测”什么值对于测试是有利的，而wb方法可以揭示1-256之间的所有值都是单向处理的，而较大的值则是另一种方式处理......也许数字42还有另一个代码路径。
因此，回答最初的问题 - bb和wb对于良好测试至关重要。
根据我的经验，大多数开发人员自然会转向白盒测试。由于我们需要确保底层算法是“正确的”，我们倾向于更多地关注内部。但是，正如已经指出的那样，白盒和黑盒测试都很重要。
因此，我更倾向于让测试人员更多地关注Black Box测试，以弥补大多数开发人员并没有真正做到这一点的事实，并且经常不太擅长。
这并不是说测试人员应该对系统如何工作保持沉默，只是我更喜欢他们更多地关注问题域以及实际用户如何与系统交互，而不是函数SomeMethod（int x）如果x等于5，将正确抛出异常。
这有点开放，但最终两者同样重要。
更糟糕的是？
我的回答：两者都不是完全可以接受的，但软件不能被证明是100％无错误。所以你将不得不做出一些权衡。选项二更直接地告知客户，因此您很快就会遇到问题。从长远来看，第一选择将是有问题的。
黑盒测试：黑盒测试只是观察不需要内部知识或软件产品的结构。只需输入有效和无效的数据输入并期望得到正确的结果。这里测试人员发现了缺陷但无法找到缺陷的位置。在所有测试级别完成黑盒测试。
黑盒测试技术包括：1。等价划分2.边界值分析3.决策表4.状态转换图4.用例图
白盒测试：白盒测试它需要内部逻辑和软件产品结构的知识。这里我们将检查循环，条件和分支。在这里，我们不仅发现了缺陷，还发现了缺陷的位置。
白盒测试技术：1。报表覆盖范围2.决策覆盖范围3.分支覆盖范围4.路径覆盖范围。