정보처리기사 실기 7장 애플리케이션 테스트 관리 요점 정리

1. 애플리케이션 테스트

● 개념 : 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차

- SW가 고객의 요구 사항을 만족시키는지 확인(Validation) => 사용자 입장, 결과

- SW가 기능을 정확히 수행하는지 검증 및 점검(Verification) => 개발자 입장, 과정

- 테스트 실행 전에 개발한 SW의 유형을 분류하고 특성을 정리해서 중점적으로 테스트할 사항을 정리해야 함

● 애플리케이션 테스트의 필요성

- 프로그램 실행 전에 오류 발견하여 예방 가능, 반복적으로 테스트하므로 신뢰도 향상

- 개발 초기부터 테스트 계획하고 시작하면 단순 오류뿐이 아닌 새로운 오류의 유입도 예방 가능

- 최소한의 시간과 노력으로 많은 결함 찾을 수 있음

● 애플리케이션 테스트의 기본 원리

- 완벽한 SW 테스팅은 불가능

- 결함은 특정 모듈에 집중, 파레토 법칙을 적용

- 동일 테스트 케이스로 동일한 테스트 반복 시 살충제 패러독스 현상 발생하므로 테스트 케이스를 지속적으로 보완 및 개선해야 함

- 정황에 따라 테스트 결과 다르므로 정황(Context)에 따라 테스트를 다르게 수행

- SW 결함이 없어도 사용자 요구 사항 충족 X 시 SW 품질 높다고 할 수 없음 => 오류-부재의 궤변

- 테스트와 위험은 반비례, 테스트는 작은 부분에서 시작하여 점점 확대, 개발자와 관계없는 별도의 팀에서 수행

● 파레토 법칙 : 테스트로 발견된 80%의 오류는 20% 모듈에서 발견되므로 20%의 모듈을 집중적으로 테스트하여 효율적으로 오류를 찾자는 것

● 살충제 패러독스 : 살충제를 지속적으로 뿌리면 벌레가 내성이 생겨 죽지 않는 현상을 의미 

 

2. 애플리케이션 테스트의 분류

​- 프로그램 실행 여부에 따라

┌ 정적 테스트 : 프로그램 실행하지 않고 명세서 소스코드 대상으로 분석하는 테스트, SW 개발 초기에 결함 발견 가능으로 비용 낮추는데 용이

- 워크스루 : SW 개발자의 작업 내역을 개발자가 모집한 전문가들이 검토하는 것, SW 검토를 위해 미리 준비된 자료를 바탕으로 정해진 절차에 따라 평가, 오류의 조기 검출을 목적으로 하며 발견된 오류는 문서화함

- 인스펙션 : 워크스루의 형태를 발전시킨 형태로, SW 개발 단계에서 산출된 결과물의 품질을 평가하며 이를 개선하기 위한 방법 등을 제시

- 코드 검사

└ 동적 테스트 : 프로그램 실행하여 오류를 찾는 테스트로 SW 개발의 모든 단계에서 테스트 수행

    ex) 블랙박스 테스트, 화이트박스 테스트

● 테스트 기반에 따른 테스트

┌ 명세 기반 테스트 : 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인하는 테스트

    ex) 동등 분할, 경계 값 분석 등

├ 구조 기반 테스트 : SW 내부의 논리 흐름에 따라 테스트 케이스 작성하고 확인하는 테스트

    ex) 구문 기반, 결정 기반, 조건 기반 등

└ 경험 기반 테스트 : 테스터의 경험을 기반으로 수행하는 테스트, 명세가 불충분하거나 시간 제약이 있는 경우 효과적

    ex) 에러 추정, 체크 리스트, 탐색적 테스팅

● 시각에 따른 테스트

- 테스트 시 누구를 기준으로 하냐에 따라

- 검증(Verification) : 개발자의 시각에서 제품의 생산 과정을 테스트하는 것으로, 제품이 명세서대로 완성됐는지를 테스트

- 확인(Validation) : 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것으로, 사용자가 요구한 대로 제품이 완성되었는지, 제품이 정상적으로 동작하는지를 테스트

● 목적에 따른 테스트

- 회복, 안전, 강도(과부하 시에도 SW 정상 실행), 성능(응답 시간, 처리량), 구조(논리적인 경로, 소스코드의 복잡도 평가),

회귀(결함이 없음을 확인 테스트), 병행(비교 테스트)

 

3. 테스트 기법에 따른 애플리케이션 테스트

● 화이트박스 테스트 : 모듈의 원시 코드를 오픈시킨 상태에서 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법

