SIT란 무엇인가요? 시스템 통합 테스트(SIT) 예시를 통해 알아보세요.

시스템 통합 테스트란 무엇입니까?

시스템 통합 테스팅 전체 시스템의 동작을 검증하기 위해 통합 하드웨어 및 소프트웨어 환경에서 수행되는 소프트웨어 테스트 유형으로 정의됩니다. 시스템이 지정된 요구 사항을 준수하는지 평가하기 위해 완전한 통합 시스템에서 수행되는 테스트입니다.

시스템 통합 테스트(SIT)는 소프트웨어 시스템의 모듈 간 상호 작용을 검증하기 위해 수행됩니다. 이는 소프트웨어 요구사항 명세서/데이터 및 소프트웨어 설계 문서에 명시된 상위 및 하위 수준 소프트웨어 요구사항을 검증하는 것을 포함합니다.

SIT는 또한 소프트웨어 시스템이 다른 시스템과 공존할 수 있는지를 검증하고 소프트웨어 애플리케이션 모듈 간의 인터페이스를 테스트합니다. 이러한 유형의 테스트에서는 먼저 모듈을 개별적으로 테스트한 다음 시스템을 구성하도록 결합합니다. 예를 들어 소프트웨어 및/또는 하드웨어 구성 요소를 결합하고 전체 시스템이 통합될 때까지 단계적으로 테스트합니다.

위 다이어그램은 SIT를 정의하는 진행 과정을 보여줍니다. 별도로 검증된 모듈들이 단계적으로 병합되어 최종적으로 하나의 통합 시스템이 테스트 대상이 됩니다.

시스템 통합 테스트를 수행하는 이유는 무엇입니까?

소프트웨어 엔지니어링에서는 시스템 통합 테스트가 수행됩니다.

• 감지하는 데 도움이 됩니다. 결함 초기의
• 개별 모듈의 수용 가능성에 대한 조기 피드백이 제공됩니다.
• 결함 수정 일정은 유연하며 개발과 중복될 수 있습니다.
• 올바른 데이터 흐름
• 올바른 제어 흐름
• 정확한 타이밍
• 올바른 메모리 사용량
• 소프트웨어 요구 사항에 맞게 수정

시스템 통합 테스트 vs 시스템 테스트 vs 사용자 승인 테스트

이 세 단계는 서로 바로 연결되어 있기 때문에 자주 혼동됩니다. 시스템 테스트 SIT는 완성된 건축물을 요구사항과 비교하여 검토하는 반면, 건축물 간의 연결 부위를 분석합니다. 사용자 동의 테스트 고객의 관점에서 기업의 건전성을 평가합니다. 아래 표는 이들을 구분합니다.

매개 변수	시스템 통합 테스트	시스템 테스트	사용자 동의 테스트
주요 초점	통합 모듈 간의 인터페이스 및 데이터 흐름	조립된 구조물 전체의 동작	실제 사용을 위한 비즈니스 적합성
테스트 수준	레벨 2	3단계	정식 출시 전 마지막 단계
기술	블랙 박스	블랙박스, 화이트박스 또는 그레이박스	블랙 박스
수행	통합 테스터 및 개발자	독립 테스트 팀	고객 또는 최종 사용자
일반적인 결함	인터페이스, 타이밍, 메모리 및 데이터 맵ping 오류	기능적 및 비기능적 시스템 오류	사용성과 요구사항 불일치
실행 시점	후 단위 테스트	앉은 후에	시스템 테스트 후

순서가 중요합니다. 모듈은 단위 테스트를 통과하고, 시스템 통합 테스트(SIT)는 인터페이스를 검증하며, 시스템 테스트는 조립된 제품을 검증하고, 사용자 승인 테스트(UAT)는 제품이 비즈니스 기대치에 부합하는지 확인합니다. 건너뛰기ping SIT는 인터페이스 결함을 UAT 단계로 넘기는데, 이 단계에서는 수정하는 데 훨씬 더 많은 비용이 듭니다.

시스템 통합 테스트를 수행하는 방법

이는 인터페이스와 관련된 오류를 발견하기 위한 테스트를 수행하면서 프로그램 구조를 체계적으로 구축하는 기법입니다.

