소프트웨어 테스팅-레벨

테스트 과정에는 다양한 수준이 있습니다. 이 장에서는 이러한 수준에 대한 간략한 설명이 제공됩니다.

테스트 수준에는 소프트웨어 테스트를 수행하는 동안 사용할 수있는 다양한 방법이 포함됩니다. 소프트웨어 테스트의 주요 수준은 다음과 같습니다.

기능 테스트
비 기능 테스트

기능 테스트

이것은 테스트 할 소프트웨어의 사양을 기반으로하는 블랙 박스 테스트 유형입니다. 입력을 제공하여 애플리케이션을 테스트 한 다음 의도 한 기능을 준수해야하는 결과를 검사합니다. 소프트웨어의 기능 테스트는 시스템이 지정된 요구 사항을 준수하는지 평가하기 위해 완전한 통합 시스템에서 수행됩니다.

응용 프로그램의 기능을 테스트하는 동안 관련된 다섯 단계가 있습니다.

단계	기술
나는	의도 된 응용 프로그램이 수행 할 기능을 결정합니다.
II	애플리케이션 사양에 따라 테스트 데이터를 생성합니다.
III	테스트 데이터 및 애플리케이션 사양을 기반으로 한 출력입니다.
IV	테스트 시나리오 작성 및 테스트 케이스 실행.
V	실행 된 테스트 케이스를 기반으로 실제 결과와 예상 결과를 비교합니다.

효과적인 테스트 관행은 모든 조직의 테스트 정책에 적용된 위의 단계를 볼 수 있으므로 조직이 소프트웨어 품질과 관련하여 가장 엄격한 표준을 유지하는지 확인합니다.

단위 테스트

이러한 유형의 테스트는 테스트 케이스를 공식적으로 실행하기 위해 테스트 팀에 설정이 전달되기 전에 개발자가 수행합니다. 단위 테스트는 각 개발자가 소스 코드 할당 영역의 개별 단위에 대해 수행합니다. 개발자는 품질 보증 팀의 테스트 데이터와 다른 테스트 데이터를 사용합니다.

단위 테스트의 목표는 프로그램의 각 부분을 분리하고 개별 부분이 요구 사항 및 기능 측면에서 올바른지 보여주는 것입니다.

단위 테스트의 한계

테스트는 애플리케이션의 모든 버그를 포착 할 수 없습니다. 모든 소프트웨어 응용 프로그램에서 모든 실행 경로를 평가하는 것은 불가능합니다. 단위 테스트의 경우도 마찬가지입니다.

개발자가 소스 코드를 확인하는 데 사용할 수있는 시나리오 및 테스트 데이터의 수에는 제한이 있습니다. 모든 옵션을 다 사용한 후에는 단위 테스트를 중지하고 코드 세그먼트를 다른 단위와 병합 할 수밖에 없습니다.

통합 테스트

통합 테스트는 제대로 작동하는지 확인하기 위해 응용 프로그램의 결합 된 부분을 테스트하는 것으로 정의됩니다. 통합 테스트는 상향식 통합 테스트와 하향식 통합 테스트의 두 가지 방법으로 수행 할 수 있습니다.

Sr. 아니.	통합 테스트 방법
1	Bottom-up integration 이 테스트는 단위 테스트로 시작하여 모듈 또는 빌드라고하는 점진적으로 더 높은 수준의 단위 조합 테스트가 이어집니다.
2	Top-down integration 이 테스트에서는 가장 높은 수준의 모듈이 먼저 테스트되고 점진적으로 더 낮은 수준의 모듈이 이후에 테스트됩니다.

포괄적 인 소프트웨어 개발 환경에서는 일반적으로 상향식 테스트를 먼저 수행 한 다음 하향식 테스트를 수행합니다. 이 프로세스는 실제 상황을 모방하도록 설계된 시나리오에서 전체 애플리케이션에 대한 여러 테스트로 마무리됩니다.

