단위 모듈 구현

단위 모듈(Unit Module)의 개요

단위 모듈은 소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것이다.

• 단위 모듈로 구현되는 하나의 기능을 단위 기능이라고 부른다.
• 단위 모듈은 사용자나 다른 모듈로부터 값을 전달받아 시작되는 작은 프로그램을 의미하기도 한다.
• 두 개의 단위 모듈이 합쳐질 경우 두 개의 기능을 구현할 수 있다.
• 단위 모듈의 구성 요소에는 처리문, 명령문, 데이터 구조 등이 있다.
• 단위 모듈은 독립적인 컴파일이 가능하며, 다른 모듈에 호출되거나 삽입되기도 한다.
• 단위 모듈은 다음의 순서로 구현한다.
  • 단위 기능 명세서 작성 ➡️ 입출력 기능 구현 ➡️ 알고리즘 구현

단위 기능 명세서 작성

• 단위 기능 명세서를 작성하는 단계에서는 복잡한 시스템을 단순하게 구현하기 위한 추상화 작업이 필요하다.
• 단위 기능 명세서를 작성하는 단계에서는 대형 시스템을 분해하여 단위 기능을 구분하고 각 기능들을 계층적으로 구성하는 구조화 과정을 거친다.
• 단위 기능 명세서 작성 시 모듈의 독립적인 운용과 한 모듈 내의 정보가 다른 모듈에 영향을 주지 않도록 정보 은닉의 원리를 고려한다.

입출력 기능 구현

• 입출력 기능 구현 단계에서는 단위 모듈 간의 연동 또는 통신을 위한 입출력 데이터를 구현한다.
• 입출력 기능 구현 시 사용자 인터페이스인 CLI, GUI와의 연동을 고려한다.
• 입출력 기능 구현 시 네트워크나 외부 장치와의 입출력은 무료로 공개되어 있는 Open Source API를 이용하면 간편하게 구현할 수 있다.

IPC(Inter-Process Communication)

IPC는 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합으로 복수의 프로세스를 구행하며 이뤄지는 프로세스 간 통신까지 구현이 가능하다.

IPC의 대표 메소드 5가지는 다음과 같다.

• Shared Memory
  • 다수의 프로세스가 공유 가능한 메모리를 구성하여 프로세스 간 통신을 수행
• Socket
  • 네트워크 소켓을 이용하여 네트워크를 경유하는 프로세스들 간 통신을 수행
• Semaphores
  • 공유 자원에 대한 접근 제어를 통해 프로세스 간 통신을 수행
• Pipes&named Pipes
  • 'Pipe'라고 불리는 선입선출 형태로 구성된 메모리를 여러 프로세스가 공유하여 통신을 수행
  • 하나의 프로세스가 Pipe를 이용중이라면 다른 프로세스는 접근할 수 없음
• Message Queueing
  • 메시지가 발생하면 이를 전달하는 형태로 프로세스 간 통신을 수행

알고리즘 구현

알고리즘 구현 단계에서는 구현된 단위 기능들이 사용자의 요구와 일치하는지 확인하는 과정이 필요하다.

• 디바이스 드라이버 모듈
  • 하드웨어 주변 장치의 동작을 구현한 모듈
• 네트워크 모듈
  • 네트워크 장비 및 데이터 통신을 위한 기능을 구현한 모듈
• 파일 모듈
  • 컴퓨터 내부의 데이터 구조 영역에 접근하는 방법을 구현한 모듈
• 메모리 모듈
  • 파일을 프로세스의 가상 메모리에 매핑/해제하는 방법, 프로세스 사이의 통신 기능을 구현한 모듈
• 프로세스 모듈
  • 하나의 프로세스 안에서 다른 프로세스를 생성하는 방법을 구현한 모듈

단위 모듈 테스트

• 단위 모듈 테스트는 단위 테스트(Unit Test)라고도 하며 화이트박스 테스트와 블랙박스 테스트 기법을 사용한다.
  • 화이트박스 테스트 : 모듈의 소스 코드를 오픈시킨 상태에서 소스 코드의 모든 논리적인 경로를 테스트
    • 모듈의 모든 문장을 한 번 이상 실행함으로써 수행됨
    • 테스팅 과정의 초기에 적용되며 모듈 안의 작동을 직접 관찰
    • 설계된 절차에 초점을 둔 구조적 테스트로 프로시저 설계의 제어 구조를 사용하여 테스트 케이스를 설계
  • 블랙박스 테스트 : 소프트웨어가 수행할 특정 기능이 완전히 작동되는 것을 인증하는 테스트
    • 사용자의 요구사항 명세를 보면서 진행하는 테스트로 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 DB 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용됨
    • 테스팅 과정의 후반부에 적용되며 소프트웨어 인터페이스에서 실시됨
• 단위 모듈 테스트를 수행하기 위해서는 모듈을 단독적으로 실행할 수 있는 환경과 테스트에 필요한 데이터가 모두 준비되어야 한다.
• 모듈의 통합 이후에는 오랜 시간 추적해야 발견할 수 있는 에러들도 단위 모듈 테스트를 수행하면 쉽게 발견하고 수정할 수 있다.
• 단위 모듈 테스트의 기준은 단위 모듈에 대한 코드이므로 시스템 수준의 오류는 잡아낼 수 없다.

테스트 케이스(Test Case)

테스트 케이스는 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서로 명세 기반 테스트의 설계 산출물에 해당된다.

• 단위 모듈을 테스트하기 전에 테스트에 필요한 입력 데이터, 테스트 조건, 예상 결과 등을 모아 테스트 케이스를 만든다.
• 테스트 케이스를 이용하지 않고 수행하는 직관적인 테스트는 특정 요소에 대한 검증이 누락되거나 불필요한 검증의 반복으로 인해 인력과 시간을 낭비할 수 있다.

ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스의 구성 요소는 다음과 같다.

식별자(Identifier)	항목 식별자, 일련 번호
테스트 항목(Test Item)	테스트 대상(모듈 또는 기능)
입력 명세(Input Specification)	입력 데이터 또는 테스트 조건
출력 명세(Output Specification)	테스트 케이스 수행 시 예상되는 출력 결과
환경 설정(Environmental Needs)	필요한 하드웨어나 소프트웨어의 환경
특수 절차 요구(Special Procedure Requirement)	테스트 케이스 수행 시 특별히 요구되는 절차
의존성 기술(Inter-case Dependencies)	테스트 케이스 간의 의존성

테스트 프로세스 5단계

1. 계획 및 제어 단계
   • 테스트 목표를 달성하기 위한 계획을 수립하고 계획대로 진행되도록 제어하는 단계
2. 분석 및 설계 단계
   • 테스트 목표를 구체화하여 테스트 시나리오와 테스트 케이스를 작성하는 단계
3. 구현 및 실현 단계
   • 효율적인 테스트 수행을 위해 테스트 케이스들을 조합하여 테스트 프로시저에 명세하는 단계
   • 모듈의 환경에 적합한 단위 테스트 도구를 이용하여 테스트를 수행하는 단계
4. 평가 단계
   • 테스트가 계획과 목표에 맞게 수행되었는지 평가하고 기록하는 단계
5. 완료 단계
   • 이후의 테스트를 위한 참고 자료 및 테스트 수행에 대한 증거 자료로 활용하기 위해 수행 과정과 산출물을 기록 및 저장하는 단계

---

화이트박스 테스트의 종류

• 기초 경로 검사(Base Path Testing)
  • 대표적인 화이트박스 테스트 기법으로 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법이다.
  • 테스트 측정 결과는 실행 겨로의 기초를 정의하는 데 지침으로 사용된다.
• 제어 구조 검사(Control Structure Testing)
  • 조건 검사(Condition Testing) : 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
  • 루프 검사(Loop Testing) : 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
  • 데이터 흐름 검사(Data Flow Testing) : 프로그램에서의 변수의 정의와 사용 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

화이트박스 테스트의 검증 기준

• 문장 검증 기준(Statement Coverage)
  • 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계
• 분기 검증 기준(Branch Coverage)
  • 결정 검증 기준(Decision Coverage)라고도 불리며 소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
• 조건 검증 기준(Condition Coverage)
  • 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
• 분기/조건 기준(Branch/Condition Coverage)
  • 분기 검증 기준과 조건 검증 기준을 모두 만족하는 설계
  • 조건문이 True인 경우와 False인 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스 설계

블랙박스 테스트의 종류

• 동치 분할 검사(Equivalence Partitioning Testing, 동치 클래스 분해)
  • 입력 자료에 초점을 맞춰 테스트 케이스(동치 클래스)를 만들고 검사하는 기법
  • 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고 해당 입력 자료에 맞는 결과가 출력되는 확인하는 기법
• 경계값 분석(Boundary Value Analysis)
  • 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법
  • 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법
• 원인-효과 그래프 검사(Cause-Effect Graphing Testing)
  • 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
• 오류 예측 검사(Error Guessing)
  • 과거의 경험이나 확인자의 감각으로 테스트하는 기법
  • 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아내는 일련의 보충적 검사 기법
• 비교 검사(Comparison Testing)
  • 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 확인하는 기법