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

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

보이는 위치에 따라 약간 다른 답변을 얻을 수 있습니다. 나는 그 주제에 대해 많이 읽었으며 여기에 증류가 있습니다. 다시 말하지만, 이들은 약간 울리며 다른 사람들은 동의하지 않을 수 있습니다.

단위 테스트

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

• (사소하지 않은) 공동 작업자에게 전화
• 네트워크에 액세스
• 데이터베이스 조회
• 파일 시스템 사용
• 실을 돌려
• 기타

느리거나 이해하기 어려운 / 초기화 / 조작이 가능한 모든 종류의 종속성은 적절한 기술을 사용하여 스텁 / 조롱 / 무엇이든 상관없이 코드 단위가 수행하는 작업에 초점을 맞출 수 있습니다.

간단히 말해, 단위 테스트는 가능한 한 간단하고 디버깅하기 쉽고 신뢰할 수 있으며 (외부 요소 감소로 인해) 실행 속도가 빠르고 프로그램의 가장 작은 빌딩 블록이 조합되기 전에 의도 한대로 작동 함을 증명하는 데 도움이됩니다. 주의해야 할 점은, 완벽하게 격리되어 작동한다는 것을 증명할 수 있지만 코드 단위가 결합되면 폭발 할 수 있습니다.

통합 테스트

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

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

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

또한 통합 테스트가 반드시 완전한 기능이 작동 함을 입증하지는 않습니다. 사용자는 내 프로그램의 내부 세부 정보에 신경 쓰지 않을 수도 있지만 그렇게합니다!

기능 테스트

기능 테스트는 지정된 입력에 대한 결과를 사양과 비교하여 특정 기능의 정확성을 검사합니다. 기능 테스트는 중간 결과 또는 부작용과 관련이 없으며 결과 만 제공합니다 (x를 수행 한 후 객체 y의 상태가 z 인 것을 신경 쓰지 않습니다). "2의 인수를 가진 함수 Square (x)를 호출하면 4가 리턴 됨"과 같은 스펙의 일부를 테스트하기 위해 작성됩니다.

합격 시험

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

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

장점은 테스트가 일반 영어로 설명되어 있으며 소프트웨어 전체가 기능을 완벽하게 완료한다는 것입니다. 단점은 테스트 피라미드를 한 단계 위로 올렸다는 것입니다. 승인 테스트는 코드의 산들과 접촉하므로 오류를 추적하는 것은 까다로울 수 있습니다.

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

결론

그것들은 모두 보완 적입니다. 때로는 한 가지 유형에 집중하거나 완전히 배제하는 것이 유리합니다. 저에게 가장 큰 차이점은 일부 테스트는 프로그래머의 관점에서 사물을 보는 반면 다른 테스트는 고객 / 최종 사용자 포커스를 사용한다는 것입니다.

중요한 것은 그 용어가 동료에게 어떤 의미인지 아는 것입니다. 예를 들어, 서로 다른 그룹은 "완전한 엔드 투 엔드"테스트를 할 때 의미가 약간 다르게 정의됩니다.

최근에 테스트를 위해 Google의 이름 지정 시스템을 발견했으며 선호합니다. Small, Medium 및 Large를 사용하여 인수를 우회합니다. 테스트에 적합한 범주를 결정하기 위해 몇 가지 요소를 검토합니다. 실행하는 데 걸리는 시간, 네트워크, 데이터베이스, 파일 시스템, 외부 시스템 등에 액세스하는 등의 요소가 있습니다.

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

현재 직장에 대한 Small, Medium 및 Large의 차이점이 Google과 다를 수 있다고 생각합니다.

그러나 그것은 단지 범위에 관한 것이 아니라 목적에 관한 것입니다. 프로그래머와 고객 / 최종 사용자 등 테스트에 대한 다양한 관점에 대한 Mark의 요점은 정말 중요합니다.

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

Martin Fowler의 블로그 게시물은 코드를 테스트하는 전략 (특히 마이크로 서비스 아키텍처)에 대해 설명하지만 대부분의 응용 프로그램에 적용됩니다.

그의 요약 슬라이드에서 인용하겠습니다.

• 단위 테스트-응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 시험하여 예상대로 작동하는지 확인합니다.
• 통합 테스트-인터페이스 결함을 감지하기 위해 구성 요소 간의 통신 경로 및 상호 작용을 확인하십시오.
• 구성 요소 테스트-테스트 된 시스템의 범위를 테스트중인 시스템의 일부로 제한하고 내부 코드 인터페이스를 통해 시스템을 조작하고 테스트 더블을 사용하여 테스트중인 코드를 다른 구성 요소와 격리시킵니다.
• 계약 테스트-외부 서비스의 경계에서 상호 작용이 소비 서비스에 의해 예상되는 계약을 충족하는지 확인합니다.
• 엔드 투 엔드 테스트-시스템이 외부 요구 사항을 충족하고 목표를 달성하여 전체 시스템을 엔드 투 엔드로 테스트하는지 확인합니다.

단위 테스트 -이름에서 알 수 있듯이이 방법은 개체 수준에서 테스트합니다. 개별 소프트웨어 구성 요소는 오류가 있는지 테스트합니다. 이 테스트에는 프로그램에 대한 지식이 필요하며 소프트웨어가 의도 한대로 동작하는지 확인하기 위해 테스트 코드가 작성됩니다.

