초기에 자주 테스트

가능한 한 초기에 오류를 파악하면 최소의 비용으로 소프트웨어 품질을 보증할 수 있습니다. Kent Beck과 Cynthia Andres는 그들의 저서에서 "오류는 그 자체로도 많은 돈이 들지만 그것을 제거하는 데에도 많은 돈이 든다는 것, 이것이 소프트웨어 개발의 딜레마이다. 하지만 대부분의 오류는 그것을 방지하는 데 들었을 비용보다 더 많은 비용을 소모하고서야 끝이 난다."라고 말했습니다(자세한 내용은 Extreme Programming Explained: Embrace Change 웹 페이지 참조). 팀에서는 모범 사례와 도구를 통해 프로젝트 수명 주기 내내 프로젝트의 품질을 유지하여 오류를 방지하고 수정하는 데 드는 비용을 최소화할 수 있습니다.

프로젝트를 진행하면서 오류를 찾아 수정하고 수정 결과를 확인한다면 언제든지 프로젝트의 품질을 보다 정확하게 측정할 수 있습니다. 자주 테스트하면 팀과 관련자가 프로젝트 기간 내내 코드의 현재 상태를 알고 있는 상태에서 합리적인 결정을 내릴 수 있습니다. 궁극적으로는 출시가 가능하느냐는 질문에 답할 수 있어야 하며 소프트웨어 사용자에게 미칠 영향을 이해하고 있어야 합니다.

이 항목에서는 다음 방법을 권장합니다.

• 각 클래스와 모든 주요 구성 요소의 API에 대해 자동화된 단위 테스트 집합을 만듭니다. 단위 테스트를 작성하는 시간은 팀 멤버 시간의 약 40%를 차지해야 합니다. 자세한 내용은 자동화된 테스트 만들기를 참조하십시오.

• 각 사용자 스토리에 대한 테스트를 만듭니다. 이러한 테스트는 자동화하는 것이 좋습니다. 자세한 내용은 요구 사항 또는 사용자 스토리를 사용하여 테스트 계획 만들기를 참조하십시오.

• 코드를 체크 인하기 전에 단위 테스트를 실행하도록 팀 멤버에게 알려 주는 체크 인 정책을 만듭니다. 자세한 내용은 체크 인 정책 추가를 참조하십시오.

• 전체 테스트 집합을 실행하는 연속 빌드나 야간 빌드를 설정합니다.

• 테스트 검사를 모니터링하여 코드가 모두 테스트되는지 확인합니다. 적어도 70%의 검사를 목표로 합니다. 자세한 내용은 테스트 간격 Excel 보고서(Agile)를 참조하십시오.

• 모든 스프린트의 끝에서 수동 테스트를 실행합니다.

팀에서는 Microsoft Test Manager, Visual Studio ALM(Application Lifecycle Management) 및 Visual Studio Team Foundation Server 간의 통합을 통해 프로젝트 초기에 이러한 테스트 작업을 관리하고 확장할 수 있습니다. 자세한 내용은 응용 프로그램 테스트를 참조하십시오.

항목 내용

• 테스트 전략

• 테스트 계획

• 승인 테스트

• 단위 테스트

• 테스트 기반 개발 및 초기 테스트

• 수동 테스트와 자동화된 테스트

• 테스트 결과 보고

테스트 전략

팀의 테스트 성공 여부는 팀의 규모, 팀에서 사용하는 방법 및 팀의 관리 도구를 비롯한 여러 가지 요소에 따라 결정됩니다. Agile 방법을 사용하면 테스트 결과를 지속적으로 향상시킬 수 있습니다. 이 방법을 적용하면 매우 제한된 리소스로도 테스트를 시작할 수 있을 뿐 아니라 프로젝트 전체 기간에 걸쳐 테스트 방법을 적절하게 조정할 수도 있습니다.

Agile 테스트를 도입할 때 고려해야 할 사항

팀에서 기존 응용 프로그램에 대해 Agile 테스트를 도입할 때는 먼저 스프린트 수준과 프로젝트 수준 모두에서 테스트 전략을 생각합니다. 스프린트 수준에서는 현재 스프린트의 각 사용자 스토리를 처리하기 위한 일련의 승인 테스트를 포함할 수 있습니다. 또한 프로젝트 수준에서는 종단 간 테스트와 같이 전체 프로젝트에 적용되는 테스트를 포함할 수 있습니다. 이렇게 하면 둘 이상의 스프린트에 걸쳐 있는 기능을 확인하려는 경우에 유용합니다. 팀에서 스프린트 중 코드를 빌드하는 동안 모든 종류의 테스트를 만들 수 있습니다. 이러한 테스트로는 단위 테스트, 승인 테스트 및 비기능 테스트(예: 성능 테스트, 보안 테스트 및 가용성 테스트)가 있습니다.

Agile 테스트 방법을 적용하려면 먼저 응용 프로그램과 팀에서 사용하는 시스템의 기록을 살펴봐야 합니다. 새 응용 프로그램과 기존 응용 프로그램 모두에 Agile 테스트 방법을 적용할 수 있습니다. Microsoft Test Manager를 사용하여 전체 프로젝트에 대한 테스트 계획과 프로젝트의 각 스프린트에 대한 테스트 계획을 만들 수 있습니다. 팀에서는 이러한 테스트 계획을 통해 테스트 사례를 테스트 실행에 우선 순위를 지정하고 테스트 결과를 이해하는 데 유용한 테스트 도구 모음으로 구성할 수 있습니다. 자세한 내용은 요구 사항 또는 사용자 스토리를 사용하여 테스트 계획 만들기를 참조하십시오. 또한 Visual Studio ALM을 사용하면 다음과 같은 몇 가지 방법을 통해 테스트 사례를 테스트 도구 모음으로 그룹화할 수 있습니다.

