Post

정보처리기사 필기 | 2. 소프트웨어 개발

📗 자격증 정보처리기사 필기의 "Chapter 2. 소프트웨어 개발" 내용을 정리했습니다.

정보처리기사 필기 | 2. 소프트웨어 개발

KEYWORDS
정보처리기사, 소프트웨어 개발, 데이터 입출력 구현, 통합 구현, 제품 소프트웨어 패키징, 애플리케이션 테스트 관리, 인터페이스 구현


     

Introduction

  • 1) 데이터 입출력 구현에서는 데이터 입출력, 논리적 데이터 모델링, 물리적 저장소 설계, ORM 프레임워크, 트랜잭션 인터페이스, 프로시저 최적화 등을 다룹니다.
  • 2) 통합 구현은 시스템 소프트웨어의 모듈 구현과 테스트에 대한 내용으로, 추상화와 모듈화 원리, 알고리즘 구현, 테스트 종류, 도구, 통합 구현 관리, 형상 관리 도구를 설명합니다.
  • 3) 제품 소프트웨어 패키징에서는 애플리케이션 패키징, 모듈화와 버전 관리, 패키징 작업에서의 사용자 중심 고려 등을 다루고, 이를 위한 도구 및 프로세스에 대한 내용을 다룹니다.
  • 4) 애플리케이션 테스트 관리에서는 테스트 케이스 설계, 결과 분석, 결함 관리 등을 포함하여 소프트웨어 품질을 확인에 대한 방법과, 이를 위한 테스트 유형 및 자동화 도구를 소개합니다.
  • 5) 인터페이스 구현에서는 명세서, 기능 구현, 보안 등의 내용들을 다루며, 실제 운영 상황에서의 오류 처리 및 감시를 고려한 효율적이고 안정적인 소프트웨어 연계 방법을 다룹니다.

     

1) 데이터 입출력 구현

논리 데이터 저장소 확인

자료 구조 Data Structure

  • 컴퓨터 과학에서 효율적인 접근 및 수정을 가능케 하는 자료의 조직, 관리, 저장
  • 데이터 값의 모임, 데이터 간의 관계, 데이터에 적용 가능한 함수나 명령
  • 분류
    • 구현 방법에 따른 분류
      • 배열 ㅣ 메모리 상에 같은 타입의 자료가 연속적으로 저장
      • 튜플 ㅣ 둘 이상의 자료형을 묶음
      • 연결 리스트 ㅣ 노드가 단위, 자료와 다음 노드를 가리키는 참조값으로 구성
      • 원형 연결 리스트 ㅣ 각 노드는 다음 노드를 가리키고, 마지막 노드가 처음 노드를 가리킴
      • 이중 연결 리스트 ㅣ 각 노드는 이전 노드와 다음 노드를 가리키는 참조값으로 구성, 양 끝 노드의 이전 노드와 마지막 노드는 없음
      • 환형 이중 연결 리스트 ㅣ 처음 노드가 이전 노드로 마지막 노드를 가리키고, 마지막 노드가 다음 노드로 처음 노드를 가리키는 이중 연결 리스트
      • 해시 테이블 ㅣ 개체가 해시값에 따라 인덱싱
    • 형태에 따른 분류
      • 선형 구조
        • 스택 ㅣ 먼저 저장된 것이 제일 나중에 나오며, 가장 최근에 저장된 것이 제일 먼저 나옴
        • ㅣ 스택과 반대로 먼저 저장된 것이 제일 먼저 나옴
        • ㅣ 양쪽에서 넣기와 빼기를 할 수 있는 선형 구조
      • 비선형 구조
        • 그래프 ㅣ 꼭짓점과 꼭짓점을 잇는 변으로 구성 (유/무향 그래프)
        • 트리 ㅣ 뿌리와 뿌리 또는 다른 꼭짓점을 단 하나의 부모로 갖는 꼭짓점들로 이루어진 구조 (이진트리, 힙)

     

논리 데이터 저장소

  • 논리 데이터 모델링
    • 데이터 모델링 프로세스의 Input으로 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법
    • 결과로 얻어지는 논리데이터 모델은 데이터 모델링이 최종적으로 완료된 상태임
    • 물리적인 스키마 설계를 하기 전 단계의 데이터 모델 상태
  • 논리 데이터 모델 품질 검토
    • 개념 데이터 모델링, 논리 데이터 모델링, 물리 데이터 모델링의 각 단계가 수행된 후 각 단계에서 작성된 모델에 대해 이루어짐
    • 정확성 ㅣ 사용된 표기법에 따라 데이터 모델이 정확하게 표현되었는지 여부
    • 완전성 ㅣ 모델 표현의 충실성 (완성도), 필요 항목 (엔티티/속성 설명) 들의 작성 상태
    • 준거성 ㅣ 데이터 표준, 표준화 규칙, 법적 요건 준수
    • 최신성 ㅣ 변경 및 결정사항이 시의 적절하게 반영, 현행 데이터 모델은 현행 시스템과 일치하는지 여부
    • 일관성 ㅣ 다양한 주제 영역에서 공통적으로 사용되는 엔티티의 일관성, 모델 표현상의 일관성
    • 활용성 ㅣ 작성된 설명 내용이나 모델 표기 등이 사용자에게 충분히 이해가 되어야 함, 데이터 모델의 유연성 여부
  • 논리 데이터 모델링의 특성
    • 논리적 데이터 모델링 시 요구사항 정보가 충분치 않은 경우, 다음 단계의 요구사항 반경에 따른 비용이 증가
    • 모든 이해 당사자들과 의사소통의 보조자료로서 E-R 모델을 활용
    • 논리적 모델은 하드웨어와 소프트웨어에 독립적
  • 데이터 모델링 목적
    • 연관 조직의 정보 요구에 대한 정확한 이해 가능
    • 사용자, 설계자, 개발자 간의 효율적인 의사소통 수단 제공
    • 데이터 체계 구축을 통한 고품질 소프트웨어와 유지보수 비용 감소 효과
    • 신규 혹은 개선 시스템의 개발 기초 제공

     

  • 데이터 모델링 프로세스
  1. 개념 데이터 모델링
    • 개체와 개체들간의 관계에서 E-R 다이어그램을 만드는 과정
    • 추상화 수준이 높고 업무 중심적, 포괄적 수준의 모델링 진행
    • 전사적 데이터 모델링, EA 수립 시 많이 사용
  2. 논리 데이터 모델링
    • E-R 다이어그램을 사용하여 관계 스키마 모델을 만드는 과정
    • 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확히 표현
    • 높은 재사용성
  3. 물리 데이터 모델링
    • 관계 스키마 모델의 물리적 구조를 정의하고 구현하는 과정
    • 실제 DB에 이식 가능하도록 성능, 저장 등 물리적인 성격을 고려하여 설계

     

  • 정규화(Normalization)
    • 논리적으로 데이터 모델을 일관성이 있고 중복을 제거하여 보다 안정성 있는 구조를 만들기 위함
    • 불필요한 데이터(Redundancy)를 없앨 수 있고, 삽입/갱신/삭제 시 발생가능한 이상현상 방지 가능
      • 불필요 데이터 제거, 논리적으로 데이터 저장, 높은 단계로 갈수록 중복이 적은 릴레이션으로 설계
    • 종류
      • 제 1 정규형(1NF) ㅣ 각 로우에 컬럼의 값은 1개씩만 존재, 테이블에는 컬럼/행 순서가 존재하나 릴레이션에는 순서를 고려하지 않음
      • 제 2 정규형(2NF) ㅣ 후보키의 진부분집함에서 키가 아닌 속성에 대해, 부분 함수 종속성을 제거, 종속성이 있는 속성만 추출하여 새 릴레이션 제작
      • 제 3 정규형(3NF) ㅣ 추이 함수 종속성(Transitive Dependency) 제거

     

