백자의 블로그

Multiple-V, 상태기반 테스트, 리스크기반 테스트, 명세기반 테스트

기출문제

I. Embedded 시스템 Testing의 개념

- 마이크로 프로세서 또는 마이크로 컨트롤러를 내장하여 제작자가 의도한 특수 기능만을 수행하도록 제작된 컴퓨팅 장치를 테스트 하는 기법

II. Embedded 시스템 테스트 모델 및 기법

가. 테스트 모델

모델	동작원리	설명
Dess-V		- 상위에서는 통합검증을 수행하고, 하위에서 SW 상세 검증하는 모델 - H/W의 테스팅 연계 부분을 별도로 고려하여 테스트를 수행
Multiple V		- V 모델 기반한 모델로 임베디드 시스템 개발 방식을 정형화한 개발모델 - 임베디드 시스템은 모델 -> 시제품(Prototype) -> 최종제품 단계로 진화 - 제품의 진화하는 단계마다 V-model의 활동 전체를 수행

- 기본적인 V모델에서 신뢰성을 높이기 위해 다양한 V-모델의 반복을 통해서 다양한 유형의 테스팅 기법을 이용

* 모델 - PC를 통해 요구된 시스템의 행위를 모의 테스트

* 프로토타입 - 모델로부터 소스 코드를 생성하고 실험용 하드웨어에 소스코드를 이식

* 최종제품 - 실제 하드웨어에 소스 코드 이식

나. Embedded 시스템 소프트웨어 테스트 기법

다. 임베디드 시스템 하드웨어 테스트 기법

• 소프트웨어의 의존도 증가로 기법 자체가 소프트웨어 테스팅으로 융합되어 발전 진화함

기출문제

Ⅰ. 테스터의 지적 능력을 극대화 및 Agile 방법론 대응을 위한 경험기반 테스팅의 개요

- 테스터의 과거 유사 시스템 개발 및 기술 경험을 기반으로 직감적으로 테스트하는 기법

Ⅱ. 경험기반 테스팅의 주요 기법

- 경험기반 테스팅 기법 중 대표적으로 탐색적 테스팅 기법이 많이 활용되고 있음

[참고] 리스트 기반 테스팅

I. 효과적인 경험기반 테스팅 수행 전략

가. 리스크 기반 전략과 연계한 경험기반 테스팅 수행

- 경험기반 테스팅은 테스트 대상에 비해서 테스트 자원이 부족한 경우, 우선순위를 나눠서 테스트 자원을 효율적으로 분배하기 위한 테스트 전략이 필요 시 많이 활용되며, 리스크 기반 전략과 연계해 테스팅을 수행

- STA(Severs Test Area): 반드시 테스트 - STTA(Strong Test Area): 테스트 - ITA(Intensive Test Area): 테스트 - FTA(Fundamental Test Area): 테스트하지 않을 수 있음

- 장애발생가능성, 장애로 인한 영향도를 판단하여 해당 영역별로 테스팅 수행 전략 마련

나. 리스크 기반과 연계한 경험기반 테스팅 수행 전략

- 해당 분야의 경험이 많고, 도메인 지식이 높으며, 고객의 요구사항을 정확히 파악하고 있을 시 효과적  

[참고] 탐색적 테스팅과 경험기반 테스팅의 비교

기출문제

Ⅰ. 프로그램 내부 로직 분석을 통한 테스트 기법, 구조기반 테스트의 개요

1. 구조기반 테스트(Structure-based Test)의 정의

- 테스트 프로그램 내부 구조를 기반으로 특정 커버리지(Coverage)를 달성하기 위한 테스트 설계 및

케이스를 도출하기 위한 테스트 기법

나. 구조기반 테스트의 특징

II. 구조기반 테스트의 개념도 및 기법

가. 구조기반 테스트의 개념도

- 내부 구조 및 복잡도를 검증하고 테스트하기 위한 White Box Test

나. 구조기반 테스트의 기법

III. 구조기반 테스트와 명세기반 테스트의 비교

구분	구조기반 테스트	명세기반 테스트
개념도
정의	프로그램 내부 로직을 참조하며 모든 경로를 테스트	외부 명세로부터 직접 테스트 Data, I/O 위주 테스트
특징	- 구조테스트 - Logic Driven 테스트 - 모듈 테스트	- 기능테스트 - Data Driven 테스트 - I/O 테스트
적용	단위테스트 위주	대부분의 테스트에 적용
V&V	하위 레벨 테스트 (시험 환경)	상위 레벨 테스트 (사용자 환경)
점검대상	Loop, Decision 결함, 비수행 구문	시작/종료/인터페이스 결함
기법	Loop, 제어구조 테스트	동등 분할, 경계 값 분석, Cause Effect 그래프, 오류 예측 기법
활용분야	알파 테스트	베타 테스트

