'Software Testing/Knowledge Base'에 해당되는 글 5건

  1. 2009.03.05 Combinational Analysis #3 (4)
  2. 2009.03.01 Combinational Analysis #2 (3)
  3. 2009.02.05 Combinational Analysis #1
  4. 2009.01.02 결함 정보는 Test case로 관리해라!! (1)
  5. 2009.01.02 Issue Tracker (Bug Tracker)적용의 어려움 (1)
막상 글을 쓰려니 내용에 대한 확신이 없어서 쉽게 써지질 않네요 -_-;; 틀린 내용을 유포했다가 잡혀가는건 아닌지 -_-;;
원래 블로깅을 하면서의 목적 중 하나가 공부한 내용을 남기는 것이었는데, 혼자 책보고 공부하는 내용을 올리는 것이라 그닥 확신이 없네요. 
사실 어느분이 '이건 틀려요, 이게 맞지 않나요?' 라고 말을 해주시면 저도 더 안목이 넓어지고 좋겠지만, 아쉽게도 이 블로그는 그리 방문객이 많은 편이 아니라 그런 토론할 기회조차 없네요. 이 블로그의 내용은 개인이 공부해서 올리는 내용이기 때문에, 틀린 내용이 있을 수 있음을 미리 감안하고 보시는게 좋을 것 같습니다. 

저번 포스팅에서 '수학적인' orthogonal array를 만들어 보았습니다. 그런데 'Software testing'에서 OA를 사용하는 이유 중 하나는 coverage의 희생을 최소화 하면서 test case의 수를 효율적으로 줄이기 위해서 입니다. 어떻게 줄일 수 있을까요?
물론 parameter의 모든 조합의 경우의 수를 다 테스트하는 것 (Exhaustive testing) 이 coverage가 더 높긴 합니다만, software의 특성상(?) 모든 parameter의 조합과 2개의 (pair) parameter의 조합에 의한 coverage가 큰 차이가 없다는 것을 전제로 합니다. 정말 그래? 라고 말할 수도 있지만, 많은 자료에서 실제로 그런 결과가 나온다고 하네요. 

어쨌든, OA를 이용한 test case의 최적화를 알아보겠습니다. Exhaustive testing에서는  k개의 parameter가 있고, 각 parameter가 v개의 값을 가지고 있다면, v의 k승 만큼의 tuple (test case)을 가지게 됩니다. 그러나 OA를 이용한다면 v의 제곱 만큼의 tuple을 가지게 됩니다. k는 갯수에 영향을 미치지 않습니다. 직접 만들어 보죠 ^^;

5개의 parameter가 있고 (k = 5), 각 parameter는 3개의 값 (v = 3)을 가지고 있는 경우의 test case최적화를 해보겠습니다. 


위와 같이 있다면, Exhaustive testing의 경우에는 3 x 3 x 3 x 3 x 3 = 243개의 조합이 있어야 합니다. 

OA를 작성할 때, k개의 parameter가 있다면, k - 2개의 Orthogonal Latin Square가 있어야 합니다. (Latin Square는 지난번 포스팅을 참조하세요)


위와 같이 3개의 Orthogonal Latin Square를 만들었습니다. 그리고 위의 3개의 orthogonal latin square를 합치겠습니다 (Superimposing)


근데 왜 k개의 parameter의 조합을 할 때, k-2개의 Latin Square가 필요할까요? 2개의 pair orthogonal 조합은 쉽게 만들어 낼 수 있기 때문입니다. 그건 바로 table의 row, column의 index입니다. table의 row, column을 조합에 포함시켜 위의 table을 array로 표현하면


아래 테이블이 완성된 OA를 이용한 Pair-wise 조합입니다. Result의 5개의 숫자 조합은 각 Parameter내 값이 index를 나타냅니다. (오른쪽에 다 표현해놨습니다 ^^)


위의 표를 살펴보면, 2개의 Parameter를 선택해서 (2개의 Column) 조합을 살펴보면, 2개의 column단위로는 모든 조합을 이루고 있음을 알 수 있습니다. 예를 들면 Param3, Param4의 조합을 보면

{(G,J), (G, K), (G, L), (H, K), (H, L), (H, J), (I, L), (I, J), (I, K)} 

을 모두 가지고 있음을 알 수 있습니다. 즉, 만약에 이렇게 2개의 parameter의 조합으로도 Exhaustive testing와 비슷한 coverage를 이룰 수 있다면, testing의 효율이 엄청나게 올라가겠죠 (243개 --> 9개, 약 97%의 resource 절약).

