자바 개발자도 쉽고 즐겁게 배우는 테스팅 이야기

 

2000년대 초중반 성능테스트를 수행해야 했던 적이 있다. 사전 지식도 없이 혼자 진행해야 했던터라 단편적인 지식을 채워 가면서 열심히 삽질을 했었다. 그 때 사용했던 툴이 MS Stress Test Tool과 JMeter 였다. ‘이렇게 하면 맞는건가?’ 하는 답답함을 꾹꾹 눌러가며 하다보니, 어찌어찌 마무리할 수 있었던 기억이 난다.  

이 책을 보는 내내 느낀 감정은 삽질하던 그 시기에 이런 책이 있었다면 정말 좋았었을텐데 하는 아쉬움 이었다. 깔끔하고 쉽게 정리해서 읽기 편했고, 엉성했던 개념들이 차곡차곡 정리되는 기쁨에 읽는 재미도 좋았다. 게다가 잘 몰랐던 보안테스트와 툴에 대한 개념도 머리 속에 자리 잡은 듯 하다. 

출퇴근 길에 가벼운 마음으로 읽어 볼 생각이었는데, 오히려 제대로 공부한 느낌이다. 

메모

xUnit이란 어떤 언어를 막록하고, 단위 테스트를 하는데 도움을 주는 프레임워크를 통틀어서 칭하는 용어이다. 

JUnit 실행 순서

setUp() -> testA() -> tearDown() -> setUp() -> testB() -> tearDown()

Annotation

어노테이션은 패키지부터 변수에 이르기까지 @를 이용하여 메타 데이터 정보를 선언할 수 있는 새로운 기능이다. 어노테이션은 미리 정해진(built-in) 어노테이션과 사용자가 정의한(custom) 어노테이션으로 나뉜다. 미리 정해진 어노테이션은 Overrides, Documentes, Inherited, Retention, Target 여섯 개가 있다. 

DB 관련 테스트

 – 요즘 나오는 테스트 프레임워크에서는 테스트 하기 쉽도록 도와주는 기능을 제공

 – 트랜잭션을 직접 관리하는 것도 방법 (모든 트랜잭션을 자동 Commit 되지 않도록 한 다음, 테스트 종료 이후 Rollback)

상용 및 비상용 GUI 테스트 툴 목록

 – www.testingfaqs.org/t-gui.html

 – 기타 웹 UI 테스트 툴 – Selenium, Wati

코드리뷰 자동화 툴

PMD, FindBugs

CTIP (Continuous Test & Integration Platform)

지속적으로 테스트를 하고 통합을 하는 플랫폼을 구축해서 일일 빌드(Daily build)와 야간 빌드(Nightly build)를 가능하도록 하라는 것이다. 

Hudson 빌드추가

1. 프로젝트 추가

2. 프로젝트 상세 설정

3. 빌드 수행

4. 빌드 결과 확인

TPMC

TPC(Transaction Processing Performance Council, www.tpc.org)라는 곳에서 제공하는 값이다. 특정 서버에 대해서 자체 기준으로 테스트를 수행하여 나온 결과 중 1분간 최대 처리 건수를 나타낸 수치가 TPMC이다. 가장 객관적으로 하드웨어의 성능을 나타내는 지표로 많이 사용하고 있다. 

성능 테스트 주된 이유

 – 오픈 시 안정성 보장

 – 시스템의 병목 구간 사전 발견 및 조치

 – 시스템의 오류 사전 확인

 – 각종 아키텍처의 검증

 – 오픈 될 시스템이 허용할 수 있는 최대 사용자 예상

 – 기타 수만 가지 이유

웹 에서의 트랜잭션

 – 요청(Request) 기준 트랜잭션 – 하나의 요청을 하나의 트랜잭션으로 보는 것이다. 즉 JSP나 Servlet을 한 번 호출하여 결과가 리턴되면 한 트랜젝션이 처리된 것이다. 

 – 사용자 트랜잭션은 WAS나 서버의 기준이 아닌 사용자 기준으로 트랜잭션을 보는 것이다. 다시 말하면 사용자가 클릭을 한 번 하고, 모든 데이터가 처리되어 화면에 표시되었을 때를 의미한다. 

 – 많은 사이트에서 사용하는 WAS 모니터링 툴인 APM을 사용하는 경우와 웹 로그를 분석할 경우에는 요청 기준 트랜잭션을 하나의 트랜잭션으로 보는 것이 일반적이고, 성능 테스트를 할 경우에는 사용자 트랜잭션을 하나의랜잭션으로 보는 것이 일반적이다. 

