확인 테스트가 무엇인지 아시는 분 계신가요?

종합 테스트를 통과한 후, 소프트웨어는 이미 완전히 조립되어 인터페이스 오류가 이미 제거되었다. 소프트웨어 테스트의 마지막 단계-테스트가 시작될 수 있는지 확인합니다. 검증 테스트에서는 소프트웨어가 계약 요구 사항, 즉 소프트웨어 요구 사항 설명서에 명시된 검증 기준을 충족하는지 확인해야 합니다.

1. 테스트 기준 확인

소프트웨어 검증을 위해서는 일련의 테스트가 필요합니다. 테스트를 확인하려면 테스트 계획 및 프로세스도 개발해야 합니다. 테스트 계획은 테스트 유형과 진행 상황을 규정해야 하며, 테스트 프로세스는 소프트웨어가 요구 사항을 충족하는지 여부를 설명하는 몇 가지 특수 테스트 사용 사례를 정의합니다. 계획이든 프로세스든, 소프트웨어가 계약에 명시된 모든 기능과 성능을 충족하는지, 문서가 완전한지, 인간-기계 인터페이스 등 측면 (예: 이식성, 호환성, 오류 복구 기능, 서비스 가능성 등) 이 사용자를 만족하는지 여부에 초점을 맞춰야 합니다.

테스트 결과를 확인할 수 있는 두 가지 가능성이 있습니다. 하나는 사용자가 받아들일 수 있는 기능 및 성능 지표가 소프트웨어 요구 사항 사양의 요구 사항을 충족한다는 것입니다. 다른 하나는 소프트웨어가 소프트웨어 요구 사항을 충족하지 못하여 사용자가 받아들일 수 없다는 것입니다. 프로젝트의 이 단계에서는 예정된 시한 내에 심각한 오류와 편차를 수정하기 어렵기 때문에 사용자와 협의하여 문제에 대한 적절한 해결책을 찾아야 한다.

2. 구성 검토

검증 테스트의 또 다른 중요한 부분은 구성 검토입니다. 검토의 목적은 소프트웨어 구성이 완전하고, 분류되며, 소프트웨어 유지 관리에 필요한 세부 사항을 포함시키는 것입니다.

3.α, β 시험

사실, 소프트웨어 개발자는 프로그램에 대한 사용자의 실제 사용을 완전히 예측할 수 없습니다. 예를 들어, 사용자가 명령을 오해하거나, 이상한 데이터 조합을 제공하거나, 디자이너가 잘 알고 있다고 생각하는 출력 정보에 혼란을 느낄 수 있습니다. 따라서 소프트웨어가 실제로 최종 사용자의 요구 사항을 충족하는지 여부는 사용자가 확인해야 합니다. 검수 테스트는 비공식 테스트 또는 계획된 시스템 테스트일 수 있습니다. 때로는 검수 테스트가 몇 주 또는 몇 달 동안 지속되고, 실수가 계속 노출되어 개발이 지연되기도 한다. 소프트웨어 제품에는 많은 사용자가 있을 수 있으며 모든 사용자가 받아들일 수는 없습니다. 이 시점에서 알파 및 베타 테스트라는 프로세스를 사용하여 최종 사용자만이 발견할 수 있는 문제를 발견하는 경우가 많습니다.

알파 테스트란 소프트웨어 개발사 조직 내부 직원이 다양한 사용자 라인을 시뮬레이션하여 곧 출시될 소프트웨어 제품 (알파 버전) 을 테스트하여 오류를 찾아 수정하는 것을 말합니다. 알파 테스트의 핵심은 가능한 한 소프트웨어 제품의 실제 운영 환경과 사용자 작업을 사실적으로 시뮬레이션하여 가능한 모든 사용자 운영 모드를 적용하는 것입니다. 알파 테스트를 거쳐 조정된 소프트웨어 제품을 베타 버전이라고 합니다. 둘째, 베타 테스트, 즉 소프트웨어 개발사 조직의 각 방면의 전형적인 사용자가 일상 업무에서 베타 버전을 실제로 사용하고 사용자에게 이상 상황을 보고하고 비판의견을 제시하도록 요구하는 것이다. 그런 다음 소프트웨어 개발 회사는 베타 버전을 수정하고 개선할 것이다.

시스템 테스트의 기본 방법

