그냥 한번 작성

화이트박스 테스트

• 모듈의 원시 코드 논리적인 모든 경로 테스트 -> 테스트 케이스 설계
• 설계된 절차 초점
• 구조적 테스트 -> 프로시저 설계의 제어 구조 사용
• 테스트 과정의 초기 적용
• 모듈 작동 직접 관찰

기초 경로 검사

• 대표적인 화이트박스 테스트 기법
• 테스트 케이스 설계자가 절차적 복잡성 측정
• 결과는 실행 경로의 기초 정의하는데 사용

제어 구조 검사

검증 기준

※ 검증 기준 종류

• 기능 기반 커버리지 : 실제 테스트 수행된 기능 수 / 전체 기능 수
• 라인 커버리지 : 테스트 시나리오가 수행한 코드 라인 수 / 전체 코드 라인 수
• 코드 커버리지 : 코드의 구문, 분기, 조건 등의 구조 코드 자체가 얼마나 테스트 되었는지 측정

블랙박스 테스트

• SW가 수행할 기능이 완전히 작동되는 것을 입증 (기능 테스트)
• 요구사항 명세 기반
• 주로 구현된 기능 테스트
• SW 인터페이스에서 실시
• 테스트 과정의 후반 적용

블랙박스 테스트 종류

애플리케이션 테스트

• 애플리케이션에 잠재되어 있는 결함 찾아냄
• 개발된 SW가 고객 요구사항을 만족시키는지
• SW가 기능을 정확히 수행하는지

애플리케이션 테스트 필요성

• 프로그램 실행 전 오류 발견
• 제품의 신뢰도 향상
• 새로운 오류의 유입 예방

애플리케이션 테스트 기본 원리

• 완벽한 소프트웨어 테스팅은 불가능
• 결함은 특정 모듈에 집중 (파레토 법칙)
• 동일한 테스트 케이스로 동일한 테스트 반복 시 더 이상 결함 발견 못함 (살충제 패러독스)
• 정황에 따라 테스트 다르게 수행
• 결함 모두 제거해도 요구사항 불만족 시 품질 높다고 말할 수 없다. (오류-부재의 궤변)
• 테스트와 위험은 반비례
• 점점 확대하며 테스트 진행
• 개발자와 관계없는 별도의 팀으로 수행

테스트 분류

프로그램 실행 여부에 따른 테스트

테스트 기반에 따른 테스트

시각에 따른 테스트

목적에 따른 테스트

시스템 소프트웨어

• 하드웨어 전체 제어 및 운영
• ex) 운영체제, 데이터 관리, 스토리지 소프트웨어, 소프트웨어 공학 도구, 가상화 소프트웨어 등

미들웨어

• 운영체제와 응용 프로그램 사이에서 운영체제 이외 추가적인 서비스 제공
• ex) 분산 시스템 소프트웨어, 서비스 플랫폼, 네트워크 보안 소프트웨어

응용 소프트웨어

• 특정 업무 처리위함
• ex) 영상처리, CG/VR, 콘텐츠 배포, 자연어 처리, 음성 처리 등

단위 모듈 테스트

• 기능 구현하는 모듈이 정해진 기능을 정확히 수행하는지 검증
• 화이트박스 테스트와 블랙박스 테스트 사용
• 단독적으로 실행할 수 있는 환경과 데이터 모두 준비
• 오류 쉽게 발견 및 수정

테스트 케이스

• 불필요한 인력, 시간 낭비 방지
• 명세 기반 테스트의 설계 산출물

테스트 프로세스

1. 계획 및 제어 : 테스트 계획 수립 및 수행
2. 분석 및 설계 : 테스트 시나리오와 테스트 케이스 작성
3. 구현 및 실현 : 테스트 케이스들 조합하여 테스트 프로시저에 명세
4. 평가 : 테스트 계획과 목표에 맞게 수행되었는지 평가 기록
5. 완료 : 테스트 수행에 대하 증거 자료로 활용 위해 수행과정과 산출물 기록 및 저장

모듈

• 단독으로 컴파일 가능
• 재사용
• 서로 독립적
• 다른 모듈과의 과도한 상호작용 배제
• 오류 발생 시 쉽게 발견 및 해결
• 독립성 ↑ : 결합도 ↓, 응집도 ↑, 크기 ↓

결합도 (Coupling)

• 두 모듈 사이의 연관 관계
• 결합도가 강할수록 품질이 낮음
• 결합도가 강할수록 시스템 구현 및 유지보수 작업 어려움

자료 결합도 (Data)

• 모듈 간 인터페이스가 자료 요소로만 구성
• 매개변수나 인수로 데이터 넘겨주고, 처리결과를 다시 돌려주는 방식
• 모듈 간 내용 알 필요 없음

스탬프 결합도 (Stamp)

• 자료구조가 전달 될 때
• 두 모듈이 동일한 자료구조 조회하는 경우

제어 결합도 (Control)