- 설계된 절차에 초점을 둔 구조적 테스트, 테스트 초기에 적용

- 모듈의 모든 문장을 한 번 이상 실행함으로써 수행

- 분기점 부분들을 수행함으로써 논리적 경로 제어함

● 화이트박스 테스트 종류

┌ 기초 경로 검사 : 대표적 화이트박스 테스트 기법, 논리적 복잡성 측정 가능, 테스트 결과는 실행 경로의 기초를 정의

└ 제어 구조 검사 : 조건 검사(논리적 조건을 테스트), 루프 검사(반복 구조에 초점),

                         데이터 흐름 검사(변수의 정의와 변수 사용에 초점)

● 화이트박스 테스트의 검증 기준 : 얼마나 적정한지를 판단하는 기준

- 문장 검증 기준 : 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계

- 분기 검증 기준 : 소스 코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계

- 조건 검증 기준 : 소스 코드의 모든 조건문에 대해 조건이 True, False인 경우가 한 번 이상 수행되도록

                        테스트 케이스 설계

- 분기/조건 기준 : 소스 코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True, False인 경우가

                        한 번 이상 수행되도록 테스트 케이스 설계

● 블랙박스 테스트 : SW가 수행할 특정 기능 알기 위해 각 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트로 기능 테스트라고도 함

- 사용자 요구 사항 명세를 보면서 테스트, 주로 구현된 기능 테스트, SW 인터페이스에서 실시되는 테스트,

  테스트 후반부에 적용

● 블랙박스 테스트 종류

┌ 동치 분할 검사 : 입력 자료에 초점, 입력 조건 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트

├ 경곗값 분석 : 입력 자료에 치중한 동치 분할 보완, 경곗값을 테스트 케이스로 선정

├ 원인-효과 그래프 검사 : 입력 데이터 간의 관계와 출력에 영향 미치는 상황 체계적으로 분석 후 효용성이 높은 테스트 케이스 작성

├ 오류 예측 검사 : 과거의 경험이나 확인자의 감각으로 테스트, 보충적 검사 기법, 데이터 확인 검사

└ 비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료 제공하여 동일한 결과가 출력되는지 테스트

​

4. 개발 단계에 따른 애플리케이션 테스트

- 개발 단계에서부터 테스트 수행하므로 SW에 포함된 코드 상의 오류뿐 아닌 요구 분석의 오류, 설계 인터페이스 오류도 발견 가능

SW 생명 주기의 V-모델

● 단위 테스트 : 코딩 직후 SW 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스팅

- 사용자 요구 사항 기반으로 한 기능성 테스트를 최우선으로 수행

┌ 구조 기반 테스트(주로 사용) : 프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트 시행 // 목적 : 제어 흐름, 조건 결정

└ 명세 기반 테스트 : 목적 및 실행 코드 기반의 블랙박스 테스트 시행 // 목적 : 동등 분할, 경곗값 분석

● 통합 테스트 : 단위 테스트 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트 의미

- 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류를 검사

● 시스템 테스트 : 개발된 SW가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트

- 환경적인 장애 리스크를 최소화하기 위해 실사용 환경과 유사한 테스트 환경서 테스트 수행

┌ 기능적 요구사항 : 명세서 기반의 블랙박스 테스트 시행

└ 비기능적 요구사항 : 구조적 요소에 대한 화이트박스 테스트 시행

● 인수 테스트 : 개발한 SW가 사용자의 요구 사항을 충족하는지에 중점을 두고 테스트하는 방법

- 사용자가 직접 테스트, 문제 X 시 사용자 SW 인수하고 프로젝트 종료 => 사용자 관점

- 사용자 인수 테스트(사용자가 적절성 여부 확인), 운영상의 //(시스템 관리자가 시스템 인수 시 수행 테스트),

계약 //, 규정 //, 알파 테스트(사용자가 개발자 앞에서 테스트, 통제된 환경),

베타 테스트(선정 사용자가 여러 명 사용자 앞에서 테스트, 통제 X 환경)

 

5. 통합 테스트 : 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법

┌ 비점진적 통합 방식 : 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 잇는 프로그램 전체를 테스트, 빅뱅 통합 테스트, 규모 작으면 유리하고 단시간 내에 테스트 가능, 오류 발견 및 장애 위치 파악 및 수정이 어렵다

└ 점진적 통합 방식 : 모듈 단위로 단계적으로 통합하면서 테스트하는 방법, 하향식, 상향식, 혼합식 통합이 있음, 오류 수정 용이, 인터페이스와 관련된 오류를 완전히 테스트할 가능성 높음

