白盒测试的缺点?[关闭]

这既是一个优点,也是一个缺点,因为您正在创建测试来测试特定的代码实现,而不是设计测试来测试在实际情况下如何使用它。所以从根本上说,它并没有捕捉到所有的用例,这就是为什么黑盒测试是对WhitBox的一个很好的补充。

imho,主要的缺点是您的测试计划、执行和覆盖范围更容易受到底层实现中的变更的影响,因此对于回归和验收测试来说就不那么有用了。

白盒测试在较低的层次上是有用的,除了黑盒测试之外,但是如果我只是交付带有白盒测试的软件,我会很紧张。

黑盒测试的优点

• 由于测试人员不必关注应用程序的内部工作,因此创建测试用例更容易。
• 测试用例的开发速度更快,因为测试人员不需要花费时间来识别内部流程;他唯一关注的是用户可以通过GUI使用的各种路径。
• 它使用简单,因为它只关注有效和无效的输入,并确保获得正确的输出。

黑盒测试的缺点

• 不断变化的图形用户界面使得脚本维护变得困难,因为输入可能也在变化。
• 与GUI交互可能会导致测试脚本变得脆弱,并且可能无法持续正确地执行。

白盒测试的优点

• 因为重点是内部工作,所以测试人员可以按照语法识别对象。当图形用户界面经常变化时,这一点很有用。
• 它可以提高测试用例的稳定性和可重用性,前提是应用程序的对象保持不变。
• 通过完全测试每一条路径,测试人员就有可能实现彻底性。

白盒测试的缺点

• 为白盒测试开发测试用例涉及高度的复杂性,因此开发测试用例需要高度熟练的人员。
• 虽然在很大程度上,在白盒测试中克服了脆弱性,但是对象名称的更改可能导致测试脚本的中断。

白盒测试imho的最大缺点是所需的时间。程序员和测试人员的时间是昂贵的。最好是先用更广泛的测试方法抓住阻止错误的大秀。

见 Should one test internal implementation, or only test public behaviour?

关于之前两次评估的一些想法:

缺点。。。测试人员需要知道并理解代码

测试计划、执行和覆盖范围更容易受到底层实现中的更改的影响。

这取决于开发人员是否还承担测试实现角色。也就是说,如果开发人员应该理解测试框架或体系结构,并负责编写内部测试tap并将它们正确连接起来,那么测试仍然是白盒,但没有我们通常想到的大多数缺点。在这种情况下,缺点是很难找到合格的开发人员,或者它将改变开发人员和测试人员的责任。

最近的趋势,如测试驱动、敏捷等,越来越多地促进了开发人员测试。更进一步,将把测试框架连接到单元测试上。从这个意义上讲,白盒的劣势将是,组织混乱所造成的角色变化所导致的人。