CSTS 공부 오답노트

 

항상 공부할 때마다 새롭다. 

 

<1. 소프트웨어 테스팅의 기초> 

오류-부재의 궤변(Absence-oferrors fallacy)

: 요구사항과 일치하고 사용에 적합해야 한다. 

 

◆다음 중 장애(Failur)에 대한 용어설명으로 올바른 것은?

(1) 결함 또는 환경적 조건에 의한 시스템의 부적절한 처리

(2) 오류 또는 실수의 결과

(3) 코드, 소프트웨어, 시스템, 문서 상의 결함

(4) 인간에 의해 만들어진 실수 

=> 결함에 대한 설명 및 용어 정리 

오류(Error) : 잘못 된 결과를 낳는 인간의 행위(Action), 실수(Mistake)와 동의어

결함(Defects, Bug, Fault) : 일반적으로 버그(Bug), 결함(Defect), 결점(Fault)은 동의어로 사용될 수 있으며 요구된 기능을 적절히 처리하지 못하는 것, 즉, 장애(Failur)를 발생 시키는 것

장애(Failur) : 코드에 존재하는 결함의 실행 

그래서 답은 (1)이다.  

 

◆'완벽한 테스팅은 불가능하다'를 설명하는 이유로 적절치 않은 것은?

(1) 프로그램에는 너무 많은 실행 경로가 있어서 모두 테스트할 수 없다.

(2) 가능한 입력값 조합이 너무 많아서 모두 테스트할 수 없다.

(3) 재정적 자원의 한계로 모두 테스트할 수 없다.

(4) 사용자 인터페이스 GUI가 너무 복잡하고 GUI 이벤트 발생 순서에 대한 조합이 많아 완벽하게 테스트 할 수 없다. 

=> 완벽한 테스팅이 불가능한 이유를 무한경로, 무한 입력값, 무한 타이밍으로 설명한다. 

(1) 무한경로, (2) 무한입력, (4) 무한 타이밍과 관련이 있다. 

재정적 자원의 한계가 '완벽한 테스팅은 불가능하다'를 설명하는 이유로 적절치 못하다. 

 

◆ 테스트 분석과 설계는 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황(Condition)과 설계로 변환하는 활동이다. 다음 중 테스트 분석과 설계의 주요 작업 중 테스트 베이시스 리뷰 대상에 해당하지 않는 것은 무엇인가? 

(1) 요구사항 분석서

(2) 개발 설계 문서

(3) 아키텍쳐

(4) 테스트 하네스(Test harness)

=> 테스트 분석과 설계 단계에서 리뷰 대상인 테스트 베이시스(Test basis)는 다음과 같다.

- 요구사항 분석서(Requirement specification)

- 아키텍쳐(소프트웨어 구조)

- 개발 설계 문서 

- 인터페이스

=> 테스트 하네스(Test harness)는 테스트 대상이 실행되는 환경을 시뮬레이션함으로써 컴포넌트나 시스템 일부에 대한 테스팅을 가능하게 한다. 이것은 테스팅 환경의 어떤 컴포넌트가 아직 준비돼 있지 않고 스텁(Stub)이나 드라이버(Driver)로 대체된 상태일 때 사용된다. 또한 결함이 테스트 대상 내에서만 국한되도록 예측 및 제어 가능한 테스트 환경을 제공하는 단순한 목적을 위해서 사용된다. 

 

◆ 테스트 프로세스의 주된 활동 중 '테스트 분석과 설계' 단계에서 수행하는 작업이 아닌 것은 무엇인가?

(1) 테스트 조건 또는 요구사항, 테스트 항목, 명세, 동작과 구조 분석을 기초로 필요한 테스트 데이터를 정의한다.

(2) 요구사항의 테스트 용이성(Testability)을 평가한다. 

(3) 테스트 환경을 설정하고 테스트에 필요한 기반 환경과 도구를 정의한다.

(4) 효과적인 테스트 실행을 위해 테스트케이스로부터 테스트 스위트(Test suite)를 작성한다. 

=> TC 만든것을 활용하여 묶음을 정의하는 테스트 스위트를 작성하는것은 '테스트 구현과 실행'단계에서 수행한다.

 

◆ 다음 중 가장 상위 수준(High level)의 산출물은 무엇인가?

(1) 프로젝트 테스트 계획(Project test plan)

(2) 테스트 정책(Test policy)

(3) 레벨 테스트 계획(Level test plan)

(4) 프로젝트 테스트 상태 보고서(Project test status report) 

=> 테스트 정책(Test plicy)는 테스팅을 위한 관리 방침을 명확히 하는 최상위 수준의 문서이다. 조직 내의 모든 테스트 활동에 적용할 수 있도록 조직차원에서 정의한다. 

- 테스트 프로젝트 차원 : 프로젝트 테스트 계획, 프로젝트 테스트 상태 보고서

- 테스트 레벨 차원 : 레벨 테스트 계획 

 

<2. 소프트웨어 수명주기와 테스팅>

verification : 무언가 만드는 '과정'을 잘 지켰는지를 말한다.

validation : 최종적으로 만든 '결과물'이 잘 나왔는지를 말한다. 

 

◆ 소프트웨어 개발에서 베리피케이션(Verification) 프로세스는 무엇을 의미하는가?

(1) 작업 산출물에 있는 가능한 모든 결함이나 약점을 찾으려고 노력하는 프로세스

(2) 소프트웨어를 모니터링하는 프로세스로, 표준과 절차를 완벽히 지키는지 확인

(3) 시스템이나 컴포넌트를 평가하는 프로세스로, 주어진 개발 단계의 제품이 그 단계에서 처음에 정의한대로 조건을 만족하는지 결정

(4) 시스템이나 컴포넌트를 평가하는 프로세스로, 판매 중 또는 판매 종료 시점에 사용자가 실제로 원하는 요구사항을 만족하는지 평가 

=> 베리피케이션(Verification)은 ISO 9000에서는 '명세된 요구사항이 충족됐는지를 조사에 의해서나 객관적인 증거 제공으로 확인하는 것'으로 정의한다.

따라서 소프트웨어 개발에서 말하는 베리피케이션은 주어진 개발 단계의 제품이 그 단계에서 정의한 대로 조건을 만족하는지 시스템이나 컴포넌트를 평가하는 프로세스다. 

 

◆ 개발 수명주기 초기에 베리피케이션(Verification) 활동의 주요 이점은 무엇인가?

(1) 사용자 요구사항의 변화를 식별할 수 있다.