MS Web Stress Tool 같은 무료 성능 테스트 툴을 사용할 경우에는 요청 기준 트랜잭션을 사용할 수 밖에 없으며 그 때 이미지, 스타일시트, 자바 스크립트, 정적 플래쉬 등의 정적인 파일은 트랜잭션의 대상에서 제외해야 한다. 왜냐하면 이러한 파일들은 웹 서버와 네트워크에 부하를 주는 것이지, WAS와 DB 서버에는 부하를 주지 않기 때문이다. 게다가 한 화면을 구성하는 수십개의 정적인 파일을 하나의 트랜잭션으로 계산한다면, 너무나 엉뚱한 TPS 결과가 나오게 될 것이다. 

평균, 최소, 50th, 90th, 최대 응답시간 중 가장 의미 있는 시간은 어떤 것일까?

 – 일단 가장 의미없는 시간은 최소 응답시간과 50th 응답, 최대 응답시간이다. 최소 응답시간은 데이터로써 가치가 매우 적으며, 최대 응답시간은 네트워크나 툴의 오류로 어쩌다가 느린 응답이 나올 수도 있기 때문에 이 또한 가치가 매우 적다(아주 가끔 최대 응답시간을 기준으로 잡자고 하는 사람이 있는데, 그런 경우에는 최대 응답시간이 잘 나올 때까지 지켜보면서 테스트를 하는 수 밖에 없다). 보통 50th와 평균 응답시간이 똑같다고 볼 수도 있겠지만, 모든 상황에서 똑같지는 않다. 그러므로 의미있는 응답시간은 다음과 같다. 

 – 평균응답시간 : 평균 응답시간은 말 그대로 응답시간의 평균이기 때문에 사용자가 평균적으로 느끼는 응답시간이다. 일반적으로는 이 응답시간을 응답시간의 지표로 사용한다. 

 – 90th 응답시간 : 90th 응답시간이 의미있는 이유는, 대체적으로 90%의 사용자가 해당 응답시간 안에 응답을 받을 수 있기 때문이다. 어떻게 보면 평균 응답시간보다 훨씬 의미있는 시간이다. 

장비의 대수를 증가시킬 경우에는 처리할 수 있는 트랜잭션의 수는 증가하고 응답시간은 빨라지지 않는 것이 일반적이다. 

응답시간과 대기시간

성능테스트를 수행하는 이유 중 하나가 시스템 오픈 전에 오픈 당일과 동일한 부하를 주어서 시스템의 안정성을 점검하는 것이다. 그렇게 동일한 부하를 주기 위해서는 사용자가 시스템을 사용하는 것과 유사한 패턴을 만들어야 하는데, 그 때 필요한 것 중 하나가 대기시간을 예측하고 지정하는 것이다. 대부분의 사용자는 응답이 오자마자 바로 서버에 요청하지 않기 때문이다. 그래서 일반적으로 툴은 대기시간을 지정할 수 있도록 설계한다. 

사용자의 종류

 – Registered / Concurrent / Active

목표 TPS와 목표 응답시간

JMeter 추천 리스너

 – Graph Results / Aggregate Report / Summary Report

응답시간 분석 및 정리 시 필요한 항목

 – 응답시간 정보

 – 트랜잭션 성공 및 실패 건수

 – CPU 및 네트워크 사용량 정보

 – 기타 연계 서버의 처리 건수 등의 정보(선택적)

nohup

 – 세션이 끊겨도 작업을 계속 수행하도록 지정

 – ex) nohup vmstat 20 3000 > vmstatWAS_1510 &