• 제어 요소를 전달하는 결합도
• 권리 전도현상 발생 (하위 모듈이 상위 모듈에게 처리명령)

외부 결합도 (External)

• 외부의 다른 모듈에서 참조할 때
• 참조되는 범위 각 모듈에서 제한 가능

공유 결합도 (Common)

• 공유되는 데이터 영역을 여러 모듈이 사용할 때
• 서로 사용하기에 수정하더라도 모든 모듈에 영향

내용 결합도 (Content)

• 다른 모듈의 내부 자료를 참조 및 수정할 때
• 다른 모듈의 내부로 제어가 이동할 때

※ 결합도 낮은 순서

자료 -> 스탬프 -> 제어 -> 외부 -> 공유 -> 내용

말도 안되는 방법으로 순서 외우기

(자료를 조사하고 스탬프를 찍어 제어하고 외부에서 공통적인 내용을 결합)

응집도 (Cohesion)

• 정보 은닉 개념을 확장
• 모듈의 내부 요소들이 서로 관련되어 있는 정도
• 모듈이 독립적인 기능으로 정의되어 있는 정도
• 응집도 강할수록 품질이 높다.

기능적 응집도 (Functional)

• 모든 기능 요소들이 단일 문제와 연관되어 수행할 경우

순차적 응집도 (Sequential)

• 출력 데이터를 다음 활동의 입력 데이터로 사용할 경우

교환적 응집도 (Communication)

• 동일한 입력, 출력 사용하여 서로 다른 기능 수행할 경우

절차적 응집도 (Procedural)

• 모듈 안의 구성요소들이 기능을 순차적으로 수행할 경우

시간적 응집도 (Temporal)

• 특정 시간에 몇 개의 기능을 모아 하나의 모듈로 작성할 경우

논리적 응집도 (Logical)

• 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우

우연적 응집도 (Coincidental)

• 서로 관련 없는 요소로만 구성된 경우

※ 응집도 강한 순서

기능적 -> 순차적 -> 교환적 -> 절차적 -> 시간적 -> 논리적 -> 우연적

말도 안되는 방법으로 순서 외우기

(기능을 순차적으로 교환하고 절차적으로 시간 안에 논리적이고 우연적이지 않게 응집한다.)

팬인 & 팬아웃

• 시스템 복잡도를 최적화하려면 팬인↑, 팬아웃↓설계

쉽게 모듈의 위는 팬인, 모듈의 아래는 팬아웃이라고 생각하면 된다.

아키텍처 패턴

• 시스템의 구조를 구성하기 위한 기본적인 윤곽 제시
• 아키텍처 스타일 or 표준 아키텍처
• 개발 시간 단축, 고품질 SW 생산
• 안정적인 개발
• 이해관계자 간 의사소통
• 개발에 참여하지 않은 사람도 쉽게 유지보수
• 개발 전, 시스템 특성 예측 가능

레이어 패턴 (Layers pattern)

• 각각의 서브 시스템들이 계층구조
• 상위 계층 : 서비스 제공자
• 하위 계층 : 클라이언트
• 변경작업 용이 (특정 계층만 교체 가능)
• ex) OSI 참조 모델

클라이언트-서버 패턴 (Client-Server Pattern)

• 하나의 서버, 다수의 클라이언트 구성
• 사용자가 클라이언트를 통해 서버에 요청 -> 서버 응답 -> 클라이언트 응답받고 사용자에게 제공
• 서버 항상 대기상태 유지
• 서버 및 클라이언트는 동기화 되는 경우 제외, 서로 독립적

파이프-필터 패턴 (Pip-Filter Pattern)

• 데이터 스트림 절차의 각 단계를 필터로 캡슐화하여 파이프 통해 데이터 전송
• 필터 -> 재사용성, 추가 확장 용이, 재배치 통해 다양한 파이프라인 구축 가능
• ex) 데이터 변환, 버퍼링, 동기화 등
• ex) UNIX의 쉘

모델-뷰-컨트롤러 (Model-View-Controller Pattern)

• 모델 : 서브시스템의 핵심 기능과 데이터 보관
• 뷰 : 사용자에게 정보 표시
• 컨트롤러 : 사용자로부터 입력 데이터 처리
• 서로 독립적으로 개발 작업 수행가능
• ex) 대화형 애플리케이션에 적합

기타 패턴

마스터-슬레이브 패턴

• 마스터 : 모든 작업의 주체
• 슬레이브 : 마스터의 지시에 따라 작업 수행 결과 반환
• ex) 장애 허용 세스템, 병렬 컴퓨팅 시스템

브로커 패턴

• 사용자 요청에 맞는 컴포넌트와 사용자와 연결
• ex) 분산 환경 시스템

피어-투-피어 패턴

• 각 피어는 서버와 클라이언트가 될 수 있다.
• 멀티스레딩 방식

이벤트-버스 패턴

