안녕하세요, 슬로우 Tony입니다.
최근 SW 품질 개선에 대한 고민을 하다 SW Testing에 대한 개발자뿐만 아니라 전사적인 이해를 돕기 위해 9월 테크데이 주제를 정하게 되었습니다.
문서의 주요한 내용은 GeeksforGeeks의 문서를 번역해서 가져왔고 제가 직접 경험했던 내용을 반영해보았습니다.
Software Testing이란?
소프트웨어 테스트는 소프트웨어 개발 수명주기 에서 중요한 프로세스 입니다. 여기에는 소프트웨어 애플리케이션에 버그가 없는지, 설계 및 개발에서 설정한 기술 요구 사항을 충족 하는지, 사용자 요구 사항을 효율적이고 효과적으로 충족 하는지 확인하는 검증 및 검증이 포함됩니다.
이 프로세스는 애플리케이션이 모든 예외 및 경계 사례를 처리하여 강력하고 안정적인 사용자 경험을 제공할 수 있도록 보장합니다. 소프트웨어 테스트는 문제를 체계적으로 식별하고 수정 함으로써 다양한 시나리오에서 예상대로 작동하는 고품질 소프트웨어를 제공하는 데 도움이 됩니다.
소프트웨어 테스트 프로세스는 기존 소프트웨어의 결함을 찾는 것뿐만 아니라 효율성, 정확성, 사용성 측면에서 소프트웨어를 개선할 수 있는 방안을 찾는 것을 목표로 합니다.
Software Testing은 두 단계로 나눌 수 있습니다
- 검증(Verification): 소프트웨어가 특정 기능을 올바르게 구현 하는지 확인하는 일련의 작업을 말합니다. "우리가 제품을 제대로 만들고 있는가?"라는 의미입니다.
- 확인(Validation): 구축된 소프트웨어가 고객 요구 사항에 따라 추적 가능한지 확인하는 다른 일련의 작업을 말합니다. "우리가 올바른 제품을 만들고 있는가?"라는 의미입니다.
Software Testing의 중요성
- 결함의 조기 발견 : 버그가 있는 경우 이를 조기에 발견하여 소프트웨어 배포 전에 수정할 수 있습니다.
- 소프트웨어 품질 향상 : 소프트웨어의 결함을 발견하고 이를 수정하여 소프트웨어의 품질을 향상시킵니다.
- 고객 만족도 향상: 신뢰성, 보안, 고성능을 보장하여 시간과 비용을 절감하고 고객 만족도를 높입니다.
- 확장성 지원: 소프트웨어 테스트 유형의 비기능 테스트는 확장성 문제와 애플리케이션이 작동을 멈출 수 있는 지점을 파악하는 데 도움이 됩니다.
- 시간과 비용 절약: 애플리케이션이 출시된 후에는 문제를 추적하고 해결하기가 매우 어렵기 때문에 이 활동을 수행하면 더 많은 비용과 시간이 소요됩니다. 따라서 소프트웨어 개발 중에 정기적으로 소프트웨어 테스트를 수행하는 것이 좋습니다.
Software Testing의 필요성
소프트웨어 버그는 잠재적인 금전적, 인적 손실을 초래할 수 있습니다. 소프트웨어 개발에서 테스트 단계가 없었다면 많은 피해가 발생했음을 명확하게 보여주는 많은 사례가 역사에 남아 있습니다. 다음은 몇 가지 예입니다:
- 1985: 캐나다의 Therac-25 방사선 치료기가 소프트웨어 버그로 인해 오작동하여 환자에게 치명적인 방사선 피폭이 발생하여 3명이 부상당하고 3명이 사망했습니다.
- 1994: 중화항공 에어버스 A300이 소프트웨어 버그로 인해 추락하여 264명이 사망했습니다.
- 1996: 소프트웨어 버그로 인해 미국 고객 823명의 은행 계좌에 9억 2천만 달러가 입금되었습니다.
- 1999: 소프트웨어 버그로 인해 12억 달러 규모의 군용 위성 발사가 실패했습니다.
- 2015: 전투기 F-35의 소프트웨어 버그로 인해 목표물을 제대로 탐지하지 못함.
- 2015: 런던의 블룸버그 터미널이 소프트웨어 버그로 인해 금융 시장 거래자 30만 명에게 영향을 미치고 정부가 30억 파운드 규모의 국채 매각을 연기해야 하는 사태가 발생했습니다.
- 스타벅스는 POS 시스템의 소프트웨어 오류로 인해 미국과 캐나다 매장의 60% 이상을 폐쇄해야 했습니다.
- 닛산 자동차는 자동차 에어백 감지기의 소프트웨어 오류로 인해 시장에서 100만 대의 자동차를 리콜해야 했습니다.
다양한 유형의 Software Testing
Software Testing의 유형
소프트웨어 테스트의 유형은 크게 3가지로 분류할 수 있습니다:
- 기능 테스트(Functional testing) : 기능 요구 사항에 대해 소프트웨어 시스템을 검증하는 소프트웨어 테스트의 한 유형입니다. 애플리케이션이 소프트웨어의 기능 요구사항에 따라 제대로 작동하는지 여부를 확인하기 위해 수행됩니다. 기능 테스트에는
단위 테스트,통합 테스트,시스템 테스트,스모크 테스트등 다양한 유형이 있습니다. - 비기능 테스트(Non-functional testing) : 애플리케이션의 성능, 확장성, 이식성, 스트레스 등과 같은 비기능적 요구 사항을 확인하는 소프트웨어 테스트의 한 유형입니다. 비기능 테스트에는
성능 테스트,스트레스 테스트,사용성 테스트등 다양한 유형이 있습니다. - 유지보수 테스트(Maintenance testing) : 고객의 요구에 따라 소프트웨어를 변경, 수정, 업데이트하는 프로세스입니다. 여기에는 코드의 최근 변경 사항이 이전에 작동하던 소프트웨어의 다른 부분에 악영향을 미치지 않았는지 확인하는 회귀 테스트(regression testing) 가 포함됩니다.
위의 분류 외에도 소프트웨어 테스트는 두 가지 테스트 방법으로 더 나눌 수 있습니다:
- 수동 테스트(Manual Testing) : 자동화 도구나 스크립트를 사용하지 않고 소프트웨어를 수동으로 테스트하는 것을 포함합니다. 이 유형에서는 테스터가 최종 사용자의 역할을 맡아 소프트웨어를 테스트하여 예기치 않은 동작이나 버그를 식별합니다. 수동 테스트에는 단위 테스트, 통합 테스트, 시스템 테스트, 사용자 승인 테스트 등 다양한 단계가 있습니다. 테스터는 테스트 계획, 테스트 케이스 또는 테스트 시나리오를 사용하여 소프트웨어를 테스트하여 테스트의 완전성을 보장합니다. 수동 테스트에는 테스터가 소프트웨어의 오류를 식별하기 위해 소프트웨어를 탐색하는 탐색 테스트도 포함됩니다.
- 자동화 테스트(Automated testing) : 테스트 자동화라고도 하며, 테스터가 스크립트를 작성하고 다른 소프트웨어를 사용하여 제품을 테스트하는 것입니다. 이 프로세스에는 수동 프로세스의 자동화가 포함됩니다. 자동화 테스트는 수동 테스트에서 수동으로 수행했던 테스트 시나리오를 빠르고 반복적으로 다시 실행하는 데 사용됩니다.
회귀 테스트(Regression testing)와는 별도로 자동화 테스트는 부하, 성능, 스트레스 관점에서 애플리케이션을 테스트하는 데 사용됩니다. 수동 테스트에 비해 테스트 커버리지를 늘리고 정확도를 높이며 시간과 비용을 절약할 수 있습니다.
다양한 수준의 Software Testing
소프트웨어 수준 테스트는 크게 4가지 레벨로 분류할 수 있습니다:
- 단위 테스트(Unit Test) : 소프트웨어/시스템의 개별 단위/구성 요소를 테스트하는 소프트웨어 테스트 프로세스의 한 단계입니다. 소프트웨어의 각 단위가 설계된 대로 작동하는지 검증하는 것이 목적입니다.
- 통합 테스트(Integration Testing) : 개별 유닛을 결합하여 그룹으로 테스트하는 소프트웨어 테스트 프로세스의 한 단계입니다. 이 테스트 레벨의 목적은 통합된 유닛 간의 상호 작용에서 결함을 노출하는 것입니다.
- 시스템 테스트(System Testing) : 완전한 통합 시스템/소프트웨어를 테스트하는 소프트웨어 테스트 프로세스의 한 단계입니다. 이 테스트의 목적은 시스템이 지정된 요구 사항을 준수하는지 평가하는 것입니다.
- 수락 테스트(Acceptance Testing) : 시스템의 수용 가능성을 테스트하는 소프트웨어 테스트 프로세스의 한 단계입니다. 이 테스트의 목적은 시스템이 비즈니스 요구사항을 준수하는지 평가하고 납품이 가능한지 여부를 평가하는 것입니다.
다양한 유형의 Software Testing 기술
소프트웨어 테스트 기술은 크게 3가지로 분류할 수 있습니다:
- 블랙 박스 테스트(Black-box testing) : 테스터가 소프트웨어의 소스 코드에 접근할 수 없고 소프트웨어의 내부 논리 구조와 무관하게 소프트웨어 인터페이스에서 수행되는 테스트로 블랙박스 테스트라고 합니다.
- 화이트 박스 테스트(White-box testing) : 테스터가 제품의 내부 작동을 알고 있고 소스 코드에 액세스할 수 있으며 모든 내부 작업이 사양에 따라 수행되는지 확인하여 수행하는 테스트를 화이트 박스 테스트라고 합니다.
- 그레이 박스 테스트(Gray-box testing) : 테스터가 구현에 대한 지식이 있어야 하지만 전문가일 필요는 없는 테스트.
| S No. | 블랙박스 테스트 | 화이트박스 테스트 |
|---|---|---|
| 1 | 애플리케이션의 내부 작업은 필요하지 않음 | 내부 작동 방식에 대한 지식은 필수. |
| 2 | 폐쇄형 상자/데이터 기반 테스트라고도 | 클리어 박스/구조 테스트라고도 |
| 3 | 최종 사용자, 테스터, 개발자. | 일반적으로 테스터와 개발자가 수행 |
| 4 | 이 작업은 시행착오를 거쳐야만 수행할 수 있습니다. | 데이터 도메인과 내부 경계를 더 잘 테스트할 수 있음 |
Black Box Testing
블랙박스 테스트는 소프트웨어가 정상적으로 작동하는지 확인하는 데 중요한 역할을 합니다. 테스터는 코드를 들여다보는 대신 사용자와 마찬가지로 외부에서 소프트웨어가 어떻게 작동하는지 확인합니다. 이를 통해 소프트웨어 작동 방식에 영향을 줄 수 있는 문제나 버그를 발견할 수 있습니다.
블랙박스 테스트란?
블랙박스 테스트는 테스터가 소프트웨어의 내부 지식이나 구현 세부 사항에 신경 쓰지 않고 제공된 사양이나 요구 사항에 따라 기능을 검증하는 데 집중하는 소프트웨어 테스트의 한 유형입니다.
블랙박스 테스트
블랙박스 테스트 유형
- 기능 테스트(FT)
- 회귀 테스트(RT)
- 비기능 테스트(NFT)
기능 테스트(Funtional Testing)
- 기능 테스트는 소프트웨어 애플리케이션의 각 기능이 요구 사항 및 사양에 맞게 작동하는지 확인하는 테스트 유형으로 정의됩니다.
- 이 테스트는 애플리케이션의 소스 코드와는 관련이 없습니다. 소프트웨어 애플리케이션의 각 기능은 적절한 테스트 입력을 제공하고, 출력을 예상하고, 실제 출력과 예상 출력을 비교하여 테스트됩니다.
- 이 테스트는 사용자 인터페이스, API, 데이터베이스, 보안, 클라이언트 또는 서버 애플리케이션 및 테스트 대상 애플리케이션의 기능을 확인하는 데 중점을 둡니다. 기능 테스트는 수동 또는 자동화할 수 있습니다. 시스템의 소프트웨어 기능 요구 사항을 결정합니다.
회귀 테스트(Regression Testing)
- 회귀 테스트는 코드의 수정된 부분과 수정으로 인해 영향을 받을 수 있는 부분을 테스트하여 수정 후 소프트웨어에 새로운 오류가 발생하지 않았는지 확인하는 프로세스입니다.
- 회귀는 무언가를 되돌리는 것을 의미하며 소프트웨어 분야에서는 버그를 되돌리는 것을 말합니다. 새로 추가된 코드가 기존 코드와 호환되는지 확인합니다.
- 즉, 새로운 소프트웨어 업데이트는 소프트웨어의 기능에 영향을 미치지 않습니다. 이는 시스템 유지 관리 작업 및 업그레이드 후에 수행됩니다.
비기능 테스트(Non-functional Testing)
- 비기능 테스트는 시스템의 비기능적 속성을 확인하는 소프트웨어 테스트 기법입니다.
- 비기능 테스트는 소프트웨어 애플리케이션의 비기능적 측면을 확인하기 위한 소프트웨어 테스트의 한 유형으로 정의됩니다.
- 비기능 테스트는 기능 테스트에서 다루지 않는 비기능 매개변수에 따라 시스템의 준비 상태를 테스트하기 위해 고안되었습니다.
- 비기능 테스트는 기능 테스트만큼이나 중요합니다.
- 비기능 테스트는 NFT라고도 합니다. 이 테스트는 소프트웨어의 기능 테스트가 아닙니다. 소프트웨어의 성능, 사용성 및 확장성에 중점을 둡니다.
블랙박스 테스트의 장점
- 테스터는 블랙박스 테스트를 구현하기 위해 더 많은 기능적 지식이나 프로그래밍 기술이 필요하지 않습니다.
- 대규모 시스템에서 테스트를 구현하는 데 효율적입니다.
- 테스트는 사용자 또는 클라이언트의 관점에서 실행됩니다.
- 테스트 사례를 쉽게 재현할 수 있습니다.
- 기능 사양의 모호함과 모순을 찾는 데 사용됩니다.
블랙박스 테스트의 단점
- 테스트 프로세스를 구현하는 동안 동일한 테스트를 반복할 가능성이 있습니다.
- 명확한 기능 사양이 없으면 테스트 케이스를 구현하기 어렵습니다.
- 테스트 단계마다 입력이 복잡하여 테스트 케이스를 실행하기 어렵습니다.
- 때로는 테스트 실패의 원인을 파악할 수 없는 경우도 있습니다.
- 애플리케이션의 일부 프로그램이 테스트되지 않습니다.
- 제어 구조의 오류를 드러내지 못합니다.
- 대규모의 입력 샘플 공간으로 작업하는 것은 철저하고 많은 시간이 소요될 수 있습니다.
블랙박스 테스트 수행 방법
-
구문 중심 테스트(Syntax-Driven Testing) - 이 유형의 테스트는 일부 언어가 구문적으로 표현할 수 있는 시스템에 적용됩니다. 예를 들어, 언어는 문맥 없는 문법으로 표현될 수 있습니다. 이 테스트에서는 각 문법 규칙이 적어도 한 번 이상 사용되도록 테스트 케이스가 생성됩니다.
-
등가 분할(Equivalence partitioning) - 많은 유형의 입력이 유사하게 작동하는 경우가 많으므로 모든 입력을 개별적으로 제공하는 대신 그룹화하고 각 그룹에서 하나의 입력만 테스트할 수 있습니다. 이 아이디어는 시스템의 입력 영역을 여러 동등성 클래스로 분할하여 각 클래스의 구성원이 유사하게 작동하도록, 즉 한 클래스의 테스트 케이스에서 오류가 발생하면 다른 클래스 구성원도 동일한 오류가 발생하도록 하는 것입니다.
이 기술에는 다음 두 단계가 포함됩니다.:
- 동등성 클래스 식별(Identification of equivalence class) - 입력 도메인을 최소 두 개의 집합으로 분할합니다: 유효한 값과 무효 값. 예를 들어, 유효 범위가 0~100인 경우 49와 같이 유효한 입력은 하나, 104와 같이 유효하지 않은 입력은 하나를 선택합니다.
- 테스트 케이스 생성하기(Generating test cases) - (i) 유효한 입력과 유효하지 않은 입력 각각에 고유 식별 번호를 할당합니다. (ii) 유효하지 않은 두 입력이 서로를 가리지 않는 것을 고려하여 모든 유효 및 유효하지 않은 테스트 케이스를 포함하는 테스트 케이스를 작성합니다. 숫자의 제곱근을 계산하기 위해 동등성 클래스는 (a) 유효한 입력: 입니다.
- 완벽한 제곱 출력인 정수는 정수가 됩니다.
- 완벽한 제곱 출력이 아닌 전체 숫자는 10진수가 됩니다.
- 양의 소수
- 음수(정수 또는 소수).
- "a","!",";" 등과 같은 숫자 이외의 문자.
[예시]
A라는 학교에서 학생들의 성적에 따른 등급을 자동으로 계산해 주는 프로그램을 만들고자 한다. 100~90점은 A, 89~70점은 B, 69~50점은 C, 49점 이하는 D로 산정하고자 한다. 이때 등가분할에 의거한 데이터는 100<=점수<=90, 89<=점수<=70, 69<=점수<=50, 점수<=49로 총 4개의 데이터가 산출될 수 있다. 이것은 최소한 결과의 값을 선택하여 테스트를 수행한다는 것까지 보장한다.
- 경계값 분석 - 경계는 오류가 발생하기 매우 좋은 곳입니다. 따라서 입력 도메인의 경계 값에 대해 테스트 케이스를 설계하면 테스트의 효율성이 향상되고 오류를 발견할 확률도 높아집니다. 예를 들어, 유효 범위가 10~100인 경우 유효 입력과 유효하지 않은 입력을 구분하여 10,100에 대해서도 테스트합니다.
[예시]
조건이 a≦ X₁≦b 이고, c≦ X₂≦d 일 때, 각 범위의 경계값을 분석하여 아래와 같이 입력값을 산정할 수 있다.
-
원인 결과 그래프 - 이 기법은 원인이라는 논리적 입력과 결과라는 상응하는 동작 간의 관계를 설정합니다. 원인과 결과는 부울 그래프를 사용하여 표현됩니다. 다음 단계를 따릅니다:
- 입력(원인)과 출력(결과)을 식별합니다.
- 원인-결과 그래프를 작성합니다.
- 그래프를 의사 결정 테이블로 변환합니다.
- 의사 결정 테이블 규칙을 테스트 케이스로 변환합니다.
원인-결과 그래프 예시:
의사 결정 테이블로 변환:
각 열은 테스트를 위한 테스트 케이스가 될 규칙에 해당합니다. 따라서 4개의 테스트 케이스가 있습니다.
-
요구사항 기반 테스트 - 소프트웨어 시스템의 SRS에 주어진 요구사항을 검증하는 것을 포함합니다.
-
호환성 테스트 - 테스트 케이스 결과는 제품뿐만 아니라 기능 제공을 위한 인프라에 따라 달라집니다. 인프라 매개변수가 변경 되더라도 여전히 제대로 작동할 것으로 예상됩니다. 일반적으로 소프트웨어의 호환성에 영향을 미치는 몇 가지 매개 변수는 다음과 같습니다:
- 프로세서(펜티엄 3, 펜티엄 4) 및 여러 프로세서.
- 컴퓨터의 아키텍처 및 특성(32비트 또는 64비트).
- 데이터베이스 서버와 같은 백엔드 구성 요소.
- 운영 체제(Windows, Linux 등).
그외에도 다음과 같은 테스팅 기법들이 있다.
- 조합 테스트 기법(Combinatorial Test Techniques)
- 시나리오 테스팅(Scenario Testing)
- 오류 추정(Error Guessing)
블랙박스 테스트에 사용되는 도구
블랙박스 테스트로 식별할 수 있는 사항
- 누락된 기능, 잘못된 기능 및 인터페이스 오류를 발견합니다.
- 데이터베이스 액세스 시 발생하는 오류를 발견합니다.
- 기능을 시작 및 종료하는 동안 발생하는 오류를 발견합니다.
- 소프트웨어의 성능 또는 동작 오류를 발견합니다.
블랙박스 테스트의 특징
- 독립 테스트: 블랙박스 테스트는 애플리케이션 개발에 관여하지 않은 테스터가 수행하므로 편향되지 않고 공정한 테스트가 이루어질 수 있습니다.
- 사용자 관점의 테스트: 블랙박스 테스트는 최종 사용자의 관점에서 수행되므로 애플리케이션이 사용자 요구 사항을 충족하고 사용하기 쉬운지 확인하는 데 도움이 됩니다.
- 내부 코드에 대한 지식 없음: 블랙박스 테스트를 수행하는 테스터는 애플리케이션의 내부 코드에 액세스할 수 없으므로 애플리케이션의 외부 동작과 기능 테스트에 집중할 수 있습니다.
- 요구사항 기반 테스트: 블랙박스 테스트는 일반적으로 애플리케이션의 요구사항을 기반으로 진행되므로 애플리케이션이 필요한 사양을 충족하는지 확인하는 데 도움이 됩니다.
- 다양한 테스트 기법: 블랙박스 테스트는 기능 테스트, 사용성 테스트, 승인 테스트, 회귀 테스트 등 다양한 테스트 기법을 사용하여 수행할 수 있습니다.
- 간편한 자동화: 다양한 자동화 도구를 사용하여 블랙박스 테스트를 쉽게 자동화할 수 있어 전체 테스트 시간과 노력을 줄일 수 있습니다.
- 확장성: 블랙박스 테스트는 테스트 대상 애플리케이션의 규모와 복잡성에 따라 확장 또는 축소할 수 있습니다.
- 애플리케이션에 대한 제한된 지식: 블랙박스 테스트를 수행하는 테스터는 테스트 대상 애플리케이션에 대한 지식이 제한적이기 때문에 최종 사용자가 애플리케이션과 상호 작용하는 방식을 보다 대표적으로 테스트하는 데 도움이 됩니다.
White box Testing
화이트 박스 테스트 기법은 블랙 박스 테스트처럼 기능만 분석하는 것이 아니라 사용된 데이터 구조, 내부 설계, 코드 구조, 소프트웨어의 작동 방식 등 내부 구조를 분석합니다. 유리 상자 테스트, 클리어 박스 테스트 또는 구조적 테스트라고도 합니다. 화이트 박스 테스트는 투명 테스트 또는 오픈 박스 테스트라고도 합니다.
화이트박스 테스트란?
화이트박스 테스트는 소프트웨어의 내부 구조와 작동을 테스트하는 소프트웨어 테스트 기법입니다. 테스터는 소스 코드에 액세스할 수 있으며 이 지식을 사용하여 코드 수준에서 소프트웨어의 정확성을 검증할 수 있는 테스트 케이스를 설계합니다.
화이트 박스 테스트는 구조 테스트 또는 코드 기반 테스트라고도 하며 소프트웨어의 내부 로직, 흐름 및 구조를 테스트하는 데 사용됩니다. 테스터는 테스트 케이스를 생성하여 코드 경로와 논리 흐름을 검사하여 지정된 요구 사항을 충족 하는지 확인합니다.
화이트박스 테스트는 무엇에 중점을 두나요?
화이트 박스 테스트는 소프트웨어의 내부 작동에 대한 자세한 지식을 사용하여 매우 구체적인 테스트 사례를 생성합니다.
- 경로 검사(Path Checking): 프로그램이 실행될 때 취할 수 있는 다양한 경로를 검사합니다. 프로그램이 내리는 모든 결정이 정확하고 필요하며 효율적인지 확인합니다.
- 출력 검증(Output Validation): 다양한 입력을 테스트하여 함수가 매번 올바른 출력을 제공하는지 확인합니다.
- 보안 테스트(Security Testing): 정적 코드 분석과 같은 기술을 사용하여 소프트웨어의 잠재적인 보안 문제를 찾아 수정합니다. 소프트웨어가 안전한 방식으로 개발되었는지 확인합니다.
- 루프 테스트(Loop Testing): 프로그램의 루프를 검사하여 정확하고 효율적으로 작동하는지 확인합니다. 루프가 해당 범위 내에서 변수를 올바르게 처리하는지 확인합니다.
- 데이터 흐름 테스트(Data Flow Testing:): 프로그램에서 변수의 경로를 따라 변수가 올바르게 선언, 초기화, 사용, 조작되었는지 확인합니다.
화이트 박스 테스트의 유형
화이트박스 테스트는 다양한 목적으로 수행할 수 있습니다. 세 가지 주요 유형이 있습니다:
- 단위 테스트(Unit Testing)
- 통합 테스트(Integration Testing)
- 회귀 테스트(Regression Testing)
화이트 박스 테스트의 유형
단위 테스트(Unit Testing)
- 애플리케이션의 각 부분 또는 기능이 올바르게 작동하는지 확인합니다.
- 개발 중에 애플리케이션이 설계 요구 사항을 충족하는지 확인합니다.
통합 테스트(Integration Testing)
- 애플리케이션의 여러 부분이 함께 작동하는 방식을 검사합니다.
- 구성 요소가 단독으로 또는 함께 잘 작동하는지 확인하기 위해 단위 테스트 후에 수행합니다.
회귀 테스트(Regression Testing)
- 변경 또는 업데이트로 인해 기존 기능이 손상되지 않는지 확인합니다.
- 업데이트 후에도 애플리케이션이 기존의 모든 테스트를 통과하는지 확인합니다.
화이트 박스 테스트 기법
화이트박스 테스트의 주요 이점 중 하나는 애플리케이션의 모든 부분을 테스트할 수 있다는 것입니다. 완전한 코드 커버리지를 달성하기 위해 화이트박스 테스트는 다음과 같은 기술을 사용합니다:
1. Statement Coverage
이 기법에서는 모든 문을 적어도 한 번 이상 트래버스하는 것이 목표입니다. 따라서 각 코드 줄이 테스트됩니다. 순서도의 경우 모든 노드를 적어도 한 번은 통과해야 합니다. 모든 코드 줄을 다루기 때문에 결함이 있는 코드를 지적하는 데 도움이 됩니다.
Statement Coverage 예제
2. Branch Coverage
이 기법에서 테스트 케이스는 모든 의사 결정 지점의 각 브랜치가 적어도 한 번 이상 통과하도록 설계됩니다. 순서도에서 모든 에지는 적어도 한 번은 통과해야 합니다.
모든 의사 결정의 모든 브랜치, 즉 순서도의 모든 가장자리가 포함되도록 4개의 테스트 케이스가 필요합니다.
3. Condition Coverage
이 기법에서는 다음 예시와 같이 모든 개별 조건에 대해 다루어야 합니다:
- READ X, Y
- IF(X == 0 || Y == 0)
- PRINT ‘0’
- #TC1 – X = 0, Y = 55
- #TC2 – X = 5, Y = 04. Multiple Condition Coverage
이 기법에서는 조건의 가능한 모든 결과 조합을 적어도 한 번 이상 테스트합니다. 다음 예시를 살펴보겠습니다:
- READ X, Y
- IF(X == 0 || Y == 0)
- PRINT ‘0’
- #TC1: X = 0, Y = 0
- #TC2: X = 0, Y = 5
- #TC3: X = 55, Y = 0
- #TC4: X = 55, Y = 55. Basis Path Testing
이 기법에서는 코드 또는 순서도에서 제어 흐름 그래프를 만든 다음 독립 경로의 수를 정의하는 순환 복잡도를 계산하여 각 독립 경로에 대해 최소한의 테스트 케이스를 설계할 수 있도록 합니다. 단계:
- Make the corresponding control flow graph
- Calculate the cyclomatic complexity
- Find the independent paths
- Design test cases corresponding to each independent path
- V(G) = P + 1, where P is the number of predicate nodes in the flow graph
- V(G) = E – N + 2, where E is the number of edges and N is the total number of nodes
- V(G) = Number of non-overlapping regions in the graph
- #P1: 1 – 2 – 4 – 7 – 8
- #P2: 1 – 2 – 3 – 5 – 7 – 8
- #P3: 1 – 2 – 3 – 6 – 7 – 8
- #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 86. Loop Testing
루프는 널리 사용되며 많은 알고리즘의 기본이므로 테스트가 매우 중요합니다. 오류는 종종 루프의 시작과 끝에서 발생합니다.
- 단순 루프:** n 크기의 단순 루프의 경우 테스트 케이스는 다음과 같이 설계됩니다:
- 루프를 완전히 건너뛰기
- 루프를 한 번만 통과
- 2번 통과
- m 패스, 여기서 m < n
- n-1 및 n+1 패스
- 중첩 루프: 중첩 루프의 경우 모든 루프가 최소 개수로 설정되며 가장 안쪽 루프부터 시작합니다. 가장 안쪽 루프에 대해 간단한 루프 테스트가 수행되며 모든 루프가 테스트될 때까지 바깥쪽으로 진행됩니다.
- 연결된 루프: 독립적인 루프가 차례로 연결됩니다. 각각에 대해 간단한 루프 테스트가 적용됩니다. 독립적이지 않은 경우 중첩된 것처럼 취급합니다.
화이트박스 테스트 프로세스
- 입력: 요구사항, 기능 사양, 설계 문서, 소스 코드.
- 처리: 위험 분석을 수행하여 전체 프로세스를 안내합니다.
- 적절한 테스트 계획: 전체 코드를 포괄하는 테스트 케이스 설계. 오류 없는 소프트웨어에 도달할 때까지 반복 실행합니다. 또한 결과를 전달합니다.
- 결과물: 전체 테스트 프로세스의 최종 보고서를 작성합니다.
화이트 테스트는 2단계로 수행됩니다
- 테스터는 코드를 잘 이해해야 합니다.
- 테스터는 테스트 케이스에 대한 코드를 작성하고 실행해야 합니다.
화이트박스 테스트에 필요한 도구:
- PyUnit
- Sqlmap
- Nmap
- Parasoft Jtest
- Nunit
- VeraUnit
- CppUnit
- Bugzilla
- Fiddler
- JSUnit.net
- OpenGrok
- Wireshark
- HP Fortify
- CSUnit
화이트박스 테스트의 특징
- 코드 커버리지 분석: 화이트박스 테스트는 애플리케이션의 코드 커버리지를 분석하여 테스트되지 않는 코드 영역을 식별하는 데 도움이 됩니다.
- 소스 코드에 대한 액세스: 화이트 박스 테스트는 애플리케이션의 소스 코드에 대한 액세스가 필요하므로 개별 함수, 메서드 및 모듈을 테스트할 수 있습니다.
- 프로그래밍 언어에 대한 지식: 화이트박스 테스트를 수행하는 테스터는 코드 구조를 이해하고 테스트를 작성하기 위해 Java, C++, Python, PHP와 같은 프로그래밍 언어에 대한 지식이 있어야 합니다.
- 논리적 오류 식별: 화이트박스 테스트는 무한 루프나 잘못된 조건문과 같은 코드의 논리적 오류를 식별하는 데 도움이 됩니다.
- 통합 테스트: 화이트박스 테스트는 테스터가 애플리케이션의 여러 구성 요소가 예상대로 함께 작동하는지 확인할 수 있으므로 통합 테스트에 유용합니다.
- 단위 테스트: 화이트박스 테스트는 개별 코드 단위를 테스트하여 올바르게 작동하는지 확인하는 단위 테스트에도 사용됩니다.
- 코드 최적화: 화이트박스 테스트는 성능 문제, 중복 코드 또는 개선할 수 있는 기타 영역을 식별하여 코드를 최적화하는 데 도움이 될 수 있습니다.
- 보안 테스트: 화이트박스 테스트는 테스터가 애플리케이션 코드의 취약점을 식별할 수 있으므로 보안 테스트에도 사용할 수 있습니다.
- 설계 검증: 소프트웨어의 내부 설계가 지정된 설계 문서에 따라 구현되었는지 확인합니다.
- 정확한 코드 확인: 코드가 가이드라인 및 사양에 따라 작동하는지 확인합니다.
- 코딩 실수 식별: 구문 및 논리적 오류를 포함한 코드의 프로그래밍 결함을 찾아서 수정합니다.
- 경로 검사: 코드 실행의 가능한 각 경로를 탐색하고 코드의 다양한 반복을 테스트합니다.
- 데드 코드 확인: 프로그램이 정상적으로 실행될 때 사용되지 않는 코드(데드 코드)를 찾아서 제거합니다.
화이트박스 테스트의 장점
- 철저한 테스트 : 전체 코드와 구조를 테스트하기 때문에 화이트박스 테스트가 철저합니다.
- 코드 최적화 : 코드 최적화를 통해 오류를 제거하고 불필요한 코드 줄을 제거합니다.
- 결함 조기 발견: 블랙박스 테스트처럼 인터페이스가 필요 없기 때문에 초기 단계부터 시작할 수 있습니다.
- SDLC와 통합: 소프트웨어 개발 수명 주기에서 화이트박스 테스트를 쉽게 시작할 수 있습니다.
- 복잡한 결함 검출: 테스터는 다른 테스트 기법으로는 검출할 수 없는 결함을 식별할 수 있습니다.
- 종합적인 테스트 케이스: 테스터는 모든 코드 경로를 포괄하는 보다 포괄적이고 효과적인 테스트 케이스를 생성할 수 있습니다.
- 테스터는 코드가 코딩 표준을 충족하고 성능에 최적화되었는지 확인할 수 있습니다.
화이트박스 테스트의 단점
- 프로그래밍 지식 및 소스 코드 액세스: 테스터는 테스트를 수행하기 위해 프로그래밍 지식과 소스 코드에 대한 액세스 권한이 있어야 합니다.
- 내부 작업에 지나치게 집중: 테스터가 소프트웨어의 내부 작업에 지나치게 집중하여 외부 문제를 놓칠 수 있습니다.
- 테스트의 편향성: 테스터는 소프트웨어의 내부 작동에 익숙하기 때문에 소프트웨어에 대해 편향된 시각을 가질 수 있습니다.
- 테스트 케이스 오버헤드: 코드를 재설계하고 코드를 다시 작성하려면 테스트 케이스를 다시 작성해야 합니다.
- 테스터의 전문성에 대한 의존성: 테스터는 블랙박스 테스트와 달리 코드와 프로그래밍 언어에 대한 심층적인 지식이 필요합니다.
- 누락된 기능 감지 불가: 존재하는 코드를 테스트하기 때문에 누락된 기능을 감지할 수 없습니다.
- 프로덕션 오류 증가: 프로덕션에서 오류가 발생할 가능성이 높습니다.
Gray Box Testing
그레이 박스 테스트 는 블랙 박스 와 화이트 박스 테스트 의 조합입니다. 이 문서에서는 그레이 박스 테스트에 대해 자세히 설명합니다.
그레이박스 테스트란?
그레이 박스 테스팅 은 블랙 박스 테스팅 기법과 화이트 박스 테스팅 기법을 결합한 소프트웨어 테스팅 기법입니다.
- 블랙 박스 테스트 기법에서는 테스터가 테스트 대상 품목의 내부 구조를 알지 못하지만, 화이트 박스 테스트에서는 내부 구조가 테스터에게 알려져 있습니다.
- 그레이 박스 테스트에서는 내부 구조가 부분적으로 알려져 있습니다.
- 테스트 케이스를 설계하기 위한 내부 데이터 구조 및 알고리즘에 대한 액세스가 포함됩니다.
- 그레이 박스 테스트는 소프트웨어 프로그램이 테스터가 부분적으로 볼 수 있는 반투명 또는 회색 상자와 같기 때문에 그렇게 명명되었습니다.
- 일반적으로 웹 시스템과 관련된 상황별 오류에 중점을 둡니다.
- 프로그램을 테스트하기 전에 모든 조건이 제시되어 있기 때문에 요구 사항 테스트 케이스 생성을 기반으로 합니다.
그레이박스 테스트
그레이박스 테스트의 목표
- 블랙박스 테스트와 화이트박스 테스트의 장점을 결합하여 제공합니다.
- 개발자와 테스터의 의견을 결합합니다.
- 전반적인 제품 품질 향상
- 기능 및 비기능 테스트의 긴 프로세스의 오버헤드를 줄이기 위해.
- 개발자에게 결함을 수정할 수 있는 충분한 자유 시간을 제공합니다.
- 디자이너 관점이 아닌 사용자 관점에서 테스트합니다.
그레이박스 테스트의 기법
그레이박스 테스트의 주요 기법은 다음과 같습니다:
그레이 박스 테스트 기법
1. 매트릭스 테스트(Matrix Testing)
매트릭스 테스트에서는 소프트웨어 프로그램에서 개발자가 정의한 비즈니스 및 기술적 위험을 검사하는 기법입니다. 개발자는 프로그램에 존재하는 모든 변수를 정의합니다. 각 변수에는 고유한 기술적 및 비즈니스 위험이 있으며 수명 주기 동안 다양한 빈도로 사용될 수 있습니다.
2. 패턴 테스트(Pattern Testing)
패턴 테스트를 수행하기 위해 이전 결함을 분석합니다. 코드를 살펴봄으로써 결함의 원인을 파악합니다. 분석 템플릿에는 결함의 원인이 포함됩니다. 이렇게 하면 프로덕션에 적용하기 전에 다른 오류를 사전에 발견할 수 있으므로 테스트 사례를 설계하는 데 도움이 됩니다.
3. 직교 배열 테스트(Orthogonal Array Testing)
주로 블랙박스 테스트 기법입니다. 직교 배열 테스트에서 테스트 데이터에는 n개의 순열과 조합이 있습니다. 직교 배열 테스트는 테스트 케이스가 매우 적고 테스트 데이터가 많을 때 최대 커버리지가 필요할 때 선호됩니다. 이는 복잡한 애플리케이션을 테스트할 때 매우 유용합니다.
4. Regression Testing
회귀 테스트는 소프트웨어가 변경될 때마다 소프트웨어를 테스트하여 변경 사항이나 새로운 기능이 시스템의 기존 기능에 영향을 미치지 않는지 확인하는 것입니다. 또한 회귀 테스트는 결함을 수정해도 소프트웨어의 다른 기능에 영향을 미치지 않는지 확인하기 위해 수행됩니다.
5. 상태 전환 테스트(State transition Testing)
상태 전환 테스트는 작동 중 다양한 상태를 표시하는 시스템에 자주 적용됩니다. 내부 상태에 대한 이해가 부족한 테스터는 상태 전환이 올바르게 처리되는지 확인하기 위해 테스트 케이스를 생성합니다.
6. 의사 결정 테이블(Testing Decision Tables)
의사 결정 테이블은 복잡한 비즈니스 규칙과 추론을 정리하고 압축하는 데 유용한 도구입니다. 의사 결정 테이블은 이해도가 낮은 테스터가 입력 조건과 예상 결과의 여러 조합을 포함하는 테스트 케이스를 생성하는 데 사용됩니다.
7. API 테스트(Testing APIs)
메인 코드를 완전히 알 수는 없지만 API(Application Programing Interface) 테스트라고도 하는 그레이박스 테스트는 시스템의 노출된 인터페이스를 테스트하는 데 중점을 둡니다. 테스트의 주요 목표는 API가 다양한 입력 형식을 받아들이고 의도한 대로 작동 하는지 확인하는 것입니다.
8. 테이터 흐름 테스트(Data Flow Testing)
시스템을 통해 데이터 흐름 테스트를 분석하는 것은 데이터 흐름 테스트의 기초를 형성합니다. 부분 지식 테스터는 애플리케이션 전체에서 데이터의 경로를 검사하는 테스트 케이스를 생성하여 데이터 처리 및 처리 시 발생할 수 있는 문제를 식별하는 데 도움을 줍니다.
그레이박스 테스트의 장점
- 목표의 명확성: 사용자와 개발자는 테스트를 수행하는 동안 명확한 목표를 갖게 됩니다.
- 사용자 관점에서 수행: 그레이박스 테스트는 대부분 사용자 관점에서 수행됩니다.
- 높은 프로그래밍 기술이 필요하지 않음: 테스터는 이 테스트를 위해 높은 프로그래밍 기술이 필요하지 않습니다.
- 비침입성: 그레이 박스 테스트는 비침입성 테스트입니다.
- 제품 품질 향상: 제품의 전반적인 품질이 향상됩니다.
- 결함 수정: 그레이 박스 테스트에서 개발자는 결함 수정에 더 많은 시간을 할애할 수 있습니다.
- 블랙박스 및 화이트박스 테스트의 이점 : 그레이박스 테스트를 수행함으로써 블랙박스 테스트와 화이트박스 테스트의 이점을 모두 얻을 수 있습니다.
- 편견 없음: 그레이 박스 테스트는 편견이 없습니다. 테스터와 개발자 간의 충돌을 방지합니다.
- 효과적인 테스트: 그레이박스 테스트는 통합 테스트에서 훨씬 더 효과적입니다.
그레이박스 테스트의 단점
- 결함 연관성의 어려움: 분산 시스템에 대해 그레이 테스트를 수행할 경우 결함 연관성이 어렵습니다.
- 내부 구조에 대한 접근 제한 : 내부 구조에 대한 접근이 제한되어 코드 경로 탐색에 제한이 있습니다.
- 소스 코드 접근 불가: 소스 코드에 접근할 수 없으므로 완전한 화이트박스 테스트가 불가능합니다.
- 알고리즘 테스트에 적합하지 않음: 그레이박스 테스트는 알고리즘 테스트에 적합하지 않습니다.
- 설계하기 어려운 테스트 케이스 : 대부분의 테스트 케이스는 설계하기 어렵습니다.
