흔적s

출처 : http://egloos.zum.com/choungjae/v/470630

너무 정리를 잘해놓으신 사이트가 있어서, 사라지기 전 얼른 펌 합니다.

귀한 지식 정리 감사합니다.

LoadRunner(로드런너) 사용법

http://choungjae.egloos.com/470630

오늘은 성능테스트 및 로드런너에 대해 포스팅 하고자 합니다. ^^

 

저도 아직 얕은 지식이기 때문에, 네이버에서 도움을 얻고자 검색을 해봤는데..

로드런너에 대한 정보가 너무 없더라고요.. OTL..

그래서 저처럼 로드런너의 기능 및 사용법에 대해 궁금한데, 검색이 안돼는 분들을 위해서!!

로드런너에 대해 정보를 공유하고자 작성해 봅니다.

 

회사에서 점심시간에 틈틈히 짬내서 작성하다 보니.. 엄청 오래 걸렸네요. ㅠㅠ

각설하고!! 시작하겠습니다!! ㅎㅎ

 

아시다시피 로드런너는 HP에서 제공하는 값 비싼?? 성능테스트 툴 입니다.

QA나 테스터가 성능테스트를 성공적으로 수행하기 위해서는, 우선 성능테스트에 대한 전반적인 지식이 있어야 한다고 생각하기에 간략한 설명부터 시작해 보도록 하겠습니다.

 

성능테스트에서 성능은 시스템의 처리량, 속도, 메모리 사용량 등이 주어진 환경에서 명시된 기능에 대해 정상적으로 수행하는 것을 말합니다.

사용자 요청을 처리하기 위해 소요된 응답시간은 클라이언트에서 측정하고, 단위 시간당 시스템에서 처리되고 있는 처리량은 서버에서 측정합니다. 보통 웹기반 시스템에서는 성능 측정의 기준을 TPS(Transaction Per Second - 단위시간당 처리건수)로 합니다.

 

성능테스트의 목적을 다음과 같이 간략하게 정리해 볼 수 있습니다.

1. 안정적인 서비스를 위해 안정성 확보

2. 다수의 사용자에 의하여 발생할 수 있는 부하에 대한 예방

3. 서버의 최적화를 위해 서버환경 검사

4. 병목 구간을 파악하여 수정

 

그리고, 목적에 따라 다음과 같은 3개의 유형으로 분류할 수 있습니다.

1. 단위테스트 - 단위 별 업무의 최대한의 성능을 측정하는 단계

2. 통합테스트 - 목표를 정해놓고 계산된 부하를 발생시켜 측정하는 단계

3. 임계테스트 - 정해놓은 목표없이 도출할 수 있는 최대 성능을 측정하는 단계

 

아래는 성능테스트의 주요 용어인데요. 꼭 읽어보시기 바랍니다.

1. Concurrent Users (동시사용자) - 해당 시스템을 사용하기 위한 사용자로서, Active Users와 Inactive Users로 분류할 수 있습니다.

Active Users는 Request를 수행한 후, 응답을 기다리고 있는 사용자이며, Inactive Users는 Request를 수행하지 않고 대기중인 사용자 입니다.

2. Load (부하) - 사용자들이 테스트하고자 하는 시스템을 단위시간당 몇 건으로 호출 하고 있는지에 대한 빈도

3. Think Time (대기시간) - 사용자가 다음 요청을 전송하기 전까지의 시간

4. Response Time (응답시간) - 사용자 요청을 처리하는데 소요되는 총 시간

5. Request Interval (호출 간격) - 호출간격 = Response Time + Think Time

6. Throughput (처리량) - 대상 웹 서버가 부하발생 클라이언트에게 송신한 데이타량

7. Vuser (Virtual user) - 시스템에 부하를 주기 위한 가상 사용자

8. Transaction (작업단위) - 하나의 작업이 시작하여 완료되는 시점을 하나의 트랜잭션으로 정의

9. TPS (단위시간당 처리건수) - 단위 시간에 처리 가능한 트랜잭션의 수(TPS = ConcurrentUser/Request Interval)

10. Test Script - 시스템의 성능에 대해 확인하기 위해서 레코딩한 소스

11. Test Scenario - 어떤 방식으로 시스템에 부하를 줄 것인지 정하는 방식

12. 병목현상 - 부하가 많이 걸려 전체 시스템에 영향을 주는 현상

 

성능테스트 프로세스는 각 회사마다 다르지만 저는 다음의 4단계로 분류해 봤습니다.

기획 및 분석 > 설계 및 구현 > 테스트 실행 > 결과 분석 및 평가

1. 기획 및 분석 - 요구사항에 대해 검토한 후, 계획 수립

2. 설계 및 구현 - 성능 목표를 설정하여 테스트 시나리오를 설계하고 테스트 환경을 구축한다.

3. 테스트 실행 - 성능 테스트를 실행하여 모니터링 한 후, 해당 결과가 초반에 설정한 성능 목표에 충족하는지 확인한다.

4. 결과 분석 및 평가 - 결과 데이터를 병합하고 유관부서와 공유하여 함께 분석한다.

 

이것으로 성능테스트에 대한 간략한 설명을 마치고...

