정보처리기사 실기 문제 정리 240407

SECTION 03. UI 프로토타입 작성

01. 다음에 설명하는 UI 프로토타입 도구를 쓰시오

 - 제품을 구성하는 서로 다른 레이아웃을 정적이면서 간단한 표현 상태로 재현한 것을 의미

 - 이름과 같이 와이어로 설계된 모양으로, 간단한 와이어를 사용하여 인터페이스를 시각적으로 묘사

 - 기획 단계 초기에 작성, 구성할 화면의 대략적인 레이아웃이나 UI 요소 등의 틀(Frame)을 설계하는 단계

 - 개발 관계자(디자이너, 개발자, 기획자) 사이의 레이아웃 협의, 현재 진행 상황 등을 공유할 때 사용

-> 와이어 프레임

 

02. UI 설계시 프로토타입을 사용함으로써 얻을 수 있는 장점

-> 사용자 설득과 이해가 쉽다. 개발 시간이 감소한다. 오류를 사전에 발견할 수 있다.

 

03. 다음 UI 프로토타입 계획 시 고려사항 중 프로토타입 일정 확인에 관한 내용이다. 빈칸에 알맞은 답

 - 프로토타입 일정 확인 단계에서는 대형 프로젝트 기준 ( 1 ) 정도로 하고, 목적이 분석이나 설계 가이드 검증일 경우 ( 2 ) 추가할 수 있다. 프로토타입 범위 확인 및 아키텍처의 핵심 요소를 범위로 설정하며 프로토타입 인원도 확인

-> 1 : 1개월

-> 2: 2개월

 

04. UI 프로토타입 계획 시 고려사항 중 프로토타입 개발자는 몇 명으로 하는 것이 좋을지

-> 3~4인

 

CHAPTER 02. UI 설계하기

SECTION 01. 소프트웨어 아키텍처 품질 특성

01. UI 설계에서 다음이 설명하는 것이 무엇을 말하는지

 - 다수의 이해관계자가 참여하는 복잡한 개발에서 상호 이해, 타협, 의사소통을 체계적으로 접근하기 위하여 개발 대상 소프트웨어의 기본 틀(뼈대)을 만드는 것

 - 전체 시스템이 전반적인 구조를 체계적으로 설계하는 것

-> 소프트웨어 아키텍처(Software Architecture)

 

02. 소프트웨어 아키텍처 품질 특성 중 고객 체감 불만 정도가 가장 높은 요구사항

-> 기능성

 

03. 다음 ISO/IEC 9126 품질 특성 중 내/외부 품질 특성이 아닌 것

 - 기능성, 효과성, 신뢰성, 사용성, 효율성, 안정성, 유지보수용이성, 이식성, 만족도

-> 효과성, 안정성, 만족도

 

04. ISO/IEC 9126 품질 특성인 신뢰성의 상세 요구사항 3가지

-> 성숙성, 고장허용성, 회복성

 

SECTION 02. UI 설계

01. UI 설계 원칙 4가지

-> 직관성, 유효성, 학습성, 유연성

 

02. UI 설계 지침 중 '주요 기능은 메인 화면에 배치하여 조작이 쉽게 한다'는 지침

-> 가시성

 

03. UI 시나리오 문서의 작성 요건 중 다음 내용이 의미하는 요건

 - 시나리오 변경사항은 쉽게 추적이 가능해야 함

 - 변경사항들이 언제, 어디서, 어떤 부분들이, 왜 발생하였는지 추적이 쉬워야 함

-> 추적 용이성(Traceable)

 

04. 스토리보드 작성 방법 중 우측 상단에 작성해야 하는 것

-> 제목, 작성자

 

05. UI 설계 단계에서 디자인 평가 방법론 3가지

-> 사용성 공학(Usability Engineering), GOMS, 휴리스틱(Heuristics)

 

06. UI 설계 원리 중 실행 차를 줄이기 위한 UI 설계 원리 3가지

-> 사용 의도 파악, 행위 순서 규정, 행위 순서 실행

 

PART 07. 애플리케이션 테스트 관리

CHAPTER 01. 애플리케이션 테스트 케이스 설계하기

SECTION 01. 애플리케이션 테스트 케이스 설계

01. 소프트웨어의 결함을 찾아내는 활동인 소프트웨어 테스트는 3가지 관점

-> 품질 향상 오류 발견, 오류 예방

 

