정확히 통합 테스트 란 무엇입니까?

내 친구와 나는 통합 테스트가 무엇인지 정확하게 분류하기 위해 고심하고 있습니다.

이제 집으로가는 길에 저는 통합 테스트의 실제 사례를 제시하려고 할 때마다 합격 테스트라는 것이 깨달았습니다. 비즈니스 사람이 시스템이 무엇을 제공해야하는지 명시하는 큰 소리로 말하는 것.

이러한 테스트 유형의 분류에 대해 Ruby on Rails 문서를 확인했으며 이제는 완전히 던져졌습니다.

실제 사례와 통합 테스트에 대한 간단한 학술적 설명을 해줄 수 있습니까?

현재 나는이 글을 좋아한다 . 이 글 에서 Gojko Adzic 이 작성한 "중요한 것이 아니라 무엇을 하는가"는 중요하다 .

테스트하려는 테스트에 대해 이야기하는 사람들과 함께 구체적으로 지정해야합니다.

그들의 역할이 무엇인지에 따라 다른 견해를 가진 사람들이 많이 있습니다.

테스터의 경우 네덜란드에서 일반적으로 허용되는 테스트 방법은 TMap 입니다. TMap은 다음과 같이 구별됩니다.

• 단위 테스트
• 단위 통합 테스트
• 시스템 테스트
• 시스템 통합 테스트
• 합격 시험 (모든 종류 / 레벨)
• 기능적 수용 테스트
• 사용자 수락 테스트
• 생산 합격 시험

위에 언급 된 테스트 내에서 수행 할 수있는보다 구체적인 테스트가 있습니다. 봐 이 워드 문서 에 대한 개요.

Wikipedia는 또한 훌륭한 개요를 가지고 있습니다.

책은 실용주의 프로그래머는 말합니다 :

• 단위 테스트는 모듈을 연습하는 테스트입니다
• 통합 테스트에 따르면 시스템의 주요 부분이 잘 작동 함

이러한 다양한 출처를보고 내 경험과 의견을 제시하기 위해 세 가지 범주로 구분할 수 있습니다.

• 일반적으로 누가 시험을합니까
• 무엇을 테스트

• 시험의 목표는 무엇입니까

  • 단위 테스트 : 프로그래머가 클래스의 로직을 테스트하여 코드 수준의 정확성을 보여줍니다. 속도가 빠르며 테스트하려는 시스템의 다른 부분에 의존해서는 안됩니다.
  • 기능 승인 테스트 : 테스트 부서에서 수행 한 제한된 (특히 생성 된) 데이터 세트에서 유스 케이스 시나리오를 테스트하여 지정된 모든 시나리오가 지정된대로 작동 함을 보여줍니다.
  • 사용자 수락 테스트 : 사용자 대표가 공식적으로 애플리케이션을 수락하도록하는 데이터와 같은 프로덕션 환경에서 유스 케이스 시나리오 테스트
  • 통합 테스트 : 테스트 부서 또는 개발자가 수행 한 모듈의 다른 부분 사이의 통신 경로를 테스트하여 모든 모듈이 올바르게 작동하는지 보여줍니다.

위의 내 목록은 단지 시작과 제안이지만 실제로는 "당신이 부르는 것이 중요하지 않지만 무엇을 하는가는 중요합니다"라고 생각합니다.

도움이 되었기를 바랍니다.

2016 년 10 월 26 일 수정 : 최근에 YouTube 단위 테스트와 통합 테스트-MPJ의 Musings-FunFunFunction # 55 에 대한 아주 좋은 소개가 있었습니다.

통합 테스트, 그것은 수용 테스트로 밝혀졌습니다

명백하게.

이 두 가지는 거의 같습니다. 그러나 테스트 정의와는 약간 다른 차원이 있습니다.

통합 == 시스템 전체

수락 == 시스템 전체.

유일한 차이점은 미묘하지만 테스트 사례의 정의입니다.

