2022-12-23 소프트웨어공학_11

 

1. 검증과 확인 프로세스

 

시험에 자주 나오는 Software V&V다.

 

가. 검증 (Verification)

 

소프트웨어가 요구사항 문서에 부합하여 구현되었음을 보장하는 활동.

 

요구사항 명세서에 기술된 대로 제품을 만들어지고 있는지 확인 한다.

 

개발자의 관점에서 제대로 만든 소프트웨어인지 확인.

 

---

나. 확인 (Validation)

 

소프트웨어가 고객의 의도에 따라 구현되었음을 보장하는 활동

 

쓸만한 제품을 만들고 있는 확인한다.

 

고객의 입장에서 제대로 된 제품을 만들고 있는지 확인.

 

---

2. 검증과 확인 기법

 

가. 정적 방법 (Static)

• 소프트웨어를 실행하지 않고 결함을 찾아내는 것
• 대표적 방법 : 검토(review), 검수(inspection), 워크스루(walk-through)
• 여러 참여자가 모여 소프트웨어 개발 산출물을 검토하여 결함을 찾아냄
• 소프트웨어 개발 중 생성되는 모든 산출물에 대해 적용 가능

 

나. 동적 방법 (Dynamic)

• 소프트웨어를 실행하여 결함을 찾아냄
• 대표적 방법: 테스트
• 발견된 결함은 디버깅 활동으로 확인 수정

 

다. 동료 검토 (peer review)

• 소프트웨어 작업 산출물의 결함 또는 개선사항을 발견하기 위해 개발 동료들에 의해 정해진 단계에 따라 수행되는 검토활동
• 동료들이 자신이 만든 산출물을 검토하는 것
• 요구 명세서, 사용자 인터페이스 프로토타입, 아키텍처, 설계 및 기타 기술적 산출물이 대상

 

---

 

3. 소프트웨어 테스트

 

요구된 상태와 개발된 상태 간 차이점을 발견하기 위하여 소프트웨어를 분석하고 평가하는 프로세스.

 

• 에러(error), 오류 : 결함의 원인이 되는 것.
• 결함(defeat), 결점(fault), 버그(bug) : 제거하지 않으면 제품이 일으키게 되는 실패 또는 문제의 원인
• 실패(failure), 문제(problem) : 제품의 결함이 있는 부분이 실행될 경우 발생되는 현상

 

가. 테스트 vs 디버깅

 

 

---

 

나. 테스트 케이스

 

테스트를 진행할 때 특정 요구사항이 제대로 구현되었는지를 검증하기 위하여 테스트 조건, 입력 값, 예상 출력 값, 실제 테스트 결과를 기록하는 것을 뜻한다.

 

테스트 계획 단계에서 미리 테스트 케이스를 작성하고 이를 바탕으로 테스트 수행한다.

---

다. 테스트 종류

 

(1) 블랙박스 테스트

: 내부 구조와 상관없이 요구사항 명세서만으로 테스트 케이스를 추출하고 입출력만으로 평가한다.

 

• 신택스 테스트(syntax test)
  : 입력 데이터의 유형(숫자, 영어, 대문자, 소문자 등)이 올바른지 확인. 가장 간단한 블랙박스 테스트.
• 동등 분할 (equivalence partitioning)
  : 입력 값의 범위가 설정되어 있는 경우에 각 범위를 그룹으로 정하여 대표 값을 활용해 테스트 케이스 생성
• 경계값 분석 (boundary value analysis)
  : 입력 값의 범위가 설정되어 있는 경우에 각 범위의 경계에 위치한 값과 그 주위 값을 테스트 케이스로 추출하는 방법
• 의사결정 테이블 (decision tree)
  : 입출력 값이 True, False로 결정될 수 있는 경우 모든 경우의 수를 확인하는 방법
  : 적은 경우의 수를 가진 입력에 유리

 

---

(2) 화이트박스 테스트

: 프로그램의 내부 구조를 기반으로 테스트 케이스를 추출한다.

 

• 문장 커버리지 (statement coverage)
  : 프로그램을 구성하는 문장이 최소한 한 번은 실행될 수 있는 입력 값을 테스트 케이스로 선정
