단위, 기능, 승인 및 통합 테스트의 차이점은 무엇입니까?

단위, 기능, 승인 및 통합 테스트의 차이점은 무엇입니까? [닫은]

---

단위, 기능, 승인 및 통합 테스트 (및 내가 언급하지 않은 다른 유형의 테스트)의 차이점은 무엇입니까?

---

어디를 보느냐에 따라 약간 다른 답을 얻을 수 있습니다. 나는 주제에 대해 많이 읽었고 여기에 내 증류가 있습니다. 다시 말하지만, 이것들은 약간 털이 많고 다른 사람들은 동의하지 않을 수 있습니다.

단위 테스트

가장 작은 기능 단위, 일반적으로 메서드 / 함수를 테스트합니다 (예 : 특정 상태의 클래스가 주어지면 클래스에서 x 메서드를 호출하면 y가 발생해야 함). 단위 테스트는 하나의 특정 기능에 초점을 맞춰야합니다 (예 : 스택이 비어있을 때 pop 메서드를 호출하면 InvalidOperationException. 그것이 접촉하는 모든 것은 기억에서 이루어져야합니다. 즉, 테스트 코드 와 테스트중인 코드 가 다음을 수행해서는 안됩니다.

• (사소하지 않은) 공동 작업자에게 전화
• 네트워크에 액세스
• 데이터베이스 히트
• 파일 시스템 사용
• 스레드 스핀 업
• 기타

느린 / 이해하기 / 초기화 / 조작하는 모든 종류의 종속성은 적절한 기술을 사용하여 스텁 / 모의 / 무엇이든해야합니다. 그래야 종속성이 수행하는 것이 아니라 코드 단위가 수행하는 작업에 집중할 수 있습니다.

요컨대, 단위 테스트는 가능한 한 간단하고, 디버그하기 쉽고, 안정적이며 (외부 요인 감소로 인해), 실행이 빠르며, 프로그램의 가장 작은 빌딩 블록이 합치기 전에 의도 한대로 작동한다는 것을 증명하는 데 도움이됩니다. 주의 할 점은 분리 된 상태에서 완벽하게 작동한다는 것을 증명할 수 있지만 코드 단위를 결합하면 폭발 할 수 있다는 것입니다.

통합 테스트

통합 테스트는 코드 단위를 결합하고 결과 조합이 올바르게 작동하는지 테스트하여 단위 테스트를 기반으로합니다. 이것은 하나의 시스템의 내부 또는 여러 시스템을 결합하여 유용한 작업을 수행 할 수 있습니다. 또한 통합 테스트와 단위 테스트를 구별하는 또 다른 요소는 환경입니다. 통합 테스트는 스레드를 사용하거나 데이터베이스에 액세스하거나 모든 코드 와 다양한 환경 변경이 올바르게 작동하는지 확인하는 데 필요한 모든 작업을 수행 할 수 있습니다.

직렬화 코드를 빌드하고 디스크를 건드리지 않고 내부를 단위 테스트 한 경우 디스크를로드하고 저장할 때 작동하는지 어떻게 알 수 있습니까? 파일 스트림을 플러시하고 처리하는 것을 잊었을 수 있습니다. 파일 권한이 올바르지 않고 메모리 스트림에서 사용하여 내부를 테스트했을 수 있습니다. 확실하게 알아내는 유일한 방법은 프로덕션에 가장 가까운 환경을 사용하여 '실제'로 테스트하는 것입니다.

가장 큰 장점은 와이어 링 버그 (예 : 클래스 A의 인스턴스가 예기치 않게 B의 null 인스턴스를 수신함) 및 환경 버그 (단일 CPU 시스템에서 잘 실행되지만 내 단일 CPU에서 잘 실행 됨)와 같이 단위 테스트에서 수행 할 수없는 버그를 찾을 수 있다는 것입니다. 동료의 4 코어 머신은 테스트를 통과 할 수 없습니다.) 가장 큰 단점은 통합 테스트가 더 많은 코드를 터치하고, 신뢰성이 떨어지고, 실패를 진단하기 어렵고 테스트를 유지하기가 더 어렵다는 것입니다.

또한 통합 테스트가 완전한 기능이 작동 함을 반드시 증명하는 것은 아닙니다. 사용자는 내 프로그램의 내부 세부 사항에 대해 신경 쓰지 않을 수 있지만 나는 있습니다!

기능 테스트

기능 테스트는 지정된 입력에 대한 결과를 사양과 비교하여 특정 기능의 정확성을 확인합니다. 기능 테스트는 중간 결과 나 부작용이 아닌 결과 만 고려합니다 (x를 수행 한 후 개체 y가 상태 z를 갖는 것은 상관하지 않습니다). "2의 인수를 사용하여 Square (x) 함수를 호출하면 4가 반환됩니다"와 같은 사양의 일부를 테스트하기 위해 작성되었습니다.

수락 테스트

수락 테스트는 두 가지 유형으로 나뉩니다.

표준 승인 테스트에는 애플리케이션의 기능이 사양을 충족하는지 확인하기 위해 전체 시스템 (예 : 웹 브라우저를 통해 웹 페이지 사용)에서 테스트를 수행하는 것이 포함됩니다. 예 : "확대 / 축소 아이콘을 클릭하면 문서보기가 25 % 확대됩니다." 결과의 실제 연속성은 없으며 단지 합격 또는 실패 결과입니다.

장점은 테스트가 일반 영어로 설명되어 있고 소프트웨어 전체가 기능이 완벽하다는 것을 보장한다는 것입니다. 단점은 테스트 피라미드에서 다른 레벨을 올렸다는 것입니다. 수용 테스트는 엄청난 양의 코드에 닿기 때문에 실패를 추적하는 것은 까다로울 수 있습니다.

