질문] Non-functional requirement에서 test case를 찾아내는 개발방법이 있나요

질문] Non-functional requirement에서 test case를 찾아내는 개발방법이 있나요?

글쓴이 : 김태호 날짜 : 08-03-01 09:12     조회 : 1600    

고수님..testing의 초보가 질문 올립니다.
Non-functional requirement에서 test case를 찾아내는 개발방법론이 있는지궁금하네요.
그리고 필드에 계씬 고수님들은 어떻게 테스트케이스랑 연결을 시키시는지요.

DongA Kim
  08-03-01 15:11

안녕하세요.
아는 것은 별로 없지만 몇 글자 적어보겠습이다. 이론적으로 잘 아시는 분 계시면 추가를 부탁드립니다.
말씀하신 내용으로는 요구사항 정의와 테스트와 개발방법론이 열거 되어 있는데요.
상세히 들어가면 너무 복잡할 것 같습니다만, 개발방법론은 요구사항 정의 및 Test Case(이하 TC)와는 약간 분리해서 봐야 하지 않을까 싶네요.
아무래도 요구사항정의와 관련이 많을 듯 하고 최근 개발방법론을 거의 적용하실 수 있을 겁니다.
예를 들어, 개발방법론을 객체지향이나 CBD 로 한다면,
요구사항은 기능성과 비기능성 요구사항으로 분류하고 TC도 기능적TC, 비기능적 TC로 개발이 되어야 겠지요.
비기능적 요구사항은 사용성, 신뢰성, 성능, 지원가능성 등으로 분류하여 작성되고
반응시간이나 하드웨어적 특성과 제약, 표준에 따르는 것, 프로세스 적인 측면과 같은 것을 기술합니다.
요구사항 정의에 따라 테스트 분석과 테스트 계획, 테스트 시나리오, 시스템TC, 통합TC, 단위TC가 개발되면 되겠지요.
금융 웹 사이트 테스트를 예를 든다면,
비기능적 요구사항: 은행 웹사이트 로그인 구간 내에서 보안성이 유지 되어야 한다.
TC:
1. 메인 페이지에서 웹 보안툴 작동 안함
2. 로그인 페이지로 이동시 보안 툴 자동 loading
3. 로그아웃 시 보안 툴 자동 unloading
위 조건을 만족할 때 성능은 어떻게 되는가?
어설프게 적었습니다만 도움이 되셨길 바랍니다.

안녕하세요. 아는 것은 별로 없지만 몇 글자 적어보겠습이다. 이론적으로 잘 아시는 분 계시면 추가를 부탁드립니다. 말씀하신 내용으로는 요구사항 정의와 테스트와 개발방법론이 열거 되어 있는데요. 상세히 들어가면 너무 복잡할 것 같습니다만, 개발방법론은 요구사항 정의 및 Test Case(이하 TC)와는 약간 분리해서 봐야 하지 않을까 싶네요. 아무래도 요구사항정의와 관련이 많을 듯 하고 최근 개발방법론을 거의 적용하실 수 있을 겁니다. 예를 들어, 개발방법론을 객체지향이나 CBD 로 한다면, 요구사항은 기능성과 비기능성 요구사항으로 분류하고 TC도 기능적TC, 비기능적 TC로 개발이 되어야 겠지요. 비기능적 요구사항은 사용성, 신뢰성, 성능, 지원가능성 등으로 분류하여 작성되고 반응시간이나 하드웨어적 특성과 제약, 표준에 따르는 것, 프로세스 적인 측면과 같은 것을 기술합니다. 요구사항 정의에 따라 테스트 분석과 테스트 계획, 테스트 시나리오, 시스템TC, 통합TC, 단위TC가 개발되면 되겠지요. 금융 웹 사이트 테스트를 예를 든다면, 비기능적 요구사항: 은행 웹사이트 로그인 구간 내에서 보안성이 유지 되어야 한다. TC: 1. 메인 페이지에서 웹 보안툴 작동 안함 2. 로그인 페이지로 이동시 보안 툴 자동 loading 3. 로그아웃 시 보안 툴 자동 unloading 위 조건을 만족할 때 성능은 어떻게 되는가? 어설프게 적었습니다만 도움이 되셨길 바랍니다.

이진규
  08-03-02 01:15

혹시 제가 아는 김태호님이시면...^^;;;저의 짧은 지식을....
Non-function과 function의 생각을 한번 다시 해보는게 좋을지도 모르겠다고 생각되네요..
앞에서 좋은 답변이 있어서...^^;;;;
한국에 오신거라면 술한잔해야지요~~!!!!!!
저도 아직 많은 분을 뵙지 못하고 있어서....^^;;

