[정보처리기사] 2과목 - 소프트웨어 개발(2)

애플리케이션 관리

---

애플리케이션 테스트

- 애플리케이션에 잠재되어 있는 결함을 찾아내는 행위

- 확인(Validation): 요구사항을 만족하는지 사용자의 입장에서 확인

- 검증(Verification): 명세서에 맞게 기능을 잘 수행하는지 개발자의 입장에서 점검

- 필요성: 오류 발견, 신뢰도 향상, 새로운 오류 유입 예방

기본 원리

- 잠재적 결함을 줄일 수 있지만 결함이 없다고 증명은 불가

- 결함은 대부분 특정 모듈에 집중

- 테스트 케이스를 지속적으로 보완 및 개선

- 정황에 다라 다르게 수행

- 작은 부분에서 시작해 점점 확대하며 진행

 

 

애플리케이션 테스트 분류

1. 프로그램 실행 여부

- 정적 테스트: 소스 코드나 명세서 분석, 개발 초기 결함 발견할 수 있어서 비용 절감 가능

ex) 워크 스루, 인스펙션, 코드 검사 등

- 동적 테스트: 프로그램 실행해 테스트

ex) 블랙 박스 테스트, 화이트 박스 테스트

 

2. 테스트 기반

- 명세 기반 테스트: 사용자 요구사항 명세를 테스트 케이스로 만들어 구현하고 있는지 확인

ex) 동등 분할, 경계 값 분석

- 구조 기반 테스트: SW 내부 논리 흐름에 따라 테스트 케이스로 만들어 구현하고 있는지 확인

ex) 구문 기반, 결정 기반, 조건 기반

- 경험 기반 테스트: 테스터 경험을 기반으로 테스트, 요구사항 명세 부족, 테스트 시간 제약 시 효율적

ex) 에러 추정, 체크 리스트, 탐색적 테스팅

 

3. 시각

- 검증 테스트: 개발자의 시각에서 생산 과정 테스트

- 확인 테스트: 사용자의 시각에서 생산 제품 결과 테스트

 

4. 목적

- 회복 테스트: 결함을 주고 복구 테스트

- 안전 테스트: 시스템 보호 도구가 불법적 침입으로부터 보호 테스트

- 강도 테스트: 과부하 테스트

- 성능 테스트: 응답 시간, 처리량 등 테스트

- 구조 테스트: 내부 논리적 경로, 소스 코드 복잡도 테스트

- 회귀 테스트: 변경(수정)에 따른 결함 테스트

- 병행 테스트: 변경된 SW와 기존 SW를 비교 테스트

 

 

동적 테스트

1. 화이트 박스 테스트

- 모듈의 원시 코드를 오픈하여 논리적인 경로를 테스트

- 테스트 과정 초기에 진행

- 모듈 안의 동작을 직접 관찰

- 종류: 기초 경로 검사, 제어구조 검사(조건, 루프, 데이터 흐름)

- 검증 기준: 문장 검증 기준, 분기 검증 기준, 조건 검증, 분기/조건 기준

 

2. 블랙 박스 테스트

- SW가 수행할 특정 기능을 알기 위해 기능이 완전 작동하는 것을 입증

- 사용자 요구사항 명세서를 보며 구현된 기능 테스트

- 종류: 동치(동등) 분할 기법, 경계값 분석, 원인-효과 그래프, 오류 예측 검사, 비교 검사

 

 

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

1. 단위 테스트(Unit Test)

- 코딩 직후 모듈이나 컴포넌트에 초점을 맞춰 테스트

- 화이트 박스 테스트(구조 기반 테스트), 블랙 박스 테스트(명세 기반 테스트) 사용

 

2. 통합 테스트(Integration Test)

- 단위 테스트가 완료된 모듈들을 결합해 하나의 시스템으로 완성시키는 과정에서 테스트

- 비점진적 통합 방식, 점진적 통합 방식

 

3. 시스템 테스트(System Test)

- 개발된 SW가 원하는 환경에서 수행되는지 테스트

- 기능적/비기능적 요구사항을 다 만족하는지 테스트

 

4. 인수 테스트(Acceptance Test)

- 개발한 SW가 사용자의 요구사항을 충족하는지 테스트

 

 

+) 통합 테스트

비점진적 통합 방식

- 모든 모듈이 미리 결합된 프로그램 전체 테스트

- 오류 발견 및 장애 위치 파악이 어려움

ex) 빅뱅 통합 테스트 방식

 

점진적 통합 방식

- 모듈 단위로 단계적으로 통합하면서 테스트

- 하향식/상향식/혼합식 테스트 방식

하향식 통합 테스트

- 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트

- 깊이 우선 통합법, 너비 우선 통합법 사용

- 상위 모듈에선 테스트 케이스 사용이 어려움

- 스텁 사용

상향식 통합 테스트

- 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트

- 클러스터(하나의 주요 제어 모듈과 종속 모듈 그룹)와 드라이버 사용

혼합식 통합 테스트(샌드위치식 통합 테스트)

- 상향식+하향식 통합 테스트

 

 

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

- 개발된 SW가 제대로 만들어졌는지 테스트하는 절차

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

 

 

테스트 케이스

- 사용자의 요구사항이 준수되었는지 확인하기 위해 테스트 항목에 대한 명세서

- 명세 기반 테스트의 설계 산출물

- 작성 순서: 테스트 계획 검토 및 자료 확보 -> 위험 평가 및 우선순위 결정 -> 테스트 요구사항 정의 ->테스트 구조 설계 및 테스트 방법 결정 -> 테스트 케이스 정의 -> 테스트 케이스 타당성 확인 및 유지 보수

 

테스트 시나리오

- TC를 적용하는 구체적인 절차를 명세한 문서

 

테스트 오라클

