'TIP' 카테고리의 글 목록

« 2024/11 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

100弱・・100に満たない
　　　例　９５（前後）～１００未満
100強・・100を越える
　　　例　100越え～105（前後）

'TIP' 카테고리의 다른 글

Jquery 라디오버튼 디폴트 체크 (0)	2011.06.13
버그질라 사용에 관해 (0)	2011.06.08
Modify Headers (0)	2011.06.03
유용한 도스 파일 복사 커맨드 (0)	2010.06.23

"희망하지 않는다" 를 화면의 디폴트 밸류로 지정하는 경우..
jquery는 다음과 같다.

라디오 버튼을 아래와 같이 사용하고 있을 경우

저작자표시 비영리 동일조건

'TIP' 카테고리의 다른 글

○○強や○○弱とは (0)	2011.09.30
버그질라 사용에 관해 (0)	2011.06.08
Modify Headers (0)	2011.06.03
유용한 도스 파일 복사 커맨드 (0)	2010.06.23

사내에서 버그질라를 이용해서 버그를 관리하고 있다. 그러나 사용에 있어 간혹 의미가 불분명한 경우가 있어 버그질라에 대해 검색해 보았다.

bugzilla에 대해서

bugzilla는

mozilla.org에서 개발하고 제공하는 버그 추적(bug-tracking)시스템이다. 버그 트래킹 시스템은 개인이나 그룹이 어떤 프로제트를 진행함에 있어서 어느 부분에서 언제 버그가 발생했는지, 버그가 얼마나 치명적인지, 어떤 우선순위로 해결해야 하는지, 해결되었다면 누구에 의해서 언제 어떻게 해결되었는지를 DB에 남김으로써 발생된 버그에 대해서 체계적으로 관리 할 수 있도록 도와 준다.

bugzilla를 이용한 버그 관리

버그관리의 중요성

특히 팀단위로 개발을 할 경우 서로가 서로의 버그를 발견하는 경우가 있는데, 많은 경우 구두로 이러한 과정이 이루어진다. 간단하면서도 심각한 버그라면 발견시 바로 해결하기도 하지만, 많은 버그들이 뒤로 미루거나 다른일과 겹치거나 하면서 잊혀져 버린다. 그결과 버그가 계속적으로 누적되고, 발생했던 버그가 또다시 발생하고 이 버그가 해결했던 버그인지 아닌지도 헷갈리고 해결해야 되는건지 아닌건지도 헷갈리는 최악의 상황에 도달하게 된다. 때에 따라서는 소모적인 책임공방도 벌어지게 된다.

메일로 발견된 버그를 보고하면 그나마 좀 낳긴 하지만 임시방편일 뿐이라는건 사용해본 사람은 안다.

결국 프로젝트는 이런저런 자잘한 버그들 때문에 문제가 계속되고 어찌어찌해서 급하게 출시를 하더라도 완성도가 떨어지는 제품을 고객에게 내놓게 된다.

이런 문제를 해결하기 위해서 전문제품을 구입하거나, 팀이나 회사차원에서 나름대로 고심해서 시스템을 구축하기도 하는데, 솔직히 왠만한 규모의 개념있는 회사가 아닌다음에야 이런건 신경도 쓰지 않는다. 다행히도 공개되었으면서도 사용하기 편하고 강력한 버그트래킹 시스템이 있으니 바로 bugzilla다.

bugzilla의 설치

bugzilla는 영어권에서 개발된 프로그램이라서 모든 메시지가 영어로 되어있다. 그러나 한글화된 버젼이 있으니 이걸 받아서 설치하면 된다. [http]

bugzilla 한국어 프로젝트를 방문해서 최신버젼을 다운받도록 한다. 여기에서는 2.16.3 한글 버젼을 기준으로 설치하도록 하겠다.

다음은 bugzilla설치를 위한 기본 환경이다.

bugzilla는 웹기반 프로그램으로 Apache(12)나 IIS서버가 설치되어 있어야 한다.
Perl(12) CGI(12)프로그램이다. 반드시 Perl이 설치되어 있어야 한다.
버그관련 정보를 DB에 저장하기 위해서 Mysql을 이용한다.

웹서버설치와 Mysql(12)설치는 여기에서 다루지 않을 것이다. 이와 관련되어서는 다른 사이트들을 참고하기 바란다.

Perl 모듈 설치

bugzilla는 상당히 방대한 시스템이며, 대부분이 perl로 이루어져 있기 때문에 perl 내부적으로 많은 모듈을 사용한다. 이런 이유로 제대로 bugzilla를 설치하기 위해서는 다음과 같은 모듈이 필수 적으로 설치되어 있어야 한다. 물론 Perl은 당연히 설치되어 있어야 하며 5.6.1 이상을 권장한다. 대부분 5.8이상이 설치되어 있으니 perl이 문제되는 경우는 없을 것이다.

