테스트 Flashcards
테스트
[정의] 숨어있는 결함(Fault)과 요구 사항의 차이점을 찾기 위해 소프트웨어를 분석하고 평가하는 프로세스
[특징]
- 성공적인 테스트는 무결점이 아닌 결함을 찾는 데 있음
- 기대하지 않는 결함이 있다는 전제하에 계획 수립
[주요이슈] (인조전투복)
- 중요성 인식 부족, 조직적 역량 부재, 전문인력 부족, 투자 부족, SW 품질 및 복잡도 증가
[해결방안]
- 자동화툴(Junit/PMD/Mockup, Auto Rollbak) 활용
- 뮤테이션/비버깅 테스트 병행
- ISO 29119/TMMi/ISO25000 표준 활용
- Agile, TDD 활용
테스트 원리
[정의] ISTQB에서 제시한 효과적 테스트 위해 테스트 수행시 발생, 지켜야하는 원칙 수립한 기본원리
[목적] 수정 위한 결함 발견, Side/Ripple Effect 확인, 신뢰성/가용성 등 시스템 특성 평가
* 결함의 원인을 밝히고 코드를 수정하는 디버깅과는 달리 테스팅은 결함을 발견하기 위한 활동
원리
1. 완벽한 테스팅 불가 : 모든 가능성 테스팅 불가, Risk 분석 필요 (Risk 기반 테스팅)
2. 결함존재 증명 : 결함이 존재함을 밝히는 활동 (테스트 본연 역할)
3. 테스팅 개발 초 시작 : 설정한 테스트 목표에 집중(요르돈 법칙, 명세기반 기법, 정적기법(FTR))
4. 결함 집중 : 결함의 80%는 코드 20%에서 발생 (파레토 법칙, 경험기반 테스트, 스파이크 테스트)
5. 오류부재의 궤변 : 사용성이 낮은 경우 오류 부재는 품질과 무관 ( ISO 2502n, 요구사항 추적, 인터뷰)
6. 정황 의존적 : 테스트 환경에 의존적 (회귀 테스트, 도메인 기반 테스트)
7. 살충제 패러독스 : 동일 테스트 케이스 반복 수행 시 결함 발견 어려움( 경험기반, 탐색적 테스트)
* Agile, MSA 확산 따른 경량화, 다양화 기반의 개발 환경 대응 위한 테스팅 효율화 방안 고려 필요
ISO/IEC 29119
[정의] 체계적 S/W 테스트 절차와 원리/가이드 지원을 위한 SW SDLC 테스팅 프로세스, 산출물 국제표준
구성
1. Part 1(BS 7925-1) Concept & Vocabulary : SW 테스팅 원리와 프랙티스, SW테스트 개념/생명주기
2. Part 2(IEEE 1008) Process : SW 생명주기 프로세스 표준(ISO/IEC 12207)의 테스팅 프로세스
3. Part 3(IEEE 829) Documentation : 조직, 테스트 문서관리, 동적 테스트 프로세스 문서
4. Part 4(BS 7925-2)Testing Techniques : 정적,동적,비기능 테스트 케이스 설계 기법, 테스트 커버리지 측정
5. Part 5(ISO29119) Keyword-Driven Testing : 키워드 주도 테스팅 F/W, Tools 요구사항
[도입방안]
- 사전 학습 : Best Practice(ISTQB 테스팅 BP 학습), ISO 29119 Working Group 참여
- 내부 절차 : TMMI 기반 성숙도 수준 측정 (현 조직의 테스팅 Practices 평가를 통해 Level 점검)
[연계표준]
- ISO/IEC 33063(테스팅 프로세스 심사모델 ), TMMi(조직 테스트역량 평가)
IEEE 29119-3(829)
[정의] 소프트웨어 테스팅 국제 표준, ISO 29119 중 테스트 문서 양식 표준(IEEE 829)
[특징] 테스트 설계 명세(테스트 조건 포함) 및 테스트 케이스 표준 양식 제시
[테스트 케이스 구성요소] (IC 사스기결 추중비)
1. ID : 테스트 케이스 식별자
2. TEST Case명 : 테스트 내용 명료한 표현
3. 사전조건 : 선행 조건, 구동환경, 테스트 데이터 정의
4. Test Step(절차) : 7단계 이내 권고
5. 기대결과 : 의도된 동작 판단 근거
6. 결과(합격/불합격) : Pass/Fail/Not Tested/Blocked-사전조건 미충족
7. 추적성 : 테스트 케이스 관련 요구사항, 적용기법 등
8. 중요도 : 시간적 제약성 고려, 수행 기준
9. 비고 : 작성 의도 등
ISO/IEC 33063
[리드] 테스팅 프로세스 심사모델
[정의] ISO/IEC 29119-2를 기반으로 한 소프트웨어 테스팅 프로세스 심사 국제 표준 모델
[특징]
- 심사범위 : 테스트 단계, 테스트 타입, 테스트 레벨든 모든 영역
- 레퍼런스 : ISO/IEC 15504-5(SPICE)의 성숙도 모델과 ISO/IEC 29119-2 테스트 프로세스
* ISO/IEC 29119-2의 테스트 프로세스를 이용하여 평가 모델 구성
[구성요소] (범참용오성)
- 프로세스 범위
- 프로세스 참조 모델
- 테스트 용어, 사례
- 테스트 평가 모델에 대한 오버뷰
- 테스트 프로세스 성숙도 레벨 (성과지표(조관동정), 능력지표 (불수관구예혁))
* TMMi, TPI, Test SPICE등의 국제 표준화
* 국내 주도로 제정된 표준이기 때문에 향후 SW 테스팅 시장에 주도권 확보
테스트 프로세스
[정의] SW 테스트를 계획, 분석, 실행, 리포팅, 마감으로 단계화하여 체계적으로 관리/수행하는 테스트 체계
[필요성] 척도/현황 파악, 프로세스 통제, 자원 효율화, 가시성 확보
[프로세스] (계분실리마) (수행활동/산출물)
1. 테스트 계획수립 : 테스트 Scope/Risk 정의, 테스트 추정 및 접근법 선정 (테스트 계획서, 테스트 디자인)
2. 테스트 분석/설계 : 테스트 베이시스 리뷰, 테스트 케이스 설계, 우선순위 선정 (테스트 설계서, TC)
3. 테스트 구현/실행 : 테스트 하네스/Suites, 실행 및 결함 분석 (테스트 프로시저, 테스트 실행 결과서)
4. 테스트 실행완료/보고 : 테스트 증적 취합, 완료조건 판단 (테스트 요약 보고서, 테스트 최종 보고서)
5. 테스트 마감 : 프로세스 평가, 결함추적 관리 (테스트 프로세스 심사 보고서, 테스트 프로세스 개선 계획서)
* 프로세스의 지속적 개선 및 서비스 적시성이 중시되는 DevOps 개발 환경 확산에 따른 최적화 전략 필요
테스트 계획
[정의] 테스트 베이시스, 테스트케이스 기반자료, SRS , 아키텍처 , 설계문서
[작성절차]
1. 계획검토 : 일정, 인원, 협조 확보
2. 테스트 범위 대상선정 : 체크리스트, 브레인스토밍
3. TC 정의/작성 : 화이트, 블랙박스
4. 타당성 확인 : Repository, R&R
5. TC 유지관리 : 형상관리, 회귀테스트 시 사용
[테스트 케이스]
- 특정 요구사항 준수 확인을 위한 개발된 입력값, 실행조건, 예상된 결과
- 테스트케이스 묶음(Test Suite)
테스트 설계 기법
[정의] 테스트 설계 과정을 통해 테스트 케이스와 테스트 데이터를 설계하고 명세화하는 기법
[설계기법 - ISTQB 4.2기준]
1. 내부구조 참조여부 : 블랙/화이트
2. 설계근원 기준 : 명세/구조/경험
[설계기법-상세]
1. 명세기반 기법 : 불구동경원조결시상분R(유즈케이스/페어/직교/분류트리)
2. 구조기반 기법 : 구결조조변다(SC/DC/CC/C.DC/MC.DC/MCC)
3. 경험기반 기법 : 경탐오체특(탐색적테스팅, 오류추정, 체크리스트-경험과 노하우를 분류정리/특성테스팅-9126특성기반 도출, 비기능테스트에 주로 사용), (+)파레토법칙
[유형별 설계 기법]
- 구조기반 (화이트박스) : 컴포넌트/시스템 코드 분석, 기개발 테스트 케이스 이용, 추가 테스트 케이스 도출
- 명세기반 (블랙박스) : 테스트 베이시스 문석 분석, 기능적/비기능적 테스트 케이스 도출
- 경험기반 (블랙박스) : 지식, 경험에서 테스트 케이스 도출
테스트 차터
[정의] 탐색적 테스팅에서 테스트의 범위와 목적, 테스트 방법 등을 정의위한 테스트 참조 문서(승인서)
[특징] Test Insight 제공, 테스트 체계화, 리스크 기반 접근, Lessons Learned로 활용
[구성요소] 1) 테스트 범위/목적 2) 테스트 세션/일정 3) 테스트 대상/절차 4) 테스트 결함/이슈 5) 테스트 경험
테스트 커버리지 & 코드 커버리지
[테스트 커버리지]
- (정의) 기능, 소프트웨어, 사용자 요고사항의 최대 검증 범위의 보장을 위한 블랙박스 테스트 기법
- (매커니즘) 단위,기능,승인, 통합 테스트
- (목적) Feature coverage, Risk coverage, Requirement coverage
- (특징) 불필요한 테스트 케이스 탐지, 결함 누출 방지
[코드 커버리지]
- (정의) 코드가 실행된 범위를 확인하기 위해 정적 도구로 검증하는 화이트 박스 테스트 기법
- (코드 커버리지 레벨) Statement, Branch, Function, Loop, Condition 커버리지
- (유형) 코드 계측, 런타임 계측
- (특징) 정량적 정보 제공, Dead/Error 코드 제거
커버리지
[리드] 테스트 충분성 지표
[개념] 시스템 또는 소프트웨어 구조가 테스트 스위트(Suite)에 의해 테스트 된 정도, 즉 테스트의 충분함(Thoroughness)을 측정하는 비율
[활용] 테스트 완료조건으로 활용
[유형] (구결조조변다)
1. 구문(Statement) : 명령문을 적어도 한번수행
2. 결정(Decision) : 결정문이 적어도 한번씩 참과 거짓 결과를 수행
3. 조건(Condition) : 각 조건이 적어도 한번은 참과 거짓이 되도록
4. 조건/결정(Condition/Decision) : 결정조건과 개별조건이 각각 참, 거짓 결과가 한번씩 수행하는 케이스
5. 변경조건/결정 (Modified Condition/Decision) : 내부조건식(개별조건)이 다른개별조건식에 무관하게 독립적으로 전체조건식 결과에 영향줌. 최소순환 복잡도 고려
6. 다중조건 (Multiple Condition) : 모든 개별 식 조건의 모든 조합 고려 커버리지
테스트 완료조건(Exit Criteria)
[리드] 테스트 종료 기준
[정의] 정량화 지표 활용, 하나의 테스트 레벨 또는 특정 목적의 테스팅에 대한 종료 시점 결정 위한 테스트 완료 조건
[수립기준] 의도한 SW 목적 달성 증명, 제약 사항/리스크 수준 고려
* SW 복잡화 및 활용 확산 따른 안전성 요구 증가, 품질 확보 위한 ExitCriteria 수립 필요
[유형] (완목기커리스)
1. 테스트 완전성 : 모든 테스트 케이스 수행, 중대결함 없을 시 (실행 TC 수/계획 TC 수 = 1)
2. 테스트 목적 달성 : 초기 정의된 품질목표 달성 시 (Defect/시간 = 0)
3. 테스트 기준 통과 : 테스터가 수립한 테스트레벨 및 완료조건 기준 충족 시 (90%이상 케이스 만족시)
4. 테스트 커버리지 : 클라이언트 요구사항 모두 충족 시 (MC/DC 100%)
5. 테스트 리스크 : 예상되었던 모든 리스크 제거 시 (재발견 Defect, 발견 Defect = 0)
6. 테스트 스케쥴 : 예정 테스트 일정 종료 시 (테스트 완료일 < 출시일)
* TEST 설계 부정확, 실행 관리 미비 시 오류 부재의 궤변, 살충제 패러독스 등 테스트 신뢰성 저하 문제 발생
테스트 베드
[정의] 실제와 동일 환경 또는 결과 예측이 가능한 가상 환경을 구축하여 개발 기 술의 적합성, 사용성을 테스트 해보는 환경
[구성요소]
1. Test Harness : 테스트를 수행하기 위해 필요한 Stub 과 Driver 로 구성된 테스트 환경
2. Test Driver : Test Tool / 가상 인증 서버
3. Test Stub : Emulator / 더미 컴포넌트
테스트 하네스
[정의] 테스트을 지원하는 목적하에 생성된 코드와 데이터의 집합으로 Test Driver를 포함하는 테스트를 위한 Tool
[구성요소] (드스스 케스목)
1. Test Driver : 시험 대상 모듈을 호출, 파라메터 전달, 상향식 테스팅에 필요, Test Tool/xUnit
2. Test Stub : 시험 대상 모듈이 호출, 하향식 테스팅에 필요, Emulator/Dummy 컴포넌트
3. Test Suites : 테스트 케이스의 집합
4. Test Case : 입력 값, 실행 조건, 기대 결과 등의 집합
5. Test Script : 테스트 절차 명세, 자동화
6. Mock Object : 예정된 시늉/행위를 하는 객체, Stub는 Stubbed Date를 단순 반환하는 것의 차이
* 단위테스트와 통합테스트에 테스트 하네스가 주로 사용됨
테스트 드라이버 & 스텁
[정의] 모듈간 상/하향식 테스트를 위하여 테스트 대상모듈의 역할을 대신 수행하는 테스트모듈
[유형]
1. 드라이버 (Driver)
- 상향식 통합 테스트에서 해당 모듈이 Call하는 가상의 상위 계층 모듈
- 상위모듈 대체, Bottom-Up(상향식), 하위모듈의 중요성 높을때 활용
- (단) 초기구조파악이 어려움, (장) 초기 오류 발견 용이
- JDBC 연결 모듈, 가상 인증 서버
2. 스텁 (Stub)
- 하향식 통합 테스트에서 해당 모듈이 Call 및 Return하는 가상의 하위 계층 모듈
- 하위모듈 대체, Top-Down(하향식), 상위모듈의 중요성 높을때
- (단) 입출력이 일반적으로 하위에 있어 테스트 어려움 (장) 구현 용이
- Emulator, Dummy Component
테스트 오라클
[정의] 테스트 수행 결과의 참/거짓 여부 판단 위한 사전 정의 참 값 대입, 비교 수행 기법 및 활동 매커니즘
[특징]
1. 제한된 검증 : 모든 케이스 판단 적용 어려움
2. 수학적 기법적용 : 테스트 시 수학적 기법 이용, 오라클 값 산정
3. 테스트 자동화 활용 : 자동화 결과의 정확성 보장, 결과 값 자동 비교하는 결정자 역할
[유형] (참샘휴일)
1. 참(true) : 모든 입력 값에 대해 결과 확인
2. 샘플링 : 특정 일부 값에 대해서 결과 맞는지 확인
3. 휴리스틱 : 샘플링 값 + 휴리스틱 판단 결과 확인
4. 일관성 검사 : 변경이 있는 경우 전후의 결과 값이 같은 지 확인 (회귀 테스트)
테스트 더블
[정의] 테스트 대상 코드를 Stub, Dummy, Mock, Fake 등 기법 이용하여 주변에서 격리하거나 상호작용하도록 하는 객체
[역할]
1. 테스트 대상코드 격리 : 협력 객체 의존성 제거. 테스트 대상에 집중 효과
2. 테스트 속도 개선 : 복잡한 계산에 따른 시간 지연 대체
3. 예측 불가능한 실행 요소 제거 4. 특수한 상황 시뮬레이션 5. 감춰진 정보 획득
[유형] (더블-덤스FM스)
1. Dummy : 인스턴스 객체만 필요한 경우 → 0, null, false 리턴
2. Test Stub : 구현 기능의 최대 단순화 → Void, 고정 값 리턴(Dummy + 동작하는 것처럼 기능)
3. Fake Object : 부수효과, 연쇄동작 방지 위한 경량화. 실제 객체 수행 기능 중 일부 변경
→ if(a=1){ return true; } else { false;}
4. Mock Up : 특정 조건 따른 Action 수행(수준 정교화), Case 별 파라미터 return 및 Fail 처리
→ Library: Mockito, JMock, Easy Mock 예) 두 객체간 상호 결과로 특정 메서드 호출 여부 확인
→ 상태기반: setName()/GetName(), 행위기반: method A() {method B()};
5. Test Spy : 기능 + 메서드 호출 등 기록 정보 제공. 메시지 처리 결과 return 구현
→ 설계 또는 명세가 제대로 되지 않은 경우 > Callcount++, getCallcount()
V모델
[정의] 명세화된 기능이 올바르게 수행하는지 개발자 관점의 Verification(검증)과 사용자 관점의 Validation(확인)을 지원하는 Test Model
[특징] 추적성, 확장성, 신뢰성
[구성도]
- 검증(Verification) : 제품 생산 활동 (과정) / 각 단계 별 수행 / 개발자 관점 / Inspection, Peer Review
- 확인(Validation) : 생산된 제품 대상 (결과) / 시작과 종료 단계 / 사용자 관점 / 단위,통합,시험,인수 테스트
[구성요소]
1. Verification(FTR) (요기상구)
- 요구 분석 : 사용자 요구사항 수집분석(기능,비기능)
- 기본 설계 : 요구사항에 따른 기능설계
- 상세 설계 : 요구사항에 대한 상세기능설계
- 구현 : 기능구현,이벤트순서i/f구현
2. Validation (단통시인)
- 단위 테스트 : 개별모듈테스트 개발자에의해 수행
- 통합 테스트 : 모듈을결합하여 시스템테스트(빅뱅,하향식,상향식통합,백본) =>컴포넌트간 i/f
- 시스템 테스트 : 통합모듈에 대한 시스템적 테스트(실제 최종사용 환경수행)
- 인수 테스트 : 사용자의 만족여부(알파,베타,감마)=>비기능 특성에 대한 확신
테스트 유형
[테스트 유형]
1. 프로그램 실행 여부
- 동적 테스트(구현 후) : 화이트 박스 테스트(구조), 블랙 박스 테스트(명세)
- 정적 테스트(구현 전) : Code Review, Work Through, Inspection
2. 테스트 설계 근원(Origin) 기준 - ISO/IEC/IEEE 29119-4 기반
- 명세기반 테스트(동등분학,경계값,결정테이블,상태전이), 구조기반(구문,조건등), 경험기반 테스팅(탐색적,오류추정,체크리스트)
3. 동적 테스팅 중 프로그램 내부구조(코드) 참조 여부
- 블랙박스 테스팅(명세/경험 기반), 화이트박스 테스팅(전통적 구분, 구조기반)
4. 테스트 시각
- 검증(Verification) : 개발자 시각, 확인(Validation) : 사용자 시각, 고객관점
5. 테스트 단계
- 단위, 통합, 시스템, 인수, 설치 테스트
6. 테스트 목적
- 회귀, 병행, 부하, 성능, 유지보수, 안전, 회복, 강도 테스트
명세기반 테스트(블랙박스)
[리드] 요구사항 명세서 기반 기능적 테스트
[정의] 시스템 명세를 기반으로 테스트 케이스를 도출 및 실행하여 결함을 찾는 테스트 기법
[특징]
- Black Box Test : 시스템 내부는 Black Box로 간주
- Data Driven : 입출력 데이터 흐름에 초점
* 원시코드를 보지 않고 목적 코드만으로 데이터 중심의 입출력 테스트 수행, 기능 및 성능 테스트
[기법] (불구동경 원조결시 상분R) - ISO/IEC/IEEE 29119-4 기반
- 구문 규칙 (Syntax) : 적합, 부적합 (ID, Password 유효 범위 체크)
- 동등분할 (Equivalence Partitioning) : 대푯값
- 경계값 분석 (Boundary Value Analysis) : 영역, 유효, 비유효 경계값
- 조합 테스트 (Combinatorial Test) : 페어와이즈 테스팅(Pairwise Testing), 직교분할 테스팅
- 결정 테이블 (Decision Table) : True/False 표현
- 원인 결과 그래프(Cause Effect Graphe) : 원인(좌측),결과(우측) 그래프, AND/OR/NOT, E.I.O.R 원인간 제약
- 시나리오 (Scenario) : Use Case 테스트
- 상태 전이 (State Transition) : 상태들 사이의 천이
- 분류 트리 (Classification Tree) : 트리 구조
- 랜덤 테스트 (Random Testing)
[검증기준] Input 검사, Output 검사, Case 검사, Othogonal Array 검사
구조기반 테스트(화이트박스)
[리드] 코드 기반 White box 테스트
[정의] SW 구현 코드 기반 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 기법
( 구조기반 테스트 = 코드기반 테스트 = 테스트 커버리지)
[특징]
- White Box Test : 프로그램 내부 구조 및 복잡도를 검증하는 테스트
- Logic Driven : 코드구조의 효율성 및 오류사항 발견하기 위한 테스트
* 프로그램 내부로직 참조, 허용되는 논리적 경로 파악 및 복잡도 계산, Logic 중심 기능 테스트
[기법] (구결조조변다)
<커버리지>
1. 구문(Statement) : 모든 명령문 적어도 한번수행
2. 결정(Decision) : 결정문 적어도 한번씩 참/거짓 결과 수행
3. 조건(Condition) : 각 조건 적어도 한번 참/거짓 결과
4. 조건/결정(Condition/Decision) : 결정/개별조건 각각 참/거짓 결과가 한번씩 수행
5. 변경조건/결정(MC/DC) : 개별 조건식이 전체 조건식의 결과에 영향을 주는 조건 조합 (영향 없는 조건 제외)
6. 다중조건 커버리지(Multiple Condition) : 모든 개별 식 조건의 모든 조합 고려 커버리지
<경로/대상에 따른> 화이트 박스
1. 기초 경로 검사, 2. 조건 검사, 3.루프 검사, 4.데이터 흐름 검사 (루프 종류 : 단일 루프, 중첩 루프, 연결 루프)
[검증기준] 문장검증 기준, 분기점 조사, 개별 조건, 경로 검증 기준
* ISO/IEC 26262, ISO/IEC 61508, DO-178B/C 등에서도 MC/DC 기반 테스트 케이스 도출
</커버리지>