• 분기 커버리지 (branch coverage)
  : 프로그램 분기를 최소한 한 번은 실행하게 하는 테스팅
• 조건 커버리지 (condition coverage)
  : &&, || 등의 조건을 가진 분기문이 전체 조건식의 결과와 관계없이 && 나 || 전후의 각 개별조건식이 참, 거짓 한 번씩을 갖도록 테스트 케이스를 추출하는 것
• 다중 조건 커버리지 (multiple condition coverage)
  : 조건 커버리지가 각 개별 조건식의 조건을 검사하는 것이라면, 다중 조 건 커버리지는 전체 조건식의 조건을 검사하는 것
• 기본 경로 테스트 (basic path test)
  : 프로그램의 제어구조(control structure)를 플로우 그래프(flow graph)로 표현하고, 순환복잡도(cyclomatic complexity)를 통해 독립적인 경로의 수를 찾아 테스트 케이스를 추출하는 기법

 

순환복잡도를 계산하는 문제가 정처기에 종종 나온다.

 

• CC(cyclomatic complexity): 순환복잡도
• R(region): 노드와 가장자리 노드로 둘러싸인 영역과 그래프 밖 영역의 수
• E(edge): 화살표의 수
• N(node): 노드의 수
• P(predicate): 분기 노드의 수

 

CC = (R의 수) 또는 (E - N + 2) 또는 (P + 1)

 

CC = 3이다.

 

R로 계산하는 것이 가장 편한 것 같다.

 

R은 밖에 모든 영역을 고려해서 항상 1부터 시작이다.

 

---

라. 테스트 단계

 

(1) 단위 테스트 (unit test)

• 구현 단계에서 모듈이 완성되었을 경우 개별적인 모듈을 테스트하는 것
• 화이트박스/블랙박스 테스트 모두 가능

 

단위 테스트를 진행할 경우 해당 모듈과 상호작용할 다른 모듈들이 완성되지 않은 경우가 있다.

 

이 경우 테스트 모듈을 완전하게 실행할 수 있는 가짜 환경을 조성한다.

 

• 스텁(stub)
  : 테스트 대상 모듈에 의해 호출되는 더미(dummy) 프로그램
  : 하향식 테스트에 주로 사용
• 테스트 드라이버(test Driver)
  : 테스트 대상 모듈을 호출하는 더미 프로그램
  : 상향식 테스트에 주로 사용

 

---

(2) 통합 테스트 (integration test)

 

모듈을 통합한 단계에서 수행되는 테스트다.

 

특히 모듈 간 상호작용에 주의하면서 검사한다.

 

• 빅뱅(big bang) 기법
  : 모듈을 한꺼번에 통합하여 테스트하는 방법
  : 오류가 발생하였을 경우 어느 부분에서 오류가 났는지 찾기 어려움
• 하향식(top-down) 기법
  : 가장 상위 모듈부터 하위 모듈로 점진적으로 통합하는 방법
  : 상위 모듈 테스트 시, 하위 모듈에 대한 스텁 사용
• 상향식(bottom-up) 기법
  : 하위 모듈부터 테스트하고 상위 모듈로 점진적으로 통합하는 방법
  : 하위 모듈 테스트 시, 상위 모듈에 대한 테스트 드라이버 사용

 

---

(3) 시스템 테스트 (system test)

 

모듈이 모두 통합된 후, 사용자 요구사항이 만족되었는지 검사하는 단계.

 

고객에게 시스템을 전달하기 전, 시스템을 개발한 조직이 주체가 되는 마지막 테스트다.

 

기능, 비기능 요구사항을 테스트의 대상으로 삼는다.

 

---

(4) 인수 테스트 (acceptance test)

 

시스템이 사용자에게 인수되기 전, 사용자에 의해 실시되는 테스트. (찐막)

 

실제 사용자가 운영하는 환경에서 테스트한다.

 

인수 테스트를 통과해야만 시스템이 정상적으로 사용자에게 인수되고 프로젝트가 종료된다.

 

---