- 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입해 비교하는 기법 및 활동

- 특징: 제한된 검증, 수학적 기법, 자동화 기능

- 종류: 참 오라클, 샘플링 오라클, 추정 오라클, 일관성 검사 오라클

 

 

테스트 자동화

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

- 장점: 인력 및 시간 감소, 향상된 테스트 품질 보장, 사용자의 요구사항 등을 일관성 있게 검증, 테스트 결과를 다양한 표시 형태로 제공, UI가 없는 서비스도 정밀 테스트 가능

- 단점: 사용방법에 대한 교육 및 학습 필요, 자동화 도구를 프로세스 단계별로 적용하기 위한 시간, 비용 노력이 필요

고려사항

- 자동화 도구를 고려하여 프로젝트 일정 계획

- 모든 과정이 아닌 그때그때 맞는 적절한 도구를 선택

- 프로젝트 초기에 테스트 엔지니어의 투입 시기 계획

유형

- 정적 분석 도구: 프로그램을 실행하지 않고 분석하는 도구

- 테스트 실행 도구: 스크립트 언어를 사용하여 테스트 실행

- 테스트 통제 도구: 테스트 계획 및 관리, 수행, 결함 관리 등을 수행

- 테스트 하네스 도구: 테스트 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈 테스트

 

 

결함 관리 프로세스

- 결함: SW가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생하는 것

- 결함 관리 계획 - 결함 기록 - 결함 검토 - 결함 수정 - 결함 재확인 - 결함 상태 추적 및 모니터링 활동 - 최종 결함 분석 및 보고서 작성

-결함 상태 추적: 테스트에서 발견된 결함은 지속적으로 상태 변화 추적 및 관리

-> 측정 지표: 결함 분포, 결함 추세, 결함 에이징

-> 결함 추적 순서: 결함 등록 - 검토 - 할당 - 수정 - 조치 분류 - 종류 - 해제

- 결함 분류: 시스템 결함, 기능 결함, GUI 결함, 문서 결함

- 결함 심각도: 우선순위에 따라 분류(High - Medium - Low)

- 결함 우선순위: 결정적, 높음, 보통, 낮음 또는 즉시 해결, 주의 요망, 대기, 개선권고

 

 

애플리케이션 성능 분석

- 측정 지표: 처리량, 응답 시간, 경과 시간, 자원 사용률

- 성능 테스트 도구: JMeter, LoadUI, OpenSTA

- 시스템 모니터링 도구: Scouter, Zabbix

 

 

애플리케이션 성능 개선

- 소스 코드 최적화: 나쁜 코드 배제, 클린 코드로 작성

- 소스 코드 최적화 유형: 클래스 분할 배치, 느슨한 결합, 코딩 형식 준수, 좋은 이름 사용, 적절한 주석문 사용

 

 

인터페이스 구현

---

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

- 공통 기능: 모듈에 공통적으로 제공되는 기능

- 데이터 인터페이스: 모듈 간 교환되는 데이터가 저장될 파라미터

 

 

인터페이스 설계서

- 교환 데이터 및 관련 업무, 송수신 시스템 등에 대한 내용을 정리한 문서

- 일반적인 인터페이스 설계서

: 인터페이스 목록, 상세 데이터 명세, 기능의 세부 정보를 정의한 문서

: 시스템 인터페이스 설계서 - 시스템 인터페이스 목록과 상세 데이터 명세를 정의

: 상세 기능별 인터페이스 명세서 - 기능의 세부 인터페이스 정보 정의

- 정적/도형 모형을 통한 인터페이스 설계서

: 시스템 구성요소를 다이어그램으로 표현하여 만든 문서

 

 

모듈 연계

- 모듈 간 데이터 교환을 위해 관계를 설정하는 것.

- EAI(Enterprise Application Integration)

: 기업 내 정보 전달, 연계, 통합 등 상호 연동이 가능하게 해주는 솔루션

: 구축 유형

-> Point-to-Point: 애플리케이션 1:1로 연결

-> Hub&Spoke: 단일 접점인 허브 시스템을 통해 데이터를 전송하는 중앙 집중형 방식

-> Message Bus(ESB): 애플리케이션 사이 미들웨어를 두어 처리

-> Hybrid: Hub&Spoke와 Message Bus의 혼합 방식

- ESB(Enterprise Service Bus)

-> 애플리케이션 간 표준 기반 인터페이스를 제공하는 솔루션

-> 애플리케이션보다는 서비스 중심의 통합을 지향

-> 관리 및 보안 유지가 쉽고 높은 수준의 품질 지원

 

 

인터페이스 데이터 표준

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

- 확인 된 인터페이스 데이터 표준은 인터페이스 기능 구현 정의에 사용

 

 

인터페이스 기능 구현

- 인터페이스를 실제로 구현하기 위해 인터페이스 기능에 대한 구현 방법을 기능별로 기술

- 정의 순서

1. 컴포넌트 명세서 확인

2. 인터페이스 명세서 확인

3. 일관된 인터페이스 기능 구현 정의

4. 정의된 인터페이스 기능 구현 정형화

- 모듈 세부 설계서: 모듈의 구성 요소와 세부적인 동작 등을 정의한 설계서

-> 컴포넌트 명세서, 인터페이스 명세서

 

 

인터페이스 구현

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

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

 

 

인터페이스 예외 처리

- 구현된 인터페이스가 동작하는 과정에서 기능상 예외 상황이 발생했을 때 처리하는 절차

 

 

인터페이스 보안

- 충분한 보안을 갖추지 않으면 시스템 전체에 악영향을 주는 취약점이 될 수 있음

 

 

연계 테스트

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

 

 

참고 자료

---

https://powerdev.tistory.com/54?category=878089

https://1d1cblog.tistory.com/161?category=847035