테스트 드라이버와 테스트 스텁의 개념 이해 (테스트 하네스에 포함)

 

 

출처 : [네이버 지식백과] 단위 테스트 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))

출처 : [네이버 지식백과] 통합 테스트 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))

 

 

 

단위 테스트

 

단위 테스트(unit test)는 프로그램의 기본 단위인 모듈을 테스트하여 모듈 테스트(module test)라고도 한다. 구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 명세서의 내용대로 정확히 구현되었는지를 테스트한다. 즉 개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트한다. 화이트박스 테스트와 블랙박스 테스트를 모두 사용할 수 있지만 모듈 내부의 구조를 구체적으로 들여다볼 수 있는 화이트박스 테스트 같은 구조적 테스트를 주로 시행한다.

단위 테스트가 개발된 모듈만 테스트하기 때문에 쉬울 것 같지만, 시스템은 수많은 모듈이 서로 정보를 주고받으며 연결되어 있다. 즉 테스트할 모듈을 호출하는 모듈도 있고, 테스트할 모듈이 호출하는 모듈도 있다. 따라서 한 모듈을 테스트하려면 그 모듈과 직접 관련된 상위 모듈과 하위 모듈까지 모두 존재해야 정확히 테스트할 수 있다.

그러나 하나의 모듈을 테스트할 때 상위나 하위 모듈이 개발이 안 된 경우도 있다. 이때 상위나 하위 모듈이 개발될 때까지 기다릴 수는 없으므로 가상의 상위나 하위 모듈을 만들어 사용해야 한다. 상위 모듈의 역할을 하는 가상의 모듈을 테스트 드라이버(test driver)라 하고 그 역할은 테스트할 모듈을 호출하는 것이다. 즉 필요한 데이터를 인자를 통하여 넘겨주고, 테스트가 완료된 후 그 결과 값을 받는 역할을 해준다.

반대로 하위 모듈의 역할을 하는 모듈을 테스트 스텁(stub)이라고 한다. 스텁 모듈은 테스트할 모듈이 호출할 때 인자를 통해 받은 값을 가지고 수행한 후 그 결과를 테스트할 모듈에 넘겨주는 역할을 한다. 따라서 드라이버와 스텁 모듈은 테스트할 때 필요한 기능만 제공할 있도록 단순히 구현한다.

[그림 8-23]은 드라이브와 스텁 모듈이 테스트 대상과 맺는 관계를 보여준다.

그림 8-23 드라이버/스텁 모듈과 테스트 대상 모듈의 관계

그림 8-23 드라이버/스텁 모듈과 테스트 대상 모듈의 관계

단위 테스트를 수행하면 다음과 같은 오류를 발견할 수 있다.

• 잘못 사용한 자료형
• 잘못된 논리 연산자
• 알고리즘 오류에 따른 원치 않는 결과
• 틀린 계산 수식에 의한 잘못된 결과
• 탈출구가 없는 반복문의 사용

 

 

 

 

 

 

 

통합 테스트

 

단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트가 통합 테스트(integrationtest)이다. 실제 업무에서는 단위 모듈이 개별적으로 존재하는 것이 아니고 여러 모듈이 유기적 관계를 맺고 있으므로 이러한 모듈들을 결합한 형태로 테스트를 수행해봐야 한다. 이때 주로 확인하는 것은 '모듈 간의 상호작용이 정상적으로 수행되는가'이다. 즉 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지를 체크한다.

개별 모듈을 테스트하는 단위 테스트에서는 오류가 발견되지 않았어도, 모듈을 통합하면 상호 간의 인자나 공유 데이터 구조 등에서 오류가 발생할 수 있다. 또 단위 테스트 시 가상의 드라이버와 스텁 모듈을 만들어 테스트를 잘 수행했더라도, 상당히 제한적인 여건에서 테스트를 수행한 것이다. 그러므로 실제 모듈 통합 시에는 다른 결과가 나올 수도 있다. 실제 개발에서는 모듈 간의 상호작용과 인터페이스에서 많은 오류가 발생하는 것을 볼 수 있다. 그러므로 통합 테스트가 필요한데, 그 방법에는 모듈 통합을 한꺼번에 하는 방법과 점진적으로 하는 방법이 있다.