모든 모듈은 사전에 통합되어 있으며 전체 프로그램이 전체적으로 테스트됩니다. 하지만 이 과정에서 일련의 오류가 발생할 가능성이 높습니다.

전체 프로그램의 광범위한 확장으로 인해 격리 원인이 복잡해지기 때문에 이러한 오류를 수정하는 것은 어렵습니다. 이러한 오류가 수정되고 수정되면 새로운 오류가 나타나고 프로세스는 끝없는 루프에서 원활하게 계속됩니다.. 이러한 상황을 피하기 위해 점진적 통합이라는 또 다른 접근 방식이 사용됩니다. 점진적 접근 방식은 다음 섹션에서 자세히 설명합니다.

통합 테스트와 같은 몇 가지 점진적인 방법이 대상 프로세서를 기반으로 하는 시스템에서 수행됩니다. 사용된 방법론은 검정 Box 지원. 상향식 또는 하향식 통합을 사용할 수 있습니다.

테스트 케이스는 높은 수준의 소프트웨어 요구사항만을 사용하여 정의됩니다.

소프트웨어 통합은 주로 호스트 환경에서 달성될 수 있으며, 대상 환경에 특정한 단위는 호스트에서 계속 시뮬레이션됩니다. 확인을 위해 대상 환경에서 테스트를 반복해야 합니다.

이 단계의 확인 테스트를 통해 메모리 할당 및 해제 오류와 같은 환경별 문제를 식별할 수 있습니다. 호스트 환경에서 소프트웨어 통합을 수행하는 실용성은 대상 시스템별 기능의 양에 따라 달라집니다. 일부 임베디드 시스템의 경우 대상 환경과의 결합도가 매우 높아 호스트 환경에서 소프트웨어 통합을 수행하는 것이 비현실적일 수 있습니다.

대규모 소프트웨어 개발은 ​​소프트웨어 통합을 여러 수준으로 나눕니다. 소프트웨어 통합의 하위 수준은 주로 호스트 환경에 기반을 두고, 이후 소프트웨어 통합 수준은 대상 환경에 더 많이 의존하게 됩니다.

참고 : 소프트웨어만 테스트하는 경우에는 소프트웨어 소프트웨어 통합 테스트(SSIT)라고 하며, 하드웨어와 소프트웨어를 모두 테스트하는 경우에는 하드웨어 소프트웨어 통합 테스트(HSIT)라고 합니다.

점진적 접근 방식

모든 것을 한 번에 통합하면 결함을 찾아내기가 어렵기 때문에 대부분의 팀은 여기에 설명된 점진적인 방식을 따릅니다.

증분 테스트는 통합 테스트의 한 방법입니다. 이러한 유형의 테스트 방법에서는 먼저 소프트웨어의 각 모듈을 개별적으로 테스트한 다음 다른 모듈을 추가하고 다른 모듈을 추가하는 방식으로 테스트를 계속합니다.

증분 통합은 빅뱅 접근 방식과 대조됩니다. 프로그램은 오류를 분리하고 수정하기가 더 쉬운 작은 세그먼트로 구성되고 테스트됩니다. 인터페이스는 완전히 테스트될 가능성이 높으며 체계적인 테스트 접근 방식이 적용될 수 있습니다.

증분 테스트에는 두 가지 유형이 있습니다.

• 하향식 접근 방식
• 상향식 접근 방식

하향식 접근

이러한 유형의 접근 방식에서는 개별적으로 스텁으로 시뮬레이션된 기본 기능을 사용하여 사용자 인터페이스만 테스트한 다음 아래 이미지에 표시된 대로 하위 레이어와 하위 레이어를 통합하여 아래로 이동합니다.

• 주 제어 모듈부터 시작하여 모듈은 제어 계층 구조를 통해 아래로 이동하여 통합됩니다.
• 주 제어 모듈의 하위 모듈은 너비 우선 방식 또는 깊이 우선 방식으로 구조에 통합됩니다.
• 깊이 우선 통합은 다음 다이어그램에 표시된 대로 구조의 주요 제어 경로에 있는 모든 모듈을 통합합니다.

모듈 통합 프로세스는 다음과 같은 방식으로 수행됩니다.

