소프트웨어 검증 방법. 소프트웨어 개발 프로세스 중 검증의 장소입니다. 검증 및 적격성 평가 계획
20. 검증 및 인증 소프트웨어
확인 및 검증은 소프트웨어가 사양 및 고객 요구 사항을 충족하는지 확인하는 테스트 및 검토 프로세스입니다. 검증 및 인증은 전체 소프트웨어 수명 주기를 포괄합니다. 요구 사항 분석 단계에서 시작하여 완성된 소프트웨어 시스템 테스트 단계에서 프로그램 코드 검증으로 끝납니다.
검증과 인증은 동일한 것이 아니지만 혼동하기 쉽습니다. 간단히 말해서, 이들의 차이점은 다음과 같이 정의할 수 있습니다.
확인은 시스템이 올바르게 생성되었는지 여부에 대한 질문에 답합니다.
인증은 시스템이 올바르게 작동하는지에 대한 질문에 답합니다.
이러한 정의에 따르면 검증은 소프트웨어가 시스템 사양, 특히 기능적 및 비기능적 요구 사항을 준수하는지 확인합니다. 인증은 보다 일반적인 프로세스입니다. 인증 중에는 소프트웨어 제품이 고객의 기대를 충족하는지 확인하는 것이 필요합니다. 인증은 시스템이 사양뿐만 아니라 고객의 기대치를 얼마나 잘 충족하는지 확인하기 위한 검증 후에 이루어집니다.
앞서 언급했듯이 소프트웨어 개발 초기 단계에서는 시스템 요구사항 인증이 매우 중요합니다. 요구사항에는 오류와 누락이 흔합니다. 이러한 경우 최종 제품이 고객의 기대를 충족하지 못할 가능성이 높습니다. 그러나 물론 요구사항 검증으로 요구사항 사양의 모든 문제를 식별할 수는 없습니다. 시스템 구현이 완료된 후에야 요구사항의 단점과 오류가 발견되는 경우도 있습니다.
검증 및 인증 프로세스에서는 시스템을 검증하고 분석하는 두 가지 주요 기술을 사용합니다.
1. 소프트웨어 검사.요구 사항 사양 문서, 아키텍처 다이어그램 또는 프로그램 소스 코드와 같은 다양한 시스템 표현을 분석하고 확인합니다. 검사는 소프트웨어 시스템 개발 프로세스의 모든 단계에서 수행됩니다. 검사와 병행하여 진행 가능 자동 분석프로그램 및 관련 문서의 소스 코드. 검사 및 자동 분석은 실행 가능한 시스템이 필요하지 않기 때문에 정적 검증 및 검증 방법입니다.
2. 소프트웨어 테스팅.테스트 데이터로 실행 가능한 코드를 실행하고 소프트웨어 제품의 출력 및 성능 특성을 검사하여 시스템이 올바르게 작동하는지 확인합니다. 테스트는 실행 중인 시스템에 적용되는 검증 및 인증의 동적 방법입니다.
그림에서. 그림 20.1은 소프트웨어 개발 과정에서 검사와 테스트가 이루어지는 위치를 보여준다. 화살표는 이러한 방법을 적용할 수 있는 개발 프로세스 단계를 나타냅니다. 이 방식에 따르면 시스템 개발 과정의 모든 단계에서 검사가 가능하며, 프로토타입이나 실행 가능한 프로그램이 만들어진 경우에도 테스트가 가능하다.
검사 방법에는 프로그램 검사, 소스 코드 자동 분석, 형식 검증 등이 있습니다. 그러나 정적 방법은 프로그램의 사양 준수 여부만 확인할 수 있으며 시스템이 올바르게 작동하는지 확인하는 데는 사용할 수 없습니다. 또한 성능, 신뢰성 등 비기능적 특성은 정적인 방법으로는 검증할 수 없습니다. 따라서 비기능적 특성을 평가하기 위해 시스템 테스트가 수행됩니다.
쌀. 20.1. 정적 및 동적 검증 및 인증
소프트웨어 검사의 광범위한 사용에도 불구하고 테스트는 여전히 검증 및 인증의 주요 방법입니다. 테스트는 시스템이 작동하는 동안 처리될 실제 데이터와 유사한 데이터를 사용하여 프로그램의 작동을 테스트하는 것입니다. 프로그램의 결함 및 부적합 여부는 출력 데이터를 검사하고 그 중에서 비정상적인 항목을 식별함으로써 감지됩니다. 테스트는 시스템 구현 단계(시스템이 개발자의 기대치를 충족하는지 확인하기 위해)와 구현이 완료된 후에 수행됩니다.
소프트웨어 개발 프로세스의 여러 단계에서 다양한 유형의 테스트가 사용됩니다.
1. 결함 테스트프로그램의 오류나 결함으로 인해 발생하는 프로그램과 사양 간의 불일치를 감지하기 위해 수행됩니다. 이러한 테스트는 시스템 작동을 시뮬레이션하는 것이 아니라 시스템의 오류를 식별하도록 설계되었습니다.
2. 통계적 테스트다양한 작동 모드에서의 시스템 작동은 물론 프로그램의 성능과 신뢰성을 평가합니다. 테스트는 실제 입력 데이터를 사용하여 실제 시스템 작동을 시뮬레이션하도록 설계되었습니다. 시스템의 신뢰성은 프로그램 운영에서 발견된 실패 횟수로 평가됩니다. 성능은 전체 작업 실행 시간과 테스트 데이터 처리 시 시스템 응답 시간을 측정하여 평가됩니다.
검증 및 자격 부여의 주요 목적은 시스템이 "목적에 적합"하다는 것을 확인하는 것입니다. 소프트웨어 시스템이 의도된 목적을 준수한다고 해서 오류가 전혀 없다는 의미는 아닙니다. 오히려 시스템은 의도된 목적을 합리적으로 잘 수행해야 합니다. 요구 수준 규정 준수의 신뢰성시스템의 목적, 사용자의 기대, 소프트웨어 시장의 조건에 따라 달라집니다.
1. 소프트웨어의 목적.규정 준수에 대한 확신 수준은 개발 중인 소프트웨어가 특정 기준에 따라 얼마나 중요한지에 따라 달라집니다. 예를 들어, 안전이 중요한 시스템에 대한 신뢰 수준은 몇 가지 새로운 아이디어를 보여주기 위해 개발된 프로토타입 소프트웨어 시스템에 대한 신뢰 수준보다 훨씬 높아야 합니다.
2. 사용자 기대.현재 대부분의 사용자의 소프트웨어 요구 사항이 낮다는 점은 안타깝습니다. 사용자는 프로그램이 실행되는 동안 발생하는 오류에 너무 익숙해서 이에 놀라지 않습니다. 시스템 사용의 이점이 단점보다 크다면 시스템 오류를 기꺼이 용납합니다. 그러나 1990년대 초반부터 소프트웨어 시스템의 오류에 대한 사용자의 허용 범위가 점차 감소하고 있습니다. 최근에는 신뢰할 수 없는 시스템을 만드는 것이 사실상 용납되지 않기 때문에 소프트웨어 제품을 개발하는 기업은 소프트웨어 검증 및 인증에 점점 더 많은 관심을 기울여야 합니다.
3. 소프트웨어 시장 상황.소프트웨어 시스템을 평가할 때 판매자는 경쟁 시스템, 구매자가 시스템에 대해 지불할 의사가 있는 가격, 시스템 출시 목표 날짜를 알아야 합니다. 개발 회사에 여러 경쟁업체가 있는 경우 전체 테스트 및 디버깅이 끝나기 전에 시스템이 시장에 출시될 날짜를 결정해야 합니다. 그렇지 않으면 경쟁업체가 가장 먼저 시장에 진입할 수 있습니다. 고객이 높은 가격에 소프트웨어를 구입하는 것을 꺼린다면 시스템 오류를 더 많이 감수할 의향이 있을 수 있습니다. 검증 및 인증 프로세스 비용을 결정할 때 이러한 모든 요소를 고려해야 합니다.
원칙적으로 검증 및 인증 과정에서 시스템에서 오류가 발견됩니다. 오류를 수정하기 위해 시스템을 변경하고 있습니다. 이것 디버깅 프로세스일반적으로 다른 검증 및 자격 프로세스와 통합됩니다. 그러나 테스트(또는 보다 일반적으로 확인 및 인증)와 디버깅은 서로 다른 목표를 가진 서로 다른 프로세스입니다.
1. 검증 및 인증은 소프트웨어 시스템의 결함을 발견하는 프로세스입니다.
2. 디버깅은 결함(오류)을 국지화하고 수정하는 과정입니다(그림 20.2).
쌀. 20.2. 디버깅 프로세스
프로그램을 디버깅하는 간단한 방법은 없습니다. 숙련된 디버거는 테스트 출력 패턴을 테스트 중인 시스템의 출력과 비교하여 오류를 감지합니다. 오류를 찾으려면 오류 유형, 출력 패턴, 프로그래밍 언어 및 프로그래밍 프로세스에 대한 지식이 필요합니다. 소프트웨어 개발 프로세스에 대한 지식은 매우 중요합니다. 디버거는 가장 일반적인 프로그래머 오류(예: 카운터 값 증가와 관련된 오류)를 알고 있습니다. 특정 프로그래밍 언어의 일반적인 오류(예: C 언어의 포인터 사용과 관련된 오류)도 고려됩니다.
프로그램 코드에서 오류를 찾는 것은 항상 쉬운 과정은 아닙니다. 오류가 반드시 문제가 발생한 프로그램 코드 위치 근처에 있는 것은 아니기 때문입니다. 오류를 지역화하기 위해 디버거 프로그래머는 프로그램 오류의 원인을 식별하는 데 도움이 되는 추가 소프트웨어 테스트를 개발합니다. 프로그램 실행을 수동으로 추적해야 할 수도 있습니다.
대화형 디버깅 도구는 코드 컴파일 시스템과 통합된 언어 지원 도구 세트의 일부입니다. 이는 식별자 테이블과 거기에서 변수 값에 액세스할 수 있는 특수 프로그램 실행 환경을 제공합니다. 사용자는 명령문에서 명령문으로 순차적으로 이동하면서 단계별 방식으로 프로그램 실행을 제어하는 경우가 많습니다. 각 명령문이 실행된 후 변수의 값을 확인하고 가능한 오류를 식별합니다.
프로그램에서 발견된 오류를 수정한 후 프로그램을 다시 확인해야 합니다. 이렇게 하려면 프로그램을 다시 검사하거나 이전 테스트를 반복하면 됩니다. 재테스트는 프로그램 변경으로 인해 시스템에 새로운 버그가 발생하지 않았는지 확인하는 데 사용됩니다. 실제로는 높은 비율의 "버그 수정"이 완전히 실패하거나 프로그램에 새로운 버그가 발생하기 때문입니다.
원칙적으로 각 수정 후 다시 테스트하는 동안 모든 테스트를 다시 실행해야 하지만 실제로 이 방법은 비용이 너무 많이 듭니다. 따라서 테스트 프로세스를 계획할 때 시스템 부분 간의 종속성을 결정하고 각 부분에 테스트를 할당합니다. 그런 다음 해당 요소에 맞춰진 특수 테스트 케이스(테스트 데이터)를 사용하여 소프트웨어 요소를 추적할 수 있습니다. 추적 결과가 문서화되면 전체 테스트 데이터 세트 중 일부만 사용하여 변경된 소프트웨어 요소와 해당 종속 구성 요소를 테스트할 수 있습니다.
검증(정확성 확인) - 사양에 제시된 일련의 공식 설명과 관련하여 개발된 프로그램의 정확성을 확인 및 증명하고 이 프로그램의 입력 및 출력 데이터 간의 관계를 완전히 정의하는 것으로 구성됩니다. 이 경우 프로그램의 입력과 출력에서 변수 간의 관계는 테스트에서와 같이 값의 형태로 분석되는 것이 아니라 제어되는 이러한 변수를 처리하는 동안 나타나는 속성에 대한 설명의 형태로 분석됩니다. 프로그램에서.
원칙적으로 프로그램을 검증하면 테스트 및 디버깅이 필요하지 않습니다. 동시에 모든 변수에 대한 더 높은 수준의 개념 및 설명에서 프로세스의 정확성, 처리 및 변환이 확립되기 때문입니다.
각 프로그램의 본질은 입력 데이터와 출력 데이터 간의 관계에 대한 설명으로 표현될 수 있습니다. 이러한 관계는 1개의 소프트웨어 사양으로 공식화됩니다. 실제 개발에서는 이러한 관계를 형식화하는 것도 나쁘지 않으며, 프로그램 개발 과정에서 일부 관계가 명확해진다. 이렇게 불완전하게 정의된 것만으로는 프로그램의 정확성을 증명하기에 충분하지 않습니다. 모든 조건과 입력 데이터와 출력 데이터 간의 연결을 완전하고 정확하게 공식화해야만 자동 검증에 사용할 수 있습니다.
귀납적 진술 방법.
이 방법을 연구하기 위해 프로그램에는 특정 지점에서 변수의 속성에 대한 설명이 제공됩니다.
a) 입력 변수는 프로그램 실행 중에 변경되지 않습니다.
b) 중간 지점의 변수 상태가 설명됩니다.
c) 출력 변수는 프로그램이 완료된 후 변수 간의 관계를 사용하여 설명됩니다.
검증은 첫 번째 단계에서 수행된 입력 변수와 변환을 통해 다음 중간 지점에서 형성된 진술의 진실이 이어지는 것을 순차적으로 입증하는 것으로 구성됩니다.
프로그램을 확인하려면 세 가지 언어가 필요합니다.
· 프로그램 텍스트 작성을 위한 언어
· 검증 조건을 공식화하기 위한 언어
· 형성 언어 및 정확성 증명.
이러한 언어는 상당히 다르기 때문에 이러한 상황은 검증 적용 중 하나입니다.
정확성 증명에는 다음과 같은 장점이 있습니다.
1. 명확하게 공식화된 프로세스를 나타냅니다.
2. 분석이 필요합니다. 정확성 증명 프로세스를 통해 무작위로 분석될 프로그램의 일부를 검사할 수 있습니다.
3. 계산의 중간 결과를 명확히 합니다. 표현식을 작성하면 프로그래머는 프로그램의 선택된 지점에서 계산 결과에 대한 가정을 명확하게 공식화할 수 있습니다.
4. 종속성을 식별합니다. 프로그램을 증명하는 과정에서 프로그램의 다양한 부분에서 입력 데이터에 대한 어떤 가정이 명시적으로 테스트되지 않았는지 이해하기 시작합니다.
이 방법의 단점:
1. 난이도 작은 것에도 간단한 프로그램계산이 매우 복잡하여 오류가 발생할 수 있습니다.
2. 오류 방법의 복잡성으로 인해 증명되는 진술의 구성과 증명 모두에서 실수를 저지르기 쉽습니다.
3. 어레이 작업의 어려움.
4. 강력한 수학적 장치가 부족합니다.
5. 높은 노동 강도: 프로그램을 테스트하는 데는 작성하는 것보다 더 많은 노동력이 필요합니다(2~6회).
6. 표현력이 부족합니다. 직관적으로 매우 간단한 계산으로 보이는 것에 대해 수익성 있는 설명을 공식화하는 것은 종종 쉽지 않습니다.
7. 이해가 어렵다.
8. 훈련의 필요성. 이 방법에는 광범위한 훈련과 훈련이 필요합니다.
이 과정의 목적은 소프트웨어 검증 프로세스에 대한 포괄적인 관점을 제시하는 것입니다. 논의 주제는 검증 분야, 특히 소프트웨어 테스트에서 사용되는 다양한 접근 방식과 방법입니다. 개발중인 소프트웨어는 더 많은 것의 일부라고 가정됩니다. 공통 시스템. 이러한 시스템에는 하드웨어, 정보 및 조직(사람 사용자, 사람 운영자 등) 구성 요소가 포함되며, 다른 팀에서 개발할 수도 있습니다. 따라서 시스템의 다양한 구성 요소에 대한 요구 사항과 상호 작용 규칙을 정의하는 개발 문서가 필요합니다. 또한 시스템 오류는 심각도에 따라 다른 결과를 초래할 수 있다고 가정하므로 소프트웨어 개발 중에 숨겨진 결함을 식별하는 데 드는 노력이 필요하고 정당합니다. 우선 이는 소프트웨어 검증 도구 및 절차에 관한 것입니다. 이 과정에는 여러 가지가 포함되어 있습니다. 실습 수업에서는 간단한 시스템을 예로 들어 소프트웨어 테스터용 Microsoft Visual Studio 2005 Team Edition 환경의 소프트웨어 검증 기술과 방법을 설명합니다. 이 출판물은 MSDN AA(MSDN Academic Alliance) 학술 협력 프로그램의 일부로 개발 중인 강좌 라이브러리의 일부입니다.
아래 텍스트는 원본 PDF 문서에서 자동 추출되어 얻어지며 미리보기용입니다.
이미지(그림, 수식, 그래프)가 없습니다.
쌀. 7 테스트, 검증 및 검증 소프트웨어 검증 – 기타 일반적인 개념테스트보다. 검증의 목적은 검증 대상 항목(요구사항 또는 프로그램 코드)이 요구사항을 충족하는지, 의도하지 않은 기능이 없이 구현되었는지, 설계 사양 및 표준을 만족하는지 확인하는 것입니다. 검증 프로세스에는 검사, 코드 테스트, 테스트 결과 분석, 문제 보고서 생성 및 분석이 포함됩니다. 따라서 일반적으로 테스트 프로세스는 다음과 같습니다. 중요한 부분검증 과정에서는 본 교육과정에서도 동일한 가정을 합니다. 소프트웨어 시스템 검증은 시스템 개발의 결과로 우리가 시스템 사용을 통해 달성하려고 계획한 목표를 달성했음을 입증하는 것이 목적인 프로세스입니다. 즉, 검증은 시스템이 고객의 기대를 충족하는지 확인하는 것입니다. 검증과 관련된 문제는 이 범위를 벗어납니다. 훈련 과정연구를 위해 별도의 흥미로운 주제를 나타냅니다. 답변하는 질문의 측면에서 이 세 가지 프로세스를 살펴보면 테스트는 "어떻게 수행됩니까?"라는 질문에 답변합니다. 또는 “개발된 프로그램의 동작이 요구사항을 만족하는가?”, 검증 – “무엇이 이루어졌는가?” 또는 "개발된 시스템이 요구 사항을 충족합니까?", 검증은 "필요한 작업을 수행했습니까?"입니다. 또는 “개발된 시스템이 고객의 기대를 충족시키는가?” 1.7. 라이프사이클의 다양한 단계에서 생성된 문서 모든 개발 단계의 동기화는 각 단계에서 생성된 문서를 통해 이루어집니다. 문서도 직선으로 생성됩니다. 수명주기– 소프트웨어 시스템을 개발하는 동안, 그 반대의 경우 – 검증하는 동안. V자형 라이프사이클의 예를 통해 각 세그먼트에서 어떤 유형의 문서가 생성되고, 이들 사이에 어떤 관계가 존재하는지 추적해 보겠습니다(그림 8). 시스템 요구사항 개발 단계의 결과는 공식화된 시스템 요구사항입니다. 일반 원칙시스템 작동, " 환경» - 시스템 사용자, 시스템 작동을 보장하는 소프트웨어 및 하드웨어. 일반적으로 시스템 요구 사항과 병행하여 검증 계획이 생성되고 검증 전략이 정의됩니다. 이 문서는 다음을 정의합니다. 일반적인 접근 테스트를 수행하는 방법, 어떤 기술을 사용할 것인지, 미래 시스템의 어떤 측면을 주의 깊게 테스트해야 하는지 등을 설명합니다. 검증 전략을 정의함으로써 해결되는 또 다른 작업은 다양한 검증 프로세스의 위치와 개발 프로세스와의 연결을 결정하는 것입니다. 20 시스템 요구사항을 다루는 검증 프로세스는 요구사항을 검증하고 이를 고객의 실제 기대치와 비교하는 프로세스입니다. 앞서 검증 프로세스는 완성된 시스템을 고객에게 전달할 때 수행되는 승인 테스트와 다르지만 이러한 테스트의 일부로 간주될 수 있다고 가정해 보겠습니다. 검증은 고객의 관점에서 시스템 구현의 정확성뿐만 아니라 개발 기본 원칙의 정확성도 입증하는 수단입니다. 쌀. 8 소프트웨어 시스템 개발의 프로세스 및 문서 시스템 요구사항은 기능 요구사항 및 프로젝트 아키텍처 개발 프로세스의 기초입니다. 이 과정에서 시스템 소프트웨어에 대한 일반 요구 사항과 시스템 소프트웨어가 수행해야 하는 기능이 개발됩니다. 기능적 요구 사항에는 정상 및 비정상 상황에서의 시스템 동작 패턴 정의, 데이터 처리 규칙 및 사용자 인터페이스 정의가 포함되는 경우가 많습니다. 요구 사항 텍스트에는 일반적으로 "반드시, 필수"라는 단어가 포함되며 "ABC 센서의 온도 값이 섭씨 30도 이상에 도달하면 시스템은 오디오 신호 발행을 중지해야 합니다."라는 형식의 구조를 갖습니다. ” 기능적 요구 사항은 시스템 아키텍처를 개발하기 위한 기초입니다. 즉, 구현이 수행되는 언어의 하위 시스템 및 구조 단위(영역, 클래스, 모듈, 기능 등) 측면에서 구조를 설명합니다. 기능 요구 사항을 기반으로 테스트 요구 사항이 작성됩니다. 기능 요구 사항의 올바른 구현을 보장하기 위해 확인해야 하는 핵심 사항의 정의가 포함된 문서입니다. 종종 테스트 요구 사항은 "Test That"이라는 단어로 시작하고 해당 기능 요구 사항에 대한 참조를 포함합니다. 위의 기능 요구 사항에 대한 테스트 요구 사항의 예는 "ABC 센서의 온도가 섭씨 30도 미만으로 떨어지면 시스템에서 경고 신호음이 나는지 확인" 및 "ABC 센서의 온도 값이 섭씨 30도 이상일 때 확인"입니다. 섭씨 온도” 이면 시스템에서 소리 신호가 생성되지 않습니다." 21 테스트 요구사항을 작성할 때 발생하는 문제 중 하나는 일부 요구사항의 근본적인 테스트 불가능성입니다. 예를 들어 "사용자 인터페이스는 직관적이어야 합니다"라는 요구사항은 직관적인 인터페이스를 구성하는 요소에 대한 명확한 정의 없이는 검증할 수 없습니다. 이러한 비특정 기능 요구사항은 일반적으로 이후에 수정됩니다. 시스템의 아키텍처 기능은 시스템의 소프트웨어 구현 기능을 고려하는 테스트 요구 사항을 생성하기 위한 소스 역할을 할 수도 있습니다. 이러한 요구 사항의 예는 "ABC 센서의 온도 값이 255를 초과하지 않는지 확인하십시오."입니다. 기능 요구 사항 및 아키텍처를 기반으로 시스템 코드가 작성되고 이를 검증하기 위해 테스트 요구 사항을 기반으로 테스트 계획이 준비됩니다. 이는 시스템 구현이 요구 사항을 준수하는지 확인하는 테스트 사례 시퀀스에 대한 설명입니다. 각 테스트 케이스에는 시스템 입력에 제공되는 값에 대한 구체적인 설명, 출력에서 예상되는 값, 테스트 실행 시나리오에 대한 설명이 포함되어 있습니다. 테스트 대상에 따라 테스트 계획은 일부 프로그래밍 언어로 된 프로그램 형식 또는 테스트 중인 시스템을 실행하고 해당 시스템에 값을 전송하는 툴킷용 입력 데이터 파일 형식으로 준비될 수 있습니다. 테스트 계획에 명시되거나 시스템의 다양한 기능을 테스트하기 위해 수행해야 하는 필수 작업을 설명하는 사용자 시스템에 대한 지침 형식으로 지정됩니다. 모든 테스트 케이스를 실행한 결과, 테스트 성공에 대한 통계가 수집됩니다. 즉, 실제 출력 값이 예상 출력 값과 일치하는 테스트 케이스의 비율, 즉 소위 통과된 테스트에 대한 통계가 수집됩니다. 실패한 테스트는 오류의 원인을 분석하고 그에 따른 수정을 위한 초기 데이터입니다. 통합 단계에서는 개별 시스템 모듈이 하나의 전체로 조립되고 시스템의 전체 기능을 확인하는 테스트 케이스가 실행됩니다. 마지막 단계에서는 완성된 시스템이 고객에게 전달됩니다. 구현에 앞서 고객 전문가는 개발자와 함께 승인 테스트를 수행합니다. 이들은 사전 승인된 테스트 프로그램에 따라 사용자에게 중요한 기능을 확인합니다. 테스트가 성공적으로 완료되면 시스템이 고객에게 전달되고, 그렇지 않으면 수정을 위해 보내집니다. 1.8. 테스트 및 검증 프로세스의 유형과 다양한 수명주기 모델에서의 위치 1.8.1. 단위 테스트 작은 모듈(프로시저, 클래스 등)은 단위 테스트를 받습니다. 100~1000줄 크기의 상대적으로 작은 모듈을 테스트할 때 전부는 아니더라도 구현 시 최소한 많은 논리적 분기, 데이터 종속성 그래프의 다양한 경로, 매개변수의 경계값을 확인할 수 있습니다. 이에 따라 테스트 범위 기준이 구성됩니다(모든 연산자, 모든 논리적 분기, 모든 경계 지점 등이 포함됨). . 단위 테스트는 일반적으로 각 독립 소프트웨어 모듈에서 수행되며 특히 중소 규모 시스템의 경우 가장 일반적인 테스트 유형일 것입니다. 1.8.2. 통합 테스트 불행하게도 모든 모듈의 정확성을 확인한다고 해서 모듈 시스템의 올바른 기능이 보장되는 것은 아닙니다. 문헌에서는 종종 "큰 도약" 방법이라고 불리는 모듈 시스템 테스트의 부적절한 구성에 대한 "고전적인" 모델을 논의합니다. 이 방법의 핵심은 먼저 각 모듈을 개별적으로 테스트한 다음 이를 시스템으로 결합하고 전체 시스템을 테스트하는 것입니다. 대규모 시스템의 경우 이는 비현실적입니다. 이 접근 방식을 사용하면 오류를 현지화하는 데 많은 시간이 소요되고 테스트 품질은 낮게 유지됩니다. "큰 도약"의 대안은 통합 테스트로, 시스템이 단계적으로 구축될 때 모듈 그룹이 점진적으로 추가됩니다. 1.8.3. 시스템 테스트 완전히 구현된 소프트웨어 제품은 시스템 테스트를 받습니다. 이 단계에서 테스터는 개별 절차와 방법의 올바른 구현에 관심이 없지만 최종 사용자가 보는 것처럼 전체 프로그램 전체에 관심이 있습니다. 테스트는 다음을 기반으로 합니다. 일반적인 요구 사항기능의 올바른 구현뿐만 아니라 성능, 응답 시간, 실패에 대한 저항, 공격, 사용자 오류 등을 포함하여 프로그램에 적용됩니다. 시스템 및 구성 요소 테스트의 경우 특정 유형의 테스트 적용 범위 기준이 사용됩니다(예: 모든 일반적인 작업 시나리오가 포함됨, 비정상적인 상황이 포함된 모든 시나리오, 시나리오의 쌍별 구성 등). 1.8.4. 부하 테스트 부하 테스트는 아키텍처 결정을 안내하는 부하 시 시스템 성능에 대한 예측 데이터를 제공할 뿐만 아니라 가장 생산적인 하드웨어 및 소프트웨어 구성 생성을 담당하는 프로젝트 및 구성 관리자는 물론 기술 지원 팀에 운영 정보도 제공합니다. 로드 테스트를 통해 개발 팀은 최적의 아키텍처 구성 개발을 목표로 더 많은 정보를 바탕으로 결정을 내릴 수 있습니다. 고객은 실제 조건과 가까운 조건에서 승인 테스트를 수행할 수 있는 기회를 얻습니다. 1.8.5. 정식 검사 정식 검사는 소프트웨어 개발 과정에서 생성된 문서와 프로그램 코드를 검증하는 방법 중 하나입니다. 공식 검사 중에 전문가 팀이 검사된 문서와 원본 문서의 일치성을 독립적으로 확인합니다. 검사의 독립성은 검사 대상 문서 개발에 참여하지 않은 검사관이 수행한다는 사실로 보장됩니다. 1.9. 인증된 소프트웨어의 검증을 결정하는 몇 가지 정의를 제시해 보겠습니다. 일반 구조소프트웨어 인증 프로세스: 소프트웨어 인증은 소프트웨어 개발이 지정된 요구 사항에 따라 수행되었음을 확립하고 공식적으로 인정하는 프로세스입니다. 인증 과정에서 신청자, 인증 기관 및 감독 기관 사이에 상호 작용이 있습니다. 신청자는 해당 인증 기관에 인증서(적합성, 품질, 적합성 등)를 받기 위해 신청서를 제출하는 조직입니다. 제품. 인증 기관은 신청자의 소프트웨어 인증 신청을 고려하고 독립적으로 또는 특별 위원회를 구성하여 신청자의 소프트웨어 인증 프로세스를 수행하기 위한 일련의 절차를 수행하는 조직입니다. 23 감독 기관 - 인증 신청자의 개발 프로세스를 모니터링하는 전문가 위원회 정보 시스템그리고 이 프로세스가 특정 요구 사항을 준수하는지에 대한 의견을 제시하며, 이는 인증 기관에 제출됩니다. 인증은 적합성 인증서 또는 품질 인증서를 획득하는 것을 목표로 할 수 있습니다. 첫 번째 경우, 인증 결과는 특정 기준에 따라 개발 프로세스가 준수되고 특정 요구 사항에 따라 시스템 기능이 인정되는 것입니다. 그러한 요구 사항의 예는 지침 문서일 수 있습니다. 연방 서비스 소프트웨어 시스템 보안 분야의 기술 및 수출 통제에 관한 것입니다. 두 번째 경우에는 제조된 제품의 적절한 품질 수준과 특정 조건에서의 사용 적합성을 보장하는 특정 기준에 따라 개발 프로세스가 준수된다는 사실이 인정됩니다. 이러한 표준의 예로는 일련의 국제 품질 표준 ISO 9000:2000(GOST R ISO 9000-2001) 또는 항공 표준 DO-178B, AS9100, AS9006이 있습니다. 인증 가능한 소프트웨어 테스트에는 두 가지 보완적인 목적이 있습니다. 첫 번째 목적은 소프트웨어가 요구 사항을 충족하는지 입증하는 것입니다. 두 번째 목표는 시스템 결함 안전 평가 프로세스에 의해 정의된 허용할 수 없는 오류 상황으로 이어질 수 있는 오류가 테스트 프로세스 중에 식별된다는 것을 높은 수준의 확신을 가지고 입증하는 것입니다. 예를 들어, DO-178B는 소프트웨어 테스팅 목표를 충족하기 위해 다음을 요구합니다. 테스트는 주로 소프트웨어 요구 사항을 기반으로 해야 합니다. 테스트는 올바른 기능을 확인하고 잠재적인 오류를 노출하도록 설계되어야 합니다. 소프트웨어 요구 사항을 기반으로 한 테스트의 완전성을 분석하면 어떤 요구 사항이 테스트되지 않는지 결정해야 합니다. 프로그램 코드의 구조를 기반으로 테스트의 완성도를 분석하면 테스트 중에 어떤 구조가 실행되지 않았는지 결정해야 합니다. 이 표준은 요구 사항 기반 테스트에 대해서도 설명합니다. 이 전략은 오류를 식별하는 데 가장 효과적인 것으로 밝혀졌습니다. 요구 사항을 기반으로 테스트 사례를 선택하는 지침에는 다음이 포함됩니다. 소프트웨어 테스팅의 목적을 달성하려면 두 가지 범주의 테스트, 즉 정상적인 상황에 대한 테스트와 비정상적인(요구 사항이 아닌, 견고한) 상황에 대한 테스트를 수행해야 합니다. 소프트웨어 개발 프로세스에 내재된 소프트웨어 요구 사항 및 오류 소스에 대해 특정 테스트 사례를 개발해야 합니다. 정상적인 상황에 대한 테스트의 목적은 필요에 따라 정상적인 입력 및 조건에 응답하는 소프트웨어의 능력을 입증하는 것입니다. 24 비정상적인 상황에 대한 테스트의 목적은 비정상적인 입력 및 조건에 적절하게 대응하는 소프트웨어의 능력을 입증하는 것입니다. 즉, 시스템 오류를 유발해서는 안 됩니다. 시스템의 고장 범주는 항공기와 탑승자에 대한 고장 상황의 심각도를 결정하여 설정됩니다. 소프트웨어의 오류로 인해 오류 상황이 발생할 수 있습니다. 따라서 안전한 작동에 필요한 소프트웨어 무결성 수준은 시스템의 오류 상황과 관련이 있습니다. 실패 상황에는 사소한 것부터 심각한 것까지 5가지 수준이 있습니다. 이러한 수준에 따라 소프트웨어 중요도 수준의 개념이 도입됩니다. 중요도 수준에 따라 인증 기관에 제공되는 문서의 구성이 결정되고 이에 따라 시스템 개발 및 검증 프로세스의 깊이가 결정됩니다. 예를 들어, DO-178B의 가장 낮은 중요도 수준까지 인증하는 데 필요한 문서 유형 수와 시스템 개발 작업량은 가장 낮은 수준의 인증에 필요한 수 및 양과 1~2배 정도 다를 수 있습니다. 높은 레벨. 특정 요구사항은 인증이 계획된 표준에 따라 결정됩니다. 25 TOPIC 2. 프로그램 코드 테스트 (2~5강) 2.1. 프로그램 코드 테스트의 작업 및 목표 프로그램 코드 테스트는 프로그램 코드를 실행하는 프로세스로, 기존 결함을 식별하는 것을 목표로 합니다. 여기서 결함은 특정 조건에서 실행하면 예기치 않은 시스템 동작(예: 요구 사항을 충족하지 않는 동작)으로 이어지는 프로그램 코드의 섹션으로 이해됩니다. 시스템의 예기치 않은 동작으로 인해 오작동 및 오류가 발생할 수 있으며, 이 경우 프로그램 코드에 심각한 결함이 있음을 나타냅니다. 일부 결함은 시스템 기능을 방해하지 않는 사소한 문제를 일으키지만 시스템 작업을 다소 어렵게 만듭니다. 이 경우 중간 또는 사소한 결함에 대해 말합니다. 이 접근 방식을 사용한 테스트 작업은 시스템 결함이 나타나는 조건을 결정하고 이러한 조건을 기록하는 것입니다. 테스트 작업에는 일반적으로 프로그램 코드의 특정 결함 부분 식별이 포함되지 않으며 결함 수정도 포함되지 않습니다. 이는 시스템 테스트 결과를 기반으로 수행되는 디버깅 작업입니다. 프로그램 코드 테스트 절차를 사용하는 목적은 최종 제품의 결함 수, 특히 중요한 결함 수를 최소화하는 것입니다. 테스트만으로는 보장할 수 없음 완전 결석시스템 코드의 결함. 그러나 불일치와 불완전성을 제거하기 위한 검증 및 검증 프로세스와 결합하여 프로젝트 문서(특히 시스템 요구 사항) 잘 구성된 테스트를 통해 시스템이 요구 사항을 충족하고 모든 의도된 상황에서 이에 따라 작동하는지 확인합니다. 예를 들어 항공 시스템과 같이 신뢰성이 향상된 시스템을 개발할 때 테스트 프로세스의 명확한 구성, 다른 수명주기 프로세스와의 연결 확인, 테스트 성공을 평가할 수 있는 정량적 특성 도입을 통해 신뢰성 보장이 달성됩니다. 또한 시스템의 신뢰성(중요도 수준)에 대한 요구 사항이 높을수록 요구 사항이 더 엄격해집니다. 따라서 우선 우리는 특정 시스템을 테스트한 구체적인 결과를 고려하는 것이 아니라 일반 조직 테스트 프로세스는 "잘 구성된 프로세스가 품질 결과를 생성합니다"라는 접근 방식을 사용합니다. 이러한 접근 방식은 많은 국제 및 업계 품질 표준에 공통적으로 적용되며, 이에 대한 자세한 내용은 이 과정의 마지막 부분에서 논의됩니다. 이 접근 방식을 사용하여 개발된 시스템의 품질은 독립적이고 통제할 수 없는 결과가 아니라 체계적인 개발 및 테스트 프로세스의 결과입니다. 최신 소프트웨어 시스템은 상당히 크기 때문에 프로그램 코드를 테스트할 때 기능적 분해 방법이 사용됩니다. 시스템은 요구 사항에 따라 정의된 기능과 인터페이스를 갖는 별도의 모듈(클래스, 네임스페이스 등)로 나뉩니다. 그 후, 각 모듈은 개별적으로 테스트됩니다. 단위 테스트가 수행됩니다. 그런 다음 개별 모듈을 더 큰 구성으로 조립합니다. 통합 테스트가 수행되고, 마지막으로 시스템 전체가 테스트됩니다. 시스템 테스트가 수행됩니다. 코드 관점에서 볼 때 단위, 통합 및 시스템 테스트는 공통점이 많으므로 이 주제에서는 단위 테스트에 중점을 두고 통합 및 시스템 테스트의 기능은 나중에 설명합니다. 26 단위 테스트 중에 각 모듈은 요구 사항 준수 여부와 시스템 오류 및 오작동을 일으킬 수 있는 프로그램 코드의 문제 영역이 없는지 테스트됩니다. 일반적으로 모듈은 시스템 외부에서 작동하지 않습니다. 다른 모듈로부터 데이터를 수신하여 처리하고 추가로 전송합니다. 한편으로는 시스템에서 모듈을 격리하고 잠재적인 시스템 오류의 영향을 제거하는 한편, 모듈에 필요한 모든 데이터를 제공하기 위해 테스트 환경이 사용됩니다. 테스트 환경의 임무는 모듈에 대한 런타임 환경을 생성하고 모듈이 액세스하는 모든 외부 인터페이스를 에뮬레이트하는 것입니다. 이 주제에서는 테스트 환경 구성 기능에 대해 설명합니다. 일반적인 테스트 절차는 테스트 케이스 준비 및 실행(단순히 테스트라고도 함)으로 구성됩니다. 각 테스트 예제는 모듈 동작에서 하나의 "상황"을 확인하고 모듈의 입력으로 전달된 값 목록, 데이터 처리 시작 및 실행에 대한 설명(테스트 스크립트) 및 다음 목록으로 구성됩니다. 모듈이 올바르게 작동할 경우 모듈의 출력에서 예상되는 값입니다. 테스트 스크립트는 모듈의 내부 데이터에 대한 액세스를 제외하는 방식으로 컴파일됩니다. 모든 상호 작용은 외부 인터페이스를 통해서만 이루어져야 합니다. 테스트 케이스의 실행은 테스트 스크립트의 소프트웨어 구현을 포함하는 테스트 환경에서 지원됩니다. 실행은 입력 데이터를 모듈에 전달하고 스크립트를 실행하는 것으로 시작됩니다. 스크립트 실행 결과로 모듈로부터 수신된 실제 출력 데이터를 저장하고 예상한 것과 비교합니다. 일치하면 테스트는 통과된 것으로 간주되고, 그렇지 않으면 실패한 것으로 간주됩니다. 실패한 각 테스트는 테스트 중인 모듈, 테스트 환경 또는 테스트 설명의 결함을 나타냅니다. 테스트 케이스에 대한 일련의 설명은 소프트웨어 모듈의 테스트 절차를 정의하는 기본 문서인 테스트 계획을 구성합니다. 테스트 계획은 테스트 케이스 자체뿐 아니라 케이스가 나타나는 순서도 지정하는데, 이는 또한 중요할 수 있습니다. 이 주제에서는 테스트 계획의 구조와 기능에 대해 논의하고, 테스트 케이스 순서와 관련된 문제는 "반복성 테스트" 주제에서 논의할 것입니다. 테스트할 때 시스템 요구 사항뿐만 아니라 테스트 중인 모듈의 프로그램 코드 구조도 고려해야 하는 경우가 많습니다. 이 경우 테스트는 다음을 감지하는 방식으로 설계되었습니다. 전형적인 실수요구 사항의 잘못된 해석으로 인해 프로그래머가 발생했습니다. 경계 조건 검사와 동등 클래스 검사가 사용됩니다. 요구 사항에 지정되지 않은 시스템 기능이 없다는 것은 테스트별로 프로그램 코드 적용 범위를 다르게 추정하여 보장됩니다. 모든 테스트 예제를 실행한 결과 특정 언어 구성의 몇 퍼센트가 완료되었는지 추정합니다. 이 모든 내용은 이 주제의 마지막 부분에서 논의됩니다. 2.2. 시험방법 2.2.1. 블랙박스 시스템을 블랙박스로 테스트하는 주요 아이디어는 테스터가 사용할 수 있는 모든 자료가 시스템에 대한 요구사항이며 시스템 동작과 시스템 자체를 설명하며 일부 외부 영향을 적용해야만 작업할 수 있다는 것입니다. 입력을 관찰하고 출력을 관찰하면 결과가 나옵니다. 시스템 구현의 모든 내부 기능은 테스터에게 숨겨져 있으므로 시스템은 요구 사항과 관련된 올바른 동작을 검증해야 하는 "블랙 박스"입니다. 27 소프트웨어 코드의 관점에서 블랙박스는 외부 인터페이스는 알려져 있지만 소스 코드에는 접근할 수 없는 클래스(또는 모듈) 집합일 수 있습니다. 이 테스트 방법에 대한 테스터의 주요 임무는 시스템 동작이 요구 사항을 충족하는지 지속적으로 확인하는 것입니다. 또한 테스터는 중요한 상황에서 시스템 작동을 확인해야 합니다. 잘못된 입력 값이 제공되면 어떻게 됩니까? 이상적인 상황에서는 중요한 상황의 모든 변형이 시스템 요구 사항에 설명되어야 하며 테스터는 이러한 요구 사항에 대한 특정 테스트만 제시할 수 있습니다. 그러나 실제로 테스트 결과 일반적으로 두 가지 유형의 시스템 문제가 식별됩니다. 1. 시스템 동작과 요구 사항의 불일치 2. 요구 사항에서 제공되지 않는 상황에서 시스템의 부적절한 동작. 두 가지 유형의 문제 모두 개발자에게 보고되고 보고됩니다. 동시에 첫 번째 유형의 문제는 일반적으로 프로그램 코드의 변경을 유발하며 훨씬 덜 자주 요구 사항이 변경됩니다. 요구 사항 변경 이 경우 불일치(여러 가지 요구 사항이 동일한 상황에서 시스템 동작의 다양한 모델을 설명함) 또는 부정확성(요구 사항이 현실과 일치하지 않음)으로 인해 필요할 수 있습니다. 두 번째 유형의 문제는 불완전성으로 인해 요구 사항을 변경해야 함을 의미합니다. 요구 사항은 시스템의 부적절한 동작으로 이어지는 상황을 명확하게 생략합니다. 이 경우 부적절한 행동은 시스템의 완전한 붕괴 또는 일반적으로 요구 사항에 설명되지 않은 모든 행동으로 이해될 수 있습니다. 블랙박스 테스트는 요구사항 테스트라고도 불립니다. 이는 테스트 계획 수립을 위한 유일한 정보 소스입니다. 2.2.2. 유리(흰색) 상자 유리 상자로 시스템을 테스트할 때 테스터는 시스템 요구 사항, 입력 및 출력뿐만 아니라 내부 구조에도 접근할 수 있습니다. 즉, 프로그램 코드를 볼 수 있습니다. 프로그램 코드의 가용성은 프로그램 코드 섹션의 요구 사항 준수 여부를 확인하고 전체 프로그램 코드에 대한 요구 사항이 존재하는지 확인할 수 있다는 점에서 테스터의 기능을 확장합니다. 요구사항이 없는 프로그램 코드를 요구사항에 포함되지 않는 코드라고 합니다. 이러한 코드는 부적절한 시스템 동작의 잠재적인 원인입니다. 또한 시스템의 투명성을 통해 문제를 일으키는 영역에 대한 심층적인 분석이 가능합니다. 종종 하나의 문제가 다른 문제를 무력화하고 동시에 발생하지 않습니다. 2.2.3. 모델 테스팅 모델 테스팅은 소프트웨어 검증의 전통적인 방법과 다소 다릅니다. 우선, 이는 테스트의 대상이 시스템 자체가 아니라 공식적인 수단으로 설계된 모델이라는 사실 때문입니다. 모델 자체의 정확성과 적용 가능성을 확인하는 문제를 제쳐두면(모델의 정확성과 원래 시스템과의 호환성이 공식적인 수단으로 입증될 수 있다고 믿어짐) 테스터는 분석을 위한 상당히 강력한 도구를 마음대로 사용할 수 있습니다. 시스템의 전반적인 무결성. 모델을 사용하여 실제 시스템에 대한 테스트 실험실에서 만들 수 없는 상황을 만들 수 있습니다. 시스템의 프로그램 코드 모델을 사용하여 작업하면 해당 속성과 알고리즘의 최적성 또는 안정성과 같은 시스템 매개변수를 분석할 수 있습니다. 28 그러나 시스템 동작에 대한 공식적인 설명을 개발하는 데 어려움이 있기 때문에 모델 테스트는 널리 보급되지 않았습니다. 몇 안되는 예외 중 하나는 통신 시스템인데, 그 알고리즘과 수학적 장치는 상당히 잘 발달되어 있습니다. 2.2.4. 프로그램 코드 분석(검사) 많은 상황에서 시스템의 동작을 전체적으로 테스트하는 것은 불가능합니다. 프로그램 코드의 개별 섹션은 실행되지 않을 수도 있지만 요구 사항에 따라 다루어집니다. 이러한 코드 섹션의 예로는 예외 처리기가 있습니다. 예를 들어 두 모듈이 서로 숫자 값을 전달하고 값 확인 기능이 두 모듈 모두에서 작동하는 경우 수신 모듈의 확인 기능은 활성화되지 않습니다. 모든 잘못된 값은 송신기에서 차단됩니다. 이 경우 코드 검토 또는 검사라고도 하는 프로그램 코드의 정확성에 대한 수동 분석이 수행됩니다. 검사 결과 문제 영역이 식별되면 이에 대한 정보가 정기 테스트 결과와 함께 수정을 위해 개발자에게 전송됩니다. 2.3. 테스트 환경 거의 모든 복잡한 시스템에 대한 대부분의 테스트는 일반적으로 자동 모드에서 수행됩니다. 또한 테스트 중인 시스템은 일반적으로 별도의 모듈로 나누어져 있으며, 각 모듈은 먼저 다른 모듈과 별도로 테스트된 다음 전체적으로 테스트됩니다. 이는 테스트를 수행하려면 테스트 중인 모듈의 시작 및 실행을 보장하고, 입력 데이터를 전송하고, 주어진 시스템에서 작동하는 시스템의 결과로 얻은 실제 출력 데이터를 수집하는 환경을 조성해야 함을 의미합니다. 입력 데이터. 그런 다음 환경은 실제 출력 데이터를 예상된 것과 비교해야 하며, 이 비교를 기반으로 모듈의 동작이 지정된 것과 일치하는지에 대한 결론을 내려야 합니다(그림 9). 테스트 드라이버 예상 출력 테스트됨 처리 입력 데이터 결과 모듈 실제 출력 데이터 스텁 그림. 9 테스트 환경의 일반화 된 다이어그램 테스트 환경은 전체 시스템에서 개별 시스템 모듈을 분리하는 데 사용될 수도 있습니다. 테스트 초기 단계에서 시스템 모듈을 분리하면 프로그램 코드에서 발생하는 문제를 보다 정확하게 지역화할 수 있습니다. 시스템과 분리된 모듈의 작동을 지원하려면 테스트 환경은 테스트 중인 모듈이 해당 기능이나 데이터에 액세스하는 모든 모듈의 동작을 시뮬레이션해야 합니다. 29
검증 및 검증이라는 용어는 소프트웨어 품질 확인과 관련이 있습니다. 우리는 기사와 보고서에서 이러한 용어를 사용합니다. 우리는 프로그램 소스 코드의 정적 분석을 검증과 검증으로 분류해야 하는지, 그리고 이들 개념의 차이점은 무엇인지에 대한 다양한 의견과 주장을 반복적으로 들었습니다. 일반적으로 이러한 용어에는 모든 사람이 자신의 개념을 적용하고 있으며 이는 상호 오해로 이어진다는 인상을 받습니다.
우리는 이러한 개념을 가장 정확하게 해석하기 위해 용어를 이해하기로 결정했습니다. 연구 중에 우리는 V.V. Kulyamin "소프트웨어 검증 방법". 이는 이러한 용어에 대한 자세한 설명을 제공하며, 우리는 이 작업에 제공된 정의에 더 의존하기로 결정했습니다. 다음은 확인 및 검증과 관련된 이 작업에서 일부 발췌한 것입니다.
확인 및 검증소프트웨어의 품질을 모니터링하고 오류를 탐지하는 활동입니다. 공통 목표를 가지고 있기 때문에 코스 중에 테스트된 속성, 규칙 및 제한 사항의 소스가 다르며 위반은 오류로 간주됩니다.
더 자세히 설명하려면 "소프트웨어 수명주기 인공물"이라는 용어를 소개해야 합니다. 소프트웨어 라이프사이클 아티팩트는 소프트웨어 개발 및 유지 관리 중에 생성되거나 사용되는 다양한 정보 개체, 문서 및 모델입니다. 따라서 인공물은 기술 사양, 아키텍처 설명, 모델입니다. 대상 지역모든 그래픽 언어, 소스 코드, 사용자 문서 등 개별 개발자가 소프트웨어를 만들고 분석할 때 사용하지만 다른 사람이 접근할 수 있는 문서 형식으로 기록되지 않은 다양한 모델은 인공물로 간주될 수 없습니다.
검증은 소프트웨어 개발 및 유지 관리 중에 생성된 일부 아티팩트와 이전에 생성되었거나 입력 데이터로 사용된 다른 아티팩트의 준수 여부뿐만 아니라 이러한 아티팩트 및 해당 개발 프로세스가 규칙 및 표준을 준수하는지 확인합니다. 특히, 검증은 표준 간의 적합성, 요구사항 설명( 위임 사항) 소프트웨어, 디자인 솔루션, 소스 코드, 사용자 문서 및 소프트웨어 자체의 기능. 또한 요구 사항, 설계 솔루션, 문서 및 코드는 소프트웨어를 개발할 때 해당 국가, 산업 및 조직에서 채택한 규범 및 표준에 따라 작성되었으며, 생성 과정에서 지정된 모든 작업도 확인됩니다. 표준은 필요한 방식으로 순서대로 수행되었습니다. 검증 중에 발견된 오류 및 결함은 나열된 여러 문서 간, 문서와 프로그램의 실제 작동 간, 표준과 소프트웨어 개발 및 유지 관리의 실제 프로세스 간의 불일치 또는 모순입니다. 동시에 어떤 문서가 수정 대상인지(어쩌면 둘 다) 결정하는 것은 별도의 작업입니다.
검증은 주제 영역의 법률과 소프트웨어 사용 상황의 제한 사항을 고려하여 소프트웨어 개발 및 유지 관리 중에 생성되거나 사용된 모든 아티팩트가 이 소프트웨어의 사용자 및 고객의 요구 사항과 요구 사항을 준수하는지 확인합니다. . 이러한 요구 사항과 요구 사항은 대부분 문서화되지 않습니다. 기록되면 소프트웨어 개발 프로세스의 결과물 중 하나인 요구 사항에 대한 설명으로 전환됩니다. 따라서 검증은 검증보다 덜 공식화된 활동입니다. 이는 항상 고객, 사용자, 비즈니스 분석가 또는 해당 분야 전문가(사용자, 고객 및 기타 이해 당사자의 실제 요구와 요구 사항을 충분히 표현한 것으로 간주될 수 있는 의견) 대표의 참여로 수행됩니다. 구현 방법에서는 참가자의 지식과 실제 요구 사항을 식별하기 위해 특정 기술을 사용하는 경우가 많습니다.
검증과 검증의 차이점은 그림 1에 나와 있습니다.
주어진 정의는 확인 및 검증 프로세스에 대한 IEEE 1012 표준의 정의를 일부 확장하여 얻은 것입니다. 1990년 IEEE 610.12 표준 소프트웨어 공학 용어 사전에서 검증의 정의는 거의 동일하지만 검증의 정의는 다소 다릅니다. 검증은 개발 결과 얻은 소프트웨어가 원본과의 호환성을 확인해야 한다고 말합니다. 그것에 대한 요구 사항. 이 경우 검증은 소프트웨어 엔지니어링 문헌 어디에도 언급되지 않은 검증의 특별한 경우이므로 2004년 IEEE 1012에서 수정되었기 때문에 이 정의는 부정확한 것으로 간주되어야 합니다. B. Boehm의 문구가 자주 사용됩니다.
검증은 "우리가 올바른 제품을 만들고 있는가?"라는 질문에 답하고, 검증은 "우리가 올바른 제품을 만들고 있는가?"라는 질문에 답합니다.
불행히도 이 진술의 격언은 모호함과 결합되어 있기 때문에 혼란을 가중시킵니다. 그러나 저자의 수많은 연구에서는 검증과 확인을 통해 그가 위에서 정의한 것과 거의 동일한 개념을 의미했다고 제안합니다. 이러한 불일치는 소프트웨어 엔지니어링 표준의 내용에서도 추적할 수 있습니다. 따라서 ISO 12207 표준은 테스트를 검증 유형으로 간주하지만 검증은 아닌 것으로 간주합니다. 이는 분명히 표준 사전의 부정확한 정의를 사용한 결과입니다.
결론적으로, 위의 정의에 따르면 프로그램 소스 코드의 정적 분석은 프로그램 코드가 다양한 코딩 표준을 준수하는지 확인하는 것과 같은 소프트웨어 검증에 해당한다는 점에 주목하고 싶습니다. 정적 분석은 소프트웨어 시스템 설계 단계의 결과가 앞서 공식화한 요구 사항 및 제한 사항을 준수하는지 확인합니다.
서지
- V.V. Kulyamin "소프트웨어 검증 방법". 시스템 프로그래밍 연구소 RAS 109004, Moscow, st. B. Kommunisticheskaya, 25번.
http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf - 소프트웨어 검증 및 검증을 위한 IEEE 1012-2004 표준. IEEE, 2005.
- IEEE 610.12-1990 소프트웨어 엔지니어링 용어의 표준 용어집, 수정판. IEEE, 1991년 2월.
- B. W. Boehm. 소프트웨어 공학; R&D 동향 및 국방 요구. R. Wegner, ed. 연구. 소프트웨어 기술의 방향. 캠브리지, MA:MIT 출판부, 1979.
- ISO/IEC 12207 시스템 및 소프트웨어 엔지니어링 – 소프트웨어 수명 주기 프로세스. 스위스 제네바: ISO, 2008.
화이트박스 테스트
유용성 테스트
가) 부하 테스트
성능 시험
기능 테스트
소프트웨어 테스팅
테스트는 오류를 찾으려는 의도(또는 목표)를 가지고 프로그램(또는 프로그램의 일부)을 실행하는 프로세스입니다.
테스트 유형을 분류하는 것이 관례적인 몇 가지 기준이 있습니다. 일반적으로 다음과 같은 증상이 식별됩니다.
나) 시험 대상별:
(주어진 시스템에 대한 요구 사항을 준수하기 위해 외부 요청에 대한 응답으로 소프트웨어 및 하드웨어 시스템 또는 장치의 성능 지표 및 응답 시간을 결정하거나 수집합니다)
b) 스트레스 테스트
(정상 작동 한계를 초과한 경우 시스템의 신뢰성 및 안정성을 평가합니다.)
c) 안정성 테스트
4) 사용자 인터페이스 테스트
5) 보안 테스트
6) 현지화 테스트
7) 호환성 테스트
II) 시스템에 대한 지식으로:
1) 블랙박스 테스트
(내부 구조를 알 수 없는 개체를 테스트합니다.)
(프로그램의 내부 구조를 확인하고, 프로그램 로직을 분석하여 테스트 데이터를 얻습니다)
III) 자동화 정도에 따라:
1) 수동 테스트
2) 자동화된 테스트
3) 반자동 테스트
IV) 구성 요소의 분리 정도에 따라:
1) 구성요소(단위) 테스트
2) 통합 테스트
3) 시스템 테스트
V) 테스트 시간별:
1) 알파 테스트– 풀타임 개발자나 테스터가 프로그램을 테스트하는 비공개 프로세스입니다. 알파 제품은 대개 50%만 완성되어 프로그램 코드는 있지만 디자인의 상당 부분이 누락되어 있습니다.
2) 베타 테스트– 대량 소비자에게 시장에 최종 출시되기 전에 후속 제거를 위해 작업 중 최대 오류 수를 식별하기 위해 거의 완성된 프로그램 버전을 집중적으로 사용합니다. 테스트를 위해 일반 미래 사용자 중에서 자원 봉사자를 모집합니다.
소프트웨어 검증은 테스트보다 더 일반적인 개념입니다. 검증의 목적은 검증 대상 항목(요구사항 또는 프로그램 코드)이 요구사항을 충족하는지, 의도하지 않은 기능이 없이 구현되었는지, 설계 사양 및 표준( ISO 9000-2000). 검증 프로세스에는 검사, 코드 테스트, 테스트 결과 분석, 문제 보고서 생성 및 분석이 포함됩니다. 따라서 일반적으로 테스트 프로세스는 검증 프로세스의 필수적인 부분으로 받아들여집니다.