ISTQB_CTAL_TA_Syllabus_v2012_Kor(고급레벨 실러버스)

ISTQB_CTAL_TA_Syllabus_v2012_Kor(고급레벨 실러버스)

0. 이 교과목 소개

0.1이 문서의 목적

이 강의 계획서는 국제 소프트웨어 테스팅 자격 취득을 위한 고급 과정

테스트 분석가를 위한 레벨. ISTQB®는 다음과 같이 이 교과 과정을 제공합니다 :

1. National Boards, 현지 언어로 번역하고 훈련 제공자를 승인하십시오.

내셔널 보드는 교과 과정을 자신의 특정 언어 요구에 맞게 조정하고

지역 출판물에 대한 참고 문헌.

2. 시험위원회에, 해당 지역 언어로 된 시험 문제를 도출하기 위해

각 강의 계획의 학습 목표.

3. 훈련 제공자에게 코스웨어를 만들고 적절한 교수 방법을 결정합니다.

4. 인증 후보자에게 시험을 준비하십시오 (교육 과정의 일부 또는

독립적으로).

5. 국제 소프트웨어 및 시스템 엔지니어링 커뮤니티에 직업을 향상 시키십시오.

소프트웨어 및 시스템 테스트, 도서 및 기사의 기초

ISTQB®는 다른 실체가 이 교과를 다른 목적으로 사용하도록 허용 할 수 있습니다.

사전 서면 허가를 얻으십시오.

0.2 개요

고급 레벨은 세 가지 별도의 강의 계획서로 구성됩니다:

시험 관리자

테스트 분석가

기술 테스트 분석가

고급 수준 개요 문서 [ISTQB_AL_OVIEW]에는 다음 정보가 포함됩니다.

각 강의 계획서의 비즈니스 성과

각 강의 요약

강의 요강 간의 관계

인지 수준 (K 수준)에 대한 설명

부록

0.3 시험 학습 목표

학습 목표는 비즈니스 결과를 지원하며 다음과 같은 목적으로 시험을 작성하는 데 사용됩니다.

Advanced Test Analyst 인증 획득. 일반적으로  이 교과의 모든 부분은 검사 할 수 있습니다.

K1 수준. 즉, 후보자는 용어 나 개념을 인식하고 기억하고 기억할 것입니다. 그만큼

K2, K3 및 K4 레벨의 학습 목표는 해당 장의 시작 부분에 나와 있습니다.

1. 시험 과정 - 300 분.

키워드

구체적인 테스트 케이스, 종료 기준, 상위 레벨 테스트 케이스, 논리적 테스트 케이스, 하위 레벨 테스트 케이스, 테스트 컨트롤,

테스트 설계, 테스트 실행, 테스트 구현, 테스트 계획

테스트 프로세스 학습 목표

1.2 소프트웨어 개발 수명주기 테스트

TA-1.2.1 (K2) 다양한 수명주기 모델로 작업 할 때 테스트 분석가의 참여시기와 수준이 어떻게, 왜 다른지 설명하십시오.

1.3 테스트 모니터링, 계획 및 제어

TA-1.3.1 (K2) 테스트 계획 및 지원을 지원하기 위해 테스트 분석가가 수행 한 활동을 요약합니다.

1.4 시험 분석

TA-1.4.1 (K4) 프로젝트 설명 및 수명주기 모델을 비롯하여 주어진 시나리오를 분석하여 분석 및 디자인 단계에서 테스트 분석가의 적절한 작업을 결정합니다.

1.5 시험 설계

TA-1.5.1 (K2) 테스트 조건을 이해 관계자가 이해해야하는 이유를 설명하십시오

TA-1.5.2 (K4) 프로젝트 시나리오를 분석하여 저수준 (구체적) 및 고수준 (논리적) 테스트 케이스에 가장 적합한 용도를 결정합니다.

1.6 테스트 구현

TA-1.6.1 (K2) 테스트 분석 및 테스트 디자인을위한 일반적인 종료 기준을 설명하고 이러한 기준을 충족시키는 것이 테스트 구현 노력에 어떻게 영향을 미치는지 설명하십시오.

1.7 테스트 실행

TA-1.7.1 (K3) 주어진 시나리오의 경우, 테스트를 실행할 때 취해야 할 단계와 고려 사항을 결정하십시오

1.8 종료 기준 평가 및보고

TA-1.8.1 (K2) 정확한 테스트 사례 실행 상태 정보가 중요한 이유를 설명하십시오

1.9 시험 폐쇄 활동

TA-1.9.1 (K2) 테스트 종료 과정에서 테스트 분석가가 제공해야 하는 작업 제품의 예를 제공합니다.

1.1 서론

ISTQB® Foundation Level 강의 요강에서 기본 테스트 과정은 다음과 같이 설명되었습니다.

다음 활동들 :

l  계획, 모니터링 및 제어

l  분석 및 설계

l  구현 및 실행

l  이탈 기준 평가 및 보고

l  폐쇄 활동 테스트

고급 레벨에서는 이러한 활동 중 일부를 별도로 고려하여

소프트웨어 개발에 더 잘 맞도록 프로세스의 추가 개선 및 최적화

효과적인 테스트 모니터링 및 제어를 용이하게 합니다. 이 레벨의 활동은 다음과 같이 고려된다 :

l  계획, 모니터링 및 제어

l  분석

l  디자인

l  이행

l  실행

l  이탈 기준 평가 및 보고

l  테스트 종료 활동

이러한 활동은 순차적으로 구현 될 수 있거나 또는 일부는 병렬로 구현 될 수 있다. 예를 들어, 구현은 구현과 병행하여 수행 될 수 있다 (예 : 탐색 적 테스트). 올바른 테스트와 테스트 사례를 결정하고, 이를 설계하고 실행하는 것이 테스트 분석가의 주된 집중 영역입니다. 테스트 프로세스의 다른 단계를 이해하는 것이 중요하지만 대부분의 테스트 분석가의 작업은 일반적으로 테스트 프로젝트의 분석, 설계, 구현 및 실행 활동 중에 수행됩니다.

고급 테스터는 이 교과 과정에서 설명한 다양한 테스트 측면을 자체 조직, 팀 및 작업의 컨텍스트에 도입 할 때 많은 어려움에 직면합니다. 이러한 요소가 테스트 접근 방식에 영향을 미칠 수 있으므로 테스트중인 시스템 유형뿐만 아니라 다양한 소프트웨어 개발 수명주기를 고려하는 것이 중요합니다.

 

1.2 소프트웨어 개발 수명주기 테스트

테스트에 대한 장기적인 라이프 사이클 접근법은 테스트 전략의 일부로 고려되고 정의되어야 합니다. 테스트 분석가가 참여하는 순간은 다양한 라이프 사이클마다 다르며 관련 소요 시간, 필요한 정보, 사용 가능한 정보 및 기대치도 매우 다양 할 수 있습니다. 테스트 프로세스가 독립적으로 발생하지 않기 때문에 테스트 분석가는 다음과 같은 다른 관련 조직 영역에 정보를 제공 할 수 있는 지점을 알아야 합니다:

l  요구 엔지니어링 및 관리 - 요구 사항 검토

l  프로젝트 관리 - 일정 입력

l  구성 및 변경 관리 - 빌드 검증 테스트, 버전 관리

l  소프트웨어 개발 - 앞으로 발생할 일 예측

l  소프트웨어 관리 - 결함 관리, 처리 시간 (예 : 결함 발견에서 결함 해결까지의 시간)

l  기술 지원 - 해결 방법에 대한 정확한 문서화

기술 문서 제작 (예 : 데이터베이스 디자인 사양) - 문서의 기술적 검토뿐만 아니라 이 문서에 대한 입력

테스트 활동은 성격이 순차적, 반복적 또는 증분적일 수 있는 선택된 소프트웨어 개발 라이프 사이클 모델과 일치해야 합니다. 예를 들어 순차 V- 모델에서 시스템 테스트 레벨에 적용되는 ISTQB® 기본 테스트 프로세스는 다음과 같이 정렬 될 수 있습니다:

l  시스템 테스트 계획은 프로젝트 계획과 동시에 이루어지며 시스템 테스트 실행 및 종료가 완료 될 때까지 테스트 제어가 계속됩니다.

l  시스템 테스트 분석 및 설계는 요구 사양, 시스템 및 아키텍처 (상위 레벨) 설계 사양 및 구성 요소 (하위 레벨) 설계 사양과 동시에 발생합니다.

l  시스템 설계 환경에서 시스템 테스트 환경 (예 : 테스트 베드, 테스트 리그) 구현은 시스템 디자인 중에 시작될 수 있지만, 일반적으로 코딩 및 구성 요소 테스트와 동시에 발생합니다.

l  시스템 테스트 구현 활동은 시작 전 며칠까지 자주 확장됩니다 시스템 테스트 실행.

l  시스템 테스트 실행은 시스템 테스트 항목 기준이 모두 충족 (또는 철회) 될 때 시작됩니다. 이는 일반적으로 최소한 구성 요소 테스트와 종종 구성 요소 통합 테스트가 완료되었음을 의미합니다.

l  시스템 테스트 종료는 시스템 테스트 종료 기준이 충족 될 때까지 계속됩니다. 시스템 테스트 종료 기준 평가 및 시스템 테스트 결과보고는 시스템 테스트 실행 전반에 걸쳐 발생하며 일반적으로 프로젝트 마감일이 가까워지면 빈도와 긴급도가 커집니다. 시스템 테스트 종료 조건은 시스템 테스트 종료 기준이 충족되고 시스템 테스트 실행이 완료되었다고 선언 된 후에 발생하지만 수락 테스트가 끝나고 모든 프로젝트 활동이 끝날 때까지 지연 될 수 있습니다.

반복 및 증분 모델은 동일한 작업 순서를 따르지 않을 수 있으며 일부 작업을 제외 할 수 있습니다. 예를 들어, 반복 모델은 각 반복마다 표준 테스트 프로세스의 축소 된 세트를 활용할 수 있습니다. 분석 및 설계, 구현 및 실행, 평가 및 보고는 각 반복에 대해 수행 될 수 있지만 계획은 프로젝트 초기에 수행되고 종결 보고서는 끝에서 수행됩니다. 민첩한 프로젝트에서는 덜 형식화 된 프로세스와 프로젝트 내에서 변경 작업을 보다 쉽게 ​​수행 할 수 있는 보다 긴밀한 협력 관계를 사용하는 것이 일반적입니다. 애자일은 "가벼운 무게"프로세스이기 때문에 일일 "일어 서기"회의 ("일어 서기"라고 불림)와 같이 의사 소통 방법이 보다 신속하고 일반적으로 10-15 개 분, 아무도 앉아서 할 필요가 없으며 모든 사람들이 계속 참여합니다).

모든 라이프 사이클 모델 중에서 애자일 프로젝트는 테스트 분석가가 가장 먼저 참여해야 합니다. Test Analyst는 초기 아키텍처 및 디자인 작업을 할 때 개발자와 협력하여 프로젝트 시작부터 참여해야 합니다. 리뷰는 공식화되지 않을 수도 있지만 소프트웨어가 발전함에 따라 계속됩니다. 프로젝트 전반에 참여가 예상되며 테스트 분석가가 팀에 제공되어야 합니다. 이러한 침수로 인해 민첩한 팀 구성원은 보통 단일 프로젝트에만 전념하고 프로젝트의 모든 측면에 완전히 참여합니다.

반복적 / 증분 모델은 소프트웨어가 진화함에 따라 변화가 예상되는 애자일 접근법부터 V- 모델 (반복 임베디드라고도 함) 내에 존재하는 반복적 / 증분 개발 모델에 이르기까지 다양합니다. 반복적 인 모델이 포함 된 경우, 테스트 분석가는 표준 계획 및 설계 측면에 참여할 것으로 예상되지만, 소프트웨어 개발, 테스트, 변경 및 배치와 같이 보다 상호 작용적인 역할로 이동하게 됩니다.

 

사용되는 소프트웨어 개발 라이프 사이클이 무엇이든 관계없이 테스트 분석가가 참여에 대한 기대와 그 참여시기를 이해하는 것이 중요합니다. 위에서 언급 한 V 모델 내에서 반복적으로 사용되는 것과 같은 많은 하이브리드 모델이 사용되고 있습니다. Test Analyst는 적절한 모델링의 순간을 나타내기 위해 세트 모델의 정의에 의존하기보다는 종종 가장 효과적인 역할을 결정하고 이를 위해 노력해야 합니다.

1.3 시험 계획, 모니터링 및 제어

이 절에서는 테스트 계획, 모니터링 및 제어 프로세스에 중점을 둡니다.

1.3.1 시험 계획

대부분의 시험 계획은 시험 노력의 개시 시에 발생하며 시험 전략에서 확인 된 사명과 목표를 달성하는 데 필요한 모든 활동과 자원을 확인하고 계획하는 과정을 포함합니다. 테스트 계획을 진행하는 동안 테스트 관리자와 함께 일하는 테스트 분석가는 다음 사항을 고려하고 계획하는 것이 중요합니다. 테스트 계획이 기능 테스트에만 국한되어 있지 않은지 확인하십시오. 모든 유형의 테스트는 테스트 계획에서 고려되어 그에 따라 스케줄 되어야 합니다. 예를 들어, 기능 테스트 이외에도 테스트 분석가가 사용성 테스트를 담당 할 수 있습니다. 이러한 유형의 테스트는 테스트 계획 문서에서도 다루어야 합니다. 테스트 관리자를 통해 테스트 견적을 검토하고 테스트 환경의 조달 및 유효성 검증을 위한 적절한 시간을 확보하십시오. 구성 테스트 계획. 여러 종류의 프로세서, 운영 체제, 가상 컴퓨터, 브라우저 및 다양한 주변 장치를 여러 가지 구성으로 결합 할 수 있는 경우 이러한 조합을 적절히 적용 할 수 있는 테스트 기술을 적용 할 계획입니다. 문서를 테스트 할 계획을 세우십시오. 사용자에게는 소프트웨어 및 설명서가 제공됩니다. 문서는 유효해야 정확합니다. 테스트 분석가는 문서를 확인하는 데 시간을 할당해야 하며 스크린 샷 및 비디오 클립에 사용할 데이터를 준비하는 데 도움을 줄 수 있도록 기술 담당 직원과 협력해야 할 수도 있습니다. 설치 절차를 테스트하십시오. 설치 절차 및 백업 및 복원 절차는 충분히 테스트 되어야 합니다. 이러한 절차는 소프트웨어보다 더 중요 할 수 있습니다. 소프트웨어를 설치할 수 없으면 전혀 사용되지 않습니다. Test Analyst는 최종 설치 프로세스 없이 사전 구성된 시스템에서 초기 테스트를 수행하기 때문에 계획하기가 어려울 수 있습니다. 소프트웨어 수명주기와 일치하도록 테스트를 계획하십시오. 작업의 순차적 실행은 대부분의 스케줄에 맞지 않습니다. 많은 작업은 종종 (적어도 부분적으로) 동시에 수행되어야 합니다. Test Analyst는 소프트웨어의 설계, 개발 및 구현 과정에서 선택한 수명주기와 참여에 대한 기대치를 알고 있어야 합니다. 여기에는 확인 및 회귀 테스트를 위한 시간 할당도 포함됩니다. 다기능 팀을 통해 위험을 식별하고 분석 할 수 있는 충분한 시간을 확보하십시오. 대개 위험 관리 세션 구성에 대한 책임은 없지만 Test Analyst는 이러한 활동에 적극적으로 참여해야 합니다.

테스트 기반, 테스트 조건 및 테스트 케이스 간에는 복잡한 관계가 존재할 수 있으므로 다 대 다 관계가 이러한 작업 제품간에 존재할 수 있습니다. 테스트 계획 및 제어를 효과적으로 구현할 수 있도록 이해해야 합니다. Test Analyst는 일반적으로 이러한 관계를 확인하고 가능한 한 종속성을 분리하는 데 가장 적합한 사람입니다.

1.3.2 테스트 모니터링 및 제어

테스트 모니터링과 컨트롤은 일반적으로 테스트 관리자의 역할이지만 테스트 분석가는 컨트롤을 가능하게 하는 측정에 기여합니다.

소프트웨어 개발 라이프 사이클 전반에 걸쳐 다양한 양적 데이터 (예 : 완료된 계획 활동의 비율, 달성 된 도달 범위의 백분율, 통과 한 테스트 사례의 수, 실패한 경우)를 수집해야 합니다. 각각의 경우에, 기준선 (즉, 기준 표준)이 정의되어야 하고 이 기준선과 관련하여 진행이 추적되어야 한다. 테스트 관리자는 요약 된 메트릭 정보를 수집하고 보고하는 데 관심이 있지만 테스트 분석가는 각 메트릭에 대한 정보를 수집합니다.

완료된 각 테스트 케이스, 작성된 각 결함 보고서, 달성 된 각 마일스톤은 전체 프로젝트 메트릭으로 롤업됩니다. 다양한 추적 도구에 입력 된 정보가 가능한 정확하게 정확해야 메트릭이 현실을 반영해야 합니다.

정확한 메트릭을 통해 관리자는 프로젝트 (모니터)를 관리하고 필요에 따라 변경 (제어)을 시작할 수 있습니다. 예를 들어, 소프트웨어의 한 영역에서 많은 수의 결함이 보고되면 해당 영역에 추가 테스트 노력이 필요하다는 것을 나타낼 수 있습니다. 요구 사항 및 위험 범위 정보 (추적 가능성)는 남은 작업의 우선 순위를 지정하고 자원을 할당하는 데 사용될 수 있습니다. 근본 원인 정보는 프로세스 개선 영역을 결정하는 데 사용됩니다. 기록 된 데이터가 정확하다면 프로젝트를 제어하고 정확한 상태 정보를 이해 관계자에게 보고 할 수 있습니다. 계획이 과거 프로젝트에서 수집 한 데이터를 고려할 때 향후 프로젝트를 보다 효과적으로 계획 할 수 있습니다. 정확한 데이터에는 수많은 용도가 있습니다. 데이터가 정확하고 시기 적절하며 객관적인지 확인하는 것은 테스트 분석가의 일 중 하나입니다.

 

1.4 시험 분석

테스트 계획 중에 테스트 프로젝트의 범위가 정의됩니다. 테스트 분석가는 이 범위 정의를 사용하여 다음을 수행합니다:

l  테스트 기준 분석

l  테스트 조건 식별

테스트 분석가가 테스트 분석을 통해 효과적으로 진행하려면 다음 항목 기준을 충족해야 합니다:

l  테스트 기준이 될 수 있는 테스트 개체를 설명하는 문서가 있습니다.

l  이 문서는 합리적인 결과와 함께 검토를 통과했으며 필요에 따라 업데이트되었습니다.

l  검토 후 이 시험 대상물에 대한 나머지 시험 작업을 수행하는 데 사용할 수 있는 합리적인 예산과 일정이 있습니다.

테스트 조건은 일반적으로 테스트 기반 및 테스트 목표를 분석하여 식별됩니다. 문서가 오래되었거나 존재하지 않는 경우, 테스트 조건은 관련 이해 관계자 (예: 워크샵 또는 스프린트 계획 중)와 상의하여 식별 할 수 있습니다. 이러한 조건은 테스트 전략 및 / 또는 테스트 계획에서 식별 된 테스트 설계 기술을 사용하여 테스트 할 대상을 결정하는 데 사용됩니다.

테스트 조건은 일반적으로 테스트중인 항목에 따라 다르지만 테스트 분석가에게는 몇 가지 표준 고려 사항이 있습니다.

l  보통 여러 가지 세부 수준에서 테스트 조건을 정의하는 것이 좋습니다. 처음에는 "화면 x의 기능성"과 같은 테스트를 위한 일반적인 목표를 정의하기 위해 높은 수준의 조건이 식별됩니다. 결과적으로 "화면 x는 올바른 길이의 한 자릿수 인 계정 x 호를 거부합니다."와 같은 특정 테스트 케이스의 기초로 더 자세한 조건이 식별됩니다. 이러한 유형의 계층 적 접근 방식을 사용하여 테스트 조건을 정의하면 해당 서비스가 상위 수준 항목에 충분한 지 확인할 수 있습니다.

l  제품 위험이 정의 된 경우 각 제품 위험을 처리하는 데 필요한 테스트 조건을 식별하여 해당 위험 항목까지 추적해야 합니다.

테스트 분석 활동이 끝나면 테스트 분석가는 테스트 프로젝트의 지정된 영역의 요구 사항을 충족시키기 위해 어떤 특정 테스트가 설계되어야 하는지를 알아야 합니다.

 

1.5 시험 설계

테스트 계획 도중 결정된 범위를 유지하면서 테스트 분석가는 구현되고 실행될 테스트를 설계하므로 테스트 프로세스가 계속됩니다. 테스트 설계 프로세스에는 다음과 같은 활동이 포함됩니다:

l  저레벨 (구체적) 또는 고레벨 (논리적) 테스트 케이스가 가장 적합한 테스트 영역을 결정합니다.

l  필요한 테스트 커버리지를 제공하는 테스트 케이스 설계 기술을 결정합니다.

l  식별 된 테스트 조건을 사용하는 테스트 케이스를 작성하십시오

위험 분석 및 테스트 계획 중에 식별 된 우선 순위 결정 기준은 분석 및 설계에서 구현 및 실행에 이르는 프로세스 전반에 걸쳐 적용되어야 합니다.

설계되는 테스트 유형에 따라 테스트 설계의 입력 기준 중 하나는 설계 작업 중에 사용될 툴의 가용성 일 수 있습니다.

테스트를 디자인 할 때 다음 사항을 기억하는 것이 중요합니다:

l  일부 테스트 항목은 스크립팅 된 테스트를 정의하는 것보다 테스트 조건 만 정의하면 더 잘 해결됩니다. 이 경우 테스트 조건은 비 스크립트 테스트의 가이드로 사용되도록 정의해야 합니다.

l  합격 / 불합격 기준은 명확하게 식별되어야 한다.

l  테스트는 저자가 아닌 다른 테스터가 이해할 수 있도록 설계되어야 합니다.

l  작성자가 테스트를 수행하는 사람이 아닌 경우 다른 테스터는 테스트 목적 및 테스트의 상대적 중요성을 이해하기 위해 이전에 지정된 테스트를 읽고 이해해야 합니다.

l  테스트는 개발자와 같은 다른 이해 관계자, 테스트를 검토하는 사람, 테스트를 승인해야 할 수 있는 감사인이 이해할 수 있어야 합니다.

l  테스트는 사용자가 볼 수 있는 인터페이스를 통해 발생하는 상호 작용뿐만 아니라 행위자 (예 : 최종 사용자, 기타 시스템)와 소프트웨어의 모든 상호 작용을 포괄하도록 설계되어야 합니다. 프로세스 간 통신, 배치 실행 및 기타 인터럽트도 소프트웨어와 상호 작용하며 결함을 포함 할 수 있으므로 테스트 분석가는 이러한 위험을 완화하기 위한 테스트를 설계해야 합니다.

l  테스트는 다양한 테스트 객체 간의 인터페이스를 테스트하도록 설계되어야 합니다.

 

1.5.1 콘크리트 및 논리 테스트 케이스

Test Analyst의 직무 중 하나는 주어진 상황에 맞는 최상의 테스트 케이스 유형을 결정하는 것입니다. 구체적인 테스트 케이스는 테스터가 테스트 케이스 (데이터 요구 사항 포함)를 실행하고 결과를 검증하는 데 필요한 모든 특정 정보와 절차를 제공합니다. 구체적인 테스트 사례는 요구 사항이 잘 정의 된 경우, 테스트 직원의 경험이 부족한 경우 및 감사와 같은 테스트의 외부 검증이 필요할 때 유용합니다. 구체적인 테스트 케이스는 우수한 재현성 (즉, 다른 테스터가 동일한 결과를 얻을 수 있음)을 제공하지만 상당한 양의 유지 보수 노력을 필요로 하며 실행 중에 테스터 독창성을 제한하는 경향이 있다.

논리적 테스트 사례는 테스트해야 할 것에 대한 가이드 라인을 제공하지만 테스트 분석가가 실제 데이터 또는 테스트 실행 시 수행되는 절차를 변경시킬 수 있습니다. 논리 테스트 케이스는 실행될 때마다 다소 달라 지므로 구체적인 테스트 케이스보다 더 나은 적용 범위를 제공 할 수 있습니다. 이것은 또한 재현성의 손실로 이어진다. 논리적 테스트 사례는 요구 사항이 잘 정의되어 있지 않은 경우, 테스트를 수행 할 테스트 분석가가 테스트 및 제품 모두에 대해 경험이 있고 정식 문서화가 필요하지 않은 경우 (예: 감사가 수행되지 않을 때) 가장 적합합니다. 논리 테스트 케이스는 요구 사항이 아직 잘 정의되지 않은 경우 요구 사항 프로세스 초기에 정의 될 수 있습니다. 이 테스트 케이스는 요구 사항이 보다 명확하고 안정적으로 될 때 구체적인 테스트 케이스를 개발하는 데 사용될 수 있습니다. 이 경우, 테스트 케이스 생성은 순차적으로 수행되며, 실행을 위해 사용 된 구체적인 테스트 케이스만으로 논리적에서 콘크리트로 흐른다.

 

