What is a smoke testing and what will it do for me

问题:

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?

回答1:

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.

回答2:

Turn it on, see if any smoke comes out.

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

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.

回答7:

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... :)

回答8:

*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.