• 정적 테스트 사례 그룹을 만들고 관리합니다.

• 쿼리를 사용하여 동적 테스트 사례 그룹을 만들고 관리합니다. 즉, 우선 순위를 기준으로 테스트 사례를 찾을 수 있습니다.

• 사용자 스토리 또는 요구 사항을 테스트 계획에 추가합니다. 이때 테스트 사례에는 요구 사항에 대한 링크가 있습니다.

• 다른 테스트 계획의 기존 테스트 도구 모음을 복사합니다.

자세한 내용은 테스트 도구 모음을 사용하여 테스트 사례 구성을 참조하십시오.

두 번째로, 코드의 테스트 용이성을 고려해야 합니다. 테스트 용이성을 확인하려면 응용 프로그램의 아키텍처와 패턴을 이해해야 합니다. MVC(Model View Controller), MVVM(Model View ViewModel) 또는 MVP(Model View Presenter) 등의 패턴을 사용하는 경우 사용자 인터페이스 테스트에 부정적인 영향을 주지 않고도 일부 기능을 격리시키고 기능 테스트를 실행할 수 있습니다. 하지만 이러한 방법으로 실제 사례를 나타낼 수 없는 경우도 있습니다. 예를 들어 응용 프로그램의 리팩터링 부분에 대한 기능은 격리시킬 수 없으며, 일부 코드 영역은 사용자 인터페이스나 네트워킹 이벤트 처리기를 통해서만 접근할 수 있습니다. 테스트 품질을 대폭 향상시키려는 경우에는 테스트 가능한 코드의 비율을 높여야 합니다. 이러한 패턴에 대한 자세한 내용은 ASP.NET MVC 2를 참조하십시오.

세 번째로, Agile 테스트를 구현하기 전에 팀의 작업 능력을 고려해야 합니다. 팀에는 기능을 구현할 때 단위 테스트를 만들 수 있는 멤버, 응용 프로그램의 비즈니스 규칙을 숙지하여 수동 사용 사례 및 워크플로 테스트를 만들고 정의할 수 있는 멤버, 그리고 필요한 기술력을 갖추고 이러한 수동 테스트를 기반으로 자동화된 테스트와 세부적인 테스트를 만들 수 있는 멤버가 필요합니다.

테스트 수명 주기를 관리하는 방법

테스트는 프로젝트 전체 기간에 걸친 반복적 프로세스입니다. 다음 단계를 참조하십시오.

1. 명확한 테스트 목표를 세우고 팀 전체가 해당 목표에 동의하도록 합니다. 이러한 목표에 따라 테스트 전략을 결정합니다. 예를 들어 모든 체크 인 이전에 테스트를 실행하고, 단위 테스트에 70%의 코드 검사를 포함하며, 모든 사용자 스토리에 적어도 하나의 자동화된 테스트를 포함하도록 전략을 세울 수 있습니다.

2. 현재 스프린트의 프로젝트 사용자 스토리, 디자인 가정 및 비기능적 요구 사항에 따라 테스트 계획을 정의합니다.

   1. 백로그에 사용자 스토리를 추가하고 이후 스프린트에 대한 사용자 스토리를 계획할 수 있습니다. 각 테스트 계획은 하나 이상의 스프린트와 연결되어야 하며, 따라서 스프린트의 모든 사용자 스토리에 대한 테스트 사례가 있어야 합니다.

3. 승인 테스트, 단위 테스트, 기능 테스트 및 성능 테스트 등의 테스트 사례를 정의하고 빌드합니다.

4. 테스트 사례를 테스트 도구 모음으로 그룹화합니다. 이러한 테스트 도구 모음은 테스트 관련 활동을 안내해 주는 정의된 테스트 계획에 맞출 수 있습니다.

5. 테스트 도구 모음과 포함된 테스트 사례를 스프린트 기간 내내 반복적으로 실행합니다. 스프린트 초기에 테스트 실행을 시작한 다음 테스트 도구 모음에 테스트 사례를 계속해서 추가해 나갑니다. 중요한 테스트 조건 및 상황을 파악하려는 경우 예비 테스트를 적용하고 팀 내에서 이에 관해 자주 논의할 수 있습니다.

6. 사용자 스토리를 완료 상태로 설정하기 전에 사용자 스토리의 모든 승인 테스트가 통과했는지 확인합니다.

소프트웨어의 세부 구조에 따라 워크플로에 차이가 있을 수는 있지만 앞의 그림에서는 주요 구성 요소 간 워크플로의 핵심을 보여 줍니다.

• 코드에서 빌드를 생성합니다.

• 코드는 정의된 작업, 테스트 계획 및 빌드 품질에 따라 영향을 받습니다.

• 테스트 계획, 테스트 도구 모음 및 테스트 사례는 계획된 목적과 이 그림에는 나타나지 않은 프로젝트의 다른 측면에 따라 영향을 받습니다.

• 코드의 변경 내용은 테스트 사례에 영향을 줄 수 있습니다.

버그 수정

1. 버그는 가능한 한 빨리 해결해야 합니다. 심각한 버그는 영향을 주는 사용자 스토리가 완료되지 않았음을 의미합니다.

2. 테스트 작업이나 다른 작업을 통해 발견된 버그에 대해 버그 작업 항목을 만듭니다. 사용자 스토리에 영향을 주는 정도를 나타내는 버그 심각도를 설정합니다. 0 또는 1과 같은 높은 심각도는 중요한 사용자 스토리가 구현되지 않았거나 사용자가 스토리를 달성하기 위해 많은 문제를 해결해야 함을 나타냅니다. 3과 같은 낮은 심각도는 사용자가 추가 작업 없이도 주요 목표를 달성할 수 있음을 나타냅니다.