● 하향식 통합 테스트 : 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트

- 깊이 우서 통합 법, 넓이 우선 통합 법 사용

- 테스트 초기부터 시스템 구조 보여줄 수 있음

- 상위 모듈에서는 테스트 케이스 사용 어렵

- 절차

① 주요 제어 모듈은 작성된 프로그램 사용, 주요 제어 모듈의 종속 모듈들은 스텁으로 대체

② 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체됨

③ 모듈이 통합될 때마다 테스트 실시

④ 새로운 오류 발생 X 보장 위해 회귀 테스트 실시

- 테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈

● 상향식 통합 테스트 : 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트

- 스텁 필요 X, 종속 모듈의 그룹인 클러스터 필요

- 절차

① 하위 모듈들을 클러스터로 결합

② 상위 모듈에서 데이터의 입출력을 확인하기 위해 더미 모듈인 드라이버 작성

③ 통합된 클러스터 단위로 테스트

④ 테스트 완료 시 클러스터는 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체된다.

● 혼합식 통합 테스트

: 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트틀 지원하는 방식 => 샌드위치 통합 테스트라고도 함

● 회귀 테스팅 : 이미 테스트된 프로그램의 테스팅을 반복하는 것으로, 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트

- 새로운 오류가 발생하지 않음을 보증하기 위해 반복 테스트

- 변경된 부분을 테스트할 수 있는 테스트 케이스만을 선정하여 수행

 

6. 애플리케이션 테스트 프로세스

 : 개발된 SW가 사용자의 요구대로 만들어졌는지, 결함은 없는지 등을 테스트하는 절차

- 테스트 계획서 : 테스트 수행을 계획한 문서

- 테스트 케이스 : 테스트 항목의 명세서

- 테스트 시나리오 : 동작 순서 기술한 문서

- 테스트 결과서 : 테스트 결과를 비교 · 분석한 내용을 정리한 문서

● 순서

① 테스트 계획 : 테스트 목표를 정의하고 테스트 대상 및 범위를 결정

- 테스트 대상 시스템 구조 파악, 테스트에 투입되는 조직 및 비용 산정

- 테스트 시작(모든 조건 만족 X여도 시작) 및 종료 조건(중요도에 따라 테스트 종료 조건을 다르게 정의 가능)을 정의

② 테스트 분석 및 디자인 : 테스트의 목적과 원칙 검토하고 사용자의 요구 사항 분석

- 테스트에 대한 리스크 분석 및 우선순위 결정

- 테스트 데이터(시스템의 기능이나 적합성 등을 테스트하기 위해 만든 데이터 집합으로, SW 기능을 차례대로 테스트 가능), 테스트 환경, 테스트 도구 등을 준비

③ 테스트 케이스 및 시나리오 작성 : 테스트 케이스의 설계 기법에 따라 테스트 케이스를 작성하고 검토 및 확인한 후 테스트 시나리오를 작성

- 테스트용 스크립트 작성

④ 테스트 수행 : 테스트 환경 구축 후 테스트 수행

- 테스트 실행 결과를 측정하여 기록

⑤ 테스트 결과 평가 및 리포팅 : 테스트 결과를 비교 분석하여 테스트 결과서를 작성

- 결함 중점적으로 기록, 테스트 종료 시 평가 수행하고 실행 절차 최적화하여 다음 테스트에 적용

⑥ 결함 추적 및 관리 : 테스트를 수행 후 결함이 어디에서 발생했는지, 어떤 종류의 결함인지 등 결함을 추적하고 관리

- 동일 결함 발견 시 처리 시간 단축 및 경함의 재발 방지 가능

​

7. 테스트 케이스/테스트 시나리오/ 테스트 오라클

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

- 테스트 케이스 미리 작성 시 오류 방지 가능, 인력 및 시간 등의 낭비 줄일 수 있음

● 테스트 케이스 작성 순서

① 테스트 계획 검토 및 자료 확보

② 위험 평가 및 우선순위 결정

③ 테스트 요구 사항 정의

④ 테스트 구조 설계 및 테스트 방법 결정

⑤ 테스트 케이스 정의

⑥ 테스트 케이스 타당성 확인 및 유지 보수

● 테스트 시나리오 : 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합으로, 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서

- 테스트 순서를 미리 정함으로써 테스트 항목 빠짐없이 수행 가능

● 테스트 시나리오 작성 시 유의 사항

- 여러 개의 시나리오로 분리하여 작성해야 함

