정처기 실기 이론: 소프트웨어 개발

테스트 레벨과 V모델

테스트 레벨

소프트웨어 개발 과정에서 테스트가 수행되는 단계. 단위 테스트- 통합 테스트 - 시스템 테스트 - 인수 테스트 순으로 진행.

V 모델

폭포수 모델을 확장한 개발 모델로 개발의 각 단계에 대응하는 테스트 단계를 정의.

테스트 단계	주체	개발 단계 (역순)	테스트 대상	툴 / 유형
단위 테스트	개발자	모듈 설계	개별 모듈 / 컴포넌트	드라이버, 스텁
통합 테스트	개발자 / 팀	시스템 설계	모듈 간 인터페이스	상향식, 하향식, 빅뱅, 샌드위치
시스템 테스트	팀	시스템 요구 명세서	전체 시스템	기능, 성능, 보안, 복구
인수 테스트	사용자	사용자 요구 명세서	사용자 요구사항	알파 / 베타 테스트

인수 테스트의 대표적인 유형

알파 테스트: 개발자 환경에서 통제된 상태로 사용자가 테스트.

베타 테스트: 사용자 환경에서 개발자 없이 수행되는 테스트.

테스트 7원칙

ISTQB(국제 소프트웨어 테스팅 자격위원회)에서 정의한 테스트의 7가지 기본 원칙.

원칙	핵심 키워드
결함 존재 증명	테스트는 결함의 존재를 보일 뿐, 결함이 없음을 증명하지 못함.
완벽한 테스트 불가능	모든 입력, 조합을 테스트하는 것은 비현실적
초기 테스트	결함은 일찍 발견할수록 비용 절감
결함 집중 (파레토 법칙)	적은 수의 모듈에 대부분의 결함이 집중됨(결함의 80%는 모듈의 20%에서 발생)
살충제 패러독스	동일한 테스트 케이스 반복 시 새로운 결함을 발견하기 어려움 - 주기적 테스트 검토 및 갱신 필요
정황 의존성	테스트 활동은 소프트웨어 종류와 환경에 따라 달라짐
오류 - 부재의 궤변	결함이 없어도 사용자 요구를 충족하지 못하면 품질이 좋다 볼 수 없음

살충제 패러독스 (Pesticlde Paradox)

같은 살충제에 해충이 내성을 가지듯, 같은 테스트 케이스를 반복하면 새로운 결함 발견 확률이 감소한다.

키워드: 동일 테스트 케이스 반복, 결함 확률 감소

대응: 기존 케이스를 주기적 검토, 수정하거나 새로운 케이스 추가

성능 측정 지표

시스템 테스트의 성능 테스트에서 사용하는 4가지 지표.

지표	정의	키워드
처리량	단위 시간당 처리할 수 있는 트랜잭션 수	단위 시간 당 처리량
응답시간	사용자 입력 후 응답 출력까지의 시간	응답 시작 순간
경과시간	사용자 요구 입력 시점부터 결과 출력까지의 시간	응답 끝나는 순간
자원 사용률	CPU, 메모리, 네트워크 사용량	자원 소비량

회귀 테스트

결함을 수정하거나 기능을 변경한 뒤, 새로운 결함이 발생하는 지 반복 시험.

목적: 변경 사항이 새로운 결함을 만드는지 점검

시점: 결함 수정, 기능 변경

핵심 키워드: 변경 사항 이후 새로운 결함 발견, 반복 시험

테스트	정의
확인 테스트	결함 수정되었는지 단독 확인
재테스트	동일한 입력으로 재시도
회귀 테스트	변경사항이 새로운 결함을 만드는지 반복 시험

화이트박스 테스트

화이트박스 테스트란?

소프트웨어의 소스 코드나 시스템의 구조, 즉 알고리즘 기반의 테스트 방법

테스트 커버리지란?

테스트가 소스 코드를 충분히 검증했는지 확인하는 지표.

구문(문장) 커버리지 (Statement Coverage)

소스 코드의 모든 실행 가능한 문장(명령문)이 적어도 한 번 이상 실행되었는지

장점: 이해하기 쉽고 테스트 케이스를 만들기 간편합니다.

단점: 코드의 논리적인 분기(branch)를 모두 테스트하지 못할 수 있습니다.

결정/조건 커버리지 (Condition/Decision Coverage)

각 결정문의 결과가 참(True)과 거짓(False)을 각각 한 번 이상 가지는지

