2020 정보처리기사 필기 요점 정리(2)-소프트웨어 개발(3)

JIGGLYPOP

염동환


새로운 개발을 좋아하는 개발자

2020-02-03 05:00 시에 저장한 글입니다.

정보처리기사 공부 후 정리 자료입니다. 정확하지 않을 수 있으니 꼭 책을 참고해서 공부하세요

소프트웨어 개발

1. 데이터 입출력 구현

자료구조

프로그램에서 사용하기 위한 자료를 기억장치의 공간 내에 저장하는 방법과 자료 간의 관계, 처리 방법 등을 저장공간의 효율성 및 실행 간의 신속성을 높이기 위한 연구 분석하는 것

자료 구조의 분류
  • 배열

    • 동일한 자료형의 데이터들이 같은 크기로 나열되어 순서를 갖고 있는 집합
    • 첨자를 이용하여 데이터에 접근
    • 첨자의 개수에 따라 n차원 배열이라 부름
  • 선형 리스트

    • 일정한 순서에 의해 나열된 자료 구조
  • 연속 리스트

    • 배열을 이용한 선형 리스트
    • 중간에 데이터를 삽입하기 위해 연속된 빈 공간이 있어야 하며 삽입, 삭제 시 자료의 이동 필요
  • 연결 리스트

    • 자료 항목의 순서에 따라 노드의 포인터 부분을 이용하여 서로 연결시킨 자료 구조
    • 연결을 위한 포인터를 찾는 시간이 필요해 접근 속도가 느림
    • 노드의 삽입 삭제 작업이 용이
    • 노드 부분 때문에 연속 리스트에 비해 기억 공간의 효율이 좋지 않음

img*

  • 스택

    • 리스트의 한쪽으로 자료의 삽입, 삭제가 이루어짐
    • LIFO(Last In First Out)의 구조를 가지고 있음
    • 오버플로우(overflow) : 기억 공간이 모두 차있는 상태에서 데이터를 삽입하면 일어나는 현상
    • 언더플로우(underflow) : 기억 공간이 비어있는 상태에서 데이터를 삭제하면 일어나는 현상
    • Top : 스택에 가장 마지막으로 삽입된 자료의 위치
    • Bottom : 스택의 가장 바닥

img*

    • 리스트의 한쪽에서는 삽입 다른 한쪽에서는 삭제가 이루어짐
    • FIFO(First In First Out)의 구조를 가지고 있음
    • F(Front) : 먼저 삽입된 자료의 기억 공간을 가르키는 포인터
    • R(Rear) : 마지막에 삽입된 자료의 기억 공간을 가르키는 포인터

img*

  • 트리

    • 노드와 가지를 이용하여 사이클이 없이 구성한 그래프의 특수 형태
    • 디그리 : 노드에서 뻗어나온 가지의 개수
    • 단말노드 / 잎 노드 : 자식이 없는 노드
    • 트리의 디그리 : 노드들의 디그리 중 가장 많은 수

데이터저장소 / 데이터베이스 / DBMS


데이터저장소의 개요
  • 소프트웨어 개발 과정에서 다루어야 할 데이터들을 논리적인 구조로 조직화하거나 물리적인 공간에 구현한 것
  • 논리 데이터저장소는 데이터 및 데이터 간의 연간성, 제약 조건을 식별하여 논리적인 구조로 조직화한 것
  • 물리 데이터저장소는 논리 데이터저장소에 저장된 데이터와 구조들을 하드웨어적인 저장장치에 저장한 것
데이터베이스의 정의 (통합, 저장, 운영, 공용)

특정 조직의 업무를 수행하는데 필요한 데이터들의 모임

통합된 데이터 : 자료의 중복을 최소화

저장된 데이터: 컴퓨터가 접근할 수 있는 저장 매체에 저장

  • 운영 데이터 : 조직의 고유한 업무를 수행하는데 필요
  • 공용 데이터 : 여러 시스템이 공동으로 소유하고 유지함
DBMS(DataBase Management System)
  • 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리하는 소프트웨어
  • 기존의 파일 시스템이 가지는 데이터의 종속성과 종복성 문제를 해결하기 위해 제안된 시스템
  • DBMS의 기능

    • 정의 기능 : 데이터베이스에 저장될 데이터의 타입과 구조에 대해 명시하는 기능
    • 조작 기능 : 데이터를 검색, 갱신, 삽입, 삭제 등 처리하기 위해 사용자와 데이터베이스 간 인터페이스 수단을 제공하는 기능
    • 제어 기능 : 데이터의 무결성이 유지되도록 제어 , 사용자에게 허가된 데이터만 접근하도록 보안을 유지하고 권한을 검사

    여러 사용자가 동시에 접근하여 데이터를 처리할 때 정확성을 유지하도록 병행 제어

DBMS의 장단점
  • 장점

    • 데이터 독립성, 일관성, 무결성 유지
    • 보안 유지
    • 데이터 실시간 처리, 통합 관리, 표준화 가능
  • 단점

    • 전문가 부족
    • 전산화 비용 증가
    • 파일의 백업과 회복이 어려움
    • 시스템이 복잡함

데이터 입출력


데이터 입출력의 개요
  • 소프트웨어의 기능을 구현하기 위해 데이터베이스에 데이터를 입력, 출력하는 작업
SQL
  • 국제 표준 데이터베이스 언어
  • 데이터 정의어, 조작어, 제어어로 구분됨
데이터 접속(Data Mapping)
  • 프로그래밍 코드와 데이터베이스의 데이터를 연결하는 것
트랜잭션
  • 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 수행돼야 할 일련의 연산
  • TCL(Transaction Control Language) : 트랜잭션을 제어하기 위해 사용되는 명령어

    • COMMIT : 트랜잭션 처리가 비정상적으로 종료되어 트랜잭션이 수행한 변경 내용을 데이터베이스에 반영
  • ROLLBACK : 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성이 깨졌을 때 트랜잭션이 행한 모든 변경 작업을 취소하고 이전 상태로 되돌림

    • SAVEPOINT(CHECKPOINT) : 트랜잭션 내에 ROLLBACK 할 위치인 저장점을 지정

절차형 SQL