혹시 제가 아는 김태호님이시면...^^;;;저의 짧은 지식을.... Non-function과 function의 생각을 한번 다시 해보는게 좋을지도 모르겠다고 생각되네요.. 앞에서 좋은 답변이 있어서...^^;;;; 한국에 오신거라면 술한잔해야지요~~!!!!!! 저도 아직 많은 분을 뵙지 못하고 있어서....^^;;

김태호
  08-03-10 08:41

DongA Kim님 답변 감사, 많은 도움이 되었습니다.
참고로 CMU의 QAW(Quality attribute workshop)이라는 non-functional requirement를 뽑아내는  method가 있구요.

Whitebox Test에 관한 논의

[질문] Unit/Component Test와 테스터

글쓴이 : 최피디 날짜 : 08-08-28 12:22     조회 : 882    

v-model을 살펴보면, Unit testing의 경우 개발자들에 의해서 진행되는 것 같은 인상을 주게 됩니다. 유닛테스트가 개발과정에서 클래스나 메소드상의 오류들을 발견하기 위한 목적이니 당연히 개발자가 주도하는 것이 맞겠지만 테스터가 유닛테스팅까지 커버하는 경우는 없는지 궁금합니다. 즉, 동적인 화이트박스테스팅도 테스팅의 영역인데, 왜 개발자들에게 의존적으로 가야하는 지 궁금합니다.

박정훈2
  08-08-28 16:02

길가다가 연예인을 만나면 분명히 처음 만나는 것인데 익숙한 기분이 듭니다. 마치 잘 알고 있는 사람 같죠. 김혜수 같은 연예인들은 이런 것을 알고 길가다가 눈이 마주치면 인사를 한다고 하네요, 밝고 힘차게. 하지만 우린 지나치면서 생각하죠. "아~ 처음 보는데 되게 잘 아는 사람 같군!"
QA를 의인화 하자면, 어쩌면 저런 문제들은 모두 'QA라는 녀석의 업보' 일지도 모르겠습니다. 잘 모르는 사람이 테스트 좀 해 봤다고, QA 책 좀 읽었다고, 수 많은 mis-cummunication을 만들어 냅니다. 프로그램 업무는 프로그램 전문가에게 맡기면서, 왜 테스트 업무는 테스트 전문가에게 맡기지 못하는지....
결론만 말하자면, 고민하시는 경우의 대부분은 communication 중 Unit에 대한 정의를 잘 못 내리고 있거나 테스트의 범위에 대해 mis-communicate되는 부분이 존재하기 때문입니다.
(더 헷갈리시겠군요.
저 멀리서 제가 아는 형님이 '또, 또 저렇게 이상하게 얘기 한다~' 라면서 빈정대는 소리가 들리네요.)

길가다가 연예인을 만나면 분명히 처음 만나는 것인데 익숙한 기분이 듭니다. 마치 잘 알고 있는 사람 같죠. 김혜수 같은 연예인들은 이런 것을 알고 길가다가 눈이 마주치면 인사를 한다고 하네요, 밝고 힘차게. 하지만 우린 지나치면서 생각하죠. "아~ 처음 보는데 되게 잘 아는 사람 같군!" QA를 의인화 하자면, 어쩌면 저런 문제들은 모두 'QA라는 녀석의 업보' 일지도 모르겠습니다. 잘 모르는 사람이 테스트 좀 해 봤다고, QA 책 좀 읽었다고, 수 많은 mis-cummunication을 만들어 냅니다. 프로그램 업무는 프로그램 전문가에게 맡기면서, 왜 테스트 업무는 테스트 전문가에게 맡기지 못하는지.... 결론만 말하자면, 고민하시는 경우의 대부분은 communication 중 Unit에 대한 정의를 잘 못 내리고 있거나 테스트의 범위에 대해 mis-communicate되는 부분이 존재하기 때문입니다. (더 헷갈리시겠군요. 저 멀리서 제가 아는 형님이 '또, 또 저렇게 이상하게 얘기 한다~' 라면서 빈정대는 소리가 들리네요.)

Kreno
  08-08-29 11:57