1.5.2 테스트 케이스의 생성

테스트 케이스는 테스트 전략 및 / 또는 테스트 계획에서 확인 된 테스트 설계 기술 (3 장 참조)을 사용하여 식별 된 테스트 조건을 단계적으로 상세화하고 세분화하여 설계됩니다.

테스트 케이스는 사용되는 테스트 전략에 따라 테스트 기준 (예: 요구 사항)으로 되풀이되고 검증 가능하며 추적 가능해야 합니다.

테스트 사례 설계에는 다음과 같은 사항이 포함됩니다:

l  목표

l  프로젝트 또는 현지화 된 테스트 환경 요구 사항 및 인도 계획, 시스템 상태 등과 같은 목표 전제 조건

l  테스트 데이터 요구 사항 (테스트 사례에 대한 입력 데이터와 테스트 케이스를 실행하기 위해 시스템에 존재해야 하는 데이터)

l  예상 결과

l  영향을 받는 데이터, 시스템 상태, 후속 처리를 위한 트리거 등의 사후 조건.

개발 비용 및 실행 중 재현성 레벨에 모두 영향을 미치는 테스트 케이스의 세부 수준은 실제로 테스트 케이스를 생성하기 전에 정의되어야 합니다. 테스트 케이스에 대한 세부 사항이 적기 때문에 테스트 사례를 실행할 때 테스트 분석가가 더 많은 유연성을 가지게 되고 잠재적으로 흥미로운 영역을 조사 할 수 있는 기회를 제공합니다. 그러나 세부 사항이 적으면 재현성이 낮아지는 경향이 있습니다.

특별한 도전은 종종 테스트의 예상 결과를 정의하는 것입니다. 이것을 수동으로 계산하는 것은 지루하고 오류가 발생하기 쉽습니다. 가능한 경우 자동화 된 테스트 오라클을 찾거나 작성하는 것이 좋습니다. 테스터는 예상 결과를 파악할 때 화면의 출력뿐만 아니라 데이터 및 환경 사후 조건에도 관심이 있습니다. 테스트 기준이 명확하게 정의 된 경우 올바른 결과를 식별하는 것은 이론적으로 간단해야 합니다. 그러나 테스트베이스는 종종 모호하거나 모순되거나 주요 영역의 적용 범위가 부족하거나 완전히 누락되었습니다. 그러한 경우, 시험 분석가는 주제 전문 지식을 보유하고 있거나 접근 할 수 있어야 합니다. 또한 테스트 기준이 명확한 경우에도 복잡한 자극과 반응의 복잡한 상호 작용으로 인해 예상 결과를 정의하는 것이 어려울 수 있습니다. 그러므로 테스트 오라클은 필수적입니다. 결과의 정확성을 판단 할 방법이 없는 테스트 사례의 실행은 부가 가치 또는 이점이 매우 낮으므로 종종 시스템에 허위 오류 보고서 또는 잘못된 신뢰를 생성합니다.

위에서 설명한 활동은 테스트 기준이 다를지라도 모든 테스트 레벨에 적용될 수 있습니다. 예를 들어 사용자 수용 테스트는 주로 요구 사항 사양, 사용 사례 및 정의 된 비즈니스 프로세스를 기반으로 할 수 있지만 구성 요소 테스트는 주로 하위 수준 디자인 사양, 사용자 사례 및 코드 자체를 기반으로 할 수 있습니다. 테스트의 대상은 다를 수 있지만 이러한 활동은 모든 테스트 레벨에서 발생한다는 것을 기억하는 것이 중요합니다. 예를 들어, 단위 수준의 기능 테스트는 특정 구성 요소가 해당 구성 요소의 세부 설계에 지정된 기능을 제공하도록 설계되었습니다. 통합 수준에서의 기능 테스트는 구성 요소가 상호 작용하고 상호 작용을 통해 기능을 제공하는지 확인하는 것입니다. 시스템 수준에서 종단 간 기능은 테스트의 대상이 되어야 합니다. 테스트를 분석하고 설계 할 때는 테스트의 목표 레벨뿐 아니라 테스트의 목표 레벨을 기억하는 것이 중요합니다. 이는 필요할 수 있는 세부 수준과 필요한 도구 (예 : 구성 요소 테스트 수준의 드라이버 및 스텁)를 결정하는 데 도움이 됩니다.

테스트 조건과 테스트 케이스가 개발되는 동안, 일반적으로 문서 작업이 생성되어 테스트 작업 제품이 만들어집니다. 실제로 시험 작업 제품이 문서화되는 정도는 상당히 다양합니다.

l  프로젝트 위험 (문서화되어야하는 /해야 할 것).

l  문서가 프로젝트에 가져 오는 "부가가치".

l  준수해야 할 표준 및 / 또는 규정.

l  사용 된 라이프 사이클 모델 (예 : 민첩한 접근 방식은 "충분한 문서"를 목표로합니다).

테스트 기반에서 테스트 분석 및 디자인을 통한 추적 가능성 요구 사항

테스트 범위에 따라 테스트 분석 및 디자인은 테스트 개체의 품질 특성을 다룹니다. ISO 25000 표준 [ISO25000] (ISO 9126을 대체)은 유용한 참조를 제공합니다. 하드웨어 / 소프트웨어 시스템을 테스트 할 때 추가 특성이 적용될 수 있습니다.

테스트 분석 및 테스트 디자인 프로세스는 검토 및 정적 분석과 얽혀서 향상 될 수 있습니다. 사실, 테스트 분석 및 테스트 디자인을 수행하는 것은 정적 테스트의 한 형태 인 경우가 종종 있기 때문에 이 프로세스 동안 기본 문서에서 문제가 발견 될 수 있습니다. 요구 사항 사양을 기반으로 하는 테스트 분석 및 테스트 디자인은 요구 사항 검토 회의를 준비하는 훌륭한 방법입니다. 테스트를 작성하기 위해 요구 사항을 읽으려면 요구 사항을 이해하고 요구 사항을 충족시키는 방법을 결정할 수 있어야 합니다. 이 활동은 명확하지 않거나, 검증 할 수 없거나, 수용 기준을 정의하지 않은 요구 사항을 종종 발견합니다. 마찬가지로 테스트 케이스, 위험 분석 및 테스트 계획과 같은 테스트 작업 제품은 검토를 받아야 합니다.

민첩한 라이프 사이클을 따르는 프로젝트와 같은 일부 프로젝트는 요구 사항을 최소한으로 문서화했을 수 있습니다. 이들은 때로는 기능의 작지만 시연 할 수 있는 비트를 설명하는 "사용자 스토리"의 형태입니다. 사용자 이야기에는 수용 기준의 정의가 포함되어야 합니다. 소프트웨어가 수용 기준을 충족했다는 것을 입증 할 수 있다면 일반적으로 다른 완성 된 기능과 통합 할 준비가 되어 있거나 기능을 입증하기 위해 이미 통합되었을 수 있습니다.

테스트 설계 중에 필요한 세부적인 테스트 인프라 요구 사항을 정의 할 수 있지만 실제로는 테스트 구현이 완료 될 때까지는 완료되지 않을 수도 있습니다. 테스트 인프라에는 테스트 객체 및 테스트웨어 이상의 것을 포함해야 한다는 것을 기억해야 합니다. 예를 들어, 인프라 요구 사항에는 회의실, 장비, 인력, 소프트웨어, 도구, 주변 장치, 통신 장비, 사용자 권한 및 테스트를 실행하는 데 필요한 기타 모든 항목이 포함될 수 있습니다.

테스트 분석 및 테스트 디자인의 종료 기준은 프로젝트 매개 변수에 따라 다르지만 이 두 섹션에서 논의 된 모든 항목은 정의 된 종료 기준에 포함되도록 고려되어야 합니다. 기준을 측정 할 수 있어야 하고 후속 단계에 필요한 모든 정보와 준비가 제공되었는지 확인하는 것이 중요합니다.

 

1.6 테스트 구현

테스트 구현은 테스트 디자인의 완성입니다. 여기에는 자동화 된 테스트 작성, 테스트 순서 (수동 및 자동) 테스트 순서, 테스트 데이터 및 테스트 환경 완성, 리소스 할당을 포함한 테스트 실행 일정 작성 등이 포함되어 테스트 사례 실행을 시작할 수 있습니다. 여기에는 해당 테스트 레벨에 대한 명시 적 및 암시 적 항목 기준을 확인하고 프로세스의 이전 단계에 대한 종료 기준이 충족되었는지 확인하는 것도 포함됩니다. 테스트 레벨이나 테스트 프로세스의 한 단계에 대한 종료 기준을 건너 뛰면 지연된 일정, 불충분 한 품질 및 예상치 못한 추가 노력으로 인해 구현 노력이 영향을 받을 수 있습니다. 테스트 구현 노력을 시작하기 전에 모든 종료 기준이 충족되었는지 확인하는 것이 중요합니다.

실행 순서를 결정할 때 많은 고려 사항이 있을 수 있습니다. 경우에 따라 테스트 케이스를 테스트 스위트 (즉, 테스트 케이스 그룹)로 구성하는 것이 좋습니다. 이렇게 하면 관련 테스트 케이스가 함께 실행되도록 테스트를 구성하는 데 도움이 됩니다. 위험 기반 테스트 전략을 사용하는 경우 위험 우선 순위에 따라 테스트 사례의 실행 순서가 결정될 수 있습니다. 적합한 인력, 장비, 데이터 및 테스트 할 기능의 가용성과 같은 주문을 결정하는 다른 요소가 있을 수 있습니다. 코드가 섹션에서 발표되는 것은 드문 일이 아니며 테스트 노력은 소프트웨어를 테스트 할 수 있는 순서에 따라 조정해야 합니다. 특히 점진적인 라이프 사이클 모델에서는 테스트 분석가가 개발 팀과 협력하여 소프트웨어를 테스트 가능한 순서로 테스트하기 위해 릴리스하는 것이 중요합니다.

테스트 구현 중에 테스트 분석가는 수동 및 자동 테스트를 실행하는 순서를 확정하고 확인해야 하며 테스트가 특정 순서로 실행되어야 하는 제약 조건을 주의 깊게 확인해야 합니다. 종속성을 문서화하고 확인해야 합니다.

테스트 구현 중에 수행 된 작업의 세부 수준 및 관련 복잡성은 테스트 사례 및 테스트 조건의 세부 사항에 의해 영향을 받을 수 있습니다. 경우에 따라 규제 규칙이 적용되며 테스트는 미국 연방 항공국 (Federal Aviation Administration)의 DO-178B / ED 12B [RTCA DO-178B / ED-12B]와 같은 적용 가능한 표준에 대한 증거를 제공해야 합니다.

위에 지정된 대로 테스트 데이터가 테스트에 필요하며 경우에 따라 이러한 데이터 집합이 상당히 클 수 있습니다. 구현하는 동안 Test Analyst는 입력 데이터 및 환경 데이터를 만들어 데이터베이스 및 기타 리포지토리에 로드합니다. Test Analyst는 수동 테스트뿐만 아니라 데이터 기반 자동화 테스트에도 사용할 데이터를 생성합니다.

테스트 구현은 테스트 환경에도 관련됩니다. 이 단계에서 환경을 테스트 실행 전에 완전히 설정하고 검증해야 합니다. "목적에 맞는"테스트 환경은 필수적입니다. 즉, 테스트 환경은 제어 테스트 중에 존재하는 결함의 노출을 가능하게 하고, 실패가 발생하지 않을 때 정상적으로 작동하며, 필요한 경우 생산 또는 엔드를 적절히 복제 할 수 있어야 합니다 높은 수준의 테스트를 위한 사용자 환경 예상치 못한 변경, 테스트 결과 또는 기타 고려 사항에 따라 테스트 실행 중에 테스트 환경 변경이 필요할 수 있습니다. 실행 중에 환경 변화가 발생하면 이미 실행 된 테스트에 대한 변경의 영향을 평가하는 것이 중요합니다.

테스트 구현 중에 테스터는 테스트 환경의 생성 및 유지 보수 담당자가 알려지고 사용 가능하고 모든 테스트웨어 및 테스트 지원 도구 및 관련 프로세스를 사용할 준비가 되었는지 확인해야 합니다. 여기에는 구성 관리, 결함 관리 및 테스트 로깅 및 관리가 포함됩니다. 또한, 테스트 분석가는 종료 기준 평가 및 테스트 결과보고를 위해 데이터를 수집하는 절차를 검증해야 합니다.

테스트 계획 중에 결정된 대로 테스트 구현에 균형 잡힌 접근 방식을 사용하는 것이 좋습니다. 예를 들어, 위험 기반 분석 테스트 전략은 종종 동적 테스트 전략과 혼합됩니다. 이 경우 테스트 구현 노력의 일정 비율은 미리 결정된 스크립트 (비 스크립트)를 따르지 않는 테스트에 할당됩니다.

비 스크립트 테스트는 임시 또는 목적이 없어야 합니다. 왜냐하면 시간이 포장되고 공인 된 경우가 아니면 예측할 수 없기 때문입니다. 수년 동안 테스터는 공격, 오류 추측 [Myers79] 및 탐색 적 테스트와 같은 다양한 경험 기반 기술을 개발했습니다. 테스트 분석, 테스트 디자인 및 테스트 구현은 여전히 ​​발생하지만 테스트 실행 중에 주로 발생합니다.

이러한 동적 테스트 전략을 따를 때, 각 테스트의 결과는 후속 테스트의 분석, 디자인 및 구현에 영향을 미칩니다. 이러한 전략은 가볍고 결함을 찾는 데 종종 효과적이지만 몇 가지 단점이 있습니다. 이러한 기술을 사용하려면 테스트 분석가의 전문 지식이 필요하고, 기간을 예측하기 어려울 수 있고, 추적하기가 어려울 수 있으며, 문서 또는 도구 지원 없이는 반복성을 잃을 수 있습니다.

 

1.7 테스트 실행

테스트 객체가 전달되고 실행을 테스트 하기 위한 입력 조건이 충족되면 테스트 실행이 시작됩니다.

만족 (또는 포기). 테스트는 테스트 중에 결정된 계획에 따라 실행되어야 합니다.

테스트 분석가는 추가 구현을 보장 할 수 있는 적절한 시간을 가져야 합니다.

테스트 중에 관찰되는 흥미로운 테스트 시나리오 및 동작 (

그러한 편차는 다음과 같은 스크립트 된 테스트 케이스의 변형을 포함하여 설명되어야 한다.

실패를 재현하는 데 필요한). 스크립트와 비 스크립트 (예 : 탐색)

테스트 기술은 스크립팅 된 커버리지의 차이로 인한 테스트 이스케이프를 방지하고 살충제 역설을 우회한다.

테스트 실행 활동의 핵심은 실제 결과와 예상 결과를 비교하는 것입니다. 테스트 분석가는 이러한 작업에주의를 기울이고 집중해야합니다. 그렇지 않으면 실패를 놓치거나 (false-negative 결과) 올바른 동작을 잘못 (false-positive 결과)으로 잘못 분류하면 테스트를 설계하고 구현하는 모든 작업이 낭비 될 수 있습니다. 예상 결과와 실제 결과가 일치하지 않으면 사고가 발생했습니다. 인시던트는 인시던트 (테스트 객체의 결함 일 수도 있고 아닐 수도 있음)를 결정하고 인시던트 해결을 돕기위한 데이터를 수집하기 위해 면밀히 조사되어야합니다 (결함 관리에 대한 자세한 내용은 6 장 참조).

오류가 확인되면 테스트 문서 (테스트 명세, 테스트 케이스 등)를 신중하게 검토하여 정확성을 보장해야합니다. 테스트 문서는 여러 가지 이유로 부정확 할 수 있습니다. 올바르지 않은 경우 수정해야하며 테스트를 다시 실행해야합니다. 테스트가 성공적으로 여러 번 실행 된 후에도 테스트 기초와 테스트 객체를 변경하면 테스트 사례가 잘못 될 수 있으므로 테스터는 부정확 한 테스트로 인해 관찰 된 결과가 발생할 가능성을 계속 인식해야합니다.

테스트 실행 중에는 테스트 결과를 적절히 기록해야합니다. 실행되었지만 결과가 기록되지 않은 테스트는 올바른 결과를 식별하기 위해 반복되어야 할 수 있으므로 비효율 성과 지연이 발생할 수 있습니다. 적절한 로깅은 탐색 테스트와 같은 테스트 기술과 관련된 적용 범위 및 반복 가능성 문제를 해결할 수 있습니다. 테스트 개체, 테스트웨어 및 테스트 환경이 모두 진화 할 수 있으므로 로깅은 테스트 한 특정 버전과 특정 환경 구성을 식별해야합니다 . 테스트 로깅은 테스트 실행에 대한 관련 세부 정보의 시간순 기록을 제공합니다.

결과 로깅은 개별 테스트와 활동 및 이벤트에 모두 적용됩니다. 각 테스트는 고유하게 식별되어야하며 테스트 실행이 진행됨에 따라 해당 상태가 기록됩니다. 테스트 실행에 영향을 미치는 모든 이벤트가 기록되어야합니다. 테스트 적용 범위를 측정하고 테스트 지연 및 중단 원인을 문서화하기위한 충분한 정보를 기록해야합니다. 또한 테스트 제어, 테스트 진행보고, 종료 기준 측정 및 테스트 프로세스 개선을 지원하는 정보가 기록되어야합니다.

로깅은 테스트의 수준과 전략에 따라 다릅니다. 예를 들어 자동화 된 구성 요소 테스트가 수행되는 경우 자동화 된 테스트는 대부분의 로깅 정보를 생성해야합니다. 수동 테스트가 수행되는 경우 테스트 분석가는 테스트 실행 정보를 추적하는 테스트 관리 도구에 테스트 실행 관련 정보를 기록합니다. 일부 경우 테스트 구현과 마찬가지로 기록 된 테스트 실행 정보의 양은 규제 또는 감사 요구 사항의 영향을받습니다.

어떤 경우에는 사용자 또는 고객이 테스트 실행에 참여할 수 있습니다. 이것은 시스템에 대한 자신감을 형성하는 방법으로 작용할 수 있습니다.하지만 테스트에서 결함이 거의 없다고 가정합니다. 이러한 가정은 초기 시험 단계에서는 종종 유효하지 않지만 수락 시험 중에는 유효 할 수 있습니다.

다음은 테스트 실행 중에 고려해야 할 몇 가지 특정 영역입니다. "관련성이없는"이상한 점을 알리고 탐구 해보십시오. 관련성이 없어 보일 수있는 관찰이나 결과는 종종 빙산처럼 표면 아래에 숨어있는 결함에 대한 지표입니다. 제품이하기로되어 있지 않은 일을하고 있지 않은지 확인하십시오. 제품이 정상적으로 수행되는지 확인하는 것은 정상적인 테스트의 초점이지만 테스트 분석가는 제품이 수행해서는 안되는 작업 (예 : 원하지 않는 추가 기능)을 수행하여 오작동이 발생하지 않았는지 확인해야합니다. 테스트 스위트를 빌드하고 시간이 지남에 따라 확장 및 변경 될 것으로 기대하십시오. 코드는 발전 할 것이고 소프트웨어의 다른 영역에서의 회귀를 점검 할뿐만 아니라 이러한 새로운 기능을 다루기 위해 추가 테스트가 구현되어야 할 것입니다. 테스트의 갭은 종종 실행 중에 발견됩니다. 테스트 슈트 구축은 지속적인 프로세스입니다.

l  다음 테스트 노력을 기록해 두십시오. 소프트웨어가 있을 때 테스트 작업이 끝나지 않습니다. 소프트웨어의 새 버전이나 릴리스가 생성 될 가능성이 높으므로 지식을 저장하고 다음 테스트 작업을 담당하는 테스터에게 전달해야 합니다.

l  모든 수동 검사를 재실행하지 마십시오. 모든 수동 검사가 재실행 될 것으로 예상하는 것은 비현실적입니다. 문제가 의심되는 경우, 시험 분석가는 그것을 조사하고 시험 사례의 후속 실행에서 발견 될 것이라고 생각하기 보다는 이를 기록해야 합니다.

l  추가 테스트 사례를 위해 결함 추적 도구에서 데이터를 마이닝하십시오. 비 스크립트 또는 탐색 테스트 중에 발견 된 결함에 대한 테스트 케이스를 작성하여 회귀 테스트 스위트에 추가하는 것이 좋습니다.

l  회귀 테스트 전에 결함을 찾으십시오. 회귀 테스트의 경우 시간이 제한적이고 회귀 테스트 중에 실패를 발견하면 일정이 지연 될 수 있습니다. 회귀 테스트는 일반적으로 많은 부분을 찾지 못한다. 이는 이미 실행 된 테스트 (예: 동일한 소프트웨어의 이전 버전)이기 때문에 이전 결함에서 결함이 발견 된 것이기 때문이다. 이것은 회귀 테스트를 모두 제거해야 한다는 의미는 아니며, 새로운 결함을 감지 할 수 있는 능력에 대한 회귀 테스트의 효과가 다른 테스트보다 낮다는 의미입니다.

 

1.8 종료 기준 평가 및 보고

테스트 프로세스의 관점에서 테스트 진행 모니터링은 보고 요구 사항을 지원하기 위한 적절한 정보 수집을 보장합니다. 여기에는 완료를 향한 진행 상황이 포함됩니다. 퇴장 기준이 계획 단계에서 정의되면 "필수"및 "필수"기준이 분류 될 수 있습니다. 예를 들어, "열려있는 우선 순위 1 또는 우선 순위 2의 버그가 없어야 합니다"라는 조건과 "모든 테스트 케이스에서 95 %의 합격률이 있어야 합니다"라는 조건이 있을 수 있습니다. 이 경우 "필수"기준을 충족시키지 못하면 종료 기준이 실패해야 하지만 93 %의 합격률로 프로젝트가 다음 단계로 진행될 수 있습니다. 이탈 기준은 객관적으로 평가 될 수 있도록 명확하게 정의되어야 합니다.

테스트 분석가는 종료 기준 충족에 대한 진행 상태를 평가하고 데이터가 정확한지 확인하기 위해 테스트 관리자가 사용하는 정보를 제공합니다. 예를 들어, 테스트 관리 시스템이 테스트 케이스 완료를 위해 다음과 같은 상태 코드를 제공하면 :

l  Passed

l  Failed

l  Passed with exception

테스트 분석가는 이러한 각각의 의미에 대해 매우 명확해야 하며 일관되게 해당 상태를 적용해야 합니다. "예외와 함께 전달"이란 결함이 발견되었지만 시스템의 기능에 영향을 미치지 않는다는 의미입니다. 사용자가 혼란스럽게 만드는 유용성 결함은 어떻습니까? 합격률이 "필수"종료 기준 인 경우 테스트 케이스를 "예외로 전달"하지 않고 "실패"로 계산하는 것이 중요한 요소가 됩니다. 또한 "실패"로 표시된 테스트 사례에 대한 고려가 있어야 하지만 실패의 원인은 결함이 아닙니다 (예 : 테스트 환경이 부적절하게 구성됨). 추적중인 메트릭이나 상태 값의 사용에 혼란이 있으면 테스트 분석가가 테스트 관리자와 명확히 구분하여 프로젝트 전체에서 정보를 정확하고 일관되게 추적 할 수 있도록 해야 합니다.

테스트 분석가가 테스트주기 중에 상태 보고서를 요청할 뿐만 아니라 테스트가 끝날 때 최종 보고서에 기여하는 것도 드문 일이 아닙니다. 이를 위해서는 결점 및 테스트 관리 시스템에서 측정 기준을 수집하고 전반적인 범위와 진행 상황을 평가해야 할 수 있습니다. Test Analyst는 보고 도구를 사용할 수 있어야 하며 필요한 정보를 추출하기 위해 Test Manager에 요청 된 정보를 제공 할 수 있어야 합니다.

1.9 시험 종료 활동

테스트 실행이 완료되면 테스트 작업의 주요 출력을 캡처하여 관련 사용자에게 전달하거나 보관해야 합니다. 집합 적으로 이들은 테스트 클로저 활동입니다. Test Analyst는 필요로 하는 사람들에게 업무용 제품을 제공하는 데 참여해야 합니다. 예를 들어, 지연되거나 수락 된 알려진 결함은 시스템 사용을 사용하고 지원하는 사람들에게 전달되어야 합니다. 테스트 및 테스트 환경은 유지 보수 테스트 담당자에게 제공되어야 합니다. 다른 작업 산출물은 회귀 테스트 세트 (자동 또는 수동) 일 수 있습니다. 테스트 작업 제품에 대한 정보는 적절한 링크를 포함하여 명확하게 문서화 되어야 하며 적절한 액세스 권한이 부여되어야 합니다.