(2) 결함을 예방한다.

(3) 테스트 환경 준비를 시의 적절하게 하도록 돕는다. 

(4) 테스터가 프로젝트 초기에 참가하도록 한다.

=> 수명주기 초기에 발생하는 중간산출물에 대해 베리피케이션을 실시하여 처음에 정의한대로 조건을 만족하는 컴포넌트나 시스템이 구현됐는지를 사전에 일부 검토가 가능하며, 이런 활동들은 차후에 발생하는 결함을 예방한다. 

 

◆ 다음 중 반복적(Iterative) 개발 모델에 대한 예를 모두 고른 것은?

i) V-모델 

ii) 민첩(Agile) 개발 모델

iii) 폭포수(Waterfall) 모델

iv) 래피드 애플리케이션 개발(RAD, Rapid Application Development) (이건 뭐여?)

v) 래셔널 통합 프로세스(RUP, Rational Unified Process) (이건 뭐여?)

(1) i, ii

(2) ii, iii, iv

(3) ii, iv

(4) ii, iv, v 

=> 반복적 개발 모델의 예는 다음과 같다.

- Agile, RUP, RAD, 프로토타이핑 

 

◆ 테스트 전문가인 이 수석은 8단계의 반복적(Iterative) 개발 모델을 따르는 웹 프로젝트의 PM으로부터 도움을 요청 받았다. 프로젝트는 현재 1단계가 진행 중이며 약 1주 후 본격적인 코딩에 들어갈 예정이다. 대다수의 웹 프로그래머ㅓ가 대형 프로젝트의 경험이 부족한 상황이며 새로 도입되는 신기술에도 익숙하지 않다. 이런 상황에서 이 수석이 제공할 수 있는 가장 적절한 조언은 무엇인가?

(1) 각 단계마다 고객의 요청사항이 프로그램에 제대로 반영됐는지를 테스트 

(2) 각 단계마다 이전 부분에 대한 수정사항이 발생되므로 이에 대한 결함 방지를 위해 리그레이션 테스트(Regression Test)를 강화한다. 

(3) 신기술에 대한 교육을 권장하고, 각 단계마다 동료 개발자에 의한 베리피케이션(Verification)과 밸리데이션(Validation)을 실시하도록 한다.

(4) 테스트 자동화 도구를 도입해 개발자가 코드를 직접 테스트 할 수 있는 환경을 구축하고 지속적으로 해당 도구를 사용해 테스팅한다.

=> 반복적이고 점증적으로 개발하는 환경에서 단위 테스트 프레임워크 도구를 이용해 개발자가 테스트 주도 개발을 하는 것이 매우 중요하다. 가장 최선의 답을 고른다면 (4)이다.

 

◆ V-모델은 요구사항이 변경됐을 경우에 빠르게 반영하기는 어렵다. 
요구사항이 변경됐을 경우에 빠르게 반영하는 모델은 반복/점증 모델(Iterative and incremental model)이다. 

◆ 소프트웨어 개발 수명주기(SDLC, Software Development Life Cycle)와 관련된 테스팅의 설명으로 잘못된 것은 무엇인가?

(1) 시스템 테스팅은 블랙박스 테스팅 위주로 수행되며 기능 및 비기능적 요구사항을 모두 포함한다.

(2) 인수 테스팅은 백업, 유지보수, 보안 취약성을 포함하고, 알파 및 베타 테스트를 수행한다.

(3) 컴포넌트 테스팅은 소프트웨어 각 단위 모듈간의 연계성을 고려해 테스트한다.

(4) 리뷰(Review)는 개발 단계의 산출물 위주로 검증을 수행하는 것이며 인스펙션, 워크쓰루 등이 그 구체적인 방법(기법)이다. 

=> 컴포넌트 테스팅(Component testing)은 소프트웨어 단위 모듈 자체만을 테스팅하는 것이다. 모듈간 연계성을 고려해 테스트하는 것은 통합 테스팅(Integration testing)이다. 

 

◆ 시스템 테스팅은 기능 및 비기능적 시스템의 요구 사항을 모두 포함한다. 단위 및 통합 테스트가 완료돼 기능상 문제가 없는 상태에서 수행할 수 있으며, 테스트 환경은 가능하면 실제 사용 환경과 유사해야 한다. 

 

◆ 다음 보기 중 시스템 테스팅(System testing)의 테스트 베이시스(Test basis)로 적절치 않은 것은 무엇인가?

(1) 리스크 분석서

(2) 비즈니스 프로세스

(3) 프로그램 상세 설명서

(4) 유즈케이스 

=> 보기 (3)은 단위 테스팅의 테스트 베이시스(Test basis)로 적절하다.

=> 시스템 테스팅 수행에 근간이 되는 것은 아래와 같은 상위 레벨 테스트 베이시스(개발 중간 산출물등) 이다. 

- 리스크 분석서

- 요구사항 명세

- 비즈니스 프로세스

- 유즈케이스

- 기타 비즈니스 레벨의 시스템 동작 명세

- OS 및 시스템 리소스와 상호작용 명세 

 

◆ 다음 중 인수 테스팅(Acceptance testing)에 대한 설명으로 올바르지 않은 것은 무엇인가?

(1) 인수 테스팅은 제품 출시 전에 수행하는 최종 단계의 테스팅이다.

(2) 인수 테스팅의 목적은 시스템이나 시스템의 일부에 대한 비기능적인 특성에 대해 '확신(Confidence)'을 얻는 것이다.

(3) 알파 테스팅은 조직 내에서 잠재적인 고객에 의해 수행되고, 베타(필드) 테스팅은 실제 업무 현장에 있는 인원에 의해서 수행된다. 

(4) 공장 인수 테스팅(Factory acceptance testing)은 알파 테스팅과 같은 의미이고, 사이트 인수 테스팅(Site acceptance testing)은 베타 테스팅과 같은 용어이다. 

=> 인수 테스팅이 반드시 최종 단계의 테스팅이라고 보기는 어렵다. 예를 들어 대규모 인수 테스트 이후에 시스템 통합 테스트를 실행할 수 있다. 또한 외부 컴포넌트의 인수 테스팅을 컴포넌트 테스트 레벨에서 수행할 수 있다. 

 

◆ 다음 중 유지보수 테스팅(Maintenance testing)을 수행하는 경우가 아닌 것은?

(1) 통합 테스트(Integration test) 결과 코드에 결함이 발견돼 수정했다.

(2) OS의 새로 드러난 취약점을 패치(patch)했다.