장점: 구문 커버리지가 놓치는 분기 경로를 테스트할 수 있습니다

조건 커버리지 (Condition Coverage)

결정문 내에 있는 각각의 개별 조건식이 참과 거짓을 한 번씩 가지는지?

주의: 조건 커버리지는 결정문 전체의 결과(참/거짓)는 고려하지 않습니다. 이로 인해 결정 커버리지를 100% 만족시키지 못하는 경우가 발생할 수 있습니다.

조건/결정 커버리지 (Condition/Decision Coverage)

각 결정문의 결과가 참/거짓을 각각 한 번 이상 가지면서, 동시에 모든 개별 조건식의 결과도 참/거짓을 각각 한 번 이상 가지는지

장점: 결정과 조건 수준을 모두 만족시켜 테스트의 신뢰도를 높입니다.

단점: 조건식의 모든 조합을 테스트하지는 않으므로, MC/DC보다는 강도가 약합니다.

변경 조건/결정 커버리지 (MC/DC, Modified Condition/Decision Coverage)

조건/결정 커버리지를 모두 만족시키면서 각 개별 조건식이 다른 조건식의 값과 관계없이 전체 결정문의 결과에 독립적으로 영향을 미치는지

핵심: 각 조건이 '독립적으로' 결과에 영향을 주는 것을 증명해야 합니다.

명령문, 결정문, 조건식

용어	정의	예시
명령문	실행 가능한 코드 한 줄 (실행문)	System.out.println("Hello");, x = 5;
결정문	참/거짓을 판단하는 조건부 문장의 전체 조건	if (x > 0 && y < 10), while (a < b)
조건식	결정문 내부의 개별 비교 연산	위 결정문 예시에서 x > 0, y < 10, a < b 이부분만 조건식

블랙박스 테스트

블랙박스 테스트란?

요구사항 명세를 기준으로 기능이 올바르게 동작하는지를 검사하는 테스트 방법.

블랙박스 테스트 유형

테스트 유형	핵심 개념
동등 분할 테스트	입력 조건을 유효/무효 클래스로 나누어 테스트
경곗값 분석 테스트	분할된 클래스의 경계값을 집중적으로 테스트
결정 테이블 테스트	복잡한 논리적 조건과 그에 따른 행동을 표로 정리
원인-결과 그래프 테스트	입력(원인)과 출력(결과)의 논리적 관계를 그래프로 표현
상태 전이 테스트	시스템의 상태 변화를 기반으로 테스트 케이스 설계
오류 예측 테스트	테스터의 경험과 직관으로 오류가 발생할 만한 부분을 예측
비교 테스트	동일한 기능의 여러 버전 또는 제품을 비교하여 테스트
페어와이즈 테스트	모든 가능한 입력 값 조합 대신, 입력 값들의 모든 쌍(pair)을 테스트
분류 트리 테스트	테스트 관련 요소를 트리 구조로 분석하고 테스트 케이스 도출
유스케이스 테스트	사용자의 시나리오(유스케이스)를 기반으로 테스트

테스트 자동화 구성요소

테스트 하네스란?

단위 테스트나 모듈 테스트에서 테스트를 실행하는 환경을 구축하기 위한 소프트웨어 도구 혹은 프레임워크를 의미합니다.

테스트 하네스의 핵심 구성 요소

구분	테스트 드라이버 (Test Driver)	테스트 스텁 (Test Stub)
목적	하위 모듈을 테스트	상위 모듈을 테스트
역할	테스트 모듈을 호출하는 상위 모듈 역할	테스트 모듈에 의해 호출되는 하위 모듈 역할
테스트	상향식(Bottom-up) 테스트	하향식(Top-down) 테스트
함수 호출, 데이터 흐름	`드라이버` → `테스트 대상(하위)`	`테스트 대상(상위)` → `스텁`

그 외 구성요소

구성요소	설명
테스트 케이스	입력값, 실행 조건, 예상 결과 등의 명세. 테스트의 최소 단위
테스트 슈트	테스트 케이스들의 집합. 모든 테스트 케이스를 묶어놓은 단위
테스트 시나리오	여러 테스트 케이스를 묶은 하나의 동작 흐름
테스트 스크립트	테스트 케이스 자동 실행 코드
목업 객체	스텁과 유사하지만, 호출에 대한 상태나 행위까지 검증하는 더 정교한 객체

테스트 케이스

테스트 케이스란?

입력값, 실행 조건, 예상 결과 등의 명세. 테스트 수행의 최소 단위.

