복구 테스트란 무엇입니까? 예를 들어

복구 테스트

복구 테스트 소프트웨어/하드웨어 충돌, 네트워크 장애 등과 같은 장애로부터 소프트웨어를 복구하는 능력을 검증하는 소프트웨어 테스팅 기술입니다. 복구 테스팅의 목적은 재해 또는 무결성 손실 후에도 소프트웨어 운영을 계속할 수 있는지 확인하는 것입니다. 복구 테스트에는 소프트웨어를 무결성이 알려진 지점으로 되돌리고 트랜잭션을 오류 지점으로 재처리하는 작업이 포함됩니다.

복구 테스트 예

애플리케이션이 네트워크에서 데이터를 수신하는 경우 연결 케이블을 분리하세요.

복구 테스트

  • 잠시 후 케이블을 다시 연결하고 네트워크 연결이 끊어진 지점부터 데이터를 계속 수신하는 애플리케이션의 능력을 분석하십시오.
  • 브라우저에 정해진 개수의 세션이 열려 있는 동안 시스템을 다시 시작하고 브라우저가 세션을 모두 복구할 수 있는지 확인하세요.

소프트웨어 엔지니어링에서 복구성 테스트는 비-복구성 테스트 유형입니다. 기능 테스트. (비기능 테스트는 확장성이나 보안과 같은 특정 기능이나 사용자 작업과 관련되지 않을 수 있는 소프트웨어의 측면을 의미합니다.)

복구에 소요되는 시간은 다음에 따라 달라집니다.

  • 재시작 지점 수
  • 애플리케이션의 양
  • 복구 활동을 수행하는 사람들의 훈련 및 기술과 복구에 사용할 수 있는 도구입니다.

다수의 실패가 있는 경우 모든 실패를 처리하는 대신 복구 테스트는 구조화된 방식으로 수행되어야 합니다. 즉, 복구 테스트는 한 세그먼트에 대해 수행된 다음 다른 세그먼트에 대해 수행되어야 함을 의미합니다.

전문 테스터가 수행합니다. 복구 테스트 전에 적절한 백업 데이터는 안전한 위치에 보관됩니다. 이는 재해 후에도 운영을 계속할 수 있도록 하기 위한 것입니다.

복구 프로세스의 수명주기

복구 프로세스의 수명 주기는 다음과 같이 분류할 수 있습니다.wing 다섯 단계:

  1. 정상 작동
  2. 재해발생
  3. 운영 중단 및 실패
  4. 복구 프로세스를 통한 재해 정리
  5. 전체 시스템을 정상 작동시키기 위해 모든 프로세스와 정보를 재구성합니다.

소프트웨어 테스팅의 복구 테스팅: 현실적인 테스트

이 5단계에 대해 자세히 논의해 보겠습니다.

  1. 공통의 목표를 달성하기 위해 통합된 하드웨어, 소프트웨어, 펌웨어로 구성된 시스템은 잘 정의되고 명시된 목표를 수행하기 위해 작동됩니다. 정해진 시간 내에 어떠한 중단도 없이 설계된 작업을 수행하기 위해 시스템이 정상 작동을 수행하도록 호출됩니다.
  2. 입력으로 인한 오작동, 하드웨어 오류로 인한 소프트웨어 충돌, 화재, 도난, 파업으로 인한 손상 등 다양한 원인으로 인해 소프트웨어 오작동으로 인해 중단이 발생할 수 있습니다.
  3. 중단 단계는 비즈니스 손실, 관계 단절, 기회 손실, 인건비 손실, 변함없이 재정적 및 영업권 손실로 이어지는 가장 고통스러운 단계입니다. 모든 합리적인 기관은 중단 단계를 최소화할 수 있는 재해 복구 계획을 가지고 있어야 합니다.
  4. 재해와 중단이 발생하기 전에 백업 계획과 위험 완화 프로세스가 올바른 위치에 있다면 시간, 노력, 에너지를 크게 낭비하지 않고 복구를 수행할 수 있습니다. 지정된 개인과 각 개인의 역할이 할당된 팀을 정의하여 책임을 확정하고 조직이 장기간의 중단 기간을 피할 수 있도록 지원해야 합니다.
  5. 재구성에는 구성 파일과 함께 모든 폴더를 다시 작성하기 위한 여러 작업 세션이 포함될 수 있습니다. 올바른 복구를 위해서는 적절한 문서화와 재구성 프로세스가 있어야 합니다.

복원 전략

복구팀은 기관의 운영을 정상화하기 위해 중요한 코드와 데이터를 검색하는 고유한 전략을 가지고 있어야 합니다.

