유스케이스 & 테스트케이스
💡 원래는 내 개인 공부를 이어 하고 싶다만… 갑작스럽게 테스트케이스에 대한 업무를 받아서 급하게 공부를 시작하게 되었다. 유스케이스와 테스트케이스에 대한 개념은 정보처리기사 할 때 배우긴 했는데 너무 이론에 대한 내용이라 잘 안 다가왔던 것 같다. 이론적인 내용과 실무적인 내용 모두 다뤄보고자 한다.
1. 유스케이스 (Use Case)
✏️유스케이스란?
유스케이스는 특정 작업을 수행하기 위해 시스템을 어떻게 사용하는지 정의하는데 사용된다.
유스케이스는 실행의 일부가 아니라 특정 작업을 수행하는 방법을 명세하는 문서의 도식적 표현이다.
- 시스템이 수행해야 할 특정 기능/업무를 사용자의 관점에서 기술
- 사용자(주체)가 시스템을 통해 달성하려는 목표나 요구사항을 표현
- 전제조건, 정상 흐름, 대안 흐름, 후속 조건 등 사세한 시나리오를 포함할 수 있음
- 개요 다이어그램으도로 시각화 가능
- 다이어그램에는 시스템과 상호작용할 때 관여하는 구성요소가 포함되어야 함
- 구성요소 : actor, actions, relationship between them 등
(유스케이스 다이어그램은 “유스케이스 테스트”와는 별개이기 때문에 여기서 다루지 않겠다. 간략하게 소개하자면,,)
- 유스케이스 다이어그램 (Use Case Diagram):
- UML(Unified Modeling Language)의 일부로, 시스템의 주요 기능과 그 기능을 사용하는 주체(사용자나 다른 시스템)간의 관계를 시각적으로 표현함
- 다이어그램은 간략하게 시스템의 전반적인 기능과 상호작용을 나타냄. 복잡한 세부 내용 포함X
- 주로 개발 초기 단계에서 시스템의 큰 그림을 위해 사용
2. 테스트 케이스 (Test Case)
✒️테스트케이스란?
테스트케이스 사양서에 대해 국제 표준규격을 정하는 IEEE Standard 829-1983의 정의,
"A test case specification documents the actual values used for input along with the anticipated outputs."
→ 즉, 예상되는 사용자의 사용 패턴에서 필요한 테스트 요건과 순서, 구체적인 방법 문장화하는 것
- 특정 테스트 목적을 개발하기 위한 테스트 입력값, 실행 조건, 예상 결과의 집합으로 정의됨
- 특정 조건 하 시스템의 특정 기능이 예상대로 작동하는지 검증하기 위한 시나리오와 절차를 명세한 것
- 소프트웨어 테스팅 단계에서 소프트웨어가 요구 사항에 따라 제대로 작동하는지 여부를 검증하기 위해 테스터에 의해 개발된 소프트웨어를 검증하는데 사용됨
용어
- 테스트 (Test): 한 개 이상의 테스트케이스 집합
- 테스트 케이스 (Test Case) : “프로그램의 특정 경로를 실험”해 보거나 혹은 “프로그램이 특정 요구 사항을 준수하는지를 확인”하기 위한 목적으로 사용
- 테스트 시나리오 (Test Scenario) : 테스트 실행을 위한 일련의 활동을 구체적으로 기술해둔 문서 (테스트 스크립트라고도 함)
⇒ 조직내에서 약속만 된다면 용어의 의미는 크게 중요하지 않으나, 각 용어가 서로 다른 의미라는 것은 이해해야 함
✒️테스트케이스는 왜 필요한가?
“테스트 누락 방지”, “테스트 투명화”
작성하는 목적은 크게 “테스트 누락 방지”와 “테스트 투명화”, 이렇게 2가지로 나뉜다.
- 테스트 담당자 개인의 판단으로 테스트 내용을 정해버리면 테스트 항목의 누락이 발생하기 쉽고 이는 중대 결함 발생 요인이 됨
- 릴리즈 후에 결함이 반생한 경우, 어떤 테스트를 실시했는지 파악하지 않으면 다시 처음부터 발생 원인으로 예상되는 지점의 테스트를 반복해서 실시해야 하므로, 일정이 지연되고 프로젝트 비용 증가가 발생하게 됨
- 효율적인 테스트를 실행하기 위해 제 3자가 보아도 알 수 있는 투명한 상태의 테스트케이스가 필요함
✒️테스트케이스 종류
📝테스트케이스의 예
👿나쁜 테스트케이스
불필요한 테스트 패턴이 많은 테스트 케이스
- “누락 없는 테스트케이스”를 지향하기 위해 모든 테스트 항목을 광범위하게 작성한 결과로, 테스트케이스를 너무 많이 만들어 일어난 사태
- 시스템과 모든 도작에 대한 조합을 테스트하려고 하면 경우에 따라 천문학적인 조합 수가 만들어진다.
- 품질 향상을 위해 테스트 항목을 누락없이 만드는 것도 중요하지만, 개발 공정 상 테스트에 부여된 시간은 한정되어 있기 때문에 불필요한 항목은 테스트케이스에서 빼는 결단도 필요함
이상 상태 테스트 케이스 부족
- 개발자 관점에서는 이해할 수 있을지 몰라도, 실제로 시스템과 SW를 사용하는 사용자 관점에서 작성하지 않으면 생각치 못한 결함 발생할 수밖에 없음
- 개발자 관점에서 사용자 관점으로 변환하여 작성하는 것이 중요
애매모호한 표현
- 만약 테스트케이스 작성자가 아닌 제 3자가 볼 경우, 다르게 해석할 수 있음
- 어떻게 하는건지 물어본다면 시간 손실로 끝나지만,
- 잘못 판단 후 테스트를 할 경우 올바른 결과를 얻지 못할 수 있다.
👼좋은 테스트케이스
- 전제 조건 : 몇 번을 할 지, 몇 명이 이용할지
- “애매모호한 것이 없는지”가 좋은 테스트케이스의 포인트
- 예를 들어 "구인 정보를 검색"하는 테스트 케이스를 작성한다고 할 경우 아래와 같이 구별해서 보면 한 눈에 그 차이를 알 수 있음(출처: 테스트케이스 작성의 기본, 인프라웨어테크놀러지)
즉, 정리하자면 다음과 같다.
- 입력과 예상 결과를 구체적으로 작성할 것
- 간결 명로한 문장으로 작성할 것
- “어디에 무엇이 있는지”, “무엇을 입력하면 무엇이 출력되는지”를 구체적으로 명시하면, 테스트 일관성을 확보하 수 있다.
효율적인 테스트케이스 작성 포인트
- 한정된 시간 내에 모든 결함을 발견하는 일은 불가능하기 때문에 테스트케이스 작성에 있어 효율적으로 결함을 발견하기 위한 작성 필요하다. 그 중 한 방법이 “결함 분석”이다.
- 결함분석
- “80%의 결함은 20%의 코드에서 나온다”라는 말처럼 결함은 일정한 규칙성이 있는 경우가 있다.
- 따라서 발견한 결함의 규칙성을 바탕으로 추측하여 테스트케이스를 작성하는 것이 중요한 포인트
- 테스트를 효율적으로 진행하기 위해서는 편리한 툴을 이용
- 관리 시스템 중에 Redmine과 Jira와 같은 BTS(Bug tracking system)
- 프로젝트 관리는 물론 결함 추적도 매우 편리해져 프로젝트 공정을 단축 가능
chatGPT가 알려준 테스트케이스 예시
테스트케이스 ID: TC001
테스트케이스 명: 유효한 사용자 이름과 비밀번호로 로그인
설명: 유효한 사용자 이름과 비밀번호를 사용하여 로그인하는 경우를 테스트합니다.
전제조건: 사용자는 로그인 페이지에 접속해 있어야 합니다.
입력:
사용자 이름: testuser
비밀번호: password123
실행 절차:
사용자 이름 필드에 testuser를 입력합니다.
비밀번호 필드에 password123를 입력합니다.
'로그인' 버튼을 클릭합니다.
예상 결과: 사용자는 성공적으로 로그인되어 메인 대시보드 페이지로 리디렉션됩니다.-
테스트케이스 ID: TC002
테스트케이스 명: 유효하지 않은 비밀번호로 로그인
설명: 유효한 사용자 이름과 유효하지 않은 비밀번호를 사용하여 로그인하는 경우를 테스트합니다.
전제조건: 사용자는 로그인 페이지에 접속해 있어야 합니다.
입력:
사용자 이름: testuser
비밀번호: wrongpassword
실행 절차:
사용자 이름 필드에 testuser를 입력합니다.
비밀번호 필드에 wrongpassword를 입력합니다.
'로그인' 버튼을 클릭합니다.
예상 결과: "비밀번호가 틀렸습니다."라는 오류 메시지가 표시됩니다.⚒️테스팅 방법론
그런데 조금 더 깊게 들어가 소프트웨어 테스팅 방법론에 대해 알아보겠습니다. 테스트의 중점과 접근방식에 따라 2가지로 구분된다.
- 블랙박스 테스트 (Black-box Testing)
- 소프트웨어의 내부구조나 작동원리를 고려하지 않고, 오직 입력과 출력만을 검사하는 테스트 방법
- 주로 요구사항과 기능 명세를 기반으로 테스트케이스를 작성함
- 시스템이 외부에서 보는 관점에서 올바르게 작동하는지 확인함
- 예시) 웹사이트의 로그인 기능 테스트
- 다양한 사용자 이름과 비밀번호 조합을 입력하고 해당 조합이 올바르게 동작하는지(로그인 성공/실패)만 확인
- 화이트박스 테스트 (White-box Testing)
- 소프트웨어의 내부 로직, 구조, 코드의 경로 등 검사하는 테스트 방법
- 주로 코드의 논리적 경로, 분기점, 반복 구조 등을 검증하는데 중점을 둠
- 프로그램의 내부 구조를 알고 있는 테스터나 개발자에 의해 수행됨
- 예시) 코드
- 화이트박스 테스트를 수행할 때, x의 값을 여러 번 변경하여 모든 조건과 분기를 테스트 (예: x=5, x=15)
if x > 10: print("x는 10보다 큽니다.") else: print("x는 10보다 작거나 같습니다.")
💡 블랙박스 테스트는 시스템이 예상대로 동작하는지 검증하기 위한 방법,
화이트박스 테스트는 코드의 특정 부분에 버그나 오류가 없는지 확인하기 위한 방법
즉, 위에서 예시로 들었던 테스트는 블랙박스 테스트에 해당한다.
테스트케이스 ID: TC002
테스트케이스 명: 유효하지 않은 비밀번호로 로그인
설명: 유효한 사용자 이름과 유효하지 않은 비밀번호를 사용하여 로그인하는 경우를 테스트합니다.
전제조건: 사용자는 로그인 페이지에 접속해 있어야 합니다.
입력:
사용자 이름: testuser
비밀번호: wrongpassword
실행 절차:
사용자 이름 필드에 testuser를 입력합니다.
비밀번호 필드에 wrongpassword를 입력합니다.
'로그인' 버튼을 클릭합니다.
예상 결과: "비밀번호가 틀렸습니다."라는 오류 메시지가 표시됩니다.⚒️테스트케이스 작성 방법
작성도구
- 보통 엑셀
- 테스터에 따라 워드나 한글을 사용하는 사람도 있음
- 어떤 도구를 사용할지는 중요하지 않음
테스트케이스 작성하기 앞서,,
- 간단하게 테스트 인원, 테스트 범위, 테스트 목적, 테스트 일정 등 정한 다음 시작해야 함
- 생각없이 테스트케이스를 적다보면 문득 테스트의 목적이 헷갈리고 범위 또한 모호할 때가 있어, 미리 정한 규칙이 큰 도움이 되기 때문
⚒️테스트케이스 예시
출처 : 동민이집 님의 “테스트케이스 작성 방법(실무 편)”
- 아래는 네이버 메인을 기준으로 20~30 라인 정도 “동민이집”님께서 작성하신 예시이다.
- P, B, F 3가지 결과 방식을 사용하였다.
- P = pass (확인)
- B = Block (확인불가)
- F = Fail (오류)
① 대분류 - 중분류 - 소분류 - 내용 - 결과 - 비고
- 동민이집님께서 현업에서 가장 많이 사용하는 테스트케이스 형식
- 기능별 / 위치 및 단락별로 분류를 크게 3가지로 나누고, 내용에는 테스트해야 할 내용을 간단히 작성
- 파란색 글씨 : 테스트에 도움이 될만한 부가 설명을 기록
② 대분류 -화면번호 - 중분류 - 소분류 - 내용 - 추가내용 - 결과 - 비고
- 1번과는 크게 다르지는 않지만, 수정해야 할 화면번호와 추가 내용이 추가됨
- 이로인해 아주 조금이나머 더 효과적으로 버그에 대한 대처를 할 수 있음
③ 대분류 -화면번호 - 중분류 - 소분류 - 내용 - 추가내용 - 결과 - 비고 - 이미지
- 특정 부분은 어쩔 수 없이 실제 이미지와 비교 해야 하는 부분이 있음.
- 이미지의 비교 원본이 없을 경우, 개발자와 다른 테스터 입장에서는 수십, 수 백가지로 해석될 수 있기 때문
- 이미지는 개수가 적다면 위와 같이 해당 페이지에 첨부할 때도 있지만, 보통 이슈 관리와 히스토리 관리를 위해 시트를 따로 빼거나 다른 문서에 작성하여 같이 전달
④ 확인란
- 개발자 혹은 테스터의 직접적인 커뮤니케이션이 가능하거나 협업이 쉬운 상황이라면 버그, 이슈를 직접 전달하여 업무를 진행할 수도 있다. 하지만 이슈의 수가 많아지고 협업/유관부서가 많아질수록 어려워진다.
- 따라서 이러한 확인란이 필요한 것!
- 이 부분의 히스토리는 최대한 유지하는 것이 좋다. 수정된 버전 혹은 모듈 역시 버그가 발생할 수 있기 때문에 QA를 1차, 2차,3차로 나누고 확인 일자를 메모해둬야 한다.
테스트케이스 문서는 “오류”나 “F”등이 하나도 남아있지 않을 때까지 여러 분서를 계속 돌아다닌다고 한다.
동민이집 님의 “테스트케이스 작성 방법(실무 편)”의 본문을 확인하면 더 유용한 정보를 얻을 수 있다.
⚒️테스트케이스 예시2
출처 : Use Case vs Test Case: Core Differences, By Sonal Dwivedi, Community Contributor https://www.browserstack.com/guide/use-case-vs-test-case
- 온라인 쇼핑 애플리케이션을 통한 고객과 판매자 간의 온라인 쇼핑 시스템 사용 사례
3. 유스케이스와 테스트케이스
- 유스케이스는 테스트 케이스의 작성의 기반이 될 수 있음. 유스케이스에 기술된 상호작용과 시나리오는 테스트케이스를 정의하는데 도움을 줌. 따라서 테스트케이스 작성에 기반이 됨
- 유스케이스는 시스템의 기능과 사용자 요구사항을 이해나느데 도움을 주며, 이러한 이해를 토대로 테스트케이스를 효과적으로 작성함
🔍Use case vs Test Case
아래는 유스케이스와 테스트케이스 간의 차이점을 비교한 표이다.
📝유스케이스 테스팅이란? (Use case testing)
- 유스케이스(또는 비지니스 시나리오)를 기반으로 테스트를 명세화하는 기법으로 블랙박스 테스팅 기법의 한 종류이다.
- 시작부터 끝까지 다루는 테스트 케이스를 식별하는데 도움이 된다.
느낀 점
- 헷갈렸던 개념들을 다시 되짚어볼 수 있어서 좋았다.
- 곧 해야 할 테스트케이스 작성을 이 이론만으로 잘 할 수는 없겠지만, 그 밑바탕으로는 잘 배운 느낌이 든다.
참고자료
- 테스트케이스 작성의 기본, https://infrawaretech-qa.tistory.com/68
- Difference between Use Case and Test Case, https://www.geeksforgeeks.org/difference-between-use-case-and-test-case/
- Use Case vs Test Case: Core Differences, https://www.browserstack.com/guide/use-case-vs-test-case
- 테스트케이스 작성 방법(실무 편), https://dongmin-house.tistory.com/10
- Use Case Testing Tutorial: Comprehensive Guide With Best Practices, https://www.lambdatest.com/learning-hub/use-case-testing#what-is-use-case-testing
반응형
'📓Wiki' 카테고리의 다른 글
| [Wiki] Git의 모든 것 (1) | 2023.07.12 |
|---|