시스템 테스트

시스템 테스트는 시스템 전체를 테스트합니다. 모든 구성 요소가 통합되면 지정된 품질 표준을 충족하는지 확인하기 위해 애플리케이션 전체를 엄격하게 테스트합니다. 이러한 유형의 테스트는 전문 테스트 팀에서 수행합니다.

시스템 테스트는 다음과 같은 이유로 중요합니다.

시스템 테스트는 애플리케이션이 전체적으로 테스트되는 소프트웨어 개발 라이프 사이클의 첫 번째 단계입니다.
응용 프로그램은 기능 및 기술 사양을 충족하는지 확인하기 위해 철저히 테스트됩니다.
응용 프로그램은 응용 프로그램이 배포 될 프로덕션 환경과 매우 가까운 환경에서 테스트됩니다.
시스템 테스트를 통해 비즈니스 요구 사항과 애플리케이션 아키텍처를 모두 테스트, 확인 및 검증 할 수 있습니다.

회귀 테스트

소프트웨어 응용 프로그램이 변경 될 때마다 응용 프로그램 내의 다른 영역이이 변경의 영향을 받았을 가능성이 높습니다. 회귀 테스트는 수정 된 버그로 인해 다른 기능이나 비즈니스 규칙 위반이 발생하지 않았는지 확인하기 위해 수행됩니다. 회귀 테스트의 목적은 버그 수정과 같은 변경으로 인해 애플리케이션에서 다른 오류가 발견되지 않도록하는 것입니다.

회귀 테스트는 다음과 같은 이유로 중요합니다.

변경된 애플리케이션을 테스트해야 할 때 테스트의 간격을 최소화합니다.
새로운 변경 사항을 테스트하여 변경 사항이 응용 프로그램의 다른 영역에 영향을주지 않았는지 확인합니다.
애플리케이션에서 회귀 테스트를 수행 할 때 위험을 완화합니다.
타임 라인을 훼손하지 않고 테스트 범위가 증가합니다.
제품 마케팅 속도를 높입니다.

수락 테스트

이것은 응용 프로그램이 의도 한 사양을 충족하고 고객의 요구 사항을 충족하는지 여부를 측정하는 품질 보증 팀에서 수행하므로 가장 중요한 유형의 테스트입니다. QA 팀은 애플리케이션을 테스트하는 데 사용되는 사전 작성된 시나리오 및 테스트 케이스 세트를 갖게됩니다.

응용 프로그램에 대한 더 많은 아이디어가 공유되고 그 정확도와 프로젝트가 시작된 이유를 측정하기 위해 더 많은 테스트를 수행 할 수 있습니다. 수락 테스트는 단순한 철자 오류, 외관상의 오류 또는 인터페이스 차이를 지적 할뿐만 아니라 시스템 충돌 또는 애플리케이션의 주요 오류를 유발하는 애플리케이션의 버그를 지적하기위한 것입니다.

애플리케이션에 대한 승인 테스트를 수행함으로써 테스트 팀은 애플리케이션이 프로덕션에서 수행되는 방식을 줄입니다. 시스템 수락을위한 법적 및 계약 적 요구 사항도 있습니다.

알파 테스트

이 테스트는 테스트의 첫 번째 단계이며 팀 (개발자 및 QA 팀)간에 수행됩니다. 함께 결합 된 단위 테스트, 통합 테스트 및 시스템 테스트를 알파 테스트라고합니다. 이 단계에서 애플리케이션에서 다음과 같은 측면이 테스트됩니다.

맞춤법 오류
끊어진 링크
흐린 방향
애플리케이션은로드 시간과 지연 문제를 테스트하기 위해 사양이 가장 낮은 컴퓨터에서 테스트됩니다.

베타 테스트