물리 데이터 저장소 설계

  • 물리 데이터 저장소
    • 논리 데이터 모델을 DBMS의 특성 및 성능을 고려하여 구체화시킨 모델
    • DBMS 선정 이후에 해당 DBMS 상에서 최상의 성능을 보장하도록 논리 데이터 모델에서 저장하는 데이터의 물리적 특성을 최대한 반영
  • 물리 데이터 저장소 모델 변환
    • 테이블 변환
      • 테이블(Table) ㅣ 컬림과 로우를 가지며, 각각의 컬럼은 지정된 유형의 데이터를 저장
      • 로우(Row) ㅣ 테이블의 한 로우에 대응 (튜플, 어커런스, 인스턴스)
      • 컬럼(Column) ㅣ 개개인의 관리 항목에 대한 Value를 저장
      • 기본 키(Primary Key) ㅣ 하나의 컬럼 혹은 몇개의 컬럼 조합으로 어떤 경우라도 테이블 내에 동일한 값을 갖는 튜플이 존재하지 않도록 주의
      • 외래키(Foreign Key) ㅣ 외부 데이터 집합과의 관계를 구현한 구조
    • 컬럼 변환 ㅣ 테이블 각 속성들에 대한 컬럼명을 사례 데이터 표의 컬럼명 란에 기록
      • 컬럼의 명칭은 혼동을 피하기 위해 표준화된 약어를 사용, SQL 해독 시간을 감소
      • SSQL의 예약어의 사용을 피함
      • 필수 입력 속성은 Nulls/Unique 란에 NN을 표시
    • Primary UID 기본키 변환 ㅣ 논리 데이터 모델에서의 Primary UID는 물리 데이터 모델에서 기본키로 생성됨
      • 사례 데이터 표의 키 형태 란에 Primary UID에 속하는 모든 속성에 PK 표시
      • PK로 표시된 모든 컬럼은 Nulls/Unique란에 반드시 NN, U로 표시
      • 또 다른 Unique Key가 있다면 U2로 표시
    • 관계 변환 ㅣ 논리 모델에서 정의된 관계는 외래 키로 변환
      • 1:M 관계 변환, 1:1 관계 변환, 1:M 순환 관계 변환, 배타적 관계 변환
    • 반 정규화 수행
      • 데이터 물리 모델링 과정 중 시스템의 성능 향상, 개발 과정의 편의성, 운영 단순화를 위한 반 정규화 과정을 수행
      • 종류
        • 테이블 반정규화 ㅣ 테이블 병함, 분할, 추가
        • 컬럼 반정규화 ㅣ 중복 컬럼 추가, 파생 컬럼 추가, PK에 의한 컬럼 추가, 응용시스템 오작동을 위한 컬럼 추가
        • 관계 반정규화 ㅣ 중복 관계 추가

     

  • 물리 데이터 저장소 구성

    • 테이블 제약 조건

      • 참조된 기본키의 값이 삭제될 경우 처리 내용을 정의하는 Delete Constraint와 수정될 경우의 처리 내용을 정의하는 Update Constraint

      • Delete Condition
        • Casacade ㅣ 참조된 테이블의 외부 키와 일치하는 모든 로우 삭제
        • Restricted ㅣ 참조된 테이블의 외부키에 없는 것만 삭제 가능
        • Nullify ㅣ 참조된 테이블에 정의된 외부키와 일치하는 것을 Null로 수정
      • Update Condition
        • Casacade ㅣ 참조된 테이블의 외부키와 일치하는 모든 로우 수정
        • Restricted ㅣ 참조된 테이블의 외부키에 없는 것만 수정 가능
        • Nullfy ㅣ 참조된 테이블에 정의된 외부키와 일치하는 것을 Null로 수정
    • INDEX 설계

      • INDEX 적용 기준 ㅣ 인덱스 컬럼 분포도 10~15% 이내, 분포 범위 이상이더라도 부분처리가 목적인 경우, 조회/출력 조건으로 사용되는 컬림인 경우, 인덱스 자동생성 기본키와 Unique키의 제약 조건을 사용할 경우
      • 인덱스 컬럼 선정 ㅣ 분포도가 좋은 컬럼은 단독 생성 활용도 향상, 결합 인덱스 생성을 통해 자주 조합되어 사용되는 컬럼 활용, 사용빈도, 유일성 등 결합 인덱스에 구성되는 순서 선정에 유의, 가능한 수정이 자주 되지 않도록 유의하여 선정
      • 설계 시 유의사항 ㅣ 신규 추가 인덱스가 기존 인덱스 경로에 영향을 주지 않도록 유의, 오버헤드 작용은 지나치게 많은 인덱스로 인해 발생, 추가적인 저장공간이 필요함을 항상 염두, 많은 범위의 인덱스 처리 시 오히려 전체 처리보다 많은 오버헤드 발생, 인덱스와 데이터 저장공간 분리 설계
    • 뷰 설계

      • Select문의 조건은 가능한 최적의 경로를 사용할 수 있도록 하거나, SQL의 Where 절에서 반드시 양호한 액세스 경로가 되도록 해야함
        • REPLACE ㅣ 뷰가 이미 존재하는 경우 재생성
        • FORCE ㅣ 기본 테이블의 존재 여부에 관계없이 뷰 생성
        • NOFORCE ㅣ 기본 테이블이 존재할 때만 뷰 생성
        • WITH CHECK OPTION ㅣ 서브 쿼리 내의 조건을 만족하는 행만 변경
        • WITH READ ONLY ㅣ 데이터 조작어 작업 불가
    • 클러스터 설계

      • 분포도가 넓을 수록 유리, 액세스 기법이 아니라 액세스 효율 향상을 위한 물리적 저장 방법
      • 분포도가 넓은 테이블의 클러스터링은 저장 공간 절약, 대량 범위를 자주 액세스 하는 경우 적용
      • 인덱스 사용 처리 부담이 되는 넓은 분포에 사용, 반복 컬럼 정규화에 의해 분할된 경우 활용
      • 다중 테이블이 빈번하게 조인을 일으킬 경우 활용, 검색 효율은 높여주나 입력/수정/삭제 시 부하가 증가
      • Union, Distinct, Order by, Group by가 빈번한 컬럼이면 검토 대상
      • 수정이 자주 발생하지 않는 컬럼은 고려 대상
      • 처리 범위가 넓어 문제가 발생하는 경우 단일 테이블 클러스터링을 고려
    • 파티션 설계

      • 파티션 종류 ㅣ Range (지정한 열의 값 기준 분할), Hash (해시 함수에 따라 데이터 분할), Composite (범위 분할에 의해 분할, 다음 해시 함수 적용 후 재분할)
      • 장점 ㅣ 데이터 액세스 범위를 줄여 성능 향상, 전체 데이터 훼손 가능성 감소, 데이터 가용성 향상, 분할 영역 독립적 백업, Disk striping을 통한 I/O 성능 향상
        • 파티션 종류 결정 🠊 파티션 키 선정, 파티션 수 결정
    • 디스크 구성 설계

      • 정확한 용량 산정은 디스크 사용 효율을 향상, 업무량 집중 디스크 분리 설계 🠊 부하 분산, 입출력 경합을 최소화하여 데이터 접근성 향상
      • 시스템 구성에 따라 테이블 공간의 수와 크기를 결정, 파티션할 테이블은 별도 분류

     

ORM 프레임워크

  • ORM(Object Relational Mapping) 프레임 워크 개념
    • 객체와 관계형 DB의 데이터를 자동으로 매핑
    • 객체 지향 프로그래밍은 클래스를 사용, 관계형 데이터베이스는 테이블을 사용
    • 객체 모델과 관계형 모델 간의 불일치 존재 🠊 ORM을 통해 객체 관계를 바탕으로 SQL을 자동으로 생성하여 해결
    • 데이터 베이스 데이터 <- 매핑 -> Object 필드
    • 객체를 통해 간접적으로 DB 데이터를 다룸, Persistant API
  • 장점
    • 객체 지향적인 코드로 더 직관적이며, 비즈니스 로직에 집중 가능
    • 재사용 및 유지보수 편리, DBMS에 대한 종속성 감소
  • 단점
    • 완벽한 ORM 으로만 서비스 구현 어려움
    • 프로시저가 많은 시스템에서 ORM의 객체 지향적인 장점을 활용하기 힘듬
  • 객체 관계 임피던스 불일치
    • 세분성(Granularity)
      • 경우에 따라 DB에 있는 테이블 수 보다 더 많은 클래스를 가진 객체 모델을 가질 수 있음
      • 코드 재사용과 유지보수를 위해 Person과 Address라는 두개의 클래스로 나눌 수 있음
      • DB에는 Person이라는 하나의 테이블에 사용자 세부 사항을 저장 가능
    • 상속성(Inheritance)
      • RDBMS는 객체 지향 프로그래밍 언어의 자연적 패러다임인 상속과 유사한 것을 정의하지 않음
    • 일치성(Identify)
      • RDBMS는 sameness라는 하나의 개념을 정확히 정의 🠊 기본 키
      • 자바에서는 객체 식별과 객체 동일성을 모두 정의
      • RDBMS에서는 PK가 같으면 서로 동일한 Record로 정의하지만, 자바에는 주소값이 같거나 내용이 같은 경우를 구분 정의
    • 연관성
      • 객체 지향 언어는 객체 참조를 사용하는 연관성을 나타내는 반면, RDBMS는 연관성을 외래키로 나타냄

     