답변과는 약간 거리가 있는 얘기일지 모르고, 제 사견입니다. (그냥 참고만..)
아무래도 클래스의 메소드 상의 오류를 발견하기 위해서 개발자의 도움은 필요하지만 개발자에 끌려다닐 필요는 없습니다. QA팀을 독립적으로 두는 이유와 연관되어 있는데, 아무래도 자신이 짠 코드를 자신이 테스트를 하다보면 헛점이 있기 마련입니다. 메소드의 파라미터와 리턴값에 대한 정보를 보고 Test Engineer가 그에 맞는 테스트 케이스를 설계해서 직접 테스트를 하던지, 아니면 개발자에게 넘겨서 Unit Test를 하는게 좋을 것 같습니다. Test Engineer 분이 프로그래밍에 대한 경험이 있다면 더욱더 쉽고 악랄하게 버그를 잡으실 수 있을겁니다.
저두 위의 분처럼 예를 들어봅니다. Test라는 클래스는  int GetFileCharNum(char* strFileName); 라는, txt 파일을 읽고 문서의 문자의 수를 리턴하는 메소드를 가지고 있다고 봅시다. 리턴값은 파일 내의 Char 개수이고, 파라미터는 파일 이름입니다. 이 메소드를 UnitTest한다고 한다면 많은 개발자는 잘 되는 파일 몇 개 읽어보고 잘 된다고 생각하고 PASS 할것입니다만, Test Engineer 는 그냥 넘어가지 않겠죠? : )
테스트 케이스를 이런식으로 작성해주면...
1. 빈껍데기 파일
2. OS에서 지원하는 파일 이름 길이만큼의(윈도우즈는 아마 255자?) 긴 파일 이름을 가진 파일
3. 엄청나게 큰 파일
4. Unicode(UTF-8) 문자셋 파일
5. Unicode(UTF-16) 문자셋 파일
6. Unicode(UTF-32) 문자셋 파일
7. Unicode(UTF-4) 문자셋 파일
8. ASCII 문자셋 파일
9. Full Path 입력(c:\가나다라마바사\가나다\aaa.txt)
10. 엄청나게 긴 FullPath 입력
11. 깨진 파일
12. 잘못된 Path 입력
13. 없는 파일 이름 입력
14. 다른 형태의 파일 정보 입력(abc.doc)
... 뭐 이 밖에 요구사항에 따라 더 늘어나겠지만 일단 생각나는건 이정도...
이 TestCase하고 기대값을 던져주세요. 욕은 하겠지만 이 중에 걸리는게 꼭 있을겁니다. -.-;;

답변과는 약간 거리가 있는 얘기일지 모르고, 제 사견입니다. (그냥 참고만..) 아무래도 클래스의 메소드 상의 오류를 발견하기 위해서 개발자의 도움은 필요하지만 개발자에 끌려다닐 필요는 없습니다. QA팀을 독립적으로 두는 이유와 연관되어 있는데, 아무래도 자신이 짠 코드를 자신이 테스트를 하다보면 헛점이 있기 마련입니다. 메소드의 파라미터와 리턴값에 대한 정보를 보고 Test Engineer가 그에 맞는 테스트 케이스를 설계해서 직접 테스트를 하던지, 아니면 개발자에게 넘겨서 Unit Test를 하는게 좋을 것 같습니다. Test Engineer 분이 프로그래밍에 대한 경험이 있다면 더욱더 쉽고 악랄하게 버그를 잡으실 수 있을겁니다. 저두 위의 분처럼 예를 들어봅니다. Test라는 클래스는 int GetFileCharNum(char* strFileName); 라는, txt 파일을 읽고 문서의 문자의 수를 리턴하는 메소드를 가지고 있다고 봅시다. 리턴값은 파일 내의 Char 개수이고, 파라미터는 파일 이름입니다. 이 메소드를 UnitTest한다고 한다면 많은 개발자는 잘 되는 파일 몇 개 읽어보고 잘 된다고 생각하고 PASS 할것입니다만, Test Engineer 는 그냥 넘어가지 않겠죠? : ) 테스트 케이스를 이런식으로 작성해주면... 1. 빈껍데기 파일 2. OS에서 지원하는 파일 이름 길이만큼의(윈도우즈는 아마 255자?) 긴 파일 이름을 가진 파일 3. 엄청나게 큰 파일 4. Unicode(UTF-8) 문자셋 파일 5. Unicode(UTF-16) 문자셋 파일 6. Unicode(UTF-32) 문자셋 파일 7. Unicode(UTF-4) 문자셋 파일 8. ASCII 문자셋 파일 9. Full Path 입력(c:\가나다라마바사\가나다\aaa.txt) 10. 엄청나게 긴 FullPath 입력 11. 깨진 파일 12. 잘못된 Path 입력 13. 없는 파일 이름 입력 14. 다른 형태의 파일 정보 입력(abc.doc) ... 뭐 이 밖에 요구사항에 따라 더 늘어나겠지만 일단 생각나는건 이정도... 이 TestCase하고 기대값을 던져주세요. 욕은 하겠지만 이 중에 걸리는게 꼭 있을겁니다. -.-;;

