QA ≠ Test

QA(품질 보증)는 개념적인 용어이고, TEST는 QA(품질 보증)를 하기 위한 수단이자 방법이다.

EDUCATION

[TMMi] 레벨.2 기준 제어 흐름 테스팅에 대해서 알아보자

품생품사(品生品死) 2021. 1. 4. 00:30
반응형

테스트 설계 명세 가이드 : 제어 흐름 테스팅(6) #9

표준 테스트 설계 명세 가이드에 대해서 알아보도록 하겠습니다.

많은 설계 기법을 다루어야 하기 때문에 8 파트로 나누어서 작성을 하도록 하겠습니다.

 

정책/전략/가이드의 문서 번호는 410번이며, 이 전 글을 참고하시기 바랍니다.

 

[TMMi : Level 2] 프레임워크 및 문서 양식 #1

목차 TMMi Level 2 : 프레임워크 및 문서 양식 #1 TMMi에 대해서는 동일 카테고리 내에 블로그가 있습니다. TMMi(Test Maturity Model integration) 목차 The TMMi model (see figure below) looks at software te..

qa-testing.tistory.com

 

개정 이력

{고객사명} SW 정책/전략/가이드 작성자  
테스트 설계 명세 가이드
(제어 흐름 테스팅)
검토자  
승인자  

 

<관련 부서 합의>

부서 이름 Comment 일자
       
       
       

<문서 제/개정 이력>

번호 제/개정 일자 제/개정 내용 문서 버전 개정자 승인자
           
           
           

 

1. 개요

1) 목적 

📌 본 문서는 테스트 설계 기법 적용방법의 가이드를 목적으로 한다.
📌 실제 프로젝트 산출물을 테스트 베이시스로 하여 테스트 케이스 설계 기법 적용 과정을 예시로 들어 설명한다.
📌 각 기법에 대한 기본적인 내용은 SW 테스팅 관련 서적 또는 교육교재 등을 참조하기 바란다.

2) 적용범위

📌 본 가이드는 ABC사(이하 ‘당사’ 라 함)의 SW 테스팅을 수행하기 위한 모든 설계 시 적용한다.

3) 참고 문서

📌 개발자도 알아야 할 소프트웨어 테스팅 3판

📌 ISTQB Syllabus Test Analysit

 

[v.2011-KOR] ISTQB CTFL 실라버스 요약 : 테스트 설계 기법 - Chapter 4

목차 ※ "개발자도 알아야 할 소프트웨어 테스팅 실무"를 기반으로 요약 ※ Part 4.테스트 설계 기법 4.1 테스트 설계 및 구현 프로세스 < 테스트 케이스 포함내용 > 1. ID(식별번호) - 테스

qa-testing.tistory.com

4) 문서 관리 담당자

📌 본 문서의 관리 담당자는 아래와 같음

역할 담당부서 담당자 내용
문서 책임자 OOO OOO 본 문서 생성 및 수정 권한 부여
문서 검토자 OOO OOO, OOO 작성 완료된 본 문서에 대하여 검토하고 의견 개진
문서 승인자 OOO OOO 본 문서의 베이스라인을 승인하고 배포 허가

 

2. 테스트케이스 설계 기법 예시

👀 각 기법 별로 본 문서를 참고한다.

  • 동등 분할 및 경곗값 분석 기법
  • 페어 와이즈 테스팅
  • 결정 테이블 테스팅
  • 상태 전이 테스팅
  • 기본 경로 테스팅 
  • 제어 흐름 테스팅 > 이번에 다룰 내용
  • 최소 비교 테스팅
  • 유스 케이스 테스팅

3. 테스트케이스 설계 명세서 작성 가이드(기존 동일)

1) 절차

선행 작업 리스크 분석 및 레벨별 테스트 설계 전략 수립
명세 절차 리스크 아이템 분석서 참조
리스크 아이템 별 테스트 컨디션 도출(기법을 적용, 테스트케이스 설계 기법 예시 참조)
각 테스트 레벨의 설계 전략에 맞는 템플릿 선정(기능 베이스, 시나리오 베이스)
테스트 스위트 작성(케이스 및 프로시저)
후행 작업 테스트 실행 및 로그 생성
테스트 결과 분석

2) 역할과 책임

테스트 매니저(또는 리더) "테스트 설계 가이드"의 유지 관리, 수정 및 배포에 대한 책임이 있다.
테스트 엔지니어 "테스트 설계 가이드"를 기반으로 테스트 케이스 도출 시 참조하여 개발한다.

3) 표준 템플릿

👀 ABC사 테스트 설계 명세서 템플릿. xlsx

 

4. 제어 흐름 테스팅

1) 기법 적용 절차

① 명세서를 분석하여 각 분기문(if, for, switch 등)을 식별하고 식별번호를 부여한다.
② 제어 흐름도를 작성하고 제어 흐름 경로에 식별 번호를 부여한다.
③ Test Depth Level을 결정하고 그에 따른 제어 흐름 경로를 도출한다.
④ 제어 흐름 경로를 모두 커버하도록 테스트 케이스를 작성한다.

2) 테스트 베이시스

👀 소스 코드의 각 분기문을 식별하여 결정 포인트(Dn) ID를 부여한다.

👀 테스트 베이시스는 요구사항을 포함하는 모든 문서를 얘기한다. 자세한 용어의 뜻은 아래 링크를 확인 바랍니다.

 

3) 기법 적용

📌 제어 흐름도 작성