트랜잭션 인터페이스

  • 여러 쿼리를 처리하는 상황에서 문제가 생기는 경우를 해결
  • 트랜잭션 ㅣ 2개 이상의 쿼리를 하나의 커넥션으로 묶어 DB에 전송하고, 이 과정의 에러를 자동으로 해결함
    • 하나 이상의 쿼리를 처리할 때 동일한 커넥션 객체를 공유하도록 함
  • 특징
    • 원자성 ㅣ 트랜잭션 연산을 DB 모두에 반영 또는 반영하지 말아야 함
    • 일관성 ㅣ 트랜잭션이 실행을 성공적으로 완료할 시 일관성 있는 데이터 상태 유지
    • 독립성 ㅣ 둘 이상 트랜잭션 동시 실행 시 한개의 트랜잭션만 접근 가능
    • 연속성 ㅣ 완료된 트랜잭션 경과는 영구 반영

     

데이터 조작 프로시저 작성

프로시저

  • SQL 분류
    • 데이터 정의어(DDL, Data Definition Language) ㅣ 테이블 등의 구조를 생성하고 변경하기 위해 사용되는 명령어, 명령 수행이 되면 이전 상태로 복귀 불가
      • CREATE, DRO, RENAME, ALTER, TRUNCATE
    • 데이터 조작어(DML, Data Manipulation Language) ㅣ DB에 있는 데이터를 변경하거나 검색하기 위해 사용되는 명령어, 트랜잭션 제어어를 활용하여 실행전 상태로 복귀 가능
      • INSERT, UPDATE, DELETE
    • 데이터 제어어(DCL, Data Control Language) ㅣ 사용자 별 DB에 접근 가능한 권한 부여 및 회수 명령어
      • ROLD, GRANT, REVOKE
  • 트랜잭션 제어어(TCL, Transaction Control Language) ㅣ 트랜잭션의 DML 작업단위를 제어하는 명령어
    • COMMIT, ROLLBACK, SAVEPOINT

     

  • 절차형 데이터 조작 프로시저 및 저장형 객체 활용
    • 절차형 데이터 조작 프로시저
      • PL/SQL 개요 ㅣ 컴파일 필요없이 스크립트 생성 및 변경 후 바로 실행 가능
        • 블록 내 논리적으로 관련된 문장들을 그룹화, 적절히 분리된 모듈의 집합
        • 변수, 상수 등을 선언하여 해당 식별자를 SQL과 절차적 프로그램에서 사용, 에러 처리 가능, 성능 향상 기대
      • PL/SQL 구조
        • 선언부(DECLARE, Optional) ㅣ 실행부에서 참조할 모든 변수, 상수, 커서, 예외를 선언
        • 실행부(BEGIN/END, Mandatory) ㅣ BEGIN과 END 사이에 기술되는 영역
        • 예외처리부(Exception, Optional) ㅣ 실행부에서 에러가 발생했을 떄 수행될 문장을 기술
    • PL/SQL 처리 절차
      • PL/SQL로 작성된 Block을 Oracle 서버로 보내면 PL/SQL 엔진이 두 언어를 구분
      • Non SQL 문은 PL/SQL Engine 내의 Procedural Statement Executor가, SQL 문은 SQL Statement Executor가 처리
      • Non SQL 문은 Client 환경에서, SQL 문은 서버에서 실행

     

프로그램 디버깅

  • 프로시저가 입력 자료를 받아 출력을 올바르게 도출하는지에 관한 확인 과정
  • DB 프로지서에 대한 검증 작업
  • SQL Plus 도구를 이용하여 디버깅, SQL을 DBMS 서버에 전송하여 처리가능 하도록 하는 Oracle에서 제공
  • 주요 명령어: 파일 명령어, 편집 명령어, 실행 명령어, 환경 명령어, 형식 명령어, 대화 명령어

     

단위 테스트 도구

  • 구현된 프로시저의 적합성을 확인하기 위한 방법 제공
  • DBMS_OUTPUT 패키지를 활용하여 메시지를 버퍼에 저장하고 버퍼로부터 메시지를 읽어오기 위한 패키지를 코드에 포함시킴

     

데이터 조작 프로시저 최적화

쿼리 성능 측정

  • 데이터의 입출력 애플리케이션 성능 향상을 위해 SQL 코드를 최적화
  • 성능 측정 도구인 APM을 사용하여 최적화할 쿼리를 선정
  • 최적화 할 쿼리에 대해 옵티마이저가 수립한 실행 계획을 검토 후 SQL 코드와 인덱스 재고성
    • APM(Application Performance Management)
      • Resource monitoring ㅣ 모니터링 대상 지원은 CPU, 메모리, 네트워크, 디스크
        • ex. Nagios, Zabbix, Cacti
      • End to End monitoring ㅣ 모니터링 대상을 애플리케이션 수행 관점으로 보아 비즈니스 트랜잭션 강화
    • 옵티마이저(Optimizer) ㅣ DBMS에 내장되어 작성된 SQL이 효율적으로 수행되도록 최적의 경로를 찾아 주는 모듈

     

소스코드 인스펙션

  • DB 성능 향상을 위해 프로시저 코드를 보면서 성능 문제점을 개선
  • SQL 코드 인스펙션 대상
    • 미사용 변수 ㅣ 프로시저에서 선언은 되었으나 본문에서 사용되지 않는 변수
    • 미사용 서브 쿼리 ㅣ 컬럼이 선언은 되었으나 외부 쿼리에서 참조가 되지 않음
    • Null 값 비교 ㅣ Null 값과 비교하는 프로시저 소스가 있는 경우
    • 과거의 데이터 타입 사용 ㅣ 데이터 타입이 바뀌었지만 과거의 타입을 그대로 쓰는 소스가 있는 경우
  • SQL 코드 인스펙션 절차 ㅣ 계획 🠊 개관 🠊 준비 🠊 검사 🠊 재작업 🠊 추적

     

2) 통합 구현

모듈 구현

단위 모듈 Unit Module

  • 시스템 SW 구현의 기본이 되는 한가지 동작을 수행하는 작은 기능을 수행하기 위하여 만들어진 소프트웨어 집합
  • 구현 원리
    • 추상화
      • 과정 추상화 ㅣ 수행 과정의 자세한 단계를 비고려, 상위 수준의 수행 흐름만 먼저 설계
      • 데이터 추상화 ㅣ 데이터 구조를 대표할 수 있는 표현으로 대체
      • 제어 추상화 ㅣ 이벤트에 대한 각 반응을 모두 대표할 수 있는 표현으로 대체
    • 정보 은닉 ㅣ 각 모듈 내부 내용을 비밀로 하며 인터페이스를 통해서만 메세지 전달
    • 단계적 분해 ㅣ 문제를 상위 개념부터 구체적인 단계로 분할
    • 모듈화
      • 모듈의 응집력 ㅣ 모듈이 이루고 있는 요소들의 관련 정도
      • 모듈의 결합도 ㅣ 모듈 간의 상호 의존 정도
  • 구현 단계
  1. 단위 기능 명세서 작성: 기본 및 상세 설계를 통해 산출된 기능 및 코드 명세서 구현
  2. 입/출력 기능 구현
  3. 알고리즘 구현 단계
  • 알고리즘 필수 조건
    • 입력 ㅣ 외부에서 제공되는 데이터가 0개 이상
    • 출력 ㅣ 적어도 한 가지 결과 생성
    • 명확성 ㅣ 각 명령들은 명확하고 모호하지 않아야 함
    • 유한성 ㅣ 알고리즘 명령대로 수행 시 어떤 경우라도 유한개의 단계 뒤에는 반드시 종료
    • 유효성 ㅣ 원칙적으로 모든 명령들은 종이와 연필로만 수행 가능

     

