소프트웨어 테스트

Preface

 

오늘은 실무 현장에 있는 친구를 만나 지난 포스팅에서 작성했던 '코드 검사와 테스트를 분리하는 이유'와 더불어 '테스트 기준들이 모호한데, 현업에선 주로 어떤 테스트 케이스를 사용하는가?'에 관한 질문을 했다.

 

답변은 의외로 간단했다.

 

코드 검사는 말 그대로 코드 자체의 오류를 검사하는 것이며, 테스트는 소프트웨어의 성능을 전반적으로 테스트하는 개념이라는 것이다. 또한, 특정 테스트 케이스를 주로 사용한다기 보단 상황에 맞는 다양한 테스트 케이스를 사용한다고 한다.

 

cf. 리팩토링과 코드 검사에 대해서도 생각해 보았는데, 리팩토링은 코드를 이해하기 쉽게 수정하는 활동이므로 코드 검사와는 다른 개념인 것 같다.

---

1. 소프트웨어 테스트 개요 및 목적

 

- 테스트 : 시스템이 정해진 요구사항을 만족하는가, 예상한 것과 실제의 모습이 어떤 차이가 있는가 검사하고 평가하는 일련의 활동

→ 테스트 케이스(test case)를 만들어 수행

 

- 일반적인 소프트웨어 테스트 목적

1) 소프트웨어 내에 존재하는 오류 발견

2) 소프트웨어 요구사항에 충족하는지 확인

3) 소프트웨어 명세에 충족하는지 확인

4) 소프트웨어 출시 이후 발생할 수 있는 결함 예방

 

- 소프트웨어 테스트의 부가적 목적

1) 소프트웨어 품질에 대한 자신감 획득과 정보 확인

2) 비즈니스 리스크를 감소시킬 수 있도록 정보에 근거한 조언 제공

3) 개발 프로세스 점검 및 이슈 제공

4) 시스템과 소프트웨어가 적절히 동작함을 확인

---

2. 소프트웨어 개발 프로세스와 테스트

 

- V모델 : 테스트 프로세스를 개발 프로세스와 매핑하여 정의한 라이프 사이클

※ 코딩 이후가 아닌, 프로젝트 각 개발 단계마다 병렬로 수행하는 것이 좋음

 

[V모델]

 

- V모델 프로세스

1) 요구사항 분석 : 개발될 시스템에 대한 요구사항 및 사용자 필요를 분석

→ 소프트웨어가 사용자의 요구사항을 정확히 실행하는가

2) 기본 설계 : 일반적인 시스템 아키텍처 구성과 메뉴 구조, 자료 구조 등을 기술

3) 상세 설계 : 각각의 모듈에 대한 상세 알고리즘 작성

---

3. V모델 소프트웨어 테스트 단계

---

1. 단위 테스트(unit testing) : 프로그램 기본 단위인 모듈에 대한 테스트

1) 화이트박스 테스트

2) 작성된 코드에 대한 분석

3) 비공식적으로 다루며 프로그래머에게 일임

4) 각 모듈에 대해 인터페이스, 지역 자료 구조, 경계 조건, 제어 흐름 및 오류 처리 등을 확인

 

- 단위 테스트에서 사용되는 모듈

1) 드라이버(driver) 모듈 : 상향식 접근 방법

2) 스텁(stub) 모듈 : 하향식 접근 방법

 

2. 통합 테스트(integration testing) : 통합된 컴포넌트 간 인터페이스 및 상호작용 오류를 발견

1) 블랙박스 테스트

2) 일반적으로 개발자가 진행

3) 점진적 통합이 바람직함

 

- 통합 테스트 방법

1) 하향식 통합 테스트 : 상위 모듈부터 통합

① 깊이 우선 : 한 모듈을 선택한 후 그 모듈의 하위 모듈부터 통합

② 넓이 우선 : 한 모듈 바로 아래에 있는 하위 모듈을 전부 통합한 후 그 밑의 모듈 통합

2) 상향식 통합 테스트 : 하위 모듈부터 통합

 

- 클러스터(cluster) : 모듈의 묶음

 

- 회귀 테스트(regression test) : 기존 테스트 케이스로 재시험 하는 과정

→ 새로 추가된 모듈들로 인해 기존 테스트에서 발생하지 않았던 오류를 발견하기 위함

 

3. 시스템 테스트(system testing) : 모든 요소들이 조화를 이루어 시스템의 기능을 만족하는가

1) 독립된 테스트 팀에 의해 수행

2) 결과를 기록하고 보관

 

- 시스템 테스트 종류

1) 복구 테스트 : 여러 방법으로 소프트웨어를 고장나게 하여 시스템 복구 능력을 확인

2) 보안 테스트 : 시스템에 대한 불법 침입자의 침입을 막을 수 있는지 확인

