개발

[정보처리산업기사 필기] 애플리케이션

노트북 산 김에 공부 2023. 8. 30. 10:05

애플리케이션 배포(Release) 환경

애플리케이션 배포는 개발자 또는 사용자가 애플리케이션을 실행, 테스트할 수 있도록 컴파일된 프로그램, 실행에 필요한 리소스(이미지, 환경 설정 파일 등)를 서버상의 적합한 위치로 이동하는 작업을 말합니다. 

동작환경이 어떻게 되는가에 따라 웹 서버, WAS로 나눌 수 있습니다.


웹 서버 (Web Server)

웹 콘텐츠를 저장하거나 처리하는 컴퓨터 또는 소프트웨어입니다.

웹 서버 소프트웨어는  HTTP 프로토콜을 통해 클라이언트(웹 브라우저)의 요청 정보를 받아 처리하고 그 결과를 다시 클라이언트에 보냅니다. 클라이언트가 요청하는 자원(리소스)을 URL(Uniform Resource Locator) 형태로 받아 내부 파일 시스템과 매핑하여 처리하거나, URL과 입력 값(ex: 로그인 화면 아이디, 패스워드)을 함께 받으면 사전에 약속된 처리를 한 후 그 결과를 클라이언트에 전달합니다. 

대표적인 웹 서버로는 아파치(Apache), 엔진엑스(nginx), IIS(Internet Information Services) 등이 있습니다.

웹 서버는 애플리케이션 배포 시 이미지, 단순 HTML과 같은 정적인 리소스를 배포하며, 정적 리소스를 빠르고 안정적으로 처리 합니다.

WAS (Web Application Server)

인터넷상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어(소프트웨어 엔진)로서, Server 단에서 Application을 동작할 수 있도록 지원합니다.

웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 됩니다. 


배포 단위

애플리케이션 배포 단위는 단순히 컴파일된 실행 파일 또는 Byte Code를 복사하는 방식 이외에 다양한 단위로 묶음, 패키징을 통해서 배포할 수 있습니다. java의 경우 jar war ear 등의 방식이 있습니다

 

  • jar (Java Archive) : Java 라이브러리, 리소스, property 파일들을 포함합니다. 프로그램에서 참조하는 라이브러리, 구현된 비즈니스 서비스를 배포할 때 jar 단위로 배포합니다.
  • war (Web Archive) : 웹 컨테이너에 배포되는 형식으로, Servlet, jar 파일과 WEB-INF 폴더에 있는 web.xml 파일로 구성됩니다. 웹 컨테이너상에 배포되어 독립적인 UI 단 웹 애플리케이션 서비스를 제공합니다.
  • ear (Enterprise Archive) : jar와 war을 묶어서 하나의 완성된 웹 애플리케이션 서비스를 제공합니다.

형상관리(Configuration Management) 시스템

형상관리 시스템은 서비스 제공 대상 형상항목을 식별하여 기준선(Baseline)을 설정하고, 형상항목 변경 과정에서 점검, 검증 등의 체계적인 통제를 통해 형 상항목 간의 일관성과 추적성을 확보하기 위한 시스템입니다.

형상관리란 소프트웨어의 전체 생명 주기, 계획부터 개발, 운영, 유지보수, 폐기까지 발생하는 모든 활동을 지속적으로 관리하는 것입니다.

 

형상관리 범위는 신규 프로젝트 및 보완 개발, 업무시스템의 운영/유지보수, 전산 설비 및 시스템 소프트웨어 등과 관련된 작업, 사용자(EUC: End User Comuting) 파일 관리 등을 포함합니다.

 

형상항목 : 형상관리 대상이 되는 항목을 의미하며, 유일한 식별자가 부여되어 개별적으로 관리되는 소스파일, 문서가 포함됩니다.

기준선 : 공식적으로 검토되고 협의되어 향후 기준이 되는 형상항목의 집합체입니다.

마이그레이션 : 개발 완료된 시스템이 운영 단계로 전환될 때 관련 소스파일을 저장 공간(리포지터리)으로 이관시키는 작업입니다.

