AP23 — 테스트, 품질, 개발 방법

• 개정일 / 출처 확인일: 2026-10-21
• 시험 기준: 2026년 IPA 응용정보기술자시험 실러버스 Ver.7.2. 이후 시험 제도에 관한 제안·검토 자료를 2026년 출제 범위 대신 사용하지 않습니다.

학습 인덱스

PDF 쪽과 인쇄 바닥글 쪽은 서로 다른 번호 체계입니다.

PDF/인쇄	실러버스 위치	이 글의 학습 범위
67/63	대분류 4 > 중분류 12 > 2. 설계	단위·통합 테스트 설계, 소프트웨어 품질
71/67	동 중분류 > 3. 구현·구축 > (8)	단위 테스트, 블랙/화이트박스, 커버리지, 동치·경계값
72/68	동 중분류 > 4. 통합·테스트	소프트웨어 통합·검증 테스트, 드라이버·스텁, 회귀 등
73/69	동 절의 계속	시스템 통합·시스템 검증 테스트
75/71	동 중분류 > 5. 도입·인수 지원 > (5)	인수 검토·테스트, 인수 기준과 문서
78/74	대분류 4 > 중분류 13 > 1. 개발 프로세스·방법	개발 모델, Agile, XP, Scrum, TDD, CI, CD
79/75	동 절 > (3) DevOps	개발·운영 협업, CI/CD, Four Keys, 관측 가능성, DevSecOps

공통 용어표

아래 표는 세 언어판에서 바이트 단위로 동일하다.

English	한국어	日本語
test level	테스트 레벨	テストレベル
unit test	단위 테스트	ユニットテスト
integration test	통합 테스트	統合テスト
system test	시스템 테스트	システムテスト
acceptance test	인수 테스트	受入れテスト
black-box test	블랙박스 테스트	ブラックボックステスト
white-box test	화이트박스 테스트	ホワイトボックステスト
equivalence partitioning (equivalence analysis)	동치 분할(동치 분석법)	同値分割（同値分析法）
boundary-value analysis (limit-value analysis)	경계값 분석(한계값 분석법)	境界値分析（限界値分析法）
statement coverage	구문 커버리지	命令網羅
decision/branch coverage	결정/분기 커버리지	判定条件網羅
condition coverage	조건 커버리지	条件網羅
defect density	결함 밀도	欠陥密度
quality characteristic	품질 특성	品質特性
waterfall	폭포수	ウォーターフォール
Agile	애자일	アジャイル
test-driven development	테스트 주도 개발	テスト駆動開発
continuous integration	지속적 통합	継続的インテグレーション

1. 테스트를 레벨과 목적으로 읽기

도서 대출 시스템의 요구사항 R-F01을 “대출 가능한 회원이 이용 가능한 도서 사본을 대출할 수 있다”라고 하자.

학습용 공통 레벨	R-F01 추적 예
단위	Copy.checkout의 상태 전이와 규칙을 고립해 확인
통합	LoanService + Copy + LoanRepository의 협업과 인터페이스를 확인
시스템 검증	시스템 요구사항에 맞춰 처음부터 끝까지 대출 흐름을 확인
인수	구매자/사용자가 인수 기준과 업무 적합성을 평가

IPA는 생명주기의 테스트 작업을 제시한다. 위의 네 레벨은 유용한 학습 매핑이지, 모든 조직이 같은 명칭과 경계를 쓴다는 뜻은 아니다. **검증(verification)**은 산출물이 명세대로 만들어졌는지, **확인(validation)**은 의도한 사용과 사용자 필요에 맞는지를 묻는다. 두 관점은 겹칠 수 있다.

블랙박스 테스트는 명세와 관찰 가능한 동작에서 테스트를 설계한다. 화이트박스 테스트는 내부 제어 흐름·데이터 구조를 이용한다. 어느 하나만으로 결함이 없음을 증명할 수 없다. 통합에서는 상향식의 드라이버, 하향식의 스텁 같은 대역을 쓸 수 있다. 시스템 차원에서는 기능, 비기능, 성능, 부하, 보안, 회귀 테스트 등을 위험에 맞게 조합한다.

2. 동치 분할과 경계값 분석 — 예제 1

