Blog
yagur.impon.net/#blog
Tumblr
yagur.tumblr.com
Live Photo
photo.live.com/…
Dopplr
dopplr.com/traveller/yagur
YouTube
youtube.com/TheYagur
Last.fm
last.fm/user/yagurchoi
Diigo
diigo.com/yagur
Ember
emberapp.com/yagur
Twitter
twitter.com/YagurChoi
Readernaut
yagur.userstorybook.net/
'Metric'에 해당되는 글 2건
- 2008/09/30 테스트와 장인 - 10
- 2008/07/12 테스트와 장인 - 9
테스트와 장인 - 10
작성자 : yagur rev : 2
GPS로 위치를 정확히 알수만 있다면, 하지만 현실은 추정으로 이루어진 지도와 육분의뿐이다.
테스트 항해(Test Nevigation)
먼 곳으로 항해하는 배가 풍파를 만나지 않고 조용히만 갈 수 는 없다. 풍파는 언제나 전진하는 자의 벗이다.
- 니체
항해의 주 목표는 목표 지점에 정확히 안전하게 가는 것이지만, 좋은 위치 측량없이는 힘들다. '명세에 맞는 결함이 적은 코드 생산'을 목표 지점으로하는 항해를 하기 위해선 위치 측정이 중요하다. 육분의는 현재 위치를 측정할수 있는 좋은 도구이다.
프로그램을 작성하면서 코드의 결함도를 측정하는 행위는 단위테스트이다. 이는 프로그램이 시간의 흐름에 따라 점진적으로 크기가 커질때 그 신뢰도(완성도)가 어느 위치에 있는지 알려주기때문에, 항해의 육분의와 유사하다. 항해에 GPS가 마련되있으니 육분의 사용이 필요 없는 팀이나 개인은 손으로 꼽을수 있을것이라 생각한다. 대부분은 덜 명확한 지도(명세, 달성 목표, 설계)를 보고 목표를 향해 항해할것이다.
GPS를 사용할수 없어서, 육분의로 항해하는 배는 삼각측량법을 사용한다. 이를 위해 항해사는 세개의 육분의를 사용한다. 그 이유는 육분의의 오차때문이다. 측정오차는 0.5′(분; 1°= 60")정도라고 한다. 짧은 거리(작은 소프트웨어)를 항해할때는 하나의 육분의로도 목표에 근접할수 있겠지만, 먼 거리를 항해할때 오차는 목표로부터 꾀 먼거리에 도달하게 만든다. 측정 반복 과정이 짧다고 가정했을때, 최악의 경우는 측정 반복 횟수와 시간의 증가에 따라 오차 최대치가 누적될것이다.
하나의 육분의로 측정할때, 그리고 두개로 측정할때는 다르다. 두개로 측정할때는 두 결과물을 놓고 비교하기 때문에, 좀더 정확한 위치에 가까워지거나, 어느 육분의에 오류가 있는지 알아낼 확률이 높아진다. 세개가 있을때는 말할것 없이 두개보다 측정값이 더 정확해질 확률이 높다.
테스팅의 세계로 돌아와 보자. 한개의 검증이 존재하는 단위테스트를 패스한 테스트 대상이 오동작활 확률을 50%로 가정한다면, 두개가 존재할때는 25%, 세개가 존재할때는 12.5%가 될것이다. 물론 코드 테스팅은 논리의 구현를 검증하는 행위이기 때문에 물리적인 측량과는 다르다.
아래는 절대값을 구하는 작위적인 테스트이다.
int abs(int i)
{
return -i;
}
}
TEST(abs)
{
FAIL_IF(abs(-1) != 1);
}
}
단위 테스트안에 하나의 검증이 존재할때의 상황이다. abs(1)이 들어간다면 어떠할까. 테스트를 통과해 신뢰성이 높아졌다고 생각했던 abs가 당신을 배신했다.
int abs(int i)
{
return -i;
}
}
TEST(abs)
{
FAIL_IF(abs(-1) != 1);
FAIL_IF(abs(1) != 1);
}
}
이제 빨간막대를 볼수 있다.
int abs(int i)
{
if(i < 0)
return -i;
return i;
}
}
이것이 녹색막대를 보여주는 절대값 함수이다. CC(CyclomaticComplexity)는 2이다. CC가 증가함에 따라 오류를 낮추기 위해 검증 횟수 역시 증가된것을 볼수있다. 위의 예는 반대 순서로 흘렀지만, 다른 길이가 길어진 프로시저들의 CC가 증가하면 그것을 검증하는 비용을 역시 증가한다.
Carnegie Mellon의 CC표.(Edmond VanDoren, Kaman Sciences, Colorado Springs)
| Cyclomatic Complexity | Risk Evaluation |
| 1 - 10 | a simple program, without much risk |
| 11 - 20 | more complex, moderate risk |
| 21- 50 | complex, high risk program |
| > 50 | untestable program (very high risk) |
오차 확률이 누적되 항로가 많이 달라졌더라도, 적당한수의 육분의가 있다면 항로를 원래 항로로 맞출 확률은 더 높아진다. 그렇다고 모든 경우에 삼각측량법을 사용하란것은 아니다. 하지만 무의식중에 자주쓰고있는 방법임은 분명하다.
하지만 우연적인 방법에서 한단계 올라가자면 의도적으로 삼각측량법을 쓰는것이다. 테스트를 우연에 맞기겠는가? 아니면 의도적으로 오류검출 확률을 높히겠는가? 테스트는 부시기 위한 테스트인가? 아니면 통과하기 위한 테스트인가? 의도적으로 방법을 쓰지 않았다면 이 질문에 대해 생각해보는것이 시간낭비가 되진 않을것이다.
개발자 테스트는 "깨끗한 테스트"가 되기 쉽다. - Boris Beizer 1994
하지만 우연적인 방법에서 한단계 올라가자면 의도적으로 삼각측량법을 쓰는것이다. 테스트를 우연에 맞기겠는가? 아니면 의도적으로 오류검출 확률을 높히겠는가? 테스트는 부시기 위한 테스트인가? 아니면 통과하기 위한 테스트인가? 의도적으로 방법을 쓰지 않았다면 이 질문에 대해 생각해보는것이 시간낭비가 되진 않을것이다.
나는 어떤 계산을 어떻게 해야 올바르게 추상화할 것인지에 대해 정말 감잡기 어려울 때만 삼각측량을 사용한다.
- Kent Beck(테스트 주도 개발중)
나의 경우엔 처음 테스팅을 시작할때, 명백해 보이는 것들도 빨간막대를 보이는 경우가 많았다. 삼각측량법으로 접근하고, 추상화되거나 의미 없는 테스트가 되었을땐 삼각측량법으로 인해 증가한 검증들을 과감히 삭제해도 좋다. 하지만 저들이 검증에 도움이 되보이는 경우가 많다 생각하여, 보통의 경우 삭제하지 않는다. 그 명백함을 지니는것으로 보이는 함수의 구현이 변경될때를 대비해서이다. 모든 테스트가 수식으로만 이루어진 함수를 대상으로 하지 않는다는 것을 생각해보면 된다.
목표에 좀더 정확히 다가가기 위해서는, 현재 위치가 중요하다. 풍랑과 같은 예측 불가한 위험은 항로를 이탈하게 만든다. 작은 검증 추가(삼각측량법)가 예측 불가한 위험으로부터 항해를 지켜줄것이다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 10 (0) | 2008/09/30 |
|---|---|
| 테스트와 장인 - 9 (0) | 2008/07/12 |
| 객체 지향 소프트웨어 일주 - 5 (0) | 2008/05/18 |
| 객체 지향 소프트웨어 일주 - 4 (0) | 2008/05/08 |
| 객체 지향 소프트웨어 일주 - 3 (0) | 2008/03/28 |
| 테스트와 장인 - 8 (0) | 2008/03/19 |
테스트와 장인 - 9
작성자: yagur Rev : 1
테스트 측정(Test Measurements)
나는 어림짐작은 안 한다네. 그건 논리적인 사고력을 파괴하는 끔찍한 습관이지
- 셜록 홈즈(아서 코난 도일)
테스트는 제품의 품질을 개선하거나 일부 항목을 검증하는 행위이다. Steve McConnell은 소프트웨어의 경우 외적으론 정확성correctness, 유용성usability, 효율성efficiency, 신뢰성reliability, 무결성integrity, 적응성adaptability, 정밀성accuracy, 견고성robustness에 영향을 미치며 내적으로는 유지 보수성maintainability, 유연성flexibility, 이식성portability, 재사용성reusability, 가독성readability등에 영향을 미친다고 한다. 아쉽게도 이 모든 사항이 어떤 측정 단위로 눈에 보여지는것은 아니다.
실세계의 제품은 테스트시 누구나 납득할만한 측정 단위로 테스트의 결과가 표현되며, 제품의 성능을 홍보할때도 많이 활용된다. 예를 들면 Bugatti Veyron은 세계에서 가장 빠른차라고 그들의 차를 홍보하며 제로백을 2.8초 최대속도 407km라고 소개한다.
위의 동영상은 부가티 베이론을 독일에 위치한 60마일 정도 되는 테스팅 트랙에서 테스트한 결과이다. 속도 변화를 보여주는데 그들은 km/h 단위로 측정하고 있다. 그들은 차량을 테스트 하며 목표 속도나 시간을 단위로 해 시스템 테스트를 진행하고 개선해 나갈것이다.
컴퓨터 부품인 Nvidia사의 GForce 9600 GT도 아래와 같은 성능을 내걸고 홍보한다.
Memory Bandwidth (GB/sec) 57.6
Texture Fill Rate (billion/sec) 20.8
Texture Fill Rate (billion/sec) 20.8
하드웨어의 경우 동력 대비 성능과 같은 효율성 측정이 있다. 예를 들자면 인텔 CPU는 풀 로드와 대기 상태의 전력소비량을 내세워 광고하고있다. 소프트웨어라면 어떠할까? 메모리 사용량과 실행 시간 같은 요소을 명세에 맞춰 효율성을 측정할수 있다. 하지만 이들은 물리적 효율성을 측정한것이다. 구조적 효율성의 변화를 테스트를 통해 개선해 나간다면 다른 단위가 필요하다. 이에 관해 Robert C. Martin은 몇가지 측량법metric을 소개한다.
1. 클래스의 숫자와 인터페이스의 숫자
추상 객체, 구체적 객체, 인터페이스의 숫자는 확장성의 지표가 될수 있다.
2. 결합도의 수입성數入性 - Ca 다른 클래스(측정 대상외의것)가 측정 대상의 클래스에 얼마나 의존하는가를 수치로 나타낸것은, 측정 대상의 책임성의 지표가 될수 있다.
3. 결합도의 수출성輸出性 - Ce 측정 대상의 클래스가 다른 클래스(측정 대상 외의 것)에 얼마나 의존하는가를 수치로 나타낸것은, 측정 대상의 독립성의 지표가 될수 있다.
4. 추상성Abstractness - A측정 혹은 분석 대상의 추상객체 혹은 인터페이스의 비율을 나타낸다. 범위는 0과 1사이이다.
5. 불안전성Instability - I 결합도의 수출성과 총 결합도의 비율을 나타낸다. I = Ce/(Ce+Ca). 이 측정값은 변경으로 부터의 복원성의 지표가 될수 있다.
테스트를 거듭하여 변경된 구조의 상태를 위의 측량법으로 측정하는 것이 추측에서 벗어난 방법, 즉 객관적이 되는데 도움이 될것이다. 물론 저들로 효율성을 전체를 판단할순 없지만, 측정기준이 없는것 보다 낫다.
예를들어 0.3 A를 가진 테스트 대상 컴포넌트나 패키지는 추상적인 객체나 인터페이스로 접근성을 높혀준다. 또한 대상(0.3 A를 가진 테스트 대상)과 결합하는 응용 프로그램의 결합도 수출성(Ce)이 높다 하더라도, 결합 대상들의 추상성(A)이 적당하다면 불안전성(I)을 완화 해줄 확률이 높아진다.
때때로 우리는 테스트를 통해 성능이나 안전성 외의 것을 생각해봐야한다. 어떤 구조개선을 이루고 있는것인지 직감에만 의존하는것은 아닐까.
마지막으로 맥코넬이 제시했던 요소들간의 영향력 차트이다.
'개발 > 수필' 카테고리의 다른 글
| 테스트와 장인 - 10 (0) | 2008/09/30 |
|---|---|
| 테스트와 장인 - 9 (0) | 2008/07/12 |
| 객체 지향 소프트웨어 일주 - 5 (0) | 2008/05/18 |
| 객체 지향 소프트웨어 일주 - 4 (0) | 2008/05/08 |
| 객체 지향 소프트웨어 일주 - 3 (0) | 2008/03/28 |
| 테스트와 장인 - 8 (0) | 2008/03/19 |
Recent Comment