Visual Studio 2010에서 단위 테스트 프로젝트를 생성하면 .NET Framework 4.0 의 단위 테스트 프로젝트를 지원했습니다. 단위 테스트 프로젝트를 .NET Framework 3.5 로 변경을 하게 되면 올바로 단위 테스트가 수행되지 않았던 문제가 있었습니다. 바로 아래와 같이 .NET Framework 버전을 변경하게 되면 발생하는 오류 메시지입니다.

 

그림 1 Visual Studio 2010에서 .NET Framework 3.5 로 변경할 경우

 

때문에 MSBuild 4.0으로 .NET Framework 3.5 빌드 및 테스트를 하게 되면 올바르게 빌드가 되지 않는 문제가 있었습니다.

필자 또한 이러한 문제로 인하여 다음과 같은 불편한 과정을 겪어야 했습니다.

참고

VS2008 을 VS2010 에서 동시에 개발하기

http://blog.powerumc.kr/314

 

VS2008 과 VS2010 동시에 개발하기 : 테스트 프로젝트가 포함 될 경우

http://blog.powerumc.kr/315

 

Visual Studio 2010 SP1은 이제 .NET Framework 3.5 버전의 단위 테스트도 지원이 가능하게 되었습니다.

그림 2 Visual Studio 2010에서 .NET Framework 3.5, 4.0 모두 단위 테스트 지원

 

다만, Visual Studio 2010 SP1은 .NET Framework 3.5까지 단위 테스트 프로젝트를 지원하며, 그 이하(.NET Framework 2.0, 3.0) 단위 테스트는 지원하지 않습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

2010년 8월 28일, Visual Studio Camp #1 에서 발표한 "Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP" 세션을 들어주신 분 중에 어느 테스트 전문가를 만나 뵙게 되었습니다. 최근 테스트 공학과 테스트 프로세스에 푹 빠져있는 저에게 매우 단비와도 같은 분이시고, 특히 테스트 전문 도구인 Load Runner 제품을 실제로 사용하고 계신 분이셨습니다.