Template(2.07)
AppConfig(1.52)
Text::Wrap(2001.0131)
Data::Dumper
DBD::mysql(1.2209)
DBI(1.13)
Date::Parse
CGI::Carp

다음은 반드시 필요하진 않지만 부가적인 기능을 위한 옵션 모듈들이다.

GD(1.10) 버그 차트기능
Chart::Base(0.99c) 버그 차트기능
XML::Parser Xml
MIME::Parser email기능

위의 모든 모듈들은 [http]

CPAN에서 구할 수 있다. 모듈을 일일이 다운받아서 컴파일하고 설치해도 되겠지만 다음과 같이 자동으로 설치할 수도 있으니 활용해보기 바란다.(필자는 그냥 일일이 받아서 설치했다)

# perl -MCPAN -e 'install "Bundle::Bugzilla"'

위의 방법을 이용하더라도 GD, Chart::Base, MIME:Parser은설치가 되지 않는다.

bugzilla 설치

bugzilla를 다운받아서 웹서버의 cgi(12)디렉토리에 압축을 풀도록 한다.

그다음 checksetup.pl을 실행해서 bugzilla의 환경을 설정한다. mysql계정등의 정보를 설정하게 되는데, 간단하게 설정을 마칠 수 있을 것이다.

# ./checksetup.pl

이제 버그질라 페이지에 접근하도록 한다. 만약 에러메시지를 출력한다면 서버에서 직접 ./index.cgi를 실행시켜서 제대로 작동이 되는지 확인해보자. 문제없이 작동하는데도 에러가 떨어진다면 파일권한 문제인 경우가 대부분이다. cgi파일들이 실행권한으로 되어 있는지, 각 디렉토리가 nobody권한으로 읽을 수 있도록 되어있는지 확인해 보자.

bugzilla를 설치하기 전에 간단하게 테스트해보고 싶다면 [http]

joinc bugzilla에서 테스트해보기 바란다.

bugzilla 상태 정보

버그를 관리하고 감시하기 위해서 버그질라는 발생된 버그에 대해서 심각도와 우선순위등을 할당하게 된다. 다음은 이들 버그의 상태정보에 대한 정보들이다. 아래의 용어들에 대해서 명확히 이해를 하고 있어야 버그관리가 제대로 이루어질 수 있을 것이다.

버그 심각도 (serverity)

Blocker : 개발 혹은 테스트 작업을 진행할 수 없게 만듦
Critical : 프로그램이 깨지거나, 데이터 손상및 메모리 누수가 발생함
Major : 기능상의 중요한 결점이 발견됨
Normal : 일반적인 문제로 반드시 고쳐야할 버그
Minor : 기능상 그리 중요하지 않은 결점, 혹은 쉽게 해결할 수 있는 문제
Trivial : 오탈자, 텍스트 정렬문제와 같은 외형적 문제
Enhancement : 기능 및 성능개선 관련 사항

버그 처리 우선순위 (Priority)

수정해야할 버그들의 중요도와 순서를 기술한다. 프로그래머 혹은 엔지니어가 자신들이 해야할 일에 대한 우선순위를 결정할 수 있도록 정보를 제공한다.

즉시(P1) : 가장 먼저 처리해야함
긴급(P2)
보통(P3)
낮음(P4)
없음(P5) : 가장 나중에 처리해도 됨

버그 상태정보(Status)

  +-----------+       +-------------+        +------+       +-------------+ 
  | 버그 발생 | ----> | UNCONFIRMED | -----> | NEW  | ----> | ASSIGNED    |  
  +-----------+       +-------------+        +------+       +-------------+ 
                            |                   |                | | | 
                            |                   |                | | | 
        +-------------+     |                   |                | | | 
        | RESOLVED    | <---+                   |                | | | 
        |             | <-----------------------+                | | | 
   +----|             | <----------------------------------------+ | | 
   |    |             | <---------------------------------+        | | 
   |    |             | <---+                             |        | | 
   |    +-------------+     |                             |        | | 
   |                        |                             |        | | 
   |    +-------------+     |                             |        | | 
   +--->| VERIFIED    | ----+                             |        | | 
   +----|             | ----------------->>---------------|--------+ | 
   |    +-------------+                                   |          | 
   |                                                      |          | 
   |                                                      |          | 
   |    +-------------+             +----------+          |          | 
   +--->| CLOSE       | ----------> | REOPENED | ---------+          | 
        |             |             |          | ------------>>------+   
        +-------------+             +----------+

버그의 상태를 나타낸다.

UNCONFIRMED(승인되지 않음)

