집중 암기
소프트웨어 테스트 (정적 테스트, 동적 테스트)
정적테스트 종류
동적테스트 종류
소프트웨어 테스트의 기본 7원칙
- 테스팅은 결함이 존재함을 밝히는 활동이다
→ 테스팅은 소프트웨어의 잠재적인 결함을 줄일 수 있지만,
결함이 발견되지 않아도 결함이 없다고 증명할 수 없음을 나타낸다
- 완벽한 테스팅은 불가능하다
→ 무한 경로, 무한 입력값, 무한 시간이 소요되어 완벽하게 테스트할 수 없다
→ 리스크 분석과 우선순위를 토대로 테스트에 집중할 것을 의미
- 테스팅은 개발 초기에 시작해야 한다
→ 애플리케이션의 개발 단계에 테스트를 계획
→ SDLC(Software Development Life Cycle)의 각 단계에 맞춰 전략적으로 접근하는 것을 고려
- 결함 집중(Defect Clustering)
→ 애플리케이션 결함의 대부분은 소수의 특정한 모듈에 집중되어 존재한다는 의미
→ 파레토 법칙 : 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상
(롱테일 법칙 : 주목받지 못하는 다수가 핵심적인 소수보다 더 큰 가치를 창출하는 현상)
- 살충제 패러독스(Pesticide Paradox)
→ 동일한 테스트 케이스로 반복 실행하면 결함을 발견할 수 없다
→ 주기적으로 테스트 케이스를 리뷰하고 개선해야 한다
- 테스팅은 정황(Context)에 의존한다
→ 정황과 비지니스 도메인에 따라 테스트를 다르게 수행하여야 한다
- 오류--부재의 궤변 (Absence of Errors Fallacy)
→ 사용자의 요구사항을 만족하지 못하면 오류를 발견하고 그 오류를 제거하였다 해도 품질이 높다고 말할 수 없다.
→ 사용자 요구와 기대에 만족하지 못해 사용성이 현저히 낮다면 결함을 찾는 과정은 아무 소용이 없다는 의미
소프트웨어 테스트
* 정적 테스트 & 동적 테스트
- 정적 테스트
→ 프로그램을 직접 실행하지 않고 분석을 하는 테스트 기법 (소스코드, 명세서 등으로 분석)
- 동적 테스트
→ 테스트 프로그램을 실행하여 결과를 분석하는 테스트 기법
소프트웨어 테스트 [정적 테스트]
* 정리
- Inspection
→ 공식적 검사
→ 프로그램을 실행하지 않고 산출물을 대상으로 공식적 검토, 결함 발견 과정
→ 구성: 이해 관계자, 중재자, 검토자, 기록자
- Peer Review
→ 동료 검토
→ 프로젝트 수행과정에서 각 단계 별 산출물, 제품에 대해 동료들이 상호교차하여 검토 수행 활동
→ 구성: 프로젝트 팀원, 체크리스트
- WalkThrough
→ 비공식 검토
→ 프로젝트 개발 초기에 팀 내에서 수행하는 검토 과정
→ 구성: 프로젝트 팀원
소프트웨어 테스트 - 동적 테스트
* 정리
→ IT 위키 참고
https://itwiki.kr/w/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%20%ED%85%8C%EC%8A%A4%ED%8A%B8
* 소스 코드 열람에 따른 구분
- 블랙박스 테스트 (사용자 관점)
※ 프로그램 외부명세(기능, I/F)로부터 직접 테스트 (Data, I/O 위주 테스트)
→ 동치 분할 테스트 (Equivalence Partitioning Test)
프로그램의 입력 데이터를 여러 분류로 나누어 검사
→ 경계값 분석 (Boundary Value Analysis)
입력값의 경계값을 중심으로 예외 발생 검사
→ 원인-효과 그래프 기법 (Cause-effect Graphing)
입력데이터 간의 관계, 출력에 미치는 영향의 분석 그래프 이용
→ 오류 예측 검사 (Fault Based Testing)
테스터의 감각이나 경험, 지식을 통해 에러케이스를 예측
→ 비교 검사 (Comparison Testing)
테스트 대상과 비교 대상 프로그램에 같은 입력값을 넣어 데이터를 비교
- 화이트박스 테스트 (개발자 관점)
※ 프로그램 내부 로직을 참조하면서 모든 경로를 테스트
→ 기초 경로 검사(Basic Path Testing)
수행 가능한 모든 경로 검사
→ 조건 검사(Condition Testing)
프로그램의 조건문에 초점을 맞추어 검사
→ 루프 검사(Loop Testing)
프로그램의 반복 구조에 초점을 맞추어 검사
→ 데이터 흐름 검사(Data Flow Testing)
프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞추어 검사
* 설계 기법에 따른 분류
- 명세 기반 테스트
※ 모델들을 통해 시스템적으로 테스트케이스를 도출할 수 있다
커버리지를 측정할 수 있으나 구조 기반 테스트의 커버리지 보다 제한적이다
→ 동치 분할
→ 경계값 분석
→ 결정 테이블 테스트
→ 상태 전이 모델
→ 유즈케이스 테스트
- 구조 기반 테스트
※ 구문(Statement), 결정(Decision), 분기문(Branch)과 같은 구조에 기반
정량화된 테스트 커버리지를 측정, 테스트 커버리지를 높이는 방향으로, 테스트 케이스를 시스템적으로 도출 가능
→ 제어흐름 테스트
→ 자료흐름 테스트
- 경험 기반 테스트
※ 테스트 관련 인력의 지식이나 경험으로 테스트 케이스를 도출한다
→ 탐색적 테스트
https://itwiki.kr/w/%ED%83%90%EC%83%89%EC%A0%81_%ED%85%8C%EC%8A%A4%ED%8C%85
→ 애드혹 테스트
테스트 커버리지
'자격 > 정보처리기사' 카테고리의 다른 글
| [정보처리기사][실기] 개인적인 정리 (소프트웨어 개발 보안) (0) | 2022.07.23 |
|---|---|
| [정보처리기사][실기] 개인적인 정리 (암호화 알고리즘) (0) | 2022.07.23 |
| [정보처리기사][실기] 개인적인 정리 (디자인패턴) (0) | 2022.07.23 |
| [정보처리기사][실기] 개인적인 정리 (결합도, 응집도) (0) | 2022.07.23 |
| [정보처리기사][실기] 개인적인 정리 (UML 다이어그램) (0) | 2022.07.23 |