또한 시험 분석가는 시험 프로젝트 내에서 그리고 전체 소프트웨어 개발 수명주기 전반에 걸친 중요한 교훈을 문서화하고 계획을 수립하고 계획을 수립하여 소위 "강화 된"소위원회 회의에 참여할 것을 기대해야 합니다 ( "교훈"). 또는 적어도 통제, "나쁜". Test Analyst는 이러한 회의에 대한 정보를 제공하는 지식이 풍부하며 올바른 프로세스 개선 정보를 수집해야 하는 경우 참여해야 합니다. 테스트 관리자 만 회의에 참석하는 경우 테스트 분석가는 해당 정보를 테스트 관리자에게 전달하여 프로젝트의 정확한 그림을 제공해야 합니다.

구성 관리 시스템에서 결과, 로그, 보고서 및 기타 문서 및 작업 제품을 보관해야 합니다. 이 작업은 종종 테스트 분석가에게 맡겨지며, 특히 향후 프로젝트에서 이 정보를 사용해야 하는 경우 중요한 폐쇄 활동입니다.

테스트 관리자는 일반적으로 어떤 정보를 보관해야 할지 결정하지만 테스트 분석가는 프로젝트가 나중에 다시 시작될 경우 필요한 정보가 무엇인지 생각해야 합니다. 프로젝트가 끝날 때 이 정보를 생각하면 프로젝트가 나중에 다시 시작되거나 다른 팀과 함께 시작될 때 수개월의 노력을 줄일 수 있습니다.

2. 테스트 관리 : 테스트 분석가의 책임

- 90 분.

키워드

제품 위험, 위험 분석, 위험 식별, 위험 수준, 위험 관리, 위험 완화, 위험 기반 테스트, 테스트 모니터링, 테스트 전략

테스트 관리를위한 학습 목표 : 테스트 분석가를 위한 책임

2.2 테스트 진행 모니터링 및 제어

TA-2.2.1 (K2) 프로젝트를 적절히 모니터링하고 제어 할 수 있도록 테스트 중에 추적해야 하는 정보 유형을 설명하십시오.

2.3 분산, 아웃소싱, 인소싱 테스트

TA-2.3.1 (K2) 24 시간 테스트 환경에서 작업 할 때 훌륭한 의사 소통 사례를 제공하십시오.

2.4 위험 기반 테스팅의 테스트 분석가 작업

TA-2.4.1 (K3) 주어진 프로젝트 상황에 대해 위험 식별에 참여하고 위험 평가를 수행하며 적절한 위험 완화를 제안하십시오.

2.1 소개

테스트 분석가가 테스트 관리자와 상호 작용하고 데이터를 제공하는 많은 영역이 있지만 이 섹션에서는 테스트 분석가가 주요 기여자 인 테스트 프로세스의 특정 영역에 중점을 둡니다. 테스트 매니저는 테스트 분석가가 필요로 하는 정보를 찾을 것으로 예상됩니다.

 

2.2 테스트 진행 모니터링 및 제어

테스트 진행 상황을 모니터링 하는 데는 5 가지 기본 차원이 있습니다.

l  제품 (품질) 위험

l  결함

l  테스트

l  적용 범위

l  자신

테스트 위험 분석가가 프로젝트 또는 운영 중에 제품 위험, 결함, 테스트 및 적용 범위를 측정하고 보고하는 경우가 있습니다. 설문 조사를 통해 측정 할 수는 있지만 자신감은 보통 주관적으로 보고됩니다. 이러한 측정 항목을 지원하는 데 필요한 정보를 수집하는 것은 테스트 분석가의 일상 업무 중 일부입니다. 부정확 한 데이터가 부정확 한 추세 정보를 생성하고 부정확 한 결론으로 ​​이어질 수 있으므로 이 데이터의 정확성은 중요합니다. 최악의 경우, 부정확 한 데이터는 부정확 한 관리 결정 및 테스트 팀의 신뢰성 손상을 가져옵니다.

위험 기반 테스트 접근법을 사용할 때 테스트 분석가는 다음을 추적해야 합니다:

l  테스트를 통해 완화 된 위험

l  완화되지 않은 것으로 간주되는 위험

추적 위험 완화는 종종 테스트 완료를 추적하는 도구 (예 : 테스트 관리 도구)를 사용하여 수행됩니다. 이를 위해서는 식별 된 리스크가 테스트 사례가 실행되고 통과 될 경우 위험을 완화하는 테스트 사례에 매핑되는 테스트 조건에 매핑되어야 합니다. 이러한 방식으로 위험 완화 정보는 테스트 케이스가 업데이트 될 때 자동으로 업데이트됩니다. 수동 및 자동 테스트 모두 가능합니다.

결함 추적은 일반적으로 결함 추적 도구를 통해 수행됩니다. 결함이 기록되면 각 결함에 대한 특정 분류 정보도 기록됩니다. 이 정보는 테스트 진행 및 소프트웨어 품질을 나타내는 경향 및 그래프를 생성하는 데 사용됩니다. 분류 정보는 결함 관리 장에서보다 자세히 설명됩니다. 수명주기는 기록 된 결함 문서의 양과 정보를 기록하는 데 사용 된 방법에 영향을 미칠 수 있습니다.

테스트가 수행됨에 따라 테스트 케이스 상태 정보가 기록되어야 합니다. 이것은 대개 테스트 관리 도구를 통해 수행되지만 필요할 경우 수동으로 수행 할 수 있습니다:

l  테스트 케이스 작성 상태 (예: 설계, 검토)

l  테스트 케이스 실행 상태 (예: 통과, 실패, 차단, 건너 뛰기)

l  테스트 케이스 실행 정보 (예 : 날짜 및 시간, 테스터 이름, 사용 된 데이터)

l  테스트 사례 실행 아티팩트 (예 : 스크린 샷, 로그 포함)

식별 된 위험 항목과 마찬가지로, 테스트 케이스는 테스트하는 요구 사항 항목에 매핑되어야 한다. 테스트 분석가는 테스트 사례 A가 요구 사항 A에 매핑되고 해당 요구 사항에 매핑 된 유일한 테스트 사례 인 경우 테스트 사례 A가 실행되고 통과 할 때 요구 사항 A가 충족 된 것으로 간주된다는 것을 기억해야 합니다. 이것은 정확하지 않을 수도 있습니다

많은 경우 요구 사항을 철저히 테스트하기 위해 더 많은 테스트 사례가 필요하지만 제한된 시간으로 인해 실제로는 이러한 테스트의 하위 집합 만 만들어집니다. 예를 들어 요구 사항의 구현을 철저하게 테스트하기 위해 20 가지 테스트 케이스가 필요하지만 10 개만 생성되어 실행되는 경우 사실상 50 % 적용 범위에 도달하면 요구 사항 범위 정보가 100 % 적용 범위를 나타냅니다. 커버리지를 정확하게 추적하고 요구 사항 자체의 검토 상태를 추적하는 것은 신뢰 측정으로 사용될 수 있습니다.

기록 할 정보의 양 (및 세부 수준)은 소프트웨어 개발 수명주기 모델을 비롯한 여러 요소에 따라 다릅니다. 예를 들어, 민첩한 프로젝트의 경우 일반적으로 팀의 긴밀한 상호 작용과 더 많은 대면 커뮤니케이션으로 인해 상태 정보가 적게 기록됩니다.

 

2.3 분산, 아웃소싱, 인소싱 테스트

많은 경우, 모든 테스트 노력이 나머지 프로젝트 팀의 동료 직원으로 구성된 단일 테스트 팀에 의해 나머지 프로젝트 팀과 동일한 위치에서 수행됩니다. 테스트 노력이 여러 위치에서 발생하면 해당 테스트 노력을 분산이라고 합니다. 단일 위치에서 발생하는 경우 중앙 집중식이라고 할 수 있습니다. 테스트 노력이 나머지 프로젝트 팀의 동료 직원이 아니고 프로젝트 팀과 같은 위치에 있지 않은 사람들에 의해 하나 이상의 위치에서 수행되는 경우 해당 테스트 노력은 아웃소싱이라고 할 수 있습니다. 테스트 노력이 프로젝트 팀과 함께 있지만 동료 직원이 아닌 사람들에 의해 수행되는 경우 해당 테스트 노력은 인소싱이라고 할 수 있습니다.

일부 테스트 팀이 여러 위치 또는 여러 회사에 분산되어있는 프로젝트에서 작업 할 때, 테스트 분석가는 효율적인 의사 소통 및 정보 전달에 특별한주의를 기울여야 합니다. 일부 조직에서는 한 시간대의 팀이 24 시간 내내 테스트를 계속할 수 있도록 다른 시간대의 팀에게 작업을 전달할 것으로 예상되는 "24 시간 테스트"모델을 사용합니다. 이를 위해서는 테스트 분석가가 작업을 양도하고 받을 사람에 대한 특별한 계획이 필요합니다. 책임을 이해하기 위해서는 계획을 세우는 것이 중요하지만 적절한 정보를 얻을 수 있도록 하는 것이 중요합니다.

구두 의사 소통이 가능하지 않은 경우 서면 통신으로 충분해야 합니다. 즉, 전자 메일, 상태 보고서 및 테스트 관리 및 결함 추적 도구의 효과적인 사용을 채택해야 합니다. 테스트 관리 도구를 사용하여 개인에게 테스트를 할당 할 수 있다면 일정 잡기 도구로 사용할 수 있고 사람 간 작업을 손쉽게 전송할 수 있습니다. 정확하게 기록 된 결함은 필요에 따라 동료에게 전달 될 수 있습니다. 이러한 통신 시스템의 효과적인 사용은 일상적인 개인적인 상호 작용에 의존 할 수 없는 조직에게 필수적입니다.

 

2.4 위험 기반 테스팅의 테스트 분석가 작업

2.4.1 개요

Test Manager는 종종 리스크 기반 테스트 전략 수립 및 관리에 대한 전반적인 책임이 있습니다. Test Manager는 일반적으로 리스크 기반 접근 방식이 올바르게 구현되었는지 확인하기 위해 Test Analyst의 참여를 요청합니다.

Test Analyst는 다음과 같은 위험 기반 테스트 작업에 적극적으로 참여해야합니다:

l  위험 식별

l  위험 평가

l  위험 완화

이러한 작업은 새로운 위험을 처리하고 우선 순위를 변경하며 위험 상태를 정기적으로 평가하고 전달하기 위해 프로젝트 라이프 사이클 전체에서 반복적으로 수행됩니다.

테스트 분석가는 프로젝트의 테스트 관리자가 수립 한 위험 기반 테스트 프레임 워크 내에서 작업해야 합니다. 그들은 안전, 사업 및 경제 문제와 관련된 위험 및 정치적 요인과 같은 위험 요소와 같은 프로젝트에 내재 한 비즈니스 영역 위험에 대한 지식을 제공해야 합니다.

 

2.4.2 위험 확인

가능한 가장 광범위한 이해 관계자 샘플을 호출함으로써 위험 식별 프로세스는 가능한 가장 큰 수의 주요 위험을 감지 할 가능성이 가장 큽니다. Test Analyst는 종종 테스트중인 시스템의 특정 비즈니스 도메인에 대한 고유 한 지식을 보유하고 있기 때문에 특히 도메인 전문가 및 사용자와의 전문가 인터뷰, 독립적 인 평가 수행, 위험 템플릿 사용  및 촉진, 위험 수행 잠재 고객 및 현 사용자와의 브레인 스토밍 세션 실시, 테스트 체크리스트 정의 및 유사한 시스템 또는 프로젝트에 대한 과거 경험 요청 특히 테스트 분석가는 테스트 과정에서 해결해야 하는 비즈니스 위험 영역을 파악하기 위해 사용자 및 기타 도메인 전문가와 긴밀히 협력해야 합니다. 또한 테스트 분석가는 특히 위험이 사용자와 이해 관계자에게 미칠 수 있는 영향을 파악하는 데 도움이 될 수 있습니다.

프로젝트에서 식별 될 수 있는 샘플 위험 요소는 다음과 같습니다:

l  소프트웨어 기능의 정확성 문제 (예 : 잘못된 계산)

l  사용 편의성 문제 (예 : 키보드 단축키 부족)

l  학습 가능성 문제 (예 : 주요 의사 결정 지점에서 사용자에게 지침이 없음)

특정 품질 특성을 테스트하는 것에 대한 고려 사항은 이 강의 계획서의 4 장에서 다룹니다.

 

2.4.3 위험 평가

위험 식별은 가능한 많은 위험을 식별하는 것이지만, 위험 평가는 이러한 확인 된 위험을 연구하는 것입니다. 특히 각 위험을 분류하고 각 위험과 관련된 가능성 및 영향을 결정합니다.

위험 수준 결정에는 일반적으로 각 위험 항목에 대해 발생할 가능성과 발생시 영향을 평가해야 합니다. 발생 가능성은 일반적으로 잠재적 인 문제가 테스트중인 시스템에 존재할 수 있고 시스템이 생산 중에 있을 때 관찰 될 가능성으로 해석됩니다. 즉, 기술적 인 위험으로부터 발생합니다. 기술 분석 분석가는 각 위험 항목의 잠재적 인 기술적 위험 수준을 파악하고 이해하는 데 기여해야 하지만 테스트 분석가는 문제의 잠재적 인 비즈니스 영향을 이해하는 데 기여합니다.

발생시의 영향은 종종 사용자, 고객 또는 기타 이해 관계자에게 미치는 영향의 심각도로 해석됩니다. 즉, 비즈니스 위험으로부터 발생합니다. Test Analyst는 각 위험 항목에 대한 잠재적 비즈니스 도메인 또는 사용자 영향을 식별하고 평가하는 데 기여해야 합니다. 비즈니스 위험에 영향을 미치는 요소는 다음과 같습니다:

l  영향을 받은 기능의 사용 빈도

l  비즈니스 손실

l  잠재적 인 재정적, 생태적 또는 사회적 손실 또는 책임

l  민사 또는 형사 법적 제재

l  안전 문제

l  벌금, 라이센스 손실

l  합리적인 해결 방법 부족

l  기능의 가시성

l  부정으로 이어지는 실패의 가시성 홍보 및 잠재적 이미지 손상

l  고객의 손실

사용 가능한 위험 정보가 주어지면 테스트 분석가는 테스트 관리자가 설정 한 지침에 따라 비즈니스 위험 수준을 설정해야 합니다. 이들은 용어 (예: 낮음, 중간, 높음) 또는 숫자로 분류 할 수 있습니다. 정의 된 규모에서 위험을 객관적으로 측정 할 방법이 없다면 진정한 양적 측정이 될 수 없습니다. 확률 / 가능성 및 비용 / 결과를 정확하게 측정하는 것은 일반적으로 매우 어렵기 때문에 위험 수준을 결정하는 것은 일반적으로 질적으로 수행됩니다.

숫자는 질적 인 가치에 배정 될 수 있지만, 그것이 진정한 양적 척도가 되지는 않습니다. 예를 들어, 테스트 관리자는 비즈니스 위험이 1에서 10까지의 값으로 분류되어야 한다고 결정할 수 있습니다. 1이 가장 높기 때문에 비즈니스에 가장 위험하고 영향을 미칩니다. 가능성 (기술 위험 평가)과 영향 (비즈니스 위험 평가)이 할당되면 이 값을 곱하여 각 위험 항목의 전반적인 위험 등급을 결정할 수 있습니다. 그런 다음 전체 등급을 사용하여 위험 완화 활동의 우선 순위를 정합니다. PRISMA® [vanVeenendaal12]와 같은 일부 위험 기반 테스트 모델은 위험 값을 결합하지 않으므로 테스트 접근 방식으로 기술 및 비즈니스 위험을 개별적으로 해결할 수 있습니다.

 

2.4.4 위험 완화

프로젝트가 진행되는 동안 테스트 분석가는 다음을 수행해야 합니다:

l  테스트 항목의 합격 여부를 명확하게 보여주는 잘 디자인 된 테스트 케이스를 사용하고 요구 사항, 디자인 및 사용자 문서와 같은 소프트웨어 아티팩트에 대한 검토에 참여하여 제품 위험을 줄입니다.

l  테스트 전략 및 테스트 계획에서 확인 된 적절한 위험 완화 활동을 구현하십시오.

l  프로젝트가 진행될 때 수집 된 추가 정보, 가능성, 영향 또는 둘 다를 적절하게 조정하여 알려진 위험을 재평가합니다.

l  테스트 중 얻은 정보로 확인 된 새로운 위험을 인식합니다.

 

제품 (품질) 위험에 대해 이야기 할 때, 테스트는 그러한 위험에 대한 완화의 한 형태입니다. 테스터는 결함을 발견함으로써 결함에 대한 인식을 제공하고 출시 전에 결함을 처리 할 수 있는 기회를 제공함으로써 위험을 줄입니다. 테스터가 결함을 발견하지 못하면 테스팅은 특정 조건 (즉, 테스트 된 조건) 하에서 시스템이 올바르게 작동하는지 확인하여 위험을 줄입니다. Test Analyst는 정확한 테스트 데이터를 수집하고 실제 사용자 시나리오를 작성 및 테스트하며 사용성 연구를 수행하거나 감독하는 기회를 조사함으로써 위험 완화 옵션을 결정하는 데 도움을 줍니다.

 

2.4.4.1 테스트의 우선 순위 지정

위험도는 테스트의 우선 순위를 매기는데도 사용됩니다. 테스트 분석가는 회계 시스템의 거래 정확성 영역에서 높은 위험이 있음을 판단 할 수 있습니다. 결과적으로 위험을 줄이기 위해 테스터는 다른 비즈니스 영역 전문가와 협력하여 처리되고 정확성을 검증 할 수 있는 강력한 샘플 데이터 집합을 수집 할 수 있습니다. 마찬가지로, 테스트 분석가는 사용성 문제가 신제품의 중요한 위험 요소라고 판단 할 수 있습니다. Test Analyst는 사용자 수용 테스트가 문제를 발견하기를 기다리지 않고 테스트 초기에 사용성 문제를 확인하고 해결할 수 있도록 통합 단계에서 초기 유용성 테스트의 우선 순위를 지정할 수 있습니다. 이 우선 순위는 계획 단계에서 가능한 한 조기에 고려되어야 스케줄이 필요한 시간에 필요한 테스트를 수용 할 수 있습니다.

경우에 따라 가장 높은 위험 테스트는 위험도가 낮은 테스트를 실시하기 전에 실행되며 테스트는 엄격한 위험 순서 (종종 "깊이 우선"이라고도 함)로 실행됩니다. 다른 경우에는 표본 추출 방법을 사용하여 선택 위험에 대한 리스크를 사용하여 식별 된 모든 위험에 대한 테스트 샘플을 선택하는 동시에 모든 위험을 최소한 한 번 ( "너비 우선 (breadth first)"라고도 함) 보장합니다.

위험 기반 테스팅이 깊이 우선인지 너비 우선인지에 관계없이 모든 테스트를 실행하지 않고 테스트에 할당 된 시간이 소비 될 수 있습니다. 리스크 기반 테스팅을 통해 테스터는 현 시점에서 리스크의 잔존 정도를 관리 부서에 보고 할 수 있으며, 테스트를 연장할지 또는 사용자, 고객, 헬프 데스크 / 기술 지원에 나머지 리스크를 이전할지 결정할 수 있습니다. / 또는 운영 직원.

2.4.4.2 미래 시험주기를 위한 시험 조정

위험 평가는 시험 시행을 시작하기 전에 수행 된 일회성 활동이 아닙니다. 그것은 연속적인 과정입니다. 향후 계획된 각 테스트 사이클에는 다음과 같은 요소를 고려하여 새로운 위험 분석을 실시해야 합니다.

l  새롭거나 크게 변경된 제품 위험.

l  불안정하거나 결함이 있는 영역이 테스트 중에 발견되었습니다.

l  고정 된 결함으로 인한 위험.

l  테스트 중 발견 된 일반적인 결함.

l  테스트되지 않은 영역 (낮은 테스트 커버리지)

테스트를 위한 추가 시간이 할당되면 위험 범위를 위험이 낮은 영역으로 확장 할 수 있습니다.

3. 테스트 기법 - 825 분.

키워드

경계 값 분석 (BVA), 원인 - 효과 그래프 작성, 체크리스트 기반 테스팅, 분류 트리 방법, 조합 테스트, 결정 테이블 테스트, 결함 분류학, 결함 기반 기술, 도메인 분석, 오류 추측, 등가 분할, 경험 기반 기법, 탐색 적

테스트, 직교 배열, 직교 배열 테스트, 쌍 테스트, 요구 사항 기반 테스트,

사양 기반 기술, 상태 전이 테스트, 테스트 용서, 사용 사례 테스트, 사용자 스토리 테스트

테스트 기법 학습 목표

3.2 사양 기반 기술

TA-3.2.1 (K2) 원인 - 영향 그래프의 사용법을 설명한다.

TA-3.2.2 (K3) 정의 된 커버리지 수준을 달성하기 위해 동등한 파티셔닝 테스트 디자인 기법을 적용하여 주어진 스펙 항목으로부터 테스트 케이스를 작성한다.

TA-3.2.3 (K3) 정의 된 수준의 적용 범위를 달성하기 위해 경계 값 분석 테스트 설계 기술을 적용하여 주어진 사양 항목에서 테스트 케이스 작성

TA-3.2.4 (K3) 의사 결정 테이블 테스트 설계 기법을 적용하여 정의 된 커버리지 수준을 달성함으로써 주어진 스펙 항목에서 테스트 케이스 작성

TA-3.2.5 (K3) 정의 된 수준의 도달 범위를 달성하기 위해 상태 전이 테스트 설계 기술을 적용하여 주어진 사양 항목에서 테스트 케이스 작성

TA-3.2.6 (K3) 정의 된 커버리지 수준을 달성하기 위해 pairwise 테스트 설계 기법을 적용하여 주어진 스펙 항목으로부터 테스트 케이스를 작성하십시오

TA-3.2.7 (K3) 정의 된 수준의 커버리지를 달성하기 위해 분류 트리 테스트 설계 기술을 적용하여 주어진 명세 항목으로부터 테스트 케이스를 작성한다.

TA-3.2.8 (K3) 정의 된 커버리지 수준을 달성하기 위해 유스 케이스 테스트 설계 기술을 적용하여 주어진 스펙 항목으로부터 테스트 케이스를 작성한다.

TA-3.2.9 (K2) 애자일 프로젝트에서 사용자 스토리가 테스트 가이드로 사용되는 방법을 설명하십시오.

TA-3.2.10 (K3) 정의 된 수준의 적용 범위를 달성하기 위해 도메인 분석 테스트 설계 기술을 적용하여 주어진 사양 항목에서 테스트 사례를 작성합니다.

TA-3.2.11 (K4) 발견 될 결함의 유형을 판별하고 적절한 명세 기반 기법을 선택하기 위해 시스템 또는 요구 사항 명세를 분석한다.

 

3.3 결함 기반 기술

TA-3.3.1 (K2) 결함 기반 테스트 기술의 적용을 기술하고 사양 기반 기술과의 사용을 구분하십시오.

TA-3.3.2 (K4) 좋은 분류법에 대한 기준을 사용하여 주어진 상황에서 적용 가능성에 대해 주어진 결함 분류를 분석합니다.

 

3.4 경험 기반 기술

TA-3.4.1 (K2) 경험 기반 기술의 원칙과 사양 기반 및 결함 기반 기술과 비교 한 장점 및 단점을 설명하십시오.

TA-3.4.2 (K3) 주어진 시나리오의 경우 탐색 테스트를 지정하고 결과를 보고하는 방법을 설명하십시오

TA-3.4.3 (K4) 주어진 프로젝트 상황에 대해 특정 목표를 달성하기 위해 어떤 사양 기반, 결함 기반 또는 경험 기반 기술을 적용해야 하는지 결정합니다

3.1 서론

이 장에서 고려되는 테스트 설계 기법은 다음과 같은 범주로 나뉩니다. 명세 기반 (또는 행동 기반 또는 블랙 박스) 결함 기반 경험 기반

이러한 기술은 보완 적이며 수행되는 테스트 수준에 관계없이 주어진 테스트 활동에 적절하게 사용될 수 있습니다.

세 가지 범주의 기술을 모두 기능적 또는 비 기능적 품질 특성을 테스트하는 데 사용할 수 있습니다. 비 기능적 특성을 테스트하는 것은 다음 장에서 논의됩니다.