컴퓨터 소프트웨어는 컴퓨터 기반 시스템의 중요한 구성 요소이다. 소프트웨어 개발이 완료되면 시스템의 다른 구성 요소와 통합해야 합니다. 이때 일련의 시스템 통합 및 검증 테스트가 필요합니다. 이러한 테스트에 대한 자세한 논의는 소프트웨어 엔지니어링의 범위를 벗어납니다. 이러한 테스트는 소프트웨어 개발자만 수행할 수 없습니다. 시스템 테스트 전에 소프트웨어 엔지니어는 다음 작업을 완료해야 합니다.

(1) 테스트 소프트웨어 시스템의 입력 정보를 위한 오류 처리 경로를 설계합니다.

(2) 테스트 사용 사례를 설계하고, 소프트웨어 인터페이스에서 오류 데이터와 발생할 수 있는 오류를 시뮬레이션하고, 테스트 결과를 기록하고, 시스템 테스트에 경험과 지원을 제공합니다.

(3) 소프트웨어 테스트의 합리성을 보장하기 위해 시스템 테스트 계획 및 설계에 참여합니다.

시스템 테스트는 시스템을 완전히 실행하고 시스템의 모든 구성 요소가 한 정당에서 작동하는지 확인하고 지정된 작업을 완료하도록 설계된 여러 가지 테스트로 구성되어야 합니다. 다음은 몇 가지 유형의 시스템 테스트에 대한 간략한 설명입니다.

1, 복구 테스트

복구 테스트는 주로 시스템의 내결함성을 확인합니다. 시스템에 문제가 발생할 경우 지정된 시간 간격 내에 오류를 수정하고 시스템을 재부팅할 수 있습니까? 복구 테스트는 먼저 여러 가지 방법으로 시스템을 무효화시킨 다음 시스템이 가능한 한 빨리 복구될 수 있는지 확인해야 합니다. 자동 복구의 경우 재초기화, 체크포인트 메커니즘, 데이터 복구 및 재시작이 정확한지 확인해야 합니다. 수동으로 개입하는 수리 시스템의 경우 평균 수리 시간을 추정하여 허용 범위 내에 있는지 확인해야 합니다.

2. 안전 시험

보안 테스트 검사 시스템이 불법 침입을 막을 수 있는 능력. 안전테스트에서 테스터는 불법 침입자로 위장해 여러 가지 방법으로 방어선을 돌파하려고 시도했다. 예를 들어 ① 암호를 가로 채거나 해독하려고 노력하십시오. (2) 맞춤형 소프트웨어 파괴 시스템의 보호 메커니즘; (3) 의도적으로 시스템 고장을 일으키고 복구 시 불법 입국을 시도하는 것; (4) 기밀이 아닌 데이터를 탐색하여 필요한 정보를 추론하려고 합니다. 이론적으로 충분한 시간과 자원만 있으면 접근할 수 없는 시스템이 없다. 따라서 시스템 보안 설계의 원칙은 불법 침입 비용이 보호된 정보의 가치를 초과하도록 하는 것입니다. 이 시점에서 불법 침입자는 이미 이익이 없다.

3. 강도 시험

강도 테스트 검사 절차의 이상 상황에 대한 저항력. 강도 테스트는 항상 시스템이 비정상적인 자원 구성으로 실행되도록 강제합니다. 예: 1 정상적인 인터럽트 빈도가 초당 1 ~ 2 개일 때 초당 10 개의 인터럽트를 생성하는 테스트 케이스를 실행합니다. (2) 데이터 입력 속도를 정량적으로 높이고 입력 하위 기능의 반영 능력을 확인합니다. (3) 최대 스토리지 공간 (또는 기타 리소스) 이 필요한 테스트 케이스를 실행합니다. (4) 테스트 사용 사례를 실행하면 가상 메모리 운영 체제가 충돌하거나 디스크 데이터가 심하게 흔들릴 수 있습니다.

4. 특성 시험

실시간 및 임베디드 시스템의 경우 소프트웨어가 기능 요구 사항을 부분적으로 충족하더라도 성능 요구 사항을 충족할 수 있는 것은 아닙니다. 각 테스트 단계에는 단위 테스트의 성능 테스트가 포함되어 있지만, 시스템이 실제로 통합되어야 실제 환경에서 성능을 완벽하게 테스트하고 실행할 수 있습니다. 성능 테스트의 목적은 이 작업을 완료하는 것입니다. 성능 테스트는 강도 테스트와 결합되기도 하며, 일반적으로 추가 소프트웨어 및 하드웨어 지원이 필요합니다.