로드런너 사용방법에 대해 말씀 드리겠습니다.

로드런너는 크게 3가지 방법으로 분류할 수 있습니다.

1. 스크립트 작성

2. 시나리오 작성

3. 실행 및 결과분석

 

아주 간단하죠??

 

자 이제 1번인 스크립트 작성부터 시작하겠습니다.

 

시작 > Mercury LoadRunndr > Applications > Virtual User Generator 선택하여 Vugen 실행

New 클릭하여 Web (HTTP/HTML)을 선택

 

 

 

URL Address에 레코딩 하고자 하는 주소를 입력 합니다.

Record into Action

- Init: 시작하면서 한번만 실행되는 영역

- Action: 반복적으로 실행되는 영역

- End: 종료되면서 한번만 실행되는 영역

 

 

Start Recording 에서 Options을 선택하여 설정을 몇가지 변경해줘야 합니다.

Options > Recording > HTML AdvancedAdvaced > 아래의 스샷과 같이 설정

- HTML-based script: browser application

- URL-based script: non-browser application

- A script describing user actions: 사용자 액션을 설명하는 스크립트

- A script containing explict URLs only: 명시적인 URL만 포함하는 스크립트

 

 

 

Options > Advanced > Support charset > UTF-8 선택하여 OK클릭

- UTF-8: UTF-8 인코딩 지원

 

참고로, Recording Options은 한번만 설정해 놓으면 이후부터는 똑같이 적용이 됩니다.

 

설정 완료 후, Start Recording 창에서 OK 버튼을 클릭하면, 설정해 놓은 URL Address 페이지를 열어 레코딩을 시작합니다.

Recording bar의 events가 count되면 정상적으로 동작하는 것 입니다.

 

 

 

측정하고자 하는 페이지가 완전히 열린 것을 확인하고 STOP 버튼을 클릭하여 레코딩을 종료합니다.

 

 

 

레코딩을 종료한 후, 측정한 스크립트를 저장합니다.

 

 

 

트랜잭션이 시작되는 부분을 마우스로 클릭한 후, Insert Start Transaction 버튼을 클릭하여 Transaction Name을 입력합니다.

 

 

 

트랜잭션이 끝나는 부분도 마찬가지로 마우스로 클릭한 후, Insert End Transaction 버튼을 클릭하여 Transaction Name을 입력합니다.

시작할때 입력한 이름이 나오므로, OK버튼만 클릭하면 됩니다.

 

 

 

이제 해당 스크립트를 측정하기 위해, 상단의 Run버튼을 클릭하여 스크립트를 실행합니다.

스크립트가 정상적으로 실행돼면 하단 Replay log에 Pass가 출력될 것 입니다.

 

 

 

이제 작성된 스크립트가 정상적으로 동작하는지 검증하는 단계 입니다.

사람이 직접 테스트를 진행할 때는, 육안으로 확인이 가능하지만, 로드런너 같은 툴을 사용할때는 로그와 같은 결과 값으로 검증할 수 있습니다.

사용자가 서버에 Request를 보내면 Response가 오는데요.

서버에서 오는 Response를 잡아서 해당 문자를 한가지 정해서 검증해 보도록 하겠습니다.

여기서는 네이버 홈페이지의 "회원가입"이란 문자를 검증하겠습니다.

 

 

 

상단메뉴 우측의 Run-time Settings를 클릭하여, Log를 선택하고 아래와 같이 설정합니다.

- Extendeed log: 데이터 검증용이므로 디버그 시에만 사용

- Parameter substitution: 수행 시, 적용되는 파라미터 값을 log에 출력

- Data returned by server: Server에서 Response되는 값을 log에 출력

 

 

 

설정을 완료한 후, 상단의 Run을 클릭하여 스크립트를 실행합니다.

스크립트 실행이 완료돼면 Replay Log를 클릭한 후, 검증할 단어를 찾습니다.

여기서는 "회원가입" 이란 단어를 검증할 문자로 선택해 보겠습니다.

회원가입 문자를 찾은 후, 해당 문자(Replay Log:회원가입)를 더블클릭 합니다.