IV. 테스트 커버리지 관계도 및 유형

가. 테스트 커버리지 관계도

- 구문, 결정, 조건, 조건/결정, 변경 조건/결정, 다중 조건 커버리지 관계도 설명

나. 테스트 커버리지 유형

테스트 유형	설명	사례
구문 커버리지 (Statement Coverage)	- 프로그램을 구성하는 모든 구문들이 최소한 한번은 실행될 수 있는 입력 데이터를 데스트 데이터로 선정 - 프로그램 내 모든 구문의 테스트를 보장	- 소스코드 If(a>0 or b>0) call join - 테스트케이스 a = 3, b = 4
결정 커버리지 (Decision Coverage)	- 프로그램 내의 전체 결정문이 적어도 한번은 참과 거짓의 결과를 수행하는 테스트 케이스 생성 - 모든 분기문을 테스트 하는 방법
조건 커버리지 (Condition Coverage)	- 결정 명령문 내의 각 조건이 적어도 한 번은 참과 거짓의 결과가 되도록 수행하는 테스트 케이스 - 모든 조건을 커버하는 방법
조건/결정 커버리지 (Condition/Decision Coverage)	- 전체 조건식 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되도록 수행하는 테스트 케이스
변경조건/결정 커버리지 (MC/DC)	- 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 하는 테스트 케이스
다중조건/결정 커버리지(Multiple Condition Coverage)	- 결정 포인트 내에 있는 모든 개별식 조건의 모든 조합을 고려한 커버리지

기출문제

I. 시스템 기능에 대한 사용자 입장의 표현, 유스케이스 다이어그램의 개요

  가. 유스케이스 다이어그램(Usecase Diagram)의 정의

   - 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 동적 다이어그램

    - 시스템 분석가가 사용자와 힘을 합쳐 시스템의 사용 방법을 결정하는데 도움을 주는 도구

 나. 유스케이스 다이어그램의 특징

II. 유스케이스 다이어그램의 구성요소와 표현

가. 유스케이스 다이어그램의 구성요소

분류	구분	설명	표기법
기본 구성	Usecase	- 시스템이 제공해야 하는 서비스. - Actor가 시스템을 통한 일련의 행위
	Actor (행위자)	- 사용자가 시스템에 대해 수행하는 역할(role) - 시스템과 상호작용하는 사람 또는 사물
	시스템 (System)	- 전체시스템의 영역을 표현 - 특별한 의미를 가지지 못함
관계 표현	연관(Association)	Usecase와 Actor의 관계를 표현 (실선)
	확장(Extend)	기본 Usecase 수행 시 특별한 조건을 만족할 때 수행하는 Usecase
	포함(Include)	- 시스템의 기능이 별도의 기능을 포함 (점선) - Usecase 를 수행할 때 다른 Usecase 가 반드시 수행되는 것
	일반화 (Generalization)	하위 Usecase/Action이 상위 Usecase/Actor에게 기능/역할을 상속 받음
	그룹화 (Grouping)	여러 개의 Usecase를 단순화 하는 방법

나. Use Case의 구성요소간 관계 표현법

관계	설명	표기법
연관 (Association)	Use Case와 Actor의 관계를 표현 (실선)
확장 (Extend)	- Optional behavior. 선택 적인 행동. - extension method의 stereotype 으로 표시.
포함 (Include)	- Mandatory behavior. 필수적인 행동. - extension method의 stereotype 으로 표시.
일반화 (Generalization)	- 하위 Use Case/Action이 상위 Use Case/Actor에게 기능/역할을 상속 받음
그룹화 (Grouping)	- 여러 개의 Use Case를 단순화 하는 방법

III. Use case Diagram 작성 절차와 사례 (레스토랑의 고객, 웨이터, 요리사, 계산대 직원)

1. Use Case 작성 절차

1.  작성 사례

Usecase 명세	Usecase Diagram
1. 웨이터는 고객의 주문을 받는다 2. 웨이터는 주문을 확인한다 (주문상태 포함) 3. 요리사는 주문을 확인한다 4. 웨이터는 음식을 제공한다 5. 계산대 직원은 음식값을 계산 처리한다

기출문제

I. 객체타입을 정의하고 정적인 관계를 표현하는, 클래스 다이어그램의 개요

- 시스템을 구성하는 객체의 타입을 정의하고, 그 타입들 간의 존재하는 관계를 표현하는 정적 다이어그램