좋은 테스트 케이스의 장점

재현 가능성: 누가 테스트하더라도 동일한 결과

추적 가능성: 요구사항과 테스트의 연결 관계 파악 용이

효율성: 체계적인 테스트 수행, 품질 검증

테스트 케이스의 구성요소

구성 요소	설명	예시
식별자(ID)	테스트 케이스를 고유하게 식별하는 번호	PID_001, TC_LOGIN_01
테스트 항목	테스트 대상 기능 또는 모듈	결제 기능, 로그인 기능
테스트 조건	테스트 실행 전 갖춰야 할 사전 조건 및 환경	결제 화면, 로그인 화면
테스트 데이터	테스트 수행 시 사용할 입력값	결제금액 5000원, ID/PW
예상 결과	테스트 수행 후 기대되는 출력 또는 시스템의 상태	결제 성공 메시지, 메인 이동

테스트 케이스 vs 테스트 시나리오 vs 테스트 스크립트

용어	설명
테스트 케이스	특정 조건에서 특정 입력으로 예상 결과를 검증하는 최소 단위
테스트 시나리오	여러 테스트 케이스를 묶어 사용자의 업무 흐름을 검증하는 시나리오
테스트 스크립트	테스트 케이스를 자동화 도구로 실행할 수 있도록 작성한 코드

인터페이스 보안 암호화 프로토콜

데이터 전송 암호화의 중요성

데이터가 암호화되지 않은 평문 형태로 전송된다면, 공격자는 중간에서 데이터를 가로채(스니핑, Sniffing) 민감한 정보를 탈취 가능, 이러한 위협을 방지하기 위해 데이터 전송 단계에서 암호화를 적용.

주요 암호화 전송 프로토콜

터널링 프로토콜

사설 가상망(VPN)을 구축할 때 사용되며, 공용 네크워크를 전용선처럼 안전하게 사용 가능하도록 데이터 패킷을 캡슐화하는 기술

프로토콜	동작 계층	키워드
PPTP	데이터 링크 계층	PPP 기초
L2F	데이터 링크 계층	시스코 개발, UDP 사용
L2TP	데이터 링크 계층	터널링만 제공, 암호화는 IPSec과 결합
IPSec	네트워크 계층	IP 패킷 단위 암호화, 강력한 보안 제공

웹 트래픽 암호화 프로토콜

웹 트래픽을 안전하게 보호하기 위한 기술

프로토콜	동작 계층	키워드
SSL/TLS	전송 계층	웹 통신 암호화 표준, HTTPS의 기반
S-HTTP	응용 계층	클라이언트 서버 간 메시지 단위 암호화
HTTPS	응용 계층	HTTP over SSL/TLS, 통신 채널 전체 암호화

IPsec

IPsec(IP Security Protocol)란?

네트워크 계층(IP 계층)에서 IP 패킷을 암호화하고 인증하여 통신을 보호하는 터널링 프로토콜.

IPsec의 핵심 구성요소

AH (Authentication Header) : 인증 헤더

데이터 무결성: 데이터가 전송 중 변경되지 않았음을 보장

송신자 인증: IP 패킷의 출발지 주소가 위조 여부 확인

재전송 공격 방지: 번호를 부여하여 동일한 패킷의 재전송 차단

암호화 부재: 데이터를 숨기지 않아 기밀성 통신 부적합

ESP (Encapsulating Security Payload) : 캡슐화 보안 페이로드

기밀성: ip payload 요청 데이터를 암호화하여 본문 보호

재전송 공격 방지

송신자 인증 및 데이터 무결성: 선택사항

IPsec의 두가지 모드

구분	전송 모드 (Transport Mode)	터널 모드 (Tunnel Mode)
보호 범위	IP 페이로드만 보호	IP 패킷 전체 보호
IP 헤더	기존 IP 헤더 유지	새로운 IP 헤더 추가
주요 용도	호스트 간 통신 (End-to-End)	네트워크 간 통신 (Site-to-Site VPN)
보안 수준	낮음 (IP 헤더 노출)	높음 (전체 패킷 보호)

기업 애플리케이션 통합

EAI (Enterprise Application Integration, 기업 애플리케이션 통합) 이란?

기업에서 운영되는 서로 다른 플랫폼 및 애플리케이션간의 정보를 전달, 연계, 통합하는 솔루션.

EAI 구축 유형 4가지