다음 포스팅때에는 Pair-wise를 만드는 또 다른 방법인 IPO (In Parameter Order)를 알아보도록 하겠습니다 ^^

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong
어느새 마지막 포스팅에서 한달 가까이 지났군요. 지난 마지막 포스팅때, Orthogonal Array (직교 배열) 에 대해서 알아보다가
멈췄네요 ㅎㅎ

저는 개인적으로는 수학을 잘 하지 못해서 그런지, 직교 배열은 관련 자료를 찾기도 쉽지가 않더군요. 사실 지난 한 달동안 직교 배열에 대해서 많이 찾아봤는데요, 워낙 여기저기 찾아보고 정리를 잘 못해서 출처도 딱히 적기가 어렵네요 -_-;; 어쨌든 근 한 달만의 포스팅이 허접하지 않게 적어보겠습니다 ^^;

직교 배열의 개론(?) 부터 말씀 드리면.
직교 배열은 Latin Square라는 수학적 행렬을 기반으로 합니다. Latin Square란, 정사각형 (row와 column의 갯수가 같은) 행렬 중, 특정 row나 column에 중복된 요소가 존재하지 않으면서 모든 요소가 한번씩 나타나는 행렬을 말합니다. 그림으로 설명하는 게 낫겠죠 ^^; 요소가 3인 (n=3) Latin Square는 아래와 같이 2개를 예로 들 수 있습니다.



위와 같은 모양을 하게 됩니다. M1, M2 두 행렬의 어느 row 혹은 column에도 요소가 중복되지 않습니다.

그럼 이제 위의 두 행렬을 합쳐보겠습니다. M1과 M2의 각 행과 열에 매치되는 요소들을 합합니다. 그러면


처럼 되겠죠. 이 행렬 L의 특징은, 행렬 내의 어떤 요소도 중복된 짝(pair)이 없다는 것입니다. 이런 경우를 우리는
두 행렬이 '직교한다', 'Mutual Orthogonal Latin Square(MOLS)'라고 합니다.
 2개의 배열을 합쳤고, 어떤 요소도 중복되지 않았다는 것은? 그렇죠,  pair-wise입니다. 단 여기서의 pair-wise는 커버리지를 
만족하는 최소의 pair-wise는 아닙니다. 단순히 수학적인 pair-wise (서로소) 입니다. 

요소가 3개인 Latin Square는 실제로 위의 2개 보다 더 많습니다. 정확히 계산하는 법은 모르곘으나, 얼추 해봐도 3개는 넘는군요.
그렇지만, Orthogonal하며, 요소가 3개인 Latin Square는 위의 행렬조합밖에 없습니다. 

그 이유는... (사실 여기부터는 찾아본 자료에 이러이러 하다고 하니까 그런 줄 알고 있는 내용입니다. 수학적으로 증명할 줄 모릅니다 -_-;;;)

수학적으로 orthogonal한 행렬은 요소가 n개 (단 여기서 n은 소수 (prime number) 혹은 소수의 제곱값 이어야 함) 일 때 
MOLS(n) = n - 1을 만족한다고 합니다. 즉 요소가 3이기 때문에 MOLS인 Latin Square는 3 - 1개 인 것입니다. 

