테스트 흰색 상자
사용성 테스트
가) 부하 테스트
성능 시험
기능 테스트
테스트 소프트웨어
테스트는 버그를 찾을 의도(또는 목적)로 프로그램(또는 프로그램의 일부)을 실행하는 프로세스입니다.
테스트 유형을 분류하는 데 사용되는 몇 가지 기준이 있습니다. 일반적으로 다음과 같은 징후가 구별됩니다.
나) 테스트 대상에 따라:
(이 시스템에 대한 요구 사항 준수를 설정하기 위해 외부 요청에 대한 응답으로 소프트웨어 및 하드웨어 시스템 또는 장치의 성능 및 응답 시간 지표의 결정 또는 수집)
b) 스트레스 테스트
(정상 작동 한계를 초과하는 조건에서 시스템의 신뢰성과 안정성을 평가합니다.)
다) 안정성 시험
4) 사용자 인터페이스 테스트
5) 보안 테스트
6) 현지화 테스트
7) 호환성 테스트
II) 시스템에 대한 지식으로:
1) 블랙박스 테스트
(내부 구조를 알 수 없는 개체를 테스트 중입니다.)
(프로그램 내부 구조 확인, 프로그램 로직 분석을 통한 테스트 데이터 획득)
III) 자동화 정도에 따라:
1) 수동 테스트
2) 자동화된 테스트
3) 반자동 테스트
IV) 구성요소의 분리 정도에 따라:
1) 부품(단위) 테스트
2) 통합 테스트
3) 시스템 테스트
V) 테스트 시점까지:
1) 알파 테스트- 전임 개발자 또는 테스터가 프로그램을 테스트하는 비공개 프로세스입니다. 알파 제품은 대부분 50%만 완성되고 프로그램 코드가 있지만 디자인의 상당 부분이 빠져 있습니다.
2) 베타 테스트- 무거운 사용 완성된 버전대중 소비자에게 시장에 최종 진입하기 전에 후속 제거를 위해 작업의 최대 오류 수를 식별하기 위해 프로그램. 일반 미래 사용자 중 자원 봉사자가 테스트에 참여합니다.
소프트웨어 검증은 테스트보다 더 일반적인 개념입니다. 검증의 목적은 검증 대상(요구사항 또는 프로그램 코드)이 요구사항을 충족하고 의도하지 않은 기능 없이 구현되며 설계 사양 및 표준( ISO 9000-2000). 검증 프로세스에는 검사, 코드 테스트, 테스트 결과 분석, 문제 보고서 생성 및 분석이 포함됩니다. 따라서 일반적으로 테스트 프로세스가 중요한 부분확인 과정.
상트 페테르부르크
주립 전자 기술 대학
MOEM과
징계로
"소프트웨어 개발 프로세스"
"소프트웨어 검증"
세인트 피터스 버그
검증 목적 ........................................................................................................... 3페이지
서론 …………………………………………………………3페이지
특별 및 일반 목표 ........................................................................... 4페이지
목표별 예상 실천 ........................................................................... 4페이지
SG1 검증 준비 ........................................................................................................... 4페이지
SG2 시험 실시(동료 평가) ........................................................................... 7페이지
SG3 검증의 구현 ........................................................................................... 9페이지
부록 1. 검증 프로세스를 위한 자동화 도구 개요........................... 11페이지
부록 2. 주요 내용 현대적 접근확인하려면 ........................... 12페이지
중고 문헌 목록 ........................................................................... 14페이지
탁월함과 성숙함의 통합 모델
검증(성숙도 3)
표적
검증 목적은선택한 미들웨어 또는 최종 제품이 지정된 요구 사항을 충족하는지 확인합니다.
물 노트
소프트웨어 제품의 검증은 완제품 또는 그 중간 버전의 검증원래 요구 사항을 충족합니다. 이것은 프로그램 자체를 테스트할 뿐만 아니라 프로젝트, 사용자 및 기술 문서 등을 감사하는 것을 의미합니다.
소프트웨어 시스템 검증의 목적은 라이프 사이클 단계에서 발생할 수 있는 오류를 식별하고 보고하는 것입니다. 검증의 주요 업무:
시스템 요구 사항에 대한 상위 수준 요구 사항의 준수 여부를 결정합니다.
시스템 아키텍처의 높은 수준의 요구 사항을 고려합니다.
소스 코드의 아키텍처 및 요구 사항 준수
시스템 요구 사항에 대한 실행 코드의 준수 여부를 결정합니다.
기술적으로 정확하고 충분히 완전한 위의 작업을 해결하는 데 사용되는 수단의 결정.
검증에는 고객 요구 사항, 완제품 요구 사항 및 개별 구성 요소에 대한 요구 사항을 포함하여 선택된 모든 요구 사항에 대한 완제품 검증 및 중간 제품 검증이 포함됩니다.
검증은 본질적으로 시작 순간부터 제품 개발 및 제품에 대한 모든 작업 전반에 걸쳐 증분(증분) 프로세스입니다. 검증은 요구 사항 검증으로 시작하여 개발 및 제조의 다양한 단계에서 모든 중간 제품의 검증을 거쳐 최종 제품의 검증으로 끝납니다.
개발 및 제조의 각 단계에서 중간 제품을 검증하면 최종 제품이 고객의 요구 사항, 완제품에 대한 요구 사항 및 개별 구성 요소에 대한 요구 사항을 충족할 가능성이 크게 높아집니다.
프로세스의 검증 및 검증은 본질적으로 관련된 프로세스이지만 다른 결과를 얻는 것을 목표로 합니다. Validation의 목적은 완제품이 원래의 목적을 실제로 충족함을 입증하는 것입니다. 검증은 제품이 특정 요구 사항을 정확히 충족하는지 확인하는 것을 목표로 합니다. 즉, 검증은 " 당신은 그것을 올바르게"이고 검증은 " 당신은 옳은 일을하고 있습니다”.
비용 효율성 및 성능을 평가하기 위해 관련 프로세스(예: 납품, 개발, 운영 또는 유지보수)에서 가능한 한 빨리 검증을 구현해야 합니다. 이 프로세스에는 분석, 검증 및 테스트(테스트)가 포함될 수 있습니다.
이 프로세스는 수행자의 다양한 독립성으로 수행될 수 있습니다. 수행자의 독립성 정도는 조직 자체의 다른 엔터티와 다른 조직의 엔터티 사이에 배포될 수 있으며 책임 분배 정도가 다릅니다. 이 과정을 과정이라고 한다 독립적인 검증구현 조직이 공급업체, 개발자, 운영자 또는 유지 관리자와 독립적인 경우.
전문가 평가 (전문적 지식) 효과적인 결함 제거를 위한 잘 확립된 도구로서 검증의 중요한 부분입니다. 여기서 중요한 점은 제품의 작업 버전과 가능한 결함을 식별하고 필요한 경우 개선 기회를 만드는 데 사용되는 워크플로에 대한 더 깊은 이해와 이해를 개발할 필요가 있다는 것입니다.
검사에는 결함 및 기타 필요한 변경 사항을 식별하기 위해 전문가가 수행한 작업에 대한 체계적인 연구가 포함됩니다.
전문가 평가의 주요 방법은 다음과 같습니다.
점검
종단 간 구조 제어
검증과 검증의 두 개념은 종종 혼동됩니다. 또한 시스템 요구 사항 검증은 종종 시스템 검증과 혼동됩니다. 이 문제를 조사하는 것이 좋습니다.
이 기사에서 객체 모델링에 대한 두 가지 접근 방식인 전체 및 구조를 고려했습니다. 현재 기사에서는 이 구분이 필요합니다.
설계된 기능적 객체가 있다고 가정합니다. 우리는 이 객체를 다른 기능적 객체 구성의 일부로 간주합니다. 객체에 대한 설명을 포함하도록 객체의 구성에 대한 설명이 있어야 합니다. 이러한 설명에서 개체는 전체적으로 설명을 갖습니다. 즉, 다른 개체와의 상호 작용 인터페이스는 개체 구성의 프레임워크 내에서 설명됩니다. 구조로서의 객체에 대한 설명이 주어집니다. 객체의 설명을 구조로 설계하기 위한 요구 사항을 포함하는 정보 객체가 있다고 가정합니다. 추론 규칙을 포함하는 지식의 몸체가 있다고 가정합니다.이 규칙을 기반으로 개체에 대한 설명이 전체 개체에 대한 설명에서 얻어집니다. 지식의 몸은 디자이너가 연구소에서 가르치는 것입니다. 많은 지식이 있습니다. 객체에 대한 지식을 기반으로 객체의 구조를 설계할 수 있습니다.
그래서, 당신은 시작할 수 있습니다. 대상 전체가 올바르게 설명되고 지식의 본문이 정확하며 추론 규칙이 준수되면 대상 구성에 대한 결과 설명이 정확하다고 주장할 수 있습니다. 즉, 이 설명을 바탕으로 에 해당하는 기능적 객체는 실제 조건작업. 발생할 수 있는 위험:
1. 객체에 대한 잘못된 지식의 사용. 사람들의 마음에 있는 대상의 모델은 현실과 일치하지 않을 수 있습니다. 예를 들어, 그들은 지진의 진정한 위험을 알지 못했습니다. 따라서 대상에 대한 요구 사항이 잘못 공식화될 수 있습니다.
2. 객체에 대한 지식의 불완전한 기록 - 무언가를 놓치고 실수를 합니다. 예를 들어, 그들은 바람에 대해 알고 있었지만 언급하는 것을 잊었습니다. 이것은 객체에 대한 요구 사항에 대한 불완전한 설명으로 이어질 수 있습니다.
3. 잘못된 지식 체계. 우리는 다른 매개변수보다 질량의 우선순위를 배웠지만 속도를 높여야 한다는 것이 밝혀졌습니다.
4. 개체 설명에 대한 추론 규칙의 잘못된 적용. 논리적 오류, 개체 설계에 대한 요구 사항에 누락된 것이 있으며 요구 사항 추적이 손상되었습니다.
5. 시스템 설계에 대해 얻은 결론에 대한 불완전한 기록. 모든 것이 고려되었고 모든 것이 계산되었지만 쓰는 것을 잊었습니다.
6. 생성된 시스템이 설명과 일치하지 않습니다.
모든 프로젝트 아티팩트는 원칙적으로 프로젝트가 끝날 때까지 완료된 형태로 나타나며 항상 그런 것은 아닙니다. 그러나 개발이 폭포수라고 가정하면 위험은 내가 설명한 대로입니다. 각 위험을 확인하는 것은 이름을 지정할 수 있는 특정 작업입니다. 관심이 있는 사람이 있으면 이러한 용어를 생각해내고 목소리를 낼 수 있습니다.
검증이란? 러시아어에서 확인은 규칙 준수 여부를 확인하는 것입니다. 규칙은 문서 형식입니다. 즉, 문서 요구 사항이 있는 문서가 있어야 합니다. 문서가 이 문서의 요구 사항을 충족하면 검증을 통과한 것입니다.
유효성 검사란 무엇입니까? 러시아어에서 유효성 검사는 결론의 정확성을 확인하는 것입니다. 즉, 객체 데이터를 기반으로 설계에 대한 설명을 얻는 방법을 설명하는 지식의 몸체가 있어야 합니다. 이러한 결론의 적용이 올바른지 확인하는 것이 유효성 검사입니다. 유효성 검사는 무엇보다도 일관성, 완전성 및 이해도에 대한 설명을 확인하는 것입니다.
요구 사항 검증은 종종 해당 요구 사항을 기반으로 구축된 제품의 검증과 혼동됩니다. 그럴 가치가 없습니다.
팀에는 2명 이상의 인원이 포함되어 불가피하게 팀 내 역할, 권한 및 책임의 분배에 대한 문제를 제기합니다. 특정 역할 세트는 개발 참가자 수와 개인 선호도, 채택된 개발 방법론, 프로젝트 기능 및 기타 요소와 같은 많은 요소에 의해 결정됩니다. 거의 모든 개발 팀에서 다음과 같은 역할을 구분할 수 있습니다. 그들 중 일부는 완전히 없을 수도 있고 개인이 한 번에 여러 역할을 수행할 수 있지만 전체 구성은 거의 변경되지 않습니다.고객(신청자). 이 역할은 개발 중인 시스템을 주문한 조직의 대표에게 속합니다. 일반적으로 신청자는 상호 작용이 제한적이며 프로젝트 관리자 및 인증 또는 구현 전문가와만 의사 소통합니다. 일반적으로 고객은 제품에 대한 요구 사항을 변경할 권리가 있습니다(관리자와 협력하는 경우에만). 개발 중인 시스템의 비기술적 기능에 영향을 미치는 설계 및 인증 문서를 읽을 수 있습니다.
프로젝트 매니저. 이 역할은 고객과 프로젝트 팀 간의 커뮤니케이션 채널을 제공합니다. 제품 관리자는 고객의 기대치를 관리하고 프로젝트에 대한 비즈니스 컨텍스트를 개발 및 유지 관리합니다. 그의 작업은 판매와 직접적인 관련이 없으며 제품에 중점을 두며 그의 임무는 정의하고 제공하는 것입니다. 고객의 요구 사항. 프로젝트 관리자는 제품에 대한 요구 사항과 제품에 대한 최종 문서를 변경할 권리가 있습니다.
프로그램 관리자. 이 역할은 프로젝트 팀 내의 커뮤니케이션 및 관계를 관리하고, 어떤 식으로든 조정자 역할을 하며, 기능 사양을 개발 및 관리하고, 프로젝트 일정을 유지하고 프로젝트 상태에 대해 보고하고, 프로젝트에 대한 중요한 결정을 시작합니다.
테스트- 오류를 감지하기 위해 프로그램을 실행하는 프로세스.
테스트 데이터- 시스템을 테스트하는 데 사용되는 입력.
테스트 상황(테스트 케이스)- 시스템이 요구 사항 사양에 따라 작동하는 경우 시스템을 테스트하기 위한 입력 및 입력에 따라 예상되는 출력.
좋은 테스트 케이스- 아직 검출되지 않은 오류를 검출할 확률이 높은 상황.
행운의 시험- 아직 감지되지 않은 오류를 감지하는 테스트.
오류-개발 단계에서 프로그래머의 행동으로 인해 소프트웨어에 내부 결함이 포함되어있어 프로그램 작동 중에 잘못된 결과를 초래할 수 있습니다.
거절- 시스템에 포함된 결함으로 인해 발생할 수 있는 예기치 않은 결과로 이어지는 시스템의 예측할 수 없는 동작.
따라서 소프트웨어 테스트 과정에서 원칙적으로 다음 사항을 확인합니다.
확인 및 검증( 검증 및 검증-V& V)고객의 사양 및 요구 사항에 대한 소프트웨어의 올바른 실행 및 준수를 분석, 확인하도록 설계되었습니다. 프로그램 및 시스템의 정확성을 확인하는 이러한 방법은 각각 다음을 의미합니다.
- 검증은 사양에 따라 시스템 생성의 정확성을 검증하는 것입니다.
- 검증은 시스템에 대해 지정된 요구 사항을 충족하는 정확성을 검증하는 것입니다.
검증은 설계 및 개발 완료 후 생성된 시스템의 정확성에 대한 결론을 내리는 데 도움이 됩니다. 검증을 통해 지정된 요구 사항의 실현 가능성을 설정할 수 있으며 올바른 프로그램 및 시스템을 얻기 위한 다음과 같은 여러 작업이 포함됩니다.
- 계획 검사 및 통제 절차 디자인 결정및 요구 사항;
- CASE 수단에 의한 프로그램 설계 자동화 수준 제공;
- 대상 테스트 세트에 대한 테스트 방법을 통해 프로그램의 올바른 기능을 확인합니다.
- 작동 환경에 대한 제품의 적응 등
검증은 초기 요구 사항이 올바르게 구현되고 지정된 조건과 제약 조건이 충족되는지 확인하기 위해 수명 주기 단계에서 사양 및 설계 출력을 검토하고 검사하여 이러한 활동을 수행합니다. 검증 및 검증 작업에는 요구 사항 사양의 완전성, 일관성 및 명확성 및 시스템 기능 성능의 정확성 확인이 포함됩니다.
확인 및 검증은 다음을 따릅니다.
- 시스템의 주요 구성 요소;
- 분산 환경에서 시스템의 구현을 보장하는 구성 요소(소프트웨어, 기술 및 정보)의 인터페이스 및 개체(프로토콜 및 메시지)의 상호 작용
- 데이터베이스 및 파일(트랜잭션 및 메시지)에 대한 액세스 수단 및 다른 사용자의 데이터에 대한 무단 액세스에 대한 보호 수단 확인
- 소프트웨어 및 시스템 전체에 대한 문서
- 테스트, 테스트 절차 및 입력 데이터.
즉, 프로그램 정확성의 주요 체계적인 방법은 다음과 같습니다.
- 확인 PS 구성 요소 및 요구 사항 사양 검증;
- PS 검사주어진 사양과 프로그램의 적합성을 확립하기 위해;
- 테스트다양한 결함, 이상, 장비 오류 또는 시스템 충돌로 인한 오류 및 결함을 식별하기 위해 특정 운영 환경에서 테스트 데이터에 대한 PS의 출력 코드(9장 참조).
ISO/IEC 3918-99 및 12207에는 검증 및 검증 프로세스가 포함됩니다. 그들에게 목표, 작업 및 조치는 수명주기 단계 및 요구 사항 준수 단계에서 생성 된 제품 (작업, 중간 제품 포함)의 정확성을 확인하기 위해 정의됩니다.
검증 및 검증 프로세스의 주요 임무는 확인하고 확인최종 소프트웨어가 목적에 적합하고 고객의 요구 사항을 충족하는지 확인합니다. 이러한 프로세스를 통해 발생 원인을 찾지 않고 수명 주기 단계의 작업 제품에서 오류를 식별하고 사양과 관련하여 소프트웨어의 정확성을 설정할 수 있습니다.
이러한 프로세스는 상호 연관되어 있으며 "검증 및 검증"(V&V 7)이라는 용어로 정의됩니다.
확인이 수행됩니다.
- 고객의 지정된 요구 사항에 따라 구성 요소의 관계를 추적하여 개별 구성 요소를 출력 코드로 변환하는 것과 인터페이스 설명의 정확성을 확인합니다.
- 데이터 조작 및 결과 전송에 사용되는 시스템 도구에 채택된 절차를 고려하여 파일 또는 데이터베이스에 대한 액세스 정확성 분석
- 고객 요구 사항 및 추적을 준수하기 위한 구성 요소 보호 수단의 검증.
시스템의 개별 구성 요소를 확인한 후 통합이 수행되고 통합 시스템의 검증 및 검증이 수행됩니다. 시스템은 테스트 스위트가 테스트를 완료하고 시스템의 정확성을 확립하기에 적절하고 충분한지 결정하기 위해 복수의 테스트 스위트에서 테스트됩니다.
공식 검증에 대한 국제 프로젝트를 만드는 아이디어는 T. Hoare가 제안했으며 2005년 2월 캘리포니아에서 열린 검증된 소프트웨어에 대한 심포지엄에서 논의되었습니다. 그런 다음 같은 해 10월 취리히에서 열린 IFIP 회의에서 "PS의 정확성을 확인하기 위한 전체론적 자동화 도구 세트"를 개발하기 위해 15년 동안 국제 프로젝트가 채택되었습니다.
다음과 같은 주요 작업을 공식화했습니다.
- 프로그램 구성 및 분석에 대한 통일된 이론의 개발;
- 사양 개발 및 검증, 테스트 케이스 생성, 프로그램 개선, 분석 및 검증을 포함하여 모든 생산 단계에 대한 포괄적인 통합 검증 도구 세트를 구축합니다.
- 공식 사양 및 검증된 소프트웨어 객체의 저장소 생성 다른 유형및 유형.
이 프로젝트는 검증이 소프트웨어 생성 및 정확성 검사의 모든 측면을 다루며 생성 중인 프로그램에서 지속적으로 발생하는 오류와 관련된 모든 문제에 대한 만병 통치약이 될 것이라고 가정합니다.
특정 프로그램을 증명하고 검증하기 위한 많은 공식 방법이 실제로 테스트되었습니다. 완료 큰 일프레임워크 내에서 국제 위원회 ISO/IEC ISO 표준/ 소프트웨어 검증 및 검증 프로세스의 표준화에 관한 IEC 12207:2002. 다른 프로그래밍 개체의 형식적인 방법으로 정확성을 확인하는 것은 유망합니다.
저장소는 개발 및 테스트, 완성된 구성 요소의 평가, 도구 및 방법 공백에 사용되는 프로그램, 사양 및 도구의 저장소입니다. 다음과 같은 일반 작업이 있습니다.
- 복잡한 응용 프로그램에 대한 검증된 사양, 증명 방법, 프로그램 개체 및 코드 구현의 축적;
- 다양한 검증 방법의 축적, 추가 적용을 위해 실현된 이론적 아이디어를 검색하고 선택하는 데 적합한 형태로 설계
- 도구 및 기성 시스템뿐만 아니라 다양한 프로그래밍 개체의 공식 사양을 설정하고 교환하기 위한 표준 형식 개발;
- 검증된 완제품을 저장소에서 새로운 분산 및 네트워크 환경으로 전송하여 새로운 PS를 생성하기 위한 상호 운용성 및 상호 작용 메커니즘의 개발.
이 프로젝트는 50년 이내에 개발되어야 합니다. 초기 프로젝트는 소프트웨어 품질 향상, 서비스 모델 공식화, PIC 사용을 통한 복잡성 감소, 시각적 오류 진단 및 제거를 위한 디버깅 도구 생성 등 유사한 목표를 설정했습니다. 그러나 프로그래밍의 근본적인 변화는 다음과 같은 의미에서 발생하지 않았습니다. 시각적 디버깅 또는 달성 고품질켜짐. 개발 과정은 계속됩니다.
새로운 국제 소프트웨어 검증 프로젝트는 참가자들에게 지식뿐만 아니라 이론적 측면프로그램 사양뿐만 아니라 향후 몇 년 동안 구현을 위한 고도의 자격을 갖춘 프로그래머입니다.