- Class, Interface, Collaboration 간의 관계를 나타내며 객체 지향 시스템 모형화에서 가장 공통적으로 많이 쓰이는 다이어그램

II. 클래스 다이어그램의 구성도 및 구성요소

가. 클래스 다이어그램의 구성도

나. 클래스 다이어그램(Class Diagram)의 구성요소

-구성(이름,속성,기능)

-접근제어자

-관계

-연관의 다중성 표현 (선에 아무런 숫자없으면 1:1 관계)

III. 클래스 다이어그램의 관계 표현

관계 유형	설명	표기법
연관관계 (Association Relationship)	- 두 클래스간 서로 어떠한 연관을 가지고 있는 의미 1 : 1개  0..1 : 0개 또는 1개 * : 다수 1..* : 1개 또는 다수
집합연관관계 (Aggregation Relationship)	- 클래스와 클래스간의 부분과 전체의 관계를 의미 - UML 2.0에서는 사용하지 않음
의존관계 (Dependency Relationship)	한 클래스의 변화가 다른 클래스에 영향을 미치는 관계
복합연관관계 (Composition Relationship)	집합연관관계와 같이 부분과 전체 관계이나, 전체클래스 소멸시 부분클래스도 소멸하는 관계
상속관계 (Inheritance)	Class 간 상속관계 (‘is a’ 관계) 객체지향의 상속관계를 의미하고, 일반화(Generation)를 의미한다.
인터페이스	인터페이스와 그 인터페이스를 구현한 클래스 사이의 관계를 의미 (실체화: 하나의 객체가 다른 객체에 의해, 오퍼레이션을 하도록 지정관계)
직접 연관(Direct Association)	Association과 Directed Association의 차이는 화살표가 의미하는 navigability(방향성)인데 이것에 따라 참조 하는 쪽과 참조 당하는 쪽을 구분

연관관계, 의존관계, 일반화(Generalization), 실체화(Realization)

기출문제

I. UML의 관계(Relationship) – ‘연의 GR’ 이라고 암기한다. ★

- UML에는 4개의 관계가 있다. 연관관계, 의존관계, 일반화(Generalization), 실체화(Realization) 이다.

기출문제

I. 객체지향 모델링 기술과 방법론의 표준, UML의 개요 – 그래픽 형태를 통한 객체지향 설계 설명 도구

   가. UML(Unified Modeling Language)의 정의

      - 객체 지향 분석/설계가 S/W공학의 새로운 추세로 자리매김함에 따라 관련된 방법론을 표준화할

         필요성을 느끼고 OMG(Object Management Group – UML, MDA를 제정한 협회)에서 객체

        모델링 기술과 방법론을 표준화 한 것으로 단어자체가 의미하는 언어가 아니고 모델링을

        위한 Notation을 말함 

   나. UML의 등장 배경 및 필요성

      - 객체지향 모델링을 위해 학자들 마다 중복되고 일부 다른 방식으로 표현,

      - 보다 체계적인 모델링 방법을 표준화하기 위해 3명의 학자가 주장하는 표기법의 통일이 필요하게 됨

      - 객체지향 시스템 개발 전 과정(Life Cycle)에서 개발자와 사용자간에 표준화된 의사소통 방식 필요

      - 자기 자신, 팀 동료, 고객들과의 의사소통 – 자신의 이해가 다른 사람과 일치하는지 확인하기 위한

        방법(1994년, 부치, 럼바, 야콥슨 연구시작 -> 1997년 발표)

가. 정적 다이어그램

나. 동적다이어그램

기출문제

I.  MSA(Micro Service Architecture)개요.

 - 하나의 큰 애플리케이션을 여러 개의 작은 마이크로 서비스 단위로 나누어 변경과 조합이 가능하도록 만든 아키텍처

II. 개념도 및 기술요소

 가. 개념도(둘 중 하나 취사선택)

OR

나. 구성요소

- 대용량 웹 서비스 개발에 적합하게 작은 서비스의 결합을 통해 하나의 응용프로그램을 개발하는 SOA를 근간으로 한 서비스 아키텍처

III. 마이크로 서비스 아키텍처와 모놀리식 아키텍처 비교

[추가자료] 마이크로 서비스 아키텍처와 SOA(Service Oriented Architecture) 비교

[참고] 콘웨이(Conway)의 법칙

•1967년 프로그래머 멜빈 콘웨이가 제안한 법칙

•시스템 구조는 설계하는 조직의 커뮤니케이션 구조를 닮게 된다.

•모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다(닮는다는 의미임).

•조직의 구조가 시스템 아키텍처 설계에 영향을 줌