모듈 통합을 한꺼번에 하는 방법으로는 빅뱅(big-bang) 테스트를 들 수 있다. 빅뱅 테스트는 단위 테스트가 끝난 모듈을 한꺼번에 결합하여 수행하는 방식이다. 이 방법은 소규모 프로그램이나 프로그램의 일부를 대상으로 하는 경우가 많고 그만큼 절차가 간단하고 쉽다. 그러나 한꺼번에 통합하면 오류가 발생했을 때 어떤 모듈에서 오류가 존재하고 또 그 원인이 무엇인지 찾기가 매우 어렵다.

모듈 통합을 점진적으로 하는 방법은 모듈 통합을 한꺼번에 하는 방법의 문제를 극복하는 방법으로, 완성된 모듈을 기존에 테스트된 모듈과 하나씩 통합하면서 테스트한다. 문제가 발생하면 바로 직전에 통합하여 테스트한 모듈에서 오류가 발생했다고 짐작할 수 있으므로 오류를 찾기가 쉽다. 점진적 통합 방식은 가장 상위에 있는 모듈부터 테스트하는지, 가장 하위에 있는 모듈부터 테스트하는지에 따라 하향식 기법과 상향식 기법으로 나뉜다.

1. 점진적 모듈 통합 방법 : 하향식 기법

하향식(top-down) 기법은 시스템을 구성하는 모듈의 계층 구조에서 맨 상위의 모듈부터 시작하여 점차 하위 모듈 방향으로 통합하는 방법이다.

[그림 8-24]의 예에서 맨 상위 모듈 A를 모듈 B와 통합하여 테스트한다. 그다음으로 모듈 C를 먼저 선택할지, 아니면 B 아래에 있는 모듈 E를 먼저 선택할지 결정해야 한다. 이때 모듈 C를 먼저 선택하는 방식을 넓이 우선(breadth first) 방식이라 하고 모듈 E를 먼저 선택하는 방식을 깊이 우선(depth first) 방식이라 한다.

넓이 우선 방식으로 테스트하면 (A, B)→(A, C)→(A, D)→(A, B, E)→(A, B, F)→(A, C, G)와 같이 같은 행에서는 옆으로 가며 통합 테스트를 한다. 반면, 깊이 우선 방식에 따라 테스트하면 (A, B)→(A, B, E)→(A, B, F)→(A, C)→(A, C, G)→(A, D) 순으로 통합하며 테스트한다. 즉 하위 방향으로 내려가면서 통합하지만, 같은 행에서는 옆이 우선이 아니라 그 아래 모듈을 먼저 통합하여 테스트한다. 또한 하향식 방식에서는 상위 모듈부터 테스트를 수행하기 때문에 단위 테스트에서 설명한 스텁 모듈이 필요하다.

그림 8-24 점진적 모듈 통합 방법을 설명하기 위한 모듈 구성도

그림 8-24 점진적 모듈 통합 방법을 설명하기 위한 모듈 구성도

일반적으로 모듈의 종속 관계에서 상위 모듈은 시스템 전체의 흐름을 관장하고, 하위 모듈은 각 기능을 구현하는 형태로 구성되어 있다. 그러므로 하향식 기법을 이용하면 프로그램 전체에 영향을 줄 수 있는 오류를 일찍 발견하기가 쉽다. 그러나 하위 모듈이 임시로 만든 스텁들로 대체되어 결과가 완전하지 않을 수도 있고 스텁 수가 많으면 스텁을 만드는 데 시간과 노력이 많이 들 수 있다. 따라서 모듈 간의 인터페이스와 시스템의 동작이 정상적으로 잘되고 있는지를 빨리 파악하고자 할 때 하향식 기법을 사용하는 것이 좋다.

2. 점진적 모듈 통합 방법 : 상향식 기법

