모듈 수정 시 관련테스트 찾아내는 법에 대하여..
강석천
수행이 되고 있는 상태입니다.
유지보수 담당자들이 버그 수정 뒤 회귀 테스트를 수행하려고 하나,
전체 테스트가 일단 20시간이 넘게 걸려서, 사람들이 전체 테스트를 잘 수행하지
않으려고 합니다. 그래서 일단 개발자들이 임의로 나누어 놓은 해당 모듈에 대한
테스트 슈트만 수행을 하는데, 이게 좀 임의로 나눈 것이기도 하고, 타 모듈
테스트 중에서도 연관이 있는 테스트가 있을 수 있을겁니다. 일단 개발자들은
관련 테스트 슈트만 돌리고 있긴 한데.. 좀 불안해보여서요.
수정된 모듈에 대하여 엮기는 테스트를 좀 더 정밀하게 찾을 방법이 없을까요?
개인적인 아이디어로는 Code Coverage Tool (gcov)로 해당 테스트가 커버하는
코드들 데이터를 DB 화 한뒤, 개발자가 특정 코드를 수정하면 역으로 수정했던
코드를 커버하던 모든 테스트를 검색하는 방법을 생각하고 있습니다.
(물론 주기적으로 coverage data 를 갱신해주어야 하겠죠. 신규 코드 추가 / 삭제 등)
따름 질문 : continuous test 를 수행할 경우 전체 유닛테스트를 수행하나요? 아니면
테스팅 프레임워크가 알아서 관련된 테스트들을 찾아서 수행해주나요?
Jeonghoon Park
--
감사합니다.
박정훈 드림
Thanks and regards,
Jake Park
Youngrok Pak
June Kim
> C/C++ 개발환경이고, 현재 전체 개발자 테스트의 경우 Daily Build 뒤
>
> 수행이 되고 있는 상태입니다.
>
> 유지보수 담당자들이 버그 수정 뒤 회귀 테스트를 수행하려고 하나,
>
> 전체 테스트가 일단 20시간이 넘게 걸려서, 사람들이 전체 테스트를 잘 수행하지
궁금한 점:
* 테스트 수행 시간에 파레토 법칙이 적용되는지. 즉, 80%의 시간을 잡아먹는 20%가 존재하는지. 그리고 그것은 어떤 것들인지.
* 테스트들 간에 중복(redundancy)이 있는지? 얼마나 될지?
* 24시간 간격으로 계속 전체 테스트를 자동으로 돌리는 독립 테스트 전용 서버를 두고, 사람들로 하여금 밤 12시에는 모든
코드가 "전체 테스트를 통과"하는 것이 디폴트라고 생각하게 하고, 그리고 그것을 지키도록 유도하는 것이 가능할지?
현길조
근래에 읽은 "How we test software at Microsoft" 7장 Analyzing Risk with Code Complexity 에 보면
윈도우 항상성 팀 (Windows Sustained engineering Team)에서는 모듈별 결함 발생 빈도와
라인수, 사이클로메틱 복잡도, 힐스테드 지표, 객체지향 지표(Fan-in,Fan-out 등) 등의 복잡도 지표들을
조합해서 리스크를 분석해서 리스크가 높은 모듈에 대해서만 회위 테스트를 수행한다고 합니다.
패치가 나올때 마다 모든 테스트를 다하는 것은 불가능하니 이렇게 한다고 합니다.
자세한 조합에 대한 내용은 나오지 않지만 대략 참조는 해보셔도 좋을 것 같습니다.
참고로 How we test software at Microsoft 는 곧 번역본이 나올 예정입니다.
그럼 QSM 스터디에서 뵙 길 바라며, 항상 에너지 넘치는 하루 되세요.
현길 올림.
[1002]
요. ^^
(개인적으로라도 베어본 3-4대 구입해서 돌리고 싶은 심정)
* DB인지라 AIX,HP-UX,Linux,Windows,Solaris 지원을 해야 하고 빌드가 GCC 로 통일된게 아닌 네이
티브 컴파일러를 쓰고 있는 중인지라.. Linux/Windows 는 몰라도 다른 장비의 경우 신규 투자가 어렵습니다.
* coverage 를 이용한 알고리즘만 두고 보면 비교적 간단해서요. 구현 자체야 일주일 사이드 잡으로 가능할 것 같고..
회사에서 PC 20대 도입해주는데 걸리는 시간보단 빨리 구현할 것 같은 예감이 들어서요 ;;
그리고 Continuous Testing 이 활성화 되는 분위기라면 혹 이미 구현된 게 있지 않을까 하는 (자바진영에서라
도..) 추측에.. ^^
On 6월9일, 오후4시47분, Youngrok Pak <pak.young...@gmail.com> wrote:
> 저라면 어떻게든 테스트 수행시간을 줄이려고 할 것 같습니다. 20시간이 걸린다면 PC 20대 사서 그리드로 구축하고 돌리면 1시간 만에
> 결과를 볼 수 있지 않을까요? 수정한 모듈과 관련된 테스트를 정확하게 찾아내는 알고리즘을 연구하는 비용보다 PC 20대의 가격이 더
> 저렴할 듯 합니다.
>
> 2009/6/9 강석천 <free1...@gmail.com>
[1002]
현재 BTS 대비 수정된 라인들에 대한 트래킹은 이루어지고 있습니다. Bug 관련 패치 커밋시 커밋로그에 버그 번호를 같이 입력
합니다. 그리고 BTS 에서 해당 버그 클릭하면 버그 패치를 위해 수정한 코드들에 대하여 viewvc 링크가 걸리게끔 되어있습니
다.
정량화된 문서는.. 작은 회사의 내부 팀에서 하는 일인지라 요구하질 않습니다. ^^
즐거운 하루 되세요.~
On 6월9일, 오후4시36분, Jeonghoon Park <xel...@gmail.com> wrote:
> 1002님, 오랜만입니다.
> 1002님은 개인적으로 좀 알아서 언제나 많이 고민해 보신다는걸 아니까 대답을 좀 건성으로 드려도 될 것 같아, 언제나 마음 편히 답하게
> 되네요.
>
> 개발자들만이 아니고 흔히 '테스터'라는 직업군으로 분류되는 QA들도 짜증내 할겁니다. 이유는 테스트가 핵심을 짚지 못하고 있기
> 때문입니다.
>
> 길게 설명할 필요 없이 석천님이시니까 핵심만 알려드려도 될 것 같습니다.
>
> 버그 관리툴을 BTS - Bug Tracking Tool 이라고 하잖아요. ^^ BTS의 기록들은 testcase들을 optimize
> 하는데도 사용합니다. 제품에 익숙해지는데 까지는 지속적인 full test가 필요하지만, 그 이후에는 테스트 자체에도 milestone을
> 설정하고, 그 외의 시간에는 testcase optimization과 regression test에 집중하시는 것이 프로젝트에 많은
> 도움이 됩니다. 그리고 이 방법은 MMO 게임에서도 사용 가능합니다. (게임 업계 PM들이 많아서 힌트만 드립니다. 나머지는 늘
> 그렇듯이 알아서 하세요.)
>
> 주주들에게 보고 가능할 정도의 문서화된 정량화를 원하신다면 다른 방식으로 접근하셔야 할 겁니다만... (제 개인적인 의견으로는, 그런
> 문서들은 보고하는데는 의미가 있겠지만 프로젝트 전체에는 의미 없는 데이터가 될 것입니다.)
>
> 몇 달 전에 제가 긴 글을 썼을 때 읽으신 분이 몇 분이나 되시는지 모르겠지만... QA를 하다보면 제품의 어디가 고장이 날 건지
> 귀신처럼 예측하는 능력이 자연스럽게 embeded됩니다. 단, 애자일에서 이 부분을 어떻게 응용할 지는, 저보다 더 잘하시는 분들이
> 많으시니, 언급하지 않고 넘어 가겠습니다.
>
> 제 대답이 아주 조금은 도움이 되셨으면 좋겠네요.
> 수고하세요~ ^^
>
> 2009년 6월 9일 (화) 오후 4:07, 강석천 <free1...@gmail.com>님의 말:
[1002]
순수하게 기능성 테스트 (품질, 스트레스 테스트 등 이것저것 돌리는게 많아서) 는
한 브랜치 기준 20000여개 정도 됩니다.
* 테스트 수행 중복은 확실히 존재할건데.. 이를 찾아내는 작업은 아직 못해봤습니다.
개발자들이 테스트를 만들 때 기존 테스트 코드에 대한 C&P 를 자주 하는지라, 10-30%정도 되지 않을까
추측합니다.
(게다가 UnitTest 가 아닌 Acceptance Test 에 가까운지라.. 테스트 프로그램과 대상 프로그램 (서버)
이 다른
프로세스이고, 서버 clean 작업도 자주 수행됩니다.
* 플랫폼 별 테스트 때문에 독립 테스트 전용 서버가 좀 많습니다. 서버 별로 성능도 달라 테스트 완료되는 시간도 다릅니다.
(2-3일 걸리는 장비도..;)
On 6월9일, 오후4시50분, June Kim <junea...@gmail.com> wrote:
> 2009/6/9 강석천 <free1...@gmail.com>:
[1002]
현 코드의 규모가 10배 정도 증가한다면 해당 모듈을 선택적으로 테스트를 돌려야 하겠지만,
300만 라인도 안되는 프로덕트인데 좀 더 빨리 돌아야 하지 않겠냐는 생각이 들어서요;;
현재 측정은 모듈 라인수, 사이클로메틱 복잡도, 커버리지는 측정하고 있고, 모듈별 결함 발생 빈도는 품질측정 관련 DB 에서 질
의 가능합니다.
궁금한 점이..
1. Fan-in, Fan-out 이 모듈에 대한 Intenal/External Dependency 를 의미하는것인가요?
2. 힐스테드 지표는 어떤 것인가요? 아직 잘 몰라서요..~ ^^
> > 2009년 6월 9일 (화) 오후 4:07, 강석천 <free1...@gmail.com>님의 말:
[1002]
해당 아이디어에 대한 예상되는 문제점이나 혹은 미리 유의해야 할 점이나, 이미 경험하신 분의
소감, 혹은 확장판 등도 환영합니다. ^^;
Youngrok Pak
시험삼아 데이터를 수집해보는 것도 좋을 것 같습니다. 이슈 트래커의 이슈 하나 처리하느라 수정했을 때 한 번에 깨지는 테스트가 몇 개인지를, 또 그 때 실제로 커버리지가 있는 테스트는 몇 개인지, 그런 숫자들을 1,2주간 재본다면 이 방법의 효과를 어느 정도 예측할 수 있겠지요.
현길조
할스테드 지표는 4가지 지표(독립적인 연산자의 개수,독립적인 피연산자의 개수,총 연산자 개수,총 피연산자 개수)에 기반한 복잡도 측정방식인데 이것들의 조합으로 다른 지표들을 산출합니다. 예를 들어 코드의 길이는 N1과 N2를 더해서 계산하고, 난이도는 (n1 / 2) * (N2 / n2) 과 같은 공식이 사용된다고 하네요. 자세한 사항은 위키를..
[1002]
* OS 의 경우 천만 라인 단위이고, 예전에 모 D-TV 관련 회사 이야기를 들으니 OS 밑단부터 다 만드는지라 천만라인 단
위 규모라고 들어서요.; 그에 비해서는 아직..;
* 아직 팀이 생긴지 얼마 안되어서, 일단 의미 있는 정보들을 수집하는 것을 먼저 하고 있습니다. 일단은 각 팀의 팀장님들 참
고용이고, 향후에는 유지보수 및 품질향상 팀과 같이 구체적인 액션도 진행할 생각입니다.
On 6월10일, 오전12시52분, 현길조 <gedw...@gmail.com> wrote:
> 크헙 300만 라인이면 엄청난거 아닌가욤 -_-;;;
>
> 팬인,팬아웃은 말씀하신 거 맞습니다.
> Fan-in : 자신을 호출한 클래스의 수
> Fan-out : 자신이 호출한 클래스의 수http://en.wikipedia.org/wiki/Fan-out
>
> 할스테드 지표는 4가지 지표(독립적인 연산자의 개수,독립적인 피연산자의 개수,총 연산자 개수,총 피연산자 개수)에 기반한 복잡도
> 측정방식인데 이것들의 조합으로 다른 지표들을 산출합니다. 예를 들어 코드의 길이는 N1과 N2를 더해서 계산하고, 난이도는 (n1 /
> 2) * (N2 / n2) 과 같은 공식이 사용된다고 하네요. 자세한 사항은 위키를..http://en.wikipedia.org/wiki/Halstead_complexity_measures
> 이외에도 CK 메트릭도 많이 쓴다고 합니다.http://www.pacis-net.org/file/2005/158.pdf
>
> 아마도 어떤 메트릭을 어떻게 조합해서 어떻게 리스크를 관리하실지는 개발팀과 많은 협의가 필요할 것 같습니다. 좋은 통찰을 얻으시면
> 공유해주시면 많은 도움이 될 것 같습니다.
>
> 2009/6/9 [1002] <free1...@gmail.com>
[1002]
제 테스트 하려는 내용과 상관없이 불필요하게 맨날 Coverage 에 체크될 것 같습니다.
한편으로는 '유닛테스트 레벨의 테스트 도입이 없으면 현 상황의 해결이 어렵다'를 좀 더 강하게 어필할 수 있는 자료가 될 듯도
하네요. (현 테스트가 느릴 수 밖에 없는 이유 등등) 슬슬 유닛테스트에 대하여 몇몇 분들이 필요성을 이야기 하시나 여전히 구체
적인 액션까지 이어지질 못해서요.
가볍게 실험해보고 피드백을 보고 판단해봐야겠습니다. 좋은 지적 감사합니다.
On 6월9일, 오후6시11분, Youngrok Pak <pak.young...@gmail.com> wrote:
> 그 방식으로 구현하는 것 자체는 어렵지 않을 것으로 봅니다. 다만, 그게 효과를 볼지가 의문입니다. 테스트 케이스가 거의
> acceptance test에 가깝다면 뭐 하나 수정했을 때 대부분의 테스트가 다 걸리는 상황도 흔하게 있을 것입니다. 작은 웹
> 프로젝트의 경우에도 작은 수정 하나 했을 때 유닛 테스트는 하나 깨져도 인수 테스트는 절반씩 깨지는 일이 생기곤 합니다. 웹은 페이지별로
> 독립성인 높은데도 이런 일이 생기는데 DB처럼 복잡하게 얽혀 있는 시스템이라면 커버리지로 찾아서 잘해야 평균적으로 절반 정도로 줄이는데
> 그치지 않을까요?
>
> 시험삼아 데이터를 수집해보는 것도 좋을 것 같습니다. 이슈 트래커의 이슈 하나 처리하느라 수정했을 때 한 번에 깨지는 테스트가 몇
> 개인지를, 또 그 때 실제로 커버리지가 있는 테스트는 몇 개인지, 그런 숫자들을 1,2주간 재본다면 이 방법의 효과를 어느 정도 예측할
> 수 있겠지요.
>
> 2009/6/9 [1002] <free1...@gmail.com>