Test Design: Concepts, Techniques, and Black Box Testing
1️⃣ Core Concepts of Test Design
2️⃣ Classification of Test Design Techniques
3️⃣ Black Box Test Preview
What is Test Design?
Test design is an activity performed after test planning is complete. It is the stage where you define what to test and how to test it. During this process, the test targets and scope are determined, enabling more efficient test execution.
In software testing, it is practically impossible to verify every possible combination. For example, with just 2 variables that hold True/False values, there are already 4 combinations. As the number of variables grows to 20 or 100, the number of possible combinations increases exponentially, making exhaustive testing completely infeasible. This is precisely why an efficient test strategy is needed — and test design plays that central role.
From a PDCA cycle perspective, test design falls under the P (Plan) phase. This is because it is preparatory work that must be completed before tests are actually executed dynamically. Specifically, this phase includes test case development, test procedure definition, and test environment preparation. Each of these activities will be covered in detail in subsequent posts.
테스트 설계란 무엇인가?
테스트 설계는 테스트 계획이 완료된 이후에 수행되는 활동으로, 무엇을 어떻게 테스트할지를 구체화하는 단계다. 이 과정에서 테스트 대상과 범위가 결정되며, 이를 바탕으로 보다 효율적인 테스트를 수행할 수 있게 된다.
소프트웨어 테스트에서 모든 경우의 수를 전부 검증하는 것은 현실적으로 불가능하다. 예를 들어 True/False 값을 가지는 변수가 단 2개만 있어도 조합은 4가지가 되는데, 변수가 20개, 100개로 늘어나면 가능한 조합의 수는 기하급수적으로 증가해 완전한 테스트 자체가 불가능해진다. 바로 이 때문에 효율적인 테스트 전략이 필요하며, 테스트 설계가 그 핵심 역할을 담당한다.
PDCA 사이클 관점에서 테스트 설계는 P(Plan) 단계에 해당한다. 실제 테스트를 동적으로 실행하기 이전에 사전에 준비해야 하는 작업이기 때문이다. 구체적으로는 테스트 케이스 개발, 테스트 절차 정의, 테스트 환경 준비가 이 단계에 포함된다. 각 세부 활동에 대한 내용은 이후 강의에서 다룰 예정이다.
Test Design as Defined by ISO/IEC/IEEE 29119
ISO/IEC/IEEE 29119 is an international standard for software testing. Let's look at how test design is positioned within this standard.
The standard divides the test process into two main areas: the Test Management Process and the Dynamic Test Process. Test planning takes place within the test management process, and its outputs are passed on to the dynamic test process where actual testing activities occur.
Within the dynamic test process, there are two areas that correspond to test design.
The first is Test Design and Implementation. This stage takes the test plan as input and concretizes what and how to test, with Test Basis analysis as its starting point.
The second is Test Environment Setup and Maintenance. Based on the environment requirements identified during test design and implementation, this activity involves building and managing the actual test environment.
The outputs of these two stages; the test cases and the prepared test environment; are passed together to the Test Execution stage, where dynamic testing finally takes place.
In summary, the key point is that within the 29119 standard, test design is defined as a concept that encompasses not just writing test cases, but also setting up the test environment.
ISO/IEC/IEEE 29119에서 정의하는 테스트 설계
ISO/IEC/IEEE 29119는 소프트웨어 테스팅에 관한 국제 표준으로, 이 표준에서 테스트 설계가 어떻게 위치하는지를 살펴보자.
표준에서 테스트 프로세스는 크게 테스트 관리 프로세스와 동적 테스트 프로세스로 구분된다. 테스트 계획은 테스트 관리 프로세스에서 진행되며, 그 결과가 동적 테스트 프로세스로 전달되어 실제 테스트 활동이 이루어진다.
동적 테스트 프로세스 내에서 테스트 설계에 해당하는 영역은 두 가지다.
첫째, 테스트 설계 및 구현이다. 테스트 계획을 입력으로 받아 테스트 베이시스(Test Basis)를 도출하는 단계로, 무엇을 어떻게 테스트할지 구체화된다.
둘째, 테스트 환경 구성 및 유지다. 테스트 설계 및 구현 단계에서 도출된 환경 요구사항을 바탕으로 실제 테스트 환경을 구성하고 관리하는 활동이다.
이 두 단계의 결과물, 즉 테스트 케이스와 준비된 테스트 환경이 함께 테스트 수행 단계로 전달되어 비로소 동적 테스트가 실제로 실행된다.
정리하면, 29119 표준에서 테스트 설계는 단순히 테스트 케이스를 작성하는 것에 그치지 않고, 테스트 환경 구성까지 포함하는 개념으로 정의된다는 점이 핵심이다.
Test Design and Implementation / Test Environment Setup and Maintenance
ISO/IEC/IEEE 29119 divides test design into two major activities.
Test Design and Implementation is the stage where test cases and procedures are defined based on the test scope and strategy identified in the test plan. The starting point is Test Basis analysis. The Test Basis refers to the artifacts that serve as the foundation for creating test cases. In the V-model, for example, architecture design artifacts serve as the basis for creating integration test cases - the left-side (development) artifacts that are referenced to build right-side (test) cases. By analyzing the Test Basis, the following items are derived: Test requirements, Test conditions, Test coverage criteria and Test cases.
Test Environment Setup and Maintenance requires that an appropriate environment and data be ready before tests can actually be executed. Taking automotive software as an example, testing may begin in a PC environment, gradually expand to a laboratory setting, and ultimately extend to a real road environment where actual vehicles operate. Constructing these various test environments and preparing the necessary data for each is the core activity of this stage.
테스트 설계 및 구현 / 테스트 환경 구성 및 유지
ISO/IEC/IEEE 29119 표준에서 테스트 설계는 크게 두 가지 활동으로 나뉜다.
테스트 설계 및 구현 테스트: 계획에서 식별된 테스트 범위와 전략을 바탕으로 테스트 케이스와 절차를 구체화하는 단계다. 이 과정의 출발점은 테스트 베이시스(Test Basis) 분석이다. 테스트 베이시스란 테스트 케이스를 만들기 위한 기반이 되는 산출물을 말한다. V모델을 예로 들면, 통합 테스트 케이스를 만들 때 아키텍처 설계 산출물이 그 기반이 된다. 즉, 오른쪽(테스트 단계)의 케이스를 만들기 위해 참조하는 왼쪽(개발 단계)의 산출물이 테스트 베이시스에 해당한다. 이 테스트 베이시스를 분석함으로써 다음 항목들을 도출하게 된다.
테스트 요구사항
테스트 조건
테스트 커버리지
기준 테스트 케이스
테스트 환경 구성 및 유지: 테스트를 실제로 실행하려면 적절한 환경과 데이터가 준비되어야 한다. 자동차 소프트웨어를 예로 들면, 초기에는 PC 환경에서 테스트하지만 점차 실험실 환경으로 확장되고, 최종적으로는 실제 차량이 주행하는 도로 환경에서까지 테스트가 이루어질 수 있다. 이처럼 다양한 테스트 환경을 구성하고, 각 환경에서 필요한 데이터를 준비하는 것이 이 단계의 핵심 활동이다.
The Need for Test Design
Why is test design necessary? It can be summarized into two main purposes.
First, to perform efficient and effective testing.
Second, to properly verify software across diverse platforms and environments.
More detailed coverage of each purpose follows below.
테스트 설계의 필요성
테스트 설계는 왜 필요한 걸까? 크게 두 가지 목적으로 정리할 수 있다.
첫째, 효율적이면서 효과적인 테스트를 수행하기 위해서다.
둘째, 다양한 플랫폼과 환경에서 소프트웨어를 제대로 검증하기 위해서다.
각 목적에 대한 더 자세한 내용은 이어지는 내용에서 다룰 예정이다.
Two Reasons Why Test Design is Necessary
Efficient and Effective Test Execution Verifying every single test case is simply not realistic. Projects always operate under limited resources — people, budget, tools, and equipment. Therefore, a systematic approach is needed to secure sufficient coverage with a minimal number of test cases. What matters is not the sheer volume of test cases, but the ability to derive cases with a high probability of detecting defects. Even with tens of thousands of test cases, if only a handful of defects are found, it cannot be considered good testing. Test design provides the systematic techniques to achieve this.
Verification Across Diverse Environments and Platforms No matter how well software runs on a developer's PC, it is meaningless if it does not operate reliably in the actual user environment. To verify behavior across various operating systems, browsers, hardware, and devices, the corresponding environments must be set up in advance. From the V-model perspective, starting to build the test environment only after coding is finished is already too late. Test environments, equipment, and tool configurations must be prepared in parallel with the left-side activities of writing test specifications and specs.
Key Point: Test design does not happen after coding — it proceeds in parallel with the development activities of the V-model.
테스트 설계의 필요성; 두 가지 이유
효율적이고 효과적인 테스트 수행: 모든 테스트 케이스를 일일이 검증하는 것은 현실적으로 불가능하다. 프로젝트에서는 인력, 비용, 도구, 장비 등 자원이 항상 제한되어 있기 때문이다. 따라서 적은 수의 테스트 케이스로 충분한 커버리지를 확보하는 체계적인 접근이 필요하다. 이때 중요한 것은 단순히 테스트 케이스의 수가 아니라 결함을 발견할 확률이 높은 테스트 케이스를 도출하는 것이다. 테스트 케이스가 수만 개라도 발견한 결함이 극히 일부에 불과하다면 좋은 테스트라고 할 수 없다. 테스트 설계는 이를 위한 체계적인 기법을 제공한다.
다양한 환경과 플랫폼에서의 검증: 개발자 PC에서 아무리 잘 동작하는 소프트웨어라도, 실제 사용자 환경에서 안정적으로 동작하지 않으면 의미가 없다. 다양한 운영체제, 브라우저, 하드웨어, 디바이스에서의 동작 여부를 검증하려면 해당 환경이 미리 구축되어 있어야 한다. V모델 관점에서 보면, 테스트 환경 구축은 코딩이 끝난 후에 시작해서는 너무 늦다. 테스트 명세와 테스트 스펙을 작성하는 왼쪽 활동과 병행해서 실제 테스트 환경, 장비, 도구 세팅을 함께 준비해 나가야 한다.
핵심 포인트: 테스트 설계는 코딩 이후가 아닌, V모델의 개발 활동과 함께 진행된다는 점을 반드시 기억하자.
Test Design Activity ① Test Case Development
The first major activity in test design is test case development. Based on the Test Basis; the left-side V-model artifacts such as requirements documents, design documents, and code. This involves writing test cases to verify that the software properly satisfies its requirements.
A test case is a document that systematically records test conditions, input values, expected output values, and actual results. Let's look at a concrete example.
In TC_1, since the lowercase "cuk" is stored in the DB, entering "CUK" in uppercase should produce an "ID not found" warning. If the actual result is "Login successful," it means case sensitivity is not properly implemented, and debugging is required. Once resolved, if "ID not found" warning appears correctly, the defect is fixed.
TC_2's expected output and actual result both show "Incorrect password warning," so it is determined to be functioning correctly.
In this way, test cases are written based on the Test Basis; test specs, design documents, etc. — to systematically verify that the software meets its requirements.
테스트 설계의 주요 활동 ① 테스트 케이스 개발
테스트 설계의 첫 번째 주요 활동은 테스트 케이스 개발이다. 요구사항, 설계서, 코드 등 V모델 왼쪽의 산출물인 테스트 베이시스를 기반으로, 소프트웨어가 요구사항을 제대로 만족하는지 확인하기 위한 테스트 케이스를 작성하는 작업이다.
테스트 케이스는 테스트 조건, 입력값, 예상 출력값, 실행 결과 등을 체계적으로 기록한 문서다. 아래 예시를 통해 구체적으로 살펴보자.
TC_1의 경우 DB에 소문자 cuk로 저장되어 있으므로 대문자 CUK 입력 시 "아이디 없음 경고"가 예상 출력값이다. 그런데 실행 결과가 "정상 로그인"이라면 대소문자 구분이 제대로 구현되지 않은 것이므로 디버깅이 필요하다. 조치 후 "아이디 없음 경고"가 정상 출력되면 결함이 해결된 것이다.
TC_2는 예상 출력값과 실행 결과가 모두 "비밀번호 틀림 경고"로 일치하므로 정상 동작으로 판단한다.
이처럼 테스트 케이스는 테스트 스펙이나 설계서 등 테스트 베이시스를 기반으로, 소프트웨어가 요구사항을 만족하는지를 체계적으로 검증하기 위한 형태로 작성된다.
[Reference] Test Case Components
There are certain components that must be included when writing a test case.
ID is a naming convention used to identify each test case. When there are hundreds or thousands of test cases, a systematic ID system is essential for distinguishing them. For example, unit tests might use UT-1, UT-2, and system tests might use ST-1, ST-2.
Conditions are the preconditions required for the test to run. These specify what must be in place before execution — such as a specific environment being set up, or certain variable values being pre-stored.
Expected output is the anticipated result when the test runs correctly. Just as "ID not found warning" is the expected output when an uppercase ID is entered in the earlier example, each test case must have a clearly defined expected result defined in advance.
In addition, the test purpose, test execution date, and assigned tester should also be recorded when writing test cases.
[참고] 테스트 케이스의 구성 항목
테스트 케이스를 작성할 때 반드시 포함되어야 하는 구성 항목들이 있다.
ID는 테스트 케이스를 식별하기 위한 명명 규칙이다. 테스트 케이스가 수백, 수천 개에 달하는 경우 각각을 구분할 수 있어야 하므로 체계적인 ID 부여가 필수다. 예를 들어 유닛 테스트라면 UT-1, UT-2, 시스템 테스트라면 ST-1, ST-2와 같은 형식으로 작성한다.
조건은 테스트가 수행되기 위한 사전 조건이다. 특정 환경이 갖춰져 있어야 한다거나, 변수값이 미리 저장되어 있어야 하는 등 테스트 실행 전에 반드시 정의되어 있어야 하는 항목들을 명시한다.
예상 출력값은 테스트가 정상적으로 수행될 때 기대되는 결과값이다. 앞선 예시에서 대문자 아이디 입력 시 "아이디 없음 경고"가 출력되어야 하는 것처럼, 테스트 케이스마다 명확한 기대값이 사전에 정의되어 있어야 한다.
이 외에도 테스트 목적, 테스트 수행 날짜, 담당 테스터 등의 항목도 테스트 케이스 작성 시 함께 기록되어야 한다.
Test Design Activity ② Test Procedure Definition
The second major activity in test design is test procedure definition. This involves determining the specific order in which various tests — unit, integration, system, acceptance, etc. — will be performed.
Integration Test Procedure Example
In the V-model, integration testing verifies that interfaces between modules operate correctly, based on the software architecture. A representative artifact used here is the sequence diagram — a diagram that represents the flow of function calls between modules from top to bottom.
For example, when integration testing software composed of Mod_A through Mod_G, the procedure can be defined incrementally as follows. Rather than integrating all modules at once, you first verify that Function_A() between A and D operates correctly, then add E in step 2, followed by F, G, and so on. When software contains dozens or hundreds of modules, integrating everything at once is impossible — which is why defining a step-by-step procedure starting from small units is essential.
Key Point
Test procedure definition is not a concept exclusive to integration testing. Systematically defining the execution order applies to all test types, including unit testing and acceptance testing. From the V-model perspective, test procedure definition must be carried out in parallel with the left-side development activities.
테스트 설계의 주요 활동 ② 테스트 절차 정의
테스트 설계의 두 번째 주요 활동은 테스트 절차 정의다. 단위, 통합, 시스템, 인수 등 다양한 테스트를 어떤 순서로 수행할지 구체적인 절차를 결정하는 활동이다.
통합 테스트 절차 예시
V모델에서 통합 테스트는 소프트웨어 아키텍처를 기반으로 모듈 간 인터페이스가 적절히 동작하는지를 검증한다. 이때 활용되는 대표적인 산출물이 시퀀스 다이어그램이다. 시퀀스 다이어그램은 모듈 간에 수행되는 함수 호출 흐름을 위에서 아래로 표현한 다이어그램이다.
예를 들어 Mod_A ~ Mod_G로 구성된 소프트웨어를 통합 테스트한다면, 절차는 다음과 같이 단계적으로 정의할 수 있다. 한 번에 모든 모듈을 통합하는 것이 아니라, 1단계에서 A와 D 간의 Function_A() 호출이 정상 동작하는지 확인한 뒤, 2단계에서 E를 추가하고, 이후 F, G를 순차적으로 붙여가며 검증하는 방식이다. 소프트웨어 내에 수십, 수백 개의 모듈이 존재할 때 한 번에 통합하는 것은 불가능하므로, 이처럼 작은 단위부터 순서대로 통합해 나가는 절차가 반드시 필요하다.
핵심 포인트
테스트 절차 정의는 통합 테스트에만 해당하는 개념이 아니다. 단위 테스트, 인수 테스트 등 모든 테스트 유형에서 수행 순서를 체계적으로 정의하는 것이 필요하다. 또한 V모델 관점에서 테스트 절차 정의는 개발의 왼쪽 활동과 함께 병행하여 수행되어야 한다는 점을 반드시 기억하자.
Test Design Activity ③ Test Environment Preparation
The third major activity in test design is test environment preparation. This involves deciding in which environment each test; unit, integration, system, acceptance - will actually be executed, and building that environment in advance.
Test environment preparation requires not just software, but also hardware, tools, and equipment. Taking an automotive electronic control system as an example, the environment expands incrementally as integration progresses:
Application Software — standalone test
Platform Software — integration and test
Hardware (ECU) — integration and test
Sensor / Actuator — connection and test
Mechanics — full system test including mechanical components
Software development alone does not make testing possible. Sensors that provide input to the controller, actuators that handle actual operation, and mechanical components must all be prepared at each stage well in advance.
For this reason, test environment preparation should not begin after development is complete. It must be systematically planned and built in parallel with the left-side activities of the V-model.
테스트 설계의 주요 활동 ③ 테스트 환경 준비
테스트 설계의 세 번째 주요 활동은 테스트 환경 준비다. 단위, 통합, 시스템, 인수 등 각 테스트를 실제로 어떤 환경에서 수행할지 결정하고, 그에 맞는 환경을 미리 구축하는 활동이다.
테스트 환경 준비에는 소프트웨어뿐만 아니라 하드웨어, 도구, 장비 등이 함께 갖춰져야 한다. 자동차 전자 제어 시스템을 예로 들면, 전체 구조는 다음과 같이 단계적으로 통합되며 테스트 환경도 이에 맞춰 확장된다.
Application Software 단독 테스트
Platform Software 통합 후 테스트
Hardware(ECU) 통합 후 테스트
Sensor / Actuator 연결 후 테스트
Mechanics(기계적 구성 요소) 포함한 전체 시스템 테스트
이처럼 소프트웨어만 개발한다고 테스트가 가능한 것이 아니다. 제어기에 입력을 제공하는 센서, 실제 구동을 담당하는 액추에이터, 그리고 기계적 구성 요소까지 각 단계에서 필요한 환경이 미리미리 준비되어 있어야 한다.
이러한 이유로 테스트 환경 준비는 개발이 완료된 후에 시작하는 것이 아니라, V모델의 왼쪽 활동과 병행하여 사전에 체계적으로 계획하고 구축해 나가야 한다.
2️⃣ Classification of Test Design Techniques
Classification of Test Design Techniques
When creating test cases, systematic test design techniques are applied. Before exploring the types of techniques, let's take a moment to think about it with the V-model in mind.
How can test design techniques be classified?
In the V-model, unit, integration, system, and acceptance tests correspond to each stage of development. Just as the target and purpose of testing differ at each stage, the techniques used to derive test cases can also be classified in various ways depending on the criteria and perspective. The specific classification will be explored in the content that follows.
테스트 설계 기법의 분류
테스트 케이스를 만들 때는 체계적인 테스트 설계 기법을 적용한다. 기법의 종류를 살펴보기 전에, 먼저 V모델을 떠올리며 스스로 생각해보자.
테스트 설계 기법은 어떤 기준으로 분류할 수 있을까?
V모델에서는 개발 단계에 따라 단위, 통합, 시스템, 인수 테스트가 대응된다. 각 단계마다 테스트의 대상과 목적이 다르듯, 테스트 케이스를 도출하는 기법도 그 기준과 관점에 따라 다양하게 분류될 수 있다. 구체적인 분류 방법은 이어지는 내용에서 살펴보도록 하자.
Classification of Test Design Techniques — Black Box vs. White Box
Test design techniques are broadly divided into two categories: Black Box Testing and White Box Testing.
Black Box Testing (Specification-Based Testing)
A "black box" refers to a state where the internal structure and details are not visible. Black box testing focuses solely on whether the output for a given input is appropriate, without considering the software's internal logic. For example, the goal is to verify that inputting 1 and 2 produces 3; not to examine what logic internally calculated that result.
Test cases are derived not from source code, but from the left-side artifacts of the V-model — requirements documents and design specifications. Because it is based on specifications rather than code, it is also known as Specification-Based Testing.
White Box Testing (Structure-Based Testing)
A "white box" refers to a state where the internal structure and details are fully visible. White box testing creates test cases from the source code itself, with the goal of covering as many of the program's internal flows and paths as possible.
Since test cases are derived from the algorithms and logic defined in the source code or detailed design documents, it is also called Structure-Based Testing, as it involves examining the entire structure of the program.
테스트 설계 기법의 분류; 블랙박스 vs 화이트박스
테스트 설계 기법은 크게 블랙박스 테스트와 화이트박스 테스트 두 가지로 나뉜다.
블랙박스 테스트 (명세 기반 테스트)
블랙박스란 내부 구조나 세부 내용이 보이지 않는 상태를 의미한다. 블랙박스 테스트는 소프트웨어의 내부 로직은 고려하지 않고, 입력에 대해 적절한 출력이 나오는지에만 집중한다. 예를 들어 1과 2를 입력했을 때 3이 출력되는지를 확인하는 것이지, 내부적으로 어떤 로직을 통해 3이 계산되었는지는 보지 않는다.
테스트 케이스를 만들 때도 소스코드가 아닌 V모델의 왼쪽 산출물, 즉 요구사항 명세서나 설계 스펙을 기반으로 도출한다. 코드가 아닌 명세를 기반으로 한다는 점에서 명세 기반 테스트(Specification-based Test) 라고도 불린다.
화이트박스 테스트 (구조 기반 테스트)
화이트박스는 내부 구조와 세부 내용이 보이는 상태를 의미한다. 화이트박스 테스트는 소스코드 그 자체를 대상으로 테스트 케이스를 만들며, 프로그램 내부의 다양한 흐름과 경로를 최대한 커버하는 것을 목표로 한다.
소스코드 또는 상세 설계서에 정의된 알고리즘과 로직을 기반으로 테스트 케이스를 도출하기 때문에, 프로그램의 전체 구조를 들여다본다는 의미에서 구조 기반 테스트(Structure-based Test) 라고도 불린다.
Black Box Testing (Specification-Based Testing) — In Depth
Black box testing excludes the software's internal logic entirely and focuses only on whether the output for a given input is correct. Because test cases are derived from specifications such as requirements documents and design documents — rather than source code — it is also referred to as specification-based or spec-based testing.
For example, consider a program that outputs the largest number among several inputs. The internal comparison algorithm used is irrelevant. Based on the specification, the following test cases are derived:
Case where A is the largest
Case where B is the largest
Case where C is the largest
Case where A is entered as a negative number
The essence of black box testing is verifying that the program produces the correct output in each of these situations.
블랙박스 테스트 (명세 기반 테스트) 심화
블랙박스 테스트는 소프트웨어 내부의 로직은 배제하고, 입력에 대한 출력 값에만 초점을 두는 테스트 방법이다. 테스트 케이스는 소스코드가 아닌 요구사항 명세서나 설계서 등의 스펙을 기반으로 도출하기 때문에 명세 기반 테스트, 스펙 기반 테스트라고도 불린다.
예를 들어 여러 숫자 중 가장 큰 수를 출력하는 프로그램이 있다고 하자. 내부적으로 어떤 비교 알고리즘을 사용하는지는 관심 밖이다. 스펙을 기반으로 다음과 같은 테스트 케이스를 도출한다.
A가 가장 큰 경우
B가 가장 큰 경우
C가 가장 큰 경우
A를 음수로 입력하는 경우
이처럼 프로그램이 각 상황에서 올바른 출력을 내는지를 확인하는 것이 블랙박스 테스트의 핵심이다.
White Box Testing (Structure-Based Testing) — In Depth
White box testing aims to test as many independent paths within the source code as possible. Test cases are derived from the source code itself, or equivalent detailed design documents and algorithm logic.
While the form of inputs and outputs is the same as in black box testing, white box testing directly examines the internal logic, creating a test case for each individual execution path within the program. Using the "largest number output" program as an example:
Because it examines the entire internal structure and aims to cover every independent path without omission, this approach is also called Structure-Based Testing.
화이트박스 테스트 (구조 기반 테스트) 심화
화이트박스 테스트는 소스코드 내의 모든 독립적인 경로를 최대한 테스트하는 방법이다. 소스코드, 혹은 이에 준하는 상세 설계서와 알고리즘 로직을 기반으로 테스트 케이스를 도출한다.
입력과 출력의 형태는 블랙박스 테스트와 동일하지만, 내부 로직을 직접 들여다보기 때문에 프로그램 안에 존재하는 다양한 실행 경로 하나하나를 테스트 케이스로 만든다. 앞서 살펴본 큰 수 출력 프로그램을 예로 들면 다음과 같다.
이처럼 내부 구조를 모두 들여다보며 독립적인 경로를 빠짐없이 커버하려 한다는 점에서 구조 기반 테스트(Structure-based Test) 라고도 부른다.
[Reference] Test Approaches by V-Model Stage
The test target, environment, and applicable technique differ at each stage of the V-model.
Unit Testing targets individual modules such as functions and files, and is conducted in the developer's own development environment. Since test cases are derived directly from source code, white box testing is applied.
Integration Testing verifies the interfaces between internal and external modules, and is typically conducted in a laboratory environment. Because both source code and specifications are often referenced together, it can be applied in a gray box form that combines white box and black box approaches.
System Testing covers the entire integrated software, verifying not only functional aspects but also non-functional qualities such as performance, usability, maintainability, and compatibility. It is conducted in an environment similar to the actual operating environment, and can also be applied in gray box form.
Acceptance Testing verifies the final software from the user's perspective in a real-world environment, confirming that it operates according to the requirements defined by the user. Since users have no need to examine internal code, black box testing is applied, using requirements definition documents and similar specs as the Test Basis.
[참고] V모델 단계별 테스트 방안
V모델의 각 테스트 단계별로 테스트 대상, 환경, 적용 기법이 달라진다.
단위 테스트 ㅡ 단위 모듈(함수, 파일 등)을 대상으로 하며, 개발자의 개발 환경에서 진행된다. 소스코드 자체를 기반으로 테스트 케이스를 도출하기 때문에 화이트박스 테스트가 적용된다.
통합 테스트 ㅡ 내부 및 외부 모듈 간의 인터페이스를 검증하는 단계로, 보통 실험실 환경에서 진행된다. 소스코드와 스펙을 함께 참조하는 경우가 많아 화이트박스와 블랙박스를 혼합한 그레이박스 형태로 적용이 가능하다.
시스템 테스트 ㅡ 통합된 소프트웨어 전체를 대상으로 기능적 측면뿐만 아니라 성능, 사용성, 유지보수성, 호환성 등 비기능적인 부분까지 검증하는 단계다. 실제 운영환경과 유사한 환경에서 진행되며, 그레이박스 형태로도 적용 가능하다.
인수 테스트 ㅡ 사용자 관점에서 최종 소프트웨어를 실제 환경에서 검증하는 단계로, 사용자가 제시한 요구사항대로 동작하는지를 확인한다. 사용자가 내부 코드를 볼 필요가 없으므로 요구사항 정의서 등의 스펙을 테스트 베이시스로 삼는 블랙박스 테스트가 적용된다.
3️⃣ Block box testing Preview
Black Box Test Design Techniques
Black box testing is an approach that excludes the internal logic of source code and verifies whether the output for a given input is appropriate. Test cases are derived from specifications such as requirements documents and architecture design documents. ISO/IEC/IEEE 29119 defines a variety of black box test techniques. Representative techniques include:
Syntax Testing
Equivalence Partitioning
Boundary Value Analysis
And many more
In this post, we will use Syntax Testing to understand the fundamental concept of black box test techniques. The remaining techniques will be covered in subsequent posts.
블랙박스 테스트 설계 기법
블랙박스 테스트는 소스코드의 내부 로직은 배제하고, 입력에 대한 출력이 적절한지를 검증하는 방식이다. 테스트 케이스는 요구사항 명세서, 아키텍처 설계서 등의 스펙을 기반으로 도출된다. ISO/IEC/IEEE 29119 표준에서는 다양한 블랙박스 테스트 기법을 정의하고 있다. 대표적인 기법으로는 다음과 같은 것들이 있다.
신택스 테스팅 (Syntax Testing)
동등 분할 (Equivalence Partitioning)
경계값 분석 (Boundary Value Analysis)
그 외 다수
이번에는 신택스 테스팅(Syntax Testing) 을 통해 블랙박스 테스트 기법의 기본 컨셉을 살펴보고, 나머지 기법들은 이어지는 내용에서 다룰 예정이다.
Black Box Test Technique ① Syntax Testing
Syntax Testing is one of the easiest black box test techniques to apply. The core concept is to divide input values into Valid and Invalid categories and create test cases accordingly. Test cases are derived from requirements documents or design specifications.
Example: User Registration ㅡ Username Input
Username condition: Korean characters only, minimum 2 characters, maximum 8 characters
When "홍길동 99" is entered, the expected output is "Number included — invalid," but if the actual result shows "Normal," it means the program failed to properly detect the number, indicating a defect.
In this way, Syntax Testing verifies only the output result — without looking at the internal logic at all — by creating test cases based on the valid/invalid conditions defined in the specification. The same approach can be applied to all input fields such as username, password, and email address.
블랙박스 테스트 기법 ① 신택스 테스팅 (Syntax Testing)
신택스 테스팅은 블랙박스 테스트 기법 중 가장 쉽게 적용할 수 있는 방법이다. 핵심 개념은 입력값을 적합(Valid) 과 부적합(Invalid) 으로 구분하여 테스트 케이스를 만드는 것이다. 테스트 케이스는 요구사항 명세서나 설계 스펙을 기반으로 도출된다.
예시: 회원가입 — 사용자 이름 입력
사용자 이름 조건: 2자리 이상 8자리 이하의 한글만 허용
"홍길동 99" 입력 시 예상 출력값은 "숫자 포함 부적합 경고"이지만 실행 결과가 "정상"으로 출력된다면, 프로그램이 숫자를 제대로 인식하지 못한 것이므로 결함이 존재한다는 것을 알 수 있다.
이처럼 신택스 테스팅은 내부 로직은 전혀 보지 않고, 스펙에 정의된 적합/부적합 조건을 기준으로 테스트 케이스를 만들어 출력 결과만을 검증하는 방식이다. 아이디, 비밀번호, 이메일 주소 등 모든 입력 항목에 동일한 방식으로 적용할 수 있다.
Syntax Testing Applied — Shopping Mall Product Search Feature
Let's apply Syntax Testing to a product search feature in a shopping mall system. This feature allows users to enter a product name or product number as a keyword, and the system searches for and displays the matching product.
All valid/invalid conditions are derived from the specification (requirements documents, design documents, etc.). Test cases can only be accurately created when these conditions are clearly defined.
The Importance of Specifications
There is a critical point that must be emphasized here. From the V-model perspective, test cases are built from the left-side artifacts — requirements definitions and design documents. If these artifacts are not properly written, it becomes difficult to accurately derive test cases. In the worst case, testers may end up creating test cases based on guesswork rather than a solid specification.
Ultimately, good testing starts with good specs. Never forget that the thoroughness with which left-side artifacts are written determines the overall quality of the entire test design activity.
신택스 테스팅 적용 예시; 쇼핑몰 상품 검색 기능
쇼핑몰 시스템의 상품 검색 기능을 예시로 신택스 테스팅을 적용해보자. 이 기능은 사용자가 상품명 또는 상품 번호를 키워드로 입력하면 해당 상품을 검색하여 표시하는 기능이다. 이 적합/부적합 조건은 모두 스펙(요구사항 명세서, 설계서 등) 으로부터 도출된다. 조건이 명확히 정의되어 있어야 테스트 케이스를 정확하게 만들 수 있다.
스펙의 중요성
여기서 반드시 짚고 넘어가야 할 점이 있다. V모델 관점에서 테스트 케이스는 왼쪽의 산출물, 즉 요구사항 정의서나 설계서를 기반으로 만들어진다. 따라서 이 산출물들이 제대로 작성되어 있지 않으면 테스트 케이스를 정확히 도출하기가 어려워진다. 최악의 경우 테스터가 스펙 없이 추측에 의존해 테스트 케이스를 만들게 되는 상황이 발생할 수 있다.
결국 좋은 테스트는 좋은 스펙에서 시작된다. 왼쪽 산출물을 충실히 작성하는 노력이 테스트 설계 활동 전체의 품질을 좌우한다는 점을 반드시 기억하자.
Syntax Testing Applied — Writing Test Cases for the Product Search Feature
Let's write actual test cases based on the valid/invalid conditions defined earlier.
Product Name Test Cases
When "노트북^^" is entered, the special characters are ignored and laptop search results are displayed. Since this differs from the expected output defined in the spec, it is identified as a defect and debugging is required.
When "AA12345678" is entered, the letters are not properly recognized and the result shows "Normal." This is likewise identified as a defect and the code must be corrected.
Key Takeaway
Every step of this process — identifying input variables, defining valid/invalid conditions, and deriving test cases — is based not on source code, but on specifications such as requirements documents and architecture design documents. Ultimately, the quality of test cases depends on the quality of the specifications. Always remember: how thoroughly the left-side artifacts of the V-model are written determines the overall completeness of the entire test effort.
신택스 테스팅 적용 예시; 쇼핑몰 상품 검색 기능의 테스트 케이스 작성
앞서 정의한 적합/부적합 조건을 바탕으로 실제 테스트 케이스를 작성해보자.
"노트북^^" 입력 시 특수 기호를 무시하고 노트북 검색 결과가 출력되었다. 스펙에 명시된 예상 출력값과 다르므로 결함으로 판단하고 디버깅이 필요하다.
"AA12345678" 입력 시 영문을 제대로 인식하지 못하고 정상으로 출력되었다. 마찬가지로 결함으로 판단하고 코드를 수정해야 한다.
핵심 정리
이 모든 과정 ~ 입력 변수를 찾고, 적합/부적합 조건을 정의하고, 테스트 케이스를 도출하는 것 은 소스코드가 아닌 요구사항 명세서, 아키텍처 설계서 등의 스펙을 기반으로 이루어진다. 결국 테스트 케이스의 품질은 스펙의 품질에 달려 있다. V모델의 왼쪽 산출물을 얼마나 충실하게 작성하느냐가 테스트 전체의 완성도를 결정한다는 점을 반드시 기억하자.
