<과정평가형 NCS 정보처리산업기사> 과년도 필기 출제 위주 정리

---

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

---

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

528~530p ✍️ 프로젝트 수행 단계에 따른 테스트의 분류

1. 단위 테스트 : 작은 소프트웨어 단위(컴포넌트 또는 모듈)를 테스트하는 것으로서 일반적으로 개발자 자신에 의해 행해짐.
   작게 분리된 소프트웨어 내에서 결함을 찾고 기능을 검증하는 테스트 활동.
   (1) 구조 기반은 업무 단위별 제어 흐름과 조건 결저엥 따른 겨로가를 테스트하는 데 목적이 있음
   (2) 명세 기반은 동등 분할과 경계 값 분석을 위하여 사용자의 입력, 출력, 내부, 이벤트 등을 확인하는 데 목적이 있음

테스트 방법	테스트 내용	테스트 목적
구조기반	프로그램 내부 구조 및 복잡도를 검증하는 화이트박스(White Box) 테스트	제어 흐름, 조건 결정
명세 기반	목적 및 실행 코드 기반의 실행을 통한 블랙박스(Black Box) 테스트	동등 분할, 경계 값 분석

2. 통합 테스트 : 컴포넌트 간 인터페이스 테스트를 하고 운영체제(OS), 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 각각 다른 부분과 상호 연동이 정상적으로 작동하는지 여부를 테스트 함. 일반적으로 빅뱅 방식보다는 순차적 형태와 아키텍처에 대한 이해를 바탕으로 진행함. 빅뱅, 상향, 하향, 샌드위치, Central, Collaboration, 레이어 통합 등의 테스트가 있음

3. 시스템 테스트 : 컴퓨터 시스템을 완벽하게 검사하기 위한 목적 또는 성능 목표를 가지고 테스트 함. 개발 프로젝트 차원에서 정의된 전체 시스템의 동작과 관련되어있음. 환경 제한적 장애 관련 리스크를 최소화하기 위하여 실제의 최종 사용자 환경과 유사하게 시스템 성능, 관련된 고객의 기능, 비기능적인 요구사항 드잉 완벽하게 수행되는지를 테스트하며, 이때 요구사항 명세서, 비즈니스 절차, 유스케이스, 리스크 분석 결과 등을 이용함.

테스트 방법	테스트 내용
기능적 요구사항	요구사항 명세서, 비즈니스 절차, 유즈케이스 등 명세서 기반의 블랙박스(Black Box) 테스트
비기능적 요구사항	성능 테스트, 회복 테스트, 보안 테스트, 내부 시스템의 메뉴 구조, 웹 페이지의 네비게이션 등의 구조적 요소에 대한 화이트박스(White Box) 테스트

4. 인수 테스트 : 시스템의 일부 또는 특정한 비기능적인 특성에 대해 인수테스트를 통해 확인하며 6가지의 종류로 구분해서 테스트 함

테스트 종류	테스트 내용
사용자 인수 테스트	비즈니스 사용자가 시스템 사용의 적절성 여부를 확인
운영상의 인수 테스트	시스템 관리자가 시스템 인수 시 수행하는 테스트 활동으로 백업, 복원 시스템, 재난 복구, 사용자 관리, 정기 점검 등을 확인
계약 인수 테스트	계약상의 인수/검수 조건을 준수하는지 여부를 확인
규정 인수 테스트	정부 지침, 법규, 규정 등 규정에 맞게 개발하였는지 확인
알파 테스트	개발하는 조직 내 잠재 고객에 의해 테스트 수행
베타 테스트	실제 환경에서 고객에 의해 테스트 수행

530p ✍️ 테스트 기반에 따른 테스트의 종류

테스트 종류	테스트 내용	세부 기법
구조 기반	소프트웨어 내부의 논리 흐름에 따른 테스트 케이스 작성 및 결함 발견 활동	구문 기반, 결정 기반, 조건 기반, 조건결정 기반, 변경 조건 기반, 멀티 조건 기반 커버리지
명세 기반	사용자의 요구사항 분석서에 주어진 명세를 빠뜨리지 않고 테스트 케이스화	동등 분할, 경꼐 값 분석, 결정 테이블 테스팅, 상태 전이 테스팅, 유스케이스 테스팅
경험 기반	유사 소프트웨어나 기솔에서의 테스터의 경험, 직관, 기술 능력을 바탕으로 하는 테스트 기법	탐색적 테스팅, 리스크 기반 테스팅