이 섹션에서 논의 된 테스트 설계 기술은 주로 최적의 테스트 데이터 (예: 등가 분할)를 결정하거나 테스트 시퀀스 (예: 상태 모델)를 도출하는 데 초점을 맞출 수 있습니다. 기술을 결합하여 완전한 테스트 케이스를 만드는 것이 일반적입니다.

 

3.2 사양 기반 기술

사양 기반 기법은 내부 구조를 참조하지 않고 구성 요소 또는 시스템의 테스트 기준을 분석하여 테스트 사례를 도출하기 위해 테스트 조건에 적용됩니다.

사양 기반 기술의 공통적 인 특징은 다음과 같습니다. 테스트 기법에 따라 테스트 설계 중에 모델 (예: 상태 전이 다이어그램 및 의사 결정 테이블)이 생성됩니다. 테스트 조건은 이 모델에서 체계적으로 파생됩니다

일부 기술은 또한 테스트 설계 및 테스트 실행 활동을 측정하는 데 사용할 수 있는 적용 범위 기준을 제공합니다. 적용 범위 기준을 완전히 충족한다고 해서 전체 테스트 세트가 완료된 것이 아니라 해당 모델이 더 이상 해당 기술을 기반으로 한 적용 범위를 늘리기 위한 추가 테스트를 제안하지 않는다는 의미입니다.

사양 기반 테스트는 일반적으로 시스템 요구 사항 문서를 기반으로 합니다. 요구 사항 사양은 시스템이 작동하는 방법, 특히 기능 영역에서 동작을 지정해야 하므로 요구 사항에서 테스트를 유도하는 것은 종종 시스템의 동작을 테스트하는 일부입니다. 경우에 따라 문서화 된 요구 사항이 없을 수도 있지만 레거시 시스템의 기능을 대체하는 것과 같은 묵시적인 요구 사항이 있습니다.

많은 사양 기반 테스트 기술이 있습니다. 이러한 기술은 다양한 유형의 소프트웨어 및 시나리오를 대상으로 합니다. 아래 섹션에서는 각 기술에 대한 적용 가능성, 테스트 분석가가 경험할 수 있는 몇 가지 제한 사항 및 어려움, 테스트 범위를 측정하는 방법 및 목표로 하는 결함 유형을 보여줍니다.

 

3.2.1 등가 분할

Equivalence Partitioning (EP)은 입력, 출력, 내부 값 및 시간 관련 값의 처리를 효과적으로 테스트하는 데 필요한 테스트 사례 수를 줄이기 위해 사용됩니다. 파티셔닝은 동일한 방식으로 처리되는 값 집합으로 만들어진 등가 클래스 (동등성 파티션이라고도 함)를 만드는 데 사용됩니다. 한 파티션에서 하나의 대표 값을 선택하면 같은 파티션에 있는 모든 항목의 적용 범위가 가정됩니다.

 

적용 분야

이 기술은 모든 테스트 수준에서 적용 할 수 있으며 테스트 할 값 집합의 모든 멤버가 동일한 방식으로 처리되어야 하고 응용 프로그램에서 사용되는 값 집합이 상호 작용하지 않을 때 적합합니다.

값 집합의 선택은 유효하거나 유효하지 않은 파티션 (즉, 테스트중인 소프트웨어에 대해 유효하지 않은 값을 포함하는 파티션)에 적용 할 수 있습니다. 이 기법은 경계 값 분석과 함께 사용하면 테스트 값을 파티션의 가장자리에 포함되도록 확장 할 때 가장 강력합니다. 이 기능은 기본 기능이 작동하는지 신속하게 판단하므로 새 빌드 또는 새 릴리스를 연기 테스트하는 데 일반적으로 사용되는 기술입니다.

 

한계 / 어려움

가정이 올바르지 않고 파티션의 값이 정확히 같은 방식으로 처리되지 않으면 이 기술은 결함이 누락 될 수 있습니다. 파티션을 신중하게 선택하는 것도 중요합니다. 예를 들어, 양수와 음수를 허용하는 입력 필드는 서로 다른 처리의 가능성 때문에 양수와 음수에 대해 하나씩 두 개의 유효한 파티션으로 더 잘 테스트됩니다. 0이 허용되는지 여부에 따라 다른 파티션이 될 수도 있습니다. 테스트 분석가는 값의 최적 파티셔닝을 결정하기 위해 기본 프로세싱을 이해하는 것이 중요합니다.

 

적용 범위

커버리지는 값이 테스트 된 파티션의 수를 취하고 그 수를 식별 된 파티션의 수로 나눔으로써 결정됩니다. 단일 파티션에 대해 여러 값을 사용한다고 해서 적용 비율이 증가하지는 않습니다.

결함 유형

이 기술은 다양한 데이터 값을 처리 할 때 기능적 결함을 찾습니다.

 

3.2.2 경계 값 분석

경계 값 분석 (BVA)은 순서화 된 등가 분할 영역의 경계에 존재하는 값을 테스트하는 데 사용됩니다. BVA에 접근하는 데는 두 가지 방법이 있습니다: 두 가지 값 또는 세 가지 값 테스트. 두 가지 값 테스트를 사용하면 경계 값 (경계 값)과 경계 값 (가능한 한 작은 값으로)이 사용됩니다. 예를 들어 파티션에 값 1 ~ 10이 0.5 단위로 포함 된 경우 상위 경계에 대한 두 값 테스트 값은 10과 10.5가됩니다. 하한 테스트 값은 1과 0.5가 됩니다. 경계는 정의 된 등가 분할 영역의 최대 값과 최소값으로 정의됩니다.

세 가지 값 경계 테스트의 경우 경계 전, 경계 위 및 경계 값이 사용됩니다. 이전 예에서 상위 경계 테스트는 9.5, 10 및 10.5를 포함합니다. 하위 경계 테스트에는 1.5, 1 및 0.5가 포함됩니다. 2 개 또는 3 개의 경계 값 사용 여부에 관한 결정은 테스트 대상 품목과 관련된 위험을 기반으로 해야 하며 세 가지 경계 접근법은 위험도가 높은 품목에 사용되어야 합니다.

 

적용 분야

이 기술은 모든 테스트 레벨에 적용 할 수 있으며, 동등한 파티션이 존재할 때 적합합니다. 경계선을 넘어서고 있다는 개념 때문에 주문이 필요합니다. 예를 들어 숫자 범위는 정렬 된 파티션입니다. 모든 직사각형 객체로 구성된 파티션은 정렬 된 파티션이 아니며 경계 값을 가지고 있지 않습니다. 숫자 값 이외의 변수 (예: 길이)의 숫자 속성 유스 케이스의 루프를 포함한 루프 저장된 데이터 구조 실제 객체 (메모리 포함) 시간 결정 활동

 

한계 / 어려움

이 기술의 정확성은 동등한 파티션의 정확한 식별에 달려 있기 때문에 동일한 한계와 어려움이 따릅니다.

또한 테스트 분석가는 테스트 할 값을 정확하게 결정할 수 있도록 유효 값과 유효하지 않은 값의 증가를 알고 있어야 합니다. 경계 값 분석에는 순서가 지정된 파티션 만 사용할 수 있지만 유효한 입력 범위에만 국한되지는 않습니다. 예를 들어 스프레드 시트에서 지원하는 셀 수를 테스트 할 때 최대 허용 셀 (경계)까지의 셀 수를 포함하는 파티션과 최대 셀 수를 초과하는 셀 (최대 경계).

적용 범위

커버리지는 테스트 된 경계 조건의 수를 취하여 식별 된 경계 조건의 수 (2 개 값 또는 3 개 값 방법 사용)로 나눔으로써 결정됩니다. 이것은 경계 테스트에 대한 적용 비율을 제공합니다.

 

결함 유형

경계 값 분석은 경계의 변위 또는 누락을 신뢰할 수 있게 찾아 내고 여분의 경계를 발견 할 수 있습니다. 이 기술은 경계 값, 특히 덜 큼 및 보다 큰 논리 (즉, 변위)를 갖는 오류의 처리에 관한 결함을 발견한다. 또한 로드 한계 허용 오차 (예 : 10,000 명의 동시 사용자를 지원하는 시스템)와 같은 기능 외 결함을 찾을 때도 사용할 수 있습니다.

 

3.2.3 의사 결정 테이블

의사 결정 테이블은 조건 조합 간의 상호 작용을 테스트하는 데 사용됩니다. 의사 결정 테이블은 모든 적절한 조건 조합의 테스트를 검증하고 모든 가능한 조합이 테스트중인 소프트웨어에 의해 처리되는지를 검증하는 명확한 방법을 제공합니다. 의사 결정 테이블 테스트의 목표는 조건, 관계 및 제약 조건의 모든 조합이 테스트되는지 확인하는 것입니다. 가능한 모든 조합을 테스트하려고 할 때 의사 결정 테이블이 매우 커질 수 있습니다. 가능한 모든 조합에서 "흥미로운"조합으로 조합 수를 지능적으로 줄이는 방법을 접힌 의사 결정 테이블 테스트라고 합니다. 이 기술을 사용하면 결과와 관련 없는 조건 집합을 제거하여 다른 출력을 생성하는 조합으로 조합이 축소됩니다. 중복 검사 또는 조건 조합이 불가능한 검사는 제거됩니다. 전체 의사 결정 테이블 또는 축소 된 의사 결정 테이블을 사용할지 여부는 일반적으로 위험을 기반으로 결정됩니다. [Copeland03]

 

적용 분야

이 기술은 일반적으로 통합, 시스템 및 수락 테스트 레벨에 적용됩니다. 코드에 따라 구성 요소가 결정 논리 집합을 담당 할 때 구성 요소 테스트에도 적용될 수 있습니다. 이 기술은 요구 사항이 플로우 차트 또는 비즈니스 규칙 테이블 형식으로 제공 될 때 특히 유용합니다. 의사 결정 테이블은 요구 사항 정의 기술이기도 하며 일부 요구 사항 사양은 이 형식으로 이미 도착할 수 있습니다. 요구 사항이 표 형식 또는 흐름 차트 형식으로 제시되지 않은 경우에도 조건 조합은 일반적으로 내러티브에서 찾을 수 있습니다. 의사 결정 테이블을 설계 할 때 정의 된 조건 조합과 명시 적으로 정의되지는 않았지만 존재할 수 있는 조건 조합을 고려하는 것이 중요합니다. 유효한 결정 테이블을 설계하기 위해 테스터는 사양 또는 테스트 오라클에서 모든 조건 조합에 대해 예상되는 모든 결과를 도출 할 수 있어야 합니다. 모든 상호 작용 조건을 고려할 때만 의사 결정 테이블을 좋은 테스트 설계 도구로 사용할 수 있습니다.

 

한계 / 어려움

요구 사항이 잘 정의되어 있지 않거나 존재하지 않는 경우 특히 모든 상호 작용 조건을 찾는 것이 어려울 수 있습니다. 일련의 조건을 준비하고 예상되는 결과를 알 수 없다는 것을 결정하는 것은 이례적인 일이 아닙니다.

 

적용 범위

의사 결정 테이블의 최소 테스트 적용 범위는 각 열에 대해 하나의 테스트 케이스를 갖는 것입니다. 여기에는 복합 조건이 없고 모든 가능한 조건 조합이 열에 기록되어 있다고 가정합니다.

의사 결정 테이블에서 테스트를 결정할 때 테스트해야 하는 경계 조건을 고려하는 것도 중요합니다. 이러한 경계 조건은 소프트웨어를 적절히 테스트하는 데 필요한 테스트 케이스의 수를 증가시킬 수 있습니다. 경계 값 분석과 동등한 파티셔닝은 의사 결정 테이블 기술을 보완합니다.

 

결함 유형

일반적인 결함에는 예상치 못한 결과를 초래하는 특정 조건 조합에 기반한 잘못된 처리가 포함됩니다. 의사 결정 테이블을 작성하는 중에 결함이 스펙 문서에서 발견 될 수 있습니다. 가장 일반적인 유형의 결함은 누락 (특정 상황에서 실제로 발생해야 하는 것에 관한 정보가 없음)과 모순입니다. 테스트를 통해 조건 조합이 처리되지 않거나 잘 처리되지 않는 문제를 발견 할 수도 있습니다.

 

3.2.4 원인 - 영향 그래프 작성

원인 - 효과 그래프는 사용자 스토리 또는 흐름도와 같은 프로그램의 기능적 논리 (즉, "규칙")를 설명하는 모든 출처에서 생성 될 수 있습니다. 이들은 프로그램의 논리 구조에 대한 그래픽 개요를 얻는 데 유용 할 수 있으며 일반적으로 의사 결정 테이블을 작성하기 위한 기초로 사용됩니다. 인과 관계 그래프 및 / 또는 의사 결정 테이블로 의사 결정을 캡처하면 프로그램 논리를 체계적으로 테스트 할 수 있습니다.

적용 분야

원인 - 영향 그래프는 의사 결정 테이블과 동일한 상황에 적용되며 동일한 테스트 레벨에도 적용됩니다. 특히, 인과 관계 그래프는 결과 (인과성)를 유발하는 조건 조합, 결과를 제외하는 조건 조합, 결과 (및)를 유발하기 위해 반드시 필요한 여러 조건 및 특별한 결과 (또는). 이러한 관계는 내러티브 설명보다 원인 - 영향 그래프에서 쉽게 볼 수 있습니다.

 

한계 / 어려움

원인 - 원인 그래프는 다른 테스트 설계 기법과 비교하여 더 많은 시간과 노력이 필요합니다. 또한 도구 지원이 필요합니다. 원인 - 원인 그래프에는 작성자와 그래프의 독자가 이해해야 하는 특정 표기법이 있습니다.

 

적용 범위

최소한의 적용 범위를 달성하기 위해 가능한 조합을 포함하여 각 가능한 원인을 테스트해야 합니다. 원인 - 영향 그래프에는 데이터 흐름과 논리 흐름에 대한 제약 조건을 정의하는 수단이 포함됩니다.

 

결함 유형

이 그래프는 의사 결정 테이블에서 발견되는 것과 같은 유형의 조합 적 결함을 찾습니다. 또한 그래프를 작성하면 테스트 기준에서 필요한 상세 수준을 정의하는 데 도움이 되므로 테스트 기준의 상세 및 품질을 향상시키고 테스터가 누락 된 요구 사항을 식별하는 데 도움이 됩니다.

 

3.2.5 상태 전이 테스트

상태 전이 테스트는 소프트웨어가 유효하고 무효 한 전환을 통해 정의 된 상태로 들어가고 나가는 기능을 테스트하는 데 사용됩니다. 이벤트로 인해 소프트웨어가 상태에서 상태로 전환되고 조치가 수행됩니다. 이벤트는 전환 경로에 영향을 미치는 조건 (가드 조건 또는 전환 가드라고도 함)으로 규정 될 수 있습니다. 예를 들어 유효한 사용자 이름 / 암호 조합이 있는 로그인 이벤트는 잘못된 암호가 있는 로그인 이벤트와 다른 전환이 됩니다.

상태 전이는 상태 사이의 모든 유효한 전이를 그래픽 형식으로 표시하는 상태 전이 다이어그램 또는 유효 및 무효 인 모든 잠재적 전이를 보여주는 상태 테이블에서 추적됩니다.

적용 분야

상태 전이 테스트는 상태를 정의하고 해당 상태 간 전환을 유발하는 이벤트 (예 : 화면 변경)가있는 모든 소프트웨어에 적용 할 수 있습니다. 상태 전이 테스트는 모든 테스트 단계에서 사용할 수 있습니다. 임베디드 소프트웨어, 웹 소프트웨어 및 모든 유형의 트랜잭션 소프트웨어는 이러한 유형의 테스트에 적합한 후보입니다. 제어 시스템, 즉 신호등 제어기 또한 이러한 유형의 시험에 적합한 후보이다.

 

한계 / 어려움

상태를 결정하는 것은 종종 상태 테이블이나 다이어그램을 정의 할 때 가장 어려운 부분입니다. 소프트웨어에 사용자 인터페이스가 있는 경우 사용자에게 표시되는 다양한 화면을 사용하여 상태를 정의하는 경우가 많습니다. 임베디드 소프트웨어의 경우 상태는 하드웨어가 경험할 수 있는 상태에 따라 달라질 수 있습니다.