3. 팀의 다른 멤버와 협력하여 각 버그에 대한 작업 계획을 결정합니다.

4. 버그를 수정하는 즉시 해결합니다. 버그를 다른 사용자에게 할당하여 확인하도록 해야 합니다. 가능한 한 빨리 버그를 확인하고 닫습니다.

5. 버그의 상태를 추적합니다. 각 반복이 종료될 때는 회고 회의에서 버그 추세 보고서를 살펴보고 버그가 비정상적으로 증가한 경우 그 이유에 대해 논의합니다. 자세한 내용은 버그 추세 보고서를 참조하십시오.

테스트 계획

테스트 계획 과정은 팀이 프로젝트를 거시적으로 이해할 수 있도록 돕고 팀에서 모든 종류의 테스트를 실행할 수 있도록 준비하는 과정입니다. Agile 테스트는 스프린트 수준에서 시작됩니다. 각 스프린트마다 팀은 테스트를 만들어 해당 스프린트에서 빌드된 사용자 스토리를 확인합니다. 팀은 현재 스프린트와 이전 스프린트 만들어진 모든 테스트를 실행합니다. 프로젝트를 진행하는 과정에서 모든 기능을 다루는 많은 수의 테스트가 빌드됩니다. 다음 그림에서는 프로젝트의 테스트 계획에 대한 템플릿을 보여 줍니다.

각 스프린트 및 프로젝트에 대한 테스트 계획 작성

Visual Studio ALM의 테스트 기능을 사용하면 팀에서 테스트 계획, 구성, 실행 및 보고를 증분 방식으로 수행할 수 있습니다. 팀에서 테스트 계획용 템플릿을 만들고 팀 멤버는 테스트 도구 모음을 채울 수 있습니다. 테스트 계획에서 팀은 자동화된 테스트 사례 또는 수동 테스트 사례를 사용해야 하는 경우를 식별할 수 있습니다.

프로젝트의 각 스프린트에 대해 테스트 계획 만들기를 시작할 수 있습니다. 이 계획을 사용하면 팀에서는 현재 스프린트의 기능을 확인하는 데 초점을 맞출 수 있습니다. 처음에는 계획에 포함된 내용이 아무 것도 없더라도 이를 테스트 도구 모음의 자리 표시자로 사용할 수 있습니다. 그런 다음 테스트 사례를 적절한 테스트 도구 모음으로 구성할 수 있습니다. 프로젝트 관련자로부터 제때에 피드백을 받으려면 스프린트 초기와 스프린트 전체 기간 동안 이러한 테스트 사례를 만들어야 합니다.

전체 프로젝트를 대상으로 한 테스트 계획을 만들 수도 있습니다. 프로젝트 테스트 계획을 사용하여 이전 스프린트에서의 테스트를 결합하고 전체 프로젝트에 적용되는 테스트 도구 모음을 구성할 수 있습니다. 팀에서 대규모 프로젝트를 빌드할 때는 안정성과 흐름을 유지 관리하는 것이 중요하므로 재발 테스트 도구 모음은 계속해서 실행해야 합니다. 특히 접근성이 부족한 대규모의 분산된 팀에서 작업하는 경우에는 재발 테스트 도구 모음을 통해 단계적 영향을 주는 변경 내용에 따른 오류를 catch할 수 있습니다. 제때에 올바른 방법을 사용하지 않으면 이러한 오류를 catch하기가 매우 어려우며 주기의 후반 또는 결과물 전달 후에야 오류를 catch하게 될 수도 있습니다.

일부 팀에서는 전체 프로젝트에 걸쳐 있는 테스트 계획을 정의할 수 있습니다. 이러한 종류의 테스트 계획에서는 여러 스프린트의 관련 기능을 확인하고 프로젝트 기간 내내 실행되는 테스트 도구 모음을 포함할 수 있습니다. 예를 들어 여러 스프린트에 사용자 스토리를 분산하는 기능은 전체 프로젝트가 완료되었을 때만 테스트할 수 있습니다.

스프린트 전에 승인 테스트 정의

승인 테스트는 스프린트 전에 정의해야 합니다. 이러한 승인 테스트는 사용자 스토리가 완전한지 여부를 확인하는 데 유용합니다. 각 스프린트에 대한 테스트 계획에 승인 테스트라는 테스트 도구 모음을 만드는 경우 승인 테스트 사례를 추적할 수 있습니다. 자세한 내용은 이 항목 뒷부분의 승인 테스트를 참조하십시오.

스프린트 도중 단위 테스트 빌드

단위 테스트는 스프린트 도중에 만들어야 합니다. 단위 테스트에서는 코드를 실행하는 데 사용되는 시간 및 리소스 비용 등의 코드 성능을 확인할 수 있습니다. 또한 성능 테스트 및 보안 테스트와 같은 비기능적 테스트를 비롯한 다른 종류의 테스트를 만들어 적절한 테스트 도구 모음에 추가해야 합니다. 코드의 비용을 쉽게 파악할 수 있도록 이러한 테스트 도구 모음을 구성해야 합니다.

많이 사용하는 영역에 테스트 초점 맞추기