• 이벤트 메시지 발행 시, 해당 채널 구독한 리스너들이 받아 처리
• 이벤트 생성 소스
• 이벤트 수행 리스터
• 이벤트 통로 채널
• 채널 관리 버스

블랙보드 패턴

• 컴포넌트가 검색을 통해 블랙보드에서 원하는 데이터 찾을 수 있다.
• 해결책 명확하지 않은 문제 처리 유용
• ex) 음성인식, 차량 식별 등

인터프리터 패턴

• 특정 언어로 작성된 코드 해석하는 컴포넌트 설계 시 사용

UI 프로토타입

• 요구사항 기반 실제 동작하는 것처럼 동적인 형태, 테스트 가능
• 요구사항에 맞게 개발자가 해석했는지 -> 최대한 간단하게

장점

• 사용자 이해시키기 쉬움
• 요구사항과 기능의 불일치로 인한 혼선 예방 -> 개발시간 단축
• 사전에 오류 발견

단점

• 반복적인 개선 및 보완작업 -> 작업시간 증가, 자원 소모
• 부분적 진행 시 중요작업 생략 가능

프로토타이핑 종류

페이퍼 프로토타입

• 아날로그 방법
• 제작 기간 짧은 경우 사용
• 비용 저렴
• 회의 중 생성가능
• 즉시 변경가능
• 테스트 부적당
• 여러 사람 공유 불가

디지털 프로토타입

• 파워포인트 등과 같은 프로그램 사용
• 숙련된 전문가 있을 경우 사용
• 최종 제품과 비슷하게 테스트 가능
• 수정 쉬움
• 재사용 가능
• 프로그램 사용법 알아야 함

고려사항

계획 시

• 개발 목적 확인
• 아키텍처 확정 이후, 실제 분석 완료 전 진행
• 비즈니스 요구사항 모두 만족하는지

작성 시

• 프로젝트 범위, 리스크 상황 등 감안하여 프로토타입 범위 정함
• 실제 개발에 참조될 수 있는지
• 범위는 가급적 좁게 설정

제작 단계

1단계

• 사용자 요구사항 분석
• 사용자 관점에서 기본적인 요구사항 확정 전까지 수행

2단계

• 페이퍼 및 디지털 프로토타입 활용
• 시스템의 핵심적인 기능 중심으로 개발

3단계

• 사용자가 직접확인 및 피드백

4단계

• 프로토타입 기반 수정 합의
• 보완작업
• 사용자 승인 전까지 3~4단계 반복

기능성 (Functionality)

• 요구사항을 정확하게 만족하는 기능을 제공하는지
• 적절성/정합성
• 정밀성/정확성
• 상호 운용성
• 보한성
• 호환성

신뢰성 (Reliability)

• 기능을 정확하고 일관되게 오류없이 수행할 수 있는 정도
• 성숙성
• 고장 허용성
• 회복성

사용성 (Usability)

• 사용자가 컴퓨터 사용행위에 대해 정확하게 이해하고 사용하며, 다시 사용하고 싶은 정도
• 이해성
• 학습성
• 운용성
• 친밀성

효율성 (Efficiency)

• 기능을 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리할 수 있는지
• 시간 효율성
• 자원 효율성

유지 보수성 (Maintainability)

• 새로운 요구사항 발생 시 SW를 개선, 확장할 수 있는 정도
• 분석성
• 변경성
• 안정성
• 시험성

이식성 (Portability)

• SW가 다른 환경에서도 쉽게 적용할 수 있는지
• 적용성
• 설치성
• 대체성
• 공존성

와이어프레임 (Wireframe)

• 기획 단계 초기 제작
• 대략적인 레이아웃, UI 요소 등 뼈대 설계
• 개발자, 디자이너 등 레이아웃 협의 및 진행상태 등 공유
• ex) 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등

목업 (Mockup)

• 실제화면과 유사하게 만든 정적인 형태의 모형
• 실제 구현 X
• ex) 파워 목업, 발사믹 목업 등

스토리보드 (Story Board)

• 와이어프레임 + 콘텐츠 설명, 페이지 간 이동 흐름 등
• 최종적으로 참고하는 작업 지침서 (문서)
• 서비스 구축을 위한 모든 정보가 있다.
• 좌측 : UI화면
• 우측 : 디스크립션 (명확하고 세부적으로 화면에 대한 설명)
• ex) 파워포인트, 키노트, 스케치, Axure 등

프로토타입 (Prototype)

• 와이어프레임 or 스토리보드 등 + 인터랙션 적용
• 실제 구현된 것처럼 테스트 가능한 동적인 형태
• ex) HTML/CSS, Axure Flinto, 네이버 프로토나우, 카카오 오븐 등

유스케이스 (UseCase)

• 사용자 측면의 요구사항
• 초기에 기능적인 요구 결정 -> 문서화
• 자연어로 작성 -> 요구사항 구조적 표현
• 유스케이스 명세서 작성