그럼 본문의 web_url(www.naver.com, 로 자동으로 이동합니다.

 

 

 

이제, 검증할 문자인 "회원가입"을 web_url(www.naver.com, 앞에 커서를 클릭하여 입력합니다.

처음에 진행했던 Insert Start Transaction 부분과 비슷하지만, 여기서는 상단의 Insert > New Step > Service > Web_reg_find >회원가입 > OK 클릭 순서로 진행합니다.

- web_reg_find: 실제 결과 페이지가 사용자에게 보여졌는지를 확인하기 위해 사용되는 함수

 

  

 

그럼 본문에 web_reg_find("Text=회원가입", LAST); 문구가 입력됩니다.

 

 

 

이제 상단의 Run 버튼을 클릭하여 스크립트 실행이 완료된 후, 하단의 Replay Log를 선택하여 검증하고자 하는 문자가 체크 되었는지 web_reg_find를 입력하여 확인해 보면 됩니다.

첫번째 나오는 web_reg_find 함수는 테스트조건이 정상적으로 등록되었다는 표시이므로, 무시하면 됩니다.

 

 

 

두번째 나오는 web_reg_find 함수가 검증하기로 했던 문자입니다.

즉, web_reg_find successful for "Text=회원가입" (count=2) 라고 출력돼야 해당 문자가 정상적으로 검증된 것 입니다.

 

 

 

문자 검증 완료 후, 상단 메뉴에서 View > Test Results를 클릭하여 해당 테스트 결과를 확인할 수 있습니다.

드디어 1단계 스크립트 작성 단계가 끝났네요. ㅎㅎ

여기까지 오시느라 수고 많으셨습니다.

 

 

이제, 2단계인 시나리오 작성에 대해 시작하겠습니다. :D

 

시작 > Mecury LoadRunner > Applications > Controller 클릭하여 실행

New Scenario 에서 스크립트 선택하여 Add 한 후, OK버튼 클릭합니다.

 

 

 

OK버튼을 클릭하면, Scenario Schedule 페이지가 출력됩니다.

해당 페이지에서 시나리오 설정을 하면 됩니다.

 

 

 

제일 먼저, Running설정 부분입니다.

Vusers를 설정하면 돼는데요. 딱히 특별한건 없습니다.

AddVuser을 사용해서 Vuser을 늘리거나, Details을 사용해서  해당 스크립트를 변경 및 조회할 수 있습니다.

 

 

 

 

 

이제 Scheduler 설정하는 방법입니다.

Edit Schedule를 클릭하여 Schedule Builder을 불러낸 후, 아래와 같이 설정하면 되는데요.

우선, Slow Ramp Up 부분에 대해서 설정하겠습니다.

- Vuser를 2분마다 2명씩 유입시키는 내용

 

 

 

- Run until completion: Iteration 횟수만큼 진행

- Run for 10분 after the ramp up has been completed: 주어진 시간(10분)만큼 진행

- Run indefinitely: 무한정 진행

 

 

 

- Stop all Vusers simultaneously: 모든 Vuser을 일제히 정지

- Stop 5 Vusers every 30: Vuser를 30초마다 5명씩 정지

 

 

 

위에서 Slow Ramp Up 부분에 대해서 각각 설정했는데요.

Schedule Name 콤보박스에서 Ramp Up을 선택한 후, Slow Ramp Up와 같이 설정을 다시 한번 해줍니다.

물론, 설정은 약간 다른방식으로 아래처럼 해줘야 합니다.

-Ramp Up: Start 2 Vusers every 00:00:15

-Duration: Run for 000:05:00

-Ramp Down: Stop all Vusers simultaneously

 

 Scheduler을 사용하는 이유는 정해진 스케쥴에 따라 load가 입력되므로 결과분석 시, 결과 값을 추출하는 것이 용이하기 때문 입니다.

 

이번에는 Generators를 사용해서 부하발생기의 상태를 확인하도록 하겠습니다.

상태가 Ready가 아닌 경우에는 Connect해서 연결하면 되며, 반대로 사용하고 싶지 않은 경우에는 Disconnect 하면 됩니다.

드디어!! 2단계인 시나리오 작성까지 완료하였습니다. ㅎㅎ

 

 

 

 

마지막 3단계인 실행 및 결과분석!! 단계 입니다. :D

 

하단의 Run탭을 선택한 후, Start Scenario 버튼을 클릭하여 실행합니다.

 

 

 

그럼, 아래와 같이 Running 표시가 뜨는데요.

스크립트를 시나리오대로 정상적으로 진행하고 있다는 표시 입니다.

중간중간 돋보기를 클릭하여 해당 내용에 대해 확인해 볼 수도 있습니다.

그리고, 왼쪽의 Available Graphs의 항목을 더블클릭하면 해당 도표를 그래프로 중앙에서 상세하게 보여줍니다.

테스트가 완료돼면 자동으로 테스트가 종료됩니다. 물론, Stop버튼을 클릭하여 임의로 종료할 수도 있고요.

 

 

 

자, 이제 모든 테스트가 종료됐습니다.

But!! 결과를 분석할 줄 모른다면 테스트를 한 의미가 없겠죠?

 

지금부터 Analysis Tool을 사용해서 결과를 분석해 보도록 하겠습니다.

메뉴탭에서 Results > Analyze Results 클릭하면 저장된 결과 *.lra 파일을 자동 분석해서 아래와 같은 창이 하나 출력됩니다.

왼쪽의 메뉴가 분석한 항목들이며, 해당 항목을 클릭하면 중앙에 해당 항목의 그래프가 보여집니다.

 

 

 

 

Merge라는 기능으로 여러 그래프를 한번에 보여줄 수도 있습니다.

우선, 하나의 그래프를 클릭해서 연 다음에 해당 그래프 에서 마우스 우측 버튼을 클릭하여 Merge를 클릭하고, 추가하고자 하는 항목을 선택하면 됩니다.

 

 

 

 

 

필터링 기능을 통해 좀 더 자세하게 확인해 보고 싶은 구간을 필터링 해서 볼 수도 있습니다.

Set Global Filter > Scenario Elapsed Time > Set Range 설정 > OK 클릭

 

 

 

 

 

이제 테스트 된 결과에 대해 Reports 할 시간입니다.

LoadRunner Analysis는 친절하게도 일반PC에서도 볼 수 있도록 HTML or Word로 작성이 가능합니다.

해당 목록을 클릭하는 순간 자동으로 결과문서가 작성 완료되므로, 확인하시면 됩니다.

 

 

 

아, 드디어 LoadRunner 테스트가 완료됐습니다. ㅎㅎ

주요 기능에 대해 빼먹은 부분도 있고, 미흡한 부분도 있는데요.

나중에 좀 더 공부해서 추가하도록 하겠습니다. ㅎㅎ

XML과 인터넷 프로토콜을 통해 표준화된 방식으로 상호작용하기위한 소프트웨어 시스템을 말한다.

웹서비스는 SOAP, WSDL, UDDI 등의 표준기술로 이뤄진다.

따라서, 서로 다른 개발환경과 운영체제에서도 상호 통신을 가능하게 된다.

HTTP를 사용한다는 점에서 CORBA나 DCOM 보다 우위에 있다.

SOAP (Simple Object Access Protocol) :

XML과 HTTP등을 기본으로 하여 다른 컴퓨터에 있는 데이터나 서비스를 호출하기 위한 통신규약(Protocol)이다.

SOAP을 지원하는 서버가 대중화가 되면서 대부분의 SOAP 서버들을 웹에서 Access가 가능해졌으며 다양한 프로그램언어에서도 쉽게 실행할 수 있게 되었다

WSDL (Web Service Description Language) :

웹서비스에서 제공하는 기능들(서비스 오퍼레이션에 해당함)을 외부에서 이용할 수 있도록 그 사용방법을 알려주는 인터페이스 언어로 XML 기반으로 작성된다.

즉, 웹서비스 설명서이다.

SOAP(Simple Object Access Protocol)

SOAP Message 구조

SOAP 메시지는 루트 엘리먼트로 Envelope를 가지며, SOAP Header와 Body를 하위 엘리먼트로 가지고 있다. SOAP의 메시지 구조는 XML을 근간으로 Header와 Body를 조합하는 디자인 패턴으로 설계되었고 Body는 필수사항으로 전송될 메시지의 내용을 기술(Header는 선택사항)한다.


SOAP 특징

장점	설명
1	SOAP은 기본적으로 HTTP 기반 위에서 동작하기 때문에, HTTP와 같이 프록시와 방화벽에 구애받지 않고 쉽게 통신 가능하다.
2	SOAP는 표준 트랜스포트 프로토콜인 HTTP 이외의 다른 트랜스포트 프로토콜들을 사용할 수 있다.
3	플랫폼 및 프로그래밍 언어에 독립적이다.
4	간단하고 확장 가능하며, (멀티파트 MIME 구조를 사용하여) 첨부를 통합하는 SOAP XML 메시지를 지원한다.




단점	설명
1	XML 포맷은 태그 형태로 보내기 때문에 CORBA 같은 미들웨어 기술과 비교해서 상대적으로 느리다. (최근 네트워크 속도의 비약적인 발전과 성능 최적화 기술의 발전으로 대부분 해결됨)

WSDL(Web Services Description Language)

WSDL 문서 구조

definitions 태그를 루트 엘리먼트로 하여 추상적 정의(types/message/portType)와 구체적 정의(binding/service)로 나뉜다. 추상적 정의와 구체적 정의를 분리하여 기술함으로써, 서로 다른 서비스 구현에 대해 서비스의 추상적 정의를 재사용할 수 있다.



WSDL 문서 구조 상세

WSDL의 주요 기술 내용에는 웹 서비스의 이름과 URI 정보, SOAP 메시지의 인코딩 방법, SOAP 메시지 전송을 위한 프로토콜 정보, 웹 서비스를 이용하는데 필요한 인터페이스 정보가 있으며 문서 구조 로는 추상적 정의와 구체적 정의를 분리하여 기술함으로써, 서로 다른 서비스 구현에 대해 서비스의 추상적 정의를 재사용할 수 있다. WSDL의 구성요소는 아래와 같다.


WSDL의 각각의 구성 요소에 대한 설명은 다음과 같다.

요소	설명
<service>	Endpoint(실제 웹 서비스로 구현된 어플리케이션)의 물리적 위치를 정의하고 각 바인딩에 대한 포트 주소를 기술한다.
<port>	binding 정보와 address location을 정의한다.(WSDL 2.0에서는 <endpoint>로 변경됨)
<binding>	portType과 네트워크 호출 프로토콜, 어떤 통신 프로토콜을 통해서 통신을 할 것인지를 정의한다.
<portType>	인터페이스의 메소드들을 정의한다. Interface(WSDL 2.0에서 <interface>로 변경됨)
<operation>	서비스의 함수에서 사용되는 요청(Request)/ 응답(Response) 메시지 정의
<message>	서비스가 사용하는 메시지를 정의한다. 메소드의 인자와 리턴 값을 선언한다. (WSDL 2.0에서는 <types>를 통해 XML 스키마 타입을 사용하여 기술)
<types>	문서에서 사용되고 있는 데이터 타입을 정의한다.

출처 : http://dev.anyframejava.org/anyframe/doc/core/3.1.0/corefw/guide/webservices.html

출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=26739929

1. HTTP(HyperText Transport Protocol) 개요

1.1 HTTP 란?

• HTTP란 HyperText Transport Protocol의 약자로 웹서버와 클라이언트간의 문서를 교환하기 위한 통신규약이다.
• World Wide Web( WWW )의 분산되어 있는 Server와 Client 간에 Hypertext를 이용한 정보교환이 가능하도록 하는 통신 규약이다.
• 1989년 Tim Berners Lee가 처음 설계
• HTTP는 웹에서만 사용하는 Protocol로 TCP/IP 기반으로 한 지점에서 다른 지점(보통 클라이언트와 서버)으로 요청과 응답을 전송한다.

1.2 HTTP의 특징

• HTTP 메시지는 HTTP Server와 HTTP Client에 의해서 해석
• TCP/IP 프로토콜의 Application 계층에 위치
• TCP Protocol을 이용한다( Default Port 80 )
• 현재 Version 1.1 ( RFC 2616 )

2. HTTP 1.1

• HTTP 1.0의 성능 개선에 중점을 두었다

2.1 HTTP 1.0의 문제점

• 단순한 OPEN,OPERAIOTN,CLOSE
• 매번 필요할 때마다 연결(비 지속성 연결방식) → 성능의 저하
• 한번에 얻어서 가져올 수 있는 데이터의 양이 제한
• URL의 크기도 작으며, 캐시 기능이 미흡함(Last-Modified에 의존)
• GET/HEAD/POST method만 허용

TCP/IP

 : 서로 다른 하드웨어와 운영체제등을 가지고 서로 통신을 하기 위해서는 모든 요소에 규칙 . 즉 프로토콜이 필요하다.

   프로토콜에는 여러가지가 있는데, 케이블 규격, IP주소지정방법, 떨어진 상대를 찾기 위한 방법과 그곳에 도달하는 순서, 웹을 표시하기 위한 순서 등

   이렇게 인터넷과 관련된 프로토콜을 모은 것을 TCP/IP 라고 부른다

   즉, 인터넷에 관련된 다양한프로토콜 집합의 총칭

   인터넷을 포함하여 일반적으로 사용하고 있는 네트워크는 TCP/IP라는 프로토콜에서 움직이고있다.

   HTTP는 그중에 하나이다.

   등장 당시에는 주로 텍스트를 전송하기 위한 프로토콜이었다.

HTTP

 : 웹브라우저와 같은 응용프로그램을 통해 Client와 Server 사이에 데이터를 전송하는 프로토콜이다.

   웹은 HTTP라는 약속을 사용한 통신으로 이뤄짐

(저자는 독자가 JUnit에 대한 기본적인 지식이 있을 것이라고 가정하고 이 글을 적었다. 만약 해당 지식이 없다면 우선 이 웹페이지http://junit.sourceforge.net/doc/cookbook/cookbook.htm를 읽기를 추천한다. 저자는 이 글을 통해 개발자가 단위 테스트를 작성할 때 고려해야 할 사항들을 기술 할 것이다.)

“비용을 천문학적으로 증가시킴에도 불구하고 프로젝트에 정말 아무런 도움이 되지도 않는 단위 테스트를 작성하기란 정말 쉽다.”

이 글의 핵심 내용 : 

·      단위 테스트는 버그를 찾기 위한 것이 아니다.

·      좋은 단위 테스트를 작성하기 위한 팁들

·      하나의 테스트 케이스는 단위 기능중 하나의 시나리오만 테스트하라. 

·      불필요한 검증 구문은 작성하지 마라.

·      각 테스트는 독립적이어야 한다.

·      테스트에 필요한 모든 외부서비스와 상태들은 스텁으로 제공되야 한다.

·      시스템 설정파일에 관한 단위 테스트를 작성하지마라.

·      단위 테스트 케이스의 이름은 명확하고 일관되게 테스트의 의미를 반영해야한다.

·      외부 시스템이나 서비스에 대한 의존성이 가장 낮은 메소드들에 대해 테스트를 먼저 작성하라. 그리고 확장         해 가라.

·      프라이빗 메소드를 포함한 모든 메소드들은 가시범위에 상관없이 적절한 단위 테스트들을 작성해야 한다.

·      각각의 단위 테스트 메소드는 정확히 하나의 검증구문을 가져야 한다.

·      예상된 예외 사항을 테스트하는 단위 테스트 코드를 작성하라.

·      가장 적합한 검증 구문을 사용하라.

·      검증 구문 파라미터들은 적합한 순서대로 배치하라.

·      테스트를 위한 코드는 제품 코드에서 분리되어야 한다.

·      단위 테스트 내에서 아무것도 출력하지 마라.

·      정적 변수를 테스트 클래스에 사용하지 마라.

·      예외 발생시 단순히 테스트를 실패하기 위한 catch 구문을 작성하지 마라.

·      간접적인 테스트에 의존하지 마라.

·      위 테스트를 자동으로 실행하게 빌드 스크립트를 작성해라.

·      단위 테스트들의 실행을 생략하지 마라.(@Ignore 어노테이션을 사용하지 마라.)

·      테스트 결과를 XML 형태로 출력하라.

소프트웨어 개발에서 단위 테스트Unit testing는 구현코드의 개별 단위의 적합성 혹은 정확성을 확인 하기 위한 방법이다. 이 단위의 정의는 테스트 시나리오에 따라 다를 수 있다.  

예를 들어서 C와 같은 절차적 프로그래밍 언어에서는 하나의 단위가 일반적으로 하나의 프로시저 또는 함수이다. 하지만 객체지향 언어에서는 하나의 메소드가 될 수 있다. 단위 테스트에서 하나의 테스트 단위는 테스트 가능한 가장 작은 부분으로 생각하면 무난하다.

단위 테스트는 버그를 찾기 위한 것이 아니다. 

Unit testing is not about finding bugs

단위 테스트의 의도를 정확히 이해하는 것은 중요하다. 단위 테스트는 단순히 버그를 찾기 위한 효과적인 방법이 아니다. 정의에 따르면 단위 테스트는 시스템의 각각의 단위들을 개별적으로 조사하는 것이다. 시스템이 구현되어 실제 환경에서 동작할 때 모든 단위들은 완벽하게 하나의 유기체로 동작해야한다. 하지만 시스템은 각 독립적으로 테스트되는 단위의 단순한 결합 그 이상으로 복잡하고 또한 에러가 발생하기 쉽다. 콤포넌트 X, Y가 독립적으로 잘 작동한다는 것이 이 콤포넌트들이 서로 호환된다든가 혹은 정확하게 조합되어졌다는 것은 아니다.

따라서 단순히 버그를 찾기 위한 것이라면 일반적으로 검증자가 일일이 테스트 하듯이 전체 시스템을 실제 통합환경에서 실행하는 것이 훨씬 효과적인 테스트가 될 수 있다. 그리고 이러한 테스트를 자동화 한 것을 통합 테스트라고 하는데, 이것은 일반적으로 단위 테스트와는 다른 기술들을 사용한다.

“단위 테스트는 TDD(Test Driven Development)에서 그러한 것처럼 반드시 시스템 디자인 단계의 일부분으로 보아야 한다.” 이렇게 함으로써 시스템 디자이너는 시스템의 가장 작은 단위 모듈을 인식할 수 있고 또한 개별적으로 테스트 할 수 있다.

Tips for writing great unit tests

하나의 테스트 케이스는 단위 기능 중 하나의 시나리오만 테스트하라. 

Test only one code unit at a time

단위 테스트 작성시 가장 중요하게 인식할 점은 테스트 단위가 복수의 테스트 시나리오들을 가질 수 있다는 것이다. 그리고 모든 테스트 시나리오들은 독립적인 테스트 코드로 작성되어져야 한다. 예를 들어 두 매개변수를 가지고 처리한 후 값을 돌려주는 함수의 테스트 케이스를 작성한다고 하면, 다음과 같은 테스트 시나리오가 가능할 것이다.

1.     첫 번째 파라미터가 널 값일 경우 예외 객체를 반환해야한다.

2.     두 번째 파라미터가 널 값일 경우 예외 객체를 반환해야한다.

3.     두 개의  파라미터 모두가 널 값일 경우 예외 객체를 반환해야한다.

4.     파라미터가 정상 범위 안일 경우 작업 실행 후 결과 값을 반환해야한다.

이러한 세분화된 테스트 케이스들은 코드를 수정하거나 리택토링시 효과적이다. 왜냐하면 단위 테스트만 수행하면 코드의 수정이 코드의 의도된 기능을 망가뜨렸는지 확인할 수 있기 때문이다. 또한 기능을 수정한다면 최소한의 테스트 코드만 수정하면 되기 때문이다.

불필요한 검증 구문을 작성하지 마라.

Don't make unnecessary assertions

단위 테스트는 시스템의 특정 단위가 어떻게 동작하는지에 대한 디자인 스펙이지 단순히 단위 내의 코드가 행하는 모든 것을 관찰하는 것이 아니다.

단위 내의 모든 것에 대해 검증구문을 작성하지 마라. 대신 테스트 할려고 하는 하나의 시나리오에 집중해라. 테스트 코드를 이렇게 작성하지 않으면 하나의 이유로 여러 테스트 케이스가 실패 할 수 있다. 결국 이것은 프로젝트에 아무런 도움이 되지 않는다. (왜냐하면 테스트 코드를 보고 문제점을 찾을 수 없기 때문이다.)

각 테스트는 독립적이어야 한다.

Make each test independent to all the others 

다른 테스트에 의존적인 꼬리에 꼬리를 무는 단위 테스트를 작성하지 마라. 이러한 테스트들은 테스트의 근본적인 실패 원인을 테스트 결과를 통해 알 수 없다. 결국 별도의 디버깅 작업을 수행해야 한다. 또한 이러한 상호 의존적인 테스트 코드는 유지보수도 번거롭다. 왜냐하면 하나의 테스트 코드를 수정할 경우 의존성을 가지고 있는 다른 코드로 수정해야 할 경우가 생기기 때문이다.

테스트의 선결 조건을 설정하기 위해서는 @Before/@After와 같은 테스트 프레임워크가 제공하는 어노테이션을 사용해라. 만약 서로 다른 테스트 구문을 위해 @Before/@After 어노테이션 구문 안에서 여러 가지 다른 셋팅을 해야 한다면 별도의 새로운 테스트 클래스를 생성하는 것을 고려해라.

모든 외부 서비스와 상태들에 테스트 더블을 사용해라. 

Mock out all external services and state

그렇게 하지 않으면 공통된 외부 조건를 사용하는 테스트 구문들의 결과가 서로에게 영향을 미친다. 결국 테스트 구문 실행 순서에 따라 테스트 결과가 달라지거나 네트워크 망이나 데이터베이스의 조건에 따라 결과가 달라진다.

게다가 외부 서비스의 버그들로 인해서 테스트 결과가 실패로 끝날 수 있다.

(테스트 구문이 정적 변수들을 변화시키게 하지마라. 어쩔 수없이 변화시켜야 한다면 적어도 테스트 시작 바로 전에 이 변수들을 초기화 시켜라)

시스템 설정파일에 관한 단위 테스트를 작성하지 마라. 

Don’t unit-test configuration settings

정의에 따르면 시스템 설정은 단위 테스트의 범위가 아니다(그래서 그러한 설정값은 별도의 설정파일로 분리된다). 시스템 설정값에 대한 단위 테스트를 작성하고 싶다면 설정값을 읽는 모듈에 대한 하나 혹은 두 개의 경우만 테스트해라.

시스템 설정에 대한 모든 경우수를 테스트를 하는 건 결국 하나 밖에 증명하지 못한다. “난 복사 후 붙여넣기 할줄 알아요”

단위 테스트 케이스의 이름은 명확하고 일관되게 테스트의 의미를 반영해야한다. 

Name your unit tests clearly and consistently

이것은 언제나 명심하고 실천해야하는 중요한 점이다. 테스트 케이스의 이름은 항상 테스트의 의도가 무엇인지 반영해야한다. 단순하게 테스트 할려고 하는 단위의 클래스와 메소드의 조합을 테스트 케이스의 이름으로 사용하는건 좋은 생각이 아니다. 클래스나 메소드의 이름을 변경해야 하는 경우가 생길 때 테스트 케이스들의 이름도 매번 수정해야 한다.

그러나 단위 테스트 케이스의 이름이 단위의 기능을 반영하는 논리적인 이름이라면 단위 기능이 바뀌지 않는 경우에는 테스트 케이스 이름은 언제나 동일하다.

아래는 테스트 케이스 이름의 좋은 예들이다.

1) TestCreateEmployee_NullId_ShouldThrowException

2) TestCreateEmployee_NegativeId_ShouldThrowException

3) TestCreateEmployee_DuplicateId_ShouldThrowException