대출 기간이 정수 1..14일이면 동치 클래스는 <=0 무효, 1..14 유효, >=15 무효이다. 대표 동치 입력은 0, 7, 15이다. 경계 바로 밖/경계 자체를 택한 간결하고 가치 높은 집합은 **{0, 1, 14, 15}**이다. 이는 이 명세에 대한 실용적 집합이지 모든 상황에서 통하는 완전한 보편 집합은 아니다.

3. 구조 커버리지 — 예제 2

단락 평가를 하는 결정식 D = eligible && available을 보자.

• T1: eligible=true, available=true → D 참; 두 조건 모두 참으로 평가된다.
• T2: eligible=false, available=true를 공급 → D 거짓; 단락 때문에 available은 평가되지 않는다.
• T1,T2의 결정 결과는 참/거짓 2개 중 2개: 결정 커버리지 2/2=100%. 관찰된 조건 진리값은 eligible T/F, available T뿐이므로 조건 커버리지 3/4=75%.
• T3: eligible=true, available=false → D 거짓이며 available의 거짓도 관찰된다. 조건 커버리지는 4/4=100%, 결정 커버리지는 계속 100%이다.

구문 커버리지 = 실행한 대상 구문 수/전체 대상 구문 수 ×100, 결정(분기) 커버리지 = 실행한 결정 결과 수/전체 가능한 결정 결과 수 ×100, 조건 커버리지 = 관찰한 원자 조건 진리 결과 수/전체 원자 조건 진리 결과 수 ×100이다. 높은 커버리지는 구조를 실행했다는 증거일 뿐 정확성이나 요구사항 커버리지의 증명이 아니다.

4. 품질과 측정

확인된 결함 18개와 코드 6 KLOC라면 결함 밀도는 18/6 = 3 defects/KLOC이다. 분모와 단위를 반드시 쓴다. 언어, 복잡도, 측정 단계, 결함 계수 정책이 다른 제품을 이 수치만으로 비교하면 위험하다. 하나의 지표가 품질 전체를 뜻하지 않는다.

Ver.7.2/JIS X 25010 범위의 여덟 제품 품질 특성은 기능 적합성, 성능 효율성, 호환성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성이다. 이후 모델을 이 2026 범위에 섞지 않는다. 목적과 위험에 맞는 특성, 기준, 측정값을 연결한다.

5. 개발 방법

• 폭포수는 단계를 계획하고 산출물을 순차적으로 관리하는 데 강점이 있으나 변경 비용을 고려해야 한다. 프로토타이핑은 불확실한 요구와 UI에 대한 빠른 피드백에 유용하다. 점증적/진화적 모델은 기능과 설계를 반복적으로 확장한다.
• Agile은 짧은 피드백과 변화 대응을 중시한다. Scrum은 반복적·점증적이며 경험주의에 기반한다. 규제, 불확실성, 피드백 필요, 위험에 따라 방법과 통제를 선택한다.
• TDD는 **실패하는 테스트(red) → 통과하는 최소 코드(green) → 리팩터링(refactor)**의 개발 실천법이며 테스트 레벨이 아니다.
• CI는 자주 통합하고 자동 검사로 빠르게 피드백받는 것이며 자동 운영 배포를 뜻하지 않는다. 지속적 전달(continuous delivery)은 변경을 배포 가능한 상태로 유지하되 운영 배포에 승인 절차가 있을 수 있다. 지속적 배포(continuous deployment)는 통과한 변경을 운영에 자동 배포한다.
• DevOps는 개발과 운영의 협업·피드백·자동화를 개선한다. 관측 가능성, Four Keys, 보안을 흐름에 포함하는 DevSecOps도 범위에 있다. 특정 도구 하나가 DevOps를 완성하지 않는다.

6. 오리지널 4지선다

Q1

LoanService와 LoanRepository 인터페이스의 협업을 확인하는 데 가장 직접적인 테스트 레벨은?

• ア 단위 테스트
• イ 통합 테스트
• ウ 시스템 테스트
• エ 인수 테스트

정답: イ (2). ア는 한 단위의 고립된 규칙에 초점이 있다. イ는 구성요소 간 협업·인터페이스를 확인하므로 맞다. ウ는 완성 시스템과 시스템 요구사항을 본다. エ는 구매자/사용자의 인수 기준과 업무 적합성을 본다.

Q2

