1. 기본 구성


Master/Slave 모델을 따르며 다음과 같은 컴포넌트로 이루어져 있다.


1.1. Master(Frontier)


서버역할을 하며 Agent가 수집한 URL을 전송받아 관리하게 되며, 필터링된 URL을 다시 Agent로 분배한다.


1.2. Slave(Agent)


Frontier로부터 URL을 전송받아, 해당 URL의 웹페이지(HTML)를 처리한다. 웹페이지 처리 결과로 다른 웹페이

지에 대한 URL Link와 이미지 등의 리소스 URL Link를 추출한다. 추출된 모든 URL Link는 Frontier로 전송

한다.


1.3. Moniotor


Frontier와 Agent의 동작상태를 모니터링하고, 제어기능을 포함한다.






2. 동작 개요


전체적인 동작개요는 다음 그림과 같다.


<그림 1. 웹 크롤러의 기본 구성도>



2.1. Master(Frontier)


  • 각 Agent가 방문해야 할 URL과 다운로드해야 하는 Resource URL 목록을 보관한다.
  • Agent가 새로 수집한 URL을 전송하면 필터링을 수행한 후 남겨진 URL을 방문해야 할 URL 목록에 추가한다.
  • Agent로 방문해야 할 URL을 분배한다.
  • 방문해야 할 URL목록이 모두 소진될 때 까지 위 3단계를 반복한다.


2.2. Slave(Agent)


  • Frontier로부터 전송받은 URL을 HTTP 프로토콜을 이용해 접근한다.
  • HTTP 응답으로 HTML 문서를 얻어 분석한다.
  • HTML 문서 분석결과로 다음 방문한 URL Link와 수집해야할 Resource URL Link를 추출한다.
  • 새로 수집된 모든 URL을 Frontier로 전송한다.


2.3. Moniotor


  • Frontier와 Agent의 동작상태를 모니터링하며 데이터를 시각적으로 재구성 출력한다.
  • Frontier와 Agent의 이상(anomaly) 상태를 파악한다.
  • Monitor를 통해 Frontier의 일부 기능을 실시간으로 제어할 수 있다.





3. 컴포넌트별 주요 프로세스

3.1. Master(Frontier)

3.1.1. 다음 방문해야할 URL Link 목록을 저장하는 자료구조는 다음과 같다.

<그림 2. URL 저장 자료구조>