상태 자체의 기본 단위 외에 상태 전환 테스트의 기본 단위는 0 전환이라고도 하는 개별 전환입니다. 단순히 모든 전이를 테스트하면 상태 전이 결함이 발견되지만 트랜잭션 순서를 테스트하면 더 많은 문제가 발견 될 수 있습니다. 두 개의 연속적인 전환 시퀀스를 1- 스위치라고 부릅니다. 3 개의 연속 천이 시퀀스는 2 스위치 등입니다. (이 스위치들은 때로 N-1 스위치로 지정됩니다. 여기서 N은 통과 할 전이 횟수를 나타냅니다. 예를 들어 (0 스위치) 단일 전환은 1-1 스위치가 됩니다. [Bath08]

 

적용 범위

다른 유형의 테스트 기술과 마찬가지로 테스트 커버리지 수준의 계층 구조가 있습니다. 수용 가능한 최소 수준은 모든 주를 방문하고 모든 전환을 통과해야 한다는 것입니다. 시스템 설계 또는 상태 전이 모델 (다이어그램 또는 테이블)에 결함이 있는 경우를 제외하고 100 % 전환 커버리지 (100 % 0 스위치 커버리지 또는 100 % 논리적 분기 커버리지 라고도 함)는 모든 상태가 방문되고 모든 전환이 통과하도록 보장합니다.  상태와 전환 사이의 관계에 따라 다른 전환을 한 번만 실행하려면 전환을 두 번 이상 통과해야 할 수 있습니다.

"n-switch coverage"라는 용어는 다루는 전환 수와 관련이 있습니다. 예를 들어, 100 % 1- 스위치 적용 범위를 달성하려면 두 번의 연속적인 전환의 모든 유효한 시퀀스가 ​​적어도 한 번 테스트되어야 합니다. 이 테스트는 100 % 0 스위치 커버리지가 실패 할 수 있는 몇 가지 유형의 장애를 자극 할 수 있습니다.

"라운드 트립 범위"는 전환 시퀀스가 ​​루프를 형성하는 상황에 적용됩니다. 모든 상태에서 동일한 상태로 되돌아가는 모든 루프가 테스트되었을 때 100 % 왕복 범위가 달성됩니다. 이것은 루프에 포함 된 모든 상태에 대해 테스트해야 합니다.

이러한 접근 방법 중 어느 하나라도 더 높은 범위의 도달 범위는 모든 잘못된 전환을 포함하려고 시도합니다. 커버리지 요구 사항 및 상태 전이 테스트 커버 세트는 무효 트랜지션이 포함되는지 여부를 식별해야 합니다.

 

결함 유형

일반적인 결함은 이전 상태에서 발생한 처리의 결과 인 현재 상태의 잘못된 처리, 잘못되거나 지원되지 않는 전환, 종료가 없는 상태 및 존재하지 않는 상태 또는 전환의 필요성을 포함합니다. 상태 기계 모델을 생성하는 동안 결함이 사양 문서에서 발견 될 수 있습니다. 가장 일반적인 유형의 결함은 누락 (특정 상황에서 실제로 발생해야 하는 것에 관한 정보가 없음)과 모순입니다.

 

3.2.6 조합 시험 기술

조합 테스트는 여러 매개 변수가 있는 소프트웨어를 테스트 할 때 사용되며, 각 매개 변수는 여러 값으로 구성되어 허용 된 시간 내에 테스트 할 수 있는 것보다 많은 조합을 발생시킵니다.

매개 변수는 독립적이어야 하며 모든 요소에 대한 옵션은 다른 요소에 대한 옵션과 결합 될 수 있다는 점에서 호환 가능해야 합니다. 분류 트리는 특정 옵션이 호환되지 않는 경우 일부 조합을 제외시킬 수 있습니다. 이것은 결합 된 요소가 서로 영향을 미치지 않는다고 가정하지 않습니다. 그들은 잘 할 수도 있지만 수용 가능한 방식으로 서로에게 영향을 주어야 합니다.

조합 테스트는 미리 정의 된 수준의 도달 범위를 달성하기 위해 이러한 조합의 적절한 하위 집합을 식별하는 수단을 제공합니다. 조합에 포함 할 항목 수는 단일 항목, 쌍, 세배 이상 [Copeland03]을 포함하여 Test Analyst에서 선택할 수 있습니다. 이 작업에서 테스트 분석가를 돕는 데 사용할 수 있는 여러 도구가 있습니다 (샘플은 www.pairwise.org 참조). 이러한 도구는 매개 변수와 그 값을 나열 (쌍 테스트 및 직각 배열 테스트)하거나 그래픽 형식 (분류 트리) [Grochtmann94]으로 나타내야 합니다. 쌍 테스트는 조합 된 변수 쌍을 테스트하는 데 적용되는 방법입니다. 직교 배열은 사전 정의 된 수학적으로 정확한 표로, 테스트 분석가가 테스트 할 항목을 배열의 변수로 대체하여 테스트 할 때 적용 범위를 달성 할 수있는 조합을 생성합니다 [Koomen06]. 분류 트리 도구를 사용하여 테스트 분석가가 테스트 할 조합의 크기 (즉, 두 값, 세 값 등의 조합)를 정의 할 수 있습니다.

 

적용 분야

너무 많은 조합의 매개 변수 값을 갖는 문제는 테스트와 관련된 최소한 두 가지 상황에서 나타납니다. 일부 테스트 케이스에는 몇 가지 입력 필드가 있는 화면과 같이 가능한 여러 가지 값이 있는 매개 변수가 여러 개 있습니다. 이 경우 매개 변수 값의 조합이 테스트 사례의 입력 데이터를 구성합니다. 또한 일부 시스템은 여러 차원에서 구성 할 수 있으므로 구성 공간이 커질 수 있습니다. 이 두 가지 상황에서 조합 테스트를 사용하여 가능한 조합의 하위 집합을 식별 할 수 있습니다.

많은 수의 값을 갖는 매개 변수의 경우, 동등한 클래스 분할 또는 일부 다른 선택 메커니즘이 조합 결과 집합을 줄이기 위해 조합 테스트를 적용하기 전에 각 매개 변수의 값 수를 줄이기 위해 먼저 각 매개 변수에 개별적으로 적용될 수 있습니다.

이러한 기술은 대개 테스트의 통합, 시스템 및 시스템 통합 수준에 적용됩니다.

 

한계 / 어려움

이러한 기술의 주요 한계는 몇 가지 테스트의 결과가 모든 테스트를 대표하고 그 몇 가지 테스트가 예상되는 사용을 나타냅니다. 특정 변수 사이에 예기치 않은 상호 작용이 있는 경우 특정 조합을 테스트하지 않으면 이 유형의 테스트에서 감지되지 않을 수 있습니다. 이러한 기술은 논리적 인 테스트 감소를 이해하지 못하기 때문에 비 기술적 인 독자에게 설명하기가 어려울 수 있습니다.

매개 변수와 해당 값을 식별하는 것이 때때로 어려운 경우가 있습니다. 특정 범위의 적용 범위를 충족시키기 위해 최소한의 조합 조합을 찾는 것은 수동으로 하기가 어렵습니다. 일반적으로 도구는 최소 조합 조합을 찾는 데 사용됩니다. 일부 도구는 일부 (하위) 조합을 조합의 최종 선택에 포함 시키거나 제외하도록 하는 기능을 지원합니다. 이 기능은 도메인 지식 또는 제품 사용 정보를 기반으로 요인을 강조하거나 강조하지 않기 위해 Test Analyst에서 사용할 수 있습니다.

 

적용 범위

몇 가지 보험 범위가 있습니다. 가장 낮은 수준의 적용 범위를 1-wise 또는 singleton 적용 범위라고 합니다. 선택한 매개 변수 중 적어도 하나에 모든 매개 변수의 각 값이 있어야 합니다. 다음 보급 수준은 2-wise 또는 pairwise coverage라고 합니다. 두 개의 매개 변수 값의 모든 쌍은 적어도 하나의 조합에 포함되어야 합니다. 이 아이디어는 모든 n 개의 매개 변수 세트의 모든 하위 조합이 선택된 조합 세트에 포함되어야 한다는 n-wise coverage로 일반화 될 수 있습니다.

n이 높을수록 100 % 적용 범위에 도달하는 데 더 많은 조합이 필요합니다. 이러한 기술의 최소 적용 범위는 도구로 생성 된 모든 조합에 대해 하나의 테스트 케이스를 갖는 것입니다.

 

결함 유형

이 유형의 테스트에서 발견되는 가장 일반적인 유형의 결함은 여러 매개 변수의 결합 된 값과 관련된 결함입니다.

 

3.2.7 유스 케이스 테스트

유스 케이스 테스트는 시스템의 사용법을 에뮬레이션 해야 하는 트랜잭션 기반의 시나리오 기반 테스트를 제공합니다. 유스 케이스는 어떤 목표를 달성 한 액터와 시스템 간의 상호 작용 측면에서 정의됩니다. 액터는 사용자 또는 외부 시스템이 될 수 있습니다.

 

적용 분야

유스 케이스 테스트는 일반적으로 시스템 및 수락 테스트 레벨에서 적용됩니다. 통합 수준에 따라 통합 테스트를 수행하고 구성 요소의 동작에 따라 구성 요소 테스트까지 사용할 수 있습니다. 유스 케이스는 시스템의 실제 사용법을 나타내기 때문에 성능 테스트의 기초가 되기도 합니다. 유스 케이스에 설명 된 시나리오는 가상 사용자에게 할당되어 시스템에 현실적인 로드를 생성 할 수 있습니다.

 

한계 / 어려움

유효하려면 유스 케이스가 실제 사용자 트랜잭션을 전달해야 합니다. 이 정보는 사용자 또는 사용자 대표가 제공해야 합니다. 유스 케이스가 실제 사용자의 활동을 정확하게 반영하지 않으면 유스 케이스의 가치가 감소합니다. 다양한 대체 경로 (흐름)에 대한 정확한 정의는 테스트 커버리지를 철저히 하기 위해 중요합니다. 유스 케이스는 지침으로 간주해야 하지만 전체 요구 사항 집합을 명확하게 정의하지는 못하기 때문에 테스트해야 할 사항에 대한 완전한 정의가 아닙니다. 테스트의 정확성을 높이고 유스 케이스 자체를 검증하기 위해 유스 케이스 서술에서 다른 모델 (예 : 플로우 차트)을 작성하는 것도 도움이 될 수 있습니다.

 

적용 범위

유스 케이스의 최소 커버리지는 메인 (포지티브) 패스에 대해 하나의 테스트 케이스를 갖고, 각각의 대체 경로 또는 플로우에 대해 하나의 테스트 케이스를 갖는 것이다. 대체 경로에는 예외 W 실패 경로가 포함됩니다. 대체 경로는 때로는 기본 경로의 확장으로 표시됩니다. 커버리지 비율은 테스트 된 경로의 수를 취하여 주 경로와 대체 경로의 총 수로 나누어 결정됩니다.

 

결함 유형

결함에는 정의 된 시나리오의 잘못된 취급, 누락 된 대체 경로 처리, 제시된 조건의 잘못된 처리 및 어색하거나 잘못된 오류보고가 포함됩니다.

 

3.2.8 사용자 이야기 테스팅

스크럼과 같은 일부 애자일 방법론에서는 요구 사항이 단일 반복 [Cohn04]에서 설계, 개발, 테스트 및 시연 될 수 있는 작은 기능 단위를 설명하는 사용자 스토리 형식으로 준비됩니다. 이러한 사용자 스토리에는 구현할 기능에 대한 설명, 비 기능적 기준 및 사용자 스토리가 완료된 것으로 간주되어야 하는 승인 기준이 포함됩니다.

적용 분야

 

사용자 스토리는 주로 애자일 (Agile) 및 비슷한 반복 및 증분 환경에서 사용됩니다. 이들은 기능 테스트 및 비 기능 테스트 모두에 사용됩니다. 사용자 스토리는 개발자가 다음 단계의 테스트 작업 (예 : 통합, 성능 테스트)을 통해 코드를 팀원에게 전달하기 전에 사용자 스토리에 대해 구현 된 기능을 시연 할 것이라는 기대로 모든 수준의 테스트에 사용됩니다.

한계 / 어려움

스토리는 기능이 조금씩 증가하기 때문에 전달되는 기능을 실제로 테스트하기 위해 드라이버와 스텁을 생성해야 할 수도 있습니다. 이는 대개 API 테스트 도구와 같은 테스트에 도움이 되는 도구를 프로그래밍하고 사용하는 기능을 필요로 합니다. 기술 테스트 분석가가 이 코드를 작성하고 API 테스팅 도구를 활용하는 경우에도 드라이버 및 스텁 생성은 대개 개발자의 책임입니다. 대부분의 민첩한 프로젝트에서와 같이 지속적인 통합 모델을 사용하면 드라이버와 스텁이 최소화됩니다.

 

적용 범위

사용자 이야기의 최소 적용 범위는 명시된 각 수용 기준이 충족되었는지 확인하는 것입니다.

 

결함 유형

결함은 일반적으로 소프트웨어가 지정된 기능을 제공하지 못한다는 점에서 기능적입니다. 결함은 이미 존재하는 기능과 새로운 스토리의 기능에 대한 통합 문제로도 볼 수 있습니다. 이야기가 독립적으로 개발 될 수 있기 때문에 성능, 인터페이스 및 오류 처리 문제가 나타날 수 있습니다. Test Analyst는 테스트를 위해 새 스토리가 출시 될 때마다 통합 테스트뿐 아니라 제공된 개별 기능 테스트를 모두 수행하는 것이 중요합니다.

 

3.2.9 도메인 분석

도메인은 정의 된 값 집합입니다. 이 집합은 단일 변수 (1 차원 도메인, 예를 들어 "24 세 이상 66 세 이하 남성")의 값 범위 또는 상호 작용하는 변수의 값 범위 (다차원 도메인, 예 : , "69 세 이상 90kg 이하의 체중을 가진 24 세 이상 66 세 미만 남성"). 다차원 도메인에 대한 각 테스트 케이스에는 관련된 각 변수에 대한 적절한 값이 포함되어야 합니다.

1 차원 도메인의 도메인 분석은 일반적으로 동등한 파티셔닝 및 경계 값 분석을 사용합니다. 파티션이 정의되면 테스트 분석가는 파티션 (IN), 파티션 외부 (OUT), 파티션 경계 (ON) 및 파티션 경계 외부의 값을 나타내는 값을 각 파티션에서 선택합니다 파티션 (OFF). 이 값을 결정하면 각 파티션이 경계 조건과 함께 테스트됩니다. [Black07]

다차원 도메인의 경우 이러한 방법으로 생성 된 테스트 케이스의 수는 관련된 변수의 수에 따라 기하 급수적으로 증가하지만 도메인 이론을 기반으로 한 접근 방식은 선형 성장으로 이어집니다. 또한 형식적 접근 방식은 등가 분할 및 경계 값 분석이 결여 된 결함 이론 (결함 모델)을 포함하기 때문에 더 작은 테스트 세트는 다차원 도메인에서 결함을 발견 할 수 있으며 더 큰 휴리스틱 테스트 세트는 누락 될 수 있습니다. 다차원 도메인을 다룰 때, 테스트 모델은 의사 결정 테이블 (또는 "도메인 매트릭스")로 구성 될 수 있습니다. 3 차원 이상의 다차원 도메인에 대한 테스트 케이스 값을 식별하는 데는 계산 지원이 필요할 수 있습니다.

 

적용 분야

도메인 분석은 의사 결정 테이블, 등가 분할 및 경계 값 분석에 사용되는 기술을 결합하여 중요한 영역과 실패 가능성이 있는 영역을 여전히 커버하는 더 작은 테스트 세트를 작성합니다. 잠재적으로 상호 작용할 수 있는 많은 수의 변수로 인해 의사 결정 테이블이 다루기 힘든 경우에 종종 적용됩니다. 도메인 분석은 모든 테스트 레벨에서 수행 할 수 있지만 통합 및 시스템 테스트 레벨에서 가장 자주 적용됩니다.

한계 / 어려움

철저한 도메인 분석을 수행하려면 다양한 도메인과 도메인 간의 잠재적 인 상호 작용을 식별하기 위해 소프트웨어에 대한 강력한 이해가 필요합니다. 도메인을 식별 할 수 없는 상태로 두면 테스트가 상당히 부족할 수 있지만 OFF 및 OUT 변수가 탐지되지 않은 도메인에 있을 수 있기 때문에 도메인이 탐지 될 가능성이 큽니다. 도메인 분석은 개발자와 협력하여 테스트 영역을 정의 할 때 사용하는 강력한 기술입니다.

 

적용 범위

도메인 분석에 대한 최소 적용 범위는 각 도메인의 각 IN, OUT, ON 및 OFF 값에 대한 테스트를 갖는 것입니다. 값이 중복되는 경우 (예: 한 도메인의 OUT 값이 다른 도메인의 IN 값인 경우) 테스트를 복제 할 필요가 없습니다. 이 때문에 필요한 실제 테스트는 종종 도메인 당 4 개 미만입니다.

 

결함 유형

결함은 도메인 내의 기능적 문제, 경계 값 처리, 변수 상호 작용 문제 및 오류 처리 (특히 유효한 도메인에 없는 값의 경우)를 포함합니다.

 

3.2.10 결합 기술

때때로 기술을 결합하여 테스트 케이스를 작성합니다. 예를 들어, 의사 결정 테이블에서 식별 된 조건은 조건이 충족 될 수있는 여러 가지 f}을 발견하기 위해 동등한 파티셔닝을 거칠 수 있습니다. 테스트 케이스는 모든 조건 조합을 포괄 할뿐만 아니라 분할 된 조건의 경우 동등한 파티션을 커버하기 위해 추가 테스트 케이스가 생성됩니다. 적용 할 특정 기법을 선택할 때, 시험 분석가는 기술의 적용 가능성, 한계 및 어려움, 그리고 적용 범위 및 결함의 관점에서의 시험 목표를 고려해야 합니다. 상황에 대해 "최고의"기술이 하나도 없을 수도 있습니다. 복합 기술은 기술을 올바르게 적용하기에 충분한 시간과 기술이 있다고 가정 할 때 가장 포괄적 인 범위를 제공합니다.

 

3.3 결함 기반 기술

3.3.1 결함 기반 기술 사용

결함 기반 테스트 설계 기술은 결함 유형에 대해 알려진 것으로부터 체계적으로 파생 된 테스트와 함께 테스트 설계의 기초로 사용되는 결함 유형을 사용하는 기술입니다. 사양에서 테스트를 이끌어내는 사양 기반 테스트와 달리 결함 기반 테스트는 테스트중인 소프트웨어와 완전히 독립적 인 결함 분류 (즉, 범주화 된 목록)에서 테스트를 유도합니다. 분류 체계에는 결함 유형, 근본 원인, 장애 증상 및 기타 결함 관련 데이터의 목록이 포함될 수 있습니다. 결함 기반 테스트는 또한 테스트 대상으로 삼는 기준으로 식별 된 위험 및 위험 시나리오의 목록을 사용할 수 있습니다. 이 테스트 기술을 통해 테스터는 특정 유형의 결함을 목표로 삼거나 특정 유형의 알려진 결함 및 일반적인 결함의 결함 분류를 통해 체계적으로 작업 할 수 있습니다. Test Analyst는 분류 체계 데이터를 사용하여 특정 유형의 결함을 찾는 테스팅의 목표를 결정합니다. 이 정보를 통해 테스트 분석가는 테스트 사례와 테스트 조건을 작성하여 결함이 있는 경우 자체를 나타낼 수 있습니다.

 

적용 분야

결함 기반 테스트는 모든 테스트 레벨에서 적용 할 수 있지만 시스템 테스트 중에 가장 일반적으로 적용됩니다. 여러 유형의 소프트웨어에 적용되는 표준 분류가 있습니다. 이 비 제품 별 테스트 유형은 산업 표준 지식을 활용하여 특정 테스트를 유도하는 데 도움이 됩니다. 업계 고유의 분류 체계를 준수함으로써 결함 발생에 관한 측정 항목을 프로젝트 전체 또는 조직 전체에서 추적 할 수 있습니다.

여러 가지 결함 분류가 존재하며 유용성과 같은 특정 유형의 테스트에 중점을 둘 수 있습니다. 사용 가능한 경우 테스트중인 소프트웨어에 적용 가능한 분류 체계를 선택하는 것이 중요합니다. 예를 들어 혁신적인 소프트웨어에 사용할 수 있는 분류 체계가 없을 수 있습니다. 일부 조직에서는 자주 발생하는 결함의 분류를 자체적으로 작성했습니다. 어떤 분류체계가 사용 되든 테스트를 시작하기 전에 예상되는 커버리지를 정의하는 것이 중요합니다.

 

적용 범위

이 기술은 모든 유용한 테스트 케이스가 식별 된 시기를 결정하는 데 사용되는 커버리지 기준을 제공합니다. 실제 문제로서 결함 기반 기술의 적용 범위 기준은 범위에 대한 일반적인 규칙 만 제공되고 유용 범위의 한도를 구성하는 것에 대한 구체적인 결정은 임의적이라는 점에서 사양 기반 기술보다 체계적이지 않은 경향이 있습니다. 다른 기술과 마찬가지로 적용 범위 기준은 전체 테스트 세트가 완료되었음을 의미하는 것이 아니라 해당 기술을 기반으로 더 이상 유용한 테스트를 제안하지 않는 것으로 간주되는 결함을 의미합니다.

 

결함 유형

발견 된 결함 유형은 일반적으로 사용중인 분류 체계에 따라 다릅니다. 사용자 인터페이스 분류법을 사용하면 발견 된 결함의 대부분은 사용자 인터페이스와 관련이 있을 수 있지만 다른 결함은 특정 테스트의 부산물로 발견 될 수 있습니다.

 

3.3.2 결함 분류

결함 분류는 결함 유형 목록으로 분류됩니다. 이 목록은 매우 일반적 일 수 있으며 상위 수준 지침으로 사용되거나 매우 구체적 일 수 있습니다. 예를 들어, 사용자 인터페이스 결함에 대한 분류는 기능, 오류 처리, 그래픽 디스플레이 및 성능과 같은 일반적인 항목을 포함 할 수 있습니다. 상세한 분류에는 가능한 모든 사용자 인터페이스 객체 목록 (특히 그래픽 사용자 인터페이스의 경우)이 포함될 수 있으며 다음과 같은 객체의 부적절한 처리를 지정할 수 있습니다,

예:

l  텍스트 필드

o 유효한 데이터는 허용되지 않습니다.

o 잘못된 데이터가 허용됩니다.

o 입력 길이가 검증되지 않았습니다.

o 특수 문자가 감지되지 않습니다.

o 사용자 오류 메시지는 유익하지 않습니다.

o 사용자가 잘못된 데이터를 수정할 수 없음

o 규칙이 적용되지 않습니다.

l  날짜 입력란

o 유효한 날짜는 받아 들여지지 않습니다.

o 잘못된 날짜가 거부되지 않았습니다.

o 기간이 확인되지 않았습니다.

o 정밀도 데이터가 올바르게 처리되지 않음 (예 : hh : mm : ss)

o 사용자가 잘못된 데이터를 수정할 수 없음

o 규칙이 적용되지 않습니다 (예 : 종료 날짜가 시작 날짜보다 커야 함).

구매할 수 있는 정식 분류 체계부터 다양한 조직에서 특정 목적으로 설계된 분류 체계까지 다양한 결함 분류가 있습니다. 내부적으로 개발 된 결함 분류는 조직 내에서 일반적으로 발견되는 특정 결함을 타깃으로 하는 데 사용될 수 있습니다. 새로운 결함 분류법을 만들거나 사용할 수 있는 분류 분류를 사용자 정의 할 때 먼저 분류법의 목표 또는 목적을 정의하는 것이 중요합니다. 예를 들어 프로덕션 시스템에서 발견 된 사용자 인터페이스 문제를 식별하거나 입력 필드 처리와 관련된 문제를 식별하는 것이 목표 일 수 있습니다.

분류 체계를 만드는 방법은 다음과 같습니다.

1. 목표를 만들고 원하는 세부 수준을 정의하십시오.

2. 주어진 분류 체계를 선택하여 기초로 사용하십시오.

3. 조직 및 / 또는 외부 연습에서 경험 한 가치 및 공통적 인 결함 정의

분류법이 상세할수록 개발 및 유지 관리에 더 많은 시간이 소요되지만 테스트 결과에서 재현성이 높아집니다. 세부적인 분류 체계는 중복 될 수 있지만 테스트 팀은 정보 나 범위를 잃지 않고 테스트를 나눌 수 있습니다.

적절한 분류 체계를 선택하면 테스트 조건 및 테스트 케이스를 작성하는 데 사용할 수 있습니다. 위험 기반 분류 체계는 특정 위험 영역에 초점을 맞출 수 있습니다. 분류 체계는 유용성, 성능 등과 같은 비 기능 영역에도 사용할 수 있습니다. 분류 목록은 IEEE, 인터넷 등 다양한 서적에서 사용할 수 있습니다.

 

3.4 경험 기반 기술

경험 기반 테스트는 테스터의 숙련도 및 직감과 유사한 응용 프로그램 또는 기술을 사용한 경험을 활용합니다. 이 테스트는 결함을 찾아내는 데는 효과적이지만 특정 테스트 커버리지 수준을 달성하거나 재사용 가능한 테스트 절차를 생성하는 다른 기술만큼 적절하지는 않습니다. 시스템 문서가 불량하고 테스트 시간이 심각하게 제한되거나 테스트 팀이 테스트 할 시스템에 대한 전문성이 강한 경우에는 경험 기반 테스팅이 보다 체계적인 접근 방식의 좋은 대안이 될 수 있습니다. 경험 기반 테스트는 상세한 테스트 문서화, 높은 수준의 반복성 또는 테스트 범위를 정확하게 평가할 수 있는 기능이 필요한 시스템에서는 부적절 할 수 있습니다.

동적 및 경험적 접근 방식을 사용하는 경우 테스터는 일반적으로 경험 기반 테스트를 사용하고 테스트는 사전 계획된 테스팅 방식보다 이벤트에보다 민감합니다. 또한 실행 및 평가는 동시 작업입니다. 경험 기반 테스트에 대한 구조화 된 접근법 중 일부는 완전히 동적이어서는 안되며, 즉 테스터가 테스트를 실행하는 동시에 테스트가 완전히 생성되는 것은 아닙니다.

여기서 다루는 기술에 대해 적용 범위에 대한 몇 가지 아이디어가 제시되었지만 경험 기반 기술에는 공식 적용 범위 기준이 없습니다.

3.4.1 오류 추측

오류 추측 기술을 사용할 때, Test Analyst는 경험을 사용하여 코드가 설계되고 개발 될 때 발생할 수 있는 잠재적 인 오류를 추측합니다. 예상되는 오류가 확인되면 Test Analyst는 결과 결함을 발견하는 데 사용할 최상의 방법을 결정합니다. 예를 들어, 테스트 분석가가 잘못된 암호를 입력했을 때 소프트웨어에서 오류가 발생할 것으로 예상되는 경우 암호 필드에 다양한 값을 입력하여 오류가 실제로 발생했는지 확인하고 오류가 발생했는지 테스트가 실행될 때 실패로 간주 될 수 있습니다.

오류 추측은 테스트 기술로 사용되는 것 외에도 잠재적 인 오류 모드를 식별하기 위해 위험 분석 중에 유용합니다. [Myers79]

 

적용 분야

오류 추측은 주로 통합 및 시스템 테스트 중에 수행되지만 모든 테스트 단계에서 사용할 수 있습니다. 이 기술은 다른 기술과 함께 사용되며 기존 테스트 케이스의 범위를 넓히는 데 도움이 됩니다. 오류 추측은 또한 보다 엄격하고 스크립트 된 테스트를 시작하기 전에 일반적인 실수와 오류를 테스트하기 위해 소프트웨어의 새 릴리스를 테스트 할 때 효과적으로 사용할 수 있습니다. 체크리스트와 분류 체계가 테스트를 안내하는 데 도움이 될 수 있습니다.

 

한계 / 어려움

커버리지는 평가하기 어렵고 테스트 분석가의 역량과 경험에 따라 크게 다릅니다.

경험이 많은 테스터가 테스트 할 코드 유형에 일반적으로 도입되는 결함 유형에 익숙한 사람에게 가장 적합합니다. 오류 추측은 일반적으로 사용되지만 자주 문서화되지 않으므로 다른 테스트 형식보다 재현성이 떨어질 수 있습니다.

 

적용 범위

분류체계가 사용될 때, 적용 범위는 적절한 데이터 오류 및 결함 유형에 의해 결정됩니다. 분류체계가 없으면 테스터의 경험과 지식 및 사용 가능한 시간으로 인해 적용 범위가 제한됩니다. 이 기법의 수율은 테스터가 문제가 되는 영역을 얼마나 잘 대상으로 할 수 있는지에 따라 달라집니다.

 

결함 유형

일반적인 결함은 일반적으로 특정 분류법에서 정의되거나 테스트 분석가가 "추측 한"것으로 스펙 기반 테스트에서 발견되지 않았을 수 있습니다.

 

3.4.2 점검표 근거한 시험

체크리스트 기반 테스팅 기술을 적용 할 때, 숙련 된 테스트 분석가는 주목할 점, 확인 또는 기억해야 할 높은 수준의 일반 항목 목록 또는 제품을 검증해야 하는 규칙 또는 기준 세트를 사용합니다. 이 체크리스트는 일련의 표준, 경험 및 기타 고려 사항을 기반으로 구축됩니다. 응용 프로그램을 테스트하기 위한 기초로 사용되는 사용자 인터페이스 표준 검사 목록은 검사 목록 기반 테스트의 한 예입니다.

 

적용 분야

체크리스트 기반 테스팅은 테스트중인 소프트웨어에 익숙하거나 체크리스트에서 다루는 영역에 익숙한 숙련 된 테스트 팀이 있는 프로젝트에서 가장 효과적으로 사용됩니다 (예: 사용자 인터페이스 체크리스트를 성공적으로 적용하기 위해 테스트 분석가는 사용자 인터페이스 테스트는 지원하지만 테스트 대상 소프트웨어는 제외). 체크리스트는 고급이며 테스트 케이스 및 테스트 절차에서 일반적으로 발견되는 세부 단계가 부족하기 때문에 테스터에 대한 지식을 사용하여 공백을 메우십시오. 세부 단계를 제거하면 점검 목록의 유지 관리가 줄어들며 여러 유사 릴리스에 적용 할 수 있습니다. 검사 목록은 모든 수준의 검사에 사용할 수 있습니다. 체크리스트는 회귀 테스트 및 연기 테스트에도 사용됩니다.

 

한계 / 어려움

체크리스트의 상위 수준 특성은 테스트 결과의 재현성에 영향을 줄 수 있습니다. 여러 명의 테스터가 체크리스트를 다르게 해석하고 체크리스트 항목을 수행하기 위해 여러 가지 방법을 따를 가능성이 있습니다. 동일한 점검표를 사용하더라도 다른 결과가 발생할 수 있습니다. 이것은 더 넓은 적용 범위를 초래할 수 있지만 재현성이 때때로 희생됩니다. 체크리스트는 실제 테스팅이 테스터의 판단에 의존하기 때문에 달성되는 커버리지의 레벨에 대해 지나친 자신감을 갖게 할 수도 있다. 체크리스트는 보다 자세한 테스트 케이스 또는 목록에서 파생 될 수 있으며 시간이 지남에 따라 커지는 경향이 있습니다. 점검 목록이 테스트중인 소프트웨어의 중요한 부분을 다루는 지 확인하려면 유지 보수가 필요합니다.

 

적용 범위

적용 범위는 체크리스트만큼 좋지만 체크리스트의 고급 특성으로 인해 체크리스트를 실행하는 테스트 분석가에 따라 결과가 달라집니다.

 

결함 유형

이 기술로 발견 된 일반적인 결함은 데이터 변경, 단계의 순서 또는 테스트 중 일반적인 워크 플로로 인한 실패를 포함합니다. 체크리스트를 사용하면 테스팅 중에 데이터와 프로세스의 새로운 조합이 허용 될 때 새로운 테스팅을 유지할 수 있습니다.

 

3.4.3 탐색 적 테스트

탐색 적 테스트는 테스터가 제품 및 결함에 대해 동시에 학습하고, 수행 할 테스트 작업을 계획하고, 테스트를 설계 및 실행하고, 결과를 보고하는 것을 특징으로 합니다.

테스터는 실행 중에 동적으로 테스트 목표를 조정하고 간단한 문서 만 준비합니다. [휘태커 09]

 

적용 분야

좋은 탐색적 테스트가 계획되고, 대화 형이며 창조적입니다. 테스트 할 시스템에 대한 문서가 거의 필요하지 않으며 문서를 사용할 수 없거나 다른 테스트 기술에 적합하지 않은 경우에 종종 사용됩니다. 탐색 적 테스트는 다른 테스트를 보강하고 추가 테스트 사례를 개발하기 위한 기초로 사용되기 위해 종종 사용됩니다.

 

한계 / 어려움