절차형 SQL의 개요
  • 프로그래밍 언어와 같이 연속적인 실행이나 분기, 반복 등의 제어가 가능한 SQL
  • 단일 SQL문장으로 처리가 어려운 연속적인 작업을 처리하는데 적합
  • BEGIN ~ END 형식의 블록 구조로 되어 있어 기능별 모듈화가 가능

2. 통합 구현

단위 모듈 구현


단위 모듈의 개요
  • 소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것
  • 사용자 또는 다른 모듈로부터 값을 전달받아 시작되는 작은 프로그램

img단위 모듈 구현 순서

단위 기능 명세서 작성
  • 단위 기능을 명세화한 문서
  • 복잡한 시스템을 단순하게 구현하기 위한 추상화 작업이 필요
  • 대형 시스템을 분해하여 단위 기능별로 구분하고 각 기능들로 계층적으로 구성하는 구조화 과정을 거침
입출력 기능 구현
  • 단위 기능 명세서에서 정의한 데이터 형식에 따라 입출력 기능을 위한 알고리즘 및 데이터 구현
  • 모듈 간 연동 또는 통신을 위한 데이터 구현
  • IPC(Inter Process Communication) : 모듈 간 통신을 구현하기 위해 사용되는 프로그래밍 인터페이스 집합

    • 공유 메모리 : 다수의 프로세스가 공유 가능한 메모리를 구성하여 통신 수행
  • 소켓 : 네트워크 소켓을 이용하여 네트워크를 경유하는 통신 수행

    • 세마포어 : 공유 자원에 대한 접근 제어를 통해 통신 수행
  • 파이프 : 선입선출의 형태로 구성된 메모리를 여러 프로세스가 공유하여 통신 수행

    • 메시지 큐잉 : 메시지가 발생하면 이를 전달하는 형태로 통신 수행
알고리즘 구현
  • 입출력 데이터를 바당으로 단위 기능별 요구 사항들을 구현 가능 언어를 이용하여 모듈로 구현

단위 모듈 테스트


단위 모듈 테스트의 개요
  • 모듈이 정해진 기능을 정확히 수행하는지 검증
  • 단위 테스트라고도 하며 화이트박스 테스트와 블랙박스 테스트 기법 사용
  • 시스템 수준의 오류는 발견할 수 없음
테스트 케이스
  • 구현된 소프트웨어가 요구사항을 정확히 준수했는지 확인하기 위한 테스트 항목에 대한 명세서로 명세 기반 테스트의 설계 산출물에 해당
  • 입력 데이터, 테스트 조건, 예상 결과 등을 모아 테스트 케이스를 만듦
  • 테스트 케이스의 구성 요소 : 식별자, 테스트 항목, 입력 / 출력 명세, 환경 설정, 특수 절차 요구, 의존성 기술
테스트 프로세스
  • 테스트를 위해 수행하는 작업이 테스트의 목적과 조건을 달성할 수 있도록 도와주는 과정

img*

개발 지원 도구


통합 개발 환경(IDE)
  • 개발에 필요한 편집기, 컴파일러 디버거 등의 다양한 툴을 하나의 인터페이스로 통합하여 제공
  • Eclipse, Visual Studio, Xcode, Android Studio, IDEA 등
빌드 도구
  • 소스 코드 파일들을 컴퓨터에서 실행할 수 있는 제품 소프트웨어로 변환하는 과정 또는 결과물
  • 소스 코드를 소프트웨어로 변환하는 과정에 필요한 전처리, 컴파일 등의 작업을 수행
  • Ant : 자바 프로젝트의 공식적인 빌드 도구
  • Maven : Ant의 대안으로 의존성을 설정하여 라이브러리 관리
  • Gradle : 안드로이드 스튜디오의 공식 빌드 도구
협업 도구
  • 개발에 참여하는 사람들이 서로 다른 작업 환경에서 프로젝트를 수행할 수 있도록 도와주는 도구
  • 협업 소프트웨어, 그룹웨어라고도 함
  • 협업 도구의 종류

    • 프로젝트 및 일정 관리 : 구글 캘린더, 분더리스트, 트렐, 지라, 플로우 등
  • 정보 공유 및 커뮤니케이션 : 슬랙, 잔디, 태스크 월드 등

    • 디자인 : 스케치, 제플린 등
  • 아이디어 공유 : 에버노트 등

    • API 문서화 : 스웨거 등
  • Git 웹 호스팅 서비스 : 깃허브 등

3. 제품 소프트웨어 패키징

소프트웨어 패키징


소프트웨어 패키징의 개요
  • 실행 파일을 묶어 배포용 설치 파일을 만듦
  • 사용자 중심
  • 모듈화 하여 일반 배포 형태로 패키징
패키징 고려사항
  • 사용자의 운영체제, CPU, 메모리 등에 필요한 최소 환경 정의
  • UI는 시각적인 자료와 함께 매뉴얼과 일치시켜 패키징
  • 소프트웨어는 하드웨어와 함께 관리될 수 있도록 Managed Service 형태로 제공
패키징 작업 순서

img*

릴리즈 노트 작성

릴리즈 노트의 개요
  • 개발 과정에서 정의된 릴리즈 정보를 고객에게 공유하기 위한 문서
  • 테스트 진행 방법에 대한 결과가 소프트웨어 사양에 대한 개발팀의 정확한 준수 여부 파악
  • 소프트웨어의 버전 관리 및 릴리즈 정보를 체계적으로 관리
  • 소프트웨어 초기 배포, 출시 후 개선 사항을 적용한 추가 배포 시 제공
릴리즈 노트 초기 버전 작성 시 고려사항
  • 정확하고 완전한 정보를 기반으로 개발팀에서 직접 현재 시제로 작성
  • 신규 코드, 빌드 등의 이력이 정확하게 관리되어 변경 또는 개선된 항목에 대한 이력 정보들도 작성
릴리즈 노트 추가 버전 작성 시 고려사항
  • 테스트 과정에서 베타 버전이 출시되거나 긴급 버그 수정, 업그레이드, 사용자 요청 등의 특수한 상황의 경우 작성
  • 긴급 버그 수정 시 수정하는 경우 릴리즈 버전을 출시하고 그 번호를 포함한 모든 내용을 수정된 내용을 담음
  • 요구사항에 의해 추가 혹은 수정된 경우 자체 기능 향상과는 다른 별도의 릴리즈 버전으로 출시하고 작성