1. 메인 제어 모듈은 테스트 드라이버로 사용되며, 스텁은 메인 제어 모듈의 직속 하위 모듈을 모두 대체합니다.
2. 하위 스텁은 선택한 접근 방식(너비 우선 또는 깊이 우선)에 따라 실제 모듈로 한 번에 하나씩 대체됩니다.
3. 각 모듈이 통합될 때마다 테스트가 실행됩니다.
4. 각 테스트 세트가 완료되면 각 테스트 세트가 완료되면 다른 스텁이 실제 모듈로 대체됩니다.
5. 새로운 오류가 발생하지 않았는지 확인하려면 Regression Testing 수행 될 수 있습니다.

전체 프로그램 구조가 구축될 때까지 2단계부터 프로세스가 계속됩니다. 하향식 전략은 비교적 간단해 보이지만 실제로는 물류 문제가 발생합니다.

이러한 문제 중 가장 일반적인 것은 상위 수준을 적절하게 테스트하기 위해 계층 구조의 낮은 수준에서 처리해야 할 때 발생합니다.

스텁은 하향식 테스트 시작 시 하위 수준 모듈을 대체하므로 중요한 데이터가 프로그램 구조에서 위쪽으로 흐를 수 없습니다.

테스터가 직면할 수 있는 과제:

• 스텁이 실제 모듈로 교체될 때까지 많은 테스트를 지연합니다.
• 실제 모듈을 시뮬레이션하는 제한된 기능을 수행하는 스텁을 개발합니다.
• 계층 구조의 맨 아래부터 위로 소프트웨어를 통합합니다.

참고 : 첫 번째 접근 방식은 특정 테스트와 특정 모듈 통합 사이의 대응에 대한 통제력을 일부 상실하게 만듭니다. 이는 하향식 접근 방식의 매우 제한된 특성을 위반하는 경향이 있는 오류의 원인을 결정하는 데 어려움을 초래할 수 있습니다.

두 번째 접근 방식은 실행 가능하지만 스텁이 점점 더 복잡해짐에 따라 상당한 오버헤드가 발생할 수 있습니다.

상향식 접근 방식

상향식 통합은 프로그램 구조의 가장 낮은 수준에서 모듈을 사용하여 구성 및 테스트를 시작합니다. 이 과정에서 모듈은 아래에서 위로 통합됩니다.

이 접근 방식에서는 주어진 수준에 하위 모듈에 필요한 처리가 항상 가능하며 스텁이 필요하지 않습니다.

이 통합 테스트 프로세스는 일련의 XNUMX단계로 수행됩니다.

1. 저수준 모듈은 특정 소프트웨어 하위 기능을 수행하는 클러스터로 결합됩니다.
2. 테스트 사례 입력 및 출력을 조정하기 위해 드라이버가 작성됩니다.
3. 클러스터나 빌드가 테스트되었습니다.
4. 드라이버가 제거되고 클러스터가 프로그램 구조에서 위쪽으로 결합됩니다.

통합이 상향식으로 진행될수록 별도의 테스트 드라이버가 필요한 경우는 줄어듭니다. 실제로 프로그램 구조의 최상위 두 레벨을 하향식으로 통합하면 드라이버 수를 크게 줄일 수 있고 클러스터 통합도 훨씬 간소화됩니다. 통합은 아래 그림과 같은 패턴을 따릅니다.

참고 : 프로그램 구조의 상위 XNUMX개 수준이 하향식으로 통합되면 드라이버 수가 크게 줄어들 수 있으며 빌드 통합이 크게 단순화됩니다.

빅뱅 접근법

이 접근 방식에서는 모든 모듈이 준비될 때까지 모든 모듈이 통합되지 않습니다. 준비가 완료되면 모든 모듈이 통합된 다음 실행되어 모든 통합 모듈이 작동하는지 여부를 알 수 있습니다.

이 방식에서는 모든 것을 한꺼번에 통합하기 때문에 실패의 근본 원인을 알기가 어렵습니다.

또한, 프로덕션 환경에서는 치명적인 버그가 발생할 가능성이 높습니다.

이 접근 방식은 통합 테스트를 한 번에 수행해야 하는 경우에만 채택됩니다.

하드웨어 소프트웨어 통합 테스트

