소프트웨어 테스트는 개발된 소프트웨어가 의도된 대로 잘 실행되는지
품질 관점의 정보를 캐내기 위하야 시험하는 작업이다.
테스트의 목표는 시스템에 존재하는 결함을 조사하고 문제점을 드러내는 것이다.
테스트는 전체 개발 프로세스 중 가장 큰 노력이 들어가는 단계이다 !
전체 프로젝트 시간의 50%, 전체 예산의 50% 이상을 소비하는 매우 중요한 단계이다.
테스트 작업은 소프트웨어에 테스트 케이스를 주어 실행시킨 후 시스템의 동작이 예상한 대로 실행되는지 확인하는 것.
테스트도 오류가 있을 수 있을까?
오류가 있는데 테스트 단계에서 찾아내지 못했다면, 그게 오류다.
그렇다면 어떻게 해야 오류를 잘 검출해낼 수 있을까?
테스트의 성패는 테스트 케이스에 달려 있다.
-> 테스트 케이스를 어떻게 선택해야 하는지에 대해 알아볼 것임!
테스트는 두 가지 접근 방식을 기반으로 수행될 수 있다.
- 기능과 구현의 관점
블랙박스 테스트: 구현을 고려하지 않고 기능을 테스트
화이트박스 테스트: 기능 테스트뿐만 아니라 구현 방식도 분석
검증과 확인 V&V
검증: 제품을 올바르게 구축하고 있는가? Do you the things right?
확인: 올바를 제품을 만들고 있는가? Do you the right things?
1. 테스트 기초
테스트
: 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 수동 또는 자동 방법을 동원하여 검사하고 평가나는 일련의 과정
버그: 문제, 결함 또는 난이도를 나타내는 데 일반적으로 사용되는 용어. 정확한 의미가 정해진 것은 아님
오류, 결함, 고장 <- 구별되는 개념임
오류 error
개발자가 잘못하여 설계나 코딩에 실수한 것.
프로그램 출력 != 예상하는 출력 -> 오류!
제품에 결함이 있도록 만든 사람의 실수
-> 테스트의 목표는 이 오류를 찾아내는 것
결함 defect
시스템이 고장을 일으키게 하는 오류의 결과
오류가 있는 경우 결함이 발생.
코드 또는 문서에 오류가 있다고 선언된 것
고장 failure
시스템이 원하는 작업을 수행할 수 없는 상황
-> 요구사항에 있는 걸 수행하지 못하는 상황. 기능, 비기능을 포함한다.
-> 시스템이 다운됐다는 걸 이야기 하는 것이 아님.
결함이 있으면 고장이 발생한다.
잘못된 결과
=> 개념들 구분!
테스트 원리
테스트의 목표는
- 명세대로 작동하는가?
- 오류 찾기
테스트 개념에 대해 정확히 이해해야 올바르게 테스트를 설계할 수 있음
- 테스트의 원리와 특징들 이해하자
- 테스트는 오류를 발견하려고 프로그램을 실행시키는 것이다.
- 프로그램이 작동한다는 것을 보여주려는 것이 아님!
- 완벽한 테스트는 불가능하다.
- 시간과 비용 문제. 효율적으로 테스트 케이스를 골라내야 함
- 테스트는 창조적인 일이며 힘든 일이다.
- 프로그램이 뭘 하는지 잘 이해하고, 테스트 기법을 잘 알고, 효율적으로 이것들 적용해야함
- 테스트는 오류의 유입을 방지할 수 있다.
- 테스트를 개발 초기 단계부터 계획하여 꾸준히 시행 -> 단순히 오류 발견 뿐만 아니라 오류 유입을 막을 수 있다.
- 오류, 문제는 빨리 발견할수록 비용이 적어진다!
- 테스트는 구현과 관계없는 독립된 팀에 의하여 수행되어야 한다.
테스트 작업 과정
다섯 단계 (목표 설정 - 방법 결정 - 테스트 케이스 선택 - 테스트 케이스 작성 - 테스트 실행 )
- 테스트에 의하여 무엇을 점검할 것인지 정한다. - 목표가 무엇? 완벽성 or 신뢰도 or ... ?
- 테스트 방법을 결정한다. - 검사, 블랙박스, 화이트박스, 자동화 도구 등 다양한 방법
- 테스트 케이스를 개발한다. - 방법에 맞춰 테스트 케이스 작성.
- 테스트의 예상되는 올바른 결과를 작성한다. - 테스트 전, 올바른 결과가 무엇인지 알아야 함. ->테스트오라클
- 테스트 케이스를 실행시킨다. - 테스트 실행. 테스트 하니스를 하기도 함.
테스트 케이스: 테스트 자료나 실행될 조건
테스트 오라클: 테스트 케이스 실행이 통과되었는지 실패하였는지 판단하기 위한 기준
테스트 하니스: 시스템의 일부 기능만 시험하기 위하여 소프트웨어에 변경을 가하는 것. 테스트 완전히 끝나면 제거함.
테스트 단계
테스트는 여러 단계로 나누어 진행한다.
-> 단위 테스트, 통합 테스트. 시스템 테스트, 인수 테스트
단위 테스트
: 각 모듈을 테스트하는 것. 대부분 모듈을 구현한 프로그래머가 실시
-> 모듈 정확하게 구현? 예상한 기능 발휘?
통합 테스트
: 전체 시스템을 이루는 모듈을 모아 통합적으로 시험하는 것.
-> 시스템이 요구 기능 제대로? 모듈 사이에 인터페이스 올바른지?
시스템 테스트
: 완성된 제품에 대한 시험.
-> 시스템이 사용될 준비가 되었다고 드러내 보이는 것
인수 테스트
: 사용될 환경에 설치하여 사용자가 직접 사용하여 시험하는 것.
리그레션 테스트
: 시스템 설치 이우 유지보수 단계에서 이루어지는 테스트. 수정이 이루어진 부분과 그에 의한 영향을 시험.
테스트 케이스
성공적인 테스트를 위해서는 좋은 테스트 케이스를 찾아내야 함!
- 결힘을 검사할 수 있는 입력
- 시험조건, 테스트 데이터, 예상 결과를 포함시켜야 한다.
-> 테스트 케이스 명세서 작성
2. 블랙박스 테스트
: 내부 경로에 대한 지식을 보지 않고 테스트 대상의 기능이나 성능을 테스트
-> 요구사항, 사양을 기반으로 시스템의 입력과 출력에 중점을 둔다.
-> 입력과 출력이 무엇인지 결정
-> 모든 입출력 케이스를 테스트 하는 것 X 대푯값으로 한 번만
여러 블랙박스 테스트 기법들
- 어떻게 테스트 케이스를 선정하는지
동등 분할 기법
동등 클래스 equivalence clasee
: 시스템의 동작이 같은 것으로 예상되는 입력들.
다른 동작 예상 -> 다른 동등 클래스
=> 동등 클래스의 개수만큼으로 테스트 케이스의 개수가 축소됨.
동등 클래스에서 대푯값을 선정하여 테스트 하면 된다.
여러 동등 클래스를 커버하늨 대푯값을 사용할 수도 있음
경곗값 분석
입력값의 경계선에 중점을 두는 테스트
반복, 입력 크기, 자료 시작과 끝 등 경계가 많은 문제를 가질 수 있음
원인과 결과 그래프
입력 조건의 조합을 쳬계적으로 선택하는 테스트 기법
위의 두 방법의 단점: 각각의 입력을 별도로 생각한다는 것. 입력 조건, 클래스 조합을 고려하지 않음.
노드: 원인(입력 조건), 결과(출력 조건)
기호: ^ amd, v or, ~ not
결정 테이블 decision table
원인 결과 그래프로부터 테스트 케이스 만들 떄 사용
기본적인 방법: 결과 하나를 참으로 정하고 - 이런 조건을 가능하게 하는 원인을 찾음.
-> 원인들의 조건이 테스트 케이스가 됨
x: don't care, 0: flase, 1: true
3. 화이트박스 테스트
: 모듈 안의 작동을 자세히 관찰하는 시험 방법 -> 소스코드를 봄
모듈의 논리적인 구조를 체계적으로 점검
-> 구조적 테스트라고도 함
<-> 블랙박스 테스트: 프로그램 내부 구ㅅㅇ,ㅁ 조는 다루지 않음.
블랙박스 -> 기능에 관심
화이트박스 -> 구현에 관심
목적
: 프로그램의 구조를 시험하기 위해 여러 가지 다른 구조에 대하여 테스트 케이스 찾아내기
기능 테스트와 다르게 프로그램 구조를 기반으로
-> 검증 기준이 더 명확하고 세밀하다.
테스트 과정
1. 원시 코드를 통해 애플리케이션 구조 이해. -> 그래프를 그려 논리 흐름을 찾음
2.검증 기준을 정함 -> 테스트에 의해 검증하느 범위를 정하고, 이에 맞는 테스트 경로, 선택조건 찾음
3. 각 경로를 구동시키는 테스트 데이터 준비. -> 프로그램 수행해서 결과 비교
논리 흐름의 표현
(1. 원시 코드를 통해 애플리케이션 구조 이해. -> 그래프를 그려 논리 흐름을 찾음)
-> 논리 흐름도 logic-flow diagram
: 모듈 내의 제어 흐름을 간선으로 표시한 그래프.
모듈 내의 모든 세그먼트 -> 그래프의 정점으로
간선: 모듈 내 제어 흐름
정점: 모듈 내 세그먼트
검증 기준
(2.검증 기준을 정함 -> 테스트에 의해 검증하느 범위를 정하고, 이에 맞는 테스트 경로, 선택조건 찾음)
화이트박스 테스트 -> 테스트 실행이 프로그램의 어떤 기준을 커버하는지 먼저 결정한 후 테스트 데이터 결정
이를 검증 기준이라고 함.
일반적으로 검증 기준에는 다음 세 가지가 있음
문장 커버리지
- 각 라인이 적어도 한 번 실행되는지 검증
분기 커버리지
- if 문에서 True, False 경로를 다 거쳐가게
- T, F
경로 커버리지
- 모든 실행 경로를 테스트
- TT, TF, FT, FF
싸이클로매틱 복잡도
: 기본 경로 개수, 소프트웨어 복잡척도
화이트박스 테스트의 기본 개념은 기본 경로 basis path 라 불리는 독립적인 논리 흐름을 검사하는 테스트케이스를 생성하는 것
기본 경로 - 시작 노드에서 종료 노드까지 서로 다른 경로로써 싸이클은 최대 한번만 지낙야 함.
-> 테스트 데이터 기본 경로만큼 필요?
-> 기본 경로 몇 개?
-> 싸이클로매틱 복잡도로 구할 수 있음
McCabe 가 발견한 세 가지 방법. 모두 같은 값을 계산함
1. 폐쇄 영역의 수 + 1
2. 노드와 간선의 수
-> 싸이클로매틱 복잡도 = 간선의 수 - 노드의 수 + 2 = (E - N + 2)
- 위의 논리 흐름도의 노드는 9개(start, exit 포함), 간선은 11개 -> 11-9+2=4
3. 단일 조건의 수 + 1
-> 단일 조건: 참과 거짓으로 판별되는 원자적 조건. AND, OR로 연결된 복합 조건이 아님.
기본 경로 도출기법
- 단순 기본 경로 기법: 짧은 경로부터
- 실용 기본 경로 기법: 긴 경로부 도출
1. 프로그램 제어 흐름 그래프 작성
2. 단순/실용 기법에 따라 첫번째 기본 경로 도출
3. 기본 경로가 지나가지 않은 분기를 가지는 첫번째 분기 노드에서 경로를 변경하여 다음 기본 경로 도출
변경한 경로 외에는 이전 경로와 동일하게
지나가지 않은 분기 노드가 존재하지 않을 때까지 반복
기본 경로 커버리지: (수행한 경로수 / 모든 기본 경로수) * 100
루프 테스트
- 단순 반복
1. 반복 구조 생략 / 2. 반복 구조 안에서 한 번 반복 / 3., 범위 내의 임의 반복 / 4. 최대 횟수 -1 만큼 / 5. 반복 최대 횟수만큼
- 중첩된 반복
가장 내부에 있는 반복 구조부터 하나씩 외부로 테스트. 다른 외부 반복은 최소 반복 횟수로 지적.
-> 가낭 내부 반복문을 위 처럼 5가지 경우로 나누어 테스트.
-> 그 다음 외부 구조에 대하야 다시 5가지 테스트.
다른 외부 반복 구조는 최소 횟수만 반복 !
- 연속된 반복
두 가지 경우 고려
- 독립: 단순 반복 구조와 깉은 방법으로
- 변수 의존적: 중첩된 반복 구조와 같은 방법
4. 상태기반 테스트
상태가 없는 프로그램: 같은 입력에 대해 언제나 같은 동작, 동일한 결과
- 배치 처리 시스템, 계산 중심, 하드웨어로 구성된 회로
상태가 있으면, 동일한 입력에 대하여 시간에 따라 다르게 동작하고 다른 결과를 출력
시스템 상태에 의해 시스템 동작이 좌우됨.
-> 이런 시스템은 어떻게 테스트 할까!
상태를 구성하는 소프트웨어 -> 상태 머신으로 모델링
상태 모델 구성요소
- 상태: 시스템의 과거 입력에 대한 영향을 표시
- 트랜지션: 이벤트에 대한 반응으로 시스템이 하나의 상태에서 다른 상태로 어떻게 변해나가는지
- 이벤트: 시스템에 대한 입력
- 액션: 이벤트에 대한 출력
-> 상태 모델을 가지고 어떻게 테스트 케이스 만들까 -- 상태와 트랜지션에 집중한다.
많이 사용되는 세 가지 - 모든 트랜지션 / 모든 트렌지션 쌍 / 트랜지션 트리
모든 트랜지션 - 테스트 케이스 집합이 상태 그래프의 모든 트랜지션을 점검
-> 모든 상태가 방문되어 점검됨.
5. 통합 테스트
: 시스템을 구성하는 모듈들의 결합을 테스트
-> 모듈의 인터페이스 결합을 테스트
- 여러 개ㅔ발 팀에서 개발한 각각의 단위 모듈을 대상
- 모듈-모듈 간의 결합을 테스트
모듈의 결합 순서에 따라 테스트 방법이 달라짐
- 빅뱅 / 하향식 / 상향식 / 연쇄식
드라이버
: 시험 대상 모듈을 호출하는 간이 소프트웨어 (테스트 하니스)
스텁
: 시험 대상 모듈이 호출하는 또 다른 모듈 (호출하는 모듈을 대신하여 간이로)
빅뱅 통합
: 한 번에 모든 모듈을 모아 통합
초보 개발자
| 장점 | 단점 |
| 일정 관리 편리 | 오류의 위치, 원인 찾기 어려움 |
| 통합을 위해 스텁을 구성할 필요 없음 | 동시에 통합->중대한 오류 발생 가능 |
| 일정 계획 융통성 X |
하향식 통합
: 시스템 구조상 최상위에 있는 모듈부터 통합
| 장점 | 단점 |
| 중요한 모듈의 인터페이스를 조기에 테스트 | 입출력 모듈이 상대적으로 하위 (테스트작성,실행 어려움) |
| 스텁을 이용하여 시스템 모습 일찍 구현 가능 | 중요 기능을 하는 최하위층은 불충분한 시험 |
| 개발자 입장에서 요이 |
테스트 대상 모듈 호출할 드라이버 -> 대상 모듈 -> 스텁들
-> 테스트 되면 대상 모듈이 또 하위 모듈들을 호출하고
상향식 통합
: 시스템 구조상 최하위에 있는 모듈부터 통합
| 장점 | 단점 |
| 점증적 통합 방식 -> 오류 발견 쉬움 -> 하드웨어 사용 분산 |
초기에 시스템의 뼈대 갖추어 지지X |
| 하위층 모듈을 상위층보다 더 많이 테스트 | 상위층의 중요한 인터페이스 마지막에 확인 가능 |
| 상위층 시스템 충분히 시험 기회X |
테스트 드라이버 만들어줘여함
연쇄식 통합
: 특정 기능을 수행하는 모듈의 최소 단위로 부터 시작
- 입출력
- 어느 정도의 기본 기능을 수행하는 모듈 단위
-> 상대적으로 중요한 모듈부터 통합 테스트
장점
- 초기에 시스템의 골격 형성
-> 빠르게 사용자 의견 확인 가능
- 시스템을 여러 프로그래머에게 나누어 개발 & 진도 확인 가능
6. 시스템 및 인수 테스트
컴포넌트 통합 후 수행하는 테스트 기법
-> 시스템이 기능적 요구와 비기능적 요구를 만족하는지 확인
-> 블랙박스 기법
기능 테스트
- 기능적 요구와 시스템의 차이를 발견하기 위한 테스트
- 사용자와 관련. 오류를 유발할 가능성이 많은 테스트를 선정 (모두 테스트는 불가 )
- 유즈케이스 모델을 검토 -> 오류를 일으킬만한 유슼이스 인스턴스 찾아내기
- 테스트 케이스 - 일반적 / 예외적 사례
- 유즈케이스 흐름에 따라 테스트를 진행함 . 유즈케이스에 테스트 데이터를 넣음 !
성능 테스트
시스템의 여러 측면을 테스트
- 작업 부하: 시스템이 처리하고 생성하는 작업 양
- 처리량: 트랜잭션 수. 시간 당 처리하는 메일 수 등
- 반응 시간: 시스템 요구를 처리하는 데 걸리는 총 시간
- 효율성: 주어진 작업 처리를 위한 CPU 시간과 메모리 같은 자원의 양
- 자원 효율성: 시스템에 의하여 실제 사용되는 자원 비율
테스트 방법
- 성능 테스트
- 정상적인 사용 환경에서 시스템을 측정
- 시뮬레이션을 이용한 테스팅 가능
- 사용자 모델 구축 - 사용 프로파일 생성 - 난수 생성기 활용하여 사용 프로파일에 작업 부하 생성
- 스트레스 테스트
- 시스템 처리 능력의 몇 배의 작업 부하를 처리하고 견딜 수 있는지 측정
보안 테스트
: 시스템의 보안 취약점을 찾아내려는 목적
테스트 방법
- 화이트박스 테스트
- 정적분석 도구로부터 원시코드의 취약한 패턴 찾아 실행
- 블랙박스 테스트
- 악의적인 공격 패턴을 입력으로
- 랜덤 테스트 : 무작위 입력값
- 퍼징 테스트
- 정상입력을 변형하여 입력
- 무작위 변형하거나 유전 알고리즘 적용 변형
사용성 테스트 - UI 테스트
기능, 성능, 보안 테스트와 목적이 다르다.
-> 인간 공학적인 목적
테스트 목적
- 보고 느끼는 UI에 대한 결함
- 데이터 입출력 디스플레이에 대한 결함
- 액터-시스템 사이의 동작 결함
- 오류 처리에 대한 결함
- 문서와 도움말에 대한 결함
인수 테스트
시스템을 당장 사용할 수 있도록 모든 준비가 되어 있는지 확인
개발자를 제외한 의뢰자 또는 대리인이 테스트 수행
시스템 요구 분석서를 기반으로 한 테스트 수행
실제 업무 절차를 따라 테스트 수행
테스트 유형
- 알파 테스트: 선택된 사용자가 개발 환경에서 시험하는 것
- 베타 테스트: 사용자가 외부 환경에서 시험하는 것(필드 테스트)
테스트 도구
- 테스트는 반복적인 작업 -> 자동화 지원
- 테스트 관리 도구, 기능 테스트 도구, 모듈 테스트 도구, 커버리지 도구, 성능 테스트 도구, 보안 테스트 도구 등
설치 테스트
'Computer Science > Software Engineering' 카테고리의 다른 글
| [소프트웨어공학] 품질 (0) | 2023.12.15 |
|---|---|
| [소프트웨어공학] UI 설계 (0) | 2023.12.15 |
| [소프트웨어 공학] 개발 프로세스 모델 (1) | 2023.10.14 |
| [소프트웨어 공학] 프로세스 (0) | 2023.09.29 |
| [소프트웨어 공학] 소개 (2) | 2023.09.23 |