Unit testing을 요구하는 표준과 그렇지 않은 표준


Unit level의 testing을 요구하는 표준이 있고, 그렇지 않은 표준이 있다. 둘간에 별 차이가 없을 거라고 생각할지도 모르겠다. 어차피 사람이 하는 일이고, 사람마다 눈 두 개 달려 있고, 손 두 개 달려있으니, 그게 그거 아니겠는가? 하고 말이다.

Automotive SPICE와 ISO26262의 경우에는 unit level의 testing을 요구하는 반면, DO-178C나 DO-278A에서는 그런 요건이 존재하지 않는다. 다만 요구사항 기반으로 시험을 하라고 요구한다.

재밌는것은 unit level의 testing을 요구하는 자동차쪽 domain에서 test case를 추출하는 기법으로 requirement based testing을 요구하고 있다는 점이다.

요구사항 관점에서 설계를 하거나 구현을 할 때, 두 가지 구현 방식이 있을 수 있다. 하나는 architecture를 설계하고 그 설계에서 component를 설계하고 그 안의 unit을 설계해서 구현하는 방식이 있다. 이 방식은 수직적 방식으로 계층적 구조를 지닌다.

다른 하나는 수평적 방법으로 요구사항에 대한 sub요구사항을 만들어서 그 요구사항에 대한 로직을 설계해서 구현하는 방식이다. 이 방식은 수평적 방식으로 볼 수 있다.

수직적 설계 방식을 적용했을 때, 요구사항에서 architecture로의 trace를 해 보았는가? 해 보았다면 과연 그게 쉬웠는가?

만약 가능하다고 대답하고 싶다면, 그 application의 경우 그럴 수 있다고 생각하고, 일반적인 경우에 대해 가능하냐고 묻고 싶다. In general, is it possible ?

이는 불가능하다고 생각한다.

그런 방식에서는 요구사항에 대한 추적이 쉽지 않다.

예를 들어서 사람의 인체로 설명을 해보자.

사람을 물리적으로 나눈다면 5장 6부가 있다. (곤충을 머리, 가슴, 배로 나누듯이) 그런데 인간의 걷는 기능과 관련된 인체 내의 part와의 관계(추적성)는 어떻게 맺을 수 있을까? 인간의 먹거나 자는 기능과 관련된 추적성은 어떻게 맺을 수 있을까?

연관이 없는게 없다고 하기도 뭣하고, 하나만 연관짓기도 뭣하고…참으로 거시기 할 것이다.

일반적으로 인체의 5장 6부로 구조화 한것은 인간이 수행할 수 있는 여러가지 기능(or activity)별로 쪼갠것이 아니다. 일반적으로 system level의 function은 sub-system(5장 6부)의 유기적인 interaction과 process에 의해 달성되기 때문이다.

sub-system(5장 6부)의 기능은 system level의 function에 1:1로 매핑되지 않는것과 같이, 그리고 그러한 방식으로 architect 되지 않았듯이, 일반적으로 sw설계에서도 그러하다.

다른 방식으로 다시 설명을 해보자면, software architecture로 넘어와서 crosscutting block의 경우 requirement기반의 기능과 mapping시킨다고 할 때, 혹은 middleware level을 설계했을때, 이를 requirement와 mapping시킨다고 했을때, 그게 쉬운가?

진짜로 쉬운가? 진심으로? 정말로? 혼또니 ?

그럴리 없다.

정말 어려운 일이다.

 

결론이다. unit level testing은 최상위 요구사항에 대해 mapping하는 것은 매우매우 어렵다.
unit level testing을 하려면 sw architecture를 설계해야 한다.하지만 모든 sw가 architecture를 필요로 하는 것은 아니라고 생각한다. architecture를 설계할때의 장단점이 있을 뿐, 그게 없다고 sw가 안되거나 하진 않는다. ISO26262의 sw개발 concept과 DO-178C의 sw 개발 concept이 같다고 생각하겠지만, 실상은 그렇지 않다. (비슷해 보일 수는 있을지라도 같은 것은 아님)

나는 개인적으로 DO-178C쪽의 표준이 더 잘 정의되었고, best practice로서 적용하기도 좋다고 생각한다.

그렇다고 자동차쪽 sw개발 방식을 비판했다거나 뭐 그런것도 아니다.

어떤 approach건 pros와 cons는 존재하기 마련이다.

그리고 그러한 방식이 잘 맞는 application이 있기 마련이다.

세상에 silver bullet이란 건 없다.

만약 존재한다면 그것은 매우 가격이 높아서 공학적으로 가치가 없을 것이다.
(그런 의미에서 효용성이 없어서 silver bullet이 없다는 의미도 된다.)

 

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중