[소프트웨어공학] 6장. 테스트

해당 게시물은 김정욱 교수님의 '소프트웨어공학' 강의를 수강하며
학습한 내용을 개인적으로 정리한 글입니다.

---

📌 목차 - 6장. 테스트

6-1. 테스트
6-2. 테스트 단계, 방법
6-3. 블랙박스 테스트
6-4. 화이트박스 테스트
6-5. 통합 테스트
6-6. 시스템 테스트
6-7. 인수 테스트

---

📌 6-1. 테스트

* 테스트
- 잘 안되는 것을 발견하기 위한 작업

* 테스트 중요성
- 소프트웨어 오작동으로 인한 재산/인명 피해를 사전에 예방하기 위함
(1) 결함 예방
(2) 품질과 안정성 보장
(3) 소프트웨어 신뢰성 향상

* 검증과 확인
- 검증(verification): 각 단계의 일들을 잘하고 있는가?
- 확인(validation): 만든 결과가 원했던 것인가?

* 테스트 기초
- 오류: 소프트웨어 개발자에 의해 생기는 실수 (결함의 원인)
- 결함: 오류에 의해 프로그램이 완전치 못한 것 (고장의 원인)
- 고장: 시스템이 요구사항대로 작동하지 않는 것 (모든 오류, 결함이 반드시 고장을 유발하지는 않는다.)

* 테스트 다섯가지 원리
- 오류를 발견하기 위해서 프로그램을 실행시키는 것
- 완벽한 테스트는 불가능하다.
- 창조적인 일이며 힘든 일이다.
- 오류의 유입을 방지할 수 있다.
- 구현과 관계없는 독립된 팀에 의해 수행되어야 한다.

* 테스트 작업 과정
(1) 목표 설정: 테스트에 의해 무엇을 점검할지 결정한다. ex. 기능, 성능, 암호화
(2) 방법 결정: 목표에 따라 테스트 방법을 결정한다. ex. 화이트박스, 블랙박스
(3) 테스트 케이스 선택: 방법에 맞는 테스트 케이스(데이터)를 선택한다.
(4) 테스트 케이스 작성: 예상되는 올바른 결과를 작성한다. 통과, 실패에 대한 기준을 정한다.
(5) 테스트 실행: 예상되는 결과와 나온 결과를 비교한다.

* 테스트 케이스
- 결함을 검사할 수 있는 입력
- 테스트 대상, 테스트 조건, 테스트 데이터, 예상 결과

---

📌 6-2. 테스트 단계, 방법

* 테스트 단계
1. 단위 테스트
- 각 모듈을 시험한다.: 프로그래머
- 모듈을 정확하게 구현했는가?
- 예정한 기능을 제대로 발휘했는가?
2. 통합 테스트
- 모듈을 모아서 통합적으로 시험한다.
- 시스템이 요구하는 기능을 제대로 수행하는가?
- 모듈 사이 인터페이스 시험 (모듈 간 연동)
3. 시스템 테스트
- 완성된 제품(소프트웨어+하드웨어)에 대해 시험한다.
- 시스템의 기능과 성능 검증
- 어느정도 과부하를 버틸 수 있는지
4. 인수 테스트
- 사용자가 직접 설치해서 사용하면서 시험한다.
- 사용자 관점에서 소프트웨어가 요구사항을 충족하는가?
- ex. 베타테스트: 다수의 사용자들이 각자의 환경에서 진행하는 테스트
5. 리그레션 테스트
- 유지보수 단계에서 이뤄지는 테스트
- 결함이 있는 부분(+ 결함이 있는 모듈과 연관된 모든 모듈)만 테스트

* 테스트 방법
1. 블랙박스 테스트: 소스코드 클로즈
- 기능을 테스트한다.
- 소프트웨어에 데이터를 입력하고 소프트웨어의 동작을 모니터링한다.
- 테스트 과정의 후반부에 적용한다.
2. 화이트박스 테스트: 소스코드 오픈
- 소스코드의 취약성이 발생할 수 있는 패턴을 분석한다.
- 모듈 안의 작동을 직접 관찰한다.
- 테스트 과정의 초반부에 적용한다.

---

📌 6-3. 블랙박스 테스트

