소프트웨어 테스트 또는 소프트웨어 테스트는 응용 프로그램 테스트라고도 합니다.
소프트웨어 테스팅은 기본적으로 상호 연결된 여러 프로세스로 구성된 대규모 프로세스입니다. 소프트웨어 테스트의 주요 목표는 기본 요구 사항 측면에서 소프트웨어의 완전성과 함께 소프트웨어의 무결성을 측정하는 것입니다. 소프트웨어 테스트에는 다양한 테스트 프로세스를 통해 소프트웨어를 검사하고 테스트하는 작업이 포함됩니다. 이러한 프로세스의 목표에는 다음이 포함될 수 있습니다.
기능/비즈니스 요구 사항에 대한 소프트웨어 완전성 검증
버그/기술적 오류 식별 및 소프트웨어에 오류가 없음을 확인
사용성, 성능, 보안성, 현지화, 호환성, 설치성 평가
테스트된 소프트웨어는 완전하거나 사용하기에 적합하기 위해 모든 테스트를 통과해야 합니다. 다양한 유형의 소프트웨어 테스트 방법에는 화이트 박스 테스트, 블랙 박스 테스트 및 그레이 박스 테스트가 포함됩니다. 또한 소프트웨어는 구성 요소/장치 또는 라이브 시스템 내에서 전체적으로 테스트할 수 있습니다.
블랙박스 테스트는 시스템의 내부 작동과 관련하여 소프트웨어의 기능을 분석하는 데 중점을 둔 소프트웨어 테스트 기술입니다. Black Box Testing은 고객의 요구 사항, 사양 및 높은 수준의 설계 전략을 분석하기 위한 방법으로 개발되었습니다.
Black Box Testing 테스터는 일련의 유효 및 무효 코드 실행 및 입력 조건을 선택하고 유효한 출력 응답을 확인합니다.
블랙 박스 테스트는 기능 테스트 또는 폐쇄 상자 테스트라고도 합니다.
검색 엔진은 블랙 박스 테스트 대상 애플리케이션의 간단한 예입니다. 검색 엔진 사용자가 웹 브라우저의 검색 표시줄에 텍스트를 입력합니다. 그런 다음 검색 엔진은 사용자 데이터 결과(출력)를 찾아 검색합니다.
블랙박스 테스트의 이점은 다음과 같습니다.
Black Box Testing에는 다음과 같은 몇 가지 단점도 있습니다.
화이트박스 테스트 중에 코드는 미리 선택된 입력 값으로 실행되어 미리 선택된 출력 값을 검증합니다. 화이트 박스 테스트에는 종종 스텁 코드(특정 기능을 대체하는 데 사용되는 코드 조각. 스텁은 원격 시스템의 프로시저와 같은 기존 코드의 동작을 시뮬레이션할 수 있음) 및 드라이버 작성이 포함됩니다.
화이트 박스 테스트의 이점은 다음과 같습니다.
단점은 다음과 같습니다.
단위 테스트는 원하는 적합성 또는 동작을 위해 소프트웨어 프로그램의 가장 작은 부분에 포괄적인 테스트 절차가 개별적으로 적용되는 소프트웨어 개발 수명 주기(SDLC)의 구성 요소입니다.
단위 테스트는 대부분의 엔터프라이즈 소프트웨어 개발 활동에 적용되는 품질 측정 및 평가 절차입니다. 일반적으로 단위 테스트는 소프트웨어 코드가 소프트웨어/응용 프로그램/프로그램의 전체 목표를 얼마나 잘 준수하는지와 그 적합성이 다른 작은 단위에 어떤 영향을 미치는지 평가합니다. 단위 테스트는 한 명 이상의 개발자가 수동으로 수행하거나 자동화된 소프트웨어 솔루션을 통해 수행할 수 있습니다.
테스트하는 동안 각 장치는 기본 프로그램 또는 인터페이스에서 격리됩니다. 단위 테스트는 일반적으로 개발 후 및 배포 전에 수행되므로 통합 및 조기 문제 감지가 용이합니다. 단위의 크기 또는 범위는 프로그래밍 언어, 소프트웨어 애플리케이션 및 테스트 목표에 따라 다릅니다.
기능 테스트는 소프트웨어가 모든 요구 사항을 준수하는지 확인하기 위해 소프트웨어를 테스트하는 소프트웨어 개발 내에서 사용되는 테스트 프로세스입니다. 기능 요구 사항에 지정된 모든 필수 기능이 있는지 확인하기 위해 소프트웨어를 검사하는 방법입니다.
기능 테스트는 주로 소프트웨어가 최종 사용자 또는 비즈니스에서 요구하는 것과 동일한 출력을 제공하는지 확인하는 데 사용됩니다. 일반적으로 기능 테스트에는 비즈니스 요구 사항에 대해 각 소프트웨어 기능을 평가하고 비교하는 작업이 포함됩니다. 소프트웨어는 관련 입력을 제공하여 테스트되므로 출력이 기본 요구 사항을 준수하거나 관련되거나 달라지는 방식을 확인하기 위해 평가할 수 있습니다. 또한 기능 테스트는 예를 들어 내비게이션 기능이 필요에 따라 작동하는지 확인하는 등 소프트웨어의 유용성을 확인합니다.
회귀 테스트는 새로운 문제가 소프트웨어 변경의 결과인지 확인하는 데 사용되는 소프트웨어 테스트 유형입니다.
변경 사항을 적용하기 전에 프로그램을 테스트합니다. 변경 사항이 적용된 후 프로그램은 선택된 영역에서 다시 테스트되어 변경 사항으로 인해 새로운 버그나 문제가 발생했는지 또는 실제 변경 사항이 의도한 목적을 달성했는지 여부를 감지합니다.
문제의 한 부분을 변경하면 응용 프로그램의 다른 부분에 새로운 문제가 발생하는지 여부를 알기가 어려운 경우가 많기 때문에 회귀 테스트는 대규모 소프트웨어 응용 프로그램에 필수적입니다. 예를 들어, 은행 신청 대출 양식을 변경하면 월별 거래 보고서가 실패할 수 있습니다. 대부분의 경우 문제는 관련이 없는 것처럼 보일 수 있지만 실제로는 응용 프로그램 개발자 사이에서 좌절의 원인이 될 수 있습니다.
회귀 테스트가 필요한 다른 상황에는 특정 변경 사항이 설정된 목표를 달성하는지 여부를 감지하거나 문제가 없는 기간 후에 다시 나타나는 문제와 관련된 새로운 위험 요소에 대한 테스트가 포함됩니다.
최신 회귀 테스트는 주로 기존 소프트웨어의 스냅샷을 찍은 다음 특정 변경 사항을 적용한 후 비교되는 특수 상용 테스트 도구를 통해 처리됩니다. 인간 테스터가 자동화된 소프트웨어 테스터만큼 효율적으로 동일한 작업을 수행하는 것은 거의 불가능합니다. 은행, 병원, 제조 회사 및 대형 소매업체와 같은 대규모 IT 환경 내의 크고 복잡한 소프트웨어 응용 프로그램의 경우 특히 그렇습니다.
스트레스 테스트는 과도한 네트워크 트래픽, 프로세스 로드, 언더클럭킹, 오버클럭킹 및 최대 리소스 사용량 요구의 결과로 발생할 수 있는 극단적이고 불리한 조건에서 성능이 만족스러운지 확인하기 위해 소프트웨어 또는 하드웨어를 테스트하는 것을 말합니다.
대부분의 시스템은 정상적인 작동 조건을 가정하여 개발됩니다. 따라서 한도를 초과하더라도 개발 중에 시스템이 스트레스 테스트를 받으면 오류는 무시할 수 있습니다.
스트레스 테스트는 다음 상황에서 사용됩니다.
자동 테스트(소프트웨어 테스트 자동화)는 테스트를 자동으로 실행한 다음 실제 테스트 결과를 예상 결과와 비교하는 특수 소프트웨어 도구를 사용하는 코드 테스트 접근 방식입니다.
자동화된 테스트는 CD(Continuous Delivery), CI(Continuous Integration), DevOps 및 DevSecOps에서 중요한 역할을 합니다. 자동 테스트의 주요 이점은 다음과 같습니다.
소프트웨어 개발에서 빌드 프로세스 중에 자동화된 테스트를 수행하여 응용 프로그램에 빌드 오류가 없고 의도한 기능을 수행하는지 확인하는 것이 특히 유용합니다.
소프트웨어 테스트를 자동화하는 데 시간을 할애하면 코드 변경으로 인해 기존 기능이 손상될 위험이 줄어들어 궁극적으로 개발자의 시간이 절약됩니다.
테스트는 개발 프로세스에서 매우 중요한 단계입니다. 모든 버그가 수정되고 제품, 소프트웨어 또는 하드웨어가 의도한 대로 또는 목표 성능에 최대한 가깝게 작동하는지 확인합니다. 결함을 최소화하면서 적시에 사용자 요구를 충족하는 비용 효율적인 소프트웨어를 지속적으로 제공하려면 수동 테스트가 아닌 자동 테스트가 필수적입니다.
수동 테스트는 여전히 개발 중에 여러 번 수행되지만 이는 대부분 개발자 또는 하드웨어 엔지니어가 수행한 변경 사항이 원하는 효과를 냈는지 신속하게 확인하기 위해 수행됩니다.
Ercole Palmeri
색칠을 통해 소근육 운동 능력을 키우면 아이들이 글쓰기와 같은 보다 복잡한 기술을 준비할 수 있습니다. 색칠하다…
지난 월요일, Financial Times는 OpenAI와의 계약을 발표했습니다. FT는 세계적 수준의 저널리즘에 라이선스를 부여합니다…
수백만 명의 사람들이 스트리밍 서비스 비용을 지불하고 월간 구독료를 지불합니다. 당신은…