리포지터리 : 형상관리 시스템으로 전송하여 압축, 암호화한 후에 저장, 관리하는 저장공간입니다.

워크플로 : 형상관리 활동 수행을 위한 미리 정해진 절차가 형상관리 시스템 안에 구현되있는 것입니다.

반출 / 반입 : 형상항목을 변경 및 이관 시키기 위해 리포지터리로부터 전송을 하거나(반출) 전송을 받습니다(반입)


애플리케이션 소스 검증

소스코드 검증도구

검증도구의 용도

 

  • 정적 테스트 도구는 테스트하기 전에 코딩 오류, 성능 저하, 보안 취약점 등의 결함을 조기에 발견할 수 있도록 지원. 개발의 생산성을 향상시키고, 운영환경에서 프로그램의 품질 향상을 제고한다

 

  •  동적 테스트 도구는 테스트 미수행 코드를 확인하고 분기(결정)문 등 특정 유형의 코드 구조가 충분히 테스트 되었는지를 확인하여 추가적인 테스트를 진행하여 애플리케이션의 안정성을 제고한다
검증도구의 구분

     

소스코드 검증도구는 구현된 SW를 실행하지 않고 테스트하는 정적 테스트, 도구와 구현된 SW를 실행하여 동작을 보면서 테스트하는 동적 테스트 도구로 구분한다.

출처 : 세명컴퓨터고등학교 인공지능 학과


동적 테스트 방법 ( 블랙박스 테스트, 화이트박스 테스트) 

블랙박스 테스트

블랙박스 테스트는 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방식입니다.

사용자가 직접 특정 App이나 Device를 가지고 작동시키는 과정이 블랙박스 테스트와 동일합니다.

즉, 내부에 어떤 내용이 있는지 하나도 모른 채, 사용자가 원하는 기능이 예측한데로 정상 동작 하는지를 확인합니다.

  • 동등분할 기법 : 프로그램의 입력 도메인을 테스트 케이스가 산출될 수 있는 데이터 클래스로 분류하는 방법입니다.
  • 경계값분석기법 : 입력 조건의 중간 값보다 경계 값에서 에러가 발생될 확률이 높다는 특징 으로 테스트 케이스를 작성합니다.
  • 오류예측기법 : 놓치기 쉬운 오류들을 감각 및 경험으로 찾아보는 방법입니다.
  • 원인결과 그래프기법 : 입력 데이터 간 관계가 출력에 미치는 영향을 그래프로 표현하여 오류를 발견합니다
  • 의사결정테이블테스팅 : 논리적 조건이나 상황에서 입력 조건과 결과를 참, 거짓으로 표현하여 테스트케이스를 작성합니다.
  • 상태전이테스팅 : 시스템에 반영되는 이전의 상태가 무엇인지, 상태간 전이, 상태를 변화시키는 이벤트와 입력값을 파악합니다.

화이트박스 테스트

화이트박스 테스트는 응용 프로그램의 내부 구조, 동작을 디테일하게 검사하는 테스트 방식입니다.

내부 소스 코드를 테스트 할 수 있기에 사용자가 들여다 볼 수 없는 구간의 코드 단위들을 테스트 할 수 있습니다.

즉, 개발자가 소프트웨어 또는 컴포넌트 등의 로직에 대한 테스트를 수행하기 위해 설계 단계에서 요구 사항을 확인합니다.

  • 문장검증 : 프로그램의 모든 문장이 적어도 한번씩 수행되는 검증 기준
  • 선택검증 : 선택하는 부분만 검증
  • 경로검증 : 수행가능한 모든 경로 검사
  • 조건 검증 : IF문장이나 While문장내에 조건식을 조사하는 기준

코드 인스펙션(Code Inspection)

    코드 인스펙션은 정적 테스트의 가장 일반적인 유형으로, 사전에 정의된 코드 작성 규칙(Rule) 기반으로 소스코드를 점검하여 작성 규칙에 위반되는 소스코드를 추출하는 분석 도구

 