박정훈2
  08-08-29 13:23

많이 배우고 갑니다.
path 관련해서 공백을 넣어 보는 테스트도 추가하면 좋을 것 같습니다.
"C:\이런 패스\space with path\path.path"
어플리케이션이 웹이 아닌 클라이언트 기반이라면 파일 헤더도 체크해 봤으면 싶습니다.

많이 배우고 갑니다. path 관련해서 공백을 넣어 보는 테스트도 추가하면 좋을 것 같습니다. "C:\이런 패스\space with path\path.path" 어플리케이션이 웹이 아닌 클라이언트 기반이라면 파일 헤더도 체크해 봤으면 싶습니다.

최일순
  08-09-03 11:11

테스터가 유닛 테스팅까지 관여하기 어려운 이유....
제 주변의 QA  엔지니어나 테스트 엔지니어 중에서 개발자 수준으로 코드를 많이 만져보고, 만들어보고, 쉽게 읽을 수 있는 정도의 분들은 아주 소수에 불과합니다. 이것은 조직 관점에서 생산성의 문제죠. 테스터가 유닛 테스트 해도 됩니다. 스스로 주어진 시간 내에 결과를 낼 수 있다면 말이죠.
현실적으로 이 코드가 왜 이렇게 구성되어 있고, 어떤 부분을 처리하도록 의도되어 있는지는 동료 개발자들도 파악하는데 시간이 꽤 걸립니다. 하물며 실제 개발에 참여하지 않는 테스터가 그이상의 생산성을 낼 것으로 기대하기 어렵지요.
두번째는 유닛 테스트 자체가 테스트만 있는 것이 아니라, 테스트 <-> 코드 수정을 반복할 가능성이 높은데, 테스터들이 개입하게 되면 커뮤니케이션이 꽤 복잡해진다는 것입니다.
글로벌한 소프트웨어 회사들을 보면 대체로 System 테스팅 이후를 담당하는 QA팀(혹은 테스팅팀... 이름이 어쨌던)과 유닛 테스트 등 로우레벨 테스트를 담당하는 테스트 엔지니어가 따로 있더군요. 테스트 엔지니어는 개발자들과 같이 묶입니다.(코드를 제대로 이해하고 협업하려면 다른 선택이 어렵지요)
현실적으로 가능성이 있는 방법은 유닛 테스트는 개발자들이 하되, 유닛 테스트 종료 기준을 정하는 것이 될 것 같습니다. 코드 커버리지 같은 게 아주 유용하게 사용될 수 있겠지요. 커버리지 자체가 명확하게 증거가 남는 공식적인 테스팅 기법이기 때문에 결과에 대해서 이견은 없을 겁니다. 테스터들이 이 과정에 참여한다면 어떤 개발문서에도 없는 내부 구조나 동작에 대한 많은 정보를 얻을 수도 있을 겁니다.

테스터가 유닛 테스팅까지 관여하기 어려운 이유.... 제 주변의 QA 엔지니어나 테스트 엔지니어 중에서 개발자 수준으로 코드를 많이 만져보고, 만들어보고, 쉽게 읽을 수 있는 정도의 분들은 아주 소수에 불과합니다. 이것은 조직 관점에서 생산성의 문제죠. 테스터가 유닛 테스트 해도 됩니다. 스스로 주어진 시간 내에 결과를 낼 수 있다면 말이죠. 현실적으로 이 코드가 왜 이렇게 구성되어 있고, 어떤 부분을 처리하도록 의도되어 있는지는 동료 개발자들도 파악하는데 시간이 꽤 걸립니다. 하물며 실제 개발에 참여하지 않는 테스터가 그이상의 생산성을 낼 것으로 기대하기 어렵지요. 두번째는 유닛 테스트 자체가 테스트만 있는 것이 아니라, 테스트 <-> 코드 수정을 반복할 가능성이 높은데, 테스터들이 개입하게 되면 커뮤니케이션이 꽤 복잡해진다는 것입니다. 글로벌한 소프트웨어 회사들을 보면 대체로 System 테스팅 이후를 담당하는 QA팀(혹은 테스팅팀... 이름이 어쨌던)과 유닛 테스트 등 로우레벨 테스트를 담당하는 테스트 엔지니어가 따로 있더군요. 테스트 엔지니어는 개발자들과 같이 묶입니다.(코드를 제대로 이해하고 협업하려면 다른 선택이 어렵지요) 현실적으로 가능성이 있는 방법은 유닛 테스트는 개발자들이 하되, 유닛 테스트 종료 기준을 정하는 것이 될 것 같습니다. 코드 커버리지 같은 게 아주 유용하게 사용될 수 있겠지요. 커버리지 자체가 명확하게 증거가 남는 공식적인 테스팅 기법이기 때문에 결과에 대해서 이견은 없을 겁니다. 테스터들이 이 과정에 참여한다면 어떤 개발문서에도 없는 내부 구조나 동작에 대한 많은 정보를 얻을 수도 있을 겁니다.