단위 모듈 테스트

  • 테스트 환경 구축
    • 속도 ㅣ 자동화를 통해 최대 1000배까지 빠르게 실행
    • 효율성 ㅣ 테스트 실행 시간 절감
    • 정확성 및 정밀도 ㅣ 동일한 테스트를 여러번 수행해도 매번 완전한 결과 보장
    • 리소스 절감 ㅣ 시뮬레이션 등을 이용한 테스트 수행에 필요한 물리적 자원 감소
    • 시뮬레이션 및 에뮬레이션 ㅣ 가상 장치나 응용 프로그램을 활용하여 정상적인 인터페이스인 H/W 또는 S/W 대체
    • 지속성 ㅣ 꾸준한 작업을 수행할 수 있는 능력 요구
  • 단위 모듈 테스트 종류
    • 화이트박스 테스트 ㅣ 주로 시행, 프로그램의 수행 경로 구조, 루프 등 내부 로직을 보면서 테스트 수행
    • 블랙박스 테스트 ㅣ 외부 사용자 요구사항 명세를 보면서 테스트 수행
  • 테스트 도구
    • 뷰어 및 모니터 ㅣ 정상적으로 볼 수 없는 소프트웨어의 동작을 자세히 볼 수 있음
    • 드라이버 ㅣ 테스트할 SW를 제어하고 동작시키는데 사용
    • 스텁(Stubs) ㅣ 테스트 하는 SW를 제어하거나 조작하지 않는 개념, SW가 보내는 데이터를 받거나 응답하는 기능
    • 스트레스 ㅣ 다른 컴퓨터 상의 SW를 실행하는데 개별적으로 메모리 크기와 디스크 공간, 파일, 사용가능한 다른 자원 설정

     

  • 테스트 케이스
    • 소프트웨어가 사용자의 요구사항을 준수했는지 검증하기 위한 테스트 조건, 입력값, 예상 출력값 및 수행결과 명세
    • 항목 및 내용
      • 식별자(Identifier) ㅣ 항목 식별자, 일련번호
      • 테스트 항목(Test Item) ㅣ 테스트할 모듈 또는 기능
      • 입력 명세(Input Specification) ㅣ 입력 값 또는 테스트 조건
      • 출력 명세(Output Specification) ㅣ 기대 되는 출력 값 결과
      • 환경 설정 ㅣ 테스트 수행 시 필요한 HW, SW 환경
      • 특수 절차 도구(Special Procedure Requirements) ㅣ 수행 시 특별히 요구되는 절차
      • 의존성 기술(Inter-case Dependencies) ㅣ 테스트 케이스 간의 의존성

     

  • 테스트 프로세스
  1. 계획/제어 단계 ㅣ 테스트 목적 달성을 위한 계획/제어
  2. 분석/설계 단계 ㅣ 테스트 목적을 구체화 하여 테스트 시나리오와 테스트 케이스로 변환
  3. 구현/실행 단계 ㅣ 효율적인 테스트 수행을 위해 테스트 케이스들을 조합하고 필요한 정보를 포함하는 테스트 프로시저를 명세
  4. 평가 단계 ㅣ 테스트 목적에 맞게 수행되었는지 평가 및 기록
  5. 완료 단계 ㅣ 명세했던 조건 수집, 테스트 수행 시 특이사항, 경헙 등을 축적

     

통합 구현 관리

IDE Integrated Development Environment 도구

  • 개발을 하면서 사용되는 여러 도구를 하나의 인터페이스로 집합하여 한 프로그램 안에서 처리 가능한 환경 제공
    • 비주얼 스튜디오 ㅣ 크로스 플랫폼, Win32/Win64, Microsoft, C/C++/C#/F# 등
    • 이클립스 ㅣ 크로스 플랫폼, Windows, Linux, IBM, Java/C/C++/웹/안드로이드
    • 엑스 코드 ㅣ 애플 플랫폼, MacOS, iOS, Apple, swift3/4/cocoa
    • IDEA ㅣ 크로스 플랫폼, Windows, Linux, MacOS, jetbrain, Java/JSP/XML/PHP

     

협업 도구와 형상 관리 도구

  • 협업 도구
    • 개발자 간 서로 다른 작업 환경에서의 원활 작업 수행을 위한 커뮤니케이션 도구
    • 문서 공유, 소스 공유, 일정 관리, 업무 흐름 관리, 커뮤니케이션, 정보 공유, 디자인 공유
  • 형상 관리 도구(Configuration Management)
    • SW 개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 결과물에 대한 형상 제작
    • 형상에 대한 변경을 체계적으로 관리, 제어
    • Git, SVN, CVS, SourceSafe, Perforce
    • 장점
      • 소스 코드 공유, 변경 이력 관리, 배포 시 유용, 버전 충돌 문제 해결, 장애 시 SW 원상복구 가능, 여러 버전 분기 개발에 유용

     

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

제품 소프트웨어 패키징

애플리케이션 패키징

  • 개념
    • 개발이 완료된 애플리케이션을 고객에게 전달하기 위한 형태로 패키징
    • 설치와 사용에 필요한 전반적인 절차 및 환경 등의 내용을 포함하는 매뉴얼 작성
    • 애플리케이션에 대한 패치 개발과 업그레이드를 위한 버전관리 수행 능력
    • 개발자가 아닌 사용자 중심, 신규 및 변경 소스 식별/모듈화
    • 고객 편의성을 위한 신규/변경 이력 확인, 버전관리 및 Release Note를 통한 지속적 관리
  • 모듈 생성 이해
    • 모듈화 ㅣ 소프트 웨어 설계 시 기능 단위 분해, 추상화로 인한 재사용 및 공유 가능한 수준으로 만들어진 단위를 모듈로 규정
      • 소프트웨어의 성능 향상 및 시스템 디버깅, 테스트, 통합 및 수정을 용이하도록 하는 설계 기법
    • 장점 ㅣ 프로그램의 효율적인 관리 및 성능 향상, 이해 용이성, 복잡성 감소, 테스트/수정시 용이, 오류 파급 효과 최소화, 기능 분리 가능
    • 목표 ㅣ 모듈 간 결합도 최소화, 모듈 내 요소들간의 응집도 최대화
  • 모듈 및 패키징
    • 모듈의 개념을 정확히 이입하고 이에 맞는 기능 단위로 패키징
    • 패키징 배포 시 제품 소프트웨어의 성능을 향상 가능, 테스트/수정에서도 모듈 단위로 모든 것을 분류하여 작업

     

  • 애플리케이션 모듈 빌드 기법
    • 소프트웨어 빌드 ㅣ 소스 코드 파일을 컴퓨터에서 실행할 수 잇는 애플리케이션 단위로 변환
    • 애플리케이션을 위한 빌드 기법: Ant, Make, Maven, Gradle
  • 사용자 중심의 패키징 작업 이해
    • 사용자 실행 환경 이해 ㅣ OS부터 실행 환경, 시스템 사양 및 고객의 사용 방법까지 상세히 분류하여 실행환경을 사전 정의
    • 사용자 관점에서의 패키징 고려 사항: OS, CPU, 메모리 등의 수행 최소 환경을 정의, 사용자가 직관적으로 확인가능한 UI 제공, 매뉴얼과 일치시켜 패키징, 하드웨어와 함께 통합 적용되도록 매니저 서비스 형태로 제공
  • 버전을 고려한 제품 릴리즈 노트 작성
    • 패키징에서의 제품 릴리즈 노트 파악
      • 릴리즈 노트 ㅣ 조직의 최종 사용자인 고객과 잘 정리된 릴리즈 정보를 공유하는 문서
      • 시험 결과와 정보가 포함, 사용자에게 확실한 정보 제공, 전체적인 제품의 수행 기능 및 서비스 변화 공유, 자동화 개념과 함께 적용
    • 릴리즈 노트 작성 시 고려 사항
      • Header, 개요, 목적, 이슈 요약, 재현 항목, 수정/개선 내용, 사용자 영향도, SW 지원 영향도, 노트, 면책 조항, 연락 정보
    • 릴리즈 노트 작성 프로세스
      • 기능 식별 🠊 모듈화 🠊 빌드 진행 🠊 사용자 환경 분석 🠊 패키징 적용 테스트 🠊 패키징 변경 개선

     

