continuous-integration - 烟雾测试应该有多复杂？

Question

因此，在这一点上，我们已经在当前项目上运行了很多个月的每日构建。不过，与日常构建一起进行的冒烟测试并不是很复杂——我们在我们的主类库上运行了一些 nUnit 测试（诚然，它并没有提供很好的代码覆盖率），并且我们确保事情可以编译并建造。有问题的应用程序是一个 ASP.NET 站点，它使用一些业务对象（包括 LINQ-to-SQL）。

我们是否应该运行更复杂的冒烟测试，尤其是在 ASP.NET 站点上？就此而言，我们将如何为 ASP.NET 站点开发冒烟测试？

Answer 1

除了单元测试之外，最好将站点启动到带有一些示例数据的登台服务器。尽可能接近生活。然后使用 HTTP 流量生成脚本来模拟用户流量和会话。您可以在后端监控调试日志、异常和其他测试代码。您还可以在此处进行性能测量。

就像你自己在浏览器中使用它的更激烈的迭代版本一样。

您可以通过定义（或通过检查）您的公共资源及其输入来做到这一点。然后，这些脚本可以尝试并导致验证问题、站点流程的奇怪排列以及在实时设置中测试站点整个上下文的其他事情。

如果测试不完整……从单元测试到“它是否与真实数据和流量配合得很好”，那么您最终将像无头鸡一样在稍后修复错误。

Answer 2

从本质上讲，冒烟测试应该是肤浅的：它可以编译吗？部署？欢迎页面是否加载？也许加载一个测试页面，该页面对数据库进行查询以查看此连接是否也有效。就是这样。

Answer 3

你不应该做冒烟测试。你知道这个词的词源吗？电子产品中的“烟雾测试”是指您打开电源并查看是否有烟雾冒出。

您应该进行更全面的单元测试；足以为您提供良好的代码覆盖率。这是您在每次构建时都应该执行的操作。您还应该尝试进行部署，并运行一些“安装验证测试”。