* 블랙박스 테스트
- 내부 경로(내부 코드 구조, 구현 세부 사항 등)에 대한 지식을 보지 않고 테스트 대상의 기능이나 성능을 테스트한다.
- 요구사항을 기반으로 입력을 설정한다.
- 입출력에 중점을 둔다. (입력을 잘 설정해야 한다.)

 

* 블랙박스 테스트 장점
- 기술적 배경이 필요하지 않다.
- 테스터와 개발자가 서로 독립적인 작업이 가능하다.
- 크고 복잡한 응용프로그램에서 더 효과적이다.
- 테스트 초기 단계에서 결함, 불일치 식별이 가능하다.

 

* 블랙박스 테스트 단점
- 테스트 할 시나리오의 가능한 조건을 무시할 가능성이 있다.
- 가능한 모든 입력과 출력 테스트를 건너뛸 수 있다.
- 크고 복잡한 테스트 대상은 완전한 범위설정이 불가능하다.

* 동등 분할 기법
- 동등 클래스(Equivalence Class)
- 시스템의 동작이 같을 것으로 예상되는 입력들로 구성된다.
- 입력의 결과로 나타날 결과 값이 동일한 경우는 하나의 그룹으로 간주한다.

* 경계값 분석
- 경계: 시스템 동작이 변경되는 한계 근처의 값
- 유효한 입력과 유효하지 않은 입력을 모두 테스트해서 문제를 확인한다.
- 경계에 있는 값을 테스트 입력으로 선택한다.
- 코딩 오류 중 "하나 차이에 의한 오류"

* 원인과 결과 그래프
- 입력 조건의 조합을 체계적으로 선택한다.
- 노드와 기호로 표시
- 노드: 원인(Cn:입력조건), 결과(En:출력조건)
- 기호: ^(and), v(or), ~(not)
- 장점: 좋은 테스트 케이스를 만들어준다. 시스템의 기능을 이해하는데 도움된다.

* 결정 테이블
- 원인 결과 그래프를 만들 때 사용되는 테이블
- 원인 결과 그래프의 테스트 케이스를 만들 때 사용한다.
- 결과 하나를 참으로 정하고 조건을 가능하게 만드는 원인을 찾는다.
- 원인들의 조건이 테스트 케이스를 구성한다.
- 1:참, 0:거짓, x:don't care

* 오류 예측
- 기존의 노하우와 경험으로 오류를 예측하고 테스트하는 방식
- 예외 케이스를 경험에서 생각해낸다.

---

📌 6-4. 화이트박스 테스트

* 화이트박스 테스트
- 소프트웨어 혹은 제품의 내부 구조, 동작을 세밀하게 검사하는 테스트 방식이다.
- 프로그램 상에 허용되는 모든 논리적 경로를 파악해서 테스트한다.
- 문제가 발생할 가능성이 있는 모듈 내부를 테스트한다.

* 화이트박스 테스트 과정
(1) 소스 코드를 통해 어플리케이션 구조를 이해한다. - 논리흐름도
(2) 검증 기준(커버리지)을 정한다.
(3) 각 경로를 구동시키는 테스트 케이스를 준비하고, 결과를 비교한다.

* 논리흐름도
- 모듈 내의 제어 흐름을 간선으로 표현한 그래프
- 논리의 흐름 수가 4개라면 4개의 논리흐름을 모두 테스트해보는 것이 좋다.

* 커버리지
- 테스트 데이터를 선택하기 위해서 테스트 실행이 프로그램의 어떤 기준을 커버하는지 결정한다.
- 문장 커버리지: 코드의 각 라인이 적어도 한 번 이상 실행되는지 검증한다. (if문의 모든 조건(구문)을 체크하는지 검사)
- 분기 커버리지: 코드에서 각 분기가 한 번 이상 실행되는지 확인한다.
- 조건 커버리지: 각 개별 조건이 참/거짓 한번을 모두 갖도록 수행한다.
- 조건/결정 커버리지: 전체 조건, 개별 조건식이 참/거짓을 한번 갖도록 수행한다.
- 경로 커버리지: 프로그램의 모든 실행 경로를 테스트하는 기준 (현실적으로 불가능하다.)

---

📌 6-5. 통합 테스트

