7. testing

Verification

- 정확한 요구사항에 부합하여 구현되었는지

- 요구사항 명세서대로 제품이 만들어지고 있는지

- 개발 중간중간 이루어짐

- 개발자 측면

 

Validation

- 고객이 의도한 요구사항에 따라 구현되었음을 보장

- 고객이 의도한 환경이나 사용목적에 맞게 만들어짐을 보장

- 제품이 고객들이 원한것이 맞는지

- 원래 의도한 사용에 부합하는지

- 개발의 처음이나 끝에 이루어짐

- 고객/사용자 측면

 

이 둘을 V&V라고 함

 

Testing과 Debugging

	Testing	Debugging
목적	알려지지 않은 결함의 발견	이미 알고 있는 결함의 수정
수행	시스템 내부 관련자 테스팅 팀 등 외부의 제3자	시스템 내부 관련자
주요 작업	숨겨진 결함 발견	결함의 정확한 위치 파악 결함의 타입 식별 결함의 수정

 

테스트의 목적

프로그램이 사용할만한것인지 확인하기 위하여 결함 발견을 목적으로 프로그램을 실행하는 작업

- 완별한 테스트는 불가능함

- 결함이 없음을 증명할 수는 없음

 

현실적인 테스트의 목적: 주어진 시간과 인력으로 오류를 발견할 확률이 높은 가장 효율적인 테스트 케이스를 찾아 실행

 

 

테스트 단계는...

개발에 비하여 적은 관심

(무계획, 개인의 경험에 의존, 개발에 비해 쉽다는 생각)

품질의 중요성에 비하여 적은 노력

(테스트 엔지니어 교육, 테스트기법 교육, 도구 교육이 필요)

 

 

Unit testing(단위 테스트)

- 소프트웨어를 구성하는 단위, 즉 모듈/함수를 중심으로 테스트하는 활동

- 함수, 독립적으로 컴파일될 수 있는 모듈, 작업 분할도(WBS)에 나타난 하나의 태스크, 구현된 화면 단위

- 모듈 내부를 구성하는 프로그램에 존재할 수 있는 결함을 찾아내는 것

 

Intergration testing(통합 테스트)

- 단위 테스트가 종료된 모듈들을 하나씩 통합하면서 수행하는 테스트

- 모듈의 내부 로직에 대한 테스트가 단위 테스트를 통해 수행되었기 때문에 모듈 간의 인터페이스 정확성이 주 관심 사항임

 

System testing(시스템 테스트)

- 실제로 소프트웨어가 운영될 하드웨어 환경을 갖추어 테스트

- 전체 시스템을 대상으로 테스트 케이스를 생성하여 테스트 진행

- 소프트웨어가 제공하는 기능에만 관심이 있는게 아니라, 성능 등의 품질 측면에도 관심이 있음

 

Acceptance testing(인수 테스트)

- 인수 또는 수락 테스트

- 사용자 환경에서 개발된 소프트웨어를 테스트 하는 활동

- 사용자가 요구한 기능을 하나씩 실행시키는 데모 형식으로 진행

 

Regression testing(회귀 테스트)

- 소프트웨어 테스트 과정에서 발견된 결함을 수정하고 난 후 수행하는 테스트

- 소프트웨어 운영 과정에서 결함을 수정하거나 기능 개선으로 코드가 변경된 경우 수행

 

 

Test case

특정한 요구사항이 제대로 구현되었는지 검증하기 위하여 테스트 조건, 입력값, 예상출력값, 그리고 실제 수행한 결과를 기록하는 것. 좋은 테스트케이스는 아직 발견되지 않은 오류를 발견할 확률이 높은 테스트케이스

블랙박스 테스팅(Black Box Testing)과 화이트박스 테스팅(White Box Testing)은 소프트웨어 테스팅의 두 가장 일반적인 접근 방식입니다. 이 두 방식은 서로 다른 관점과 목적을 가지고 있으며, 각각의 특징에 따라 소프트웨어의 다른 측면을 검증하고 평가합니다.

