什么是单位测试，集成测试，烟雾测试，回归测试？
https://stackoverflow.com/questions/520064
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
什么是单位测试，集成测试，烟雾测试，回归测试以及它们之间有什么区别？我可以为它们使用哪些工具？
例如，我将Junit和Nunit用于单元测试和集成测试。是否有烟雾测试或回归测试工具？
解决方案
单元测试: ：指定并测试类单个方法的合同的一个点。这应该具有非常狭窄且定义明确的范围。复杂的依赖性和与外界的互动是 顽固或嘲笑.
集成测试: ：测试多个子系统的正确操作。那里有整个频谱，从两个类之间的测试集成到测试与生产环境的集成。
烟雾测试（又名理智检查）: ：一个简单的集成测试，我们只检查调用正在测试的系统时，它会正常返回并且不会爆炸。
回归测试: ：修复错误时编写的测试。它确保了此特定错误不会再次发生。全名是“非回归测试”。它也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。
对此，我会补充：
验收测试: ：测试是否正确实现了功能或用例。它类似于集成测试，但重点是提供用例，而不是涉及的组件。
系统测试: ：测试系统作为黑匣子。在测试期间，对其他系统的依赖性通常是模拟或固执的（否则，它将更多地是集成测试）。
飞行前检查: ：在类似生产的环境中重复的测试，以减轻“在我的机器上建立”综合征。通常，这是通过在像环境这样的生产中进行接受或烟雾测试来实现的。
其他提示
- 单元测试: ：自动测试以测试课程的内部工作。它应该是与其他资源无关的独立测试。
- 集成测试: ：在环境上进行的自动测试，类似于单位测试，但具有外部资源（DB，磁盘访问）
- 回归测试: ：实现新功能或错误修复后，您可以重新测试过去有效的情况。在这里，您涵盖了新功能破坏现有功能的可能性。
- 烟雾测试: ：首先测试哪些测试人员可以得出结论，他们是否将继续测试。
每个人的定义都会略有不同，并且通常有灰色区域。然而：
- 单位测试：这是否有点（尽可能孤立）起作用？
- 集成测试：这两个（或更多）组件是否可以一起工作？
- 烟雾测试：整个系统（尽可能接近生产系统）是否合理地挂在一起？ （即，我们是否有理由确信它不会产生黑洞？）
- 回归测试：我们是否无意中重新引入了我们以前修复的任何错误？
我刚刚意识到的一个新测试类别是：
金丝雀测试
一个 金丝雀测试 是一种自动化的，无损的测试 定期运行 在一个 居住 环境，如果它失败了，那么确实发生了一些不好的事情。示例可能是：
- 具有只能在DEV/TEST中可用的数据出现在LIVE中。
- 有背景过程无法运行
- 用户登录可以吗
伪经历史琐事：“烟雾测试”来自海底工程（从管道上继承），在那里，字面的烟雾将被泵入船体，以查看是否再次出现，这对海底来说是巨大的失败！
Unit test: Verifying that particular component (i.e.,class) created or modified functions as designed. This test can be manual or automated but does not move beyond the boundary of the component.
Integration test: Verifying that the interaction of particular components function as designed. Integration tests can be performed at the unit level or the system level. These tests can be manual or automated.
Regression test: Verifying that new defects are not introduced into existing code. These tests can be manual or automated.
Depending upon your SDLC (waterfall, rup, agile, etc) particular tests may be performed in 'phases' or may all be performed, more or less, at the same time. For example, unit testing may be limited to developers who then turn the code over to testers for integration and regression testing. However another approach might have developers doing unit testing and some level of integration and regression testing (using a TDD approach along with continuous integration and automated unit and regression tests).
The tool set will depend largely on the codebase but there are many open source tools for unit testing (JUnit). HP's (mercury) QTP or Borland's Silktest are both tools for automated integration and regression testing.
unit test: testing of individual module or independent component in an application is known to be unit testing , the unit testing will be done by developer.
integration test: combining all the modules and testing the application to verify the communication and the data flow between the modules are working properly or not , this testing also performed by developers.
smoke test IN smoke test they check the application in shallow and wide manner, In smoke testing they check the main functionality of the application , if there is any blocker issue in the application they will report to developer team , and developing team will fix it and rectify the defect, and give it back to testing team and now testing team will check all the modules to verify tat changes made in one module will impact the other module or not. IN SMOKE TESTING the test cases are scripted
regression testing executing the same test cases repeatedly to ensure tat the unchanged module does not cause any defect. REGRESSION TESTING comes under functional testing
REGRESSION TESTING-
"A regression test re-runs previous tests against the changed software to ensure that the changes made in the current software do not affect the functionality of the existing software."
Unit testing is directed at the smallest part of the implementation possible. In java this means you are testing a single class. If the class depends on other classes these are faked.
When your test calls more than one class, its an integration test.
Full test suites can take a long time to run, so after a change many teams run some quick to complete tests to detect significant breakages. For example, you have broken the URIs to essential resources. These are the smoke tests.
Regression tests run on every build and allow you to refactor effectively by catching what you break. Any kind of test can be regression test, but I find unit tests are most helpful finding the source of fault.
Unit test: Verifying that particular component (i.e.,class) created or modified functions as designed. This test can be manual or automated but does not move beyond the boundary of the component.
Integration test: Verifying that the interaction of particular components function as designed. Integration tests can be performed at the unit level or the system level. These tests can be manual or automated.
Regression test: Verifying that new defects are not introduced into existing code. These tests can be manual or automated.
Depending upon your SDLC (waterfall, rup, agile, etc) particular tests may be performed in 'phases' or may all be performed, more or less, at the same time. For example, unit testing may be limited to developers who then turn the code over to testers for integration and regression testing. However another approach might have developers doing unit testing and some level of integration and regression testing (using a TDD approach along with continuous integration and automated unit and regression tests).
One type of test that seems to be worth mentioning in this thread is stress/performance/load tests which could be simply put as finding out the limits beyond which a certain piece of software breaks. Note that in terms of tooling it is essential to precisely determine the scope of what one proposes to stress tests from a system perspective. For instance in the case of a "web application" stress testing can include in its scope the web server application itself and so the tooling could intervene on that end. Here is a nice post about http load testing
- Integration Testing : Integration Testing is the Integrate the Another Element
- Smoke Testing : Smoke Testing is also known as build version Testing.Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing.
- Regression Testing : Regression Testing is Reapeated Testing. Whether new software is effected in another module or not.
- Unit Testing : It is a White box Testing .Only Developers involve in it
Unit Testing:- unit testing is usually done by the developers side,where as testers are partly evolved in this type of testing where testing is done unit by unit. In java Junit test cases can also be possible to test whether the written code is perfectly designed or not.
Integration Testing:- This type of testing is possible after the unit testing when all/some components are integrated.This type of testing will make sure that when components are integrated,do they affect each others working capabilities or functionalists.
Smoke Testing:- This type of testing is done at the last when system is integrated successfully and ready to go on production server. This type of testing will make sure that every important functionality from start to end is working fine and system is ready to deploy on production server.
Regression Testing:- This type of testing is important to test that unintended/unwanted defects are not present in the system when developer fixed some issues. This testing also make sure that all the bugs are successfully solved and because of that no other issues are occurred.
Unit Testing: It always performs by developer after their development done to find out issue from their testing side before they make any requirement ready for QA.
Integration Testing: It means tester have to verify module to sub module verification when some data/function output are drive to one module to other module. Or in your system if using third party tool which using your system data for integrate.
Smoke Testing: tester performed to verify system for high-level testing and trying to find out show stopper bug before changes or code goes live.
Regression Testing: Tester performed regression for verification of existing functionality due to changes implemented in system for newly enhancement or changes in system.
Smoke and sanity testing are both performed after a software build to identify whether to start testing. Sanity may or may not be executed after smoke testing. They can be executed separately or at the same time - sanity being immediately after smoke.
Because sanity testing is more in-depth and takes more time, in most cases it is well worthed to be automated.
Smoke testing usually takes no longer than 5-30 minutes for execution. It is more general: it checks a small number of core functionalities of the whole system, in order to verify that the stability of the software is good enough for further testing and that there are no issues, blocking the run of the planned test cases.
Sanity testing is more detailed than smoke and may take from 15 minutes up to a whole day, depending on the scale of the new build. It is a more specialized type of acceptance testing, performed after progression or re-testing. It checks the core features of certain new functionalities and/or bug fixes together with some closely related to them features, in order to verify that they are functioning as to the required operational logic, before regression testing can be executed in larger scale.
Some good answers already but I would like further refine them:
Unit testing is the only form of white box testing here. The others are black box testing. White box testing means that you know the input, you know the inner workings of the mechanism and can inspect it and you know the output. With black box testing you only know what the input is and what the output should be.
So clearly unit testing is the only white box testing here.
- Unit testing test specific pieces of code. Usually methods.
- Integration testing test whether your new feature piece of software can intergrate with everything else.
- Regression testing. This is testing done to make sure you haven't broken anything. Everything that used to work should still work.
- Smoke testing is done as a quick test to make sure everything looks okay before you get involved in the more vigorous testing.
Regression test - Is a type of SW testing where we try to cover or check around the bug Fix. the functionality around the bug fix should not get changed or altered due to the Fix provided. Issues found in such process are called as Regression Issues.
Smoke Testing : Is a kind of testing done to decide whether to accept the Build/Software for further QA testing .
Smoke test has been explained here already and is simple. Regression test comes under integration test.
Automated tests can be divided into just 2.
Unit test and Integration Test. (this is all that matters)
I would call use the phrase "long test"(LT) for all tests like integration test, functional test, regression test, UI test , etc. And unit test as "short test".
A LT example could be, automatically loading a web page, logging in to the account and buying a book. If the test passes it is more likely to run on live site the same way(hence the 'better sleep' reference). Long = distance between web page(start) and database(end).
And this is a great article discussing the benefits of integration testing(long test) over unit testing
Unit tests Unit tests are very low level, close to the source of your application. They consist in testing individual methods and functions of the classes, components or modules used by your software. Unit tests are in general quite cheap to automate and can be run very quickly by a continuous integration server.
Integration tests Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.
Functional tests Functional tests focus on the business requirements of an application. They only verify the output of an action and do not check the intermediate states of the system when performing that action.
There is sometimes a confusion between integration tests and functional tests as they both require multiple components to interact with each other. The difference is that an integration test may simply verify that you can query the database while a functional test would expect to get a specific value from the database as defined by the product requirements.
End-to-end tests End-to-end testing replicates a user behavior with the software in a complete application environment. It verifies that various user flows work as expected and can be as simple as loading a web page or logging in or much more complex scenarios verifying email notifications, online payments, etc...
End-to-end tests are very useful, but they're expensive to perform and can be hard to maintain when they're automated. It is recommended to have a few key end-to-end tests and rely more on lower level types of testing (unit and integration tests) to be able to quickly identify breaking changes.
Acceptance testing Acceptance tests are formal tests executed to verify if a system satisfies its business requirements. They require the entire application to be up and running and focus on replicating user behaviors. But they can also go further and measure the performance of the system and reject changes if certain goals are not met.
Performance testing Performance tests check the behaviors of the system when it is under significant load. These tests are non-functional and can have the various form to understand the reliability, stability, and availability of the platform. For instance, it can be observing response times when executing a high number of requests, or seeing how the system behaves with a significant of data.
Performance tests are by their nature quite costly to implement and run, but they can help you understand if new changes are going to degrade your system.
Smoke testing Smoke tests are basic tests that check basic functionality of the application. They are meant to be quick to execute, and their goal is to give you the assurance that the major features of your system are working as expected.
Smoke tests can be useful right after a new build is made to decide whether or not you can run more expensive tests, or right after a deployment to make sure that they application is running properly in the newly deployed environment.
source: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
I just wanted to add and give some more context on why we have these levels of test, what they really mean with examples
Mike Cohn in his book “Succeeding with Agile” came up with the “Testing Pyramid” as a way to approach automated tests in projects. There are various interpretations of this model. The model explains what kind of automated tests need to be created, how fast they can give feedback on the application under test and who writes these tests. There are basically 3 levels of automated testing needed for any project and they are as follows.
Unit Tests- These test the smallest component of your software application. This could literally be one function in a code which computes a value based on some inputs. This function is part of several other functions of the hardware/software codebase that makes up the application.
For example - Let’s take a web based calculator application. The smallest components of this application that needs to be unit tested could be a function that performs addition, another that performs subtraction and so on. All these small functions put together makes up the calculator application.
Historically developer writes these tests as they are usually written in the same programming language as the software application. Unit testing frameworks such as JUnit and NUnit (for java), MSTest (for C# and .NET) and Jasmine/Mocha (for JavaScript) are used for this purpose.
The biggest advantage of unit tests are, they run really fast underneath the UI and we can get quick feedback about the application. This should comprise more than 50% of your automated tests.
API/Integration Tests- These test various components of the software system together. The components could include testing databases, API’s (Application Programming Interface), 3rd party tools and services along with the application.
For example - In our calculator example above, the web application may use a database to store values, use API’s to do some server side validations and it may use a 3rd party tool/service to publish results to the cloud to make it available across different platforms.
Historically a developer or technical QA would write these tests using various tools such as Postman, SoapUI, JMeter and other tools like Testim.
These run much faster than UI tests as they still run underneath the hood but may consume a little more time than unit tests as it has to check the communication between various independent components of the system and ensure they have seamless integration. This should comprise more that 30% of the automated tests.
UI Tests- Finally, we have tests that validate the UI of the application. These tests are usually written to test end to end flows through the application.
For example - In the calculator application, an end to end flow could be, opening up the browser-> Entering the calculator application url -> Logging in with username/password -> Opening up the calculator application -> Performing some operations on the calculator -> verifying those results from the UI -> Logging out of the application. This could be one end to end flow that would be a good candidate for UI automation.
Historically, technical QA’s or manual testers write UI tests. They use open source frameworks like Selenium or UI testing platforms like Testim to author, execute and maintain the tests. These tests give more visual feedback as you can see how the tests are running, the difference between the expected and actual results through screenshots, logs, test reports.
The biggest limitation of UI tests is, they are relatively slow compared to Unit and API level tests. So, it should comprise only 10-20% of the overall automated tests.
The next two types of tests can vary based on your project but the idea is-
Smoke Tests
This can be a combination of the above 3 levels of testing. The idea is to run it during every code check in and ensure the critical functionalities of the system are still working as expected; after the new code changes are merged. They typically need to run with 5 - 10 mins to get faster feedback on failures
Regression Tests
They usually are run once a day at least and cover various functionalities of the system. They ensure the application is still working as expected. They are more details than the smoke tests and cover more scenarios of the application including the non-critical ones.
