我们知道有许多测试标准。例如: 1)语句准则,2)分支准则,3)路径准则。我的问题是:
( 1)我们在哪里使用这些度量?我的意思是,我们是否只在白盒测试和单元测试中使用它们?由于这些度量涉及代码的结构,所以我认为它们更多的是与白盒和单元测试有关,而不是处理模块/系统整体的黑箱测试和系统测试,以及处理模块/系统之间接口的集成测试。
2)为什么我们首先需要白盒测试?白盒测试基于它的代码结构测试模块做什么,我认为作为软件工程师,如果模块/系统做用户想做的事情(黑盒测试),对我们来说什么是重要的?
发布于 2019-12-09 20:23:23
1)我们应该在哪里使用这些措施.因为这些度量涉及代码的结构..。更多与白盒和单元测试相关。
白盒测试不仅仅是单元测试。主要是手工测试。每次我运行、阅读或梦见我编写的代码时,它都是一个白盒测试。
我添加了一个自动测试,这样我就可以不去想它了,只需要让它运行。在创建自动测试时,我非常努力地避免利用我的白盒透视图。一个与我现在所知道的实现细节相关联的自动化测试,除非它实际上阻止重构(这不是一件好事),否则不会在重构中存活。一个只依赖于稳定接口的自动化测试可以在许多重构中生存下来。这一点很重要,因为如果我不能重新运行测试,那么编写它就是浪费时间。最好是手动运行它。
行为测试、单元测试和集成测试也是如此。这就是自动化的本质。
2)为什么做首先需要白盒测试?
因为在将system.out.print1n("Hello bug");交给其他人进行黑匣子测试之前,在不检查它是否有效的情况下编写它是非常不礼貌的。就像我的英语老师曾经说的,“你在给我看之前看过这个吗?”
使它成为白盒测试的是知道它是如何工作的,而不是只知道它需要做什么(比如黑匣子测试)。知道它的工作原理并不能阻止你进行测试。它只是改变了你的观点。
如果您不知道白盒测试是如何进行开发的,那么完全有可能取消它。也许你可以用人工智能来实现它。定义你需要什么,摇它直到你得到你想要的。谁在乎它是怎么变成这样的?
根据我的经验,当知道bug是如何工作的(即使在AI中),早期发现它时,修复bug要便宜得多。等到我去度假后,忘记了我们是如何建立排队系统的,这是一个告诉我排队系统挂起的糟糕时刻。走之前让我来测试一下。
https://softwareengineering.stackexchange.com/questions/402270
复制相似问题