(http://willstory.tistory.com/4)

제 세션의 내용과 현재 사용하고 계신 Load Runner 제품에 대해 경험적으로 비교를 해 주신 후기를 작성해 주셔서, 여러분들에게 도움이 될까 싶어 @will_story 님의 동의를 얻어 저희 팀 블로그에 게시하게 되었습니다.

가격에서 상당히 차이가 나는 Load Runner 와 Visual Studio 2010 Ultimate(테스팅 기능에 한하여) 비교해 주셨는데, 역시 비싸다고 좋은 도구는 아닌가 봅니다.^^ 이 두 도구에 대해 냉철하게 비교해 주신 @will_story 님께 감사 드리며, @will_story 님의 글을 보기 쉽게 편집하여 전문을 공개해 드립니다.

참고로, Visual Studio 2010 은 매우 광범위한 테스트 영역을 지원하고 있습니다. 테스트 공학에서 접근하는 대부분의 테스트 기능이 Visual Studio 2010 하나의 통합 도구에서 제공하는 것입니다.

[그림1] 테스트 기법 정리(Visual Studio Camp #1 의 세션 내용 중)

아래의 글은 http://willstory.tistory.com/4 의 글쓴이의 동의 하에 제공되어, 약간의 편집하였으나, 원문의 의미상 변형이 전혀 없음을 알려드립니다. 좋은 글을 제공해 주셔서 감사의 마음을 전해 드립니다. ^^

비주얼 스튜디오 2010 팀 블로그에서 Visual Studio Camp를 진행하였다. 여러가지 세션이 있었지만 나의 관심사항만 세미나를 경청하고 퇴장하였다. 유익한 정보였고 너무나도 소중한 시간이었다. 혹시 세미나 후기에 대한 내용에 대하여 자세한 정보를 알고 싶다면 아래의 링크를 따라갔으면 좋겠다.

Load Runner 의 버전은 8.1이다. 나에게는 아직 Windows 7이 없어 XP에서 잘 돌아가는 8.1 버전으로 작성하였다. Windows 7 에서 Load Runner 10.1을 해보고 싶었지만 OS가 없기에 아쉽게도 XP기준으로 작성한다.

세미나 후기, Visual Studio Camp #1

Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP – 땡초[엄준일]

소프트웨어 개발의 이전의 사례를 바탕으로 테스팅의 중요성과 그 기법과 방법을 공부하면서 경험한 내용을 전달하였습니다. 소프트웨어 개발 프로세스 중 테스팅의 매력에 푹 빠져 있답니다.

소프트웨어는 개발 및 릴리즈 과정까지 수 많은 과정을 겪는데, 소프트웨어가 점진적으로 진화함에 따라 결함의 발생률이 증가합니다. 이를 개선하기 위한 테스트 기법 중 단위 테스트, WhiteBox 테스트, 화면 테스트, 성능 테스트, 부하 테스트 등 다양한 테스트 기법을 알아봅니다.

사실 PPT 자료만 올라오면 이미지를 Load Runner 와 비교하고 싶었지만 아쉽게도 자료를 받지 못한 것이 아쉽다. 먼저 Load Runner 이미지로 비교 분석을 하고자 한다. 나중에 추후 VS2010 팀에서 자료를 받으면 추후 업그레이드를 하도록 하겠다.

자아.. 이제 내 Tistory의 첫 포스팅이자 첫 블로그 운영이 내가 관심이 있는 분야라서 매우 즐겁다. 이제 이야기를 보따리를 풀어보자.

Visual Studio Camp #1은 예전부터 신청하였다. 전에도 SW Testing Bar Camp 때 주최하였던 곳에서 그리 멀지 않은 곳이기 때문에 가기까지는 무리 없이 도착하였다. 이전에 Sten에서 Razar라는 제품[베타 테스트로 참석하여 경품을 받게 되었다.]으로 테스트한 경험을 공유한다고 하여 10시에 일정이 있었는데, 필요인원 부족으로 무산이 되어 집에서 피파온라인으로 열심히 게임을 하다가 세미나 시간에 맞추어 참석하였다.



도착하였을 때 깔끔한 신청 절차 간편한 입장이 인상적이다. 누가 발표자인지 누가 경청자인지 알 수 있는 이름표는 좋았다는 생각이 들었다. 하지만 이름표에 자신의 맡고 있는 MVP 분야를 적어 두었다면 경청자가 추후 질문을 하는데 있어 생각하는 수고를 덜어줄 수 있지 않았을까? 라는 생각을 하게 된다. 1시간 정도의 짧은 만남 물론 얼굴과 이름은 질문자가 당연히 갖추어야 할 기본 예의지만 … 그냥.. 뭐 아쉽다는 거다.

난 엔터프라이즈 Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP 님의 세미나를 들었다. 들으면서 Load Runner 와 흡사하기 보다는 오히려 'Load Runner 를 뛰어 넘을 수도 있겠다'라는 생각과 전율이 마음 깊숙히 전해져 왔다. 이미지가 있다면 전달이 쉽겠지만 아쉽다.. 아쉬워….

첫 번째, 비교[다양한 옵션 VS 심플함]

  • Load Runner 의 강점! 다양한 옵션
    다양한 옵션을 포함하고 있어 스크립트 작성 시 웹 페이지에 맞도록 작성이 용이하다.

    이외에 다양한 옵션이 존재한다. 좀…. 복잡하다. 잘못 설정했다가 원하는 결과를 얻기 어렵다.

  • Visual Studio 2010 강점
    • Simple 하다. 너무도 쉽게 심지어 Load Runner 보다 쉽다. Load Runner 의 사용자 매뉴얼은 너무도 이론적이며 복잡하다.
    • 하지만 Visual Studio 안내 설명은 매우 쉽게 설명하여, 특히 Visual Studio 2010 공식 팀 블로그에서도 자세하게 설명을 해주고 있다. 직접 경험을 기반으로 작성을 해주니 이보다 친절하고 절실하게 와닿은 설명이 어디 있겠는가!(소통과 공유가 존재하는 것)
    • 일반 사용자가 특히 개발자가 바로 바로 성능 테스트를 수행 할 수 있도록 되어있다.

두 번째, 비교[성능 테스트 시나리오]

  • 스케줄이 편리한 강점
    원하는 대로 인원도 증가 시킬 수 있다. 예약시간도 존재한다. 성능을 위하여 새벽2시에 기다려 테스트하지 않고 예약시간을 설정하면 알아서 돌아 간다. 랜덤으로 oo명에서 0명까지 물결 치듯 설정도 가능

  • 편리한 스케줄 일정
    Load Runner 와 마찬가지로 스케줄이 변경이 동일하다. 랜덤으로 oo명에서 0명까지 물결 치듯 설정도 가능한지는 짧은 세미나 내용으로 언급되지 못한 것이 아쉬운 점이다. 하지만 예상으로는 될 것으로 보인다.     세 번째, 비교[성능 모니터링]

  • Load Runner 의 모니터링
    Load Runner 는 Web/HTML만 반영하는 것이 아니며 DB/Oracle도 성능 테스트가 가능하기 때문에 매우 다양한 모니터링 지원이 가능하다[물론 돈이 많은 기업이라면 유로로 라이선스를 사야 한다.]

  • Visiual Studio 2010의 모니터링
    가장 아쉬운 부분 중에 하나이다. Load Runner 처럼 다양한 모니터링을 제공할 수 있을까[?] 라는 의문이 든다.

    하지만 강점도 있다. Load Runner 모니터링보다 심플하고 깔끔하며 원하는 정보만 보여준다. 로드러너 처럼 4개 정도의 모니터링 그래프를 제공하는 형식은 비슷하지만 디자인 면에서나 컴퓨터를 오래 사용하는 사용자의 입장에서 생각하는 UI는 Microsoft 의 Windows 7 로고처럼 심플하면서도 편안한 이미지로 되어있다. Load Runner 는 보고서를 출력하면 중복되는 내용이 많은데 Visual Studio 2010은 깔끔함과 심플함 원하는 정보와 불필요한 중복을 피하는 듯한 느낌을 받았다.     네 번째, 비교[리포트 및 보고서 출력]

  • Load Runner 의 모니터링
    Load Runner 는 2가지 방식으로 보고서를 출력할 수 있다. HTML, *.doc(docx) 방식이다. 알아서 목차도 만들어주고 내용도 작성해 준다. 물론 아쉽지만 영어로만 제공된다. 나는 그래서 주로 그래프만 이용한다.     

  • Visiual Studio 2010의 모니터링
    내가 보았을 경우에는 *.execl 형식으로 출력을 하는 것을 보았다. 조금은 아쉬운 점이다. 보고서를 다른 발주처에 보내었을 때 엑셀보다는 워드파일로 만약 공공기관이라면 *.hwp 파일로 보내야 하지만 *.execl은 조금은 뽀대[?]가 부족하다. 작성한 문서를 워드로 다시 편집 해야하는 수고를 덜어야 한다.

    물론 99% 성능 전문가들과 각 회사마다 프로젝트 성능 담당자들은 회사에서 쓰는 양식을 이용하여 템플릿에 맞게 보고서를 작성할 것이다. 나 또한 회사 템플릿으로 작성한다. 하지만 보고서로 출력하여 바로 줄 수 있을 정도의 수준이라면 이제는 로드러너는 내 손을 떠나 보내고 Visual Studio 2010 을 사용하지 않을까 생각한다.     Visual Studio 2010 Camp #1 짧은 후기

세션을 들으면서 엄준일[땡초]님과 10정도의 대화를 나누었다. 테스트에 재미를 붙이신 듯 호기심 어린 모습과 열정에 박수를 보내주고 싶다. [테스트의 세계로 오신 것을 환영합니다. 쿠쿠쿠쿠.ㅋ]

Visual Studio 2010 Camp #1 를 진행하셨던 어느 기술전도사님이 예전에 나도 스탭으로 다른 몇몇 분들과 함께 진행한 SW Testing Camp 와 함께 진행하였으면 좋겠다고 제안하였을 때 당장 "그럽시다" 라고 대답하고 싶었지만 아쉽게도 나 혼자만의 결정할 사안이 아니기에 대답을 회피했다. 아쉽 아쉽… Windows 7 운영체제에 Visiual Studio 2010 을 설치한 제품과 Load Runner 를 비교하면 나의 객관적인 입장에서는 Load Runner 에게 8.5점을 Visual Studio 2010 에게는 9.0점을 주고 싶다.

1시간만 들었던 세미나였지만 너무나 강렬한 인상이 아직도 기억 속에 남는다. 엄준일님이 함께하자는 말과.. 기술전도사님이 Visual Studio 2010 팀에서 함께 하자는 말 들이.. "기술전도사님 사실 저는 Windows 7이 없어요.. Visual Studio 2010도 없어요. ㅠㅠ;;; 빌려주시면.. 해보고는 싶어요.ㅠㅠ". 흑흑 2010년도는 일만 벌린다.. 담 주는 대학원 개강이구나

Windows 7에 Visiual Studio 2010 설치해주는 회사로 이직 옵션의 하나로 정해야겠다.. 좋은 회사 있음 소개시켜줘~ *_*/

많은 정보를 공유하고 싶지만 방화벽으로 text로만 해야 하는 회사에 아쉬움을 던지며 이만 작성 끝~~~

필자는 Load Runner 를 써보지 않고, 오직 Visual Studio 만으로 테스팅 공학과 분야에 흥미를 갖고 공부를 하고 있습니다. 이번 Visual Studio Camp #1 을 통해서 오히려 저에게 좋은 정보를 제공해 주시고, 의견을 공유할 수 있어서 너무 뜻 깊은 자리였습니다.

좋은 글을 저희 팀 블로그에 기고에 동의해 주신 http://willstory.tistory.com/4 님께 감사합니다.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

테스트 계획

테스트 계획은 테스트 작업을 시작하기 위한 가장 기초적인 명세서입니다. 테스트를 어떻게 진행하고 어떻게 결함을 발견할 것인지 계획을 갖고 테스트에 진입하는 것이죠. 테스트 계획 없이 테스트를 한다는 것은 아키텍처 없이 머리 속의 청사진으로 프로그램을 코드를 짜는 것과 마찬가지입니다. 그만큼 테스트 계획은 테스트에 있어서 첫 발을 내 딛는 중요한 작업입니다.    

테스트 계획은 좋은 소프트웨어의 첫 걸음

아마 독자 여러분들 중에 개발 프로젝트를 한 두 번쯤 리딩(Leading) 해 보신 경험이 있다면 아실 겁니다. 좋은 설계과 좋은 계획만으로 좋은 소프트웨어가 나오는 것이 아니라는 것을…. 물론 좋은 소프트웨어를 위해 밑거름이 바로 계획입니다. 그리고 계획이 좋거나 나쁘다고 해서, 소프트웨어의 품질과 직결되는 문제는 아닐 수도 있습니다.

실제로 엉터리 계획을 가지고 소프트웨어를 만들어도, 정말 잘 되는 케이스(대외적으로)도 많습니다. 심지어 계획 없이 시작한 프로젝트도 좋은 소프트웨어(절대적으로 좋다는 것은 아닙니다)가 나올 수 도 있습니다. 반대로 아주 철저한 계획을 가지고 시작하더라도 소프트웨어의 품질이 엉망이기도 합니다.

최근 애자일(Agile) 방법론은, 설계 단계를 코딩(Coding) 으로 대체하기도 합니다. 계획 자체가 불필요한 산출물로 직결되는 경향이 많기 때문에, 바로 최종 산출물을 코드(Code) 로 바라보는 매우 간결한 방법론입니다. 그리고 설계 단계를 뛰어넘음으로써 발생하는 여러 가지 문제를 XP(eXtreme Programming) 에서 애자일 선언문 중 12가지 원칙으로 커버를 하고자 합니다.  

깜놀~ MSDN 에서 애자일 방법론에 대한 설명이 있네요. (MSF v5.0과 관련된)
http://msdn.microsoft.com/ko-kr/library/dd997578.aspx   하지만 실제 현실에서는 어떤 특정한 계획 작업이 반드시 필요한 경우에 대부분입니다. 왜냐하면 지속적으로 소프트웨어가 운영되기 위해서는 과거의 이력이 쓸모 없기 보다는 적어도 필요 있는 경우가 대부분입니다. 설령 이력 관리가 되지 않은 문서라도 말입니다.   고객사의 소프트웨어의 산출물은 왜 관리가 안되는가?
몇 번의 컨설팅에 참여한 경험으로, 고객사의 산출물이 제대로 관리가 되지 않은 곳이 대부분이었습니다. 컨설팅을 수행하기 위해서 낯선 소프트웨어의 구조를 알기 위해, 산출물을 검토하면 실제로 현재와 다른 아키텍처나 구조를 가지고 있는 경우가 허다합니다.

왜 현재의 소프트웨어와 산출물이 일치하지 않는가에 대한 물음을 가질 수 있습니다. 산출물이 업데이트가 되지 않은 과거의 산출물이라면 특히 아키텍처나 구조를 파악하기 힘들 수 있거든요.

하지만, 굳이 산출물이 업데이트 되지 않더라도 누구를 탓할 수 있는 노릇은 아닙니다. 왜냐하면 업데이트가 되지 않은 산출물이라도 그 시대적인 배경과 당시의 이슈 등에 대해서 충분히 검토가 가능하기 때문입니다. 산출물이 업데이트 되지 않는 것은 무의미한 산출물이라고 말하는 사람들도 있지만, 꼭 나쁜 것은 아닙니다. 오히려 업데이트 되지 않은 산출물이 그 조직의 프로세스나 조직 구조를 파악하는데 더 도움이 되기도 하기 때문입니다.

테스트 계획, 어떻게 세워야 하나?

만약, 당신에게 소프트웨어의 특정 컴포넌트를 테스트를 해야 한다면, 바로 테스트의 계획을 어떻게 시작하냐 입니다. 필자의 생각으로는 개발보다 더 중요한 것이 바로 테스트라고 생각합니다. 잘못된 코딩을 검증할 수 있는 방법이 바로 테스트이기 때문입니다. 코드적인 오류나 비즈니스 프로세스적인 오류, 기술적인 오류 등 다양한 개발 코드에 잠재적인 오류가 내포되어 있습니다. 그것을 찾아내고 올바르게 검증하는 단계가 바로 테스트 단계입니다.

즉, 테스트를 하기 위한 목적과 목표가 뚜렸해야 합니다. 테스트 케이스는 테스트를 진행한 테스터(SDET) 에 의해 명확한 비전을 제시하며, 커뮤니케이션을 증진할 수 있습니다. 그렇기 때문에 테스트 케이스가 없는 테스트는 커뮤니케이션을 포기한 테스트와 다름 없습니다.

그럼 다음과 같은 단계로 테스트 계획을 진행할 수 있습니다.

  • 테스트 이름
    한 문장에 테스트에 대한 모든 요약 내용을 함축할 수 있어야 합니다.
  • 테스트 문제
    테스트 이름에 대한 설명입니다. 예를 들어, Stack Overflow 가 발생할 수 있다는 추측이나 테스트 목표를 서술합니다.
  • 분석
    개발자와 테스터의 업무는 전혀 다릅니다. 개발자는 문제 발생에 간과하여 넘어가는 경향이 있지만, 테스터는 그 문제를 밝혀내는 업무를 수행합니다. 문제가 되는 부분에 대해 왜 문제가 되는지 정곡을 찌르는 설명이나 추측을 서술합니다.
  • 설계
    실제 테스트가 수행될 경우, 어떤 파라메터와 결과 기대값을 갖는지에 대한 서술입니다. 테스트를 실제로 진행하게 될 과정을 서술하면 됩니다.
  • 오라클
    예상되는 결과에 대한 설명입니다. 즉, 설계 단계에서 왜 결과가 이렇게 나오게 될지에 대한 서술입니다.
  • 예제
    왜 결과 값이 이렇게 나오는지에 대한 예제나 코드 등을 나열하면 됩니다.
  • 함정과 계약
    예를 들면, 테스트에 사용된 파라메터가 항상 옳을 수는 없습니다. 즉, 업무 지식이 있는 사람과 없는 사람간에 테스트를 진행할 경우 테스트 결과에 대한 오차를 서술합니다. 왜냐하면 테스트 계획을 테스터와 비즈니스 업무 분석가 간에 시각 차이가 있을 수 있기 때문입니다.
  • 관련된 패턴
    이전에 말씀 드렸다시피 테스팅 패턴을 다양합니다. 어떤 테스팅 기법의 패턴으로 접근했는지에 대한 요약입니다.

위와 같이 테스트 계획을 수립할 수 있습니다. 하지만, 간결한 프로세스를 위해 몇 가지 항목은 건너뛰어도 괜찮다고 생각합니다. 필자가 테스팅 아티클을 쓰는 이유도 바로 이것 때문이죠. 우리나라 실정에 맞게 불필요 한 것은 제거하자.

필자의 경험으로 반드시 필요한 항목은 아래와 같습니다. 물론 필요한 경우 더 추가하셔도 좋습니다.

  • 테스트 이름
  • 테스트 문제
  • 함정과 계약

그렇다면 테스트 하는데 얼마나 걸리는데?

가장 민감한 사항입니다. 개발된 코드를 이용하여 테스트를 진행하는데 얼마만큼의 시간이 소요되는지에 대한 추정은 테스팅을 도입함에 있어서 비용과 직결되는 민감한 부분입니다. 왜 테스트를 진행해야 하는지조차 불분명하다면 차라리 전통적인 방법(수직적인 개발 방법론) 의 가장 마지막 단계에서 진행하는 것과 별반 다를 것이 없기 때문입니다.

개발자(SDE)가 자신의 코드를 테스트 하는 것과, 테스터(SDET) 가 테스트하는 것과 품질의 차이가 없다면 정말 테스트는 불품 없는 작업이기도 합니다. 하지만 분명한 것은 개발자의 시각과 테스터의 시각은 현저하게 다릅니다. 예를 들어, 개발자는 '사용자'가 이런 어처구니 없는 값을 입력하지 않을 거라고 단정하고 개발을 하지만, 테스터는 그렇지 않기 때문이죠. 이해하시죵? ^^

일반적으로 Microsoft 에서는 개발과 테스트의 시간을 1:1 로 봅니다. 즉, 개발 시간이 3시간이 걸리면, 테스트 시간도 3시간으로 예측합니다. 테스트에 소비되는 시간은 고객이 사용하는 소프트웨어의 결함에 대한 불쾌지수와 다름이 없습니다. 테스트가 적절한 패턴으로 정합적으로 수행되었다면, 그만큼 잠재적인 결함과 버그도 줄어들 것입니다.    

테스트 산출물이 필요하다.

테스터(SDET) 가 테스트를 수행했더라도 잠재되어 있는 결함이나 버그는 여전할 수 있습니다. 테스트 패턴이 잘못된 접근법이나 방법을 사용했다면 잠재적인 치명적인 결함이나 버그로 이어질 수 있기 때문입니다. 그래서 특히 테스트에 대한 산출물이 테스터에게는 방어적이고 효율적인 수단이 될 수 있습니다.

가장 기본적으로 테스트는 코드의 모든 부분을 검증해야 합니다. 입력 값이 잘되었든, 잘못되었든 말이죠. 그리고 그 결과를 이력으로 저장하여 지속적으로 테스트의 검증이 올바르거나 효과적으로 진행되었다는 것도 기록이 필요합니다.

즉, 테스트를 진행해서 뭐가 좋아 졌는지의 수치적인 측정이 필요합니다.

  • 테스트 결과
  • 코드 커버러지
  • 스펙 종료 상태
  • 결함율 추이
  • 성능 테스트 결과

위의 항목에 대해서는 차근 차근 알아볼 예정입니다. 특히 주의할 사항은, 코드 커버러지가 100% 라도 테스트가 완전히 완료된 것은 아니라는 것입니다. 차후에 테스트 패턴에 대해서 알아보면서 다룰 예정입니다. 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

샘플 프로그램으로 시작해보자고!!

아주 간단한 Windows Forms 어플리케이션을 작성해 보았습니다. 실제로 실무에서는 이렇게 간단한 프로그램을 만드는 개발자도 없겠지만, 아주 간단한 것 부터 시작하여 테스트의 필요성과 테스터의 역할이 얼마나 중요한지 알 수 있는 시간이 되길 바랍니다.    

아래의 윈폼 어플리케이션은 숫자A와 숫자B 를 더하여 결과를 보여주는 프로그램입니다. 아래와 같이 간단하게 디자인을 하였습니다.

   

소스 코드는 더할나위 없이 간단합니다. 특별한 설명은 하지 않겠습니다.

이 프로그램으로 1과 2 값을 입력하면 당연히 3이라는 결과가 출력되어야 합니다 아래와 같이 말이죠.

프로그램이 완벽하지요?? 정말일까요?? 특히 프로그램을 개발하는 개발자의 시각은 테스터와 매우 다릅니다. 일반적으로 개발자에게 스팩(Spec)을 구현하는 명세서가 전달이 됩니다. 아래는 간단한 구현 명세서 입니다. (단, 화면 명세서가 아닙니다)

   

구현 명세서

제목

두 숫자를 입력 받고 합을 구하는 기능

기능

1. 테스트 박스 1에 숫자를 입력할 수 있다.
2. 텍스트 박스 2에 숫자를 입력할 수 있다.
3. 새로운 텍스트 박스에 텍스트 박스 1과 텍스트 박스 2의 합을 출력한다.

   

테스터(SDET) 의 힘이 발휘되는 순간!

개발자는 위의 명세서를 보고 두 숫자를 입력 받아 출력하는 프로그램을 아래와 같이 구현합니다.

사실상 동작에 아무런 문제점이 없지만, 테스터의 시각에서는 전혀 다릅니다. (물론 구현 명세서가 부정확하긴 합니다) 즉 숫자의 입력 범위가 매우 불확실합니다. 정수만 입력되는 Integer 값인지, 32Bit 부동 소수점을 표현하는 Float 인지 아무런 정보가 없기 때문이겠지요.

테스터는 바로 버그를 발생시킬 수 있는 프로그램의 코드나 사용성에 대해 즉각 테스트를 수행합니다. 개발 소스 코드가 제공이 된다면 해결 방안까지 제시할 수 있겠지만, 그렇지 않는다면 오로지 테스터의 경험과 실력에 의존할 수 밖에 없습니다. 그렇기 때문에 SDET 는 개발자(SDE) 와 동등한 기술 능력을 갖추거나 그 이상의 능력을 필요로 하게 됩니다.

위의 간단한 프로그램을 테스트하기 위해서는 SDET 는 테스트 케이스(Test Case) 를 작성합니다. 테스트 케이스(Test Case) 를 작성하는 목적은 기능이 올바르게 동작한다는 가정하에 잠재적인 버그(Bug) 를 유도하는 작업입니다. 그리고 테스트 케이스에 대해서는 차후에 자세히 다루도록 하겠습니다.

만약, SDET 가 아래와 같은 값을 입력했다면 어떻게 될까요? 즉시 프로그램은 오류를 뱉고 말 것입니다. 아래와 같이 말이죠.

   

물론, SDET 는 소프트웨어 버전이 매번 릴리즈 될 때마다 위와 같이 무식하게 수동 테스트(Manual Test) 를 수행하지 않을 것입니다. 이 수동 테스트를 개선하기 위해 자동화 테스트를 수행할 것이며, 이 부분 또한 차후에 설명할 예정입니다. 간단히 설명하자면 반복적으로 테스트를 수행한 가치나 목적이 있다는 자동화 테스트 대상이 될 수 있습니다.

위의 무식한 테스트 과정을 자동화 하기 위해 단위 테스트(Unit Test) 를 사용하여 아래와 같이 작성할 수 있습니다. (아래의 UI 테스트와 관련된 부분이며 마찬가지로 차후에 상세히 설명할 예정입니다, 단, 자동화 테스트 이외의 비기능 테스트가 무식하다는 것은 아닙니다.)

   

이 테스트는 아쉽지만, 무자비하게 오류를 발생합니다. 프로그램 소스 코드의 int.Parse 는 정수 값만 변환 가능하므로, 소수점이 포함된 "1.1" 값은 FormatException 을 발생하게 됩니다.

이런 결함에 대한 버그 리포트를 개발자에게 할당하게 되면, 아마도 아래와 같이 프로그램의 소스 코드가 int.Parse 에서 float.Parse 로 변경될 수 도 있겠지요.

위와 같이 코드를 수정하면 프로그램을 정상적으로 동적을 합니다. 아래와 같이 말이죠^^

   

정말 버그가 해결된 것일까?

FormatException 에 대해 SDET 가 테스트한 테스트 코드를 통해 개발자(SDE) 가 코드를 수정하였습니다. 그리고 원하는 테스트는 다행스럽게도 통과(Pass) 했습니다.

   

모든 소프트웨어는 그 품질을 향상하기 위해 테스트를 진행합니다. 하지만, 버그가 없는 소프트웨어란 있을 수가 없습니다. 위와 같은 다행스럽게 SDET 가 버그나 결함을 발견하였더라도 앞으로 발견될 잠재적인 버그는 언제나 소프트웨어가 내포하고 있습니다. 즉, 완벽한 소프트웨어는 없다는 것이지요. SDET 는 이러한 버그와 잠재적인 버그를 효과적으로 발견 해야하는 매우 중대한 업무를 수행하는 직군입니다.

현대의 소프트웨어는 인터넷의 발달로, 언제나 제작사에게 피드백을 건의하고 버그를 건의하는 시스템이 구축이 되어 있습니다. 그 중 Microsoft 의 대표적인 것이 아래와 같습니다.

  • CEIP(Customer Experience Improvement Program)

    고객 또는 사용자의 동의하에 고객 경험 개선 프로그램에 참여할 수 있습니다. 이 정보는 고객의 피드백을 수집하기 위한 정보로 활용이 됩니다.

  • WER(Windows Error Reporting)

    Microsoft Windows 제품은 실제 매우 광범위한 영역과 자원과 비용이 할당된 제품입니다. 이 제품에서 발생하는 오류나 버그를 수집하기 위해서 WER 프로그램이 윈도우 내부에 탑재가 되어 있습니다. 이 정보를 기반으로 윈도우의 차기 버전이나 패치 버전에서 우선 순위로 할당되는 중요한 정보로 활용이 됩니다.

  • CER(Corporate Error Reporting)

    일반 고객이 아닌 기업 대상으로 소프트웨어를 사용한다면, 기업 내부에서는 오류 정보가 Microsoft 로 전송되는 것을 원치 않을 경우가 많습니다. 왜냐하면 기업의 시스템의 배치, 소프트웨어의 활동 등이 기밀 정보가 될 수 있고, 매우 조심스러운 부분이기 때문입니다. CER 은 Microsoft 로 정보가 전송되지 않고 기업 내부에서 관찰할 수 있는 프로그램입니다.

  • 스마일 전송 프로그램 : 추후에 설명할 예정입니다. 간략하게 고객이나 사용자의 감성을 데이터베이스화 하고자 하는 Microsoft 사용성 향상을 위한 프로그램 입니다.

   

개발자 보다 더 똑똑한 테스터!

위의 int.Parse 를 float.Parse 로 바꿈으로써 버그가 해결되었다고 볼 수 있습니다. 하지만 진정으로 버그가 해결되었다고 볼 수 없기도 합니다. 왜냐하면 테스트 케이스를 만족하지만 다양한 부류 집단인 '베타 테스트'에서는 전혀 다른 결과가 나올 수 도 있으니까요. 그리고 테스터는 바로 이러한 버그의 발생을 아키텍처/코드/기능적인 부분을 고려하여 버그를 유도할 수 있습니다.

만약, 유능한 SDET 라면 Float 으로 인한 결과 값 버그를 아래와 같은 테스트 케이스로 작성할 수 있습니다.

   

왜 결과 값이 당연이 1이 되어야 하지만, 1.000054 라는 황당한 값이 나왔을까요? 바로 컴퓨터의 내부 연산이 2진수로 이루어 진다는 것을 모르는 개발자나 테스트는 위와 같은 오류를 예감하지 못할 것입니다. 저 또한 제니퍼소프트의 정성태 과장님을 통해 이러한 문제를 처음 알게 되었으니까요.

정성태 과장님의 설명에 의하면,

"2진수의 소수점 표현들이 자리수에 따라서 1/2, 1/4, 1/8, 1/16, 1/32, 1/64 와 같은 식으로 표현이 되는데, 십진수 0.5 는 다행히 정확하게 1/2 에 맞아 떨어지지만, 십진수 0.6 은... 겨우 0.1 차이일 뿐인데 0.10011001100110011001 와 같은 2진수로 되어 버립니다. 근데 이것도 근사치일 뿐이지 1001 패턴이 계속 무한 반복 되어버리죠. 정밀도를 높이면 0.6 은 0.010011001100110011001100110011001100110011001100110011 로 표현이 되어버립니다."
더 자세한 내용은 http://k.daum.net/qna/view.html?qid=3wykn&aid=3xIOa 참고하세요.

만약, 이러한 문제가 회계 업무나 우주 공학에 적용이 된다면, 수억, 수십, 수 조원이 투입된 프로젝트에서 불에 뻔하듯 우주선이 폭발하거나 궤도를 이탈할 수 도 있는 심각한 문제를 발생할 수 있습니다. 실제로 이러한 문제로 일부 고객은 손해 금액에 대하여 마이크로소프트를 대상으로 법적인 대응을 한 사례도 있습니다.

Microsoft 가 이 문제를 몰라서 그랬을까요? 그렇지는 않습니다. IEEE(Institute of Electrical and Electronics Engineers) 표준으로 사용되었던 C 언어와 Pascal 언어간의 원활한 데이터 전달을 위해 C# 의 Float 도 같은 방식의 연산이 사용된 것입니다. 더 자세한 내용은 http://support.microsoft.com/kb/42980/ko 를 참고하세요.

   

그럼 어떻게 해결하나?

위와 같이 int.Parse 는 결함을 유발하기 매우 쉽지만, float.Parse 의 경우 더 깊은 이해가 필요합니다. 만약 테스트 케이스(Test Case) 가 이것을 유추하지 못한다면 얼마 되지 않아 소송에 휘말릴 수 있는 충분한 근거가 되겠지요. 만약 구현 명세서를 간파한 SDET 라면 이 수치에 대한 근거를 요구할 것이며, 테스트 과정에서 IEEE 745에 대한 테스트를 수행했을 테니까요.

현명한 테스터라면 float.Parse 의 타입을 Decimal 로 변경하기를 권장할 것입니다. Decimal 은 부동 소수점의 오류나 반올림에 대한 이슈를 해결할 수 있는 구조체(Struct) 입니다. 즉, 아래와 같은 구현이 회계 업무에 버그가 없는 코드가 될 것입니다.

   

테스터의 역할

테스터(SDET) 는 위의 간단한 예시와 같이 다양한 테스트를 진행하는 역할을 수행합니다. 그리고 그 역할이 매우 단순하고 초보 개발자가 수행할 수 있는 단순한 작업이 아님을 알 수 있습니다.

테스트 케이스(Test Case) 를 만들고, 다양한 테스트 시나리오를 계획하는 테스트 계획(Test Planning) 을 함으로서 소프트웨어의 잠재적인 버그를 하나씩 제거하는 매우 막중한 임무를 수행하는 직군입니다. 그리고 SDET 의 역할이 개발자(SDE) 의 코드적인 목적을 정확하게 간파하지 못하거나, 제품 전체적인 아키텍처, 프로세스를 이해하지 못한다면 더욱 더 많은 문제에 봉착하게 됩니다.

본 회에서 SDET 가 가지는 역할을 강조하기 위한 것이며, 추후에 테스트를 수행하기 위한 공학적인 기법에 대해서 차근 차근 알아보도록 할 예정입니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 지송 2010.08.06 15:47 Address Modify/Delete Reply

    잘보고 갑니다. float 연산관련해서는 글보고 처음 알았네요.

    다음에 또 들리겠습니다. 더운 여름 잘 보내세요.

배포 또는 구성된 가상 Lab 환경을 시작하고 사용하는 방법입니다.

가상 머신 시작하기

   

가상 머신이 시작하는 중

   

가상 머신이 시작 된 모습.

   

   

가상 머신 연결하기

   

가상 Lab 환경에 연결하면 새로운 원격 제어 창이 뜬다. 이 창은 가상 머신을 원격 제어할 수 있는 Microsoft Environment Viewer 창이다.

   

사용 중인 가상 머신은 Marking 을 하여 다른 사람이 볼 수 있도록 할 수 있다.

   

Mark 를 'In Use' 로 설정하면 Lab Center 에서는 사용중이라는 표시가 뜨므로, 공동 작업에 유용할 것이다.

   

Snapshot 을 통해 특정 지점의 상태를 저장하고, 언제든지 이전 또는 이후의 Snapshot 으로 이동할 수 있다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

문제

가상 랩 환경을 배포하는 중 TF259115 오류가 발생하면서 배포 할 수 없는 경우입니다.

 

1. DNS 설정 문제

TFS Admin Console 의 Lab Management 설정의 Network Location 문제입니다.

이러한 경우 대부분 DNS 상의 설정 문제입니다.

   

역시 DNS 상에 호스트 IP 가 잘못 설정되어 있었습니다.

 

2. VMM 템플릿에 네트워크 위치 설정

VMM 템플릿에 네트워크 어뎁터가 구성이 되지 않아 발생하는 문제입니다.
http://blogs.technet.com/chengw/archive/2009/05/08/vmm-network-location-and-network-tag.aspx
http://blogs.blackmarble.co.uk/blogs/rfennell/archive/2010/01/27/so-you-want-to-demo-vs2010-lab-manager.aspx

이 설정이 정상적이지 않으면, 루프백(loopback) 현상이 발생한다고 합니다.

VMM 의 호스트 탭에서 속성(Properties) 를 클릭합니다.

하드웨어 탭에서 "검색된 네트워크 위치 다시 정의(Override discovered network location)" 을 클릭하고, 새로운 네트워크 이름을 입력합니다.

그리고 "네트워크" 탭으로 이동하여 새로운 가상 네트워크를 추가합니다.

아래와 같이 가상 네트워크 이름을 입력하고, 태그로 반드시 함께 입력해 주자.

다시 라이브러리의 템플릿의 하드웨어 구성 탭에서 이전에 지정한 네트워크 이름과 태그를 지정해 줍니다.

TFS Admin Console 의 Application Tier 의 Lab Management 탭으로 이동하고, Reconfigure Lab Management 를 클릭하여 Lab 환경을 다시 설정합니다.

Virtual Machine Manager 탭에서 아래와 같이 Protected Network 를 선택합니다.

이제 Team Project Collections 에서 Configure Host Groups 를 클릭합니다.

Verify 를 클릭하여 점검이 통과하는지 확인합니다.

   

Posted by 땡초 POWERUMC

댓글을 달아 주세요

최근에 많은 기술이 쏟아지고, .NET 의 생태계에도 새로운 국면을  맞이했습니다. 바로 Microsoft  에서 야심차게 준비하고 있는 .NET 4.0 플랫폼과 Team Foundation Server 기술은 상상과 생각을 현실로 이루어주는 강력한 밑거름이 되기 때문입니다.

 

지금이 아마 우리도 함께 변화할 수 있는 최고의 시점이며, 본 세미나는 그 길을 열어주는 가장 효과적인 세미나가 될 것입니다.



본 세미나는 프로젝트를 주도하는 관리자나 프로젝트 매니저를 위한  세미나입니다. 세미나 신청은 아래 "세미나 등록하기" 버튼을 클릭하십시오.

 

ALM 의 도입과 그 필요성

여러분의 조직은 효율적이라고 생각하나요? 바꾸어 보십시오. 국내 최고 아키텍처겸 컨설턴트인 닷넷엑스퍼트의 안재우 수석님의 많은 경험을 전수해드립니다. Team System MVP 엄준일 선임은 ALM 을 이용하여 효과적인 관리 방법, 팀과 조직이 한발 앞의 미래를 바라보는 노하우를 알려드립니다.

 

기업용 LOB 프로그램의 테스트 환경 구축
"왜 소프트웨어에 결함이 발생할까?" 라는 80년대의 구세대적이고 형식적인 질문은 버리십시오. 오늘날 소프트웨어 개발부터 운영까지 최신의 테스팅 기법과 기술을 직접 눈으로 확인하십시오. 테스트 자동화와 테스트 가상화는 분명 여러분들의 감탄과 탄성을 자아낼 것입니다.

 

WPF 기반 스마트클라이언트 적용 고객 사례
국내에 한번 있을까 말까한 최대 규모의 .NET 프로젝트를 닷넷엑스퍼트에서 수행하였습니다. 최신 프레젠테이션 기술인 WPF 를 이용하여 UX 컨설턴트 김선구 책임이 직접 참여한 프로젝트입니다. 최신 기술과 UX 와의 교감, 개발까지 아우르는 현장감있는 그들의 고민과 재미있는 경험을 들을 수 있을 것입니다.


 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

목차

[Testing] TDD (Test-Driven Development)-테스트 주도 개발

[Testing] BDD (Behavior-Driven Development)–행위 주도 개발

[Testing] Moq.NET (T/B Driven Development)

 



Moq.NET

Moq 는 "Mock-you" 또는 "Mock" 로 부른다고 합니다. Moq.NET 3.0 은 C# 3.0 과 .NET Framework 3.5 를 통해 Linq Expression Tree 와 Lambda Expression(람대 표현식) 으로 직관적이고 생산적이라고 합니다.

이전에 봤던 웹 사이트 로그인 사용자 스토리를 다시 봅시다. 단, 이 예제에서는 복잡성을 만족하는 항목을 삭제합니다.

웹 사이트의 로그인 사용자 스토리

  • 사용자 아이디는 영문만 입력 가능하고 한글은 입력할 수 없다
  • 사용자 아이디는 최소 3자리, 최대 10자리까지 입력가능하고 초과시 경고 메시지를 보여준다
  • 사용자 비밀번호는 최소 5자리, 최대 20자리까지 입력 가능하고 초과시 경고 메시지를 보여준다

   

위의 사용자 스토리를 Mocking Framework 인 Moq.NET 을 이용하여 TDD와 BDD 형태로 테스트를 작성해 나갈 수 있습니다.

아래의 소스 코드는 Login 인터페이스를 정의한 코드입니다.

public interface ILogin
{

LoginResult Login(string id, string password);

LoginInputResult Valide(string id, string password);

}

   

public enum LoginResult

{

Authentication,

NoAuthentication

}

   

public enum LoginInputResult

{

Success,

MinLengthId,

MaxLengthId,

MinLengthPassword,

MaxLengthPassword

}

   

이제 Login 의 Behavior(행위) 측면에서 주도적인 개발을 하고자 합니다. BDD 이용하여 [그림1] 의 Clean up code 를 얻기 위한 목적이 아닙니다. 좀 더 TDD 에 가깝고, 디자인과 설계에 초점을 맞추고자 합니다.

class Program
{

static void Main(string[] args)

{

var id = "powerumc";

var pwd = "aaaa";

var mock = new Mock<ILogin>();

}

   

private static string minString(int length)

{

return Match<string>.Create( o => o.Length <= length );

}

   

private static string maxString(int length)

{

return Match<string>.Create( o => o.Length >= length );

}

}

   

위의 코드를 통해 Mocking Object 를 생성하도록 Mock<T> 생성자를 볼 수 있습니다. 바로 Mock<T> 를 통해 Mocking Object 를 생성합니다.

아래의 코드는 위의 로그인 사용자 스토리에서 입력되는 아이디/비밀번호의 유효성을 검사하도록 Mocking Object 를 설정합니다.

// Validate

mock.Setup( o => o.Valide(minString(3), It.IsAny<string>()))

.Returns(LoginInputResult.MinLengthId)

.Callback(()=>Console.WriteLine("ERROR> MinLengthId"));

mock.Setup( o => o.Valide(maxString(10), It.IsAny<string>()))

.Returns(LoginInputResult.MaxLengthId)

.Callback(()=>Console.WriteLine("ERROR> MaxLengthId"));

mock.Setup( o => o.Valide(It.IsAny<string>(), minString(3)))

.Returns(LoginInputResult.MinLengthPassword)

.Callback(()=>Console.WriteLine("ERROR> MinLengthPassword"));

mock.Setup( o => o.Valide(It.IsAny<string>(), maxString(20)))

.Returns(LoginInputResult.MaxLengthPassword)

.Callback(()=>Console.WriteLine("ERROR> MaxLengthPassword"));

   

아래의 코드는 유효성을 통과한 아이디/비밀번호로 로그인을 시도하고 결과값을 리턴하는 Mocking Object 입니다.

// Login

mock.Setup( o => o.Login(It.IsAny<string>(), It.IsAny<string>()))

.Returns(LoginResult.NoAuthentication)

.Callback(()=>Console.WriteLine("No Authentication"));

mock.Setup( o => o.Login(id, pwd))

.Returns(LoginResult.Authentication)

.Callback(()=>Console.WriteLine("Success Login"));

   

자, 그럼 가상의 Mocking Object 를 통해 인터페이스만으로 로그인 시도를 해보도록 하겠습니다.

var obj = mock.Object;

var loginInputResult = obj.Valide(id,pwd);

   

if( loginInputResult != LoginInputResult.Success ) return;

   

obj.Login(id,pwd);

   

입력 변수 값에 따라 비록 Mocking Object 지만, 테스트 시나리오를 충분히 검증할 수 있습니다.

Id="aaa", pwd="aaa" 일 경우는 아래와 같은 결과가 나타나겠죠~?

 

Id="powerumc", pwd="aaaa" 일 경우는 아래와 같이 모든 테스트 시나리오를 통과한 결과입니다.

 

그럼, Microsoft Research 프로젝트의 일환인 Pex 를 이용하여 Mocking Object 를 Testing 해보겠습니다. Pex 테스트 프로젝트를 생성하고 아래의 PexMethod 를 만들었습니다.

아래는 테스트 결과입니다. 총 31개의 테스트 케이스 중에 통과되는 1개의 테스트를 확인할 수 있습니다.

자 어떻습니다~? 전혀 구현 코드를 구현하지 않았음에도 인터페이스를 통해 TDD-테스트 주도 개발이 가능합니다. BDD-행위 주도 개발을 통해 번거로운 TDD 의 Red, Green, Refector 의 유한반복 사이클 없이도, 실제 인터페이스의 디자인과 설계에 초점을 맞추어 테스트를 진행하였습니다.

단순히 BDD 가 최고야~ 라는 말은 아닙니다. 우리가 BDD 를 통해 TDD 를 좀 더 쉽고, 근접하게 접근할 수 있습니다. 그리고 코드의 구현이 전혀 없이 오직 디자인과 설계에 초점이 맞추어져 있다는 사실을 알면 됩니다. 바로 Moq.NET 은 Mocking Object 를 통해 TDD 와 BDD 개발을 통해 좀 더 품질 좋은 WhiteBox Testing 의 기대효과를 누릴 수 있습니다.

데이터베이스의 데이터를 조회하여 테스트한다고 할 때에도, 반드시 데이터베이스가 존재하지 않아도 됩니다. 가상의 데이터베이스 커넥션 객체를 만들어서 쓰면 됩니다. 쇼핑몰 사이트에서 결재 프로세스를 테스트해야 하나요? 그렇다면 가상의 객체를 통해 설계된 결재 프로세스가 합당한지 Mocking Object 를 통해 테스트를 하면 됩니다. 그 이후에는 잘 설계된 인터페이스를 구현하기만 하면 되겠죠?

   

이 외에도 WikiPedia 에 Mock Library 의 종류가 있네요. 아무튼 테스트와 Moq.NET 에 대한 내용은 여기까지 하는 것으로 마치도록 하렵니다.

 

참고 문헌

http://en.wikipedia.org/wiki/Mock-object
http://behaviour-driven.org/

Posted by 땡초 POWERUMC

댓글을 달아 주세요

목차

[Testing] TDD (Test-Driven Development)-테스트 주도 개발

[Testing] BDD (Behavior-Driven Development)–행위 주도 개발

[Testing] Moq.NET (T/B Driven Development)



그렇다면 BDD (Behavior-Driven Development) !

TDD 는 그렇다고 치고, 이제는 BDD(Behavior-Driven Development-행위 주도 개발) 가 왠말이냐 -_-; 저 또한 Moq 에 생소한 나머지 여기까지 추적하게 되었습니다. 모두가 TDD 가 좋은 줄은 압니다. 종속적인 기능이나 코드가 정상적임을 증명하고 점진적으로 테스트 코드를 만듦으로써 자연스럽게 세부 설계를 생각하게 할 수 있습니다.

나에게 "TDD" 를 요구한다면 나에게 "시간"을 달라

어째든, BDD 는 소프트웨어 품질을 향상하기 위해 개발자간에 협력할 수 있는 Agile Software Development 기법입니다. BDD 의 목표는 TDD 를 수행하기 위한 것이며 TDD 의 접근법을 전환한 것입니다. TDD 의 딱딱한 어휘를 정리하고 설계나 디자인에 초점이 맞추어진 패러다임의 전환이라고 합니다. 그리하여 TDD 를 수행한다는 본질은 변하지 않지만, TDD 를 수행하기 위해 BDD 를 통해 행위 자체는 변할 수 있다는 것입니다.

더 자세한 내용은 아래의 Behavior-Driven Development 공식 사이트를 참고하십시오.

Behaviour-Driven Development
http://behaviour-driven.org/

또한 Agile Software Development 에서 각 이터레이션(Iteration)에서 수행하게 될 사용자 스토리를 통해 기능이나 구현에 대한 스팩을 정의할 수 있습니다. 즉, 애자일의 사용자 스토리는 바로 테스트를 수행하는 테스트 시나리오로 이어지게 됩니다. 헌데, TDD 로만 수행되는 테스트 시나리오는 실제로 변화에 능동적으로 대처하지 못할 수 있는 경우도 존재합니다.

예를 들어, 설계자는 개발자에게 아래의 스팩이 만족하는 로그인 기능의 "사용자 스토리" 를 정의합니다.

웹 사이트의 로그인 사용자 스토리

  • 사용자 아이디는 영문만 입력 가능하고 한글은 입력할 수 없다
  • 사용자 아이디는 최소 3자리, 최대 10자리까지 입력가능하고 초과시 경고 메시지를 보여준다
  • 사용자 비밀번호는 최소 5자리, 최대 20자리까지 입력 가능하고 초과시 경고 메시지를 보여준다
  • 사용자 비밀번호는 복잡성 만족도를 우측에 색깔과 메시지로 보여준다

위의 사용자 스토리에 만족하도록 TDD 를 수행해야 하는데, TDD 를 수행하기 위해서는 반드시 스토리의 우선 순위대로 진행해야 다음의 테스트 코드를 작성할 수 있습니다. 그런데 여기에 엄청난 함정이 있을 수 도 있습니다.

  • 초/중반의 우선순위의 사용자 스토리의 규모가 한 이터레이션의 주기와 맞먹는 경우라면 TDD 를 어떻게 수행할건가요?
  • 또는, 로그인 시나리오(에피소드, 테마) 안에 고객의 쉽지 않은 요구사항이 추가되었다면 어떻게 할건가요?

예를 들면, 설계가 진행 도중 아래와 같은 요구 사항이 추가가 되었다고 가정해 봅시다.

  • 로그인은 SSO(Single Sign On) 을 통해 로그인하며, SSO 중앙 서버를 통해 인증해야 합니다.

 

기가 막히군요. 아직 SSO 서버는 구축이 되지 않은 상태이고, 단일 시스템간에 명확한 프로토콜도 정의되지 않은 시점입니다. TDD 를 수행하기 위해 SSO 중앙 서버와 프로포콜이 구축되지 않는다면 더 이상 로그인과 관련된 작업은 진행할 수 없게 됩니다.

자! 바로 이런 경우 행위 주도 개발-BDD 가 빛을 발할 때입니다. BDD 의 행위 주도 개발은 인터페이스와 구현을 분리하고 인터페이스에 집중할 수 있습니다. 즉, 어떠한 구현 코드가 없이도 BDD 를 통해 인터페이스만으로 테스트나 코드를 통해 설계 작업을 진행할 수 있게 되는 것입니다.

구현 코드가 없이 인터페이스만으로 테스트를 진행한다니요? 이거 말장난 아닙니까? 아닙니다. 객체의 구현은 전혀 알 필요 없습니다. 단, 내부적인 테스트 시나리오를 알고 있는 것만으로 테스트를 진행하게 됨으로써, 인터페이스의 디자인이나 설계에 집중하게 됩니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 까꿍 2010.04.18 16:47 Address Modify/Delete Reply

    서비스를 기획하는 초기 단계에 고객 또는 사용자에게 서비스 필요성을 납득 시킬 필요가 있을 경우에도 BDD 적용하여 진행하면 되는건가요?

    • 땡초 POWERUMC 2010.04.19 10:00 신고 Address Modify/Delete

      훔... 어려운 질문이네요.
      개인적으로는 BDD 를 구현과 아키텍처링의 일부로 보고 있습니다.
      물론 Express Blend 분야에서 BDD 와 같은 역할을 하는게
      스케치플로가 아닐까란 생각이 드네요.

 

목차

[Testing] TDD (Test-Driven Development)-테스트 주도 개발

[Testing] BDD (Behavior-Driven Development)–행위 주도 개발

[Testing] Moq.NET (T/B Driven Development)

이번에 Moq.NET 3.0 버전이 릴리즈 되었습니다. Moq.NET 는 Mocking Object 를 통해 특정 테스트를 진행하고 훨씬 TDD 기반에 근접한 테스팅을 가능하게 합니다. 즉, Mocking Object 는 실제 클래스나 개발이 완료되지 않는 시점에서부터 테스트를 가능하도록 합니다.

그런데 필자는 Moq.NET 를 이해하는 과정에서 내가 알고 있던 것보다 더 깊은 배경이 있었다는 것을 알게 되었습니다. 예를 들어, TDD 외에 BDD 또한 애자일 개발 방법론에 포함된다는 사실과, 조금은 낯설은 BDD-행위 주도 개발을 직접 체험해 보는 과정에서 말입니다. ^^ 

   

왜 TDD (Test-Driven Development) ?

TDD 가 좋으면서 쓰지 않는 이유는 뭘까요? 일반적으로 완벽한 TDD 를 수행하는 과정은 매우 힘듭니다. TDD 에 대한 이론을 들었을때는 확 가슴에 와닿지만, 이것을 몸소 체험하는 과정에서 개발자의 인내력의 한계를 올려놨다 내려놨다 하는 극한을 체험하게 합니다^^; 그러므로 일반적인 TDD 사이클인 Red, Green, Refactor 는 사람을 금방 지치게 만들죠^^; 한 사이클을 마치기 위해서는 많은 시간이 투자되어야 한다는 겁니다.

[그림1] TDD Process

하지만 우리가 TDD 를 수행하는 목적은 이러한 과정에서 코드에 대한 신뢰도를 향상시키고 품질을 향상시키고자 하는 것입니다. 그렇기 때문에 하고자 하는 목적이 보다 나은 품질을 보장하기 위해서라면 TDD 가 필요하다는 것이 머릿속으로만 느낌이 팍팍 옵니다^^;

이제 슬슬 스스로에게 딜레마다 옵니다. 좋은 줄은 알지만 누군가 나에게 TDD 를 강요한다면 아마도 전 "Oh~ No!" 라고 할 것 같네요 -_-;

 

WhiteBox Testing & BlackBox Testing

Moq 를 이야기 하기도 전에 정말 딴소리를 많이 하네요. 일반적으로 테스팅은 크게 WhiteBox Testing 과 BlackBox Testing 으로 구분할 수 있습니다. 이 두 가지 테스팅의 차이는 좁은 범위에서 내부적인 프로세스를 아느냐 모르느냐의 차이고요, 넓은 범위에서는 테스트 레벨의 차이라고 보시면 됩니다.

다음의 그림을 보면 좀 더 이해가 쉬울 겁니다.

[그림2] BlackBox Test 와 WhiteBox Test

즉 BlackBox Test 와 WhiteBox 테스트는 그 목표의 설정이 다르게 됩니다.

BlackBox Test 는 로그인 기능에 대해 요구사항이 있고, 그 기능이 반드시 가져야 할 스팩이 있을 것입니다. 요구사항을 통과하기 위해서는 로그인 기능의 스펙을 만족하면 되고, 실제 단위 테스트 등으로 그런 케이스를 통과를 하면 됩니다. 즉, 내부적으로 어떻게 동작하는지는 알아야 할 필요가 없으므로 수십/수백가지의 테스트 케이스를 통과하여 기능이 정상적으로 동작하는 것을 보장하기 위한 목표입니다.

WhiteBox Test 는 해당 기능에 대해 내부적인 구조를 기반으로 테스트를 진행하게 됩니다. 테스터는 이미 위의 로그인 기능이 내부적으로 어떤 프로세스로 진행되는지 알고 있으며, 예측 가능한 테스트 시나리오를 작성하여 테스트를 진행하게 됩니다. 이 테스트의 목적은 테스트 케이스를 통과하는 BlackBox Test 를 한 단계 뛰어넘어 잠재적인 오류까지 테스트를 통해 잡아내는 것이 목표입니다.
즉, 코드상의 Memory Leak 이나 SQL Injection, Stack Overflow 등 잠재적인 오류를 미리 찾는 경우도 있습니다. 이미 이런 기능은 Visual Studio 2005 이상부터 지원되는 정적 코드 분석(Static Code Analysis) 가 제공이 됩니다. 또, WhiteBox Test 는 코드 커버리지(Code Coverage) 의 수치를 높임으로써 테스트가 안된 코드의 양을 최소화 시키고, 궁극적으로 소프트웨어의 품질을 향상시키는데 있습니다.(Software QA)

Posted by 땡초 POWERUMC

댓글을 달아 주세요

프로젝트 어느 아래와 같은 오류가 발생하였습니다. C++/CLI 연동하는 프로젝트였는데, 로컬 설정이 제대로 되지 않았던 이유로 우회적으로 Local Test 통해 UI 있는 화면을 띄우고 테스트를 진행하였습니다.

 

그러던 중에 아래와 같은 오류가 나네요.

 

    코드 검사 모음 오류: 컴퓨터에서 Visual Studio 성능 및 검사 로깅 엔진이 이미 실행되고 있으므로 테스트 실행을 계속할 수 없습니다. 보류 중인 성능 또는 코드 검사 세션을 닫은 다음 테스트를 다시 실행하십시오.

     

 

오류 재연

 

번의 시행 착오 끝에 오류를 재연하는 시나리오를 발견하게 되었습니다.

 

  1. UI 화면를 표시하는 테스트를 만든다
  2. 테스트 메서드가 종료되지 않도록 모달 창으로 띄운다
  3. 테스트를 디버그로 실행한다
  4. 모달 창을 닫지 말고 디버그로 종료한다 (또는 테스트 디버깅 브레이크 포인트가 활성화 되었을 )
    1. 다음 테스트 시에 위의 오류가 발생
    2.  
    3. 위의 테스트 오류가 발생하면 Visual Studio 다시 실행하면 해결이 되지만, 그렇게 하기에 매번 재실행 하는 시간이 많이 아깝네요.
    4.  
    5. 해결 방법
    6.  
    7. 문제는 아래의 블로그를 통해 문제의 해결 방법을 찾을 있습니다.

    1. 간단하게 VSPerfmon.exe 프로세스를 죽이라고 하네요
    2.  
    3. %ProgramFiles%\Microsoft Visual Studio 9.0\Team Tools\Performance Tools 폴더에 VSPerform.exe 파일이 존재하는데 녀석이 테스트 데이터를 수집하는 도구네요.

    Posted by 땡초 POWERUMC

    댓글을 달아 주세요