탐색 적 테스트는 관리 및 스케줄하기가 어려울 수 있습니다. 적용 범위가 산발적이어서 재현성이 어려울 수 있습니다. 헌장을 사용하여 테스트 세션에서 다루어야 할 영역을 지정하고 테스트에 허용 된 시간을 결정하기 위한 타임 박스는 탐색 적 테스트를 관리하는 데 사용되는 한 가지 방법입니다. 테스트 세션 또는 세션 집합이 끝나면 테스트 관리자는 테스트 결과를 수집하고 다음 세션의 헌장을 결정할 수 있는 보고 세션을 가질 수 있습니다. 대형 테스팅 팀이나 대형 프로젝트의 경우보고 세션을 확장하기가 어렵습니다.

탐색 세션의 또 다른 어려움은 테스트 관리 시스템에서 이를 정확하게 추적하는 것입니다. 실제로는 실제로 시험 세션 인 테스트 사례를 작성하여 수행됩니다. 이를 통해 다른 테스트 노력으로 탐색 테스트 및 계획 적용 범위에 할당 된 시간을 추적 할 수 있습니다.

예비 테스트에서 재현성이 어려울 수 있기 때문에 장애를 재현하기 위한 단계를 다시 호출해야 할 때 문제가 발생할 수 있습니다. 일부 조직에서는 검사 자동화 도구의 캡처 / 재생 기능을 사용하여 탐색 적 테스터가 수행 한 단계를 기록합니다. 이것은 탐험 세션 (또는 체험 기반 테스트 세션) 동안 모든 활동의 완전한 기록을 제공합니다. 실패의 실제 원인을 찾기 위해 세부 사항을 파헤치면 지루할 수 있지만 적어도 관련된 모든 단계에 대한 기록이 있습니다.

 

적용 범위

태스크, 목표 및 산출물을 지정하기 위해 차터가 작성 될 수 있습니다. 그런 다음 목적을 달성하기 위해 탐색적인 세션을 계획합니다. 헌장은 또한 시험 활동의 초점, 시험 세션의 범위와 범위 밖, 계획된 시험을 완료하기 위해 어떤 자원을 투입해야 하는지를 식별 할 수 있습니다. 세션은 특정 결함 유형 및 스크립팅 된 테스트의 형식 없이 해결 될 수 있는 잠재적으로 문제가 되는 영역에 집중할 수 있습니다.

 

결함 유형

탐색 적 테스트에서 발견 된 일반적인 결함은 스크립팅 된 기능 테스트 중에 누락 된 시나리오 기반 문제, 기능 경계 사이의 문제 및 워크 플로 관련 문제입니다. 성능 및 보안 문제는 탐색 테스트 중에도 발견되는 경우가 있습니다.

 

3.4.4 최상의 기술 적용

결함 및 경험 기반 기술은 결함 탐지를 높이기 위해 결함 및 기타 테스트 경험에 대한 지식을 적용하여 테스트 대상으로 지정해야 합니다. 테스터가 수행 할 공식적으로 사전 계획된 활동이 없는 사전 테스트 세션부터 미리 계획된 세션 및 스크립팅 된 세션에 이르기까지 다양합니다. 그것들은 거의 항상 유용하지만 다음과 같은 상황에서 특별한 가치가 있습니다:

l  사용할 수 있는 사양이 없습니다.

l  테스트중인 시스템에 대한 설명서가 부족합니다.

l  상세한 테스트를 설계하고 생성하기에 불충분 한 시간이 허용됩니다.

l  테스터는 도메인 및 / 또는 기술 분야에서 경험이 풍부합니다.

l  스크립팅 된 테스트의 다양성은 테스트 범위를 극대화하는 목표입니다.

l  작동 불량을 분석해야 한다.

결함 기반 및 경험 기반 기법은 사양 기반 기술과 함께 사용할 경우에도 유용합니다. 이러한 기술의 체계적인 약점으로 인해 테스트 커버리지에서 부족한 부분을 채울 수 있기 때문입니다. 사양 기반 기술과 마찬가지로 모든 상황에 적합한 기술은 하나도 없습니다. 시험 분석가는 각 기술의 장점과 단점을 이해하고 프로젝트 유형, 일정, 정보에 대한 접근성, 테스터 기술 및 기타 기술, 선택에 영향을 줄 수 있는 요인을 고려하여 상황에 대한 최상의 기술 또는 기술 집합을 선택할 수 있어야 합니다.

4. 소프트웨어 품질 특성 테스트 - 120 분.

키워드

접근성 테스트, 정확성 테스트, 매력, 휴리스틱 평가, 상호 운용성 테스트,

학습 능력, 조작성, 적합성 테스트, SUMI, 이해 가능성, 유용성 테스트, WAMMI

소프트웨어 품질 특성 테스트를위한 학습 목표

4.2 비즈니스 영역 테스트를위한 품질 특성

TA-4.2.1 (K2) 예제를 통해 정확성, 적합성, 상호 운용성 및 컴플라이언스 특성을 테스트하는 데 적합한 테스트 기술이 무엇인지 설명하십시오. TA-4.2.2 (K2) 정확성, 적합성 및 상호 운용성 특성을 위해 표적화 될 일반적인 결함을 정의하십시오

TA-4.2.3 (K2) 정확성, 적합성 및 상호 운용성 특성에 대해 특성을 라이프 사이클에서 테스트 해야 하는 시점을 정의하십시오.

TA-4.2.4 (K4) 주어진 프로젝트 컨텍스트에서 사용성 요구 사항의 구현과 사용자의 기대 충족을 검증하고 검증하는 데 적합한 방법을 간략히 설명하십시오

4.1 소개

이전 장에서는 테스터가 사용할 수 있는 특정 기술에 대해 설명했지만 이 장에서는 소프트웨어 응용 프로그램 또는 시스템의 품질을 설명하는 데 사용 된 주요 특성을 평가할 때 이러한 기술의 적용을 고려합니다.

이 강의 계획은 테스트 분석가가 평가할 수 있는 품질 특성을 설명합니다. 기술 테스트 분석가가 평가할 속성은 고급 기술 테스트 분석가의 강의 계획서에서 고려됩니다. ISO 9126에 제공된 제품 품질 특성에 대한 설명은 특성을 설명하는 지침으로 사용됩니다. ISO 25000 [ISO25000] 시리즈 (ISO 9126을 대체)와 같은 다른 표준도 사용할 수 있습니다. ISO 품질 특성은 제품 품질 특성 (속성)으로 나뉘며 각 제품은 하위 특성 (하위 특성)을 가질 수 있습니다. 아래 표에는 테스트 분석가 및 기술 테스트 분석가의 실러비가 어떤 특성 / 하위 특성을 포함하고 있는지 표시가 나와 있습니다.

 

특성	부 특성	테스트 분석가	기술 테스트 분석자
기능	정확성, 적합성, 상호 운용성,	X
	보안		X
신뢰성	성숙 (견고성), 결함 허용, 복구 가능성, 컴플라이언스	X	X
유용성	이해력, 학습 가능성, 조작성, 매력, 준수	X
능률	성과 (시간 행동), 자원 활용, 준수		X
유지 보수성	분석 가능성, 변경 가능성, 안정성, 테스트 가능성, 컴플라이언스		X
이식성	적응력, 설치 가능성, 공존, 교체 가능성, 컴플라이언스		X

Test Analyst는 기능 및 유용성의 소프트웨어 품질 특성에 집중해야 합니다. 접근성 테스트는 테스트 분석가가 수행해야 합니다. 하위 특성으로 나열되지는 않았지만 액세스 가능성은 종종 사용성 테스트의 일부로 간주됩니다. 다른 품질 특성 테스트는 일반적으로 기술 테스트 분석가의 책임으로 간주됩니다. 이 작업 배분은 조직마다 다를 수 있지만 ISTQB 강의 계획서에서 준수해야 합니다.

각 품질 특성에 대해 준수의 하위 특성이 표시됩니다. 특정 안전 또는 규제 환경의 경우 각 품질 특성은 특정 표준 및 규정을 준수해야 할 수 있습니다 (예: 기능 준수는 기능이 특정 통신 프로토콜을 사용하는 것과 같은 특정 표준을 준수 함을 나타낼 수 있음) 칩에서 데이터를 송수신 할 수 있음). 이러한 표준은 업계에 따라 크게 다를 수 있으므로 여기서는 자세히 설명하지 않습니다. 테스트 분석가가 컴플라이언스 요구 사항의 영향을 받는 환경에서 작업하는 경우 이러한 요구 사항을 이해하고 테스트 및 테스트 문서가 컴플라이언스 요구 사항을 충족하는지 확인하는 것이 중요합니다.

이 절에서 논의 된 모든 품질 특성 및 하위 특성에 대해 적절한 테스트 전략을 수립하고 문서화 할 수 있도록 일반적인 위험을 인식해야 합니다. 품질 특성 테스트에는 수명주기, 필요한 도구, 소프트웨어 및 문서 가용성 및 전문 기술에 특히 주의해야 합니다. 각 특성 및 고유 한 테스트 요구 사항을 처리하기 위한 전략을 계획하지 않으면 테스터는 적절한 계획, 램프 업 및 테스트 실행 시간을 일정에 포함하지 못할 수 있습니다.

 이 시험의 일부는, 예를 들어, 사용성 테스트는, 대부분의 경우, 상당한 시간이 특별한 인적 자원, 광범위한 계획, 전용 실험실, 특정 도구, 전문 시험 기술의 할당을 요구하고 있습니다. 어떤 경우에는 사용성 테스트가 사용자 또는 사용자 경험 전문가의 별도 그룹에 의해 수행 될 수 있습니다.

품질 특성 및 부 특성 시험은 전체 시험 일정에 통합되어야 하며 적절한 자원을 노력에 할당해야 합니다. 각 영역은 특정 요구 사항을 가지고 있으며 특정 문제를 대상으로 하며 아래 섹션에서 설명하는 대로 소프트웨어 개발 수명주기 동안 서로 다른 시간에 발생할 수 있습니다.

테스트 애널리스트는 기술적 인 접근 방식을 필요로 하는 품질 특성에 대해 책임을지지 않을 수도 있지만, 테스트 애널리스트는 다른 특성을 인식하고 테스트를 위한 중복 영역을 이해하는 것이 중요합니다. 예를 들어 성능 테스트에 실패한 제품은 사용자가 효과적으로 사용하기에는 너무 느리면 사용성 테스트에서도 실패 할 가능성이 높습니다. 마찬가지로, 일부 구성 요소와의 상호 운용성 문제가 있는 제품은 환경이 변경 될 때보다 기본적인 문제를 모호하게 하는 경향이 있으므로 이식성 테스트를 위한 준비가 되지 않은 것 같습니다.

 

4.2 비즈니스 영역 테스트를 위한 품질 특성

Functional Testing은 Test Analyst의 주안점입니다. 기능 테스트는 제품의 "무엇"에 초점을 맞춥니다. 기능 테스트의 테스트 기준은 일반적으로 요구 사항 또는 사양 문서, 특정 도메인 전문 지식 또는 암시 적 요구 사항입니다. 기능 테스트는 수행되는 테스트 레벨에 따라 다르며 소프트웨어 개발 수명주기의 영향을 받을 수도 있습니다. 예를 들어, 통합 테스트 중에 수행되는 기능 테스트는 정의 된 단일 기능을 구현하는 인터페이싱 모듈의 기능을 테스트합니다. 시스템 테스트 레벨에서 기능 테스트에는 응용 프로그램 전체의 기능 테스트가 포함됩니다. 시스템 시스템의 경우, 기능 테스트는 주로 통합 시스템 전반의 엔드 투 엔드 테스트에 중점을 둡니다. 민첩한 환경에서 반복 테스트를 위한 회귀 테스트가 출시 된 모든 기능을 포함 할 수 있지만 기능 테스트는 대개 특정 반복이나 스프린트에서 사용 가능한 기능으로 제한됩니다.

기능 테스트 동안 다양한 테스트 기술이 사용됩니다 (3 장 참조). 기능 테스트는 전용 테스터, 도메인 전문가 또는 개발자 (일반적으로 구성 요소 수준)에서 수행 할 수 있습니다.

이 섹션에서 다루는 기능 테스트뿐만 아니라, 작동하지 않는 것으로 간주 테스트 영역 ("어떻게"제품이 기능을 제공에 초점을 맞추고)하는 책임의 시험 분석의 영역의 한 부분에 품질 특성도 있습니다. 이 두 가지 비 기능적 속성은 유용성과 접근 성입니다.

이 절에서는 다음과 같은 품질 특성을 고려합니다:

l  기능 품질 하위 특성

o 정확도

o 적합성

o 상호 운용성

l  비 기능적 품질 특성

o 유용성

o 접근성

 

4.2.1 정확도 테스트

기능적 정확성은 명시 적 또는 묵시 요구 사항에 대한 응용 프로그램의 준수 여부를 테스트하는 것을 포함하며 계산 정확도를 포함 할 수도 있습니다. 정확성 테스트는 3 장에서 설명한 많은 테스트 기술을 사용하며 종종 테스트 오라클로서 사양 또는 레거시 시스템을 사용합니다. 정확성 테스트는 라이프 사이클의 어느 단계에서나 수행 할 수 있으며 데이터 또는 상황의 잘못된 처리를 대상으로 합니다.

 4.2.2 적합성 테스트

적합성 테스트는 의도 된 특정 작업에 대한 기능 집합의 적합성을 평가하고 유효성을 검사하는 것을 포함합니다. 이 테스트는 유스 케이스를 기반으로 할 수 있습니다. 적합성 테스트는 대개 시스템 테스트 중에 수행되지만 통합 테스팅의 후기 단계에서도 수행 될 수 있습니다. 이 테스트에서 발견 된 결함은 시스템이 수용 가능한 것으로 간주되는 방식으로 사용자의 요구를 충족시킬 수 없다는 징후입니다.

 

4.2.3 상호 운용성 테스트

상호 운용성 테스트는 둘 이상의 시스템 또는 구성 요소가 정보를 교환 할 수 있는 정도를 테스트 한 후 교환 된 정보를 사용합니다. 테스트는 데이터 교환이 제대로 작동 할 수 있도록 의도 된 모든 대상 환경 (하드웨어, 소프트웨어, 미들웨어, 운영 체제 등)을 포함해야 합니다. 현실적으로 이것은 비교적 적은 수의 환경에서만 실현 가능할 수 있습니다. 이 경우 상호 운용성 테스트는 선택된 대표 그룹 환경으로 제한 될 수 있습니다. 상호 운용성을 위한 테스트를 지정하려면 테스트 대상 팀이 의도 한 대상 환경의 조합을 식별하고 구성하여 사용할 수 있어야 합니다. 그런 다음 환경에 존재하는 다양한 데이터 교환 지점을 실행하는 기능 테스트 케이스를 사용하여 이러한 환경을 테스트합니다.

상호 운용성은 서로 다른 소프트웨어 시스템이 서로 상호 작용하는 방식과 관련이 있습니다. 상호 운용성 특성이 우수한 소프트웨어는 크게 변경하지 않고도 다른 여러 시스템과 통합 할 수 있습니다. 이러한 변경을 수행하는 데 필요한 변경 횟수 및 노력은 상호 운용성을 측정하는 데 사용할 수 있습니다.

소프트웨어 상호 운용성 테스트는 다음과 같은 디자인 기능에 중점을 둘 수 있습니다:

l  XML과 같은 업계 전반의 통신 표준 사용

l  상호 작용하는 시스템의 통신 요구를 자동으로 감지하는 기능 및

적절하게 조정

 

COTS (Commercial Off The Shelf) 소프트웨어 및 시스템을 개발하는 조직 및 조직을 개발하는 조직의 경우 상호 운용성 테스트가 특히 중요 할 수 있습니다.

이러한 유형의 테스트는 시스템 통합과 시스템 테스트 중에 수행되며 시스템과 환경의 상호 작용에 중점을 둡니다. 시스템 통합 수준에서 이 유형의 테스트는 완전하게 개발 된 시스템이 다른 시스템과 얼마나 잘 상호 작용 하는지를 결정하기 위해 수행됩니다. 시스템은 여러 수준에서 상호 운용 될 수 있으므로 테스트 분석가는 이러한 상호 작용을 이해하고 다양한 상호 작용을 수행 할 조건을 생성 할 수 있어야 합니다. 예를 들어 두 시스템이 데이터를 교환 할 경우 테스트 분석가는 필요한 데이터와 데이터 교환을 수행하는 데 필요한 트랜잭션을 생성 할 수 있어야 합니다. 모든 상호 작용이 요구 사항 문서에 명확하게 명시되어 있지 않을 수 있음을 기억하는 것이 중요합니다. 대신, 이러한 상호 작용의 대부분은 시스템 아키텍처 및 설계 문서에서만 정의됩니다. Test Analyst는 해당 문서를 검토하여 시스템 간 및 시스템과 환경 간 정보 교환 지점을 확인하여 모든 것이 테스트되었는지 확인할 수 있어야 합니다. 의사 결정 테이블, 상태 전이 다이어그램, 사용 사례 및 조합 테스트와 같은 기술은 모두 상호 운용성 테스트에 적용됩니다. 일반적인 결함으로는 상호 작용하는 구성 요소 간의 잘못된 데이터 교환이 있습니다.

 

4.2.4 사용성 테스트

사용자가 시스템 사용에 어려움을 느낄 수 있는 이유를 이해하는 것이 중요합니다. 이러한 이해를 얻으려면 먼저 "사용자"라는 용어가 IT 전문가에서 아동, 장애인에 이르기까지 다양한 유형의 사람들에게 적용될 수 있음을 알아야 합니다.

일부 국가 기관 (예: 영국 왕립 국립 맹인 연구소)은 장애인, 시각 장애인, 부분 관찰자, 이동 장애인, 농아 및 인지 장애가 있는 사용자가 웹 페이지에 액세스 할 수 있도록 권장합니다.

위의 사용자가 응용 프로그램 및 웹 사이트를 사용할 수 있는지 확인하면 다른 사용자의 유용성도 향상 될 수 있습니다. 접근성에 대해서는 아래에서 자세히 설명합니다.

l  효과 성 - 사용자가 지정된 사용 환경에서 정확하고 완전성을 갖춘 지정된 목표를 달성 할 수 있도록 해주는 소프트웨어 제품의 기능.

l  효율성 - 사용자가 지정된 사용 환경에서 달성 한 효과와 관련하여 적절한 양의 자원을 소비 할 수 있도록 제품의 기능.

l  만족도 - 지정된 사용 환경에서 사용자를 만족시키는 소프트웨어 제품의 기능

 

이해할 수 있는 속성은 다음을 포함합니다 :

l  이해력 - 논리적 개념과 그 적용 가능성을 인식하기 위해 사용자가 요구하는 노력에 영향을 미치는 소프트웨어의 속성.

l  학습 능력 - 사용자가 응용 프로그램을 학습하는 데 필요한 노력에 영향을 미치는 소프트웨어의 속성입니다.

l  조작 가능성 - 사용자가 효율적이고 효과적으로 작업을 수행하는 데 필요한 노력에 영향을 미치는 소프트웨어의 속성.

l  매력 - 사용자가 좋아할만한 소프트웨어의 기능

 

사용성 테스트는 일반적으로 다음 두 단계로 수행됩니다.

l  Formability Usability Testing - 설계 및 프로토 타이핑 단계에서 반복적으로 수행되는 테스트로 사용성 설계상의 결함을 식별하여 설계를 안내 (또는 "형성")하는 데 도움을 줍니다.

l  Summative Usability Testing - 구현 후 수행되는 테스트

유용성 및 완성 된 구성 요소 또는 시스템의 문제점 식별

 

사용성 테스터 기술에는 다음 분야의 전문 지식이나 지식이 포함되어야 합니다.

l  사회

l  심리학

l  국가 표준 (접근성 표준 포함)에 대한 적합성

l  인체 공학

 

4.2.4.1 사용성 테스트 실시

실제 구현의 유효성 확인은 시스템이 사용되는 조건에 최대한 가까운 조건에서 수행되어야 합니다. 비디오 카메라로 실용성 실험실을 구성하고, 사무실, 리뷰 패널, 사용자 등을 검토하여 실제 직원이 실제 시스템에 미치는 영향을 관찰 할 수 있습니다. 공식적인 유용성 테스트는 종종 "사용자"(실제 사용자 또는 사용자 대표 일 수 있음)를 준비하는 스크립트 나 지침을 제공하여 어느 정도 준비해야 합니다. 다른 자유 형식 테스트를 통해 사용자는 소프트웨어를 실험 할 수 있으므로 관찰자는 사용자가 자신의 작업을 수행하는 방법을 파악하는 것이 얼마나 쉽고 어려운지를 결정할 수 있습니다.

많은 유용성 테스트는 예를 들어 기능 시스템 테스트와 같이 다른 테스트의 일부로 테스트 분석가가 실행할 수 있습니다. 수명주기의 모든 단계에서 사용성 결함을 탐지하고 보고하는 일관된 접근 방식을 얻으려면 사용성 지침이 유용 할 수 있습니다. 사용성 가이드 라인이 없으면 "수용 할 수 없는"유용성이 무엇인지 판단하기 어려울 수 있습니다. 예를 들어, 사용자가 응용 프로그램에 로그인하기 위해 10 번의 마우스 클릭을 해야 한다는 것은 무리가 있습니까? 특별한 지침 없이 테스트 분석가는 소프트웨어가 "설계된 대로"작동하기 때문에 개발자가 닫으려고 하는 결함 보고서를 방어하기 어려운 위치에 있을 수 있습니다. 검증 가능한 유용성 스펙을 요구 사항에 정의하고 모든 유사한 프로젝트에 적용되는 일련의 사용성 가이드 라인을 갖는 것이 매우 중요합니다. 지침에는 지침의 접근 가능성, 프롬프트의 명확성, 활동 완료를 위한 클릭 수, 오류 메시지, 처리 표시기 (시스템이 처리 중이며 그 당시에는 추가 입력을 수용 할 수 없는 사용자를 위한 표시기 유형) , 화면 레이아웃 지침, 색상 및 사운드 사용 및 사용자의 경험에 영향을 미치는 기타 요소가 포함됩니다.

 4.2.4.2 사용성 테스트 규격

사용성 테스트를위한 주요 기술은 다음과 같습니다.

l  검사, 평가 또는 검토

l  프로토 타입과 동적으로 상호 작용

l  실제 구현 확인 및 검증

l  설문 조사 및 설문 조사 실시

 

검사, 평가 또는 검토

사용자의 참여 수준을 높이는 요구 사항 사양 및 디자인을 사용성 측면에서 검사하거나 검토하면 문제를 조기에 발견하여 비용 효과적 일 수 있습니다. 휴리스틱 평가 (유용성을 위한 사용자 인터페이스 디자인의 체계적인 검사)를 사용하여 반복적 인 설계 프로세스의 일부로 참석할 수 있도록 사용 가능성 문제를 찾을 수 있습니다. 여기에는 작은 일련의 평가자가 인터페이스를 검사하고 인식 된 사용 가능성 원칙 ("경험적 방법")을 준수하는지 판단하는 것이 포함됩니다. 사용자 인터페이스가 더 잘 보이면 리뷰가 더 효과적입니다. 예를 들어 샘플 스크린 샷은 일반적으로 특정 화면에서 제공하는 기능에 대한 설명보다 이해하기 쉽고 해석하기 쉽습니다. 시각화는 문서의 적절한 유용성 검토에 중요합니다.

 

프로토 타입과 동적으로 상호 작용

프로토 타입이 개발되면 테스트 분석가는 프로토 타입과 함께 작업하고 개발자가 사용자 피드백을 디자인에 통합하여 프로토 타입을 발전시키는 데 도움을 주어야 합니다. 이 방법으로 프로토 타입을 세련시킬 수 있으며 사용자는 완성 된 제품의 모양과 느낌을 보다 사실적으로 볼 수 있습니다.

 

실제 구현 확인 및 검증

요구 사항이 소프트웨어의 유용성 특성 (예 : 특정 목표를 달성하기 위한 마우스 클릭 수)을 지정하는 경우 소프트웨어 구현에 이러한 특성이 포함되었는지 확인하기 위한 테스트 사례를 작성해야 합니다.

실제 구현의 유효성 확인을 수행하기 위해 기능 시스템 테스트를 위해 지정된 테스트가 사용성 테스트 시나리오로 개발 될 수 있습니다. 이러한 테스트 시나리오는 기능적 결과가 아닌 학습 가능성 또는 작동 가능성과 같은 특정 사용 가능성 특성을 측정합니다.

특히 유용성에 대한 테스트 시나리오는 구문과 의미를 구체적으로 테스트하기 위해 개발 될 수 있습니다. 구문은 인터페이스의 구조 또는 문법 (예를 들어, 입력 필드에 입력 될 수 있는 것)이지만, 의미는 인터페이스의 의미 및 목적 (예 : 합리적이고 의미 있는 시스템 메시지 및 사용자에게 제공되는 출력)을 설명합니다.

