单元测试与短期/长期情景下的探索性测试

时间:2010-11-25 13:36:03

标签: unit-testing testing exploratory

您认为产品,单元测试或探索性测试能带来更多价值吗?

我知道这两种测试都有不同的一般用途,但是你会优先考虑什么样的测试,即你先做什么,第二次做什么?单位或探索?

此外,哪一项在短期内会带来更多好处?从长远来看?

最后,如果你只有两个时间中的一个,你的答案会改变吗?

1 个答案:

答案 0 :(得分:2)

在我看来,两者都很关键。我遵循TDD方法,因此单元测试形成了我的代码的可执行规范。必须首先进行单元测试,但是在这个过程中我经常会进行一些形式的探索性测试来创建我的传递单元测试。此外,还有一些东西 - 例如界面设计 - 如果没有某种形式的探索就无法完全开发。是的,在许多情况下,您可以开发单元测试以确保界面元素按照预期的方式运行,但是在确定它们如何之前,您经常需要了解的不同元素之间的交互方式应该互动。探索不同的场景并根据反馈调整测试脚本是设计的重要部分。

对于非接口工作,我会先进行单元测试,然后根据需要进行探索性测试。对于界面工作,我会进行原型和探索,然后开发单元(脚本)测试,如果有的话。这部分是由于每个空间中的测试工具的功能,但这也与正在完成的工作类型有关。

至于福利,很难比较,因为它们提供不同的好处。两种类型的测试都可以找到并消除缺陷,但是单元测试(使用TDD)也可以指导并改进应用程序的设计和结构。通过改进设计,我们还提高了可维护性。在我看来,探索性测试主要是提高应用程序的可用性,尽管它可用于评估我们的设计决策是否真正按照我们期望的方式工作,并在设计发展过程中对其进行验证。

我认为单元测试更具基础性,因为它们提供了一个安全网,所有其他测试都可以用来产生变化。从这个意义上讲,它们更重要,但在现实环境中你也离不开它们。此外,这些不仅仅是两种类型的测试,它们也不是真正可直接比较的,与单元和集成测试的方式相同。如果要使用调试器,可以进行单元测试。

我可以想象你没有时间做自动化脚本测试的场景,但这些都是边缘情况,至少对我而言。我无法想象即使使用手动,探索性测试,我也不会进行某种程度的单元测试。事实上,在没有必要进行某种程度的单元测试之前,应用程序必须简单易行。