4) TestCreateEmployee_ValidId_ShouldPass

외부 시스템이나 서비스에 대한 의존성이 가장 낮은 메소드들에 대해 테스트를 먼저 작성하라. 그리고 확장해 가라. 

Write tests for methods that have the fewest dependencies first, and work your way up

예를 들어 Employee 모듈을 테스트 한다고 하자. 가장 먼저 Employee 모듈을 생성하는 코드부터 테스트를 작성하자. 왜냐하면 이 시나리오가 가장 낮은 외부 의존성을 가지기 때문이다. 이 시나리오가 성공한다면,  데이터베이스에 접근하는 테스트 코드를 추가하자.

데이터베이스에 Employee 정보를 가질려면 먼저 Employee 모듈을 생성하는 테스트 시나리오를 통과해야 한다. 만약 모듈을 생성하는 코드에 버그가 있다면 훨씬 빨리 발견할 수 있다.

프라이빗 메소드를 포함한 모든 메소드들은 가시범위에 상관없이 적절한 단위 테스트들을 작성해야 한다. 

All methods, regardless of visibility, should have appropriate unit tests

사실 이것은 논란거리이다. 소스의 코드의 핵심적인 부분은 그것이 프라이빗 메소드들이라도 반드시 테스트 되어져야 한다. 이 메소드들은 몇몇 클래스에서 호출 되어지는 어떤 결정적인 알고리즘을 가질 수 있다. 그러나 이것은 중요한 역활을 한다. 따라서 이 메소드들이 의도대로 동작하는 것을 확인해야한다.

