소프트웨어 테스팅 개요

소프트웨어 테스팅은 사용자 및 시스템 사양에서 수집 한 요구 사항에 대해 소프트웨어를 평가하는 것입니다. 테스트는 소프트웨어 개발 수명주기의 단계 수준 또는 프로그램 코드의 모듈 수준에서 수행됩니다. 소프트웨어 테스트는 검증 및 검증으로 구성됩니다.

소프트웨어 검증

유효성 검사는 소프트웨어가 사용자 요구 사항을 충족하는지 여부를 검사하는 프로세스입니다. SDLC가 끝날 때 수행됩니다. 소프트웨어가 만들어진 요구 사항과 일치하면 유효성이 검사됩니다.

검증을 통해 개발중인 제품이 사용자 요구 사항에 맞는지 확인합니다.
검증은 "이 소프트웨어에서 사용자가 필요로하는 모든 것을 시도하는 제품을 개발하고 있습니까?"라는 질문에 답합니다.
유효성 검사는 사용자 요구 사항을 강조합니다.

소프트웨어 검증

검증은 소프트웨어가 비즈니스 요구 사항을 충족하는지 확인하는 프로세스이며 적절한 사양 및 방법론에 따라 개발됩니다.

검증은 개발중인 제품이 설계 사양에 맞는지 확인합니다.
검증은 "모든 설계 사양을 굳게 준수하여이 제품을 개발하고 있습니까?"라는 질문에 답합니다.
검증은 설계 및 시스템 사양에 중점을 둡니다.

테스트 대상은-

Errors-개발자가 저지른 실제 코딩 실수입니다. 또한 소프트웨어의 출력과 원하는 출력의 차이가있어 오류로 간주합니다.
Fault-오류가있는 경우 오류가 발생합니다. 버그라고도하는 결함은 시스템 실패를 유발할 수있는 오류의 결과입니다.
Failure -실패는 시스템이 원하는 작업을 수행 할 수 없음을 말합니다. 시스템에 오류가 있으면 오류가 발생합니다.

수동 대 자동 테스트

테스트는 수동으로 수행하거나 자동화 된 테스트 도구를 사용하여 수행 할 수 있습니다.

Manual-이 테스트는 자동화 된 테스트 도구의 도움없이 수행됩니다. 소프트웨어 테스터는 코드의 여러 섹션 및 레벨에 대한 테스트 케이스를 준비하고 테스트를 실행하고 결과를 관리자에게보고합니다.

수동 테스트에는 시간과 리소스가 많이 소모됩니다. 테스터는 올바른 테스트 케이스가 사용되는지 여부를 확인해야합니다. 테스트의 주요 부분에는 수동 테스트가 포함됩니다.
Automated이 테스트는 자동화 된 테스트 도구를 사용하여 수행되는 테스트 절차입니다. 수동 테스트의 한계는 자동화 된 테스트 도구를 사용하여 극복 할 수 있습니다.

테스트는 Internet Explorer에서 웹 페이지를 열 수 있는지 확인해야합니다. 이것은 수동 테스트로 쉽게 수행 할 수 있습니다. 그러나 웹 서버가 100 만명의 사용자 부하를 감당할 수 있는지 확인하기 위해 수동으로 테스트하는 것은 매우 불가능합니다.

테스터가 부하 테스트, 스트레스 테스트, 회귀 테스트를 수행하는 데 도움이되는 소프트웨어 및 하드웨어 도구가 있습니다.

접근 방식 테스트

테스트는 두 가지 접근 방식을 기반으로 수행 할 수 있습니다.

기능 테스트
구현 테스트

실제 구현을 고려하지 않고 기능을 테스트하는 경우이를 블랙 박스 테스트라고합니다. 다른 측면은 기능을 테스트 할뿐만 아니라 구현 방식도 분석하는 화이트 박스 테스트로 알려져 있습니다.

철저한 테스트는 완벽한 테스트를 위해 가장 바람직한 방법입니다. 입력 및 출력 값 범위에서 가능한 모든 값이 테스트됩니다. 값의 범위가 큰 경우 실제 시나리오에서 모든 값을 테스트 할 수 없습니다.

블랙 박스 테스트

프로그램의 기능을 테스트하기 위해 수행됩니다. '행동'테스트라고도합니다. 이 경우 테스터는 일련의 입력 값과 각각의 원하는 결과를 가지고 있습니다. 입력을 제공 할 때 출력이 원하는 결과와 일치하면 프로그램이 '정상'테스트되고 그렇지 않으면 문제가 있습니다.

