2020개정 정보처리기사 필기 시험 전날 최종체크

 

지극히 개인적으로 중요하다고 생각하고 헷갈리는 부분을 시험 직전에 보기 좋다고 생각하여 정리한 것입니다.

 

소프트웨어 재사용을 위해서는 사용법이 공개되어야 한다.

소프트웨어 재사용은 규모에 따라 함수, 객체, 컴포넌트 단위로 재사용한다(변수)

전략은 행위패턴, 컴포지트는 구조패턴이다.

시스템 인터페이스 요구사항 분석 시, 요구사항 선별 후 관련 자료를 준비한다.

인터페이스 요구사항 검증의 주요 항목에는 완전성, 일관성, 명확성, 기능성, 검증 및 추적 가능성, 변경 용이성 등이 있다.

인터페이스 요구사항 검증 순서 : 요구사항 검토 계획 수립 -> 검토 및 오류 수정 -> 베이스라인 설정

인터페이스 식별 후 인터페이스 시스템 식별에서 내/외부를 구별한다.

거래 공통부 : 직원 정보, 승인자 정보, 기기 정보, 매체 정보

지연 처리 방식 : 매건 단위로 처리할 경우 비용이 많이 발생할 경우 사용

배치 방식 : 대량 데이터 처리 시 사용

운영 데이터 : 없어서는 안될 반드시 필요한 자료

통합된 데이터 : 자료의 중복을 배제한 데이터의 모임

파일을 잘못 복사하거나 다른 위치로 복사하는 것에 대비하기 위해~ : 공유폴더방식

오류-부재의 궤변 : 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 품질이 높다고 할 수 없다.

정적 테스트 : 실행안함, 명세서나 소스코드를 분석, 개발 초기에 결함발견 가능, 워크스루/인스펙션/코드검사

동적 테스트 : 실행하여 오류를 찾는 테스트, 블랙박스/화이트박스 테스트

명세기반 테스트 : 사용자의 요구사항에 대한 명세를 빠짐없이 테스트케이스로 만들어 구현하고 있는지 확인하는 테스트, 동등분할, 경계값분석

구조기반 테스트 : 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 작성하고 확인하는 테스트, 구문/결정/조건 기반

경험기반 테스트 : 테스터의 경험을 기반으로 함, 명세가 불충분하거나 테스트 시간에 제약 시 유용, 에러추정, 체크리스트, 탐색적 테스팅

회복테스트 : 결함을 주어 실패하도록 한 후 올바르게 복구되는지 확인

회귀테스트 : 변경 또는 수정된 코드에 새로운 결함이 없음을 확인

모든 문장을 한번씩 수행 -> 화이트박스 테스트

사용자 요구사항 명세를 보면서 수행 -> 블랙박스 테스트

애플리케이션 테스트 프로세스 : 테스트 계획 -> 테스트 분석 및 디자인 -> 테스트 케이스 및 시나리오 작성 -> 테스트 수행 -> 테스트 결과 평가 및 리포팅 -> 결함 추적 및 관리

에러(개발자, 분석가 실수)가 결함/결점/버그(에러로 인해 발생한 것)를 키운다.

애플리케이션 테스트 후 산출되는 문서 : 테스트 계획서, 테스트 케이스, 테스트 시나리오, 테스트 결과서

모든 테스트 과정을 자동화 할 수 있는 도구는 없다.

테스트 엔지니어 투입은 반드시 프로젝트 초기에 해야 한다.

테스트 드라이버 : 테스트 대상의 하위모듈을 호출하고, 파라미터를 전달하고, 모듈 테스트 수행 후의 결과를 도출하는 도구

테스트 스텁 : 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로, 일시적으로 필요한 조건만을 가지고 있는 테스트용 모듈

테스트 슈트 : 테스트 대상 컴포넌트나 모듈, 시스템에 사용되는 테스트 케이스의 집합

테스트 케이스 : 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목 명세서

테스트 스크립트 : 자동화된 테스트 실행 절차에 대한 명세서

목 오브젝트 : 사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체

결함관리 순서 : 계획 -> 기록 -> 검토 -> 수정 -> 재확인

테스트 부족으로 유입되는 결함 : 개발자의 코딩 실수, 테스트팀과 개발팀의 의사소통 부족

코딩 시 유입되는 결함 : 코딩 표준 미준수로 인한 기능의 불일치/불완전, 데이터 결함 , 인터페이스 결함 등

기획 시 유입되는 결함 : 사용자 요구사항의 표준 미준수로 인한 테스트 불가능, 요구사항 불명확/불완전/불일치 결함 등

결함관리 도구 : Mentis, Redmine, Bugzilla, Trac

결함관리 측정지표 : 결함분포(모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정), 결함추세(테스트 진행 시간에 따른 결함 수의 추이 분석), 결함에이징(특정 결함 상태로 지속되는 시간 측정)

호출하는 함수를 호출되는 함수보다 먼저 배치해야 좋다.

워크스루는 오류의 해결이 아닌 조기검출 목적이다.

단위 테스트는 주로 구조적 테스트인 화이트박스 테스트를 실행한다.

상향식 통합 테스트 순서 : 하위 모듈을 클러스터로 결합 -> 상위 모듈에서 데이터 입출력 확인을 위해 더미 모듈인 드라이버 작성 -> 클러스터 단위로 테스트 -> 클러스터를 프로그램 상위로 이동하여 결합하고 드라이버를 실제 모듈로 대체

경과시간 : 사용자가 작업을 의뢰한 순간부터 처리가 완료될 때까지 걸린 시간

테스트 절차를 명세한 것은 테스트 시나리오다.

인터페이스 설계서에서 외부모듈은 오퍼레이션, 사전조건, 송신 및 전달부분, 내부모듈은 인터페이스 영역, 수신부분이다.

모듈연계 EAI에서 하이브리드 방식은 모듈 간은 메시지버스(ESB), 모듈 내는 Hub&Spoke 방식을 사용한다.

인터페이스 오류 테이블로는 오류내역 및 원인을 구체적으로 확인할 수 없다.

 

정적 SQL : 커서를 통한 정적 처리, 커서의 범위 안에서 반복문을 활용하여 SQL 작성, 실행속도 빠름, 사전 검사 가능

동적 SQL : 문자열 변수에 담아 동적 처리, NVL 함수 없이 로직을 통해 SQL 작성, 실행속도 느림, 사전 검사 불가능

ORM으로 생성된 가상의 객체지향 데이터베이스는 프로그래밍 코드 또는 데이터베이스와 독립적이므로 재사용/유지보수가 용이하다.

WHERE절에 연산자가 포함되면 INDEX를 활용하지 못한다.

실행계획은 EXPLAIN, DDL은 DESCRIBE로 확인한다.

비용기반 옵티마이저의 성능을 좌우하는 것은 개발자의 숙련도가 아니라 알고리즘이다.

주석을 통해 결과를 검증하는 것은 절차형 SQL이다.

데이터 추출, 전환, 적재까지는 로그검증, 적재 후는 기본항목검증, 전환완료후는 응용프로그램/응용데이터 검증을 한다.

 

소프트웨어 개발 방법론 테일러링 기법 : 프로젝트 규모와 복잡도, 프로젝트 구성원, 팀내 방법론 지원, 자동화