릴리즈 노트 작성 순서

img*

디지털 저작권 관리


저작권의 개요
  • 창작자가 가지는 배타적 독점적 권리로 타인의 침해를 받지 않을 고유한 권한
  • 컴퓨터 프로그램처럼 복제하기 쉬운 저작물에 대해 저작권을 보호하는 방법을 저작권 보호 기술이라 함
디지털 저작권 관리(Digital Right Management)의 개요
  • 저작권자가 배포한 디지털 콘텐츠가 저작권자가 의도한 용도로만 사용되도록 생성, 유통, 이용까지 전 과정에 걸쳐 사용되는 디지털 콘텐츠 관리 및 보호 기술
  • 크기가 작은 경우 사용자가 콘텐츠를 요청하는 시점에 실시간 패키징 수행
  • 크기가 큰 경우 미리 패키징을 수행 후 배포
  • 종량제 방식을 적용한 소프트웨어의 경우 서비스의 실제 사용량을 측정하여 이용한 만큼 이용 부과
디지털 저작권 관리의 흐름도

img*

  • 클리어링 하우스 : 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제 관리 등 수행
  • 콘텐츠 제공자 : 콘텐츠를 제공하는 저작권자
  • 패키저 : 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화는 프로그램
  • 콘텐츠 분배자 : 암호화된 콘텐츠를 유통
  • 콘텐츠 소비자 : 콘텐츠를 구매해서 사용
  • DRM 컨트롤러 : 배포된 콘텐츠의 이용 권한을 통제하는 프로그램
  • 보안 컨테이너 : 콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치
디지털 저작권 관리의 기술 요소
  • 암호화, 키 관리, 암호화 파일 생성, 식별 기술, 저작권 표현, 정책 관리, 크랙 방지, 인증

소프트웨어 설치 매뉴얼 작성


소프트웨어 설치 매뉴얼의 개요
  • 개발 초기에서부터 적용된 기준이나 사용자가 소프트웨어를 설치하는 과정에 필요한 내용을 기록한 문서
  • 설치 시작부터 완료까지의 과정을 순서대로 설명
서문
  • 문서 이력, 설치 매뉴얼의 주석, 설치 도구의 구성, 설치 환경 체크 항목 기술
  • 설치 매뉴얼의 주석 : 주의 사항과 참고 사항 기술
  • 설치 환경 체크 항목 : 사용자 환경, 응용 프로그램, 업그레이드 버전, 백업 폴더 확인
기본 사항
  • 소프트웨어 개요, 설치 관련 파일, 설치 아이콘, 프로그램 삭제, 관련 추가 정보 설명
설치 매뉴얼 작성
  • 사용자가 설치 과정을 이해하기 쉽게 설치 화면을 누락 없이 캡처하여 순서대로 설명
  • 설치 화면 및 UI, 설치 이상 메시지, 설치 완료 및 결과, 설치 시 점검 사항, Network 환경 및 보안, 고객 지원 방법, FAQ, 준수 정보 & 제한 보증에 대해 기술
설치 매뉴얼 작성 순서

img*

소프트웨어 사용자 매뉴얼 작성


소프트웨어 사용자 매뉴얼의 개요
  • 사용자가 소프트웨어를 사용하는 과정에서 필요한 내용을 기록한 문서
서문
  • 문서 이력, 사용자 매뉴얼의 주석, 기록 보관 내용 기술
  • 기록 보관 내용 : 소프트웨어를 사용하면서 필요한 기술 지원이나 추가 정보를 얻기 위한 소프트웨어 등록 정보 기술
기본 사항
  • 소프트웨어 개요, 사용 환경, 관리, 모델 버전별 특징, 기능 및 인터페이스의 특징, 구동 환경 설명
사용자 매뉴얼 작성
  • 사용자가 사용방법을 이해하기 쉽도록 작성
  • 사용자 화면 및 UI, 주요 기능 분류, 응용 프로그램 및 설정, 장치 연동, Network 환경, Profile 안내, 고객 지원 방법, 준수 정보 및 제한 보증에 대해 기술
사용자 매뉴얼 작성 순서

img*

소프트웨어 버전 등록


소프트웨어 패키징 형상 관리
  • 형상관리는 소프트웨어의 변경 사항을 관리하기 위한 활동
형상 관리의 중요성
  • 지속적으로 변경사항을 체계적으로 관리 및 추적할 수 있음
  • 발견된 버그나 수정 사항을 추적
  • 무절제한 변경 방지
형상 관리 기능
  • 형상 식별 : 대상에 이름과 관리 번호를 부여하고 계층 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업
  • 버전 제어 : 소프트웨어 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고 특정 절차와 도구를 결합하는 작업
  • 형상 통제 : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선이 잘 반영될 수 있도록 하는 작업
  • 형상 감사 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
  • 형상 기록 : 형상의 식별, 통제, 감사 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업
소프트웨어 버전 등록 관련 주요 용어
  • 저장소(Repository) : 형상에 대한 정보들이 저장되어 있는 곳
  • 가져오기 : 아무것도 없는 저장소에 처음으로 파일 복사
  • 체크아웃 : 저장소에서 소스 파일, 버전 관리를 위한 파일을 받아옴
  • 체크인 : 체크아웃으로 받아온 파일을 수정 후 저장소에 새로운 버전으로 갱신
  • 커밋 : 체크인 수행 시 이전에 갱신된 내용이 있는 경우 충돌을 알리고 diff 도구를 이용해 수정한 후 갱신
  • 동기화 : 저장소에 있는 최신 버전을 동기화

소프트웨어 버전 관리 도구


공유 폴더 방식
  • 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리
클라이언트/서버 방식
  • 버전 관리 자료가 서버에 저장되어 관리
  • 서버의 자료를 자신의 PC로 복사하여 작업 후 변경 내용을 서버에 반영
  • 모든 버전 관리는 서버에서 수행
분산 저장소 방식
  • 버전 관리 자료가 하나의 원격 저장소와 분산된 PC의 로컬 저장소에 함께 저장되어 관리
  • 원격 저장소의 자료를 자신의 로컬 저장소로 복사하여 작업 후 변경 내용을 로컬 저장소에서 버전 관리 후 이를 원격 저장소에 반영