이름	방식	장점단점
Point to Point	애플리케이션 1:1 연결	구현 빠름 / 연결선 비효율 `n(n-1)/2`
Hub & Spoke	중앙 허브와 애플리케이션 연결	연결선 효율 `n` / 단일 장애점 존재
Message Bus	메세지 버스를 통해 송수신	확장성,안정성 높음 / 큰 비용
Hybrid	내부 - 메세지 버스 외부 - 허브 앤 스포크 등 조합	조직 구조에 맞춰 유연하게 설계

ESB (Enterprise Service Bus, 기업 서비스 버스)란?

EAI의 한계를 극복하기 위해 등장한 통합 솔루션. SOA(Service-Oriented Architecture)의 핵심 인프라.

구분	EAI	ESB
통합 대상	기업 내부 애플리케이션	기업 내·외부 서비스
연결 방식	시스템마다 다른 어댑터	웹 서비스(SOAP, WSDL) 등 표준 인터페이스
결합도	상대적으로 높음	낮음 (Loose Coupling)
메시지 라우팅	단순 라우팅	라우팅·변환·오케스트레이션

JSON (JavaScript Object Notation)

key-value 쌍으로 이루어진 데이터 객체

단순한 구조로 파싱이 빠르고 메모리 소모가 적음

웹 환경, 특히 REST API에서 주로 사용

XML (eXtensible Markup Language)

태그로 데이터 구조를 계층적으로 표현하는 마크업 언어

트리 구조로 데이터의 의미·관계를 명확히 표현, 확장성이 뛰어남

과거 웹 서비스(SOAP)나 다양한 시스템의 설정 파일에서 많이 사용