소프트웨어에서 가변성이 높은 부분을 이해하면 어떤 부분이 핫 스폿이 될 수 있는지를 판별할 수 있습니다. 팀에서 소프트웨어의 핫 스폿을 찾을 수 있는 구성 변수의 예로는 사용자 입력, 소프트웨어를 실행하는 환경, 네트워크 및 하드웨어가 있습니다. 테스트 중 어떤 조건이 거의 발생하지 않거나 발생할 수 있는 조건이 복잡하게 많다면 오류의 잠재적 영향이 매우 큰 경우를 제외하고는 테스트의 가치가 떨어집니다. 일반적으로는 가능한 경우 기능을 격리시키는 것이 바람직합니다. 영향이 큰 상황을 테스트하는 것도 중요합니다. Microsoft Test Manager를 사용하여 구성을 관리하는 방법에 대한 자세한 내용은 테스트 구성을 사용하여 테스트 매트릭스 정의를 참조하십시오.

기존 프로젝트의 경우, 오류 수가 가장 많은 영역을 모니터링하고 해당 오류의 원인을 확인합니다. 또한 코드 변동(code churn) 영역에서는 기본 가정을 간과할 수 있으므로 이 영역을 모니터링합니다. 코드 오류는 네트워크 및 사용자 인터페이스 등의 상태와 코드를 관리하기 어려운 경우와 같은 몇 가지 원인으로 발생할 수 있습니다.

데이터 처리 및 저장을 위한 테스트 구분

데이터베이스를 사용하는 코드에서는 일반적으로 데이터 처리와 데이터 저장을 구분합니다. 데이터 처리는 단위 테스트를 실행하여 테스트할 수 있고 데이터 저장은 데이터베이스 레이어에서 직접 테스트할 수 있습니다. Visual Studio Test Professional 2010에서는 데이터베이스의 저장 프로시저를 테스트하기 위한 기능을 제공합니다. 이러한 테스트는 자체적인 테스트 도구 모음으로 구성해야 합니다. 자세한 내용은 데이터베이스 단위 테스트 만들기 및 정의를 참조하십시오.

Microsoft Test Manager를 사용하여 컴퓨터 이미지의 스냅숏을 만들고, 데이터가 필요한 테스트를 실행한 후 이 스냅숏을 사용하여 알려진 상태로 되돌릴 수 있습니다. 이러한 테스트는 매우 가치가 있으며 일반적으로 시간이 많이 걸렸습니다.

승인 테스트

승인 테스트에서는 사용자 스토리를 확인합니다. 이러한 테스트를 통해 프로젝트의 전체 수명 주기 동안 고객이 요구하는 사항을 성공적으로 구현할 수 있을 뿐 아니라 고객과의 신뢰를 구축하고 프로젝트 이행 능력을 검증받을 수 있습니다. 자세한 내용은 Acceptance Test Engineering Guide 웹 페이지를 참조하십시오.

승인 테스트 시작 방법

Microsoft Test Manager를 연 다음 테스트 계획에 승인 테스트라는 테스트 도구 모음을 만듭니다. 팀에는 각 스프린트에 대한 승인 테스트를 그룹화하는 테스트 도구 모음이 하나 이상 있어야 합니다. 자세한 내용은 테스트 계획을 사용하여 테스트 관련 활동 정의를 참조하십시오.

수동 테스트에서 자동화된 테스트로 마이그레이션

수동 테스트는 자동화된 테스트보다 정의하기 쉽지만 실행하는 데 비용이 더 많이 듭니다. 따라서 처음에는 수동 테스트로 시작하고 중요한 수동 테스트를 자동 테스트로 점진적으로 대체하는 것이 좋습니다.

먼저 스프린트에 대해 정의된 각 사용자 스토리를 확인하는 일련의 수동 테스트 사례를 만듭니다. 스프린트가 시작될 때는 코드가 없는 상태이므로 테스트 사례에서는 사용자 스토리의 각 부분에 매핑되는 상위 수준의 작업을 대략적으로 기술해야 합니다. 예를 들어 "인증된 사용자는 ...을(를) 수행함"이라는 단계가 테스트 사례에 포함될 수 있습니다. 수동 테스트 사례에서부터 시작하면 팀에서는 스프린트가 시작되기 전에 이상적인 승인 테스트를 빠르게 정의할 수 있습니다.

두 번째로, 스프린트의 사용자 스토리를 구현하는 코드가 생기게 되면 팀에서 특정 사용자 환경에 맞게 승인 테스트를 수정 및 업데이트합니다. 그러나 기존의 승인 테스트 집합을 수정하지 않으려는 경우에는 해당 테스트를 새 테스트 도구 모음으로 가져와 보다 세부적인 테스트를 위한 시작점으로 삼을 수 있습니다. 예를 들어 보다 세부적인 테스트 사례에는 "사용자 이름 입력란에 이름을 입력하고 로그인 단추를 클릭하여 은행 계정에 로그인하십시오."라는 단계가 포함될 수 있습니다.

세 번째로, 작업 기록을 사용하여 승인 테스트를 기반으로 한 코딩된 UI(사용자 인터페이스) 테스트를 만듭니다. 자세한 내용은 방법: 작업 기록에서 코딩된 UI 테스트 생성을 참조하십시오. 기능을 격리하는 단계를 만들 경우 코딩된 UI 테스트에서는 보다 깔끔한 코드를 생성할 수 있습니다. 코딩된 UI 테스트를 수동 테스트 사례에 연결하면 테스트 계획에서 자동화된 테스트를 실행할 수 있습니다. 자세한 내용은 방법: 테스트 사례에 자동화된 테스트 연결을 참조하십시오.

스프린트가 시작될 때 정의된 수동 테스트는 자동화된 테스트를 만드는 데 도움이 될 수 있습니다. 수동 테스트는 사람이 실행해야 하고 자동화된 테스트는 코드나 사용자 환경이 변경될 때마다 업데이트해야 하므로 두 테스트 모두 비용이 발생합니다. 자세한 내용은 이 항목 뒷부분의 수동 테스트와 자동화된 테스트를 참조하십시오.

승인 테스트 사례를 실행하는 주체

