안녕하세요 :-) 김민지입니다. 어느새 CSTS 시험이 내일로 다가왔습니다.
코로나가 2.5단계로 격상되었는데, CSTS 시험은 그대로 시행하는 것 같습니다.
이번에 CSTS에 응시하지 못하신 분들은 제 경험과 컨텐츠를 기반으로 다음 시험 준비하시길 바랍니다.
오늘은 CSTS에서 가장 중요한 테스팅 기법에 관한 내용입니다. 지난 시간 내용들을 숙지한 뒤, 이번 내용을 배워보도록 합시다!
시험에 꼭 나올 문제들은 표시하도록 하겠습니다.
-
테스팅 방법 (7문제)
-
테스팅 방법 개요
-테스팅 방법은 기준에 따라 다양하게 나뉠 수 있습니다.
유형별 (기능 적합성, 보안성, 신뢰성, 호환성 등), 정적 (Walkthrough, Inspection), 동적(화이트박스, 블랙박스, 경험기반테스트), 설치(확인(재), 리그레션, 스모크), 소프트웨어 주기모델(순차, 진화, 애자일 등)등 다양한 목적과 상황에 따라 테스팅 방법을 달리할 수 있습니다.
2. 재테스팅 및 리그레션 테스팅
-
|
구분 |
개념 |
|
재테스팅 (Re-Testing) |
확인 테스팅(Confirmation Testing)라고도 합니다. 결함이 발견되고 수정된 후에 원래의 결함이 성공적으로 제거 되었는지 확인하기 위해 다시 테스트하는 것입니다. *디버깅(Debugging)은 결함의 원인을 찾거나 결함을 수정하기 위한 개발 활동입니다. 테스팅이 아닙니다. |
|
리그레션 테스팅 (중요) (Regression Testing) |
결함 수정 이후 변경의 결과로 도입되었거나, 발견되지 않았던 또 다른 결함을 발견하는 것입니다. 즉, 이미 테스트된 프로그램의 테스팅을 반복하는 것, 퇴행 (Regression)여부를 확인합니다. |
|
스모크 테스팅(중요) (Smoke Testing) |
빌드 테스팅(Build Acceptance Testing)라고도 합니다. 각 모듈의 중요한 기능을 테스트합니다. 빌드, 즉 배포가 가능한 수준인지 확인하기 위한 테스트입니다.
|
3. 소프트웨어 생명 주기 모델과 테스팅 (모델기반 테스팅)
- 일반적으로 많이 사용되는 소프트웨어 개발 수명주기 모델을 잘 이해하는 것은 테스터의 중요한 역할이며, 테스트 활동을 수명주기 초반에 시작해야 합니다.
- 어떤 개발 수명주기 모델을 선택하더라도 테스팅을 초기에 시작하면 시간과 비용을 절약할 수 있고, 개발 초기에 발견한 결함은 수정하는 비용도 비교적 저렴합니다.
|
구분 |
개념 |
|
순차적 모델(중요) |
V 모델, 폭포수 모델에 근간을 두고 있습니다. 위에서 살펴본 것과 같이 각 테스트 레벨의 테스트 실행이 순차적으로 이루어지도록 되어 있습니다. |
|
진화적 모델 |
요구사항 정의, 시스템의 설계, 구축, 테스팅을 조각으로 나눠서 진행합니다. 즉, 소프트웨어의 기능이 점진적으로 늘어나 기능이 증분 되는 경우입니다. |
|
애자일 모델 |
애자일 방법론은 속도에 강점을 두고, 각 개발 사이클(스프린트)을 보고 데드라인을 예측하는 경우입니다. 일반적으로 애자일 모델에 따른 테스트는, 개발과 동시에 지속적인 리그레이션 테스트를 진행하고, 팀이 각 스크럼(각 개발자가 자신에게 할당된 태스크 혼자서 진행)팀으로 나위고 스크럼팀에 개발자와 QA가 같이 포함되어 있습니다. QA는 독립적이기도 하고 독립적이지 않기도 해야 합니다. |
4. 소프트웨어 테스트 원칙
-
Beizer의 소프트웨어 테스트 진화 과정 (중요)
|
레벨 1 (debugging-oriented) |
디버깅 개발 환경에서의 오류 해결 |
|
레벨 2 (demonstration-oriented) |
올바른 동작을 입증 |
|
레벨 3 (destruction-oriented) |
오류가 있음을 보여주는 테스트 |
|
레벨 4 (evaluation-oriented) |
SDLC(Software Development Life Cycle)전 단계에서의 오류 테스트 |
|
레벨 5 (prevention-oriented) |
사전에 결함을 예방, 테스트 용이성 고려해야함 |
2. 소프트웨어 테스트의 원칙(중요)
-
테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹에 의해서 수행되어야 한다. (테스트의 독립성에 대한 문제는 꼭 나옵니다!)
-
테스트 작업 능력이 뛰어난 사람에게 맡겨라 (경험 기반 테스팅)
-
타당한 경우 뿐만 아니라 타당하지 않고, 예상하지 못한 경우들에 대해서도 테스트하라 (Positive 테스트와 Negative 테스트 둘 다 이행)
-
프로그램의 어떤 부분에 오류가 남아있을 확률은 이미 발견된 오류의 수에 직접적으로 비례한다 (파레토의 80:20의 법칙)
-
파레토의 법칙은 컴퓨팅 자원의 80%를 20%의 모듈이 사용하며, 20%의 모듈이 전체 실행시간의 80%를 차지함, 또한 전체 오류 중 20%가 수정 비용의 80%를 차지함
테스트 설계 기법
정적 테스팅 (7문제)
-
정적 테스팅 개요
정적 테스팅은 프로그램 실행 전, 소스코드 파싱 기반 문법과 코드 등 잠재적 취약점을 발견하는 기법입니다. 적은 비용과 인력으로 테스트할 수 있는 기법입니다.
-
리뷰
리뷰의 주 목적은 결함 발견입니다. 프로젝트 요구사항, 가용자원, 제품 유형과 리스크, 비즈니스 도메인, 조직의 문화 등에 따라 적절한 리뷰 유형을 선택해야 합니다.
각 유형 별로 파악해보도록 합시다.
-
정적 분석 (중요) : 공식도의 정도와 워크쓰루와 인스펙션을 구분합시다!
-정적 분석은 소프트웨어를 실행하지 않고 테스트 하는 것입니다.
정적분석은 크게, 비공식 리뷰, 워크쓰루, 기술 리뷰, 인스펙션 등이 있습니다.
|
구분 |
설명 |
|
비공식 리뷰 |
동료검토(Buddy Check)라고도 합니다. 소소한 문제의 빠른 해결, 공식 프로세스를 기반으로 하진 않습니다. 체크리스트 사용 여부는 상황에 맞게 판단하며, 애자일 개발에서 매우 일반적으로 사용되는 자유로운 리뷰 방식입니다. 결함과 개선을 발견하기 위해서 개발 당사자를 제외한 동료가 검토합니다. |
|
워크쓰루 (Walkthrough) |
개발 작성물을 작성하는 중에 검토하며, 조기에 오류를 발견하고 해결하며 개발 산출물 작성자에 의해서 진행됩니다. 인스펙션에 비해 비형식적인 기법입니다. |
|
인스펙션 (Inspection) |
개발 초기 단계부터 결함을 발견하며, 공식적이고, 주재자, 거토자, 작성자, 기록자, 판독자, 테스터로 구성되며 체크리스트를 기반으로 훈련된 리더가 회의를 중재합니다, |
|
기술 리뷰 |
체계적으로 명세 및 표준에 대한 적합성 검사입니다. 동료와 기술적 전문가가 참여합니다. |
*공식도
비공식 리뷰 < 워크쓰루 < 기술 리뷰 < 인스펙션
동적 테스팅 (17문제) *****17문제가 나오니, 모든 내용에 대해 숙지합시다*****
-
동적 테스팅 개요
동적 테스팅은 코드의 동적 동작 테스트를 설명하기 위한 것입니다. 시스템이 일정하지 않고 시간이 지남에 따라 변하는 변수를 테스트합니다. 동적 테스팅에서는 소프트웨어를 실제 컴파일하고 실행해야 합니다.
따라서 정적 테스팅보다 비용이 많이들고, 소스코드가 늘어나면 복잡합니다.
|
항목 |
정적 테스트 |
동적 테스트 |
|
특징 |
– 코딩 규칙, 가이드 준수 여부 검사 |
– 단독분석보다 정적 기법 병행 수행 적용 |
|
장점 |
– 코드 실행 전 사용 |
– 오류 탐색 정확도 높음 |
|
단점 |
– 정확도 상대적 낮음 |
– 코드 전체 수행 어려움 |
2. 구조기반 테스팅(화이트박스 테스트)
동적 분석은 대표적으로 구조기반 테스팅(화이트박스 테스트)와 명세기반 테스팅(블랙박스 테스트)으로 나뉘어집니다. 블랙박스 테스트는 입력값을 넣은 뒤, 기대되는 출력값이 나오는지를 검사하고, 화이트박스는 논리 코드를 보면서 테스트 하는 것이 가장 큰 차이점입니다.
구조기반 테스팅(화이트박스 테스트)부터 알아보도록 하겠습니다.
- 구조기반 테스팅은 프로그램 소스코드의 논리적인 구조를 커버 하도록 테스트 케이스를 설계하는 방법입니다.
- 화이트박스 테스트 종류
|
구분 |
개념 |
|
문장 커버리지 (Statement/Block Coverage) |
테스트 하는 프로그램 내의 모든 문장을 적어도 한번 이상 실행 문장 커버리지 = 테스트케이스에 의해 실행된 문장의 수/전체 문장의수 *100 |
|
분기(결정) 커버리지 (Branch Coverage) |
결정 포인트(If, for, while, switch와 같은 조건문)가 탐과 거짓을 적어도 한번 이상 실행하게 시키는 테스트 케이스를 설계 분기 커버리지 = 테스트케이스에 의해 실행된 분기수/전체 분기수 * 100 |
|
조건/분기 커버리지 (Condition/Decision Coverage) |
프로그램에 나타난 각 기본조건들의 참과 거짓 및, 이를 포함한 각 전체 조건의 참과 거짓이 적어도 한번 테스트 되도록 테스트케이스를 설계 실행된 기본 + 전체 조건식의 T,F 수/모든 기본 + 전체 조건식의 T,F 수 *100 |
|
다중조건커버리지 (Multiple Condition Coverage) |
프로그램의 각 조건문 내 기존 조건식의 가능한 논리적 조합이 적어도 한번 테스트 되도록 테스트케이스를 도출하는 기준 다중조건커버리지 = 실행된 기본 조건식의 T,F수/모든 기본 조건식의 T,F 모든 조합의 개수 * 100 |
|
기본 경로 커버리지 |
McCabe가 제안한 방법으로 사이클로매틱 복잡도의 개수 만큼의 경로를 테스트 케이스로 도출 프로그램 내의 모든 독립적인 경로를 테스트한다. 사이클로매틱 복잡도 계산 1. 간선의 수 – 노드의 수 + 2 2. 폐구간 + 1 3. 분기 노드의 개수 + 2 |
3. 복잡도
-소프트웨어 복잡도 측정을 위해 사용되는 소프트웨어 지표이며, 복잡도가 낮을수록 프로그램이 구조적으로 안정되었다는 의미이며, 높을수록 프로그램이 비 구조적이며 불안정하다는 의미입니다.
-보통 분기가 10개 미만인 소프트웨어가 적절하며, 10개가 넘어가면 단위를 잘라서 개발하는 것이 좋다고 평가합니다.
제일 핵심적인 내용만 정리하여 올려드리니, 꼭 꼼꼼하게 보고 숙지하시길 바랍니다. 이어서 블랙박스테스트(명세기반 테스팅)에 대해 포스팅하도록 하겠습니다.
이해되지 않거나, 궁금하신 사항은 메일(bigdataleader@naver.com) 또는 댓글에 달아주세요.
