Question

如果有的话，产品团队的测试人员了解产品的内部代码详细信息是多么有用。这并不意味着他们需要了解代码的每一行，而是要了解代码的结构，对象模型是什么，各种模块如何相互关联，各种功能之间的相互依赖性等等。这可以帮助他们找到相关的问题或缺陷。另一方面，这可能会“偏向”他们的“以用户为中心”的方法来评估和认证产品，并最终影响测试结果。

我没有听说过这种互动的具体模型。（假设产品是用户，可能是非技术消费者，而不是测试人员正在测试的框架或API - 在后一种情况下，测试人员可能需要了解代码来测试，因为用户是另一个程序员）。

Answer 1

这完全取决于正在进行的测试类型。

对于功能系统测试，测试人员可以而且可能应该忘记实施的细节 - 如果他们知道他们可能无意中在他们的测试策略中考虑到的细节而没有正确地测试产品。

对于性能和可伸缩性测试，测试人员通常有助于对代码库的结构有一些高级知识，因为它有助于识别潜在的性能热点，从而编写目标测试用例。这一点很重要的原因在于，通常性能测试是一个广泛的开放式过程，因此任何可以用来集中测试以获得结果的方法都对每个人都有益。

Answer 2

你在这里看到的是黑匣子（不知道内幕），白盒子（所有知识）和灰盒子（一些选择知识）之间的区别。

答案实际上取决于代码的目的。对于集成繁重的项目，然后他们在何处以及如何进行通信，即使它完全在幕后，也允许测试人员生成适当的非功能测试用例。

这些测试用例正在确定组件是否能够优雅地处理缺少可用性的依赖性。它还可用于识别与性能相关的问题。

例如：作为测试人员，如果我知道Web UI组件将请求推迟到执行实际工作的业务流程服务，那么我可以构建业务流程需要很长时间的方案（高负荷）。如果用户然后执行另一个请求（模拟用户不耐烦），并且Web服务将在第一个请求仍然继续时收到第二个请求。如果我们不断重复这一点，那么Web服务最终会因压力而死亡。如果不了解底层模型，就不容易找到问题

在大多数情况下，对于功能测试，黑盒子是首选，只要您转向非功能性或系统集成，那么了解相互作用可以帮助确保适当的测试覆盖。

并非所有测试人员都熟练或舒适地工作/理解组件交互或内部组件，因此每个测试人员/每个系统都基于它是否合适。

在几乎所有情况下，我们都从黑盒子开始，并根据需要朝向白色。

Answer 3

