많은 유형의 소프트웨어 테스트 방법

소프트웨어가 공개되기 전에 프로그래머는 모든 작은 버그를 해결하기 위해 수 시간을 소비합니다. 제품이 모든 이해 관계자를 만족시킬 때까지는 상업적 용도로 사용할 수 없습니다.

Google과 같은 거대 소프트웨어 회사는 환자 투자자와 충성도가 높은 사용자가있어 소프트웨어의 우선 순위가 낮은 버그에도 불구하고 성공합니다. 그러나 소규모 기업과 벤처 기업은 그 사치를 누리지 못합니다. 고객은 제품이 판매 페이지 또는 문서에서 주장하는 바를 수행 할 것으로 기대합니다. 밖에 많은 옵션이있어, 제품이 시간과 돈을 낭비한다면 배를 뛰어 넘는 것에 대해 두 번 생각하지 않을 것입니다. 따라서 소프트웨어는 다음과 같은 목적으로 출시되기 전에 엄격한 테스트를 거칩니다.

• 원래 개념과 최종 출력 간의 차이점 강조
• 디자이너의 계획대로 소프트웨어 작동 확인
• 최종 제품이 고객 요구 사항을 충족하는지 확인합니다.
• 기능 및 품질 평가

테스트는 엄격한 청사진에 따라 직원의 기술, 시간 및 비용을 최적화하는 동시에 이해 관계자에게 제품을 앞으로 나아갈 필수 정보를 제공합니다. 목표는 강력한 품질 보증 프로그램을 통해 우수한 최종 사용자 경험을 촉진하는 것입니다.지분이 너무 많기 때문에 품질 보증 관리자는 기술 업계에서 가장 많은 수입원입니다. 테스트는 대개 다음 단계를 따릅니다.

1. 관리자가 적절한 테스트 전략을 수립 할 계획을 세운 요구 분석.
2. 테스트가 시작되고 결과가 분석됩니다.
3. 결함은 수정되고 소프트웨어는 회귀 테스트를 거치게됩니다. 시스템은 수정 후에도 프로그램이 계속 작동하는지 확인합니다.
4. 테스트 종료 보고서는 전체 프로세스와 결과를 자세히 설명합니다.

BCS, Chartered Institute for IT, ISTQB® (International Software Testing Qualifications Board) 및 ASQ (이전의 미국 품질 협회)와 같은 조직을 통해 인증 된 소프트웨어 테스터가 될 수 있습니다.

소프트웨어 테스트 방법

블랙 박스 및 화이트 박스 테스트는 제품 동작 및 성능을 판단하는 두 가지 기본 방법이지만 다른 방법도 있습니다.

• 블랙 박스 테스트: 기능적 또는 사양 기반 테스트라고도하는이 메서드는 출력에 중점을 둡니다. 테스터는 내부 메커니즘에 관심이 없습니다. 그들은 단지 소프트웨어가해야 할 일을하는지 확인합니다. 코딩에 대한 지식은 필요하지 않으며 테스터는 사용자 인터페이스 수준에서 작동합니다.
• 화이트 박스 테스트: 이 방법은 테스트 절차의 일부로 코딩 노하우를 사용합니다. 제품에 오류가 발생하면 테스터는 원인을 파악하는 데 필요한만큼 코드 깊숙이 들어가게됩니다. 소프트웨어 개발자는 제품 작동 방식을 결정할 때이 작업을 직접 수행합니다. 구조 기반 및 유리 상자 테스트는이 방법의 다른 이름입니다.

• 정적 테스트: 테스터는 소프트웨어의 코드와 문서를 검사하지만 프로그램을 실행하지 않습니다. 정적 테스트는 검증 프로세스 중에 제품 개발 초기에 시작됩니다.
• 동적 테스트: 소프트웨어는 다양한 입력으로 실행되며 테스터는 예상되는 동작과 출력을이 방법과 비교합니다.
• 그래픽 사용자 인터페이스 테스트: 텍스트 서식, 텍스트 상자, 단추, 목록, 레이아웃, 색, 글꼴, 글꼴 크기 등과 같은 GUI 특성을 테스트합니다. GUI 테스트는 시간이 많이 걸리고 타사 회사는 개발자가 아닌 작업을 맡는 경우가 많습니다.

테스트 레벨

소프트웨어 개발 수명주기의 각 단계에서 취약성과 겹침 영역을 식별하기 위해 여러 수준의 테스트가 사용됩니다.

• 단위 테스트: 개발자는 클래스, 인터페이스 및 함수 / 프로 시저와 같은 코드의 가장 기본적인 부분을 테스트합니다. 그들은 코드가 응답해야하는 방법을 알고 출력에 따라 조정할 수 있습니다.
• 구성 요소 테스트: 다른 이름은 모듈 또는 프로그램 테스트입니다. 단위 테스트와 유사하지만 더 높은 수준의 통합을 포함합니다. 소프트웨어의 모듈은 개별 기능을 검증하기 위해 결함에 대해 테스트됩니다.
• 통합 테스트: 모듈 통합시 오류를 식별합니다. 다양한 통합 테스트는 상향식, 하향식 및 기능적 증분 테스트입니다.

