//구글콘솔 광고 추가가

슬슬 한번씩 더 읽어봐야 이해가 되는 부분이 왔다. 그래도 꽤 재밌구만!!


4.1 테스트 설계 및 구현 프로세스

테스트 설계의 진행 방식
 - 테스트 조직 구성
 - 테스팅과 개발 프로세스의 성숙도
 - 시간 절약
 - 참여인원 등 테스트 정황에 따라 달라짐
무엇을 테스트할지 결정하기 위해 테스트 베이시스 문서 분석
 - 테스트 베이시스 - 요구사항 명세서, 개발 설계서
테스트 조건
 - 기능, 트랜잭션, 품질 특성 또는 구조적 요소
테스트 설계 과정
 - 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 함
테스트 케이스
 - 입력 값의 묶음
 - 실행 사전 조건
 - 기대 결과와 실행 사후 조건으로 구성
테스트 표준 문서
 - 소프트웨어 테스트 문서 표준(IEEE 829)
 - 테스트 설계 명세와 테스트 케이스의 표준 양식 제안
테스트 용이성 평가

테스트 분석 및 설계 단계- 평가 대상 : 테스트 베이시스(개발 명세)
- 낮은 품질의 테스트 베이시스는 테스트 케이스 도출이 어려우므로 테스트 베이시스의 테스트 용이성을 평가해 테스트 베이시스의 품질을 높임.
- 명세서가 테스트를 고려해 작성됐는지 확인(테스트를 위한 API 설계 등)
테스트 구현 및 실행 단계- 완결성
   >> 테스트에 필요한 모든 것이 다 있는가?
- 주요 기능성
   >> 주요 기능이 잘 동작하는가?
- 테스트 시작조건 준수 여부 검증
- 테스트 환경 검증
   >> 테스트 인프라 확인(하드웨어, 도구, 테스트 데이터)
   >> 기타 어플리케이션(stub, driver) 

 
테스트 분석, 설계, 구현