532p ✍️ 테스트 활동에 따른 자동화 도구

테스트 활동	테스트 도구	내용
테스트 계획
테스트 분석/설계
테스트 수행	테스트 자동화 정적 분석 동적 분석 성능 테스트 모니터링	기능 테스트 등 테스트 도구를 활용하여 자동화를 통한 테스트의 효율성 제고 코딩 표준, 런타임 오류 등을 검증 대상 시스템 시뮬레이션을 통한 오류 검출 가상 사용자를 인위적으로 생성하여 시스템 처리능력 측정 시스템 자원(CPU, memory 등)의 상태 확인 및 분석 지원 도구
테스트 통제	형상 관리 테스트 관리 결함 추적/관리

544p ✍️ 결함
(1) 프로그램과 명세서 간의 차이, 업무 내용 불일치
(2) 기대 결과와 실제 관찰 결과 간의 차이
(3) 시스템이 사용자가 기대하는 타당한 기대치를 만족시키지 못할 때 변경이 필요한 모든 것

544p ✍️ 결함관리 프로세스
결함관리 계획 => [ 결함 기록 => 결함 검토 => 결함 수정 <=> 결함 재확인 ] => 최종 결함 분석 및 보고서 작성
[ 결함 기록 => 결함 검토 => 결함 수정 <=> 결함 재확인 ] ?
결함관리 DB (결함 상태 추적 및 모니터링 활동)

546, 547p ✍️ 결함 분류
(1) 시스템 결함 : 비정상적인 종료/중단, 응답 시간 지연, 데이터베이스 에러 등 주로 애플리케이션 환경과 데이터베이스 처리에서 발생하는 결함
(2) 기능 결함 : 사용자의 요구사항 미반영/불일치, 부정확한 비즈니스 프로세스, 스크립트 에러, 타 시스템 연동 시 오류 등 기획, 설계, 업무 시나리오 단계에서 발생된 결함
(3) GUI 결함 : 응용 프로그램의 UI 비일관성, 부정확한 커서/메시지, 데이터 타입의 표시 오류 등으로 사용자 화면 설계에서 발생된 결함
(4) 문서 결함 : 기획자, 사용자, 개발자 간의 의사소통과 기록이 원활하지 않은 경우에 발생하는 결함

548p ✍️ 결함 심각도
(1) High : 시스템이 중단(또는 다운)되어 더 이상 프로세스를 진행할 수 없게 만드는 결함으로 시스템의 핵심 요구사항 미구현, 시스템 다운, 장시간 시스템 응답 지연, 시스템 복구 후 데이터 왜곡 등의 경우
(2) Medium : 시스템의 흐름에 영향을 미치는 결함으로 부적확한 기능, 부정확한 업무 프로세스, 데이터 필드 형식의 오류, 데이터베이스 에러, 보안 관련 오류 등의 경우
(3) Low : 시스템의 흐름에는 영향을 미치지 않는 결함이나 상황에 맞지 않는 용도와 화면 구성(Configuration) 결함으로 부정확한 GUI 및 메시지, 에러 시 메시지 미출력, 화면상의 문법/절차 오류 등

---

2. 사용성 테스트 수행하기

557p ✍️ Mock 테스트 객체 유형

객체 유형	수행 내용
Dummy	객체의 전달에만 사용되고 실제로는 사용하지 않는 것. 주로 매개변수 목록을 채우는 데 쓰임
Fake	실제로 동작하도록 구현되지만 보통 빠른 구현을 위해 실제 환경과는 다르게 구현 할 수 있음
Stubs	테스트를 위해 미리 준비한 응답만을 제공하는 것. 그 외의 상황에 대해서는 정상적인 작동을 하지 못하는 것이 일반적이고 호출에 대한 정보를 기록하는 겅우도 있음
Mocks	스펙을 통해 정의된 응답을 받고 다른 응답을 받을 경우 예외를 발생하도록 구현되어 있으며 응답에 대한 확인을 수행하는 역할