이 테스트는 알파 테스트가 성공적으로 수행 된 후에 수행됩니다. 베타 테스트에서는 의도 된 대상의 샘플이 애플리케이션을 테스트합니다. 베타 테스트는pre-release testing. 소프트웨어의 베타 테스트 버전은 부분적으로는 프로그램에 "실제"테스트를 제공하고 부분적으로는 다음 릴리스의 미리보기를 제공하기 위해 웹의 광범위한 청중에게 이상적으로 배포됩니다. 이 단계에서 청중은 다음을 테스트합니다.

사용자는 응용 프로그램을 설치하고 실행하고 프로젝트 팀에 피드백을 보냅니다.
오타, 혼란스러운 응용 프로그램 흐름, 심지어 충돌까지 발생합니다.
피드백을 받으면 프로젝트 팀은 실제 사용자에게 소프트웨어를 출시하기 전에 문제를 해결할 수 있습니다.
실제 사용자 문제를 해결하기 위해 수정하는 문제가 많을수록 애플리케이션의 품질이 높아집니다.
일반 대중에게 출시 할 때 더 높은 품질의 애플리케이션을 보유하면 고객 만족도가 높아집니다.

비 기능 테스트

이 섹션은 비 기능적 속성에서 애플리케이션 테스트를 기반으로합니다. 비 기능적 테스트에는 본질적으로 작동하지 않지만 성능, 보안, 사용자 인터페이스 등과 같이 중요한 요구 사항에서 소프트웨어를 테스트하는 것이 포함됩니다.

중요하고 일반적으로 사용되는 비 기능 테스트 유형 중 일부는 아래에서 설명합니다.

성능 시험

주로 소프트웨어에서 버그를 찾는 것보다 병목 현상이나 성능 문제를 식별하는 데 사용됩니다. 소프트웨어 성능 저하에 기여하는 여러 원인이 있습니다.

네트워크 지연
클라이언트 측 처리
데이터베이스 트랜잭션 처리
서버 간 부하 분산
데이터 렌더링

성능 테스트는 다음 측면에서 중요하고 필수 테스트 유형 중 하나로 간주됩니다.

속도 (예 : 응답 시간, 데이터 렌더링 및 액세스)
Capacity
Stability
Scalability

성능 테스트는 정 성적 또는 정량적 일 수 있으며 다음과 같은 여러 하위 유형으로 나눌 수 있습니다. Load testing 과 Stress testing.

부하 테스트

큰 입력 데이터에 액세스하고 조작하는 소프트웨어 측면에서 최대 부하를 적용하여 소프트웨어의 동작을 테스트하는 프로세스입니다. 정상 및 최대 부하 조건에서 모두 수행 할 수 있습니다. 이 유형의 테스트는 소프트웨어의 최대 용량과 사용량이 많을 때의 동작을 식별합니다.

대부분의 경우 Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test 등과 같은 자동화 된 도구를 사용하여로드 테스트를 수행합니다.

가상 사용자 (VUsers)는 자동화 된 테스트 도구에 정의되고 스크립트가 실행되어 소프트웨어의 부하 테스트를 확인합니다. 사용자 수는 요구 사항에 따라 동시에 또는 점진적으로 늘리거나 줄일 수 있습니다.

스트레스 테스트

스트레스 테스트에는 비정상적인 조건에서 소프트웨어의 동작을 테스트하는 것이 포함됩니다. 예를 들어 일부 리소스를 제거하거나 실제 부하 제한을 초과하는 부하를 적용하는 것이 포함될 수 있습니다.

스트레스 테스트의 목적은 시스템에 부하를 적용하고 중단 점을 식별하기 위해 소프트웨어에서 사용하는 리소스를 인수하여 소프트웨어를 테스트하는 것입니다. 이 테스트는 다음과 같은 다양한 시나리오를 테스트하여 수행 할 수 있습니다.

네트워크 포트를 임의로 종료 또는 다시 시작
데이터베이스 켜기 또는 끄기
CPU, 메모리, 서버 등과 같은 리소스를 소비하는 다양한 프로세스 실행

