설계근원의 기준에 따라 분류(명세/구조/경험기반) 할 수도 있음 - 블랙박스 기법은 명세기반 기법과 경험기반 기법을 포함, 화이트박스 기법은 구조 기반 기법을 포함함
2. 테스트 설계 기법의 주요 종류
분류
주요 종류
설명
명세기반
- 동등분할
- 입력값/출력값 영역, 등가집합 대표값 예) 각 레벨 범위의 대표값을 테스트
- 경계값 분석
- 동등분할의 경계값 포함 예) 각 레벨의 경계의 값을 테스트
- 결정테이블 테스팅
- 논리적으로 의존적 모든 조건들의 조합 생성 - 테스트 조건/기대결과 True, False로 논리조합
- 상태전이 테스팅
- 현재상황, 이전이력의 상태/변화를 상태 전이 다이어그램을 통해 도출
- 유즈케이스 테스팅
- 컴포넌트(단위)레벨, 시스템 레벨
- 페어와이즈 테스팅
- 결함의 2요소의 상호작용에 기인, 2개 요소의 모든 조합을 다루는 테스트
- 직교배열 테스팅
- 각 행과 열이 페어와이즈하게 함으로써 조합의 수를 줄임
- 구문 커버리지(SC)
- 테스트 스위트(테스트 케이스 묶음)에 실행된 구문이 몇 퍼센트인지를 측정
- 결정 커버리지(DC)
- 결정포인트 내의 전체 조건식이 최소한 참/거짓 한번의 값을 갖도록 측정
- 조건 커버리지(CC)
- 전체 조건식의 결과와 관계없이 각 개별 조건식이 참/거짓 한번 모두 갖도록 개별 조건식을 조합
- 조건/결정 커버리지 (C/DC)
- 전체조건식 참/거짓 한번씩하면서 개별조건식 참/거짓 모두 한번씩 갖도록 조
- 변경조건/결정 커버 리지(MC/DC)
- 각 개별 조건식이 다른 개별 조건식에 무관하게 전체 조건식의 결과에 무관하게 영향 - 각 ISO 26262의 최고 안전 무결성 등급인 ASIL D의 경우 MC/DC 100%의 구조적(코드) 커버리지를 만족해야 함
- 다중조건 커버리지 (MCC)
- 결정포인트 내의 모든 개별조건식의 모든 가능한 논리적 조합 100% 보장
경험기반
- 탐색적 테스팅 접근법 (Exploratory Testing approach)
-테스트의 설계, 수행, 계획, 테스트 기록 및 학습을 동시에 진행하는 휴리 스틱(heuristic, 발견적인) 테스팅 접근법 o테스트 목적 기반 수행 (Test-charter) o60~120분의 제한된 시간에 수행 (Time-boxing) o테스트 수행 후 요약보고 (Debriefing)
- 분류 트리 기법
-SW 일부 또는 전체를 트리 구조로 분석 및 표현, 테스트케이스를 도출
-체크리스트
-테스트 하고 평가해야 할 내용과 경험과 노하우를 분류 정리하고 목록화
-특성 테스팅
-ISO9126 등의 품질모델에 있는 품질특성을 근간으로 테스트케이스를 도 출하는 방법 - 비기능적 테스팅에서 주로 사용
- 소프트웨어 내부 구조를 고려하지 않고, 입력값에 대한 출력값을 확인하여 테스트하는 기법
- 특) 기능테스트, Data Driven, I/O Driven
2) 블랙박스 테스트 주요 기법
기법
활용예
상세 설명
동등 클래스 분할 기법 (Equivalence Class Partitioning)
- 등가 분할 된 대표 값을 이용 테스트케이스 도출
- 프로그램의 입력 도메인을 등가 영역들로 분할 후 각 영역별로 대표되는 값들을 선정하여 테스트 케이스를 설계하는 방법 예) 입력데이터 x값이 0 ~ 100 사이여야 한다면 TC를 (x < 0), (x = 50), (x > 100)으로 분할하여 적용
경계값 분석 (Boundary Value Analysis)
- 결함은 경계 값 근처에서 많이 발생 이용
- 입력 영역의 분할 클래스의 경계값으로 테스트 케이스를 설계하는 방법 - 등가 분할 기법의 확장, 등가분할 된 경계의 유효한 값, 경계의 가장 가까운 유효하지 않는 값 선택 테스트 진행 예) x값이 0∼100사이여야 한다면 TC를 (x=0), (x=100), (x=-0.01), (x=100.1) 로 정의
의사결정 테이블 테스팅 (Decision Table Testing)
- 조건과 결과를 참/거짓으로 표현
- 주요한 의사결정 요소들을 표(결정테이블)로 만들고, 요소들간의 결합에 의한 테스트 케이스 설계 - 각 의사결정 요소들의 조합을 통해 다양한 형태의 테스트 시나리오를 도출
유스케이스 테스팅 (Use Case Testing)
- usecase명세서 이용 테스트 케이스 설계
- 유즈케이스를 통해 도출되는 비즈니스 시나리오 (기본 흐름, 대체 흐름)를 기반으로 테스트를 명세화하여 테스트 - 컴포넌트/단위 레벨 유즈케이스 테스팅 - 시스템 레벨 유즈케이스 테스팅
분류 트리 기법(Classification Tree Method)
- SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하는 기법 - 트리구조를 시각화 하여 테스트 케이스를 설계하므로 불필요한 중복 및 누락을 회피
페어와이즈 테스팅 (Paireise Testing)
- 대부분 결함이 2 개의 요소(Pair)의 상호 작용에 기인한다는 것에 착안하여, 각 값들이 다른 파라미터의 값과 최소 한번씩은 조합을 이루도록 구성하는 테스트 기법 - 모든 조합을 포함하지 않으므로 결함을 찾지 못하는 경우 발생 가능
원인-결과 그래프 (Cause Effect Graph)
- 입력 데이터간 관계가 출력에 영향을 미치는 상황을 체계적으로 분석하여 테스트 케이스 설계 및 테스트 - 원인,결과에 근거한 테스트 케이스 생성하며 시스템 외부 동작만 고려
오류예측 기법 (Error Guessing)
예) 입력값 없이 Return 친다. 문법에 어긋난 입력을 시험한다 등
각 시험 기법들이 놓치기 쉬운 오류들을 감각과 경험으로 찾아 검증 - Ad-hoc Testing이라고도 하며 직관과 경험에 의한 특정 형태의 결함 예측 및 해당 결함을 드러내는 테스트 케이스 설계 기법.
2. 내부구조기반 테스트. 화이트박스 테스트 (White-Box Test)
1) 개념
- 소프트웨어의 내부 구조와 복잡도를 기반으로 테스트 케이스를 도출하여 테스트를 수행하는 방식
- 특) 구조 테스트, Logic Driven
2) 화이트박스 테스트 주요 기법
기법
설명
사례
제어구조 시험 (Control Structure Testing)
- McCabe에 의해 제안된 대표적 White Box Test 기법 - 프로그램의 처리 흐름을 제어하는 방법 및 수행 제어를 위해 사용되는 문장의 구조
- 순차형(순차 구조, Sequence형) - 선택형(분기구조, If Then Else형) - 반복형(반복구조, Do While형)
루프 시험 (Loop Testing)
- 프로그램 루프 구조에 국한해서 실시하는 기법 - 루프 시험의 대상 결함 : 초기화 결함, 인덱싱 및 증가의 결함, 루프의 경계선에서 나타나는 경계 오류 - 루프의 유형 : 단순루프, 중첩루프, 연결루프, 비구조적 루프
국가기관등에서 소프트웨어사업의 예산편성, 발주, 소프트웨어 배포 및 서비스 제공을 추진하는 경우 민간 소프트웨어시장침해 등 소프트웨어 산업 생태계에 미치는 영향을 검토하여 사전 조정하는 소프트웨어 영향평가제도에 대한 가이드를 개발 및 보급하는 제도
공공과 민간 간 불필요한 경쟁 및 SW산업 위축을 방지하기 위해 공공 정보화 사업의 기획단계에서 민간 시장 침해 등 SW 산업 생태계에 미치는 영향을 평가하여 개선 의견을 제시하는 제도
2) 법적 근거
소프트웨어진흥법 제43조(소프트웨어사업 영향평가), 동법 시행령 35조, 36조, 37조
소프트웨어사업 계약 및 관리감독에 관한 지침 제5조, 제6조
3) 도입 배경
도입 배경
설명
공공기관의 SW 무상배포에 관한문제 제기
- 일부 공공기관이 SW 또는 정보시스템을 개발하여 무상 제공함에 따라 민간시장을 위축시켜 SW 산업육성을 저해한다는 산업계의 문제제기
공공기관 자체 직접적으로 대국민서비스 앱을 직접 개발(무료배포)
- 민간의 유사 서비스와 불필요한 경쟁 발생 및 민간시장 축소
정부-민간 SW 사업 중복, 민간 업체 도산 등의 문제 발생, 선순환 생태계 구축을 위해 시행
2. 공공 SW 사업 영향평가 제도 평가 절차
1) 공공 SW 사업 영향 평가제도 평가 절차
평가 결과에 따라 사업계획 변경 또는 사업 재검토 수행
평가 결과에 따라 단계적으로 민간 이양 또는 사업 중지 수행
민간 SW 시장 침해 가능성 및 사업의 필요성 및 공공성을 위주로 평가 수행
2) 공공 SW사업 영향 평가제도 평가 기준
평가 결과
구분
내용
민간시장 침해 가능성 없음
- 평가 결과 민간시장 침해 가능성이 없어 사업추진 가능
민간 시장 침해 가능성 있음
민간시장 침해 최소화
- 평가 결과 민간시장 침해 가능성이 있어 민간시장에 침해가 되지 않도록 유의하여 사업 추진
사업 재검토
- 평가 결과 민간시장 침해 우려가 매우 높아 사업 계획의 변경 또는 중지
3. 공공SW 사업 영향평가 단계별 활동
1) 공공 SW 사업 영향평가 단계별 주요 활동
단계
주요활동
참고자료
소프트웨어 사업 기본정보 작성
- 소프트웨어사업의 기본정보를 확인하여 작성하는 단계로 사업기본정보(사업명, 주요 사업내용, 사업기간), 영향평가 단계, 사업 구분을 분류하여 작성
- 사업추진계획서 - 제안 요청서
운영계획 검토
- 운영기관 또는 사용자의 공동 사용 여부 등 소프트웨어 사업의 운영 계획을 분석하여 작성
- 사업추진계획서 - 운영계획안
민간 소프트웨어 시장 침해 가능성 검토
- 소프트웨어사업의 주요 기능과 동일·유사한 민간 소프트웨어가 존재하는지를 확인
- 사업추진계획서 - 기능 요구사항 - 제안 요청서 - 민간 소프트웨어 현황 정보 검색
사업의 필요성 및 공공성 검토
- 주요 기능이 동일·유사한 민간 소프트웨어가 있음에도 불구하고 해당 사업을 추진해야만 하는 필요성과 공공성에 대해 기재한
- 대상 SW 규정 관련 법령 - 국가안보 점검 기준 - 공공데이터 활요 공공서비스 제공 및 정비 가이드라인
종합의견 작성
- 단계별 검토 내용을 토대로 소프트웨어사업의 민간 소프트웨어 시장 침해 가능성을 종합적으로 판단하여 작성 - 민간소프트웨어시장 침해 가능성이 있음에도 추진하여야 하는 경우 민간 소프트웨어 시장 침해를 완화할 방안을 작성 - 민간 소프트웨어시장 침해가능성이 있으며 사업의 필요성 및 공공성이 낮은 경우 사업을 재검토
- 각 단계별 검토 내용
2)공공 SW 사업 영향평가 항목
유형
평가항목
설명
기관 공동사용형
SW 산업계의 파급 효과
- 정부의 SW 개발 및 배포가 시장에 미치는 영향을 정성평가
사업추진의 필요성
- 사업의 기획단계에서 여러 대안을 충실히 검토했는지와 사업 추진의 타당성(필요성, 시급성, 효과성 등)에 대해 정성평가
대국민 서비스형
민간 유사서비스 침해여부
- 매우 침해 : 핵심기능과 수요계층이 유사 서비스 2개 이상 - 침해함 : 핵심기능과 수요계층이 유사한 서비스 1개 존재 - 침해 없음 : 핵심기능과 수요계층이 유사한 서비스 없음
추진사업의 공공성
- 높음 : 민간대체가 힘든 사업으로 공공에서 수행해야하는 서비스 - 낮음 : 민간대체가 가능한 서비스
소프트웨어 사업 영향 평가 가이드라인 : https://www.swit.or.kr/download.do?fileName=/202104/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EC%82%AC%EC%97%85%20%EC%98%81%ED%96%A5%ED%8F%89%EA%B0%80%20%EA%B0%80%EC%9D%B4%EB%93%9C%EB%9D%BC%EC%9D%B8%EB%82%B4%EC%A7%80(2021)%EC%B5%9C%EC%A2%85.pdf