각각의 단위 테스트 메소드는 정확히 하나의 검증구문을 가져야 한다. 

Aim for each unit test method to perform exactly one assertion

(번역자주 : 동의 하지 않음. 기능의 정확성을 확인하기 위해서는 복수의 검증구문이 필요할 수 있음.)

예상된 예외 사항을 테스트하는 단위 테스트 코드를 작성하라. 

Create unit tests that target exceptions

예상된 예외 사항을 검증하기 위한 테스트 케이스를 작성해야 하는 경우도 있다. 이때에는 아래와 같이 try/catch 구문으로 결과를 검증할려고 하지마라.

try{

          methodOccursDomainSpecificException();

          assertFail(“Exception should be occurred”);

}

catch(DomainSpecificException e){

}

대신 아래와 같이JUNIT이 제공하는 아래의 방법을 사용해라.

가장 적합한 검증 구문을 사용하라. 

Use the most appropriate assertion methods

각 테스트 케이스에 사용할수 있는 많은 검증 구문이 있을 수 있다. 하지만 각 경우마다 이유와 의도에 맞게 가장 적합한 것을 사용하라.

검증 구문 파라미터들은 적합한 순서대로 배치하라. 

Put assertion parameters in the proper order

검증 구문은 대개 두 개의 파라미터를 취한다. 첫 번째 것은 테스트 결과가 패스할 때 기대하는 정상 값이고, 두 번째 것은 테스트 결과 값이다. 이 두 값들을 순서대로 작성하라. 이렇게 하면 테스트 실패시 에러 메세지를 통해 무엇이 잘못 되었는지 쉽게 확인할 수 있다.

