[ISTQB CTFL] 실라버스 A유형 문제 정리/요약 ( 1~20번 )

 

 

 

 

시험 공부하며 정리 중인거 공유합니다

 

 

* 테스팅의 일반적인 목적

- 요구사항, 사용자 스토리 등등 작업 산출물 평가

- 명시된 모든 요구사항이 충족됐는지 검증

- 결함 예방 / 결함 및 장애 발견

- 만족스럽지 않은 소프트웨어 품질로 인한 리스크 완화(운영 중 기존 발견되지않았던 결함 발생)

- 계약, 법적, 규범적 요구사항이나 표준 준수나 테스트 대상이 그런 요구사항이나 표준을 준수하는지

 

 

 

* 테스팅과 디버깅

- 테스트를 실행하면 소프트웨어 결함으로 인한 장애를 찾아낼수있음

- 디버깅은 그런 장애의 원인을 찾고 수정하는 개발 활동

확인테스팅 : 결함을 제대로 수정했는지 확인

 

 

 

* 결함 오류 장애

오류(error) : 부정확한 결과를 초래하는 인간의 활동, 인간의 실수 ( 결함을 일으킴 )

결함(defect) : 필요한 기능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점 ( 오류에 의해 발생 )

ex) 부정확한 구문이나 부정확한 데이터 정의

장애(failure) : 컴포넌트나 시스템이 예상된 서비스 또는 예상 결과와 실제적인 편차를 보이는 것

기대결과와 다르다고 무조건 장애는 아님

(결함으로 인해 의도치 않은 결과 발생)

 

 

 

*테스팅의 7가지 원리

1. 결함이 존재함을 밝히는 활동, 결함이 없음을 밝히는게 아님

2. 완벽한 테스팅은 불가능

3. 조기 테스팅으로 시간과 비용 절약

4. 결함은 집중되어 나타남( 소수의 모듈에 집중되어 발생하는 경향 )

5. 살충제 패러독스 ( 새로운 결함을 발견하기 위해선 기존 테스트만을 하면 안됨)

6. 테스팅은 정황에 의존

ex) 안전 최우선 산업에의 제어 소프트웨어는 이커머스 애플리케이션과 다르게 테스트해야함

7. 오류 부재는 궤변이다.

(단순히 많은 결함을 발견하고 고쳤거나, 결함이 거의 없다고해서 시스템의 성공이 보장되는게 아님)

 

 

 

* 품질보증

품질보증과 테스팅은 다른 개념

테스팅은 다양한 방식으로 품질 목표 달성에 기여

테스팅은 품질 관리에 포함

 

 

 

* 테스트 활동과 작업

- 테스트 계획 ex)적합한 테스트 기법과 작업 명시, 테스트 일정 수립 테스팅의 목적과 정황으로 인한 제약 사항을 고려해 목적을 달성하기 위해 필요한 접근법을 정의하는 활동   - 테스트 모니터링과 제어 ex) 명시된 커버리지 조건 대비 테스트 결과와 로그 확인 테스트 계획에 정의된 모니터링 메트릭을 활용해 실제 진행 상황을 테스트 계획과 지속적으로 비교하는 활동   - 테스트 분석 ex)테스트 베이시스의 테스트 용이성 평가 측정 가능한 커버리지 조건의 측면에서 ‘무엇을 테스트할지’를 결정하는 것   - 테스트 설계 ex)필요한 인프라와 도구 식별 테스트 컨디션을 기반으로 상위수준의 (테스트 케이스, 세트), 기타 테스트웨어를 생성 “어떻게 테스트를 할 것인가?”를 다룸   - 테스트 구현 ex)테스트 스크립트로 테스트 스위트 생성 “테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가?”   - 테스트 실행 ex)기대 결과와 실제 결과 비교 테스트 스위트를 테스트 실행 일정에 따라 실행   - 테스트 완료 ex) 프로세스 개선을 위한 교훈 도출 / 회고 회의의 일부 완료한 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동

 

 

 

* 인수테스팅

인수 테스팅 목적 (전체 시스템 또는 제품의 동작이나 능력에 초점을 두고 진행하는 경우가 많음)

- 전체 시스템의 품질에 대한 자신감 획득

- 완성된 시스템이 기대한 대로 동작하는지 확인

- 시스팀의 기능/비기능 동작이 명세대로 동작하는지 검증