### 블랙박스 테스팅

블랙박스 테스팅은 소프트웨어의 내부 구조, 설계, 구현에 대해서는 고려하지 않고, 오직 소프트웨어의 기능적인 측면만을 테스트합니다. 이 접근 방식에서는 입력과 기대되는 출력에 초점을 맞춥니다. 블랙박스 테스팅은 사용자의 관점에서 소프트웨어를 테스트함.
블랙박스 테스팅의 장점은 테스터가 소프트웨어의 내부 구조에 대해 알 필요가 없다는 것입니다. 하지만 이 접근 방식은 내부 로직의 오류나 복잡한 조건을 놓칠 수 있습니다.

1. **동치 분할(Equivalence Partitioning)**: 입력 데이터를 대표값의 집합으로 분할하고, 각 집합의 한 값을 테스트하여 전체 집합을 테스트합니다. 예를 들어, 어떤 입력 범위에 대해 동일한 결과가 예상되는 경우, 이 범위를 하나의 '동치 클래스'로 간주합니다.

2. **경계값 분석(Boundary-value Analysis)**: 입력 범위의 경계값 주변에서 오류가 발생할 확률이 높기 때문에, 경계값을 중점적으로 테스트합니다.

3. **오류 추측(Error Guessing)**: 경험과 직관을 바탕으로 오류가 발생할 가능성이 높은 부분을 추측하여 테스트합니다.

4. **원인-효과 그래핑(Cause-effect Graphing)**: 입력과 출력의 관계를 그래프로 표현하여 복잡한 비즈니스 로직을 시각화하고 테스트 케이스를 도출합니다.


화이트박스 테스팅

화이트박스 테스팅은 소프트웨어의 내부 구조와 작동 원리에 초점을 맞춥니다. 이 방식에서는 소스 코드, 알고리즘, 내부 시스템 구조 등을 깊이 파악하고 테스트합니다. 화이트박스 테스팅은 다음과 같은 측면을 포함합니다:

화이트박스 테스팅의 장점은 내부 오류를 더 깊이 파악하고 수정할 수 있다는 것입니다. 그러나 이 방법은 복잡하고 시간이 많이 소요될 수 있으며, 테스터가 소프트웨어의 내부 구조에 대한 상세한 지식을 필요로 합니다.

이 내용은 블랙박스 테스팅과 화이트박스 테스팅의 구체적인 테스트 기법들에 대한 설명입니다. 각각의 방법은 소프트웨어 테스팅의 특정 측면을 다루며, 블랙박스 테스팅은 주로 기능적인 측면에, 화이트박스 테스팅은 소프트웨어의 구조적인 측면에 초점을 맞춥니다.

 

1. **문장 커버리지(Statement Coverage)**: 소프트웨어의 모든 코드 라인이 적어도 한 번은 실행되도록 하는 테스팅 방식입니다.

2. **결정/분기 커버리지(Decision/Branch Coverage)**: 모든 제어 구조(예: if, switch)의 모든 결과(참/거짓)가 적어도 한 번은 실행되도록 합니다.

3. **조건 커버리지(Condition Coverage)**: 결정/분기 구문 내의 모든 조건이 각각 참과 거짓이 되도록 하는 테스팅 방식입니다.

4. **다중 조건/결정 커버리지(Multiple Condition/Decision Coverage)**: 결정/분기 구문 내의 모든 조건의 가능한 모든 조합을 테스트합니다.

 

 

 

---

 

TMMi(Testing Maturity Model Integration)

소프트웨어 테스팅 프로세스 성숙도 수준 측정 모델

 

테스팅 관련 자격증

CSTS(Certified Software Test Specialist)

- 국내자격증이며 TTA에서 주관

 

ISTQB

- 국제자격증이며 KTB 주관, 영어객관식이며 Foundation Level/Advanced Level