테스트를 위한 코드는 제품 코드에서 분리되어야 한다. 

Ensure that test code is separated from production code

빌드 스크립트에서 테스트를 위한 코드는 실제 제품 코드와 같이 전달되지 않게 하라.

테스트 코드 내에서 아무것도 출력하지마라. 

Do not print anything out in unit tests

만약 테스트 케이스가 가이드 라인들에 따라 제대로 작성 되어졌다면 별도의 출력문이 필요하지 않다. 만약 출력문에 대한 필요성을 느낀다면 테스트 코드를 재검증 하라. 무엇인가 테스트 코드 중 잘못된 점이 있다.

정적 변수를 테스트 클래스에 사용하지 마라. 만약 사용했다면 각 테스트 케이스 실행시마다 재 초기화 해라. 

Do not use static members in a test class. If you have used then re-initialize for each test case

 이미 각 테스트들 간의 독립성에 대해 중요성을 언급했다. 따라서 절대 스트틱 변수들을 사용하지 마라. 만약 어쩔수 없이 사용해야 하는 경우가 발생한다면 각 테스트 케이스의 시작 전에 반드시 재 초기화 시켜라.

예외 발생시 단순히 테스트를 실패하기 위한 catch 구문을 작성하지 마라. 

Do not write your own catch blocks that exist only to fail a test

 테스트 코드 내에 어떤 메소드가 예외를 발생시킬 수 있다면 단순히 테스트를 실패하기 위해 catch 구문을 사용하지 마라. 대신 throws 구문을 테스트 코드 선언시에 사용하라. 되도록이면 별도의 특정 예외 객체보다는 일반적이 Exception 예외 객체를 사용해라. 이 가이드 라인은 테스트 커버러지 증가에도 도움이 된다.