테스트 케이스
 - 정의
   >> 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치 여부 확인을 위해 디자인된 입력 값의 묶음.
   >> 실행 사전 조건, 기대 결과와 실행 사후 조건의 집합
   >> 테스트 돼야 하는 Test Condition((상황)을 입력 값과 기대결과로 표현
 - 작성 목적
   >> 요구되는 보장성을 갖는 최소개의(최적의) 테스트 케이스가능한 많은 결함을 발견할 수 있도록 정의한 목표 수준의 테스트 보장성 확보

< 테스트 케이스의 목적 >
1. 최소한의 테스트 케이스로 많은 결함을 발견하는 것.
2. 테스트 대상을 가능한 빠짐없이 테스트하여 테스트 보장성을 확보할 수 있도록 설계되어야 함.
3. 공식적 기법과 경험 기반의 비공식적 기법을 모두 이용해야 함.
 - 공식적 기법을 먼저 작성한 후에 비공식적인 기법으로 보완이 필요함.

 
  - 예시 테스트 케이스                                                                                                            결과값, 데이터나 상태 변화

테스트 케이스 개발 및 작성
 >> 테스트 케이스 개발 시 우선순위 선정 - 테스트 프로시져 명세서(테스트 케이스의 실행 순서) 만듦 - 테스트 실행 스케쥴 작성(테스트 실행도구를 사용하여 테스트를 수행하면 테스트 프로시저는 테스트 스크립트로 기술할 수 있음)
테스트 수행 절차
 >> 얼마나 상세하게 작성하는 것이 좋을 지 작성해야 함 - 테스터의 스킬, 능력, 해당시스템에 대한 이해를 고려하여 테스트 케이스의 상세함을 조절해야 함.
 >> 만약 외주를 주는 경우는 자주 테스터가 바뀌더라도 작업을 수행할 수 있도록 상세하게 수행 절차를 기록하여야 함.
테스트 케이스 작성
 >> 테스트 수행 절차를 얼마나 상세하게 작성하는 것이 적절한 지 결정해 주어야 함(테스트 케이스당 7스탭이내로 수행 절차를 작성하는 것이 바람직)
 >> 7스텝이 넘을 경우는 두 개로 분리하여 관리하는 것이 좋음

4.2 테스트 설계 기법의 종류

블랙박스 기법 VS. 화이트박스 기법

블랙박스 기법(>> 명세기반 기법과 경험기반 기법) - 완성제품화이트박스 기법(>> 구조기반 기법) - 소스 대상
- 테스트 대상의 내부구조(코드)를 참조하지 않고 테스트 베이시스 그리고 개발자와 테스터, 사용자들의 경험을 바탕으로 기능적 혹은 비기능적 테스트 케이스를 도출하고 선택하는 방법.- 컴포넌트(단위) 또는 소프트웨어(시스템)의 구조(코드)를 중심으로 테스트 케이스를 도출.

 
▶ 테스트 설계의 근원(Origin)을 기준
 - 명세 기반 기법, 구조 기반 기법, 경험 기반 기법으로 분류

명세 기반 기법- 테스트 대상에 관한 공식적/ 비공식적 모델(명세) 사용
- 모델로부터 테스트 케이스를 체계적으로 도출
= 블랙박스 테스트
(공식적 방법)
구조 기반 기법- SW 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출
- 작성한 테스트 케이스로부터 커러리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가할 수 있음.
= 화이트박스 테스트
(공식적 방법)
경험 기반 기법- 테스터, 개발자, 사용자 등의 지식 활용
- 발생 가능한 결함과 그 분포 등에 대한 지식 활용
- 문서화 필요
= 탐색적 테스트
(비공식적 방법)

명세가 나오면 블랙박스, 구조가 나오면 화이트박스

4.3.1 명세 기반 기법(Specification - based)

명세 기반 기법

 - 종류 : 동등 분할, 경계값 분석, 조합 테스팅, 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅.

 

4.3.1.1 동등 분할

동등 분할
 - 입력 / 출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대표값을 선택하여 테스트 케이스를 도출하는 방법.
 - 동일한 입력에 대해 항상 동일한 결과를 갖도록 클래스 구분
 - 적용 방법
   >> 주어진 시스템 정보를 분석해 입력/ 출력 영역을 유사한 특징을 가진 클래스로 분할
   >> 분할된 클래스에서 각 클래스를 대표하는 테스트 케이스 도출
   >> 모든 Valid equivalence class(유효)가 커버될 때까지 테스트 케이스 생성
   >> 모든 Invalid equivalence class가 커버될 때까지 테스트 케이스 생성

4.3.1.2 경계값 분석

경계값 분석
 - 동등 분할의 경계에서 결함이 발견될 확률이 높기 때문에 결함을 예방하기 위해 경계값까지 포함하여 테스트
 - 분할 영역의 최대값과 최소값이 그 영역의 경계값
 - 동등 분할과 마찬가지로 모든 테스트 레벨, 테스트 유형에 적용
 - 동등 분할의 확장으로 여겨지며 동일한 방식으로 커버리지 보장

4.3.1.3 결정 테이블 테스팅

결정 테이블
 - 시스템의 동작을 결정하는 비즈니스 규칙을 정의하는 방법
 - 입력 값들이 논리적인 관계(Binary Condition - 참과 거짓)를 갖는 경우, 입력 값을 원인 / 결과로 나누어 기술
    -- > 테스트 케이스 작성
 - 구현이나 명세에 잠재된 오류를 찾는 데 효과적으로 이용
특징
 - 테이블 분석을 통해 중복, 발생 불가능한 상황, 모순이 생기는 상황을 제외시키고 나머지의 결정과 액션 조합
 - 좋은 테스트 데이터 선택을 위해, 경계 값 또는 동등 분할 기법 사용
 - 불가능한 Rule을 식별하는 것은 테스트 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -- > 시스템 설계에 의존적.
결정 테이블 장단점

장점 - 요구사항 등 테스트 베이시스의 문제점을 발견할 수 있는 효과적인 테스트 케이스 생성 가능
(테스트 케이스를 작성하면서 결함 발견, 인스펙션 등 리뷰미팅에 테스트 전문가가 참여한다는 의미)
 - 테스트 베이시스의 불완전성과 모호함 식별 가능
단점 - 작성에 노력과 시간이 많이 소요될 수 있음(특히 테스트를 위해 결정 테이블을 작성해야 하는 경우)
- 복잡한 시스템은 표현하기 어려울 수 있으며, 작성 시 논리적인 실수 가능성있음(개발팀 검토 필요)

 

728x90

나에게 필요한 공부가 뭐가 있을까 찾아보다 ISTQB 자격증에 대해 알게 되었다.

국제 자격증이라 일단 멋있다. 물론 멋있기도 하지만 사실은 소프트웨어 테스팅의 전문성에 대해 알아두면 나의 길에도 언젠간 도움이 될 것 같아 준비해 보려고 한다. 실러버스에 공부자료도 올라와 있어 공부하기에 어려운 환경이 전혀 아니라는 상황도 만족스럽다. 찾아보니 유튜브에서 대학생들을 위한 강의도 있길래 보면서 같이 공부할 예정이다.

4월에 시험이 하나 있고 6월에 시험이 있던데 업데이트 된 내용으로 시험을 보려면 6월에 시험을 봐야 하는 것 같다.

 

6월 20일 시험 접수기한 : 2024-06-10 ~ 2024-06-14 

 

 

++

시험 일자
2024-08-29

 
ISTQB® Foundation Level (CTFL) 7회 정기(한글 4차)
 
접수 시작
08/19(월)
11:00 접수 마감
08/23(금)
17:00

 

 

실러버스 자료 링크와 샘플 문제 링크

자료링크:

http://www.kstqb.org/board_skin/board_view.asp?idx=1902&page=1&bbs_code=4&key=0&word=&etc=

 

KSTQB

ISTQB Foundation Level V.4.0 실러버스 한글 번역본이 업로드 되었습니다. 학습에 참고하시기 바랍니다. (샘플문제는 샘플문제 자료실로 이동) - 2024.2.21 by KSTQB Teams ISTQB® Foundation Level 실러버스가 v.4.0

www.kstqb.org

샘플문제: (아직 한글 버전은 올라오지 않음)

http://www.kstqb.org/board_skin/board_view.asp?idx=1903&page=1&bbs_code=5&key=0&word=&etc=

 

KSTQB

ISTQB® Foundation Level 실러버스가 v.4.0으로 업데이트 되었습니다. 따라서 2024년 6월 4일 정기시험부터 ISTQB Foundation Level(CTFL) 자격시험은 V.4.0 실러버스로 시행됩니다.  (이전 버전(CTFL Syllabus 2018) 대

www.kstqb.org

유튜브 강의 링크

https://www.youtube.com/watch?v=hCD8799VmM8&list=PLUQt-s6e18eOY8rMTw95VsL-jzgLSMuXJ&index=2&ab_channel=%EA%B9%80%EA%B8%B0%ED%83%9C%EC%9D%98JAVA%EB%A5%BC%EC%9E%90%EB%B0%94

 


40문제 중 26문제만 맞추면 된다지만 문제들이 생각보다 완벽하게 알지 못하면 헷갈릴 만한 문제들이 많나 보다.

역시 쉬울 리가 없지. 잘 공부해서 웬만하면 다 맞아보자!

728x90

+ Recent posts