아키텍처, 테스팅 개요

아키텍처 

소프트웨어를 설계하는 틀 

목적에 맞게 선택한다.

 

layered architecture 

동일한 인터페이스를 제공한다면 다르게 구현하여도 상호 대체 가능 

presentation layer, business logic layer, data access layer

 

pipe & filter 

filter는 데이터 변환기의 역할 

파이프는 데이터 전달 

필터는 병렬적으로 수행되며 파이프를 통해 동기화 

 

블랙보드 

해결책이 명확하지 않은 음성인식, 차량번판인식, 자율주행과 같은 도메인에 사용

Controller, Knowledge source, blackboard로 구성

 

Controller는 Blackboard의 정보를 가지고 Knowledge Source를 스케줄링한다.

Knowledge Source는 문제를 해결하고 해당 내용을 Blackboard에 반영한다.

 

컴포넌트끼리 소통을 하지 않기 때문에 쉽게 추가 가능 

자료 저장소와 컴포넌트들의 결합도가 강하여 자료 저장소가 변하면 컴포넌트들이 변해야 함

 

MVC 

model, view, controller

model 컴포넌트는 핵심이 되는 데이터, 기능 제공

view는 사용자에게 보여지는 인터페이스 

controller는 사용자의 요청에 따라 모델 생성 및 사용자에게 보여 줄 뷰 선정

 

Contoller가 요청을 받고 

Model한테 필요한 데이터를 요구 

Model한테 데이터를 받고 

View한테 데이터를 전달 

View는 데이터에 맞는 뷰 선정하여 

사용자에게 보여줌

 

Microservice architecture

프로젝트의 기능들을 작고 독립이며 느슨하게 분해 

 

monolithic architecture 

너무 커서 비효율 

 

EDA

중간에 broker: Publisher와 Subscriber 중간 역할 

비동기 통신 지원 

 

Hexagonal architecture

DIP(Dependency inversion Principle) 설계원칙을 원칙으로 만듦

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

잔존 위험(residual risk)

 

테스트 대상이 되는 프로그램: Test Item

테스트 케이스의 구성요소: 식별자, 목적, 우선순위, 추적성, 사전조건, 입력, 기대출력, 실제 결과 

 

Test Oracle : 생성 기능, 평가 기능 

 

Error 개발자가 요구사항을 잘못 이해, 문법을 잘못 이해 발생 

fault error로 인한 결함(정적) 

failer 실행결과와 기대 결과가 다름(동적),

fault가 있다고 해서 항상 오작동 x 따라서 테스트 케이스 집합을 잘 만들어야한다.

 

Exhaustive Test (완전한 테스트)

테스트 하는데 시간이 너무 오래 걸림 

 

테스트 커버리지: 얼마나 테스트가 되었는지?

테스트 커버리지 아이템: 테스트 케이스에 의해 포함될 필요가 있는 명세, 프로그램 항목 

 

커버리지: 실행된 테스트 커버리지 아이템/ 총 테스트 커버리지 아이템 개수 

 

명세기반 테스팅: 의도하는 대로 프로그램이 실행되는지?

 

구조기반 테스팅 : 의도한 기능이 올바르게 구현되었는지??

코드로부터 테스트 케이스를 만들지만 

기대 출력은 명세에 의존한다.

 

누락된 요구사항 검출(missing requirements)

누락된 테스트 검출(missing tests)

Dead code 검출: 어떠한 경우에도 실행이 안되는 코드 -> 제거 

활성화 되지 않은 코드(Deactivated code): 현 시스템에서는 사용되지 않으나 나중에 사용될 수 있는 코드

 

경험 기반 테스팅 

error guessing(오류 추정)

독단적으로 사용되지 않고 다른 테스팅 방법을 보완하는 식으로 사용