Subversion(SVN)
  • 아파치 소프트웨어 재단에서 2000년에 발표
  • 클라이언트/서버 방식
  • 모든 작업은 trunk 디렉토리에서 추가 작업은 branches 디렉토리 안에 별도의 디렉토리를 만들어 작업 후 trunk 디렉토리와 병합
  • 커밋 시 커밋의 버전인 리버전이 1씩 증가
  • 서버는 주로 유닉스에서 사용
명령어
  • add : 새로운 파일이나 디렉토리를 관리 대상으로 지정
  • commit: add한 소스파일을 서버의 소스파일에 적용
  • update : 서버의 최신 commit 이력을 클라이언트 소스에 적용
  • checkout : 서버에서 버전 관리 정보와 소스 파일을 받아옴
  • merge : 다른 디렉토리에서 작업된 버전 관리 내역을 기본 개발 작업과 병행
  • import: 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장
  • export: 버전 관리 정보 빼고 소스 파일만 서버에서 받아옴
  • info: 지정된 파일에 대한 정보를 표시
  • diff: 지정된 파일이나 경로에 대해 이전 리버전과의 차이를 표시
Git
  • 리누스 토발즈가 2005년에 개발
  • 분산 저장소 방식
  • 버전 관리가 지역 저장소에서 진행되어 버전 관리가 신속하게 처리되고, 원격 저장소나 네트워크에 문제가 있어도 작업 가능
  • 브랜치를 이용하여 기본 버전 관리 틀에 영향을 주지않으면서 다양항 형태의 테스팅 가능
  • 파일의 변화를 스냅샷으로 저장하고 이전 스냅샷의 포인터를 가져 버전의 흐름 파악 가능
명령어
  • add : 작업 내역을 스테이징 영역에 추가하여 버전 관리 대상으로 지정
  • commit : 작업 내역을 지역 저장소에 저장
  • branch: 새로운 브런치 생성 / 삭제
  • checkout: 지정한 브런치로 이동
  • merge: 두 브랜치 병합
  • init : 지역 저장소 생성
  • remote add : 원격 저장소에 연결
  • push : 로컬 저장소의 변경 내용을 원격 저장소에 반영
  • fetch : 원격 저장소의 변경 이력만 지역 저장소에 반영
  • clone: 원격 저장소의 전체 내용을 지역 저장소로 복제
  • fork: 지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제

빌드 자동화 도구


빌드 자동화 도구의 개념

소스 코드를 컴파일한 후 여러 개의 모듈로 묶어 실행 파일로 만드는 과정을 포함하여 테스트 및 배포를 자동화하는 도구

Jenkins
  • Java 기반의 오픈소스
  • 서블릿 컨테이너에서 실행되는 서버 기반 도구
  • 형상 관리 도구와 연동 가능
  • Web GUI 제공으로 사용이 쉬움
  • 여러 대의 컴퓨터를 이용한 분산 빌드나 테스트 가능
Gradle
  • Groovy를 기반으로 한 오픈 소스 형태의 자동화 도구
  • 안드로이드 앱 개발 환경에 사용
  • Java, C/C++, Python 등의 언어도 빌드 가능
  • Groovy를 사용해서 만든 DSL을 스크립트 언어로 사용
  • 실행할 처리 명령들을 모아 태스크로 만든 후 태스크 단위로 실행
  • 이전의 태스크를 재사용하거나 다른 시스템의 태스크를 공유하여 빌드의 속도를 향상시킬 수 있음

4. 애플리케이션 테스트

애플리케이션 테스트의 개념
  • 애플리케이션에 잠재된 결함을 찾아내는 과정
  • 확인(Validation) : 개발된 소프트웨어가 요구사항을 만족시키는지 사용자의 입장에서 확인
  • 검증(Verification) : 기능을 제대로 수행하고 명세서에 맞게 만들었는지 개발자의 입장에서 점검
  • 테스트 전 개발한 소프트웨어의 유형을 분류하고 특성을 정리해서 중점적으로 테스트할 사항을 정리
애플리케이션 테스트의 필요성
  • 미리 오류를 발견하고 새로운 오류의 유입 예방
  • 사용자의 요구사항에 만족하는지 테스트해 제품의 신뢰도 향상
애플리케이션 테스트의 기본 원리
  • 잠재적인 결함을 줄일 수 있지만 소프트웨어 자체 결함이 없다곤 할 수 없음
  • 결함은 특정 모듈에 집중되어 있어 애플리케이션의 20%에 해당하는 코드에서 80%의 결함이 발견된다고 하여 파레토 법칙을 적용하기도 함
  • 살충제 패러독스 현상을 방지하기 위해 테스트 케이스를 지속적으로 보완 및 개선
  • 테스트를 정황에 따라 다르게 진행
  • 결함을 모두 제거해도 사용자의 요구사항을 만족할 수 없으면 안 됨
  • 작은 부분에서 시작해서 점점 확대하며 진행

애플리케이션 테스트의 분류


프로그램 실행 여부
  • 정적 테스트

    • 프로그램을 실행하지 않고 소스코드나 명세서를 분석하여 테스트
    • 개발 초기에 결함을 발견할 수 있어 비용이 절감
    • 워크 스루, 인스펙션, 코드 검사 등
  • 동적 테스트

    • 프로그램을 실행하여 테스트
  • 개발의 모든 단계에서 진행

    • 블랙박스 테스트, 화이트 박스 테스트
테스트 기반
  • 명세 기반 테스트

    • 사용자의 요구사항을 테스트 케이스로 만들어 구현하고 있는지 확인하여 테스트
    • 동등 분할, 경계 값 분석
  • 구조 기반 테스트

    • 소프트웨어 내부 논리 흐름에 따라 테스트 케이스를 만들어 테스트
    • 구문 기반, 결정 기반, 조건 기반, 결정 기반 등
  • 경험 기반 테스트

    • 테스터의 경험을 기반으로 테스트
    • 요구사항에 대한 명세가 부족하거나 시간의 제약이 있는 경우
    • 에러 추정, 체크 리스트, 탐색적 테스팅