상향식(bottom-up) 기법은 하향식 기법과는 반대로 가장 말단에 있는 최하위 모듈부터 테스트를 시작한다. 하향식에서 스텁이 필요했다면, 상향식에서는 상위 모듈의 역할을 하는 테스트 드라이버가 필요하다. 이 드라이버는 하위 모듈을 순서에 맞게 호출하고, 호출할 때 필요한 매개 변수를 제공하며, 반환 값을 전달하는 역할을 한다.

[그림 8-24]에서 상향식 기법을 이용하여 테스트하는 순서는 다음과 같다. 우선 가장 말단(레벨 3)에 있는 모듈 E와 F를 모듈 B에 통합하여 테스트한다. 그다음 모듈 G를 모듈 C에 통합하여 테스트한다. 마지막으로 모듈 B, C, D를 모듈 A에 통합하여 테스트한다.

상향식 기법의 장점은 최하위 모듈들을 개별적으로 병행하여 테스트할 수 있기 때문에 하위에 있는 모듈들을 충분히 테스트할 수 있다는 것이다. 또한 정밀한 계산이나 데이터 처리가 요구되는 시스템 같은 경우에 사용하면 좋다. 그러나 상위 모듈에 오류가 발견되면 그 모듈과 관련된 하위의 모듈을 다시 테스트해야 하는 번거로움이 생길 수 있다.

 

 

 

 

 

 

'ITPE > SE' 카테고리의 다른 글

소프트웨어 테스팅 국제표준 - ISO 29119  (0) 2021.02.19
CMMI  (0) 2018.04.12
TOC-Thinking Process  (0) 2018.04.06

 

 

 

 

 

 

퍼온글
 
 
 
 

ITWorld 용어풀이 | 인터클라우드

박재곤 기자 | ITWorld
인터클라우드(Intercloud)는 ‘클라우드의 클라우드’란 뜻입니다. ‘네트워크의 네트워크’가 인터넷인 것과 같은 맥락으로 만들어진 용어입니다. 와이어드 편집자 케빈 켈리가 2007년 클라우드 컴퓨팅을 설명하며 처음 사용했고, 이후 업계에서 보편적으로 사용되고 있습니다.

그럼 ‘클라우드의 클라우드’란 어떤 의미일까요? 클라우드 서비스는 ‘구름 속에 있는 컴퓨팅 자원’의 실체에 관계없이 필요한 만큼 가져다 사용하고 사용한만큼 비용을 지불하는 것을 기본 개념으로 합니다. 

하지만 단일 클라우드 서비스의 실제 물리 자원은 무한하지 않으며, 지역적으로 모든 곳에 서비스를 제공할 수 있는 것도 아닙니다. 만약 수요가 포화 상태에 이른 클라우드 서비스가 새로운 고객의 요청을 받는다면, 혹은 자사가 서비스할 수 없는 지역으로부터 요청을 받는다면 어떻게 해야 할까요? 이때 다른 클라우드 서비스의 인프라에서 필요한 자원을 가져다 서비스하는 것으로 이런 문제를 해결한다는 것이 인터클라우드의 핵심 개념입니다.

물론 실제로 이런 일이 가능하기 위해서는 클라우드 간의 상호호환성이 있어야 하며, 클라우드 간의 인터페이스, 네트워크 프로토콜 표준화 등의 작업이 필요합니다. 그리고 IEEE는 2010년 7월 클라우드 컴퓨팅 상호호환성과 서비스에 대한 국제 워크샵을 시작으로 관련 연구를 계속해 오고 있습니다.
 
 
이런 기술적인 노력과는 달리 시장에서 인터클라우드가 관심을 모으기 시작한 것은 2013년 말, 시스코가 처음으로 인터클라우드 관련 제품을 발표하면서부터입니다. 인터클라우드가 결국 클라우드가 어느 정도 확산된 단계에서나 구현할 수 있는 개념이라는 점에서 당연한 수순이기도 합니다. 시스코는 2014년부터 클라우드 사업 확대에 10억 달러를 투자하겠다고 발표하며 자사의 인터클라우드 전략을 본격적으로 내세우기 시작했습니다.

