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

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

对于功能系统测试,测试人员可以并且可能应该忽略实现的细节——如果他们知道细节,他们可能会在无意中在他们的测试策略中解释这些细节,并且没有正确地测试产品。

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

这听起来类似于前面的问题: Should QA test from a strictly black-box perspective?

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

我会断言,有一些自以为是的谬论,即一个知情的测试人员比一个技术性很强的测试人员更合适,甚至更好,因为:

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

您在这里看到的是黑盒(不了解内部)、白盒(所有知识)和灰盒(一些精选知识)之间的区别。

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

这些测试用例正在确定组件是否能够适当地处理依赖项的可用性不足。它还可以用于识别与性能相关的问题。

例如: 作为测试人员,如果我知道Web UI组件将请求推迟到执行实际工作的编排服务,那么我可以构建编排需要很长时间(高负载)的场景。如果用户随后执行另一个请求(模拟用户不耐烦),那么Web服务将在第一个请求仍在运行时接收第二个请求。如果我们不断重复这个过程,Web服务最终会因压力而消亡。如果不知道底层模型,就很难找到问题所在。

在大多数情况下,对于功能性测试,最好使用黑盒,当您转向非功能性或系统集成时,了解交互可以帮助确保适当的测试覆盖率。

并不是所有的测试人员都是熟练的或舒适的工作/理解组件交互或内部结构,所以它是基于每个测试人员/每个系统的,取决于它是否合适。

在几乎所有的情况下,我们从黑匣子开始,并根据需要朝着白色的方向前进。

测试人员不需要知道内部细节。

应用程序应该在不了解内部结构、开发问题、外部依赖性的情况下进行测试。

如果你用这些额外的信息拖累测试人员,你就把他推到一个特定的测试方案中,而测试人员不应该被推到一个方向,他应该只从一个非编码人员的角度进行测试。

有多种测试方法需要代码评审,而那些方法不需要代码评审。

白盒测试(即读取代码)的优点是,您可以将测试定制为您知道(通过读取代码)将失败的测试区域。

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

黑盒测试(即不读取代码)也可以是好的(或更好的?)在发现比白盒的错误。

通常这两种类型的测试都可以发生在一个项目上,开发人员的白盒单元测试和测试人员的黑盒集成测试。

对于最终测试方案,我更喜欢黑盒测试 在一个理想的世界里…

• 测试人员不应该知道代码的内部结构。
• 他们应该知道客户将要做的一切,即拥有使用系统/应用程序所需的文档/帮助。(如果是某种代码交付,则明确包括API描述/文档)

如果测试人员无法通过这些限制找到缺陷,那么您还没有足够的文档记录您的API/应用程序。

如果他们是专门的测试人员(他们唯一做的事情),那么我认为他们应该尽可能少地了解他们试图测试的代码。

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

也就是说,我认为开发人员是优秀的测试人员,因为我们往往知道某些类型功能的边缘情况。

下面是一个bug的例子,如果您不知道代码的内部结构,就无法找到它,因为您无法测试所有输入:

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

然而,在这种情况下,如果测试人员将100%的代码覆盖率作为目标,并且只查看足够的内部构件来编写测试来实现这一点,就可以发现这一点。

下面是一个bug的例子,如果你 做 知道代码的内部结构,因为错误的信心是可以传染的。尤其是,代码的作者通常不可能编写一个捕获此错误的测试:

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

如果myconnect的文档没有提到必须绑定套接字,那么有一天会发生意外情况(有人会称之为unbound,而套接字实现可能会选择一个任意的本地地址)。但是能够看到代码的测试人员往往没有“测试”文档的思想。除非它们确实在形式上,否则它们不会注意到在文档中没有提到的代码中有一个假设,并且只接受这个假设。相反,一个从文档中编写的测试人员可以很容易地发现这个bug,因为他们会认为“套接字可能处于什么状态?”我会为每个人做一个测试。由于没有提到任何约束,他们没有理由不尝试失败的案例。

回答:两者都做。一种方法是 在看到/编写代码之前编写一个测试套件 ,然后添加更多的测试来覆盖您在实现中引入的任何特殊情况。这适用于测试人员是否与程序员是同一个人,尽管很明显,如果程序员编写了第二种测试,那么组织中只有一个人必须理解代码。只有一个人能理解代码是否是一个好的长期策略是有争议的,但是它是广泛存在的,因为它确实可以节省时间,让一些东西走出家门。

[编辑:我拒绝透露这些bug是如何产生的。也许第一个接口的程序员在临床上是精神错乱的,而第二个接口对所使用的端口有一些限制,以解决已知会发生的一些奇怪的网络设置,而这个接口应该是通过一些在一般的sockets文档中提到的去规范化API创建的,但是他们忽略了R。平衡使用。显然,在这两种情况下,程序员都非常粗心。但这并不影响要点:示例不需要现实,因为如果您不捕获只有非常粗心的程序员才会生成的错误,那么您就不会捕获代码中的所有实际错误,除非您从来没有过糟糕的一天,否则会犯疯狂的错别字等。]

我想这取决于你想要的测试有多好。如果你只是想清醒地检查常见的场景,那么无论如何,只要给测试人员/吃比萨的人应用程序,并告诉他们疯狂。

但是,如果您希望有机会发现边缘案例、性能或负载问题,或者隐藏在代码深度中的大量其他问题,那么最好雇佣知道如何以及何时使用白盒技术的测试人员。

你的电话。

imho,我认为测试人员的行业观点是完全错误的。

想想看…你有两个水管工,一个经验非常丰富,知道所有的规则和建筑规范,并且能很快看到一些东西,知道工作是否做得对。另一个管道工很好,能可靠地完成工作。

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

这些年来,我已经看到了质量保证的门槛越来越高,这让我很高兴。随着时间的推移,QA可能会成为开发人员所渴望的东西。

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

会发生吗?可能比你想象的要早。我已经能够减少进行QA所需的人员数量,提高团队的整体效率,并且仅仅通过雇佣具有开发/架构师背景且有很强的QA能力的非常熟练的人员来提高产品质量。我有较低的操作成本,而且由于软件的输出质量更高,我最终得到的支持成本更低。FWW…我发现,尽管我可以在需要的时候有效地将QA人员替换为开发人员角色,但事实往往恰恰相反。

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

因此,如果您编写黑盒测试来查看规范,并且认为您有时间执行所有这些测试,并且仍将有时间,那么完成代码并不是一个坏主意。

基本上,这取决于你有多少时间。您可以做的另一件事是查看开发人员设计文档来提高覆盖率。这些应该能让您很好地了解代码的外观……

测试人员的优势是熟悉开发代码和测试代码!

我想说他们根本不需要知道内部代码的细节。然而,他们确实需要像分析师一样全面详细地了解所需的功能和系统规则。否则,它们不会测试所有的功能,也不会在系统出现错误时意识到。

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

修复bug的人应该知道各种特性之间的相互依赖性。