사용성 테스트

사용성 테스트는 블랙 박스 기술이며 사용 및 운영을 통해 사용자를 관찰하여 소프트웨어의 오류 및 개선 사항을 식별하는 데 사용됩니다.

Nielsen에 따르면 사용성은 사용 효율성, 학습 가능성, 기억력, 오류 / 안전성, 만족도의 5 가지 요소로 정의 할 수 있습니다. 그에 따르면 제품의 사용성이 좋을 것이고 위의 요소를 가지고 있다면 시스템을 사용할 수있을 것이라고한다.

Nigel Bevan과 Macleod는 사용성이 컴퓨터 시스템과의 상호 작용의 결과로 측정 할 수있는 품질 요구 사항이라고 생각했습니다. 이 요구 사항은 충족 될 수 있으며 최종 사용자는 적절한 리소스를 사용하여 의도 한 목표를 효과적으로 달성하면 만족할 것입니다.

2000 년 Molich는 사용자 친화적 인 시스템은 배우기 쉽고 기억하기 쉽고 사용하기 쉽고 사용하기 만족스럽고 이해하기 쉬운 다섯 가지 목표를 충족해야한다고 말했습니다.

사용성에 대한 다양한 정의 외에도 ISO-9126, ISO-9241-11, ISO-13407 및 IEEE std와 같은 속성 및 하위 속성의 형태로 사용성을 정의하는 몇 가지 표준 및 품질 모델과 방법이 있습니다. 610.12 등

UI 대 사용성 테스트

UI 테스트에는 소프트웨어의 그래픽 사용자 인터페이스 테스트가 포함됩니다. UI 테스트는 GUI가 요구 사항에 따라 작동하는지 확인하고 색상, 정렬, 크기 및 기타 속성 측면에서 테스트됩니다.

반면 사용성 테스트는 쉽게 처리 할 수있는 우수하고 사용자 친화적 인 GUI를 보장합니다. UI 테스트는 사용성 테스트의 하위 부분으로 간주 될 수 있습니다.

보안 테스트

보안 테스트에는 보안 및 취약성 관점에서 결함과 차이를 식별하기 위해 소프트웨어 테스트가 포함됩니다. 다음은 보안 테스트가 보장해야하는 주요 측면입니다.

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
소프트웨어는 알려 지거나 알려지지 않은 취약점으로부터 안전합니다.
소프트웨어 데이터는 안전합니다.
소프트웨어는 모든 보안 규정을 따릅니다.
입력 확인 및 유효성 검사
SQL 삽입 공격
주입 결함
세션 관리 문제
교차 사이트 스크립팅 공격
버퍼 오버 플로우 취약점
디렉터리 탐색 공격

이식성 테스트

이식성 테스트에는 재사용 가능성을 확인하고 다른 소프트웨어에서도 이동할 수있는 소프트웨어 테스트가 포함됩니다. 다음은 이식성 테스트에 사용할 수있는 전략입니다.

한 컴퓨터에서 다른 컴퓨터로 설치된 소프트웨어 전송.
다른 플랫폼에서 소프트웨어를 실행하기위한 실행 파일 (.exe) 빌드.

이식성 테스트는 시스템 테스트의 하위 부분 중 하나로 간주 될 수 있습니다.이 테스트 유형에는 다양한 환경에서의 사용과 관련하여 소프트웨어의 전체 테스트가 포함되기 때문입니다. 컴퓨터 하드웨어, 운영 체제 및 브라우저는 이식성 테스트의 주요 초점입니다. 이식성 테스트를위한 일부 전제 조건은 다음과 같습니다.

소프트웨어는 이식성 요구 사항을 염두에두고 설계 및 코딩되어야합니다.
관련 구성 요소에 대해 단위 테스트가 수행되었습니다.
통합 테스트가 수행되었습니다.
테스트 환경이 설정되었습니다.