1. 소프트웨어 테스팅 목적
소프트웨어에 문제가 생기면?
소프트웨어가 오작동이 발생할 위험을 줄여야 한다.
위험: (발생 확률) x (발생했을 때 끼치는 손실)
소프트웨어 테스팅은 위험에서 발생 확률을 줄이는 작업
테스팅 목적
1. 결함 발견
2. 품질과 잔존 위험(residual risk)에 대한 정보 제공
➕ 결함이 왜 소프트웨어로 유입됐는지 원인을 찾음으로써 소프트웨어 개발 프로세스를 개선시킬 수도 있는 정보를 제공하기도 함
2. 동적 테스팅과 정적 테스팅
1. 정적 테스팅
- 프로그램 실행을 하지 않고 프로그램 코드나 산출물(문서) 결함을 찾는 활동
- IEEE 1024(리뷰)
- 관리 리뷰(Management Review)
- 기술 리뷰(Technical Review)
- 인스펙션(Inspection)
- 워크쓰루(Walk-through)
- 감사(Audit)
2. 동적 테스팅
- 컴퓨터 결함을 발견할 의도로 프로그램이나 시스템을 실행하는 과정(Meyers)
3. 동적 테스팅 프로세스
3.1 테스트 케이스
- 주요 구성 요소로 입력과 기대 결과가 있음
- 우선순위: 시간이 없을 때 높은 우선순위의 테스트 케이스만 수행
- 추적성: 테스트되지 않은 요구사항이 있는지 확인하고, 요구사항이 변경될 때 해당 테스트 케이스도 변경됨, 어떠한 요구사항을 테스트하기 위한 것일지 확인
- 사전 조건이 만족되지 않으면 테스트 케이스 수행 x
- 기대 결과대로 실행 결과가 나오지 않으면 프로그램에 문제가 있을 수 있음
3.2 테스트 환경
- 테스트 케이스를 수행하기 위해 필요한 운영체제, 하드웨어, DB 서버 등의 도구
3.3 테스트 아이템
- 테스트 대상이 되는 것
3.4 테스트 오라클
- 생성 기능: 각 테스트에 대해 예상 또는 기대되는 결과를 생성하여 제공하는 기능(기대 결과를 생성)
- 평가 기능: 예상 또는 기대 결과와 실제로 프로그램을 실행하여 얻어진 결과를 비교하여 테스트가 통과되었는지를 판단하는 기능(test가 통과되는지 안되는지 확인)
ISTQB에서는 테스트를 넘어 소프트웨어의 실제 결과와 기대 결과를 비교하기 위해 사용하는 정보의 원천이라고 함
테스트 오라클에는 사용자 메뉴얼, 전문가의 지식, 유사한 타 시스템, 다른 소프트웨어가 속하지만 프로그램 실행 결과는 속하지 않는다고 봄
4. 소프트웨어 테스팅 용어
4.1 Error
- 부정확한 결과를 야기하는 개발자의 행위
- 사용자의 요구 사항을 잘못 파악하거나 typo나 프로그래밍 언어의 문법을 잘못 이해하여 코딩하는 경우에 발생
4.2 Fault(결함)
- 프로그램의 기능을 제대로 수행하지 못하게 하는 프로그램의 흠
- 잘못된 정보를 반영하는 경우(commission): 안 해야할 일을 하는 경우
- 올바른 정보를 빠뜨리는 경우(omission): 해야할 일을 안 하는 경우
- 잘못된 프로그램 경로를 수행하도록 하는 제어 흐름과 관련된 결함이나 대상이 되는 프로그램의 외부와 통신과 관련된 인터페이스 결함 및 잘못된 자료 구조의 사용으로 인한 결함(알고리즘 결함): 할일을 올바르지 않게 하는 경우
- 프로그램 코드에서 문제를 일으키는 정적인 부분
- error로 인해 발생
4.3 Failure(오작동)
- 프로그램의 실행 결과와 기대 결과와의 (관찰 가능한) 차이를 말함
- 실행 결과와 기대 결과가 동일하지 않을 경우에 오작동 발생
- 프로그램이 명세와는 다르게 동작하는 것이 외부에서 관찰되는 상황
- 오작동은 결함에 의해서 발생되지만 fault가 있다고 해서 반드시 failure를 발생하는 건 아님
- fault가 있으면 오작동을 유도하는 테스트 케이스를 설계하는 것이 좋다.
5. 완전한 테스팅
완전한 테스트(Exhaustive Test): 완전하게 테스트한다는 의미는 모든 입력 조건 조합에 대하여 테스트한다는 의미
입력 인자가 늘어난다면 개수가 기하급수적으로 늘어나 모든 가능한 완전한 테스트는 실제로 불가능함
-> 모든 가능한 입력 값에 대해 완전한 테스트하는 건 가능하지 않음, 그 중에 일부분만 사용해서 테스트하는 수밖에 없음, testing은 일종의 sampling
6. 테스팅 한계
- 테스트는 오류가 없음을 보여주지 않는다.
- 테스트의 완료 기준
-> 이 기준을 만족하면 프로그램의 신뢰성을 어느 정도 보장해줌
설령, 프로그램에 검출이 안 된 결함이 있을지라도 더 이상 테스트는 수행하지 않을 것임(만족하면 다음 개발 단계로 넘어감)
7. 커버리지 분석
- 테스팅이 얼마나 충분하게 이루어졌는지를 분석(테스트 케이스가 원하는 만큼 충분하게 만들어졌는지)
- 테스트 커버리지 아이템: 테스트 아이템에 포함되거나 실행될 필요가 있는 명세나 프로그램에 있는 항목
ex) 구조 기반 테스팅에서 문장 테스팅(statement testing)은 테스트 커버리지 아이템이 프로그램을 구성하는 문장(statement)임 - 커버리지 계산
커버리지(%) = 테스트 케이스에 의해 실행된 테스트 커버리지 아이템의 수/전체 테스트 커버리지 아이템의 수 - 테스트 완료 기준으로 사용(완전한 테스팅이 불가능하므로 언제까지 테스팅을 수행할 것인지 커버리지 값으로 테스트 완료 기준을 사용함)
8. 테스트 케이스 설계 방법
테스트 케이스는 어떻게?
- 누락된 요구사항 검출: 요구사항 명세서를 요구사항을 추가한 후에 실행이 되지 않은 부분을 실행할 수 있는 테스트 케이스를 추가
- 누락된 테스트 케이스 검출: 실행되지 않은 부분을 실행할 수 있는 테스트 케이스를 추가
- 의도하지 않은 기능 검출: 프로그램에서 제거
- 데드(dead) 코드 검출: 프로그램에서 제거
- 활성화되지 않은 코드(deactivate code) 검출: 현 시스템에서는 사용되지 않으나 특정 상황에서는 필요한 코드임을 보이는 증명 필요
[ISO29119] 소프트웨어 (동적) 테스트 방법 분류
테스트 케이스를 설계할 때 어떠한 정보를 바탕으로 테스트 케이스를 설계하는지 분류
1. 명세 기반 테스팅(Specification-Based Techniques)
- 출력 인터페이스 정보나 명세 정보를 이용하여 테스트 케이스를 설계
- 의도한대로 프로그램이 동작하는지 체크
- 블랙박스 테스팅
- 테스트 베이시스(test basis): 테스트 케이스를 만드는 데 사용되는 정보
- 명세 기반 테스트 케이스: 요구사항 명세, 상태전이도, 유스케이스 다이어그램, 액티비티 다이어그램과 같은 다양한 명세 형태(=테스트 베이시스)로부터 테스트 케이스 추출
- 요구사항에 해당하는 로직이 구현되어 있지 않다면 요구사항으로부터 추출된 테스트 케이스로 누락 결함(omission)을 검출할 수 있는데, 명세 기반 테스팅이 효과적임
2. 구조 기반 테스팅(Structure-Based Techniques)
- 프로그램 코드 로직 정보를 이용하여 테스트 케이스 설계
- 프로그램 로직으로부터 테스트 케이스를 만들어내기 때문에 의도한 기능을 올바르게 만들었는지 체크
- 화이트박스 테스팅
- 테스트 베이시스가 프로그램 코드
- 프로그램 코드로부터 테스트 케이스들을 추출하여 해당 로직이 올바르게 동작되는지 검증 -> 로직에 해당하는 요구사항이 없다면 이 코드로부터 추출된 테스트 케이스로 의도되지 않은 로직(commission)이 있음을 검출활 수 있음
3. 경험 기반 테스팅(Experience-Based Techniques)
- 테스터의 경험이나 지식 및 직관을 기반으로 테스트 케이스를 설계하는 방법
- 오류 추정(error guessing)은 대표적인 경험 기반 테스트 설계 기술
- 오류 추정은 과거의 유사한 프로그램을 테스트했던 경험이나 테스터의 직관을 바탕으로 일반적으로 발생할 수 있는 오작동의 원인이나 문제가 될 만한 영역 등을 추정하여 테스트 케이스를 설계하는 방법
- 오류 추정은 테스트 케이스를 설계하는 특별한 규칙이나 가이드라인이 없으며 독단적으로 사용되기 보다는 명세 기반 테스트 테스팅 등에 의해 검출되는 오류 유형들을 보완하기 위해 사용