팀, 제품 소유자 및 고객이 승인 테스트 사례를 실행할 수 있습니다. 팀에서는 승인 테스트 사례를 가능한 한 자주 실행하여 스프린트에서 통과해야 하는 일련의 테스트에 대한 기준을 마련해야 합니다. 제품 소유자와 고객도 승인 테스트를 실행할 수 있으며 이때 스프린트가 성공적으로 완료되었는지에 대한 확인이 필요할 수 있습니다.

팀에서는 Microsoft Test Manager를 사용하여 각 승인 테스트 사례를 실행하고 테스트 결과를 비디오 화면 캡처로 녹화할 수 있습니다. 이 방법으로 테스트 결과의 시각적 기록을 남길 수 있으며 결과를 고객과 공유할 수도 있습니다. 이렇게 하면 다중 서버 구성과 같이 필요한 구성을 만들기 어려울 때 유용합니다.

사용자 스토리와 함께 승인 테스트 사례 정의

사용자 스토리를 정의한 직후 승인 기준을 정의할 수 있습니다. 승인 테스트를 정의하면 팀에서는 현재 스프린트에 대해 제품 소유자와 고객으로부터 승인을 얻기 위한 승인 기준을 쉽게 이해할 수 있습니다. 고객이 승인 테스트에 동의해야 하므로 승인 테스트 사례는 스프린트가 시작되기 전에 만드는 것이 좋습니다.

단위 테스트

단위 테스트는 구성 요소, 클래스, 메서드 또는 속성 수준에서 기능을 확인하는 자동화된 테스트입니다. 단위 테스트는 자동화된 테스트 및 재발 테스트의 기초가 되며 프로젝트의 장기적 안정성과 향후의 유지 관리 편의성을 보장해 줍니다.

단위 테스트를 통해 응용 프로그램의 디자인을 개선하는 방법

테스트된 코드를 빌드하면서 단위 테스트를 만드는 과정을 통해 코드의 모양을 쉽게 정의할 수 있습니다. 단위 테스트를 사용하여 테스트할 수 있는 코드를 만들 수 있습니다. 코드에 대한 단위 테스트를 만들기가 어렵다면 이는 코드를 리팩터링해야 한다는 의미입니다.

단위 테스트를 구성하는 방법

코드를 작성하는 각 팀 멤버는 자신이 빌드하는 구성 요소에 대한 단위 테스트를 만들고 Visual Studio 프로젝트 내에서 이 단위 테스트 코드를 버전 제어에 체크 인해야 합니다. 테스트 사례 작업 항목을 각 빌드 도중 연속 통합을 통해 실행할 빌드 확인 테스트 도구 모음과 해당 사용자 스토리를 확인하는 테스트 도구 모음에 포함합니다.

테스트 코드를 변경할 필요 없이 단위 테스트의 가변성을 관리하는 방법

테스트 입력의 가변성은 프로젝트 코드의 기능을 확인할 때 테스트 간의 유사점 또는 차이점을 정의합니다. 예를 들어 웹 응용 프로그램의 로그온 구성 요소를 테스트할 경우에는 사용자 계정을 만들기 위한 몇 가지 암호 유형을 제공할 수 있습니다. 시스템에는 사용되는 문자 형식의 순서 및 조합에 대한 규칙이 있을 수 있습니다.

Visual Studio Test Professional 2010에서는 데이터 기반 단위 테스트 및 코딩된 UI 테스트를 작성하는 기능을 제공합니다. 자세한 내용은 방법: 데이터 기반 단위 테스트 만들기 및 방법: 데이터 기반 코딩된 UI 테스트 만들기를 참조하십시오.

테스트 기반 개발 및 초기 테스트

TDD(테스트 기반 개발)는 프로그래머가 코딩 직전에 작성하는 테스트의 결과에 따라 모든 코드 줄이 작성되는 디자인 및 프로그래밍 분야입니다. 구현하려는 코드의 소비자가 되어 보면 개발에 매우 큰 도움이 될 뿐 아니라 코드의 사용 방식과 디자인 방식에 대한 현실적인 기대에 부응할 수 있습니다.

TDD에서 개발자는 작게 나뉜 여러 개의 증분 단위로 작업합니다. 각각의 작은 증분 단위를 개발하는 데는 몇 분에서 몇 시간이 소요됩니다. 일반적으로 이러한 여러 개의 증분 단위가 모여 사용자 스토리를 구성합니다. 개발자는 사용자 스토리가 작동할 때 테스트와 코드를 체크 인합니다. 개발자의 작업 주기는 다음과 같습니다.

1. 증분이 작성될 때 통과해야 하는 자동화된 테스트를 작성합니다.

2. 새 테스트가 실패하는지 확인하여 테스트 작동 여부를 확인합니다.

3. 테스트에 통과하도록 하는 코드를 작성합니다.

4. 테스트를 실행하여 테스트가 성공하는지 확인합니다.

5. 또한 동일한 영역에서 다른 모든 테스트를 실행하여 버그가 없는지 확인합니다.

6. 필요한 경우 코드를 리팩터링하여 추가 동작 없이 해당 구조를 향상시킵니다. 테스트를 다시 실행하여 코드가 여전히 작동하는지 확인합니다.

7. 전체 사용자 스토리가 구현될 때까지 이러한 모든 단계를 반복합니다. 이전 증분이 전체 스토리에 통합될 때는 전체 스토리를 확인하는 테스트를 추가합니다.

8. 구현 코드 및 단위 테스트를 체크 인합니다.