김종서
  08-09-03 17:21

유닛테스트는 범위가 살짝 좁은 경우의 API 테스트 같은거져..
API 테스트는 범위가 좀 넓은 경우의 유닛테스트 같은거져...
결국, 그게 그거져.. 개발자가 자신의 코드의 안정을 위해 몇몇의 테스트케이스만을 적용해서 이 정도면 내 코드가 원하는 일을 한다고 할수 있지~ 라는 목적으로 수행하는 것이 유닛테스트..
QA팀에서 가능한 모든 수단을 동원하여 코드의 Hole을 찾아내는 목적으로 수행하는 것이 API 테스트...
즉, QA팀에서도 한답니다.. 보통 개발자가 하는 정도보다 훨씬 더 많이 체계적으로 하져..

유닛테스트는 범위가 살짝 좁은 경우의 API 테스트 같은거져.. API 테스트는 범위가 좀 넓은 경우의 유닛테스트 같은거져... 결국, 그게 그거져.. 개발자가 자신의 코드의 안정을 위해 몇몇의 테스트케이스만을 적용해서 이 정도면 내 코드가 원하는 일을 한다고 할수 있지~ 라는 목적으로 수행하는 것이 유닛테스트.. QA팀에서 가능한 모든 수단을 동원하여 코드의 Hole을 찾아내는 목적으로 수행하는 것이 API 테스트... 즉, QA팀에서도 한답니다.. 보통 개발자가 하는 정도보다 훨씬 더 많이 체계적으로 하져..

sten
  08-09-04 01:54

단위테스팅은 테스터가 할 수 있습니다.
하는 조직도 상당수 알려져 있고요...
일반적으로 아래의 2가지 방식으로 단위테스팅에 테스트 전문가가 참여하고 있습니다.
1. 개발경험이 풍부한 테스트 엔지니어가 단위 테스팅을 전담하여 진행함.
2. 테스트 엔지니어가 개발자와 협력하여 단위 테스팅을 진행함. 테스트 엔지니어는 화이트박스 테스트 설계 기법 등 테스팅 전문 지식을 제공하고 개발자가 이를 반영해 테스트 케이스를 생성한 후 수행함. 해당 테스트 케이스를 테스트 엔지니어가 검토해 줄 수 있음.
테스트 엔지니어가 개발 테스팅 가이드를 만들어 주는 경우도 있고,
기타 여러가지 형태로 테스트 엔지니어가 단위테스팅에 참여합니다.
일종의 최근의 추세이니, 테스트 엔지니어가 여러형태로 관심을 갖고 역량을 키우셔야 할 것입니다.

white box test 방법론에 대한 논의

출처는 역시 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%가 나왔다. 그러면 커버되지 않은 코드를 분석합니다. 왜 테스트되지 않았을까? 발생시키기 아주 어려운 예외 처리 코드와 같이 테스트하기가 사실상 불가능한 코드도 있고.. 테스트에서 부족한 부분 때문에 테스트되지 않은 부분도 있습니다. 그러면 테스트를 다시 좀 더 보강하고 다시 돌립니다.
최종적인 목표는 코드 전체에 대해서 테스트되지 않은 납득할만한 이유가 제시되거나, 테스트되거나 둘 중의 하나가 되어야 합니다. 물론 단숨에 이렇게 되기는 어렵지요.
이 과정에서 커버되지 않은 코드를 분석하는 것은 개발자가 봐주지 않으면 테스터가 하기는 매우 어렵고 효율성도 문제가 될 것입니다. 테스트 실행은 테스트 엔지니어가 한다해도 그 결과를 가지고 테스트 내용과 커버되지 않은 코드를 대조해서 분석하고 부족한 부분을 찾는 것은 개발자 도움이 없으면 거의 불가능하죠.
그나마 합리적인 방법은 이런 것이고, 이런 부분을 개발자가 좀 더 쉽게 할 수 있도록 툴을 도입해 준다든지 테스트 실행을 해 준다든지 결과 분석한다든지... 등 할 일은 많지만 직접 화이트박스 테스트를 하는 것은 재고해 보시는 것이 좋을 것 같습니다.