• 시스템 테스트: 이 방법을 사용하면 프로젝트의 구성 요소가 다른 환경에서 전체적으로 테스트됩니다. 그것은 블랙 박스 방법에 속하며 그 과정에서 최종 테스트 중 하나입니다. 시스템이 업무 및 사용자 요구를 충족시켜야하는지 여부를 결정합니다.
• 알파 테스트: 내부 직원은 시뮬레이트 된 또는 실제 환경에서 개발자 사이트의 소프트웨어를 테스트합니다. 그 후에 개발자는 버그 및 기타 문제를 수정합니다.
• 베타 테스트: 필드 테스트라고도하는 클라이언트는 실제 상황에서 자신의 사이트에서 제품을 테스트합니다. 고객은 시험판 또는 베타 버전을 통해 최종 사용자 그룹에게 소프트웨어를 테스트 할 기회를 제공 할 수 있습니다. 가능한 개선 사항에 대한 피드백이 개발자에게 전송됩니다.

• 수락 테스트: 또한 블랙 박스 테스트의 범위에서 클라이언트는 소프트웨어가 개발자가 원하는 사양으로 프로그램을 만들었는지 확인하기 위해 소프트웨어를 테스트합니다.

시험 유형

다양한 종류의 소프트웨어 테스트는 특정 목적에 중점을 두도록 고안되었습니다.

• 설치 테스트: 소프트웨어 테스트 엔지니어와 구성 관리자는 최종 사용자가 프로그램을 설치하고 실행할 수 있는지 확인하기 위해이 테스트를 수행합니다. 설치 파일, 설치 위치 및 관리 권한과 같은 영역을 포함합니다.
• 개발 테스트: 이것은 결함을 감지하고 방지하기위한 동기화 된 전략의 범위를 구현합니다. 여기에는 정적 코드 분석, 피어 코드 검토, 추적 가능성 및 메트릭 분석이 포함됩니다. 목표는 위험을 줄이고 비용을 절감하는 것입니다.
• 사용성 테스트: 이 테스트에서는 사용자 경험이 주목을 받고 있습니다. GUI가 얼마나 잘 디자인되고 사용이 용이한지 측정합니다. 이 테스트는 기능의 정확성과 효율성 및 테스트 대상자의 감정적 반응을 검사합니다.

• 온전한 테스트: 이것은 소프트웨어가 추가 테스트를 계속하기에 충분한 시간과 비용이 필요한지 여부를 나타냅니다. 결함이 너무 많으면 더 공격적인 테스트가 수행되지 않습니다.
• 연기 테스트: 연기 테스트는 방출을 방지하기에 충분히 심각한 기본 실패를 나타냅니다. 이 작업을 새 빌드에서 수행 할 때 빌드 확인 테스트라고합니다.
• 회귀 테스트: 시스템이 수정 될 때 회귀 테스트는 예기치 않은 동작을 모니터링합니다. 모듈 또는 구성 요소에 대한 부작용을 지적합니다.
• 파괴적인 테스트: 테스터는 비정상적인 입력을 입력하고 예기치 않은 입력을 관리하는 소프트웨어의 기능을 식별합니다. 이것은 프로그램이 오류 관리에 얼마나 강건한 지 개발자에게 보여줍니다.
• 복구 테스트: 하드웨어 또는 다른 기능이 실패하면이 테스트는 소프트웨어가 얼마나 잘 복구되고 작동 하는지를 보여줍니다.
• 자동 테스트: 이는 수동으로 구현하기 어려운 기능을 수행합니다. 이 도구는 특정 소프트웨어를 사용하여 테스트를 실행하고 실제 결과 대 예상 결과에 대한 데이터를 제공합니다.
• 호환성 테스트: 소프트웨어는 다른 컴퓨팅 환경에서 실행되어야하므로 다른 시스템과의 호환성을 검사합니다. 예를 들어 소프트웨어가 다양한 운영 체제 및 웹 브라우저에서 작동합니까?
• 성능 시험: 이 시나리오는 여러 시나리오에서 소프트웨어 성능을 검사하는 심층적 인 테스트입니다. 응답 성, 안정성, 자원 할당 및 속도에 대한 정보가 수집됩니다. 또한 볼륨, 용량 및 스파이크 테스트와 같은 하위 테스트가이 프로세스에 포함됩니다.
• 보안 테스트: 이것은 사용자의 보안을 보호하는 소프트웨어 기능을 측정합니다. 이는 인증 기능, 인증, 기밀성, 무결성, 가용성 및 부인 방지를 의미합니다.
• 접근성 테스트: 이는 사용성 테스트와 동일하지 않습니다. 이것은 학습 및 신체 장애가 포함 된 다른 사용자가 소프트웨어를 사용할 수있는 정도를 결정합니다.
• 국제화 및 현지화 테스트: 결과는 소프트웨어가 다양한 언어와 지역 수요에 어떻게 적응할 수 있는지 보여줍니다. 여기에는 특정 위치에 대한 구성 요소 추가 및 텍스트 번역이 포함됩니다.