초기 테스트 방법의 이점에 관심이 있다면 수동 테스트 또는 수동 승인 테스트를 만드는 것으로 작업을 시작할 수 있습니다. 코딩된 UI 테스트를 만들면 이러한 수동 테스트를 자동화할 수 있습니다. 자세한 내용은 방법: 테스트 중인 응용 프로그램을 기록하여 코딩된 UI 테스트 생성을 참조하십시오. Visual Studio ALM의 단위 테스트 프레임워크를 사용하는 통합 테스트를 만들어 구현할 기능을 확인할 수도 있습니다. 반복 초기에 만들어지는 테스트 사례 그룹은 기능을 확인하고 동시에 버그를 찾기 위해 반복 초기에 실행됩니다. 이러한 테스트 도구 모음과 테스트 사례는 프로젝트의 전체 수명 기간 동안 지속적으로 재발 테스트로 실행될 수 있습니다. 이러한 테스트를 지속적으로 실행하면 반복 초기에 발견된 버그와 확인된 기능은 이후에 프로젝트가 변경되더라도 영향을 받지 않습니다.

연속 통합을 위한 단위 테스트 사용

초기 테스트 방법을 사용할 때 만들어진 단위 테스트는 현재 스프린트 및 사용자 스토리의 테스트 도구 모음 내에 구성되어야 합니다. 이러한 단위 테스트를 프로젝트 수준의 테스트 계획으로 승격시켜 팀에서 또는 연속 통합 주기 내에서 정기적으로 실행할 수 있습니다. 단위 테스트는 통합 테스트, 부하 테스트 및 성능 테스트의 기초로도 사용됩니다.

시작 시 만들어진 단위 테스트는 연속 통합의 일부로 사용할 수 있습니다. 빌드 중 테스트를 실행하는 방법에 대한 자세한 내용은 TestToolsTask 작업을 참조하십시오.

가상화를 사용하여 테스트 구성 관리

단위 테스트를 실행하려면 Microsoft Test Manager에서 관리되는 Hyper-V 이미지인 일련의 환경을 만듭니다. Microsoft Test Manager를 사용하여 테스트 계획에 포함된 자동화된 테스트를 실행하는 방법에 대한 자세한 내용은 TestToolsTask 작업을 참조하십시오.

수동 테스트와 자동화된 테스트

자동화된 테스트 사례와 수동 테스트 사례는 상호 보완적입니다. Agile 팀에서는 빈번하거나 지속적인 테스트 실행을 장려하므로 자동화된 테스트 사례를 더 많이 확보하고자 노력합니다. 테스트를 지속적으로 실행하려면 실행 속도가 빠르고 빈번해야 하는데 이는 수동 테스트로는 달성하기가 어렵습니다.

수동 테스트 사례 및 자동화된 테스트 사례의 배포와 관련된 사항을 결정할 때는 다음과 같은 몇 가지 사항을 고려해야 합니다.

조직의 기술이 테스트 형식의 배포에 미치는 영향

제품 소유자는 프로젝트의 사용자 스토리를 정의할 수 있도록 도와 주며, 승인 테스트를 만드는 과정에도 참여해야 합니다. 제품 소유자는 코딩된 테스트를 생성하지 않으려고 할 수도 있지만 해당 비즈니스 도메인에 대한 상당한 지식을 갖고 있다는 것은 분명합니다. 따라서 제품 소유자에 의해 정의된 테스트 사례는 비즈니스 용어 모음 및 비즈니스 규칙에 맞는 수준을 유지하게 됩니다. 예를 들어 선적 회사의 제품 소유자는 해당 비즈니스 분야에서 지원되는 다양한 운송 수단(예: 트럭, 기차, 항공, 해운 또는 이러한 운송 수단의 조합)을 지정할 것입니다. 그런 다음 제품 소유자는 여러 가지 가능성을 고려한 몇 가지 테스트 사례를 정의할 수 있습니다. 이러한 수동 테스트의 경우 다양한 옵션(이 경우 선적 수단)을 사용하는 최소 개수의 테스트를 지정하는 것이 중요합니다.

코드를 생성하는 팀 멤버는 수동 테스트를 기반으로 또는 다른 테스트와는 독립적으로 코딩된 UI 테스트를 만들 수 있습니다. 자세한 내용은 How to: Generate a Coded UI Test by Recording the Application Under Test을 참조하십시오. 코딩된 UI 테스트는 프로젝트 코드를 관리 및 개발할 수 있는 능력이 있는 팀 멤버가 지원해야 합니다.

수동 테스트를 자동화된 테스트로 변환해야 하는 경우 및 처음부터 자동화된 테스트를 만들어야 하는 경우

테스트를 반복적으로 실행하여 코드의 안정성을 유지하려는 경우 자동화된 테스트를 만들 수 있습니다. 자동화에 따르는 비용은 팀의 리소스에 영향을 주므로 자동화된 테스트를 만들 때의 효과를 고려해야 합니다. 코드 변동(code churn)이 거의 없을 때 자동화된 테스트를 만들면 테스트 변동이 적으므로 ROI(투자 수익률)가 높아집니다. 그러나 초기에 자동화된 테스트를 만들면 논리와 디자인 모두의 문제를 찾는 데 도움이 되므로 이 방법을 사용하는 것도 좋습니다. 두 경우 모두 자동화된 테스트 코드를 지원하는 데 필요한 리소스를 고려해야 합니다.

자동화해야 할 일련의 테스트를 결정한 후에는 가능한 한 빠르게 작업을 진행하여 자동화를 완료해야 합니다. 자동화하면 코드의 안정성을 관리할 수 있다는 이점도 있기 때문입니다. 자동화된 테스트를 작성할 때 발견된 오류 수와 안정성은 자동화를 완료하는 데 필요한 작업량에 영향을 줍니다. 궁극적으로 수동 테스트와 자동화된 테스트의 균형은 프로젝트 수명 기간 중 만들어 실행해야 하는 테스트 유형에 우선 순위를 지정함으로써 찾을 수 있습니다.