기능 테스트 -시스템의 내부 작동에 대한 지식없이 수행됩니다. 테스터는 다른 입력을 제공하고 생성 된 출력을 테스트하여 요구 사항에 따라 시스템을 사용하려고합니다. 이 테스트는 폐쇄 상자 테스트 또는 블랙 박스라고도합니다.

승인 테스트 -소프트웨어가 클라이언트에게 전달되기 전에 수행되는 마지막 테스트입니다. 개발 된 소프트웨어가 모든 고객 요구 사항을 충족하는지 확인하기 위해 수행됩니다. 내부 승인 테스트 (알파 테스트)라고하는 개발 팀 구성원이 수행하는 승인 테스트와 고객 또는 최종 사용자 (베타 테스트)가 수행하는 승인 테스트의 두 가지 유형이 있습니다.

통합 테스트 – 이미 유닛 테스트를 거친 개별 모듈은 서로 통합되어 있습니다. 일반적으로 두 가지 접근 방식을 따릅니다.

1) 하향식
2) 상향식

이것은 매우 간단합니다.

1. 단위 테스트 : 코딩 지식이있는 개발자가 실제로 수행하는 테스트입니다. 이 테스트는 코딩 단계에서 수행되며 화이트 박스 테스트의 일부입니다. 소프트웨어가 개발 용으로 제공되면 소프트웨어는 단위라고하는 코드 조각 또는 코드 조각으로 개발됩니다. 그리고 이러한 단위에 대한 개별 테스트는 개발자가 문장 적용 범위 누락 등과 같은 사람의 실수를 찾기 위해 수행 한 단위 테스트라고합니다.

2. 기능 테스트 :이 테스트는 테스트 (QA) 단계에서 수행되며 블랙 박스 테스트의 일부입니다. 이전에 작성된 테스트 사례의 실제 실행 이 테스트는 실제로 테스터가 수행하며 사이트에서 기능의 실제 결과를 찾고이 결과를 예상 결과와 비교합니다. 그들이 불일치를 발견하면 이것은 버그입니다.

3. 수락 테스트 : UAT라고합니다. 그리고 실제로 테스터와 개발자, 관리 팀, 저자, 작가 및이 프로젝트에 참여한 모든 사람이 수행했습니다. 버그가없는 상태로 프로젝트를 최종 제공 할 수 있도록합니다.

4. 통합 테스트 : 코드 단위 (1 지점에서 설명)는 서로 통합되어 프로젝트를 완료합니다. 이 코드 단위는 다른 코딩 기술로 작성되거나 다른 버전 일 수 있으므로 개발자는 코드의 모든 단위가 다른 코드 단위와 호환되고 통합 문제가 없는지 확인하기 위해이 테스트를 수행합니다.

과도한 조롱 및 순수한 단위 테스트에 대한 (상대적으로) 최근 아이디어 :

• 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
• 대부분의 단위 테스트가 낭비되는 이유

나는 이론적 인 것없이 실제적인 예를 가지고 이것을 설명 할 것이다 :

개발자가 코드를 작성합니다. 아직 GUI가 구현되지 않았습니다. 이 레벨의 테스트는 기능이 올바르게 작동하고 데이터 유형이 올바른지 검증합니다. 이 단계의 테스트를 단위 테스트라고합니다.

GUI가 개발되고 응용 프로그램이 테스터에게 할당되면 클라이언트와 함께 비즈니스 요구 사항을 확인하고 다양한 시나리오를 실행합니다. 이것을 기능 테스트라고합니다. 여기에서는 클라이언트 요구 사항을 응용 프로그램 흐름과 매핑합니다.

통합 테스트 : 애플리케이션에 HR 및 재무라는 두 가지 모듈이 있다고 가정 해 봅시다. HR 모듈은 이전에 제공 및 테스트되었습니다. 이제 재무가 개발되어 테스트 할 수 있습니다. 이제 상호 종속 기능도 사용할 수 있으므로이 단계에서는 두 지점 간의 통신 지점을 테스트하고 요구 사항에 따라 요청한대로 작동하는지 확인합니다.

회귀 테스트는 새로운 개발 또는 버그 수정 후에 수행되는 또 다른 중요한 단계입니다. 그 목적은 이전에 작동 한 기능을 확인하는 것입니다.

단위 테스트 : 응용 프로그램에서 개별 모듈 또는 독립 구성 요소의 테스트는 단위 테스트로 알려져 있으며 단위 테스트는 개발자가 수행합니다.

통합 테스트 : 모든 모듈을 결합하고 응용 프로그램을 테스트하여 통신 및 모듈 간의 데이터 흐름이 제대로 작동하는지 확인합니다.이 테스트는 개발자도 수행합니다.

funcional 테스트 애플리케이션의 개별 기능 검사는 기능 시험 수 평균 인

승인 테스트이 테스트는 최종 사용자 또는 고객이 빌드 응용 프로그램이 고객 요구 사항을 따르는 지 여부와 고객 사양에 따라 수행되며, 고객 사양은 승인 테스트라고합니다.