모델 기반 테스트란 무엇입니까?

모델 기반 테스트란 무엇입니까?

모델 기반 테스트 테스트는 테스트 대상 소프트웨어의 실행 시간 동작을 모델이 예측한 내용과 비교하여 확인하는 소프트웨어 테스트 기법입니다. 모델은 입력 시퀀스, 동작, 조건, 출력 및 입력에서 출력으로의 데이터 흐름을 표현하여 시스템의 동작을 설명한 것입니다. 유용한 모델은 실질적으로 이해하기 쉽고, 재사용 및 공유가 가능해야 하며, 테스트 대상 시스템을 정확하게 설명해야 합니다.

다양한 모델이 존재하며, 각 모델은 시스템 동작의 서로 다른 측면을 설명합니다. 일반적인 예는 다음과 같습니다.

• 데이터 흐름
• 제어 흐름
• 의존성 그래프
• 의사결정표
• 상태 전이 기계

모델 기반 테스트는 모델에 의해 결정된 동작에 대한 시스템의 반응을 분석하는 것입니다. 먼저 동작을 입력한 후, 시스템이 모델의 예측대로 반응하는지 확인합니다. 두 결과가 일치하지 않으면 소프트웨어의 결함이거나 모델의 오류일 수 있으며, 둘 다 찾아내는 것이 중요합니다.

이는 시스템 검증을 위한 경량화된 형식적 방법론으로, 하드웨어 테스트뿐 아니라 소프트웨어 테스트에도 쉽게 적용할 수 있습니다. 테스트가 코드 자체가 아닌 동작 명세에서 도출되기 때문에, 이 기법은 하드웨어 테스트에 적합합니다. 블랙 박스 테스트 가족 소프트웨어 테스트 기법.

모델 기반 테스트 예

행동 모델을 이해하는 가장 간단한 방법은 모델을 따라가 보는 것입니다. 아래 다이어그램은 간단한 텍스트 편집 작업을 모델링한 것으로, 각 상자는 애플리케이션의 상태를 나타내고 각 화살표는 사용자가 취할 수 있는 동작을 나타냅니다.

이 모델은 메모장에서 시를 쓰는 간소화된 접근 방식과 각 단계와 관련된 가능한 동작들을 설명합니다. 애플리케이션 실행, 시 입력, 파일 저장과 같은 모든 동작에 대해, 테스트 사례 테스트 케이스를 생성하고 그 결과를 검증할 수 있습니다. 예를 들어, 동일한 다이어그램에서 저장하지 않고 시작해서 닫는 등 다른 경로를 따라가면 추가적인 설계 비용 없이 다른 테스트 케이스가 생성되는데, 이것이 바로 이 기술의 경제적인 장점입니다.

MBT의 종류

모델 기반 테스트 프레임워크에는 두 가지 유형이 있으며, 두 유형의 차이점은 테스트 단계가 생성되는 시점에 있습니다.

• 오프라인 / 사전적: 테스트 스위트를 실행하기 전에 생성합니다. 테스트 스위트는 테스트 케이스 모음이며, 이 모드에서는 다른 테스트 스위트와 마찬가지로 저장, 검토 및 재실행됩니다. 자동화 테스트 유산.
• 온라인/즉석: 테스트 실행 중에 테스트 스위트가 생성되며, 다음 단계는 시스템이 이전 단계에 실제로 어떻게 반응했는지에 따라 선택됩니다.

오프라인 생성 방식은 검토 및 반복 가능한 테스트 세트가 필요한 규제 환경에 적합합니다. 온라인 생성 방식은 상태 저장 시스템을 대상으로 하는 장시간 탐색 세션에 적합한데, 이는 생성기가 예측된 응답이 아닌 실제 응답에 반응할 수 있기 때문입니다.

모델 기반 테스트는 어떻게 작동할까요?