애플리케이션 배포 도구

  • 배포를 위한 패키징 시에 디지털 컨텐츠의 지적 재산권을 보호하고 관리하는 기능 제공
  • 고려사항
    • 반드시 암호화/보안 고려, 다양 기종 연동 고려, 사용자 편의성을 위한 복잡성 및 비효율성 문제 고려, 애플리케이션 종류에 적합한 암호화 알고리즘 적용
  • 암호화/보안 기능 중심의 패키징 도구 기술 및 활용
    • 암호화 (전자서명), 키 관리, 암호화 파일 생성, 식별 기술, 저작권 표현 (라이센스 내용 표현), 정책 관리, 크랙 방지, 인증 (사용자 인증 기술)

     

애플리케이션 모니터링 도구

  • 애플리케이션을 사용자 환경에 설치 이후 기능 및 성능, 운영 현황을 모니터링하여 제품을 최적화
  • 기능
    • 변경 관리 ㅣ 애플리케이션 간 종속관계 모니터링
      • ex. ChangeMiner
    • 성능 관리 ㅣ 서버로 유입되는 트랜잭션 수량, 처리 시간, 응답 시간 등을 모니터링
      • ex. Jeniffer, Nmon
    • 정적 분석 ㅣ 소스 코드의 잠재적 문제 발견, 코딩 규칙 오류 발견
      • ex. PMD, Cppcheck
    • 동적 분석 ㅣ 프로그램에 대한 결함 및 취약점 동적 분석, 메모리 및 오류 문제 발견
      • ex. Avalanche, Valgrind
  • 효과
    • 서비스 가용성, 서비스 성능, 장애 인지/리소스 측정, 근본 원인 분석

     

DRM Digital Rights Management

  • 디지털 권리 관리는 출판사 또는 저작권자가 그들이 배포한 디지털 자료나 하드웨어의 사용을 제어하고 이를 의도한 용도로만 사용하도록 제안
  • 인증된 사용자가 인증된 기간 동안만 사용하도록 통제, 기업 기밀을 담은 내부 문서를 외부로 유출되지 않도록 관리
  • 구성 요소
    • 컨텐츠 제공자, 컨텐츠 분배자 (암호화)
    • 패키저 ㅣ 컨텐츠 메타 데이터와 함께 배포 가능한 단위로 묶는 기능
    • 보안 컨테이너 ㅣ 원본 안전 유통을 위한 전자적 보안 장치
    • DRM 컨트롤러 ㅣ 배포된 컨텐츠의 이용 권한 통제
    • 클리어링 하우스 ㅣ 키 관리 및 라이센스 발급 관리
  • 기술 요소
    • 접속 제어 ㅣ 권한이 없는 사용자에 대한 컨텐츠 접근 제어
    • 사용 제어 ㅣ 권한이 없는 사용자에 대한 컨텐츠 사용 제어
    • 내용 제어 ㅣ 워터마킹을 통한 컨텐츠 자체 은닉된 소유권 및 불법복제, 제어 정보 삽입

     

애플리케이션 매뉴얼 작성

애플리케이션 매뉴얼 작성

  • 매뉴얼 파악
    • 매뉴얼은 개발 단계부터 적용한 기준이나 패키징 이후 설치 및 사용자 중심의 기능 방법 설명서
  • 설치 매뉴얼 작성 기본 사항
    • 개발자의 기준이 아닌 사용자의 기준으로 작성
    • 최초 설치 실행부터 완료까지 순차적으로 진행
    • 각 단계별 메시지 및 해당 화면을 순서대로 전부 캡쳐하여 설명
    • 설치 중간에 이상 발생 시 해당 메시지 및 에러에 대한 내용을 분류하여 설명
  • 애플리케이션 설치 매뉴얼 작성 항목
    • 기본 작성 항목
      • 목차 및 개요 ㅣ 매뉴얼 전체 내용을 순서대로 요약, 설치 매뉴얼의 주요 특징, 구성과 설치 방법, 순서 기술
      • 문서 이력 정보 ㅣ 매뉴얼 변경 이력에 대한 정보를 버전 별 표시
      • 설치 매뉴얼 주석 ㅣ 사용자가 제품 설치 시 반드시 숙지해야하는 정보 주석 표시, 설치 관련 영향을 미치는 특별한 사용자 환경 및 상황 주석 표시
      • 설치 도구 구성 ㅣ exe, dll, ini, chm 등 해당 설치 관련 파일 설명, 폴더 및 설치 프로그램 실행 파일 설명
      • 설치 위치 지정 ㅣ 설치 폴더와 설치 프로그램 실행 파일 설명
    • 애플리케이션 설치 환경 체크 항목
      • 사용자 환경 ㅣ 사용자의 CPU 및 메모리, OS 등 적합 환경
      • 응용프로그램 ㅣ 설치 전 다른 응용 프로그램의 종료
      • 업그레이드 버전 ㅣ 업그레이드 이전 버전에 대한 존재 유무 확인
      • 백업 폴더 확인 ㅣ 데이터 저장 폴더를 확인하여 설치 시 폴더 동기화
    • 매뉴얼 기본 사항
      • 애플리케이션 개요 ㅣ 주요 기능 및 UI 설명, UI 및 화면 상의 버튼, 프레임 도식화 설명
      • 설치 관련 파일 ㅣ 애플리케이션 설치를 위한 파일 설명, 설치 구동을 위한 exe 설명, ini나 log파일 같은 관련 파일
      • 설치 아이콘 ㅣ Windows 구동용 설치 아이콘 설명
      • 프로그램 삭제 ㅣ 원래대로 삭제하는 방법 설명
      • 관련 추가 정보 ㅣ 애플리케이션 이외의 관련 설치 프로그램 정보 (빌드), 제작사 정보

     

제품 소프트웨어 버전 관리

소프트웨어 버전 관리 도구

  • 애플리케이션 버전 관리 도구
    • 버전 관리를 ALM Application Lifecycle Management 같이 전체 라이프 사이클을 관리하는 방향으로 진행
    • ITIL 기반의 ITSM 도입으로 SW와 HW에 대한 전체적인 서비스 관점으로 버전 관리를 진행
    • 버전관리는 EAMS, PPM 등의 전사 IT 거버전수의 한 부분으로 정의되어 비즈니스 영속성을 유지하기 위해 통합
  • 버전 관리 도구 특징 및 사용방법
    • 방식에 따른 버전 관리 도구 유형
      • 공유 폴더 방식 (RCS, SCCS) ㅣ 매일 개발 완료 파일은 약속된 위치의 공유 폴더에 복사, 파일을 PC로 복사 후 컴파일하여 정상 동작 확인
      • 클라이언트/서버 방식 (CVS, SVN) ㅣ 중앙에 버전 관리 시스템이 항시 동작, 작업 내용 축적 용이, 다수가 같은 파일 작업 시 경고 출력, GUI로 모니터링 가능
        • ex. Trac, CVS view
      • 분산 저장소 방식: 로컬 저장소와 원격 저장소 구조, Git
    • 구분에 따른 버전 관리 도구 유형
      • 저장소 구분 ㅣ 로컬 버전 관리 시스템 (rcs), 중앙 집중형 버전 관리 시스템 (CVS, SVN, Clear case), 분산형 버전 관리 시스템 (Git, Mercurial)
      • 소스 공개 유형 ㅣ 오픈 소스 툴 (CVS, SVN), 상용 버전 관리 툴 (PVCS, Clear case)
    • 버전 관리 도구의 유형별 분류
      • CVS(Concurrent Versions Systems) ㅣ 서버와 클라이언트로 구성되어 다수의 인원이 동시에 범용적인 운영체제로 접근 가능하여 버전관리를 가능케 함, 클라이언트가 이클립스에 내장됨
      • SVN(Subversion) ㅣ GNU의 버전 관리 시스템, 업계 표준
      • RCS(Revision Control System) ㅣ CVS와 달리 소스파일의 수정을 한 사람마느로 제한하여 다수의 사람이 파일의 수정을 못하도록 잠금하는 방식으로 버전관리
      • Bitkeeper ㅣ SVN과 비슷한 중앙 통제 방식의 버전 컨트롤 툴로서 대규모 프로젝트에서 빠른 속도를 냄
      • Git ㅣ 분산 버전 관리 시스템으로 2개의 저장소가 존재함
      • Clear Case ㅣ 복수 서버, 복수 클라이언트 구조이며 서버가 부족할 때 필요한 서버를 하나씩 추가하여 확장성
    • 버전 관리 도구 사용 유의점
      • 형상 관리 지침에 의거 버전에 대한 정보를 언제든지 접근 할 수 있도록 해야 함
      • 제품 소트트웨어 개발자, 배포자 이외의 사용자는 소스 수정 불가능
      • 동일한 프로젝트에 대해 여러 개발자가 동시에 개발 가능
      • 에러 발생시 최대한 빠른 시간 내에 복구

     