간접적인 테스트들에 의존하지 마라. 

Do not rely on indirect testing

하나의 테스트가 본래 의도된 시나리오 외 또 다른 시나리오도 테스트 한다고 가정하지마라. 이것은 혼란만 가져온다. 대신 또 다른 시나리오에 대한 추가적인 테스트 케이스를 작성하라.

단위 테스트를 자동으로 실행하게 빌드 스크립트를 작성해라. 

Integrate Testcases with build script

테스트 케이스들이 빌드 스크립트를 통해 자동적으로 실행되어지게 하라. 이것은 테스트 실행환경과 애플리케이션의 신뢰성을 높여준다.

단위 테스트들의 실행을 생략하지 마라. 

Do not skip unit tests

만약 단위 테스트의 코드가 적절하지 않다면 코드를 삭제해라. @Ignore 어노테이션을 사용하지마라. 소스코드의 부적절한 테스트 케이스를 포함하는건 아무런 도움이 되지 않는다.

테스트 결과를 XML 형태로 출력하라. 

Capture results using the XML formatter

즐거운 것은 좋은 것이다. 이 가이드 라인은 테스트 케이스 작성을 즐겁게 한다. 예를 들어 JUNIT을 빌드 스크립트와 통합시켜서 XML­로 테스트 결과를 출력 후 이것을 ­추가적인 포맷팅 작업을 통해 테스트 결과를 보기 좋게 바꿀 수 있다. (번역자주 : JUNIT 프레임워크에서 제공하는 그린/레드UI 디스플레이를 의미하는듯 함.)

결론 

Conclusion

의심할 여지없이 단위 테스트는 소프트웨어 프로젝트 결과물의 품질을 월등히 향상시킬 수 있다. 소프트웨어 공학 관련 많은 학자들이 단위 테스트를 작성하는 것이 작성하지 않는 것보다 훨씬 효율적이라고 주장한다. 하지만 난 이 의견에 반대한다. 테스트 케이스들은 훌륭한 자산이다. 하지만 반대도 성립한다. 즉 형편없이 작성된 테스트 케이들은 프로젝트에 아무런 도움이 되지않는 골칫거리에 불과하다. 이러한 단위 테스트 코드의 품질은 개발자들이 단위 테스트의 목적과 철학을 얼마나 잘 이해하는지에 달려있는 것 같다.

독자 여러분이 그동안 저자가 서술한 가이드 라인을 잘 이해하고 그것을 잘 따른다면 다음 단위 테스트시 변화된 자신의 코드를 경험할 수 있을 것이다.

Happy Learning !!

출처 : http://jinson.tistory.com/191

sftp로 folder를 가져올수 없어... 굴링 해보니

scp를 사용하면 된다.

scp -r 계정@호스트:절대경로폴더/ .

이렇게 하면 폴더를 get 할 수 있음.

끝