시각
  • 확인 테스트

    • 사용자의 시각에서 결과를 테스트
    • 요구사항을 만족하면서 정상적으로 동작이 되는지 테스트
  • 검증 테스트

    • 개발자의 시각에서 과정을 테스트
  • 명세서에 맞게 완성되었는지 테스트
목적에 따른 테스트
  • 회복 테스트 : 결함을 주고 잘 복구되는지 테스트
  • 안전 테스트 : 시스템 보호 도구가 볼법적인 침입으로부터 보호할 수 있는지 테스트
  • 강도 테스트 : 과부하 시 정상적으로 실행되는지 테스트
  • 성능 테스트 : 응답 시간, 처리량 등을 테스트
  • 구조 테스트 : 내부의 논리적인 경로, 소스 코드 복잡도 등을 평가
  • 회귀 테스트 : 변경 혹은 수정에 따른 새로운 결함이 없는지를 테스트
  • 병행 테스트 : 기존의 소프트웨어와 변경된 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트

동적 테스트


화이트박스 테스트
  • 모듈의 원시 코드를 오픈하여 논리적인 모든 경로를 한번 이상 실행하면서 테스트하여 테스트 케이스를 설계
  • 테스트 과정의 초기에 진행
  • 설계된 절차에 초점을 둔 구조적 테스트
  • 모듈 안의 동작을 직접 관찰
화이트박스 테스트의 종류
  • 기초 경로 검사

    • 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
    • 테스트 측정 결과를 통해 실행 경로의 기초를 정의
  • 제어 구조 검사

    • 조건 검사 : 프로그램 내의 논리적 조건을 테스트
    • 루프 검사 : 프로그램 내의 반복 구조에 초점을 맞춰 테스트
    • 데이터 흐름 검사 : 프로그램 내의 변수의 정의와 사용의 위치에 초점을 맞춰 테스트
화이트박스 테스트 검증 기준
  • 문장 검증 기준 : 모든 구문이 한 번 이상 수행되도록 설계
  • 분기 검증 기준 : 모든 조건문이 한 번 이상 수행되도록 설계
  • 조건 검증 기준 : 모든 조건문에 대해 참/거짓인 경우가 한번 이상 수행되도록 설계
  • 분기/조건 기준 : 모든 조건문과 조건문에 포함된 개별 조건식의 결과가 참/거짓인 경우가 한번 이상 수행되도록 설계
블랙박스 테스트
  • 소프트웨어가 수행할 특정 기능을 알기 위해 기능이 완전히 작동되는 것을 입증하는 기능 테스트
  • 테스트 과정의 후반부에 진행
  • 사용자의 요구사항 명세를 보면서 구현된 기능을 테스트
  • 소프트웨어 인터페이스에서 실시
블랙박스 테스트의 종류
  • 동치(동등) 분할 검사 : 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사
  • 경계값 분석 : 입력 조건의 경계값을 테스트 케이스로 선정하여 검사
  • 원인-효과 그래프 검사 : 입력 데이터 간의 관계과 출력의 영향을 미치는 상황을 분석 후 효용성이 높은 테스트 케이스를 선정하여 검사
  • 오류 예측 검사 : 과거 경험이나 확인자의 감각으로 테스트
  • 비교 검사 : 여러 프로그램에 동일한 테스트 자료를 제공하여 동일한 출력이 나오는지 확인하는 검사

개발 단계에 따른 애플리케이션 테스트


단위 테스트
  • 코딩 직후 모듈이나 컴포넌트에 초점을 맞춰 테스트
  • 인터페이스, 외부적 I/O, 자료 구조 등을 검사
  • 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행
  • 구조 기반 테스트 : 화이트 박스 테스트를 시행하여 제어 흐름이나 조건 결정을 목적으로 함
  • 명세 기반 테스트 : 블랙 박스 테스트를 시행하여 동등 분할이나 경계값 분석을 목적으로 함
통합 테스트
  • 단위 테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성하는 과정에서 테스트
  • 모듈 간 또는 통합된 컴포넌트 간 상호 작용 오류 검사
  • 비점진적 통합 방식

    • 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트
    • 빅뱅 통합 테스트 방식
    • 오류 발견 및 장애 위치 파악이 어려움
  • 점진적 통합 방식

    • 모듈 단위로 단계적으로 통합하면서 테스트
    • 하향식 / 상향식 / 혼합식 테스트 방식
    • 오류 수정이 용이하고 인터페이스 관련 오류를 완전히 테스트할 수 있음
  • 하향식 통합 테스트

    • 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트
    • 깊이 우선 통합법이나 넓이 우선 통합법 사용
    • 상위 모듈에선 테스트 케이스 사용이 어려움
    • 스텁 : 상위 모듈은 있지만 하위 모듈이 없는 경우 하위 모듈 대체

img*

  • 상향식 통합 테스트

    • 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
    • 하나의 주요 제어 모듈과 종속 모듈의 그룹인 클러스터가 필요
    • 드라이버 : 상위 모듈 없이 하위 모듈이 있는 경우 하위 모듈 구동

img*

  • 혼합식 통합 테스트

    • 하위 수준에서는 상향식 통합 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원
    • 샌드위치 통합 테스트
  • 회귀 테스팅

    • 이미 테스트된 프로그램의 테스팅을 반복
    • 통합 테스트로 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인
시스템 테스트
  • 개발된 소프트웨어가 원하는 환경에서 수행되는지 테스트
  • 실제 환경과 유사하게 만든 테스트 환경에서 진행
  • 기능적 요구사항 : 명세서 기반의 블랙박스 테스트
  • 비기능적 요구사항 : 구조적 요소에 대한 화이트박스 테스트
인수 테스트
  • 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트
  • 사용자가 직접 테스트
  • 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부 확인
  • 운영상의 인수 테스트 : 시스템 관리자가 시스템 인수 시 수행
  • 계약 인수 테스트 : 계약상의 조건을 준수하는지 확인
  • 규정 인수 테스트 : 규정에 맞게 개발되었는지 확인
  • 알파 테스트 : 개발된 환경에서 사용자가 개발자 앞에서 수행
  • 베타 테스트 : 사용자의 환경에서 사용자가 직접 테스트 수행

애플리케이션 테스트 프로세스