558p ✍️ 부하 및 성능 테스트
: 동시접속으로 시스템에 많은 요청(업데이트, 조회 등)이 발생될 때 어떻게 가동되는지 확인하는 테스트

분류	기본 공식 내용
동시 이용자 수	TPS(Throughput)X호출간격(응답시간Sec+대기시간Sec)
동시 단말 이용자	PC앞에 앉아서 시스템을 이용하는 이용자로서 Active User와 (가상적으로) In-active User의 합으로 정의
액티브 이용자	동시에 같은 서비스나 업무를 실행하고 나서 응답을 기다리고 있는 이용자
처리량	단위 시간당 처리하는 건수, 단위는 tps(transaction per second), tpm, tph를 사용하고, 관점에 따라 두 가지 유형이 있으며 요청을 받는 입장에서 단위 시간당 요천 건수와 단위 시간당 처리 건수로 구분되어 표현
대기시간	응답을 받은 직후부터 다음 명령 또는 호출할 때까지 사용자가 대기하는 시간

560p ✍️ 결함 관련 용어
(1) 에러(Error) - 소프트웨어 개발 또는 유지 보수 수행 중에 발생한 부정확한 결과로 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등
(2) 오류(Fault) - 프로그램 콪드 상에 존재하는 것으로 비정상적인 프로그램과 정상적인 프로그램 버전 간의 차이로 인하여 발생되며 잘못된 연산자가 사용된 경우에 프로그램이 서브루틴으로부터의 에러 리턴을 점검하는 코드가 누락된 것
(3) 실패(Failure) - 정상적인 프로그램과 비정상적인 프로그램의 실행 결과의 차이를 의미하며 프로그램 실행 중에 프로그램의 실제 실행 결과를 개발 명세서에 정의된 예상 결과와 비교함으로써 발견
(4) 결함(Defect) - 버그, 에러, 오류, 실패, 프로그램 실해엥 대한 문제점, 프로그램 개선 사항 등의 전체를 포괄하는 용어

572p ✍️ 소프트웨어 인스펙션 (Software Inspection)
(1) 코드 인스펙션 외에도 설계 및 설계 산출물까지 포괄하여 소프트웨어 인스펙션으로 부르기도 함
(2) 매우 효과적인 테스트 방법으로서 어떠한 다른 테스트 방법으로 대체할 수 없고 상당한 시간이 필요한 작업이며 통계에 따르면 인스펙션을 적절히 잘 수행하기만 하면 포함된 에러의 90%까지 찾아낼 수 있음
(3) 코드 인스펙션, 워크스루와 같이 몇 시간 동안 수행되는 단위 미팅과는 구별되어야 함. 적절한 코드 인스펙션은 여러 날이 필요하고 도구의 도움이 있어야 함
(4) 적절한 인스펙션은 소프트웨어 개발의 전체 수명 주기에 걸친 리소스 절감과 그에 따른 비용 감소 그리고 산출물의 품질을 향상시키는 것으로 나타남

575p ✍️ 인스펙션과 워크스루의 차이점
: 인스펙션은 워크스루와 달리 체크리스트를 기반으로 검토하며 발견된 모든 결함을 제거해야 한다는 특징이 있음. 완성도가 기준 이상일 때 수행함으로써 모든 결함을 없애는 데 주요 목적이 있음

577p ✍️ 형상관리
: 복수의 이용자가 네트워크를 이용해서 소프트웨어를 개발하거나 문서를 작성하는 경우 파일과 내용은 빈번히 변화하게 되는데 변경과 이력을 파일마다 관리함

단계	설명
형상 식별	형상 관리 대상을 구분하고 관리 목록 번호 부여
버전 관리	진화 그래프 등을 통해 SCI의 버전 부여/갱신
변경 통제	SCI에 대한 접근 및 동기화 제어
형상 감사	SCI 무결성을 평가하여 공식적으로 승인
상태 보고	개발자와 유지 보수자에게 변경 사항을 공지