|
자바개발자라면 한번쯤 들어봤을 법한 내용들 TDD, JUnit, 정적테스트, 성능테스트 등의 내용이 포함되어 있습니다. 게다가 내용의 수준은 높은데 문체도 어렵지 않아서 쉽게 읽어 내려갈수 있습니다. 책 제목이 정말 딱 잘 지어진 것 같네요~ 자바개발자도 쉽고 즐겁게 배우는.. 코드의 품질을 위해서 평소 알고는 있지만 우리가 쉽게 간과할수 있는 내용들이 담겨진 책입니다. 딱딱한 내용도 전혀 아니니 부담없이 읽을 책으로 추천드립니다. 글로만 설명해주시는게 아니라 실제 실습해볼수 있게 그림도 포함되어 있으니 정말 실무에 유용하게 쓰일 수 있는 책 같습니다. 아직 다 읽어보진 못했지만 앞으로 옆에두고 계속 참고할 수 있을만한 책이네요^^ |
|
2012년 1월 드디어 부활한 독후감 쓰기때문에 이 책을 접하게 되었다. 책 제목은 "쉽고 즐겁게" 인데, 쉽고 즐겁지만은 않은 책이었다. 소설책도 아니고 기술서적에 즐겁게라는 단어가 들어간 제목을 붙인 이유를 모르겠다. 아마, 책이 팔리면 돈이 벌리는 저자의 심정이 즐거운가보다. 그리고 개인적으로 별로 호감하지 않는 출판사에서 나온 책이라 나의 마음이 더욱 즐겁지 않았다^^ 1. 테스트에 대한 재미없는 이야기 Story 01 테스트 전문가들이 항상 이야기하는 기본 내용 책의 시작은 나필승씨라는 SI 개발자가 그동안 소규모 프로젝트에서 경력을 쌓아가던중 대형 프로젝트에 참여하는 설정으로 시작한다. 앞으로 나필승씨는 책의 독자와 함께 저자가 하고 싶었던 설명을 하나 둘 차근히 살펴보는 독자의 대변인이 되어 준다. 대제목을 보면 알수 있듯이 정말 『재미없는 이야기』들로 시작한다. 퇴근 후, 1장부터 3장까지 읽다가 두번이나 잠들 정도로 지루한 내용을 펼쳐놓는다. 저자는 이부분에 대해 각주를 달아 놓았는데 이론적인 글에 대해 잠이 오는 사람이면 바로 4장부터 읽으라고 권고한다. 그러나... 우선 읽을 수 밖에 없는 이 불편한 진실... 우선 테스트를 왜 하는지 테스트는 무엇인지에 대해서 정의하고 테스트의 단계별 분류와 목적별 분류를 설명하고 마지막으로 V-Model을 설명한다. 이 모든 지루한 설명은 V-Model 을 말하기 위해 기초적인 내용을 설명하여 둔 것이다. 먼저 테스트의 정의는
로 책에서는 말하고 있다. 다익스트라와 같이 어디선가 많이 들어본 사람들 이름도 나오고, 정의 하는 말도 보면 중학교 국어시간에 배웠던 삼단논법에 나오는 문장처럼 지루하다. 요점은... ① 사람은 누구나 실수를 한다(?) - 무슨 삼단 논법의 첫번째 명제와 같은 글귀가... ② 실수는 문제를 발생시키거나 실패를 초래한다. ③ 실수로 인한 문제점이나 실패를 발견하고 방지하기 위해서 테스트를 해야 한다. 이렇게 세가지이다. 이 때 중요한 점은 실수, 즉 소프트웨어의 결함을 발견하는 시기가, 프로젝트의 요구사항 분석 단계인지, 설계 단계인지, 개발 단계인지, 운영단계인지에 따라 단계가 늦어질수록 많은 비용을 지불해야 한다는 것이다. 즉, 결함을 빨리 발견해서 고쳐야 돈이 조금 깨지니까 단계별로 테스트를 수행하여 결함을 줄이도록 해야 한다고 저자는 말한다. 그럼 테스트의 단계는 무엇이 있는가?? 일반적으로 컴포넌트 테스트, 통합 테스트, 시스템 테스트, 인수 테스트의 4가지 단계로 나뉜다. 컴포넌트 테스트는 단위 테스트나 유닛 테스트라는 용어로 널리 사용되는 단계이다. 각 컨트롤 컴포넌트들을 테스트 하는 단계이다. 통합 테스트는 사용자 화면과 서버에서 동작되는 온라인 서비스를 한대 묶어서 테스트 하거나 기능 사이의 연결 관계를 테스트하는 것으로 한 시스템 내에서 컴포넌트간의 관계를 테스트 하는 컴포넌트 통합 테스트와 두 개 이상의 시스템의 관계를 테스트 하는 시스템 통합 테스트로 분류할 수 있다. 다음으로 시스템 테스트는 개발된 시스템이 제대로 동작하는지(Verification)을 의미하고, 인수 테스트는 고객이 원하는대로 동작하는지 (Validation)을 확인하는 단계이다. 그리고, 드라이버와 스텁에 대해 개념을 이야기 하는데, 스텁 같은 용어는 뭐 나중에 JUnit에서 다시 나오니 이 장에서는 반드시 이해할 필요는 없고 우선은 목적으로 분류한 테스트에 대한 이야기를 살표보면!
이렇게 네가지 이다. 먼저 기능적 테스트는 요구사항에 맞게 또는 비즈니스 프로세스대의 시나리오처럼 시스템이 올바르게 작동하는지를 점검하는 테스트이다. 비 기능 테스트는 성능 및 부하, 사용성 등 시스템이 얼마나 잘 수행되는지를 확인하는 것이다. 구조 테스트는 화이트 박스 테스트에 속하며 시스템의 구조나 아키텍처를 점검한다. 마지막으로 이름도 어려운 확정 및 회귀 테스트는 한쪽에서 결함을 고쳐 시스템의 일부를 수정한 경우 정상적으로 작동하던 다른 부분에서 결함이 생기지 않는지 점검한다. 지금까지 이렇게 지루한 설명을 늘어논 이유는 V-Model 이라는 개발을 중심으로 각각의 요구사항, 디자인 단계와 테스트 단계별로 연관성을 보여주는 하나의 모델을 설명하며 1장을 끝낸다. Story 02 또 재미없는 테스트 이야기 드디어 2장이다. 저자도 알긴 아는가보다. 또 재미없는 이야기라니... 그럼 좀 재미있게 풀어 쓰던가... 대한민국 육군도 아니고, 또 「필승」이 등장하면서 2장은 시작한다. 먼저 정적테스트는 우리가 일반적으로 알고 있는 리뷰를 의미하며 리뷰를 통하여 산출물의 품질을 높이기 위한 목적을 가지고 있다. 정적테스트는 다음과 같이 몇가지로 분류된다.
이외에, 동적 테스트와 동적 테스트의 기술에 따른 분류, 블랙박스, 화이트박스 테스트의 의미 설명과 커버리지 개념을 하면서 장을 마친다. 여기까지 읽는것도 지루했지만, 책에 대해 리뷰 쓰는 것도 무척이나 지루하다. Story 03 테스트 그냥 하면 되지 뭘 분석해 경계값 분석(Boundary value analysis)와 동등 분할(Equivalence partitioning)이라는 용어에 대해 개념을 알아보는 장이다. 52페이지에서 잔고가 100원밖에 없는 경우에는 이 경우가 통하지 않는다는 말이 무엇인지 모르겠다. 53페이지 표를 보면 무엇을 말하고 싶은지는 알겠지만, 저자의 설명이 매끄럽지 않아 이해하기가 어렵다. 경계값분석은 입력된 값이 프로세스를 수행하는데 올바르게 동작하는 임의의 한계를 만족하는지를 확인하는 것이고, 동등 분할은 입력된 값에 대한 일정한 기준을 가지고 동일한 결과를 만들어 내고, 이러한 결과를 한데 묶어 기준 구간을 만드는것이다. 이외에 복잡한 입력값에 사용할 수 있는 결정 테이블(Decision table)을 설명한다. 복잡한 값이라는 말은 경계값 분석이나 동등 분할처럼 한가지 파라미터만 가지고 결과를 도출하는게 아닌 두가지 입력값에 의한 결과를 만들어내는 분석이다. 다음으로는 프로세스의 진행 단계의 변화를 나타내는 상태천의도를 설명한다. 저자는 transition을 전의(轉移)라고 표현했는데, 천의(遷移)가 맞는 표현이 아닌가? 뭐 아무튼 테스트를 위해 입력값을 분석하는 방법과 프로세스 진행에 따라 변화된 상태에서 테스트하는 방법을 설명하고 3장이 끝난다. 2. 단위 테스트 쉽게 해보기 여기서부터는 앞서 살펴봤던 테스트중에서 단위 테스트라는 범위에서 사용할 수 있는 자동화 테스트 도구를 소개하고 간단히 사용법을 알아보는 내용이다. 중간에 TDD, 정적 테스트등의 개념을 설명하는 내용이다. Story 04 JUnit 이름은 많이 들어 봤는데... 자바를 사용하는 환경에서 단위 테스트에 사용하는 프레임워크인 JUnit에 대한 설명이다. 자바뿐만 아니라 닷넷과 루비,C/C++,Python,DB,PL/SQL, 자바스크립트/DHTML, PHP 등 다른 언어에서 사용할 수 있는 xUnit 도 있으며, 다운로드 하여 설치하는것과 테스트 클래스를 작성하는 법을 설명한다. 다음으로는 JUnit 4.x 버전부터는 JDK 5.0에서 지원하는 어노테이션을 사용할 수 있다는 것과 테스트를 위한 대체 객체(Test Double)을 Stub, Spy, Mock Object, Fake Object로 세분화하여 개념을 설명한다. 마지막으로 자바 기반의 Mock 중에서 Mockito를 사용하는 예제를 보여주면서 장을 마친다. 4장부터는 자바 코드가 나오기 시작해서 눈에 좀더 빠르게 들어오고 읽는 속도도 빨라졌지만 실무에서 JUnit을 정용하거나 Mock 을 작성하기에는 무리가 있어보인다. 예제처럼 단순한 코드라면 문제가 없겠지만 현실에서는 훨씬 복잡한 코드가 많아 개인적으로는 IDE 툴에서 디버깅 하면서 단위 테스트 하는게 더 빠르다고 생각한다. Story 05 TDD가 뭐야? TDD(Test Driven Development)는 테스트를 위한 개발전 테스트 스크립트를 먼저 만들어서 새로 개발하는 코드가 올바르게 동작하는지를 점검하는 개념이다. 앞서 살펴본 JUnit 은 코드 개발후에 작성한 코드가 올바르게 동작하는지 테스트 코드를 작성한것과는 반대 개념이다. 그리고 TDD 사용에 대한 저자의 견해도 9시 출근하고 밤 12시나 1시에 퇴근하는 바쁜 사람들에게 전사 표준이니 꼭 사용하라는 식으로 설득하고 싶지 않다고 한다. 그러나 TDD를 사용해야 하는 이유를 설명하기 위해 기존 개발자들의 습관을 지적하고 있다. 로거나 출력문을 포함한 코드가 운영 시스템에 적용되었을때 시스템 성능과 시스템 자원면에서 불리해지는 점이다. 그러나 전혀 공감이 안된다. 운영시스템에서 누가 debug 단위로 로그를 출력하는지 모르겠고, 출력문이 물론 부하를 주긴 하지만 그러한 성능 저하보다 DB와 연동 되었을때 SQL구문이 얼마나 효율적인지(튜닝되었는지)가 더 큰 영향을 준다는게 본인 생각이다. 다음으로는 테스트 해야할 대상을 메소드 단위로 볼때, 메소드의 갯수만큼 수동으로 테스트 하는 경우 테스트 시간이 증가한다는 점을 내세우고 있다. 이점은 공감하지만, 굳이 TDD가 필요한가? 실무에서 프로젝트 진행 도중 요구사항이 변하는 경우를 수없이 보아 왔다. 이러한 경우 테스트 스크립트와 업무 코드를 모두 수정해야 하는 부담감이란... 마지막은 TDD를 적용하기 어려운 웹 또는 통합환경과 리팩토링에 대해 간단한 설명을 하고 장을 마친다. Story 06 웹 UI도 자동화 테스트가 가능하구나 제목 그대로, 웹 페이지에서 테스터가 버튼을 누르고 값을 입력하면서 테스트를 진행하던 것을 자동화 할 수 있는 여러가지 도구 중에서 Selenium에 대해 설명한다. 이 도구는 매크로처럼 사용자의 행동을 녹화 하거나 입력값과 동작을 코드로 작성하여 웹 페이지를 호출하는 방식으로 동작한다. 이때 제약사항은 UI기반 테스트이므로 단순하지만 지루한 코딩을 하는점과 HTML과 스크립트가 아닌 플래시나 ActiveX기반의 컨트롤은 제어할 수 없어 플렉스나 ActiveX를 사용하는 국내 실정상 사용하기 어렵다는 점이다. 또 일부 브라우저에서만 동작하는 제약도 있다. 그리고 113 페이지 밑에서 3번째 줄에 바꾸刊면 이렇게 된 오타가 있다. Story 07 웹 URL 요청을 자동화해서 테스트 해보자 솔직히 이번장은 왜 분리했는지 모르겠다. 앞의 6장과 같이 적었어도 될 내용으로 구성되어 있다. 이번장은 Selenium과는 약간 다르게 URL 호출하고 결과 페이지를 분석(파싱)하여 동작하게 해주는 HttpUnit을 소개한다. 그러나 자바스크립트의 분석이 완벽하지 않아 에러를 출력하거나, ActiveX를 사용하면 무용지물이라는 제약사항이 여전히 존재한다. 마지막으로 JUnitPerf를 사용하여 응답시간이나 부하 테스트를 하는 예제를 소개한다. 6장 7장은 웹 기반 환경에서 자동으로 테스트할 수 있는 몇가지 툴을 소개해주어 새로운 정보를 알 수 있어서 흥미롭게 보았지만 역시 실무에서 쓰기에는 무리가 있어 아쉽다. 3. 정적인 테스트하기 Story 08 이것도 테스트구나 8장은 리뷰에 대해 이야기한다. 품질 담담자 관점에서 접근한 리뷰를 살펴보고 개발자가 할 수 있는 가장 쉬운 리뷰로 코드 리뷰를 이야기한다. 본격적인 코드 리뷰 이야기를 시작하기 전에 XP(eXtream Programming)과 Pair Programming 을 소개한다. 이 중에서 Pair Programming은 아직까지 경험하지 못했는데, 개발자들이 많이 모이는 웹 사이트를 가보면 항상 책에 있는 내용처럼 개발자 둘이 서로 말도 안하는 사이가 된 경우도 있다라는 말이 보인다.(알고보면 그 게시물 주인이 이 책의 저자인것은 아닐까??) 다음으로 코드 리뷰를 쉽게 할 수 있는 도구로 Crucible 를 소개하는데 상용이어서 아쉽다는 말과 함께 오픈소스인 PMD와 FindBug를 소개한다. PMD 하니까 생각나는데, 전에 모 사이트에서 PMD로 코드 인스펙션을 수행하였으니 이에 대해 조치를 해달라는 요청이 있었다. 그런데, PMD 가 잡아낸 코드중에 협력업체의 솔루션 중 코어 프로그램 소스가 대상에 포함되어 있었다.(코어 프로그램 소스를 왜 형상관리에 등록해 놨던건지...) 이때 나는 이 코드들은 정상 코드이므로 PMD 체크 목록에서 빼달라고 요청하였으나 결국 요청은 돌고 돌아 코드를 수정하라는 지시가 다시 내려왔고, 협력업체에 연락하여 코드 수정에 대해 알리고 PMD 점검 목록에 나타나지 않도록 편법으로 코드를 작성해야 했다. 이번장 마지막에 나오는 내용중에 코드 리뷰 툴에서 분석해서 나온 내용은 개발자를 힐책하고, 관리하는 목적으로 사용하면 안된다는 것을 알아두자. 라는 글이 있는데 그때 당시 이러한 내용에 대해 어필할 수 있었으면 좋았을텐데라는 생각을 해본다. PMD에 관한 다른 에피소드로는 PMD라는 단어를 처음 듣고 무슨 약어라고 생각한 나머지 상사인 차장님께 물어본적이 있다. 그러나 답변은 "글쎄??" 였다. 그런데 이 책을 보면 PMD 홈페이지의 내용을 발췌하여 PMD라는 이름의 기원을 설명한다. 결국 아무런 의미도 없으며 그냥 발음이 듣기 좋아서라는 재미 있는 사실을 알려준다. 마지막으로 Check Style에 대해 소개하는데, 이 도구는 오류를 찾는것보다 개발 표준에 맞게 코드를 작성했는지 점검한다. 이번 장을 정리하며 저자는 코드 리뷰는 QAO또는 QA가 하는것보다 개발자가 하는 것이 옳다고 말한다. Story 09 정적 테스트 툴 살펴보기 앞에서 소개한 PMD 와 FindBugs를 통합 개발 환경 도구인 이클립스 플러그인으로 추가하고 사용하는 방법과 분석 규칙에 대한 약간의 소개 및 사용자 정의 규칙을 추가하기 위한 참고사항으로 구성되어 있다. 4. 통합 테스트 쉽게 해보기 Story 10 통합 테스트도 자동화할 수 있어? CTIP(Coninuous Test & Integration Platform)에 대해 설명하고 형상관리에 대한 간략한 이야기를 한 뒤에 통합 빌드에 대한 이야기를 하고 있다. 통합 빌드의 수행절차는 AntHill 의 동작을 예로 들어 설명하고 이외에 통합빌드에 필표한 몇가지 요소를 이야기 한다. 이 과정에서 CTIP 에서 Test 코드가 빠지고 CIP로 변형되는 경우 좋지 않다는 것과 통합 빌드 환경 구축시 유의할 점에 대해 설명한다. 먼저 통합 빌드에 필요한 요소로는 형상관리 서버, 통합 빌드 툴, 빌드 스크립트, 테스트 코드, 테스트 시스템(WAS + DB), 커버리지 툴이 필요하다고 한다. 이중 웹 기반이라는 특징을 가진 통합 빌드 도구 세가지 Hudson, AntHill, Cruise Control 을 소개한다. Story 11 Hudson에 대해서 알아보자 앞장에서 소개한 Hudson 에 대해 장점, 설치방법, 예제 빌드 스크립트를 작성하는 내용으로 이루어져 있다. 그리고 참고사항으로 Maven에 대해 언급하며 더 궁금한 점이 있으면 참조하라는 책소개도 있다. (그런데 참조 도서의 출판사가 이 책의 출판사와 동일하다^^) Hudson 은 WAS 위에서 동작한다. 저자는 이를 톰캣에서 구동하도록 사용하였고 부록에 톰캣 다운로드와 설치 방법을 적어두었다. Hudson 내부적으로 Winstone 이라는 내장 WAS가 있지만 책에서는 톰캣을 사용하여 진행하였다. 예제 빌드를 작성하면서 프로젝트 추가, 프로젝트 상세 설정, 빌드 수행, 빌드 결과 확인이라는 4단계로 저자 나름대로의 절차를 정리하여 소개하고 각 절차별로 설정하는 방법을 설명한다. 로컬 환경에서 간단한 빌드를 수행하는 예제를 보여주어 Hudson 을 어떻게 사용하는지 대략적으로 살펴보고 나면, Hudson 의 장점인 다양한 플러그인을 추가하여 빌드 작업을 수행하는 예제를 설명한다. Subversion, PMD, Findbugs 플러그인을 설치하고 형상관리 서버에서 소스를 내려받아 Ant 로 빌드하고 결과를 XML로 출력하여 결과를 보는 과정을 보여주고 이번 장을 마친다. 5. 성능 테스트는 이렇게 Story 12 성능 테스트가 뭐야? 성능 테스트에 대해 설명하기 전에 성능 테스트를 하는 이유를 설명하고 TPS(Transaction Per Second)/초당 처리 트랜잭션 수를 설명하기 앞서 요청 기준 트랜잭션과 사용자 트랜잭션을 구분하여 이야기한다. 몇가지 그래프로 TPS와 응답시간 그리고 상관관계를 설명하고 있으며 응답시간에 관해 생각해볼수 있는 간단한 퀴즈도 있다. Story 13 성능 테스트 한번 해볼까? 성능 테스트의 종류를 4가지로 나누어 설명한다.
다음으로 성능 테스트에서의 시간 구분을 Response Time 과 Think Time 으로 나누어 개념을 설명하고, 동시 사용자의 정확한 의미를 영어로 구분 하여 설명한다. 사용자의 종류는 다음과 같이 분류한다.
성능 테스트에 대한 종류와 동시 사용자의 개념을 설명한 뒤에는 테스트 대상을 선정하는 기준과 목표 TPS를 구하는 간단한 식을 설명하고 스크립트에 대한 예제 코드를 간단히 보여주고, 성능테스트에 대한 고려사항으로 13장을 마친다. 마지막 절에 고려사항으로 3가지를 이야기 했는데, 첫번째 보안 모듈에 대한 이야기는 프로젝트 수행 중에 내가 직접 겪은 일이라서 그런지 조금은 반가운 기분이 들었다. 사실 저자가 말하듯 일부 상용 프로그램에서는 보안모듈을 연결하여 테스트 할 수 있다고 하지만, 비용이 어마 어마 하기 때문에 도입하기가 힘들다는 불편한 진실... 12장에서 도입부에서도 가격이 어마어마 하다고 말했듯이 정말 억소리 나는 가격때문에, 보안 구간으로 설정된 코드를 제거하는 대대적인 작업을 거친 뒤 성능 테스트를 진행한 추억이 새록새록 떠올랐다. Story 14 JMeter가 뭘까? 성능 테스트를 위한 도구 중에서 무료로 사용할만한 유명한 툴로 MS Web Application Stress Toll, JMeter, Grinder, Faban 등이 있고 국산으로는 아직 개발중인 사바나가 있는데, 그중에서 JMeter를 설치하는 방법과 JMeter를 위한 기능을 제공하는 나쁜남자(?) Badboy라는 윈도우 OS 전용 프로그램을 소개한다. 다음으로 스크립트를 작성하는 방법을 설명하는데, 직접 입력하여 생성하는 방법과 Proxy 를 이용하여 스크립트를 레코딩 하는 방법 그리고 Badboy를 이용하여 스크립트 레코딩 하는 방법을 설명한다. 그리고 JMeter 에서 결과를 검증하는 방법과 성능테스트시에 참조하여 사용할 데이터를 CSV 만들어 사용하는 방법, 가장 중요한 성능테스트를 수행하는 과정과 성능테스트를 수행할때 모니터링 해야 하는 항목을 표로 정리하여 설명한다. 실제로 프로젝트에서 성능테스트를 진행할때 TPS 이외에도 시스템의 자원 사용현황, DB, 네트워크등을 함께 모니터링 했었기에 저자가 하고자 하는 말이 무엇인지 알수 있었다. Story 15 결과 어떻게 분석하라고? 성능 테스트를 수행하고 나면 얻을 수 있는 응답시간을 TPS 로 변환하여 살펴보는 것과, 고객이 응답시간이 느리다고 말할 수도 있는 올바르지 않은 예제 그래프를 보여주면서 결과값을 어떤식으로 잘 표현해서 나타내야 하는지를 설명한다. 성능 테스트 결과값으로 얻은 동시 사용자수와 응답시간을 가지고 TPS 로 변환하여 그래프를 그리는 과정까지를 설명하며, CPU 사용량 분석과 정리하는 방법 성능테스트 결과보고서를 작성하는 방법을 설명한다. 6. 보안 테스트도 어려운 것만은 아니네 Story 16 보안이 그렇게 중요한가? 도입부에, 필승씨가 눈물을 머금고 보안테스트에 대해 준비하는 상황이 왠지 낮설지 않았다. 보안성 심의라고 갑자기 와서는, 외부에서 툴을 이용하여 사이트를 점검하고, 보안모듈의 취약점을 이용하여 암호화된 데이터를 복호화 해내던 모 보안회사의 지적에 대응할때 나는 혼자였던 상황이 오버랩 되었다...생각해보면 그 시절에는 참 많은 것을 했었다. 우선 보안에 대해서 네트워크, 서버, 애플리케이션, 데이터 보안으로 나누어 설명하고 잘 알려진 취약점(공격 기법)과 보안 테스트 도구를 소개하는 장이다. 16장 제목이 보안이 그렇게 중요한가? 인데 결론은 보안이 중요하다는 것이다. Story 17 보안 테스트의 기초를 알아보자 보안 테스트의 정의를 설명하고 인코딩, MD5 와 SHA1과 같은 해쉬 생성 알고리즘을 소개한 뒤, 보안테스트 도구를 소개한다. 보안 테스트의 정의는 O'Reilly 의 Web Security Testing Cookbook 에서 다음 정의를 인용했다. 보안테스트 : 악의적이거나 적대적인 입력에 대응할 수 있도록 정의되어 있는 요구사항을 만족시키는지 확인하고, 근거를 제공하는 것 보안 테스트 도구로는 CAL9000 과 Burp Suite 를 소개하고 보안 테스트에 익숙해지기 위한 방법으로 WebGoat 를 소개한다. 7. 프로젝트를 마무리하는 테스트는 이런 것이 있구나 Story 18 시스템 오픈 여부를 결정하는 출하검사와 인수 테스트 이번장에서는 지금까지 살펴봤던 테스트 자동화가 아닌 사람이 수동으로 테스트를 수행하여야 하는 상황이 있다는 것을 말하면서 시작한다. 무엇보다 업무의 분류에 따라 테스터의 경험이 중요한 경우가 있다는 것과 수동 테스트의 종류로 체크리스트 테스트, 소프트웨어/시스템 공격, 탐색적 테스트에 대해 간단히 설명한다. 그리고 제품 생상 공장에서 쓸법한 용어인 출하검사와 인수테스트에 대해 저자의 경험을 바탕으로 유의사항과 테스트 방법, 그리고 프로젝트 초기에 인수 테스트 결과에 대해 목표를 결정하여 악덕 고객에게 끌려 다니지 않는것이 필요하다는 이야기로 정리한다. Story 19 인수 테스트를 위한 Fit 와 FitNesse 이번 장을 보면서 이 책의 저자는 NHN 에서 일한다는 사실을 알게 되었다.(그랬구나...) 그러면서 STAF 를 바탕으로 만들었다는(결국 모방한것으로 보이는) NTAF 를 이야기하고 어느 프레임워크나 장점으로 내세우는 단어인 유연, 확장 이런말을 적어 놓았다. 난 NTAF 광고 보러 책을 구입한게 아닌데...어찌 되었든 Fit와 FitNesse에 대해 설명을 하고 있는데, Fit 는 엑셀이나 MS 워드의 표를 만들줄 안다면 개발에 대해 잘 모르는 사람이라도 테스트 케이스를 만들수 있는 도구라고 한다. Fit는 명령 프롬프트에서 작업을 수행하고, HTML 형태의 결과를 확인할 수 있는데, 이러한 작업을 좀더 쉽게 해주는 것이 FitNesses 라고 소개하고 사용법에 대해 설명한다.실제로 FitNesses 사용하는 방법은 Fixture 소스를 작성하고 워드나 엑셀에서 데이터로 사용할 표를 작성하여 FitNesses 위키 페이지에서 붙여 넣기 한뒤, 위키에서 테이블을 생성하는 형식에 맞추어 작성해주면 된다. 그리고 바이블과 같은 책이 아니고 테스트에 대해 개념을 이해하는 정도로 도움이 되었으면 좋겠다는 작가의 말고 함께 생각보다 두꺼운 책의 내용이 마무리 된다. 제목처럼 쉽고 즐겁게 배우는건 아니었지만 테스트에 대한 전반적인 내용을 살펴보고 다양한 도구에 대해 알 수 있는 내용이 많이 있어 유익했다. 그리고, 사실 책의 내용과 구성에 대해 어느정도 불만이 있었는데 마지막 저자의 말에서도 알 수 있듯 바이블 형태가 아니고 개념서 정도라는 설명과 책의 시리즈가 블로그2북 인점을 감안할때 어느정도 납득할 수 있었다. |
|
이 책은 다른 테스팅 관련 책보다 쉽고, 다양한 테스트들이 왜 필요한 지에 대해서, 저자의 경험을 바탕으로 재미있게 설명해 주고 있다.
사실, 자바관련 오픈소스의 무료 툴과 상용 툴들이 넘쳐나고 있는 현실에서, 어떤 툴을 사용해야 하는지 헷갈릴 때가 많다. 이러한 상황에서 각 테스트 종류에 따라 어떤 툴을 사용하는 것이 도움이 되는지를 방향을 알려주는 책이라고 하겠다.
1장에서 3장까지 테스트관련된 개념과 용어들을 설명하고 있다. 프로젝트에 투입된 개발인력들의 역량이 너무나 다양하기 때문에, 전산을 전공하지 않은 사람이 기능과 비기능의 구분, 정적과 동적 테스트의 구분, 검증(Verification)과 확인(Validation)의 구분, 블랙박스와 화이트 박스 테스트를 사용해야 하는 대상의 구분, 회귀테스트의 의미 등을 이해하지 못하여, 같은 단어를 사용하고 있지만 다른 의미로 사용하여 의사소통의 오류를 발생시키는 경우가 생각보다 많은 것 같다.
4장의 JUnit을 적용하기가 어려운 것이 현실인 것 같다. TDD를 도입하려고 해도 , 프로젝트의 참여자들의 협조가 없으면 거의 불가능하다. PM은 초기의 개발진척상황에 너무 집착하지 말고 테스트 코드를 반드시 작성하도록 독려해야 하고, 분석가와 설계자들은 특정 기능에 대한 테스트케이스를 명세해주고, 기술지원이나 QA팀은 개발자가 테스트코드를 작성해야지만 빌드가 될 수 있는 환경을 만들어주고, 개발자는 테스트 코드를 먼저 작성하는 습관을 들여야지만 가능한 것 같다. 리팩토링도 경험이 많고 역량있는 개발자는 유지보수나 기능의 확장을 위하여 수시로 자신이 담당하고 있는 부분을 리팩토링하지만, 초급개발자가 리팩토링하는 경우는 드문 것 같다. 초급개발자는 결과를 만들어 내기도 힘들기 때문이 아닐까 생각해 본다.
6장의 Selenium은 저자가 이야기 했듯이 ActiveX 이슈때문에 활성화가 생각보다 잘 안 되는 것 같고, FireFox를 사용해야 한다는 것도 걸림돌이 되는 것 같다.
7장 웹 응용프로그램인 경우에는 HttpUnit을 이용하여 단위테스트를 하는 방법을 설명하고 있다. 적용하면 좋겠는데.... 이러한 코드를 자동으로 생성해 주는 것이 아니라면... 쉽지 않은 이야기인 것 같다.
8장과 9장에서 PMD와 FindBug를 통한 정적테스트하기에 대해서 설명하고 있다. PMD를 이용하면 룰(Rule)에 의하여 개발자들이 작성한 모든 프로그램을 전수조사할 수 있다. (java 언어 기준) 이것은 checkstyle과 같이 프로젝트 표준의 준수여부를 확인하는 데 도움이 되는 것 같다. 실제 프로젝트에서 PMD를 적용하는 사례가 최근에 많아 졌는데 새로운 룰은 XPath를 이용하는 것이 편리한 것 같다.
10장과 11장에서는 통합테스트를 설명하면서 통합빌드를 위한 Hudson에 대한 설명이 나와 있다. Oracle과 상표권 문제때문에 Jenkins로 이름이 바뀌게 된 Hudson은 지속적 통합툴(Continuous Integration)로서 강력한 지위를 차지하고 있는 것 같다. 지속적 통합툴을 적용하여 일일빌드를 하게 되면, 매일 전체 시스템의 빌드되고, 빌드에 관련되어 문제가 있는 모듈이 확인되기 때문에, 나중에 통합을 위한 노력이 상당히 줄어드는 것 같다.
이 책에서는 형상관리 도구에 대해서 많이 설명하지 않고 있는데... 최근에는 CVS보다 SVN(SubVersion)이 많이 사용되고 있는 것 같다. 형상관리 툴을 무엇으로 사용하느냐에 따라서 형상관리서버에서 일괄로 소스를 가져와 통합빌드하는 작업의 난이도가 달라지는 것 같다.
12장과 15장에 걸쳐서 성능테스트의 기본개념, 관련된 척도, 성능계획서, 시나리오, 부하발생기 툴(특히 JMeter), 결과 분석, 보고서 등에 대해서 설명하고 있다. 성능테스트를 한 번이라도 해 본 사람은 저자가 이야기한 것처럼 이 작업이 매우 힘든 작업이라는 것을 알고 있을 것이다. 부하발생기 툴의 라이센스 정책에 따라 왜 그리 비싼지 모르겠다. 이에 비해 무료툴인 JMeter도 상당히 훌륭한 툴이다. 개념 및 용어가 상용툴과 다른 부분은 이 책에서 설명되어 있으며, 실제로 사용해 보면, 상용툴에 비해 편의성은 떨어지지만, 부하를 발생하고 결과를 해석하는데 큰 무리가 없다. 참고로, 목표 TPS나 목표 응답시간의 설정 부분은 정말 주의해야 한다. 잘못된 목표치는 성능테스트 관련된 사람들을 너무나 힘들게 하는 것 같다.
16장과 17장에서 보안테스트에 대해서 이야기하고 있다. 최근 금융분야에서 보안사고가 자주 발생하다 보니, 보안이 핫 이슈가 되고 있다. 저자가 이야기하고 있는 툴을 통한 연습도 필요하지만, 실제로는 국정원에서 보안인증을 받은 제품들을 설치해야지만 보안관련 감리나 보안성심사 등을 통과하는데 유리한 것 같다.
18장의 출하검사는 일반적이지 않은 것 같았다.
19장의 인수테스트에서 Fit과 FitNesse를 적용하는 방법에 대해서 설명하고 있다. 이부분을 실무에 적용하는 방법에 대해서는 고민을 해 봐야 할 것 같다. 너무 자세하게 적어서 책을 읽는 재미를 줄인 스포일러가 되지 않았나 생각해 본다. 하지만, 내가 IT 분야에서 10년 넘게 종사해 본 결과, 불행히도 IT 관련자 중 적지 않은 사람들이 IT분야 서적을 많이 읽지 못한다. 게을러서라기 보다는 월화수목금금금에 시달리고, 당장 눈앞에 쌓여 있는 지침서나 매뉴얼을 읽어서 익숙해 져야하고, 수많은 버그들과 싸우기에도, 시간이 모자라기 때문이다. 이런 현실을 너무나 잘 알기에, 챕터별 요약 및 경혐을 기반으로한 사견은, 시간을 줄여주고자 하는 먼저 고생했었던 사람의 의도로 이해해 주었으면 좋겠다.
주제가 쉽지 않음에도 불구하고, 전반적으로 책의 내용은 읽기 쉽게 구성되어 있다.
아쉬운 점은, 다른 컴퓨터 관련 책의 경우에는, 요리책과 같이 특정 작업을 수행하는 절차를 화면을 캡처하여 자세히하나하나 단계별로 설명하고 있는데 비하여, 이 책은 그렇게까지 자세하게 설명하지 않고 있다. 아마도, 책의 분량이 늘어나는 것도 부담스럽고, 원래 저자가 의도한 방향과 맞지 않아서 그런 것 같다. 대신 부록에 관련 참고할 수 있는 사이트정보를 제공하고 있다.
한가지.. 사족을 단다면..., 1장에서 V-model을 설명하면서 "폭포수모델 같은 방법론은 더 이상 사용되지 않기 때문에..." 이런 이야기가 있다. 그런데... 아직까지도 폭포수 모델을 사용하여 프로젝트 진행이 되는 경우가 많다. 이것은 폭포수 모델 자체가 다른 모델에 비해서 대단히 우수하기 때문이라기 보다는, 시스템 구축계약을 맺을 때 단계별로 대금지급 기일을 정하고, 각 단계별로 감리수행결과를 근거로 대금을 지급하는 경우가 많기 때문인 것 같다. 이러한 현실을 설명해 주는 것도 필요하지 않을까 하는 생각이 들었다. |
|
저자의 스타일을 좋아하기에 무조건 구매했던 책입니다.
대략 알고 있던 테스팅의 기본부터 차근차근 설명해주고, 시리즈의 스타일을 그대로 유지하고 있어서 그림과 그래프도 많네요. 그리고 내용들을 등장 인물들의 대화로 풀어서더욱 친근하게 다가오네요.
전 개인적으로 나오는 인물들의 이름이 너무 직관적이라서 재미있게 읽었습니다. |