(3) 시스템을 다른 플랫폼으로 마이그레이션했다.

(4) 소프트웨어가 최신 버전으로 업데이트됐다. 

=> 유지보수 테스팅(Maintenance testing)은 소프트웨어 시스템이 배포된 후에 수행한다.

개발중에 변경이 발생한 경우 확인 테스팅(Confirmation testing) 또는 리그레션 테스팅(Regression testing) 등을 수행한다.

=> 유지보수 테스팅은 이미 운영되고 있는 시스템에서 수행하며 소프트웨어나 시스템이 변경, 단종됐거나 마이그레이션될 때 발생한다. 

 

◆ 다음 중 유지보수 테스팅(Maintenance testing)을 진행하는 경우는?

(1) 기존에 운영되던 시스템을 변경할 때 수행

(2) 개발 단계에서 결함을 수정할 때 수행

(3) 모든 테스트 레벨에서 수행

(4) 컴포넌트 간의 인터페이스와 연동 관련 결함 확인 시 수행

=> 유지보수 테스팅은 시스템 또는 소프트웨어가 운영 중 변경이 발생하면 수행하는 테스팅이다. 유지보수 테스팅은 유지보수성 테스팅(Maintainability testing)과 혼동하기 쉬우니 유의하기 바란다. 유지보수성 테스팅은 시스템 및 소프트웨어가 변경을 고려해 얼마나 잘 개발했는지 밝히는 테스팅이다. 

일반적으로 유지보수성이 낮은 시스템은 작은 변경에도 취약해 이를 반영하려면 코드의 많은 부분을 수정하는 등 많은 재작업과 리소스를 투입해야 한다. (1)이 답임. 

 

◆ 최근 A 증권사의 프로젝트 개발이 거의 막바지에 다다랐다. 프로젝트 성공을 위해 프로젝트 매니저, 테스트 매니저, 품질 보증 담당자, 현업 사용자 대표가 참여하는 PMO를 구성했다. 프로젝트 개발이 끝나면 개발한 시스템을 증권사의 운영 조직으로 이관해 다른 시스템과 통합할 예정이다. 이 운영 조직에서 시스템의 유지보수도 같이 담당할 예정이다. 

다음 중 운영 조직에서 시스템 이관 시 수행할 테스트 활동으로 맞는 것은?

(i) 단위 테스트

(ii) 통합 테스트

(iii) 인수 테스트

(iv) 시스템 통합 테스트

(1) i, ii

(2) ii, iii

(3) iii, iv

(4) i, iii, iv
=> 개발한 시스템을 다른 시스템과 통합하기 때문에 시스템 통합 테스팅이 필요하다. 시스템 통합 테스팅은 테스트 대상 제품이 이미 운영 중인(상호작용할) 시스템과 인터페이스나 시스템 테스팅 또는 인수 테스팅이 끝난 시스템 간의 인터페이스에 최대한 문제를 많이 일으켜 정상 동작하지 않음을 밝히려는 상위 레벨의 통합 테스팅이다. 

운영조직에서 해당 시스템을 인수해 유지보수를 책임질 예정이므로 인수 테스팅도 수행한다. 유지보수와 관련한 인수테스팅은 '운영상의 인수 테스팅'으로 구분된다. 

 

<3 정적 기법>

◆ 리뷰를 통해서 발견하기 용이한 결함의 종류는 다음과 같다.

- 표준 위반

- 요구사항 결함

- 개발 설계(디자인) 결함

- 불충분한 유지보수성(Insufficient maintainability)

- 부정확한 인터페이스 명세 

 

◆ 다음 중 정적 기법의 효과로 올바르지 않은 것은 무엇인가?

(1) 개발 프로세스의 생산성이 향상된다.

(2) 테스팅 인력이 부족할 때 유용하다.

(3) 정적 기법을 통해 결함 예방이 가능하다.

(4) 구성원간 커뮤니케이션이 향상된다. 

=> 정적 기법은 잘 활용하면 개발 기간 단축 및 테스팅 비용을 감소시켜 주지만 테스팅 인력이 부족할 때 사용하는 기법은 아니다. 리소스가 제한적일 경우에는 경험 기반 기법 및 탐색적 테스팅 등을 활용하는 것이 좋다.

 

◆ 다음 중 공식 리뷰에서 리뷰 미팅 참여자에 대한 설명 중 맞는 것은?
(i) 저자(Author)

(ii) 기록자(Scriber or Recorder)

(iii) 중재자(Moderator)

(iv) 관리자(Manager)

(1) i, ii, iii, iv 모두 리뷰에 참여

(2) i, ii, iii 리뷰에 참여, iv 참여하지 않음

(3) ii, iii 리뷰에 참여, i, iv 참여하지 않음

(4) i, iv 리뷰에 참여, ii, iii 참여하지 않음

=> 관리자도 공식 리뷰에 참여하기는 하지만, 리뷰 미팅에는 참여하지 않는다.

=> 기록자 : 리뷰 미팅에서 발견된 이슈, 미해결점 등을 기록하고 문서화한다.

중재자 : 리뷰를 계획하고 미팅을 진행하고 후속조치 처리 여부 등을 추적하고 관리한다. 리뷰 중재자는 리뷰 중재자 교육을 받는다.

관리자 : 리뷰의 실행여부를 결정하고 프로젝트 일정에 리뷰 시간을 할당하고 리뷰의 목적 달성 여부를 확인하고 승인한다.

저자 : 리뷰 대상 문서(산출물)의 작성자 또는 책임자이다. 

검토자 : 해당 분야의 기술적 또는 비즈니스적 배경을 갖춘 사람으로, 필요한 준비를 거쳐 리뷰 대상에서 인시던트를 발견하고 발견한 인시던트를 리뷰 미팅에서 공유하는 사람이다. 

 

◆ 기술적 리뷰 

이상적으로는 중재자가 미팅을 주도한다.

설계 및 소스코드를 리뷰 하는데 적합하다. 

하위레벨 테스트에 집중하지는 않는다. (하위레벨 테스트는 단위테스팅, 통합테스팅을 의미한다) 

 

◆ 리뷰 기법 중의 하나인 워크쓰루(Walkthrough)가 정적 분석(Static analysis)이나 동적 테스팅(Dynamic testing)에 비해 갖는 강점을 적절히 설명한 것은? 