어떤 프레임워크를 사용하든, 이 기법은 동일한 5단계를 따릅니다. 각 단계는 다음 단계에서 사용할 산출물을 생성하며, 이것이 바로 테스트 스크립트가 아닌 모델이 팀의 유지 관리 대상이 되는 이유입니다.

• 1단계: 모델을 만듭니다. 요구사항 또는 명세서를 요약문으로 변환합니다.trac예상되는 동작에 대한 모델로서, 상태, 상태 간의 전환, 그리고 각 전환을 유발하는 입력값을 정의합니다.
• 2단계: 시험 선택 기준을 정하십시오. 기준은 생성기가 언제 멈춰야 하는지를 알려줍니다. 일반적인 기준으로는 모든 상태를 최소 한 번씩 방문하는 모든 상태 탐색, 모든 전환을 최소 한 번씩 실행하는 모든 전환 탐색, 그리고 더 심층적인 탐색을 위한 경로 또는 데이터 흐름 탐색 등이 있습니다.
• 3단계: 평균값 생성tract 테스트 케이스. 이 도구는 모델을 따라 이동하며 일련의 절편을 출력합니다.trac선택된 기준을 만족하는 t단계와 각 단계에서 예상되는 결과.
• 4단계: 복근을 구체화하세요tract 검정. 어댑터 레이어는 각 abs를 매핑합니다.trac시스템에 대한 실제적인 조치, 예를 들어 UI 상호 작용으로 넘어가는 단계입니다. API 호출 또는 프로토콜 메시지. 이 지도ping 이 파일은 한 번 작성되면 생성된 모든 테스트에서 재사용됩니다.
• 5단계: 판결을 집행하고 배정합니다. 테스트 대상 시스템에 대해 구체적인 테스트가 수행되며, 관찰된 각 응답은 모델 예측과 비교되고, 합격 또는 불합격 판정이 기록됩니다. trac그것을 만들어낸 모델 요소로 되돌아갔습니다.

The trac5단계에서 확보한 안정성이 실질적인 이점입니다. 요구사항이 변경되면 모델이 변경되고, 영향을 받는 테스트는 다시 작성하는 대신 새로 생성됩니다. 이것이 바로 팀들이 빈번하게 테스트를 진행하는 이유입니다. 회귀 테스트 안정적인 사양에 비해 가장 큰 이점을 제공합니다.

테스트의 다양한 모델

MBT를 이해하려면 아래에 설명된 몇 가지 모델을 이해해야 합니다. 각 모델은 표현력과 노력의 균형을 중시하므로, 어떤 모델을 선택할지는 테스트 대상 행동의 복잡성에 따라 달라집니다.

유한 상태 머신

이 모델은 테스터가 선택한 입력에 따라 결과를 평가하는 데 도움이 됩니다. 다양한 입력 조합을 통해 시스템의 해당 상태를 생성할 수 있습니다.

이 시스템은 특정 상태와 현재 상태를 가지며, 이는 테스터가 제공하는 입력값 집합에 의해 결정됩니다.

아래 예시를 살펴보세요. 직원들이 시스템에 로그인할 수 있습니다. 직원의 현재 상태는 "로그아웃"이며, 시스템에 로그인하면 "로그인" 상태가 됩니다. "로그인" 상태에서는 시스템에서 문서를 보고, 인쇄하고, 스캔할 수 있습니다.

해당 예시의 상태 기계는 여기에 나와 있으며, 각 화살표에는 전환을 일으키는 입력값이 표시되어 있습니다.

상태 차트

상태도는 유한 상태 기계의 확장 개념으로, 복잡하고 실시간 시스템에 사용될 수 있습니다. 상태도는 시스템의 다양한 동작을 기술하며, 정해진 수의 상태를 가지고 각 상태에 대한 이벤트 형태로 시스템의 동작을 분석하고 표현합니다. 실제로 중요한 확장 기능은 계층 구조입니다. 상태도는 중첩되고 병렬적인 상태를 허용하므로, 수십 개의 평면 상태가 필요한 기계를 간결하게 그릴 수 있습니다.