vmstat 상세

 – r : run queue 약자로 CPU를 사용하기 위해서 쌓여있는 큐의 개수를 의미. 10 이상으로 높으면 시스템 큐가 많이 쌓인다는 이야기므로, 서버가 한계에 다다랐다고 생각할 수 있다. 

 – b : blocked의 약자로 스레드 중 I/O와 같은 리소스 때문에 대기하고 있는 스레드의 개수를 표시한다. 이 수치 또한 높으면 안된다. 

 – CPU의 사용량을 표시하기 위한 항목은 대부분 가장 우측에 존재하며 us, sy, id, wa 4개가 있다. 가끔 OS의 종류에 따라서 wa가 없는 서버도 있다. 

 – us : 사용자 CPU를 의미한다. 우리가 개발한 대부분의 애플리케이션은 이 CPU 사용량에 표시된다. 

 – sy 혹은 sys : 시스템 CPU를 의미한다. OS 커널에서 사용하는 CPU 사용량이 표시된다. 

 – id : 100-(us+sy+wa)의 값으로 여유있는 CPU의 양이다. 즉 idle CPU 사용량이 된다. 

 – wa : 각종 리소스(대표적으로 I/O)에서 사용하는 CPU 사용량이 표시된다. 

이를 기반으로 그래프를 그릴 수 있다. 

성능테스트 결과 보고서 내용

 – 성능테스트 개요

 – 테스트 환경

 – 테스트 대상 화면 및 시나리오

 – 테스트 결과

 – 종합 의견 및 권고사항

웹 애플리케이션 보안 체크리스트 TOP 10

 = OWASP 프로젝트는 비영비 프로젝트로 보안 정보와 무료 툴을 홈페이지에서 제공한다. (www.owasp.org)

 = 네이버 보안카페(SecurityPlus)에서 한글판 제공

 – 크로스사이트스크립팅(XSS)

 – 인젝션 취약점

 – 악성 파일 실행

 – 불안전한 직접 개체 참조

 – 크로스사이트 요청 변조(CSRF)

 – 정보 유출 및 부적절한 오류 처리

 – 취약한 인증 및 세션 관리

 – 불안전한 암호화 저장

 – 불안전한 통신

 – URL 접속 제한 실패

보안테스트 툴

FireBug, cURL, Nikto2

Base(진수) 시리즈

 – Base 8 : 8진수는 0-7로만 이루어져 있다. 

 – Base 16 : 0-9, A-F로 이루어져 있다. 

 – Base 36 : 0-9, A-Z로 이루어져 있다. 모든 문자가 대문자 이거나, 소문자이다. 

 – Base 64 : 0-9, 알파벳 대소문자 52자, +, / 를 합쳐 64개의 문자로 구성된다. 4개 바이트의 배수로 구성되어 있으며, 해당 값의 끝에는 대부분 하나 이상의 =이 붙어있다. 

URL 인코딩 : URL 인코딩은 URL 전송 시 공백이 있거나 인식이 되지 않는 문자가 있을 경우를 대처하기 위해서 사용되며, %와 16진수가 결합된 형태로 되어 있다. 

MD5 : 정확히 128비트(16바이트)의 데이터를 생성하는 방식이다. (Hash)

SHA1 : 정확히 160비트(20바이트)의 데이터를 생성하는 방식이다. (Hash)

Hash 방식이란 단방향 기능을 제공하는 방식을 의미한다. 일반적으로는 입력되는 데이터의 내용에 상관없이 동일한 크기의 데이터를 출력한다. 보통 주민번호와 패스워드를 이 방식으로 저장하여 변환된 입력 값이 동일한 지를 체크하여 사용한다. 

CAL9000 

 – OWASP에서 제공하며, 참고자료, 가이드, 데이터 변환 툴 등 유용한 기능을 제공한다. 

 – 보안에 취약하므로 개인PC에서만 테스트 해야 한다. 

WebGoat

OWASP에서 제공하며, 일종의 보안테스트 용 웹 애플리케이션이다. 보안에 취약하므로 로컬에서 테스트 용도로만 사용할 것을 강력 권장한다. 

simples.kr

Linux와 웹 해킹에 관련된 e-book을 무료로 제공한다. 

경험에 의한 테스트 방법

 – 체크리스트 테스트

 – 소프트웨어 / 시스템 공격

 – 탐색적(Exploratory) 테스트