(1) 워크쓰루는 정적 분석에 비해 개발 대상 소프트웨어를 사용자가 요구한 대로 개발했는지 밸리데이션(Validation)하는데 유용하다. 또한 동적 테스팅에 비해서 개발 초기에 결함을 제거해 결함 예방 효과가 있다.

(2) 워크쓰루는 동적 테스팅에 비해 명세대로 개발했는지 베리피케이션(Verification)하는데 유용하고, 정적 분석에 비해 개발 초기에 결함을 제거해 결함 예방 효과를 볼 수 있다.

(3) 워크쓰루는 정적 분석과 달리 밸리데이션과 베리피케이션에서 적절하게 사용할 수 있는 반면에 정적 분석보다 결함을 예방하는 효과는 낮다.

(4) 워크쓰루는 정적 분석에 비해 결함 예방 효과가 낮고 동적 테스팅에 비해서는 결함 예방 효과가 높다. 

=> 워크쓰루는 저자가 주도해 특별한 형식없이 발표 또는 회의 형태로 저자가 작성한 내용을 검토하며 진행하는 방식으로 기술을 잘 모르는 사용자도 익숙한 방식이다. 그래서 사용자가 실제 원하는 것을 밸리데이션(Validation)하고 검토하는 목적으로 사용될 수 있다. 

반면 정적 분석은 일반적으로 자동화 도구를 사용해 코딩 규칙에 맞는지 또는 코드의 시맨틱에 문제가 없는지 확인하는 기법으로 사용자의 실제 요구보다는 작성된 코드의 문제 여부를 베리피케이션(Verification)한다.
그리고 일반적으로 리뷰가 정적 분석보다 개발 초기에 진행되므로 결함 예방 효과가 높다. 

 

<4 테스트 설계 기법> => 정리 (myinbox.tistory.com/66)

◆ 테스트 컨디션

=> 테스트할 대상의 기능, 품질속성, 트랜잭션 등 테스트 설계에 필요한 대상 또는 조건을 의미한다. 

◆ 테스트 하네스 

=> 실행 환경

◆ 테스트 드라이버

=> 상향식

◆ 테스트 스텁

=> 하향식 

◆ 품질 특성

=> 사기신이유효 

◆ 블랙박스 기법

=> 경동유결상(경계값 분석 기법, 동등 분할 기법, 유즈케이스 테스팅 기법, 결정 테이블 테스팅 기법, 상태전이 테스팅 기법)

◆ 화이트박스 기업

=> 결제구(결정 테스팅 기법, 제어 흐름 테스팅 기법, 구문 테스팅 기법) 

◆ 상태 전이 다이어그램의 올바른 절차 

=> 상전유비(가)테

◆ 커버리지 포함관계

=> 구문 커버리지 < 조건/결정 커버리지 < 변경 조건/결정 커버리지 < 다중 조건 커버리지 < 경로 커버리지

=> S < CD < MC/DC < MCC < APC 

 

◆ 다음 중 테스팅 프로세스에 대한 설명 중 옳지 않은 것을 고른 것은?

(i) 테스팅 프로세스를 따르는지 여부는 테스팅 프로세스에서 작성되는 문서로 확인할 수 있다.

(ii) 테스팅 프로세스의 성숙도를 진단하고 심사하기 위해 베스트 프랙티스(Best-practice) 기반의 테스트 심사 모델을 활용할 수 있다. 

(iii) 국제 표준에서 테스팅 프로세스를 개발 프로세스와 별도로 정의하고 있다.

(iv) 테스트 정책 수립 프로세스와 같이 테스팅 프로세스는 조직차원에서도 존재한다.

(v) 테스트 전략은 각 테스트 레벨(Test level)에서만 수립된다.

(vi) 프로젝트 차원의 테스팅 프로세스는 테스트 계획 및 제어, 분석 및 설계, 환경 셋업, 실행, 결함 리포팅, 테스트 리포팅 및 마감을 의미한다. 

(1) ii, iii

(2) iv, v, vi

(3) i, iii, v

(4) v, vi

=> 테스트 전략은 각 테스트 레벨 뿐만 아니라 프로젝트 차원(마스터 테스트 계획)에서도 수립된다. 프로젝트 차원의 테스팅 프로세스는 크게 프로젝트 테스트 계획 작성 및 업데이트, 테스트 레벨 감시 및 제어, 테스트 프로젝트 종료 보고로 구성돼 있다. 

 

◆ 다음 보기 중 테스트 하네스(Test harness)에 대한 설명으로 올바른 것은 무엇인가?

(1) 테스트 드라이버(Driver)와 같은 용어이다.

(2) 테스트 대상이 실행되는 환경을 시뮬레이션한다.

(3) 하향식(Top-down) 통합 테스트 접근에서 사용된다.

(4) 테스트 중 모듈에 의해 호출되는 기능(Functions)이다.

=> 테스트 하네스 : 테스트 대상이 실행되는 환경을 시뮬레이션함으로써 컴포넌트나 시스템 일부에 대한 테스팅을 가능하게 한다. 이것은 테스팅 환경의 어떤 컴포넌트가 아직 준비가 돼있지 않고 스텁이나 드라이버로 대체된 상태일 때 사용되거나 또는 결함이 테스트 대상 내에서만 국한되도록 예측 및 제어 가능한 테스트 환경을 제공하는 목적으로 사용된다. 

테스트 드라이버 : 테스트 중에 시스템 모듈을 호출하는 기능(Functions)이다. 상향식 (Buttom-up) 통합 테스트 접근에서 사용된다. 

테스트 스텁 : 테스트 중에 시스템 모듈에 의해 호출되는 기능이다. 하향식(Top-down) 통합 테스트 접근에서 사용된다. 

 

◆ 다음 중 테스트 용이성(Testability)이 높은 요구사항(testable requirements)은 무엇인가?

(1) 시스템은 반드시 사용자에게 친숙해야 한다.

(2) 시스템에서 안전우선(Safety-critical) 영역은 결함이 없어야 한다.

(3) 홈페이지 접속 시 응답 시간은 1초 이하여야 한다.

(4) 시스템을 다른 시스템에 이식 가능하도록 만들어야 한다. 

=> 테스트 용이성이 높은 요구사항이란 요구사항이 충족됐는지를 결정하기 위해 테스트를 쉽게 설계(Test design)하고 실행(Test execution)할 수 있게 지원한다. 따라서 (3)가 테스트 설계 및 실행이 가능한 가장 명확한 요구사항이다.

 

◆ 다음 중 명세 기반(블랙 박스) 테스트 설계 기법과 구조 기반(화이트 박스) 테스트 설계 기법에 대한 설명으로 잘못된 것은 무엇인가?

