Post

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

Posted Updated
By Seoyoung Oh 91 min read

자격증 정보처리기사 필기의 “Chapter 2. 소프트웨어 개발” 내용을 요약합니다.

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: 서버와 클라이언트로 구성되어 다수의 인원이 동시에 범용적인 운영체제로 접근 가능하여 버전관리를 가능케 함, 클라이언트가 이클립스에 내장됨
      • Subversion (SVN): 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. 인터페이스 관련 테이블에 오류 사항 기록
    • 테이블을 통한 인터페이스 기능 구현, 트랜잭션 기록 별도 보관 시 테이블에 오류 사항 기록 가능
    • 이력을 직관적으로 보기 쉽기 때문에 운영자가 관리하기 용이
  • 오류 처리 보고서 작성
Extracurricular Activities, Certification
정보처리기사 data-structure er-diagram dbms orm apm ide drm test-case xml
This post is licensed under CC BY 4.0 by the author.