자, 다음은 요소 갯수가 더 많은 latin square를 만드는 법을 알아보겠습니다. (사실 이거 찾는데 시간이 엄청 오래 걸렸습니다. 다 tool돌리면 나온다고 그런 설명만 있어서... 근데 또 알고 보니 별거 아니라는 -_-_

요소가 5개인 orthogonal array를 만들어보겠습니다. 


쉽죠? -_-;; 딱 보시면 규칙을 아실껍니다. 값이 1인 요소를 기준으로 보면, 1의 row내 index가 row가 내려갈수록 0 --> 4 --> 3--> 2--> 1로 바뀌는 것을 알 수 있습니다. 2, 3, 4, 5 모두 마찬가지 입니다. 

다음 행렬 보시겠습니다. 

이번에도 값이 1인 요소를 기준으로 살펴보면, 0 --> 3 --> 1 --> 4 --> 2 이렇게 2씩 줄어드는 것을 알 수 있습니다. (index 값이 0보다 작아지면 반대쪽 끝으로 간다고 (look around) 생각하세요)
아까는 1씩 줄어들고, 이번엔 2씩 줄어듭니다. 3번째는? 4번째는? 3씩, 4씩 줄이면 될 듯 합니다. 

역시 됩니다. 이 행렬 중 2개를 선택해서 합쳐보면, 그 조합된 값은 모두 pair-wise하게 됩니다. 

참고로, 5 역시 소수이기에 위의 방법이 가능합니다. 8이나 10개의 요소를 가진 행렬을 위의 방법으로 만들어보시면
Latin Square조차 성립할 수 없다는 것을 알게 되실겁니다. (한 column에 중복된 값이 나오게 됩니다). 다른 방법을 통해 Orthogonal array를 찾으셔야 합니다.
또 덧붙이면, 2보다 큰 요소를 갖는다면 모두 MOLS를 만들 수 있으나, '6'은 예외입니다. 6개의 요소를 가진 MOLS는 만들 수 없다는군요. 이는 Eulean Number와 연관이 있다고는 하나 제가 그거에 대해 아는 바가 없습니다. -_-;;

어쨌든 orthogonal Array의 개념은 이 정도로 정리하겠습니다. 다음 포스트는 이 orthogonal array를 어떻게 테스트 케이스에 적용하는 가를 적어보겠습니다. (이번엔 한 달씩이나 걸리진 않아요 ㅎㅎ)

참조 목록
- Foundation of Software Testing:: Chapter 4. Test Generation. Aditya P.Mathur. Purdue University.
- A Practical Strategy for Testing Pair-wise Coverage of Network Interfaces. Allan W.Williams et. al
- An Evaluation of Combination Strategies for Test Case Selection. Mats Grindal et.al

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong
본 글은 Microsoft Press의 How to Test Software at Microsoft와  'An Evaluation of Combination Strategies for Test Case Selection' (Mats Grindal et al) paper를 참조했음을 미리 밝힙니다.



어떤 한 Test case의 parameter가 여러개 일 때, 이들을 어떻게 조합시킬 수 있을까요? 일반적으로 2가지 방법이 있습니다. 

첫째는 Random 혹은 ad-hoc 방식으로 조합하는 것입니다. 이 것은 tester의 능력과 경험에 따라 다른 결과가 나올 수 있으며 운에 따라 결과가 영향을 받을 수도 있습니다. 이 부분은 논외로 하겠습니다 ^^;

두번쨰는 좀더 제어를 가능하게 하여 시스템적인 접근을 하는 것입니다. 이러한 방법 중에는 EC (Each Choice), BC (Base Choice), OA (Orthogonal Array), 그리고 Exhaustive Test 등이 있습니다. EC부터 살펴보겠습니다. 

EC는 가장 단순한 Test case combination technique입니다. 1-wise test로 볼 수도 있습니다. 예를 들어 설명하는 것이 가장 이해가 빠를 것 같네요 

  1. p1 = {v1, v2, v3}
  2. p2 = {v4, v5, v6}
  3. p3 = {v7, v8}

위와 같이 각각의 parameter는 다른 값과 다른 갯수를 가지고 있다고 가정합니다. 물론 각각의 parameter는 다른 parameter에 대해 독립적입니다. (영향을 받지 않습니다. 영향을 받는 다면 그것은 하나의 parameter로 묶어야 합니다). 

tc(n) = f(p1, p2, p3)라 표현한다고 가정하면, EC의 경우에는 다음과 같이 조합될 수 있습니다.
  1. tc(0) = f(v1, v4, v7)
  2. tc(1) = f(v2, v5, v8)
  3. tc(2) = f(v3, v6, v7)

위와 같이 조합할 수 있습니다. 위의 parameter를 분석해보면, p1이 가질 수 있는 3개의 값을 모두 한번 씩 이용했고 (coverage를 확보했고), p2, p3역시 모두 마찬가지 입니다. 단, tc(2)를 보면 이미 위에 나와있던 v7이 다시 나왔습니다. 이는 p3가 갖는 value의 갯수가 하나 적으므로, 중복되게 들어간 것입니다. 위의 값을 보면 알 수 있듯이, 모든 값이 각각 한번씩 선택되었습니다. (Each Choice). EC의 경우 test case의 갯수는 가장 많은 value를 가진 parameter의 value 갯수가 됩니다. 

2번째로 BC (Base Choice)를 알아보겠습니다. BC역시 1-wise test이지만, BC의 coverage는 n-wise test에 뒤지지 않는다는 연구결과가 있다고 합니다. 어쨌든 한번 조합을 만들어보겠습니다. 
BC의 Key point는 'Base Case'가 있어야 한다는 것입니다. 이 base case는 사용자의 관점에서 가장 선택될 빈도가 높고, 단순하며, 일반적으로는 정상동작할 수 있는 것을 선택하는 것이 좋습니다. (Most common, Most normal)

Assume that base case is [v1, v4, v7] 

위처럼 가정하면, 다음과 같은 parameter의 조합이 나오게 됩니다.
  1. tc(0) = f(v1, v4, v7)
  2. tc(1) = f(v2, v4, v7)
  3. tc(2) = f(v3, v4, v7)
  4. tc(3) = f(v1, v5, v7)
  5. tc(4) = f(v1, v6, v7)
  6. tc(5) = f(v1, v4, v8)

위에 주황색으로 표시한 부분을 제외하면 모두 base case의 값을 유지하고 있습니다. 즉, base case에서 하나의 parameter에만 변경을 주어 해당 variation에 대한 동작의 추이를 볼 수 있는 조합법 입니다.  BC의 coverage를 모두 만족하는 test case의 최소 갯수는 1 + (각 parameter의 value 갯수 - 1)입니다.  즉, 위의 예를 들면, 1 + (3 - 1) + (3 - 1) + (2 - 1) = 6 입니다. (사실 ∑를 써서 표현해야 하는데, 잘 못쓰겠네요 -_-;;)

다음은 OA (Orthogonal Array, 직교배열) 입니다. 이 것은 다음 post에....

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong
이 포스트는 "왜 프로그램은 실패하는가"의 2장을 읽고 썼습니다.

발생한 defect 정보와 그 해결책을 연관짓기 위해서는 defect report를 적기 보다는, test case를 작성할 것을 추천하고 있습니다. 물론 저도 그것에 동의합니다. . 

물론 자세하게 적힌 defect report는 초기에 그 정보를 팀원과 공유하기엔 매우 유용합니다. 

그러나 예를 들면 2주 정도 지난 다음에 그 길게 작성된 따분한 report를 읽는 것은 어떨까요?

만약에 복잡한 state machine의 미묘한 문제같은 같은 것이라면 그 내용을 한참 지난 후에 기억하는 것은 쉽지 않습니다. 

더 나아가 만약에 1달 정도 지난 뒤에 regression testing을 해야 한다면, 그 test case를 작성하는 것 조차 거의 불가능 합니다. 

그래서!!

이 책의 저자는 defect이 해결되면, 바로 test case를 작성할 것을 추천하고 있습니다. 
(사실 이 부분은 제 개인적인 해석이 들어갔습니다. 책에서는 test case를 작성하고 report를 퇴물로 만들어라 라고 되어 있는데, 제 생각에는 최대한 빨리 test case를 작성하라는 것도 포함되어 있지 않을까 싶습니다.)

간혹 어떤 보고서보다도 test case가 더 명확하기도 합니다. test case는 단어보다는 논리로 구성되기 때문입니다.  


This post is written after reading chapter 2 in "Why programs are failed??"


Be linked with happened defect information and its solution, writer recommends make test case, instead of writing defect report, and i agree. 

Of course, at beginning step, defect report which is written in detail is helpful for sharing with team member what happened. 

But after 2 weeks passed from it resolved, how about that i have to read that boring report to verify it??

If that defect is happened in complex condition (For example, a kind of state machine problem) , I cannot remember all of its situation. 

Furthermore, how about i have to do regression test after a month?? Even writing test case  is almost impossible. 

So!!

in this book writer recommends to write its test case immediately when defect is resolved. (Don't be LAZY!!!)

Sometimes, test case code can be more clear than any other report, because test case is the code, and the code is logic not words, i think.

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong
본 내용은 "왜 프로그램은 실패하는가? (Why programs are failed?)"란 책을 읽으며 작성한 글입니다. 

일반적으로 정말 단순한 프로그램을 개발하는 것이 아니라면, Issue tracker 혹은 bug tracker라 불리는 시스템을 사용하게 됩니다. 

대표적인 툴로서, 먼저  bugzilla 와 Mantis가 있습니다. 둘 다 Open source기반이고, Web 기반입니다. 
그러나 제가 리눅스에 매우 약한 이유로 이 둘은 써본적이 없습니다 -_-;;

그리고 상용프로그램은 대표적으로 Perforce와 IBM의 Clear Quest가 있습니다. 
Perforce는 써본지 워낙 오래 되었고, 당시에는 이런 툴의 목적도 몰랐고 잘 쓸줄도 몰랐고 -_-;; 사실 지금은 Clear Quest밖에 쓸 줄 모릅니다. 

그렇지만 이런 Issue tracker류의 프로그램은 사용방법이 대동소이 한 것 같습니다. 

Defect정보를 등록하면 (Defect Submit), Project manager에 의해 개발자 혹은 누군가에게 할당되고 (Assign), 개발자는 그 문제를 분석 및 수정한 후에 수정되었음을 표시하고 (Resolved), 해당 defect의 수정이 확인되면 (Closed)시키는 process를 갖게 됩니다. 물론 reject, reopened등의 state가 있지만, one-shot 에 수정가능하다는 전제하에^^ (이와 다르게 하는 경우도 있나요? 있으시면 리플좀 ^^;)

물론 이 책에서 처럼 Unconfirmed, verified 등의 state가 있을 수는 있으나 이는 생략이 가능해 보이고, 

이 책에서 표시된 "WONTFIX" (Will Not Fix)는 사실 아직 겪어보진 못했습니다.
요구사항에 명시되어 있는 대로 동작하지 않는 다는 것을 알면서도 고치지 않겠다라는 건... 글쎄요. 아마 현재의 상황에 어쩔 수 없는 선택이겠지요? 그렇다면, 이는 시간 (혹은 현재의 어떤 특별한 상황)의 문제일 뿐, 나중엔 고쳐져야 하지 않을까 싶습니다. (그렇다면 POSTPONE 처리) 아니면, "고칠 이유가 없다"라는 이유로 고치지 않겠다고 하면, 이 defect을 올린 test engineer가 가지고 있는 requirement spec이 현재 개발이 가는 방향과 일치하지 않는다는 것입니다. 그렇다면 요구사항 변경  process를 수행해야 겠죠. (요구사항의 문제 혹은 SQA Error로 Close 할 수 있음). 

그리고 이 책엔 SCCB (Software Change Control Board)가 나옵니다. defect을 누구에서 assign할 것인지, severity, priority를 정하기 위한 모임이라는데... 개발자, 테스터, 형상관리자가 참가한다고 나옵니다.
근데 이 정도면 개발팀 전체 다 나오라는 것 같군요... -_-;;

사실 defect의 severity는 개발팀과의 관계에도 매우 민감한 문제입니다. 일반적으로 critical 혹은 Major수준의 defect이 발견되면, 해당 S/W는 출시를 하지 않아야 합니다. 그런에 이 구분 명확하지 않아 애매모호 하면, 개발팀과 의견 충돌이 발생할 수 있습니다. 

실제 이런 경우가 있었습니다. 

모 개발 조직에서 defect의 severity를 책정할 때, Requirement Spec violation은 Major defect처리 한다. 라고 정하고 시작하였습니다. 그러다 테스트 도중 거의 일반적인 user scenario에서는 쓰이지 않는 기능중에서 spec과 약간 다르게 동작하는 현상 (Spec과 다른 error code반환) 을 발견했습니다. 이를 issue tracker에 major defect으로 등록하자 

개발팀 : 이 defect은 major급이 아니다. 어짜피 error는 발생시켰지 않느냐,, 그 error code가 아니더라도, 일반적으로는 error가 발생하면 retry하기 때문에, 동작은 같다.
SQA팀 : 해당 error code는 Industry spec에 명시되어 있으며, 우리의 requirement spec에 우리의 product는 Industry spec을 따른다고 명시되어 있다. 그리고 모든 사용자가 그 "일반적"이라는 시나리오 대로 사용할 것을 보장할 수 있는가?  
개발팀 : 그러나 이 문제로 다시 시스템 테스트 process를 밟으면 납기 일정을 맞추지 못할 수 있다. 그 risk가 더 크다. 동작이 크게 틀리지 않은데 굳이 major로 처리해야 하는가? 
SQA팀 : 물론 일정의 문제는 이해하지만, 그렇다고 spec violation을 아니라고 할 수는 없다. Major처리 하겠다.

머 대략 이런 경우입니다. 많이 공감하시는지 모르겠습니다. 전 하도 많이 겪어봐서 -_-;; 대부분 납기 일정에 쫓길 때 이런 상황이 많이 발생하더군요. 이럴땐 기획이나 마케팅의 자문을 구해 일정의 critical한 수준을 보고서 판단하여 해결하는 경우가 많았습니다만... 참 어렵더군요. 하지만 이런 일을 겪으면서 defect의 severity를 정하는 지표가 도출되어 점점 나이지긴 했습니다.

추가 : Issue tracker가 필요한데 서버도 없고, 서버 운영할 사람도 없으면 google의 Project hosting을 참고하세요~ 무료입니다!!

'Software Testing > Knowledge Base' 카테고리의 다른 글

Combinational Analysis #3  (4) 2009.03.05
Combinational Analysis #2  (3) 2009.03.01
Combinational Analysis #1  (0) 2009.02.05
결함 정보는 Test case로 관리해라!!  (1) 2009.01.02
Issue Tracker (Bug Tracker)적용의 어려움  (1) 2009.01.02
Posted by yunseong
이전버튼 1 이전버튼