(1) 구조기반 테스트 설계 기법은 상위레벨 테스팅(High level testing)에 적용될 수 있다.

(2) 명세기반 테스트 설계 기법은 주로 상위레벨 테스팅에 적용한다.

(3) 구조기반 테스트 설계 기법은 입력 값을 선택하는 기법과 같이 사용되지 않는다.

(4) 명세기반 테스트 설계 기법은 개발 초기 단계의 명세서 리뷰(Review)에 사용한다. 

=> 구조기반 기법에서도 입력 및 출력 데이터가 필요한 경우에 등가 분할이나 경계값 분석등과 같은 입력 값을 선택하는 기법을 사용할 수 있다. 

=> 구조 기반 기법은 소프트웨어나 시스템의 구조(Structure)를 중심으로 테스팅하는 것으로 상위레벨의 명세나 시스템에 구조적인 부분이 있으면 해당 부분의 테스트를 구조 기반 기법으로 설계할 수 있다. 

 

◆ 다음 중 명세 기반(블랙 박스) 테스트 설계 기법에 대한 설명으로 잘못된 것은 무엇인가?

(1) 하위레벨 테스팅(Low level testing)에는 사용하지 못한다.

(2) 많은 경우 입력 값을 선택하는 기법과 같이 사용한다.

(3) 결함을 예방하는 차원에서 사용한다.

(4) 상세 설계서를 기초로 단위 및 통합 테스팅에서 사용한다.

=> 명세 기반 기법은 대부분의 경우 모든 테스트 레벨에서 사용이 가능하다.

=> 명세 기반 기법은 조기 테스트 설계(Early test design)에 적극 활용해 결함을 예빵하는 차원에서 사용할 수 있다. 

 

◆ 테스트 설계 기법의 특징에 대한 설명 중 틀린 것을 모두 고르시오 

(i) 경험 기반 기법은 경험적으로 테스팅하는 것으로 테스트케이스를 문서화하지 않는다.

(ii) 구조 기반 기법은 소프트웨어 코드나 설계 정보로부터 테스트케이스를 도출한다.

(iii) 상태전이 테스팅은 명세 기반 기법으로 분류되는데 해당 명세가 상태 전이 구조를 갖고 있어 구조 기반 기법으로도 분류될 수 있다.

(iv) 결정 테스팅은 결정 포인트를 중심으로 모든 분기를 커버하는 테스트 기법으로 결정 포인트 명세를 토대로 테스트를 설계하므로 명세 기반 기법으로 분류된다. 

=> 경험 기반 기법은 테스트 설계 기법 중에 하나다. 경험 기반 기법은 경험을 기반으로 테스트케이스를 도출(문서화)한다. 결정 테스팅은 구조 기반 기법으로 분류한다. 결정 테이블 테스팅과 혼돈하기 쉬워 문제에서 많이 다루니 유의하기 바란다. 상태 전이 테스팅은 기본적으로 명세 기반 테스트 설계 기법으로 분류하지만 명세 자체에 구조가 들어 있어 구조 기반 테스트 설계 기법의 특징이 있다. 

 

◆ 다음 보기 중 동등분할(Equivalence partitioning)을 적용할 수 있는 테스트 유형으로 올바르게 고른 것은 무엇인가? 

(i) 기능성 테스팅

(ii) 비기능성 테스팅

(iii) 구조적 테스팅

(iv) 확인/리그레션 테스팅

(1) i, ii 

(2) i, iii, iv

(3) ii, iii, iv

(4) i, ii, iii, iv

=> 동등 분할은 모든 테스트 유형, 모든 테스트 레벨에서 적용이 가능하다.(경계값 분석도 마찬가지임) 

 

◆ 다음 중 커버리지간의 포함관계가 올바른 것은 무엇인가?

(1) 구문(Statement) 커버리지 결정 < 결정(Decision) 커버리지 < 결정/조건(Condition/Decision) 커버리지 < 경로(Path) 커버리지 < 다중 조건(Multiple condition) 커버리지

(2) 결정 커버리지 < 다중 조건 커버리지 < 결정/조건 커버리지 < 경로 커버리지

(3) 구문 커버리지 < 결정 커버리지 < 결정/조건 커버리지 < 다중 조건 커버리지 < 경로 커버리지

(4) 구문 커버리지 < 결정 커버리지 < 조건 커버리지 < 결정/조건 커버리지 < 다중 조건 커버리지 

=> 구문 커버리지 < 조건/결정 커버리지 < 변경 조건/결정 커버리지 < 다중 조건 커버리지 < 경로 커버리지 

=> S < CD < MC/DC < MCC < APC 

 

◆ 코드 커버리지(Code coverage)에 대한 설명으로 올바른 것은 무엇인가?
(1) 구문(Statement), 결정(Decision) 커버리지 등 테스트 정도를 의미한다.

(2) 구문, 결정 커버리지와 전혀 다른 커버리지이다.

(3) 상세 설계 명세에 있는 내용이 다뤄진 정도를 의미한다.

(4) 다중 조건 커버리지, 경로 커버리지 등 강력한 커버리지는 코드 커버리지에 포함되지 않는다.

=> 코드 커버리지(Code coverage)란 테스트 스위트로 소프트웨어 코드의 어떤 부분이 실행됐고 어떤 부분이 실행되지 않았는지 결정하는 분석기법이다. 코드 커버리지에는 구문(Statement) 커버리지, 결정(Decision) 커버리지, 조건(Condition) 커버리지, 다중(Multiple condition)커버리지, 경로(Path) 커버리지 등이 있다. 

 

◆ 다음 중 코드 커버리지 설명으로 틀린 것은?

(1) 테스트한 코드 또는 로직이 어느 정도인지 수치화한다.

(2) 사용자 화면(UI)을 테스팅할 때 사용할 수 있다.

(3) 단위 및 통합 테스팅(주로 단위 테스팅)을 완료하는 기준으로 사용하기에 적합하다.

(4) 일반적으로 경로 커버리지(Path coverage)의 100% 달성을 목표로 한다. 

=> 코드 커버리지(Code coverage)는 코드의 구조가 테스트 스위트(Suite)에 의해 테스트된 정도를 백분율로 나타낸 것이다. 코드 커버리지에는 그 강도에 따라 다양한 종류가 있으며 보장하는 범위가 다르다. 100% 경로 커버리지(Path coverage) 달성은 모든 가능한 경로를 한번 이상 테스트 하는 것을 의미하며 대부분의 경우 달성하기 불가능하다. 

 

