본 글은 작성자가 기사 자격증 취득을 위해 공부하고자 정리겸 작성한 글입니다.
정리본을 무료로 공유해주시는 분들의 자료를 참고했으며 페이지 하단에 출처를 남깁니다.
★ 표시는 20년도 정보처리기사 개편이후 출제된적 있는 경우 입니다.
1. 자료구조
1) 자료 구조의 분류
▶ 선형 구조(Linear Structure)
- 배열(Array)
- 스택(Stack)
- 큐(Queue)
- 데크(Deque)
- 선형 리스트(Linear List) : 연속 리스트(순차적), 연결 리스트(비 순차적)
▶ 비선형 구조(Non-Linear Structure)
- 트리(Tree)
- 그래프(Graph)
2) 배열(Array) ★
- 정적인 자료 구조로 기억장소의 추가가 어렵고 메모리의 낭비가 발생함
- 반복적인 데이터 처리 작업에 적합한 구조
- 데이터마다 동일한 이름의 변수를 사용해 처리가 간편함
3) 스택(Stack) ★
- 리스트의 한쪽 끝으로만 자료의 삽입, 삭제 작업이 이뤄지는 자료 구조
- 후입선출(LIFO: Last In First Out) 방식
4) 큐(Queue)
- 리스트의 한쪽에서는 삽입 작업, 다른 한쪽에서는 삭제 작업이 이뤄지는 자료 구조
- 선입선출(FIFO: First In First Out) 방식
- 시작(F, Front)과 끝(R, Rear)을 표시하는 두 개의 포인터가 있음
- 운영체제의 작업 스케줄링에 사용함
5) 데크(Deque)
- 리스트의 양쪽 끝에서 삽입과 삭제작업을 할 수 있는 자료 구조
6) 선형 리스트(Linear List)
▶ 연속 리스트(Contiguous List)
- 배열과 같이 연속되게 저장되는 자료 구조
- 기억장소를 연속적으로 배정받고, 기억장소 이용 효율이 가장 좋음
- 중간에 데이터를 삽입하려면 연속된 빈 공간이 있어야함
- 삽입, 삭제 시 자료의 이동이 필요함
▶ 연결 리스트(Linked List)
- 자료들을 반드시 연속적으로 배열시키지 않고 임의의 기억공간을 기억시키되, 자료 항목의 순서에 따라 노드의 포인터 부분을 이용해 서로 연결시킨 자료 구조
- 노드의 삽입, 삭제 작업이 용이
- 기억공간이 연속적으로 놓여 있지 않아도 저장가능
- 연결을 위한 포인터가 필요하기 때문에 순차 리스트에 비해 기억 공간의 효율이 좋지 않음
- 연결을 위한 포인터를 찾는 시간이 필요하기 때문에 접근 속도가 느림
- 중간 노드 연결이 끊어지면 그 다음 노드를 찾기 힘듦
7) 트리(Tree) ★
- 정점(Node)과 선분(Branch, 가지)을 이용해 사이클을 이루지 않도록 구성한 그래프(Graph)의 특수한 형태
- 노드(Node): 트리의 기본요소, 자료항목과 다른 항목에 대한 가지(Branch)를 합친 것
- 루트 노드(Root Node): 트리의 맨 위에 있는 노드
- 차수(Degree): 각 노드에서 뻗어나온 가지의 수 ★
- 단말 노드(Terminal Node): 자식이 하나도 없는 노드, Degree가 0인 노드★
- 자식 노드(Son Node): 어떤 노드에 연결된 다음 레벨의 노드들
- 부모 노드(Parent Node): 어떤 노드에 연결된 이전 레벨의 노드들
- 형제 노드(Brother Node, Sibling): 동일한 부모를 갖는 노드들
- 트리의 차수: 노드들의 차수 중에서 가장 많은 수★
8) 그래프(Graph) ★
▶ 방향 그래프
- 정점을 연결하는 선에 방향이 있는 그래프
- n 개의 정점으로 구성된 방향 그래프의 최대 간선 수 = n(n-1)
▶ 무방향 그래프
- 정점을 연결하는 선에 방향이 없는 그래프
- n 개의 정점으로 구성된 무방향 그래프의 최대 간선 수 = n(n-1)/2
2.데이터 입출력
데이터 구분 용어 ★
- 공용 데이터(Shared Data): 여러응용 시스템들이 공동으로 소유하고 유지하는 자료
- 통합된 데이터(Integrated Data): 자료의 중복을 최대로 배제한 데이터의 모임
- 운영 데이터(Operational Data): 고유한 업무를 수행하는데 필요한 자료
- 저장된 데이터(Stored Data): 컴퓨터가 접근할 수 있는 저장 매체에 저장된 자료
1) SQL(Structured Quer y Language) ★
- 데이터 정의어(DDL) : DOMAIN(도메인), SCHEMA(스키마), TABLE(테이블), VIEW(뷰), INDEX(인덱스)를 정의하거나 변경 또는 삭제할 때 사용하는 언어
- 데이터 조작어(DML): SELECT(검색), INSERT(삽입), UPDATE(갱신), DELETE(삭제)로 저장된 데이터를 실질적으로 처리하는 데 사용하는 언어
- 데이터 제어어(DCL): 데이터의 무결성, 보안, 회복, 병행 제어등을 하는데 사용되는 언어
2) 데이터 맵핑(Data Mapping) ★
- 소프트웨어의 기능구현을 위해 프로그래밍 코드와 데이터베이스의 데이터를 연결(Mapping)하는 것을 말함
- SQL Mapping: 프로그래밍 코드내 SQL을 직접 입력해 DBMS의 데이터에 접속하는 기술 ★
ex) JDBC, ODBC, MyBatis
- ORM(Object-Relational Mapping): 객체(Object)와 관계형데이터베이스(RDB)의 데이터를 연결(Mapping)하는 기술
ex) JPA, Hibernate, Django
3) 트랜잭션(Transaction) ★
- 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위
- 한꺼번에 모두 수행되어야 할 일련의 연산들
- COMMIT: 트랜잭션 처리가 정상적으로 종료되어 수행한 변경 내용을 DB에 반영하는 명령어
- ROLLBACK: 트랜잭션 처리가 비정상으로 종료되어 DB의 일관성이 깨졌을 때 트랜잭션이 행한 모든 변경 작업을 취소하고 이전 상태로 되돌리는 연산
- CHECKPOINT: 트랜잭션 내에서 ROLLBACK 할 위치인 저장 점을 지정하는 명령어, 여러 개의 SAVEPOINT 지정 가능
| 특징 | 설명 |
| 영속성 (Durability) | 성공적으로 완료된 트랜잭션 결과는 영구적으로 반영됨 |
| 독립성 (Isolation) | 둘 이상 트랜잭션 동시 실행시 한 개의 트랜잭션만 접근이 가능하여 간섭불가 |
| 일관성 (Consistency) | 트랜잭션이 실행 완료후 일관성 있는 데이터베이스 상태를 유지 |
| 원자성 (Atomicity) | 트랜잭션 연산을 데이터베이스 모두에 반영 또는 반영하지 말아야 함(All or Nothing) |
3.절차형 SQL
1) 정의
- C, JAVA등의 프로그래밍 언어와 같이 연속적인 실행이나 분기, 반복등의 제어가 가능한 SQL
- 일반적인 프로그래밍 언어에 비해 효율이 떨어짐
- 연속적인 작업들을 처리하는데 적합
- BEGIN ~ END 형식으로 작성되는 블록(Block)구조로 기능별 모듈화 가능
- 프로시저(Procedure): 호출을 통해 미리 저장해 놓은 SQL작업수행, 결과는 한 개 이상의 값 혹은 반환을 아예 하지않음
- 트리거(Trigger): 입력, 갱신, 삭제 등의 이벤트가 발생할 때마다 관련 작업을 자동수행
- 사용자 정의 함수: 프로시저와 유사하게 SQL을 사용해 일련의 작업을 연속적으로 처리, 종료시 예약어를 사용해 처리 결과를 단일값으로 반환
2) 테스트와 디버깅
- 테스트 전 구문오류(Syntax Error)나 참조 오류의 존재여부 확인
- 오류및 경고 메시지가 상세히 출력되지 않으므로 SHOW 명령어를 통해 내용 확인
- 실제로 데이터베이스에 변화를 줄 수 있는 삽입 및 변경 관련 SQL문을 주석으로 처리하고 디버깅 수행
3) 쿼리 성능 최적화
- 데이터 입출력 애플리케이션의 성능향상을 위해 SQL코드를 최적화하는 것
- 성능 측정 도구 APM을 사용해 최적화할 쿼리를 선정
- 최적화할 쿼리에 대해 옵티마이저(Optimizer)가 수립한 실행 계획을 검토하고 SQL 코드와 인덱스 재구성
4.개발지원 도구
1) 통합개발 환경(IDE)
- 개발에 필요한 환경인 편집기(Editor), 컴파일러(Compiler), 디버거(Debugger)등의 다양한 툴을 하나의 인터페이스로 통합해 제공
2) 빌드 자동화 도구 ★
- 전처리(Preprocessing), 컴파일(Complie)등의 작업들을 수행하는 소프트웨어
▶ Ant(Another Neat Tool)
- 아파치 소프트웨어 재단에서 개발한 소프트웨어
- 자바프로젝트의 공식적인 빌드 자동화 도구
- XML 기반의 빌드 스크립트를 사용
- 정해진 규칙이나 표준이 없어 개발자가 모든것을 정의
- 스크립트의 재사용이 어려움
▶ Maven
- 아파치 소프트웨어 재단에서 Ant의 대안으로 개발
- 규칙이나 표준이 존재해 예외사항만 기록됨
- 컴파일과 빌드를 동시에 수행가능
- 의존성(Dependency)을 설정하여 라이브러리를 관리
▶Gradle ★
- 기존의 Ant와 Maven을 보완해 개발된 빌드 자동화 도구
- 안드로이드 스튜디오의 공식 빌드 도구
- Maven과 동일하게 의존성 활용
- 그루비 기반의 빌드 스크립트 사용
- 플러그인을 설정하면, JAVA, C/C++, Python등 빌드가능
- 실행할 처리 명령들을 모아 태스크(Task)로 만든 후 태스크 단위로 실행
- 이전에 사용했던 태스크를 재사용하거나 다른 시스템의 태스크를 공유할 수 있는 빌드 캐시 기능 지원
▶Jenkins ★
- JAVA 기반의 오픈 소스형태로 가장 많이 사용되는 빌드 자동화 도구
- 서블릿 컨테이너에서 실행되는 서버기반 도구
- SVN, Git등 대부분의 형상 관리 도구와 연동가능
- Web GUI 제공
- 여러 대의 컴퓨터를 이용한 분산 빌드나 테스트 가능
5.소프트웨어 패키징
1) 정의
- 모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것
- 개발자가 아닌 사용자를 중심으로 진행
2) 고려사항
- 운영체제(OS), CPU, 메모리등에 필요한 최소 환경을 정의
- 하드웨어와 함께 관리될 수 있도록 Managed Service형태로 제공
- 다양한 사용자의 요구사항 반영
3) 패키징 작업 순서 ★
- 기능 식별→ 모듈화 → 빌드진행 → 사용자 환경 분석 → 패키징 및 적용시험 → 패키징 변경개선 → 배포
4) 제품 소프트웨어 패키징 도구 활용 시 고려사항 ★★★
- 패키징시 사용자에게 배포되는 SW 이므로 보안 고려
- 사용자 편의성을 위한 복잡성 및 비효율성 문제 고려
- 제품 SW 종류에 적합한 암호화 알고리즘 적용
- 다양한 이기종 연동 고려
6. 릴리즈 노트
1) 릴리즈 노트(Release Note)
- 개발 과정에서 정리된 릴리즈 정보를 소프트웨어의 고객과 공유하기 위한 문서
- 개선된 작업이 있을 때마다 관련 내용을 릴리즈 노트에 담아 제공
- 개발팀에서 제공하는 소프트웨어 사양에 대한 최종 승인을 얻은 후 문서화
2) 초기 버전 작성 시 고려사항
| 항목 | 내용 |
| 머리말 (Header) ★ | 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 릴리즈 노트 날짜, 릴리즈 노트 버전★ |
| 개요 | 소프트웨어 및 변경사항 전체에 대한 간략한 내용 |
| 목적 | 해당 릴리즈 버전에서의 새 기능 또는 수정된 기능의 목록과 릴리즈 노트의 목적에 대한 간략한 내용 |
| 문제 요약 | 수정된 버그에 대한 설명 또는 릴리즈 추가 항목에 대한 요약 |
| 재현 항목 | 버그 발견에 대한 과정 설명 |
| 수정/ 개선 내용 | 버그를 수정 / 개선한 내용을 간단히 설명 |
| 사용자 영향도 | 사용자가 다른 기능을 사용하는데 있어 해당 릴리즈 버전에서의 기능 변화가 미칠 수 있는 영향에 대한 설명 |
| 노트 | SW/HW 설치 항목, 업그레이드, 소프트웨어 문서화에 대한 참고 항목 |
| 면책 조항 | 회사 및 소프트웨어 관련 참조사항 ex) 프리웨어, 불법 복제 금지 조항등 |
| 연락처 | 사용자 지원 및 문의 응대를 위한 연락처 정보 |
3) 추가 버전 작성 시 고려사항
- 베타 버전이 출시되거나 긴급한 버그 수정, 업그레이드와 같은 자체 기능 향상, 사용자 요청 등의 특수한 상황이 발생하는 경우 추가로 작성
- 버그 번호를 포함한 모든 수정된 내용을 담아 릴리즈 노트 작성
- 추가나 수정된 경우 자체 기능 향상과는 다른 별도의 릴리즈 버전출시하고 릴리즈 노트 작성
4)릴리즈 노트 작성 순서
- 모듈 식별 → 릴리즈 정보 확인 → 개요 작성 → 영향도 체크 → 정식 릴리즈 노트 작성 → 추가 개선 항목 식별
7.디지털 저작권 관리
1) 디지털 저작권 관리(DRM)★
- 디지털 콘텐츠의 전 과정에 사용되는 디지털 콘텐츠 관리 및 보호 기술
- 콘텐츠 제공자(Contents Provider): 콘텐츠를 제공하는 저작권자
- 콘텐츠 분배자(Contents Provider): 암호화된 콘텐츠를 유통하는 곳이나 사람
- 콘텐츠 소비자(Customer): 콘텐츠를 구매해서 사용하는 주체
- 패키저(Packager): 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램
- 클리어링 하우스(Clearing House): 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제관리 등을 수행하는 곳
- DRM 컨트롤러(DRM Controller): 배포된 콘텐츠의 이용 권한을 통제하는 프로그램
- 보안 컨테이너(Security Container): 콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치
2) 디지털 저작권 관리의 기술 요소 ★
- 암호화(Encryption): 콘텐츠 및 라이선스를 암호화하고 전자서명을 할 수 있는 기술
- 키 관리(Key Management): 콘텐츠를 암호화한 키에 대한 저장 및 분배 기술
- 식별 기술(Identification): 콘텐츠에 대한 식별 체계 표현 기술
- 저작권 표현(Right Expression): 라이선스의 내용 표현 기술
- 암호화 파일 생성(Packager): 콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술
- 정책 관리(Policy Management): 라이선스 발급 및 사용에 대한 정책 표현 및 관리 기술
- 크랙 방지(Tamper Resistance): 크랙에 의한 콘텐츠 사용 방지 기술
- 인증(Authentication): 라이선스 발급 및 사용의 기준이 되는 사용자 인증 기술
8. 형상 관리
1) 소프트웨어 패키징의 형상 관리(SCM) ★
- 형상 관리는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동
- 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행
2) 형상 관리의 중요성
- 소프트웨어의 변경 사항을 체계적으로 추적하고 통제할 수 있음
- 제품 소프트웨어에 대한 무절제한 변경 방지
- 진행 정도를 확인하기 위한 기준으로 사용될 수 있음
3) 형상 관리 기능
- 형상 식별: 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이하도록 작업
- 형상 통제(변경 관리): 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(베이스 라인, Base line)이 잘 반영될 수 있도록 조정하는 작업
- 형상 감사: 베이스 라인의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
- 형상 기록(상태 보고): 형상의 식별, 통제, 감사 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업
- 버전 제어: 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구(Tool)를 결합시키는 작업
4) 소프트웨어 버전 등록 용어
| 용어 | 내용 |
| 동기화 (Update) | 저장소에 있는 최신 버전으로 자신의 작업 공간(로컬/지역 저장소)을 동기화하는 것 |
| 커밋 (Commit) | 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우, 충돌(Confilct)을 알리고 diff 도구를 이용해 수정한 후, 갱신 |
| 체크인 (Check-In) | 체크아웃 한 파일의 수정을 완료 후, 저장소(Repository)의 파일을 새로운 버전으로 갱신 |
| 체크아웃 (Check-Out) | 프로그램을 수정하기 위해 저장소(Repository)에서 파일을 받아오는 것 |
| 가져오기 (Import) | 버전 관리가 되고 있지 않은 아무것도 없는 저장소(Repository)에 처음으로 파일을 복사 |
| 저장소 (Repository) | 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳 |
5) 소프트웨어 버전 등록 과정
- 가져오기(Import) → 인출(Check-Out) → 예치(Commit) → 동기화(Update) → 차이(Diff)
6) 제품 소프트웨어의 형상 관리 역할 ★
- 형상 관리를 통해 이전 리비전이나 버전에 대한 정보에 접근 가능하여 배포본 관리에 유용
- 불필요한 사용자의 소스 수정 제한
- 동일한 프로젝트에 대해 여러 개발자 동시 개발 가능
9.버전 관리 도구
1) 공유 폴더 방식
- 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식
- 개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사함
- 담당자는 공유 폴더의 파일을 자기 PC 로 복사해 컴파일 한 후 이상 유무 확인
- 파일의 변경 사항을 데이터베이스에 기록하며 관리
ex) SCCS, RCS, PVCS, QVCS
2) 클라이언트/서버 방식
- 버전 관리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식
- 서버의 자료를 개발자별로 자신의 PC(클라이언트)로 복사해 작업한 후 변경된 내용을 중앙 서버에 반영
- 모든 버전 관리는 서버에서 수행됨
- 하나의 파일을 서로 다른 개발자가 작업할 경우 경고 메시지 출력
- 서버에 문제가 생기면 다른 개발자와의 협업 및 버전 관리 작업은 중단됨
ex) CVS, SVN(Subversion)
3) 분산 저장소 방식
- 하나의 원격 저장소와 분산된 개발자 PC 의 로컬 저장소에 함께 저장되어 관리되는 방식
- 개발자별로 원격 저장소의 자료를 자신의 로컬 저장소로 복사해 작업한 후 변경 된 내용을 로컬 저장소에서 우선 반영(Commit)한 다음 이를 원격 저장소에 반영(Push)
- 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용해 작업 가능
- 로컬 저장소에서 작업을 수행할 수 있어 처리속도가 빠름
ex) Git, Bitkeeper
4) SVN(Subversion)
- CVS 를 개선한 것으로 아파치 소프트웨어 재단에서 2000 년 발표함
- 모든 개발 작업은 trunk 디렉터리에서 수행되며, 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만들어 작업을 완료한 후 trunk 디렉터리와 병합(merge)
- 커밋(Commit)할 때마다 리비전(Revision)이 1 씩 증가
- 서버는 주로 유닉스(UNIX) 사용
- 오픈 소스로 무료사용 가능
- CVS 의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능
5) Git(깃) ★
- 리누스 토발즈(Linus Torvalds)가 2005 년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노(Junio Hamano)에 의해 유지 보수되고 있음
- 원격 저장소는 여러 사람들이 협업을 위해 버전을 공동 관리하는 곳으로, 자신의 버전 관리 내역을 반영(Push)하거나 다른 개발자의 변경 내용을 가져올 때(Fetch) 사용
- 로컬 저장소는 개발자들이 본인의 실제 개발을 진행하는 장소로 버전 관리가 수행됨
- 브랜치(Branch)를 이용하면 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅 가능
- 파일의 변화를 스냅샷(Snapshot)으로 저장
- 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름 파악 가능
- 순서 : git init → git remote add → git add -all → git commit → git push
10. 애플리케이션 테스트
1) 애플리케이션 테스트 개념
- 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
- 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인(Validation)
- 소프트웨어가 기능을 정확히 수행하는지 검증(Verification)
2) 애플리케이션 테스트 원리 ★
| 원리 | 설명 |
| 오류-부재의 궤변 | 요구사항을 충족시켜주지 못한다면, 결함이 없다고 해도 품질이 높다 볼 수 없음 |
| 테스팅은 정황에 의존적 | 소프트웨어 성격에 맞게 테스트 실시 |
| 살충제 패러독스 | 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못함 ★ |
| 결함 집중 | 20%의 모듈에서 80%의 결함 발견, 파레토(Pareto) 법칙 ★ |
| 개발 초기에 테스팅 시작 | 테스팅 기간 단축, 재작업 감소로 개발 기간 단축 및 결함 예방 |
| 완벽한 테스팅은 불가능 | 무한 경로, 무한 입력 값으로 인한 어려움 |
| 테스팅은 결함이 존재함을 밝히는 것 |
결함을 줄일 순 있지만, 결함이 없다고는 증명할 수 없음 |
11.애플리케이션 테스트의 분류
1) 프로그램 실행 여부에 따른 테스트
- 정적 테스트: 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트
ex) 워크 스루, 인스펙션, 코드 검사 ★
- 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트
ex) 화이트박스 테스트, 블랙박스 테스트 ★
2) 테스트 기반에 따른 테스트
- 명세 기반 테스트: 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로
만들어 구현하고 있는지 확인하는 테스트
ex) 동등 분할, 경계값 분석(블랙박스 테스트) ★
- 구조 기반 테스트: 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고
확인하는 테스트
ex) 구문 기반, 결정 기반, 조건 기반(화이트박스 테스트)
- 경험 기반 테스트: 테스터의 경험을 기반으로 수행하는 테스트
ex) 에러 추정, 체크 리스트, 탐색적 테스팅
3) 시각에 따른 테스트
- 검증(Verification) 테스트: 개발자의 시각에서 제품의 생산 과정을 테스트하는 것
ex) 단위 테스트, 통합 테스트, 시스템 테스트
- 확인(Validation) 테스트: 사용자의 시각에서 생산된 제품의 결과를 테스트하는 것
ex) 인수 테스트(알파 테스트, 베타 테스트) ★
4) 목적에 따른 테스트 (T = 테스트)
- 병행(Parallel) T : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
- 회귀(Regression) T : 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트 ★
- 구조(Structure) T : 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
- 성능(Performance) T : 실시간 성능이나 전체적인 효율성을 진단하는 테스트
- 강도(Stress) T : 과부하 시에도 소프트웨어가 정상적으로 실행되는지 확인하는 테스트
- 안전(Security) T : 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트
- 회복(Recovery) T : 시스템에 여러가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
5) 테스트 커버리지 유형 ★
- 다중 조건 커버리지 : 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100% 보장하는 테스트 커버리지
- 변경/조건 결정 커버리지 : 각 개별 조건식이 다른 개별 조건식의 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 테스트 커버리지
- 조건/결정 커버리지 : 전체 조건식이 참/거짓 한 번씩 가지면서, 개별 조건식이 참/거짓 모두 한 번씩 갖도록 조합하는 테스트 커버리지
- 조건 커버리지 : 전체 조건식 결과와 관계없이 관계없이 각 개별 조건식이 참/거짓 한 번 모두 갖도록 개별 조건식을 조합하는 테스트 커버리지
- 결정 커버리지 : 결정 조건 내 전체 조건식이 최소한 참/거짓 한 번의 값을 가지도록 측정하는 테스트 커버리지
- 구문 커버리지 : 프로그램 내 모든 문장을 적어도 한 번 이상 실행하는 것을 기준으로 수행하는 테스트 커버리지
12.화이트박스 테스트, 블랙박스 테스트
1) 화이트박스 테스트(White Box Test) ★
- 모듈 안의 내용(작동)을 직접 볼 수 있음
- 내부의 논리적인 모든 경로를 테스트해 테스트 케이스를 설계
- 소스 코드(Source Code)의 모든 문장을 한번 이상 수행함으로써 진행됨
- 선택, 반복 등의 부분들을 수행함으로써 논리적 경로 점검
- 제어 구조 검사★
▶ 조건 검사(Condition Testing): 논리적 조건을 테스트하는 기법
▶ 루프 검사(Loop Testing): 반복(Loop) 구조에 맞춰 테스트하는 기법
▶ 데이터 흐름 검사(Data Flow Testing): 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 테스트하는 기법
▶ 기초 경로 검사 (Base Path Testing) : 대표적인 화이트박스 테스트 기법, 테스트 측정 결과는 실행 경로의 기초를 정의하는 지침으로 사용
2) 블랙박스(Black Box Test) ★
- 모듈 안에서 어떤 일(작동)이 일어나는지 알 수 없음
- 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 테스트로 기능 테스트라고도 함
- 소프트웨어 인터페이스에서 실시되는 테스트
▶오류 예측 검사 (Error Guessing): 다른 블랙박스 테스트 기법으로 찾아낼 수 없는 오류를 찾아내는 일력의 보충적 검사 기법(데이터 확인 검사)
▶비교 검사 (Comparison Testing) : 여러 버전의 프로그램에 동일한 테스트 자료를 제공해 동일한 결과가 출력되는지 테스트하는 기법
▶원인-효과 그래프 검사(Cause-Effect Graphing Testing) : 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정해 검사하는 기법
▶경계값 분석 (Boundary Value Analysis): 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용해 입력 조건의 경계값을 테스트 케이스로 선정해 검사하는 기법
▶ 동치 분할 검사 (Equivalence Partitioning Testing) : 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 해 테스트 케이스를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 기법(동등 분할 기법)
13.개발 단계에 따른 애플리케이션 테스트
1) 단위 테스트(Unit Test) ★
- 코딩 직후 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트 하는 것
- 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행
- 명세 기반 테스트, 구조 기반 테스트 중 주로 구조 기반 테스트를 시행함
2) 통합 테스트(Integration Test) ★
- 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트를 의미
- 모듈 간 또는 통합된 컴포넌트 간의 상호 작용 오류 검사
ex) 빅뱅 테스트, 상향식 테스트(클러스터, Cluster/드라이버, Driver), 하향식 테스트(스텁, Stub) ★
3) 시스템 테스트(System Test) ★
- 개발된 소프트웨어가 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
- 실제 사용 환경과 유사하게 만든 테스트 환경에서 테스트 수행해야 함
- 기능적 요구사항(블랙박스 테스트), 비기능적 요구사항(화이트박스 테스트) 구분
4) 인수 테스트(Acceptance Test) ★
- 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두는 테스트
▶베타 테스트 : 통제되지 않은 환경에서 여러 명의 사용자가 행하는 테스트 기법 (게임 베타 테스터) ★
▶알파 테스트 : 통제된 환경에서 사용자가 개발자와 함께 확인하면서 행하는 테스트 기법 ★
14. 통합 테스트
1) 상향식 통합 테스트(Bottom Up Integration Test)
- 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트하는 기법
- 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster) 필요
▶ 하위 모듈들을 클러스터(Cluster)로 결합 → 더미 모듈인 드라이버(Driver) 작성 → 통합된 클러스터 단위로 테스트 → 테스트 완료 후 클러스터는 프로그램 구조의 상위로 이동해 결합하고 드라이버는 실제 모듈로 대체됨 ★
2) 하향식 통합 테스트(Top Down Integration Test) ★
- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트하는 기법
- 깊이 우선 통합법, 넓이 우선 통합법 사용
- 테스트 초기부터 사용자에게 시스템 구조를 보여줄 수 있음
- 상위 모듈에서는 테스트 케이스 사용하기 어려움
▶ 주요 제어 모듈은 작성된 프로그램을 사용, 주요 제어 모듈의 종속 모듈은 스텁(Stub)으로 대체 → 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 하위 모듈인 스텁(Stub)들이 한 번에 하나씩 실제 모듈로 교체됨 → 모듈이 통합될 때마다
테스트 실시 → 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트 실시
ex) 스텁(Stub) ★
3) 혼합식 통합 테스트
- 하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용해 최적의 테스트를 지원하는 방식
- 샌드위치(Sandwich)식 통합 테스트 방법
15.테스트 케이스, 테스트 시나리오, 테스트 오라클, 테스트 하네스
1) 테스트 케이스(Test Case)
- 구현된 소프트웨어가 사용자의 요구사항을 정확하게 준수했는지를 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서
- 명세 기반 테스트(블랙박스 테스트)의 설계 산출물에 해당
- 미리 설계해두면 테스트 오류 방지 및 테스트 수행 자원의 낭비를 줄일 수 있음
2) 테스트 시나리오(Test Scenario)
- 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합
- 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서
▶ 작성 시 유의 사항
- 시스템별, 모듈별, 항목별 등과 같이 여러 개의 시나리오로 분리해 작성
- 사용자의 요구사항과 설계 문서 등을 토대로 작성
3) 테스트 오라클(Test Oracle)
- 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입해 비교하는 활동
▶ 특징
- 제한된 검증: 모든 테스트 케이스에 적용할 수 없음
- 수학적 기법: 값을 수학적 기법을 이용해 구할 수 있음
- 자동화 기능: 프로그램 실행, 결과 비교, 커버리지 측정 등을 자동화할 수 있음
▶일관성(Consistent)검사 오라클: 변경이 있을 때 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클
▶휴리스틱(Heuristic 추정) 오라클: 샘플링 오라클을 개선한 오라클, 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
▶샘플링(Sampling) 오라클: 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
▶참(True) 오라클: 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클, 발생된 모든 오류를 검출할 수 있음
4) 테스트 하네스(Test Harness) ★
▶목 오브젝트 (Mock Object):사전에 사용자의 행위를 조건부로 입력해 두면, 그 상황에 맞는 예정된 행위를 수행하는 객체
▶테스트 스크립트 (Test Script) : 자동화된 테스트 실행 절차에 대한 명세서
▶테스트 케이스 (Test Case): 사용자의 요구사항을 정확하게 준수했는지 확인하기 위한 입력 값, 실행 조건, 기대 결과 등으로 만들어진 테스트 항목 명세서
▶테스트 슈트 (Test Suites): 테스트 대상 컴포넌트나 모듈 등 시스템에 사용되는 테스트 케이스의 집합
▶테스트 스텁 (Test Stub): 테스트 대상의 상위 모듈을 대신하는, 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구
▶테스트 드라이버 (Test Driver): 테스트 대상의 하위 모듈을 호출하고 모듈 테스트 수행 후의 결과를 도출하는 도구
16.결함 관리
1) 결함 상태 추적
▶결함 에이징 (Fault Aging): 특정 결함 상태로 지속되는 시간 측정
ex) 1 개의 결함이 30 분 동안 지속됨
▶결함 추세: 테스트 진행 시간에 따른 결함 수의 추이 분석
ex) 4 시간 동안 5 개 발견
▶결함 분포: 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
2) 결함 추적 순서
1. 결함 등록(Open): 테스터와 품질 관리 담당자에 의해 발견된 결함이 등록된 상태
2. 결함 검토(Reviewed): 등록된 결함을 테스터, 품질 관리 담당자, 프로그램 리더, 담당 모듈 개발자에 의해 검토된 상태
3. 결함 할당(Assigned): 결함을 수정하기 위해 개발자와 문제 해결 담당자에게 결함이 할당된 상태
4. 결함 수정(Resolved): 개발자가 결함 수정을 완료한 상태
5. 결함 조치 보류(Deferred): 결함의 수정이 불가능해 연기된 상태
6. 결함 종료(Closed): 결함이 해결되어 테스터와 품질 관리 담당자가 종료를 승인한 상태
7. 결함 해제(Clarified): 종료 승인한 결함을 검토하여 결함이 아니라고 판명한 상태
3) 결함 심각도, 결함 우선순위
- 결함 심각도: 치명적(Critical) → 주요(Major) → 보통(Normal) → 경미(Minor) → 단순(Simple)
- 결함 우선순위: 치명적(Critical) → 높음(High) → 보통(Medium) → 낮음(Low)
17.애플리케이션 성능 분석
1) 애플리케이션 성능 ★
▶자원 사용률(Resource Usage): 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률
▶경과 시간(Turn Around Time): 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간
▶응답 시간(Response Time): 애플레이케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
▶처리량 (Throughput): 일정 시간 내 애플리케이션이 처리하는 일의 양
2) 애플리케이션 성능 저하 원인 분석
- DB 에 필요 이상의 많은 데이터를 요청한 경우
- 커넥션 풀(Connection Pool)의 크기를 너무 작거나 크게 설정한 경우
- JDBC 나 ODBC 같은 미들웨어를 사용한 후 종료하지 않아 연결 누수가 발생한 경우
- 대량의 파일을 업로드하거나 다운로드해 처리 시간이 길어진 경우
3) 소스 코드 최적화
▶클린 코드(Clean Code) 작성 원칙
- 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화
4) 소스 코드 품질분석 도구의 종류 ★
- 정적 분석 도구: pmd, cppcheck, checkstyle, SonarQube, ccm, cobertuna
- 동적 분석 도구: Avalanche, Valgrind
18. 모듈 연계
1) EAI(Enterprise Application Integration) ★
- 기업 내 각종 애플리케이션 및 플랫폼 간의 정보 전달, 연계, 통합 등 상호 연동이 가능하게 해주는 솔루션
▶하이브리드 (Hybrid): Hub & Spoke(그룹 내)와 Message Bus(그룹 간)의 혼합 방식, 데이터 병목 현상을 최소화
▶메시지 버스(Message Bus, ESB방식): 애플리케이션 사이에 미들웨어를 둬 처리하는 방식, 확장성이 뛰어나며 대용량 처리가 가능
▶허브 앤 스포크(Hub & Spoke): 단일 접점인 허브(Hub) 시스템을 통해 데이터를 전송하는 중앙 집중형 방식, 확장 및 유지보수가 용이하지만 허브 장애 발생 시 시스템 전체에 영향을 미침
▶포인트 투 포인트(Point to Point): 점 대 점으로 연결하는 방식, 변경 및 재사용이 어려움
2) ESB(Enterprise Service Bus)
- 애플리케이션 간 연계, 데이터 변환, 웹 서비스 지원 등 표준 기반의 인터페이스를 제공하는 솔루션
- 애플리케이션 통합 측면에서 EAI 와 유사하지만 애플리케이션 보다는 서비스 중심의 통합을 지향
- 결합도(Coupling)를 약하게(Loosely) 유지함
- 관리 및 보안 유지가 쉽고, 높은 수준의 품질 지원이 가능
19.인터페이스 구현, 인터페이스 보안
1) 데이터 통신을 이용한 인터페이스 구현 ★
- 애플리케이션 영역에서 인터페이스 형식에 맞춘 데이터 포맷을 인터페이스 대상으로 전송하고 이를 수신 측에서 파싱(Parsing)해 해석하는 방식
- 주로 JSON 이나 XML 형식의 데이터 포맷을 사용해 인터페이스를 구현
▶JSON(JavaScript Object Notation): 속성-값 쌍(Attribut-Value Pairs)으로 이뤄진 데이터 객체를 전달하기 위해 사람이 읽을 수 있는 텍스트를 사용하는 개방형 표준 포맷 ★
▶XML(eXtensible Markup Language): 특수한 목적을 갖는 마크업 언어를 만드는 데 사용되는 다목적 마크업 언어, 웹 페이지의 기본 형식인 HTML 의 문법이 각 웹 브라우저에서 상호 호환적이지 못하다는 문제와 SGML(Stand Generalized Markup Language)의 복잡함을 해결하기 위해 개발됨 ★
2) 인터페이스 엔터티를 이용한 인터페이스 구현
- 인터페이스가 필요한 시스템 사이에 별도의 인터페이스 엔터티로 상호 연계하는 방식
- 일반적으로 인터페이스 테이블을 엔터티로 활용
- 송, 수신 인터페이스 테이블의 구조는 상황에 따라 서로 다르게 설계할 수도 있음
3) 인터페이스 보안 기능 적용 ★
- 네트워크(Network), 애플리케이션(Application), 데이터베이스(Database) 영역
▶스니핑(Sniffing): 네트워크의 중간에서 남의 패킷 정보를 도청하는 해킹 유형 ★
▶시큐어 코딩 (Secure Coding): 소프트웨어 개발 과정에서 지켜야 할 일련의 보안 활동 ★
ex) 입력 데이터 검증 표현, 보안 기능, 시간 및 상태, 에러 처리, 코드 오류, 캡슐화, API 오용
20.인터페이스 구현 검증, 인터페이스 오류 확인
1) 인터페이스 구현 검증 도구 ★
▶watir: Ruby 언어를 사용하는 애플리케이션 테스트 프레임워크
▶Selenium: 다양한 브라우저 및 개발 언어를 지원하는 웹 애플리케이션 테스트 프레임워크
▶NTAF: STAF 의 장점인 재사용 및 확장성과 FitNesse 의 장점인 협업 기능을 통합한 NHN의 테스트 자동화 프레임워크
▶FitNesse: 웹 기반 테스트케이스 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임워크
▶STAF: 서비스 호출 및 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크 ★
▶xUnit: Java(Junit), C++(Cppunit), .Net(Nunit) 등 다양한 언어를 지원하는 단위 테스트 프레임워크
2) 인터페이스 오류 발생 즉시 확인
- 오류 메시지 알람 표시, 오류 SMS 발송, 오류 내역 이메일 발송
3) 인터페이스 오류 발생 주기적인 확인 방법
▶인터페이스 감시(APM) 도구 사용: 스카우터(Scouter)나 제니퍼(Jennifer) 등의 인터페이스 감시 도구를 사용해 주기적 확인
▶ 인터페이스 오류 테이블 확인: 오류사항의 확인이 쉬워 관리가 용이함, 오류사항이 구체적이지 않아 별도의 분석이 필요
▶인터페이스 오류 로그 확인: 오류를 별도의 로그파일로 생성해 보관함, 자세한 오류 원인 및 내역을 확인할 수 있음
참고자료 출처
1. https://blog.naver.com/ttao00730
'자격증 공부 > 정보처리기사' 카테고리의 다른 글
| 1 과목 소프트웨어 설계 (1) | 2023.02.04 |
|---|