하드웨어 소프트웨어 통합 테스트 대상 하드웨어 환경에서 높은 수준의 기능을 확인하기 위해 컴퓨터 소프트웨어 구성요소(CSC)를 테스트하는 프로세스입니다. 하드웨어/소프트웨어 통합 테스트의 목표는 하드웨어 구성 요소에 통합된 개발된 소프트웨어의 동작을 테스트하는 것입니다.

요구 사항 기반 하드웨어-소프트웨어 통합 테스트

요구 사항 기반 하드웨어/소프트웨어 통합 테스트의 목적은 대상 컴퓨터의 소프트웨어가 높은 수준의 요구 사항을 충족하는지 확인하는 것입니다. 이 테스트 방법으로 밝혀진 일반적인 오류는 다음과 같습니다.

• 하드웨어/소프트웨어 인터페이스 오류
• 소프트웨어 파티셔닝 위반.
• 내장된 테스트로 오류를 감지할 수 없음
• 하드웨어 오류에 대한 잘못된 대응
• 시퀀싱, 과도 입력 부하 및 입력 전력 과도로 인한 오류
• 피드백 루프가 잘못된 동작
• 메모리 관리 하드웨어의 부정확하거나 부적절한 제어
• 데이터 버스 경합 문제
• 현장 로딩 가능 소프트웨어의 호환성 및 정확성을 검증하는 메커니즘의 잘못된 작동

하드웨어 소프트웨어 통합은 높은 수준의 요구 사항 검증을 다룹니다. 이 수준의 모든 테스트는 대상 하드웨어에서 수행됩니다.

• 이 수준의 테스트에서 기본적으로 사용되는 테스트 방법은 블랙박스 테스트입니다.
• 밝히다 테스트 케이스 높은 수준의 요구 사항에서만
• 테스트는 프로덕션 표준 하드웨어(대상)에서 실행되어야 합니다.

HW/SW 통합을 위한 테스트 케이스 설계 시 고려해야 할 사항

• 소프트웨어에 의한 모든 데이터의 올바른 획득
• 하드웨어에서 소프트웨어까지 예상대로 데이터 확장 및 범위
• 소프트웨어에서 하드웨어로의 올바른 데이터 출력
• 사양 내 데이터(정상 범위)
• 사양을 벗어난 데이터(비정상 범위)
• 경계 데이터
• 처리 중단
• 타이밍
• 올바른 메모리 사용(주소 지정, 중복 등)
• 상태 전환

참고 : 인터럽트 테스트의 경우 모든 인터럽트는 초기 요청부터 전체 서비스를 거쳐 완료될 때까지 독립적으로 확인됩니다. 테스트 케이스는 인터럽트를 적절하게 테스트하기 위해 특별히 설계됩니다.

소프트웨어 대 소프트웨어 통합 테스트

이는 호스트/타겟 컴퓨터 환경 내에서 작동하는 컴퓨터 소프트웨어 구성 요소(CSC)를 테스트하는 것으로, 전체 시스템(다른 CSC 포함)을 시뮬레이션하고 고수준 기능을 테스트하는 것입니다.

이 연구는 시뮬레이션된 호스트/타겟 환경에서 CSC(클라우드 소스 컨트롤러)의 동작에 초점을 맞춥니다. 소프트웨어 통합에 사용되는 접근 방식은 점진적 접근 방식(하향식, 상향식 또는 이 둘을 조합한 샌드위치 방식 또는 하이브리드 방식)일 수 있습니다.

통합 테스팅의 시작 및 종료 기준

접근 방식과 두 가지 통합 변형이 확정되면, 팀이 언제 시작하고 언제 종료할 수 있는지가 남은 문제입니다. 일반적으로 통합 테스트를 수행할 때는 ETVX(진입 조건, 작업, 유효성 검사 및 종료 조건) 전략이 사용됩니다.

진입 기준 :

• 완성 단위 테스트

입력 :

• 소프트웨어 요구 사항 데이터
• 소프트웨어 설계 문서
• 소프트웨어 검증 계획
• 소프트웨어 통합 문서

활동:

• 높은 수준 및 낮은 수준의 요구 사항을 기반으로 테스트 사례 및 절차를 만듭니다.
• 공통 기능을 구현하는 하위 수준 모듈 빌드 결합
• 테스트 하네스 개발
• 빌드 테스트
• 테스트를 통과하면 빌드가 다른 빌드와 결합되고 시스템이 전체적으로 통합될 때까지 테스트됩니다.
• 대상 프로세서 기반 플랫폼에서 모든 테스트를 다시 실행하고 결과를 얻습니다.