빌드 자동화 도구

  • 빌드 ㅣ 소스 코드 파일들을 생성하고 테스트를 검사하고 배포하기 위해 수행하는 과정
  • 도구 목록
    • Ant ㅣ Apache, 좋은 안정성, 문서화, 자바 프로젝트, task 개념을 사용하며 자바 소스파일 컴파일 jar, war, ear, zip 파일 생성, javadoc 생성 지원
    • Gradle ㅣ JVM 기반의 빌드 도구, 오픈소스 기반, Groovy 기반 DSL 작성
  • 기능
    • 코드 컴파일 ㅣ 테스트를 포함한 소스 코드 컴파일
    • 컴포넌트 패키징 ㅣ 자바의 jar 파일이나 윈도우의 exe 파일 같은 배포할 수 있는 컴포넌트를 묶는 작업
    • 파일 조작 ㅣ 파일과 디렉토리를 만들고 복사하고 지우는 작업
    • 개발 테스트 실행, 버전관리 도구 통합, API 문서 생성, 테스트 서버 배포 지원, 코드 품질 분석

     

4) 애플리케이션 테스트 관리

애플리케이션 테스트 케이스 설계

테스트 케이스

  • 사용자가 요구하는 기능의 동작과 성능, 안정성, 사용성 등을 만족하는지 확인하여 소프트웨어의 결함을 찾음
  • 필요성
    • 오류 발견 관점, 오류 예방 관점, 품질 향상 관점
  • 기본 원칙
    • 테스트는 결함이 존재함을 밝히는 활동, 완벽한 테스팅은 불가능, 테스팅은 개발 초기에 시작해야함
    • 결함 집중, 주기적 리뷰 및 개선, 테스팅은 정황에 의존, 오류 및 부재의 궤변

     

테스트 케이스 시나리오

  • 테스트 산출물
    • 계획서 ㅣ 테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행 절차, 테스트 일정, 조직의 역할 및 책임 정의, 종료 조건 정의
    • 테스트 케이스 ㅣ 특정 요구사항에 준수하는지를 확인하기 위한 개발 입력 값, 실행 조건, 예상된 결과
    • 시나리오 ㅣ 여러 테스트 케이스의 집합, 테스트 케이스 동작 순서를 기술한 문서, 테스트를 위한 절차를 명세한 문서
    • 결과서 ㅣ 결과를 정리한 문서, 테스트를 리뷰 및 결과를 평가/리포팅

     

테스트 지식 체계

  • 스프트웨어 테스트의 유형
    • 정적 테스트 ㅣ 프로그램 실행 없이 소스코드의 구조를 분석하여 논리적으로 검증 (Inspection, Code test, Work through)
    • 동적 테스트 ㅣ 프로그램의 실행을 요구하는 테스트 (White box test, Black box test)
  • 목적
    • Recovery Test ㅣ 실패를 유도하고 시스템이 정상 복귀하는지 테스트
    • Security Test ㅣ 불법 소프트웨어의 접근성을 보호하기 위해 보안 결함을 미리 점검
    • Stress Test ㅣ 과부하에 대한 내구도 테스트
    • Performance Test ㅣ 응답시간, 특정 시간 내 처리 업무량, 반응 속도 테스트
    • Structure Test ㅣ 시스템 내부 논리 경로, 소스코드의 복잡도를 평가하는 테스트
    • Regression Test ㅣ 변경 또는 수정된 코드에 대한 새로운 결함 발견 여부 평가 테스트
    • Parallel Test ㅣ 동일한 데이터 입력 후 결과를 비교

     

애플리케이션 통합 테스트

결함 관리 도구

  • 각 단계 별 테스트 수행 후 발생한 결함의 재발 방지를 위해, 유사 결함 발견 시 처리 시간 단축을 위해 결함을 추적/관리
  • 관리 활동
    • 테스트 단계 ㅣ 단위 (수행 기준 X), 통합 (설계 문서 결함 발견, 평가 완료), 시스템 (명세서 결함 발견, 시스템 테스트 평가 완료), 운영 (명세서 결함 발견, 평가 완료)
    • 입력물 ㅣ 테스트 활동 로그, 결함 관리 대장
    • 종료 조건 ㅣ 심각도 상위 수준의 결함 해결 여부 확인
    • 산출물 ㅣ 결함관리 대장, 테스트 활동 로그, 테스트 결과 보고서
  • 결함 관리 프로세스
    • 에러 발견 ㅣ 요구 사항 분석, 설계 테스트 실행 중 에러가 발생 될 경우 논의
    • 에러 등록 ㅣ 결함 관리 대장에 발견된 에러 등록
    • 에러 분석 ㅣ 단순 에러인지 실제 결함인지 분석
    • 결함 확정 ㅣ 등록된 에러가 실제 결함으로 확정될 경우, 결함 확정 상태로 설정
    • 결함 할당 ㅣ 결함을 해결할 담당자를 지정하여 결함을 할당하고 결함 할당 상태로 설정
    • 결함 조치 ㅣ 결함에 대해 수정 활동을 수행하고, 수정이 완료된 경우 결함 조치 상태로 설정
    • 결함 조치 검토 및 승인 ㅣ 수정이 완료된 결함에 대해 확인 테스트를 수행하고, 정상적으로 조치 완료 후 결함 조치 완료 상태로 설정
  • 결함 추이 분석
    • 결함 분포 ㅣ 각 애플리케이션 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함의 수를 측정하여 결함의 분포를 분석
    • 결함 추세 ㅣ 테스트 진행 시간의 흐름에 따른 결함의 수를 측정하여 결함 추세를 분석
    • 결함 에이징 ㅣ 등록된 결함에 대해 특정한 결함 상태의 지속 시간을 측정하여 분석

     

  • 테스트 커버리지
    • 기능 기반 커버리지 ㅣ 테스트 대상 애플리케이션 전체 기능을 모수로 설정, 실제 테스트가 수행된 기능의 수를 측정, 100% 달성 목표, 일반적으로 UI가 많은 시스템의 경우 화면 수를 모수로 사용할 수도 있음
    • 라인 커버리지 ㅣ 애플리케이션 전체 소스코드의 Line 수를 모수로 테스트 시나리오가 수행한 소스코드의 Line 수 측정
    • 코드 커버리지 ㅣ 소프트웨어 테스트 충분성 지표 중 하나로 소스 코드의 구문, 조건, 결정 등의 구조 코드 자체가 얼마나 테스트 되었는지 측정
  • 결함의 식별
    • 단계별 결함 유입 분류
      • 기획시 유입 ㅣ 사용자 요구사항의 표준 미준수로 인해 테스트 불가능, 요구사항 불명확/불완전/불일치, 기타 결함
      • 설계시 유입 ㅣ 기획 단계에 유입된 결함 또는 설계 표준 미준수로 인함, 요구사항 불명확/불완전/불일치, 기타 결함
      • 코딩 시 유입 ㅣ 설계 단계에 유입된 결함 또는 코딩 표준 미준수로 인해 기능의 불일치/불완전, 데이터 결함, 인터페이스 결함, 기타 결함
      • 테스트 부족으로 유입 ㅣ 테스트 완료 기준 미준수, 테스트 팀 및 개발 팀의 의사소통 부족, 개발자의 코딩 실수
    • 결함 심각도별 분류
      • 치명적 결함, 주요 결함, 보통 결함, 정미한 결함, 단순 결함
    • 결함 우선 순위
      • 발생한 결함이 얼마나 빠르게 처리되어야 하는지를 결정, 결함 심각도가 높아도 우선순위가 반드시 높은것은 아님
      • 표현 사례 ㅣ 결정적, 높음, 보통, 낮음
  • 결함 관리 항목
    • 결함 관리 시스템에 등록하여 관리
    • 필수 등록 항목 ㅣ 결함 내용, 결함 ID, 결함 유형, 발견일, 심각도, 운선순위, 시정 조치 예정일, 수정 담당자, 재테스트 결과, 종료일

     