👀 제어 흐름도를 작성하고 각 제어 흐름 경로에 고유의 식별 번호를 부여한다.

 

This is audit_00016
제어 흐름도 예시

 

📌 제어 흐름 경로 조합 도출

👀 Test Depth Level 2 강도를 기준으로 제어 흐름 경로 조합을 도출한다. Test Depth Level 강도는 테스트 전략이나 테스트 컨디션에서 결정된다.

결정 포인트 In Out Path
D1 1 39 (1, 39)
D2 2 3, 4 (2, 3) (2, 4)
D3 4, 7, 8 5, 6 (4, 5) (4, 6) (7, 5) (7, 6) (8, 5) (8, 6)
D4 6 7, 8 (6, 7) (6, 8)
D5 3, 5, 11, 12 9, 10 (3, 9) (3, 10) (5, 9) (5, 10) (11, 9) (11, 10) (12, 9) (12, 0)
D6 10 11, 12 (10, 11) (10, 12)
D7 9 13, 14 (9, 13) (9, 14)
D8 13 15, 22, 29, 36 (13, 15) (13, 22) (13, 29) (13, 36)
D9 15 16, 17 (15, 16) (15, 17)
D10 17 18, 19 (17, 18) (17, 19)

✔ Exception의 경우 하나의 경로로 처리하였다.
필요한 경우 Exception 가능 포인트마다 개별적인 경로 조합을 도출할 수 있다.

 

📌 논리적 테스트 케이스 도출

👀 제어 흐름도를 참고하여 제어 흐름 경로 조합이 모두 커버될 때까지 테스트 케이스를 도출한다.

테스트 케이스 제어 흐름 경로
TC01 (1, 39, 40)
TC02 (1, 39, 41)
TC03 (1, 2, 3, 9, 13, 15, 17, 18)
TC04 (1, 2, 4, 5, 9, 14)
TC05 (1, 2, 4, 6, 7, 5, 10, 11, 10, 12, 9, 14)
TC06 (1, 2, 3, 10, 11, 9, 13, 36)
TC07 (1, 2, 4, 6, 8, 6, 7, 6, 8, 5, 10, 12, 10, 11, 9, 13, 22, 23)
TC08 (1, 2, 3, 10, 11, 10, 12, 9, 13, 29, 30)
TC09 (1, 2, 3, 10, 11, 10, 12, 9, 13, 15, 16)
TC10 (1, 2, 3, 10, 11, 10, 12, 9, 13, 15, 17, 19, 20)

📌 구체적 테스트 케이스 도출

👀 논리적 테스트 케이스 흐름에 맞도록 입력 값을 선택하여 구체적 테스트 케이스를 도출한다.

TC Input Data Expected Result
strDate iDateFormat dtDate
TC01 null N/A N/A FALSE
TC02 null N/A N/A FALSE
TC03 not null & lenth = 0 N/A N/A FALSE
TC04 not null & lenth = 0 N/A N/A FALSE
TC05 2012-AUG-6 N/A N/A FALSE
TC06 2012-08-06 3 N/A FALSE
TC07 AUG-2012-06 1 N/A FALSE
TC08 06-08-2012 2 N/A FALSE
TC09 0000-08-06 0 N/A FALSE
TC10 2012-08-99 0 N/A FALSE

🐱‍🐉 노란색 행 : 소스 코드 로직상 실행 불가한 케이스

 

📌 적용 유의 사항

① 제어 흐름 테스팅은 소스 레벨 이외에도 상위 레벨의 업무 흐름, 메뉴 흐름에서도 적용이 가능하다.
② 제어흐름도 작성은 필수이며 제어 흐름도에 오류가 없도록 주의한다.
③ 제어 흐름 경로 조합 도출 시 식별된 결정 포인트(Dn)에서 해당 결정 포인트로 진입하는 모든 경로를 누락하지 않도록 작성한다. 특히 순환 문의 진입 경로를 누락하는 실수를 하지 않도록 한다.
④ Test Depth Level 3의 강도로 적용하는 경우 제어 흐름 조합이 (n1, n2, n3)와 같이 세쌍의 경로 조합이 도출된다. Test Depth Level을 높일수록 강도 높은 테스트 케이스 도출이 가능해진다.

 

Related References

 

Control Flow Testing in White Box Testing - javatpoint

Control Flow Testing in White Box Testing with introduction, software development life cycle, design, development, testing, quality assurance, quality control, methods, black box testing, white box testing, etc.

www.javatpoint.com

 

Control Flow Software Testing - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

 

Control Flow Testing | Section II - White Box Testing Techniques

It was from the primeval wellspring of an antediluvian passion that my story arises which, like the round earth flattened on a map, is but a linear projection of an otherwise periphrastic and polyphiloprogenitive, non-planar, non-didactic, self-inverting c

flylib.com

 

Control Flow Testing

This blog provides the brief introduction of control flow testing

www.oodlestechnologies.com

 

An introduction to Control Flow Testing - A Black Box Testing Technique - Software Testing Genius

Download Link for your Favorite Presentaion is at the End of this Page ***************************************************************************************** An introduction to Control Flow Testing – A Black Box Testing Technique Behavioral control-f

www.softwaretestinggenius.com

요약 : 소프트웨어어 qa, 웹 qa, 앱 qa, 소프트웨어 테스트 자동화, 자동화 소프트웨어, pm 교육, 비즈니스 소프트웨어, 기업 교육, audit, auditer

반응형