YAML (YAML Ain't Markup Language)

사람이 읽고 쓰기 편한 것에 중점을 둔 데이터 직렬화 형식

들여쓰기로 계층 구조 표현, 가독성 높음, 주석(#) 지원

JSON의 상위 집합(superset)이라 대부분의 파서가 JSON도 해석 가능

비교

구분	JSON	XML	YAML
가독성	높음	보통(태그로 복잡)	매우 높음(간결)
구조 표현	key-value, 괄호	태그	들여쓰기, 하이픈
주석	지원 안 함	지원	지원(#)
주 사용처	API 통신, 웹	SOAP, 문서 구조 정의	설정 파일(Docker, K8s)
파싱 속도	빠름	상대적으로 느림	JSON보다 느림

클래식 웹 서비스 삼총사

UDDI (Universal Description, Discovery, and Integration)

역할: 웹 서비스의 '전화번호부' / 서비스 디렉토리

어떤 서비스가 어디에 있고 어떤 종류인지 찾는 검색·등록 역할

WSDL (Web Services Description Language)

역할: 서비스의 '상세 메뉴판' / 사용 설명서

어떤 메서드가 있고, 파라미터·데이터 타입은 무엇인지 XML 형식으로 기술한 웹 서비스 명세

SOAP (Simple Object Access Protocol)

역할: 정해진 양식에 따른 '격식 있는 주문서'

매우 엄격한 XML 기반 메시지를 사용하는 프로토콜, 원격 프로시저 호출

현대적 웹 API의 주역

REST (Representational State Transfer)

웹의 기본 원리(HTTP)를 최대한 활용하는 아키텍처 스타일(설계 철학)

URI로 자원을 식별하고 HTTP 메서드를 사용, 주로 JSON 데이터 형식

별도의 UDDI·WSDL·복잡한 SOAP 없이 간단한 JSON 사용

SOAP 스택 vs REST 스타일 비교

구분	SOAP · WSDL · UDDI 스택	REST 스타일
개념	프로토콜: 엄격한 규칙	아키텍처 스타일: 유연한 원칙
데이터 형식	XML만 사용	JSON, XML 등 자유(주로 JSON)
통신 방식	HTTP 외 다른 프로토콜도 가능	HTTP 위에서만 동작
복잡성	높음(WSDL, 스키마 필요)	낮음(HTTP와 URI만 알면 됨)
주 사용처	높은 보안/트랜잭션이 필요한 기업용	대부분의 공개 API, 모바일·웹

AJAX (Asynchronous JavaScript and XML)

웹페이지 전체를 새로고침하지 않고 백그라운드에서 서버와 데이터를 비동기 교환해 화면을 동적으로 갱신하는 개발 기법

XMLHttpRequest 객체로 요청·응답 처리, 이름에 XML이 있지만 현재는 주로 JSON 사용

특정 기술이 아닌 여러 기술(JavaScript·DOM·Fetch/XHR)을 쓰는 패러다임

Fetch API

XMLHttpRequest를 대체하는 현대적 브라우저 내장 API, 별도 라이브러리 불필요

Promise 기반으로 async/await와 함께 비동기 코드를 쉽게 관리, 현재 웹 표준

WebSocket

클라이언트-서버 간 양방향 실시간 통신 프로토콜

한 번 연결되면 계속 유지(Persistent Connection), 서버가 요청 없이 보내는 서버 푸시 가능

낮은 지연으로 실시간 채팅·게임·시세 알림에 사용

GraphQL

API를 위한 쿼리 언어이자 런타임

Over-fetching/Under-fetching 해결: 클라이언트가 필요한 데이터 구조를 직접 정의해 요청

하나의 엔드포인트로 여러 데이터를 유연하게 요청, 강력한 타입 시스템

통신 기술 요약

기술	핵심 키워드	주요 특징
AJAX	XMLHttpRequest, 비동기, 부분 리로드	새로고침 없이 화면 일부를 동적 업데이트하는 개발 기법
Fetch API	Promise 기반, 내장 API	XMLHttpRequest를 대체하는 현대적 웹 표준 API
WebSocket	양방향, 실시간, 서버 푸시	지속 연결로 실시간 데이터를 주고받는 프로토콜
GraphQL	API 쿼리 언어, Over-fetching 해결	클라이언트가 필요한 데이터만 정확히 요청하는 API 명세

URL과 URI

URI는 자원 식별 전체(상위 개념), URL은 위치 기반 식별

URL 일반 구조

scheme://authority/path?query#fragment

구분자

:// : scheme과 authority 구분

/ : path 시작

? : query 시작

# : fragment 시작

구성요소

구성요소	구분 위치	의미	예시
scheme	`://` 앞	자원에 접근하는 방법(프로토콜)	`https`
authority	`://` 뒤	사용자 정보 · 호스트명 · 포트 번호	`example.com`
path	호스트 뒤 `/`	서버 안의 자원 경로	`/watch`
query	`?` 뒤	서버에 전달할 추가 데이터(키=값)	`v=abc123`
fragment	`#` 뒤	문서 내 특정 위치(앵커)	`comments`

보충 개념

Authority: userinfo@host:port 형식(사용자 정보·포트는 생략 가능)

Query: 키=값 형태, 여러 쌍은 & 로 연결

Fragment: 서버로 전송되지 않고 브라우저만 처리

형상 관리란?

소프트웨어 개발 생명주기 동안 발생하는 산출물(소스 코드·문서·설정 파일 등)의 변경 사항을 체계적으로 추적·통제하여 무결성을 유지하는 활동. (SCM, Software Configuration Management)

베이스라인 (Baseline)

공식 검토·합의를 거친 형상 항목의 기준선

설정되면 형상 항목은 임의 수정 불가, 반드시 형상 통제 절차를 거쳐야 변경

단계별로 누적: 요구사항 → 설계 → 제품 베이스라인

형상 관리 4가지 활동

활동	역할	핵심 키워드
형상 식별(Identification)	관리 대상(형상 항목)을 정의하고 베이스라인 설정	식별, 베이스라인 설정
형상 통제(Control)	변경 요구를 검토·승인하여 베이스라인에 반영	변경 요구 검토·승인, CCB
형상 감사(Audit)	베이스라인의 무결성·일관성을 확인	검증, 감사(FCA/PCA)
형상 기록(Status Accounting)	형상 항목의 변경 이력을 기록·보고	변경 이력, 보고서

형상 관리(버전 관리) 도구

도구	분류	특징
CVS	중앙 집중식	초기 오픈소스 VCS, 파일 단위 버전 관리
SVN(Subversion)	중앙 집중식	CVS 한계 보완, 디렉토리·메타데이터 버전 관리
Git	분산형(DVCS)	로컬 저장소를 가진 분산 버전 관리, 현재 표준

중앙 집중식 vs 분산형

중앙 집중식(CVCS): CVS, SVN. 단일 중앙 서버에 모든 이력 저장, 서버 장애 시 작업 곤란

분산형(DVCS): Git, Mercurial. 각 개발자가 전체 이력을 가진 로컬 저장소 보유, 오프라인 작업·빠른 분기/병합 가능

오답 함정 (형상 관리 도구가 아닌 것)

JVM(자바 가상 머신), JUnit(단위 테스트 프레임워크), AVL(이진 검색 트리), Ada(프로그래밍 언어)