💡 테스트
소프트웨어 개발에서의 테스트는 소프트웨어의 품질을 평가하고 결함을 발견하여 실제 동작 사이의 차이를 수정하는 작업이다. 테스트는 소프트웨어의 오류를 최소화하고 사용자에게 안정적이고 신뢰할 수 있는 소프트웨어를 제공하기 위해 필수적이다.
그러나 테스트는 결함이 있음을 보여줄 뿐, 결함이 없음을 증명할 수는 없다. 소프트웨어는 복잡하고 다양한 입력 조건과 환경에서 실행되기 때문에 모든 가능성을 고려하여 완벽하게 테스트하는 것은 불가능하다. 따라서 테스트는 소프트웨어의 특정 부분을 검사하고 그 부분에 대한 오류를 찾아내고 수정함으로써 소프트웨어의 신뢰성과 안정성을 향상시키는 데에 주로 사용된다.
⚬ 파레토 법칙
파레토 법칙은 경영학자 빌포르도 파레토가 이탈리아에서 20%의 사람이 80% 부를 소유하고 있는 현상을 보고 제시한 원리로, "80:20 법칙" 또는 "중요한 몇 가지 원인이 결과의 대부분을 설명한다"는 개념을 나타낸다.
테스트에 파레토 원리를 적용함으로써 제한된 리소스를 가지고도 효과적으로 결함이나 오류에 대응할 수 있다. 또한, 주요한 원인에 집중함으로써 테스트의 효율성을 개선하고, 시간과 비용을 절감할 수 있다.
⚬ 롱테일 법칙 / 롱테일 현상
롱테일 법칙은 상위 몇 개의 인기 있는 항목들이 대부분의 수요를 가져오는 반면, 그 외에 수많은 항목들이 상대적으로 작은 수요를 가지는 현상을 설명하는 법칙이다.
예를 들어, 온라인 음악 스트리밍 서비스에서 상위 몇 개의 인기 아티스트들이 많은 사람들에게 많이 들어지는 반면, 그 외에도 수많은 아티스트들의 음악들이 존재하는데, 이러한 경우 상위 인기 아티스트들이 헤드에 해당하며, 그 외의 아티스트들이 롱테일에 해당한다.
⚬ 패러독스
패러독스는 논리적 또는 상반된 개념 또는 주장을 함께 가지고 있는 문제나 상황을 가리키는 용어이다. 보통 상식이나 직관과는 반대되는 결과를 가져와서 우리의 사고를 도전하거나 논리적인 모순을 드러내는 역할을 한다. 이러한 역설은 우리의 사고의 패턴을 변화시키고 새로운 통찰력을 제공한다.
💡 테스트 필요성과 특징
1. 오류 (Error)
소프트웨어 개발자가 프로그램을 작성하거나 구현할 때 실수로 발생하는 결함이나 잘못된 부분을 의미한다.
예를 들어, 잘못된 변수명, 잘못된 연산, 잘못된 조건문 등 프로그램 코드에서 발생하는 실수들이 오류의 원인이 될 수 있다.
2. 결함 (Fault)
결함은 소프트웨어에 내재된 오류로, 프로그램이 기대한 동작을 수행하지 못하는 상태를 나타낸다.
오류로 인해 프로그램의 일부 기능이 제대로 작동하지 않거나 예기치 않은 동작을 수행할 수 있다.
결함은 개발자의 실수에 의해 발생하거나 요구사항을 충족시키지 못하는 부분을 나타낼 수 있다.
3. 고장 (Problem)
고장은 시스템이 요구사항에 맞게 작동하지 않는 상태를 의미한다.
소프트웨어의 결함으로 인해 시스템이 오동작하거나 기대한 결과를 제공하지 못하는 상황을 가리킨다.
고장은 요구사항 분석이나 명세서의 부족, 잘못된 요구사항 등에 의해 발생할 수 있다.
💡 테스트 절차
1. 테스트 계획: 테스트 목적, 범위, 일정, 리소스, 테스트 방법 등을 정의하는 계획을 수립한다.
2. 테스트 설계: 테스트 케이스를 작성하고, 테스트 데이터를 준비한다. 이 단계에서는 예상되는 소프트웨어 동작을 확인하고, 테스트 목표를 달성하기 위한 테스트 시나리오를 설계한다.
3. 테스트 실행: 작성된 테스트 케이스를 실행하여 소프트웨어의 동작을 확인한다. 테스트 결과를 기록하고, 예상된 결과와 실제 결과를 비교하여 차이를 확인한다.
4. 테스트 결과 분석: 테스트 결과를 분석하여 결함이나 오류를 식별하고, 우선순위를 부여한다. 이 단계에서는 테스트 커버리지를 평가하고, 테스트 결과를 통해 소프트웨어의 품질을 평가한다.
5. 오류 추적 및 수정: 발견된 결함을 기록하고, 개발팀에 보고하여 수정될 수 있도록 한다. 오류 추적 시스템을 사용하여 결함의 상태를 추적하고, 수정된 소프트웨어에 대한 재테스트를 수행한다.
💡 테스트 분류
⚬ 시각에 따른 테스트 (V & V)
1. Verification
각 단계에서 개발자의 입장에서 테스트하는 것이다.
2. Validation
요구사항이 맞는지, 설계서의 내용대로 코딩이 이루어졌는지를 테스트하는 것이다.
⚬ 사용 목적에 따른 테스트
1. 성능 테스트
2. 스트레스 테스트
3. 보안 테스트
4. 안정성 테스트
5. 복원 가능성 테스트
⚬ 프로그램 실행 여부에 따른 테스트
1. 정적 테스트
정적 테스트는 프로그램을 실행하지 않고 코드나 문서를 검토하여 오류를 찾는 방법이다.
주로 코드 리뷰, 문서 검토, 정적 분석 도구 등을 사용하여 소스 코드, 설계 문서, 요구사항 등을 검사한다.
목적은 프로그램의 구조, 논리적인 오류, 일반적인 코딩 규칙 준수 여부 등을 확인하여 개발 초기에 오류를 발견하고 수정하는 것으로, 변수 사용 오류, 함수 호출 오류, 잘못된 제어 흐름 등을 검사한다.
2. 동적 테스트
동적 테스트는 프로그램을 실행하면서 실제 입력 데이터를 사용하여 프로그램의 동작을 검증하는 방법이다.
테스트 케이스를 설계하고 실행하여 프로그램의 예상된 동작과 실제 동작을 비교하여 오류를 찾는다.
목적은 프로그램의 실행 경로, 예외 처리, 데이터 처리 등을 확인하여 실제 환경에서의 동작을 평가하는 것으로, 특정 입력값을 주고 결과를 확인하거나 예외 상황을 발생시켜 처리하는지를 확인한다.
⚬ Black Box (명세 기반 테스트)
블랙박스 테스트는 동적 테스트의 한 종류로, 프로그램의 내부 구조나 알고리즘을 보지 않고 명세서나 설계 사양서를 기반으로 테스트를 수행하는 방법이다.
테스트 케이스를 추출하여 입력값에 대한 예상 출력을 정의하고, 실제로 그 결과가 예상과 일치하는지를 확인한다.
블랙박스 테스트는 프로그램의 기능을 어떻게 수행하는가 보다는 사용자가 요구한 기능을 올바르게 수행하는가에 초점을 둔다.
⚬ White Box (구조 기반 테스트)
화이트박스 테스트는 프로그램의 내부 구조, 알고리즘, 소스 코드 등을 분석하여 테스트 케이스를 설계하고 검증하는 방법이다.
테스트 대상의 내부 동작에 직접적인 접근이 필요하며, 프로그램의 제어 흐름, 조건문, 반복문 등을 검증한다.
화이트박스 테스트는 프로그램의 내부 로직에 초점을 두고 테스트를 수행하므로, 코드의 모든 경로를 커버하고 오류를 찾는 데 유용하다.
주로 개발자가 수행하며, 테스트 대상에 대한 내부 구조에 대한 이해가 필요하다.
블랙박스 테스트는 사용자 관점에서 기능을 테스트하고, 화이트박스 테스트는 개발자 관점에서 내부 구현을 테스트한다. 두 가지 접근 방식은 서로 보완적이며, 테스트의 완전성과 효과성을 높이기 위해 종종 혼합하여 사용된다.
💡 V 모델
V 모델은 소프트웨어 개발 생명주기에서 요구사항 정의부터 테스트까지의 단계를 V자 형태로 연결하여 표현한 모델이다. 이 모델은 각 단계에서 수행되는 테스트의 유형과 그 연결성을 강조한다.
⚬ 알파 테스트
알파 테스트는 개발자의 시선에서 문제를 파악하고 개선하기 위한 단계로, 개발 완료된 소프트웨어를 베타 테스트 전에 회사 내의 다른 직원에게 테스트하는 것이다.
개발자가 개발 환경에서 소프트웨어를 다른 직원들에게 사용하면서 오류나 사용상의 문제점을 파악하고 수정한다.
⚬ 베타 테스트
베타 테스트는 소프트웨어의 시장 적합성을 평가하고 사용자들의 의견을 반영하여 제품을 완성하는 단계로, 알파 테스트를 거친 후에 개발이 완료된 소프트웨어를 실제 사용자에게 배포하여 테스트하는 것이다.
일반 사용자들에게 미리 사용해보도록 소프트웨어를 배포하고, 사용자들이 실제 환경에서 사용하면서 문제점이나 오류를 개발자에게 보고한다. 이를 통해 사용자의 피드백을 수집하고, 보고된 문제점을 수정하여 최종 제품 출시 전에 사용자 요구에 맞게 조정한다.
