CERTIFICATION/IEIP
[1-3] 테스트 및 배포
써머레인
2024. 5. 17. 19:03
031 개발 지원 도구
통합 개발 환경 도구의 기능
- 코딩(Coding)
- C, JAVA 등의 프로그래밍 언어로 컴퓨터 프로그램을 만드는 기능
- 컴파일(Compile)
- 개발자가 작성한 고급 언어로 된 프로그램을 컴퓨터가 이해할 수 있는 목적 프로그램으로 번역
- 컴퓨터에서 실행 가능한 형태로 변환하는 기능
- 디버깅(Debugging)
- 소프트웨어나 하드웨어의 오류나 잘못된 동작(버그, Bug)를 찾아 수정하는 기능
- 배포(Deployment)
- 소프트웨어를 사용자에게 전달하는 기능
032 애플리케이션 테스트
특정 모듈 집중
- 결함 집중(Defect Clustering)
- 대부분의 결함이 소수의 특정 모듈에 집중해서 발생
파레토 법칙(Pareto Principle)
- 상위 20% t사람들이 전체 부의 80%를 가지고 있다거나, 상위 20% 고객이 매출의 80%를 창출한다는 의미
- 이 법칙이 애플리케이션 테스트에도 적용됨
- 테스트로 발견된 80%의 오류는 20%의 모듈에서 발견됨
- 20%의 모듈을 집중적으로 테스트하여 효율적으로 오류를 찾음
033 애플리케이션 테스트의 분류
목적에 따른 테스트
- 회복(Recovery) 테스트
- 시스템에 여러가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
- 안전(Security) 테스트
- 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지 확인하는 테스트
- 강도(Stress) 테스트
- 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하시에도 소프트웨어가 정상적으로 실행되는지 확인하는 테스트
- 성능(Perfomance) 테스트
- 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트
- 소프트웨어의 응답 시간, 처리량 등을 테스트
- 구조(Structure) 테스트
- 소프트웨어 내부의 논리적인 경로, 소스 코드의 복잡도 등을 평가하는 테스트
- 회귀(Regression) 테스트
- 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트
- 병행(Parallel) 테스트
- 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
034 테스트 기법에 따른 애플리케이션 테스트
화이트박스 테스트
- 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 테스트 → 테스트 케이스 설계
- 모듈 안의 작동을 직접 관찰
- 원시 코드(모듈)의 모든 문장을 한 번 이상 실행
- 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행 → 논리적 경로 제어
제어 구조 검사
- 조건 검사(Condition Testing)
- 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법
- 루프 검사(Loop Testing)
- 프로그램 반복(Loop) 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
- 반복 구조 : 단순 루프, 중첩 루프, 연결 루프, 비구조적 루프
- 데이터 흐름 검사(Data Flow Testing)
- 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법
블랙박스 테스트
- 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
- 기능 테스트라고도 함
- 사용자의 요구사항 명세를 보면서 테스트 → 주로 구현된 기능을 테스트
- 소프트웨어 인터페이스에서 실시되는 테스트
035 개발 단계에 따른 애플리케이션 테스트
소프트웨어 테스트 순서
단위 테스트 → 통합 테스트 → 시스템 테스트(System Test) → 인수 테스트(Acceptance Test)
단위 테스트(Unit Test)
- 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
- 사용자의 요구사항을 기반으로 한 기능성 테스트를 최우선으로 수행
036 통합 테스트
통합 테스트(Interation Test)
- 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
- 종류
- 하향식 통합 테스트
- 상향식 통합 테스트
- 혼합식 통합 테스트
하향식 통합 테스트
- 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트
- 주요 제어 모듈을 기준으로 아래 단계로 이동하면서 통합
- 깊이 우선 통합법 or 넓이 우선 통합법
- 테스트 과정에서 스텁(Stub) 사용
상향식 통합 테스트(Bottom Up Integration Test)
- 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트
- 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster) 필요
- 가장 하위 단계의 모듈부터 통합 및 테스트 수행 → 스텁(Stub) 필요 X
- 테스트 과정에서 드라이버(Driver) 사용
037 결함 관리
결함의 정의
- 오류 발생, 작동 실패 등과 같이 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것
결함 관리 프로세스
결함 관리 계획 → 결함 기록 → 결함 검토 → 결함 수정 → 결함 재확인 → 결함 상태 추적 및 모니터링 활동
→ 최종 결함 분석 및 보고서 작성
038 사용자 인터페이스
사용자 인터페이스(UI) 특징
- 사용자의 편리성과 가독성을 높음 → 작업 시간 단축, 업무에 대한 이해도 상승
- 사용자 중심으로 설계 → 사용자 중심의 상호 작용
- 수행 결과의 오류 감소
- 사용자의 막연한 작업 기능에 대해 구체적인 방법 제시
UX(User Experience)
- 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험
- 단순히 기능이나 절차상의 만족뿐만 아니라 사용자가 참여, 사용, 관찰하고, 상호 교감을 통해 알 수 있는 가치있는 경험
사용자 인터페이스 구분
- CLI(Command Line Interface)
- 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스
- GUI(Graphical User Interface)
- 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스
- NUI(Natural User Interface)
- 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
- VUI(Voice User Interface)
- 사람의 음성으로 기기를 조작하는 인터페이스
- OUI(Organic User Interface)
- 모든 사물과 사용자 간의 상호작용을 위한 인터페이스
- 소프트웨어가 아닌 하드웨어 분야에서 사물 인터넷, 가상현실, 증강현실, 혼합현실 등과 함께 대두되고 있음
사용자 인터페이스의 기본 원칙
- 직관성
- 누구나 쉽게 이해하고 사용할 수 있어야 함
- 유효성
- 사용자의 목적을 정확하고 완벽하게 달성해야 함
- 학습성
- 누구나 쉽게 배우고 익힐 수 있어야 함
- 유연성
- 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 함
039 UI 표준 및 지침
웹의 3요소
- 웹 표준(Web Standards)
- 웹에서 사용되는 규칙 또는 기술
- 웹 사이트 작성 시 이용하는 HTML, JavaScript 등에 대한 규정, 웹 페이지가 다른 기종이나 플랫폼에서도 구현되도록 제작하는 기법 등
- 웹 접근성(Web Accessibility)
- 누구나, 어떠한 환경에서도 웹 사이트에서 제공하는 모든 정보를 접근하여 이용할 수 있도록 보장
- 웹 호환성(Cross Browsing)
- 하드웨어나 소프트웨어 등이 다른 환경에서도 모든 이용자에게 동등한 서비스를 제공
네비게이션
- 사용자가 사이트에서 원하는 정보를 빠르게 찾을 수 있도록 안내하는 것 → 사용자 중심
- 원하는 정보를 쉽고 빠르게 찾을 수 있도록 다양한 경로나 방법 제공
- 메뉴, 사이트 맵, 버튼, 링크 등으로 구성
- 구성 요소들은 사용자가 직관적으로 찾아 사용할 수 있도록 설계되어야 함
- 사용자가 혼동하지 않도록 전체 페이지에서 일관성 있어야 함
040 UI 설계 도구
와이어 프레임
- 기획 단계의 초기에 제작
- 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대 설계 단계
목업
- 디자인, 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형
- 시각적으로만 구성 요소를 배치하는 것(실제 구현 X)
스토리보드
- 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
041 UI 테스트 기법의 종류
휴리스틱 평가
- 최소 3명 이상의 디자인 전문가가 사전에 작성한 원칙에 따라 제품 평가
- UI 구현 정도에 관계없이 평가 가능
페이퍼 프로토타입
- 종이로 해당 서비스를 간단하게 만들어 실제 구현되는 것처럼 표현 → 이를 이용해 테스트
- 프로토타입 작성시 포함되어야 할 중요한 내용을 체크리스트로 작성
선호도 평가
- "A보다 B가 더 좋다"와 같이 선호도에 영향을 주는 속성들을 파악하고 예측하기 위한 기법
- 사용자의 감성을 분석하기 위해 과학적인 시점에서 객관적으로 해석
성능 평가
- 개발 마지막 단계에서 제품의 학습성, 효율성, 기억용이성, 오류, 만족도 등을 평가한 결과를 바탕으로 성능을 개선하는 기법
042 소프트웨어 버전 등록
소프트웨어 패키징의 형상 관리
- 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동
- 관리 항목 : 소스 코드, 프로젝트 계획, 분석서, 설계서, 지침서, 프로그램, 테스트 케이스 등
형상 관리 기능
- 형상 식별
- 형상 관리 대상에 이름과 관리 번호를 부여
- 계층(Tree) 구조로 구분 → 수정 및 추적 용이하게 하는 작업
- 버전 제어
- 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목 관리
- 특정 절차와 도구(Tool)를 결합시키는 작업
- 형상 통제(변경 관리)
- 식별된 형상 항목에 대한 변경 요구 검토 → 현재 기준선(Base Line)이 잘 반영될 수 있도록 조정하는 작업
소프트웨어의 버전 등록 관련 주요 기능
- 저장소(Repository)
- 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳
- 가져오기(Import)
- 버전 관리가 되고 있지 않은 아무것도 없는 저장소(Repository)에 처음으로 파일을 복사
- 체크아웃(Check-Out)
- 프로그램을 수정하기 위해 저장소(Repository)에서 파일을 받아옴
- 체크인(Check-In)
- 체크아웃 한 파일의 수정을 완료한 후 저장소(Repository)의 파일을 새로운 버전으로 갱신
- 커밋(Commit)
- 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에는 충돌(Conflict)을 알리고 diff 도구를 이용해 수정한 후 갱신 완료
043 소프트웨어 버전 관리 도구
Subversion
- CVS를 개선한 것
- 2000년 아파치 소프트웨어 재단에서 발표
- 클라이언트/서버 구조
- 서버(저장소, Repository)에는 최신 버전의 파일들과 변경 내역 관리
- 서버의 자료를 클라이언트로 복사해와 작업한 후 변경 내용을 서버에 반영(Commit)
- 클라이언트는 대부분의 운영체제에서 사용되지만, 서버는 주로 유닉스를 사용
- 오픈 소스 → 무료 사용 가능
- CVS의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능
Git
- 리누스 토발즈(Linus Torvalds)가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발
→ 주니오 하마노(Junio Hamano)에 의해 유지 보수되는 중 - 분산 버전 관리 시스템 → 2개의 저장소 존재
- 지역(로컬) 저장소, 원격 저장소
- 지역 저장소 : 개발자들이 실제 개발을 진행하는 장소, 버전 관리 수행
- 버전 관리가 지역 저장소에서 진행 → 버전 관리가 신속하게 처리, 원격 저장소나 네트워크에 문제가 있어도 작업 가능
044 빌드 자동화 도구
빌드 자동화 도구
- 빌드
- 소스 코드 파일들을 컴파일한 후 여러 개의 모듈을 묶어 실행 파일로 만드는 과정
- 빌드 자동화 도구
- 빌드를 포함하여 테스트 및 배포를 자동화하는 도구
- Ant, Make, Maven, Gradle, Jenkins 등
Gradle
- Groovy 기반 오픈 소스 형태의 자동화 도구
- 안드로이드 앱 개발 환경에서 사용
- 플러그인 설정시 JAVA, C/C++, Python 등의 언어도 빌드 가능
- Grrovy를 사용해서 만든 DSL(Domain Specific Language)을 스크립트 언어로 사용
- Gradle Wrapper를 이용하면 빌드 환경이 변해도 환경에 필요한 추가적인 설치 없이 Gradle 사용 가능