적분 깊이와 정도를 테스트하기 위해 적분 == 테스트 사례. 모든 엣지 케이스 및 코너 케이스에서 작동합니까? 테스트 케이스는 디자이너와 코더가 작성한 기술적 인 경향이 있습니다.

Acceptance == 테스트 사례는 최종 사용자 중심 기능 세트의 80 % 만 실행합니다. 모든 모서리와 모서리가 아닙니다. 테스트 케이스는 기술이 아닌 최종 사용자가 작성하는 경향이 있습니다.

필자는 개인적으로 시스템의 모든 구성 요소가 모의 객체가 아닌 실제 테스트 인 경우 기능 테스트 로 통합 테스트를 생각 합니다.

실제 저장소, 실제 데이터베이스, 실제 UI. 시스템이 완전히 조립 될 때 특정 기능을 테스트하고 배포 할 때와 같아야합니다.

저의 경험에 의하면, 통합이라는 단어가 실제로 오해를 일으킬 수 있다는 것을 이해했습니다. 실제로 시스템에서 완전히 고립 된 것을 찾기가 어려우며, 일부 요소는 확실히 통합이 필요합니다.

따라서 다음과 같은 차이점을 익히는 데 익숙해졌습니다.

• 단위 테스트 를 사용하여 테스트 중인 클래스가 수행해야 할 모든 동작을 식별, 문서화 및 강조합니다.
• 시스템에 다른 " 외부 "시스템 과 대화하는 구성 요소 (하나 이상)가있을 때마다 통합 테스트를 수행하고 있습니다. (아래 계속 ...)
• 시스템에서 예상되는 특정 워크 플로를 정의, 문서화 및 강조하기 위해 승인 테스트 를 구현합니다 .

통합 테스트 정의에서 외부는 개발 범위를 벗어난 시스템을 의미했습니다 . 어떤 이유로 든 작동 방식을 즉시 변경할 수 없습니다. 라이브러리, 변경할 수없는 시스템의 구성 요소 (예 : 회사의 다른 프로젝트와 공유), dbms 등일 수 있습니다. 이러한 테스트를 위해 시스템의 실제 환경과 매우 유사한 것을 설정해야합니다. 작동합니다 : 외부 시스템을 초기화하고 특정 상태로 설정해야합니다. 실제 데이터는 db에 등록해야합니다. 기타

대신, 수용 테스트를 할 때 나는 가짜 일을합니다. 나는 다른 일을하고 있습니다. 나는 외부 엔터티와 협력 할 수있는 능력이 아니라 시스템 사양을 연구하고 있습니다.

이것은 KeesDijk가 이전에 설명한 것과 비교하여 더 좁은 견해이지만, 지금까지 작업 한 프로젝트 가이 수준의 단순화를 가능하게 할만 큼 작다고 가정합니다.

통합 테스트는 설계대로 복잡한 시스템 (예 : 소프트웨어, 항공기, 발전소)의 구성 요소가 함께 작동하는지 확인합니다.

항공기에 대해 이야기하고 있다고 가정 해 봅시다 (소프트웨어를 사용하면 더 추상적이고 차별화하기가 어렵습니다). 통합 테스트에는 다음이 포함됩니다.

• 일부 구성 요소 간의 올바른 상호 작용 예 : 시작 버튼을 누르면 엔진이 시동되고 프로펠러가 예상 회전 속도에 도달합니다 (항공기는 여전히지면에 남아 있습니다).
• 외부 구성 요소와의 올바른 상호 작용 예 : 내장 라디오가 고정 라디오 (항공기가 여전히 지상에 있음)와 통신 할 수 있는지 확인
• 시스템 전체가 예상대로 작동하도록 관련된 모든 구성 요소 간의 올바른 상호 작용 예 : 테스트 조종사 및 엔지니어 팀이 비행기를 시작하고 비행기를 타고 비행합니다 (모두 낙하산을 착용합니다).

