데이터베이스 및 데이터베이스 프로세스는 독립 서브시스템으로 테스트해야 합니다. 이 테스트는 테스트 대상의 사용자 인터페이스가 없는 서브시스템을 데이터의 인터페이스로 사용하여 테스트합니다. 데이터베이스 관리
시스템(DBMS)에 대한 추가 조사를 수행하여 다음 표에서 식별된 테스트를 지원하는 도구와 기법이 있는지 식별해야 합니다.
기법의 목표:
|
UI와 별개로 데이터베이스 액세스 메소드 및 프로세스를 연습하여 올바르지 않게 기능하는 대상 동작 또는 데이터 손상을 관찰하고 기록할 수 있도록 하십시오.
|
기법:
|
각 데이터베이스 액세스 메소드 및 프로세스를 호출하여 올바르거나 올바르지 않은 데이터 및 데이터 요청을 입력하십시오.
데이터가 의도한 대로 채워졌는지와 데이터베이스 이벤트 발생이 적절한지 확인하려면 데이터베이스를 검사하고, 데이터가 타당한 이유로 올바르게 검색되었는지 확인하려면 리턴된 데이터를
검토하십시오.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
기본 구성 이미저 및 복원기
백업 및 복구 도구
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
데이터베이스 SQL 유틸리티 및 도구
데이터 생성 도구
|
성공 기준:
|
기법은 모든 주요 데이터베이스 액세스 메소드 및 프로세스의 테스트를 지원합니다.
|
특수 고려사항:
|
테스트 시 데이터베이스에서 직접 데이터를 입력 또는 수정하기 위해 DBMS 개발 환경 또는 드라이버가 필요할 수 있습니다.
프로세스는 수동으로 호출해야 합니다.
허용되지 않는 이벤트의 가시성을 증가시키려면 소형 또는 최소형 데이터베이스(레코드 수가 제한됨)를 사용해야 합니다.
|
테스트 대상 기능 테스트는 유스 케이스 또는 비즈니스 기능 및 비즈니스 규칙을 정확히 추적할 수 있는 테스트 요구사항에 초점을 맞춰야 합니다. 이러한 테스트의 목적은 올바른 데이터 허용, 처리 및 검색과 올바른
비즈니스 규칙 구현을 검증하는 것입니다. 이 테스트 유형은 블랙 박스 기법을 기반으로 하는데, 이는 그래픽 사용자 인터페이스(GUI)를 통해 응용프로그램과 상호작용하고 결과를 분석함으로써 응용프로그램 및 내부
프로세스를 확인합니다. 다음 표는 각 응용프로그램에 대해 권장되는 테스트의 아웃라인을 식별합니다.
기법의 목표:
|
탐색, 데이터 입력, 처리 및 검색을 포함한 테스트 대상 기능을 연습하여 대상 동작을 관찰하고 기록하십시오.
|
기법:
|
올바르거나 올바르지 않은 데이터를 사용해서 각 유스 케이스 시나리오의 개별 유스 케이스 플로우 또는 기능을 연습하여 다음을 확인하십시오.
올바른 데이터를 사용할 때 예상 결과가 나타나는지 여부
올바르지 않은 데이터를 사용할 때 해당 오류 또는 경고 메시지가 표시되는지 여부
각 비즈니스 규칙이 적절히 사용되었는지 여부
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
기본 구성 이미저 및 복원기
백업 및 복구 도구
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
데이터 생성 도구
|
성공 기준:
|
기법은 다음 테스트를 지원합니다.
모든 핵심 유스 케이스 시나리오
모든 핵심 기능
|
특수 고려사항:
|
기능 테스트의 구현 및 실행에 영향을 주는 항목이나 문제(내부 또는 외부)를 식별하거나 설명하십시오.
|
비즈니스 주기 테스트는 오랜 시간 동안 <프로젝트 이름>으로 수행된 타스크를 에뮬레이트해야 합니다. 주기는 예를 들어 1년으로 식별되고, 1년 동안 발생하는 트랜잭션 및 타스크가 실행되어야 합니다. 이
테스트는 매일, 매주, 매월 주기 및 날짜 의존 이벤트(예: 단식 계산서(tickler))를 모두 포함합니다.
기법의 목표:
|
필수 비즈니스 모델 및 스케줄에 따라 테스트 대상 및 백그라운드 프로세스를 이용하여 대상 동작을 관찰하고 기록하십시오.
|
기법:
|
테스트에서 다음을 수행하여 여러 비즈니스 주기를 시뮬레이트합니다.
테스트 대상 기능 테스트에 사용된 테스트는 지정된 기간 동안 각 기능의 실행 횟수를 늘려 여러 다른 사용자를 시뮬레이트하도록 수정 또는 개선됩니다.
모든 시간 또는 날짜 의존 기능은 올바르거나 올바르지 않은 날짜 또는 기간을 사용하여 실행됩니다.
정기적인 스케줄에 따라 일어나는 모든 기능은 적절한 시간에 실행 또는 시작됩니다.
테스트에서는 올바르거나 올바르지 않은 데이터를 사용하여 다음을 확인합니다.
올바른 데이터를 사용할 때 예상 결과가 나타나는지 여부
올바르지 않은 데이터를 사용할 때 해당 오류 또는 경고 메시지가 표시되는지 여부
각 비즈니스 규칙이 올바르게 적용됩니다.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
기본 구성 이미저 및 복원기
백업 및 복구 도구
데이터 생성 도구
|
성공 기준:
|
기법은 모든 주요 비즈니스 주기의 테스트를 지원합니다.
|
특수 고려사항:
|
시스템 날짜 및 이벤트는 특수 지원 타스크를 필요로 합니다.
비즈니스 모델은 해당 테스트 요구사항 및 프로시저를 식별하는 데 필요합니다.
|
사용자 인터페이스(UI) 테스트는 소프트웨어에 대한 사용자의 상호작용을 확인합니다. UI 테스트의 목적은 UI가 테스트 대상의 기능을 통해 사용자에게 적절한 액세스 및 탐색을 제공하는지 확인하는 것입니다. 또한
UI 테스트는 오브젝트가 예상되는 UI 기능 범위 내에 있으며 기업 또는 산업 표준에 따르도록 합니다.
기법의 목표:
|
다음을 수행하여 표준 준수 및 대상 동작을 관찰하고 기록하십시오.
창 대 창, 필드 대 필드 및 액세스 메소드 사용(탭 키, 마우스 이동, 단축키)을 포함하여 비즈니스 기능 및 요구사항을 반영하는 테스트 대상 탐색
메뉴, 크기, 위치, 상태, 초점 등 창 오브젝트 및 특성을 이용할 수 있습니다.
|
기법:
|
각 창의 테스트 사항을 작성 또는 수정하여 각 응용프로그램 창 및 오브젝트에 적합한 탐색 및 오브젝트 상태를 확인하십시오.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에는 테스트 스크립트 자동화 도구가 필요합니다.
|
성공 기준:
|
기법은 사용자에게 널리 사용되는 각각의 주 화면 또는 창의 테스트를 지원합니다.
|
특수 고려사항:
|
사용자 정의 및 써드파티 오브젝트에 대한 일부 특성에만 액세스할 수 있습니다.
|
성능 프로파일링은 응답 시간, 트랜잭션 비율 및 기타 시간 의존 요구사항을 측정 및 평가하는 성능 테스트입니다. 성능 프로파일링의 목적은 성능 요구사항이 달성되었는지 확인하는 것입니다. 성능 프로파일링은 테스트
대상의 성능 동작을 워크로드나 하드웨어 구성과 같은 조건의 기능으로 프로파일링하고 조정하기 위해 구현하고 실행됩니다.
참고: 다음 표의 트랜잭션은 "논리 비즈니스 트랜잭션"에 해당합니다. 이 트랜잭션은 시스템 액터가 테스트 대상을 사용하여 수행할 것으로 예상되는 특정 유스 케이스(예: 지정된 계약의 추가 또는 수정)로
정의됩니다.
기법의 목표:
|
다음 조건에서 지정된 기능 트랜잭션 또는 비즈니스 기능의 동작을 수행하여 대상 동작 및 응용프로그램 수행 데이터를 관찰하고 기록하십시오.
예상되는 정상 워크로드
최악의 경우 예상되는 워크로드
|
기법:
|
기능 또는 비즈니스 주기 테스트용으로 개발된 테스트 프로시저를 사용하십시오.
각 트랜잭션에서 발생하는 반복 횟수를 늘리려면 데이터 파일을 수정하여 트랜잭션이나 스크립트의 수를 늘리십시오.
스크립트는 하나의 시스템에서 실행되며(단일 사용자, 단일 트랜잭션을 벤치마킹하는 경우 가장 바람직함), 복수의 가상 또는 실제 클라이언트에 대해 반복됩니다(아래의 특수 고려사항 참조).
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
응용프로그램 성능 프로파일링 도구(예: Rational Quantify)
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
자원 제한 도구(예: Canned Heat)
|
성공 기준:
|
기법은 다음 테스트를 지원합니다.
단일 트랜잭션 또는 단일 사용자: 테스트 구현 문제점으로 인한 실패 없이 성공적인 트랜잭션 스크립트 에뮬레이션
복수 트랜잭션 또는 복수 사용자: 테스트 구현 문제점으로 인한 실패 없이 성공적인 워크로드 에뮬레이션
|
특수 고려사항:
|
서버에 백그라운드 워크로드가 있는 경우 광범위한 성능 테스트를 실시합니다.
이를 수행하기 위해서는 다음과 같은 몇 가지 방법을 사용할 수 있습니다.
보통 SQL(Structured Query Language) 호출 형식으로 서버에 직접 "트랜잭션을 구동"합니다.
"가상" 사용자 로드를 작성하여 보통 수백 단위의 많은 클라이언트를 시뮬레이트합니다. 원격 터미널 에뮬레이션 도구를 사용하여 이 로드를 수행합니다. 이 기법은 네트워크에 "트래픽"을
로드할 때에도 사용할 수 있습니다.
각각 테스트 스크립트를 실행하는 복수의 실제 클라이언트를 사용하여 시스템에 로드합니다.
성능 테스트는 전용 시스템 또는 지정된 시간에 수행해야 따라서 완전한 제어와 정확한 측정이 가능합니다.
성능 테스트에 사용된 데이터베이스는 실제 크기이거나 동일한 크기로 조정됩니다.
|
로드 테스트는 테스트 대상에 다양한 워크로드를 적용하여 서로 다른 워크로드 상태에서도 적절하게 기능하는지에 대해 테스트 대상의 성능 작동 및 능력을 측정하고 평가하는 성능 테스트입니다. 로드 테스트의 목적은 예상
최대 워크로드가 초과된 상태에서도 시스템이 올바른 기능을 수행하는지 확인하는 것입니다. 또한 로드 테스트는 성능 특성(예: 반응 시간, 트랜잭션 비율 및 기타 시간 의존 문제)을 평가합니다.
참고: 다음 표의 트랜잭션은 "논리 비즈니스 트랜잭션"에 해당합니다. 이 트랜잭션은 시스템 사용자가 응용프로그램을 사용하여 수행할 것으로 예상되는 특정 기능(예: 지정된 계약의 추가 또는 수정)으로
정의됩니다.
기법의 목표:
|
다양한 워크로드 조건에서 지정된 트랜잭션 또는 비즈니스 사례를 수행하여 대상 동작 및 시스템 성능 데이터를 관찰하고 기록하십시오.
|
기법:
|
기능 또는 비즈니스 주기 테스트를 기반으로 하여 개발된 트랜잭션 테스트 스크립트를 사용하며 단, 불필요한 상호작용 및 지연 요소는 제거해야 합니다.
각 트랜잭션의 수를 늘리려면 데이터 파일을 수정하고, 각 트랜잭션의 발생 횟수를 늘리려면 테스트를 수정하십시오.
워크로드는 예를 들어 매일, 매주 및 매월 단위의 최대 로드를 포함합니다.
워크로드는 평균 및 최대 로드를 둘 다 표시합니다.
워크로드는 순간적 최대치와 지속적 최대치를 모두 표시합니다.
워크로드는 각각 다른 테스트 환경 구성에서 실행됩니다.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
트랜잭션 로드 스케줄링 및 제어 도구
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
자원 제한 도구(예: Canned Heat)
데이터 생성 도구
|
성공 기준:
|
이 기법은 워크로드 에뮬레이션 테스트를 지원하는데 이는, 테스트 구현 문제점으로 인한 실패가 없는 성공적인 워크로드 에뮬레이션입니다.
|
특수 고려사항:
|
로드 테스트는 전용 시스템 또는 지정된 시간에 수행해야 따라서 완전한 제어와 정확한 측정이 가능합니다.
로드 테스트에 사용되는 데이터베이스는 실제 크기이거나 동일한 크기로 조정됩니다.
|
스트레스 테스트는 예상 허용 오차 범위 경계 또는 범위 밖의 조건으로 인한 시스템 실패 양상을 이해하기 위해 구현 및 실행되는 성능 테스트의 한 유형입니다. 이 테스트에는 일반적으로 적은 자원 또는 자원 경쟁이
포함됩니다. 적은 자원 조건에서는 정상 조건 하에서 식별할 수 없는 테스트 대상의 실패 양상이 나타납니다. 기타 결함은 공유 자원(예: 데이터베이스 잠금 또는 네트워크 대역폭)의 경쟁 결과로 발생할 수 있습니다.
이 테스트 중 일부는 보통 기능 및 로드 테스트에 포함됩니다.
참고: 다음 표의 트랜잭션에 대한 참조는 논리적 비즈니스 트랜잭션을 참조합니다.
기법의 목표:
|
다음 스트레스 조건에서 테스트 대상의 기능을 수행하여 대상 동작을 관찰 및 기록한 후 시스템 기능이 제대로 수행되지 않는 조건을 식별하고 문서화하십시오.
서버에서 사용 가능한 메모리(RAM 및 지속적 저장영역)가 거의 없거나 전혀 없음
실제로 연결 또는 시뮬레이트할 수 있는 최대 클라이언트 수
같은 데이터나 계정에 대하여 같은 트랜잭션을 수행하는 복수의 사용자
"오버로드" 트랜잭션 볼륨 또는 믹스(위의 성능 프로파일링 참조)
|
기법:
|
성능 프로파일링 또는 로드 테스트용으로 개발된 테스트를 사용하십시오.
제한된 자원을 테스트할 경우, 단일 시스템에서 테스트가 실행되고 서버의 RAM 및 지속적 저장영역이 줄어들거나 제한됩니다.
스트레스 테스트를 계속 실행하려면, 복수 클라이언트를 사용하여 해당 테스트나 보충 테스트 실행 시 최악의 경우 트랜잭션 볼륨 또는 믹스를 생성하십시오.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
트랜잭션 로드 스케줄링 및 제어 도구
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
자원 제한 도구(예: Canned Heat)
데이터 생성 도구
|
성공 기준:
|
기법은 스트레스 에뮬레이션 테스트를 지원합니다. 시스템 에뮬레이션은 스트레스 조건으로 정의된 하나 이상의 조건에서 성공적으로 수행할 수 있으며, 조건 에뮬레이트 도중 및 이후에 결과로
나타나는 시스템 상태를 관찰할 수 있습니다.
|
특수 고려사항:
|
네트워크 스트레스를 가할 때 네트워크에 메시지나 패킷을 로드하기 위해 네트워크 도구가 필요할 수 있습니다.
시스템에 사용된 지속적 저장영역이 일시적으로 줄어 데이터베이스 생성에 사용 가능한 공간이 제한됩니다.
같은 레코드나 데이터 계정을 액세스하는 동시 접속 클라이언트를 동기화하십시오.
|
볼륨 테스트에서는 테스트 대상에 대량의 데이터를 로드하여 한계 도달 시 소프트웨어 실패를 일으키는지 여부를 판별합니다. 또한 볼륨 테스트를 통해 테스트 대상이 정해진 기간에 처리할 수 있는 지속적 최대 로드 또는
볼륨을 식별합니다. 예를 들어 테스트 대상이 보고서를 생성하기 위해 데이터베이스 레코드 세트를 처리할 경우, 볼륨 테스트는 대규모 테스트 데이터베이스를 사용하여 소프트웨어가 정상적으로 작동하고 올바른 보고서를
생성했는지를 확인합니다.
기법의 목표:
|
다음 고용량 시나리오에서 테스트 대상 기능을 수행하여 대상 동작을 관찰하고 기록하십시오.
연결되거나 시뮬레이트되어 연장된 기간에 모두 동일한 최악의 경우 (성능) 비즈니스 기능을 수행하는 실제 최대 클라이언트 수.
실제 또는 크기 조정된 최대 데이터베이스 크기에 도달하며 복수의 조회 또는 보고서 트랜잭션이 동시에 실행됩니다.
|
기법:
|
성능 프로파일링 또는 로드 테스트용으로 개발된 테스트를 사용하십시오.
해당 테스트나 보충 테스트 실행하는 복수 클라이언트를 사용하여 연장된 기간 동안 최악의 경우 트랜잭션 볼륨 또는 믹스(스트레스 테스트 참조)를 생성하십시오.
최대 데이터베이스 크기가 작성되며(실제, 크기 조정됨 또는 대표 데이터로 채워짐), 복수 클라이언트를 사용하여 연장된 기간 동안 동시에 조회를 실행하고 트랜잭션을 보고합니다.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
트랜잭션 로드 스케줄링 및 제어 도구
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
자원 제한 도구(예: Canned Heat)
데이터 생성 도구
|
성공 기준:
|
이 기법은 볼륨 에뮬레이션 테스트를 지원합니다. 대량의 사용자, 데이터, 트랜잭션 또는 기타 시스템 볼륨 사용 측면을 성공적으로 에뮬레이트하고 볼륨 테스트 지속기간 동안 시스템 상태의
변경사항을 관찰할 수 있습니다.
|
특수 고려사항:
|
위에 언급한 고용량 조건에 허용 가능한 시간으로 고려되는 기간은 얼마입니까?
|
보안 및 액세스 제어 테스트는 다음 두 가지의 주요 보안 영역에 초점을 맞춥니다.
데이터 또는 비즈니스 기능에 대한 액세스를 포함한 응용프로그램 레벨 보안
시스템에 대한 로깅 또는 원격 액세스를 포함한 시스템 레벨 보안
필요한 보안에 따라 응용프로그램 레벨 보안은 액터가 특정 기능이나 유스 케이스에 대해 제한되도록 하거나 또는 액터에게 사용 가능한 데이터가 제한되도록 합니다. 예를 들어, 데이터를 입력하거나 새 계정을 작성하는
것은 누구나 할 수 있지만 삭제는 관리자만 할 수 있습니다. 보안이 데이터 레벨에 있는 경우, 테스트 결과에서 "사용자 유형 1"은 재무 데이터를 포함한 모든 고객 정보를 볼 수 있는 반면 "사용자 유형 2"는
해당 고객에 대한 인구통계학적 데이터만 보는 것으로 나타납니다.
시스템 레벨 보안은 시스템 액세스 권한이 부여된 사용자만 응용프로그램에 액세스할 수 있고 해당 게이트웨이를 통과할 수 있도록 보장합니다.
기법의 목표:
|
다음 조건 하에서 테스트 대상 기능을 수행하여 대상 동작을 관찰하고 기록하십시오.
응용프로그램 레벨 보안: 액터는 해당 사용자 유형에게 사용이 허가된 기능이나 데이터에만 액세스할 수 있습니다.
시스템 레벨 보안: 시스템 및 응용프로그램에 대한 액세스 권한이 있는 액터만 해당 시스템 및 응용프로그램에 액세스할 수 있습니다.
|
기법:
|
응용프로그램 레벨 보안: 각 사용자 유형 및 각 유형에게 사용이 허가된 기능 또는 데이터를 식별하여 목록을 작성하십시오.
각 사용자 유형별로 테스트를 작성하고 각 사용자 유형 특정의 트랜잭션을 작성하여 각 권한을 확인하십시오.
사용자 유형을 수정하고 해당 사용자에 대한 테스트를 재실행하십시오. 각 경우별로 추가 기능 또는 데이터가 올바르게 사용되고 있는지 혹은 거부되었는지 확인하십시오.
시스템 레벨 액세스: 아래의 특수 고려사항을 참조하십시오.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
테스트 스크립트 자동화 도구
"해커" 보안 위반 및 탐색(probing) 도구
OS 보안 관리 도구
|
성공 기준:
|
기법은 보안 설정에 의해 영향받은 기능 또는 데이터 테스트의 경우 알려져 있는 각 액터 유형별로 테스트할 수 있도록 지원합니다.
|
특수 고려사항:
|
시스템에 대한 액세스는 해당 네트워크 또는 시스템 관리자와 검토하거나 논의해야 합니다. 네트워크 또는 시스템 관리에 관한 기능일 경우 이 테스트는 필요하지 않습니다.
|
장애 극복 및 복구 테스트는 테스트 대상이 과도한 데이터 또는 데이터 무결성 손실에 따른 다양한 하드웨어, 소프트웨어 또는 네트워크 기능 장애를 성공적으로 극복하고 복구할 수 있도록 합니다.
시스템을 계속 실행해야 하는 경우, 장애 복구 테스트는 장애 복구 조건이 발생하면 대체 또는 백업 시스템이 데이터 또는 트랜잭션의 손실없이 실패 시스템의 작업을 인계받도록 합니다.
복구 테스트는 응용프로그램 또는 시스템이 극도의 조건이나 시뮬레이션 조건에 노출되어 실패(예: 장치 입출력(I/O) 실패 또는 올바르지 않은 데이터베이스 포인터 및 키)를 야기하는 대립 테스트 프로세스입니다. 복구
프로세스가 호출되면, 응용프로그램 또는 시스템의 모니터링 및 검사를 통해 해당 응용프로그램 또는 시스템 및 데이터 복구가 이루어졌는지 확인합니다.
기법의 목표:
|
장애 조건을 시뮬레이트하고 복구 프로세스를 수동 또는 자동으로 실행하여 데이터베이스, 응용프로그램 및 시스템을 알려진 요구 상태로 복원하십시오. 다음은 복구 후 동작을 관찰 및 기록하기
위해 테스트에 포함되는 조건 유형입니다.
클라이언트의 정전
서버의 정전
네트워크 서버 경유 통신 중단
DASD(Direct Access Storage Devices) 및 DASD 제어기의 중단, 통신 또는 전력 손실
불완전 주기(데이터 필터 프로세스 중단, 데이터 동기화 프로세스 중단)
올바르지 않은 데이터베이스 포인터 또는 키
데이터베이스에서 올바르지 않거나 손상된 데이터 요소
|
기법:
|
기능 및 비즈니스 주기 테스트의 경우, 이전에 작성된 테스트를 기초로 사용하여 장애 극복 및 복구 테스트를 지원하기 위한 일련의 트랜잭션을 작성할 수 있으며, 주로 복구가 완료되었는지
테스트하기 위해 실행해야 할 테스트를 정의합니다.
클라이언트의 정전: PC 전원 끄기
서버의 정전: 서버의 전원 끄기 프로시저를 시뮬레이트하거나 시작합니다.
네트워크 서버 경유 중단: 네트워크와의 통신 손실을 시뮬레이트하거나 시작합니다(실제로 통신 연결을 끊거나 네트워크 서버 또는 라우터 전원 끄기).
DASD(Direct Access Storage Devices) 및 DASD 제어기의 중단, 통신 또는 전력 손실: 실제로 하나 이상의 DASD 또는 DASD 제어기와의 통신을
제거하거나 시뮬레이트합니다.
위의 조건 또는 시뮬레이트 조건이 발생하면 추가 트랜잭션이 실행되고, 이 2차 테스트 지점의 상태에 도달하면 복구 프로시저가 호출됩니다.
불완전 주기 테스트는 데이터베이스 프로세스가 자체 중단되거나 조기에 종료되는 경우 외에는 위에서 설명한 해당 기법을 이용합니다.
다음 조건에 대한 테스트를 수행하려면 알려진 데이터베이스 상태에 도달해야 합니다. 데이터베이스 내의 몇몇 데이터베이스 필드, 포인터 및 키는 데이터베이스 도구에 의해 직접 손상되거나
수동으로 손상됩니다. 추가 트랜잭션은 응용프로그램 기능 및 비즈니스 주기 테스트에서 실행된 테스트 및 전체 주기를 사용하여 실행됩니다.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
기본 구성 이미저 및 복원기
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
백업 및 복구 도구
|
성공 기준:
|
기법은 다음 테스트를 지원합니다.
하나 이상의 응용프로그램, 데이터베이스 및 시스템 조합이 포함된 하나 이상의 시뮬레이션 재해
하나 이상의 응용프로그램, 데이터베이스 및 시스템 조합을 알려진 희망 상태로 만드는 하나 이상의 시뮬레이션 복구
|
특수 고려사항:
|
복구 테스트는 매우 까다로운 작업으로서, 케이블 연결을 끊는 프로시저(전원 또는 통신 차단 시뮬레이션)가 바람직하지 않거나 불가능할 수 있습니다. 대체 메소드(예: 진단 소프트웨어
도구)가 필요할 수 있습니다.
시스템 (또는 컴퓨터 오퍼레이션), 데이터베이스 및 네트워킹 그룹의 자원이 필요합니다.
이 테스트는 몇 시간 후 또는 분리된 시스템에서 실행해야 합니다.
|
구성 테스트는 각기 다른 소프트웨어 및 하드웨어 구성에서 테스트 대상의 오퍼레이션을 확인합니다. 대개의 프로덕션 환경에서 클라이언트 워크스테이션, 네트워크 연결 및 데이터베이스 서버의 특정 하드웨어 스펙은 차이가
있습니다. 클라이언트 워크스테이션에서는 다양한 소프트웨어(예: 응용프로그램, 드라이버 등)를 로드할 수 있고, 언제든지 많은 다른 조합이 다양한 자원을 사용하여 활성화될 수 있습니다.
기법의 목표:
|
필수 하드웨어 및 소프트웨어 구성에서 테스트 대상을 실행하여 다양한 구성에 따른 대상 동작을 관찰 및 기록하고 구성 상태의 변경을 식별하십시오.
|
기법:
|
기능 테스트 스크립트를 사용하십시오.
다양한 테스트 이외의 대상 관련 소프트웨어(예: Microsoft® Excel® 및 Microsoft® Word® 응용프로그램)를 테스트 시작 이전 또는 테스트의 파트로 열고
닫으십시오.
선택한 트랜잭션을 실행하여 테스트 대상 및 테스트 이외의 대상 소프트웨어와 상호작용하는 액터를 시뮬레이트하십시오.
위의 프로세스를 반복하여 클라이언트 워크스테이션에서 사용 가능한 기본 메모리를 최소화하십시오.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
기본 구성 이미저 및 복원기
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
|
성공 기준:
|
기법은 예상 지원 배치 환경에서 실행 중인 하나 이상의 대상 테스트 항목 조합의 테스트를 지원합니다.
|
특수 고려사항:
|
테스크탑에서 필요하고 사용 가능하고 액세스 가능한 테스트 이외의 대상 소프트웨어는 무엇입니까?
일반적으로 사용되는 응용프로그램은 무엇입니까?
응용프로그램이 실행 중인 데이터는 무엇입니까(예: Excel에서 열리는 대형 스프레드시트 또는 100페이지 분량의 Word 문서)?
전체 시스템 Netware, 네트워크 서버, 데이터베이스도 또한 이 테스트의 파트로 문서화해야 합니다.
|
설치 테스트의 목적은 두 가지가 있습니다. 첫 번째는 소프트웨어를 정상 및 비정상 조건 하에서 다양한 조건(예: 새 설치, 업그레이드 및 전체 또는 사용자 정의 설치)으로 설치할 수 있는지 확인하는 것입니다.
비정상 조건에는 충분하지 않은 디스크 공간, 디렉토리 작성 특권 결여 등이 있습니다. 두 번째 목적은 설치된 소프트웨어가 올바르게 작동하는지 검증하는 것입니다. 보통은 기능 테스트용으로 개발된 많은 테스트를
실행하는 것을 의미합니다.
기법의 목표:
|
다음 조건 하에서 각 필수 하드웨어 구성에 테스트 대상의 설치를 실행하여 설치 동작 및 구성 상태 변경을 관찰 및 기록하십시오.
새 설치: 이전에 <프로젝트 이름>으로 설치된 적이 없는 새 시스템
갱신: 이전에 <프로젝트 이름> 동일 버전이 설치된 시스템
갱신: 이전에 <프로젝트 이름> 구 버전이 설치된 시스템
|
기법:
|
자동 또는 수동 스크립트를 개발하여 대상 시스템의 조건을 유효성 검증하십시오.
새: <프로젝트 이름>이 설치된 적 없음
<프로젝트 이름> 동일 또는 구 버전이 이미 설치되어 있음
설치를 시작 또는 수행하십시오.
사전 판별된 기능 테스트 스크립트 서브세트를 사용하여 트랜잭션을 실행하십시오.
|
오라클:
|
테스트의 결과물을 정확하게 관찰하기 위해 해당 기법에 사용할 수 있는 전략을 하나 이상 간단히 설명하십시오. 오라클은 관찰에 사용되는 메소드와 성공 또는 실패 가능성을 표시하는 특정
결과의 특성 요소를 모두 결합합니다. 원칙적으로 오라클은 자체 확인 및 자동화된 테스트를 통해 테스트 패스 또는 실패를 초기 평가하지만, 자동 결과 판별에 따르는 위험성을 줄이도록
주의해야 합니다.
|
필수 도구:
|
기법에 필요한 도구는 다음과 같습니다.
기본 구성 이미저 및 복원기
설치 모니터링 도구(레지스트리, 하드 디스크, CPU, 메모리 등)
|
성공 기준:
|
기법은 하나 이상의 설치 구성에서 개발된 제품의 설치 테스트를 지원합니다.
|
특수 고려사항:
|
<프로젝트 이름> 응용프로그램의 설치가 완료되고 주요 소프트웨어 컴포넌트가 빠지지 않았는지 확인하는 신뢰성 테스트를 포함하기 위해 선택해야 하는 <프로젝트 이름>
트랜잭션은 무엇입니까?
|
|