경계값 분석(일반적으로 BVA로 줄임)은 일반적인 블랙박스 테스트 기법입니다. 이 접근 방식은 허용 범위의 경계에서 입력값을 확인하여 소프트웨어 결함을 테스트합니다.
이 글에서는 경계 분석 테스트가 무엇인지, 왜 유용한지 살펴보고 몇 가지 다른 접근 방식, 기법 및 다양한 경계 테스트 도구를 살펴봅니다.
소프트웨어 테스트에서 경계값 분석이란 무엇인가요?
경계값 분석은 기능 테스트의 한 유형입니다. 이러한 유형의 테스트는 소프트웨어의 각 기능이 요구 사항 및 사양을 충족하는지 확인하는 것과 관련이 있습니다. 바운더리 테스트의 경우, 이 기능에는 소프트웨어가 다양한 입력을 처리하는 방법이 포함됩니다.
BVA는 입력 경계의 가장자리 또는 그 부근에서 소프트웨어가 입력에 어떻게 반응하는지 검증하는 소프트웨어 테스트 기법입니다. 기본적으로 각 입력에는 허용 범위가 있습니다. 예를 들어 8~12자 사이의 비밀번호를 허용하는 로그인용 비밀번호 상자가 있을 수 있습니다. 경계 테스트는 문자 길이가 7, 8, 12, 13인 비밀번호를 테스트합니다.
여기서는 7, 8, 12, 13과 같은 극한값의 경계가 9, 10, 11과 같은 경계 안쪽의 숫자보다 오류를 발생시킬 가능성이 더 높다는 점을 고려한 것입니다. 8~12자를 허용하는 필드 상자의 예에서는 이러한 이점이 미미해 보일 수 있지만, 1~20자 또는 1~1000 사이의 숫자를 허용하는 필드 상자에 대한 테스트 케이스를 작성해야 하는 경우 그 이점이 더욱 분명해집니다.
따라서 기능 테스트 내에서 시간을 절약하고 테스트 케이스 수를 줄이기 위해 경계 값 분석은 값을 살펴봅니다:
- 최소값으로
- 최소값 바로 아래
- 최대값으로
- 최대값 바로 위
테스트에서 경계값 분석의 이점
바운더리 테스트는 QA 팀에게 몇 가지 강력한 이점을 제공합니다.
#1. 소프트웨어 품질 향상
테스터에게 악몽 같은 시나리오는 눈에 띄지 않는 버그와 결함입니다. 확인해야 할 사항이 너무 많기 때문에 일부 결함은 틈새로 빠져나갈 수 있습니다. 바운더리 테스트는 소프트웨어에서 오류가 발생할 가능성이 높은 영역의 기능을 입증하여 소프트웨어 빌드를 개선하고 궁극적으로 더 안정적이고 안정적인 애플리케이션으로 이어집니다.
#2. 테스트 범위 확대
소프트웨어 테스트에서 BVA는 포괄적인 테스트 커버리지에 필요한 테스트 케이스 수를 줄이는 데 도움이 되기 때문에 매우 유용합니다. 경계 값 분석을 통해 중요한 값과 각 값을 더욱 철저하게 테스트할 수 있습니다.
#3. 조기 결함 감지
경계값 테스트는 조기 결함 발견을 우선시하는 접근 방식의 일부입니다. 프로세스 초기에 버그를 발견하면 개발팀은 개발 초기 단계에서 버그를 수정하는 것이 훨씬 쉽다는 사실을 언급하지 않고도 시간과 비용을 절약할 수 있습니다.
#4. 능률
경계값 테스트는 많은 테스트 케이스에 대한 요구 사항을 완화하기 때문에 매우 효율적입니다. 실제로 문제를 일으킬 가능성이 가장 높은 항목을 제외한 모든 항목으로 입력을 줄이면 테스트 팀의 테스트 케이스 작성 및 실행 시간을 크게 절약할 수 있습니다.
테스트에서 경계값 분석의 단점
물론 완벽하거나 한계가 없는 소프트웨어 테스트 기술은 없습니다. 경계 값 분석에는 많은 이점이 있지만, 이 기능 테스트 기법으로 작업하는 데는 몇 가지 제약이 있습니다.
#1. 좁은 범위
BVA는 유효한 데이터 입력의 경계 또는 가장자리에서 작동합니다. 일반적으로 가장자리에 유효한 입력이 있으면 괜찮을 것이라고 추론하여 중간 입력은 무시합니다. 그러나 검증되지 않은 일부 값에 문제가 있을 수 있다는 전례가 없는 것은 아닙니다.
#2. 지나치게 단순함
경계 분석은 일을 단순하게 만드는 것입니다. 이 접근 방식은 테스트 케이스를 줄이는 데는 효과적이지만 여러 경계, 상호 작용 또는 종속성이 있는 매우 복잡한 도메인에는 적합하지 않습니다. 실제로 복잡한 시나리오를 처리하는 데 어려움을 겪을 수 있으므로 적절한 적용 범위를 위해 다른 기술을 모색해야 합니다.
#3. 가정
효율성을 높이려는 모든 프로세스는 특정 오류를 놓칠 위험이 있습니다. BVA는 범위의 가장자리에 있는 경계에 초점을 맞춥니다. 이 과정에서 경계 값의 양쪽에 해당하는 다른 입력값에 대한 가정을 해야 합니다. 테스터는 효율성과 커버리지 사이의 균형을 유지해야 하며, 바운더리 테스트만 사용할 경우 약간의 위험이 따를 수 있습니다.
#4. 정확한 사양 및 요구 사항에 대한 신뢰
효율적인 BVA는 사양 및 요구 사항 문서의 품질과 정확성에 달려 있습니다. 이러한 문서에서 확인되지 않은 오류는 경계값 테스트에 영향을 미쳐 개발의 중요한 후반 단계까지 특정 오류가 확인되지 않고 발견되지 않을 수 있습니다.
#5. 동등성 클래스에 대한 의존도
철저한 BVA를 수행하려면 동등성 클래스에 대한 탄탄한 실무 지식이 필요합니다. 이러한 클래스를 정확하게 설정하려면 경험과 애플리케이션에 대한 배경 정보가 필요합니다.
경계값 분석의 과제
소프트웨어 테스트
지금쯤이면 경계 테스트의 장단점에 대해 어느 정도 이해하셨을 것입니다. 그러나 이 접근 방식을 자체 소프트웨어 테스트에 구현하려면 극복해야 할 다양한 과제를 알고 있어야 합니다.
다음은 소프트웨어 테스트에서 경계값 테스트를 구현할 때의 몇 가지 과제입니다.
#1. 경계 윤곽 설정
단순한 시스템 내에서 경계를 식별하는 것은 유능한 테스터에게는 거의 어려운 일이 아닙니다. 하지만 다음과 같은 더 복잡한 상황도 있습니다:
- 다양한 입력 변수 또는 복잡한 관계가 있는 복잡한 입력 도메인
- 사양 문서에 명확하게 설명되지 않은 문서화되지 않은 경계선
- 사용자 행동 또는 기타 조건에 따라 변경되는 동적 경계
#2. 모호한 요구 사항
잘못 작성되거나 불명확한 요구사항 문서는 경계값을 식별하는 데 방해가 될 수 있습니다. 명확성, 완전성, 철저한 사양 문서 작성에 대한 노력은 시간이 걸리지만 결국에는 보상을 받을 수 있습니다.
#3. 전문성
경계 값 분석은 놀라울 정도로 복잡할 수 있습니다. 실제로 테스트 팀에는 기술의 미묘한 뉘앙스를 이해하기 위해 해당 분야에 대한 경험과 지식을 갖춘 인력이 필요합니다. 또한 테스터는 소프트웨어에 대한 지식을 어느 정도 갖추고 있거나 최소한 신뢰할 수 있는 사양 문서를 가지고 있어야 합니다.
#4. 오류
경계 분석은 유효한 입력과 유효하지 않은 입력을 검증하는 데 필요한 테스트 케이스의 수를 줄이려고 합니다. 그러나 테스트 범위 밖에 있는 결함은 쉽게 발견되지 않을 수 있습니다. 또한 ‘오프-바이-원’ 오류는 경계에서 또는 경계 근처에서 발생할 수 있는 일반적인 코딩 실수입니다. 테스터는 이러한 시나리오를 염두에 두고 테스트에 대비해야 합니다.
#5. 테스트 사례 폭발
여러 입력 경계가 작용하면 테스트 케이스는 곧 복잡해지고 통제 불능 상태가 될 수 있습니다. 이러한 상황에서는 경계 테스트를 통해 절약할 수 있는 시간과 비용이 손실되어 솔루션의 이점이 훼손됩니다. 조합이나 순열이 많은 복잡한 소프트웨어 빌드도 비슷한 효과를 낼 수 있습니다.
#6. 분석 도구의 제한 사항
소프트웨어 테스트 자동화 도구는 팀이 적절한 경계 값 분석을 수행하는 데 도움이 될 수 있습니다. 그러나 최상의 경우에도 이러한 도구는 테스트와 테스트 생성 모두에 약간의 수동 개입이 필요합니다. 여러 변수가 상호 작용하는 복잡한 빌드의 경우 이러한 상황이 악화될 수 있습니다.
다양한 유형의 경계 값
소프트웨어 테스트의 테스트
소프트웨어 테스트: 장인의 접근 방식』의 저자 Paul C. Jorgensen과 Byron DeVries는 다음과 같은 네 가지 유형의 경계값 테스트에 대해 설명합니다:
1. 정상 경계 값 테스트(NBVT)
- 입력 도메인의 가장자리에서 유효한 입력 값을 테스트합니다.
- 경계 바로 위와 아래의 입력과 함께 최소값과 최대값을 탐색합니다.
- 이것은 경계 값 분석의 고전적인 유형입니다.
2. 강력한 경계 값 테스트(RBVT)
- 위의 NBVT와 유사하지만 유효하지 않은 입력도 포함됩니다.
- 경계와 경계를 넘어선 테스트는 물론 잘못된 입력도 설명합니다.
- 극단적이거나 예상치 못한 출력에서 오류를 찾는 데 중점을 둡니다.
3. 3. 최악의 경계값 테스트(WBVT)
- 극단적인 유효 및 유효하지 않은 값을 사용하여 소프트웨어 동작을 검증합니다.
- 입력 도메인의 가장자리에 있는 값과 이러한 경계를 넘어서는 값을 탐색합니다.
- 보다 극단적인 조건에서 소프트웨어 동작을 이해하고자 합니다.
4. 강력한 최악의 경우 경계값 테스트(RWBVT)
- 가장 철저한 경계값 테스트를 위해 RBVT와 WBVT를 혼합하여 사용합니다.
- 일반적인 경계와 극단적인 경계 모두에서 유효한 입력 값과 유효하지 않은 입력 값을 테스트합니다.
- 경계 관련 결함을 찾을 수 있는 최고의 기회 제공
이러한 접근 방식은 포괄성에서 차이가 있으며, RWBVT가 가장 철저합니다. 그러나 테스터는 이러한 추가 수준의 결함 발견을 위해 필요한 시간과 노력에 대한 추가 투자를 인정해야 합니다.
동등성 분할 및 경계 값
분석: 유사점과 차이점
동등성 분할과 경계 값 분석은 종종 서로 함께 사용됩니다. 실제로 이 두 기술은 상호보완성이 매우 높습니다. 하지만 데이터 입력의 유효성을 검사하는 방식은 서로 다릅니다. 다음은 두 가지의 유사점과 차이점을 살펴봅니다.
1. 유사점
동등성 분할과 경계 값 분석은 훌륭한 조합을 이룹니다. 다음은 두 기술 간의 몇 가지 유사점입니다.
- 두 가지 모두 블랙박스 테스트 기법으로, 애플리케이션의 소스 코드에 대한 선험적 지식 없이도 테스트할 수 있는 입력과 출력에 초점을 맞춘 테스트 기법입니다.
- 두 가지 모두 입력 테스트에 대한 철저한 접근 방식의 일부입니다.
- 두 가지 모두 테스터가 과도한 양의 테스트 케이스를 작성하지 않고도 포괄적인 테스트 커버리지 사이에서 균형을 잡을 수 있도록 도와줍니다.
2. 차이점
동등성 파티셔닝과 경계 값 분석의 차이점을 살펴보기 위해서는 각각을 개별적으로 살펴볼 필요가 있습니다.
동등성 파티셔닝
- 입력 데이터를 유사한 시스템 출력을 가져올 수 있는 동등성 클래스로 나눕니다.
- 각 클래스의 단일 대표 값을 사용하고 해당 값으로 시스템을 테스트합니다.
- 유효한 동등성 클래스와 유효하지 않은 동등성 클래스를 식별하는 것과 관련이 있습니다.
경계값 분석
- 동등성 클래스의 경계 또는 가장자리에서 값을 테스트합니다.
- 최소값, 최대값, 경계 양쪽의 값 등 다양한 값을 테스트합니다.
- 경계 가장자리에서 발견되는 오류를 찾습니다.
동등성 분할 및 경계값 분석 예제
동등성 분할 및 경계 값 분석에 대한 이해를 돕기 위해 몇 가지 예를 들어 설명합니다.
동등성 파티셔닝 예제:
자동차 등록을 위한 입력 상자가 있다고 가정해 보겠습니다. 일반적으로 미국 자동차 번호판은 6~7개의 문자로 구성되어 있습니다. 간소화를 위해 특수 번호판을 할인해 드립니다.
유효한 데이터 = 플레이트 6 또는 7 문자
잘못된 데이터 = >6자 또는 >7자가 포함된 번호입니다.
경계 값 분석 예제:
위와 동일한 번호판 예시를 사용하여 경계 분석은 다음을 테스트합니다.
유효한 데이터 = 6자 또는 7자로 된 번호판
잘못된 데이터 = 5자 또는 8자의 번호판, 일부 시나리오에서는 4자와 9자의 번호판입니다.
경계값 분석 예제
개념을 완전히 이해하는 가장 좋은 방법은 다른 경계 값 분석 예시를 한두 가지 살펴보는 것입니다.
경계 값 테스트 예제 #1
경계 값 테스트에 대해 더 자세히 알아보기 위해 연령 확인 도메인의 예를 살펴보겠습니다.
사용자가 나이를 입력할 수 있는 상자가 있습니다.
경계 값은 다음과 같습니다:
- 최소 연령 = 18세
- 최대 연령 = 120세
바운더리 테스트 사례 예시:
총 6개의 테스트 케이스가 있습니다:
- 17, 18, 19는 각각 최소값, 최소값 이하, 최소값 초과입니다.
- 119, 18, 19는 각각 최대치, 최대치 이하, 최대치 이상입니다.
경계 값 테스트 예제 #2.
다음 경계 테스트 예제에서는 100달러 이상 주문 시 20%의 최소 금액 구매 할인을 제공하는 웹사이트를 살펴보겠습니다.
이 예제에서는 600달러 이상 구매 시 25% 할인이 적용됩니다. 경계 값 테스트는 $100에서 $600 사이의 입력을 처리합니다.
경계 값은 다음과 같습니다:
최소 적격 할인 = $100
최대 적격 할인 = $600
바운더리 테스트 사례 예시:
다시 말하지만, 총 6개의 테스트 사례를 생성합니다:
- 99.99달러, 100달러, 100.01달러로 각각 최소, 최소 이하, 최소 이상입니다.
- 599.99달러, 600달러, 600,01달러로 각각 상한선, 하한선, 상한선보다 낮습니다.
소프트웨어 테스트의 경계 테스트는 정확한가요?
연구 논문 ‘ 동등성 분할 및 경계값 분석 방법을 사용한 블랙박스 테스트‘에서 저자는 인도네시아 마타람 대학교의 학술 정보 시스템을 테스트하기 위해 동등성 분할과 경계값 분석을 사용하는 방법을 살펴봅니다.
저자들은 테스트에 널리 사용되는 오픈 소스 테스트 도구인 셀레늄을 사용하여 총 322개의 테스트 케이스를 실행했습니다. 동등성 테스트와 경계값 분석을 통해 약 80개의 실패 사례를 발견했으며, 그 결과 유효 테스트 점수와 무효 테스트 점수의 비율은 약 75:25로 나타났습니다. 전반적으로 소프트웨어 테스트에 동등성 파티셔닝과 BVA를 함께 사용하면 소프트웨어에 대한 철저하고 유용한 테스트가 이루어집니다.
최고의 경계값 테스트 도구
전용 경계 테스트 소프트웨어 도구는 드물지만, 이 작업을 수행할 수 있는 주목할 만한 테스트 도구는 많이 있습니다.
#3. TestCaseLab
테스트케이스 랩은 클라우드 기반 테스트 관리 도구로, BVA 테스트에 도움이 될 수 있습니다. 이 소프트웨어를 사용하면 팀은 직관적이고 매력적인 UI에서 테스트 케이스를 생성하고 관리할 수 있습니다. 테스트케이스 랩은 유연하고 기능이 풍부하지만 제한된 보고 및 사용자 지정 옵션 등 제약이 있습니다.
#2. Micro Focus UFT One
Micro Focus UFT One은 기능 및 회귀 테스트에 중점을 둔 소프트웨어 테스트 도구입니다. 다양한 플랫폼, 기기, API 테스트를 지원하며 강력한 통합 옵션을 제공합니다. 노코드 및 키워드 기반 테스트 생성을 모두 지원하며 팀이 경계 가치 분석 테스트 사례를 쉽게 구축할 수 있도록 도와줍니다. 가파른 학습 곡선, ZAPTEST와 같은 도구와 비교할 때 부족한 성능 등 고려해야 할 몇 가지 한계가 있습니다.
#1. 재프테스트
ZAPTEST는 고급 RPA 기능을 갖춘 종합적인 소프트웨어 자동화 테스트 도구입니다. 테스터에게 사용자 친화적이고 강력한 테스트 자동화 도구 모음을 제공하여 소프트웨어 테스트에서 BVA를 비롯한 다양한 방법으로 소프트웨어를 검증하는 데 도움을 줄 수 있도록 제작되었습니다.
경계 값 분석에 도움이 되는 ZAPTEST의 가장 강력한 사용 사례로는 테스트 케이스 생성, 테스트 데이터 처리, 테스트 실행, 보고 및 분석이 있습니다. 다양한 템플릿과 높은 수준의 사용자 지정, 코드 없는 테스트 케이스 생성 기능을 통해 ZAPTEST 사용자는 모든 유형의 경계 분석을 위한 강력한 테스트 케이스를 빠르고 쉽게 생성하고 관리할 수 있습니다.
테스트 사례 생성 및 관리 외에도 ZAPTEST의 RPA 기능은 테스트 팀의 경계값 분석 테스트에 다른 방식으로 도움을 줄 수 있습니다. 예를 들어 테스트 케이스 실행을 자동화하고, 테스트 데이터를 생성하고, 다른 테스트 도구와의 강력한 통합을 구축할 수 있습니다.
경계값 테스트를 위한 팁
- 경계값 분석과 동등성 파티셔닝을 결합하여 다양한 입력 시나리오를 테스트 케이스에 포함할 수 있습니다.
- 유효하지 않은 입력 시나리오(예: 네거티브 테스트)를 사용하여 소프트웨어가 오류 및 예기치 않은 입력을 처리하는 방법을 확인합니다.
- 텍스트, 숫자, 부울 등 다양한 데이터 유형에 대한 경계값을 식별하는 데 시간을 투자하세요.
- 중요한 기능 또는 오류가 발생할 가능성이 높은 영역에 대한 경계 값 테스트 우선순위 지정
- 사용자가 도메인에 입력할 데이터의 종류를 나타내는 현실적인 데이터를 사용하세요.
마지막 생각들
경계 값 분석은 유용한 기능 테스트 접근 방식입니다. 입력 도메인이 있는 경우 유효한 데이터를 허용하고 잘못된 데이터를 수신하면 오류 메시지를 보내는지 확인해야 합니다. 경계 분석 테스트는 포괄적인 테스트에 필요한 테스트 케이스만 구축하여 효율적인 방식으로 해당 기능을 검증하는 데 도움이 됩니다.
경계 테스트는 허용 범위 안팎의 값을 살펴보고 시스템이 이러한 입력에 어떻게 반응하는지 확인합니다. 결론적으로 중복 테스트 케이스를 빌드할 필요가 없으므로 시간이 많이 절약되고 노력이 줄어듭니다. 마감 시한이 빠르게 다가오는 소프트웨어 개발의 세계에서 테스트 팀은 가능한 모든 도움을 필요로 합니다.