◆ 다음 중 코드 커버리지에 대한 설명으로 틀린 것은 무엇인가?

(1) 100% 결정 커버리지(Decision coverage)를 달성하면 100% 구문 커버리지(Statement coverage)도 달성한다.

(2) 경로(Path) 커버리지 100% 달성하면 일반적으로 구문 커버리지 100%를 달성하는 것보다 더 많은 결함을 찾는다. 

(3) 경로 커버리지를 100% 달성하면 구문 커버리지를 100% 달성한다.

(4) 구문 커버리지를 100% 달성하면 일반적으로 분기 커버리지 100%를 달성하는 것보다 더 많은 결함을 찾는다. 

=> 분기(=결정) 커버리지가 구문 커버리지를 포함하기 때문에 틀린 내용이다.

 

◆ 코드 기반의 테스트 커버리지(Code coverage)에 대한 설명 중 틀린 것은?

(1) 구문 커버리지(Statement coverage)는 결정 커버리지(Decision coverage) 보다 강도가 약하다.

(2) 결정 커버리지는 분기문에서 각 분기를 모두 테스트했는지 측정한다.

(3) 조건 커버리지(Condition coverage)는 분기문에서 각 개별 조건식(Individual condition)의 참/거짓을 모두 고려하므로 결정 커버리지 보다 강도가 세다.

(4) 일반적으로 커버리지 목표 수치는 조직과 소프트웨어의 특성을 고려해 국제 표준이 정의한 기준을 따른다. 

=> 결정 커버리지는 분기문에서 각 분기를 모두 테스트하는지 확인하므로 구문 커버리지보다 강도가 세다. 반면 조건 커버리지는 결정 커버리지보다 강도는 세지만 포함 관계는 없다. 커버리지 목표 수치는 조직과 소프트웨어의 특성을 고려해 조직 내에서 협의를 통해 결정한다. 기능 안전성 관련 국제 표준에서는 안전 최우선 시스템에 대해 커버리지 목표 수치의 일부를 제시하지만, 소프트웨어는 일반적인 커버리지 목표 수치를 제시하는 국제 표준은 없다.  

 

◆ 아래 코드에서 구문(Statement) 커버리지 100%와 분기(Branch) 커버리지를 100% 달성하는 최소 테스트케이스 수는?

Read P;

Read Q;

IF(P+Q > 200) THEN

     Print "F Large"

ENDIF
IF(P > 10) THEN

     Print "S Large"

ENDIF

(1) 구문 커버리지 테스트케이스 1개, 분기 커버리지 테스트케이스 2개

(2) 구문 커버리지 테스트케이스 1개, 분기 커버리지 테스트케이스 1개

(3) 구문 커버리지 테스트케이스 2개, 분기 커버리지 테스트케이스 3개

(4) 구문 커버리지 테스트케이스 2개, 분기 커버리지 테스트케이스 2개