전략은 처리 중인 시스템의 중요성에 따라 각 조직마다 고유할 수 있습니다.

중요한 시스템에 가능한 전략은 다음과 같이 시각화할 수 있습니다.

  1. 단일 백업 또는 둘 이상의 백업을 보유하려면
  2. 한 장소 또는 다른 장소에 여러 백업을 보유하려면
  3. 온라인 백업 또는 오프라인 백업을 하려면
  4. 정책에 따라 백업을 자동으로 수행할 수 있습니까, 아니면 수동으로 수행할 수 있습니까?
  5. 독립적인 복원팀을 구성하거나 개발팀 자체를 활용하여 작업 가능

이러한 각 전략에는 비용 요소가 관련되어 있으며 여러 백업에 필요한 여러 리소스가 더 많은 물리적 리소스를 소비하거나 독립 팀이 필요할 수 있습니다.

관련 개발자 기관에 대한 데이터 및 코드 종속성으로 인해 많은 회사가 영향을 받을 수 있습니다. 예를 들어, 만약 Amazon AWS 인터넷이 25번 종료됩니다. 그러한 경우에는 독립 복원이 매우 중요합니다.

복구 테스트 수행 방법

복구 테스트를 수행하는 동안wing 사항을 고려해야 합니다.

  • 최대한 실제 배치 조건에 가까운 테스트베드를 만들어야 합니다. 인터페이스, 프로토콜, 펌웨어, 하드웨어, 소프트웨어의 변경 사항은 동일한 조건은 아니더라도 최대한 실제 조건에 가까워야 합니다.
  • 철저한 테스트를 통해 시간과 비용이 많이 들 수 있으므로 동일한 구성과 완전한 점검이 수행되어야 합니다.
  • 가능하다면 최종적으로 복원할 하드웨어에 대해 테스트를 수행해야 합니다. 백업을 생성한 머신이 아닌 다른 머신으로 복원하는 경우 특히 그렇습니다.
  • 일부 백업 시스템에서는 하드 드라이브의 크기가 백업을 가져온 드라이브의 크기와 정확히 동일할 것으로 예상합니다.
  • 드라이브 기술은 빠른 속도로 발전하고 있으며 오래된 드라이브는 새 드라이브와 호환되지 않을 수 있으므로 노후화를 관리해야 합니다. 문제를 처리하는 한 가지 방법은 가상 머신. VMware Inc.와 같은 가상화 소프트웨어 공급업체는 디스크 크기 및 기타 구성을 포함하여 기존 하드웨어를 모방하도록 가상 머신을 구성할 수 있습니다.
  • 온라인 백업 시스템도 테스트에서 예외는 아닙니다. 대부분의 온라인 백업 서비스 제공업체는 내결함성 스토리지 시스템을 사용하여 미디어 문제에 직접 노출되지 않도록 보호합니다.
  • 온라인 백업 시스템은 매우 안정적이지만 시스템의 복원 측면을 테스트하여 검색 기능, 보안 또는 암호화에 문제가 없는지 확인해야 합니다.

복원 후 테스트 절차

대부분의 대기업에는 정기적으로 복구 테스트를 수행하는 독립 감사인이 있습니다.

포괄적인 재해 복구 계획을 유지하고 테스트하는 데 드는 비용은 상당할 수 있으며 소규모 기업에서는 감당하기 어려울 수 있습니다.

작은 위험은 재해 발생 시 데이터 백업 및 오프사이트 스토리지 계획에 의존하여 데이터를 저장할 수 있습니다.

폴더와 파일이 복원된 후 다음을 따르세요.wing 파일이 제대로 복구되었는지 확인하기 위해 검사를 수행할 수 있습니다.

  • 손상된 문서 폴더 이름 바꾸기
  • 복원된 폴더의 파일 수를 계산하고 기존 폴더와 일치시킵니다.
  • 파일 중 몇 개를 열고 액세스할 수 있는지 확인하세요. 일반적으로 사용하는 응용 프로그램으로 열어야 합니다. 그리고 데이터를 탐색하고, 데이터를 업데이트하거나 평소에 수행하는 모든 작업을 수행할 수 있는지 확인하세요.
  • 다양한 유형의 여러 파일, 사진, mp3, 문서 및 크고 작은 파일을 여는 것이 가장 좋습니다.
  • 다리 운영체제 파일과 디렉터리를 비교하는 데 사용할 수 있는 유틸리티가 있습니다.

슬립폼 공법 선택시 고려사항

이 튜토리얼에서는 시스템이나 프로그램이 실패 후 요구 사항을 충족하는지 이해하는 데 도움이 되는 복구 테스트의 다양한 측면을 배웠습니다.