인터클라우드는 아직 실제로 구현된 모습이 나타나지 않았으며, 기술적으로도 보안이나 QoS, 지불결제, 상호 신뢰, 거버넌스, 법적 책임 문제 등 많은 해결과제를 안고 있는 상황입니다. 하지만 클라우드의 발전 방향 중 하나라는 것만은 확실한 것으로 평가되고 있습니다.

한편 인터클라우드와 연관성이 있는 개념으로는 하이브리드 클라우드(Hybrid Cloud), 멀티클라우드(Multi-Cloud), 메타클라우드(Meta-Cloud) 등을 들 수 있습니다.

하이브리드 클라우드는 퍼블릭 클라우드와 프라이빗 클라우드를 연동해 함께 사용할 수 있는 환경을 말하는 것으로, 다양한 배치 형식의 클라우드를 하나로 이용하는 것이 핵심입니다. 사실 시스코의 인터클라우드 전략도 파트너 생태계가 완성되기 전에는 하이브리드 클라우드 단계라고 볼 수 있죠.

멀티클라우드는 단일 기업이 여러 클라우드 서비스를 하나의 환경에서 동시에 사용하는 것을 말하는 것으로, 보안이나 거버넌스 등의 복잡한 문제를 사용 기업이 해결하는 방식입니다. 메타클라우드는 시스코가 인터클라우드 전략을 위해 인수한 업체 이름이기도 하며, 여러 클라우드 인프라를 엮어서 메타 서비스를 프로비저닝할 수 있도록 해 주는 것을 말합니다. 멀티클라우드의 서비스 업체 버전이라고 할 수 있습니다.  editor@itworld.co.kr



원문보기: 
http://www.itworld.co.kr/tags/63516/%EC%9D%B8%ED%84%B0%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C/91416#csidx6999ff0023f1c17ad9c81aa3d204c51 

 

 

 

 

 

 

 

'ITPE > DS' 카테고리의 다른 글

패브릭 컴퓨팅  (0) 2018.06.24

 

 

 

AUTOSAR 공부중 검색한 글로,

 

원본글 : http://cafe.naver.com/powworld/7055

 

문제시 삭제

 

 

프랑스와 독일 자동차 ecu표준 방식은 iso인증한
OSEK/VXD 이방식이 쓰이며 표준입니다

 

프로그램 구조도 입니다

 

oo

 

 


- Application Layer : 우리하 흔히 알고 있는 OSI 7 Layer에서 Application Layer와 거의 동일하다고 보면 됩니다


- Interaction Layer : 소프트웨어 구조 설계시 정의 된 메시지 전송 형태의 핸들링을 처리하는 기능의 Layer이다. 또 데이터 교환에 관한 API를 제공하고 각종 기본 값들을 설정 할 수 있습니다


- Diganostic Layer : 자동차에 내장 된 각종 진단 기능에 대해 인터페이스를 제공하는 Layer 이다. 또 예외처리(Busy 등)를 담당하고 있으며 CAN과 관련한 진단사항 요구를 처리합니다


- Transport Protocol : 대용량(기본 전송 데이터는 8byte인데 이보다 더 큰) 데이터를 보내기 위한 고안된 Protocol이다. 네트워크의 7Layer 중 Transport Layer처럼 데이터 분할 기능도 있다. 또 동기화 기능과 에러감지 기능도 가지고 있습니다


- Network Management : 주된 목적은 자동차의 전원 사용 효율성이다. 각 상태(Network Wakeup, Network Active, Network Slepp)에 따라 전원 사용량을 달리 하는 기능을 가지고 있습니다


- CAN Calibratoin Protocol : ECU의 Flash ROM에 다양한 데이터 접근 방식으로 읽기와 쓰기를 담당하는 프로토콜입니다



 

회로 이해도 입니다

ecu코딩이나 맵핑에 필요한 프로그램은 시중에
많이 나와 있습니다 대표적으로 win ols라든지요

 

 

'ITPE > CA_OS' 카테고리의 다른 글

Cache Clean, Flush  (0) 2021.04.28
MESI protocol  (0) 2021.04.28
CPU 명령어 사이클  (0) 2021.04.27
CPU 구성  (0) 2021.04.24
개요  (0) 2021.04.24

+ Recent posts