단위 테스트, 통합 테스트, 연기 테스트, 회귀 테스트는 무엇입니까?
단위 테스트, 통합 테스트, 연기 테스트, 회귀 테스트는 무엇이며 그 차이점은 무엇입니까? 그리고 각각에 어떤 도구를 사용할 수 있습니까?
예를 들어 단위 테스트 및 통합 테스트에 JUnit과 NUnit을 사용합니다. 연기 테스트 또는 회귀 테스트 도구가 있습니까?
단위 테스트 : 클래스의 단일 메서드 계약의 1 점을 지정하고 테스트합니다. 이것은 매우 좁고 잘 정의 된 범위를 가져야합니다. 외부 세계에 대한 복잡한 종속성 및 상호 작용은 스텁 또는 조롱 됩니다.
통합 테스트 : 여러 하위 시스템의 올바른 상호 운용을 테스트합니다. 두 클래스 간의 통합 테스트에서 프로덕션 환경과의 통합 테스트에 이르기까지 전체 스펙트럼이 있습니다.
스모크 테스트 (일명 Sanity 검사) : 테스트중인 시스템이 호출 될 때 정상적으로 반환되고 폭발하지 않는지 확인하는 간단한 통합 테스트입니다.
회귀 테스트 : 버그 수정시 작성된 테스트입니다. 이 특정 버그가 다시 발생하지 않도록합니다. 전체 이름은 "비 회귀 테스트"입니다. 응용 프로그램이 동일한 결과를 제공하는지 확인하기 위해 응용 프로그램을 변경하기 전에 수행되는 테스트 일 수도 있습니다.
여기에 다음을 추가합니다.
수락 테스트 : 기능 또는 사용 사례가 올바르게 구현되었는지 테스트합니다. 통합 테스트와 유사하지만 관련된 구성 요소보다는 제공 할 사용 사례에 중점을 둡니다.
시스템 테스트 : 시스템을 블랙 박스로 테스트합니다. 다른 시스템에 대한 종속성은 테스트 중에 종종 조롱되거나 스텁됩니다 (그렇지 않으면 통합 테스트에 더 가깝습니다).
Pre-flight check : '빌드 온 마이 머신'신드롬을 완화하기 위해 프로덕션과 같은 환경에서 반복되는 테스트입니다. 종종 이것은 생산과 같은 환경에서 수락 또는 연기 테스트를 수행하여 실현됩니다.
- 단위 테스트 : 클래스의 내부 동작을 테스트하는 자동 테스트입니다. 다른 리소스와 관련이없는 독립형 테스트 여야합니다.
- 통합 테스트 : 단위 테스트와 유사하지만 외부 리소스 (db, 디스크 액세스)를 사용하여 환경에서 수행되는 자동 테스트
- 회귀 테스트 : 새로운 기능이나 버그 수정을 구현 한 후 과거에 작동했던 시나리오를 다시 테스트합니다. 여기에서는 새로운 기능이 기존 기능을 손상시킬 가능성을 다룹니다.
- 연기 테스트 : 테스터가 테스트를 계속할 것인지 결정할 수있는 첫 번째 테스트입니다.
모든 사람은 약간 다른 정의를 가지며 종종 회색 영역이 있습니다. 하나:
- 단위 테스트 :이 작업이 가능한 한 분리되어 작동합니까?
- 통합 테스트 :이 두 가지 (또는 그 이상) 구성 요소가 함께 작동합니까?
- 연기 테스트 :이 전체 시스템 (가능한 한 프로덕션 시스템에 가깝게)이 합리적으로 잘 어울 립니까? (즉, 블랙홀을 만들지 않을 것이라고 합리적으로 확신합니까?)
- 회귀 테스트 : 이전에 수정 한 버그를 실수로 다시 도입 했습니까?
방금 알게 된 새로운 테스트 카테고리는 다음과 같습니다.
카나리아 테스트
카나리아 테스트 하는 자동화 된 비파괴 검사입니다 정기적으로 실행 A의 라이브 이제까지 실패하면 환경, 등, 뭔가 정말 나쁜 일어난 것이다.예는 다음과 같습니다.
- DEV / TEST에서만 사용할 수 있어야하는 데이터가 LIVE에 나타났습니다.
- 백그라운드 프로세스를 실행하지 못했습니다.
- 사용자 로그온 가능
외설적 인 역사적 퀴즈 : "연기 테스트"는 잠수함 엔지니어링 (배관에서 상 속됨)에서 비롯됩니다. 문자 그대로 연기가 선체로 펌핑되어 다시 나오는지 확인하기 위해 잠수함에게는 극적인 실패입니다!
소프트웨어 테스팅 기술을위한 최고의 웹 사이트 중 하나의 답변 :
소프트웨어 테스트 유형 – 전체 목록 여기를 클릭하십시오.
꽤 긴 설명이므로 여기에 붙여 넣지 않겠습니다. 그러나 모든 테스트 기술을 알고 싶은 사람에게는 도움이 될 수 있습니다.
도움이 되길 바랍니다 :)
단위 테스트 : 특정 구성 요소 (즉, 클래스)가 설계된대로 기능을 만들거나 수정했는지 확인합니다. 이 테스트는 수동 또는 자동화가 가능하지만 구성 요소의 경계를 벗어나지 않습니다.
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
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.
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.
스모크 테스트는 새 빌드를 만든 직후에 더 비싼 테스트를 실행할 수 있는지 여부를 결정하는 데 유용 할 수 있으며, 배포 직후 새로 배포 된 환경에서 애플리케이션이 제대로 실행되고 있는지 확인하는 데 유용 할 수 있습니다.
출처 : https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
'programing' 카테고리의 다른 글
| jar를 설치하지 않고 maven 2 빌드 클래스 경로에 추가 할 수 있습니까? (0) | 2020.09.30 |
|---|---|
| Mac OS 파인더에서 여기에서 터미널 열기 (0) | 2020.09.30 |
| PostgreSQL에서 데이터베이스 복사본 생성 (0) | 2020.09.30 |
| JPA와 Hibernate의 차이점은 무엇입니까? (0) | 2020.09.30 |
| LINQ Aggregate 알고리즘 설명 (0) | 2020.09.30 |