통합 테스트는 기술적 인 문제를 해결 시스템이 구성 요소로의 세분화에도 불구하고 작동 즉 것을. 소프트웨어에서 구성 요소는 사용 사례, 모듈, 기능, 인터페이스, 라이브러리 등이 될 수 있습니다.

수용 테스트는 제품이 목적에 적합 있는지 확인합니다. 원칙적으로 고객이 수행합니다. 항공기를 비유하면 다음 사항을 확인합니다.

• 예상되는 비즈니스 시나리오는 거의 실제 상황에서 예상되는 결과로 이어집니다. 예 : 테스트 승객과 탑승을 연습하여 직원이 운영 절차에 따라 탑승을 예상대로 모니터링 할 수 있는지 확인합니다. 일부 시나리오는 매우 간단하여 단위 테스트처럼 보일 수 있지만 사용자가 수행합니다 (예 : 회사의 장비로 전기 플러그 사용).
• 이 시스템은 거의 실제 비즈니스 상황에서 작동합니다. 예 : 항공사에서 새로 훈련 된 조종사와 함께 두 실제 목적지 사이에 빈 시험 비행을하여 연료 소비가 약속 된 것인지 확인하십시오.

수용 테스트는 더 많은 책임 문제를 해결합니다 . 고객 / 공급자 관계에서는 계약 상 책임이 될 수 있습니다 (모든 요구 사항 준수). 그러나 어쨌든 시스템을 사용하여 직무를 수행하고 예기치 않은 문제를 신중하게 방지하는 것은 사용 조직의 책임이기도합니다 (예 : 수락 테스트 중에 발견 된 철도 회사와 같이 일부 quais를 단축해야 함) 새로운 왜건은 5cm가 너무 커서 농담이 없었습니다!).

결론 : 통합 및 승인 테스트가 겹칩니다. 둘 다 시스템이 전체적으로 작동 함을 보여 주려고합니다. 그러나 "전체"는 고객에게 더 클 수 있으며 (시스템 자체가 더 큰 조직 시스템의 일부일 수 있기 때문에) 시스템 통합 자에게 더 기술적 인 것입니다.

통합 테스트는 두 개 이상의 모듈 간 데이터 흐름의 연결 및 정확성을 확인하는 것입니다.

예 : 메일 (하나의 모듈)을 작성하여 유효한 사용자 ID (두 번째 모듈)로 보낼 때, 통합 테스트는 전송 된 메일이 전송 된 항목에 있는지 확인하는 것입니다.

하나의 실제적인 통합 테스트의 정의는 다음과 같습니다 독립 프로세스 무언가와의 상호 작용을 필요로하는 시험.

예를 들면 다음과 같습니다.

• 파일 시스템
• 네트워크
• 데이터베이스
• 외부 API

프로세스와 외부 환경간에 일종의 계약이 존재하며 계약이 통합 테스트의 목표가되는지 최소한으로 확인합니다. 즉, 계약을 확인하는 것 이상을해서는 안됩니다. 그렇다면 시스템 / 엔드 투 엔드 공간으로 이동하는 것입니다.

단위 테스트는 프로세스 경계 내에서 모든 논리를 테스트 할 수 있으며 느리고 취약한 복잡한 "외부 세계"에 대한 종속성이 없기 때문에 쉽게 정확하게 수행 할 수 있습니다 .

통합 테스트가 있지만이 정의는 다루지 않으므로 ( 실제 정의 라고 부르는 이유 는) 덜 일반적이고 유용하다고 생각합니다.

NB 엄밀히 말하자면,이 정의는 시스템 / 엔드 투 엔드 테스트에도 적용됩니다. 저의 철학에서 그들은 '극단적'통합 테스트의 한 형태이기 때문에 그들의 이름이 다른 측면을 강조하는 이유입니다. 다른 방향으로, 단위 테스트 제로 요소의 통합 테스트 IE에서 고려 될 수 0-N 요소 간의 통합 모든 검사가 통합 스펙트럼 어딘가에 놓여 간주 될 수 :-)