애플리케이션 테스트 프로세스
  • 개발된 소프트웨어가 제대로 만들어 졌는지 테스트하는 절차
  • 테스트를 마치면 테스트 계획서, 케이스, 시나리오, 결과서가 산출
  • 에러는 빨리 발견될수록 좋음

img*

  • 테스트 계획 : 프로젝트 계획서 및 요구 명세서를 기반으로 테스트 목표를 정의하고 테스트 대상 및 범위 결정
  • 테스트 분석 및 디자인 : 테스트의 목적과 원칙을 검토하고 사용자의 요구사항 분석
  • 테스트 케이스 및 시나리오 작성 : 테스트 케이스를 작성, 검토 및 확인 후 시나리오 작성
  • 테스트 수행 : 테스트 환경 구축 후 테스트 수행
  • 테스트 결과 평가 및 리포팅 : 테스트 결과를 분석하여 테스트 결과 작성
  • 결함 추적 및 관리 : 테스트 수행 후 결함이 어디에서 발생했고 어떤 결함인지 추적하고 관리

테스트 케이스 / 시나리오 / 오라클


테스트 케이스
  • 사용자의 요구사항이 준수되었는지 확인하기 위해 테스트 항목에 대한 명세서
  • 명세 기반 테스트의 설계 산출물
  • 테스트 케이스 작성 순서

img*

테스트 시나리오
  • 테스트 케이스를 적용하는 구체적인 절차를 명세한 문서
테스트 오라클
  • 테스트 결과가 올바른지 판단하기 위해 정의된 참 값을 대입하여 비교
  • 테스트 오라클의 특징

    • 제한된 검증 : 모든 테스트 케이스에는 적용 불가
    • 수학적 기법 : 수학적 기법을 통해 테스트 오라클 값을 구할 수 있음
    • 자동화 기능 : 테스트 대상에 대한 실행, 결과 비교 등을 자동화할 수 있음
  • 테스트 오라클의 종류

    • 참 오라클 : 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공
    • 샘플링 오라클 : 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공
    • 추정 오라클 : 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고 나머지 값에 대해서는 추정으로 처리
    • 일관성 검사 오라클 : 변경 시 테스트 케이스 수행 전과 후의 결과 값이 동일한지 확인

테스트 자동화 도구

반복적인 테스트 절차를 스크립트 형태로 구현하는 자동화 도구를 적용하여 쉽고 효율적으로 테스트 수행

테스트 자동화 도구의 장단점
  • 장점

    • 반복적인 작업을 자동화해 인력 및 시간 절감
    • 향상된 테스트 품질 보장
    • 사용자의 요구사항 등을 일관성 있게 검증
    • 테스트 결과에 대한 객관적인 평가 기준 제공
    • 테스트 결과를 다양한 표시 형태로 제공
    • UI가 없는 서비스도 정밀 테스트 가능
  • 단점

    • 사용방법에 대한 교육 및 학습 필요
    • 자동화 도구를 프로세스 단계별로 적용하기 위한 시간, 비용, 노력이 필요
테스트 자동화 수행 시 고려사항
  • 모든 과정이 아닌 그때그때 맞는 적절한 도구를 선택
  • 자동화 도구를 고려하여 프로젝트 일정 계획
  • 프로젝트 초기에 테스트 엔지니어 투입 시기 계획
테스트 자동화 도구의 유형
  • 정적 분석 도구 : 프로그램을 실행하지 않고 소스코드를 통해 결함을 발견
  • 테스트 실행 도구 : 스크립트 언어를 사용하여 테스트를 실행
  • 성능 테스트 도구 : 가상의 사용자를 만들어 테스트를 수행
  • 테스트 통제 도구 : 테스트 계획 및 관리, 수행, 결함 관리 등을 수행
  • 테스트 하네스 도구

    • 테스트가 실행될 환경을 시뮬레이션하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 함
    • 구성요소 : 테스트 드라이버, 테스트 스텁, 테스트 슈트, 테스트 케이스, 테스트 스크립트, 목 오브젝트
테스트 수행 단계별 테스트 자동화 도구
  • 테스트 계획 단계 : 요구사항 관리 도구
  • 테스트 분석 및 설계 단계 : 테스트 케이스 생성 도구
  • 테스트 수행 단계 : 테스트 자동화 / 정적 분석 / 동적 분석 / 성능 테스트 / 모니터링 도구
  • 테스트 관리 단계 : 커버리지 분석 / 형상 관리 / 결함 추적 및 관리 도구

결함 관리


소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것

결함 관리 프로세스
  • 애플리케이션 테스트에서 발견된 결함을 처리

img*

결함 상태 추적
  • 테스트에서 발견된 결함은 지속적으로 상태 변화를 추적하고 관리해야 함
  • 결함 분포 : 특정 속성에 해당하는 결함 수 측정
  • 결함 추세 : 시간에 따른 결함 수의 추이 분석
  • 결함 에이징 : 결함 상태로 지속되는 시간 측정
결함 추적 순서
  • 결함이 발견되고 해결될 때까지의 과정

img*

결함 분류
  • 시스템 결함 : 주로 애플리케이션이나 데이터베이스 처리에서 발생된 결함
  • 기능 결함 : 애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함
  • GUI 결함 : 화면 설계에서 발생된 결함
  • 문서 결함 : 기획자, 사용자, 개발자 간 의사소통 및 기록이 원활하지 않아 발생된 결함
결함 심각도
  • 결함이 전체 시스템에 미치는 치명도를 High, Medium, Low로 나눔
결함 우선순위
  • 발견된 결함 처리에 대한 신속성을 나타내는 척도
  • 결함의 중요도와 심각도에 따라 설정되고 수정 여부 결정
  • Critical, High, Medium, Low 또는 즉시 해결, 주의 요망, 대기, 개선 권고 등으로 분류
결함 관리 도구
  • Mantis : 소프트웨어 설계 시 단위 별 작업 내용을 기록할 수 있어 결함 및 이슈 관리, 추적 도구
  • Trac : 결함 추적 및 통합 관리 도구
  • Redmine : 프로젝트 관리 및 결함 추적 도구
  • Bugzilla : 결함을 지속적으로 관리하고 심각도와 우선순위를 지정할 수 있는 도구

애플리케이션 성능 분석


