Google과 같은 거대 소프트웨어 회사는 소프트웨어의 우선 순위가 낮은 버그에도 불구하고 성공하지만 중소 기업과 신생 기업에게는 그 사치가 없습니다.
고객은 제품이 판매 페이지 또는 문서에서 주장하는 바를 수행 할 것으로 기대합니다. 밖에 많은 옵션이 있기 때문에 시간과 돈을 낭비한다면 배를 뛰어 넘는 것에 대해 두 번 생각하지 않을 것입니다. 따라서 소프트웨어는 다음과 같은 목적으로 출시되기 전에 엄격한 테스트를 거칩니다.
원래 개념과 최종 출력 간의 차이점 강조
디자이너의 계획대로 소프트웨어 작동 확인
최종 제품 유효성 확인 - 제품이 고객 요구 사항을 충족해야 함
기능 및 품질 평가
테스트는 엄격한 청사진을 따릅니다. 기술, 시간 및 비용과 같은 중요한 자원의 사용을 최적화하는 동시에 이해 관계자에게 제품을 앞으로 나아갈 수있는 필수 정보를 제공합니다. 목표는 강력한 품질 보증 프로그램을 통해 우수한 최종 사용자 경험을 촉진하는 것입니다. 스테이크가 너무 높을 때, 품질 보증 관리자는 기술 분야에서 가장 많은 수입 을 올리고 있습니다. 테스트는 대개 다음 단계를 따릅니다.
관리자가 적절한 테스트 전략을 수립 할 계획을 세운 요구 분석.
테스트가 시작되고 결과가 분석됩니다.
결함은 수정되고 소프트웨어는 회귀 테스트를 거치게됩니다. 프로그램을 확인하는 시스템은 수정 후에도 작동합니다.
테스트 종료 보고서는 전체 프로세스와 결과를 자세히 설명합니다.
소프트웨어 테스트 방법
다음은 제품 동작 및 성능을 판단하는 데 사용되는 여러 가지 방법입니다.
블랙 박스와 화이트 박스 테스트는 두 가지 기본적인 방법입니다.
- 블랙 박스 테스트 - 기능적 또는 사양 기반 테스트라고도하는이 방법은 출력에 중점을 둡니다. 테스터는 내부 메커니즘에 관심이 없습니다. 그들은 단지 소프트웨어가 자신이 원하는 것을 수행하는지 확인합니다. 코딩에 대한 지식은 필요하지 않으며 테스터는 사용자 인터페이스 수준에서 작동합니다.
- 화이트 박스 테스트 -이 방법은 테스트 절차의 일부로 코딩 노하우를 사용합니다. 제품에 오류가 발생하면 테스터는 원인을 파악하는 데 필요한만큼 코드 깊숙이 들어가게됩니다. 소프트웨어 개발자는 제품 작동 방식을 결정할 때이 작업을 직접 수행합니다. 구조 기반 및 유리 상자 테스트는이 방법의 다른 이름입니다.
- 정적 테스트 - 테스터는 소프트웨어의 코드와 문서를 검사하지만 프로그램을 실행하지 않습니다. 정적 테스트는 검증 프로세스 중에 제품 개발 초기에 시작됩니다.
- 동적 테스트 - 소프트웨어는 다양한 입력으로 실행되며 테스터는 예상되는 동작과 출력을 비교합니다.
- GUI 테스트 - GUI 특성 (텍스트 형식, 텍스트 상자, 단추, 목록, 레이아웃, 색, 글꼴, 글꼴 크기 등)을 테스트합니다. GUI 테스트는 시간 소모적이며 타사 회사는 종종 개발자가 아닌 작업을 맡습니다.
테스트 레벨
이는 소프트웨어 개발 라이프 사이클의 각 단계에서 약점과 중첩 영역을 식별하는 데 필요합니다.
- 단위 테스트 - 개발자는 클래스, 인터페이스 및 함수 / 프로 시저와 같은 코드의 가장 기본적인 부분을 테스트합니다. 개발자는 코드가 응답해야하는 방법을 알고 출력에 따라 조정할 수 있습니다.
- 구성 요소 테스트 - 다른 이름은 모듈 또는 프로그램 테스트입니다. 단위 테스트와 유사하지만 더 높은 수준의 통합을 포함합니다. 소프트웨어의 모듈은 개별 기능을 검증하기 위해 결함에 대해 테스트됩니다.
- 통합 테스트 - 모듈 통합시 오류를 식별합니다. 다양한 통합 테스트는 상향식, 하향식 및 기능적 증분 테스트입니다.
- 시스템 테스트 - 프로젝트의 구성 요소는이 방법으로 다른 환경에서 전체적으로 테스트됩니다. 그것은 블랙 박스 방법에 속하며 그 과정에서 최종 테스트 중 하나입니다. 시스템이 비즈니스 및 사용자 요구를 충족시켜야하는지 여부를 결정합니다.
- 알파 테스트 - 내부 직원이 가상 또는 실제 환경에서 개발자 사이트의 소프트웨어를 테스트합니다. 그 후에 개발자는 버그 및 기타 문제를 수정합니다.
- 베타 테스트 - 현장 테스트로도 알려진 클라이언트는 실제 상황에서 자신의 사이트에서 제품을 테스트합니다. 클라이언트는 시험판 또는 베타 버전을 통해 최종 사용자 그룹에게 소프트웨어를 테스트 할 수있는 기회를 제공 할 수 있습니다. 가능한 개선에 대한 피드백이 개발자에게 전송됩니다.
- 수락 테스트 - 또한 블랙 박스 테스트의 범위에서 클라이언트는 소프트웨어가 개발자가 원하는 사양으로 프로그램을 만들었는지 확인하기 위해 소프트웨어를 테스트합니다.
테스트 유형
이 소프트웨어 테스트는 특정 목표에 중점을 둡니다.
- 설치 테스트 - 소프트웨어 테스트 엔지니어와 구성 관리자는이 테스트를 수행하여 최종 사용자가 프로그램을 설치하고 실행할 수 있는지 확인합니다. 설치 파일, 설치 위치 및 관리 권한과 같은 영역을 포함합니다.
- 개발 테스트 - 결함을 탐지하고 방지하기위한 동기화 된 전략의 범위를 구현합니다. 여기에는 정적 코드 분석, 피어 코드 검토, 추적 가능성 및 메트릭 분석이 포함됩니다. 목표는 위험을 줄이고 비용을 절감하는 것입니다.
- 사용성 테스트 -이 테스트에서는 사용자 경험 에 주목합니다. GUI가 얼마나 잘 디자인되고 사용이 용이한지를 측정합니다. 이 테스트는 기능의 정확성과 효율성 및 검사 대상자의 감정적 반응을 검사합니다.
- 온전한 테스트 - 소프트웨어가 추가 테스트를 계속하기에 충분한 시간과 비용이 필요한지 여부를 나타냅니다. 너무 많은 결함과보다 공격적인 테스트는 따르지 않습니다.
- 연기 테스트 - 연기 테스트는 방출을 방지하기에 충분히 심각한 기본 실패를 나타냅니다. 이 작업을 새 빌드에서 수행하면이를 빌드 확인 테스트라고합니다.
- 회귀 테스트 - 시스템이 수정 될 때 회귀 테스트는 예기치 않은 동작을 모니터링합니다. 모듈 또는 구성 요소에 대한 부작용을 지적합니다.
- 파괴적인 테스트 - 테스터는 비정상적인 입력을 입력하고 예기치 않은 입력을 관리하는 소프트웨어의 기능을 식별합니다. 이것은 프로그램이 오류 관리에 얼마나 강건한 지 개발자에게 보여줍니다.
- 복구 테스트 - 하드웨어 또는 다른 기능이 실패 할 때이 테스트는 소프트웨어가 얼마나 잘 복구되고 작동 하는지를 보여줍니다.
- 자동화 된 테스트 - 이것은 수동으로 구현하기 어려운 기능을 수행합니다. 이 도구는 특정 소프트웨어를 사용하여 테스트를 실행하고 실제 결과 대 예상 결과에 대한 데이터를 제공합니다.
- 호환성 테스트 - 소프트웨어는 다른 컴퓨팅 환경에서 실행되어야하므로 다른 시스템과의 호환성을 검사합니다. 예를 들어, 소프트웨어가 다양한 운영 체제 및 웹 브라우저에서 작동합니까?
- 성능 테스트 -이 시나리오는 여러 시나리오에서 소프트웨어 성능을 검사하는 심층적 인 테스트입니다. 응답 성, 안정성, 리소스 할당 및 속도에 대한 정보가 수집됩니다. 또한 볼륨, 용량 및 스파이크 테스트와 같은 하위 테스트가이 프로세스에 포함됩니다.
- 보안 테스트 - 이것은 사용자의 보안을 보호하는 소프트웨어의 기능을 측정합니다. 즉, 권한 부여 기능, 인증, 기밀성, 무결성, 가용성 및 부인 방지를 의미합니다.
- 접근성 테스트 - 이것은 사용성 테스트와 동일하지 않습니다. 이것은 학습 및 신체 장애가 포함 된 다른 사용자가 소프트웨어를 사용할 수있는 정도를 결정합니다.
- 국제화 및 로컬라이제이션 테스트 - 결과는 소프트웨어가 다양한 언어 및 지역 요구에 어떻게 적응할 수 있는지 보여줍니다. 여기에는 특정 위치에 대한 구성 요소 추가 및 텍스트 번역이 포함됩니다.
소프트웨어 테스팅은 제품을 출시하기 위해 필수적인 부분입니다. 테스터가 없다면 방대한 소프트웨어가 존재하지 않을 것입니다. BCS, IT 공인 연구소, ISTQB® (International Software Testing Qualifications Board) 및 ASQ (이전에는 미국 품질 협회)와 같은 조직을 통해 인증 된 소프트웨어 테스터가 되십시오.