서로 구분될 수 있는 URL(도메인이 서로 다른)을 따로 분리하여 별도의 FIFO에 각각 저장한다.
URL의 구분은 도메인명(예: www.daum.net)을 64bit Hash 알고리즘을 통해 정수로 변환하여 구분 할 수 있다.
(Rabin's fingerprinting algorithm) 또한, 메모리 공간 요구가 무한하게 커지는 것을 막기 위해 일정 크기이상으로 FIFO가 증가하면 Disk로 FIFO의 데이터를 Flush할 수 있어야 한다.

3.1.2. URL 필터

특정 URL 집한에 대한 Allow/Deny 동작을 정의한다. Frontier에는 다양한 필터가 존재하며, 각 필터에 정의된 룰에 따라 URL을 Allow할지 Deny할지 결정한다.

필터 목록은 다음과 같다.

  • URL 패턴 필터 : 특정 문자열을 포함하는 URL을 필터링한다.
  • URL 중복 필터 : 중복되는 URL을 필터링한다.
  • URL 국가 필터 : URL을 포함하는 웹 서버가 위치하는 국가의 코드를 확인하여 필터링한다.
  • 외부 URL 필터 : Tracking 모드로 동작 시 최초 Seed가 아닌 모든 URL을 필터링한다.

* Tracking 모드란, 웹크롤러가 특정 도메인의 페이지만을 수집하도록 설정된 상태를 말한다. 예를들어 웹크롤러에게 www.daum.net을 Tracking하도록 명령하면 웹크롤러는 www.daum.net 도메인의 서브도메인에 대한 페이지만을 수집/분석하고, 해당 도메인외의 URL을 처리하지 않는다.

특히 중복되는 URL을 제거하기 위한 SeenFilter는 메모리 공간의 효율적인 사용을 위해 URL 전체를 Hash 알고리즘을 통해 정수로 변환하여 처리하며, 앞서 처리된 모든 URL에 대한 집합 저장소가 일정 크기 이상으로 증가하면 Disk로 데이터를 Flush 한다.

<그림3. URL Seen Filter>


3.1.3. 접근관리

다수의 Agent가 짧은 시간동안 단일 웹 서버로 접근하는 것을 방지한다.
이것은 짧은 주기동안 크롤링 대상이 되는 웹서버에 과도한 부하를 발생시키지 않기 위해 중요하다. 이런 장치가 없다면 대상 웹 서버에서는 다수의 Agent접근을 DDoS 공격으로 오인할 수 있다.

3.1.4. 크롤러 함정 피하기

때로는 Agent가 의미없는 URL을 무한대로 발생시키는 특정 도메인에 갖혀 빠져나오지 못하는 경우가 발생한다. 
예를들어 웹에 구현된 달력과 같은 경우 각각의 날짜들에 대해 URL Link를 생성하는 경우가 있는데, Agent가 이러한 웹 페이지를 만날경우 의미있는 데이터는 수집하지 못하고 헤메이게 된다. 

이러한 크롤러 함정을 회피하기 위해 앞서 URL Filter에서 URL 패턴에 기반한 URL을 필터링할 수 있는 기법을 사용할 수 있다.
(달력과 같은 경우 calendar등과 같은 키워드가 URL에 포함되어 있으며 처리하지 않도록 한다.)

또는, 크롤링 대상이 되는 도메인에 대한 접근횟수/유효데이터/쓰레기데이터 등과 같이 통계데이터를 실시간으로 작성하고, 유효데이터와 쓰레기데이터의 추출 비율을 계산해 해당 도메인이 크롤러 함정을 포함하고 있는지 유추할 수 있다. 


Master(Frontier)의 주요 특징을 요약하면 다음과 같다.

특징

 요약설명 

 인터넷 자동 크롤링

 초기 Seed URL로부터 추출되는 모든 URL을 따라 크롤링한다.

 그룹 Seed 지정

 초기 Seed URL을 엑셀파일(xls)로 정의하여 입력할수 있다.

 대상지정 크롤링(Tracking)

 초기 Seed URL에 해당하는 URL만을 크롤링한다.

 크롤링 주기 관리

 크롤링 대상이 되는 도메인에 대한 접근 주기를 설정한다.

 도메인별 접근/데이터 수집/통계

 크롤링이 이루어지는 대상 도메인에 대한 접근및 데이터 수집 통계를 생성한다.
 방문할 URL 관리

 Agent부터 전송되어오는 URL을 도메인별로 관리한다.

 URL 핑거프린트 생성 및
 도메인 중복 제거
 URL의 효과적인 관리를위해 64bit Rabin's Hash Code로 변환한다.

 동적 Configuration 지원

 원격접속을 통한 크롤러 설정을 실시간 변경이 가능하다.

 디스크 캐시 및
 디스크/메모리 동기화
 크롤링 데이터를 disk에 저장하며, 효율성을 위해 disk일부를 메모리로 캐쉬한다.
 IP 기반 지역 필터링  IP를 국가코드로 변환하여, 국가별 크롤링을 지원한다.



3.2. Slave(Agent)

3.2.1. 로봇배제표준

로봇배제표준 엔진은 설정파일에 정의되어 있는 고정크기의 캐시맵을 가지고 있으며, LRU알고리즘에 따라 캐시맵을 관리한다. 또한, 설정파일에는 로봇배제표준 기능의 동작 스위치가 정의되어 있다.

<그림4. 로봇배제표준 캐시 맵>

로봇 배제 표준(http://ko.wikipedia.org/wiki/%EB%A1%9C%EB%B4%87_%EB%B0%B0%EC%A0%9C_%ED%91%9C%EC%A4%80)은 웹 사이트에 로봇이 접근하는 것을 방지하기 위한 규약으로, 일반적으로 접근 제한에 대한 설명을 robots.txt에 기술한다. 이 규약은 1994년 6월에 처음 만들어졌고, 아직 이 규약에 대한 RFC는 없다. 이 규약은 권고안이며, 로봇이 robots.txt 파일을 읽고 접근을 중지하는 것을 목적으로 한다. 따라서, 접근 방지 설정을 하였다고 해도, 다른 사람들이 그 파일에 접근할 수 있다.

3.2.2. URL 정규화

물리적으로 동일한 HTML을 문서를 가리키는 URL은 논리적으로 서로 다르게 표현될 수 있다.
예를들어 다음과 같이 서로 다른 URL이지만 물리적으로 동일한 HTML문서를 가리키는 경우가 있을 수 있다.

  • http://www.youdomain.com
  • http://www.youdomain.com:80
  • http://www.youdomain.com/
  • http://www.youdomain.com/index.html

이처럼 하나의 HTML 물리 문서에 논리적으로 서로 다른 형태의 URL이 존재할 수 있기때문에, 정규화를 통해 이들 URL을 하나의 일관된 형태로 표현하는 처리가 필요하다.

3.2.3. Resource 선택 처리

설정파일에는 Agent가 처리할수 있는 Resource Type과 속성(image/*, javascript, css 등등)이 정의되어 있으며, 정의되지 않은 Resource는 수집하지 않는다.

3.2.4. 멀티쓰레드 & Asynchronous I/O

방대한 인터넷에서 주어진 시간동안 최대한 많은 Resource를 수집하기 위해 멀티쓰레드 및 NIO 기법을 최대한 활용한다.

3.2.5. HTML 파싱

HTML 문법은 견고하지 않다. 실제로 빈번하게 HTML문법이 올바르지 않은 HTML 문서를 발견할 수 있는데,  Agent는 이처럼 정확하게 작성되지 않는 HTML문서에 대해서도 Parsing이 가능해야 한다.


Slave(Agent)의 주요 특징을 요약하면 다음과 같다.

 리소스 확장자 구분  리소스의 확장자를 이용하여 리소스 타입을 구분한다.
 리소스 수집 및 리소스 파일명 정규화  정의된 리소스를 수집하며, 수집시간을 기반으로 리소스명을 정규화한다.
 URL 정규화 및 인코딩 적용  추출된 URL을 정규화하고, URL인코딩한다.
 수집 대상 필터링  정의된 리소스가 아니면 수집하지 않는다.
 로봇배제표준 처리  robots.txt를 처리한다.
 링크 추출  HTML문서로부터 새로운 static link를 추출한다.
 파일크기 기반 리소스 필터링  리소스 크기를 이용해 필터링할수 있다.
 HTML 소스 분석  HTML 파서 기능을 제공한다.
 HTTP 헤더 분석  HTTP 헤더 분석을 지원한다.
 비동기 소켓 입출력 및 멀티쓰레딩  시스템의 효율적인 운영을 위해 비동기I/O 및 멀티쓰레딩을 지원한다.






4. 개선된 아키텍처


앞서 설명한 크롤러 아키텍처의 경우 Frontier로 Agent가 수집한 모든 URL이 집중되기 때문에 시간이 지남에 따라 Seen Filter의 앞서 처리된 URL집합 저장소가 과도하게 커지는 경향이 있다. URL집합 저장소가 커지며, 중복 URL을 검사하기 위한 프로세스 타임도 비례해서 증가하게 되며, 이는 전반적으로 크롤링 성능에 악영향을 주게된다. 마찬가지로 앞으로 방문해야 할 URL 집합 역시 시간이 지남에 따라 크기가 커지며 관리에 많은 노력을 기울어야 한다.


또한, Agent가 수집한 대부분의 URL을 전송받고 처리해, 이를 다시 Agent로 처리해야 하므로 Agent와의 네트워크 통신을 유지하는데에도 많은 리소스가 소모된다.


이와 같은 문제를 해결하기 위해 Agent는 모든 URL을 Frontier로 전송하지 않고, 새로발견된 Host URL만을 전송하는 방법을 생각해 볼수 있다.


<그림5. 개선된 크롤러 구성도>


4.1. Master(Frontier)


  • 각 Agent가 방문해야 할 도메인 URL목록을 보관한다.
  • Agent가 새로 수집한 도메인 URL을 전송하면 필터링을 수행한 후 남겨진 URL을 목록에 추가한다.
  • Agent로 도메인 URL을 분배한다.
  • 도메인 URL목록이 모두 소진될 때 까지 위 3단계를 반복한다.



4.2. Slave(Agent)


  • Frontier로부터 전송받은 도메인 URL을 HTTP 프로토콜을 이용해 접근한다.
  • HTTP 응답으로 HTML 문서를 얻어 분석한다.
  • HTML 문서 분석결과로 다음 방문한 URL Link와 수집해야할 Resource URL Link를 추출한다.
  • 새로운 도메인 URL은 Frontier로 전송한다.
  • 새로운 도메인 URL을 제외한 모든 URL은 재귀적으로 Agent로 입력되어 위 처리과정을 따른다.


4.3. Moniotor


2.3.과 동일



이는 결과적으로 Frontier의 작업 일부를 Agent로 옮겨놓은 것인데, Frontier에서는 Agent로 부터 도메인 URL만을 전송 받고 이를 필터링한다. Agent는 Frontier로부터 받은 초기 Seed URL로 부터 시작해 크롤링을 시작하고, 크롤링으로 얻어지는 결과물 URL들은 그것이 Seed URL의 서브 URL인 경우 다시 Agent로 재귀적으로 입력되고, Seed URL에 포함되지 않는 외부 URL이라면 Frontier로 전송하는 방식이다.


Frontier는 이전 방식과 비교해보았을 때, 도메인 URL만을 처리하기 때문에 URL 누적속도가 훨씬 느려지고, Agent와의 네트워크 사용량도 현저히 줄어들게 된다. Agent는 이전과 비교해보았을 때, 추가적으로 서브 URL에 대한 필터링를 수행해야 하므로 추가적인 복잡도를 지니게 된다.


하지만 위 2방식 모두 Frontier로의 중앙집중 방식이기에, Frontier가 다운되며 시스템 전체가 다운되는 치명적인 단점이 있다. 그래서 최근에는 Hadoop과 같은 P2P 클러스터 환경위에서 웹 크롤러를 가동하는 기법들을 찾아볼 수 있다.


http://www.slideshare.net/hadoopusergroup/building-a-scalable-web-crawler-with-hadoop






5. 제약사항


일반적으로 웹크롤러는 다음과 같은 제약사항을 가지고 있다.


5.1. 플래시(*.swf) 및 Javascript 처리 불가


웹크롤러는 기본적으로 HTML문서내의 Anchor 태그를 분석하여 URL을 추출하는데, 현재 많은 웹 페이지들이 플래시 또는 Javascript 기법을 통해 웹 페이지를 Navigate하고 있다. 


플래시 파일에는 이미지, 동영상, 폰트 등 다양한 Resource가 포함될 수 있는데, 이는 크롤러의 HTML 파싱을 통한 URL 추출을 사용할 수 없음을 의미한다. 이 경우 플래시 바이너리 파일을 해독해 URL을 추출해야 하는데, 플래시 바이너리를 해독하는 작업은 주어진 시간내에 최대한 많은 Resource를 수집해야하는 크롤러에는 치명적인 오버헤드를 유발할 수 있다.


마찬가지로 현재 많은 페이지들은 ajax기법을을 통해 HTML 문서의 일부 또는 전체를 비동기적으로 로딩하는데, 이는 크롤러의 일반적인 처리방식을 통해 URL을 추출할 수 없음을 의미하며, 크롤러가 Javascript 코드를 시뮬레이션 해야하는 부담이 있다.




* 참고자료


stanford_IR_ch20.pdf

대용량 검색 엔진을 위한 병렬 웹 크롤러 설계 및 구현.pdf

웹 어플리케이션을 위한 URL 정규화.pdf

Mercator A scalable, extensible Web crawler part1.ppt

Mercator A scalable, extensible Web crawler part2.ppt




'프로젝트 > 웹크롤러' 카테고리의 다른 글

웹크롤러 아키텍처  (2) 2013.04.02
웹크롤러(WebCrawler)  (1) 2009.07.28
Posted by devop

댓글을 달아 주세요

  1. 좋은 글 감사합니다

    2013.04.11 16:18 신고 [ ADDR : EDIT/ DEL : REPLY ]
  2. 잘 읽었습니다~

    2013.07.29 15:58 신고 [ ADDR : EDIT/ DEL : REPLY ]

프로젝트/ITAMS2013.03.26 01:46

본 프로젝트는 SW마에스트로 1기 2단계 과정을 통해 진행하였습니다.


--


소프트웨어 테스팅은 소프트웨어 산업뿐만 아니라 전반적인 IT산업나아가 첨단 산업 전반에 걸쳐 영향을 미치고 있다.


<그림 1. 시스템 또는 제품의 결함에 의한 피해>


과거 오라클의 DBMS인 11g가 프로그래밍 실수로 보안취약성을 드러낸 적이 있다. 간단한 프로그래밍 실수로 인해 발생한 보안 취약점이지만, 프로그램을 수정하고 다시 재배포하기까지는 엄청난 비용이 발생하는 것은 당연한 수순. 이런 실수는 비용 발생에 그치는 것이 아니라 오라클이라는 글로벌 소프트웨어 업체의 위상에도 심각한 타격을 주는 것이다.


“오류 없는 소프트웨어 없다”는 개발 내 격언처럼 오류 없는 완벽한 소프트웨어는 한 번도 출시되지 않았으며, 이를 개발할 수 있는 개발자 또한 현재까지 존재하지 않는다. 이 때문에 소프트웨어의 오류를 발견하고 이를 수정하기 위해서는 또 다른 작업이 필요한데, 이것이 바로 소프트웨어 테스팅이며, 이는 소프트웨어 개발 과정 상 필수적인 요소다.


또한 그간 소프트웨어 제품들은 전통적인 소프트웨어 영역에서는 오류가 발생해도 사용자의 이해와 함께 빠른 패치를 통해 커버할 수 있었지만, 최근 첨단 산업 군에서 소프트웨어 비중이 높아짐에 따라 소프트웨어 오류는 커다란 나제로 부각됐다.


미션 크리티컬한 기업용 애플리케이션이나 휴대폰, 자동차, 항공기, 가전제품 내부에서 오류가 발생하면 기업 업무가 마비되거나 대규모 리콜사태, 심지어는 항공기 추락과 같은 엄청난 사건이 발생할 수도 있다. 가전제품이나 휴대폰 자동차의 대규모 리콜 사례의 원인을 분석해보면 내장된 소프트웨어 문제가 대다수였다는 점은 이제 잘 알려진 사실이다.


자동차의 신형 모델에는 80개 이상의 CPU가 탑재되고, 수없이 많은 소프트웨어가 내장돼 자동차를 제어하고 고급 기능을 수행한다. 최근 자동차 리콜의 경우 많은 원인이 소프트웨어 결함으로 판명됨에 따라 소프트웨어의 품질 향상에 심혈을 기울이고 있고 그 핵심에는 소프트웨어 테스팅이 자리하고 있다.


이렇게 판매 이후에 발생하는 문제 외에도 소프트웨어의 오류는 제품 출시 시기까지 영향을 미치고 있다. 그래서 기존에는 제품 양산 직전에 테스트가 이뤄지는 것이 대부분이었는데, 그런 테스트만으로는 소프트웨어가 가질 수 있는 문제점을 커버할 수 없다는 인식이 생기게 됐고, 소프트웨어 개발 프로세스 과정에서부터 개발이 끝난 제품의 소프트웨어까지 오류를 사전에 진단하고 정상 작동 여부를 시험하는 전사적인 테스팅의 중요성이 점점 부각되고 있다.



<그림 2. 오류에 따른 수정 비용>



<그림 3.결함의 이해>


[그림. 2]는 소프트웨어 개발 과정에서 결함을 바로 잡는 데 드는 비용이 단계가 빠를수록 적게 든다는 점을 잘 나타내 주고 있다. 이와 함께 [그림. 3] 은 소프트웨어 주요 결함 중 대다수는 요구사항 정의와 설계 단계에서 발생하지만, 이런 결함을 발견하는 것은 사용자 인수 테스트 단계에서 발견하게 됨으로써 시간과 비용 측면에서 많은 누수현상이 생김을 알 수 있다. 


* 소프트웨어 개발 수명 주기에 따른 테스팅 이론은 다음 링크를 참조한다.




<그림 4. 소프트웨어 테스팅 수명 주기>


[그림. 4] 과 같이 기존의 테스트 개념이 테스트 수행이라는 수면 위로 드러난 빙산의 일부분 이였다면, 테스트 계획과 제어, 분석과 설계, 평가와 마감 등과 같은 수행 이전 단계와 이후 단계는 수면 밑에 보이지 않는 거대한 부분이라고 할 수 있다.


즉, 소프트웨어 오류를 찾아내는 것이 테스팅의 목적이라면, 좀 더 적은 비용으로 오류를 찾아내기 위해 테스트 수행 이전 단계에서부터 테스팅의 범주에서 진행해 프로젝트 수행 이후까지 포함 한다는 결론에 이르게 되었고, 이런 개념의 확장은 테스팅 업계가 마케팅 차원에서 확장시킨 것이 아니라 고객들의 필요성과 수요에 따라 확장된 것이라 할 수 있다.


완벽한 제품이나 소프트웨어를 만들기 위해서는 모든 부분을 철저하게 테스트하고 관리하면 되지만, 지금까지 오류 없는 완벽한 소프트웨어는 한 번도 출시되지 않았으며, 이는 현실적으로 유한한 리소스(시간, 비용)를 가지고 제품 또는 소프트웨어의 모든 부분을 테스트하는 것은 불가능하다는 것을 의미한다.


그래서 소프트웨어 테스팅의 주요 방법론으로서 리스크 기반 테스팅(Risk Based Testing) 을 꼽을 수 있다. 리스크는 테스팅을 시작하는 시점을 결정하고, 더 강력하고 깊이 있게 테스트할 부분을 결정하기 위해 사용될 수 있으며, 리스크 제어 활동으로 프로젝트 초기 단계부터 리스크에 미리 대처할 수 있게해 제품의 리스크 수준을 줄여나갈 수 있다.


* 리스크 기반 테스팅 기법은 다음 링크를 참조한다. - http://lyb1495.tistory.com/102


그럼 리스크는 과연 무엇인가? 리스크에 대한 정의는 다음과 같다.


  • P(f) 어떤 기능에서 결함의 발생 가능성을 의미하는 Likelehood로 표현된다.
  • C(f)는 결함이 발생되었을때 비즈니스에 끼치는 영향도를 의마하는 Impact로 표현된다.
  • 그리고 리스크는 이들 두가지 요소의 곱으로 최종 산출된다.

<그림 5. 리스크의 정의>



리스크 기반 테스팅의 전반적은 흐름은 다음과 같다.


<그림 6. 리스크 기반 테스팅 프로세스>


즉, ITAMS(Integrated Testing Asset Management System)
는 리스크 기반 테스팅 기법에 근거해 요구사항, 리스크 데이터, 테스트케이스 등 테스팅 자산을 전사적으로 관리해주며, 프로젝트의 리스크가 무엇이고 그것들의 우선순위를 식별하도록 돕는 솔루션이다.

  • 요구사항, 테스트케이스, 결과 등 테스팅 자산관리 시스템
  • ISO/IEC 29119 및 TMMi 에서 제안하는 프로세스를 구현하기 위해 구체적인 리스크 기반 테스팅을 제공
  • 리스크와 결함 분석을 통한 의사결정 지원 데이터 제공
  • UI와 데이터를 가장 효율적으로 분리할 수 있는 최신의 소프트웨어 아키텍처 적용
  • 요구사항에 대한 Traceability 제공
  • 모바일 디바이스 지원


ITAMS의 주요 구동 화면은 다음과 같다.


<그림 7. 리스크 분석>


[그림. 7]은 정해진 내부 이해 관계자가 개인적으로 리스크를 분석하고 평가하기 위한 화면이다.


모든 이해 관계자가 개인별 리스크 평가를 완료하였다면, 정해진 이해 관계자가 모여 리스크 평가 결과를 공유하고 협의를 이끌어 낸다. 이해관계자는 서로 다른 시각을 지니고 있으므로 동일한 리스크에 대해 리스크 평가 결과가 다른 경우가 훨씬 많다.


<그림 8. 리스크 데이터 시각화>


[그림. 8]은 분석된 리스크들의 커버리지 챠트 및 리스크 매트릭스이다. 


커버리지 챠트에서는 프로젝트의 리스크와 각 리스크에 할당된 리소스를 분석할 수 있다. 리스크가 높은 영역에는 상대적으로 많은 리소스(TC, 고급인력, 시간 등)가 할당 되어야 한다. 이와 같은 차트를 통해 리소스가 많이 투입되어야 하는 영역에 리소스가 올바르게 할당 되었는지, 낭비되고 있는 리소스가 존재하는지 확인할 수 있다.


일반적으로 테스팅은 제한된 시간과 자원을 가지고 수행되기 때문에 리스크의 우선순위에 따라 테스팅을 진행해야 효과적인 테스팅을 수행할 수 있다. 리스크 매트릭스는 리스크를 4가지 영역으로 구분하고 각 영역에 위치한 리스크가 무엇인지 확인할 수 있는 차트이다.


  • STA(Servere Test Area) : 가장 강도 높게 테스트 해야 하는 영역
  • ITA(Intensive Test Area) : 테스트 가치가 있음
  • STTA(Strong Test Area) : 테스트 가치고 있고, 테스트를 해야함
  • FTA(Fundamental Test Area) : 테스트할 수 있음


<그림 9. 결함 S커브>


[그림. 9]는 결합의 분포비율과 처리상태, 결함 S커브를 확인할 수 있는 화면이다.


결함 S커브는 프로젝트의 개발 기간 동안 발견 된 결함의 개수와 해결된 결함의 관계를 나타내는 그래프이다. 전형적인 결함 추이 그래프는 S곡선을 그리게 되는데 이는 프로젝트가 막바지에 이르게 될수록 발견되는 결함의 개수는 적어지고 해결되는 결함의 개수가 많아져 프로젝트의 종료 시점에는 남은 결함의 개수와 해결된 결함의 개수가 일치하게 되는 것을 의미한다.  


<그림 10. 리스크 매트릭스 구분에 따른 결함 S커브>


[그림. 10]는 결함 S커브를 리스크 매트릭스의 영역별로 확인할 수 있는 화면이다.


의사결정자는 위와 같은 데이터를 통해 제품 출시 일정에 대한 계획을 할 수 있다. 예를 들어 심각한 결함을 의마하는 STA영역에서 결함이 지속적으로 발견되고 있고, 결함 해결 추이가 지연되고 있다면 당연히 제품 출시를 미룰수 밖에 없을 것이다.


<그림 11요구사항에 대한 Traceability>


[그림. 11]은 프로젝트 요구사항에 대한 리스크 아이템, 테스트슈트, 테스트 케이스, 결함 등에 대한 연관 정보를 나타낸다.



<그림 12전체적인 화면 구성>


소프트웨어 테스팅이 소프트웨어 품질관리 있어서 필수 조건이라는 점을 인식하면서도 제대로 테스팅을 하지 않는다는 것은 자사의 제품 품질에 관심은 있지만, 향상시키지는 않겠다는 것과 마찬가지다. 글로벌 경쟁 시대에 접어들면서 품질에 대한 중요성이 나날이 증대되고 있으며, 각 산업에서의 시장 상황 또한 이를 반영해 준다.


소비자들은 이미 품질에 대해 눈을 뜨기 시작했으며, 인터넷을 통해 이런 정보를 실시간으로 공유해가고 있다. 단적인 예로, 온라인 게임의 경우 클로즈베타를 할 경우 예전엔 각종 오류나 미완성 부분에 대해 많이 격려하고 완성도를 높이기 위해 소비자들이 적극적으로 참여했지만, 현재는 유료화 단계의 서비스 품질이 아니면 시장에서 살아남을 수 없다.


 소프트웨어 테스팅 업계 관계자는 “그렇다고 무작정 소프트웨어 품질을 턱없이 고도화하자는 주장이 아니며, 제품 출시 때 자사가 필요한 소프트웨어 품질 수준만큼의 시간과 비용을 투자하라는 것”이라고 설명했다. 소프트웨어 품질은 테스팅에 소요된 시간과 비용만큼 비례하는 경향이 있지만, 어느 수준에 이르게 되면 더 이상 올라가지 않는 한계가 있다.


 STA의 권원일 대표는 “업계에서 테스팅에 관심 있는 개발자와 테스트 엔지니어 등을 대상으로 교육을 진행하다 보면 수강자들이 테스팅에 대해 너무 단편적으로 알고 있다는 것에 놀라곤 한다”고 전했다. “테스팅의 가장 중요한 개념인 테스트 커버리지(Test Coverage)에 대한 개념을 제대로 이래하고 사용하는 이는 거의 없고, 그나마 알고 있는 테스팅 개념과 기법들을 적용하고 있는 경우는 더 찾아보기 힘들다”고 토로했다.


ITAMS와 같은 솔루션을 통해 ISO/IEC 29119와 같은 테스팅 국제 표준을 국내에 소개하고, 나아가 SO/IEC 29119에 기반하고 Risk Based Testing 기법을 지원하는 통합 테스팅 솔루션으로 자리 잡아 소프트웨어는 물론 자동차, 항공기, 의료 등과 같은 첨단 산업분야에서도 고객과 성공하는 프로젝트를 만들어가는 것을 기대한다.



* 프로젝트에 도움을 주신분들









'프로젝트 > ITAMS' 카테고리의 다른 글

프로젝트 개요  (0) 2013.03.26
리스크와 테스팅  (0) 2013.03.26
소프트웨어 수명주기와 테스트 레벨  (0) 2013.03.26
소프트웨어 수명주기와 테스팅  (0) 2013.03.26
Posted by devop

댓글을 달아 주세요

프로젝트/ITAMS2013.03.26 01:43

1. 테스팅에서의 리스크


제한된 시간과 자원의 한계를 극복하기 위해서는 리스크를 고려해야 한다.


리스크(Risk) = 장애(Failure) 가능성 * 손실(Damage)

장애 가능성 = 사용빈도 * 결함 가능성 


1.1. 리스크 분류


1.1.1. 프로젝트 리스크 - 프로젝트 목적을 달성하기 위한 프로젝트의 역량 전반과 관계하는 리스크

  • 조직적인 요소기술적 이슈

  • 공급자 이슈

  • 프로덕트 리스크


1.1.2. 프로덕트 리스크

  • SW나 시스템에 의도치 않은 향후 이벤트나 위험 요소가 존재하는 잠재적인 장야 영역을 말함

  • 제품의 품질에 대한 리스크



 


2. 리스크 기반 테스팅


2.1. 절차


리스크 식별 -> 리스크 분석 -> 리스크 계획 -> 리스크 추적

 

2.2. 리스크 식별


무엇이 리스크이고 어디에 리스크가 있는지 확인


  • 기능적/기술적 아이템으로 분리

  • 요구사항에 따른 상위레벨 테스트 관련 항목

  • 아키텍처에 따른 하위레벨 테스트 관련 항목

  • 브레인스토밍 세션 이용 가능

  • 35개 이하의 리스크 아이템 식별 권장


2.3. 리스크 분석


중요하고, 복잡하고 잠재적으로 결함이 많은 부분을 분석(리스크 우선순위 결정)


2.3.1. 장애발성 가능성(Likelihood)

  • 복잡성

  • 새로운 개발의 정도

  • 상호관계

  • 크기

  • 사용된 기술의 난이도/최신성

  • 개발팀의 경험 미흡


2.3.2. 장애로 인한 영향(Impact)

  • 사용자에 의한 취급 중요도(잘 팔리는 아이템)

  • 경제적, 사회적, 회사 이미지적 피해

  • 사용강도

  • 외부적 가시성

 

제품의 리스크 요소에 해당하는 리스크 아이템 각각에 대해 리스크 수준을 표현한다.

<리스크 테이블 예시>


2.3.3. 리스크 매트릭스

  • STA(Servere Test Area) : 가장 강도 높게 테스트 해야 하는 영역

  • ITA(Intensive Test Area) : 테스트 가치가 있음

  • STTA(Strong Test Area) : 테스트 가치고 있고, 테스트를 해야함

  • FTA(Fundamental Test Area) : 테스트할 수 있음


<리스크 매트릭스 예시>


2.4. 리스크 계획

리스크 정보를 근거로 대처 방안 수립(리스크 줄이는 테스트 생성)

리스크의 강도에 따라 인력배치, 테스트 설계 기법, 리포팅, 리뷰, 테스팅에 필요한 요소들을 차별화 시켜 테스트를 수행한다.


2.4.1. 하위 레벨 테스팅

  • 기술적 리스크에 집중

  • 우선순위 : STA -> ITA -> STTA -> FTA


2.4.2. 상위 레벨 테스팅

  • 사업적 리스크에 집중

  • 우선순위 : STA -> STTA -> ITA -> FTA


2.5. 리스크 추적

리스크 및 리스크에 대한 대응을 모니터링.

  • 리스크가 높은 곳 -> 테스트케이스 수가 많음

  • 리스크가 낮은 곳 -> 테스트케이스 수가 적음


<리스크 커버리지 예시. 리스크 기반 테스팅 전략이 최적으로 구현되지 않음.>


'프로젝트 > ITAMS' 카테고리의 다른 글

프로젝트 개요  (0) 2013.03.26
리스크와 테스팅  (0) 2013.03.26
소프트웨어 수명주기와 테스트 레벨  (0) 2013.03.26
소프트웨어 수명주기와 테스팅  (0) 2013.03.26
Posted by devop

댓글을 달아 주세요