모델에서 테스트 개발
요구 사항 및 아키텍처 모델을 사용하여 시스템 및 해당 구성 요소의 테스트를 구성하도록 지원할 수 있습니다. 이렇게 하면 사용자 및 기타 이해 관계자에게 중요한 요구 사항을 테스트하는지 확인할 수 있고 요구 사항이 변경될 때 테스트를 빠르게 업데이트할 수 있습니다. Microsoft Test Manager를 사용하는 경우 모델과 테스트 간의 링크를 유지할 수도 있습니다.
이러한 기능을 지원하는 Visual Studio를 확인하려면 아키텍처 및 모델링 도구에 대한 버전 지원을 참조하세요.
시스템 및 하위 시스템 테스트
‘시스템 테스트’는 ‘수용 테스트’라고도 하며, 사용자 요구가 충족되는지 여부를 테스트합니다. 이러한 테스트는 내부 디자인이 아니라 시스템 외부에 표시되는 동작과 관련이 있습니다.
시스템 테스트는 시스템을 확장하거나 다시 디자인할 때 매우 유용합니다. 코드를 변경할 때 버그가 발생하는 것을 방지하는 데 도움이 됩니다.
시스템 변경 또는 확장을 계획하는 경우 기존 시스템에서 실행되는 시스템 테스트 집합으로 시작하는 것이 좋습니다. 그런 다음 테스트를 확장하거나 조정하여 새 요구 사항을 테스트하고, 코드를 변경하고, 전체 테스트 집합을 다시 실행합니다.
새 시스템을 개발하는 경우 개발이 시작되는 즉시 테스트 만들기를 시작할 수 있습니다. 각 기능을 개발하기 전에 테스트를 정의하면 매우 구체적인 방식으로 요구 사항 논의를 캡처할 수 있습니다.
하위 시스템 테스트는 시스템의 주요 구성 요소에 동일한 원칙을 적용합니다. 각 구성 요소가 다른 구성 요소와 별도로 테스트됩니다. 하위 시스템 테스트는 구성 요소의 사용자 인터페이스 또는 API에 표시되는 동작에 중점을 둡니다.
요구 사항 모델에서 시스템 테스트 파생
시스템 테스트와 요구 사항 모델 간의 관계를 만들고 유지 관리할 수 있습니다. 이 관계를 설정하려면 요구 사항 모델의 주요 요소에 해당하는 테스트를 작성합니다. Visual Studio는 테스트 및 모델 파트 간에 링크를 만들 수 있도록 하여 해당 관계의 유지 관리를 도와줍니다. 요구 사항 모델에 대한 자세한 내용은 사용자 요구 사항 모델링을 참조하세요.
각 사용 사례에 대한 테스트 작성
Microsoft Test Manager를 사용하는 경우 요구 사항 모델에 정의된 각 사용 사례에 대한 테스트 그룹을 만들 수 있습니다. 예를 들어 주문 만들기 및 주문에 항목 추가를 포함하는 음식 주문 사용 사례가 있는 경우 전체 사용 사례 및 보다 자세한 사용 사례에 대한 테스트를 모두 만들 수 있습니다.
다음 지침이 도움이 될 수 있습니다.
각 사용 사례에 주 경로 및 예외적 결과에 대한 여러 테스트가 있어야 합니다.
요구 사항 모델의 사용 사례를 설명하는 경우 목표를 달성하기 위해 사용자가 따라야 하는 절차를 자세히 설명하는 것보다 사후 조건, 즉 달성되는 목표를 정의하는 것이 더 중요합니다. 예를 들어 음식 주문의 사후 조건은 식당에서 고객을 위해 음식을 준비하고 고객이 대금을 지불하는 것일 수 있습니다. 사후 조건은 테스트에서 확인해야 하는 조건입니다.
사후 조건의 개별 절에 따라 별도 테스트를 만듭니다. 예를 들어 레스토랑에 주문을 알리는 테스트와 고객으로부터 대금을 지불 받는 테스트를 별도로 만듭니다. 이렇게 구분하면 다음과 같은 이점이 있습니다.
요구 사항의 여러 측면에서 변경이 독립적으로 자주 발생합니다. 이런 방식으로 테스트를 여러 측면으로 분리하면 요구 사항이 변경될 때 테스트를 쉽게 업데이트할 수 있습니다.
개발 계획에서 사용 사례의 한 측면을 다른 측면보다 먼저 구현하는 경우 개발이 진행됨에 따라 테스트를 별도로 사용하도록 설정할 수 있습니다.
테스트를 디자인할 때 사후 조건이 달성되었는지 여부를 확인하는 테스트 데이터 선택 항목을 코드 또는 스크립트에서 구분합니다. 예를 들어 단순한 산술 함수 테스트는 입력 4, 출력이 2인지 확인이 될 수 있습니다. 대신, 스크립트를 입력 선택, 출력에 자신을 곱하고 결과가 원래 입력인지 확인으로 디자인합니다. 이 스타일을 사용하면 테스트의 본문을 변경하지 않고 테스트 입력을 확인할 수 있습니다.
사용 사례에 테스트 연결
Test Manager를 사용하여 테스트를 디자인 및 실행하는 경우 요구 사항, 사용 사례 또는 사용자 스토리 작업 항목 아래에 테스트를 구성할 수 있습니다. 모델의 사용 사례에 이러한 작업 항목을 연결할 수 있습니다. 이렇게 하면 테스트에 대한 요구 사항 변경을 신속하게 추적할 수 있으며 각 사용 사례의 진행률을 추적하는 데 도움이 됩니다.
사용 사례에 테스트를 연결하려면
Test Manager에서 요구 사항을 만들고 요구 사항에 따라 테스트 도구 모음을 만듭니다.
만드는 요구 사항은 Team Foundation Server의 작업 항목입니다. 프로젝트가 Team Foundation에서 사용하는 프로세스 템플릿에 따라 사용자 스토리, 요구 사항 또는 사용 사례 작업 항목일 수 있습니다. 자세한 내용은 Agile 도구 및 Agile 프로젝트 관리 정보를 참조하세요.
모델에서 하나 이상의 사용 사례에 요구 사항 작업 항목을 연결합니다.
사용 사례 다이어그램에서 사용 사례를 마우스 오른쪽 단추로 클릭한 다음 작업 항목에 연결을 클릭합니다.
테스트 도구 모음에 사용 사례를 확인하는 테스트 사례를 추가합니다.
일반적으로 각 사용자 스토리 또는 요구 사항 작업 항목은 모델의 여러 사용 사례에 연결되며, 각 사용 사례는 여러 사용자 스토리 또는 요구 사항에 연결됩니다. 이는 각 사용자 스토리 또는 요구 사항이 여러 사용 사례를 개발하는 작업 집합을 포함하기 때문입니다. 예를 들어 프로젝트의 초기 반복에서 고객이 카탈로그에서 항목을 선택하고 배달시킬 수 있는 기본 사용자 스토리를 개발할 수 있습니다. 이후 반복에서는 사용자가 주문을 완료할 때 대금을 지불하고 공급자가 상품을 보낸 후 돈을 받는 스토리일 수 있습니다. 각 스토리에서 상품 주문 사용 사례의 사후 조건에 절을 추가합니다.
사용 사례 다이어그램의 별도 주석에 이러한 절을 작성하여 요구 사항과 사후 조건의 절 간에 별도의 링크를 만들 수 있습니다. 각 주석을 요구 사항 작업 항목에 연결하고, 주석을 다이어그램의 사용 사례에 연결할 수 있습니다.
요구 사항 형식에 따른 테스트
요구 사항 모델의 형식, 즉 클래스, 인터페이스 및 열거형은 사용자가 비즈니스에 대해 생각하고 전달하는 방식과 관련해서 개념 및 관계를 설명합니다. 시스템의 내부 디자인에만 관련된 형식은 제외됩니다.
이러한 요구 사항 형식에 따라 테스트를 디자인합니다. 이 연습은 요구 사항 변경을 논의할 때 해당 변경을 필요한 테스트 변경과 쉽게 연결하는 데 도움이 됩니다. 최종 사용자 및 다른 이해 관계자와 직접 테스트 및 예상 결과를 논의할 수 있습니다. 즉, 사용자 요구를 개발 프로세스 외부에서 유지 관리할 수 있으므로 가능한 디자인 결함에 따른 부주의한 테스트 디자인이 방지됩니다.
수동 테스트의 경우 이 연습을 통해 테스트 스크립트에서 요구 사항 모델의 어휘를 준수해야 합니다. 자동화된 테스트의 경우 이 연습을 통해 요구 사항 클래스 다이어그램을 테스트 코드의 기초로 사용하고 접근자 및 업데이트 프로그램 함수를 만들어 요구 사항 모델을 코드에 연결해야 합니다.
예를 들어 요구 사항 모델에 메뉴, 메뉴 항목, 주문 형식과 형식 간의 연결이 포함될 수 있습니다. 이 모델은 음식 주문 시스템에서 저장 및 처리하는 정보를 나타내지만 구현의 복잡성은 나타내지 않습니다. 작동하는 시스템의 데이터베이스, 사용자 인터페이스 및 API에서는 각 형식이 다르게 인식될 수 있습니다. 분산 시스템에서는 각 인스턴스의 여러 변형이 시스템의 서로 다른 파트에 동시에 저장될 수도 있습니다.
주문에 항목 추가와 같은 사용 사례를 테스트하려면 테스트 메서드에 다음과 비슷한 코드가 포함될 수 있습니다.
Order order = ... ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = ...; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
이 테스트 메서드는 요구 사항 모델의 클래스를 사용합니다. 연결 및 특성은 .NET 속성으로 인식됩니다.
이 메서드가 작동하려면 시스템에 액세스하여 현재 상태에 대한 정보를 검색하는 읽기 전용 함수 또는 접근자로 클래스의 속성을 정의해야 합니다. AddItemToOrder와 같은 사용 사례를 시뮬레이트하는 메서드는 해당 API나 사용자 인터페이스 아래의 레이어를 통해 시스템을 구동해야 합니다. Order 및 MenuItem과 같은 테스트 개체의 생성자는 시스템을 구동하여 시스템 내부에 해당 항목도 만들어야 합니다.
대부분의 접근자와 업데이트 프로그램은 애플리케이션의 일반 API를 통해 이미 사용할 수 있습니다. 그러나 테스트를 사용하도록 설정하기 위해 일부 추가 함수를 작성해야 할 수도 있습니다. 이러한 추가 접근자와 업데이트 프로그램을 '테스트 계측'이라고도 합니다. 접근자와 업데이트 프로그램은 시스템의 내부 디자인에 의존하므로 시스템 개발자가 제공해야 하는 반면, 테스터는 요구 사항 모델과 관련해서 테스트 코드를 작성합니다.
자동화된 테스트를 작성하는 경우 일반 테스트를 사용하여 접근자와 업데이트 프로그램을 래핑할 수 있습니다.
비즈니스 규칙 테스트
일부 요구 사항은 하나의 특정 사용 사례와 직접 관련되지 않습니다. 예를 들어 DinnerNow 비즈니스에서는 고객이 많은 메뉴에서 선택할 수 있지만 각 주문에서 선택된 모든 항목은 단일 메뉴에 속해야 합니다. 이 비즈니스 규칙은 요구 사항 클래스 모델에서 주문, 메뉴 및 항목 간의 연결에 대한 고정으로 표현될 수 있습니다.
이러한 종류의 고정 규칙은 현재 정의된 모든 사용 사례뿐 아니라 나중에 정의할 다른 모든 사용 사례에도 적용됩니다. 따라서 사용 사례와 별도로 작성하고 사용 사례와 별도로 테스트하는 것이 유용합니다.
모델에서 하위 시스템 테스트 파생
대규모 시스템의 전반적인 디자인에서 구성 요소 또는 하위 시스템을 식별할 수 있습니다. 이러한 구성 요소 또는 하위 시스템은 별도로 디자인될 수 있거나, 서로 다른 컴퓨터에 있거나, 다양한 방식으로 다시 결합할 수 있는 재사용 가능한 모듈인 파트를 나타냅니다.
전체 시스템에 사용하는 것과 동일한 원칙을 각 주요 구성 요소에 적용할 수 있습니다. 대규모 프로젝트에서는 각 구성 요소에 자체 요구 사항 모델이 있을 수 있습니다. 작은 프로젝트에서는 아키텍처 모델 또는 전반적인 디자인을 만들어 주요 구성 요소 및 상호 작용을 표시할 수 있습니다. 자세한 내용은 앱 아키텍처 모델링을 참조하세요.
두 경우 모두, 요구 사항 모델과 시스템 테스트 간에 관계를 설정하는 것과 동일한 방식으로 모델 요소와 하위 시스템 테스트 간에 관계를 설정할 수 있습니다.
제공된 인터페이스 및 필수 인터페이스로 구성 요소 분리
시스템 또는 외부 서비스의 다른 파트에 대한 구성 요소의 모든 종속성을 식별하고 이러한 종속성을 필수 인터페이스로 나타내는 것이 유용합니다. 이 연습에서는 일반적으로 구성 요소를 훨씬 더 분리되고 디자인의 나머지 파트에서 쉽게 분리할 수 있게 하는 재디자인이 발생합니다.
이러한 분리의 장점은 일반적으로 사용되는 서비스를 모의 개체로 대체하여 테스트를 위해 구성 요소를 실행할 수 있다는 것입니다. 이러한 구성 요소는 테스트 용도로 설정됩니다. 모의 구성 요소는 구성 요소에 필요한 인터페이스를 제공하고 시뮬레이트된 데이터로 쿼리에 응답합니다. 모의 구성 요소는 구성 요소의 모든 인터페이스에 연결할 수 있는 전체 테스트 도구의 일부를 구성합니다.
모의 테스트는 사용하려는 서비스를 제공할 다른 구성 요소가 개발되는 동안 구성 요소를 개발할 수 있다는 이점이 있습니다.
테스트와 모델 간의 관계 유지 관리
몇 주마다 반복을 수행하는 일반적인 프로젝트에서 요구 사항 검토는 각 반복을 시작할 때 수행됩니다. 회의에서는 다음 반복 시 제공할 기능을 논의합니다. 요구 사항 모델을 사용하여 개념, 시나리오 및 개발할 작업 시퀀스를 설명할 수 있습니다. 비즈니스 이해 관계자는 우선 순위를 설정하고, 개발자는 예측하고, 테스터는 각 기능의 예상 동작이 올바르게 캡처되는지 확인합니다.
테스트 작성은 요구 사항을 정의하는 가장 효과적인 방법인 동시에 사용자가 필요한 사항을 명확하게 이해하는 데 효과적인 방법이기도 합니다. 그러나 테스트 작성은 시간이 너무 오래 걸려 사양 워크샵에서 수행하기 어렵지만 모델 생성은 훨씬 더 신속하게 수행할 수 있습니다.
테스트 관점에서 요구 사항 모델은 테스트 축약형으로 간주될 수 있습니다. 따라서 프로젝트 전체에서 테스트와 모델 간의 관계를 유지하는 것이 중요합니다.
모델 요소에 테스트 사례 연결
프로젝트에서 Test Manager를 사용하는 경우 모델의 요소에 테스트를 연결할 수 있습니다. 이렇게 하면 요구 사항 변경의 영향을 받는 테스트를 빠르게 찾을 수 있으며 요구 사항이 인식된 익스텐트를 추적하는 데 도움이 됩니다.
모든 종류의 요소에 테스트를 연결할 수 있습니다. 다음 몇 가지 예를 참조하세요.
실행하는 테스트에 사용 사례를 연결합니다.
사용 사례 사후 조건 또는 목표의 절을 사용 사례에 연결된 주석에 작성하고 각 주석에 테스트를 연결합니다.
클래스 다이어그램 또는 동작 다이어그램의 주석에 고정 규칙을 작성하고 테스트에 연결합니다.
동작 다이어그램 또는 개별 동작에 테스트를 연결합니다.
테스트하는 구성 요소 또는 하위 시스템에 테스트 도구 모음을 연결합니다.
모델 요소 또는 관계에 테스트를 연결하려면
Test Manager에서 요구 사항을 만들고 요구 사항에 따라 테스트 도구 모음을 만듭니다.
만드는 요구 사항은 Team Foundation Server의 작업 항목입니다. 프로젝트가 Team Foundation에서 사용하는 프로세스 템플릿에 따라 사용자 스토리, 요구 사항 또는 사용 사례 작업 항목일 수 있습니다. 자세한 내용은 Agile 도구 및 Agile 프로젝트 관리 정보를 참조하세요.
모델에서 하나 이상의 요소에 요구 사항 작업 항목을 연결합니다.
모델링 다이어그램에서 요소, 주석 또는 관계를 마우스 오른쪽 단추로 클릭한 다음 작업 항목에 연결을 클릭합니다.
모델 요소에서 표현된 요구 사항을 확인하는 테스트 사례를 테스트 도구 모음에 추가합니다.