애플리케이션 성능
  • 사용자가 요구한 기능을 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도
  • 측정 지표 : 처리량, 응답 시간, 경과 시간, 자원 사용률
성능 테스트 도구
  • 애플리케이션의 성능을 테스트 하기 위해 부하나 스트레스를 가해 성능 측정 지표를 점검하는 도구
  • JMeter : 다양한 프로토콜을 지원하는 부하 테스트 도구
  • LoadUI : 사용자의 편리성이 강화된 부하 테스트 도구
  • OpenSTA : HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구
시스템 모니터링 도구
  • 애플리케이션 실행 중 시스템 자원의 사용량을 확인하고 분석하는 도구
  • 성능 저하의 원인 / 시스템 부하량 / 사용자 분석과 같은 시스템을 안정적으로 운영할 수 있는 기능 제공
  • Scouter, Zabbix
애플리케이션 성능 저하 원인 분석
  • 애플리케이션을 DB에 연결하기 위해 커넥션 객체를 생성하거나 쿼리를 실행하는 애플리케이션 로직에서 자주 발생

애플리케이션 성능 개선


소스코드 최적화
  • 나쁜 코드를 배제하고 클린 코드로 작성
  • 클린 코드 작성 원칙 : 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화
소스 코드 최적화 유형
  • 클래스 분할 배치, 느슨한 결합, 코딩 형식 준수, 좋은 이름 사용, 적절한 주석문 사용
소스 코드 품질 분석 도구
  • 정적 분석 도구

    • 작성한 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함을 확인하는 도구
    • pmd, cppcheck, SonarQube, checkstyle, ccm, cobertuna 등
  • 동적 분석 도구

    • 작성한 코드 소스를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
    • Avalanche, Valgrind

5. 인터페이스 구현

모듈 간 공통 기능 및 데이터 인터페이스 확인


모듈 간 공통 기능 및 데이터 인터페이스의 개요
  • 공통 기능 : 모듈에 공통적으로 제공되는 기능
  • 데이터 인터페이스 : 모듈 간 교환되는 데이터가 저장될 파라미터
  • 인터페이스 설계서에서 정의한 모듈의 기능을 기반으로 확인
인터페이스 설계서
  • 교환 데이터 및 관련 업무, 송수신 시스템 등에 대한 내용을 정리한 문서
  • 일반적인 인터페이스 설계서

    • 인터페이스 목록, 상세 데이터 명세, 기능의 세부 정보를 정의한 문서
    • 시스템 인터페이스 설계서 : 시스템 인터페이스 목록과 상세 데이터 명세를 정의
    • 상세 기능별 인터페이스 명세서 : 기능의 세부 인터페이스 정보 정의
  • 정적/도형 모형을 통한 인터페이스 설계서

    • 시스템의 구성요소를 다이어그램으로 표현하여 만든 문서
인터페이스 설계서 별 모듈 기능 확인

img*

모듈 연계를 위한 인터페이스 기능 식별


모듈 연계의 개요
  • 모듈 간 데이터 교환을 위해 관계를 설정
  • EAI(Enterprise Application Intergration) : 기업 내 정보 전달, 연계, 통합 등 상호 연동이 가능하게 해주는 솔루션

    • Point-to-Point : 애플리케이션끼리 1:1로 연결. 변경 및 재사용이 어려움
    • Hub & Spoke : 단일 접점인 허브 시스템을 통해 데이터를 전송하는 중앙 집중형 방식. 확장 및 유지보수 용이, 허브 장애 시 전체 시스템에 영향
    • Message Bus(ESB 방식) : 애플리케이션 사이 미들웨어를 두어 처리. 확장성이 뛰어나고 대용량 처리 가능
    • Hybrid : Hub & Spoke와 Message Bus의 혼합 방식. 그룹 내에선 Hub & Spoke 방식을 그룹 간에는 Message Bus 방식 이용. 데이터 병목 현상 최소화
  • ESB(Enterprise Service Bus)

    • 애플리케이션 간 표준 기반 인터페이스를 제공하는 솔루션
    • 애플리케이션보다는 서비스 중신의 통합을 지향
    • 애플리케이션과의 결합도를 약하게 유지
    • 관리 및 보안 유지가 쉽고 높은 수준의 품질 지원
모듈 간 연계 기능 식별
  • 모듈 간 공통 기능 및 데이터 인터페이스를 기반으로 모듈과 연계된 기능을 시나리오 형태로 구체화하여 식별
  • 인터페이스 기능을 식별하는 데 사용
모듈 간 인터페이스 기능 식별
  • 식별된 모듈 간 기능을 검토하여 인터페이스 동작에 필요한 기능을 식별
  • 해당 업무에 대한 시나리오를 통해 내부 모듈과 관련된 인터페이스 기능 식별
  • 외부 및 인터페이스 모듈 간 동작하는 기능을 통해 인터페이스 기능 식별

모듈 간 인터페이스 데이터 표준 확인


모듈 간 인터페이스에 사용되는 데이터의 형식을 표준화

데이터 인터페이스 확인
  • 데이터 표준을 위해 식별된 데이터 인터페이스에서 입출력 값의 의미와 데이터의 특성 등을 구체적으로 확인
인터페이스 기능 확인
  • 데이터 표준을 위해 식별된 인터페이스 기능을 기반으로 인터페이스 기능 구현을 위해 필요한 데이터 항목 확인
인터페이스 데이터 표준 확인
  • 데이터 인터페이스에서 확인된 데이터 표준과 인터페이스 기능을 통해 확인된 데이터 항목을 검토하여 최종적으로 데이터 표준 확인

인터페이스 기능 구현 정의


인터페이스 기능 구현 정의에 대한 개요
  • 인터페이스를 실제로 구현하기 위해 인터페이스 기능에 대한 구현 방법을 기능별로 기술
  • 인터페이스 기능 구현 정의 순서

img*

모듈 세부 설계서
  • 모듈의 구성 요소와 세부적인 동작 등을 정의한 설계서
  • 컴포넌트 명세서 : 컴포넌트의 개요 및 내부 클래스의 동작, 인터페이스를 통해 외부와 통신하는 명세 등을 정의
  • 인터페이스 명세서 : 컴포넌트 명세서의 항목 중 인터페이스 클래스의 세부 조건 및 기능 등을 정의
