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?
标签:
smoke-testing
相关问题
- Confusion about sanity testing of software [closed
-
Why does
work but doesnt? - Check If System Is Connected To Kafka
- Automatically smoke test all webpages in applicati
- Are regression tests the entire test suite or a sa
相关文章
- Confusion about sanity testing of software [closed
-
Why does
work but doesnt? - 自动烟雾测试应用中的所有网页,部署后(Automatically smoke test all we
- Check If System Is Connected To Kafka
- Automatically smoke test all webpages in applicati
- Are regression tests the entire test suite or a sa
- What is a sanity test/check
- What is a smoke testing and what will it do for me
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.
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... :)
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.
Turn it on, see if any smoke comes out.
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.
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.