최근에 데이터베이스에 등록된 버그로, 아무도 이 버그에 대해서 확인을 해보지 않았다. 즉 아직 버그인지 아닌지도 검증이 되지 않은 상태다. 등록된버그를 Confirm할수 있는 사용자는 이 버그를 승인할 수 있으며, New(새로운버그)로 하거나 해결될 경우 (RESOVED)등의 상태로 변경이 가능하다.
NEW(신규버그)

이 버그는 최근에 버그를 할당받은 담당자에 의해서 버그로 인정되었으며, 이에 대한 처리가 이루어져야 한다. 이 상태의 버그는 수락(accept)될 수 있으며, 필요한 경우 다른 사람에게 전달될 수(ASSIGNED) 있다. 만약 다음 단계로 더 이상 진행이 안된다면 계속 NEW상태로 남아 있을 것이고, 문제가 해결된다면 RESOLVED 상태로 전이될 수도 있을 것이다.
ASSIGNED(할당됨)

이 버그는 아직 해결되지 않았지만, 버그를 처리할 수 있는 적합한 사람에게 할당되어져 있음을 의미한다.
REOPENED(다시 오픈됨)

이전에 해결(CLOSED)되었던 버그라고 하더라도 다시 재현될 수 있고, 혹은 담당자가 봤을때 버그처리가 명확하게 되어있지 않음을 인지할 수도 있을 것이다. 이경우 REOPENED 상태가 될수 있을 것이다. 이상태의 버그들은 ASSIGNED 혹은 RESOLVED 상태로 전이될 수 있다.
RESOLVED(처리됨)

처리가 되었으며, QA(품질보증)담당자의 검증을 기다린다. 이 상태의 버그들은 REOPEND, VERIFIED 상태로 혹은 CLOSED 상태로 전이될 수 있다.
VERIFIED(검증)

QA담당자가 버그와 처리결과를 보고 적절하게 처리가 완료되었는지를 검증하게 된다.
CLOSED(닫힘)

버그가 완전히 사라졌다고 간주되는 상태다. 그러나 불행히도 다시 살아나는 경우가 발생할 수 있는데, 이때는 REOPENED 상태가되어야 한다.

버그 처리결과

버그에 어떤 일이 발생했는지를 나타낸다.

FIXED(해결됨)

테스트가 완료되었으며 버그트리에 해결되었다고 표시된다.
INVALID(버그아님)

기술된 문제는 버그가 아니였음
WONTFIX(해결불가)

기술된 문제는 해결될 수 없는 버그이다.
LATER(나중에)

기술된 문제는 본 제품에서는 수정될 수 없다. 차후 제품에 수정이 가능할 수 있다.
REMIND(기억할 것)

기술된 문제는 본 제품의 현재 버젼에서는 수정할 수 없는 버그이지만, 앞으로 계속 영향을 끼칠 것으로 예상된다.
DUPLICATE(중복됨)

기술된 문제는 기존의 버그와 중복되었다(혹은 유사한 버그가 이미 존재함). 버그를 중복되었다고 표시하기 위해서는 기존버그 번호를 필요로 한다.
WORKSFORME(파악할 수 없음)

버그를 재연해 보려고 많은 노력을 기울였지만 실패했으며, 생성된 코드를 분석해봐도 왜 보고된 문제가 발생했는지를 파악할 수 없는 상태이다. 이 문제를 해결하기 위해서는 추가적인 정보가 필요하고, 그럴경우 이 버그는 다시 할당될 수 있다. 혹은 문제를 파악할 수 있을 만한 다른 개발자에게 할당할 수 있을 것이다.

플랫폼

버그가 보고된 대상 하드웨어 플랫폼 정보를 기록

OS

버그가 보고된 대상 운영체제 정보를 기록한다.

버그 등록하기

이제 버그를 등록해야될 차례다. 그런데 버그를 등록한다고 해서 바로 등록되는게 아니다. 버그를 관리해야할 제품(Products)와 구성되는 컴포넌트(Component)를 먼저 만들어야 한다. (하나의 제품은 여러개의 컴포넌트로 구성되어 있고, 각 컴포넌트 별로 버그를 관리할 필요가 있기 때문이다.)

Products메뉴를 이용해서 Products를 생성할 수 있으며, Products가 생성이 되었다면, Component를 입력할 수 있다. Component까지 만들어졌다면 버그관리를 위한 기본적인 환경이 만들어 졌다고 볼 수 있다.

출처:http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Development/Env/bugzilla

저작자표시 비영리 동일조건

'TIP' 카테고리의 다른 글

○○強や○○弱とは (0)	2011.09.30
Jquery 라디오버튼 디폴트 체크 (0)	2011.06.13
Modify Headers (0)	2011.06.03
유용한 도스 파일 복사 커맨드 (0)	2010.06.23

파이어 폭스의 애드온

용도는 주로 모바일 웹 개발용이다.