모듈 세부 설계서 확인
  • 모듈의 컴포넌트 명세서와 인터페이스 명세서를 기반으로 인터페이스에 필요한 기능 확인
인터페이스 기능 구현 정의
  • 인터페이스의 기능, 데이터 표준, 모듈 세부 설계서를 기반으로 정의

인터페이스 구현


송수신 시스템 간의 데이터 교환 및 처리를 실현해주는 작업

정의된 인터페이스 기능 구현을 기반으로 인터페이스 구현 방법을 분석하고 분석한 인터페이스 구현 정의를 기반으로 구현

데이터 통신을 이용한 인터페이스 구현
  • 애플리케이션 영역에서 인터페이스 형식에 맞춘 데이터 포맷을 인터페이스 대상으로 전송하고 이른 수신 측에서 파싱 하여 해석하는 방식
  • JSON, XML 형식 사용
인터페이스 엔티티를 이용한 인터페이스 구현
  • 인터페이스가 필요한 시스템 사이에 별도의 인터0페이스 엔티티를 두어 상호 연계하는 방식
  • 인터페이스 테이블 활용

인터페이스 예외 처리


인터페이스 예외 처리의 개요
  • 구현된 인터페이스가 동작하는 과정에서 기능상 예외 상황이 발생했을 때 처리하는 절차
데이터 통신을 이용한 인터페이스 예외 처리
  • 인터페이스 객체를 이용해 구현한 인터페이스 동작이 실패할 경우를 대비
  • 송수신 시 발생할 수 있는 예외 케이스를 정의하고 예외 처리 방법을 기술
  • 시스템 환경, 송수신 데이터, 프로그램 자체 원인
인터페이스 엔티티를 이용한 인터페이스 예외 처리
  • 엔티티에 인터페이스의 실패 상황과 원인을 기록
  • 조치를 취할 수 있도록 사용자와 관리자에게 알려주는 방식으로 예외 처리

인터페이스 보안


인터페이스 보안 취약점 분석
  • 인터페이스 기능이 수행되는 각 구간들의 구현 현황을 확인 후 어떤 취약점이 있는지 확인
  • 송수신 영역의 구현 기술 및 특징을 구체적으로 확인
  • 확인된 인터페이스 기능을 기반으로 영역별로 발생할 수 있는 취약점을 시나리오 형태로 작성
인터페이스 보안 기능 적용
  • 분석한 인터페이스 기능과 취약점을 기반으로 보안 기능 적용
  • 네트워크 영역 : 송수신간 스니핑 등을 이용한 데이터 탈취 및 변조 위험을 방지하기 위해 네트워크 트래픽에 대한 암호화 설정
  • 애플리케이션 영역 : 소프트웨어 개발 보안 가이드를 참조하여 코드 상의 취약점을 보완
  • 데이터베이스 영역 : 접근 권한과 데이터베이스 동작 객체의 취약점에 보안 기능 적용

연계 테스트


구축된 연계 시스템과 구성 요소가 정상적으로 동작하는지 확인

연계 테스트 케이스 작성
  • 연계 시스템 간의 데이터 및 프로세스 흐름을 분석하여 필요한 테스트 항목을 도출
  • 송수신 연계 응용 프로그램의 단위 테스트 케이스와 연계 테스트 케이스를 각각 작성
연계 테스트 환경 구축
  • 테스트의 환경을 송수신 기관과의 협의를 통해 결정하고 구축
연계 테스트 수행
  • 연계 응용 프로그램을 실행하여 연계 테스트 케이스의 시험 항목 및 처리 절차 등을 실제로 진행
연계 테스트 수행 결과 검증
  • 연계 테스트 케이스의 시험 항목 및 처리 절차를 수행한 결과가 예상 결과와 동일한지 확인
  • 연계 서버에서 적용하는 모니터링 현황 확인
  • 시스템에서 기록하는 로그 확인
  • 테이블 또는 파일을 열어 데이터를 확인

인터페이스 구현 검증


인터페이스 구현 검증 도구
  • xUnit : Java, C++, .Net 등 다양한 언어를 지원
  • STAF : 서비스 호출 및 컴포넌트 재사용 등 다양한 환경을 지원
  • FitNesse : 웹 기반 테스트케이스 설계, 진행, 결과 확인 등을 지원
  • NTAF : FitNess의 협업 기능과 STAF의 재사용 및 확장성을 통합한 NHN의 프레임워크
  • Selenium : 다양한 브라우저 및 개발 언어 지원
  • watir : Ruby를 사용
인터페이스 구현 감시 도구
  • APM을 사용하여 감시 가능
  • 애플리케이션 성능 관리 도구를 통해 데이터베이스와 웹 애플리케이션의 다양한 정보를 조회하고 분석할 수 있음
  • 스카우터(Scouter), 제니퍼(Jennifer) 등
인터페이스 구현 검증 도구 및 감시 도구 선택
  • 인터페이스 명세서의 세부 기능을 참조하여 검증 도구와 감시 도구의 요건을 분석
  • 분석 후 시장 및 솔루션 조사를 통해 적절한 도구 선택
인터페이스 구현 검증 확인
  • 외부 시스템과 연계 모듈 동작 상태 확인
  • 예상되는 결과값과 실제 검증 값이 동일한지 비교
인터페이스 구현 감시 확인
  • 외부 시스템과 연결 모듈이 서비스를 제공하는 동안 정상적으로 동작하는지 확인

인터페이스 오류 확인 및 처리 보고서 작성


인터페이스 오류 발생 시 오류사항을 확인하고 오류 처리 보고서를 작성하여 관리 조직에 보고

인터페이스 오류 발생 즉시 확인
  • 화면에 오류 메시지를 표시하고 자동으로 SMS나 이메일을 발생하는 것으로 즉시 오류 발생 확인
주기적인 인터페이스 오류 발생 확인
  • 시스템 로그나 인터페이스 오류 관련 테이블 등을 통해 주기적으로 오류 발생 여부 확인
인터페이스 오류 처리 보고서 작성
  • 인터페이스 작동 시 발생하는 오류의 발생 및 종료 시점, 원인 및 증상, 처리사항 등을 정리한 문서
  • 보고 시기를 최초 발생 시, 오류 처리 경과 시, 완료 시로 나누어 작성