코드 인스펙션 Rule 유형

 

  • 성능개선 : 메모리 낭비 코드 식별 
  • 코드 작성 규칙 : 소스코드의 가독성 향상
  • 에러 발생 가능성 : 에러 발생 가능성이 있는 코드 점검

 

코드 작성 Rule 심각도 구분(예시)

 

  • 필수(Blocker) : 에러 발생 가능성 매우 높음, 메모리 누수 발생, 반드시 수정
  • 권고 상(Critical) : 에러 발생 가능성 높음, 일반적으로 수정
  • 권고 중(Major) : 에러발생 있음, 수정 권고
  • 권고 하(Minor) : 소스코드 가독성, 유지 보수 향상 위해 수정 권고 
  • 정보(Info) : 정보성으로 제공되는 위반 사항으로 개발자가 참고하여 적용 할 수 있음

 

정규 표현식(Regular Expression)

 

특정한 규칙을 가진 문자열의 집합을 표현하는 범용적인 방식. 도구의 코드 작성 규칙은 일반적으로 정규식으로 표현된다

 


테스트 프레임워크(동적 분석 도구)

    테스트 케이스를 별도의 테스트 코드로 작성하고 동작시킬 수 있는 환경을 제공하는 도구

 

테스트 프레임워크의 구성

 

  • 테스트 코드 :  테스트 코드 작성 및 자동화된 운영환경을 구성한다. 
  • 테스트 저장소 : 테스트 코드, 데이터, 관련 테스트 스크립트, 수행결과를 저장, 관리한다

    

Junit 테스트 프레임워크

 

Java, 오픈소스 기반의 테스트 프레임워크로 Java 개발환경의 범용적인 표준으로 사용되며 (Eclipse 개발 도구에 기본 내장 기능),

아래와 같이 테스트 가능한 Assert 함수를 제공

 

        제공함수)  assertArrayEquals(a, b)    :    배열 a와 b가 일치함을 확인

                            assertEquals(a, b)    :    객체 a와 b가 일치함을 확인

                            assertSame(a, b)    :    객체 a와 b가 같은 객체임을 확인

                            assertTrue(a)    :    a값이 참인지 확인

                            assertNotNull(a)    :    객체 a가 null이 아님을 확인


애플리케이션 빌드

지속적인 통합(CI: Continuous Integration) 환경

애플리케이션 개발 과정 중 지속적으로 개발된 프로그램을 통합, 빌드, 배포하여 애플리케이션의 개발 내역을 검증, 테스트할 수 있는 환경

 

빌드 도구

 

애플리케이션의 배포 단위, 형식에 따라 소스코드를 컴파일, 패키징하며, 배포하는 스크립트를 제공하고 수행하는 도구

(Ant, Maven 등)

 

테스트 도구

 

개발된 소스코드를 테스트할 수 있는 테스트 코드를 작성, 동작시킬 수 있는 도구로, 통합 빌드 수행시 연결할 수 있다

(Junnit, DBUnit, StrutsTestCase 등)

 

소스코드 품질 측정도구(코드 인스펙션)

 

정해진 소스코드 작성 규칙에 따라 소스코드를 점검하고 규칙 위반 여부를 체크하는 도구.

통합 빌드 수행 시 연결할 수 있다(PMD, FindBugs 등)

 


테스트 커버리지

전체 프로그램의 범위 대비 테스트 수행 시 해당 테스트 수행을 위해 동작된 프로그램의 범위 비율

 

라인 커버리지(Statement Coverage)

 

개발 소스의 각 라인이 수행되었는지 확인하는 측정 지표.

 

분기 커버리지(Decision Coverage)

 

개발소스의 각 분기문이 수행되었는지를 확인하는 측정 지표.

만약 소스 내에 if문에 대한 true/false 조건이 있다면, 두 가지 경우가 모두 테스트되어야 100%로 측정된다

 

조건 커버리지(Condition Coverage)

 

각 분기문 내에 존재하는 조건식이 모두 테스트되었는지를 확인하는 측정 지표.

조건식 간의 조합에 대해서는 체크하지 않는다