모델에서 테스트 개발
Microsoft Visual Studio Ultimate에서는 요구 사항 및 아키텍처 모델을 사용하여 시스템과 시스템 구성 요소의 테스트를 구성할 수 있습니다. 이렇게 하면 사용자 및 다른 관련자에게 중요한 요구 사항을 테스트할 수 있으며 요구 사항이 변경될 경우 테스트를 신속하게 업데이트할 수 있습니다. Microsoft Test Manager를 사용하는 경우 모델과 테스트 간의 링크를 유지 관리할 수도 있습니다.
시스템 및 하위 시스템 테스트
시스템 테스트는 수용 테스트라고도 하며 사용자의 요구가 충족되는지 여부를 테스트합니다. 이러한 테스트는 내부 디자인 대신 외부적으로 나타나는 시스템의 동작과 관계가 있습니다.
시스템 테스트는 시스템을 확장하거나 다시 디자인할 때 매우 유용합니다. 예를 들어 코드를 변경할 경우 버그가 발생하지 않도록 합니다.
시스템을 변경하거나 확장하려는 경우 기존 시스템에서 실행되는 시스템 테스트 집합으로 시작하면 도움이 됩니다. 그런 다음 새 요구 사항을 테스트할 수 있도록 기존 테스트를 확장하거나 조정하고, 코드를 변경한 후 전체 테스트 집합을 다시 실행할 수 있습니다.
새 시스템을 개발하는 경우 개발 작업이 시작되는 즉시 테스트 만들기를 시작할 수 있습니다. 각 기능을 개발하기 전에 테스트를 정의하면 매우 특정한 방식으로 요구 사항 논의를 캡처할 수 있습니다.
하위 시스템 테스트는 시스템의 주요 구성 요소에 동일한 원칙을 적용합니다. 각 구성 요소는 다른 구성 요소와 별개로 테스트됩니다. 하위 시스템 테스트는 구성 요소의 사용자 인터페이스 또는 API에서 볼 수 있는 동작에 집중합니다.
테스트를 실행하는 방법에 대한 자세한 내용은 응용 프로그램 테스트을 참조하십시오.
요구 사항 모델에서 시스템 테스트 파생
시스템 테스트와 요구 사항 모델 간의 관계를 만들고 유지 관리할 수 있습니다. 이러한 관계를 만들기 위해 요구 사항 모델의 주요 요소에 대응하는 테스트를 작성합니다. Visual Studio Ultimate에서는 테스트와 모델 요소 간의 링크를 만들어 관계를 유지 관리할 수 있습니다. 요구 사항 모델에 대한 자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.
사용 사례별 테스트 작성
Microsoft Test Manager를 사용하는 경우 요구 사항 모델에 정의한 각 사용 사례에 대한 테스트 그룹을 만들 수 있습니다. 예를 들어 Create Order와 Add Item to Order를 포함하는 Order a Meal 사용 사례가 있으면 전체뿐만 아니라 하위 사용 사례에 대한 테스트를 둘 다 만들 수 있습니다. 사용 사례에 대한 자세한 내용은 UML 사용 사례 다이어그램: 지침을 참조하십시오.
다음과 같은 유용한 지침을 참조하십시오.
각 사용 사례에는 주 경로 및 예외적 결과에 대한 몇 가지 테스트가 포함되어야 합니다.
요구 사항 모델에 사용 사례를 기술하는 경우 목표를 달성하기 위해 사용자가 수행하는 절차를 상세하게 기술하는 것보다 사후 조건, 즉 달성할 목표를 정의하는 것이 더 중요합니다. 예를 들어 Order a Meal의 사후 조건은 Restaurant에서 Customer를 위해 식사를 준비 중이고 Customer가 지불을 완료했다는 것이 될 수 있습니다. 사후 조건은 테스트에서 확인해야 할 기준입니다.
사후 조건의 개별 절에 기초하여 별도의 테스트를 작성합니다. 예를 들어 식당에 주문을 알리는 데 대한 테스트와 고객이 지불하는 데 대한 테스트를 각각 만들어야 합니다. 이렇게 테스트를 분리하면 다음과 같은 이점이 있습니다.
요구 사항의 여러 요소가 개별적으로 변경되는 경우가 종종 있습니다. 이런 식으로 요소에 따라 테스트를 분리하면 요구 사항이 변경될 경우 테스트를 쉽게 업데이트할 수 있습니다.
개발 계획에서 특정 사용 사례의 요소 중 하나를 다른 것보다 먼저 구현할 경우 개발이 진행됨에 따라 테스트를 개별적으로 가능하게 할 수 있습니다.
테스트를 디자인할 때 사후 조건이 달성되었는지 여부를 확인하는 스크립트 또는 코드와 테스트 데이터 선택을 분리합니다. 예를 들어 입력이 4이고 출력이 2인지 확인하는 간단한 산술 함수 테스트의 경우, 입력을 선택하고 출력에 같은 값을 곱한 후 결과가 원래 입력한 값인지 확인하도록 스크립트를 디자인하십시오. 이 스타일을 사용하면 테스트 본문을 변경하지 않고 테스트 입력을 다양하게 바꿀 수 있습니다.
사용 사례에 테스트 연결
테스트 관리자를 사용하여 테스트를 디자인하고 실행하는 경우 요구 사항, 사용 사례 또는 사용자 스토리 작업 항목 조건에서 테스트를 구성할 수 있습니다. 이러한 작업 항목을 모델의 사용 사례에 연결할 수 있습니다. 이렇게 하면 요구 사항 변경 내용을 테스트까지 신속하게 추적할 수 있으므로 각 사용 사례의 진행 상태를 관리할 수 있습니다.
사용 사례에 테스트를 연결하려면
테스트 관리자에서 요구 사항을 만들고 이 요구 사항을 기초로 테스트 도구 모음을 작성합니다. 이 작업을 수행하는 방법을 보려면 요구 사항 또는 사용자 스토리를 사용하여 테스트 계획 만들기를 참조하십시오.
이때 만드는 요구 사항은 Team Foundation Server의 작업 항목이며, Team Foundation에서 프로젝트에 사용되는 프로세스 템플릿에 따라 사용자 스토리, 요구 사항 또는 사용 사례 작업 항목이 될 수 있습니다. 자세한 내용은 프로젝트 계획 및 추적을 참조하십시오.
요구 사항 작업 항목을 모델에서 하나 이상의 사용 사례에 연결합니다.
사용 사례 다이어그램에서 사용 사례를 마우스 오른쪽 단추로 클릭하고 작업 항목에 연결을 클릭합니다. 자세한 내용은 방법: 모델 요소에서 작업 항목으로 연결을 참조하십시오.
테스트 도구 모음에 추가합니다. 테스트 도구 모음은 사용 사례를 확인하는 테스트 사례입니다.
일반적으로 각 사용자 스토리 또는 요구 사항 작업 항목은 모델에서 여러 개의 사용 사례에 연결되고, 각 사용 사례는 여러 개의 사용자 스토리 또는 요구 사항에 연결됩니다. 이는 각 사용자 스토리 또는 요구 사항이 여러 개의 사용 사례를 개발하는 작업 집합을 포함하기 때문입니다. 예를 들어 프로젝트 반복의 초기 단계에서는 고객이 카탈로그에서 품목을 선택하면 해당 품목이 배송될 수 있는 기본적인 사용자 스토리를 개발할 수 있습니다. 또한 이후 반복에서는 주문이 완료되면 사용자가 대금을 지불하고 공급자가 상품을 보낸 후 대금을 받도록 스토리가 바뀔 수 있습니다. 각 스토리는 Order Goods 사용 사례의 사후 조건에 절을 추가합니다.
사용 사례 다이어그램에서 별도의 주석으로 사후 조건의 절을 작성하여 요구 사항에서 해당 절로 연결되는 개별 링크를 만들 수 있습니다. 각 주석을 요구 사항 작업 항목에 연결하고 이 주석을 다이어그램의 사용 사례에 연결할 수 있습니다.
요구 사항 형식을 기초로 테스트 작성
요구 사항 모델의 형식, 즉 클래스, 인터페이스 및 열거형은 사용자가 비즈니스에 대해 어떻게 생각하고 서로 의견을 교환하는지에 대해 그 개념과 관계를 기술합니다. 이때 시스템 내부 디자인과 관련된 형식은 제외됩니다.
이러한 요구 사항 형식으로 테스트를 디자인하십시오. 이렇게 하면 요구 사항 변경에 대해 논의할 때 이러한 변경 내용을 테스트에서 필요한 변경 내용과 쉽게 연결할 수 있습니다. 이를 통해 테스트와 예상 결과에 대해 최종 사용자 및 다른 관련자와 직접 논의할 수 있게 됩니다. 즉, 사용자의 요구를 개발 프로세스 외부에서 유지 관리할 수 있으며 디자인 자체의 가능한 오류와 관련된 테스트를 불필요하게 만들지 않아도 됩니다.
수동 테스트의 경우 테스트 스크립트에서 요구 사항 모델의 용어를 따라야 합니다. 자동화된 테스트의 경우에는 요구 사항 클래스 다이어그램을 테스트 코드의 기초로 사용하고, 요구 사항 모델을 코드에 연결하는 접근자 및 업데이트 프로그램 함수를 만들어야 합니다.
Menu, Menu Item 및 Order라는 형식과 이러한 형식 간의 연결을 포함하는 요구 사항 모델을 예로 들어 봅니다. 이 모델은 식사 주문 시스템에서 저장하고 처리하는 정보를 나타내지만 구현의 복잡성은 나타내지 않습니다. 작동 중인 시스템의 경우 데이터베이스, 사용자 인터페이스 및 API에서 각 형식이 다르게 구현될 수 있습니다. 또한 분산 시스템의 경우에는 각 인스턴스의 변형된 형태가 시스템의 여러 구성 요소에 동시에 저장되어 있을 수 있습니다.
Add Item to Order와 같은 사용 사례를 테스트하려면 테스트 메서드에 다음과 같은 코드가 포함되어야 합니다.
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 비즈니스의 경우 고객은 다양한 Menu에서 선택할 수 있지만 모든 Order에서 모든 Item은 단일 Menu에서 선택되어야 합니다. 이 비즈니스 규칙은 요구 사항 클래스 모델에서 Order, Menu 및 Item 간 연결에 대해 고정(invariant)으로 표현될 수 있습니다.
이 유형의 고정 규칙은 현재 정의된 모든 사용 사례뿐만 아니라 나중에 정의될 다른 모든 사용 사례도 제어합니다. 따라서 이러한 규칙은 사용 사례와 별도로 작성하고 테스트하는 것이 좋습니다.
고정 비즈니스 규칙을 클래스 다이어그램의 주석으로 작성할 수 있습니다. 자세한 내용은 UML 클래스 다이어그램: 지침을 참조하십시오.
주석을 요구 사항 또는 사용자 스토리 작업 항목에 연결하여 테스트를 비즈니스 규칙에 연결할 수 있으며, 이렇게 하면 테스트 관리자의 테스트 도구 모음에 연결할 수 있습니다. 자세한 내용은 모델 요소에 테스트 사례 연결을 참조하십시오.
성능 및 기타 서비스 품질 요구 사항을 사용 사례, 동작 또는 시퀀스 다이어그램의 주석에 기록할 수 있습니다. 또한 요구 사항 작업 항목 및 테스트 도구 모음에 연결할 수도 있습니다.
테스트를 위한 시퀀스 및 동작 다이어그램
요구 사항 또는 아키텍처 모델에 시퀀스 다이어그램이나 동작 다이어그램이 포함되어 있으면 다이어그램을 따르는 테스트를 직접 작성할 수 있습니다.
다이어그램에서 분기와 루프를 통과하는 여러 경로를 동적으로 선택하는 테스트를 디자인하면 유용할 때가 종종 있습니다.
각 메시지 또는 동작 이후에 시스템 상태를 확인해 보십시오. 이렇게 하려면 추가 도구가 필요할 수 있습니다.
모델에서 하위 시스템 테스트 파생
규모가 큰 시스템의 수준 높은 디자인에서는 구성 요소 또는 하위 시스템을 식별할 수 있습니다. 구성 요소 또는 하위 시스템은 개별적으로 디자인할 수 있거나 다른 컴퓨터에 배치되는 하위 요소를 나타내거나, 다양한 방식으로 다시 결합할 수 있는 재사용 가능한 모듈입니다. 자세한 내용은 UML 구성 요소 다이어그램: 지침을 참조하십시오.
전체 시스템에 사용하는 것과 같은 원칙을 각 주요 구성 요소에 적용할 수 있습니다. 대형 프로젝트의 각 구성 요소에는 자체적으로 요구 사항 모델이 있을 수 있습니다. 또한 작은 프로젝트에서는 아키텍처 모델 또는 수준 높은 디자인을 만들어 주요 구성 요소 및 구성 요소의 상호 작용을 표시할 수 있습니다. 자세한 내용은 소프트웨어 시스템의 아키텍처 모델링을 참조하십시오.
두 경우 모두 요구 사항 모델과 시스템 테스트 간에 했던 것과 같은 방식으로 모델 요소와 하위 시스템 테스트 간의 관계를 설정할 수 있습니다.
제공된 인터페이스와 필요한 인터페이스를 사용하여 구성 요소 격리
구성 요소가 시스템의 다른 요소 또는 외부 서비스에 갖는 모든 종속성을 식별하고 이를 필요한 인터페이스로 나타내면 유용합니다. 일반적으로 이 방법을 사용하면 구성 요소가 훨씬 많이 분리되어 디자인의 나머지 부분에서 쉽게 떨어질 수 있는 상태가 되도록 다시 디자인됩니다.
이러한 분리는 구성 요소를 테스트할 때 서비스에서 일반적으로 사용하는 모의 개체로 대체하여 실행할 수 있다는 이점이 있습니다. 모의 개체는 테스트 용도로 설치되는 구성 요소입니다. 모의 구성 요소는 시뮬레이션된 데이터로 쿼리에 응답하여 실제 구성 요소에 필요한 인터페이스를 제공합니다. 이러한 모의 구성 요소는 구성 요소의 모든 인터페이스에 연결할 수 있는 전체 테스트 도구의 일부를 구성합니다.
모의 테스트를 실행하면 사용할 서비스를 포함하는 다른 구성 요소를 계속 개발 환경에 유지하면서 해당 구성 요소를 개발할 수 있으므로 유용합니다.
테스트와 모델의 관계 유지 관리
몇 주에 한 번씩 반복을 수행하는 일반적인 프로젝트의 경우 각 반복의 시작 부분 근처에서 요구 사항 검토가 시작됩니다. 회의에서는 다음 반복에 제공될 기능에 대해 논의합니다. 요구 사항 모델을 사용하면 개발할 동작의 개념, 시나리오, 시퀀스 등을 논의하는 데 도움이 됩니다. 비즈니스 관련자가 우선 순위를 설정하면 개발자가 계획을 평가하고 테스터는 각 기능의 예상 동작이 정확하게 캡처되도록 합니다.
테스트를 작성하는 것은 요구 사항을 정의하는 가장 효과적인 방법이며 사용자가 무엇을 필요로 하는지에 대해서도 명확하게 이해할 수 있는 유용한 방법입니다. 그러나 테스트 작성은 세부 사항을 실시하는 동안 시간이 너무 오래 걸리는 반면 모델 만들기는 훨씬 빨리 완료할 수 있습니다.
테스트 측면에서 보면 요구 사항 모델을 간략한 테스트로 간주할 수 있습니다. 따라서 프로젝트 전체에서 테스트와 모델의 관계를 유지하는 것이 중요합니다.
모델 요소에 테스트 사례 연결
프로젝트에서 테스트 관리자를 사용하는 경우 테스트를 모델 요소에 연결할 수 있습니다. 이렇게 하면 요구 사항 변경에 영향을 받는 테스트를 빨리 찾을 수 있으며 요구 사항이 구현된 범위를 추적할 수 있습니다.
모든 종류의 요소에 테스트를 연결할 수 있습니다. 예를 들면 다음과 같습니다.
사용 사례를 사용 사례 실행 테스트에 연결합니다.
사용 사례 사후 조건의 절 또는 목표를 해당 사용 사례에 연결되는 주석에 쓴 다음, 테스트를 각 주석에 연결합니다.
클래스 다이어그램 또는 동작 다이어그램의 주석에 고정 규칙을 작성하여 테스트에 연결합니다.
동작 다이어그램 또는 개별 작업에 테스트를 연결합니다.
테스트할 구성 요소 또는 하위 시스템에 테스트 도구 모음을 연결합니다.
모델 요소 또는 관계에 테스트를 연결하려면
테스트 관리자에서 요구 사항을 만들고 이 요구 사항을 기초로 테스트 도구 모음을 작성합니다. 이 작업을 수행하는 방법을 보려면 요구 사항 또는 사용자 스토리를 사용하여 테스트 계획 만들기를 참조하십시오.
이때 만드는 요구 사항은 Team Foundation Server의 작업 항목이며, Team Foundation에서 프로젝트에 사용되는 프로세스 템플릿에 따라 사용자 스토리, 요구 사항 또는 사용 사례 작업 항목이 될 수 있습니다. 자세한 내용은 프로젝트 계획 및 추적을 참조하십시오.
요구 사항 작업 항목을 모델에서 하나 이상의 요소에 연결합니다.
모델링 다이어그램에서 요소, 주석 또는 관계를 마우스 오른쪽 단추로 클릭하고 작업 항목에 연결을 클릭합니다. 자세한 내용은 방법: 모델 요소에서 작업 항목으로 연결을 참조하십시오.
모델 요소로 표현된 요구 사항을 확인하는 테스트 사례, 즉 테스트 도구 모음에 추가합니다.