또한 민첩한 소프트웨어 개발에서 사용자 수용 테스트에는 개발 중에 소프트웨어 고객이 생성 한 사용자 스토리를 반영하는 테스트 생성이 포함됩니다. 테스트가 통과되면 소프트웨어가 고객의 요구 사항을 충족해야하며 스토리가 완료된 것으로 간주 될 수 있음을 의미합니다. 수락 테스트 스위트는 기본적으로 시스템 사용자가 사용하는 언어로 테스트를 설명하는 도메인 특정 언어로 작성된 실행 가능한 사양입니다.

결론

They're all complementary. Sometimes it's advantageous to focus on one type or to eschew them entirely. The main difference for me is that some of the tests look at things from a programmer's perspective, whereas others use a customer/end user focus.

---

The important thing is that you know what those terms mean to your colleagues. Different groups will have slightly varying definitions of what they mean when they say "full end-to-end" tests, for instance.

I came across Google's naming system for their tests recently, and I rather like it - they bypass the arguments by just using Small, Medium, and Large. For deciding which category a test fits into, they look at a few factors - how long does it take to run, does it access the network, database, filesystem, external systems and so on.

http://googletesting.blogspot.com/2010/12/test-sizes.html

I'd imagine the difference between Small, Medium, and Large for your current workplace might vary from Google's.

However, it's not just about scope, but about purpose. Mark's point about differing perspectives for tests, e.g. programmer vs customer/end user, is really important.

---

http://martinfowler.com/articles/microservice-testing/

Martin Fowler's blog post speaks about strategies to test code (Especially in a micro-services architecture) but most of it applies to any application.

I'll quote from his summary slide:

• Unit tests - exercise the smallest pieces of testable software in the application to determine whether they behave as expected.
• Integration tests - verify the communication paths and interactions between components to detect interface defects.
• Component tests - limit the scope of the exercised software to a portion of the system under test, manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components.
• Contract tests - verify interactions at the boundary of an external service asserting that it meets the contract expected by a consuming service.
• End-To-End tests - verify that a system meets external requirements and achieves its goals, testing the entire system, from end to end.

---

Unit Testing - As the name suggests, this method tests at the object level. Individual software components are tested for any errors. Knowledge of the program is needed for this test and the test codes are created to check if the software behaves as it is intended to.

Functional Testing - Is carried out without any knowledge of the internal working of the system. The tester will try to use the system by just following requirements, by providing different inputs and testing the generated outputs. This test is also known as closed-box testing or black-box.

Acceptance Testing - This is the last test that is conducted before the software is handed over to the client. It is carried out to ensure that the developed software meets all the customer requirements. There are two types of acceptance testing - one that is carried out by the members of the development team, known as internal acceptance testing (Alpha testing), and the other that is carried out by the customer or end user known as (Beta testing)

Integration Testing - Individual modules that are already subjected to unit testing are integrated with one another. Generally the two approachs are followed :

1) Top-Down
2) Bottom-Up

---

This is very simple.

1. Unit testing: This is the testing actually done by developers that have coding knowledge. This testing is done at the coding phase and it is a part of white box testing. When a software comes for development, it is developed into the piece of code or slices of code known as a unit. And individual testing of these units called unit testing done by developers to find out some kind of human mistakes like missing of statement coverage etc..

2. Functional testing: This testing is done at testing (QA) phase and it is a part of black box testing. The actual execution of the previously written test cases. This testing is actually done by testers, they find the actual result of any functionality in the site and compare this result to the expected result. If they found any disparity then this is a bug.

3. Acceptance testing: know as UAT. And this actually done by the tester as well as developers, management team, author, writers, and all who are involved in this project. To ensure the project is finally ready to be delivered with bugs free.

4. Integration testing: The units of code (explained in point 1) are integrated with each other to complete the project. These units of codes may be written in different coding technology or may these are of different version so this testing is done by developers to ensure that all units of the code are compatible with other and there is no any issue of integration.

---

Some (relatively) recent ideas against excessive mocking and pure unit-testing:

• https://www.simple-talk.com/dotnet/.net-framework/are-unit-tests-overused/
• http://googletesting.blogspot.com/2013/05/testing-on-toilet-dont-overuse-mocks.html
• http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours/
• http://cdunn2001.blogspot.com/2014/04/the-evil-unit-test.html
• http://www.jacopretorius.net/2012/01/test-behavior-not-implementation.html
• Why Most Unit Testing is Waste

---

I will explain you this with a practical example and no theory stuff:

A developer writes the code. No GUI is implemented yet. The testing at this level verifies that the functions work correctly and the data types are correct. This phase of testing is called Unit testing.

When a GUI is developed, and application is assigned to a tester, he verifies business requirements with a client and executes the different scenarios. This is called functional testing. Here we are mapping the client requirements with application flows.

Integration testing: let's say our application has two modules: HR and Finance. HR module was delivered and tested previously. Now Finance is developed and is available to test. The interdependent features are also available now, so in this phase, you will test communication points between the two and will verify they are working as requested in requirements.

Regression testing is another important phase, which is done after any new development or bug fixes. Its aim is to verify previously working functions.

---

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.

funcional test checking the individual functionality of an application is mean to be functional testing

acceptance testing this testing is done by end user or customer whether the build application is according to the customer requirement , and customer specification this is known to be acceptance testing

참고URL : https://stackoverflow.com/questions/4904096/whats-the-difference-between-unit-functional-acceptance-and-integration-test