사진으로 보는 소나무 가족의 행복한 이야기

웹오피스 3종 벤치마킹

 

웹오피스 3종 벤치마킹

세계적으로 유례를 찾아보기 힘들 정도로 발빠른 인터넷 인프라의 구축에 힘입어 웹오피스의 쓰임새가 높아지고 있습니다. 값 비싼 오피스 패키지를 구입하지 않더라도 즉석에서 다운로드 받아 이용할 수 있는 웹오피스는 설치 및 실행의 신속함과 더불어 불법 복제 시비에 휘말릴 염려가 없이 집과 사무실, 혹은 외부에서 편리하게 이용할 수 있습니다.

현재 국내에는 넷피스(http://www.netffice.com), 씽크프리(http://www.thinkfree.co.kr), 훈민웹오피스(http://web.hunmin.com) 등의 웹오피스가 서비스 중에 있습니다. 

 

자세한 것은 첨부 파일 참조

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

(2) 품질보증·품질관리

"품질보증"이란 제품의 운전 시에 만족하게 작동한다" 라는 확신을 얻을 수 있도록 하기 위한 조직적이고 체계적인 활동의 전체라고 일반적으로 정의되어 있다. "품질관리"는 제품의 특정 품질특성을 일정한 기준으로 부합시키기 위한 활동으로 품질보증활동 일부이다 라고 일반적으로 정의되어 있다.
ASME B & PV Code에서는 이 같은 정의와는 다르며, "ASME B & PV Code가 적용되는 Section의 요구사항에 부합하고 있다 라고 하는 것을 증명하기 위한 활동"이라고 되어 있다.

ASME B & PV Code의 품질보증, 품질관리도 "적합증명"의 기초가 되는 것이며, SAME Code 심볼, 스템프의 표시와도 밀접한 관계에 있다.
ASME B & PV Code에서 요구하고 있는 품질보증과 품질관리는 100% 순수하고 정확한 ASME 규격품을 창출하기 위한 것으로, ASME B & PV Code의 요구로부터 전혀 일탈하는 일이 없다고 하는 것을 나타내는 것으로 생각하여야 한다.
따라서, ASME B & PV Code에서 요구하고 있는 품질보증이나 품질관리만으로 요구되는 성능 전부를 만족할 만한 품질이 확보된다고는 할 수 없다. ASME B & PV Code에서 규정하고 있지 않은 품질에 대해서는 적용하는 자가 적절하게 보충할 필요가 있다.


자세한 것은 URL 자료 참조

프로젝트 품질관리의 기본「품질 제어 vs 품질 보증」

Tom Mochal (TechRepublic)  
2005/06/17
원문보기  
품질 제어와 품질 보증은 중요한 개념이지만 대부분의 프로젝트 관리자들은 이를 충분히 숙지하지 못하고 있으며, 두 개념 간의 차이점에 대해서도 잘 모르고 있다. 정확한 의미를 짚어보자.

프로젝트의 품질을 관리한다는 것은 우선 고객이 요구하는 정확한 품질 기대치를 이해하고, 이러한 기대치에 부응하는 혁신적인 계획을 입안하는 것이다. ‘혁신적인 계획’에는 수많은 요소가 포함된다. 이 중 가장 중요한 것은 이 프로젝트를 위해 수행돼야 하는 품질 제어와 품질 보증 활동이다.

품질 제어와 품질 보증은 중요한 개념이지만 대부분의 프로젝트 관리자들은 이를 충분히 숙지하지 못하고 있으며, 두 개념 간의 차이점에 대해서도 잘 모르고 있다. 그러나 품질 제어와 품질 보증은 실제로는 상당히 쉬운 개념이다.

품질 제어는 실행 가능한 프로젝트를 완성하기 위해 수행하는 관련 활동의 품질을 의미한다. 품질 제어는 이 프로젝트가 수용 가능한 품질이며, 완벽하고 올바른지 것인지 평가하는 데 사용된다. 품질 보증 활동의 사례로는 프로젝트에 함께 참여하고 있는 동료들의 검토와 테스팅 과정 등을 들 수 있다.

품질 보증은 프로젝트를 수행하는 과정을 의미하며, 관리자, 고객, 심지어는 서드파티 검수관도 품질 보증을 수행할 수 있다. 품질 보증의 사례로는 프로세스 체크리스트와 프로젝트 감사가 있다. 예를 들어 현재 맡은 프로젝트가 감사 대상이라면 감사관은 특정 요구사항의 내용이 품질 제어를 수용할 만한 것인지에 대해 알려주지 않을 수도 있다.

그러나 이 프로젝트가 품질 보증에 이용되는 프로세스를 기반으로 수용할 수 있는 것인지에 대해서는 말해줄 수 있다. 이것이 프로젝트 감사관이 프로젝트의 결과물에 대한 세부 사항은 모르고 있다 하더라도 여러분의 프로젝트에 대해 품질 보증을 검토할 수 있는 이유다. 감사관들은 여러분의 프로젝트에 대해 잘 알지는 못하지만 어떤 프로세스가 훌륭한 것인지는 알고 있다.

사례를 통해 살펴보자. 한 프로젝트 관리자가 후원자에게 ‘비즈니스 요구사항 보고서’를 승인해달라고 요청했다. 만약 여러분이 후원자라면 이 비즈니스 요구사항 보고서가 완벽하고 올바른 것인지 어떻게 확인할 것인가?

한 가지 방법은 해당 문서와 비즈니스 요구사항을 모두 검토하는 것이다. 이러한 활동은 프로젝트 평가를 기반으로 하기 때문에 곧 품질 제어 활동이 된다.

그러나 이 문서가 30페이지 정도의 분량인데다 여러분이 전문성도 없고 시간도 없는데다 구체적인 내용을 검토하고 싶지도 않을 때는 어떻게 할 것인가.

이 경우 여러분은 문서 검토를 위한 자료를 요청하지는 않을 것이다. 대신 프로젝트 관리자에게 이 문서를 생산하기 위해 어떤 과정을 밟았는지 설명해보라고 할 것이다. 그리고 이에 대한 답변을 듣는다.

프로젝트 관리자 : “프로젝트 첫 단계에서 8명의 주요 사용자들을 모아 회의를 가졌다. 회의가 끝난 후 이들의 요구사항을 문서화하고, 다시 피드백, 수정사항 등을 요청했다. 최종 작성된 문서를 법률, 재무, 생산, 구매 그룹 대표자들에게 전달하고, 이들 대표자들이 기업 표준 지원에 필요한 요구사항을 추가했다. 그리고 나서 이 시스템에 대해 가장 강력한 영향력을 갖고 있는 4명의 각 분야 관리자들과 회의를 가졌다. 관리자들이 몇 가지 요구사항을 추가로 제안했다. 요구사항을 반영해 문서를 수정한 후 4명의 관리자들에게 서명을 요청했고, 마지막 페이지에 이들이 서명했다.”

여러분이 만약 이 후원자라면 별 이견 없이 이 문서에 서명할 것인가? 필자가 보기에는 이 프로세스는 훌륭하게 수행된 것이다.

바로 여기에 차이점이 있다. 품질 제어 활동은 프로젝트의 수행 과정 자체에 중점을 두는 반면, 품질 보증 활동은 프로젝트를 실행하기 위해 진행된 과정상의 문제에 중점을 둔다.

품질 제어와 품질 보증 모두 강력한 기법이며, 여러분의 프로젝트가 고객이 요구하는 품질 요구사항에 부응할 수 있도록 보장하려면 반드시 수행해야 하는 것이다. @

  
  폰트는 무엇인가요?




폰트(font)란 활자조판에 필요한 모든 글자, 숫자, 그리고 특수기호들을 포함한 동일한 크기와 모양의 한벌 전체를 말합니다. 이 말은 본래 'foundary(활자 주조소)'의 'found(녹이다. 주조하다)'에서 유래되었습니다.
폰트는 모든 글자들이 다른 글자에 대해 관계를 가질 때 구조적인 통일성을 가지고 있어야 합니다. 가로획과 세로획의 무게와 두께는 통일되어야 하고 활자끼리의 시각적인 배열도 잘 조화되어야만 합니다. 동일한 폰트라면 조판면이 일정한 색조를 이룰 수 있도록 글자의 속과 글자 사이의 밝기와 어두움의 영향에 대해 주의 깊게 다루어져야 합니다.
한글에 있어서 가장 단순한 폰트의 구성은 첫닿자 19자, 홀자 21자, 받침닿자 27자를 합하여 총 67개로 이루어집니다. 여기에 숫자와 특수기호 75개를 합하면 좀더 편리하게 사용할 수 있는 142개로 구성된 폰트가 됩니다. 그러나 한글을 완성형으로 사용할 때는 특수기호를 포함시키지 않고도 2,300자 이상이 요구됩니다.




활자가족이란 무엇인가요?


그동안 궁금했던 활자 가족에 대해서 알아보겠습니다. ^^

활자가족 (The Type Family)
활자가족은 기준이 되는 부모 폰트( Parents Font)가 여러 모양으로 다양하게 변형됨으로써 만들어집니다. 이렇게 만들어진 여러 벌의 폰트를 활자가족( The Type Family)이라고 부릅니다. 그러나 비록 기준이 되는 폰트에서 변형된 것일지라도 개별적인 폰트로 간주됩니다. 한글에서의 활자가족은 이제까지 두께의 변화로 모양을 달리한 폰트들을 말할 때 쓰여왔습니다. 가장 즐겨쓰는 명조체는 일반적으로 세명조, 신명조, 중명조, 태명조, 견출명조라고 부르는 다섯 가지로 분류됩니다.

유니버스 가족체(Univers Family)
활자에 있어서 다양한 타이포그라피의 표현과 시각적인 대조는 활자의 주된 특성인 무게, 비례, 각도 등이 활자의 한 가족 안에서 종합적으로 표현될 때 그 차이점을 쉽게 볼 수 있습니다. 이러한 변화의 차이점을 가장 잘 볼 수 있는 활자가 유니버스 가족체입니다. 22개의 활자가족으로 구성된 유니버스 가족체는 'Adrian Frutiger'에 의해 디자인 되었습니다. 그는 일상적인 용어를 사용하는 대신에 일관된 숫자체계를 도입하여 다양한 폰트들을 체계화 시켰습니다. 유니버스 55가 기준체인데 그 이유는 이 체의 획의 무게와 비례는 변형되어 나오는 다른 모든 폰트들에 대해 기준이 되기 때문입니다. 유니버스 55의 회색효과나 비례가 서적의 본문조판에서 가장 이상적입니다.
유니버스체는 다른 활자에 비해 더 높은 x높이를 가진 것 때문에 유행이 되었던 활자입니다. 일반적인 폰트와 비교할 때 유니버스체의 소문자의 높이가 크기 때문에 대문자의 크기나 무게와 훨씬 비슷해졌습니다. 유니버스가족체에서 x높이, 대문자, 올림기둥, 내림기둥의 높이를 의도적으로 같게 디자인한 이유는 22종류의 폰트가 서로 제한받지 않고 얼마든지 혼합되어 조판될 수 있도록 무한한 가능성을 주기 위해서입니다. 이러한 배려는 디자이너에게 엄청난 융통성을 가져다 줍니다.









활자 관련 용어에는 무엇이 있나요


활자에 관련된 용어들에 대해서 알아보겠습니다. 너무 어렵게 생각하지 마시고 천천히 읽어보세요. ^^

글리프(glyph)
사람들이 인식할 수 있는 추상적인 그래픽 심볼이며, 이것은 어떤 특정의 글자 디자인에 독립적인 심볼을 의미합니다. 글리프는 하나 또는 그 이상의 최종 표현 형태를 뜻합니다.
폰트는 여러 글자가 모여 활자 한 벌을 이룬 것을 나타내지만 글리프는 글자 한 자를 가리킬 때 사용됩니다. 낱자 글자꼴과는 관계없이 표현된 보통 글자 외의 기호, 로고타입, 아이콘, 글자의 구성 요소 등의 패턴도 글리프라고 할 수 있습니다.

글자너비(character width, set width)
활자너비, 또는 자폭이라 부르기도 합니다. 글자 한 자가 인쇄 판짜기될 때 차지하는 너비를 말합니다. 이는 표기 방향선 상의 길이에 따릅니다.
글자너비에는 좌우여백을 포함합니다. 글자가 가지고 있는 기본 여백은 글자가 서로 만날 때 글자사이 공간을 이루며, 이는 왼쪽 여백과 오른쪽 여백이 있습니다.

글자여백(side bearing)
보통 글자는 까맣게 디자인된 글자꼴 주변에 일정한 여백을 가집니다. 이 때문에 글자너비는 물리적으로 칠해진 글자꼴 상하좌우에 이 약간의 여백을 더한 것이 됩니다. 바로 이것이 글자여백입니다.
영문의 경우 글자여백의 수치가 음수(마이너스)로 되는 것도 있는데, 이것은 글자꼴의 일부가 글자너비의 범위에서 빠져나오는 것을 뜻합니다.

고정 너비(mono space)
한 폰트에서 글자너비를 모두 동일하게 적용하는것을 말합니다.
네모틀 한글꼴의 경우가 이것이며, 영문타자기 글자도 이에 속합니다.

비례 너비(proportional space)
가변폭이라고도 부르며, 어떤 폰트의 경우 글자너비가 일정하지 않고, 그 디자인에 따라 글자마다 따로따로 글자너비가 다르게 디자인 된 것을 말합니다.
타자기 글자를 제외한 영문 폰트는 일반적으로 비례너비글자로 되어 있으며, 한글에서 탈네모틀류의 글자는 모두 비례너비글자로 되어 있습니다.

글자 크기(type size)
글자의 크기, 일반적으로 글줄사이 0일 때, 첫 글줄의 기준선과 다음 글줄의 기준선까지의 거리 크기가 바로 글자크기입니다.
글자 크기를 나타내는 척도 단위로는 현재 영미시의 포인트(1포인트=0.3514mm)와 일본식 급수(1급=0.25mm)가 있습니다.

글자 몸통(body)
글자 한 자가 점유하는 사각형의 영역을 말합니다. 글자 진행 방향으로는 글자너비만큼, 글줄 보내기 쪽으로는 첫 기준선에서 다음 기준선까지의 거리가 갖는 사각형의 공간을 뜻합니다.

커닝(kerning)
어느 특정 글자의 조합만을 표준 너비보다 글자 보내기를 작게 하여 글자 사이를 조정하는 것을 말합니다. 보통 표준 글자너비로 할 때 영문 대문자 'L' 다음에 'T'자가 오는 경우, 다른 글자들의 조합에 비해 글자사이가 더 넓게 보입니다. 이 때 이것을 시각적으로 고르게 보이게 하기 위해 'L'과 'T'의 사이를 좁힐 필요가 있습니다. 이것은 기술적으로 'L'이 가지는 글자너비를 작게 하면 됩니다. 소프트웨어상에서 글자사이 보정을 하려면, 미리 보정을 해야 하는 글자들의 조합과 보정치 데이터가 미리 주어져 있어야 합니다.

속공간(counter)
글자 속의 공간을 말합니다. 글자 줄기에 둘러싸인 비교적 넓은 공백 영역으로 열린 속공간과 닫힌 속공간으로 나눌 수 있습니다.
글자 속공간이 크고 작음으로 해서 글자꼴의 시각적 크기를 결정하는 요인이 되기도 하며, 글자꼴이 주는 이미지에도 영향을 미칩니다. 곧 한글의 경우, '이응'이나 '히읗'의 속공간이 보통보다 크면 글자의 느낌이 시원스러워지는 경향이 있습니다.

바깥공간
글자 속공간에 상대되는 뜻으로 글자 바깥에 이루어지는 공간을 말합니다. 곧 글자 바깥 공간이 넓으면 글자는 작아보이고, 글자 바깥 공간을 작게 하면 글자는 커보이기 마련입니다.

이음자(ligature)
두 글자 또는 세 글자를 합하여 하나의 글자로 만든 것을 말합니다. 영문자의 경우 'ff'. 'fi'등을 이어서 만든 것이나, 한글의 경우 세로줄기 하나를 생략한 '쌍비읍'자가 이에 속합니다.

자면(字面)
글자꼴에서 여백을 포함하지 않는 실제 인지되거나 표시되는 영역을 말합니다. 곧 이것은 활자꼴을 결정하는 것이 됩니다. 납활자에는 실제로 인쇄 잉크가 묻어 종이와 접촉하는 면을 말합니다.

본문 활자(text types)
주로 문장 본문에 쓰이는 가독성이 높고 줄기가 가는 활자꼴을 말합니다. 본문활자는 오랜 시간에 의해 대개 가독성이 높고, 아름다우며, 독자의 기호에 적합한 것이 특징입니다.

제목 활자(display types)
주로 제목이나 돋보임용으로 쓰이는 줄기의 표현이 강하거나 굵은 활자꼴을 말합니다. 일반적으로 문장에서 독자의 주의를 금방 끌 목적으로 사용되기 때문에 그 모양이 강하고 새로운 것이 많으며, 줄기의 굵기는 본문용 활자에 비해 굵은 것이 특징입니다. 대개 영문활자에서 제목활자 크기는 18포인트 이상을 말합니다.

활자 무게(type weight)
활자가 가지는 시각적인 무거움과 가벼움에 대한 느낌을 가리키는 말입니다. 활자 무게는 활자 굵기의 개념을 포함합니다.

활자 굵기(type boldness)
활자 줄기의 굵고 가늘음의 물리적 수치를 나타내는 말입니다.

그림자 글자(shadow typeface)
그림자가 있는 시각 효과를 갖는 활자꼴을 말합니다.

테두리 글자(outline typeface)
글자꼴의 획선에서 윤곽선만을 남기는 활자꼴을 말합니다.


<출처 :
통합체계로서의 한글 폰트 개발에 관한 기초 연구
석금호의 타이포그라픽 디자인>



활자의 측정 단위는 무엇이 있나요



활잘의 측정 단위에는 유니트, 미터법, 포인트 그리고 엠크기가 있습니다.

1. 유니트(unit):글자사이.백분율.%(100유니트시스템)
2. 미터법(mm):글줄길이
3. 포인트(point):글줄사이(leading). 글자크기
4. 엠크기(em quad):낱말사이. 전각. 반각. 1/2각. 엔쿼드. 1/3각 등

1pt=0.35mm이며 1inch는 72pt. 컴퓨터에서 Q라는 단위도 적용할 수 있는데 이는 사진식자의 크기를 측정하던 방법으로 급이라고 합니다. 1급은 0.25mm로서 사진식자의 크기는 7급에서 100급까지입니다. 영문 위주로 만들어진 컴퓨터의 체계는 인치 단위를 베이스로 하였기 때문에 1인치의 1/10인 7pt부터 1인치 크기인 72pt크기가 기본으로 선택될 수 있는 크기입니다.



서체는 어떻게 분류하나요.








오늘날 우리가 사용하고 있는 서체들은 매우 다양하지만, 이들을 체계적으로 분류하려는 많은 시도들은 서체가 지닌 시각적 특징이 중복되기 때문에 결코 쉬운 일이라고 할 수는 없습니다. 때문에 완벽한 서체 분류 체계는없고 다만 역사적 발달 과정에 근거한 일반적 분류 체계가 흔히 사용되고 있습니다. 즉 이 체계에서는 모든 서체를 올드 스타일(Old Style), 트렌지셔널(Transitional), 모던(Morden), 이집션(Egyptian) 또는 슬라브 세리프(Slab Serif), 산세리프(Sans Serif), 그리고 디스플레이(Display)의 여섯 가지 범주로 분류됩니다.


서체들의 시각적 특성

올드 스타일(Old Style)
획 굵기의 대비가 적음. 비스듬한 스트레스. 경사진 까치발 세리프. 표준적인 굵기.

트렌지셔널(Transitional)
획 굵기의 대비가 큰 편. 거의 수직에 가까운 스트레스. 날카롭고 조금 경사진 까치발 세리프.

모던(Morden)
굵기의 대비가 대단히 큼. 수직 스트레스. 매우 가느다란 세리프.

이집션(Egyptian)
획 굵기의 대비가 극히 적음. 스트레스가 거의 없음. 두껍고 사각진 세리프. x-높이가 높음.

산세리프(Sans Serif)
획 굵기의 대비가 약간 있음. 거의 수직에 가까운 스트레스. 수직과 수평으로 끝이 잘린 곡선획. 소문자 g의 꼬리가 열림.

디스플레이(Display)
일률적으로 평가할 수 없을 만큼 다양.

출처: 편집+타이포그라피



바탕체와 돋움체는 무엇인가요?



우리 일상에서 가장 많이 보고, 가장 많이 쓰이고 있는 네모틀 한글꼴의 대표적인 바탕체와 돋움체에 대해서 알아보겠습니다.


바탕체






한글은 본래 세로쓰기용으로 만들어졌습니다. 훈민정음 창제 당시, 한글의 모양은 각이 지고, 두텁고, 울뚝불뚝하였습니다. 그러나 그 당시의 유일한 필기도구인 붓을 가지고는 창제 때의 한글 모양을 그대로 제현할 수 없었고, 붓이라는 도구의 특성과 한자 쓰기의 관습에 따라 자연히 흘림체로 변화하였습니다. 이렇게 만들어진 한글체가 곧 궁서체였습니다. 결국 한글은 조선조 여인들에 의해서 아름답게 다듬어져 오늘에 이어졌다고 해도 과언이 아닙니다. 한글 바탕체는 조선조의 여인들에 의해 다듬어져 온 궁체 중에서 해서체를 기본으로 정리한 글자꼴입니다.
그런데, 이러한 한글꼴이 그동안 '명조체'로 불리어 왔습니다. 이러한 이름이 붙게 된 데에는 몇가지 요인이 있겠으나, 최초의 새활자나 사진 식자가 일본을 통하여 도입된 경로를 보거나 그들의 가나 글자체가 붓글씨체이지만 한자 명조체와 함께 쓰이면서 똑같은 이름으로 불리고 있는 것을 보면 일본의 영향일 가능성이 크다고 할 수 있겠습니다. 본래 명조체라는 것은 한자에 붙여진 이름입니다. 따라서 그동안 명조체로 불리어 온 한글꼴의 이름은 주체성이 없고, 부적합하다는 의견이 각 분야에서 거론되어 1991년 문화체육부가 주축이 되어 새로 '바탕체'라는 이름으로 결정하여 그 사용을 권장하고 있습니다.



돋움체






한글 돋움체라는 이름도 바탕체와 함께 1991년 문화체육부에서 지정한 이름입니다. 본래 고딕체로 통용되어 왔는데, 이러한 유래는 로마자 알파벳의 글자체 이름에서부터 유래되어 일본에 그대로 전해진 것이 한글 명조체의 경우와 마찬가지로 그대로 우리에게 도입된 것입니다. 그러나, 같은 성격의 한자를 대만에서는 흑체라고 부르고 있으며, 우리도 1960년대까지는 오죽체라고도 불렀습니다. 따라서 그나마 정확하지도 못한 이름을 무분별하게 그대로 사용하기 보다는 한글 나름대로의 고유한 이름을 찾는 것이 바람직하겠다는 이유로 '돋움체'라 부르기로 한 것입니다. 이러한 한글 돋움체는 가독성에서는 바탕체보다 떨어지지만 눈에 쉽게 뜨이는 특징이 있어서 각종 표지판이나 신문, 서적 등의 돋보임용으로 가장 많이 쓰이고 있습니다. 본래 한글 창제기의 글자체는 돋움체의 성격으로 되어 있었습니다.



2벌식 자판과 3벌식 자판은 어떻게 다른가요





*2벌식
'각'자의 경우, 초성 'ㄱ'과 종성 'ㄱ'을 같은 자판을 누르는 자판입력 방법을 2벌식 자판 입력 방법이라고 합니다. 보통 일반적으로 우리가 쓰고 있는 키보드 입력 방식이 이에 속합니다.

*3벌식
지금은 고인이 되신 "공병우"박사님께서 국가표준으로 삼고자 운동하신 자판입력 방식이기도 합니다. 3벌식은 초성과 중성, 종성이 각각 다른 키이므로 동시 타이핑이 가능합니다. 이런 이유에서 익숙해 지면 2벌식자판 보다 훨씬 빠른 타이핑이 가능하다고 합니다.매킨토시 메뉴 오른쪽에 보면 2벌식 입력, 3벌식 입력 교환 메뉴가 있습니다. 거기서 3벌식을 선택후, 그 메뉴 위에 단락에 있는 '자판보기'라는 메뉴를 보면 3벌식을 칠 수 있습니다.





비트맵폰트란 무엇인가요?



비트맵 폰트( Bitmap font),스크린폰트(Screen font)라고도 합니다.네모난 점들로 이루어진 폰트입니다. 포스트스크립트 폰트의 화면 디스플레이에 필요합니다. 보통은 12포인트, 24포인트 등의 정해진 글자크기를 제작하고, 나머지 크기의 서체들은 깨진 상태로 나타나게 되지만 화면에 빠르게 나타낼 수 있다는 장점이 있습니다. 레이져 프린터같은 포스트스크립트 지원용 프린터에서 "출력용폰

트"에게 정보전달을 해주는 역할을 합니다.







트루타입 폰트란 무엇인가요?



트루타입(TrueType)이란 애플사와 마이크로소프트사가 협력하여 만든 폰트기술로 화면과 프린터 출력상의 구현이 거의 비슷하게 이뤄집니다. 일반 잉크젯 프린터에서도 사용 될 수 있으며, 포스트스크립트 폰트처럼 꽤 양질의 출력물을 얻을 수가 있습니다.
다른 서체와 달리 화면상에서도 깨끗한 외곽선을 보여주므로, 일러스트레이터나 포토샵같은 그래픽 프로그램에서 다양한 용도로 사용할 수 있습니다.
하지만 레이저 등의 포스트스크립트 지원 프린터에선 용량이 커 출력이 빠르지 못하며, 화면 디스플레이 시간이 오래 걸리는 단점이 있습니다.


[그림 1]윈도에서 본 TTF(TrueType Font)파일

윈도우에서의 폰트 확장자 파일은 TTF 이외에 FON, TTC파일등이 있습니다.
FON : 시스템 글꼴 파일
TTC : 트루타입 컬렉션 파일


[그림 2]맥킨토시에서 본 TTF(TrueType Font)파일

맥킨토시에서는 보통 시스템\한글시스템\자형폴더 에 TTF파일들이 들어있습니다.
간혹 용량에 넘치게 폰트를 넣어두고 사용하는 경우를 몇번 보았습니다.
OS 9까지는 한글을 512개밖에 쓰지 못합니다. 이것은 애플에서 한글영역으로 지정가능한 Font ID를 512개로 한정해 놓았기 때문입니다. 따라서 그 이상의 서체(TTF파일)를 자형폴더에 넣게(또는 설치하게)되면, 동일한FontID(Font를 구분해주는 값)가 생기게 되고, ID가 같은 서체는 사용하지 못하는 경우가 생기게 됩니다. OS X에 관해서는 더 알아보아야 할것 같습니다.



포스트스크립트 폰트는 무엇인가요?




Adobe사에서 만든 포스트스크립트 서체 포맷으로 ATM, Type1,2,3,4 등의 종류 가 있습니다. 고품질의 출력을 할 수 있는 Type1, Type3 등의 포맷으로 프린터의 내장형 또는 외장형 폰트박스에 설치된 출력 전용 서체를 말합니다.


완성형 폰트와 조합형 폰트는 무엇인가요



*조합형
조합형 한글. 초성, 중성, 종성을 각각 따로 디자인하고 조합하여 구현합니다. 즉 초성 'ㄱ'은 딱 한가지 모양뿐이며, 중성과 종성도 마찬가지 입니다. 이런 방식으로 제작 되어지기 때문에 완성형에 비해 상당히 제작기간이 단축됩니다. 모든 문자를 모두 구현하는 장점이 있는 반면, 완성형에 비해 들쭉날쭉한 빨래줄 현상이 생기므로 "가독성"에 좋지 않은 영향을 주어 본문체로는 적합치 못한 단점이 있습니다. 그래서 주로 제목용 서체나 짧은 본문에 사용하고 있습니다.

*완성형
완성형 한글, ('산','돌','사','랑'..)등 완성된 글자 하나하나를 제작 하였습니다. '산' 과'사' 의 'ㅅ' 의 모양을 살펴보면 글자의 크기, 모양이 조금씩 다른 것을 볼 수 있습니다. 2,350자를 한자 한자 만들다보니 자연히 제작기간이 오래 걸리는 단점이 있지만, 섬세하게 제작 되어 조합형에 비해 "가독성"이 상당히 좋다고 볼 수있습니다. 그러나 완성형 폰트는 조합형에 비해 용량이 훨씬 크고 화일의 구조가 복잡하여 컴퓨터의 처리속도가 떨어지는 단점이 있습니다.




폰트는 어떤 프로그램을 이용해 만드나요




-많은 프로그램들이 있지만 여기에는 주로 쓰이는 몇가지를 소개하겠습니다.

*폰토그라퍼(Fontographer)
일반적으로 가장 많이 쓰이는 서체제작 프로그램으로 툴사용법이 어도비 일러스트레이터와 유사합니다.

*폰트매니아 (Fontmania)
휴먼컴퓨터에서 개발한 국내 유일의 상용 프로그램인데 매킨토시 버전은 없고 윈도용만 있습니다.

*폰트랩 (Fontlab)
서체개발 프로그램으로 유니코드가 지원됩니다.




세리프와 산세리프는 무엇인가요




*세리프(Serif)
문자 가로획의 시작이나 끝부분에 붙어있는 장식. 세로기둥과 줄기의 끝부분에 맵시를 내거나 가독성을 높이기 위해 붙인 획을 말합니다.

*산세리프(sanserif)
'sans'는 프랑스어로 '없다'는 의미로, 산세리프는 세리프가 없는 문자를 말합니다. 한글의 경우 고딕체가 이에 해당합니다.


자간과 행간은 무엇인가요




*자간(Inter-letter Spacing)
글자와 글자사이의 간격을 말합니다. 서체의 크기가 클수록 자간도 어느정도 확보해야 좋습니다. 그러나 본문용으로 적용할 경우 넓은자간은 오히려 가독성을 방해하기 때문에 적당한 자간을 유지하는게 좋습니다. 자간을 고르게 하면 본문의 색감이 고르게 되는데, 여기서 색감이란 본문에 형성되는 전체적인 명암을 말합니다.이렇게 일관성있고 고른 색채는 가독성을 좋게 합니다.

* 행간(Leading)
글의 행과 행사이의 공간을 말하며, 적절 행간은 가독성에 영향을 주는 중요한 요소가 됩니다.
예를들어 좁은행간은 글줄사이가 빽빽해 본문을 어두워 보이게 하고, 읽는 독자에게 상당한 피로를 주게 됩니다. 반대로, 간격이 지나치게 넓을때는 독자가 읽으면서 이 행에서 다음행으로 시선이 옮겨가는 동안 글을 읽는 흐름이 끊어질 수 있어 적당한 행간의 조정이 반드시 필요합니다.

*포인트(point)
타이포그라피를 위한 활자 계산법은 크게 알파벳을 위해 만들어진 포인트( Point)와 파이카( Pica), 히라가나와 카타카나 그리고 한자를 위해 사용되었던 호수, 세가지로 나누어 집니다. 한글은 사진식자기계 자판이 일본에서 제작, 한국에 보급된 것으로 인해 한자와 함께 급수체계를 사용하게 되었지만 전자출판 시스템이 보편화되면서 자연스럽게 포인트를 사용하게 되었습니다. 포인트의 단위는 P 또는 Pt라고 쓰이며, 1point = 0.3514mm, 1mm = 2.847point 입니다.



***홈페이지작업하시는 분이나 그래픽 작업 하시는 분들에게 유용한 자료가 될꺼 같아서 올려드립니다***



사용방법은 c:드라이브 들어가시면 윈도우폴더가있습니다. 윈도우 폴더안에 폰트(font) 폴더가 있는데 지금받으시는 자료를 압축풀어주시고 font폴더로 옮겨주시면 자동으로 적용되거나 설치하겠느냐는 메세지가 나옵니다. 예를 누르면 폰트가 설치가 됩니다.

중복되는 폰트도 있을껀데 양해해주세여 왠만한 폰트는 다있답니다 ^^

위에 내용은 폰트에 대해 모르시는분들을 위해 설명차원에서 올린글이구여. 500원하는거 가격 다운시킵니다. 용량도 최소화하기 위해 압축했습니다. 제필로그 오시면 폰트모음 또하나 있는데 이거랑 같은겁니다. 다만 압축시켜놓은것뿐이죠 용량을 줄이기 위해 500원에 받아가신 님들한테는 죄송하네요..그럼 좋은하루 보내시고

유용하게 쓰세요!

그럼 유용하게 사용하시길 바랍니다.
   
  

테스터를 위한 가이드라인 by Chris Wilkinson, 소프트웨어 엔지니어, IBM

웹 서비스는 분산 컴퓨팅의 심장이며, 그들 간 인터랙션은 테스트가 까다롭다. 스트레스 테스트는 코드 결함을 탐지하는 효율적인 방법이다. 단, 스트레스 시스템이 효과적으로 구현되어야 한다. 이 글을 통해 스트레스 시스템의 기본적인 필요조건을 알아본다.

테스트 방식

전통적인 테스트 방식에는 일정한 형식의 간단한 단위 테스트(Unit Testing)가 포함되어 있다. 이는 종종 개발자들이 수행한다. 이 테스트들은 소프트웨어 내부에 대한 지식을 기반으로 설계되었고 제품의 아주 작고 특정한 부분을 테스트할 목적으로 수행되었다. 이러한 종류의 테스트들은 다른 코드 컴포넌트와 관계가 조금 있거나 거의 없는 단순한 웹 서비스에 잘 맞는다.

기능 검증(Functional Verification)은 제품의 소스 코드에 대해 제한된 지식을 갖고 있는 디자이너가 제품 또는 서비스의 핵심 기능을 확인하도록 하는 테스트 과정이다. 이 테스트들은 핵심 기능들이 스팩에 순응하는지를 확인하도록 설계된다. 예를 들어, 나의 온라인 경매가 입력된 대로 정확한 비드(bid)를 디스플레이하는가? 보험 브로커 시스템이 가장 저렴한 가격을 찾아내는가? 만일 이러한 테스트가 실패하면 이 제품의 근본적인 문제는 발견되기 마련이다(그리고 보통 이러한 문제는 픽스가 단순하다). 이러한 테스트 역시 단순한 웹 서비스에 알맞고 서비스가 각각의 기능을 정확히 수행하는지 여부를 검사할 수 있다.
시스템 테스트(System Test)는 기능 검증(Functional Verification) 단계가 완료된 후 발생한다. 즉 핵심 기능이 확인된 후에 발생한다. 전체 시스템의 문제를 포괄적으로 테스트한다. 웹 서비스가 시스템의 일부로서 어떻게 작동하는지, 다른 것들과 어떻게 인터랙트 하는지를 검사한다. 시스템 테스트(System Test) 단계는 개발 과정 중 마무리 단계에 이르러 발생한다. 이를 수행하는데 할당된 시간은 적다. 빡빡한 배포 스케쥴과 개발 방향의 변경으로 인해 시스템 테스트 단계는 종종 간과되고, 드러나는 특정 버그는 너무나 빈번해서 탐지되지도 않는다. 버그가 발견되더라도 원인을 밝혀내고 픽스를 시도하기에는 늦는 경우가 종종 있다. 따라서 시스템 테스트 애플리케이션은 코드 오류를 가능한 효율적으로 찾아낼 수 있도록 설계되어야 한다. 시스템 테스트는 다음 세 가지 분야로 구성된다.

1. 퍼포먼스 : 해당 제품의 통계를 결정하는 과정. 예를 들어, 초당 메시지 수는? 서비스 동시 사용자들의 허용 수는?
2. 시나리오 : 고객이 요구하는 정확한 구성을 만들어내는 과정. 이 시나리오에서 발견된 문제들은 고객이 제품을 사용하기 전에 탐지될 수 있다.
3. 스트레스 (또는 워크로드 밸런싱) : 과중한 워크로드를 적용하여 소프트웨어를 최대로 작동시키도록 설계된 점으로 볼 때, 위 두 분야와는 다르다. 제품을 강도높게 사용하여 효과적으로 수행되기만 한다면 스트레스 테스팅은 위에 언급한 기술로 발견할 수 없는 모호한 많은 버그를 발견한다. (이 경우 픽스 또한 가장 어렵다).

위 세 개의 시스템 테스트 요소들 중 가장 효율적인 것은, 코드 오류 탐지 관점에서 볼 때, 스트레스 테스팅(stress testing)이다. 하지만 이 과정은 시스템 테스트 또는 기능 테스팅의 다른 요소들과 종종 혼동되고 이 과정에 포함된 방식도 정확하게 구현되지 않는다.

스트레스 버그

스트레스 테스트를 통해 발견할 수 있는 버그는 상당히 다양하다. 이들은 다른 테스트 방식으로는 발견하기 힘들다. 다음이 두 가지 유형이 있다:

1. 메모리 유출 : 가장 탐지하기 어려운 현상. 메모리 유출은 배포된 제품에서 발견될 때가 종종 있는데 이들을 감지할 테스트 케이스를 디자인하는 것이 매우 어렵기 때문이다. 간단한 기능 테스트를 통해 메모리 유출은 극히 드물게 발견되는데 테스트가 완료되기 전에는 제품을 충분히 사용할 수 없기 때문이다. 메모리 소비가 인식될 정도가 되게 하려면 수차례 작동을 반복해야 한다. 메모리 유출을 C/C++ 같은 언어들보다 자바 프로그램에 도입하는 것이 더 어렵지만, 프로그램이 객체에 대한 레퍼런스를 갖고있는 한 객체가 인스턴스화되고 할당받는 것은 여전히 가능하다.
2. 병행성과 동기화 : 스트레스 테스트는 병행성 문제를 찾아내는데 단연 돋보인다. 다양한 코드 경로들과 하나의 테스트 수명기간 동안 실행할 타이밍 조건 때문이다. 교착상태(Deadlocks), 쓰레드 유출, 일반적인 동기화 문제들은 스트레스 테스트 단계에서만 종종 탐지된다. 단위 테스트를 실행하여 이러한 유형의 문제들을 찾는 것은 매우 어렵다. 개발자들은 그들의 코드가 다른 영역의 코드들과 어떻게 인터랙팅하는지를 항상 고려해야하는 것은 아니다.

기존 스트레스 툴

개발중인 제품을 스트레스 테스트 할 수 있는 툴들이 있다. 이러한 툴 대부분은 웹 서비스를 타겟으로 하는 툴이다. 하지만 이러한 툴 대부분은 단순한 HTML/SOAP 생성기로서 많은 클라이언트 연결을 시뮬레이팅하고 따라서 웹 서버에 높은 부하를 만들어낸다. 이러한 툴들은 기본적인 스트레싱에는 유용하지만 같은 기능적 태스크를 반복적으로 수행하는 기능 검증 (Functional Verification)단계의 확장에 불과하다. 시간과 리소스가 충분히 사용할 수 있다면 커스텀 구현의 스트레스 테스팅 시스템을 만듦으로서 보다 효과적인 테스팅을 할 수 있다. 스트레싱 시스템의 설계자는 테스트를 받고 있는 제품과 웹 서비스에 대한 지식을 갖고 있기 때문에 스트레스 시스템이 특정 부분의 코드를 목표로 정할 수 있다.

스트레스 애플리케이션 디자인

웹 서비스를 스트레싱할 테스트 시스템은 특별한 방식으로 코드를 실행하도록 설계되어야한다. 이러한 스타일은 기능 검증의 수준을 뛰어넘어 웹 서비스가 기대하는 일을 수행하는지 여부 뿐만 아니라 특정한 스트레스 조건이 적용될 때 지속적으로 실행 상태를 유지할 수 있는지를 검사한다. 스트레스 테스트가 웹 서비스에 적용해야하는 네 개의 기본적인 조건이 있다. 검증된 많은 스트레스 시스템들은 이 조건들을 적용하고 있다. 효과적인 스트레스 테스팅 시스템은 다음의 핵심 조건을 적용한다.

1. 반복 : 스트레스 조건을 이해할 수 있는 가장 확실하고 쉬운 방법은 아마도 '테스트 반복'일 것이다. 다시말하면, 테스트 반복은 특정 작동이나 기능을 계속하여 반복적으로 수행하는 것을 의미한다. 이를 테면 웹 서비스를 반복적으로 호출하는 것도 이에 속한다. 기능 검증(Functional Verification) 테스트는 작동이 실행되는지의 여부를 검사하도록 설계될 수 있다. 스트레스 테스트는 실행이 작동하는지와 테스트가 실행될 때 지속적으로 작동하는지를 검사한다. 제품이 실제 환경에서 사용되기에 적합한지의 여부를 결정하는 데에 반드시 필요하다. 일반적으로 사용자들은 제품을 반복적으로 사용하기 때문에 스트레스 테스팅은 사용자 보다 앞서 코드 결함을 찾아내야한다. 많은 단순한 스트레스 시스템들은 오직 이러한 조건을 구현하지만 기능 검증 테스트가 여러번 반복하도록 단순히 확장하는 것만으로는 효과적인 스트레스 테스트를 수행할 수 없다. 다음의 원리들을 조합하여 사용할 때 반복은 모호한 코드 결함을 발견할 수 있다.

2. 병행성 : 병행성은 여러 작동들을 동시에 수행하는 것이다. 다른 말로 표현하면 동시에 여러 테스트들을 수행하는 것, 예를 들어 같은 서버에서 동시에 많은 웹 서비스를 호출하는 것도 이에 포함된다. 이 원리가 모든 제품에 적용되는 것은 아니지만 대부분의 소프트웨어는 병행 작동이나 멀티 쓰레드 작동 요소를 갖고 있어서 코드에서 여러 인스턴스들을 실행시켜서 테스트 될 수 있다. 기능 테스트 또는 단위 테스트는 병행 디자인에 잘 결합되지 않는다. 스트레스 시스템은 기능 테스트보다 한 수 위여서 동시에 여러 개의 코드 경로를 실행할 수 있다. 이는 특정 제품에 의존한다. 예를 들어, 웹 서비스 스트레스 테스트가 한 번에 여러 개의 클라이언트를 시뮬레이트 해야한다고 가정해보자. 웹 서비스(또는 멀티 쓰레디드 코드)는 일반적으로 쓰레드 인스턴트 중 몇 개의 공유 데이터에 접근할 것이다. 프로그래밍의 가외 범위 때문에 더해지는 복잡함은 코드가 병행성 때문에 많은 오류를 갖고 있음을 의미한다. 병행성을 도입한다는 것은 한 쓰레드에 있는 코드가 다른 쓰레드의 코드로 인해 방해받는다는 것을 의미하기 때문에 결함이 발견되는 것이다. 반복의 원리를 결합하여 많은 코드 경로와 타이밍 조건을 포함시킬 수 있다.

3. 크기(Magnitude) : 제품에 적용되어야 하는 스트레스 시스템의 또 다른 조건은 하나의 작동에 적용되는 로드의 양을 고려해야한다. 스트레스 테스트는 작동을 반복적으로 수행할 수 있지만 그 작동은 제품 그 자체를 손상시킬 것이다. 예를 들어 클라이언트가 메시지를 입력할 수 있는 웹 서비스가 있다면 많은 메시지를 입력하는 클라이언트를 시뮬레이팅하여 하나의 작동에 높은 가용성을 줄 수 있다. 다시말해서 작동의 크기(Magnitude)를 높이는 것이다. 크기는 언제나 애플리케이션 스팩이지만 사용자가 측정 및 변경할 수 있는 제품에서 값을 확인할 수 있다. 예를 들어 데이터 사이즈, 지연 길이, 전송량, 인풋 속도, 인풋 종류 등이 그것이다. 하나의 강력한 작동이 코드 결함을 찾지 못할 수 있지만 다른 스트레스 원리들을 결합하여 문제를 찾을 수 있는 기회를 늘인다.

4. 임의 변동 : 마지막으로, 어떤 스트레스 시스템도 임의성의 요소 없이 완성될 수 없다. 이전의 스트레스 원리들을 도입한 수 많은 변수들을 임의적으로 사용한다면 테스트가 실행될 때마다 다양한 많은 코드 경로를 포함할 수 있다. 반복을 통해 반복들 간 시간, 재시작이나 서비스에 재연결하기 전의 반복의 수, 반복되는 웹 서비스의 순서들간 시간을 다르게 할 수 있다. 병행성의 경우 함께 수행되는 웹 서비스, 한번에 실행되는 웹 서비스의 수, 다른 서비스를 여러번 실행하는 경우 또는 같은 인스턴스를 많이 실행하는 경우를 다르게 할 수 있다. 크기는 아마도 변경이 가장 쉬울 것이다. 테스트가 반복될 때마다 애플리케이션에 보이는 변수들을 변경할 수 있다. 테스트가 완전히 임의적이라면 스트레스 오류를 지속적으로 다시 만들기는 어렵기 때문에 몇몇 시스템들은 constant random seed에 기반한 임의 변동을 사용한다.

일반적으로 스트레스 테스트는 위에 열거한 모든 것을 결합하게 될 것이다. 또한 허용된 시간이 끝날때 까지 실행할 것이다. 테스트에 허용된 실행 시간이 길 수록 더 많은 코드 경로가 포함되고 발견되는 결함 역시 많다. 오류가 일단 발견되면 진단 후 치료되어야 하는 것은 물론이다. 스트레스 테스트에서 코드 오류는 실행 후 며칠이 지나서 발견될 수 있기 때문에 시스템은 무엇인가 잘못 되었을 때 사용가능한 디버그 정보를 만들어야 한다.
    

이 글은 sten.cyworld.com 에서 옮겨졌습니다.
작성자 : 박희장

이 글은 sten.cyworld.com 에서 옮겨졌습니다

QC 관련 자료를 모아 두었습니다.