유효한 대출 기간이 정수 1..14일일 때 간결한 고가치 경계 집합은?

• ア {1, 7, 14}
• イ {0, 7, 15}
• ウ {1, 2, 13, 14}
• エ {0, 1, 14, 15}

정답: エ (4). ア는 바깥값이 없다. イ는 동치 대표값에는 알맞지만 두 경계의 안쪽 값을 모두 포함하지 않는다. ウ는 유효 영역 안만 검사한다. エ는 각 경계의 바로 밖과 경계 자체를 포함한다.

Q3

위 T1과 T2만 실행했을 때 올바른 조합은?

• ア 결정 50%, 조건 50%
• イ 결정 75%, 조건 100%
• ウ 결정 100%, 조건 75%
• エ 결정 100%, 조건 100%

정답: ウ (3). ア는 참·거짓 결정 결과가 모두 나왔음을 놓친다. イ는 분모를 뒤섞었다. ウ는 결정 2/2, 조건 결과 3/4로 맞다. エ는 단락 때문에 available=false가 관찰되지 않았음을 놓친다.

Q4

확인된 결함 18개, 코드 6 KLOC에 대한 가장 적절한 해석은?

• ア 3 defects/KLOC이며 다른 제품과 비교할 때 언어·복잡도·단계·계수 정책 맥락이 필요하다.
• イ 0.33 KLOC/defect가 유일하게 허용되는 품질 지표다.
• ウ 108 defects/KLOC이고 품질 전체를 증명한다.
• エ 결함 밀도에는 분모가 필요 없다.

정답: ア (1). ア는 계산과 맥락이 모두 맞다. イ는 역수를 냈고 유일 지표라는 주장도 틀리다. ウ는 나눗셈 대신 곱했고 과도한 결론이다. エ는 밀도의 분모를 빠뜨린다.

Q5

TDD의 올바른 순서는?

• ア 최소 코드 → 리팩터링 → 실패 테스트
• イ 실패 테스트 → 통과하는 최소 코드 → 리팩터링
• ウ 리팩터링 → 운영 배포 → 테스트
• エ 요구사항 제거 → 테스트 생략 → 통합

정답: イ (2). ア는 실패 테스트가 먼저가 아니다. イ는 red→green→refactor이다. ウ는 TDD 순서가 아니며 운영 배포는 별개다. エ는 테스트와 요구사항을 제거하므로 TDD가 아니다.

모든 문제는 자체 제작했으며 IPA 기출문제를 사용·개작하지 않았다.

퀵 시트

• 명세/외부 동작 → 블랙박스, 내부 구조 → 화이트박스. 상호 보완적이다.
• 1..14: 동치 대표 0,7,15; 경계 핵심 0,1,14,15.
• 커버리지의 분자·분모와 단락 평가를 확인한다. 높은 수치 ≠ 무결함.
• 결함 밀도 = 결함 수/규모. 단위와 비교 맥락을 기록한다.
• 단위→통합→시스템→인수의 목적을 R-F01에 연결한다.
• TDD는 red→green→refactor. CI ≠ 자동 운영 배포. delivery ≠ deployment.

셀프 체크와 1/3/7일 복습

답을 보지 않고 (1) 네 테스트 레벨에 R-F01을 배치하고, (2) 1..14의 동치·경계값을 쓰고, (3) T1~T3 커버리지를 계산하고, (4) 여덟 품질 특성을 말하고, (5) TDD와 CI/CD 차이를 설명한다.

• 1일: 용어표와 퀵 시트를 회상하고 Q1~Q5를 다시 푼다.
• 3일: 숫자와 조건을 바꿔 경계·커버리지·결함 밀도를 재계산한다.
• 7일: R-F01을 테스트 레벨부터 개발 방법까지 한 장에 연결하고 틀린 문제만 재시험한다.

공식 출처 및 고지

• IPA, 응용정보기술자시험（レベル3）シラバス Ver.7.2 — 확인 2026-10-21
• IPA, 시험 실러버스·개요 — 확인 2026-10-21
• Manifesto for Agile Software Development — 확인 2026-10-21
• The 2020 Scrum Guide — 확인 2026-10-21

이 자료는 IPA 또는 다른 출처 기관과 제휴·승인 관계가 없다. 학습·합격·시험 결과를 보장하지 않는다.