02. 소프트웨어 테스트의 원리 중 '사옹자의 요구사항을 만족하지 못하는 오류를 발견하고 그 오류를 제거하였다고 해도, 해당 애플리케이션의 품질이 높다고 말할 수 없다'는 원리

-> 오류-부재의 궤변(Absence of Errors Fallacy)

 

03. 소프트웨어 테스트의 산출물 4가지

-> 테스트 계획서, 테스트 케이스, 테스트 시나리오, 테스트 결과서

 

SECTION 02. 테스트 케이스, 오라클, 시나리오

01. 특정한 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행조건, 기대결과로 구성된 테스트 항목의 명세서를 이용하는 명세 기반 테스트의 설계 산출물

-> 테스트 케이스

 

02. 다음이 설명하는 것

 - 테스트의 결과가 참인지 거짓인지 판단하기 위해 사전에 정의된 참(True) 값을 입력하여 비교하는 기법 및 활동

-> 테스트 오라클

 

03. 테스트 시나리오 작성 시 유의점으로 알맞은 것

 가. 시스템별, 모듈별, 항목별로 분리하지 않고 테스트 시나리오 작성

 나. 고객의 요구사항과 설계문서 등을 토대로 테스트 시나리오 작성

 다. 테스트 항목은 식별자 번호, 순서 번호, 테스트 데이터, 테스트 케이스, 예상 결과, 확인 등의 항목을 포함하여 작성

-> 나, 다

 

04. 여러 테스트 케이스의 집합으로 테스트 케이스의 동작 순서를 정의한 기술 문서

-> 테스트 시나리오

 

05. 테스트 시나리오 작성 시에는 ( ), ( ), ( )(으)로 분리하여 테스트 시나리오를 작성한다. 빈칸에 알맞은 답

-> 시스템별, 모듈별, 항목별

 

SECTION 03. 애플리케이션 테스트 유형

01. 다음이 설명하는 테스트 관련 용어

 - 애플리케이션 개발 단계에 따라 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트, 설치 테스트로 분류

 - 애플리케이션을 총체적으로 관리하기 위한 테스트 활동 묶음

 - 각각 테스트 레벨은 서로 독립적, 각각 다른 테스트 계획과 전략을 필요

-> V-모델

 

02. 애플리케이션 테스트에서 다음이 설명하는 것

 - 제품이 명세서대로 완성되었는지 검증하는 단계

 - 개발자의 시각에서 제품의 생산 과정을 테스트 하는 것

-> 검증(Verification)

 

03. 화이트박스 테스트 제어구조 검사 기법 중 "프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법"

-> 루프 검사

 

04. 테스트 기반에 따른 테스트 기법 3가지

-> 구조 기반, 명세 기반, 경험 기반

 

05. 구조 기반 테스트 기법은 소프트웨어의 내부 논리적 흐름에 따라 테스트 케이스를 작성하고 확인하는 기법이다. 구조 기반 테스트 기법의 종류 3가지

-> 구문, 결정, 조건

 

CHAPTER 02. 애플리케이션 통합 테스트하기

SECTION 01. 단위 모듈 테스트

01. 다음이 설명하는 용어

 - 소프트웨어 구현에 필요한 다양한 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것을 의미

 - 사용자 또는 다른 모듈로부터 값을 전달받아 시작되는 작은 프로그램

 - 독립적인 컴파일이 가능, 다른 모듈에 호출되거나 삽입될 수 있음

-> 단위 모듈

 

02. 다음이 설명하는 용어

 - 큰 규모의 시스템을 분해하여 단위 기능별로 계층적으로 구조화하고, 단순하게 추상화한 문서

-> 단위 기능 명세서

 

03. 모듈화의 원리 중에서 '복잡한 문제를 분해하고 모듈 단위로 문제를 해결한다' 라는 원리

-> 분할과 지배

 

04. 테스트 커버리지는 크게 3가지로 구분

-> 기능 기반 커버리지, 라인 커버리지, 코드 커버리지

 

05. 테스트 커버리지에서 소프트웨어 테스트 충분성 지표 중 하나로 소스코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트되었는지 측정하는 기법

-> 코드 커버리지

 

SECTION 02. 통합 테스트

01. 통합 테스트는 각 모듈을 결합하여 시스템을 완성하는 과정에서 모듈 간 인터페이스 혹은 통합된 컴포넌트간 상호 작용 오류 및 결함을 찾아 해결하기 위한 테스트 기법. 다음 특징을 갖는 통합 방식

 - 모든 모듈이 결합된 프로그램 전체가 대상

 - 규모가 작은 소프트웨어에 적합

 - 오류를 발견하거나 장애 위치를 파악하고 수정하는 것이 어려움