- 사용자의 요구 사항과 설계 문서 등을 토대로 작성해야 함

- 유스케이스간 업무 흐름이 정상적인지를 테스트할 수 있도록 작성

- 개발된 모듈 or 프로그램 간의 연계가 정상적으로 동작하는지 테스트할 수 있도록 작성

● 테스트 오라클 : 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하어 비교하는 기법 및 활동

- 결과를 판단하기 위해 테스트 케이스에 대한 예상 결과를 계산하거나 확인

- 특징 : 제한된 검증, 수학적 기법, 자동화 기능

● 테스트 오라클의 종류

- 참 오라클 : 모든 오류 검출 가능 ex) 항공기, 은행, 발전소 SW 등 미션 크리티컬 한 업무에 사용

- 샘플링 오라클 : 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과 제공 ex) 일반적 업무, 게임, 오락 등

- 추정 오라클 : 샘플링 오라클 개선, 샘플링 오라클 + 나머지 입력 값들에 대해서는 추정으로 처리 ex) 샘플링과 같음

- 일관성 검사 오라클 : 애플리케이션 변경 있을 때 테스트 케이스의 수행 전과 후의 결괏값이 동일한지 확인하는 오라클

 

8. 테스트 자동화 도구

●테스트 자동화의 개념 : 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용함으로써 쉽고 효율적으로 테스트 수행 가능

- 휴먼 에러 줄이고, 정확성을 유지하면서 품질 향상 가능

- 장점 : 인력 및 시간 ↓, 향상된 테스트 품질 보장, 일관성, 객관적 평가 기준, 다양한 표시 형태,

          UI 없는 서비스 정밀 테스트 가능

- 단점 : 교육 및 학습 필요, 시간 · 비용 · 노력이 필요, 비공개 상용 도구의 경우 추가 비용 필요

● 테스트 자동화 수행 시 고려 사항

- 재사용 및 측정이 불가능한 것 제외

- 모든 테스트 과정 자동화 가능 도구 없으므로 용도에 맞는 적절한 도구 선택해서 사용

- 자동화 도구의 환경 설정 및 습득 기간을 고려하여 프로젝트 일정 계획

- 반드시 프로젝트 초기에 테스트 엔지니어 투입 시기를 계획해야 함

● 테스트 자동화 도구의 유형

: 정적 분석 도구, 테스트 실행 도구, 성능 테스트 도구, 테스트 통제 도구, 테스트 하네스 도구(테스트를 지원하기 위해 생성된 코드와 데이터를 의미, 시뮬레이션하여 컴포넌트 및 모듈이 정상적으로 테스트

되도록 함)

 

9. 결함 관리

: 오류 발생, 작동 실패 등과 같이 SW가 개발자가 설계한 것과 달리 동작하거나 다른 결과가 발생되는 것을 의미

- 사용자가 예상한 결과와 실행 결과 간의 차이, 업무 내용과의 불일치 등으로 인해 변경이 필요한 부분도 모두 결함에 해당

● 결함 관리 프로세스

결함 관리 프로세스 흐름도

● 결함 상태 추적

- 발견된 결함은 지속적으로 상태 변화를 추적하고 관리

- 향후 결함이 발견될 모듈 또는 컴포넌트 추정 가능

- 결함 관리 측정 지표 : 결함 분포(결함 수 측정), 결함 추세(결함 수의 추이 분석), 결함 에이징(특정 결함 상태로 지속되는 시간 측정)

● 결함 추적 순서                                                                                       // 결함 종료 후 결함 해제

                                                                                                          ┌ 재오픈을 준비 중 상태

결함 추적 순서

● 결함 분류

: 시스템 결함(애플리케이션 환경, DB 처리에서 발생), 기능 결함(기획, 설계, 업무, 시나리오서 유입 결함),

  GUI 결함(사용자 화면 설계 시 발생 결함), 문서 결함(의사소통 및 기록이 원활치 않아 발생 결함)

● 결함 심각도

: High(진행 X), Medium(시스템 흐름에 영향 미치는 결함), Low(시스템 흐름에는 영향 미치지 않는 결함)

● 결함 우선순위 : 발견된 결함 처리에 대한 신속성을 나타내는 척도, 결함의 중요도와 심각도에 따라 설정되고 수정 여부 결정

- 심각도가 높다고 반드시 우선순위가 높은 건 아님

● 결함 관리 도구

- Mantis : 결함 및 이슈 관리 도구로, SW 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적도 가능한 도구