화이트박스 테스팅 : 시스템 내부 구조나 구현을 기반으로 테스트를 도출

 

 

 

* 컴포넌트 테스팅 vs 시스템 테스팅

컴포넌트 테스팅	시스템 테스팅
리스크 완화	리스크 완화
컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단	시스템의 기능/비기능 동작이 설계 및 명시된 대로 이루어지는지 검증
컴포넌트 품질 수준에 대한 자신감 획득	완성된 시스템이 기대대로 동작하는지 확인
컴포넌트에 존재하는 결함 발견	결함발견
다음 단계로의 결함 전이 방지	결함이 상위테스트 레벨이나 생산단계로의 전이 방지
테스트 케이스는 일반적으로 컴포넌트 명세서, 설계 명세서 또는 데이터 모델에서 도출	테스트 케이스는 요구사항 명세서나 유스케이스로부터 도출

 

 

 

* 확인 테스팅 vs 리그레션 테스팅

확인 테스팅

- 발견된 결함이 수정됐는지 점검

- 구현이 잘되었는지 점검

리그레션 테스팅

- 시스템이 새로운 환경에서 잘 동작하는지 점검

- 의도치않는 부작용을 찾음

 

 

 

* 점진적 개발 모델

- 요구사항 정의, 소프트웨어 설계 및 테스팅을 일련의 추가 작업으로 수행

 

 

 

* 유지보수 테스팅

- 변경된 소프트웨어뿐아니라 새로운 환경에 대한 운영 테스트

- 장기간 보관된 데이터 복원/검색 절차 시스템

- 실질적 장애를 일으키는 긴급 결함을 고치기 위해 전달된 소프트웨어 제품을 수정

(주의) 유지보수 테스팅 vs 유지보수성 테스팅 헷갈리지않기

유지보수성 테스팅 : 소프트웨어의 유지보수성을 테스트하기로 했다.

 

 

 

* 공식 리뷰의 역할 담당자

- 저자(작성자), 관리자, 촉진자(중재자), 리뷰 리더, 리뷰어(검토자), 서기(기록자)

 

 

 

* 공식 리뷰의 주요 활동

- 계획, 리뷰 착수, 개별 리뷰, 이슈 논의 및 분석, 수정 및 보고

 

 

 

* 리뷰 유형

비공식 리뷰 : 장재적 결함 발견, 공식 프로세스를 기반으로 하지 않음

워크쓰루 : 결함 발견, 소프트웨어 제품 개선, 다른 구현 방법 고려, 표준이나 규정 준수 평가

기술 리뷰 : 합의 도출, 잠재적 결함 발견

인스펙션 : 규정과 체크리스트에 기반한 공식 프로세스를 따라야하는 리뷰 수행시

 

 

 

* 정적테스팅 효과 ( 동적테스트랑 비교 )

- 동적 테스팅 실행 전에 보다 효율적으로 결함을 발견하고 수정

- 동적 테스팅으로 발견이 쉽지 않은 결함 식별

- 개발 생산성 향상 / 개발, 테스팅 비용 및 기간 단축

- 리뷰에 참여하는 팀원 간의 의사소통 개선

 

 

 

* 체크리스트 기반 테스팅

- 체크리스트 : 테스트하기 위한 항목을 통과/실패 또는 예/아니오로 답할 수 있게 나열한 목록

- 숙련된 테스터가 제품 검증을 위한 일련의 규칙이나 기준, 또는 참고/확인/기억해야 하는 상위수준 아이템 목록을 사용하는 경험 기반 기법

(추가 다른 용어)

*에러 추정

- 과거 장애에 대한 테스터의 지식이나 장애 모드에 대한 일반적 지식에 기반해 테스트를 도출하는 기법

*블랙 박스 테스트 기법

- 내부 구조는 참조하지 않고, 컴포넌트나 시스템의 기능 및 비기능 명세를 분석해 테스트 케이스를 도출하고 선택하는 절차

*탐색적 테스팅

- 테스터가 자신의 지식, 테스트 항목의 탐구, 이전 테스트 결과를 기반으로 한 테스트를 적극적으로 설계하고 실행하는 테스팅 접근법

 

 

 

* 블랙박스 테스트 기법

- 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용

- 적절한 테스트 베이시스 분석을 기반 ex) 공식 요구사항 문서, 명세서, 유스케이스, 사용자 스토리