* 통합 테스트
- 모듈들의 인터페이스 결합을 테스트한다.
- 대부분 블랙박스 테스트 (시스템이 통합된 후에는 사이즈가 크기 때문이다.)
- 드라이버: 시험 대상 모듈의 상위 모듈
- 스텁: 시험 대상 모듈의 하위 모듈

* 빅뱅 통합
- 한 번에 모든 모듈을 통합한다.
- 장점
- 일정에 대한 관리가 편하다.
- 통합을 위해 스텁을 구성할 필요가 없다.
- 단점
- 오류의 위치와 원인을 찾기 어렵다.
- 개발 진도를 예측하기 어렵다.

* 하향식 통합
- 시스템 구조도의 위층에 있는 모듈부터 아래층의 모듈로 내려오면서 통합한다.
- 장점
- 중요한 모듈의 인터페이스를 초기에 테스트할 수 있다.
- 오류의 원인을 찾아내기 쉽다. (점증적 개발)
- 개발자 입장에서 용이하다.
- 단점
- 입출력 모듈이 대부분 하위에 존재한다. (테스트 케이스 작성 및 실행이 어렵다.)
- 중요한 기능을 하는 최하위층 모듈은 충분한 시험을 할 수 없다.

* 상향식 통합
- 시스템 구조도상 최하위에 있는 모듈부터 통합한다.
- 장점
- 오류의 원인을 찾아내기 쉽다. (점증적 개발)
- 하위층 모듈을 상위층보다 더 많이 테스트할 수 있다.
- 단점
- 초기에 시스템의 뼈대가 갖춰지지 않는다.
- 상위층의 중요한 인터페이스를 마지막에 확인 가능하다.
- 의뢰자(상위)에게 시스템을 시험해 볼 기회를 충분히 제공하지 못한다.

* 연쇄식 통합
- 기본 기능을 수행하는 모듈(중요한 모듈)부터 통합한다.
- 특정 기능을 수행하는 모듈의 최소 단위(thread)로부터 시작한다.
- 장점
- 초기에 시스템의 골격이 형성되어 사용자의 의견을 빠르게 받을 수 있다.
- 여러 프로그래머에게 나누어 개발될 수 있고, 각 프로그래머도 시스템의 부분적 개발 진도를 확인 가능하다.

---

📌 6-6. 시스템 테스트

* 시스템 테스트
- 모듈 통합 후 수행하는 테스트 기법
- 전체 시스템이 기능/비기능적 요구를 만족하는지 테스트

* 기능 테스트
- 기능적 요구와 시스템의 차이를 테스트한다.
- 유스케이스 모델을 검토, 오류를 일으킬 유스케이스 인스턴스를 찾아낸다.
- 일반적인 사례, 예외적인 사례를 고려해서 테스트한다.

* 성능 테스트
- 작업 부하(workload): 시스템이 처리하고 생성하는 작업의 양
- 처리량(throughput): 시간당 처리하는 양
- 반응 시간(response time): 시스템의 요구를 처리하는데 걸리는 총 시간
- 효율성: 주어진 작업 처리르 위한 CPU 시간과 메모리 같은 자원의 양의 비율 측정
- 방법
- 스트레스 테스트: 시스템 처리능력 몇 배의 작업 부하를 처리하고 견딜 수 있는지 측정한다.
- 성능 테스트: 정상적인 사용환경에서 시스템의 성능을 측정한다.
- 보안 테스트
- 일반적으로 툴을 사용해서 테스트를 진행한다. ex. 제니퍼소프트

* UI 테스트
- 기능, 성능, 보안 테스트와 목적이 다르다.
- 인간 공학적인 목적을 가지고 있다. ex. 마우스가 움직이는 거리를 최대한 적게
- 목적
- 보고 느끼는 UI에 대한 결함 (미학적)
- 데이터 입력과 출력 디스플레이에 대한 결함
- 오류 처리에 대한 결함
- 도움말에 대한 결함

---

📌 6-7. 인수 테스트

* 인수 테스트
- 시스템을 당장 사용할 수 있도록 모든 준비가 되어 있는지
- 개발자가 하지 않고, 개발을 의뢰한 사람 또는 대리인이 진행한다.
- 알파 테스트: 선택된 사용자가 개발 환경에서 시험한다. (정해진 곳에서)
- 베타 테스트: 선택된 사용자가 외부 환경에서 시험한다. (외부에서 직접 설치까지)

---