테스트 자동화 도구

  • 장점
    • 재입력 작업의 자동화, 사용자 요구 기능의 일관성 검증 유리, 테스트 결과에 대한 객관적 평가 기준 제공
    • 테스트 결과의 통계 작업 및 그래프 형태 제공, UI가 없는 서비스의 경우에도 정밀 테스트 가능
  • 단점
    • 도구 도입 후 도구 사용 방법에 대한 교육 필요, 도구를 프로세스 단계별로 적용하기 위한 시간/비용 필요, 유지 관리 비용
  • 유형
    • 정적 분석 도구
      • 애플리케이션을 실행하지 않고 분석, 소스코드에 대한 코딩 표준, 스타일, 복잡도 및 결함 발견을 위함
      • 수행하는 사람의 소스 코드에 대한 이해를 바탕
    • 테스트 실행 도구
      • 데이터 주도 접근 방식 ㅣ 테스트 데이터를 스프레드시트에 저장하고, 읽고 실행 가능하도록 함, 반복 실행 가능, 쉬운 실행
      • 키워드 주도 접근 방식 ㅣ 테스트를 수행할 동작을 나타내는 키워드 테스트 데이터를 스프레드시트에 저장, 키워드에 대한 테일러링
    • 테스트 장치
      • 애플리케이션 컴포넌트 및 모듈을 테스트하는 환경의 일부분, 테스트를 지원하기 위한 코드와 데이터
      • 테스트 드라이버 ㅣ 테스트 대상 하위 모듈을 호출하고, 파라미터를 전달, 모듈 테스트 수행 후의 결과를 도출하는 등의 상향식 테스트에 필요
      • 테스트 스텁 ㅣ 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 하향식 테스트에 필요
      • 테스트 케이스 ㅣ 입력 값, 실행 조건, 기대 결과
      • 테스트 스크립트 ㅣ 자동화된 테스트 실행 절차에 대한 명시
      • Mock 오브젝트 ㅣ 사용자의 행위를 조건부로 사전에 입력해두면, 그 상황에 예정된 행위를 수행
  • 테스트 단계별 자동화 도구
    1. 테스트 계획 ㅣ 요구사항 관리, 고객 요구사항 정의 및 관리 지원
    2. 테스트 분석/설계 ㅣ 테스트 케이스 생성
    3. 테스트 수행 ㅣ 테스트 자동화, 정적 분석, 동적 분석, 성능 테스트, 모니터링
    4. 테스트 관리 ㅣ 커버리지 측정 (테스트 충분성 여부 검증), 형상 관리 (테스트 수행 도구, 문서 관리), 결함 추적/관리

     

통합 테스트

  • 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법
  • 하향식 통합
    • 메인 제어 모듈로부터 아래 방향으로 제어의 경로를 따라 이동하면서 하향식으로 통합하면서 테스트 진행
    • 메인 제어 모듈에 통합되는 하위 모듈과 최하위 모듈은 깊이우선 또는 너비 우선 방식
  • 상향식 통합
    • 애플리케이션 구조에서 최하위 레벨의 모듈 또는 컴포넌트로부터 위쪽 방향으로 제어의 경로를 따라 이동하면서 구축과 테스트를 시작

     

애플리케이션 성능 개선

알고리즘

  • 어떠한 행동을 하기 위해 만들어진 명령어들의 유한 집합
  • 요건
    • 입력 ㅣ 0 또는 그 이상의 외부에서 제공된 자료가 존재
    • 출력 ㅣ 최소 1개 이상의 결과를 가짐
    • 명확성 ㅣ 알고리즘의 의미가 명확
    • 유한성 (종결성) ㅣ 정해진 단계를 지나면 종료
    • 효율성 ㅣ 유한한 시간에 수행 가능하도록 단순화
  • 분류
    • 주제별 ㅣ Basic (최대/최소값 찾기), Searching (탐색 문제), Sorting (정렬 문제), Graph (그래프 순회/탐색/검색), Optimizing (최적화)
    • 확률의 개입 여부 ㅣ Deterministic (정확한 답 반환), Probabilistic (실행 명령이 무작위로 결정)
    • 설계 기법/전략 ㅣ Divide and Conquer (규모가 큰 문제를 쪼갬)

     

코드 최적화

  • 읽기 쉽고 변경 및 추가가 쉬운 클린 코드를 작성
  • Bad Code
    • 로직을 이해하기 어렵게 작성된 코드, 로직의 제어가 정제되지 않은 스파게티 코드, 변수나 메서드에 대한 이름 정의를 알 수 없는 코드, 동일한 처리 로직이 중복 작성된 코드
  • Clean Code
    • 가독성이 높고, 단순하며 낮은 의존성을 가짐, 중복을 최소화, 설계가 개선되고 버그를 찾기 쉬움, 빠른 속도

     

소스코드 품질분석 도구

  • 정적 분석 도구
    • 사전에 결함을 발견하고 예방하는 도구, 코딩 표준 준수 여부를 분석하는 도구, 소스 코드의 복잡도를 계산하는 도구
  • 동적 분석 도구
    • 정적 분석 도구 ㅣ pmd (자바 버그, 데드코드 분석), cppcheck (c/cpp 메모리 누수, 오버플로우), SonarQube (소스코드 품질통합 플랫폼), checkstyle (자바 코딩 표준 준수 검사)
    • 코드 복잡도 ㅣ ccm (다양한 언어), cobertura (jcoverage 기반 테스트 커버리지 측정)
    • 동적 분석 도구 ㅣ Avalanche (Valgrind 프레임워크 및 STP 기반 소프트웨어 에러 분석), Valgrind (자동화된 메모리/스레드 결함 발견)

     

5) 인터페이스 구현

인터페이스 설계 확인

인터페이스 기능 확인

  • 인터페이스 설계서
    • 이 기종 시스템 및 컴포넌트 간 데이터 교환/처리를 위한 문서
    • 시스템 인터페이스 정의서 ㅣ 시스템 인터페이스 현황을 파악하기 위해 인터페이스 목록 및 상세 정보 구체화
    • 상세 기능별 인터페이스 정의서 ㅣ 실행하기 전 필요한 사전 조건, 사후 조건 및 인터페이스 파라미터, 호출 이후 결과 반환값 정의
  • 정적/동적 모형을 통한 인터페이스 설계서 ㅣ 시스템을 구성하는 주요 구성 요소 간 트랜잭션, 인터페이스의 위치와 어떤 트랜잭션을 사용하는지 확인
  • 데이터 정의를 통한 인터페이스 설계서 ㅣ 제공하는 인터페이스 서비스에 대한 상세 명세를 표현

     

  • 인터페이스 목록
    • 인터페이스 ID (명명 표준), 인터페이스명, 송신 시스템 (전송), 수신 시스템 (데이터를 이용)
    • 대내외 구분 (인터페이스가 기업 내부 시스템 간 또는 내/외부 시스템 간 발생 여부), 연계 방식 (웹서비스, FTP, DB Link, Socket)
    • 통신 유형 (동기, 비동기), 처리 유형 (실시간 배치, 지연 처리), 주기, 데이터 형식 (포맷), 관련 요구사항 ID
  • 인터페이스 정의서 주요 항목
    • 인터페이스 ID
      • 식별자, 명명 표준에 맞게 부여, 식별성 강화를 위해 업무 분류 코드와 연속 번호를 같이 활용
    • 최대 처리 횟수
      • 단위 시간 당 처리 가능한 최대 수행 건수
    • 데이터 크기 (평균/최대) ㅣ 해당 인터페이스 1회 처리 시 소요되는 데이터의 평균/최대 크기
    • 시스템 정보 (송수신 시스템 각각 작성) ㅣ 시스템명, 업무, 서비스명/프로그램 ID, 연계 방식, 담당자 연락처
    • 데이터 정보 (송수신 시스템 각각 작성) ㅣ 번호, 필드, 식별자 여부, 데이터 타입, 데이터 크기, NULL 허용 여부, 설명, 조건, 매핑 규칙, Total Length, 추출조건/SQL

     