종료 기준 :

• 대상 하드웨어에 소프트웨어 모듈 통합이 성공적으로 완료되었습니다.
• 지정된 요구 사항에 따라 소프트웨어의 올바른 성능

출력

• 통합 테스트 보고서
• 소프트웨어 테스트 사례 및 절차 [SVCP].

시스템 통합 테스트에서 흔히 발생하는 문제점

체계적인 접근 방식과 명확한 종료 기준을 갖추더라도, 통합 환경은 단위 테스트 중에는 드러나지 않는 문제를 야기할 수 있습니다. 이러한 문제를 조기에 파악하면 개발 일정을 현실적으로 유지할 수 있습니다.

• 환경 불일치: 통합된 테스트 환경 실제 생산 환경을 거의 반영하지 않기 때문에 타이밍 및 구성 결함은 매우 늦게 발견됩니다.
• 의존성 준비 상태: 타사 및 기존 인터페이스는 종종 미완성 상태이므로 테스터는 계획보다 훨씬 오랫동안 스텁과 시뮬레이터에 의존해야 합니다.
• 데이터 불일치: 두 모듈이 동일한 레코드를 다르게 표현할 수 있으며, 이로 인해 눈에 띄는 오류 대신 미묘한 불일치가 발생할 수 있습니다.
• 결함 소유권: 두 팀에 걸쳐 실패가 발생했을 경우, 근본 원인 분석이 필요합니다. 결함 관리 속도가 눈에 띄게 느려집니다.
• 회귀 분석 비용: 새로운 인터페이스가 추가될 때마다 범위가 넓어집니다. 회귀 테스트 통합 솔루션이므로 수동으로 다시 실행하는 것은 곧 지속 불가능해집니다.

이러한 문제들은 대부분 기술적인 난관이라기보다는 일정상의 위험입니다. 첫 번째 빌드를 통합하기 전에 인터페이스 준비 날짜, 시뮬레이터 범위, 결함 분류 담당자를 합의하면 이러한 위험의 대부분을 제거할 수 있습니다. 공급업체 소유 인터페이스의 경우, 합의된 메시지 형식과 에스컬레이션 담당자 연락처도 기록해 두어야 합니다. 담당자가 누락되면 결함 수정이 필요 이상으로 지연될 수 있기 때문입니다.

시스템 통합 테스트를 위한 최고의 사례

반복 가능한 SIT 사이클은 툴보다는 인터페이스, 데이터 및 증거에 대한 규율에 더 크게 좌우됩니다. 아래 다섯 가지 실천 방안은 소규모 임베디드 빌드부터 대규모 멀티벤더 환경에 이르기까지 모든 규모의 환경에 적합하며, 각각 후반 테스트 단계에서 발생하는 재작업을 줄여줍니다.

1. 먼저 모든 인터페이스를 매핑하세요. 테스트 케이스를 작성하기 전에 각 데이터 교환, 그 방향, 프로토콜 및 담당자를 나열하십시오.
2. 위험도에 따라 우선순위를 정하세요. 돈, 신원 또는 규제 대상 데이터가 오가는 인터페이스를 외관상의 인터페이스보다 먼저 검증하십시오.
3. 실제와 유사한 테스트 데이터를 설계하십시오. 정상 범위, 경계 범위 및 비정상 범위를 모두 포함하여 스케일링 및 반올림 오류를 조기에 파악할 수 있도록 합니다.
4. 안정적인 경로를 자동화하세요. 와이어 인터페이스 검사가 진행됩니다. 지속적인 통합 파이프라인이 모든 빌드에서 해당 항목들을 다시 검증하도록 설계되었습니다.
5. 증거를 보관하세요 trac가능함. 각 결과를 요구 사항과 연결합니다. trac가능성 매트릭스 따라서 퇴사 기준은 주장하는 것이 아니라 입증할 수 있는 것입니다.

⚠ 팁: 통합을 시작하기 전에 인터페이스 사양을 확정하십시오. 메시지 형식에 대한 늦은 변경은 인터페이스 양쪽의 테스트 케이스를 무효화하며, SIT 재작업의 가장 흔한 원인입니다.

자주 묻는 질문