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 − 결함 수정 또는 개선을위한 최근 코드 변경으로 인해 빌드가 애플리케이션의 다른 부분을 손상시키지 않았는지 확인하기 위해 정상적인 회귀 테스트가 수행됩니다.

활동 블록 다이어그램

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