자동화되는 테스트 형식

단위 테스트

단위 테스트는 코드에서 또는 TDD 등의 과정을 통해 기능을 확인합니다. 단위 테스트는 코드 내의 안정성과 종속성을 유지하는 데 도움이 되므로 중요합니다. 또한 TDD를 사용하면 대개 코드 소비자의 입장에서 디자인을 이해하는 데 도움이 되므로 종속성이 있고 레이어 정의가 올바른 뛰어난 디자인을 얻을 수 있습니다.

부하 테스트

기존의 자동화된 테스트 사례를 기반으로 하는 부하 테스트를 만들거나, 응용 프로그램 또는 서비스에 특정 유형의 부하를 생성하는 테스트를 만들 수 있습니다. 테스트 에이전트 컨트롤러와 테스트 에이전트를 사용하여 시뮬레이션된 테스트 부하를 생성하는 방법에 대한 자세한 내용은 방법: 테스트 컨트롤러 및 테스트 에이전트를 사용하여 테스트 실행을 참조하십시오.

Visual Studio ALM을 사용한 부하 테스트 방법에 대한 자세한 내용은 Microsoft 웹 사이트의 Understanding Load Tests 페이지를 참조하십시오.

연속 통합 테스트

Visual Studio ALM과 연속 통합을 함께 사용하면 코드가 개발되고 체크 인될 때마다 기존 코드와 올바르게 작동하는지 확인할 수 있습니다. 연속 통합은 팀 및 코드베이스의 규모가 커질 때 중요한 역할을 합니다. 테스트 매개 변수를 포함하여 빌드 형식을 정의하고 빌드를 완료한 후 실행할 테스트를 지정할 수 있습니다. 테스트를 실행하는 빌드를 정의하는 방법에 대한 자세한 내용은 기본 템플릿을 사용하여 빌드 정의를 참조하십시오.

자동화할 수 있는 테스트 형식

구성 테스트

설치된 여러 환경에서 테스트를 실행한다는 것은 매우 힘든 작업일 수 있습니다. Microsoft Test Manager에서는 가상 컴퓨터나 실제 컴퓨터를 사용하여 다양한 구성에 대해 테스트 도구 모음을 실행하는 기능을 제공합니다. 여러 환경에서 테스트를 실행하고 데이터를 수집하는 방법에 대한 자세한 내용은 테스트를 실행하거나 데이터를 수집할 테스트 컴퓨터 설정을 참조하십시오.

사용자 인터페이스 테스트

Visual Studio ALM에는 사용자 인터페이스에 대해 직접적으로 자동화된 테스트를 만드는 기능이 있습니다. 코딩된 사용자 인터페이스 테스트를 만드는 방법에 대한 자세한 내용은 방법: 코딩된 UI 테스트 만들기를 참조하십시오.

설치 테스트

Microsoft Test Manager의 랩 기능을 사용하여 응용 프로그램의 설치 프로그램이 예상대로 작동하는지 여부를 확인하는 데 사용할 수 있는 구성 그룹을 설정할 수 있습니다.

자동화에 장애가 되는 요소

팀의 작업 능력

자동화하려면 테스트 팀의 일부 멤버가 코드 작성 방법을 알고 있어야 합니다. 따라서 자동화 만들기와 테스트 코드의 디자인에 대한 학습 기간을 갖도록 계획합니다. 프로덕션 코드와 마찬가지로 유지 관리 편의성, 작성 용이성, 수명 등의 원하는 목적에 맞는 자동화 코드를 디자인합니다.

Visual Studio Test Professional 2010을 사용하여 자동화된 테스트를 만드는 방법에 대한 자세한 내용은 자동화된 테스트 만들기를 참조하십시오.

코드 변동(code churn)

자주 변경되는 코드는 움직이는 표적이라고 할 수 있으며, 코드가 변경되면 테스트 자동화 코드도 변경해야 하므로 테스트 자동화 코드에 단계적으로 영향을 줍니다. 따라서 변경될 가능성이 적은 구성 요소 및 인터페이스에 대한 테스트 자동화 코드를 만들어 이러한 단계적 영향을 방지해야 합니다.

코드 디자인

ASP.NET MVC 및 MVVM과 같은 코드 프레임워크는 팀 멤버가 코드의 다른 부분을 확인하는 데 필요한 격리 기능이 있는 코드를 작성할 수 있도록 도와 줍니다. 사용자 인터페이스에 긴밀하게 바인딩된 코드의 경우에는 사용자와 사용자 인터페이스 컨트롤 간의 상호 작용이 필요할 수 있으므로 테스트하기가 어렵습니다.

수동 테스트 사례의 장점

수동 테스트 사례에는 다음과 같은 장점이 있습니다.

• 수동 테스트는 팀에서 탐색 과정을 통해 버그를 찾는 데 유용합니다.

• 수동 테스트의 경우 모든 추상화 수준에서 일련의 단계를 정의할 수 있고 원하는 어떤 용어로든 성공 및 실패를 정의할 수 있으므로 정의하기가 쉽습니다.

• 프로젝트 초기에 코드가 아직 작성되지 않은 상태에서도 수동 테스트 사례를 시작하기가 매우 쉽습니다. 이는 승인 테스트를 정의할 때 중요한 사항입니다.

