- 응용 프로그램에 대해 Windows 2000 호환성 테스트
- QC/품질관리
- 2005. 10. 27. 16:08
21장 - 응용 프로그램에 대해 Windows 2000 호환성 테스트
새로운 운영 체제를 배포하는 계획을 수립할 때 엄청난 노력이 들기 때문에 그 운영 체제에서 실행할 응용 프로그램에 대해서는 미루어 두기 쉽습니다. 그러나 배포 프로젝트에서 중요한 단계는 배포 중에 문제를 일으킬 수 있는 응용 프로그램을 확인하고 배포를 시작하기 전에 문제를 해결하는 것입니다.
배포 전에 잠재적 응용 프로그램 문제를 해결할 수 있으려면 응용 프로그램 테스트 관리자가 초기에 Windows 기반 응용 프로그램 테스트 계획을 수립해야 합니다. 이 장은 응용 프로그램과 Microsoft? Windows? 2000의 호환성을 테스트하는 과정을 다룹니다.
차례 목차로
다음 장으로
응용 프로그램 테스트 개요
응용 프로그램 테스트 관리
비즈니스 응용 프로그램 확인 및 우선 순위 매기기
응용 프로그램 테스트 계획 준비
응용 프로그램 테스트
테스트 결과 추적
응용 프로그램 비호환성 해결
응용 프로그램 테스트를 위한 계획 수립 작업 목록
이 장의 목표
이 장은 다음과 같은 계획 수립 문서의 개발을 도와줍니다.
비즈니스 응용 프로그램의 우선 순위 목록
응용 프로그램 호환성 테스트를 위한 계획
추적 및 보고 시스템 테스트
Resource Kit의 관련 정보
테스트 계획 수립에 대한 자세한 내용은 이 가이드의 "Windows 2000 테스트 랩 만들기"를 참조하십시오.
응용 프로그램 표준 정의에 대한 자세한 내용은 이 가이드의 "클라이언트 관리 및 구성 표준 정의"를 참조하십시오.
응용 프로그램 테스트 개요
Windows 2000의 기반이 되는 새로운 기술로 인하여 Windows 2000 배포 프로젝트의 일부로 비즈니스 응용 프로그램의 운영 체제 호환성을 테스트해야 합니다. 현재 Windows NT를 사용하고 있다고 해도 모든 응용 프로그램이 Windows 2000에서 같은 방식으로 작동할 것이라고 생각해서는 안됩니다. 개선된 보안과 같은 성능 향상은 이전 Windows 버전용으로 개발된 응용 프로그램을 다시 테스트해야 한다는 것을 의미합니다. 이러한 응용 프로그램은 Windows 2000에서 사용할 수 있는 새로운 기능을 완전히 이용하지 않을 수도 있습니다. 그러나 응용 프로그램은 현재 플랫폼에서 작동하는 것처럼 Windows 2000에서도 계속 실행되어야 합니다.
비즈니스 응용 프로그램 정의
이 장에서 비즈니스 응용 프로그램은 비즈니스 수행에 중요한 응용 프로그램을 의미합니다. 비즈니스 응용 프로그램의 범위는 업무용 시스템부터 특수한 도구까지 다양합니다. 구매하여 사용할 수 있는 완제품, 사용자 정의된 다른 공급업체 시스템, 자체 개발한 시스템 등을 포함한 클라이언트 컴퓨터나 서버에서 실행되는 모든 프로그램을 고려합니다.
참고 이 장에서 클라이언트 기반 응용 프로그램을 자주 언급하기는 하지만 여기에서 다루는 문제와 방법은 서버 기반 응용 프로그램과 클라이언트 기반 응응 프로그램에 모두 적용됩니다.
조직이 다른 조직과 비슷하다면 테스트할 시간보다 응용 프로그램이 더 많다는 것을 알게 될 것입니다. 이런 경우, 응용 프로그램의 우선 순위를 매기고 핵심 비즈니스 작업에 중대한 영향을 주는 응용 프로그램부터 테스트합니다. 응용 프로그램 우선 순위 매기기에 대한 자세한 내용은 이 장의 뒷부분에 나오는 "비즈니스 응용 프로그램 확인 및 우선 순위 매기기"를 참조하십시오.
응용 프로그램 테스트 절차
그림 21.1은 응용 프로그램 테스트 절차에 포함된 단계를 나타냅니다. 먼저 Windows 기반 응용 프로그램을 확인하고 비즈니스에 중요한 순서로 응용 프로그램의 우선 순위를 매겨야 합니다. 인벤터리를 만드는 동안 테스트 조정 방법의 계획 수립에 착수할 수 있습니다. 그런 다음 테스트가 진행되는 동안 정기적으로 관리 부서에 상태를 보고하여 호환성 문제가 발생할 때 문제를 해결해야 합니다. 이 장에서는 그러한 단계를 자세히 다룹니다.
그림 21.1 응용 프로그램 테스트 단계
응용 프로그램 테스트 관리
응용 프로그램 테스트에 많은 노력을 들여야 하므로 테스트와 테스트 과정을 모니터링하고 테스트 계획과 방법을 수립할 관리자를 선발하는 것이 좋습니다. 다국적 기업이거나 고도로 분산된 조직이라면, 특히 각기 다른 응용 프로그램 제품군을 여러 장소에서 사용하는 경우, 여러 곳에 테스트 관리자를 두고 싶을 것입니다. 이런 접근 방식을 사용하면 테스트 관리자가 다양한 네트워크 클라이언트나 성능 요구 사항과 같은 특정 지역의 요구 사항을 중점적으로 다룰 수 있습니다.
Windows 2000 프로젝트의 초기에 어떤 문제가 발생했을 때 그 문제를 해결할 수 있는 시간을 가질 수 있도록 응용 프로그램 테스트의 기본 토대를 마련합니다. 테스트 관리자는 다음과 같은 작업에 대한 책임을 지면서 응용 프로그램 테스트 프로젝트를 조정합니다.
응용 프로그램의 우선 순위를 매기기 위한 시스템 개발
인벤터리 및 우선 순위 매기기 절차 조정
테스트 방법 개발
하드웨어, 소프트웨어 및 인력을 포함한 테스트 리소스 요구 사항 결정
테스트 일정 만들기
테스트 계획 작성
테스트 추적 및 보고 시스템 디자인 또는 구매
응용 프로그램 테스트를 위한 중요성 및 전략 개선, 응용 프로그램 전문가의 도움 얻기
테스트 진행 과정을 모니터링하여 관리 부서, 내부 응용 프로그램 개발 그룹 및 외부 공급업체에게 모니터링 내용 보고
테스트 요구 조건을 만족시키지 못하는 그룹 추적
비즈니스 응용 프로그램 확인 및 우선 순위 매기기
테스트 준비 시 가장 먼저 해야 하는 일은 컴퓨터(클라이언트와 서버 모두)에서 설치된 응용 프로그램에 대한 정보를 수집하는 것입니다. 응용 프로그램 사용 여부와 사용자 수 등과 같은 수집 정보는 비즈니스에서 해당 정보의 중요도를 결정하는 데 도움이 됩니다.
응용 프로그램을 확인하면서 응용 프로그램의 우선 순위를 매기기 시작합니다. 아무리 응용 프로그램이 중요하지 않아 보여도 각 응용 프로그램을 살펴봐야 합니다. 많은 사용자가 작업을 수행하기 위해 의존하는 응용 프로그램이 제대로 기능을 수행하지 못하면 큰 영향을 주게 됩니다.
응용 프로그램 확인
아직 서버와 클라이언트 컴퓨터에 설치된 응용 프로그램의 인벤터리를 없다면 먼저 인벤터리를 만들어야 합니다. 바이러스 방역, 압축, 백업 및 원격 제어 프로그램을 포함한 작업 및 관리 도구를 포함시켜야 한다는 점을 명심하십시오.
응용 프로그램 정보 수집
조직의 규모가 크거나 분산되어 있다면 응용 프로그램 목록을 만드는 데 많이 시간이 걸릴 수 있습니다. Microsoft? Systems Management Server나 다른 소프트웨어 인벤터리 도구를 사용하여 네트워크로 연결된 컴퓨터를 관리한다면 소프트웨어 인벤터리 프로세스를 사용하여 정보를 수집한 다음 그 정보를 범주별로 나누고 보고하는 쿼리를 실행할 수 있습니다. 소프트웨어 인벤터리 작성에 Systems Management Server를 사용하는 것에 대한 자세한 내용은 이 가이드의 "Systems Management Server를 사용하여 네트워크 인프라 분석"을 참조하십시오.
컴퓨터에 설치된 응용 프로그램이 무엇인지 자동으로 알아내는 방법을 갖고 있지 않다면 정보 수집 절차를 개발해야 합니다. 예를 들어, 관리자가 자신의 비즈니스 단위에 대해 응답할 수 있도록 웹 기반 양식이나 질문서를 작성할 수 있습니다. 수동 절차에 의존해야 한다면 신속한 답변을 얻을 수 있도록 상위 관리 부서의 도움을 받아야 합니다.
응용 프로그램 목록을 합칠 때 각 비즈니스 단위에서 필요한 프로그램이 무엇인지 확인합니다. 다음 목록은 각 응용 프로그램에 대해 필요한 정보의 일부 예입니다.
응용 프로그램 이름 및 버전
공급업체 이름
현재 상태(생산 중, 개발 중, 사용되지 않음 등)
사용자 수 및 비즈니스 단위의 수
조직에 대한 우선 순위 또는 중요도
응용 프로그램을 사용하는 현재 플랫폼
응용 프로그램이 클라이언트 기반인지 또는 서버 기반인지 여부와 클라이언트와 서버에 상주하는 구성 요소를 포함시킵니다.
웹 응용 프로그램의 웹 사이트 주소(URL)
설치 요구 사항(보안 설정, 설치 디렉터리 등)
개발 유틸리티 또는 기술(내부적으로 개발된 경우)
연락처 이름 및 전화 번호(내부 및 공급업체)
같은 공급업체에 대해 여러 연락처가 있는 경우, 가능하다면 연락처들을 통합 정리합니다.
추가 정보를 수집하고 응용 프로그램의 우선 순위를 매길 때 정보를 쉽게 액세스하고 업데이트할 수 있는 중앙 저장소에 응용 프로그램 정보를 모아 둡니다. 응용 프로그램 테스트를 시작하면 테스트 결과를 입력하고 상태를 보고하기 위해 이 저장소를 사용할 수도 있습니다. 테스트 결과 추적 및 보고에 대한 자세한 내용은 이 가이드의 "테스트 결과 추적"을 참조하십시오.
응용 프로그램 환경 단순화
인벤터리 프로세스는 응용 프로그램 환경을 좀더 관리하기 쉽고 비용 효율적으로 만드는 데 도움을 주는 추가 정보를 수집하기에 좋은 때입니다. 환경이 단순할수록 응용 프로그램 호환성을 테스트하기가 쉬워지고, 응용 프로그램을 Windows 2000으로 더욱 무리 없이 옮길 수 있고, 결과적으로 환경이 관리하기 쉬워집니다.
이 절에서 설명하는 정보는 테스트를 용이하게 해줄 뿐만 아니라 향후 지원 비용도 줄여줍니다.
문제 해결 정보
응용 프로그램에 대한 상세한 정보는 테스터가 Windows 2000 테스트 시 발생한 문제를 진단하는 데 도움을 주며 기술 지원 서비스의 문제 해결 시간을 줄여줍니다.
응용 프로그램에서 하드 드라이브에 설치한 파일
각 파일의 날짜 스탬프
각 파일의 크기(바이트 단위)
파일이 설치된 위치
레지스트리 설정
응용 프로그램의 인벤터리를 작성할 때보다는 테스트 랩에서 응용 프로그램을 설치할 때 이 정보를 수집하는 것이 좋습니다. 랩처럼 통제된 환경에서 응용 프로그램을 설치하면 응용 프로그램이 사용됨에 따라 축적되는 외부 사용자 관련 파일 없이 완전한 목록을 얻을 수 있습니다.
중복된 응용 프로그램
조직에서 많은 유사한 프로그램을 사용하는 경우, 인벤터리 프로세스는 많이 사용하는 응용 프로그램들에 대한 중복 여부와 표준화를 평가할 수 있는 가장 좋은 시기입니다. 예를 들어, 조직에서 다수의 문서 편집 응용 프로그램이나 다양한 버전을 사용하고 있을 수도 있습니다. 단일 응용 프로그램과 버전으로 표준화하면 Windows 2000 테스트 과정을 크게 단순화하고 클라이언트 지원 비용을 상당히 줄일 수 있습니다. 각기 다른 팀에서 응용 프로그램 표준을 평가하고 결정할 수도 있기 때문에 적절한 응용 프로그램을 집중적으로 테스트하기 위해서는 테스트 팀이 다른 팀과 밀접하게 협력해야 합니다. 클라이언트 구성 표준화에 대한 자세한 내용은 이 가이드의 "클라이언트 관리 및 구성 표준 정의"을 참조하십시오.
인증되지 않은 응용 프로그램
응용 프로그램 목록을 모을 때 사용자가 인터넷에서 다운로드하거나 집에서 가져온 응용 프로그램과 같이 인증되지 않은 응용 프로그램을 찾을 수 있습니다. 인벤터리 프로세스를 사용하여 인증되지 않은 응용 프로그램을 제거하고 사용 중인 모든 소프트웨어에 라이센스가 있는지 확인합니다.
사이트 라이센스 응용 프로그램
인벤터리 프로세스는 압축 및 바이러스 방역 프로그램과 같은 사이트 라이센스 응용 프로그램을 확인하고 해당 프로그램의 관리 전략을 수립하기에 좋은 시기입니다. IntelliMirror™를 구현할 계획이라면 그것을 사용해 이런 응용 프로그램을 알립니다. IntelliMirror를 사용하여 응용 프로그램을 알리면 중복되는 서버를 쉽게 설치하여 응용 프로그램에 대한 사용자의 액세스를 최대화할 수 있습니다. 클라이언트 지원에 IntelliMirror를 사용하는 것에 대한 자세한 내용은 이 가이드의 "변경 및 구성 관리 적용"을 참조하십시오.
IntelliMirror를 구현할 계획이 없다면 사이트 라이센스 응용 프로그램을 위한 공유 드라이브를 설정할 수 있습니다. 서버에 \\licensed_products와 같이 기억하기 쉬운 이름을 지정여합니다.
응용 프로그램 우선 순위 매기기
응용 프로그램 목록을 모으기 전에도 응용 프로그램을 분류하고 우선 순위를 매기는 방법을 개발할 수 있습니다. 인벤터리 작업을 수행할 때 이미 개발된 스키마가 있다면 응용 프로그램을 찾으면서 분류할 수 있습니다. 다음과 같은 두 가지 이유 때문에 우선 순위 매기기 스키마가 필요합니다.
롤아웃 날짜까지 모든 응용 프로그램을 제대로 테스트할 시간이 없는 경우
배포가 진행되기 위해서 제대로 실행되어야 하는 응용 프로그램이 무엇인지 알아야 하는 경우
우선 순위 매기기 작업의 최종 목표는 Windows 2000을 배포하기 전에 제대로 작동해야 하는 핵심 응용 프로그램 그룹을 확인하는 것입니다. 우선 순위 매기기 스키마를 개발할 때는 다음 사항을 고려하십시오.
조직에 대한 응용 프로그램의 중요도
영향 받는 사용자의 수
새 버전의 사용 가능 여부
지역화 필요성
조직에 이미 사용하거나 수정할 수 있는 분류 방법이 있을 수도 있습니다. 예를 들어, 오류 복구 계획을 위해서 응용 프로그램의 우선 순위를 매겼을 수도 있습니다. 오류가 발생했을 때 먼저 다시 온라인 상태가 되어야 하는 응용 프로그램을 확인했다면 이런 응용 프로그램의 호환성 테스트 우선 순위가 가장 높게 됩니다.
우선 순위 매기기 스키마의 복잡성은 보유한 응용 프로그램 수와 응용 프로그램이 지원하는 비즈니스 기능의 다양성과 같은 요소에 따라 달라집니다.
거대한 첨단 기술 회사가 네 가지 우선 순위 수준을 개발했다고 가정해 봅시다. 이 회사는 다음과 같이 우선 순위를 정의합니다.
업무용 이 응용 프로그램은 오류가 발생한 후에 먼저 온라인 상태가 되어야 합니다. 이 응용 프로그램은 법적 의무를 완수하거나 자금 정보를 수집하는 데 필요합니다. 조직은 이러한 응용 프로그램의 오류로 인한 아주 작은 위험도 용인할 수 없으며 오류로 인한 영향이나 비용이 매우 클 것입니다.
비즈니스용 이 응용 프로그램은 오류가 발생한 후에 두 번째로 온라인 상태가 되어야 합니다. 이 응용 프로그램은 비즈니스 인프라를 실행하는 데 필요합니다. 인력 관리 응용 프로그램은 비즈니스용 응용 프로그램의 한 예입니다. 조직은 오류로 인한 위험을 거의 용인할 수 없으며 오류로 인한 영향이나 비용이 상당한 수준입니다.
필수 이 응용 프로그램은 비즈니스를 실행하는 데 필요하지만 장시간 동안 오프라인 상태로 있을 수 있습니다. 조직은 오류로 인한 적당한 수준의 위험을 용인할 수 있으며 오류로 인한 영향이나 비용이 비교적 낮습니다.
기타 이 응용 프로그램은 앞에 설명한 어떤 범주에도 들어가지 않으며 이 응용 프로그램 없어도 비즈니스를 계속 진행할 수 있습니다.
또 다른 대규모 첨단 기술 회사가 두 개의 범주(업무용과 비업무용)만 갖고 있다고 가정해 봅시다. 모든 응용 프로그램을 테스트할 충분한 시간이 없다면 이 조직은 배포를 시작하기 전에 업무용 응용 프로그램이 완전히 테스트되고 모든 문제가 해결되어 있는지 확인하고 싶을 것입니다.
응용 프로그램 테스트 계획 준비
테스트 준비의 기본 작업 중 하나는 테스트 계획을 작성하는 것입니다. 테스트 계획에서 테스트의 범위와 목적을 지정하고 사용할 방법을 설명합니다. 계획에는 다음과 같은 정보가 포함됩니다.
범위
테스트 동안 다룰 우선 순위 수준
방법
테스트 수행자와 참여 방법
요구 사항
테스트 수행에 필요한 하드웨어, 소프트웨어, 인력, 교육 및 도구
합격 기준
응용 프로그램 테스트의 성공 여부를 판별하는 요소
일정
일정이 지정된 롤아웃에 따라 테스트를 완료하는 방법
응용 프로그램 수와 테스트 접근 방식에 따라 응용 프로그램 테스트에는 조직 내의 다양한 비즈니스 단위의 협력이 요구되기도 합니다. 프로젝트 초기에 응용 프로그램 보관자를 확인하고 그들에게 테스트 계획을 검토하고 승인할 것인지 아니면 동의한 수준에서 리소스를 적용할 것인지 묻습니다.
테스트 계획 작성에 대한 자세한 내용은 이 가이드의 "Windows 2000 테스트 랩 만들기"를 참조하십시오.
테스트 범위 설정
조직에서 많은 수의 응용 프로그램을 사용한다면 모든 응용 프로그램을 원하는 수준으로 철저히 테스트할 시간이 없을 수도 있습니다. 우선 순위가 가장 높고 가장 많이 사용하는 응용 프로그램을 먼저 테스트합니다. 하지만 테스트를 이 응용 프로그램으로만 제한해서는 안됩니다.
서버 기반 응용 프로그램과 클라이언트 기반 응용 프로그램을 모두 테스트합니다. 일반적으로 클라이언트 기반 응용 프로그램은 변수가 많기 때문에 가장 테스트하기 어렵고 시간이 많이 걸립니다.
사용 중인 시판 응용 프로그램을 이미 외부 조직에서 테스트한 경우라도 사용자 환경에서 테스트해야 합니다. 환경에서 응용 프로그램을 사용할 때 제대로 작동하는 것이 Windows 2000의 기반이 되는 기술과의 호환성을 입증하는 전부는 아닙니다. 외부에서 테스트한 시판 응용 프로그램에 대한 자세한 내용은 이 장의 뒷부분에 나오는 "응용 프로그램 테스트"를 참조하십시오.
테스트 방법 정의
테스트 계획의 주요 부분은 테스트 전략을 설명하는 것입니다. 방법을 계획할 때 다음 사항을 고려합니다.
테스트 수행 장소
테스트 수행자
참여자 포함 방법 및 의사 소통 방법
테스트 일정
응용 프로그램 문제 관리 방법
외부 인력을 사용하는 것은 응용 프로그램 테스트를 위한 한 가지 방법입니다. 이 방법을 사용할 것인지 결정하려면 다음 사항을 고려합니다.
테스트에 사용할 수 있는 인력이 있는지 여부
담당자에게 전문적인 기술이 있는지 여부
외부 인력을 사용하는 비용과 내부 비용 비교
계획 일정, 외부 인력을 사용할 경우 테스트의 조기 달성 여부
보안 요구 사항, 외부 조직에 기밀 자료를 제공해야 하는지 여부
내부적으로 테스트할 때는 경험이 많은 테스터를 선택합니다. 조직에 응용 프로그램 테스터 그룹이 있다면 이러한 테스터 그룹을 사용하는 것이 좋습니다. 이러한 그룹이 없거나 사용할 수 없다면 다양한 리소스를 사용하여 적절한 시간에 최적의 결과를 얻을 수 있는 방법을 찾아야 합니다. 예를 들어, 경험이 많은 소수의 테스터에게 테스트 사례를 개발하게 하고 이러한 테스트 사례를 다른 테스터에게 교육하여 실행할 수 있습니다. 또 다른 방법으로 경험 많은 테스터가 일련의 핵심 테스트를 수행한 후 전문가가 있는 비즈니스 단위와 협력하여 전문적 지식을 테스트 랩에 적용시킬 수 있습니다.
테스트 일정을 잡고 테스터와 의사 소통을 하기 위한 절차를 고안합니다. 예를 들어, 인트라넷에서 모든 사용자가 테스트 날짜, 상태 보고서, 연락처 이름 및 기타 관련 문서를 볼 수 있도록 웹 사이트를 구축할 수도 있습니다.
테스트 결과를 관리하는 절차를 수립합니다. 다음과 같은 사항을 포함한 역할과 책임을 설명합니다.
사고 추적 시스템의 문제 보고서 입력자
문제의 우선 순위 지정, 할당 및 해결 방법
문제 해결과 응용 프로그램의 재테스트 추적자
테스트 추적 및 보고 시스템에서 테스터의 테스트 결과 입력 방법
사례 연구 1: 테스트 페스티벌
대규모 첨단 기술 회사에서 내부 개발자가 응용 프로그램이 Windows 2000과 호환되는지 테스트를 하라는 지시를 받았다고 가정합니다. 테스트 관리자는 다른 관리자와 협력하여 자신의 팀으로부터 도움을 얻었습니다. 테스트 관리자는 CIO에게 보고를 하고 프로그램에 필요한 모든 지원을 얻게 되었기 때문에 활발한 참여를 유도하기가 쉬웠습니다. 테스트 관리자는 랩 테스트 세션 일정을 잡고 개발자에게 세션에 대해 통보했습니다. 랩은 테스터가 원하는 응용 프로그램을 설치할 준비가 된 상태로 미리 구성된 컴퓨터가 설치되었습니다. 테스터는 CD나 네트워크에서 원하는 응용 프로그램을 설치할 수 있었습니다. 이벤트를 흥미롭게 하기 위해서 테스트 관리자가 다과를 제공하였기 때문에 세션은 "테스트 페스티벌"이라는 이름을 얻게 되었습니다.
사례 연구 2: 미리 보기 프로그램
주요한 제조 회사는 Windows 2000 Professional을 테스트하기 위해 미리 보기 프로그램을 개발했습니다. 이 프로그램을 사용하여 클라이언트 기반 응용 프로그램을 테스트하였습니다. 이 회사는 먼저 Windows 2000 클라이언트 컴퓨터에서 사용될 프로토콜 스택이 Windows NT 4.0 프로덕션 환경과 호환되는지 확인하였습니다. 그런 다음 응용 프로그램을 테스트할 장소를 만들기 위해 프로덕션 네트워크의 제한된 장소에 Windows 2000 Professional을 배포했습니다.
프로젝트 팀은 프로그램에 대한 정보로 웹 사이트를 구축했습니다. 사용자는 미리 보기 프로그램에 참가하기 위해 웹 사이트에 있는 응용 프로그램 양식에 정보를 입력했습니다. 참가자 수를 제한하고 철저한 테스트를 보장하기 위해서 프로젝트 책임자와 인사 부장은 신청자를 검토하고 승인하였습니다. 참가자 수가 50-100명으로 제한된 프로그램은 응용 프로그램을 테스트하기 위해서 다양한 범위의 테스터를 제공하였습니다. 테스터는 자신의 문제 보고서를 웹 사이트에 게시했습니다.
리소스 요구 사항 확인
응용 프로그램 호환성 테스트를 계획할 때 컴퓨팅 환경의 향후 상태를 염두에 두어야 합니다. 일부 소프트웨어를 새로운 Windows 2000 기능을 완전히 사용하는 버전으로 업그레이드를 할 계획입니까? 새로운 표준 데스크톱 구성을 구현하거나 터미널 서비스를 사용할 계획입니까? 이와 같은 문제는 하나의 제품군으로 테스트되어야 하는 응용 프로그램과 필요한 리소스를 결정합니다.
룰아웃 도중에 Windows 2000과 함께 새로운 응용 프로그램을 배포할 계획이라면 현재 응용 프로그램과 함께 그러한 응용 프로그램을 테스트합니다.
테스터가 테스트를 수행할 수 있는 랩을 구축하여 테스트를 용이하게 할 수 있습니다. 이런 랩에서는 필요한 도구와 장비를 언제나 사용할 수 있습니다. 일부 조직은 Windows 2000 랩과는 별도로 응용 프로그램 테스트 랩을 갖추고 있습니다. 랩을 분리할 예산이 없다면 다른 프로젝트나 교육과 랩을 공유해야 할 것입니다. 랩을 공유한다면 일정과 필요한 장비가 다른 사용자와 겹치지 않도록 해야 합니다.
테스터가 원하는 응용 프로그램을 설치하고 테스트하는 데 필요한 모드를 신속히 액세스할 수 있도록 랩의 컴퓨터를 다중 부팅을 지원하도록 설정합니다. 예를 들어, 이 장의 뒷부분에 나오는 "응용 프로그램 테스트" 절에서 제시한 사항을 따른다면 업그레이드 경로를 통해 응용 프로그램을 테스트하기 위해 Windows NT 4.0과 Windows 2000이 필요합니다. 테스터가 쉽게 이전 상태로 컴퓨터를 복원시킬 수 있게 하려면 기본 운영 체제가 있는 드라이브의 디스크 이미지를 만듭니다.
회사 네트워크에 랩을 연결해야 하는지 여부를 고려하십시오. 예를 들어, 웹 기반 테스트 추적 시스템을 개발한다면 네트워크에서 또는 회사 인트라넷으로 응용 프로그램을 설치하기 위해 네트워크 공유에 액세스해야 합니다. 이러한 액세스가 필요한 경우에는 먼저 클라이언트 컴퓨터가 사용하는 프로토콜 스택이 프로덕션 네트워크와 호환되는지 확인합니다.
테스트 랩이 큰 경우, 랩 관리자를 지정할 수 있습니다. 랩을 운영하는 기술과 테스트를 관리하는 데 필요한 기술은 매우 다르기 때문에 두 가지 역할에 대해서 각기 다른 사람을 선택하는 것이 좋습니다. 랩 관리자가 뛰어난 기술적 능력을 갖고 있어야 하는 반면 테스트 관리자는 뛰어난 관리 능력과 의사 소통 능력을 갖추어야 합니다.
테스트 랩 디자인 및 관리에 대한 내용이나 테스트 계획 작성에 대한 자세한 내용은 이 가이드의 "Windows 2000 테스트 랩 만들기"를 참조하십시오.
합격-불합격 기준 정의
테스터가 다양한 테스트를 수행하게 되면 테스트를 통과하는 응용 프로그램과 그렇지 못한 응용 프로그램이 생기게 됩니다. 따라서 해결해야 할 응용 프로그램 문제와 쟁점을 로그할 수 있는 장소와 시기를 참가자가 알 수 있도록 정의된 절차가 있어야 합니다.
테스터가 특정 응용 프로그램에 대한 테스트를 완료하게 되면 테스트 추적 및 보고 시스템에 그 결과를 입력해야 합니다. 물론 모든 미해결 문제의 우선 순위를 매기고 추적한 다음 문제가 해결되면 응용 프로그램을 다시 테스트해야 합니다. 그러나 테스트 과정을 추적하려면 이미 준비되어 있는 응용 프로그램과 준비되어 있지 않은 응용 프로그램을 알고 싶을 것입니다. 응용 프로그램의 테스트 통과 여부에 따라 진행 과정을 추적할 계획이라면 사용할 각 범주에 대한 기준을 정의해야 합니다. 테스트 통과 여부의 기준을 정의하려면 다음 사항을 고려합니다.
문제의 심각성, 주요 기능이나 주변 장치에 영향을 주는지 여부
문제를 발견한 과정
문제를 피할 수 있는 방법이 있는지 여부
테스트 일정 작성
테스트 일정은 다음과 같은 많은 조건에 영향을 받습니다.
참가하는 테스터의 수
테스터가 이 프로젝트에서 상근직으로 근무하는지 아니면 시간제로 근무하는지 여부
테스터의 경험 수준
응용 프로그램의 수와 복잡성
일정에는 문제를 해결하고 불합격한 응용 프로그램을 다시 테스트할 수 있는 충분한 시간을 고려해야 합니다. 일정에 따라 진행되고 있는지 진행 과정을 모니터링하고 확인할 수 있도록 중요한 중간 일정을 설정합니다.
응용 프로그램 테스트
Microsoft는 고객 및 독립적인 소프트웨어 공급업체(ISV)와 협력하여 Windows 2000 Application Specification을 개발했습니다. 이 사양에 따라 작성된 응용 프로그램은 Windows 2000과 호환될 뿐만 아니라 Windows 2000에서 제공하는 새로운 기술을 이용할 수 있습니다.
Windows 2000 Application Specification은 MSDN(Microsoft Developer Network) 웹 사이트에서 다운로드할 수 있으며 데스크톱 응용 프로그램용과 분산 응용 프로그램용의 두 구성 요소가 있습니다. 데스크톱 응용 프로그램 사양은 Windows 2000 Professional에서 독립 실행형 프로그램이나 분산 응용 프로그램의 클라이언트 부분으로 실행되는 응용 프로그램에 적용됩니다. 분산 응용 프로그램 사양은 Windows 2000 Server에서 실행되는 응용 프로그램에 적용됩니다. 사양과 복사본 다운로드에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Windows 2000 Application Specification 링크를 참조하십시오.
또한 Windows 2000 Application Specification과 일치하는 시판 응용 프로그램은 인증될 수 있습니다. 인증된 응용 프로그램은 독립적인 테스트 기관에서 테스트되며 일정 요구 사항을 만족시킵니다. 예를 들어, 인증서를 받으려면 응용 프로그램에서 Windows Installer를 사용해야 합니다. 시판 응용 프로그램은 인증되지 않은 사양을 따를 수 있습니다. 이런 경우 응용 프로그램은 독립적인 테스트 기관이 아니라 공급업체에서 테스트합니다.
일부 조직에서는 Windows 2000 배포 프로젝트의 일부로 사양 요건의 충족 여부를 응용 프로그램을 구입 시의 선택 기준으로 삼았습니다. 응용 프로그램을 내부적으로 개발한 경우, 응용 프로그램 개발 지침에 사양을 추가하는 것이 좋습니다.
그 동안에 많은 시판 응용 프로그램이 이미 Windows 2000 지원 여부에 대한 테스트를 거쳤습니다. Microsoft는 여러분이 사용하는 응용 프로그램의 상태를 살펴볼 수 있도록 Windows 2000 응용 프로그램의 디렉터리를 제공합니다. Windows 2000을 지원하는 클라이언트 기반 제품이나 서버 기반 제품에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources))에서 Directory of Windows 2000 Application 링크를 참조하십시오.
디렉터리는 다음과 같은 명칭을 사용합니다.
Certified 응용 프로그램이 독립적인 테스트 기관에 의해 테스트되었고 새로운 Windows 2000 기능을 이용한다는 것을 나타냅니다.
Ready 공급업체에 따라 응용 프로그램의 Windows 2000 호환성과 지원 여부가 테스트되었음을 나타냅니다. 응용 프로그램이 새로운 Windows 2000 기능을 이용할 필요는 없습니다.
Planned 응용 프로그램이 완전히 테스트되면 Certified 또는 Ready 기준에 적합한 응용 프로그램이라는 것을 나타냅니다.
테스트 전략 개발
응용 프로그램 테스트의 목적은 현재 플랫폼에서 작동하는 모든 것이 Windows 2000에서도 작동하는지 확인하는 것입니다. 응용 프로그램이 이전 버전의 Windows용으로 작성된 경우, 반드시 새로운 Windows 2000 기능을 최대한으로 사용하는 것은 아닙니다. 하지만 그 기능은 현재 플랫폼뿐만 아니라 Windows 2000에서도 작동해야 합니다.
시판 응용 프로그램을 위한 전략
시판 응용 프로그램의 경우, 먼저 업그레이드만 확인 모드에서 Windows 2000 Professional 설치 프로그램을 실행하여 잠재적 비호환성을 검사해야 합니다. 이 모드에서 설치 프로그램을 실행하면 설치 프로그램은 호환되지 않는 것으로 알려진 응용 프로그램 목록에서 설치된 소프트웨어를 검사하고 찾아낸 것을 기록합니다. 업그레이드만 확인 모드의 명령줄 구문은 다음과 같습니다.
winnt32 /checkupgradeonly
이 유틸리티가 잠재적 호환성 문제에 대해서 경고를 할 수 있기는 하지만 이것은 컴퓨터에 설치된 응용 프로그램과 소수의 응용 프로그램만을 다룹니다. 응용 프로그램이 호환되지 않는 응용 프로그램 목록에 없다고 해서 해당 응용 프로그램이 호환될 수 있다는 것을 의미하는 것은 아닙니다. 설치 프로그램에 대한 자세한 내용은 이 가이드의 "클라이언트 설치 및 업그레이드 자동화"를 참조하십시오.
다음 단계는 Windows 2000 응용 프로그램의 디렉터리를 확인하여 사용하는 응용 프로그램의 호환성을 알아보는 것입니다.
응용 프로그램의 일부가 이미 테스트를 받았다는 것을 알게 된다고 해도 여러분의 환경에서 응용 프로그램을 테스트해야 합니다. 이 경우, 조직에서 응용 프로그램을 사용하는 방식에 초점을 맞춰 테스트를 할 수 있습니다. 예를 들어, 다음을 테스트하십시오.
조직에서 사용하는 구성
가장 많이 사용하는 기능
함께 사용되는 응용 프로그램의 조합
이 장의 뒷부분에 나오는 "테스트 팁" 절에서 응용 프로그램 기능을 테스트하는 몇 가지 방법을 제공합니다. 다른 조직에서 호환성을 테스트하지 않은 시판 응용 프로그램을 사용한다면 더욱 광범위하게 테스트해야 합니다.
바이러스 방역 소프트웨어를 테스트해야 한다는 점을 기억하시기 바랍니다. 이러한 응용 프로그램의 대부분은 파일 시스템 필터를 사용하기 때문에 업데이트가 필요합니다. 많은 Windows NT 4.0 파일 시스템 필터는 NTFS 파일 시스템의 변경으로 인하여 Windows 2000에서 작동하지 않을 수도 있습니다.
사용자 정의 응용 프로그램을 위한 전략
사용자 정의된 다른 공급업체 제품을 사용하거나 내부적으로 응용 프로그램을 개발하는 경우, 사전에 테스트된 시판 응용 프로그램의 테스트 전략보다 좀더 광범위한 테스트 전략을 수립해야 합니다.
자체 개발하지 않은 응용 프로그램을 테스트하는 경우에도 Windows 2000 Application Specification은 테스트에 대한 자세한 내용을 제공합니다. MSDN 웹 사이트는 다운로드할 수 있는 형태의 사양 뿐만 아니라 Windows 2000 Application 인증을 위한 Microsoft 테스트의 모든 세부 테스트 계획을 포함합니다. 이 테스트 계획은 기능적인 영역과 테스트 방식에 대한 개념을 제공해 줄 수 있습니다. 사양이나 테스트 계획을 다운로드하는 방법에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Application Specification Download 링크를 참조하십시오.
MSDN 웹 사이트에는 독립적인 테스트 기관에서 공급업체가 인증을 위해 제출한 응용 프로그램의 기능을 테스트하기 위해 사용하는 검사 테스트와 방법에 대한 백서와 같은 다른 중요한 정보가 있습니다.
테스트 팁
이 절의 테스트 제안은 포괄적인 것이 아니며 모든 경우에 적용되지 않습니다. 이것은 테스트 방법을 작성하는 데 도움을 주기 위한 것입니다.
배포 시나리오 테스트
배포 동안 사용할 예정인 시나리오를 통해 응용 프로그램 설치와 실행을 테스트해야 합니다. 예를 들어, 새로 설치로 배포하거나 Windows 3.x 또는 Windows NT의 이전 버전에서 업그레이드를 하여 배포하는 계획을 수립할 수도 있습니다. 업그레이드를 할 계획이라면 업그레이드 동안 응용 프로그램을 컴퓨터에 유지하거나 응용 프로그램을 제거하고 업그레이드 한 다음 다시 설치할 수도 있습니다.
IntelliMirror 소프트웨어 설치 및 관리로 응용 프로그램을 관리할 수 있도록 Windows Installer용이나 .zap 파일로 응용 프로그램을 다시 패키지하는 것을 고려합니다. 응용 프로그램 패키지에 대한 자세한 내용은 이 가이드의 "변경 및 구성 관리 적용"을 참조하십시오.
Windows 3.x와 Windows 2000 사이에는 차이가 있기 때문에 일부 응용 프로그램 설치는 설치에 사용한 운영 체제에 따라 다르게 작동합니다. 예를 들어, Windows 3.x를 실행하는 컴퓨터에서 응용 프로그램을 설치하고 나서 컴퓨터를 Windows 2000으로 업그레이드하면 응용 프로그램을 Windows 2000에 설치했을 때와 똑같이 작동하지 않을 수도 있습니다. 이런 경우, 응용 프로그램을 제거하고 업그레이드가 된 후나 마이그레이션 동적 링크 라이브러리(DLL)를 구한 후에 다시 설치해야 합니다.
마이그레이션 DLL은 원래 Windows 3.x에 설치된 응용 프로그램이 컴퓨터를 Windows 2000으로 업그레이드한 이후에 제대로 실행될 수 있도록 해줍니다. 마이그레이션 DLL은 다음과 같은 조치를 통해 응용 프로그램 문제를 해결할 수 있습니다.
Windows 3.x 관련 파일을 Windows 2000 호환 파일로 대체 또는 업그레이드
응용 프로그램 및 사용자 설정을 Windows 2000의 올바른 위치로 매핑
Windows 3.x 관련 레지스트리 키를 적절한 Windows 2000 위치로 매핑
내부적으로 개발된 응용 프로그램의 경우, 마이그레이션 DLL을 만들거나 공급업체로부터 이 DLL을 구해야 할 것입니다. "migration DLL"이라는 키워드를 사용하여 MSDN Library를 검색하면 마이그레이션 DLL 만들기와 테스트에 대한 자세한 내용을 찾을 수 있습니다. MSDN Library에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 MSDN 링크를 참조하십시오. 또한 일부 마이그레이션 DLL은 Windows 2000에 포함됩니다.
결과는 업그레이드 방법에 따라 달라질 수 있기 때문에 롤아웃 동안 사용할 것과 같은 절차와 도구를 사용하여 테스트를 하는 것이 중요합니다. 응용 프로그램을 테스트할 때 절차와 도구가 아직 준비되지 않았다면 최소한 사용할 시나리오를 테스트해야 합니다.
업그레이드 시나리오
컴퓨터를 업그레이드할 계획이라면 다음 단계를 사용합니다.
Windows 3.x 또는 Windows NT 3.51 또는 그 이후 버전 설치
응용 프로그램 설치
Windows 2000으로 업그레이드
응용 프로그램 테스트
Windows 3.x 응용 프로그램이 제대로 작동하지 않으면 ISV에게 마이그레이션 DLL에 대해서 문의합니다. Windows NT 응용 프로그램이 제대로 작동하지 않으면 ISV에게 패치 또는 새로운 설치 프로그램에 대해서 문의하십시오.
새로 설치 시나리오
Windows 2000을 다시 포맷된 컴퓨터에 설치할 계획이라면 다음 단계를 사용합니다.
Windows 2000 설치
응용 프로그램 설치
응용 프로그램 테스트
응용 프로그램이 제대로 작동하지 않으면 ISV에게 패치 또는 새로운 설치 프로그램에 대해서 문의하십시오.
설치 및 제거 테스트
다양한 방법으로 응용 프로그램의 설치를 테스트해야 합니다.
완료 전에 설치를 중지합니다.
환경에서 모든 설치 옵션을 사용해 봅니다.
조직에서 사용자가 응용 프로그램을 설치할 수 있도록 허용하는 경우, 관리자와 고급 사용자 모두로 설치를 테스트합니다. 그런 다음 응용 프로그램의 기능을 테스트합니다.
응용 프로그램의 설치를 제거해 봅니다.
응용 프로그램이 관리자에 의해서 설치되고 사용자에 의해서 설치가 제거될 수 있는지 확인합니다. 사용자가 사용자로 로그온하면 설치 제거가 완료되거나 활성화되지 않아야 합니다.
기본 응용 프로그램 기능 테스트
비즈니스 작업을 달성하기 위해 사용하는 기능, 구성 및 응용 프로그램 제품군을 사용하여 응용 프로그램을 테스트합니다. 예를 들어, 다음과 같은 종류의 테스트를 시도해 볼 수 있습니다.
사용자로서 로그온하고 최종 사용자에게 가장 중요한 기능을 테스트합니다. 비즈니스 작업을 수행하는 데 필요한 특수한 시나리오를 테스트합니다.
사용자 그룹의 구성원인 여러 사용자로 로그온합니다.
응용 프로그램과 시스템에 그룹 정책을 적용합니다.
표준 데스크톱 구성과 같은 응용 프로그램 조합을 테스트합니다.
종료를 하지 않고 몇 일 또는 몇 주 동안 몇 개의 응용 프로그램을 데스크톱에서 실행합니다.
Microsoft? Office 응용 프로그램에서 Microsoft? Visual Basic? for Application(VBA)을 사용하는 자동화 작업을 테스트합니다.
긴 파일 이름이 일관성 있게 지원되는지 테스트합니다. 마침표를 포함시키고 앞에 있는 공백이 삭제되는지 확인합니다.
1MB 이상의 큰 그래픽 파일을 조작합니다.
워드 프로세싱 문서에서 광범위한 편집 작업을 수행합니다.
편집, 컴파일, 편집, 컴파일의 순서로 RAD를 수행합니다.
OLE 사용자 정의 컨트롤(OCX)을 테스트합니다.
스캐너와 플러그 앤 플레이 장치와 같은 적용 가능한 하드웨어를 테스트합니다.
터미널 서비스를 배포할 계획이라면 터미널 서비스 서버에서 응용 프로그램을 테스트합니다. 사용자 특정 설정으로 동일한 응용 프로그램을 실행하는 다중 사용자와 다른 응용 프로그램을 실행하는 다중 사용자를 테스트합니다.
예제 테스트 계획을 다운로드하려면 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Application Specification Download 링크를 참조하십시오.
데이터 액세스
다음과 같은 다양한 방식으로 데이터를 액세스해 보십시오.
현재 버전의 Windows를 실행하는 서버 뿐만 아니라 Windows 2000을 실행하는 서버에서 데이터를 액세스합니다.
레코드의 동시 발생적인 액세스와 업데이트를 포함한 데이터베이스의 동시 사용을 테스트합니다.
복잡한 쿼리를 실행합니다.
인쇄 테스트
다음과 같이 다양한 문서 종류를 다양한 프린터로 인쇄합니다.
몇몇 원본 응용 프로그램에서 포함된 파일이 있는 문서를 인쇄합니다.
긴 파일 이름을 가진 프린터로 인쇄합니다.
테스트 도구 사용
Windows 2000 Software Development Kit(SDK), Driver Development Kit(DDK) 및 Microsoft? Windows? 2000 Server Resource Kit에는 응용 프로그램을 테스트하고 디버깅하는 도구가 들어 있습니다.
Windows 2000 Server Resource Kit에 있는 Dependency Walker는 응용 프로그램에서 요구하는 종속 모듈을 재귀적으로 검색합니다. 이 유틸리티는 손실된 파일, 유효하지 않은 파일, 가져오기 또는 내보내기 불일치, 원형 종속 오류, 불일치된 컴퓨터에 설치되어 있는 모듈 등을 검색합니다. 이 유틸리티에 대한 자세한 내용은 함께 들어 있는 도움말 파일을 참조하십시오.
Windows 2000 Server Resource Kit에 있는 Apimon은 모든 응용 프로그램 프로그래밍 인터페이스(API) 호출에 대한 카운트와 타이밍을 통해 실행중인 응용 프로그램을 모니터링합니다. 선택적으로 페이지 오류를 모니터링할 수도 있습니다. Apimon은 다음과 같은 사항을 보고할 수 있습니다.
모든 API 호출의 카운트 및 각 호출에 대한 타이밍
호출이 이루어지는 순서로 API 호출 추적
일반적인 호환성 문제
Windows 2000의 새로운 기술은 Windows의 이전 버전용으로 개발된 응용 프로그램에서 오류를 발생시킬 수 있습니다. MSDN 웹 사이트에서 찾을 수 있는 Windows 2000 Compatibility Guide에는 응용 프로그램에서 문제를 일으킬 수 있는 많은 변경 사항에 대한 자세한 설명이 나옵니다. 이 가이드는 호환 문제를 다음과 같은 네 가지 영역으로 나누고 있습니다.
설정 및 설치
일반적인 Windows 2000 호환성
응용 프로그램 안정성
Windows 플랫폼
이 절에서는 응용 프로그램에서 가장 많은 문제를 일으키는 Windows 2000의 몇 가지 변경 사항을 다룹니다. Windows의 이전 버전용으로 개발된 응용 프로그램은 Active Directory나 IntelliMirror와 같은 새로운 기능을 완전히 이용하지 않을 수도 있습니다. 이 절에서는 응용 프로그램이 이러한 새 기능을 사용하지 않을 때 발생하는 문제는 다루지 않습니다.
다음과 같은 영역에서 문제가 발생할 수 있습니다.
시스템 파일 보호
Windows의 초기 버전에서 응용 프로그램은 설치 도중에 공유 시스템 파일을 대체할 수 있었습니다. 이러한 변경이 발생하면 사용자는 프로그램 오류에서 불안정한 운영 체제에 이르기까지 다양한 문제를 자주 경험하게 되었습니다.
시스템 파일 보호(SFP)는 Windows 2000의 새로운 기능으로 응용 프로그램이 시스템 파일을 바꾸지 못하게 해줍니다. 이 기능은 보호된 시스템 파일이 올바른 Microsoft 버전인지 확인합니다. 파일이 잘못된 버전으로 바뀌면 Windows 2000은 올바른 버전을 복원합니다.
강력한 힙 검사
Windows 2000은 몇 가지 성능이 개선된 힙 관리자를 포함합니다. 이전에 힙 관리를 올바르게 사용하지 않았던 응용 프로그램들은 이제 메모리 관리에 문제가 발생할 수 있습니다. 공통적인 문제는 해제된 메모리를 계속 사용하는 것과 메모리가 더 작은 크기로 다시 할당된 경우에도 메모리가 이동되지 않았다고 가정하는 것입니다.
하드웨어 장치 열거
지원되는 하드웨어 장치 목록이 변경되면 지원되지 않는 장치를 사용하는 응용 프로그램에 문제가 발생할 수 있습니다.
글꼴 열거
글꼴 목록이 변경되었습니다. 국제화를 지원하기 위한 레지스트리 키가 추가되었기 때문에 몇몇 응용 프로그램에서는 글꼴이 여러 개 표시될 수도 있습니다.
변경된 레지스트리 키
몇몇 레지스트리 키가 이동되거나 삭제되었습니다. Win32 응용 프로그램 프로그래밍 인터페이스(API)를 사용하여 레지스트리 키를 변경하는 응용 프로그램은 문제가 없지만 레지스트리에 직접 쓰기를 한다면 문제가 발생할 수 있습니다.
버전 검사
버전을 제대로 검사하지 못하는 설치 응용 프로그램은 문제가 있게 됩니다. 응용 프로그램이 특정 운영 체제나 버전에 의존하지 않는 한 응용 프로그램에서 요구하는 최소한의 운영 체제 버전을 검사하고 그 버전이나 그 이후 버전에서 설치를 해야 합니다.
Windows 메시징 서비스
Windows 메시징 서비스(WMS)를 운영 체제에서 제공하기를 기대하는 응용 프로그램은 이 서비스를 찾지 못합니다. 이 서비스를 Windows Update 웹 사이트에서 구해야 합니다.
파일 입출력 보안
Windows 2000에는 파일 입출력에 대한 강력한 보안 기능이 있습니다. 바이러스 방역 프로그램과 같이 파일 필터를 사용하는 응용 프로그램은 Windows 2000에서 중요한 기능이 손상될 수도 있습니다.
테스트 결과 추적
응용 프로그램 비호환성을 발견할 때 이 응용 프로그램 비호환성을 입력하는 기존의 사건 추적 시스템을 갖고 있다고 해도 응용 프로그램 테스트의 상태를 추적할 수 있는 별도의 방법이 필요합니다. 테스트를 통과한 응용 프로그램, 통과하지 못한 응용 프로그램 및 테스트되지 않은 응용 프로그램과 같은 정보를 찾을 수 있어야 합니다.
필요할 때 보고서를 만들 수 있도록 테스트 결과를 쉽고 정확하게 변환하는 방법을 고려해야 합니다. 방법을 계획할 때는 다음 사항을 고려합니다.
데이터 캡처 메커니즘
캡처될 데이터의 범주
추적 시스템 선택
데이터 캡처용으로 선택하는 메커니즘은 테스트 노력, 예산, 사용 가능한 전문가의 규모에 따라 달라집니다. 테스트 추적 및 보고 시스템을 구입할 수도 있습니다. 많은 공급업체에서 이런 용도의 제품을 판매합니다. 이러한 제품을 판매하는 공급업체에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Test Tracking Systems 링크를 참조하십시오. 또 다른 방법으로 다음과 같은 키워드를 사용하여 웹 사이트에서 검색을 수행합니다.
"소프트웨어 테스트 도구"
"테스트 관리 도구"
"자동 테스트 도구"
"테스트 도구"
결정을 하기 전에 옵션을 조사하고 시판 솔루션 비용과 자체 개발 비용을 비교합니다.
자체 시스템을 개발하기로 했다면 테스트 결과를 스프레드시트나 워드 프로세싱 문서 대신 데이터베이스로 변환하는 것이 좋습니다. 데이터베이스는 보고서 작성 시 가장 큰 유연성을 제공하며 데이터의 양이 증가해도 관리하기가 쉽습니다. 웹 프런트 엔드는 데이터 입력 및 상태 보기 모두에 대해서 손쉬운 액세스를 제공합니다.
자동화 온라인 솔루션의 장점은 결과를 쉽게 기록하고 보고서를 작성할 수 있다는 것입니다. 단점은 개발 시간 및 비용이 많이 든다는 것입니다. 액세스가 불가능하고 제때에 정확한 보고서를 만들기 어렵다는 주된 단점으로 인하여 용지 기반 시스템은 권장되지 않습니다.
개발할 것인지 구매할 것인지 여부에 따라 사용하려고 결정한 메커니즘은 다음과 같은 기준을 만족시켜야 합니다.
쉽고 정확한 데이터 입력
데이터를 입력하거나 보는 모든 사용자의 손쉬운 액세스
보관을 위한 쉬운 백업 또는 복제
다양한 보고서를 위한 데이터의 쉬운 선택 및 정렬
많은 양의 데이터 처리 가능
동시 발생적인 다중 사용자 처리 가능
변경으로부터 기존의 항목 보호
테스터는 테스트를 완료하는 동안 데이터를 기록하기 위해서 간단하면서도 손쉽게 기억될 수 있는 프로세스를 요구합니다. 테스트 컴퓨터에서 응용 프로그램이나 웹 사이트에 대한 링크를 갖고 싶을 수도 있습니다.
인트라넷에서 웹 사이트를 개발하여 데이터를 수집하는 경우, 사이트를 테스트 통신 센터로 사용할 수 있습니다. 여기에는 상태 보고서, 연락처 이름, 테스트 일정표, 관련 정보 링크 및 기타 관련 문서가 포함됩니다.
데이터 수집 메커니즘을 구축하려면 다음과 같은 항목을 개발하기 위한 리소스가 필요합니다.
데이터 입력 응용 프로그램을 위한 웹 또는 일부 다른 응용 프로그램 코드
데이터베이스 및 스키마
보고서 및 쿼리
보안(필요한 경우)
데이터 캡처
일단 데이터 수집 방법을 결정하고 나면 수집할 데이터를 결정해야 합니다. 필요한 데이터를 미리 결정하는 데 시간을 투자하는 것이 좋다는 것을 알게 될 것입니다. 처음부터 데이터가 수집된 경우, 필요에 따라 새로운 보고서를 디자인할 수 있습니다.
응용 프로그램의 인벤터리를 작성할 때 필요한 정보의 대부분을 수집하게 됩니다. 또한 각각의 응용 프로그램에 대해서 다음과 같은 정보가 필요할 것입니다.
테스터의 이름과 비즈니스 단위
개발자의 이름과 비즈니스 단위(내부적으로 개발된 경우)
Windows 2000 제품명(Server 또는 Professional)
테스트 결과는 다음과 같습니다.
합격
불합격
진행 중
알 수 없음
사고 추적 시스템에 입력된 각 문제에 할당된 번호
설명
각 레코드에 대한 날짜 및 시간 스탬프
날짜/시간 스탬프는 특정 시간 범위에 대한 보고서를 만들 때 유용한 필터를 제공합니다.
결과 보고
수집할 데이터를 신중하게 분석할수록 보고서 작성에 더욱 큰 유연성을 갖게 됩니다. 다음에 제시되는 사항은 도움이 될 예제 보고서입니다.
호환성 테스트에 불합격한 응용 프로그램 목록
이 보고서는 문제를 해결하고 응용 프로그램을 다시 테스트하기 위해 추적 방식을 요구합니다.
각 비즈니스 단위에 대해서 각 우선 순위 수준에 대한 응용 프로그램의 총 수
각 비즈니스 단위에 대해서 테스트되지 않은 응용 프로그램의 총 수
테스트되지 않은 응용 프로그램의 비율(백분율)을 포함시킵니다. 이 보고서를 사용하여 과정을 수행 중인 테스트와 그렇지 못한 테스터를 추적할 수 있습니다. 테스트에서 뒤쳐져 있는 그룹에게 이 보고서를 일종의 인센티브로 사용할 수 있다는 점을 간과해서는 안됩니다.
응용 프로그램의 합격 또는 불합격 여부에 따라 진행 상황을 보고하는 경우, 상대적 진행 상황을 나타내야 하는지 아니면 실제 수치를 나타내야 하는지 고려합니다. 색상 구성표나 그래픽과 같은 확장 기능으로 상대적 진행 상황을 나타낼 수 있습니다. 이렇게 하면 잘못 이해될 수 있는 숫자를 나타내지 않고도 진행 상황을 제공할 수 있습니다. 실제 숫자로 진행 상황을 나타내야 하는 경우, 응용 프로그램의 우선 순위를 토대로 하여 수치를 보고하거나 비중을 매길 방법을 만들고 싶을 수도 있습니다. 예를 들어, 10개의 응용 프로그램만 합격하고 하나가 불합격했다고 알려주는 보고서는 정확한 상태를 나타내지 않을 수도 있습니다. 10개의 응용 프로그램이 소수의 사용자들이 가끔씩 사용하는 특수한 유틸리티이고 불합격한 하나의 응용 프로그램이 일상 업무를 수행하는 데 필요한 중요 응용 프로그램인 경우, 보고서는 완전한 설명을 제공하지 않는 것입니다.
테스터가 웹 사이트와 같은 특정 장소에 문제를 게시한 경우, 미해결 문제와 완결된 문제의 보고서를 제공할 수도 있습니다.
각 테스트 이벤트 후에 그리고 필요에 따라 정기적으로 관리 및 테스트 참가자에 대한 보고서를 작성하고 배포합니다. 테스트 프로젝트를 위한 웹 사이트가 있다면 온라인 보고서를 실행하는 기능을 포함시킬 수 있습니다.
응용 프로그램 비호환성 해결
응용 프로그램 문제를 발견하면 응용 프로그램의 우선 순위를 매긴 다음 문제를 해결할 담당자를 지정해야 합니다. 문제를 할당하는 방법에 대한 계획이 있어야 합니다. 예를 들어, 시판 응용 프로그램 관련 문제는 내부적으로 개발한 응용 프로그램과는 다르게 처리됩니다. 문제 연구 및 해결에 적합한 인력을 구축하는 것은 응용 프로그램 테스트의 성공을 위해 중요합니다. 문제 해결에는 다음과 같은 다양한 활동이 포함될 수 있습니다.
알려진 문제 및 해결책에 대한 웹 사이트 조사
패치, 설치 프로그램 또는 마이그레이션 DLL에 대해 공급업체에게 문의
Microsoft 제품 지원 서비스 문의
내부적으로 개발된 응용 프로그램 디버깅
문제의 원인을 조사할 때 다양한 접근 방식을 고려하여 가장 효과적인 솔루션을 결정해야 합니다. 예를 들어, 다음과 같은 방법을 선택할 수 있습니다.
응용 프로그램을 개발한 경우 문제 수정
응용 프로그램을 구입한 경우 공급업체로 문제 수정 요청
응용 프로그램을 새로운 버전 또는 다른 응용 프로그램으로 대체
문제를 해결할 수 있는 방법이 있는 경우에는 오류 무시
문제를 Windows 2000 호환성 문제로 다루기 전에 항상 현재 플랫폼에 문제가 발생하지 않는지 확인해야 합니다. Windows 2000 호환성 문제에 대한 몇 가지 연구 자료는 다음과 같습니다.
Windows 2000 Application Specification
사양 다운로드 방법에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Application Specification Download 링크를 참조하십시오.
Windows 2000 Compatibility Guide
이 가이드는 MSDN과 Technet에서 사용할 수 있으며 호환성 문제 진단에 대한 가치 있는 정보가 들어 있습니다.
Microsoft Technet
이 리소스는 제품 업데이트, 백서 및 기타 기술 자료를 포함합니다. Technet에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)의 Technet 링크를 참조하십시오.
Directory of Windows 2000 Applications
이것은 지원 정보 및 공급업체 웹 사이트에 대한 링크를 포함합니다. 디렉터리에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)의 Directory of Windows 2000 Application 링크를 참조하십시오.
응용 프로그램 테스트를 위한 계획 수립 작업 목록
표 21.1은 응용 프로그램의 Windows 2000 호환성을 테스트하고 계획을 수립할 때 수행해야 하는 작업을 요약한 것입니다.
표 21.1 응용 프로그램 테스트를 위한 계획 수립 작업 목록 작업
참조할 항목
비즈니스 작업에 사용되는 응용 프로그램 인벤터리 작성 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
사용하는 응용 프로그램의 수를 줄이고 데스크톱 표준 개발 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
응용 프로그램 우선 순위 매기기를 위한 시스템 개발 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
비즈니스 수행에 중요한 순서로 응용 프로그램 우선 순위 매기기 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
테스트 방법, 랩 및 테스트 리소스 요구 사항, 일정을 포함한 테스트 계획 작성 응용 프로그램 테스트 계획 준비
테스트 결과 캡처 및 보고를 위한 테스트 추적 시스템 개발 테스트 결과 추적
테스트 방법 개발 장려 응용 프로그램 테스트 계획 준비
테스트 이벤트 일정 응용 프로그램 테스트 계획 준비
응용 프로그램 테스트 및 결과 기록 응용 프로그램 테스트
테스트 과정 보고 테스트 결과 추적
응용 프로그램 비호환성 문제 해결 응용 프로그램 비호환성 해결
추가 리소스
응용 프로그램의 비호환성 테스트 및 진단에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Microsoft Knowledge Base 링크를 참조하십시오.
응용 프로그램 테스트에 대한 자세한 내용은 다음을 참조하십시오.
Testing Computer Software by Cem Kaner, Jack Falk and Hung Quoc Nguyen, 1993, New York, NY: Van Nostrand Reinhold
Black-Box Testing: Techniques for Functional Testing of Software and Systems by Boris Bizer, 1995, New York, NY: John Wiley & Sons
Software Testing: A Craftsman's Approach by Paul Jorgensen, 1995, Boca Raton, FL: CRC Press
The Craft of Software Testing: Subsystem Testing Including Object -Based and Object-Oriented Testing by Brian Marick, 1995, Englewood Cliffs, NJ: Prentice Hall
새로운 운영 체제를 배포하는 계획을 수립할 때 엄청난 노력이 들기 때문에 그 운영 체제에서 실행할 응용 프로그램에 대해서는 미루어 두기 쉽습니다. 그러나 배포 프로젝트에서 중요한 단계는 배포 중에 문제를 일으킬 수 있는 응용 프로그램을 확인하고 배포를 시작하기 전에 문제를 해결하는 것입니다.
배포 전에 잠재적 응용 프로그램 문제를 해결할 수 있으려면 응용 프로그램 테스트 관리자가 초기에 Windows 기반 응용 프로그램 테스트 계획을 수립해야 합니다. 이 장은 응용 프로그램과 Microsoft? Windows? 2000의 호환성을 테스트하는 과정을 다룹니다.
차례 목차로
다음 장으로
응용 프로그램 테스트 개요
응용 프로그램 테스트 관리
비즈니스 응용 프로그램 확인 및 우선 순위 매기기
응용 프로그램 테스트 계획 준비
응용 프로그램 테스트
테스트 결과 추적
응용 프로그램 비호환성 해결
응용 프로그램 테스트를 위한 계획 수립 작업 목록
이 장의 목표
이 장은 다음과 같은 계획 수립 문서의 개발을 도와줍니다.
비즈니스 응용 프로그램의 우선 순위 목록
응용 프로그램 호환성 테스트를 위한 계획
추적 및 보고 시스템 테스트
Resource Kit의 관련 정보
테스트 계획 수립에 대한 자세한 내용은 이 가이드의 "Windows 2000 테스트 랩 만들기"를 참조하십시오.
응용 프로그램 표준 정의에 대한 자세한 내용은 이 가이드의 "클라이언트 관리 및 구성 표준 정의"를 참조하십시오.
응용 프로그램 테스트 개요
Windows 2000의 기반이 되는 새로운 기술로 인하여 Windows 2000 배포 프로젝트의 일부로 비즈니스 응용 프로그램의 운영 체제 호환성을 테스트해야 합니다. 현재 Windows NT를 사용하고 있다고 해도 모든 응용 프로그램이 Windows 2000에서 같은 방식으로 작동할 것이라고 생각해서는 안됩니다. 개선된 보안과 같은 성능 향상은 이전 Windows 버전용으로 개발된 응용 프로그램을 다시 테스트해야 한다는 것을 의미합니다. 이러한 응용 프로그램은 Windows 2000에서 사용할 수 있는 새로운 기능을 완전히 이용하지 않을 수도 있습니다. 그러나 응용 프로그램은 현재 플랫폼에서 작동하는 것처럼 Windows 2000에서도 계속 실행되어야 합니다.
비즈니스 응용 프로그램 정의
이 장에서 비즈니스 응용 프로그램은 비즈니스 수행에 중요한 응용 프로그램을 의미합니다. 비즈니스 응용 프로그램의 범위는 업무용 시스템부터 특수한 도구까지 다양합니다. 구매하여 사용할 수 있는 완제품, 사용자 정의된 다른 공급업체 시스템, 자체 개발한 시스템 등을 포함한 클라이언트 컴퓨터나 서버에서 실행되는 모든 프로그램을 고려합니다.
참고 이 장에서 클라이언트 기반 응용 프로그램을 자주 언급하기는 하지만 여기에서 다루는 문제와 방법은 서버 기반 응용 프로그램과 클라이언트 기반 응응 프로그램에 모두 적용됩니다.
조직이 다른 조직과 비슷하다면 테스트할 시간보다 응용 프로그램이 더 많다는 것을 알게 될 것입니다. 이런 경우, 응용 프로그램의 우선 순위를 매기고 핵심 비즈니스 작업에 중대한 영향을 주는 응용 프로그램부터 테스트합니다. 응용 프로그램 우선 순위 매기기에 대한 자세한 내용은 이 장의 뒷부분에 나오는 "비즈니스 응용 프로그램 확인 및 우선 순위 매기기"를 참조하십시오.
응용 프로그램 테스트 절차
그림 21.1은 응용 프로그램 테스트 절차에 포함된 단계를 나타냅니다. 먼저 Windows 기반 응용 프로그램을 확인하고 비즈니스에 중요한 순서로 응용 프로그램의 우선 순위를 매겨야 합니다. 인벤터리를 만드는 동안 테스트 조정 방법의 계획 수립에 착수할 수 있습니다. 그런 다음 테스트가 진행되는 동안 정기적으로 관리 부서에 상태를 보고하여 호환성 문제가 발생할 때 문제를 해결해야 합니다. 이 장에서는 그러한 단계를 자세히 다룹니다.
그림 21.1 응용 프로그램 테스트 단계
응용 프로그램 테스트 관리
응용 프로그램 테스트에 많은 노력을 들여야 하므로 테스트와 테스트 과정을 모니터링하고 테스트 계획과 방법을 수립할 관리자를 선발하는 것이 좋습니다. 다국적 기업이거나 고도로 분산된 조직이라면, 특히 각기 다른 응용 프로그램 제품군을 여러 장소에서 사용하는 경우, 여러 곳에 테스트 관리자를 두고 싶을 것입니다. 이런 접근 방식을 사용하면 테스트 관리자가 다양한 네트워크 클라이언트나 성능 요구 사항과 같은 특정 지역의 요구 사항을 중점적으로 다룰 수 있습니다.
Windows 2000 프로젝트의 초기에 어떤 문제가 발생했을 때 그 문제를 해결할 수 있는 시간을 가질 수 있도록 응용 프로그램 테스트의 기본 토대를 마련합니다. 테스트 관리자는 다음과 같은 작업에 대한 책임을 지면서 응용 프로그램 테스트 프로젝트를 조정합니다.
응용 프로그램의 우선 순위를 매기기 위한 시스템 개발
인벤터리 및 우선 순위 매기기 절차 조정
테스트 방법 개발
하드웨어, 소프트웨어 및 인력을 포함한 테스트 리소스 요구 사항 결정
테스트 일정 만들기
테스트 계획 작성
테스트 추적 및 보고 시스템 디자인 또는 구매
응용 프로그램 테스트를 위한 중요성 및 전략 개선, 응용 프로그램 전문가의 도움 얻기
테스트 진행 과정을 모니터링하여 관리 부서, 내부 응용 프로그램 개발 그룹 및 외부 공급업체에게 모니터링 내용 보고
테스트 요구 조건을 만족시키지 못하는 그룹 추적
비즈니스 응용 프로그램 확인 및 우선 순위 매기기
테스트 준비 시 가장 먼저 해야 하는 일은 컴퓨터(클라이언트와 서버 모두)에서 설치된 응용 프로그램에 대한 정보를 수집하는 것입니다. 응용 프로그램 사용 여부와 사용자 수 등과 같은 수집 정보는 비즈니스에서 해당 정보의 중요도를 결정하는 데 도움이 됩니다.
응용 프로그램을 확인하면서 응용 프로그램의 우선 순위를 매기기 시작합니다. 아무리 응용 프로그램이 중요하지 않아 보여도 각 응용 프로그램을 살펴봐야 합니다. 많은 사용자가 작업을 수행하기 위해 의존하는 응용 프로그램이 제대로 기능을 수행하지 못하면 큰 영향을 주게 됩니다.
응용 프로그램 확인
아직 서버와 클라이언트 컴퓨터에 설치된 응용 프로그램의 인벤터리를 없다면 먼저 인벤터리를 만들어야 합니다. 바이러스 방역, 압축, 백업 및 원격 제어 프로그램을 포함한 작업 및 관리 도구를 포함시켜야 한다는 점을 명심하십시오.
응용 프로그램 정보 수집
조직의 규모가 크거나 분산되어 있다면 응용 프로그램 목록을 만드는 데 많이 시간이 걸릴 수 있습니다. Microsoft? Systems Management Server나 다른 소프트웨어 인벤터리 도구를 사용하여 네트워크로 연결된 컴퓨터를 관리한다면 소프트웨어 인벤터리 프로세스를 사용하여 정보를 수집한 다음 그 정보를 범주별로 나누고 보고하는 쿼리를 실행할 수 있습니다. 소프트웨어 인벤터리 작성에 Systems Management Server를 사용하는 것에 대한 자세한 내용은 이 가이드의 "Systems Management Server를 사용하여 네트워크 인프라 분석"을 참조하십시오.
컴퓨터에 설치된 응용 프로그램이 무엇인지 자동으로 알아내는 방법을 갖고 있지 않다면 정보 수집 절차를 개발해야 합니다. 예를 들어, 관리자가 자신의 비즈니스 단위에 대해 응답할 수 있도록 웹 기반 양식이나 질문서를 작성할 수 있습니다. 수동 절차에 의존해야 한다면 신속한 답변을 얻을 수 있도록 상위 관리 부서의 도움을 받아야 합니다.
응용 프로그램 목록을 합칠 때 각 비즈니스 단위에서 필요한 프로그램이 무엇인지 확인합니다. 다음 목록은 각 응용 프로그램에 대해 필요한 정보의 일부 예입니다.
응용 프로그램 이름 및 버전
공급업체 이름
현재 상태(생산 중, 개발 중, 사용되지 않음 등)
사용자 수 및 비즈니스 단위의 수
조직에 대한 우선 순위 또는 중요도
응용 프로그램을 사용하는 현재 플랫폼
응용 프로그램이 클라이언트 기반인지 또는 서버 기반인지 여부와 클라이언트와 서버에 상주하는 구성 요소를 포함시킵니다.
웹 응용 프로그램의 웹 사이트 주소(URL)
설치 요구 사항(보안 설정, 설치 디렉터리 등)
개발 유틸리티 또는 기술(내부적으로 개발된 경우)
연락처 이름 및 전화 번호(내부 및 공급업체)
같은 공급업체에 대해 여러 연락처가 있는 경우, 가능하다면 연락처들을 통합 정리합니다.
추가 정보를 수집하고 응용 프로그램의 우선 순위를 매길 때 정보를 쉽게 액세스하고 업데이트할 수 있는 중앙 저장소에 응용 프로그램 정보를 모아 둡니다. 응용 프로그램 테스트를 시작하면 테스트 결과를 입력하고 상태를 보고하기 위해 이 저장소를 사용할 수도 있습니다. 테스트 결과 추적 및 보고에 대한 자세한 내용은 이 가이드의 "테스트 결과 추적"을 참조하십시오.
응용 프로그램 환경 단순화
인벤터리 프로세스는 응용 프로그램 환경을 좀더 관리하기 쉽고 비용 효율적으로 만드는 데 도움을 주는 추가 정보를 수집하기에 좋은 때입니다. 환경이 단순할수록 응용 프로그램 호환성을 테스트하기가 쉬워지고, 응용 프로그램을 Windows 2000으로 더욱 무리 없이 옮길 수 있고, 결과적으로 환경이 관리하기 쉬워집니다.
이 절에서 설명하는 정보는 테스트를 용이하게 해줄 뿐만 아니라 향후 지원 비용도 줄여줍니다.
문제 해결 정보
응용 프로그램에 대한 상세한 정보는 테스터가 Windows 2000 테스트 시 발생한 문제를 진단하는 데 도움을 주며 기술 지원 서비스의 문제 해결 시간을 줄여줍니다.
응용 프로그램에서 하드 드라이브에 설치한 파일
각 파일의 날짜 스탬프
각 파일의 크기(바이트 단위)
파일이 설치된 위치
레지스트리 설정
응용 프로그램의 인벤터리를 작성할 때보다는 테스트 랩에서 응용 프로그램을 설치할 때 이 정보를 수집하는 것이 좋습니다. 랩처럼 통제된 환경에서 응용 프로그램을 설치하면 응용 프로그램이 사용됨에 따라 축적되는 외부 사용자 관련 파일 없이 완전한 목록을 얻을 수 있습니다.
중복된 응용 프로그램
조직에서 많은 유사한 프로그램을 사용하는 경우, 인벤터리 프로세스는 많이 사용하는 응용 프로그램들에 대한 중복 여부와 표준화를 평가할 수 있는 가장 좋은 시기입니다. 예를 들어, 조직에서 다수의 문서 편집 응용 프로그램이나 다양한 버전을 사용하고 있을 수도 있습니다. 단일 응용 프로그램과 버전으로 표준화하면 Windows 2000 테스트 과정을 크게 단순화하고 클라이언트 지원 비용을 상당히 줄일 수 있습니다. 각기 다른 팀에서 응용 프로그램 표준을 평가하고 결정할 수도 있기 때문에 적절한 응용 프로그램을 집중적으로 테스트하기 위해서는 테스트 팀이 다른 팀과 밀접하게 협력해야 합니다. 클라이언트 구성 표준화에 대한 자세한 내용은 이 가이드의 "클라이언트 관리 및 구성 표준 정의"을 참조하십시오.
인증되지 않은 응용 프로그램
응용 프로그램 목록을 모을 때 사용자가 인터넷에서 다운로드하거나 집에서 가져온 응용 프로그램과 같이 인증되지 않은 응용 프로그램을 찾을 수 있습니다. 인벤터리 프로세스를 사용하여 인증되지 않은 응용 프로그램을 제거하고 사용 중인 모든 소프트웨어에 라이센스가 있는지 확인합니다.
사이트 라이센스 응용 프로그램
인벤터리 프로세스는 압축 및 바이러스 방역 프로그램과 같은 사이트 라이센스 응용 프로그램을 확인하고 해당 프로그램의 관리 전략을 수립하기에 좋은 시기입니다. IntelliMirror™를 구현할 계획이라면 그것을 사용해 이런 응용 프로그램을 알립니다. IntelliMirror를 사용하여 응용 프로그램을 알리면 중복되는 서버를 쉽게 설치하여 응용 프로그램에 대한 사용자의 액세스를 최대화할 수 있습니다. 클라이언트 지원에 IntelliMirror를 사용하는 것에 대한 자세한 내용은 이 가이드의 "변경 및 구성 관리 적용"을 참조하십시오.
IntelliMirror를 구현할 계획이 없다면 사이트 라이센스 응용 프로그램을 위한 공유 드라이브를 설정할 수 있습니다. 서버에 \\licensed_products와 같이 기억하기 쉬운 이름을 지정여합니다.
응용 프로그램 우선 순위 매기기
응용 프로그램 목록을 모으기 전에도 응용 프로그램을 분류하고 우선 순위를 매기는 방법을 개발할 수 있습니다. 인벤터리 작업을 수행할 때 이미 개발된 스키마가 있다면 응용 프로그램을 찾으면서 분류할 수 있습니다. 다음과 같은 두 가지 이유 때문에 우선 순위 매기기 스키마가 필요합니다.
롤아웃 날짜까지 모든 응용 프로그램을 제대로 테스트할 시간이 없는 경우
배포가 진행되기 위해서 제대로 실행되어야 하는 응용 프로그램이 무엇인지 알아야 하는 경우
우선 순위 매기기 작업의 최종 목표는 Windows 2000을 배포하기 전에 제대로 작동해야 하는 핵심 응용 프로그램 그룹을 확인하는 것입니다. 우선 순위 매기기 스키마를 개발할 때는 다음 사항을 고려하십시오.
조직에 대한 응용 프로그램의 중요도
영향 받는 사용자의 수
새 버전의 사용 가능 여부
지역화 필요성
조직에 이미 사용하거나 수정할 수 있는 분류 방법이 있을 수도 있습니다. 예를 들어, 오류 복구 계획을 위해서 응용 프로그램의 우선 순위를 매겼을 수도 있습니다. 오류가 발생했을 때 먼저 다시 온라인 상태가 되어야 하는 응용 프로그램을 확인했다면 이런 응용 프로그램의 호환성 테스트 우선 순위가 가장 높게 됩니다.
우선 순위 매기기 스키마의 복잡성은 보유한 응용 프로그램 수와 응용 프로그램이 지원하는 비즈니스 기능의 다양성과 같은 요소에 따라 달라집니다.
거대한 첨단 기술 회사가 네 가지 우선 순위 수준을 개발했다고 가정해 봅시다. 이 회사는 다음과 같이 우선 순위를 정의합니다.
업무용 이 응용 프로그램은 오류가 발생한 후에 먼저 온라인 상태가 되어야 합니다. 이 응용 프로그램은 법적 의무를 완수하거나 자금 정보를 수집하는 데 필요합니다. 조직은 이러한 응용 프로그램의 오류로 인한 아주 작은 위험도 용인할 수 없으며 오류로 인한 영향이나 비용이 매우 클 것입니다.
비즈니스용 이 응용 프로그램은 오류가 발생한 후에 두 번째로 온라인 상태가 되어야 합니다. 이 응용 프로그램은 비즈니스 인프라를 실행하는 데 필요합니다. 인력 관리 응용 프로그램은 비즈니스용 응용 프로그램의 한 예입니다. 조직은 오류로 인한 위험을 거의 용인할 수 없으며 오류로 인한 영향이나 비용이 상당한 수준입니다.
필수 이 응용 프로그램은 비즈니스를 실행하는 데 필요하지만 장시간 동안 오프라인 상태로 있을 수 있습니다. 조직은 오류로 인한 적당한 수준의 위험을 용인할 수 있으며 오류로 인한 영향이나 비용이 비교적 낮습니다.
기타 이 응용 프로그램은 앞에 설명한 어떤 범주에도 들어가지 않으며 이 응용 프로그램 없어도 비즈니스를 계속 진행할 수 있습니다.
또 다른 대규모 첨단 기술 회사가 두 개의 범주(업무용과 비업무용)만 갖고 있다고 가정해 봅시다. 모든 응용 프로그램을 테스트할 충분한 시간이 없다면 이 조직은 배포를 시작하기 전에 업무용 응용 프로그램이 완전히 테스트되고 모든 문제가 해결되어 있는지 확인하고 싶을 것입니다.
응용 프로그램 테스트 계획 준비
테스트 준비의 기본 작업 중 하나는 테스트 계획을 작성하는 것입니다. 테스트 계획에서 테스트의 범위와 목적을 지정하고 사용할 방법을 설명합니다. 계획에는 다음과 같은 정보가 포함됩니다.
범위
테스트 동안 다룰 우선 순위 수준
방법
테스트 수행자와 참여 방법
요구 사항
테스트 수행에 필요한 하드웨어, 소프트웨어, 인력, 교육 및 도구
합격 기준
응용 프로그램 테스트의 성공 여부를 판별하는 요소
일정
일정이 지정된 롤아웃에 따라 테스트를 완료하는 방법
응용 프로그램 수와 테스트 접근 방식에 따라 응용 프로그램 테스트에는 조직 내의 다양한 비즈니스 단위의 협력이 요구되기도 합니다. 프로젝트 초기에 응용 프로그램 보관자를 확인하고 그들에게 테스트 계획을 검토하고 승인할 것인지 아니면 동의한 수준에서 리소스를 적용할 것인지 묻습니다.
테스트 계획 작성에 대한 자세한 내용은 이 가이드의 "Windows 2000 테스트 랩 만들기"를 참조하십시오.
테스트 범위 설정
조직에서 많은 수의 응용 프로그램을 사용한다면 모든 응용 프로그램을 원하는 수준으로 철저히 테스트할 시간이 없을 수도 있습니다. 우선 순위가 가장 높고 가장 많이 사용하는 응용 프로그램을 먼저 테스트합니다. 하지만 테스트를 이 응용 프로그램으로만 제한해서는 안됩니다.
서버 기반 응용 프로그램과 클라이언트 기반 응용 프로그램을 모두 테스트합니다. 일반적으로 클라이언트 기반 응용 프로그램은 변수가 많기 때문에 가장 테스트하기 어렵고 시간이 많이 걸립니다.
사용 중인 시판 응용 프로그램을 이미 외부 조직에서 테스트한 경우라도 사용자 환경에서 테스트해야 합니다. 환경에서 응용 프로그램을 사용할 때 제대로 작동하는 것이 Windows 2000의 기반이 되는 기술과의 호환성을 입증하는 전부는 아닙니다. 외부에서 테스트한 시판 응용 프로그램에 대한 자세한 내용은 이 장의 뒷부분에 나오는 "응용 프로그램 테스트"를 참조하십시오.
테스트 방법 정의
테스트 계획의 주요 부분은 테스트 전략을 설명하는 것입니다. 방법을 계획할 때 다음 사항을 고려합니다.
테스트 수행 장소
테스트 수행자
참여자 포함 방법 및 의사 소통 방법
테스트 일정
응용 프로그램 문제 관리 방법
외부 인력을 사용하는 것은 응용 프로그램 테스트를 위한 한 가지 방법입니다. 이 방법을 사용할 것인지 결정하려면 다음 사항을 고려합니다.
테스트에 사용할 수 있는 인력이 있는지 여부
담당자에게 전문적인 기술이 있는지 여부
외부 인력을 사용하는 비용과 내부 비용 비교
계획 일정, 외부 인력을 사용할 경우 테스트의 조기 달성 여부
보안 요구 사항, 외부 조직에 기밀 자료를 제공해야 하는지 여부
내부적으로 테스트할 때는 경험이 많은 테스터를 선택합니다. 조직에 응용 프로그램 테스터 그룹이 있다면 이러한 테스터 그룹을 사용하는 것이 좋습니다. 이러한 그룹이 없거나 사용할 수 없다면 다양한 리소스를 사용하여 적절한 시간에 최적의 결과를 얻을 수 있는 방법을 찾아야 합니다. 예를 들어, 경험이 많은 소수의 테스터에게 테스트 사례를 개발하게 하고 이러한 테스트 사례를 다른 테스터에게 교육하여 실행할 수 있습니다. 또 다른 방법으로 경험 많은 테스터가 일련의 핵심 테스트를 수행한 후 전문가가 있는 비즈니스 단위와 협력하여 전문적 지식을 테스트 랩에 적용시킬 수 있습니다.
테스트 일정을 잡고 테스터와 의사 소통을 하기 위한 절차를 고안합니다. 예를 들어, 인트라넷에서 모든 사용자가 테스트 날짜, 상태 보고서, 연락처 이름 및 기타 관련 문서를 볼 수 있도록 웹 사이트를 구축할 수도 있습니다.
테스트 결과를 관리하는 절차를 수립합니다. 다음과 같은 사항을 포함한 역할과 책임을 설명합니다.
사고 추적 시스템의 문제 보고서 입력자
문제의 우선 순위 지정, 할당 및 해결 방법
문제 해결과 응용 프로그램의 재테스트 추적자
테스트 추적 및 보고 시스템에서 테스터의 테스트 결과 입력 방법
사례 연구 1: 테스트 페스티벌
대규모 첨단 기술 회사에서 내부 개발자가 응용 프로그램이 Windows 2000과 호환되는지 테스트를 하라는 지시를 받았다고 가정합니다. 테스트 관리자는 다른 관리자와 협력하여 자신의 팀으로부터 도움을 얻었습니다. 테스트 관리자는 CIO에게 보고를 하고 프로그램에 필요한 모든 지원을 얻게 되었기 때문에 활발한 참여를 유도하기가 쉬웠습니다. 테스트 관리자는 랩 테스트 세션 일정을 잡고 개발자에게 세션에 대해 통보했습니다. 랩은 테스터가 원하는 응용 프로그램을 설치할 준비가 된 상태로 미리 구성된 컴퓨터가 설치되었습니다. 테스터는 CD나 네트워크에서 원하는 응용 프로그램을 설치할 수 있었습니다. 이벤트를 흥미롭게 하기 위해서 테스트 관리자가 다과를 제공하였기 때문에 세션은 "테스트 페스티벌"이라는 이름을 얻게 되었습니다.
사례 연구 2: 미리 보기 프로그램
주요한 제조 회사는 Windows 2000 Professional을 테스트하기 위해 미리 보기 프로그램을 개발했습니다. 이 프로그램을 사용하여 클라이언트 기반 응용 프로그램을 테스트하였습니다. 이 회사는 먼저 Windows 2000 클라이언트 컴퓨터에서 사용될 프로토콜 스택이 Windows NT 4.0 프로덕션 환경과 호환되는지 확인하였습니다. 그런 다음 응용 프로그램을 테스트할 장소를 만들기 위해 프로덕션 네트워크의 제한된 장소에 Windows 2000 Professional을 배포했습니다.
프로젝트 팀은 프로그램에 대한 정보로 웹 사이트를 구축했습니다. 사용자는 미리 보기 프로그램에 참가하기 위해 웹 사이트에 있는 응용 프로그램 양식에 정보를 입력했습니다. 참가자 수를 제한하고 철저한 테스트를 보장하기 위해서 프로젝트 책임자와 인사 부장은 신청자를 검토하고 승인하였습니다. 참가자 수가 50-100명으로 제한된 프로그램은 응용 프로그램을 테스트하기 위해서 다양한 범위의 테스터를 제공하였습니다. 테스터는 자신의 문제 보고서를 웹 사이트에 게시했습니다.
리소스 요구 사항 확인
응용 프로그램 호환성 테스트를 계획할 때 컴퓨팅 환경의 향후 상태를 염두에 두어야 합니다. 일부 소프트웨어를 새로운 Windows 2000 기능을 완전히 사용하는 버전으로 업그레이드를 할 계획입니까? 새로운 표준 데스크톱 구성을 구현하거나 터미널 서비스를 사용할 계획입니까? 이와 같은 문제는 하나의 제품군으로 테스트되어야 하는 응용 프로그램과 필요한 리소스를 결정합니다.
룰아웃 도중에 Windows 2000과 함께 새로운 응용 프로그램을 배포할 계획이라면 현재 응용 프로그램과 함께 그러한 응용 프로그램을 테스트합니다.
테스터가 테스트를 수행할 수 있는 랩을 구축하여 테스트를 용이하게 할 수 있습니다. 이런 랩에서는 필요한 도구와 장비를 언제나 사용할 수 있습니다. 일부 조직은 Windows 2000 랩과는 별도로 응용 프로그램 테스트 랩을 갖추고 있습니다. 랩을 분리할 예산이 없다면 다른 프로젝트나 교육과 랩을 공유해야 할 것입니다. 랩을 공유한다면 일정과 필요한 장비가 다른 사용자와 겹치지 않도록 해야 합니다.
테스터가 원하는 응용 프로그램을 설치하고 테스트하는 데 필요한 모드를 신속히 액세스할 수 있도록 랩의 컴퓨터를 다중 부팅을 지원하도록 설정합니다. 예를 들어, 이 장의 뒷부분에 나오는 "응용 프로그램 테스트" 절에서 제시한 사항을 따른다면 업그레이드 경로를 통해 응용 프로그램을 테스트하기 위해 Windows NT 4.0과 Windows 2000이 필요합니다. 테스터가 쉽게 이전 상태로 컴퓨터를 복원시킬 수 있게 하려면 기본 운영 체제가 있는 드라이브의 디스크 이미지를 만듭니다.
회사 네트워크에 랩을 연결해야 하는지 여부를 고려하십시오. 예를 들어, 웹 기반 테스트 추적 시스템을 개발한다면 네트워크에서 또는 회사 인트라넷으로 응용 프로그램을 설치하기 위해 네트워크 공유에 액세스해야 합니다. 이러한 액세스가 필요한 경우에는 먼저 클라이언트 컴퓨터가 사용하는 프로토콜 스택이 프로덕션 네트워크와 호환되는지 확인합니다.
테스트 랩이 큰 경우, 랩 관리자를 지정할 수 있습니다. 랩을 운영하는 기술과 테스트를 관리하는 데 필요한 기술은 매우 다르기 때문에 두 가지 역할에 대해서 각기 다른 사람을 선택하는 것이 좋습니다. 랩 관리자가 뛰어난 기술적 능력을 갖고 있어야 하는 반면 테스트 관리자는 뛰어난 관리 능력과 의사 소통 능력을 갖추어야 합니다.
테스트 랩 디자인 및 관리에 대한 내용이나 테스트 계획 작성에 대한 자세한 내용은 이 가이드의 "Windows 2000 테스트 랩 만들기"를 참조하십시오.
합격-불합격 기준 정의
테스터가 다양한 테스트를 수행하게 되면 테스트를 통과하는 응용 프로그램과 그렇지 못한 응용 프로그램이 생기게 됩니다. 따라서 해결해야 할 응용 프로그램 문제와 쟁점을 로그할 수 있는 장소와 시기를 참가자가 알 수 있도록 정의된 절차가 있어야 합니다.
테스터가 특정 응용 프로그램에 대한 테스트를 완료하게 되면 테스트 추적 및 보고 시스템에 그 결과를 입력해야 합니다. 물론 모든 미해결 문제의 우선 순위를 매기고 추적한 다음 문제가 해결되면 응용 프로그램을 다시 테스트해야 합니다. 그러나 테스트 과정을 추적하려면 이미 준비되어 있는 응용 프로그램과 준비되어 있지 않은 응용 프로그램을 알고 싶을 것입니다. 응용 프로그램의 테스트 통과 여부에 따라 진행 과정을 추적할 계획이라면 사용할 각 범주에 대한 기준을 정의해야 합니다. 테스트 통과 여부의 기준을 정의하려면 다음 사항을 고려합니다.
문제의 심각성, 주요 기능이나 주변 장치에 영향을 주는지 여부
문제를 발견한 과정
문제를 피할 수 있는 방법이 있는지 여부
테스트 일정 작성
테스트 일정은 다음과 같은 많은 조건에 영향을 받습니다.
참가하는 테스터의 수
테스터가 이 프로젝트에서 상근직으로 근무하는지 아니면 시간제로 근무하는지 여부
테스터의 경험 수준
응용 프로그램의 수와 복잡성
일정에는 문제를 해결하고 불합격한 응용 프로그램을 다시 테스트할 수 있는 충분한 시간을 고려해야 합니다. 일정에 따라 진행되고 있는지 진행 과정을 모니터링하고 확인할 수 있도록 중요한 중간 일정을 설정합니다.
응용 프로그램 테스트
Microsoft는 고객 및 독립적인 소프트웨어 공급업체(ISV)와 협력하여 Windows 2000 Application Specification을 개발했습니다. 이 사양에 따라 작성된 응용 프로그램은 Windows 2000과 호환될 뿐만 아니라 Windows 2000에서 제공하는 새로운 기술을 이용할 수 있습니다.
Windows 2000 Application Specification은 MSDN(Microsoft Developer Network) 웹 사이트에서 다운로드할 수 있으며 데스크톱 응용 프로그램용과 분산 응용 프로그램용의 두 구성 요소가 있습니다. 데스크톱 응용 프로그램 사양은 Windows 2000 Professional에서 독립 실행형 프로그램이나 분산 응용 프로그램의 클라이언트 부분으로 실행되는 응용 프로그램에 적용됩니다. 분산 응용 프로그램 사양은 Windows 2000 Server에서 실행되는 응용 프로그램에 적용됩니다. 사양과 복사본 다운로드에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Windows 2000 Application Specification 링크를 참조하십시오.
또한 Windows 2000 Application Specification과 일치하는 시판 응용 프로그램은 인증될 수 있습니다. 인증된 응용 프로그램은 독립적인 테스트 기관에서 테스트되며 일정 요구 사항을 만족시킵니다. 예를 들어, 인증서를 받으려면 응용 프로그램에서 Windows Installer를 사용해야 합니다. 시판 응용 프로그램은 인증되지 않은 사양을 따를 수 있습니다. 이런 경우 응용 프로그램은 독립적인 테스트 기관이 아니라 공급업체에서 테스트합니다.
일부 조직에서는 Windows 2000 배포 프로젝트의 일부로 사양 요건의 충족 여부를 응용 프로그램을 구입 시의 선택 기준으로 삼았습니다. 응용 프로그램을 내부적으로 개발한 경우, 응용 프로그램 개발 지침에 사양을 추가하는 것이 좋습니다.
그 동안에 많은 시판 응용 프로그램이 이미 Windows 2000 지원 여부에 대한 테스트를 거쳤습니다. Microsoft는 여러분이 사용하는 응용 프로그램의 상태를 살펴볼 수 있도록 Windows 2000 응용 프로그램의 디렉터리를 제공합니다. Windows 2000을 지원하는 클라이언트 기반 제품이나 서버 기반 제품에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources))에서 Directory of Windows 2000 Application 링크를 참조하십시오.
디렉터리는 다음과 같은 명칭을 사용합니다.
Certified 응용 프로그램이 독립적인 테스트 기관에 의해 테스트되었고 새로운 Windows 2000 기능을 이용한다는 것을 나타냅니다.
Ready 공급업체에 따라 응용 프로그램의 Windows 2000 호환성과 지원 여부가 테스트되었음을 나타냅니다. 응용 프로그램이 새로운 Windows 2000 기능을 이용할 필요는 없습니다.
Planned 응용 프로그램이 완전히 테스트되면 Certified 또는 Ready 기준에 적합한 응용 프로그램이라는 것을 나타냅니다.
테스트 전략 개발
응용 프로그램 테스트의 목적은 현재 플랫폼에서 작동하는 모든 것이 Windows 2000에서도 작동하는지 확인하는 것입니다. 응용 프로그램이 이전 버전의 Windows용으로 작성된 경우, 반드시 새로운 Windows 2000 기능을 최대한으로 사용하는 것은 아닙니다. 하지만 그 기능은 현재 플랫폼뿐만 아니라 Windows 2000에서도 작동해야 합니다.
시판 응용 프로그램을 위한 전략
시판 응용 프로그램의 경우, 먼저 업그레이드만 확인 모드에서 Windows 2000 Professional 설치 프로그램을 실행하여 잠재적 비호환성을 검사해야 합니다. 이 모드에서 설치 프로그램을 실행하면 설치 프로그램은 호환되지 않는 것으로 알려진 응용 프로그램 목록에서 설치된 소프트웨어를 검사하고 찾아낸 것을 기록합니다. 업그레이드만 확인 모드의 명령줄 구문은 다음과 같습니다.
winnt32 /checkupgradeonly
이 유틸리티가 잠재적 호환성 문제에 대해서 경고를 할 수 있기는 하지만 이것은 컴퓨터에 설치된 응용 프로그램과 소수의 응용 프로그램만을 다룹니다. 응용 프로그램이 호환되지 않는 응용 프로그램 목록에 없다고 해서 해당 응용 프로그램이 호환될 수 있다는 것을 의미하는 것은 아닙니다. 설치 프로그램에 대한 자세한 내용은 이 가이드의 "클라이언트 설치 및 업그레이드 자동화"를 참조하십시오.
다음 단계는 Windows 2000 응용 프로그램의 디렉터리를 확인하여 사용하는 응용 프로그램의 호환성을 알아보는 것입니다.
응용 프로그램의 일부가 이미 테스트를 받았다는 것을 알게 된다고 해도 여러분의 환경에서 응용 프로그램을 테스트해야 합니다. 이 경우, 조직에서 응용 프로그램을 사용하는 방식에 초점을 맞춰 테스트를 할 수 있습니다. 예를 들어, 다음을 테스트하십시오.
조직에서 사용하는 구성
가장 많이 사용하는 기능
함께 사용되는 응용 프로그램의 조합
이 장의 뒷부분에 나오는 "테스트 팁" 절에서 응용 프로그램 기능을 테스트하는 몇 가지 방법을 제공합니다. 다른 조직에서 호환성을 테스트하지 않은 시판 응용 프로그램을 사용한다면 더욱 광범위하게 테스트해야 합니다.
바이러스 방역 소프트웨어를 테스트해야 한다는 점을 기억하시기 바랍니다. 이러한 응용 프로그램의 대부분은 파일 시스템 필터를 사용하기 때문에 업데이트가 필요합니다. 많은 Windows NT 4.0 파일 시스템 필터는 NTFS 파일 시스템의 변경으로 인하여 Windows 2000에서 작동하지 않을 수도 있습니다.
사용자 정의 응용 프로그램을 위한 전략
사용자 정의된 다른 공급업체 제품을 사용하거나 내부적으로 응용 프로그램을 개발하는 경우, 사전에 테스트된 시판 응용 프로그램의 테스트 전략보다 좀더 광범위한 테스트 전략을 수립해야 합니다.
자체 개발하지 않은 응용 프로그램을 테스트하는 경우에도 Windows 2000 Application Specification은 테스트에 대한 자세한 내용을 제공합니다. MSDN 웹 사이트는 다운로드할 수 있는 형태의 사양 뿐만 아니라 Windows 2000 Application 인증을 위한 Microsoft 테스트의 모든 세부 테스트 계획을 포함합니다. 이 테스트 계획은 기능적인 영역과 테스트 방식에 대한 개념을 제공해 줄 수 있습니다. 사양이나 테스트 계획을 다운로드하는 방법에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Application Specification Download 링크를 참조하십시오.
MSDN 웹 사이트에는 독립적인 테스트 기관에서 공급업체가 인증을 위해 제출한 응용 프로그램의 기능을 테스트하기 위해 사용하는 검사 테스트와 방법에 대한 백서와 같은 다른 중요한 정보가 있습니다.
테스트 팁
이 절의 테스트 제안은 포괄적인 것이 아니며 모든 경우에 적용되지 않습니다. 이것은 테스트 방법을 작성하는 데 도움을 주기 위한 것입니다.
배포 시나리오 테스트
배포 동안 사용할 예정인 시나리오를 통해 응용 프로그램 설치와 실행을 테스트해야 합니다. 예를 들어, 새로 설치로 배포하거나 Windows 3.x 또는 Windows NT의 이전 버전에서 업그레이드를 하여 배포하는 계획을 수립할 수도 있습니다. 업그레이드를 할 계획이라면 업그레이드 동안 응용 프로그램을 컴퓨터에 유지하거나 응용 프로그램을 제거하고 업그레이드 한 다음 다시 설치할 수도 있습니다.
IntelliMirror 소프트웨어 설치 및 관리로 응용 프로그램을 관리할 수 있도록 Windows Installer용이나 .zap 파일로 응용 프로그램을 다시 패키지하는 것을 고려합니다. 응용 프로그램 패키지에 대한 자세한 내용은 이 가이드의 "변경 및 구성 관리 적용"을 참조하십시오.
Windows 3.x와 Windows 2000 사이에는 차이가 있기 때문에 일부 응용 프로그램 설치는 설치에 사용한 운영 체제에 따라 다르게 작동합니다. 예를 들어, Windows 3.x를 실행하는 컴퓨터에서 응용 프로그램을 설치하고 나서 컴퓨터를 Windows 2000으로 업그레이드하면 응용 프로그램을 Windows 2000에 설치했을 때와 똑같이 작동하지 않을 수도 있습니다. 이런 경우, 응용 프로그램을 제거하고 업그레이드가 된 후나 마이그레이션 동적 링크 라이브러리(DLL)를 구한 후에 다시 설치해야 합니다.
마이그레이션 DLL은 원래 Windows 3.x에 설치된 응용 프로그램이 컴퓨터를 Windows 2000으로 업그레이드한 이후에 제대로 실행될 수 있도록 해줍니다. 마이그레이션 DLL은 다음과 같은 조치를 통해 응용 프로그램 문제를 해결할 수 있습니다.
Windows 3.x 관련 파일을 Windows 2000 호환 파일로 대체 또는 업그레이드
응용 프로그램 및 사용자 설정을 Windows 2000의 올바른 위치로 매핑
Windows 3.x 관련 레지스트리 키를 적절한 Windows 2000 위치로 매핑
내부적으로 개발된 응용 프로그램의 경우, 마이그레이션 DLL을 만들거나 공급업체로부터 이 DLL을 구해야 할 것입니다. "migration DLL"이라는 키워드를 사용하여 MSDN Library를 검색하면 마이그레이션 DLL 만들기와 테스트에 대한 자세한 내용을 찾을 수 있습니다. MSDN Library에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 MSDN 링크를 참조하십시오. 또한 일부 마이그레이션 DLL은 Windows 2000에 포함됩니다.
결과는 업그레이드 방법에 따라 달라질 수 있기 때문에 롤아웃 동안 사용할 것과 같은 절차와 도구를 사용하여 테스트를 하는 것이 중요합니다. 응용 프로그램을 테스트할 때 절차와 도구가 아직 준비되지 않았다면 최소한 사용할 시나리오를 테스트해야 합니다.
업그레이드 시나리오
컴퓨터를 업그레이드할 계획이라면 다음 단계를 사용합니다.
Windows 3.x 또는 Windows NT 3.51 또는 그 이후 버전 설치
응용 프로그램 설치
Windows 2000으로 업그레이드
응용 프로그램 테스트
Windows 3.x 응용 프로그램이 제대로 작동하지 않으면 ISV에게 마이그레이션 DLL에 대해서 문의합니다. Windows NT 응용 프로그램이 제대로 작동하지 않으면 ISV에게 패치 또는 새로운 설치 프로그램에 대해서 문의하십시오.
새로 설치 시나리오
Windows 2000을 다시 포맷된 컴퓨터에 설치할 계획이라면 다음 단계를 사용합니다.
Windows 2000 설치
응용 프로그램 설치
응용 프로그램 테스트
응용 프로그램이 제대로 작동하지 않으면 ISV에게 패치 또는 새로운 설치 프로그램에 대해서 문의하십시오.
설치 및 제거 테스트
다양한 방법으로 응용 프로그램의 설치를 테스트해야 합니다.
완료 전에 설치를 중지합니다.
환경에서 모든 설치 옵션을 사용해 봅니다.
조직에서 사용자가 응용 프로그램을 설치할 수 있도록 허용하는 경우, 관리자와 고급 사용자 모두로 설치를 테스트합니다. 그런 다음 응용 프로그램의 기능을 테스트합니다.
응용 프로그램의 설치를 제거해 봅니다.
응용 프로그램이 관리자에 의해서 설치되고 사용자에 의해서 설치가 제거될 수 있는지 확인합니다. 사용자가 사용자로 로그온하면 설치 제거가 완료되거나 활성화되지 않아야 합니다.
기본 응용 프로그램 기능 테스트
비즈니스 작업을 달성하기 위해 사용하는 기능, 구성 및 응용 프로그램 제품군을 사용하여 응용 프로그램을 테스트합니다. 예를 들어, 다음과 같은 종류의 테스트를 시도해 볼 수 있습니다.
사용자로서 로그온하고 최종 사용자에게 가장 중요한 기능을 테스트합니다. 비즈니스 작업을 수행하는 데 필요한 특수한 시나리오를 테스트합니다.
사용자 그룹의 구성원인 여러 사용자로 로그온합니다.
응용 프로그램과 시스템에 그룹 정책을 적용합니다.
표준 데스크톱 구성과 같은 응용 프로그램 조합을 테스트합니다.
종료를 하지 않고 몇 일 또는 몇 주 동안 몇 개의 응용 프로그램을 데스크톱에서 실행합니다.
Microsoft? Office 응용 프로그램에서 Microsoft? Visual Basic? for Application(VBA)을 사용하는 자동화 작업을 테스트합니다.
긴 파일 이름이 일관성 있게 지원되는지 테스트합니다. 마침표를 포함시키고 앞에 있는 공백이 삭제되는지 확인합니다.
1MB 이상의 큰 그래픽 파일을 조작합니다.
워드 프로세싱 문서에서 광범위한 편집 작업을 수행합니다.
편집, 컴파일, 편집, 컴파일의 순서로 RAD를 수행합니다.
OLE 사용자 정의 컨트롤(OCX)을 테스트합니다.
스캐너와 플러그 앤 플레이 장치와 같은 적용 가능한 하드웨어를 테스트합니다.
터미널 서비스를 배포할 계획이라면 터미널 서비스 서버에서 응용 프로그램을 테스트합니다. 사용자 특정 설정으로 동일한 응용 프로그램을 실행하는 다중 사용자와 다른 응용 프로그램을 실행하는 다중 사용자를 테스트합니다.
예제 테스트 계획을 다운로드하려면 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Application Specification Download 링크를 참조하십시오.
데이터 액세스
다음과 같은 다양한 방식으로 데이터를 액세스해 보십시오.
현재 버전의 Windows를 실행하는 서버 뿐만 아니라 Windows 2000을 실행하는 서버에서 데이터를 액세스합니다.
레코드의 동시 발생적인 액세스와 업데이트를 포함한 데이터베이스의 동시 사용을 테스트합니다.
복잡한 쿼리를 실행합니다.
인쇄 테스트
다음과 같이 다양한 문서 종류를 다양한 프린터로 인쇄합니다.
몇몇 원본 응용 프로그램에서 포함된 파일이 있는 문서를 인쇄합니다.
긴 파일 이름을 가진 프린터로 인쇄합니다.
테스트 도구 사용
Windows 2000 Software Development Kit(SDK), Driver Development Kit(DDK) 및 Microsoft? Windows? 2000 Server Resource Kit에는 응용 프로그램을 테스트하고 디버깅하는 도구가 들어 있습니다.
Windows 2000 Server Resource Kit에 있는 Dependency Walker는 응용 프로그램에서 요구하는 종속 모듈을 재귀적으로 검색합니다. 이 유틸리티는 손실된 파일, 유효하지 않은 파일, 가져오기 또는 내보내기 불일치, 원형 종속 오류, 불일치된 컴퓨터에 설치되어 있는 모듈 등을 검색합니다. 이 유틸리티에 대한 자세한 내용은 함께 들어 있는 도움말 파일을 참조하십시오.
Windows 2000 Server Resource Kit에 있는 Apimon은 모든 응용 프로그램 프로그래밍 인터페이스(API) 호출에 대한 카운트와 타이밍을 통해 실행중인 응용 프로그램을 모니터링합니다. 선택적으로 페이지 오류를 모니터링할 수도 있습니다. Apimon은 다음과 같은 사항을 보고할 수 있습니다.
모든 API 호출의 카운트 및 각 호출에 대한 타이밍
호출이 이루어지는 순서로 API 호출 추적
일반적인 호환성 문제
Windows 2000의 새로운 기술은 Windows의 이전 버전용으로 개발된 응용 프로그램에서 오류를 발생시킬 수 있습니다. MSDN 웹 사이트에서 찾을 수 있는 Windows 2000 Compatibility Guide에는 응용 프로그램에서 문제를 일으킬 수 있는 많은 변경 사항에 대한 자세한 설명이 나옵니다. 이 가이드는 호환 문제를 다음과 같은 네 가지 영역으로 나누고 있습니다.
설정 및 설치
일반적인 Windows 2000 호환성
응용 프로그램 안정성
Windows 플랫폼
이 절에서는 응용 프로그램에서 가장 많은 문제를 일으키는 Windows 2000의 몇 가지 변경 사항을 다룹니다. Windows의 이전 버전용으로 개발된 응용 프로그램은 Active Directory나 IntelliMirror와 같은 새로운 기능을 완전히 이용하지 않을 수도 있습니다. 이 절에서는 응용 프로그램이 이러한 새 기능을 사용하지 않을 때 발생하는 문제는 다루지 않습니다.
다음과 같은 영역에서 문제가 발생할 수 있습니다.
시스템 파일 보호
Windows의 초기 버전에서 응용 프로그램은 설치 도중에 공유 시스템 파일을 대체할 수 있었습니다. 이러한 변경이 발생하면 사용자는 프로그램 오류에서 불안정한 운영 체제에 이르기까지 다양한 문제를 자주 경험하게 되었습니다.
시스템 파일 보호(SFP)는 Windows 2000의 새로운 기능으로 응용 프로그램이 시스템 파일을 바꾸지 못하게 해줍니다. 이 기능은 보호된 시스템 파일이 올바른 Microsoft 버전인지 확인합니다. 파일이 잘못된 버전으로 바뀌면 Windows 2000은 올바른 버전을 복원합니다.
강력한 힙 검사
Windows 2000은 몇 가지 성능이 개선된 힙 관리자를 포함합니다. 이전에 힙 관리를 올바르게 사용하지 않았던 응용 프로그램들은 이제 메모리 관리에 문제가 발생할 수 있습니다. 공통적인 문제는 해제된 메모리를 계속 사용하는 것과 메모리가 더 작은 크기로 다시 할당된 경우에도 메모리가 이동되지 않았다고 가정하는 것입니다.
하드웨어 장치 열거
지원되는 하드웨어 장치 목록이 변경되면 지원되지 않는 장치를 사용하는 응용 프로그램에 문제가 발생할 수 있습니다.
글꼴 열거
글꼴 목록이 변경되었습니다. 국제화를 지원하기 위한 레지스트리 키가 추가되었기 때문에 몇몇 응용 프로그램에서는 글꼴이 여러 개 표시될 수도 있습니다.
변경된 레지스트리 키
몇몇 레지스트리 키가 이동되거나 삭제되었습니다. Win32 응용 프로그램 프로그래밍 인터페이스(API)를 사용하여 레지스트리 키를 변경하는 응용 프로그램은 문제가 없지만 레지스트리에 직접 쓰기를 한다면 문제가 발생할 수 있습니다.
버전 검사
버전을 제대로 검사하지 못하는 설치 응용 프로그램은 문제가 있게 됩니다. 응용 프로그램이 특정 운영 체제나 버전에 의존하지 않는 한 응용 프로그램에서 요구하는 최소한의 운영 체제 버전을 검사하고 그 버전이나 그 이후 버전에서 설치를 해야 합니다.
Windows 메시징 서비스
Windows 메시징 서비스(WMS)를 운영 체제에서 제공하기를 기대하는 응용 프로그램은 이 서비스를 찾지 못합니다. 이 서비스를 Windows Update 웹 사이트에서 구해야 합니다.
파일 입출력 보안
Windows 2000에는 파일 입출력에 대한 강력한 보안 기능이 있습니다. 바이러스 방역 프로그램과 같이 파일 필터를 사용하는 응용 프로그램은 Windows 2000에서 중요한 기능이 손상될 수도 있습니다.
테스트 결과 추적
응용 프로그램 비호환성을 발견할 때 이 응용 프로그램 비호환성을 입력하는 기존의 사건 추적 시스템을 갖고 있다고 해도 응용 프로그램 테스트의 상태를 추적할 수 있는 별도의 방법이 필요합니다. 테스트를 통과한 응용 프로그램, 통과하지 못한 응용 프로그램 및 테스트되지 않은 응용 프로그램과 같은 정보를 찾을 수 있어야 합니다.
필요할 때 보고서를 만들 수 있도록 테스트 결과를 쉽고 정확하게 변환하는 방법을 고려해야 합니다. 방법을 계획할 때는 다음 사항을 고려합니다.
데이터 캡처 메커니즘
캡처될 데이터의 범주
추적 시스템 선택
데이터 캡처용으로 선택하는 메커니즘은 테스트 노력, 예산, 사용 가능한 전문가의 규모에 따라 달라집니다. 테스트 추적 및 보고 시스템을 구입할 수도 있습니다. 많은 공급업체에서 이런 용도의 제품을 판매합니다. 이러한 제품을 판매하는 공급업체에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Test Tracking Systems 링크를 참조하십시오. 또 다른 방법으로 다음과 같은 키워드를 사용하여 웹 사이트에서 검색을 수행합니다.
"소프트웨어 테스트 도구"
"테스트 관리 도구"
"자동 테스트 도구"
"테스트 도구"
결정을 하기 전에 옵션을 조사하고 시판 솔루션 비용과 자체 개발 비용을 비교합니다.
자체 시스템을 개발하기로 했다면 테스트 결과를 스프레드시트나 워드 프로세싱 문서 대신 데이터베이스로 변환하는 것이 좋습니다. 데이터베이스는 보고서 작성 시 가장 큰 유연성을 제공하며 데이터의 양이 증가해도 관리하기가 쉽습니다. 웹 프런트 엔드는 데이터 입력 및 상태 보기 모두에 대해서 손쉬운 액세스를 제공합니다.
자동화 온라인 솔루션의 장점은 결과를 쉽게 기록하고 보고서를 작성할 수 있다는 것입니다. 단점은 개발 시간 및 비용이 많이 든다는 것입니다. 액세스가 불가능하고 제때에 정확한 보고서를 만들기 어렵다는 주된 단점으로 인하여 용지 기반 시스템은 권장되지 않습니다.
개발할 것인지 구매할 것인지 여부에 따라 사용하려고 결정한 메커니즘은 다음과 같은 기준을 만족시켜야 합니다.
쉽고 정확한 데이터 입력
데이터를 입력하거나 보는 모든 사용자의 손쉬운 액세스
보관을 위한 쉬운 백업 또는 복제
다양한 보고서를 위한 데이터의 쉬운 선택 및 정렬
많은 양의 데이터 처리 가능
동시 발생적인 다중 사용자 처리 가능
변경으로부터 기존의 항목 보호
테스터는 테스트를 완료하는 동안 데이터를 기록하기 위해서 간단하면서도 손쉽게 기억될 수 있는 프로세스를 요구합니다. 테스트 컴퓨터에서 응용 프로그램이나 웹 사이트에 대한 링크를 갖고 싶을 수도 있습니다.
인트라넷에서 웹 사이트를 개발하여 데이터를 수집하는 경우, 사이트를 테스트 통신 센터로 사용할 수 있습니다. 여기에는 상태 보고서, 연락처 이름, 테스트 일정표, 관련 정보 링크 및 기타 관련 문서가 포함됩니다.
데이터 수집 메커니즘을 구축하려면 다음과 같은 항목을 개발하기 위한 리소스가 필요합니다.
데이터 입력 응용 프로그램을 위한 웹 또는 일부 다른 응용 프로그램 코드
데이터베이스 및 스키마
보고서 및 쿼리
보안(필요한 경우)
데이터 캡처
일단 데이터 수집 방법을 결정하고 나면 수집할 데이터를 결정해야 합니다. 필요한 데이터를 미리 결정하는 데 시간을 투자하는 것이 좋다는 것을 알게 될 것입니다. 처음부터 데이터가 수집된 경우, 필요에 따라 새로운 보고서를 디자인할 수 있습니다.
응용 프로그램의 인벤터리를 작성할 때 필요한 정보의 대부분을 수집하게 됩니다. 또한 각각의 응용 프로그램에 대해서 다음과 같은 정보가 필요할 것입니다.
테스터의 이름과 비즈니스 단위
개발자의 이름과 비즈니스 단위(내부적으로 개발된 경우)
Windows 2000 제품명(Server 또는 Professional)
테스트 결과는 다음과 같습니다.
합격
불합격
진행 중
알 수 없음
사고 추적 시스템에 입력된 각 문제에 할당된 번호
설명
각 레코드에 대한 날짜 및 시간 스탬프
날짜/시간 스탬프는 특정 시간 범위에 대한 보고서를 만들 때 유용한 필터를 제공합니다.
결과 보고
수집할 데이터를 신중하게 분석할수록 보고서 작성에 더욱 큰 유연성을 갖게 됩니다. 다음에 제시되는 사항은 도움이 될 예제 보고서입니다.
호환성 테스트에 불합격한 응용 프로그램 목록
이 보고서는 문제를 해결하고 응용 프로그램을 다시 테스트하기 위해 추적 방식을 요구합니다.
각 비즈니스 단위에 대해서 각 우선 순위 수준에 대한 응용 프로그램의 총 수
각 비즈니스 단위에 대해서 테스트되지 않은 응용 프로그램의 총 수
테스트되지 않은 응용 프로그램의 비율(백분율)을 포함시킵니다. 이 보고서를 사용하여 과정을 수행 중인 테스트와 그렇지 못한 테스터를 추적할 수 있습니다. 테스트에서 뒤쳐져 있는 그룹에게 이 보고서를 일종의 인센티브로 사용할 수 있다는 점을 간과해서는 안됩니다.
응용 프로그램의 합격 또는 불합격 여부에 따라 진행 상황을 보고하는 경우, 상대적 진행 상황을 나타내야 하는지 아니면 실제 수치를 나타내야 하는지 고려합니다. 색상 구성표나 그래픽과 같은 확장 기능으로 상대적 진행 상황을 나타낼 수 있습니다. 이렇게 하면 잘못 이해될 수 있는 숫자를 나타내지 않고도 진행 상황을 제공할 수 있습니다. 실제 숫자로 진행 상황을 나타내야 하는 경우, 응용 프로그램의 우선 순위를 토대로 하여 수치를 보고하거나 비중을 매길 방법을 만들고 싶을 수도 있습니다. 예를 들어, 10개의 응용 프로그램만 합격하고 하나가 불합격했다고 알려주는 보고서는 정확한 상태를 나타내지 않을 수도 있습니다. 10개의 응용 프로그램이 소수의 사용자들이 가끔씩 사용하는 특수한 유틸리티이고 불합격한 하나의 응용 프로그램이 일상 업무를 수행하는 데 필요한 중요 응용 프로그램인 경우, 보고서는 완전한 설명을 제공하지 않는 것입니다.
테스터가 웹 사이트와 같은 특정 장소에 문제를 게시한 경우, 미해결 문제와 완결된 문제의 보고서를 제공할 수도 있습니다.
각 테스트 이벤트 후에 그리고 필요에 따라 정기적으로 관리 및 테스트 참가자에 대한 보고서를 작성하고 배포합니다. 테스트 프로젝트를 위한 웹 사이트가 있다면 온라인 보고서를 실행하는 기능을 포함시킬 수 있습니다.
응용 프로그램 비호환성 해결
응용 프로그램 문제를 발견하면 응용 프로그램의 우선 순위를 매긴 다음 문제를 해결할 담당자를 지정해야 합니다. 문제를 할당하는 방법에 대한 계획이 있어야 합니다. 예를 들어, 시판 응용 프로그램 관련 문제는 내부적으로 개발한 응용 프로그램과는 다르게 처리됩니다. 문제 연구 및 해결에 적합한 인력을 구축하는 것은 응용 프로그램 테스트의 성공을 위해 중요합니다. 문제 해결에는 다음과 같은 다양한 활동이 포함될 수 있습니다.
알려진 문제 및 해결책에 대한 웹 사이트 조사
패치, 설치 프로그램 또는 마이그레이션 DLL에 대해 공급업체에게 문의
Microsoft 제품 지원 서비스 문의
내부적으로 개발된 응용 프로그램 디버깅
문제의 원인을 조사할 때 다양한 접근 방식을 고려하여 가장 효과적인 솔루션을 결정해야 합니다. 예를 들어, 다음과 같은 방법을 선택할 수 있습니다.
응용 프로그램을 개발한 경우 문제 수정
응용 프로그램을 구입한 경우 공급업체로 문제 수정 요청
응용 프로그램을 새로운 버전 또는 다른 응용 프로그램으로 대체
문제를 해결할 수 있는 방법이 있는 경우에는 오류 무시
문제를 Windows 2000 호환성 문제로 다루기 전에 항상 현재 플랫폼에 문제가 발생하지 않는지 확인해야 합니다. Windows 2000 호환성 문제에 대한 몇 가지 연구 자료는 다음과 같습니다.
Windows 2000 Application Specification
사양 다운로드 방법에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Application Specification Download 링크를 참조하십시오.
Windows 2000 Compatibility Guide
이 가이드는 MSDN과 Technet에서 사용할 수 있으며 호환성 문제 진단에 대한 가치 있는 정보가 들어 있습니다.
Microsoft Technet
이 리소스는 제품 업데이트, 백서 및 기타 기술 자료를 포함합니다. Technet에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)의 Technet 링크를 참조하십시오.
Directory of Windows 2000 Applications
이것은 지원 정보 및 공급업체 웹 사이트에 대한 링크를 포함합니다. 디렉터리에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)의 Directory of Windows 2000 Application 링크를 참조하십시오.
응용 프로그램 테스트를 위한 계획 수립 작업 목록
표 21.1은 응용 프로그램의 Windows 2000 호환성을 테스트하고 계획을 수립할 때 수행해야 하는 작업을 요약한 것입니다.
표 21.1 응용 프로그램 테스트를 위한 계획 수립 작업 목록 작업
참조할 항목
비즈니스 작업에 사용되는 응용 프로그램 인벤터리 작성 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
사용하는 응용 프로그램의 수를 줄이고 데스크톱 표준 개발 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
응용 프로그램 우선 순위 매기기를 위한 시스템 개발 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
비즈니스 수행에 중요한 순서로 응용 프로그램 우선 순위 매기기 비즈니스 응용 프로그램 확인 및 우선 순위 매기기
테스트 방법, 랩 및 테스트 리소스 요구 사항, 일정을 포함한 테스트 계획 작성 응용 프로그램 테스트 계획 준비
테스트 결과 캡처 및 보고를 위한 테스트 추적 시스템 개발 테스트 결과 추적
테스트 방법 개발 장려 응용 프로그램 테스트 계획 준비
테스트 이벤트 일정 응용 프로그램 테스트 계획 준비
응용 프로그램 테스트 및 결과 기록 응용 프로그램 테스트
테스트 과정 보고 테스트 결과 추적
응용 프로그램 비호환성 문제 해결 응용 프로그램 비호환성 해결
추가 리소스
응용 프로그램의 비호환성 테스트 및 진단에 대한 자세한 내용은 웹 리소스 페이지(http://windows.microsoft.com/windows2000/reskit/webresources)에서 Microsoft Knowledge Base 링크를 참조하십시오.
응용 프로그램 테스트에 대한 자세한 내용은 다음을 참조하십시오.
Testing Computer Software by Cem Kaner, Jack Falk and Hung Quoc Nguyen, 1993, New York, NY: Van Nostrand Reinhold
Black-Box Testing: Techniques for Functional Testing of Software and Systems by Boris Bizer, 1995, New York, NY: John Wiley & Sons
Software Testing: A Craftsman's Approach by Paul Jorgensen, 1995, Boca Raton, FL: CRC Press
The Craft of Software Testing: Subsystem Testing Including Object -Based and Object-Oriented Testing by Brian Marick, 1995, Englewood Cliffs, NJ: Prentice Hall
'QC > 품질관리' 카테고리의 다른 글
| Project Quality Management (0) | 2005.10.31 |
|---|---|
| 소프트웨어 품질의 평가 (0) | 2005.10.31 |
| 조엘 테스트: 소프트웨어팀 평가 테스트 방법 (0) | 2005.10.31 |
| 소프트웨어 기술성 평가 기준 해설서 (0) | 2005.10.31 |
| 웹오피스 3종 벤치마킹 (0) | 2005.10.28 |
| 품질보증·품질관리 (0) | 2005.09.14 |
| 프로젝트 품질관리의 기본「품질 제어 vs 품질 보증」 (0) | 2005.09.14 |
| 글꼴 관련 정보 (0) | 2005.09.06 |
| 웹 서비스의 스트레스 테스트 (0) | 2005.08.30 |
| [자료] 테스터의 역할 및 SW테스트기법 (0) | 2005.08.30 |
Recent comment