Index
1. 소프트웨어 테스트 개요
1.1. 소프트웨어 테스트
•
소프트웨어 품질 보증을 위한 활동
•
V&V 활동 중 하나
•
프로그램을 실행시켜 요구사항 만족을 보이거나 결함을 찾기 위한 행동
•
성공적인 테스트란 발견되지 못했던 결함을 찾는 테스트
1.2. 결함 테스트와 검증 테스트
•
결함 테스트
◦
소규모 코드에서 결함을 찾고자 하는 것
◦
부정학한 계산이나 데이터 오류 등이 발생하는지 확인
◦
좁은 의미에서 테스트
•
검증 테스트
◦
주요 시스템의 기능을 검증하기 위한 것
◦
주어진 요구 명세의 만족을 보이는 인수 테스트와 같은 고수준 테스트
1.3. 소프트웨어 테스트 프로세스
•
프로세스
1.4. 테스트 작업의 고려사항과 우선 순위
•
고려 사항
◦
가능한 테스트 케이스 중 일부만 실행 (모든 테스트 데이터 테스트 현실적 불가능)
◦
어느 수준까지 테스트 할 것인가?
•
테스트 작업의 우선 순위
◦
전체 시스템 > 모듈 하나
◦
기존 기능 > 새 기능
◦
일반적인 상황 > 예외적인 상황
2. 단계별 테스트
2.1. 단위 테스트
•
시스템을 구성하는 기본 단위를 테스트
•
다른 모듈과 통합되기 전에 수행
•
드라이버와 스텁을 사용
◦
드라이버 - 테스트되는 모듈을 호출하여 결과 검증
◦
스텁 - 테스트 되는 모듈에 의해 호출되는 모듈
2.2. 통합 테스트
•
테스트 된 개별 모듈들을 통합하여 상호작용으로 인한 문제가 있는지 테스트
◦
주로 상호작용에서 생기는 결함 발견을 위해
◦
모듈간의 인터페이스 검사 목적으로 개발
•
프로그램을 구축해가는 기술 → 최종적으로 시스템이 구축됨
•
주로 블랙박스 테스트 기법 사용
2.3. 시스템 통합 방식
•
빅뱅 통합
◦
모듈들을 모두 개발한 후 한꺼번에 통합
•
점증적 통합
◦
모듈을 하나씩 추가하여 통합한 후 테스트 진행
•
하향식 통합
◦
점증적 통합 방식
◦
제어 계층 구조 상에서 최상위 모듈부터 시작하여 아래 모듈들을 차례로 통합
◦
통합되어 테스트되는 모듈들의 하위 모듈에 대한 스텁이 필요함
◦
깊이 우선 방식 / 너비 우선 방식
◦
장단점
▪
초기에 소프트웨어 구조가 갖추어지고 개발자에게 심리적 안정감 제공
▪
병행 통합 작업이 어렵고 입출력 모듈이 하위에 위치하므로 테스트 작업이 어려움
깊이 우선 방식
•
상향식 통합
◦
프로그램 구조에서 최하위 모듈들을 먼저 만들어 테스트 하고 상위 수준으로 올라가며 통합과 테스트
◦
하위 모듈들을 통합하다보면 클러스터를 형성
◦
통합 되는 모듈 제어를 위해 드라이버 필요
◦
장단점
▪
초기 단계에서 병행 작업 가능. 대규모 시스템 통합에 적당
▪
골격을 갖추는데 오랜 시간 걸림
▪
같은 수준의 모듈들이 준비되어야 테스트 가능
•
샌드위치 테스트
◦
상향식과 하향식을 조합한 방식
•
cf) 회기 테스트
◦
프로그램 수정할 때, 수정으로 인한 오류의 발생 여부를 밝히기 위해 테스트 방법
◦
이전 단계에서 사용한 테스트케이스 집합을 재사용 가능
◦
수정된 부분과 수정에 의한 파급 효과를 분석하여 선택적으로 재사용하는 것이 필요함
2.4. 시스템 테스트
•
완전한 시스템 구축 이후, 기능적/비기능적 요구사항 만족 및 검증 테스트
◦
사용자 전달되는 시스템 버전 테스트
◦
요구사항 명세 기초한 블랙박스 텟트
◦
성능, 신뢰도 테스트
•
릴리즈 테스트라고 하며, 테스트 작업에 고객이 포함되면 인수테스트 라고 함
3. 화이트박스 테스트
3.1. 화이트박스 테스트
•
프로그램의 논리 구조에 바탕으로 한 테스트
•
소스코드를 분석하여 테스트 케이스 개발
•
프로그램 제어 흐름 그래프에서 경로를 분석하여 테스트 개발
•
소규모 프로그램에 적용
•
자동화된 테스트 도구로 사용할 수 있음
3.2. 테스트케이스 선정 기준
•
코드 커버리지
◦
효과적인 테스트 케이스 집합을 구하는 기준
◦
적정 수의 테스트 경로 실행 필요
•
코드 커버리지 종류
◦
문장 검증 기준 (SC)
▪
프로그램의 모든 문장을 한번 이상 실행
◦
분기 검증 기준 (DC)
▪
모든 제어 분기점에서 참과 거짓에 해당하는 경로를 각각 한번 이상 실행
◦
조건 검증 기준 (CC)
▪
모든 분긱점에서 조건식을 구성하는 단일 조건의 참과 거짓을 각각 한번 이상 실행
▪
분기 검증 조건의 불만족 문제
◦
조건/분기 검증 기준 (CDC)
▪
조건 & 분기 검증 기준을 모두 만족해야 함
▪
short-circuiting의 문제
•
첫번째 조건 실패하면 뒤에 조건 확인 안함
◦
수정된 조건/분기 검증 기준 (MCDC)
◦
복수 조건 검증 기준(MCC)
▪
저건식을 구성하는 단일 조건식들의 모든 가능한 참/거짓 조합을 각각 한번 이상 실행
◦
경로 검증 기준
▪
프로그램에 존재하는 모든 실행 가능한 경로를 한번 이상 테스트
•
cf) 기본 경로 테스트
◦
시작 노드에서 종료 노드까지의 선형 독립적인 경로를 모두 테스트
◦
메케이브의 사이클로매틱 수는 기본 경로의 개수와 일치함
◦
예) 그림에서 기본경로는 (1,9), (1,2,3,8,1,9), (1,2,4,5,7,8,1,9), (1,2,4,6,7,8,1,9). 이 경로를 실행시키는 테스트 집합을 구함
4. 블랙박스 테스트
4.1. 블랙박스 테스트
•
명세서를 기초하여 기능 검사
•
프로그램의 구조를 고려하지 않음
•
기능 테스트 / 행위 테스트
•
기능적 요구사항을 검사 할 수 있고, 오류를 일으킬 가능성이 높은 입력 조거 파악
•
장점
◦
코드 분석 X → 개발자에 독립적인 테스트
◦
사용자 관점의 테스트
◦
요구 명세서만 작성되면 테스트 케이스 설계 가능
4.2. 블랙박스 테스트 방법
•
완전 테스트
•
랜덤 테스트
•
동치 분할
◦
입력 집합을 몇개의 동치 클래스로 나누어 테스트
◦
요구사항에 기초하여 분할을 만들고 각 분할에서 대표 값 선정
•
경계값 분석
◦
동치 분할 방법의 변형
◦
경계값과 경계값의 직전/직후 값을 가지고 테스트
◦
경계값 주변에 오류의 가능성이 높다는 점을 가정한 방법
•
원인-결과 그래프
◦
명세서를 분석하여 원인에 해당하는 입력 조건과 그것이 출력 결과를 논리적으로 연결한 그래프 작성
◦
의사 결정 테이블로 바꾼후 테스트 케이스 개발
5. 비기능성 테스트
5.1. 비기능성 테스트와 성능 테스트
•
비기능성 테스트
◦
기능적 요구사항 이외의 것을 테스트하는 것
◦
신뢰성, 성능, 안전성, 빠른복구, 사용편의성, 확장성 등 확인 위함
•
성능 테스트
◦
실제 운영 중 성능 수준을 보장할 수 있는지 테스트
◦
평균 응답 시간, 시간당 처리율, 피크시간 성능 검사
◦
테스트 작업을 장기적 연속적으로 수행
◦
트랜잭션의 유형별 비중을 고려하여 테스트 케이스 작성
5.2. 부하 테스트
•
성능 테스트의 일종
•
비정상적인 높은 부하를 주고 관찰하여 잘못된 점 발견 (스트레스 테스트)
◦
시스템의 설계 한도를 벗어난 요구 테스트
◦
네트워크 과부하로 인한 성능 저하 우려 분산 시스템 테스트
•
고려 사항
◦
스트레스 테스트를 통해서 정상적인 상황에서 드러나지 않았던 결함 발견 가능
◦
시스템에 부하가 걸릴 때도 심각한 고장이 발생하지 않아야 함
5.3. 보안 테스트
•
시스템 보호를 위해 보안성 테스트
•
기밀 유지, 무결성, 가용성 보장 위함
•
고의적 침입 시도, 지속적인 서비스 요청을통해 다른 서용자 서비스 방해 행위 (DDOS) 등으로 테스트 진행