3) 스트레스 테스트 : 비정상적인 상태에서 소프트웨어의 기능과 성능을 확인

4) 성능 테스트 : 시스템이 통합된 상태에서 시스템 수행 능력을 확인

 

4. 인수 테스트(validation testing) : 개발된 소프트웨어가 고객의 요구사항을 만족하는지 확인

1) 개발자, 독립적인 테스터(ITG : Independent Testing Group), 사용자가 수행

 

- 인수 테스트 중 사용자가 수행하는 검증 테스트

1) 알파 테스트 : 사용자가 개발 환경에 와서 테스트

2) 베타 테스트 : 사용자가 자신의 컴퓨터 환경에서 테스트

---

---

4. 소프트웨어 테스트 방법 및 테스트 설계 기법

 

- 블랙박스 테스트 : 내부 구조를 참조하지 않고 주어진 입력에 요구되는 결과가 나오는지 확인

1) 기능 테스트, 명세서에 기초한 테스트와 같은 의미

2) 프로그램의 기능에 초점

 

[블랙박스 테스트]

 

[블랙박스 테스트 케이스 도출 기법]

→ 동등 분할과 경계값 분석을 주로 사용

 

 

- 화이트박스 테스트 : 내부 코드의 동작 방식에 대한 테스트

1) 구조 테스트, 코드에 기초한 테스트와 같은 의미

 

[화이트박스 테스트]

 

[화이트박스 테스트 검증 기준]

→ 문장 검증 기준은 가장 최소한의 테스트를,

다중 조건 검증 기준은 가장 넓은 범위의 테스트를 지원

 

- 화이트박스 테스트 존재 이유

1) 블랙박스 테스트만으론 프로그램의 모든 실행문이 실제로 실행되는지 알 수 없고, 실행되지 않는 코드가 있는 경우 이해하기 어려우며 유지보수가 힘듬

2) 블랙박스 테스트만으론 부작용을 예측하기 어려움

3) 화이트박스 테스트로 프로그램 내에 불필요한 기능을 찾아낼 수 있음

4) 화이트박스 테스트로 프로그램의 오자(type error)를 찾아낼 수 있음

---

5. 소프트웨어 테스트 프로세스

 

[소프트웨어 테스트 프로세스]

---

1. 테스트 계획 : 프로젝트 계획서, 요구사항 명세서를 바탕으로 테스트의 목표를 수립하고, 테스트 대상 및 범위 선정

1) 최상위 테스트 계획서 : 전체적인 테스트 지침 문서

2) 단계별 테스트 계획서 : 각 단계별(단위, 통합, 시스템, 인수 테스트)로 일정, 자원, 범위, 접근방법 등을 기술

 

2. 테스트 설계 : 테스트에 필요한 최적의 입력 값을 찾아내는 것

 

- 테스트 케이스 : 테스트에 사용할 특정한 입력값

 

- 테스트 설계 산출물

1) 테스트 설계서 : 테스트를 수행하기 위한 접근 방법, 테스트 케이스 설계 기법을 정의

① 설계 문서 식별자

② 테스트 대상 특성

③ 세부 접근 방법

④ 테스트 식별 및 특성의 성공/실패 기준

2) 테스트 케이스 명세서 : 테스트 설계 기법을 이용하여 테스트 케이스를 도출하여 정의하는 문서

3) 테스트 절차서 : 테스트 케이스를 수행하는 절차에 대해 기술

 

3. 테스트 실행 : 실제 테스트를 수행하고 테스트 상황 기록 문서 작성

 

4. 테스트 결과 분석 및 평가 : 테스트 성공 여부 평가 및 테스트 보고서 작성

 

- 테스트 보고서 포함 내용

1) 테스트 사건 보고서 : 더 조사할 필요가 있는 사건 기록

2) 테스트 요약 보고서 : 결과 요약 및 평가와 권고사항 기록

---

---

6. 테스트 종료

 

- 테스트 종료 관점

1) 테스트 기간에 따른 기준 : 일정 기간이 흐른 후 종료

2) 테스트 작업량에 따른 기준 : 필요 작업량을 설정한 후 이를 초과할 시 종료

3) 발견되는 오류가 감소하는 데 따른 기준 : 오류의 수가 설정된 범위보다 적어질 경우 종료

4) 테스트 케이스의 수에 의한 기준 : 설정된 테스트 항목 및 테스트 케이스 수행 이후 오류가 없을 시 종료

→ 주로 블랙박스 테스트 기법에 사용

5) 테스트 커버리지에 의한 기준 : 테스트 커버리지 기준치를 초과한 경우 종료

→ 테스트 커버리지 : 테스트가 수행된 정도

 

 

 

 

 

참고 문헌 : 윤청, 『소프트웨어 공학 에센셜』(생능출판), 2019, p.428~464.