什么是冒烟测试？它对我有什么作用？
我以为我理解烟雾服务器用于持续集成来衡量项目的性能和测试覆盖率。 这基本上是正确的吗？ 对程序进行冒烟测试意味着什么？ 它是否仅仅意味着持续应用烟雾服务器上定义的测试，以便能够查明特定时间范围内的性能下降情况？
这个其他问题确实描述了之间的区别健全性测试和烟雾测试，但不要求定义烟雾测试。 这个问题比参考问题早很多年。
I thought I understood that a smoke server was used for continous integration to measure the performance and test coverage of a project. Is this basically correct? What does it mean to smoke-test a program? Does it simply mean to continously apply the tests defined on the smoke server to be able to pinpoint performance degradation to a particular time frame?
This other question does describe the difference between sanity testing and smoke testing but does not ask to define smoke testing. This question is many years older than the reference question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
冒烟测试不是性能测试或回归预防测试。
冒烟测试是一组最高优先级的全自动测试。 即使您的常规构建成功，您的产品也可能会以非常根本的方式被破坏，导致其 100% 无法使用。 冒烟测试旨在测试该级别的核心功能。 未通过冒烟测试的构建很可能无法通过大部分自动化测试。
如果冒烟测试失败，通常意味着您正在失去生产力，因为构建不可用、无法测试等。冒烟测试失败往往需要立即修复，修复时间为数小时而不是数天。
冒烟测试的一个重要方面是它们可以快速运行。 您应该始终运行某种形式的冒烟测试。 许多团队都有足够的资源在日常或持续集成构建中运行更大的测试套件（这是好事），但冒烟测试应被视为最低限度。
Smoke testing isn't performance testing or regression prevention testing.
Smoke testing is a set of your highest priority fully automated tests. Even if your regular build succeeds, it's possible for your product to be broken in very fundamental ways that make it 100% unusable. Smoke tests are designed to test that level of core functionality. A build that doesn't pass smoke tests is very likely to fail a majority of all of your automated tests.
If a smoke test fails that generally means that you're losing productivity because the build is not usable, can't be tested, etc. Smoke test failures tend to require immediate fixes, on the order of hours not days.
The important aspect about smoke tests is that they can be run quickly. You should ALWAYS be running smoke tests of some sort. Many groups have sufficient resources to run a larger suite of tests on their daily or continuous integration builds (which is goodness), but smoke tests should be considered the bare minimum.
关于冒烟测试的维基百科页面实际上相当不错。
它包含指向 IEEE Software 13(4), 1996 的最佳实践部分中 Steve McConnel（“代码完整”）论文的指针，标题为 “每日构建和冒烟测试”。
我想说，冒烟测试是单元测试和其他形式测试的先决条件：如果冒烟测试失败，那么启动单元测试就没有意义了。
The wikipedia page on smoke testing is actually quite good.
It includes a pointer to Steve McConnel's ("Code Complete") paper in the best practices section of IEEE Software 13(4), 1996 titled "Daily Build and Smoke Test".
I'd say smoke testing is a precondition to unit and other forms of testing: if the smoke test fails there's no point in even starting up a unit test.
我们使用术语冒烟测试来指对应用程序或产品进行快速基本测试的测试，以使其有资格进行进一步的测试，例如集成测试或功能测试。 如果应用程序无法完成这些高级测试所需的一些基本操作，那么进行集成测试或其他高级测试就没有多大用处。 例如，我们有一个基于 Web 的应用程序，我们进行冒烟测试以确保我们可以加载所有网页，让用户登录/注销等。这些是应该与应用程序一起使用以使其可测试的基本内容。 如果页面甚至无法加载，或者用户甚至无法登录，我们就无法在功能或集成测试方面做太多事情。 我们对每个构建进行冒烟测试，然后进行功能和集成测试。
We use the term smoke test to refer to a testing that does quick basic tests to an application or product to make it qualify for further testing like integration testing or functionality testing. It is of little use to do integration testing or other adavanced testing if the application fails to do some of the elementary things required for these advanced testing. For instance we have a web based application and we do smoke test to ensure we can load all the web pages, lets users to login/logout etc. These are the basic things that should work with the application to make it testable. If the pages do not even load or if the users could not even login, we cannot do much with functionality or integration testing. We do smoke testing with every build followed by functionality and integration testing.
冒烟测试是集成测试的第一步。 作为开发人员，您已将所有部分放在一起，并确保您的应用程序能够运行，然后再将其交给您的 QA 团队进行“真正的”测试。
我想写更多，但 MahdeTo 打败了我，给了我一个正确的答案......:)
Smoke testing is the first step of integration testing. As a developer, you've put all the parts together and you're making sure your app will run before giving it to your QA team for "real" testing.
I wanted to write more, but MahdeTo beat me to a correct answer... :)
*在进行测试之前检查应用程序的基本和关键功能称为冒烟测试。
*在冒烟测试中，我们检查基本和关键功能的积极流程，以检查构建是否可测试。
*checking the basic and critical feature of an application before proceeding the testing is known as smoke testing.
*In smoke testing we check the positive flow of basic and critical feature to check if the build is testable or not.
我同意之前的一些答案。 对我来说，冒烟测试只是检查我的数千个子页面和重定向是否仍然有效。
工作是指各子页面的状态码为“200 OK”。
我尽可能晚地进行冒烟测试。 在将代码部署到服务器之后和激活该服务器之前。
如今，甚至有在线服务 (SaaS) 可以帮我完成这项工作。 https://www.smest.it 帮助我进行烟雾测试。 我刚刚在他们的主页上输入了一次我的私人域名，自从我每天检查我的网站以来。 完全没有压力。
I agree with some of the previous answers. To me, Smoke Testing is simply a check if all my X thousands of sub-pages and redirects are still working.
Working means that the status code of each sub-page is "200 OK".
I run Smoke Tests as late as possible. After I deployed my code to the server and before I take this server active.
Today there is even an online service (SaaS) doing the job for me. https://www.smest.it helps me with Smoke Testing. I just entered once my private domain on their homepage and ever since I get my website checked daily. No stress at all.
冒烟测试也可以称为构建验证测试或构建验收测试，如果冒烟测试失败则意味着构建不可用并且不能被接受，这个缺陷需要立即以高优先级修复
Smoke testing can also be called build verification testing or build acceptance testing, if smoke testing fails it means build is not usable and can not be accepted , this defect needs to be fixed immediately on high priority
来自维基百科
From Wikipedia
冒烟测试是一组在实际测试之前进行的基本且廉价的测试。 它的目的是验证构建是否已成功部署以及所有测试环境。 各方面正在运行并准备好进行实际测试过程。 它可以帮助您将测试的全部愤怒降到错误的构建上，并让您意识到您一直在一个糟糕的环境上进行测试。 或者错误地部署构建可能为时已晚。
Smoke testing is a set of basic cheap to run tests that precede actual testing. It aims to verify that the build is deployed successfully and that all test env. aspects are running and ready for the actual test process. It saves you bringing the full extent of your testing wrath down a faulty build and just realizing that you have been testing on a bad env. or erroneously deployed build possibly too late.
打开电源，看看有没有冒烟。
Turn it on, see if any smoke comes out.
该术语起源于硬件修复，并已应用于软件。 它旨在进行快速测试，以查看应用程序首次运行时是否“着火”。 如上所述，这只是为了确保您不会让一群人浪费在明显损坏的东西上。
The term originates in hardware repair and has been applied to software. It's intended to be a quick test to see if the application "catches on fire" when run for the first time. As stated above it's just to make sure you don't waste a bunch of folks time by setting them loose on something that's obviously broken.