Software Test Flashcards
1
Q
소프트웨어 테스트 원리
A
⦿ SW 테스트의 정의 : SW 신뢰도 및 고객요구 만족도 향상을 위한 품질보증활동 ⦿ 7가지 원리 (결완초집 살정오) - 결함 존재만을 증명 - 완벽한 테스트 불가 - 개발 초기 테스트 시작 - 결함은 집중되어 존재 - 살충제 패러독스 - 정황 의존적 - 오류 부재의 궤변
2
Q
소프트웨어 테스트 유형
A
- 정보획득 대상 : 화이트박스/블랙박스 테스트
- 실행여부 : 동적(화이트, 블랙), 정적(코드검사, 워크스루)
- 시각 : 검증, 확인
- 단계 : 단통시인설
- 목적 : 회안강성구
3
Q
Verification
A
⦿ 활동대상 : 제품생산 활동(과정) ⦿ 목적 : 올바르게 생산하는가 ⦿ 활동기간 : 각 단계별 ⦿ 관점 : Internal (개발자) ⦿ 테스트 유형 : Inspection, Walkthrough
4
Q
Validation
A
⦿ 활동대상 : 생산된 제품(결과) ⦿ 목적 : 제품이 올바른가 ⦿ 활동기간 : 시작 및 종료 단계 ⦿ 관점 : External (사용자) ⦿ 테스트 유형 : 단통시인설
5
Q
단계별 테스트 유형
A
- 단위 테스트 : 개별 모듈 확인
- 통합 테스트 : 빅뱅, 상향식, 하향식, 샌드위치
- 시스템 테스트 : 기능, 비기능
- 인수 테스트 : 알파, 베타, 감마
- 설치 테스트 : 상호 연동 확인
6
Q
단위 테스트
A
⦿ 정의 : 테스트 가능한 최소 단위 모듈을 기준으로 결함을 찾고, 기능을 검증하는 활동 ⦿ 분야 - 인터페이스 : 입출력 매개변수 - 자료구조 : 자료형태 - 실행경로 : 조건, 루프 - 오류처리 : 오류 메시지 ⦿ 절차 및 산출물 - 계획 : 단위 테스트 계획서 - 케이스 : Test Case/Oracle - 수행 : 뮤테이션, 탐색적 - 보고 : 결과/수정 보고서
7
Q
통합 테스트
A
⦿ 정의 : 최종 SW구성 시, 컴포넌트 및 인터페이스와 상호작용의 결함과 기능을 검증하는 활동 ⦿ 유형 - 하향식 : Test Stub 이용 - 상향식 : Test Driver 이용 - 샌드위치 : 모듈 최소 단위 부터 - 빅뱅 : 전체 시스템 한번에
8
Q
Test Driver
A
- Bottom Up
- 하위 모듈 구동
- Simulator
- 구현 어려움
- 초기 구조 파악 어려움
9
Q
Test Stub
A
- Top-Down
- 하위 모듈 대체
- SetDebug
- 구현용이
- 테스트 비교적 어려움
10
Q
시스템 테스트
A
⦿ 정의 : 사용자 요구사항 만족 여부를 기능 및 비기능 측면에서 테스트 ⦿ 목적 - 요구사항 부합 여부 확인 - 가용성과 안전성 보장 여부 확인 - 중/장기적 운영위한 사전검증 ⦿ 종류(회안강성구) - 회복 : 자가 회복 - 안전 : 불법 SW 방지 - 강도 : 과부하 - 성능 : 응답시간, 처리량, 속도 - 구조 : 내부 논리적 복잡도
11
Q
인수 테스트
A
⦿ 정의 : 기능/비기능 요구사항을 사용자가 직접 테스트, 개발 완료 증명 ⦿ 목적 : 확신, 배포 가능성, 준수성(납기, 표준), 고객 피드백 ⦿ 절차 - 준비 : 계획, 환경구축 (테스트 케이스/시나리오) - 수행 : 테스트 수행, 오류 수정(테스트 수행 계획서) - 평가 : 테스트 결과 요약, 검토, 승인 (테스트 결과 보고서) - 시스템 모니터링 : 자원 사용량, 성능 보안 (시스템 테스트 보고서) ⦿ 주요 인수 기준 - 기능성, 성능 - 보안성, 안전성 - 인터페이스 품질 - 소프트웨어 품질
12
Q
기능 테스팅
A
- ISO 9126 : 기능성
- 목적 : 원하는 기능
- 특징 : 기능 만족 필수
- 사례 : 로그인, 권한, 조회
- 종속성 : 개발자 실력
- 기법 : 단위 테스트, 통합 테스트
13
Q
비기능 테스팅
A
- ISO 9126 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성
- 목적 : 원하는 성능
- 특징 : 성능 만족 협의
- 사례 : 동접 100명 처리시 CPU 50%
- 종속성 : 솔루션, HW
- 기법 : 성능, 부하, 스트레스
14
Q
확인 테스트 (Confirmation)
A
⦿ 정의 : 수정 활동이 성공적이었는지를 확인하기 위하여, 마지막으로 실행했을 때의 실패한 테스트 케이스를 다시 실 행하는 테스트. 재테스팅(Re-Testing)
⦿ 대상 : 결함이 발견된 후 수정된 소프트웨어
⦿ 목적 : 수정활동이 성공적이었는지를 확인하기 위함
⦿ 범위와 정도 : 실제 결함이 발견된 부분에 대해서만 테스팅, 수행 횟수는 리스크 분석 정보를 기반으로 결정
⦿ 적용 : 모든 테스트 레벨에서 수행가능
⦿ 방법 : 기존 실패한 테스트 케이스를 다시 실행
15
Q
회귀 테스트 (Regression)
A
⦿ 정의 : 프로그램 수정으로 인해 숨어 있던 결함이 노출되지 않았는지, 또는 신규결함이 유입되지 않았는지 검증
⦿ 대상 : 변경된 소프트웨어 또는 관련이 있거나 전혀 관련이 없는 소프트웨어
⦿ 수행 : 소프트웨어 또는 실행환경이 변경되었을 때
⦿ 범위와 정도 : 이전에 정상동작했던 SW에서 결함을 발견하지 못해 야기될 수 있는 리스크에 바탕을 둠
⦿ 적용 : 모든 테스트 레벨에서 수행 가능
⦿ 방법 : 여러번 반복 수행되므로 자동화에 적합
⦿ 수행유형
- Retest All
- Selective Test
- Priority Test
16
Q
리스크 기반 테스팅에서 Test 수준 적용 사례
A
- STA(Severe) : Re-Testing 3회 / Full Regression Test
- STTA(STrong) : Re-Testing 2회 / Full Regression Test
- ITA(Intensive) : Re-Testing 1회 / Partial Regression Test
- FTA(Fundamental) : Re-Testing 1회
- 장애로인한영향(왼쪽)
- 장애발생가능성(아래)
17
Q
리뷰의 유형
A
- 비공식적 리뷰 : 페어 프로그래밍
- 기술적 리뷰 : 사전준비, 기술해결, 결함발견, 대안평가, 적합성 검토
- 워크쓰루 : 학습, 이해향상, 결함발견
- 인스팩션 : 훈련된 모더레이터, 사전준비, 결함발견, 개선활동수행
18
Q
Inspection
A
(형주진계관회해)
- 형태 : 공식 (Formal)
- 주최자 : 프로젝트 팀
- 진행 : 진행자 (Moderator)
- 계획성 : 역할기반, 계획적
- 관심사 : 결함발견
- 회의록 : 기록자에 의한 공식 회의록 운영
- 해결책 : 논하지 않음
19
Q
Walkthrough
A
- 형태 : 비공식 (Informal)
- 주최자 : 작성자 (코드, 문서)
- 진행 : 작성자 (Author)
- 계획성 : 비 계획적 미팅
- 관심사 : 결함발견 혹의 의견제안
- 회의록 : 작성자, 개발자의 메모성 기록
- 해결책 : 결함에 대해 의견 제안
20
Q
성능 테스트
A
⦿ 개념 - 병목지점파악/튜닝 - 용량산정/시스템용량계획 ⦿ 종류 1) 목적분류 - 단위 : 업무단위 - 복합 : 동시 사용자 및 가중치 - 임계 : 최대 성능 2) 방법분류 - 루프백 : 병목지점 도출 - 스파이크 : 트랜젝션 동시 실행 - 확장성 : 확장 계수 보장 여부 - 가용성 : HA, FT ⦿ 구성요소 - 조직 : 의뢰자, 관리자, 실행자, 인프라, 개발자 - 대상 : SW, 서버, 인프라 - 도구 : 자동화 도구, 부하 솔루션 - 스크립트 : Shell, Batch - 지표 : 전체/동시 사용자, 부하, 응답시간, 처리량 ⦿ 절차 - 계획 : 목표성능, 테스트계획 수립 - 설계 : Workload 설계, TestCase 도출, Process 수립, Script 생성 - 실행 : 수행, 모니터링 - 보고 : 종합결과보고, 평가보고서 작성 ⦿ 성능지표 1) CPU - MIPS (Millions of Instructions Per Second) - MFLOPS (Millions of Floating-Point Operations Per Second) 2) Network - PPS (Packets Per Seconds) - BPS (Bits Per Seconds) 3) HW Vendor - TPMC (Transaction Per Minute Concurrent : 동접자 + 분당처리수) 4) Main Frame C/S - TPS (Transaction Per Seconds)
21
Q
Little’s Law
A
⦿ 정의 : 공간 내에 머무는 객체 수는 객체의 공간 유입량과 객체가 머무는 시간에 비례 ⦿ 분석도 : TPS가 더 이상 증가하지 않고 완만하게 되는 시점이 그 시스템의 임계치 ⦿ Little's Law를 적용한 분석방법 - 운영서버의 임계치 분석 - 튜닝 포인트 분석 - 향후의 성능 위험 요소 분석 - 튜닝의 향상 효과 분석 ⦿ 성공적 테스트를 위한 고려사항 - 테스트 케이스 정의 - 테스트 계획 수립 - 테스트 조직 및 전문가 지원 - 제3자 테스트 수행
22
Q
성능테스트 목표를 정하기 위한 Workload Metric
A
⦿ 정의 : 작업량(Workload)에 대한 정량적인 수치로써, 사용자 수에 따라 결정되는, 대상 시스템에 대한 성능 기준선(Baseline) ⦿ 평가 항목 및 지표 - 시간당 처리건수(TPH) - 분당 최다 처리건수(TPM) - 초당 최대 처리건수(TPS, 60초) - 업무별 업무 가중치(비율%) - 최대동시 사용자 수(명) - 호출간격(초)
23
Q
TPS (Transaction Per Second)
A
⦿ 정의 : 사용자의 요청(Request)에 대한 초당 처리된 트랜잭션의 건 수
⦿ 상관관계
- TPS-사용자 : 비례관계
- TPS-응답시간 : 반비례관계
⦿ TPS 계산방법
- Concurrent User = TPS * (Response Time + Think Time)
- TPS = Concurrent User / Request interval
- Active User = TPS * (Response Time)
24
Q
성능 테스트 구성 용어
A
- Named User(전체 사용자) = Concurrent User + 비접속자
- Concurrent User(동시 사용자) = Active User + Inactive User
- Response Time(응답 시간) = Round Trip Time + Queuing Time + Process Time
- Think Time(사용대기 시간)
- Request Interval = Response Time + Think Time
25
Q
Loop Back Test
A
⦿ 정의 : 컴포넌트 성능시험 ⦿ 방법 : 소스코드에 Loop Back 코드 삽입 ⦿ 효과 : 아키텍처 측면 발전 방향 제시 ⦿ 테스트 구성 : WEB-WAS-TP-DB 구성 시스템 ⦿ 테스트 방법 - TP 호출하는 부분에 Loop Back Code 삽입 - WEB-WAS에 대한 성능 측정
26
Q
Tier Test
A
⦿ 정의 : Tier에 직접 부하 ⦿ 방법 : 각 Tier에 직접 부하 ⦿ 효과 : Tier 별 성능 측정, 병목 지점 개선 ⦿ 테스트 구성 : WEB-WAS-DB 구성 시스템 ⦿ 테스트 방법 - WAS에 직접 부하 발생, DB에 직접 부하 발생 - WAS나 DB가 병목 구간 인지 확인
27
Q
Spike Test
A
⦿ 정의 : 모든 사용자 일시 사용 ⦿ 방법 : 정해진 시간에 대량 트랜잭션 ⦿ 효과 : 시스템 리스소 변화량 검증 ⦿ 테스트 구성 : WEB-WAS-DB 구성 시스템 ⦿ 테스트 방법 - 1,000명 사용자가 1분 이내 로그인 완료 여부 - 시스템 사용량은 95% 허용
28
Q
테스트 도구
A
⦿ 테스트 자동화 도구의 분류 (SDLC) 1) 설계 - 명세기반 테스트 설계도구 - 코드기반 데트스 설계도구 - 테스트 관리 도구 2) 구현 - 정적분석 도구 - 리뷰 및 인스펙션 도구 - 커버리지 측정 도구 - 성능, 로드, 시뮬레이션 도구 - 테스트 수행도구 ⦿ 테스트 자동화 지원도구 유형 1) 테스트 관리 지원도구 - 테스트 관리 도구 - 인시던트 관리 도구 - 요구사항 관리 도구 - 형상관리 도구 2) 테스트 설계 지원도구 - 테스트 설계 도구 3) 정적 테스팅 지원도구 - 정적 분석 도구 4) 동적 테스팅 지원도구 - 단위 테스트 도구 - 테스트 실행 도구 - 성능 테스트 도구 - 커머리지 측정 도구 - 동적 분석 도구 - 모니터링 도구 - 보안 도구
29
Q
IEEE829
A
⦿ 테스트케이스 구성요소
- 식별자 : 추적성
- 테스트항목 : 테스트 대상
- 입력명세 : 입력값
- 출력명세 : 출력값
- 환경설정 : 테스트 베드
- 특수절차요구 : 프로세스
- 의존성기술 : 선/후관계
30
Q
테스트 케이스 작성절차
A
(계자위요구방정타유)
- 테스트 계획 검토
- 자료 확보
- 위험평가 및 우선순위 지정
- 테스트 요구사항 정의
- 테스트 케이스 구조설계
- 테스트 방법 결정
- 테스트 케이스 정의
- 테스트 케이스 타당성 확인
- 테스트 케이스 유지보수
31
Q
테스트 케이스의 요건
A
(정경반추적자자)
- 정확성
- 경제성
- 추적성
- 적합성
- 자립성
- 자정성
32
Q
테스트 오라클
A
⦿ 정의 : 테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 메커니즘 ⦿ 특징 : 객관적 평가 제공, 제한된 검증, 수학적 기법 ⦿ 유형 - 실제 오라클 : 모든 입력값 검증, 비용과다 - 샘플링 오라클 : 몇몇 입력값 검증, 특정값 만 검증 - 휴리스택 오라클: 샘플링 단점 극복 - 일관성 검사 오라클 : 수정전/수정후 실행 결과 비교
33
Q
Test Harness
A
⦿ 개념 : 테스트를 지원하는 목적하에 생성된 코드와 데이터의 집합 ⦿ 목적 : 테스트 프로세스의 자동화, 테스트 케이스의 실행, 테스트 결과 리포팅 작성 ⦿ 구성요소 - Test Driver : Bottom Up 접근 - Test Stub; Top Down 접근 - Test Suites : 테스트 케이스의 집합 - Test Case : 자동화된 명세서 - Mock Object : 비슷한 기능의 가상 객체 ⦿ 기대효과 - 생산성 증가 - 회귀 테스트 활용성 증가 - 품질 향상 - 어려운 조건속에 테스트 환경 제공
34
Q
명세 기반 기법
A
⦿ 종류
- 동등분할 기법
- 경계값 분석
- 결정 테이블 테스팅
- 상태전이 테스팅
- 유스케이스 테스팅
- 분류트리 기법
- 페어와이즈 조합 테스팅
- 직교배열 테스팅
35
Q
동등분할 기법
A
⦿ 정의 : 프로그램의 입력 도메인을 테스트케이스가 산출 될 수 있는 데이터의 클래스로 분류하는 방법 ⦿ 예제 - x값이 0~100사이, 시험사례 - (x100)으로 분할 ⦿ 특징 - 등가성 : 등가분할영역 확인 - 대표성 : 대표 입력값 적어도 한 개씩은 사용 보장 - 커버리지 : 특정 입력과 출력 커버리지 달성 - 재사용 : 다른 기법에서 입출력 데이터 사용가능 - 범용 : 모든 테스트 레벨에서 사용 가능
36
Q
경계값분석 기법
A
⦿ 정의 : 일반적으로 많은 오류가 경계 값에서 발생하므로, 결함방지를 위해 경계값을 포함하는 테스트 ⦿ 특징 - 경계값 : 최대/최소값 - 용이성 : 발견률 높고, 적용 쉬움 - 커버리지 : 동등분할의 확장 - 범용성 : 모든 테스트 레벨에 적용 ⦿ 경계값 분석의 한계 - 동작에 대한 조합 테스트 부적합 - 입력 조합이 상호간에 독립적이라는 가정에서만 적합
37
Q
결정 테이블 테스팅
A
⦿ 정의 : 조건과 행위의 모든 가능한 조합을 테스트하도록 설계하는 블랙박스 테스트 기법 ⦿ 특징 - 조건과 행위 : 누락없는 테스트 - 복잡한 로직의 정의, 분석, 테스트에 효과적 - 모든 프로세스 수행 동작을 점검 - 구현 또는 명세의 잠재적 오류 발견 - 테스트 전략에 따른 조건 추가 제거가 용이 ⦿ 구성요소 - 조건부(Condition) : 업무규칙 조건 - 행위부(Action) : 조건 조합 결과 ⦿ 장점 - 논리적 모든 조합 생성 가능 - 효과적인 논리적 모순 발견 - 불완전한 요구사항의 결함 발견 ⦿ 장점 - 작성에 많은 시간과 노력 필요 - 복잡한 시스템 적용시 논리적 실수 우려
38
Q
상태전이 테스팅
A
⦿ 정의 : 시스템의 현재상황, 이전 이력의 변화에 따른 내용을 테스트 ⦿ 특징 - 상태간 전이 표시 - 임베디드 소프트웨어 분야 ⦿ 다이어그램 - 상태 : 이벤드 대기 모드 (원) - 전이 : 다른 상태로 변경 (화살표) - 이벤트 : 유발요인 (화살표 이름) - 가드 : 이벤트 발생 조건 [조건/값] - 액션 : 전이에 따른 동작 (화살표 이름/값 표시) ⦿ 설계방식 - 전형적인 상태 - 모든 상태 - 특정 상태 전이 - 불가능한 상태 전이 ⦿ 목표 - 모델상의 결함 발견 - 구현상의 결함 발견
39
Q
유스케이스 테스팅
A
⦿ 정의 : 유스케이스를 사용하는 Actor사이의 상호작용의 결함을 찾는 테스트 기법 ⦿ 특징 - Use-case 검증 - 테스트 케이스 조기 작성 ⦿ 흐름종류 - 기본흐름 : 반드시 발생하는 흐름 - 대체흐름 : 조건, 상황, 추가 흐름 ⦿ 테스트 레벨에 따른 유스케이스 테스팅 방법 1) 컴포넌트 레벨 - 시나리오별 테스트 케이스 - 문장별 테스트 케이스 2) 시스템 레벨 - 활동기반 커버리지 - 전이기반 커버리지 - 경로기반 커버리지