블랙 박스 기술 (예 : 3.2 절에서 설명)은 특히 일반 텍스트 또는 UML (Unified Modeling Language)로 정의 할 수 있는 사용 사례가 사용성 테스트에 사용됩니다.

사용성 테스트를 위한 테스트 시나리오에는 사용자 지침, 지침을 제공하고 의견을 수렴하기 위한 사전 및 사후 테스트 인터뷰 시간 할당, 세션 수행을 위한 합의 된 프로토콜이 포함되어야 합니다. 이 프로토콜에는 테스트 수행 방법, 타이밍, 메모 작성 및 세션 로깅, 인터뷰 및 설문 조사 방법에 대한 설명이 포함됩니다.

 

설문 조사 및 설문 조사 실시

설문 조사 및 설문 조사 기법은 시스템의 사용자 행동에 관한 관찰 및 피드백을 수집하기 위해 적용될 수 있습니다. SUMI (소프트웨어 사용성 측정 인벤토리) 및 WAMMI (웹 사이트 분석 및 측정 인벤토리)와 같은 표준화되고 공개적으로 사용 가능한 설문 조사는 이전 사용성 측정의 데이터베이스에 대한 벤치마킹을 허용합니다. 또한 SUMI는 유용성을 구체적으로 측정하므로 완료 / 승인 기준 세트를 제공 할 수 있습니다.

 4.2.5 접근성 테스트
특정 요구 나 제한 사항이 있는 사람들을 위해 소프트웨어에 대한 접근성을 고려하는 것이 중요합니다. 여기에는 장애가 있는 사람들도 포함됩니다. 접근성 테스트는 장애인 차별 행위 (영국, 호주) 및 제 508 조 (미국)와 같은 웹 컨텐츠 접근성 지침 및 법규와 같은 관련 표준을 고려해야 합니다. 접근성은 사용성과 유사하게 설계 단계에서 고려해야 합니다. 테스트는 종종 통합 단계에서 발생하며 시스템 테스트와 수락 테스트 단계를 거칩니다. 결함은 일반적으로 소프트웨어가 소프트웨어에 대해 지정된 규정 또는 표준을 충족시키지 못할 때 결정됩니다.

5. 리뷰 - 165 mins.

키워드

없음

리뷰를위한 학습 목표

5.1 서론

TA-5.1.1 (K2) 테스트 분석가가 검토 준비가 중요한 이유를 설명하십시오

5.2 리뷰에서 체크리스트 사용하기

TA-5.2.1 (K4) 유스 케이스에서 제공되는 체크리스트 정보에 따라 유스 케이스 또는 사용자 인터페이스를 분석하고 문제를 식별합니다.

TA-5.2.2 (K4) 요구 사항 사양 또는 사용자 스토리를 분석하고 강의 계획서에 제공된 점검 목록 정보에 따라 문제점을 식별하십시오.

5.1 서론

성공적인 검토 프로세스에는 계획, 참여 및 후속 조치가 필요합니다. 테스트 분석가는 검토 프로세스에 적극적으로 참여하여 고유 한 견해를 제공해야 합니다. 검토 과정에서 각자의 역할을 더 잘 이해하기 위해 공식적인 검토 교육을 받아야 합니다. 모든 검토 참가자는 잘 수행 된 검토의 이점을 위해 최선을 다해야 합니다. 제대로 완료되면 검토는 전반적으로 제공되는 품질에 가장 큰 단일 비용으로 가장 효과적 일 수 있습니다.

수행되는 검토 유형에 관계없이 시험 분석가는 준비하기에 충분한 시간을 허용해야 합니다. 여기에는 작업 결과를 검토하는 시간, 일관성을 확인하기 위해 교차 참조 된 문서를 확인하는 시간 및 작업 제품에서 누락 된 항목을 결정하는 시간이 포함됩니다. 적절한 준비 시간이 없으면 테스트 분석가는 검토 팀의 시간 사용을 극대화하고 최상의 피드백을 제공하는 효율적인 검토에 참여하기보다는 문서에 이미 포함되어있는 내용을 편집하는 것으로 만 제한 될 수 있습니다. 좋은 리뷰는 무엇이 작성되었는지를 이해하고, 빠진 것이 무엇인지를 결정하고, 설명 된 제품이 이미 개발되었거나 개발중인 다른 제품과 일치하는지 확인하는 것을 포함합니다. 예를 들어 통합 수준 테스트 계획을 검토 할 때 테스트 분석가는 통합되는 항목도 고려해야 합니다. 통합 준비에 필요한 조건은 무엇입니까? 문서화 해야 하는 종속성이 있습니까? 통합 지점을 테스트 할 수 있는 데이터가 있습니까? 검토는 검토중인 작업 제품과 분리되지 않습니다. 해당 항목과 시스템의 다른 항목 간의 상호 작용을 고려해야 합니다.

검토 대상 제품의 저자가 비판을 받기 쉽습니다. Test Analyst는 가능한 최고의 제품을 만들기 위해 작성자와 함께 작업한다는 관점에서 검토 주석에 접근해야 합니다. 이 접근법을 사용함으로써, 코멘트는 건설적으로 말로 표시되고 저자가 아닌 작업 결과물로 향하게 됩니다. 예를 들어 진술이 애매한 경우 "이 요구 사항이 올바르게 구현되었는지 확인하기 위해 내가 테스트해야 할 것을 이해하지 못한다"고 말하는 것이 낫습니다. "이 요구 사항은 모호하며 아무도 알아 내지 못할 것입니다."검토의 테스트 분석가는 작업 결과물에서 제공되는 정보가 지원하기에 충분한 지 확인합니다 테스트 노력. 정보가 없거나 명확하지 않거나 필요한 수준의 세부 정보를 제공하지 못하면 작성자가 수정해야 하는 결함 일 수 있습니다. 비판적인 접근보다는 긍정적 인 접근 방식을 유지함으로써 의견을 더 잘 받아들이고 회의가 더 생산적으로 될 것입니다.

 

5.2 리뷰에서 체크리스트 사용하기

체크리스트는 검토 중에 참가자가 특정 시점을 검토하도록 상기시키기 위해 검토 중에 사용됩니다. 체크리스트는 리뷰 검토 시 맞춤 설정을 해제하는 데 도움을 줄 수 있습니다. 예 : '리뷰 할 때마다 사용하는 체크리스트와 동일하므로 작업 제품 만 타겟팅 하는 것이 아닙니다.' 체크리스트는 일반적 일 수 있으며 모든 리뷰에 사용되거나 특정 품질 특성, 영역 또는 문서 유형에 집중할 수 있습니다. 예를 들어, 일반 체크리스트는 고유 식별자, TBD 참조 없음, 적절한 형식 및 유사한 적합성 항목 등 일반적인 문서 속성을 확인할 수 있습니다. 요구 사항 문서에 대한 특정 체크리스트에는 "shall"및 "should"라는 용어의 올바른 사용에 대한 점검이 포함되어 있으며 각 요구 사항의 테스트 가능성을 확인하는 등의 작업을 수행 할 수 있습니다. 요구 사항의 형식은 사용될 검사 목록 유형을 나타낼 수도 있습니다. 서술 텍스트 형식의 요구 사항 문서는 다이어그램을 기반으로 하는 요구 사항 문서와 다른 검토 기준을 갖습니다.

체크리스트는 프로그래머 / 건축가 스킬 세트 또는 테스터 스킬 세트를 지향 할 수도 있습니다. 테스트 분석가의 경우 테스터 기술 세트 체크리스트가 가장 적합합니다. 이 체크리스트에는 아래와 같은 항목이 포함될 수 있습니다.

 요구 사항, 사용 사례 및 사용자 스토리에 사용되는 체크리스트는 일반적으로 코드 또는 아키텍처에 사용 된 것과는 다른 초점을 둡니다. 이러한 요구 사항 지향 체크리스트는 다음 항목을 포함 할 수 있습니다:

l  각 요구 사항의 테스트 가능성

l  각 요구 사항에 대한 수락 기준

l  적용 가능한 경우 유스 케이스 호출 구조의 가용성

l  각 요구 사항 / 사용 사례 / 사용자 스토리의 고유 한 식별

l  각 요구 사항 / 사용 사례 / 사용자 스토리의 버전 관리

l  비즈니스 / 마케팅 요구 사항의 각 요구 사항에 대한 추적 성

l  요구 사항과 사용 사례 간의 추적 성

위의 내용은 예제로 제공되는 것을 의미합니다. 테스트 분석가가 테스트 방법을 결정할 수 없는 방식으로 요구 사항을 테스트 할 수 없는 경우 해당 요구 사항에 결함이 있다는 것을 기억해야 합니다. 예를 들어 "소프트웨어는 매우 사용자 친화적이어야 합니다"라는 요구 사항은 테스트 할 수 없습니다. 테스트 분석가가 소프트웨어가 사용자 친화적인지 또는 사용자 친화적인지를 어떻게 판단 할 수 있습니까? "소프트웨어가 사용성 표준 문서에 명시된 사용성 표준을 준수해야 합니다"라는 요구 사항이 있고 사용성 표준 문서가 실제로 존재하는 경우 이 요구 사항은 테스트 가능한 요구 사항입니다. 이 요구 사항은 인터페이스의 모든 항목에 적용되기 때문에 또한 중요한 요구 사항입니다. 이 경우 하나의 요구 사항만으로도 많은 개별 테스트 케이스를 쉽게 생성 할 수 있습니다. 참조 된 사용 가능성 명세가 변경되어야 할 경우 모든 테스트 사례를 검토하고 필요에 따라 업데이트 해야 하기 때문에 이 요구 사항 또는 유용성 표준 문서에서 테스트 사례에 이르는 추적 가능성 또한 중요합니다.

테스터가 테스트가 통과했는지 실패했는지를 판단 할 수 없거나 합격 또는 불합격 인 테스트를 구성 할 수 없는 경우 요구 사항도 테스트 할 수 없습니다. 예를 들어, "시스템은 시간의 100 %, 하루 24 시간, 주 7 일, 연중 365 일 (또는 366 일)"을 사용할 수 있어야 합니다.

.

사용 사례 검토를 위한 간단한 점검 목록에는 다음 질문이 포함될 수 있습니다.

 

l  주요 경로 (시나리오)가 명확하게 정의되어 있습니까?

l  모든 대체 경로 (시나리오)가 식별되고 오류 처리가 완료됩니까?

l  사용자 인터페이스 메시지가 정의되어 있습니까?

l  하나의 주요 경로 만 있습니까 (아니면 여러 개의 유스 케이스가 있어야합니다).

l  각 경로를 테스트 할 수 있습니까?

응용 프로그램의 사용자 인터페이스에 대한 사용 편리성에 대한 간단한 점검 목록에는 다음이 포함될 수 있습니다:

l  각 필드와 함수가 정의되어 있습니까?

l  모든 오류 메시지가 정의되어 있습니까?

l  모든 사용자 프롬프트가 정의되고 일관성이 있습니까?

l  필드의 탭 순서가 정의되어 있습니까?

l  마우스 동작 대신 키보드를 사용할 수 있습니까?

l  사용자에게 정의 된 "바로 가기"키 조합 (예 : 잘라 내기 및 붙여 넣기)이 있습니까?

l  필드간에 종속성이 있습니까 (특정 날짜는 다른 날짜보다 늦어야 함)

l  화면 레이아웃이 있습니까?

l  화면 레이아웃이 지정된 요구 사항과 일치합니까?

l  시스템이 처리 될 때 나타나는 사용자에 대한 표시기가 있습니까?

l  화면이 최소 마우스 클릭 요구 사항 (정의 된 경우)을 충족합니까?

l  유스 케이스 정보를 기반으로 사용자가 논리적으로 이동하는지 여부

l  화면이 학습 가능성에 대한 요구 사항을 충족합니까?

l  사용자가 사용할 수 있는 도움말 텍스트가 있습니까?

l  사용자가 사용할 수 있는 마우스 오버 텍스트가 있습니까?

l  사용자가 이것을 "매력적"이라고 생각합니까 (주관적 평가)?

l  색상 사용은 다른 응용 프로그램 및 조직 표준과 일치합니까?

l  사운드 효과가 적절하게 사용되고 있으며 구성 할 수 있습니까?

l  화면이 현지화 요구 사항을 충족합니까?

l  사용자가 할 일 (이해 가능성)을 결정할 수 있습니까 (주관적 평가)?

l  사용자가해야 할 일 (학습 능력) (주관 평가)을 기억할 수 있습니까?

민첩한 프로젝트에서 요구 사항은 일반적으로 사용자 스토리의 형태를 취합니다. 이 이야기는 시연 가능한 기능의 작은 단위를 나타냅니다. 유스 케이스는 여러 기능 영역을 가로 지르는 사용자 트랜잭션이지만 사용자 스토리는 더 고립되어 있으며 일반적으로 사용자 스토리는 개발하는 데 걸리는 시간에 따라 범위가 지정됩니다. 사용자 이야기에 대한 체크리스트는 다음을 포함 할 수 있습니다:

 

l  스토리가 목표 반복 / 스프린트에 적합한가?

l  수용 기준을 정의하고 테스트 할 수 있습니까?

l  기능이 명확하게 정의되어 있습니까?

l  이 이야기와 다른 이야기 사이에 어떤 의존성이 있습니까?

l  이야기의 우선 순위가 정해져 있습니까?

l  이야기에 하나의 기능 항목이 포함되어 있습니까?

 

