출처는 역시 STEN
안녕하세요~
기존에는 Black box test 위주로 test를 해오다가
이번에 회사를 옮기면서 White box test 를 지원해야 하는데요
도무지 감이 안오네요
개발자에게 요청해야할것이 있나요?
아니면 제가 소스를 직접보고 구조를 파악해서 test를 해야하는것인가요
휴대폰사업이라 소스분량이 장난이 아닙니다.
white box test 가 가능하긴 한건지 ㅠㅠ
white box test 를 지원하려면 언어를 공부해야 할까요?
기존에 해오던 케이스도 없고 제가 맨바닥부터 팀을 짜야합니다.
도움을 주세요~~
seopro97
08-09-11 14:34
white box를 하는데 있어서 몇가지 Tool들이 있습니다. 하지만, 그 가격이 만만치가 않습니다. 무엇보다, White Box를 하기위해서는 기본적인 Programming 능력이 있어야 합니다. Source를 보면서 논리적인 부분의 이상이라든지(Coding Syntax Error는 제외입니다.) 아니면 Memory나 File관련 부분의 Exceptional Case 등에 대해서 최소한 알아야 하겠지요. 휴대폰 사업분야라니 기본적으로 C나 C++ 로 대부분 구현이 되었을터이고, 개발자들에게 요구사항서부터 구조설계서나 상세설계서등의 High Level 설계서까지 요청을 하셔서 비교를 하시면서 제대로 Implement가 되었는지 Inspection해보시는 것도 많은 도움이 되리라 생각됩니다. 수고하세요.
white box를 하는데 있어서 몇가지 Tool들이 있습니다. 하지만, 그 가격이 만만치가 않습니다. 무엇보다, White Box를 하기위해서는 기본적인 Programming 능력이 있어야 합니다. Source를 보면서 논리적인 부분의 이상이라든지(Coding Syntax Error는 제외입니다.) 아니면 Memory나 File관련 부분의 Exceptional Case 등에 대해서 최소한 알아야 하겠지요. 휴대폰 사업분야라니 기본적으로 C나 C++ 로 대부분 구현이 되었을터이고, 개발자들에게 요구사항서부터 구조설계서나 상세설계서등의 High Level 설계서까지 요청을 하셔서 비교를 하시면서 제대로 Implement가 되었는지 Inspection해보시는 것도 많은 도움이 되리라 생각됩니다. 수고하세요.
FenderMani…
08-09-11 17:19
EX-
입력값 : 로그인 안한 상태에서 글 적기 시도
기대값 : "로그인 후에 작성 가능합니다...!!!!!!!!!!" 팝업 -> 로그인창 이동
아울 억울해...ㅡㅜ
흐억... 나름데로 장문의 글을 적었는데.. 로그인이 안된 상태라고 내용이 날라가 버렸네요.. 다시 적겠습니다..ㅡㅡ (아까 처럼 자세히 적을 자신은 없네요...ㅠㅠ) 사이트 개선 부탁합니다.. EX- 입력값 : 로그인 안한 상태에서 글 적기 시도 기대값 : "로그인 후에 작성 가능합니다...!!!!!!!!!!" 팝업 -> 로그인창 이동 아울 억울해...ㅡㅜ
FenderMani…
08-09-11 17:30
화이트박스 테스팅에 대한 애매하고 개인적인 의견입니다..
혼자만의 방법입니다.. 검증 안됬고요..ㅡㅡ
참조만 하시기 바랍니다..
우선 기본적인 프로그래밍에 대한 이해는 반드시 필요 합니다..
하지만 기본적인 이해로는 소스상의 오류를 검출하는건 거의 불가능하다고 봅니다..
기본적인 오류는 개발자에 의해 이미 수정되는 경우가 대부분입니다..
또한 소스만 보고 그 안의 오류를 검출한다면 이미 높은 수준의 개발 능력이 있다고 생각합니다..
그렇다고 화이트박스 테스트가 비현실적이냐..?
그렇진 않습니다.. 저두 나름데로의 방법으로 테스트를 해왔습니다..
제가 혼자서 해온 방법이라서 정답이 될순 없지만 몇가지 적어봅니다..
"White Box Testing는 소스코드에 대한 절대적 이해 필요.!!"
<= 요건 절대 아니라고 봅니다..!!! ^^
간혹 주위에 그런 분들이 있으셔서.. (물론 높은 수준의 이해는 많은 도움이 되겠죠..ㅡㅡ)
1. 사용되어지는 변수의 선언 및 해제의 명확한 확인
(이건 기술적리뷰라 해야 할지..뭐라 해야할지..ㅡㅡ 하여간 몇번 쓸쓸히 해봤습니다..)
- 대부분의 SW의 결함은 메모리에서 기인한다고 보고 있습니다..
- 개발 자체가 일정부분 메모리와의 싸움입니다.. (특히 임베디드)
- 변수의 사용을 쫓아가서 사용과 해제를 확인하는데..
보기 힘들더군요..ㅡㅡ Source Insight등의 Editor나 Viewer를 이용하는데..
오류 검출률이 상당히 낮았습니다.. (왜냐..? 이미 개발자에 의해서 수정되어서..ㅡㅡ)
2. 요구사항이나 설계문서상의 입력값의 범위 확인
- Define 되어 있는 입력 요구 변수에 대해서 확인 합니다..
- 저는 여기서 경계값, 동등분할등을 사용했습니다..
(White - Black Box의 경계가 모호해 집니다..ㅡㅡ)
- 이런 방식의 테스트는 최소한 저한테는 유용하더군요..^^
3. 분기, 결정문을 이용한 시나리오 테스트 케이스 작성
- 교재나 자료의 예제처럼 간단하다면 모를까..
실제 코드에서 모든 조건문에 대한 분기를 고려하는건 거의 불가능에 가깝습니다..
그럼 안되냐..? -> 그래도 전 씁니다..
어떻게..? -> 알맞게.. 잘.. ㅡㅡ
- 전체의 흐름 보다는 테스트할 대상의 동작에 따른 모듈의 범위를 정합니다..
설계/요구 문서상의 동작과 소스상의 동작을 일으키는 분기나 결정 포인트를 잡는겁니다..
(폰쪽이라고 하시니깐.. 예를 들면..
"메세지 처리 흐름", "카메라 동작 상태전이", "통화중 발생 가능 이벤트"등등등으로..^^)
-요구사항 VS 구현내용 확인 필요
흐름도 혹은 순서도, 전이도 작성에서 주의 해야 합니다..
예를 들면 (책이나 교재에 나오는 사항으로 비유하겠습니다..)
요구사항 : "세금이 40세 이상이면 10% 감면, 자녀가 있으면 20% 감면"
입력값 : 수입이 100만원, 40세이상, 자녀있다..!!
결과 1 : 10% 감면하면 90만원 -> 다시 20% 감면하면 xx원
But..!!! 어떤 조건이 먼저냐..?
자녀에 대해 먼저 고려 하면
결과 2 : 20% 감면하면 80만원 -> 다시 10% 감면하면 yy원
결과가 다릅니다..
이런 부분은 요구사항의 우선순위와 소스상의 선처리가 정확히 확인되어져야 합니다..
(간단히 코드랑 도식을 보면서 하면 이해에 좀더 도움을 드릴텐데...ㅜㅡ)
- 상태전이, 결정테이블, 제어흐름테스트 등등 사용합니다..
(역시 화이트-블랙의 이론상의 기준이 없습니다..ㅡㅡ 제가 잘못한건지..)
- 막상 하다보면 if, case, switch, goto... 별거 다 나옵니다...ㅡㅡ
그래도 해보고 그려봅니다.. 그리고 케이스 도출해봅니다..
짱구 굴려봅니다.. (잘 안돕니다..ㅜㅜ) 그러다 보면 됩니다.. 도움도 되고요..^^
헉헉.. 대단한 내용없이 글만 길어졌네요..ㅡㅡ
다시 적으니깐 오히려 더 헷갈려지네요.. 이해바랍니다..ㅡㅜ
그외에도 몇가지 혼자만의 방식이 있는데 글로 적긴 힘드네요..
혼자 꾸역꾸역 해왔던거라 정답인지도 모르겠고요..
요즘은 화이트 - 블랙 박스의 경계에서의 혼동과, 이론과 실무의 충돌..ㅡㅡ
저두 헷갈리네요..
이런 부분에 대해서 가이드나 오프라인에서의 의견 교환이 있었음 합니다..
그런 기회가 있길 바랍니다.. 누가 좀 추진 해보심이..^^
화이트박스 테스팅에 대한 애매하고 개인적인 의견입니다.. 혼자만의 방법입니다.. 검증 안됬고요..ㅡㅡ 참조만 하시기 바랍니다.. 우선 기본적인 프로그래밍에 대한 이해는 반드시 필요 합니다.. 하지만 기본적인 이해로는 소스상의 오류를 검출하는건 거의 불가능하다고 봅니다.. 기본적인 오류는 개발자에 의해 이미 수정되는 경우가 대부분입니다.. 또한 소스만 보고 그 안의 오류를 검출한다면 이미 높은 수준의 개발 능력이 있다고 생각합니다.. 그렇다고 화이트박스 테스트가 비현실적이냐..? 그렇진 않습니다.. 저두 나름데로의 방법으로 테스트를 해왔습니다.. 제가 혼자서 해온 방법이라서 정답이 될순 없지만 몇가지 적어봅니다.. "White Box Testing는 소스코드에 대한 절대적 이해 필요.!!" <= 요건 절대 아니라고 봅니다..!!! ^^ 간혹 주위에 그런 분들이 있으셔서.. (물론 높은 수준의 이해는 많은 도움이 되겠죠..ㅡㅡ) 1. 사용되어지는 변수의 선언 및 해제의 명확한 확인 (이건 기술적리뷰라 해야 할지..뭐라 해야할지..ㅡㅡ 하여간 몇번 쓸쓸히 해봤습니다..) - 대부분의 SW의 결함은 메모리에서 기인한다고 보고 있습니다.. - 개발 자체가 일정부분 메모리와의 싸움입니다.. (특히 임베디드) - 변수의 사용을 쫓아가서 사용과 해제를 확인하는데.. 보기 힘들더군요..ㅡㅡ Source Insight등의 Editor나 Viewer를 이용하는데.. 오류 검출률이 상당히 낮았습니다.. (왜냐..? 이미 개발자에 의해서 수정되어서..ㅡㅡ) 2. 요구사항이나 설계문서상의 입력값의 범위 확인 - Define 되어 있는 입력 요구 변수에 대해서 확인 합니다.. - 저는 여기서 경계값, 동등분할등을 사용했습니다.. (White - Black Box의 경계가 모호해 집니다..ㅡㅡ) - 이런 방식의 테스트는 최소한 저한테는 유용하더군요..^^ 3. 분기, 결정문을 이용한 시나리오 테스트 케이스 작성 - 교재나 자료의 예제처럼 간단하다면 모를까.. 실제 코드에서 모든 조건문에 대한 분기를 고려하는건 거의 불가능에 가깝습니다.. 그럼 안되냐..? -> 그래도 전 씁니다.. 어떻게..? -> 알맞게.. 잘.. ㅡㅡ - 전체의 흐름 보다는 테스트할 대상의 동작에 따른 모듈의 범위를 정합니다.. 설계/요구 문서상의 동작과 소스상의 동작을 일으키는 분기나 결정 포인트를 잡는겁니다.. (폰쪽이라고 하시니깐.. 예를 들면.. "메세지 처리 흐름", "카메라 동작 상태전이", "통화중 발생 가능 이벤트"등등등으로..^^) -요구사항 VS 구현내용 확인 필요 흐름도 혹은 순서도, 전이도 작성에서 주의 해야 합니다.. 예를 들면 (책이나 교재에 나오는 사항으로 비유하겠습니다..) 요구사항 : "세금이 40세 이상이면 10% 감면, 자녀가 있으면 20% 감면" 입력값 : 수입이 100만원, 40세이상, 자녀있다..!! 결과 1 : 10% 감면하면 90만원 -> 다시 20% 감면하면 xx원 But..!!! 어떤 조건이 먼저냐..? 자녀에 대해 먼저 고려 하면 결과 2 : 20% 감면하면 80만원 -> 다시 10% 감면하면 yy원 결과가 다릅니다.. 이런 부분은 요구사항의 우선순위와 소스상의 선처리가 정확히 확인되어져야 합니다.. (간단히 코드랑 도식을 보면서 하면 이해에 좀더 도움을 드릴텐데...ㅜㅡ) - 상태전이, 결정테이블, 제어흐름테스트 등등 사용합니다.. (역시 화이트-블랙의 이론상의 기준이 없습니다..ㅡㅡ 제가 잘못한건지..) - 막상 하다보면 if, case, switch, goto... 별거 다 나옵니다...ㅡㅡ 그래도 해보고 그려봅니다.. 그리고 케이스 도출해봅니다.. 짱구 굴려봅니다.. (잘 안돕니다..ㅜㅜ) 그러다 보면 됩니다.. 도움도 되고요..^^ 헉헉.. 대단한 내용없이 글만 길어졌네요..ㅡㅡ 다시 적으니깐 오히려 더 헷갈려지네요.. 이해바랍니다..ㅡㅜ 그외에도 몇가지 혼자만의 방식이 있는데 글로 적긴 힘드네요.. 혼자 꾸역꾸역 해왔던거라 정답인지도 모르겠고요.. 요즘은 화이트 - 블랙 박스의 경계에서의 혼동과, 이론과 실무의 충돌..ㅡㅡ 저두 헷갈리네요.. 이런 부분에 대해서 가이드나 오프라인에서의 의견 교환이 있었음 합니다.. 그런 기회가 있길 바랍니다.. 누가 좀 추진 해보심이..^^
최일순
08-09-18 17:46
저도 잘 안풀리고 있지만, 그냥 제 의견을 드려 봅니다.
개발자도 아닌 블랙박스 테스팅하던 분이 어느날 갑자기 짠~하고 화이트박스 테스팅을 하는 것은 별로 가능성이 없는 이야기로 보고 있습니다.(개발자 수준의 코드를 읽고 이해하는 능력은 갖추어야 시도해 볼 수 있는 테스트니까요.)
같은 프로젝트 내에서 동료 개발자가 짠 코드 유지보수하는 것도 쉽지 않다고 이야기하는데, 코드 짤 때 거의 전혀 관여하지 않았던 테스트 엔지니어가 그 코드를 제대로 이해하고 테스팅을 한다는 것은 글쎄요. 매우 어려운 이야기이겠지요.
전 그 시작점을 코드 커버리지라는 결과로부터 다시 풀어가는 것이 좋겠다고 봅니다. 전체의 틀을 잡고 끌고 갈 수는 있지만 개발자가 봐주지 않으면 거의 풀기 어려운 숙제지요.
개발자들도 테스트를 합니다. 무슨 테스트를 했는지 테스트 엔지니어가 TCL 작성하고 그 베이스에서 하는 것만큼 기록으로 관리되지 않을 뿐, 자기가 짠 코드는 당연히 테스트합니다. 그냥 테스트하기가 어려우니 테스트를 하기 위한 간단한 테스트 코드도 만들고, 테스트를 위한 툴도 만듭니다.(화이트 박스 테스트라는 것을 이야기하지 않아도 요기까지는 개발자들이 이미 하고 있는 부분입니다.)
첫번째는 그 개발자가 하던 테스트를 커버리지로 측정합니다. 50%가 나왔다. 그러면 커버되지 않은 코드를 분석합니다. 왜 테스트되지 않았을까? 발생시키기 아주 어려운 예외 처리 코드와 같이 테스트하기가 사실상 불가능한 코드도 있고.. 테스트에서 부족한 부분 때문에 테스트되지 않은 부분도 있습니다. 그러면 테스트를 다시 좀 더 보강하고 다시 돌립니다.
최종적인 목표는 코드 전체에 대해서 테스트되지 않은 납득할만한 이유가 제시되거나, 테스트되거나 둘 중의 하나가 되어야 합니다. 물론 단숨에 이렇게 되기는 어렵지요.
이 과정에서 커버되지 않은 코드를 분석하는 것은 개발자가 봐주지 않으면 테스터가 하기는 매우 어렵고 효율성도 문제가 될 것입니다. 테스트 실행은 테스트 엔지니어가 한다해도 그 결과를 가지고 테스트 내용과 커버되지 않은 코드를 대조해서 분석하고 부족한 부분을 찾는 것은 개발자 도움이 없으면 거의 불가능하죠.
그나마 합리적인 방법은 이런 것이고, 이런 부분을 개발자가 좀 더 쉽게 할 수 있도록 툴을 도입해 준다든지 테스트 실행을 해 준다든지 결과 분석한다든지... 등 할 일은 많지만 직접 화이트박스 테스트를 하는 것은 재고해 보시는 것이 좋을 것 같습니다.
댓글 없음:
댓글 쓰기