이 테스트 방법에서 코드의 디자인과 구조는 테스터에게 알려지지 않으며 테스트 엔지니어와 최종 사용자는 소프트웨어에서이 테스트를 수행합니다.

블랙 박스 테스트 기술 :

Equivalence class-입력은 유사한 클래스로 나뉩니다. 클래스의 한 요소가 테스트를 통과하면 모든 클래스가 통과 된 것으로 간주됩니다.
Boundary values-입력은 상하 한 값으로 나뉩니다. 이 값이 테스트를 통과하면 그 사이의 모든 값도 통과 할 수 있다고 가정합니다.
Cause-effect graphing-이전 두 방법 모두 한 번에 하나의 입력 값만 테스트합니다. 원인 (입력) – 효과 (출력)는 입력 값의 조합을 체계적으로 테스트하는 테스트 기술입니다.
Pair-wise Testing-소프트웨어의 동작은 여러 매개 변수에 따라 다릅니다. 쌍별 테스트에서 여러 매개 변수는 서로 다른 값에 대해 쌍별로 테스트됩니다.
State-based testing-시스템은 입력 제공시 상태를 변경합니다. 이러한 시스템은 상태 및 입력에 따라 테스트됩니다.

화이트 박스 테스트

코드 효율성이나 구조를 개선하기 위해 프로그램 및 구현을 테스트하기 위해 수행됩니다. '구조적'테스트라고도합니다.

이 테스트 방법에서는 코드의 디자인과 구조가 테스터에게 알려져 있습니다. 코드 프로그래머는 코드에서이 테스트를 수행합니다.

다음은 몇 가지 화이트 박스 테스트 기술입니다.

Control-flow testing-제어 흐름 테스트의 목적은 모든 문과 분기 조건을 포함하는 테스트 케이스를 설정합니다. 분기 조건은 참과 거짓 모두에 대해 테스트되므로 모든 진술을 다룰 수 있습니다.
Data-flow testing-이 테스트 기술은 프로그램에 포함 된 모든 데이터 변수를 포함하도록 강조합니다. 변수가 선언되고 정의 된 위치와 사용 또는 변경된 위치를 테스트합니다.

테스트 수준

테스트 자체는 다양한 수준의 SDLC에서 정의 될 수 있습니다. 테스트 프로세스는 소프트웨어 개발과 동시에 실행됩니다. 다음 단계로 넘어 가기 전에 단계를 테스트, 검증 및 확인합니다.

소프트웨어에 숨겨진 버그 나 문제가 없는지 확인하기 위해 별도로 테스트가 수행됩니다. 소프트웨어는 다양한 수준에서 테스트됩니다.

단위 테스트

코딩하는 동안 프로그래머는 해당 프로그램 단위에 대해 몇 가지 테스트를 수행하여 오류가 없는지 확인합니다. 테스트는 화이트 박스 테스트 방식으로 수행됩니다. 단위 테스트는 개발자가 프로그램의 개별 단위가 요구 사항에 따라 작동하고 오류가 없는지 결정하는 데 도움이됩니다.

통합 테스트

소프트웨어 단위가 개별적으로 잘 작동하더라도 함께 통합하면 단위가 오류없이 작동하는지 확인할 필요가 있습니다. 예를 들어, 인수 전달 및 데이터 업데이트 등.

시스템 테스트

소프트웨어는 제품으로 컴파일 된 다음 전체적으로 테스트됩니다. 다음 테스트 중 하나 이상을 사용하여 수행 할 수 있습니다.

Functionality testing -요구 사항에 대해 소프트웨어의 모든 기능을 테스트합니다.
Performance testing-이 테스트는 소프트웨어의 효율성을 증명합니다. 소프트웨어가 원하는 작업을 수행하는 데 걸리는 효과와 평균 시간을 테스트합니다. 성능 테스트는 소프트웨어가 다양한 환경 조건에서 높은 사용자 및 데이터 부하를받는 부하 테스트 및 스트레스 테스트를 통해 수행됩니다.
Security & Portability -이러한 테스트는 소프트웨어가 다양한 플랫폼에서 작동하도록되어 있고 여러 사람이 액세스 할 때 수행됩니다.

수락 테스트

소프트웨어가 고객에게 전달 될 준비가되면 사용자 상호 작용 및 응답을 테스트하는 마지막 테스트 단계를 거쳐야합니다. 이는 소프트웨어가 모든 사용자 요구 사항과 일치하더라도 사용자가 표시되거나 작동하는 방식이 마음에 들지 않으면 거부 될 수 있기 때문에 중요합니다.