这听起来类似于上一个问题：{{3p>

Answer 4

我从未见过一个对系统内部有很多了解的测试人员处于不利地位的情况。

我认为有一种自我辩解的神话，一个知情的测试人员比一个技术深刻的测试人员更充足甚至更好，因为：

它允许项目经理使用“随机或低质量资源”进行测试。 '像用户神话一样不知情'。如果你想要这种类型的测试 - 让一些“真正的”用户来测试你的东西。
测试人员通常被认为比开发人员更便宜，价值更低。 “任何人都可以做黑盒测试神话”。
开发可以将适当的测试推迟到测试团队。两个神话中的一个'我们不需要培训测试人员'和'只有测试团队测试'神话。

Answer 5

测试人员无需了解内部细节。

应该在不知道内部结构，开发问题，外部因素的情况下测试应用程序。

如果你用这些附加信息来阻碍测试人员，你就会把他推到一个特定的测试方案中，测试人员永远不应该朝着他应该从非编码器视角进行测试的方向推进。

Answer 6

有多种测试方法需要代码审查，还有那些不需要代码审查。

白盒测试（即阅读代码）的优点是，您可以定制测试，只测试您知道的区域（通过阅读代码）将失败。

缺点包括从实际测试中浪费时间来理解代码。

黑盒测试（即不读代码）在发现错误方面可能与白盒一样好（或更好？）。

通常，两种类型的测试都可以在一个项目，开发人员白盒单元测试和测试人员黑盒集成测试中进行。

Answer 7

我更喜欢Black Box测试用于最终测试制度在一个理想的世界......

测试人员应该对代码内部一无所知
他们应该了解客户的所有内容 - 即拥有使用系统/应用程序所需的文档/帮助。（如果有某种代码可交付，这绝对包括API描述/文档）

如果测试人员无法找到具有这些限制的缺陷，那么您还没有充分记录您的API /应用程序。

Answer 8

如果他们是专门的测试人员（只有他们做的事情）那么我认为他们应该尽可能少地了解他们试图测试的代码。

他们常常试图确定其失败的原因，这是开发人员而不是测试人员的责任。

那就是说我认为开发人员会成为优秀的测试者，因为我们倾向于知道某些类型功能的边缘情况。

Answer 9

如果你不知道代码内部，那么这是一个你无法找到的错误的例子，因为你根本无法测试所有输入：

long long int increment(long long int l) {
    if (l == 475636294934LL) return 3;
    return l + 1;
}

然而，在这种情况下，如果测试人员将100％的代码覆盖率作为目标，并且仅查看内部部件以编写测试以实现该目标，则会发现。

这是一个错误的例子，如果你做知道代码内部，你很可能找不到，因为错误的自信具有传染性。特别是，代码的作者通常不可能编写一个捕获此错误的测试：

int MyConnect(socket *sock) {
    /* socket must have been bound already, but that's OK */
    return RealConnect(sock);
}

如果MyConnect的文档没有提到必须绑定套接字，那么有一天会发生意外事件（有人会将其称为未绑定，并且可能是套接字实现将选择一个任意本地地址）。但是，能够看到代码的测试人员通常没有“测试”文档的心态。除非他们真的在形式上，否则他们不会注意到在文档中没有提到的代码中有一个假设，并且只会接受这个假设。相比之下，从文档中编写的测试人员可以很容易地发现错误，因为他们会想到“套接字可以处于什么状态？我会对每个进行测试”。由于没有提到任何约束，因此他们没有理由不尝试失败的情况。

答案：两者都做。一种方法是在查看/编写代码之前编写测试套件，然后添加更多测试以涵盖您在实现中引入的任何特殊情况。无论测试人员是否与程序员是同一个人，这都适用，但显然如果程序员编写第二种测试，那么组织中只有一个人必须理解代码。这个代码只有一个人能够理解，这是一个很好的长期策略，这是有争议的，但这种做法很普遍，因为它确实可以节省时间。“

[编辑：我拒绝透露这些错误是如何产生的。也许第一个的程序员在临床上疯了，而对于第二个程序员，对所使用的端口有一些限制，以便解决已知发生的一些奇怪的网络设置，并且套接字应该是通过一些de-创建的奇怪的API，其存在在通用套接字文档中提到，但它们忽略了要求使用它。很明显，在这两种情况下，程序员都非常粗心。但这并不影响这一点：示例不需要是现实的，因为如果你没有捕获只有非常粗心的程序员会犯的错误，那么你将无法捕获代码中的所有实际错误，除非你从来没有过糟糕的一天，做一个疯狂的错字等等。]

Answer 10

我想这取决于你想要的测试有多好。如果您只是想要理智地检查常见情况，那么无论如何，只要给测试人员/披萨食者提供申请并告诉他们发疯。

但是，如果您希望有机会找到边缘情况，性能或负载问题，或者隐藏在代码深处的许多其他问题，那么您最好雇用测试人员知道如何以及何时使用白盒技术。

你的电话。

Answer 11

恕我直言，我认为测试人员的行业观点是完全错误的。

想一想......你有两个水管工，一个非常有经验，知道所有的规则，建筑规范，并且可以快速查看某些东西并知道工作是否正确完成。另一个管道工很好，可靠地完成工作。

你想做哪一个最后的检查，以确保你不回到被水淹没的房子？事实上，在其他行业中，他们允许那些对系统一无所知的人，他们正在检查实际进行检查吗？

多年来，我已经看到了质量保证的标准，这让我感到高兴。随着时间的推移，QA可能成为开发者渴望成为的东西。

简而言之，他们不仅应该熟悉被测试的代码，而且应该有一个与产品架构师相媲美的理解，并且能够有效地与产品所有者/客户进行交互。确保创建的内容实际上是他们想要的。但现在我要进行一场完全独立的对话......

会发生吗？可能比你想象的要快。我已经能够减少进行质量保证所需的人数，提高团队的整体效率，并通过聘请具有开发/建筑背景且具有很强的质量保证能力的非常熟练的人员来提高产品质量。我的运营成本较低，而且由于软件质量较高，我的支持成本较低。 FWIW ...我发现虽然我可以在需要时将QA人员有效地回填到开发角色，但反过来几乎总是不正确。

Answer 12

如果有时间，测试人员一定要查看开发人员代码。这样，您可以改进测试以获得更好的覆盖率。

所以，也许如果你编写你的黑盒子测试看看规范并认为你有时间执行所有这些并且仍然会留下时间，那么通过代码并不是一个坏主意。

基本上这一切都取决于你有多少时间。你可以做的另一件事就是改进报道，看看开发人员的设计文档。那些应该让你很好地了解代码的样子......

测试人员的优势在于熟悉开发代码和测试代码！

Answer 13

我想说他们根本不需要了解内部代码细节。但是，他们确实需要详细了解所需的功能和系统规则 - 就像分析师一样。否则他们将无法测试所有功能，或者在系统出现异常时无法实现。

Answer 14

对于用户验收测试，测试人员无需了解应用程序的内部代码详细信息。他们只需要知道预期的功能，业务规则。报告错误时

修复错误的人应该知道各种功能之间的相互依赖性。

测试人员应该了解代码的内部细节多少？

14 个答案: