CHAPTER 02 - 애플리케이션 통합 테스트, CHAPTER 03 - 애플리케이션 성능 개선

2024년도 수제비 실기책(6판) 내용

---

CHAPTER 02 - 애플리케이션 통합 테스트

---

1. 애플리케이션 테스트 수행

1) 단위 테스트(Unit Test)

• 개별적인 모듈(또는 컴포넌트)을 테스트하며 구현 단계에서 각 모듈을 구현한 후 수행함
• 개별적인 모듈에 대해 컴포넌트 테스트를 수행하려면 모듈을 단독으로 실행 할 수 있는 테스트 베드(Test Bed)라는 환경이 필요함

(1) 단위 테스트 수행 도구

구분	설명
테스트 드라이버 Test Driver	- 모듈 테스트 수행 후의 결과를 도출하는 시험용 모듈 - 필요 테스트를 인자를 통해 넘겨주고, 테스트 완료 후 그 결괏값을 받는 역할을 하는 가상의 모듈 - 하위 모듈을 호출하는 상위 모듈의 역할
테스트 스텁 Test Stub	- 일시적으로 필요한 조건만을 가지고 임시로 제공되는 시험용 모듈 - 상위 모듈에의해 호출되는 하위 모듈의 역할

2) 통합 테스트(Integration Test)

• 소프트웨어 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
• 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지를 확인하는 테스트

(1) 하향식 통합 테스트(Top Down Integration Test)

 

• 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
• 하위 모듈에서 반환 값을 전달하기 위한 더미 모듈인 스텁을 사용함

(2) 상향식 통합 테스트(Bottom Up Integration Test)

 

• 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
• 상위 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈인 드라이버(Driver)를 사용함

(3) 빅뱅 통합 테스트(Big Bang Integration Test)

 

• 모든 모듈을 동시에 통합한 후 테스트하는 기법이며 작은 시스템에 유리함
• 드라이버/스텁 없이 실제 모듈로 테스트를 수행함

(4) 샌드위치 통합 테스트(Sandwich Integration Test)

 

• 상향식 통합 테스트와 하향식 통합 테스트 방식을 결합한 테스트 방식
• 하위 프로젝트가 있는 큰 규모의 통합 테스트에서 사용하는 방식이며 병렬 테스트가 가능하고 시간 절약이 가능함
• 스텁과 드라이버의 필요성이 매우 높은 방식

3) 테스트 자동화 도구

• 테스트 도구를 활용하여 반복적인 테스트 작업을 스크립트 형태로 구현함으로써 쉽고 효율적인 테스트를 수행할 수 있는 방법

(1) 테스트 자동화 도구의 장단점

장점	단점
- 반복되는 테스트 데이터 재입력 작업의 자동화 - 사용자 요구 기능의 일관성 검증에 유리 - 테스트 결괏값에 대한 객관적인 평가 기준 제공 - 테스트 결과의 통계 작업과 그래프 등 다양한 표시 형태 제공 - UI가 없는 서비스의 경우에도 정밀한 테스트 가능	- 도구 도입 후 도구 사용 방법에 대한 교육 및 학습 필요 - 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력이 필요 - 상용 도구의 경우 고가, 유지 관리 비용이 높아 추가 투자가 필요

 

(2) 테스트 자동화 도구 유형

 

[1] 정적 분석 도구(Static Analysis Tools)

 

• 만들어진 애플리케이션을 실행하지 않고 분석하는 도구
• 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함을 발견하기 위하여 사용함
• 테스트를 수행하는 사람이 작성된 소스 코드에 대한 이해를 바탕으로 도구를 이용해서 분석하는 것을 마랗ㅁ

[2] 성능 테스트 도구(Performance Test Tools)

 

• 애플리케이션의 처리량, 응답 시간, 경과 시간, 자원 사용률에 대해 가상의 사용자를 생성하고 테스트를 수행함으로써 성능 목표를 달성하였는지를 확인하는 도구

(3) 테스트 하네스(Test Harness)(드스슈케시스목)

 

• 시스템 모듈의 테스트를 위해 테스트를 자동화하거나 제어하기 위한 코드 및 도구의 집합

구성요소	설명
테스트 드라이버 (Test Driver)	상위 모듈에서 데이터의 입력과 출력을 확인하기 위한 더미 모듈
테스트 스텁 (Test Stub)	하위 모듈에서 반환 값을 전달하기 위한 더미 모듈
테스트 슈트 (Test Suite)	테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합
테스트 케이스 (Test Case)	입력값, 실행 조건, 기대 결과 등의 집합
테스트 시나리오 (Test Scenario)	애플리케이션의 테스트 되어야 할 기능 및 특징, 테스트가 필요한 상황을 작성한 문서 하나의 단일 테스트 시나리오가 하나 또는 여러 개의 테스트 케이스들을 포함할 수 있음
테스트 스크립트 (Test Script)	자동화된 테스트 실행 절차에 대한 명세
목 오브젝트(Mock Object)	사용자의 행위를 조건부로 사전에 입력해 두면, 그 상황에 예정된 행위를 수행하는 객체

---

2. 애플리케이션 테스트 결함

1) 결함(Defect)

• 개발자 오류로 인해 만들어지는 문서 또는 코딩상의 결점으로 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 현상

용어	설명
오류 (Error)	결함의 원인이 되는 것으로 일반적으로 사람에 의해 생성된 실수(Human Mistake)
결점 (Fault)	소프트웨어 개발 활동을 수행함에 있어서 시스템이 고장을 일으키게 하며 오류가 있는 경우 발생하는 현상
버그 (Bug)	프로그램 오류로 인해 예상치 못한 결과가 나는 현상
고장(Failure) / 문제(Problem)	소프트웨어 제품에 포함된 결함이 실행될 때 발생하는 현상

2) 결함 관리

• 단계별 테스트 수행 후 발생한 결함의 재발 방지와 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적하고 관리하는 활동

(1) 결함 생명주기

결함 상태	설명
결함 등록 (Open)	- 테스터가 테스트 절차를 실행하여 발견한 결함을 분석 후 구체화, 고립화, 일반화한 결함으로서 보고된 상태 - 결함 보고서에 기록되어 결함 추적의 대상이 된 상태
결함 검토 (Reviewed)	- Open된 결함의 처리 방안을 검토하는 상태 - 각 결함은 위험성(발생 가능성, 심각성, 긴급성)을 바탕으로 이번에 수정되거나(Assigned 상태로 이동), 다음 릴리스에서 수정(Defereed 상태로 이동) 되거나 무시(Closed 상태로 이동) 될 수 있음
결함 할당 (Assigned)	결함을 수정할 개발자가 결정되고, 그 개발자에게 결함 해결이 요구된 상태
결함 수정 (Resolved)	개발자가 자신에게 할당된 수정 사항에 대한 해결을 처리한 상태
결함 확인 (Verified)	개발자의 결함 처리가 합당한지, 정확한지 검증이 완료된 상태
결함 종료 (Closed)	수정된 사항에 대하여 정확한 수정이 이루어졌다고 판단되어 종료된 상태
결함 재등록 (Reopen)	결함이 정확하게 수정되지 않아서 다시 수정을 요구하는 상태
결함 조치 보류 (Deferred)	- Open된 결함을 곧바로 수정하지 않고 다음 릴리스에서 해결하기로 연기된 상태 - Deferred된 결함은 적절한 시점에 Reopen되어 결함 처리가 시작될 수 있음

---

CHAPTER 03 - 애플리케이션 성능 개선

---

1. 애플리케이션 성능 분석

1) 애플리케이션 성능 측정 지표(처응경자)

지표	설명
처리량 (Throughput)	- 애플리케이션이 주어진 시간에 처리할 수 있는 트랜잭션의 수 - 웹 애플리케이션의 경우 시간당 페이지 수로 표현
응답 시간 (Response Time)	- 사용자 입력이 끝난 후, 애플리케이션의 응답 출력이 개시될 때까지의 시간 - 애플리케이션의 경우 메뉴 클릭 시 해당 메뉴가 나타나기까지 걸리는 시간
경과 시간 (Turnaround Time)	애플리케이션에 사용자가 요구를 입력한 시점부터 트랜잭션을 처리 후 그 결과의 출력이 완료할 때까지 걸리는 시간
자원 사용률 (Resource Usage)	애플리케이션이 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량

2) 유형별 성능 분석 도구

구분	설명
성능/부하/스트레스 점검 도구 (Perfomance / Load / Stress)	애플리케이션의 성능 점검을 위해 가상의 사용자를 점검 도구 상에서 인위적으로 생성한 뒤, 시스템의 부하나 스트레스를 통해 성능 측정 지표인 처리량, 응답 시간, 경과 시간 등을 점검하기 위한 도구
모니터링(Monitoring) 도구	- 애플리케이션 실행 시 자원 사용량을 확인하고 분석 가능한 도구 - 성능 모니터링, 성능 저하 원인 분석, 시스템 부하량 분석, 장애 진단 사용자 분석, 용량 산정 등의 기능을 제공하여 시스템의 안정적 운영을 지원하는 도구

---

2. 애플리케이션 성능 개선

1) 소스 코드 최적화

• 읽기 쉽고 변경 및 추가가 쉬운 클린 코드를 작성하는 것으로 소스 코드 품질을 위해 기본적으로 준수해야 할 원칙과 기준을 정의

(1) 배드 코드(Bad Code)

 

• 다른 개발자가 로직을 이해하기 어렵게 작성된 코드
• 처리 로직의 제어가 정제되지 않고 서로 얽혀 있는 스파게티 코드, 변수나 메서드에 대한 이름 정의를 알 수 없는 코드, 동일한 처리 로직이 중복되게 작성된 코드 등이 있음

유형	설명
외계인 코드 (Alien Code)	오래 되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
스파게티 코드 (Spaghetti code)	- 작동은 정상적으로 하지만, 사람이 코드를 읽으면서 그 코드의 작동을 파악하기는 어려운 코드 - 컴퓨터 프로그램의 소스 코드가 복잡하게 얽힌 모습을 스파게티의 면발에 비유한 표현

 

(2) 클린 코드(Clean Code)

 

• 잘 작성되어 가독성이 높고 단순하며 의존성을 줄이고 중복을 최소화하여 깔끔하게 잘 정리된 코드
• 중복 코드 제거로 애플리케이션의 설계가 개선됨
• 가독성이 높으므로 애플리케이션의 기능에 대해 쉽게 이해할 수 있음
• 버그를 찾기 쉬워지며 프로그래밍 속도가 빨라짐

작성 원칙	설명
가독성	이해하기 쉬운 용어를 사용, 코드 작성 시 들여쓰기 기능을 사용
단순성	한 번에 한 가지 처리만 수행, 클래스/메서드/함수를 최소 단위로 분리
의존성 최소	영향도를 최소화, 코드의 변경이 다른 부분에 영향이 없게 작성
중복성 제거	중복된 코드를 제거, 공통된 코드를 사용
추상화	클래스/메서드/함수에 대해 동일한 수준의 추상화 구현, 상세 내용은 하위 클래스/메서드/함수에서 구현

 

(3) 리펙토링(refactoring)

 

• 유지보수 생산성 향상을 목적으로 기능을 변경하지 않고 복잡한 소스 코드를 수정, 보완하여 가용성 및 가독성을 높이는 기법
• 소프트웨어 모듈의 외부적 기능은 수정하지 않고 내부적으로 구조, 관계 등을 단순화하여 소프트웨어의 유지 보수성을 향상시키는 기법

목적	설명
유지 보수성 향상	복잡한 코드의 단순화, 소스의 가독성 향상
유연한 시스템	소프트웨어 요구사항 변경에 유연한 대응
생산성 향상	정제 및 최적화된 소스의 재사용
품질 향상	소프트웨어 오류발견이 용이하여 품질 향상

2) 소스 코드 품질 분석

• 소스 코드에 대한 코딩 스타일, 설정된 코딩 표준, 코드의 복잡도, 코드 내에 존재하는 메모리 누수 현황, 스레드의 결함 등을 발견하기 위한 활동

유형	설명
정적 분석 도구	작성된 소스 코드를 실행시키지 않고, 코드 자체만으로 코딩 표준 준수 여부, 코딩 스타일 적정 여부, 잔존 결함 발견 여부를 확인하는 코드 분석 도구
동적 분석 도구	애플리케이션을 실행하여 코드에 존재하는 메모리 누수 현황을 발견하고 발생한 스레드의 결함 등을 분석하기 위한 도구