短期/长期场景中的单元测试与探索性测试
您认为单元测试和探索性测试哪个能给产品带来更多价值？
我知道这两种测试都有不同的一般目的，但是您会优先考虑哪个测试，即您首先要做什么，其次要做什么，是单元测试还是探索性测试？
另外，哪一个在短期内支付的福利更多？从长远来看？
最后，如果您只有时间进行两者之一，您的答案会改变吗？
What do you think brings more value to the product, Unit Test or Exploratory Test?
I understand that both tests serve different general purposes, but what test would you prioritize, i.e. what would you do first and what second, Unit or Exploratory?
Also, which one pays more benefits in the short term? and in the long term?
Finally, would your answer change if you had only time for one of the two?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，两者都很关键。我遵循 TDD 方法，因此单元测试形成了我的代码的可执行规范。单元测试必须首先完成，但在这个过程中，我经常发现自己在进行某种形式的探索性测试来创建通过的单元测试。此外，有些东西——例如界面设计——如果不进行某种形式的探索就无法完全开发。是的，在许多情况下，您可以开发单元测试来确保界面元素按照预期的方式运行，但您通常需要了解不同元素如何交互，然后才能确定它们应该互动。探索不同的场景并根据反馈调整测试脚本是设计的重要组成部分。
对于非界面工作，我会首先进行单元测试，并根据需要进行探索性测试。对于界面工作，我会进行原型设计和探索，然后开发单元（脚本化）测试（如果有的话）。这部分是由于每个领域的测试工具的功能，但这也与正在完成的工作类型有关。
至于好处，很难比较，因为它们提供不同种类的好处。两种类型的测试都可以发现并消除缺陷，但单元测试（使用 TDD）也可以指导和改进应用程序的设计和结构。通过改进设计，我们还提高了可维护性。在我看来，探索性测试主要提高了应用程序的可用性，尽管它可以用来评估我们的设计决策是否真正按照我们期望的方式工作，并随着设计的发展而验证设计。
我的观点是，单元测试更为基础，因为它们提供了一个安全网，所有其他测试都可以从中产生变化。从这个意义上说，它们更重要，但在现实环境中，两者都缺一不可。此外，这些并不是唯一的两种类型的测试，它们也不能像单元测试和集成测试一样直接进行比较。如果您想使用调试器，您可以进行探索性的单元测试。
我可以想象您没有时间进行自动化、脚本化测试的场景，但这些都是边缘情况，至少对我来说是这样。我无法想象即使使用手动探索性测试我也不会进行某种程度的单元测试的场景。实际上，在不需要进行某种级别的单元测试之前，应用程序必须非常简单。
In my opinion both are critical. I follow a TDD methodology, so unit tests form an executable specification of my code. Unit tests must be done first, but often in the process I find myself doing some forms of exploratory testing to create my passing unit test. Further, there are somethings -- interface design, for example -- that cannot be fully developed without some form of exploration. Yes, you can in many cases develop unit tests to ensure that interface elements operate the way they are expected to, but you often need to see how different elements do interact before you can determine how they should interact. Exploring different scenarios and adjusting the test script based on feedback is an important part of the design.
For non-interface work, I would do unit tests first and exploratory tests as needed. For interface work, I would prototype and explore, then develop unit (scripted) tests after, if at all. This is partly due to the capabilities of test tools in each space, but that is related to the type of work being done as well.
As to benefits, it's hard to compare because they provide different kinds of benefits. Both types of testing can find and eliminate defects, but unit testing (using TDD) guides and improves the design and structure of the application as well. By improving the design, we also improve maintainability. Exploratory testing, in my opinion, primarily improves the usability of the application, though it can be used to evaluate whether our design decisions actually work the way we expect and validate the design as it evolves.
My opinion is that unit tests are more foundational in that they provide a safety net from which all other tests can work to produce change. In that sense they are more important, but you cannot do without either in a realistic environment. Also, these aren't the only two types of testing, nor are they really directly comparable, in the same way as unit and integration tests are. You can do unit tests that are explorations if you want using the debugger.
I can imagine scenarios in which you wouldn't have time to do automated, scripted tests but these are edge cases, at least for me. I can't imagine a scenario where I wouldn't do some level of unit testing even if using manual, exploratory tests. The application would have to be dead simple, indeed, before some level of unit testing isn't necessary.