STLC-테스트 실행

테스트 실행은 코드를 실행하고 예상 결과와 실제 결과를 비교하는 프로세스입니다. 테스트 실행 프로세스를 위해 다음 요소를 고려해야합니다.

위험을 기반으로이주기에 실행할 테스트 스위트의 서브 세트를 선택하십시오.
실행을 위해 각 테스트 스위트의 테스트 케이스를 테스터에게 지정하십시오.
테스트를 실행하고 버그를보고하며 테스트 상태를 지속적으로 캡처합니다.
발생하는 차단 문제를 해결합니다.
상태를보고하고, 할당을 조정하고, 매일 계획과 우선 순위를 재고합니다.
테스트주기 결과 및 상태를보고합니다.

테스트 실행을 위해 다음 사항을 고려해야합니다.

이 단계에서 QA 팀은 준비된 테스트 사례를 기반으로 AUT의 실제 유효성 검사를 수행하고 단계적 결과를 예상 결과와 비교합니다.
이 단계의 시작 기준은 테스트 계획 및 테스트 케이스 개발 단계의 완료이며 테스트 데이터도 준비되어야합니다.
테스트 환경 설정의 검증은 공식적으로 테스트 실행에 들어가기 전에 항상 연기 테스트를 통해 권장됩니다.
종료 기준은 모든 테스트 케이스의 성공적인 검증을 요구합니다. 결함은 종결되거나 연기되어야합니다. 테스트 케이스 실행 및 결함 요약 보고서가 준비되어야합니다.

테스트 실행을위한 활동

이 단계의 목표는 프로덕션 / 릴리스로 이동하기 전에 AUT의 실시간 검증입니다. 이 단계에서 승인하기 위해 QA 팀은 제품 품질을 보장하기 위해 다양한 유형의 테스트를 수행합니다. 이 결함보고 및 재 테스트와 함께이 단계에서도 중요한 활동입니다. 다음은이 단계의 중요한 활동입니다.

시스템 통합 테스트

제품 / AUT의 실제 검증은 여기서 시작됩니다. 시스템 통합 테스트 (SIT)는 지정된 요구 사항 / 준비된 테스트 사례에 대한 시스템의 컴플라이언스를 평가하는 블랙 박스 테스트 기술입니다.

시스템 통합 테스트는 일반적으로 시스템의 하위 집합에서 수행됩니다. SIT는 테스트 도구를 최소한으로 사용하여 수행 할 수 있으며, 교환 된 상호 작용을 확인하고 개별 레이어 내 각 데이터 필드의 동작도 조사합니다. 통합 후 데이터 흐름의 세 가지 주요 상태가 있습니다.

통합 계층 내의 데이터 상태
데이터베이스 계층 내의 데이터 상태
애플리케이션 계층 내의 데이터 상태

Note− SIT 테스트에서 QA 팀은 품질을 보장하기 위해 가능한 한 많은 결함을 찾으려고 노력합니다. 여기서 주요 목표는 가능한 한 많은 버그를 찾는 것입니다.

결함보고

예상 결과가 실제 결과와 일치하지 않으면 소프트웨어 버그가 발생합니다. 컴퓨터 프로그램의 오류, 결함, 실패 또는 결함 일 수 있습니다. 대부분의 버그는 개발자 또는 설계자가 만든 실수와 오류로 인해 발생합니다.

SIT 테스트를 수행하는 동안 QA 팀은 이러한 유형의 결함을 발견하고 관련 팀 구성원에게보고해야합니다. 회원은 추가 조치를 취하고 결함을 수정합니다. 보고의 또 다른 장점은 결함 상태를 쉽게 추적 할 수 있다는 것입니다. 결함보고 및 추적을 지원하는 ALM, QC, JIRA, Version One, Bugzilla와 같은 널리 사용되는 도구가 많이 있습니다.

결함보고는 고객의 피드백을 테스트하거나 기록하고 고객의 피드백을 기반으로 결함을 수정하는 제품의 새 버전을 작성하여 테스트중인 애플리케이션 또는 제품에서 결함을 찾는 프로세스입니다.

복잡하고 비즈니스에 중요한 시스템에는 수백 개의 결함이 있으므로 결함 추적은 소프트웨어 엔지니어링에서 중요한 프로세스이기도합니다. 가장 어려운 요소 중 하나는 이러한 결함을 관리, 평가 및 우선 순위 지정하는 것입니다. 일정 기간 동안 결함의 수가 증가하고이를 효과적으로 관리하기 위해 결함 추적 시스템을 사용하여 작업을보다 쉽게 수행 할 수 있습니다.

결함 매핑

결함이보고되고 기록되면 관련 실패 / 차단 된 테스트 사례 및 요구 사항 추적 성 매트릭스의 해당 요구 사항과 매핑되어야합니다. 이 매핑은 Defect Reporter에 의해 수행됩니다. 적절한 결함 보고서를 작성하고 제품의 부정확성을 분석하는 데 도움이됩니다. 테스트 케이스 및 요구 사항이 결함과 매핑되면 이해 관계자는 우선 순위 및 심각도에 따라 결함을 수정 / 연기할지 여부를 분석하고 결정할 수 있습니다.

재시험

재 테스트는 AUT에 대해 이전에 실패한 테스트를 실행하여 문제가 해결되었는지 확인하는 것입니다. 결함이 수정 된 후 동일한 환경 조건에서 시나리오를 확인하기 위해 다시 테스트가 수행됩니다.

다시 테스트하는 동안 테스터는 변경된 기능 영역에서 세분화 된 세부 정보를 찾는 반면 회귀 테스트는 이러한 변경으로 인해 기능이 손상되지 않도록 모든 주요 기능을 다룹니다.

회귀 테스트

모든 결함이 종료, 지연 또는 거부 상태에 있고 진행중인 / 실패 / 실행 상태가 아닌 테스트 케이스가 없으면 시스템 통합 테스트는 완전히 테스트 케이스 및 요구 사항을 기반으로한다고 말할 수 있습니다. 그러나 코드 변경 / 결함 수정으로 인해 기능이 손상되지 않도록하려면 한 번의 빠른 테스트가 필요합니다.

회귀 테스트는 코드 변경으로 인해 영향을받은 테스트를 다시 실행하는 것으로 구성된 블랙 박스 테스트 기술입니다. 이러한 테스트는 소프트웨어 개발 수명주기 동안 가능한 한 자주 실행되어야합니다.

회귀 테스트 유형

Final Regression Tests− 일정 기간 동안 변경되지 않은 빌드를 확인하기 위해 "최종 회귀 테스트"가 수행됩니다. 이 빌드는 배포되거나 고객에게 제공됩니다.
Regression Tests − 결함 수정 또는 개선을위한 최근 코드 변경으로 인해 빌드가 애플리케이션의 다른 부분을 손상시키지 않았는지 확인하기 위해 정상적인 회귀 테스트가 수행됩니다.

활동 블록 다이어그램

다음 블록 다이어그램은이 단계에서 수행 된 중요한 활동을 보여줍니다. 또한 이전 단계의 종속성을 보여줍니다.