Alpha testing-개발자 팀이 작업 환경에서 사용하는 것처럼 시스템을 사용하여 알파 테스트를 직접 수행합니다. 그들은 사용자가 소프트웨어의 어떤 행동에 어떻게 반응하고 시스템이 입력에 어떻게 반응해야하는지 알아 내려고합니다.
Beta testing-소프트웨어는 내부적으로 테스트 한 후 사용자에게 전달하여 테스트 목적으로 만 프로덕션 환경에서 사용하도록합니다. 이것은 아직 배송 된 제품이 아닙니다. 개발자는이 단계의 사용자가 참석하지 못한 사소한 문제를 가져올 것으로 예상합니다.

회귀 테스트

소프트웨어 제품이 새로운 코드, 기능 또는 기능으로 업데이트 될 때마다 추가 된 코드의 부정적인 영향이 있는지 감지하기 위해 철저하게 테스트됩니다. 이를 회귀 테스트라고합니다.

테스트 문서

테스트 문서는 여러 단계에서 준비됩니다.

테스트하기 전에

테스트는 테스트 케이스 생성으로 시작됩니다. 참조를 위해 다음 문서가 필요합니다.

SRS document -기능 요구 사항 문서
Test Policy document -제품 출시 전 테스트를 얼마나 진행해야하는지 설명합니다.
Test Strategy document -테스트 팀, 책임 매트릭스 및 테스트 관리자 및 테스트 엔지니어의 권리 / 책임의 세부 사항을 언급합니다.
Traceability Matrix document-요구 사항 수집 프로세스와 관련된 SDLC 문서입니다. 새로운 요구 사항이 발생하면이 매트릭스에 추가됩니다. 이러한 매트릭스는 테스터가 요구 사항의 출처를 파악하는 데 도움이됩니다. 앞뒤로 추적 할 수 있습니다.

테스트 중

테스트가 시작되고 수행되는 동안 다음 문서가 필요할 수 있습니다.

Test Case document-이 문서에는 수행해야하는 테스트 목록이 포함되어 있습니다. 단위 테스트 계획, 통합 테스트 계획, 시스템 테스트 계획 및 수락 테스트 계획이 포함됩니다.
Test description -이 문서는 모든 테스트 케이스와이를 실행하기위한 절차에 대한 자세한 설명입니다.
Test case report -이 문서에는 테스트 결과로 테스트 케이스 보고서가 포함되어 있습니다.
Test logs -이 문서에는 모든 테스트 사례 보고서에 대한 테스트 로그가 포함되어 있습니다.

테스트 후

테스트 후 다음 문서가 생성 될 수 있습니다.

Test summary-이 테스트 요약은 모든 테스트 보고서 및 로그를 종합적으로 분석 한 것입니다. 소프트웨어를 시작할 준비가되었는지 요약하고 결론을 내립니다. 소프트웨어가 출시 될 준비가되면 버전 관리 시스템으로 출시됩니다.

테스트 대 품질 관리, 품질 보증 및 감사

소프트웨어 테스트는 소프트웨어 품질 보증, 소프트웨어 품질 관리 및 소프트웨어 감사와 다르다는 것을 이해해야합니다.

Software quality assurance-소프트웨어 개발 프로세스 모니터링 수단으로 조직의 기준에 따라 모든 조치를 취하고 있음을 보증합니다. 이 모니터링은 적절한 소프트웨어 개발 방법을 따랐는지 확인하기 위해 수행됩니다.
Software quality control-소프트웨어 제품의 품질을 유지하기위한 시스템입니다. 여기에는 조직의 영업권을 향상시키는 소프트웨어 제품의 기능적 및 비 기능적 측면이 포함될 수 있습니다. 이 시스템은 고객이 자신의 요구 사항에 맞는 고품질의 제품을 받고 있으며 '사용에 적합'하다고 인증 된 제품을 제공합니다.
Software audit-조직에서 소프트웨어를 개발하기 위해 사용한 절차에 대한 검토입니다. 개발 팀과는 독립적 인 감사 팀이 소프트웨어 프로세스, 절차, 요구 사항 및 SDLC의 기타 측면을 검사합니다. 소프트웨어 감사의 목적은 소프트웨어와 개발 프로세스가 모두 표준, 규칙 및 규정을 준수하는지 확인하는 것입니다.