테스트 개요는 총 7장으로 이루어져 있다.
(7장 내 겹쳐진 내용이 많아 여기선 3장으로 요약하였다)
1. 테스트 개요
테스트 목적
- 결함 검출
- SW 품질 개선
- SW 품질 평가
- SW에 대한 의사 결정 지원 (품질 평가 결과 기반)
- 개발 프로세스 개선 지원 (개발 단계의 결함 분석하여 개선)
오류, 결함, 장애
- 오류
- 결함을 생기게 한 "개발자의 행위"
ex) 사용자의 요구사항을 잘못 이해, 오타, 문법 잘못 이해 등
- 결함을 생기게 한 "개발자의 행위"
- 결함
- 장애를 유발할 수 있는 문제
- 결함 때문에 장애 발생하지만 결함이 있다하여 반드시 장애가 발생하는 것은 아님
- 3가지 결함 종류
- 누락 : 요구사항(기능/성능/보안 등 품질 요소도 포함)에 대한 누락 ex) 요구사항이 구현되지 않음
- 부정확한 구현 : 요구사항이 부정확하게 반영
- 비관련 결함 : 요구사항과 무관한 구현
- 소스 코드 뿐만 아니라 개발 산출물에도 존재 ex) 설계 결함
- 장애 : SW 실제 동작과 요구사항에 (관찰 가능한) 차이가 있음
테스팅, 디버깅, 재테스팅
- 테스팅 : SW 실제 동작과 요구사항과의 차이를 확인. 외부
- 디버깅 : 테스팅을 통해 결함 확인 후 수행되고, 결함 위치를 파악하고 제거하는 행위. 내부 관련자가 수행
- 재테스팅 : 실제로 결함이 제거되었는지 초기와 동일한 TC를 통해 확인
테스트의 진화 과정
5개의 레벨로 나누어져 있음
- 레벨 1 : 테스트와 디버깅에 뚜렷한 차이 없어 우연히 발견된 결함 정도 수정
- 레벨 2 : SW가 올바르게 동작한다는 사실 입증을 위해 테스트 수행
- 레벨 3 : 결함이 있다는 것을 보여주기 위해 테스트 수행
- 레벨 4 : 코드 뿐만 아니라 SW 개발 전 단계에서 결함 발견 위해 평가
- 레벨 5 : 결함을 예방하고 테스트 용이하도록 SW 설계 (TDD)
테스트와 품질 평가
SW 품질을 평가(비기능 테스트)할 때 주로 보는 유형
기능 적합성 | 요구한 기능 만족시켰는지? |
성능 효율성 | 자원 사용이 적절했는지? 반응시간 괜찮은지? |
호환성 | 다른 SW 연동 능력 |
사용성 | 사용자가 SW 이해하기 쉬운지? 만족하는지? |
신뢰성 | 정해진 조건/기간 동안 오동작 없는지? |
보안성 | 데이터 안전한지? |
유지보수성 | 운영 용이한지? |
이식성 | 다양한 플랫폼에서 운영될 수 있는지? |
1. 기능 적합성
- 기능 완전성 : 모든 요구사항을 제공하는가? (명세 기반 테스트)
- 기능 정확성 : 정확한 결과를 제공하는가? (명세/구조 기반 테스트)
- 기능 적절성 : 기능이 목적 달성에 도움을 주었는가?
2. 성능 효율성 - 시간 반응성, 자원 효율성, 수용성(동시 사용자 수, 트랜잭션 처리량 등의 최대 한계가 충족하는가?)
- 성능 테스트 방법
- 벤치마크(Benchmark) 테스트 : 다른 SW과 성능을 비교/평가
- 부하 테스팅 : 부하를 계속 증가시쳐 임계점을 찾음
- 스트레스 테스팅 : 임계점 이상의 부하를 가하면서 기능/처리 등을 테스트
- 스파이크 테스팅 : 짧은 시간에 사용자가 몰릴 때 시스템 반응 테스트
- 내구성 테스팅 : 오랜 시간 동안 높은 부하를 가하여 반응 테스트
- 리틀의 법칙(Little's law) : SW에 오랜기간 있는 고객의 평균 수치 = 오랜 시간동안 걸친 평균 실제 도착률 * 시스템에서 고객이 머문 평균 시간
- 목표 처리량에 요구되는 동시 사용자 수를 산정할 때 사용
3. 호환성
- 공존성 : 다른 SW와 효율적으로 자원을 공유하면서 기능 수행하는가?
- 상호운영성 : 정보를 교환하고 교환된 정보를 사용할 수 있는지?
4. 사용성
- 적합 인식성 : 사용자가 필요한 시스템인지?
- 학습 용이성 : 배워서 쓸 수 있는지?
- 운영 용이성 : 시스템을 쉽게 조작할 수 있는지?
- 사용자 오류 방지성
- 사용자 인터페이스 심미성
- 접근성 : 사용자 특성이나 능력(연령, 장애 등) 관계없이 시스템 사용할 수 있는지?
- 사용성 테스트 방법 - 휴리스틱 평가(전문가가 체크리스트 통해 문제점 도출), FGI(그룹 인터뷰), 인지적 워크쓰루(교육없이 SW 사용하는 것 확인)
- 사용성 테스트는 시스템 개발의 전 주기에 걸쳐 진행되어야함
5. 신뢰성
- 성숙성 : 정상 작동 상태에서 신뢰성 충족시키는 정도
- 가용성 : 사용자가 시스템 사용하고자 할 때 사용 및 접근이 가능한 정도
- 결함 허용성 : 결함이 있어도 시스템이 의도대로 작동하는 정도
- 복구성 : 장애 나도 데이터 복구하고 상태를 재설정할 수 있는지?
- 신뢰성 테스트 방법 - 통계적 테스트(운영 프로파일 사용하여 TC 생성)
6. 보안성 - 기밀성, 무결성(데이터 변경/접근 방지), 부인 방지성, 책임성(사용자 행위 기록하여 추적), 인증성
- 보안성 테스트 방법 - 침입 테스트(해커 관점에서 취약성 찾기), 정적 분석
7. 유지보수성 - 모듈성, 재사용성, 분석성(결함 분석 등), 변경 용이성, 테스트 용이성
※ 테스트 용이성 - 제어 용이성, 관찰 가능성(내부상태 파악), 단순성, 분할 용이성, 운영용이성(결함있어도 테스트 가능하도록 설계), 안정성(테스트 동안 변경 자주 없도록 설계), 이해 용이성(설계 조직/쉽게 접근 가능하도록)
8. 이식성 - 적응성, 설치 용이성, 대체 용이성
테스트와 품질 보증
테스트 < V&V(Verification검증&Validation확인) < 품질 보증
더보기
※ V&V
- 검증 : 시스템이 명세를 만족하는지 검사 = 시스템을 올바르게 만들고 있니?
- 확인 : 시스템이 사용자의 요구사항을 만족하는지 검사 = 우리가 올바른 시스템을 만들고 있니?
테스트 기본 용어
- 테스트 대상 : 결함을 검출하려는 SW로 규모가 클수록 어려워 일부분 먼저 테스트 후 통합테스트 진행
- 피처 : 테스트 대상 중 테스트하고자 하는 측면 or 관점으로 이를 기준으로 TC 및 테스트 절차 개발
- 테스트 설계 기법
- 정적 테스트 : 실행 하지 않고 테스트 ex) 리뷰, 정적 분석
- 장점 : 실행환경 불필요, 산출물에 대한 테스트 가능, 소스 코드 작성 후 디버깅하는 것보다 경제적, 테스트 자동화 가능
- 동적 테스트 : SW 실행하여 테스트 ex) 명세 기반 방법, 구조 기반 방법, 경험 기반 테스트
- 장점 : 소스 코드가 없어도 테스트 가능
- 정적 테스트 : 실행 하지 않고 테스트 ex) 리뷰, 정적 분석
- 테스트 케이스 : 입력과 예상 결과의 묶음
- 테스트 절차 : 말 그대로 테스트 준비/실행/결과 관찰 및 기록하는 테스트 절차
- 테스트 환경 : 테스트 대상을 실행하는 모든 환경
ex) 외부 연동 시스템, 테스트 도구, 운영체제 포함한 시스템 SW, 공존하는 응용SW 등
2. 테스트 분류와 테스팅 방법
테스트 분류
테스트는 1 테스트 레벨, 2 테스트 유형, 3 테스트 설계 기법에 따라 분류 가능
- 테스트 레벨로 분류 - 컴포넌트(단위) 테스트, 통합테스트, 시스템 테스트, 인수 테스트
- 컴포넌트(단위)테스트 : 개별 단위 모듈을 독립적으로 테스트
- 모듈을 단독으로 실행할 수 있는 환경 필요 → 모듈을 테스트할 때 다른 연관되는 모듈은 스텁으로 이용
※ 테스트 베드 : 테스트 환경- 테스트 드라이버, 테스트 스텁
- Mock(모의) 객체 : 스텁의 객체지향 버전.
- 다른 레벨 테스트보다 쉽게 수행 + 결함을 쉽게 식별 + 테스트 수행에 따른 피드백 빠름
- 컴포넌트 테스트를 잘 수행하기 위한 FIRST 원칙
- Fast : 빠르게 수행되어야 함 (모의 객체 등을 이용하여 시간 단축)
- Isolated : 테스트가 다른 컴포넌트 테스트에 의존하지 않아야함
→ 전체 테스트 집합 실행해도 개별적으로 실행한 결과와 달라서는 안 됨 - Repeatable : 몇 번 실행해도 동일한 결과
- Self-Validating : 사람 개입 없이 테스트가 통과되었는지 알 수 있어야함
- Timely : 테스트는 코드가 작성되는 시점에 수행되어야함
- 모듈을 단독으로 실행할 수 있는 환경 필요 → 모듈을 테스트할 때 다른 연관되는 모듈은 스텁으로 이용
- 통합 테스트 : 모듈과 이들 간의 관계들(인터페이스) 테스트. 구조 설계 명세서 기반으로
- 통합테스트 방법
- 빅뱅 방식 : 통합해야할 컴포넌트가 많은 경우, 전체 컴포넌트를 한 번에 통합하여 테스트
- 점진적 방식 : 적은 수의 컴포넌트를 차례로 통합하여 테스트
- 상향식 통합 : 하위 컴포넌트 먼저 테스트하여 상위에 있는 컴포넌트들을 통합.
- 하향식 통합 : 상위 컴포넌트부터 시작하여 하위에 있는 컴포넌트 통합 (스텁 필요. 리그레이션 테스트 진행)
- 샌드위치 통합 : 상향식 + 하향식
- 2가지 목적
- 컴포넌트 간 연결의 정확성
- 연결된 두 컴포넌트의 기능적 측면 확인
- 통합테스트 방법
- 시스템 테스트 : 시스템이 명세에 따라 개발되었는지 전체 테스트. 요구사항 명세서 기반으로 기능 + 비기능 요구사항 모두 확인
- 인수 테스트 : 시스템 테스트와 동일하나 인수 테스트는 고객/사용자의 관점에서 SW가 동작하는지 확인. 보통 고객 또는 사용자가 테스트
- 알파 테스트 : 선별된 사용자가 개발자 환경에서 통제된 상태로 수행
- 베타 테스트 : 일정 수의 사용자에게 SW를 사용하게 하고 피드백 받음. 보통 개발자 참여 X
- 컴포넌트(단위)테스트 : 개별 단위 모듈을 독립적으로 테스트
- 테스트 유형으로 분류 - 기능 테스트, 비기능 테스트
- 기능 테스트 : 기능 측면 테스트. 모든 테스트(컴포넌트/통합/시스템/인수 테스트)에서 진행
- 비기능 테스트 : 품질 요구사항 측면 테스트. 보통 시스템/인수 테스트에서 진행
- 테스트 설계 기법으로 분류 - 정적 테스트, 동적 테스트
- 정적 테스트 : 실행하지 않고 테스트
- 리뷰 : 산출물에 존재하는 결함 검출 or 프로젝트 진행상황 점검. 보통 전문가 그룹이 수행
ex) 관리 리뷰, 기술 리뷰, 인스펙션, 워크 쓰루, 감사 - 정적 분석 : 산출물(주로 코드)의 구조적 속성을 이용하여 자동화된 방식으로 수행
- 리뷰 : 산출물에 존재하는 결함 검출 or 프로젝트 진행상황 점검. 보통 전문가 그룹이 수행
- 동적 테스트 : 실행하여 테스트
- 명세 기반 테스트 : 코드를 참고하지 않고 명세를 통해 TC 결정. 명세 정보가 있는 전 단계에서 사용
- 구조 기반 테스트 : 코드 참고하여 TC 결정
- 경험 기반 테스트 : 경험 바탕으로 테스트 ex) 오류 추정, 탐색적 테스트 등
- 정적 테스트 : 실행하지 않고 테스트
테스팅 방법
대표적인 테스트 수행 방법
- 리그레션 테스트 : SW 변경 후에 수행되는 테스트로 변경이 결함을 만들었는지 요구사항 충족하는지 검증
- 개발 단계에서 사용된 TC 그대로 이용
- 컴포넌트 테스트, 통합 테스트, 시스템 테스트, 유지보수 등 모든 단계에서 수행
- 리그레션 테스트 방법
- Retest-All : 기존에 개발된 모든 TC 사용. but 너무 많은 시간 자원 필요
- 선택석 리그레션 테스트 : 결과가 다르게 나올 수 있는 TC만 일부만 선정하여 테스트
- 테스트 최소화 : 커버리지 통해 중복된 TC 제거하여 테스트 수를 줄이기
- 테스트 우선순위화 : ADFD 방식을 사용하여 TC에 우선순위를 두어 높은 것만 활용
※ ADFD 방식 = 테스트 케이스 실행 수 대비 검출된 결함의 비율
테스트 케이스 수, 결함 수, 실행 순서로 계산
- 소프트웨어 생명 주기 모델과 테스트
- 순차적 개발 모델 : 요구사항이 초반에 완전하게 정의되어있을 때 사용
- 폭포수 모델
- 가장 오래된 전통적인 모형
- 요구사항 분석 → 구조 설계 → 상세 설계 → 코딩 → 테스팅 → 운영
- 장점 : 개발 과정 후 테스트를 하기 때문에 테스트 작업에 필요한 정보 쉽게 얻음.
- 단점 : 전체 프로젝트의 비용 및 일정에 심각한 영향 (개발 중심 모델 : 테스트를 코딩 이후의 한 단계로만 생각)
- V-모델
- V = V&V
- 폭포수와 달리 테스트를 개발과 동등하게 취급 → 테스트 계획 및 설계는 개발 시작됨과 동시에 시작
- 개발 단계별 테스트 유형이 대응하여 정의
(요구사항 ↔ 인수 테스트, 요구사항 분석 ↔ 시스템 테스트, 구조설계 ↔ 통합 테스트, 상세설계 ↔ 단위 테스트)
- 폭포수 모델
- 진화적 개발 모델 : 요구사항이 명확하지 않을 때 적용
- 핵심 부분을 우선 개발 후, 추가 요구사항을 여러 이터레이션(Iteration)을 통해 개선 및 발전
- 각 이터레이션마다 테스트 수행 계획 작성하여 수행
- 나선형 모델 : 기술적으로 어렵거나 고객이 중요하게 생각하는 요구사항에 대해 우선 프로토타입 개발하고, 프로토타입에 대한 테스트 및 사용자의 평가를 거쳐 개발 주기 시작
- 애자일 개발 모델 ex) XP, TDD
- 순차적 개발 모델 : 요구사항이 초반에 완전하게 정의되어있을 때 사용
- 위험 기반 테스트 : 위험 수준이 높은 것들 우선 테스트
- 위험 분석
- 테스트가 필요한 피처들을 모두 나열하고 명확하고 구체적으로 기술
- 발생 가능성, 심각성, 긴급성(자주쓰는기능?) 바탕으로 위험도 산정
- 위험도 = 장애가 발생할 가능성 * 영향도 - 피처 별로 테스트 강도 선택하여 테스트에 투입할 자원 비용 등을 결정
- 고강도 테스트 > 균형적 테스트 > 부가적 테스트 > 결험 보고(가장 낮은 등급. 보통 테스트 범위 X) - 테스트 레벨/유형 결정 (보통 고강도는 테스트 레벨 전체. 피처에 따라 기능/비기능 나눠짐)
- 테스트 대상 선정
- 테스트 범위 설정
- 테스트 전략 결정 : 위험 강도에 따라 테스트 설계 기법, 종료 기준, 재테스팅 및 리그레션 테스팅 여부 또는 방법 결정
- 테스트 설계/구현 및 테스트 환경 : 위험 수준에 따라 테스트 환경 구축하고 TC 설정
- 테스트 실행 및 결함 보고 : 위험 수준이 높은 테스트에서의 결함은 우선순위로 보고하여 재테스팅 수행
- 테스트 모니터링/제어 및 테스트 종료 : 위험 수준 높은 테스트는 상세하게 모니터링 수행하고 별도로 결과 보고 정리
- 위험 관리 : 잠재 위험이 문제로 발현되기 전 대응책을 생각해 내는 과정
- 위험 분석
- 모델 기반 테스트 : 모델(UML, 자연어, 순서도 등) 기반으로 자동으로 TC 생성
3. 테스트 자동화
테스트 자동화
- 도구를 사용하여 테스트 프로세스 일부 또는 전부를 자동화
- 자동화를 위해 상당한 초기 투자 비용 발생
테스트 자동화 분야 및 테스트 도구
- 테스트 설계 도구 : TC 생성 도구
- 명세 기반 테스트 설계 도구 : 명세서 기반으로 TC 생성
- 구조 기반 테스트 설계 도구 : 코드 기반으로 TC 생성
- 테스트 환경 구축 도구
- 테스트 실행 도구
- 이슈 관리 도구 ex) Jira
테스트 도구 선정
- 요구사항 정의 → 도구 조사 → 도구 평가 → 파일럿 프로젝트 → 도구 선정 → 도구 도입
반응형
'💻 개발IT > 기타' 카테고리의 다른 글
느슨해진 1인개발자에 동기 부여/정보를 주는 사이트 모음 (2) | 2024.01.26 |
---|---|
[RevenueCat] There is an issue with your configuration (0) | 2023.09.20 |
CSTS 요약 3 - 테스트 프로세스 (0) | 2023.06.13 |
CSTS 요약 2 - 테스트 설계 기법 (0) | 2023.06.12 |
[gitlab-ci.yaml] config contains unknown keys: rules (0) | 2023.03.21 |
[Python] 위키피디아(한국어) 데이터 가져오기 (1) | 2023.02.08 |
[FastText] 단어 유사도 구현하기 (0) | 2023.02.07 |
[Word2Vec] 단어 유사도 구현하기 (0) | 2023.02.01 |