-> 비점진적 통합(빅뱅 통합)

 

02. 다음의 테스트 방법

 - 상향식과 하향식의 장점을 이용하는 방식(상향식+하향식)

 - 하위 프로젝트가 있는 대규모 프로젝트에 사용하는 방식

 - 병렬 테스트가 가능하고 시간 절약 가능

 - 스텁(Stub)과 드라이버(Driver)의 필요성이 매우 높은 방식, 비용이 많이 들어감

-> 샌드위치 테스트(혼합식 테스트)

 

03. 회귀 테스트의 유형 3가지

-> Retest All 기법, Selective 기법, Priority 기법

 

04. 다음이 설명하는 통합 검사 기법

 - 상위 컴포넌트를 테스트하고 점증적으로 하위 컴포넌트를 테스트

 - 주요 제어 모듈 기준으로 아래로 통합하며 진행

 - 하위 컴포넌트 개발이 완료되지 않으면 스텁(Stub)을 사용

-> 하향식 통합 검사

 

SECTION 03. 결함 관리

01. 애플리케이션 테스트 관리 단계 중 결함 관리에서 다음이 의미하는 것

 - 사용자의 요구사항을 잘못 파악하거나 잘못 이해할 때 발생하는 실수(Mistake) 등을 의미하며 보통 버그(Bug)를 의미

 - 소프트웨어 개발 또는 유지보수 수행 중에 사람에 의해 발생하는 부정확한 결과로 개발자의 실수로 발생한 오타, 개발 명세서의 잘못된 이해, 서브루틴의 기능 오해 등이 있음

-> 에러(Error)

 

02. 결함의 심각도별 분류 중 가장 중대한 결함 단계

-> 치명적(Critical) 결함

 

03. 결함 관리 도구 중 '소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 및 이슈 관리, 추적을 지원하는 오픈 소스 도구'

-> Mantis

 

04. 결함의 3가지 구분

-> 에러, 결점(버그, 결함), 실패(장애)

 

05. 주로 애플리케이션이나 데이터베이스 처리에서 발생하는 결함

-> 시스템 결함

 

CHAPTER 03. 애플리케이션 성능 개선하기

SECTION 01. 애플리케이션 성능 분석

01. 오픈 소스 성능 테스트 도구 중에서 Cross Platform에서 동작하며, HTTP, JDBC 등의 웹 서비스를 대상으로 부하 테스트를 수행하는 서버 모니터링에 UI를 강화한 도구

-> LoadUI

 

02. 애플리케이션 성능 저하 원인 분석 과정 중 다음이 설명하는 DB 연결 및 쿼리 실행 시 발생하는 성능 저하 원인

 - 실제 필요한 데이터보다 많은 대량의 데이터 요청이 들어올 때 발생

 - 결과 세트에서 마지막 위치로 커서를 옮기는 작업이 빈번한 경우 응답 시간 저하 현상 발생

-> 불필요한 DB fetch

 

03. 애플리케이션의 성능을 측정하기 위한 지표 중 "요구를 입력한 시점부터 트랜잭션 처리 후 그 결과의 출력이 완료될 때까지 걸리는 시간"

-> 경과 시간(Turnaround Time)

 

SECTION 02. 애플리케이션 성능 개선

01. 애플리케이션 성능 개선 과정 중 소스코드 품질 분석 도구는 정적 분석 도구와 동적 분석 도구로 나눌 수 있다. 다음 보기에서 동적 분석 도구

 가. pmd 

 나. cppcheck

 다. ccm

 라. cobertura

 마. Avalanche

 바. Valgrind

 사. SonarQube

 아. CheckStyle

-> 마, 바

 

02. 나쁜 코드의 한 종류로 '처리 로직의 제어가 체계화되어 있지 않고 서로 얽혀 있는 코드'

-> 스파게티 코드

 

03. 정적 소스코드 품질 분석 도구의 종류 중에서 미사용 변수, 최적화되지 않은 코드 등 결함 유발이 가능한 코드를 검사하는 도구

-> pmd

 

04. 동적 소스코드 품질 분석 도구 기법 중에서 동적 역공학 분석 도구를 이용하여 구조분석을 하는 기법

-> 리버스 엔지니어링