예를 들어, 결함 관리 도구에 결함이 등록되면 상태는 '새로 등록됨'으로 표시됩니다. 개발자가 결함을 수정하면 상태를 '수정됨'으로 변경해야 합니다. 결함이 수정되지 않으면 상태는 '다시 열림'으로 변경됩니다. 상태도는 각 상태에 대해 이벤트가 호출되도록 설계해야 합니다.

결함 수명 주기는 아래 그림과 같습니다. 각 상태는 상태로 표시되고, 각 워크플로 작업은 결함을 상태 간에 이동시키는 이벤트로 표시됩니다.

통합 모델링 언어(UML)

통합 모델링 언어(UML) UML은 표준화된 범용 모델링 언어입니다. UML은 매우 복잡한 시스템 동작을 설명할 수 있는 시각적 모델을 만드는 데 사용되는 일련의 그래픽 표기법을 포함합니다.

UML에는 다음과 같은 표기법이 있습니다.

• 활동
• 배우
• 비즈니스 프로세스
• 구성 요소
• 프로그래밍 언어

아래의 UML 샘플 모델에서 볼 수 있듯이, 활동 및 상태 머신 다이어그램은 테스트 생성기가 가장 자주 읽는 다이어그램입니다.

모델 기반 테스트 도구

이론상의 모델만으로는 아무것도 생성할 수 없습니다. 모델을 탐색하고 테스트 경로를 생성하려면 제너레이터가 필요하며, 이러한 도구 시장은 오픈 소스 제너레이터와 상용 테스트 설계 플랫폼으로 나뉩니다.

• 그래프워커 — 방향 그래프 형태의 모델을 읽고 선택 가능한 생성기와 종료 조건을 사용하여 테스트 경로를 생성하는 오픈 소스 도구입니다.
• fMBT — 인텔에서 제공하는 오픈 소스 모델 기반 테스트 도구 세트로, 상태 모델에 대한 테스트 생성 및 실행을 지원합니다.
• 컨포믹 — 그래픽 동작 모델에서 테스트 케이스와 스크립트를 도출하는 상용 자동화 테스트 설계 제품입니다.
• MaTeLo와 MBTsuite — 통계적 사용 모델 및 기존 자동화 프레임워크에 테스트를 생성하는 것을 목표로 하는 상용 플랫폼.
• 스펙 익스플로러 - MicrosoftVisual Studio용 모델 기반 테스트 확장 프로그램으로, 프로토콜 테스트 관련 문헌에서 널리 인용됩니다.

선택은 기능 목록보다는 다음 두 가지 질문에 더 크게 좌우됩니다. 첫째, 팀이 실제로 어떤 표기법을 사용할 수 있는지, 둘째, 해당 도구가 이미 사용 중인 자동화 프레임워크에 통합할 수 있는 테스트 스위트를 생성할 수 있는지 여부입니다. 실행할 수 없는 테스트 스위트를 생성하는 생성기는 프로세스를 간소화하는 대신 불필요한 단계를 추가합니다.

모델 기반 테스트 vs 전통적인 테스트 설계

손으로 직접 시험 문제를 작성하는 방식과의 차이점을 명확히 하는 것은 중요합니다. 왜냐하면 두 방식 중 어느 하나가 단순히 더 낫다고 할 수 있는 것이 아니라, 각기 다른 부분에서 한계를 드러내기 때문입니다.