물론 스토리가 새로운 인터페이스를 정의한다면 일반적인 스토리 체크리스트 (예 :

자세한 사용자 인터페이스 체크리스트가 적절할 것입니다.

체크리스트는 다음을 기반으로 맞춤 설정할 수 있습니다.

l  조직 (예: 회사 정책, 표준, 협약 고려)

l  프로젝트 / 개발 노력 (예: 초점, 기술 표준, 위험)

l  검토중인 객체 (예: 코드 리뷰는 특정 프로그래밍 언어에 맞게 조정될 수 있습니다. )

좋은 체크리스트는 문제를 발견하고 체크리스트에서 특별히 언급되지 않았을 수도 있는 다른 아이템에 대한 토론을 시작하는데 도움이 될 것입니다. 체크리스트의 조합을 사용하면 리뷰가 최고 품질의 작업 결과를 달성 할 수 있는 확실한 방법입니다. Foundation Level 강의에서 언급 한 것과 같은 표준 체크리스트를 사용하고 위에 제시된 것과 같은 조직 별 특정 체크리스트를 개발하면 시험 분석가가 검토에 효과적으로 도움이 됩니다.

리뷰 및 검사에 대한 자세한 내용은 [Gilb93] 및 [Wiegers03]을 참조하십시오.

 6. 결함 관리 - 120 분.

키워드

결함 분류, 위상 봉쇄, 근본 원인 분석

결함 관리 학습 목표

6.2 결함을 언제 발견 할 수 있습니까?

TA-6.2.1 (K2) 위상 억제가 비용을 절감 할 수 있는 방법을 설명하십시오

6.3 결함 보고서 필드

TA-6.3.1 (K2) 기능 외 결함을 문서화 할 때 필요할 수 있는 정보를 설명하십시오.

6.4 결함 분류

TA-6.4.1 (K4) 주어진 결함에 대한 분류 정보를 확인, 수집 및 기록한다.

6.5 근본 원인 분석

TA-6.5.1 (K2) 근본 원인 분석의 목적 설명

6.1 서론

테스트 분석가는 비즈니스 및 사용자 요구 측면에서 시스템의 동작을 평가합니다. 예를 들어 사용자는 이 메시지 또는 동작에 직면했을 때 수행 할 작업을 알 수 있습니다. 실제 결과와 예상 결과를 비교하여 시스템이 올바르게 작동하는지 테스트 분석가가 결정합니다. 이례 (사건이라고도 함)는 추가 조사가 필요한 예기치 않은 사건입니다. 이상은 결함으로 인한 실패 일 수 있습니다. 이상 현상으로 인해 결함 보고서가 생성되거나 생성되지 않을 수 있습니다. 결함은 해결되어야 하는 실제 문제입니다.

 

6.2 결함을 언제 발견 할 수 있습니까?

정적 테스트를 통해 결함을 감지 할 수 있으며 동적 테스트를 통해 결함의 증상 인 실패를 감지 할 수 있습니다. 소프트웨어 개발 라이프 사이클의 각 단계는 잠재적 인 오류를 감지하고 제거하는 방법을 제공해야 합니다. 예를 들어, 개발 단계에서 결함을 발견하기 위해 코드 및 설계 검토를 사용해야 합니다. 동적 테스트 중 테스트 케이스는 오류를 감지하는 데 사용됩니다.

결함이 발견되어 수정 될수록 시스템 전체의 품질 비용은 낮아집니다. 예를 들어 정적 테스트는 동적 테스트가 가능하기 전에 결함을 발견 할 수 있습니다. 이것이 정적 테스트가 고품질 소프트웨어를 생산하는 데 비용 효율적인 접근 방식 인 이유 중 하나입니다.

결함 추적 시스템을 통해 테스트 분석가는 결함이 도입 된 라이프 사이클의 단계와 결함이 발견 된 단계를 기록 할 수 있어야 합니다. 두 단계가 동일하면 완벽한 위상 봉쇄가 이루어집니다. 이것은 결함이 도입되어 동일한 단계에서 발견되었고 나중에 단계에서 벗어나지 않았다는 것을 의미합니다. 이에 대한 예는 요구 사항 검토 중에 확인 된 잘못된 요구 사항이며 거기에서 수정됩니다. 이는 요구 사항 검토를 효율적으로 사용 할 뿐만 아니라 결함으로 인해 조직에 비용이 많이 드는 추가 작업이 발생하는 것을 방지합니다. 잘못된 요구 사항이 요구 사항 검토에서 "빠져 나와"이어서 개발자가 구현하고, 테스트 분석가가 테스트하고 사용자 수락 테스트 중에 사용자가 포착 한 경우 해당 요구 사항에 대해 수행 한 모든 작업이 낭비되었습니다 (사용자는 이제 시스템에 대한 신뢰를 상실했을 수 있습니다.)

단계 억제는 결함 비용을 줄이는 효과적인 방법입니다.

 

6.3 결함 보고서 필드

결함 보고서에 제공된 필드 (매개 변수)는 결함 보고서가 실행될 수 있도록 충분한 정보를 제공하기 위한 것입니다. 실행 가능한 결함 보고서는 다음과 같습니다.

l  완료 - 필요한 모든 정보가 보고서에 있습니다.

l  간결한 - 보고서에 관계없는 정보 없음

l  정확한 - 보고서의 정보가 정확하고 예상 및 실제 정보가 명확하게 명시되어 있습니다.

l  결과 및 재현 할 적절한 단계

l  목표 - 보고서는 전문적으로 작성된 진술

결함 보고서에 기록 된 정보는 데이터 필드로 나누어 져야 합니다. 더 잘 정의 된 필드 일수록 개별 결함을 보고하고 추세 보고서 및 기타 요약 보고서를 작성하는 것이 더 쉬워집니다. 필드에 정의 된 수의 옵션을 사용할 수 있는 경우 사용 가능한 값 목록을 드롭 다운하면 결함을 기록 할 때 필요한 시간이 줄어들 수 있습니다. 드롭 다운 목록은 옵션 수가 제한되어 있고 사용자가 올바른 옵션을 찾으려면 긴 목록을 스크롤 하지 않아도 유효합니다. 다양한 유형의 결함 보고서에는 서로 다른 정보가 필요하며 결함 관리 도구는 결함 유형에 따라 올바른 필드를 요구 할 만큼 유연해야 합니다.

 

데이터 입력 실패를 피하고 효과적인 보고를 보장하기 위해 데이터 검증에 의해 이상적으로 지원되는 고유 한 필드에 데이터를 기록해야 합니다.

결함 보고서는 기능 및 비 기능 테스트 중에 발견 된 오류에 대해 작성됩니다. 결함 보고서의 정보는 예상되는 결과와 실제 결과뿐만 아니라 해당 시나리오를 재현하는 데 필요한 단계와 데이터를 포함하여 문제가 감지 된 시나리오를 명확하게 식별 할 수 있도록 항상 지향되어야 합니다. 기능 외 결함보고는 환경, 다른 성능 파라미터 (예 : 하중의 크기), 단계의 순서 및 예상되는 결과에 관한 더 많은 세부 사항을 요구할 수 있다. 유용성 실패를 문서화 할 때 사용자가 소프트웨어가 기대하는 바를 기술하는 것이 중요합니다. 예를 들어 사용 편리 성 표준이 4 번의 마우스 클릭 이하로 작업이 완료되어야 한다는 것이라면, 결함 보고서는 명시된 표준보다 몇 번의 클릭이 필요한지를 나타내야 합니다. 표준을 사용할 수 없고 요구 사항이 소프트웨어의 기능 외 품질 측면을 다루지 않는 경우 테스터는 "합리적인 사람"테스트를 사용하여 사용 성이 용납 될 수 없다고 판단 할 수 있습니다. 그러한 경우, 그 "합리적인 사람"의 기대는 결함 보고서에 명확하게 기술되어야 한다. 비 기능적 요구 사항이 때로는 요구 사항 문서에서 누락되기 때문에 비 기능적 실패를 문서화하는 것은 테스터가 "예상"대 "실제"동작을 문서화하는 데 더 많은 어려움을 낳습니다.

결함 보고서를 작성하는 일반적인 목표는 문제의 수정 사항을 얻는 것이지만, 정확한 분류, 위험 분석 및 프로세스 개선을 지원하기 위해서는 결함 정보도 제공해야 합니다.

 

6.4 결함 분류

결함 보고서가 수명주기 전반에 걸쳐 나타날 수 있는 여러 수준의 분류가 있습니다. 적절한 결함 분류는 적절한 결함보고의 필수적인 부분입니다. 분류는 결함을 그룹화하고, 테스트의 효과를 평가하고, 개발 라이프 사이클의 유효성을 평가하고, 흥미로운 추세를 결정하는 데 사용됩니다.

새로 식별 된 결함에 대한 공통 분류 정보에는 다음이 포함됩니다:

 

l  결함이 발견 된 프로젝트 활동 - 예 : 검토, 감사, 검사, 코딩, 테스트

l  결함이 도입 된 프로젝트 단계 (알려진 경우) - 예 : 요구 사항, 설계, 상세한 디자인, 코드

l  결함이 발견 된 프로젝트 단계 - 예 : 요구 사항, 설계, 세부 설계,

코드, 코드 검토, 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

l  의심되는 원인 - 예 : 요구 사항, 디자인, 인터페이스, 코드, 데이터

l  반복성 - 예 : 한 번, 간헐적 인, 재현 가능한

l  증상 - 예 : 충돌, 정지, 사용자 인터페이스 오류, 시스템 오류, 성능

 

결함이 조사되면 추가 분류가 가능합니다:

l  근본 원인 - 결함, 예를 들어 프로세스, 코딩 오류, 사용자 오류, 테스트 오류, 구성 문제, 데이터 문제, 타사 소프트웨어, 외부 소프트웨어 문제, 문서 문제와 같은 실수를 한 실수

l  출처 - 요구 사항, 디자인, 세부 디자인, 아키텍처, 데이터베이스 디자인, 사용자 문서, 테스트 문서 등 실수가 발생한 작업 제품

l  유형 - 예 : 논리 문제, 계산 문제, 타이밍 문제, 데이터 처리, 향상

결함이 수정되거나 (지연되었거나 확인에 실패한 경우) 다음과 같은 더 많은 분류 정보를 사용할 수 있습니다:

l  해결책 - 예 : 코드 변경, 문서 변경, 지연, 문제가 아닌 복제

l  시정 조치 - 요구 사항 검토, 코드 검토, 단위 테스트, 구성

문서화, 데이터 준비, 변경 없음

이러한 분류 범주 외에도 결함은 심각도와 우선 순위에 따라 자주 분류됩니다. 또한 프로젝트에 따라 임무 안전 영향, 프로젝트 일정 영향, 프로젝트 비용, 프로젝트 위험 및 프로젝트 품질 영향을 기준으로 분류하는 것이 좋습니다. 이러한 분류는 수정 본이 얼마나 빨리 전달되는지에 대한 합의로 간주 될 수 있습니다.

최종 분류 영역은 최종 해결 방법입니다. 결함은 해상도 (예: 고정 / 확인, 종결 / 문제 없음, 지연, 개방 / 미확인)에 따라 그룹화되는 경우가 많습니다. 이 분류는 일반적으로 결함이 수명주기를 통해 추적되기 때문에 프로젝트 전체에서 사용됩니다.

조직에서 사용하는 분류 값은 종종 사용자 정의됩니다. 위의 내용은 업계에서 사용되는 몇 가지 일반적인 값의 예입니다. 유용하게 사용하려면 분류 값을 일관되게 사용하는 것이 중요합니다. 분류 필드가 너무 많으면 열리고 처리하는 데 다소 시간이 걸릴 수 있으므로 수집되는 데이터의 가치와 처리되는 모든 결함의 증분 비용을 비교하는 것이 중요합니다. 도구로 수집 된 분류 값을 사용자 정의하는 기능은 종종 도구 선택의 중요한 요소입니다.

 

6.5 근본 원인 분석

근본 원인 분석의 목적은 결함의 원인을 판별하고 결함의 상당 부분을 담당하는 근본 원인을 제거하는 프로세스 변경을 지원하는 데이터를 제공하는 것입니다. 근본 원인 분석은 대개 조사하여 문제를 해결하거나 문제를 해결할 수 없거나 수정할 수 없다고 판단한 사람이 수행합니다. 이것은 대개 개발자입니다. 예비 근본 원인 값을 설정하는 것은 일반적으로 문제를 일으킨 원인에 대해 교육 된 추측을하는 테스트 분석가가 일반적으로 수행합니다. 수정 사항을 확인하면 테스트 분석가는 개발자가 입력 한 근본 원인 설정을 확인합니다. 근본 원인이 결정된 시점에서 결함이 도입 된 단계를 결정하거나 확인하는 것도 일반적입니다.

일반적인 근본 원인은 다음과 같습니다:

l  불명확 한 요구 사항

l  누락 된 요구 사항

l  잘못된 요구 사항

l  잘못된 디자인 구현

l  잘못된 인터페이스 구현

l  코드 논리 오류

l  계산 오류

l  하드웨어 오류

l  인터페이스 오류

l  유효하지 않은 데이터

이 근본 원인 정보는 결함 생성의 원인이 되는 공통적 인 문제를 파악하기 위해 집계됩니다. 예를 들어 불명확 한 요구 사항으로 인해 많은 결함이 발생하는 경우 효과적인 요구 사항 검토를 수행하는 데 더 많은 노력을 기울이는 것이 좋습니다. 마찬가지로 인터페이스 구현이 개발 그룹 전반에서 문제가 되는 경우 공동 설계 세션이 필요할 수 있습니다.

프로세스 개선에 근본 원인 정보를 사용하면 조직에서 효과적인 프로세스 변경의 이점을 모니터링하고 특정 근본 원인에 기인 할 수 있는 결함 비용을 계량하는 데 도움이 됩니다. 이렇게 하면 추가 도구 및 장비를 구입해야 하는 프로세스 변경에 대한 자금 지원뿐만 아니라 스케줄 변경시기를 조정하는 데 도움이 될 수 있습니다. ISTQB 전문가 수준 시험 계획 "시험 과정 개선"[ISTQB_EL_ITP]은 근본 원인 분석을 보다 자세히 고려합니다.

7. 테스트 도구 - 45 분.

키워드

키워드 기반 테스트, 테스트 데이터 준비 도구, 테스트 디자인 도구, 테스트 실행 도구

테스트 도구 학습 목표

7.2 시험 도구 및 자동화

TA-7.2.1 (K2) 테스트 데이터 준비 도구, 테스트 디자인 도구 및 테스트 실행 도구를 사용할 때의 이점 설명

TA-7.2.2 (K2) 키워드 중심 자동화에서 테스트 분석가의 역할 설명

TA-7.2.3 (K2) 자동 테스트 실행 실패 문제를 해결하기 위한 단계 설명

7.1 서론

테스트 도구는 테스트 도구의 효율성과 정확성을 크게 향상시킬 수 있지만 적절한 도구가 적절한 방법으로 구현되는 경우에만 가능합니다. 테스트 툴은 잘 실행 된 테스트 조직의 또 다른 측면으로 관리되어야 합니다. 테스트 툴의 정교함과 적용 가능성은 매우 다양하며 툴 시장은 끊임없이 변화하고 있습니다. 도구는 대개 상용 도구 공급 업체뿐만 아니라 다양한 프리웨어 또는 셰어웨어 도구 사이트에서도 사용할 수 있습니다.

 

7.2.1 시험 설계 도구

테스트 설계 도구는 테스트 케이스를 작성하고 테스트에 적용 할 테스트 데이터를 작성하는 데 사용됩니다. 이러한 도구는 특정 요구 사항 문서 형식, 모델 (예: UML) 또는 테스트 분석가가 제공 한 입력에서 작동 할 수 있습니다. 테스트 디자인 도구는 특정 형식 및 특정 요구 사항 관리 도구와 같은 특정 제품에서 작동하도록 설계 및 제작되는 경우가 많습니다.

테스트 디자인 도구는 테스트 범위의 목표 수준, 시스템에 대한 신뢰도 또는 제품 위험 완화 조치를 얻는 데 필요한 테스트 유형을 결정할 때 사용할 테스트 분석가에 대한 정보를 제공 할 수 있습니다. 예를 들어, 분류 트리 도구는 선택된 커버리지 기준에 따라 전체 커버리지에 도달하는 데 필요한 조합 세트를 생성 (및 표시)합니다. 그런 다음이 정보는 테스트 분석가가 실행해야 하는 테스트 사례를 결정하는 데 사용할 수 있습니다.

 

7.2.2 시험 데이터 준비 도구

테스트 데이터 준비 도구는 몇 가지 이점을 제공합니다. 일부 테스트 데이터 준비 도구는 요구 사항 문서 또는 소스 코드와 같은 문서를 분석하여 테스트하는 동안 요구되는 데이터를 결정하여 일정 수준의 적용 범위를 얻을 수 있습니다. 다른 테스트 데이터 준비 도구는 프로덕션 시스템에서 데이터 세트를 가져 와서 해당 데이터의 내부 무결성을 유지하면서 개인 정보를 제거하기 위해 이를 "스크럽 (scrub)"또는 "익명화 (anonymize)"할 수 있습니다. 그런 다음 개인 정보가 유출되거나 보안 누출의 위험이 없이 테스트를 위해 스크럽 된 데이터를 사용할 수 있습니다. 이는 대용량의 실제 데이터가 필요한 경우 특히 중요합니다. 주어진 데이터 입력 세트로부터 (즉, 무작위 테스트에 사용하기 위해) 테스트 데이터를 생성하기 위해 다른 데이터 생성 툴을 사용할 수 있다. 이들 중 일부는 데이터베이스 구조를 분석하여 Test Analyst에서 필요한 입력을 결정합니다.

 

7.2.3 자동화 된 테스트 실행 도구

테스트 실행 도구는 테스트의 모든 수준에서 테스트 분석가가 주로 테스트를 실행하고 테스트 결과를 확인하는 데 사용됩니다. 테스트 실행 도구를 사용하는 목적은 일반적으로 다음 중 하나 이상입니다:

l  (노력 및 / 또는 시간면에서)비용을 줄이려면

l  더 많은 테스트를 실행하려면

l  여러 환경에서 동일한 테스트를 실행하려면

l  테스트 실행을 보다 반복 가능하게 만들기

l  수동으로 실행할 수 없는 테스트를 실행하려면 (즉, 대규모 데이터 유효성 검사)

이러한 목표는 비용을 줄이면서 보상 범위를 늘리는 주요 목표와 겹치는 경우가 많습니다.

7.2.3.1 적용 분야

테스트 실행 도구에 대한 투자 수익 (ROI)은 일반적으로 유지 보수 수준이 낮고 반복적으로 테스트가 실행되므로 회귀 테스트를 자동화 할 때 가장 높습니다. 연기 테스트 자동화는 테스트의 빈번한 사용, 신속한 결과의 필요성 및 유지 보수 비용이 더 높을 수도 있기 때문에 자동화의 효과적인 사용이 될 수 있습니다. 자동화 된 방식으로 새 건물을 평가할 수 있는 능력 지속적인 통합 환경.

테스트 실행 도구는 시스템 및 통합 테스트 단계에서 일반적으로 사용됩니다. 일부 도구, 특히 API 테스트 도구는 구성 요소 테스트 수준에서도 사용될 수 있습니다. 가장 적용 가능한 도구를 활용하면 투자 수익을 개선하는 데 도움이 됩니다.

 

7.2.3.2 시험 자동화 도구 기본 사항

테스트 실행 도구는 스크립팅 언어라고 하는 프로그래밍 언어로 작성된 일련의 명령어를 실행하여 작동합니다. 이 도구에 대한 지침은 입력, 입력 순서, 입력에 사용 된 특정 값 및 예상 출력을 지정하는 매우 상세한 수준에 있습니다. 이로 인해 상세한 스크립트가 SUT (Software Under Test)에서 변경 될 수 있습니다. 특히 도구가 그래픽 사용자 인터페이스 (GUI)와 상호 작용할 때 특히 그렇습니다.

대부분의 테스트 실행 도구는 실제 결과를 저장된 예상 결과와 비교할 수 있는 기능을 제공하는 비교기를 포함합니다.

 

7.2.3.3 시험 자동화 구현

프로그래밍과 마찬가지로 테스트 실행 자동화의 경향은 라이브러리, 매크로 및 하위 프로그램을 사용하여 자세한 저급 지침에서 고급 수준의 언어로 이동하는 것입니다. 키워드 기반 및 액션 단어 주도와 같은 설계 기법은 일련의 지침을 수집하고 특정 "키워드"또는 "조치 단어"를 사용하는 지침을 참조합니다. 이를 통해 테스트 분석가는 기본 프로그래밍 언어와 하위 수준 기능을 무시하면서 테스트 사례를 인간 언어로 작성할 수 있습니다. 이 모듈러 쓰기 기술을 사용하면 테스트중인 소프트웨어의 기능 및 인터페이스가 변경되는 동안 유지 관리가 쉬워집니다. [Bath08] 자동 스크립트에서 키워드 사용에 대해서는 아래에서 자세히 설명합니다.

모델은 키워드 또는 액션 단어의 생성을 안내하는 데 사용할 수 있습니다. 요구 사항 문서에 자주 포함되는 비즈니스 프로세스 모델을 살펴봄으로써 테스트 분석가는 테스트 해야 하는 주요 비즈니스 프로세스를 결정할 수 있습니다. 프로세스 중에 발생할 수 있는 결정 포인트를 포함하여 이러한 프로세스의 단계를 결정할 수 있습니다. 결정 포인트는 테스트 자동화가 키워드 또는 조치 단어 스프레드 시트에서 얻고 사용할 수 있는 조치 단어가 될 수 있습니다. 비즈니스 프로세스 모델링은 비즈니스 프로세스를 문서화하는 방법이며 이러한 주요 프로세스와 의사 결정 지점을 식별하는 데 사용할 수 있습니다. 모델링은 수동으로 수행하거나 비즈니스 규칙 및 프로세스 설명을 기반으로 입력을 처리 할 도구를 사용하여 수행 할 수 있습니다.

 

7.2.3.4 자동화 노력의 성공 향상

자동화 할 테스트를 결정할 때 각 후보 테스트 케이스 또는 후보 테스트 세트를 평가하여 자동화가 필요한지 확인해야 합니다. 많은 실패한 자동화 프로젝트는 자동화의 실제 이점을 확인하지 않고 손쉽게 사용할 수 있는 수동 테스트 사례를 자동화하는 데 기반을 둡니다. 주어진 일련의 테스트 케이스 (스위트)가 수동, 반자동 및 완전 자동 테스트를 포함하는 것이 최적 일 수 있습니다.

테스트 실행 자동화 프로젝트를 구현할 때 다음 측면을 고려해야 합니다:

가능한 이점:

l  자동화 된 테스트 실행 시간이 더 예측 가능해질 것입니다.

l  자동화 된 테스트를 사용한 회귀 테스트 및 결함 검증은 프로젝트 후반부에보다 빠르고 신뢰할 수 있습니다.

l  테스터 또는 테스트 팀의 상태 및 기술적 성장은 자동화 된 도구를 사용하여 향상 될 수 있습니다.

l  자동화는 반복 또는 증분 개발 라이프 사이클에서 각 빌드 또는 반복에 대해보다 우수한 회귀 테스트를 제공하는 데 특히 유용 할 수 있습니다.

l  특정 테스트 유형의 적용 범위는 자동화 된 도구 (예 : 대규모 데이터 유효성 검사 노력)를 통해서만 가능합니다.

l  테스트 실행 자동화는 신속하고 일관된 입력 및 검증을 제공함으로써 대용량 데이터 입력, 변환 및 비교 테스트 작업을 위해 수동 테스트보다 비용 효율적일 수 있습니다.

 

가능한 위험 :

l  불완전하고 비효율적이거나 잘못된 수동 테스트는 "있는 그대로"자동화 될 수 있습니다.

l  테스트웨어는 유지 보수가 어려우므로 테스트중인 소프트웨어가 변경 될 때 여러 번 변경해야 합니다.

l  테스트 실행에 직접적인 테스터 참여가 줄어들어 결함 감지가 줄어들 수 있습니다.

l  테스트 팀은 자동 도구를 효과적으로 사용할 수 있는 기술이 충분하지 않을 수 있습니다.

l  전체 테스트 커버리지에 기여하지 않는 관련 없는 테스트는 존재하고 안정적이기 때문에 자동화 될 수 있습니다.

l  소프트웨어가 안정화되면 테스트가 비생산적이 될 수 있습니다 (살충제 역설)

 

테스트 실행 자동화 도구를 배포하는 동안 수동 테스트 사례를 그대로 자동화하는 것은 좋지 않지만 더 나은 자동화 사용을 위해 테스트 사례를 재정의하는 것은 항상 바람직하지 않습니다. 여기에는 테스트 사례 서식 지정, 재사용 패턴 고려, 하드 코딩 된 값 대신 변수를 사용하여 입력 확장, 테스트 도구의 모든 이점 활용 등이 포함됩니다. 테스트 실행 도구는 대개 여러 테스트, 그룹 테스트, 반복 테스트 및 실행 순서 변경을 모두 통과하면서 분석 및 보고 기능을 제공합니다.

많은 테스트 실행 자동화 도구에서 효율적이고 효과적인 테스트 (스크립트) 및 테스트 스위트를 작성하려면 프로그래밍 기술이 필요합니다. 신중하게 설계하지 않으면 대형 자동화 테스트 스위트를 업데이트하고 관리하기가 일반적으로 어렵습니다. 테스트 도구, 프로그래밍 및 디자인 기법에 대한 적절한 교육은 도구의 모든 이점을 활용하는 데 중요합니다.

테스트 계획 중에는 테스트 작동 방식에 대한 지식을 유지하고 올바른 작동을 확인하고 입력 데이터의 유효성 및 적용 범위를 검토하기 위해 수동으로 자동화 된 테스트 사례를 주기적으로 실행하는 데 시간을 허용해야 합니다.

 

7.2.3.5 키워드 중심 자동화

키워드 (액션 단어라고도 함)는 대부분 시스템과의 고급 비즈니스 상호 작용 (예 : '주문 취소')을 나타내기 위해 사용되지만 배타적이지 않습니다. 각 키워드는 일반적으로 액터와 테스트중인 시스템 간의 상세한 상호 작용을 나타내기 위해 사용됩니다. 키워드의 순서 (관련 테스트 데이터 포함)는 테스트 사례를 지정하는 데 사용됩니다. [Buwalda01]

테스트 자동화에서 키워드는 하나 이상의 실행 가능한 테스트 스크립트로 구현됩니다. 도구는 키워드 기능을 구현하는 적절한 테스트 스크립트를 호출하는 일련의 키워드로 작성된 테스트 사례를 읽습니다. 스크립트는 특정 키워드에 쉽게 매핑 할 수 있도록 모듈 방식으로 구현됩니다. 이러한 모듈러 스크립트를 구현하려면 프로그래밍 기술이 필요합니다.

키워드 기반 테스트 자동화의 주요 이점은 다음과 같습니다:

l  특정 애플리케이션 또는 비즈니스 도메인과 관련된 키워드는 도메인 전문가가 정의 할 수 있습니다. 이는 테스트 케이스 스펙의 태스크를보다 효율적으로 만들 수 있습니다.

l  주로 도메인 전문 지식을 가진 사람은 기본 자동화 코드를 이해하지 않고도 자동 테스트 사례 실행 (키워드가 스크립트로 구현 된 후)에서 이점을 얻을 수 있습니다.

l  키워드를 사용하여 작성된 테스트 케이스는 테스트중인 소프트웨어의 세부 사항이 변경되는 경우 수정이 필요하지 않으므로 유지 관리가 더 쉽습니다.

l  테스트 케이스 스펙은 구현과 독립적입니다. 키워드는 다양한 스크립팅 언어 및 도구를 사용하여 구현할 수 있습니다.

 

키워드 / 액션 단어 정보를 사용하는 자동화 스크립트 (실제 자동화 코드)는 일반적으로 개발자 또는 기술 테스트 분석가가 작성하지만 테스트 분석가는 일반적으로 키워드 / 액션 단어 데이터를 작성 및 유지 관리합니다. 일반적으로 키워드 기반 자동화는 시스템 테스트 단계에서 실행되지만 코드 개발은 통합 단계만큼 일찍 시작될 수 있습니다. 반복적 인 환경에서 테스트 자동화 개발은 지속적인 프로세스입니다.

일단 입력 키워드와 데이터가 생성되면 테스트 분석가는 대개 키워드 중심 테스트 케이스를 실행하고 발생할 수 있는 모든 실패를 분석 할 책임이 있습니다. 이상이 감지되면 테스트 분석가는 실패 원인을 조사하여 문제가 키워드, 입력 데이터, 자동화 스크립트 자체 또는 테스트중인 응용 프로그램과 관련이 있는지 확인해야 합니다. 일반적으로 문제 해결의 첫 번째 단계는 동일한 데이터를 수동으로 동일한 테스트를 실행하여 해당 오류가 응용 프로그램 자체에 있는지 확인하는 것입니다. 이것이 실패를 나타내지 않는다면, 시험 분석가는 이전 단계에서 문제가 발생했는지 (아마도 부정확 한 데이터를 생성함으로써) 발생했는지를 결정하지 못한 경우까지의 일련의 시험을 검토해야 하지만, 문제는 이후에 나타날 것입니다 처리. 테스트 분석가가 실패의 원인을 파악할 수 없는 경우 문제 분석 정보를 기술 분석 분석가 또는 개발자에게 넘겨서 분석을 진행해야 합니다.

 

7.2.3.6 자동화 노력의 실패 원인

테스트 실행 자동화 프로젝트는 종종 목표를 달성하지 못합니다. 이러한 실패는 테스트 도구 사용의 불충분 한 유연성, 테스트 팀의 프로그래밍 기술 부족 또는 테스트 실행 자동화로 해결할 수 있는 문제에 대한 비현실적인 기대 때문일 수 있습니다. 모든 테스트 실행 자동화는 모든 소프트웨어 개발 프로젝트와 마찬가지로 관리, 노력, 기술 및 관심을 필요로 한다는 점에 유의해야 합니다. 적절한 설계 방법을 따르고 구성 관리를 제공하며 훌륭한 코딩 방법을 따르는 지속 가능한 아키텍처를 만드는 데 시간을 투자해야 합니다. 자동 테스트 스크립트는 결함이 있을 가능성이 있기 때문에 테스트 해야 합니다. 성능을 위해 스크립트를 조정해야 할 수도 있습니다. 개발자뿐만 아니라 도구를 사용하여 스크립트를 실행하는 사람들을 위해 도구 유용성을 고려해야 합니다. 테스터를 위해 논리적으로 구성되지만 도구에 필요한 접근성을 제공하는 방식으로 테스트 케이스에 대한 액세스를 제공하는 도구와 사용자 간의 인터페이스를 설계해야 할 수도 있습니다.

8. 참고 문헌

8.1 표준

[ISO25000] ISO / IEC 25000 : 2005, 소프트웨어 엔지니어링 - 소프트웨어 제품 품질

요구 사항 및 평가 (SQuaRE)

1 장과 4 장

[ISO9126] ISO / IEC 9126-1 : 2001, 소프트웨어 엔지니어링 - 소프트웨어 제품 품질,

1 장과 4 장

[RTCA DO-178B / ED-12B] : 공수 시스템 및 장비의 소프트웨어 고려 사항

인증, RTCA / EUROCAE ED12B.1992.

1 장

8.2 ISTQB 문서

[ISTQB_AL_OVIEW] ISTQB 고급 수준 개요, 버전 1.0

[ISTQB_ALTM_SYL] ISTQB 고급 레벨 테스트 관리자 강의 계획서, 버전 1.0

[ISTQB_ALTTA_SYL] ISTQB 고급 수준의 기술 테스트 분석가, 실러버스, 버전 1.0

[ISTQB_FL_SYL]

ISTQB Foundation 레벨 강의 계획서, 버전 2011

[ISTQB_GLOSSARY] 소프트웨어 테스팅 2.2 버전에서 사용되는 용어의 표준 용어집.

2012 년

8.3 책

[Bath08] Graham Bath, Judy McKay, "Software Test Engineer 's Handbook", Rocky Nook, 2008,

ISBN 978-1-933952-24-6

[Beizer95] Boris Beizer, "블랙 박스 테스팅", John Wiley & Sons, 1995, ISBN 0-471-12094-4

[Black02] : Rex Black, "테스트 프로세스 관리 (제 2 판)", John Wiley & Sons : New York,

2002, ISBN 0-471-22398-0

[Black07] : Rex Black, "Pragmatic Software Testing", John Wiley and Sons, 2007,

ISBN 978-0-470-12790-2

[Buwalda01] : Hans Buwalda, "통합 테스트 설계 및 자동화", Addison-Wesley Longman,

2001 년, ISBN 0-201-73725-6

[Cohn04] : Mike Cohn, "사용자 스토리 적용 : 민첩한 소프트웨어 개발", Addison-Wesley

Professional, 2004, ISBN 0-321-20568-5

[Copeland03] : Lee Copeland, "소프트웨어 테스트 디자인 실무자 가이드", Artech House, 2003,

ISBN 1-58053-791-X

[Craig02] : Rick David Craig, Stefan P. Jaskiel, "Systematic Software Testing", Artech House, 2002,

ISBN 1-580-53508-9

[Gerrard02] : Paul Gerrard, Neil Thompson, "위험 기반 전자 상거래 테스트", Artech House, 2002,

ISBN 1-580-53314-0

[Gilb93] : Tom Gilb, Graham Dorothy, "Software Inspection", Addison-Wesley, 1993,

ISBN 0-201-63181-4

[Graham07] : 도로시 그레이엄, 에릭 반 비넨 달, 이사벨 에반스, 렉스 블랙 "

소프트웨어 테스팅 ", Thomson Learning, 2007, ISBN 978-1-84480-355-2

[Grochmann94] : M. Grochmann (1994), Classification Trees를 사용한 테스트 케이스 디자인, in : conference

절차 STAR 1994

[Koomen06] : Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon "TMap NEXT, 결과

구동 테스트 ", UTN Publishers, 2006, ISBN 90-72194-80-2

[Myers79] : Glenford J. Myers, "소프트웨어 테스팅의 기술", John Wiley & Sons, 1979,

ISBN 0-471-46912-2

[Splaine01] : Steven Splaine, Stefan P. Jaskiel, "웹 테스트 핸드북", STQE Publishing, 2001,

ISBN 0-970-43630-0

[vanVeenendaal12] : Erik van Veenendaal, "실용적 위험 기반 테스트 - PRISMA 접근법", UTN

발행인, 네덜란드, ISBN 9789490986070

[Wiegers03] : Karl Wiegers, "Software Requirements 2", Microsoft Press, 2003, ISBN 0-735-61879-8

[Whittaker03] : James Whittaker, "소프트웨어를 깨는 방법", Addison-Wesley, 2003,

ISBN 0-201-79619-8

[Whittaker09] : James Whittaker, "Exploratory Software Testing", Addison-Wesley, 2009, ISBN 0-321-

63641-4

8.4 기타 참고 문헌

다음 참조 자료는 인터넷 및 기타 지역에서 사용할 수있는 정보를 가리 킵니다. 비록

이러한 참고 자료는이 고급 레벨 강의 발표 당시에 확인되었으며, ISTQB

참조가 더 이상 유효하지 않으면 책임을지지 않습니다.

3 장

- Czerwonka, Jacek : www.pairwise.org

- 버그 분류 : www.testingeducation.org/a/bsct2.pdf

Boris Beizer의 작업에 기반한 샘플 버그 분류법 : inet.uni2.dk/~vinter/bugtaxst.doc

- 다양한 택 소노 미의 개요 : testingeducation.org/a/bugtax.pdf

- James Bach의 발견 적 위험 기반 테스팅

- "Exploratory & Risk-Based Testing (2004) www.testingeducation.org "에서

- Exploratory Testing, Cem Kaner 및 Andy Tikam, 2003 조사

- Pettichord, Bret, "Exploratory Testing Workshop Report",

www.testingcraft.com/exploratorypettichord

제 4 장

- www.testingstandards.co.uk