데이터 표준 확인

  • 인터페이스 데이터 형태가 동일한 경우
    • 송신자 A ㅣ (전달) 인터페이스 데이터 영역에 맞는 데이터 전송
    • 송신사 B ㅣ (전달) 인터페이스 데이터 영역을 수신자에게 전송
  • 인터페이스 데이터 형태가 동일하지 않은 경우
    • 송신자 A ㅣ (변환) 인터페이스에 맞게 데이터를 변환하여 전송
    • 송신자 B ㅣ (전달) 인터페이스 공통영역을 수신자에게 전송

     

  • 표준 확인 순서
  1. 식별된 데이터 인터페이스를 통해 데이터 표준을 확인
    • 데이터 표준 작성을 위해 데이터 인터페이스의 입출력 값이 의미하는 내용 파악
    • 데이터 인터페이스에서 각 항목의 의미를 파악
  2. 식별된 인터페이스 기능을 통해 인터페이스 데이터 표준을 확인
    • 인터페이스 기능을 구현하기 위해 필요 항목에 대해 분석/나열
    • 식별된 인터페이스 기능을 통해 필요 데이터 항목과 이전에 식별된 데이터 인터페이스 항목에서 수정, 추가, 삭제
  3. 데이터 인터페이스 및 식별된 인터페이스 기능을 통해 데이터 표준 확인
    • 필요 표준 및 조정해야 할 항목들을 검토/확인
    • 데이터 표준을 어디서 도출하였는지 구분 작성

     

인터페이스 기술 표준 확인 방식

  • EAI and ESB

     

인터페이스 기능 구현

인터페이스 보안

  • 인터페이스 구현 도구
    • 데이터 통신을 통한 인터페이스 구현: 애플리케이션 영역에서 인터페이스 형식에 맞춘 데이터 포맷을 인터페이스 대상으로 전송하고 이를 수신 측에서 Parsing 하여 해석하는 방식
      • 특정 언어에 종속되지 않으며 대부분의 프로그래밍 언어에서 JSON 포맷의 데이터를 핸들링 할 수 있는 라이브러리 제공
        • JSON 데이터 타입
          • Number, String, Boolean, Array, Value, Object, Whitespace, Null
        • XML Extensible Markup Language: 다목적 마크업 언어
          • 다른 목적의 마크업 언어를 만드는데 사용, 다양한 종류의 데이터를 쉽게 교환
          • 새 태그를 만들어 추가해도 계속해서 동작, 넓은 확장성, 데이터를 보여주지 않고도 데이터를 전달/저장 하는 목적
          • 텍스트 데이터 형식의 언어, 모든 XML 문서는 유니코드 문자로만 이루어짐
          • XHTML, SVG, RDF, RSS, Atom, MathML
    • 인터페이스 엔티티를 통한 인터페이스 구현

     

  • 인터페이스 주요 보안 문제점
    • 스니핑(Sniffing) ㅣ 컴퓨터 네트워크 상에서 자신이 아닌 다른 상대방들의 패킷 교환을 훔쳐보는 행위, 수동적 공격
    • 스푸핑(Spoofing) ㅣ 외부의 악의적 네트워크 침입자가 웹사이트를 구성해 사용자들의 방문을 유도, TCP/IP의 구조적 결함을 이용해 사용자의 시스템 권한을 획득 후 정보를 빼감
      • ARP 스푸핑 ㅣ 근거리 통신망 하에서 주소 결정 프로토콜 메세지를 이용하여 상대방의 데이터 패킷을 중간에 가로챔, 중간자 공격
      • IP 스푸핑 ㅣ MAC의 윗 단계인 IP 주소를 속이는 방법
      • DNS 스푸핑 ㅣ 실제 DNS 서버보다 빨리 공격 대상에게 DNS 응답 패킷을 보내 공격 대상이 잘못된 IP주소로 웹 접속을 하도록 유도
    • 스니퍼(Sniffer) ㅣ UDP, TCP, ICMP 등으로 패킷의 정보를 가로채는 크래킹 기술

     

  • DB 암호화
    • DB 암호화 알고리즘 ㅣ 대칭 키 암호 알고리즘 (ARIA 128/192/256, SEED), 해시 알고리즘 (SHA-256/384/512, HAS-160), 비대칭 키 알고리즘 (RSA, ECDSA)
    • DB 암호화 기법
      • API 방식 ㅣ APP 레벨에서 암호 모듈을 적용하는 APP 수정 방식, 별도의 APP 개발 통합, APP 서버에 암호화/복호화/정책관리 키 관리 부하 발생
        • APP 개발 통합 기간 필요, APP 변경 및 암호화 필드 변경에 따른 유지 보수 필요
      • Fiter 방식 ㅣ DB 레벨의 확장성 프로시저 기능 이용, DBMS에 Plug-in/Snap-in 모듈로 동작, DB내 설치 연동, DB 서버에 암호화/복호화/정책관리/키 관리 부하 발생
        • APP 변경 불필요, 관리자용 GUI 이용, 다수 DB 통합 관리 기능 편의성 높음
      • Hybrid 방식 ㅣ API 방식 + Fiter 방식, Fiter 방식 + SQL 문에 대한 최적화, 어플라이언스/DB 내 설치, DB와 어플라이언스에서 부하 분산
        • APP 변경 불필요, 관리자용 GUI 이용, 다수 DB 통합 관리 기능 편의성 높음

     

소프트웨어 연계 테스트

  • 구축된 연계 시스템과 송신 모듈, 수신 모듈, 연계 서버 및 엔진, 모니터링 현황 등의 정상 동작 여부 확인/검증
  • 환경 구축
    • 연계 서버 또는 송/수신용 어댑터 설치, 연계를 위한 IP 및 포트 허용 신청, 연계를 위한 DB 계정 및 테이블과 데이터 생성 등의 테스트 환경 구축
  • 진행 순서
  1. 연계 모듈 테스트 케이스 작성 및 명세화
    • 연계 테스트 구간에서의 데이터 및 프로세스 흐름에 따라 테스트 케이스를 작성
    • 송수신 시스템 간 연계 데이터 정상 추출 여부, 데이터 형식 체크, 데이터 표준 준수 여부 등을 테스트
    • 연계 테스트 케이스는 연계 테이블 단위로 작성, 연계 테이블 간 송수신 절차의 선후로 연결하여 흐름을 확인
  2. 연계 테스트 수행 및 검증
    • 연계 테스트 환경은 실제 운영 환경과 동일하게 구축
    • 송수신 기관 간 테스트 수행 전 연계 일정, 절차, 방법, 소요 시간, 테스트 환경, 환경 구축 기간 협의
    • 단위 테스트에서 오류 없이 수행 완료 되면 작성한 테스트 케이스대로 데이터를 추출, 송수신, 데이터 반영 과정의 연계 테스트 수행
    • 목표했던 결과인지 검증 수행

     

인터페이스 구현 검증

설계 산출물

  • 인터페이스 구현 검증 도구
    • 인터페이스 구현 검증 도구와 감시 도구를 통하여 인터페이스 동작 상태를 검증 및 감시 가능
    • 도구 목록
      • xUnit ㅣ Java (Junit), C++ (Cppunit), Net (Nunit) 등 다양한 언어를 지원하는 단위 테스트 프레임 워크
      • STAF ㅣ 서비스 호출, 컴포넌트 재사용 지원
      • FitNesse ㅣ 웹 기반 테스트 케이스 설계/실행/결과 확인 지원
      • NTAF ㅣ Naver 테스트 자동화 프레임 워크, STAF + FiNesse
      • Selenium ㅣ 웹 애플리케이션 테스트 프레임워크
      • watir ㅣ Ruby 기반 웹 애플리케이션 테스트 프레임워크
  • 인터페이스 감시 도구
    • 인터페이스 동작 여부를 확인하기 위해 애플리케이션 모니터링 툴을 이용하여 동작 상태 감시
    • 데이터베이스, 웹 애플리케이션의 트랜잭션과 변수값, 호출 함수, 로그 및 시스템 부하 등 종합적인 정보를 조회/분석
    • Scouter, Jennifer

     

인터페이스 명세서

  • 오류 처리 방법
  1. 사용자 화면에서 오류를 발생
    • 가장 많이 쓰임, 가장 직관적으로 오류를 인지, 오류 발생시 알람의 형태로 화면에 표시, 주로 즉시적으로 데이터가 인터페이스되는 경우에 사용
  2. 인터페이스 오류 로그 생성
    • 시스템 운영 로그에 인터페이스 오류 발생 시 관련 에러 로그 생성, 인터페이스 오류의 자세한 내역을 알기 위함, 시스템 관리자/운영자가 확인 가능
  3. 인터페이스 관련 테이블에 오류 사항 기록
    • 테이블을 통한 인터페이스 기능 구현, 트랜잭션 기록 별도 보관 시 테이블에 오류 사항 기록 가능
    • 이력을 직관적으로 보기 쉽기 때문에 운영자가 관리하기 용이
  • 오류 처리 보고서 작성
This post is licensed under CC BY 4.0 by the author.