• Visual Studio Test Professional 2010을 사용하는 경우, 유사한 테스트를 정의할 때 시간을 절약해 주고 팀이 단일 버전의 테스트 하위 집합을 다시 사용할 수 있게 해 주는 공유 단계로 테스트 사례를 구성할 수 있습니다. 공유 단계가 변경되면 해당 공유 단계를 사용하는 모든 테스트 사례가 자동으로 변경되므로 공유 단계를 사용하면 테스트 사례를 변경할 때도 유용합니다. 공유 단계를 만들고 사용하는 방법에 대한 자세한 내용은 How to: Share Common Test Case Steps Using Shared Steps를 참조하십시오.

• 수동 테스트 사례는 프로젝트 또는 스프린트에서 초기 정보 교환의 수단으로 사용될 수 있습니다.

• 수동 테스트 사례는 코드를 검토할 필요 없이 자동화된 테스트 사례를 문서화하는 수단으로 사용될 수 있습니다.

• Visual Studio ALM을 사용하는 경우 수동 테스트를 실행하면 코드 검사 메트릭을 수집할 수 있습니다.

수동 테스트 사례의 단점

수동 테스트 사례에는 다음과 같은 단점이 있습니다.

• 테스트 정의에 사용된 언어와 관점에 따라 성공 기준이 달라지므로 성공 기준을 정의하는 것이 복잡할 수 있습니다. 일부 언어는 해석 방법이 달라서 오류가 발생할 여지를 남길 수 있습니다.

• 수동 테스트 사례가 포함된 테스트 도구 모음을 실행하려면 실제로 테스트 단계와 보고 결과를 따를 사람이 필요합니다. 이 과정에는 많은 시간이 소비될 수 있으며, 그에 따라 테스트를 실행할 팀 멤버의 수나 테스트 도구 모음의 실행 기간을 늘려야 할 수 있습니다. Visual Studio Test Professional 2010을 사용하는 팀에서는 테스트 도중 작업을 기록한 다음 이후 테스트 실행에서 이를 실행할 수 있는 "수동 테스트 빨리 감기" 기능을 사용할 수 있습니다.

• 코드의 안정성에 따라 테스트를 실행하는 데 필요한 시간과 작업량이 달라집니다. 따라서 수동 테스트를 실행하면 팀의 작업 흐름에 영향을 줄 수 있습니다.

• 수동 테스트의 가장 큰 단점은 사람이 직접 버그를 찾다 보니 오류가 있을 수 있다는 점입니다. 즉, 테스터는 눈 앞에 버그가 있는데도 이를 깨닫지 못할 수 있습니다.

자동화된 테스트 사례의 장점

자동화된 테스트 사례에는 다음과 같은 장점이 있습니다.

• 자동화된 테스트는 안정성을 유지 관리하고 코드 변경으로 인해 발생할 수 있는 재발 문제를 찾는 데 유용합니다.

• 자동화된 테스트는 무인 모드에서 실행할 수 있습니다.

• 자동화된 테스트는 소프트웨어이므로 다시 사용할 수 있는 다른 코드로 디자인하고 구성할 수 있습니다. 따라서 자동화된 테스트는 유연하며 유지 관리가 편리합니다.

• Microsoft Test Manager를 사용하여 여러 구성에서 자동화를 실행할 수 있습니다.

• 자동화된 테스트를 실행할 때 코드 검사 메트릭을 수집할 수 있습니다.

자동화된 테스트 사례의 단점

자동화된 테스트 사례에는 다음과 같은 단점이 있습니다.

• 특수한 조건을 고려하고 이를 코드로 구현해야 합니다. 자동화를 만들고 실행할 때 이러한 조건이 발견되면 추가 조건이 구현됩니다.

• 코드가 변경되거나 리팩터링되면 그에 따라 영향 받는 자동화된 테스트를 변경해야 하는 단계적인 영향이 있을 수 있습니다.

• 코드 변경으로 인해 여러 테스트가 실패할 경우 팀에 심리적인 영향이 있을 수 있습니다. 이러한 테스트가 플래그로 사용되는 경우 팀에서는 플래그를 발생시키지 않으려고 할 수 있습니다.

• 테스트 사례가 올바른 조건을 테스트하고 있지 않은 경우 모든 테스트에 통과하면 보안 상태가 잘못 인식될 수 있습니다. 따라서 테스트 도구 모음을 유지 관리하여 항상 올바른 조건과 결과를 확인하도록 해야 합니다.

테스트 결과 보고

Agile 관점에서 볼 때 버그나 집계 메트릭을 기반으로 한 현재 품질 상태에 대한 Team Foundation Server 보고 및 쿼리는 팀이 반복 작업을 수행하고 코드, 프로젝트 계획 및 테스트 계획을 변경할 수 있도록 하는 피드백 루프의 일부분입니다. 자세한 내용은 테스트 계획 진행률 보고서를 참조하십시오.

팀에 보고해야 하는 테스트 수준

팀에서는 Visual Studio Test Professional 2010 및 Team Foundation Server를 사용하여 테스트 계획 및 실행 상태를 파악할 수 있습니다. Team Foundation Server는 테스트 계획, 테스트 도구 모음, 테스트 사례 및 테스트 결과뿐 아니라 전체 테스트 과정 중에 생성된 다른 모든 관련 데이터도 저장합니다. Microsoft Test Manager와 Team Foundation Server의 보고 및 작업 항목 쿼리를 함께 사용하면 테스트 및 품질 제어 과정을 시각화할 수 있습니다. Microsoft Test Manager를 사용하여 각기 다른 다양한 상태에서 버그를 쿼리할 수 있습니다. 다른 팀 멤버에 의해 수정된 것으로 표시된 버그는 해결됨 상태여야 합니다. 후속 빌드를 사용하여 수정된 버그를 확인할 수 있습니다. 버그가 수정되었는지 여부를 확인하는 방법에 대한 자세한 내용은 방법: Microsoft 테스트 관리자를 사용하여 수정된 버그 확인을 참조하십시오.