아래	모델 기반 테스트	전통적인 시험 설계
테스트 케이스의 출처	행동 모델로부터 자동으로 생성됨	요구사항을 바탕으로 테스터가 개별적으로 작성함
요구사항 변경의 영향	모델을 업데이트하고 영향을 받는 테스트를 다시 생성합니다.	영향을 받는 각 테스트 케이스를 수동으로 찾아 편집하십시오.
적용 범위	모든 상태 또는 모든 전환과 같은 모델 기준에 따라 측정됨	요구사항 대비 평가되며, 테스터의 판단에 따라 달라집니다.
선행 비용	난이도 높음: 모델링 기술, 도구 설정 및 어댑터 레이어	낮음: 테스터는 즉시 작성을 시작할 수 있습니다.
최고의 핏	상태를 유지하고 수명이 길며 사양이 안정적인 시스템	단기 프로젝트, 단편 작품 및 탐색적 작업
주요 고장 모드	잘못되었거나 오래된 모델은 아무런 경고 없이 잘못된 테스트를 생성합니다.	대규모 제품군 전체에 걸쳐 누락된 부분과 중복된 부분이 누적됩니다.

아래의 발전 과정은 해당 기술의 맥락을 보여줍니다. 수동 테스트 실행은 자동화된 실행으로 대체되었고, 모델 기반 접근 방식은 자동화를 한 단계 더 앞당겨 테스트 설계 자체에 적용합니다.

모델 기반 테스트의 과제

조직에 MBT를 도입하려면 상당한 자금과 노력이 필요합니다. 다음은 MBT 도입의 단점입니다. 소프트웨어 공학:

• 테스터는 기존 테스트 설계 방식에서는 요구하지 않는 모델링 기술이 필요합니다.
• 학습 곡선은 길고, 첫 번째 프로젝트는 대개 절감액보다 비용이 더 많이 듭니다.
• 모델 자체는 이해하고 검토하기가 어려울 수 있으며, 특히 규모가 커질수록 더욱 그렇습니다.
• 사양과 어긋나는 모델은 확신에 찬 잘못된 테스트 결과를 생성합니다.
• ABS를 변환하는 어댑터 레이어trac실제 실행 단계로의 전환 과정은 별도로 작성하고 관리해야 합니다.
• 모델 크기는 빠르게 증가하므로, 제약 없는 상태 모델은 어떤 팀도 실행할 수 있는 것보다 더 많은 경로를 생성할 수 있습니다.

이러한 이유들 중 어느 것도 해당 기술을 피해야 할 이유는 아니지만, 종합적으로 볼 때 MBT가 전체 시스템이 아닌 하나의 안정적인 하위 시스템에 먼저 도입되는 이유를 설명해 줍니다. 소프트웨어 테스팅 수명주기 한 번에.

모델 기반 테스트의 장점

이러한 비용 대비 MBT의 이점은 다음과 같습니다.

• 개별 테스트가 아닌 모델을 편집하기 때문에 테스트 케이스 및 테스트 스위트 관리가 쉽습니다.
• 장기 프로젝트의 전체 수명 주기 동안 비용 절감.
• 개선 테스트 범위생성기가 사람이 건너뛸 경로를 탐색하기 때문입니다.
• 생성된 여러 테스트 스위트는 여러 대의 컴퓨터에서 동시에 실행될 수 있습니다.
• 모델 구축 과정에서, 즉 코드가 실행되기 전에 모호성이 드러나기 때문에 조기에 결함을 감지할 수 있습니다.
• 동일한 테스트 노력에 비해 발견된 결함 수가 증가했습니다.
• 모델과 어댑터가 준비되면 테스트 설계 시간을 절약할 수 있습니다.
• 반복적인 스크립팅 작업에서 모델링 및 분석 작업으로 업무 비중이 옮겨감에 따라 테스터의 직무 만족도가 향상되었습니다.

테스터들은 작업을 진행하면서 자연스럽게 정신적 모델을 구축하는데, MBT는 이러한 정신적 모델을 문서로 옮겨 검토, 버전 관리 및 재사용할 수 있도록 합니다. 이 기법이 다른 접근 방식들과 어떻게 조화를 이루는지에 대해서는 다음에서 설명합니다. 소프트웨어 테스트 유형.

자주 묻는 질문