흔히 HTTP리퀘스트를 전송할 때 User-Agent 문자열을 서버로 신고한다. [User-Agent:] 의 접두어를 가진다. 이 Modify Headers를 활용하면 User-Agent를 추가, 변경 하는 것이 가능해 진다.

과거에는 각 벤더에서 제공하는 모바일 에뮬레이터 등을 이용해서 개발을 진행했으나 한계가 있었다. 여러 기종에 대응을 하지 못한다거나 특정 구문에서는 에러를 뱉어 내며 퍼져버리기도 했다.

그러나 이 Modify Header를 이용하면 모바일 에뮬레이터가 주던 불편함을 잊을 수 있게 된다. 물론 특정 패턴의 테스트에는 의존성이 낮아질 수도 있다. 대부분의 테스트 패턴에서 불편함없이 진행할 수 있게 된다.

User-Agent 대해 짚어보고 가자

이용자가 어느 프로토콜을 기반으로 데이타를 이용할 때 쓰여지는 소프트웨어나 하드웨어를 지칭한다. 대표적으로는 웹브라우저가 되겠다.

예 )
Mozilla/5.0 (Windows NT 5.1) ............

User-Agent의 구조에 대해 알고 싶다면 http://useragentstring.com 를 방문해 보라.
User-Agent를 붙여넣으면 각 항목에 대한 정보를 제공해 준다.

아래 그림은 Modify Header를 설치 후 3개의 User-Agent를 설정한 그림이다.

위 그림의 설정대로라면 (Modify Headers의 설정이 유효하다면) 파이어 폭스는 AU의 휴대전화의 한 모델로서 User-Agent를 서버로 보내게 된다.

다음은 위의 설정대로 구글에 접속해 본 화면이다. (파이어 폭스의 화면 크기를 모바일처럼 줄이고 각 메뉴들을 보이지 않도록 설정했다.)

표시모드가 모바일인 것을 알 수 있다.

Modify Headers는 설정한 User-Agent의 내용을 import / export 할 수 있다.
다수의 기종을 반복해서 테스트해야 하는 경우라면 유용하게 사용할 수 있다.

또한 User-Agent이외에도 서버로 보내고 싶은 정보가 있다면 추가해서 보낼 수 있다.

모바일 에뮬레이터에 좌절해 본 적이 있는 사람이라면 써 볼만하다.

아직도 2G 세대 이하의 모바일 웹 개발을 하거나 혹은 웹개발 후 휴대폰에서 우리 웹이 어떻게 보일지 궁금하다면 써 보라.

저작자표시 비영리 동일조건

'TIP' 카테고리의 다른 글

○○強や○○弱とは (0)	2011.09.30
Jquery 라디오버튼 디폴트 체크 (0)	2011.06.13
버그질라 사용에 관해 (0)	2011.06.08
유용한 도스 파일 복사 커맨드 (0)	2010.06.23

for /f "tokens=1" %i in (d:\music\number.txt) do copy 04_0280409100004.g726 TestMusic_%i.g726

number.txt 는 일련번호가 저장되어 있는 텍스트 파일

위 명령어는 04_0280409100004.g726 이라는 원본 파일을 TestMusic_0001.g726 부터 TestMusic_9999.g726까지 복사해 준다. 숫자의 범위는 텍스트 파일에 지정하기 나름이다.

반복해서 (for) 복사를 (cpoy)하는 커맨드이다.

똑같은 형식의 테스트용 파일이 많이 필요할 때 사용했다.

저작자표시 비영리 동일조건

'TIP' 카테고리의 다른 글

○○強や○○弱とは (0)	2011.09.30
Jquery 라디오버튼 디폴트 체크 (0)	2011.06.13
버그질라 사용에 관해 (0)	2011.06.08
Modify Headers (0)	2011.06.03

'TIP' 카테고리의 다른 글

'TIP' 카테고리의 다른 글

사내에서 버그질라를 이용해서 버그를 관리하고 있다. 그러나 사용에 있어 간혹 의미가 불분명한 경우가 있어 버그질라에 대해 검색해 보았다. bugzilla에 대해서

bugzilla를 이용한 버그 관리

버그관리의 중요성

bugzilla의 설치

Perl 모듈 설치

bugzilla 설치

bugzilla 상태 정보

버그 심각도 (serverity)

버그 처리 우선순위 (Priority)

버그 상태정보(Status)

버그 처리결과

플랫폼

OS

버그 등록하기

'TIP' 카테고리의 다른 글

'TIP' 카테고리의 다른 글

'TIP' 카테고리의 다른 글

티스토리툴바

사내에서 버그질라를 이용해서 버그를 관리하고 있다. 그러나 사용에 있어 간혹 의미가 불분명한 경우가 있어 버그질라에 대해 검색해 보았다.

bugzilla에 대해서