- Trac : 결함 추적은 물론 결함을 통합하여 관리할 수 있는 도구

- Redmine : 프로젝트 관리 및 결함 추적이 가능한 도구

- Bugzilla : 결함 신고, 확인, 처리 등 결함을 지속적으로 관리할 수 있는 도구로, 결함의 심각도와 우선순위를 지정 가능

​

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

● 애플리케이션 성능 : 사용자가 요구한 기능을 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도

- 측정 지표

- 처리량(Throughout)

- 응답 시간(Response Time)

- 경과 시간(Turn Around Time)

- 자원 사용률(Resource Usage)

● 성능 테스트 도구 : 애플리케이션 성능을 테스트하기 위해 부하나 스트레스를 가해 성능 측정 지표를 점검하는 도구

- JMeter : HTTP, FTP 등 다양한 프로토콜 지원하는 부하 테스트 도구

- LoadUI : 서버 모니터링, Drag & Drop 등 사용자의 편리성이 강화된 부하 테스트 도구, HTTP, JDBC 등 다양한 프로토콜 지원

- OpenSTA : HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구

● 시스템 모니터링 도구 : 애플리케이션 실행 중 시스템 자원의 사용량을 확인하고 분석하는 도구

- 안정적으로 운영할 수 있는 기능 제공

- Scouter : 단일 뷰 통합/실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 구현, 애플리케이션의 성능을 모니터링/통제하는 도구

- Zabbix : 웹 기반 서버, 서비스, 애플리케이션 등의 모니터링 도구

● 애플리케이션 성능 저하 원인 분석

- 애플리케이션을 DB에 연결하기 위해 커넥션 객체를 생성하거나 쿼리를 실행하는 애플리케이션 로직에서 많이 발생

- DB에 필요 이상 많은 데이터 요청한 경우

- 커넥션 풀의 크기를 너무 작거나 크게 설정하면 애플리케이션의 성능 저하 현상이 발생

- 대량의 파일 업로드 or 다운로드하여 처리 시간이 길어진 경우

- 애플리케이션에 연결된 데이터베이스의 락으로 인한 성능 저하

 

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

● 소스코드 최적화 : 나쁜 코드(로직 복잡, 스파게티 코드) 배제, 클린 코드(잘 작성된 코드)로 작성

- 클린 코드 작성 원칙 : 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화

● 소스코드 최적화 유형

- 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 수행, 응집도 높이고, 크기를 작게 작성

- 느슨한 결합(Loosely Couple) : 인터페이스 클래스를 이용하여 추상화된 자료 구조와 메소드 구현함으로써 클래스 간의 의존성 최소화

- 코딩 형식 준수 : 줄 바꿈 사용, 종속 함수 사용, 호출하는 함수 선배치, 호출되는 함수 후 배치, 지역 변수는 맨 처음에 선언

- 좋은 이름 사용 : 기본적인 이름 명명 규칙을 정의하고 규칙에 맞는 이름 사용

- 적절한 주석 문 사용

● 소스 코드 품질 분석 도구

┌ 정적 분석 도구 : 작성 소스 코드 실행 X, 코딩 스타일, 결함 등을 확인, 개발 초기 결함 찾는 데 사용, 완료 시점에서는 소스 코드 품질 검증, 동적 분석 도구로는 발견하기 어려운 결함 찾고, 소스 코드에서 코딩의 복잡도, 모델 의존성, 불일치성 분석

- pmd : 소스 코드에 대한 미사용 변수, 최적화되지 않은 코드 등 결함을 유발할 수 있는 코드를 검사

- cppcheck : C/C++ 코드에 대한 메모리 누수, 오버플로우 등 분석

- SonarQube : 중복 코드, 복잡도, 코딩 설계 등을 분석하는 소스 분석 통합 플랫폼

- checkstyle : Java 코드에 대해 소스 코드 표준을 따르고 있는지 검사, 다양한 개발 도구에 통합하여 사용 가능

- ccm : 다양한 언어의 코드 복잡도를 분석

- cobertuna : Java의 소스 코드 복잡도 분석 및 테스트 커버리지를 측정

└ 동적 분석 도구 : 작성한 소스 코드 실행, 메모리 누수, 스레드 결함 등을 분석하는 도구

- Avalanche : Valgrind 프레임워크 및 STP 기반으로 구현됨

- Valgrind : 프로그램 내에 존재하는 메모리 및 스레드 결함 등을 분석

● 스레드 : 프로세스 내에서의 작업 단위로서 시스템의 여러 자원을 할당받아 실행하는 프로그램의 단위를 의미