=> 구문 커버리지는 전체 구문 중 실행된 구문이 몇 퍼센트인지 측정하는 것이고, 분기 커버리지는 실행된 결정 포인트 내의 전제조건식의 참 거짓이 선택된 정도(결정 포인트에서 분기 

 

◆ 다음과 같은 의사코드(Pseudo code)에서 결정 커버리지(Decision Coverage, Dc)와 조건/결정 커버리지(Condition/Decision Coverage, C/DC) 100%를 달성하는 최소 테스트케이스 수는?

Read A;

Read B;

IF (A*B) > 200 Then

     print "Key is A";

end IF

IF(A > 100) Then

     print "Key is B";

end If

=> 일반적으로 결정 커버리지와 조건/결정 커버리지를 달성하는 최소 테스트 케이스 수는 동일하다. 특히, 결정 포인트의 개별 조건식이 'and', 'or'로 묶여있지 않고 하나만 있는 경우는 쉽게 최소 테스트케이스의 수가 동일함을 유추할 수 있다. 

 

◆ 기본 경로의 수 = 분기문+1

 

◆ 다음 중 제어 흐름 테스트(Control flow test)를 적절하게 설명한 것은 무엇인가?

(1) 제어 흐름 테스트를 수행하면 결정 커버리지와(Decision coverage) 조건 커버리지 (Condition coverage)를 달성할 수 있다.

(2) 제어 흐름 테스트와 테스트 커버리지와 관계가 없다

(3) 제어 흐름 테스트는 결정 커버리지(Decision coverage)를 달성하는 수단으로 볼 수 있다.

(4) 제어 흐름 테스트는 코드 레벨의 테스트 설계 기법이므로 시스템 테스트 레벨(Test lelvel)에는 적용할 수 없다. 

=> 결정 테스팅은 결정 포인트(Decision points)에 해당하는 제어 흐름을 다루므로 제어 흐름 테스팅의 한가지 형태이다. 제어 흐름 테스트는 프로그램 구조를 테스트하는 것으로 단위 테스트나 통합 테스트를 수행하기 위해 사용되는 공식적인 화이트박스 테스트 설계 기법이지만 경우에 따라서 시스템 테스팅과 같은 비즈니스 레벨에서도 적용이 가능하다.

즉, 시스템 코드 이외에도 흐름도로 표시 가능한 시스템 명세(Specification)에 제어 흐름 테스트 기법을 적용해 테스팅할 수 있다. 

 

◆ 탐색적 테스팅은 애드혹(Ad-hoc) 테스팅, 게릴라(Guerrilla) 테스팅, 직관적(Intuitive) 테스팅과 유사한 개념의 테스팅이나 정해진 임무(Tasks)와 목표(Objectives), 결과물(Deliverables), 회고(Debriefing)가 있다는 점에서 다르다.

 

◆ ISO/IEC 9126에 명시된 비기능 품질 특성

신뢰성 : 규정된 성능 수준을 유지하고 결함을 방지할 수 있는 소프트웨어의 능력

사용성 : 사용자가 이해하고 배우기 쉬운 정도

효율성 : 자원의 적절한 사용 및 적절한 반응시간 정도 

유지보수성 : 소프트웨어의 수정 및 변경의 용이성 

이식성 : 지원하는 다양한 환경에서 운영될 수 있는 소프트웨어 능력

기능성 : 요구되는 기능을 만족하는 능력 

 

<5 테스트 조직> 

◆ 테스트 리더 

- 테스트 전략과 계획을 프로젝트 관리자 및 이해관계자와 조정한다.

- 추적성 확보를 위해 적절한 테스트웨어 형상 관리를 구성한다.

- 테스팅 지원 도구 선택하고 관련된 교육 훈련을 계획한다.

- 자동화할 대상, 범위, 방법 등을 결정한다.

 

◆ 테스터

- 테스트 계획을 검토하고 테스트 계획에 기여한다.

- 테스트 명세(Test specification)를 작성한다.

- 테스트 데이터를 준비하고 확보한다. 

- 테스트 실행에 필요한 테스트 환경을 구축하고 셋업한다. 

- 테스트를 자동화한다. 

 

◆ 테스트 계획과 관련된 내용 중 잘못된 것은 무엇인가?

(1) 분석된 시스템 또는 소프트웨어의 리스크를 반영해 테스트 종료 조건(Exit criteria)을 결정한다.

(2) 테스트 리포트에 어떤 내용을 담을 것인지 결정하고 테스트 결과를 어떻게 평가할 것인지 결정한다.

(3) 테스트 수명주기에 걸쳐 정의된 다양한 업무에 소요되는 비용을 추정하고 테스트 수행에 필요한 자원을 할당한다. 

(4) 테스트에 소요되는 비용을 추정하고 테스트 완료 조건 등을 결정한 후 테스트 전략을 수립한다. 

=> 테스트 계획 활동은 해당 테스트를 전략적으로 접근하는 방법 결정, 소프트웨어 수명주기와 연계시키는 활동, 테스트 대상과 범위를 결정하고 이에 따라 투입 인력과 자원 및 일정을 계획하는 활동 등을 포함한다. 

테스트에 소요되는 비용 추정과 종료 조건의 결정은 리스크 기반 테스팅 전략이 수립된 후에 수행돼야 의미를 가질 수 있다. 

 

◆ 다음 중 테스트 접근법과 그 설명을 잘못 짝지은 것은?

(1) 분석적(Analytical) 접근법 : 리스크가 가장 높은 부분을 집중적으로 테스팅하는 접근법으로 리스크 기반 테스팅(Risk-based testing)이 대표적이다.

(2) 모델 기반(Model-based) 접근법 : 장애 기반, 체크리스트 기반, 품질 특성 기반 접근법 등이 있다.

(3) 동적/발견적(Dynamic and heuristic) 접근법 : 테스팅을 미리 계획하지 않고 개발 이후 수행하고, 실행과 평가가 동시에 이뤄지는 탐색적 테스팅이 있다. 

(4) 리그레션 회피형(Regression-averse) 접근법 : 기존의 테스트웨어는 물론, 기능적 리그레션 테스팅의 광범위한 자동화와 표준적 테스트 스위트(Suite)를 재사용하는 접근법이다. 

=> (2)는 방법론적 접근법의 설명이다. 

모델기반 접근법 : 실패율 혹은 실 사용에 대한 통계적 정보를 이용하는 확률론적 테스팅이다. 

 

◆ 테스트 진척도를 측정하는 메트릭은 다음과 같다.

- 테스트케이스 작성 완료 비율

- 테스트 환경을 갖추는 작업 완료 비율

- 테스트 실행 관련 메트릭(예를 들어, 합격 및 실패한 테스트케이스 수)

- 결함 정보 : 결함 밀도, 발견된 결함과 수정된 결함, 장애율, 재 테스트 결과

- 요구사항, 리스크, 코드의 테스트 커버리지 

- 제품에 대한 테스터의 주관적 자신감

- 테스트 마일스톤 달성률

- 테스트 비용 관련 메트릭 

 

◆ 다음 중 테스트 제어활동에 해당하지 않는 것은?

(1) 계획대로 진행되는지 확인 후 계획에서 벗어나거나 부족한 내요은 보고한다.

(2) 모니터링 결과, 계획대로 진행되지 않는 항목이 있어서 일정을 늘린다.

(3) 테스트 진행이 끝나면 테스트 결과를 바로 제출할 수 있도록 정리한다.

(4) 테스트 진척률이 부족한 모듈은 일정을 추가하도록 계획을 변경한다.

=> 테스트 결과를 정리하는 활동은 테스트 종료 조건의 평가와 리포팅 단계에서 한다.

 

◆ 다음 중 테스트 프로젝트 관점에서 형상 관리에 대한 설명으로 틀린 것은?

(1) 개발 수명주기 동안 나오는 시스템과 소프트웨어의 온전함을 확보하고 유지한다.

(2) 테스트 문서화는 식별한 모든 개발 문서와 소프트웨어 아이템을 정확하게 참조한다

(3) 테스트케이스 명세를 개발 산출물과 연계해서 관리해 해당 개발 산출물의 테스트 커버리지를 높인다.

(4) 형상 관리 절차와 인프라는 테스트를 계획하는 동안 구현한다.

=> 형상 관리는 설계 문서, 코드 등 개발 (중간) 산출물 전체가 대상이다. 테스트 베이시스가 개발 산출물임을 감안하면 개발 산출물(테스트 베이시스)의 변화에 따라 테스트 관련 문서와 산출물의 형상을 관리해야 한다. 빌드 별로 테스트 케이스, 발견된 결함 등이 다를 수 있어 테스트 산출물의 지속적인 형상 관리가 필요하다. 

 

◆ 프로젝트 리스크

- 개인적인 이슈와 교육훈련 관련 이슈

- 공급자인 제3자가 역할 수행에 실패

- 완성도 높은 요구사항을 정의하는 문제 

- 설계 문서가 준비되지 않은 것

- 신규 기능 테스트케이스를 작성하지 않은 것.

- 설계 인원이 부족해 코드 설계 품질이 낮은 것

 

◆ 제품 리스크

- 소프트웨어 및 하드웨어가 개인이나 회사에 손실을 끼칠 가능성

- 취약한 소프트웨어 특성

- 출시 예정인 시스템이 데이터 표준을 위반했다.

- 시스템 사용 시간이 길수록 성능이 급격하게 떨어진다. 

 

◆ 다음 중 인시던트 리포트(Incident report)의 목적이 아닌 것은?
(1) 개발자와 다른 프로젝트 관련자가 문제점을 식별, 격리하고 필요하면 정정하도록 피드백을 제공한다.

(2) 테스트 대상 시스템의 품질은 물론 테스팅 진척도를 추적하는 수단을 테스트 리더에게 제공한다.

(3) 테스트 프로세스 개선(Test process improvement)에 대한 아이디어를 제공한다.

(4) 다음번 테스트 레벨 및 양산 단계, 유지보수 단계로 출시하는데 필요한 조언을 제공한다.

=> 테스트 리포트의 한 종류인 릴리즈 조언(Release advice)에 대한 설명이다. 릴리즈 조언은 다음번 테스트 레벨 및 양산 단계, 유지보수 단계로 출시하기 위한 공식적인 보고서이다. 

 

<6 테스팅 지원 도구>

◆ 다음 중 테스트 관리 도구(Test management tool)가 지원할 수 있는 업무는 무엇인가?

(1) 테스트 실행
(2) 테스트 진행 리포트

(3) 인시던트 관리

(4) 요구사항 관리 

=> 테스트 관리 도구를 이용해 결과를 기록(Logging)하고 테스트 진행 상황에 대한 리포트(Progress report)를 생성할 수 있다. 

 

◆ 다음 중 정적 분석 도구(Static analysis tool)의 주요 목적이 아닌 것은 무엇인가?

(1) 코드에 대한 이해를 지원한다.

(2) 구조와 의존관계를 분석한다.

(3) 코딩 표준을 지키도록 한다.

(4) 코드 리뷰 프로세스 정보를 저장한다.

=> (4)의 내용은 리뷰 도구(Review tools)의 역할이다. 

 

◆ 다음 중 컴포넌트 테스트나 통합 테스트 단계에서 개발자가 유용하게 사용할 수 있는 테스트 도구가 아닌 것은?

(1) 형상 관리 도구

(2) 정적 분석 도구

(3) 동적 분석 도구

(4) 커버리지 측정 도구

=> 컴포넌트 테스트나 통합 테스트 중에 개발자에게 보다 유용한 도구는 아래와 같은 것들이 있다.

- 정적 분석 도구(Static analysis tools)

- 모델링 도구(Modeling tools)

- 테스트 하네스/유닛 테스트 프레임웍 도구(Test harness/Unit test framework tools)

- 커버리지 측정 도구(Coverage measurement tools)

- 동적 분석 도구(Dynamic analysis tools)

 

◆ 소프트웨어 실행 중에 발생할 수 있는 메모리 누수(Memory leak)를 측정할 수 있는 도구는?

(1) 동적 분석 도구

(2) 성능 테스팅 도구

(3) 스트레스 테스팅 도구

(4) 모니터링 도구

=> 소프트웨어 실행 중에 메모리 누수는 동적 분석 도구가 발견할 수 있고, 소프트웨어를 실행하지 않고 코드를 분석해 메모리 누수를 발견하는 도구는 정적 분석 도구이다. 

 

◆ 테스트 자동화 도구에 대한 설명으로 틀린 것은?

(1) 초기 환경 구성과 테스트 설정에 많은 시간과 노력이 소요된다.

(2) 객관적인 평가 기준 및 테스트 결과에 대한 신뢰성을 제공한다.

(3) 수동 테스트와 비교하면 테스트 실행과 결과에서 월등한 일관성과 반복성을 제공한다.

(4) 테스트 자동화는 기록&재생(Record & play back) 방식이 대부분이다. 

=> 기록&재생 방식의 테스트 자동화는 테스트 자동화 도구에서 일부에 불과하다. 테스트 데이터를 자동으로 생성해 이를 자동으로 실행하는 도구, 단위 테스트 환경을 제공해 주고 실행을 자동화하는 도구, 테스트를 관리하는 도구, 코드를 분석하는 도구, 코드 실행을 분석하는 도구 등 거의 모든 테스트 활동에 여러 유형의 테스트 도구가 있다. 

 

◆ 다음 중 비기능(Non-functional) 테스팅을 가장 잘 설명한 것은?
(1) 통합 시스템이 요구 명세를 충족하는지 확인하는 통합 시스템 테스트 프로세스

(2) 시스템이 코딩 표준(Coding standards)을 준수하는지 확인하는 테스트 프로세스

(3) 시스템의 내부 구조를 참조하지 않는 테스팅

(4) 사용성(Usability), 신뢰성(Reliability), 유지보수성(Maintainability)과 같은 시스템 속성을 테스트

=> 비기능 테스팅을 성능 테스팅(부하 테스팅, 스트레스 테스팅 등), 사용성 테스팅, 호환성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅, 이식성 테스팅 등으로 분류한다.

(1) 테스트 레벨(Test level) 중의 하나인 시스템 테스팅 설명이다.

(2) 정적 분석(Static analysis)의 일부를 설명했다.

(3) 내부 구조를 참조하지 않는 테스트는 테스트 접근법 중의 하나인 블랙박스 테스팅으로 볼 수 있다.

내부 구조를 참조하지 않고 테스트를 설계할 때 블랙박스 테스트 설계 기법을 활용할 수 있다. 즉 블랙박스 테스팅으로 테스트를 계획/모니터링/제어하고 설계하고 실행하고 리포팅할 수 있다. 

 

◆ 정 주임은 안전-최우선 소프트웨어 개발 프로젝트를 수행하는 테스터다. 테스트 실행 중 기대 결과와 다른 결과가 나와 인시던트 리포트(Incident report)를 작성하려고 한다.

IEEE 표준 829를 따른다면 가장 중요하게 생각해야 할 정보는?
(1) 영향도(Impact), 인시던트 설명, 날짜와 시간, 테스터 이름

(2) 리포트 고유 ID, 필요한 특별 요구사항

(3) 본인이 생각하는 테스트 대상 전달 항목, 테스터 이름, 결함 원인

(4) 인시던트 설명, 환경, 기대 결과 

=> IEEE 829에서는 다음과 같이 기술한다.

- 테스트 인시던트 보고 식별자 : 테스트 리포트는 다른 문서와 구별할 수 있도록 고유 식별자(고유 ID)가 있다.

- 요약(Summary) 사건을 요약한다.

- 인시던트 기술(Incident description) : 입력 값, 예상 결과, 실제 결과, 환경, 반복시도 등

- 영향도(Impact) : (알려진 경우)인시던트가 테스트에 미칠 영향도를 기술한다.

 

◆ 키워드 주도 테스트(Keyword-driven test) 실행 도구

=> 테스트 입력 데이터, 액션 단어, 기대 결과가 들어있는 테이블(표)로 테스트 대상의 실행 을 제어한다.

 

◆ 테스트 관리 도구

=> 요구사항 명세와 같은 소스 문서, 테스트케이스, 테스트 결과, 결함이나 인시던트 간의 추적성을 제공한다.