테스트 모델테스트 케이스가 생성되는 시스템 및/또는 사용자 행동의 기능을 설명하는 논리적 구조입니다. 테스트 모델 구축은 구조를 구축하는 것으로 시작되며 승인된 구조는 테스트 케이스로 채워집니다.

모델은 일반적으로 시스템의 요구 사항 및/또는 예상되는 동작을 기반으로 구축됩니다. 테스트 모델을 구축하고 관리하는 것은 복잡한 비즈니스 로직을 가진 대규모 시스템에 적합하며 애자일 방법론을 사용하는 프로젝트에는 적용하기 어렵기 때문에 테스트 모델 관리 및 품질 보증 프로세스를 유지하는 데 드는 비용이 너무 많이 듭니다.

테스트 모델 관리는 테스트 모델의 적용 범위, 테스트 모델을 설명하는 시나리오의 품질 및 구현을 제어하는 ​​프로세스입니다.

테스트 모델 관리는 전체에 걸쳐 지속적인 프로세스입니다. 라이프 사이클제품.

테스트 모델 커버리지

모든 요구 사항의 적용 범위를 제어하기 위해 테스트 시나리오별로 요구 사항의 적용 범위를 결정하는 추적 행렬을 사용할 수 있습니다(예제 참조).
테스트 케이스를 설명하기 전에 테스트 모델의 구조를 고객과 함께 승인해야 합니다.

스크립트 품질

시나리오의 품질을 관리하기 위해서는 테스트 케이스의 서술 수준뿐만 아니라 품질도 관리해야 한다.

테스트 케이스에 대한 설명을 시작하기 전에 각 수준의 설명에 대한 요구 사항과 테스트 케이스 설명 품질에 대한 기준을 정의할 필요가 있습니다.

테스트 케이스의 가능한 설명 레벨:

4단계에서는 고객과의 합의가 합의로 대체될 수 있습니다.

테스트 케이스를 설명하기 위한 품질 기준은 다음과 같습니다.

• 테스트 케이스는 요구 사항에 따라 작성되어야 합니다.

테스트는 제품이 요구 사항을 충족하는지 확인하는 프로세스입니다. 따라서 테스트 케이스의 일반적인 설명 부분(테스트 추적 시스템에서는 일반적으로 "요약"이라는 용어가 사용됨)에서 요구 사항 텍스트의 일부와 함께 특정 요구 사항을 참조할 필요가 있습니다. 따라서 모든 프로젝트 참가자는 이 테스트 사례가 작성된 내용을 기반으로 명확해질 것입니다.

• 자세한 전제 조건 사용

테스트 케이스의 시간을 절약하는 방법은 무엇입니까?

모든 테스트 사례에 대한 형식 지정 규칙을 설정합니다. 따라서 테스트 사례는 모든 프로젝트 참가자가 쉽게 이해하고 읽을 수 있습니다. 예를 들어 프로젝트에서 다음 규칙을 입력할 수 있습니다.

• 모든 입력 매개변수는 빨간색으로 표시되어야 합니다.
• 모든 스크립트는 파란색으로 강조 표시되어야 합니다.
• 버튼, 필드, 블록의 모든 이름은 이탤릭체와 굵게 표시됩니다.
• 중요한 구절은 밑줄이 그어져 있습니다.
• 수행된 각 단계에는 예상 결과가 있어야 합니다.
• 테스트 케이스의 각 단계는 하나의 작업과 그에 대한 예상 결과만 설명해야 합니다. 저것들. 특정 단계에서 실패한 테스트 케이스를 수신할 때 오류가 발생한 조치가 명확해야 합니다.
• 예상 결과는 명확해야 합니다.

테스트 케이스는 모호하지 않아야 합니다. 모호한 해석을 허용하지 않고 모든 참가자가 명확하게 이해할 수 있는 방식으로 초안을 작성하고 공식화해야 합니다.

테스트 사례를 작성하는 데 시간이 오래 걸리면 전문가가 자신의 실수를 보지 않는 상황이 발생할 수 있습니다. 이렇게하려면 측면에서 볼 필요가 있습니다. 여기에서 도움이 될 것입니다. 교차 검토. 이 단계는 테스트 모델의 개발이 시간적으로 연장되고 시간이 오래 걸리는 경우에 수행하는 것이 좋습니다. 예를 들어 테스트 시나리오 개발에 1개월 이상 소요되는 경우.

스크립트 품질 관리 프로세스를 수행할 수 있습니다. 테스트 모델 제어 포함- 특별히 준비된 템플릿.

테스트 모델 업데이트

테스트 케이스의 우선 순위를 검토할 뿐만 아니라 요구 사항을 준수하기 위해 테스트 모델과 테스트 케이스 자체를 정기적으로 업데이트해야 합니다.

업데이트용 "요구 사항 매트릭스"를 유지할 수 있습니다.(요구사항 추적성 매트릭스): 특정 요구사항이 변경될 때마다 이 요구사항과 관련된 모든 테스트 시나리오가 테스트 추적 시스템에서 선택되고 업데이트됩니다.

테스트 모델 컨트롤:

• 테스트 레일
• 테스트 링크
• 지라+제퍼
• 마이크로소프트 테스트 매니저(MTM)
• 뛰어나다

테스트는 생산되는 제품의 품질을 평가할 수 있는 프로세스입니다. 고품질 소프트웨어 제품은 기능적 및 비기능적 모두에 대한 요구 사항을 충족해야 합니다. PS는 필요한 모든 VI를 구현해야 하며 결함이 없어야 합니다. 또한 PS는 신뢰성(hangup, crash 등이 없어야 함), 보안성, 원하는 성능 제공, 사용 용이성, 확장성 등의 속성을 가져야 한다. 따라서 테스트는 PS를 분석하는 과정이다. , 결함을 식별하고 PS의 속성을 평가하는 것을 목표로 합니다.

테스트 프로세스의 목표

테스트의 목적은 품질을 평가하는 것입니다. 소프트웨어 제품~을 통해

• 구성 요소 상호 작용 확인
• 구성 요소의 올바른 통합 확인
• 모든 요구 사항 구현의 정확성을 확인하고 결함을 식별합니다.

RUP에서 테스트 프로세스의 기능

테스트는 반복적으로 수행되는 프로세스입니다. 라이프 사이클의 모든 단계에서.테스트는 처음부터 시작됩니다 첫 단계미래 제품에 대한 요구 사항을 식별하고 현재 작업과 밀접하게 통합합니다. 각 반복에 대해 테스트 목표와 달성 방법이 결정됩니다. 각 반복이 끝날 때 이 목표가 어느 정도 달성되었는지, 추가 테스트가 필요한지, 원칙과 테스트 도구를 변경해야 하는지 여부가 결정됩니다.

발견된 각 결함은 발견된 상황에 대한 설명과 함께 프로젝트 데이터베이스에 기록됩니다. 분석가는 이것이 실제 결함인지, 이전에 발견된 결함의 반복인지 여부를 판별합니다. 발견된 결함이 할당됨 우선 순위수정의 중요성을 나타내는 A. 하위 시스템, 구성 요소 또는 클래스 개발을 담당하는 디자이너 또는 관리자가 지정한 다른 사람이 결함 수정을 진행합니다. 결함이 수정되는 순서는 우선순위에 따라 결정됩니다. 테스터는 테스트를 반복하고 결함이 수정되었음을 확신(또는 확신하지 않음)합니다.

테스트 개발자테스트 계획, 개발 및 구현을 담당합니다. 그는 테스트 계획과 모델, 테스트 절차(아래 참조)를 만들고 테스트 결과를 평가합니다.

테스터(테스터)시스템 테스트 수행을 담당합니다. 그의 책임에는 테스트 설정 및 실행, 테스트 성능 평가, 오류 복구 및 감지된 결함 기록이 포함됩니다.

유물

테스트하는 동안 다음 문서가 생성됩니다.

테스트 계획– 각 반복에서 테스트 전략을 정의하는 문서. 여기에는 현재 반복에서 테스트의 목표와 목적과 사용할 전략에 대한 설명이 포함되어 있습니다. 계획은 어떤 리소스가 필요한지 표시하고 테스트 목록을 제공합니다.

테스트 모델테스트 대상 및 방법을 나타냅니다. 이 모델에는 일련의 제어 작업, 테스트 방법, 테스트 시나리오 및 예상 결과(테스트 케이스), 테스트 스크립트 및 테스트 상호 작용에 대한 설명이 포함됩니다.

• 제어 작업– 테스트 데이터 세트, 테스트 실행 조건 및 예상 결과.
• 시험 방법– 제어 작업을 설정하고 수행하고 얻은 결과를 평가하기 위한 지침이 포함된 문서.
• 테스트 스크립트- 이것은 초기 데이터, 조건 및 일련의 작업, 예상 결과를 포함하여 테스트에 대한 간략한 설명입니다.
• 테스트 스크립트테스트 도구를 사용하여 자동화된 테스트 중에 실행되는 프로그램입니다.
• 테스트 상호 작용에 대한 설명테스트 구성 요소와 테스트 개체 간의 시간 순서대로 메시지의 흐름을 반영하는 시퀀스 또는 협력의 다이어그램입니다.

시험 결과및 테스트 실행 중에 얻은 데이터.

워크로드 모델최종 사용자가 수행하는 외부 기능, 해당 기능의 범위 및 해당 기능에 의해 생성된 워크로드를 모델링하는 데 사용됩니다. 이 모델은 실제 조건에서 시스템 작동을 시뮬레이션하는 부하 및/또는 스트레스 테스트를 수행하기 위한 것입니다.

결함- 이것은 테스트 중에 발견된 요구 사항에 대한 시스템의 비준수 사실에 대한 설명입니다. 변경 요청 유형입니다.

테스트 작업은 모든 단계의 각 반복에서 수행되지만 프로젝트의 여러 단계에서 목표와 목표는 크게 다릅니다.

프로젝트에 진입하는 단계. 이 단계에서는 테스트 준비가 수행됩니다. 여기에는 다음이 포함됩니다.

• 테스트 요구 사항 및 테스트 전략이 포함된 테스트 계획을 만듭니다. 모든 유형의 테스트(기능, 부하 등)에 대해 단일 계획을 생성하거나 각 유형에 대해 별도의 계획을 생성할 수 있습니다.
• 테스트 범위 분석.
• 품질 기준의 공식화 및 테스트 완료.
• 테스트 도구의 설치 및 작동 준비.
• 테스트 요구 사항에 따라 결정된 PS 개발 프로젝트에 대한 요구 사항 공식화.

개발 단계.이 단계의 반복에서 테스트 모델 및 관련 아티팩트의 구성이 시작됩니다. VI 모델이 이미 이 단계에 있으므로 테스트 시나리오 설계를 시작할 수 있습니다. 동시에, 일반적으로 이 단계에서 아직 완성된 PS 조각이 없기 때문에 테스트를 수행하는 것은 바람직하지 않습니다. 다음 활동이 수행됩니다.

• 테스트 시나리오 개발.
• 테스트 스크립트 생성.
• 제어 작업 개발.
• 테스트 방법 개발.
• 워크로드 모델 개발.

건설 단계.이 단계에서는 테스트해야 하는 완성된 시스템 조각과 프로토타입이 나타납니다. 동시에 거의 모든 반복에서 모든 모듈이 검사됩니다(이전에 개발 및 테스트되었으며 현재 반복에서 새 모듈이 추가됨). 이전 반복에서 적용된 테스트는 회귀 테스트, 즉 이전에 구현된 시스템 기능이 새 반복에서 유지되는지 확인하기 위한 후속 반복에서도 사용됩니다. 다음 활동이 수행됩니다.

• 각 반복에 대한 테스트 계획을 작성하십시오.
• 테스트 모델의 개선 및 추가.
• 테스트 실행.
• 발견된 결함에 대한 설명입니다.
• 테스트 결과에 대한 설명입니다.
• 테스트 결과 평가.

테스트 결과에 따라 식별된 결함을 제거하기 위해 프로그램 코드를 변경한 후 테스트를 반복합니다.

배포 단계.이 단계를 반복하면서 전체 PS를 소프트웨어 제품으로 테스트합니다. 수행된 활동은 이전 단계의 활동과 유사합니다. 결함 감지는 변경 및 재테스트의 필요성을 결정합니다. 테스트 종료 기준이 충족될 때까지 반복 프로세스가 반복됩니다.

테스트 결과는 테스트된 PS의 품질과 테스트 프로세스 자체를 결정할 수 있는 테스트 메트릭을 기반으로 평가됩니다.

악기 지원

반복 테스트 프로세스에는 여러 번의 테스트 반복이 포함되기 때문에 수동 테스트는 비효율적이며 소프트웨어 제품의 품질에 대한 철저한 평가를 허용하지 않습니다. 이는 특히 워크로드를 시뮬레이션하고 상당한 양의 데이터를 축적해야 하는 부하 및 스트레스 테스트에 해당됩니다. 솔루션은 테스트 컴파일 및 실행 자동화를 지원하는 도구를 사용하는 것입니다.

개발 프로세스와 마찬가지로 소프트웨어 사후 테스트 프로세스도 특정 방법론을 따릅니다. 이 경우 방법론이란 프로젝트에서 작업하는 동안 사용하는 원칙, 아이디어, 방법 및 개념의 다양한 조합을 의미합니다.

현재 상당히 많은 수의 다양한 테스트 접근 방식이 있으며, 각각 고유한 시작 지점, 실행 기간 및 각 단계에서 사용되는 방법이 있습니다. 그리고 둘 중 하나를 선택하는 것은 상당히 어려울 수 있습니다. 이 기사에서는 소프트웨어 테스트에 대한 다양한 접근 방식을 살펴보고 기존 다양성을 탐색하는 데 도움이 되는 주요 기능에 대해 설명합니다.

폭포수 모델(선형 순차 소프트웨어 수명 주기 모델)

Waterfall Model은 소프트웨어 개발이나 테스트뿐만 아니라 거의 모든 다른 프로젝트에 사용할 수 있는 가장 오래된 모델 중 하나입니다. 그의 기초 원리작업이 수행되는 순차적인 순서입니다. 이는 이전 단계가 성공적으로 완료된 후에만 다음 개발 또는 테스트 단계로 진행할 수 있음을 의미합니다. 이 모델은 소규모 프로젝트에 적합하며 모든 요구 사항이 명확하게 정의된 경우에만 적용됩니다. 이 방법론의 주요 장점은 경제적 효율성, 사용 용이성 및 문서 관리.

소프트웨어 테스팅 프로세스는 개발 프로세스가 완료된 후 시작됩니다. 이 단계에서 필요한 모든 테스트는 개별적으로 또는 전체적으로 구성 요소의 작동을 제어하기 위해 단위에서 시스템 테스트로 이전됩니다.

위에서 언급한 장점 외에도 이러한 테스트 접근 방식에는 단점도 있습니다. 테스트 과정에서 치명적인 오류를 발견할 가능성이 항상 있습니다. 이로 인해 시스템 구성 요소 중 하나 또는 프로젝트의 전체 논리를 완전히 변경해야 할 수도 있습니다. 그러나 폭포수 모델의 경우 이 방법론에서 이전 단계로의 복귀가 금지되어 있기 때문에 이러한 작업은 불가능합니다.

이전 기사에서 폭포수 모델에 대해 자세히 알아보세요..

V-Model(검증 및 검증 모델)

폭포 모델과 마찬가지로 V-모델은 단계의 직접적인 순서를 기반으로 합니다. 이 두 방법론의 주요 차이점은 이 경우 테스트가 해당 개발 단계와 병행하여 계획된다는 것입니다. 이 소프트웨어 테스팅 방법론에 따르면 요구사항이 정의되는 즉시 프로세스가 시작되고 정적 테스팅을 시작할 수 있게 됩니다. 이후 단계에서 가능한 소프트웨어 결함을 방지하는 검증 및 검토. 해당 제품에 대한 예상 결과와 진입 및 퇴장 기준을 정의하는 소프트웨어 개발의 각 수준에 대해 적절한 테스트 계획이 생성됩니다.

이 모델의 계획은 작업을 두 부분으로 나누는 원칙을 보여줍니다. 디자인 및 개발과 관련된 것은 왼쪽에 배치됩니다. 소프트웨어 테스트와 관련된 작업은 오른쪽에 있습니다.

이 방법론의 주요 단계는 다를 수 있지만 일반적으로 다음을 포함합니다.

• 단계 요구 사항 정의. 수락 테스트는 이 단계에 속합니다. 주요 임무는 최종 사용을 위한 시스템의 준비 상태를 평가하는 것입니다.
• 하는 단계 고수준 설계 또는 고수준 설계(HDL). 이 단계는 시스템 테스트를 말하며 통합 시스템에 대한 요구 사항 준수 평가를 포함합니다.
• 세부 설계 단계(상세 설계)는 시스템의 다양한 구성 요소 간의 상호 작용이 테스트되는 통합 테스트 단계와 병행합니다.
• 후에 코딩 단계또 다른 중요한 단계가 시작됩니다 - 단위 테스트. 소프트웨어의 개별 부품 및 구성 요소의 동작이 정확하고 요구 사항을 충족하는지 확인하는 것이 매우 중요합니다.

고려된 테스트 방법론의 유일한 단점은 테스트 단계에서 발견된 소프트웨어 결함을 제거하기 위해 적용할 수 있는 기성 솔루션이 없다는 것입니다.

증분 모델

이 방법론은 다중 캐스케이드 소프트웨어 테스트 모델로 설명할 수 있습니다. 워크플로는 여러 주기로 나뉘며 각 주기도 모듈로 나뉩니다. 각 반복은 소프트웨어에 특정 기능을 추가합니다. 증분은 세 사이클로 구성됩니다.

1. 디자인과 개발
2. 테스트
3. 구현.

이 모델에서는 다양한 버전의 제품을 동시에 개발할 수 있습니다. 예를 들어, 첫 번째 버전은 테스트 단계에 있고 두 번째 버전은 개발 중일 수 있습니다. 세 번째 버전은 동시에 설계 단계를 거칠 수 있습니다. 이 프로세스는 프로젝트가 끝날 때까지 계속될 수 있습니다.

분명히 이 방법론을 사용하려면 테스트 중인 소프트웨어에서 가능한 최대 오류 수를 최대한 빨리 감지해야 합니다. 최종 사용자에게 전달될 제품의 준비 상태를 확인해야 하는 구현 단계뿐 아니라 이러한 모든 요소는 테스트 요구 사항의 무게를 크게 증가시킵니다.

기존 방법론과 비교하여 증분 모델 몇 가지 중요한 장점이 있습니다. 테스트와 디버깅이 적은 반복을 통해 훨씬 더 쉽기 때문에 더 유연하고 요구 사항의 변경으로 인해 비용이 절감되며 소프트웨어 테스트 프로세스가 더 효율적입니다. 그러나 주목할 가치가 있습니다. 총 비용캐스케이드 모델의 경우보다 여전히 높습니다.

나선형 모델

Spiral Model은 점진적 접근 및 프로토타이핑을 기반으로 하는 소프트웨어 테스트 방법론입니다. 4단계로 구성됩니다.

1. 계획
2. 위험도 분석
3. 개발
4. 등급

첫 번째 주기가 완료된 직후 두 번째 주기가 시작됩니다. 소프트웨어 테스트는 계획 단계에서 시작하여 평가 단계까지 계속됩니다. 나선형 모델의 주요 장점은 첫 번째 테스트 결과가 각 주기의 세 번째 단계에서 테스트 결과 직후에 나타나서 올바른 품질 평가를 보장하는 데 도움이 된다는 것입니다. 그러나 이 모델은 비용이 많이 들고 소규모 프로젝트에는 적합하지 않을 수 있다는 점을 염두에 두는 것이 중요합니다.

이 모델은 꽤 오래되었지만 테스트와 개발 모두에 유용합니다. 뿐만 아니라, 주요 목표나선형 모델을 포함한 많은 소프트웨어 테스트 방법이 최근에 변경되었습니다. 우리는 그것들을 응용 프로그램의 결함을 찾는 것뿐만 아니라 원인을 찾는 데 사용합니다. 이 접근 방식은 개발자가 더 효율적으로 작업하고 버그를 빠르게 수정하는 데 도움이 됩니다.

이전 블로그 게시물에서 나선형 모델에 대해 자세히 알아보세요..

기민한

애자일 소프트웨어 개발 방법론과 소프트웨어 테스팅은 대화형 개발의 사용, 요구 사항의 동적 형성 및 자체 조직화 조직 내에서 지속적인 상호 작용의 결과로 구현을 보장하는 데 중점을 둔 일련의 접근 방식으로 설명할 수 있습니다. 작업 그룹. 대부분의 애자일 소프트웨어 개발 방법론은 짧은 반복 개발을 통해 위험을 최소화하는 것을 목표로 합니다. 이 유연한 전략의 주요 원칙 중 하나는 장기 계획에 의존하기보다 가능한 변화에 신속하게 대응하는 능력입니다.

애자일에 대해 자세히 알아보기(참고 - 영어 기사).

익스트림 프로그래밍(XP, 익스트림 프로그래밍)

익스트림 프로그래밍은 애자일 소프트웨어 개발의 한 예입니다. 이 방법론의 독특한 특징은 한 개발자가 코드에 대해 작업하고 그의 동료가 작성된 코드를 지속적으로 검토하는 상황인 "쌍 프로그래밍"입니다. 소프트웨어 테스팅 프로세스는 코드의 첫 번째 라인이 작성되기도 전에 시작되기 때문에 매우 중요합니다. 대부분의 버그가 코딩 단계에서 수정될 수 있도록 각 응용 프로그램 모듈에는 단위 테스트가 있어야 합니다. 또 다른 구별되는 속성은 테스트가 코드를 결정하고 그 반대의 경우가 아니라는 것입니다. 이는 모든 테스트가 통과한 경우에만 특정 코드 조각이 완전한 것으로 간주될 수 있음을 의미합니다. 그렇지 않으면 코드가 거부됩니다.

이 방법론의 주요 장점은 지속적인 테스트와 짧은 릴리스로 고품질암호.

스크럼

스크럼 - 소프트웨어 개발 프로세스를 관리하기 위해 생성된 반복적인 증분 프레임워크인 애자일 방법론의 일부입니다. 스크럼 원칙에 따르면 테스트 팀은 다음 단계에 참여해야 합니다.

• 스크럼 계획 참여
• 단위 테스트 지원
• 사용자 스토리 테스트
• 고객 및 제품 소유자와 협력하여 수락 기준 결정
• 자동화된 테스트 제공

또한 QA 구성원은 다른 팀 구성원과 마찬가지로 모든 일일 회의에 참석하여 어제 테스트하고 수행한 작업, 오늘 테스트할 항목 및 전체 테스트 진행 상황에 대해 논의해야 합니다.

동시에 Scrum의 Agile 방법론의 원칙은 다음과 같은 특정 기능의 출현으로 이어집니다.

• 각 사용자 스토리에 필요한 노력을 추정하는 것은 필수입니다.
• 테스터는 요구 사항이 항상 변경될 수 있으므로 주의를 기울여야 합니다.
• 잦은 코드 변경으로 회귀 위험이 증가합니다.
• 테스트의 동시 계획 및 실행
• 고객의 요구 사항이 완전히 명확하지 않은 경우 팀원 간의 오해

이전 기사에서 Scrum 방법론에 대해 자세히 알아보십시오..

결론

결론적으로 오늘날 하나 또는 다른 소프트웨어 테스팅 방법론을 사용하는 관행은 다중 접근 방식을 의미한다는 점에 유의하는 것이 중요합니다. 다시 말해, 어떤 방법론이 모든 유형의 프로젝트에 적합할 것이라고 기대해서는 안 됩니다. 그 중 하나의 선택은 프로젝트 유형, 고객 요구 사항, 마감일 및 기타 여러 측면과 같은 많은 측면에 따라 다릅니다. 소프트웨어 테스트 관점에서 일부 방법론은 개발 초기에 테스트를 시작하는 것이 일반적이지만 다른 방법론에서는 시스템이 완료될 때까지 기다리는 것이 일반적입니다.

소프트웨어 개발이나 테스트에 대한 도움이 필요한 경우 개발자와 QA 엔지니어로 구성된 전담 팀이 준비되어 있습니다.

웹 서비스 테스팅

대부분 가장 좋은 방법우리가 제품을 잘 테스트했는지 평가하십시오 – 놓친 결함을 분석하십시오. 사용자, 구현자, 비즈니스가 직면한 문제. 우리가 충분히 철저하게 확인하지 않은 것, 제품의 어떤 부분에 더 주의를 기울여야 하는지, 일반적으로 누락된 비율은 무엇인지, 변화의 역동성은 무엇인지 등 많은 평가를 할 수 있습니다. 이 메트릭(테스트에서 가장 일반적일 수 있음)을 사용하면 모든 것이 괜찮지만 ... 제품을 출시하고 누락된 오류에 대해 알았을 때 너무 늦었을 수 있습니다. 우리에 대한 화난 기사가 Habré에 게재되었고 경쟁업체는 빠르게 퍼지는 비판, 고객의 신뢰 상실, 경영진의 불만.

이를 방지하기 위해 일반적으로 출시 전에 사전에 테스트 품질을 평가하려고 합니다. 제품을 얼마나 잘, 철저하게 확인합니까? 관심이 부족한 영역, 주요 위험 요소, 진행 상황은 무엇입니까? 그리고 이 모든 질문에 답하기 위해 테스트 커버리지를 평가합니다.

왜 평가합니까?

모든 평가 지표는 시간 낭비입니다. 이때 테스트, 버그 시작, 자동 테스트 준비가 가능합니다. 테스트 커버리지 메트릭에서 테스트 시간을 희생함으로써 얻을 수 있는 마법 같은 이점은 무엇입니까?

1. 자신의 약한 부분을 찾습니다.당연히, 우리는 이것이 필요합니까? 단순히 슬퍼하는 것이 아니라 개선이 필요한 부분을 알기 위해서입니다. 테스트에서 다루지 않는 기능 영역은 무엇입니까? 우리가 확인하지 않은 것은 무엇입니까? 누락된 오류의 가장 큰 위험은 어디에 있습니까?
2. 평가 결과에서 100% 적용되는 경우는 거의 없습니다. 무엇을 개선할 것인가? 어디로 가야? 지금 백분율은 얼마입니까? 어떤 작업으로 그것을 늘릴 수 있습니까? 얼마나 빨리 100에 도달할 수 있습니까? 이러한 모든 질문은 프로세스에 투명성과 명확성을 가져옵니다., 그리고 그들에 대한 답은 커버리지 추정에 의해 주어진다.
3. 관심의 초점입니다.우리 제품에 약 50개의 서로 다른 기능 영역이 있다고 가정해 보겠습니다. 나오는 새 버전, 그리고 우리는 그 중 첫 번째 테스트를 시작하고 거기에서 오타, 몇 픽셀 이동한 버튼 및 기타 사소한 ... 그리고 이제 테스트 시간이 끝났고이 기능이 자세히 테스트되었습니다 .. 그리고 나머지 50개는? 적용 범위 평가를 통해 현재 현실과 마감일에 따라 작업의 우선 순위를 정할 수 있습니다.

어떻게 평가할 것인가?

메트릭을 구현하기 전에 사용 방법을 결정하는 것이 중요합니다. 이 질문에 정확히 답하는 것으로 시작하십시오. 아마도 가장 좋은 계산 방법을 즉시 이해하게 될 것입니다. 그리고 나는 이 기사에서 몇 가지 예와 이것이 어떻게 이루어질 수 있는지에 대한 나의 경험만을 공유할 것입니다. 맹목적으로 솔루션을 복사하기 위해서가 아니라, 이 경험에 의존하여 당신의 상상력이 당신에게 이상적인 솔루션을 생각하게 하기 위해서입니다.

테스트를 통한 요구 사항 적용 범위 평가

팀에 분석가가 있고 시간을 헛되이 보내지 않는다고 가정해 보겠습니다. 근무 시간. 작업 결과를 바탕으로 HP QC, MS TFS, IBM Doors, Jira(추가 플러그인 포함) 등의 RMS(요구사항 관리 시스템)에서 요구사항이 작성되었습니다. 이 시스템에서 그들은 요구 사항에 대한 요구 사항에 해당하는 요구 사항을 만듭니다(동어반복 죄송합니다). 이러한 요구 사항은 원자적, 추적 가능, 구체적… 일반적으로 테스트에 이상적인 조건입니다. 그런 경우에 우리는 무엇을 할 수 있습니까? 스크립트 방식을 사용할 때 요구 사항과 테스트를 연결합니다. 우리는 동일한 시스템에서 테스트를 수행하고 요구 사항-테스트 연결을 만들고 어떤 요구 사항에 테스트가 있고 어떤 요구 사항이 없는지, 이러한 테스트가 통과된 시기와 결과에 대한 보고서를 볼 수 있습니다.
우리는 커버리지 맵을 얻고, 커버되지 않은 모든 요구 사항을 커버하고, 모두가 행복하고 만족하며, 실수를 놓치지 않습니다 ...

좋아, 지상으로 돌아가자. 대부분의 경우 세부 요구 사항이 없고 원자적이지 않고 요구 사항 중 일부가 일반적으로 손실되고 각 테스트 또는 적어도 두 번째 테스트를 문서화할 시간이 없습니다. 절망하고 울거나 테스트가 보상 프로세스임을 인정할 수 있으며 프로젝트에 대한 분석 및 개발이 나빠질수록 프로세스에서 다른 참가자의 문제를 해결하기 위해 더 많이 노력하고 보상해야 합니다. 문제를 별도로 분석해 보겠습니다.

문제: 요구 사항이 원자적이지 않습니다.

분석가는 때때로 머리에 샐러드로 죄를 지으며 일반적으로 전체 프로젝트에 문제가 있습니다. 예를 들어, 텍스트 편집기를 개발 중이고 시스템에 두 가지 요구 사항이 있을 수 있습니다(무엇보다도): "html 형식이 지원되어야 함" 및 "지원되지 않는 형식의 파일을 열 때 질문이 있는 팝업 창 나타나야 한다." 1차 요구사항의 기본 검증을 위해 몇 번의 테스트가 필요합니까? 그리고 2위는? 답의 차이는 아마도 백배 정도입니다!!! 첫 번째 요구 사항에 대해 최소 1개의 테스트가 있는 경우 이것으로 충분하다고 말할 수는 없지만 두 번째에 대해서는 거의 완전히 가능합니다.

따라서 요구 사항 테스트가 있다고 해서 아무 것도 보장할 수 없습니다! 이 경우 보장 통계는 무엇을 의미합니까? 거의 아무것도! 우리가 결정해야 합니다!

1. 이 경우 테스트에 의한 요구 사항 적용 범위의 자동 계산을 제거할 수 있습니다. 여전히 의미론적 부하를 전달하지 않습니다.
2. 각 요구 사항에 대해 가장 높은 우선 순위부터 테스트를 준비합니다. 준비할 때 이 요구 사항에 대해 어떤 테스트가 필요한지 분석합니다. 몇 개 정도면 충분할까요? 본격적인 테스트 분석을 진행하며, “테스트는 하나지만 괜찮습니다.”를 외면하지 않습니다.
3. 사용된 시스템에 따라 요청 시 테스트를 내보내거나 업로드하고… 이러한 테스트를 테스트합니다! 그들은 충분합니까? 물론 이상적으로는 이러한 테스트는 이 기능의 분석가 및 개발자와 함께 수행해야 합니다. 테스트를 인쇄하고 동료를 회의실에 가두고 "예, 이 테스트로 충분합니다"라고 말할 때까지 놓지 마십시오(테스트 분석 없이도 이러한 단어가 구독 취소를 위해 사용되는 경우 서면 동의가 있는 경우에만 발생합니다. 구두 토론 중에 동료들은 욕조 비판, 시험 놓친, 잘못된 요구 사항 등을 쏟아낼 것입니다. 이것은 항상 즐거운 것은 아니지만 테스트에는 매우 유용합니다!)
4. 주문형 테스트를 완료하고 완료에 동의한 후 시스템에서 이 요구 사항을 "테스트 대상" 상태로 표시할 수 있습니다. 이 정보는 "여기에 적어도 1개의 테스트가 있습니다." 이상의 의미가 있습니다.

물론 그러한 합의 과정은 특히 처음에는 실천이 발전할 때까지 많은 자원과 시간을 필요로 합니다. 따라서 우선 순위가 높은 요구 사항과 이에 대한 새로운 개선 사항만 수행하십시오. 시간이 지남에 따라 나머지 요구 사항을 강화하면 모두가 만족할 것입니다! 하지만 ... 그리고 요구 사항이 전혀 없다면?

문제: 요구 사항이 전혀 없습니다.

그들은 프로젝트에 참여하지 않고 구두로 토론하며 모두가 원하는 대로/할 수 있고 이해하는 방식으로 수행합니다. 우리는 같은 것을 테스트합니다. 결과적으로 우리는 테스트 및 개발뿐만 아니라 초기에 잘못된 기능 구현에 많은 문제가 발생했습니다. 우리는 완전히 다른 것을 원했습니다! 여기에서 "요구 사항을 직접 정의하고 문서화"하는 옵션을 조언할 수 있으며 실제로 이 전략을 두 번 사용하기도 했지만 99%의 경우 테스트 팀에 그러한 리소스가 없습니다. 리소스 집약적인 방법:

1. 기능 목록을 만듭니다. 사미! google-tablet 형식, TFS의 PBI 형식 - 텍스트 형식이 아닌 한 아무거나 선택하세요. 아직 상태를 수집해야 합니다! 우리는 이 목록에 제품의 모든 기능 영역을 포함하고 하나의 일반적인 분해 수준을 선택하려고 합니다(소프트웨어 개체, 사용자 스크립트, 모듈, 웹 페이지, API 메서드 또는 화면 형식을 작성할 수 있습니다. .) - 그러나 이 모든 것이 한 번에 ! 중요한 것을 놓치지 않도록 더 쉽고 명확하게 만드는 하나의 분해 형식입니다.
2. 우리는 팀 내에서 분석가, 개발자, 비즈니스와 이 목록의 완전성을 조정합니다... 제품의 중요한 부분을 잃지 않도록 모든 것을 시도하십시오! 분석의 깊이는 당신에게 달려 있습니다. 내 연습에서는 테이블에 100 페이지가 넘는 페이지를 만든 몇 가지 제품만 있었고 이들은 거대한 제품이었습니다. 대부분의 경우 30-50 라인은 추가 신중한 처리를 위해 달성 가능한 결과입니다. 전담 테스트 분석가가 없는 소규모 팀 더 fichelista 요소는 유지 관리하기가 너무 어렵습니다.
3. 그 후 우선 순위를 살펴보고 위에서 설명한 요구 사항 섹션과 같이 fichelist의 각 줄을 처리합니다. 우리는 테스트를 작성하고, 논의하고, 충분성에 동의합니다. 기능에 대한 테스트가 충분한 상태를 표시합니다. 팀과의 커뮤니케이션을 통해 테스트의 진행 상황, 진행 상황, 확장성을 파악합니다. 모든 사람이 행복하다!

하지만... 요구 사항이 유지되지만 추적 가능한 형식이 아닌 경우에는 어떻게 됩니까?

문제: 요구 사항을 추적할 수 없습니다.

프로젝트에 대한 엄청난 양의 문서가 있으며, 분석가는 분당 400자의 속도로 입력하고, 사양, 기술 사양, 지침, 참조(대부분 고객의 요청에 따라 발생)가 있으며 이 모든 것이 다음과 같이 작동합니다. 요구 사항 및 모든 것이 오랫동안 프로젝트에 있었습니다. 어떤 정보를 찾아야 할지 혼란스럽습니까?
이전 섹션을 반복하여 전체 팀이 정리하는 데 도움이 됩니다!

1. 우리는 기능 목록(위 참조)을 생성하지만 요구 사항에 대한 자세한 설명은 없습니다.
2. 각 기능에 대해 기술 사양, 사양, 지침 및 기타 문서에 대한 링크를 함께 수집합니다.
3. 우리는 우선 순위에 따라 테스트를 준비하고 완전성에 동의합니다. 모든 문서가 하나의 플레이트에 결합된 덕분에 문서에 대한 액세스 용이성, 투명한 상태 및 테스트 일관성이 향상되었습니다. 결국 모든 것이 훌륭하고 모두가 행복합니다!

하지만... 얼마 안가... 지난주에 분석가가 고객 요청에 따라 4가지 사양을 업데이트한 것 같습니다!!!

문제: 요구 사항은 항상 변경됩니다.

물론 일부 고정된 시스템을 테스트하는 것이 좋겠지만 우리 제품은 일반적으로 라이브입니다. 고객이 무엇인가를 요청했고, 우리 제품 외부의 법률이 변경되었습니다. 그리고 분석가는 어딘가에서 작년의 분석 오류를 발견했습니다. 요구 사항은 자신의 삶을 살고 있습니다! 무엇을 할까요?

1. 기능 목록, PBI, 요구 사항, Wiki 메모 등의 형태로 TK 및 사양에 대한 링크를 이미 수집했다고 가정해 보겠습니다. 이러한 요구 사항에 대한 테스트가 이미 있다고 가정해 보겠습니다. 그리고 이제 요구 사항이 바뀌고 있습니다! 이것은 RMS의 변경, TMS(Task Management System)의 작업 또는 메일의 편지를 의미할 수 있습니다. 어느 쪽이든 동일한 결과로 이어집니다. 테스트가 오래되었습니다! 또는 관련이 없을 수도 있습니다. 이는 업데이트가 필요함을 의미합니다(테스트 적용 범위 구 버전상품은 어쩐지 별로 고려되지 않죠?)
2. 기능 목록에서, RMS에서, TMS(Test Management System - testrails, sitechco 등)에서 테스트는 즉시 관련성이 없는 것으로 반드시 표시되어야 합니다! HP QC 또는 MS TFS에서는 요구 사항을 업데이트할 때 자동으로 수행할 수 있으며 Google 태블릿이나 위키에서는 펜을 내려 놓아야 합니다. 그러나 즉시 확인해야 합니다. 테스트는 관련이 없습니다! 이것은 우리가 완전한 경로 재지정을 기다리고 있음을 의미합니다. 업데이트, 테스트 분석 재실행, 테스트 재작성, 변경 사항에 동의하고 그 후에야 기능/요구 사항을 "테스트 대상"으로 다시 표시합니다.

이 경우 테스트 커버리지 평가의 모든 이점을 얻을 수 있으며 역학에서도 마찬가지입니다! 모든 사람이 행복하다!!! 하지만…
그러나 요구 사항 작업에 너무 집중하여 이제는 테스트를 테스트하거나 문서화할 시간이 충분하지 않습니다. 제 생각에는 (그리고 종교적인 논쟁을 위한 장소가 있습니다!) 요구 사항이 시험보다 더 중요하고, 그렇게 하는 것이 더 좋습니다! 최소한 순서대로 되어 있고 전체 팀이 알고 있으며 개발자는 필요한 작업을 정확히 수행하고 있습니다. 하지만 시험을 문서화할 시간이 없습니다!

문제: 테스트를 문서화할 시간이 충분하지 않습니다.

사실, 이 문제의 원인은 시간이 부족할 뿐만 아니라 문서화하지 않기로 한 매우 의식적인 선택일 수도 있습니다(우리는 그것을 좋아하지 않고, 살충제 효과를 피하고, 제품이 너무 자주 바뀌는 등). 그러나 이 경우 테스트 커버리지를 평가하는 방법은 무엇입니까?

1. 전체 요구 사항 또는 기능 목록으로 요구 사항이 여전히 필요하므로 프로젝트에 대한 분석가의 작업에 따라 위 섹션 중 하나가 여전히 필요할 것입니다. 요구 사항/기능 목록이 있습니까?
2. 우리는 특정 테스트를 문서화하지 않고 짧은 테스트 전략에 대해 설명하고 구두로 동의합니다! 이 전략은 테이블 열, Wiki 페이지 또는 RMS의 요구 사항에 지정될 수 있으며 다시 동의해야 합니다. 이 전략의 일환으로 검토는 다양한 방식으로 수행되지만 다음 사항을 알게 될 것입니다. 마지막으로테스트하고 어떤 전략으로? 그리고 이것도 나쁘지 않습니다! 그리고 모두가 행복할 것입니다.

하지만… "하지만"은 또 무엇입니까? 어느???

우리는 모든 것을 둘러보고 고품질 제품이 우리와 함께 할 수 있습니다!

| 학년도 수업 계획 | 모델링의 주요 단계

2과
모델링의 주요 단계

이 주제를 공부하면 다음을 배우게 됩니다.

모델링이란 무엇입니까?
- 모델링을 위한 프로토타입으로 사용할 수 있는 것;
- 인간 활동에서 모델링의 위치는 무엇입니까?
- 모델링의 주요 단계는 무엇입니까?
- 컴퓨터 모델이란 무엇입니까?
컴퓨터 실험이란?

컴퓨터 실험

새로운 디자인 개발에 생명을 불어넣고 새로운 기술 솔루션을 생산에 도입하거나 새로운 아이디어를 테스트하려면 실험이 필요합니다. 실험은 개체 또는 모델로 수행되는 실험입니다. 몇 가지 작업을 수행하고 실험 샘플이 이러한 작업에 반응하는 방식을 결정하는 것으로 구성됩니다.

학교에서 생물학, 화학, 물리학, 지리 수업에서 실험을 수행합니다.

기업에서 신제품 샘플을 테스트할 때 실험이 수행됩니다. 일반적으로이 목적을 위해 특별히 제작 된 설정이 사용되므로 실험실 조건에서 실험을 수행하거나 실제 제품 자체에 모든 종류의 테스트 (실제 실험)가 적용됩니다. 예를 들어 유닛이나 어셈블리의 성능 특성을 연구하기 위해 온도 조절 장치에 놓고 특수 챔버에서 동결하고 진동 스탠드에서 테스트하거나 떨어 뜨리는 등의 작업을 수행합니다. 새 시계 나 진공 청소기라면 좋습니다. 파괴 중 손실은 크지 않습니다. 비행기나 로켓이라면?

실험실 및 본격적인 실험은 재료 비용과 시간이 많이 소요되지만 그 중요성은 매우 큽니다.

개발과 함께 컴퓨터 기술새로운 독특한 연구 방법 - 컴퓨터 실험이 나타났습니다. 많은 경우에 컴퓨터 시뮬레이션 연구가 도움이 되었고 때로는 실험 샘플과 테스트 벤치를 대체하기도 했습니다. 컴퓨터 실험을 수행하는 단계는 실험 계획을 세우고 연구를 수행하는 두 단계로 구성됩니다.

실험 계획

실험 계획은 모델 작업 순서를 명확하게 반영해야 합니다. 이러한 계획의 첫 번째 단계는 항상 모델을 테스트하는 것입니다.

테스팅은 구축된 모델의 정확성을 확인하는 과정이다.

테스트 - 모델 구성의 정확성을 결정할 수 있는 초기 데이터 세트.

얻은 모델링 결과의 정확성을 확인하려면 다음이 필요합니다. ♦ 모델 구축을 위해 개발된 알고리즘을 확인합니다. ♦ 구성된 모델이 시뮬레이션에서 고려된 원본의 속성을 올바르게 반영하는지 확인합니다.

모델 구성 알고리즘의 정확성을 확인하기 위해 초기 데이터의 테스트 세트가 사용되며, 이에 대한 최종 결과는 미리 알려지거나 다른 방식으로 미리 결정됩니다.

예를 들어 모델링에서 계산 공식을 사용하는 경우 초기 데이터에 대해 여러 옵션을 선택하고 "수동으로" 계산해야 합니다. 테스트 항목들입니다. 모델이 구축되면 동일한 입력으로 테스트하고 시뮬레이션 결과를 계산으로 얻은 결론과 비교합니다. 결과가 일치하면 알고리즘이 올바르게 개발되고 그렇지 않은 경우 불일치 원인을 찾아 제거해야 합니다. 테스트 데이터는 실제 상황을 전혀 반영하지 않을 수 있으며 의미론적 내용을 포함하지 않을 수 있습니다. 그러나 테스트 과정에서 얻은 결과는 원래 정보 모델 또는 기호 모델을 변경하는 것에 대해 생각하도록 유도할 수 있습니다.

구축된 모델이 시뮬레이션에서 고려한 원본의 속성을 반영하는지 확인하려면 실제 소스 데이터가 있는 테스트 예제를 선택해야 합니다.

연구 수행

테스트 후 구축된 모델의 정확성에 확신이 생기면 바로 연구를 진행할 수 있습니다.

계획에는 시뮬레이션의 목적을 충족하는 실험 또는 일련의 실험이 포함되어야 합니다. 각 실험에는 모델링 결과를 분석하고 결정을 내리는 기초가 되는 결과에 대한 이해가 수반되어야 합니다.

컴퓨터 실험을 준비하고 수행하는 계획은 그림 11.7에 나와 있습니다.

쌀. 11.7. 컴퓨터 실험의 계획

시뮬레이션 결과 분석

모델링의 궁극적인 목표는 시뮬레이션 결과에 대한 포괄적인 분석을 기반으로 개발되어야 하는 결정을 내리는 것입니다. 이 단계는 결정적입니다. 연구를 계속하거나 끝내십시오. 그림 11.2는 결과 분석 단계가 자율적으로 존재할 수 없음을 보여줍니다. 얻은 결론은 종종 일련의 추가 실험에 기여하고 때로는 문제의 변화에 ​​기여합니다.

테스트 및 실험 결과는 솔루션 개발의 기초가 됩니다. 결과가 작업의 목표와 일치하지 않으면 이전 단계에서 실수가 있음을 의미합니다. 이는 문제에 대한 잘못된 설명이거나 정보 모델의 지나치게 단순화된 구성이거나 모델링 방법이나 환경의 실패한 선택이거나 모델을 구축할 때 기술적인 방법의 위반일 수 있습니다. 이러한 오류가 식별되면 모델을 수정해야 합니다. 즉, 이전 단계 중 하나로 돌아가야 합니다. 실험 결과가 시뮬레이션의 목표를 충족할 때까지 프로세스가 반복됩니다.

기억해야 할 주요 사항은 감지된 오류도 결과라는 것입니다. 속담이 말하듯이, 당신은 당신의 실수로부터 배운다. 위대한 러시아 시인 A. S. 푸쉬킨도 이에 대해 다음과 같이 썼습니다.

오, 얼마나 많은 놀라운 발견이 있습니까?
깨달음의 정신을 준비하라
그리고 경험, 어려운 실수의 아들,
그리고 천재, 역설적인 친구,
그리고 우연, 신은 발명가...

질문 및 작업 제어

1. 모델링 문제 설명의 두 가지 주요 유형은 무엇입니까?

2. G. Oster의 잘 알려진 "Problem Book"에는 다음과 같은 문제가 있습니다.

지칠 줄 모르고 일하는 사악한 마녀는 하루에 30명의 공주를 애벌레로 만든다. 그녀가 810명의 공주를 애벌레로 만드는 데는 며칠이 걸릴까요? 15일 안에 일을 마치려면 하루에 몇 명의 공주가 애벌레로 변해야 할까요?
어떤 질문이 "만약 ...이면 어떻게 될까요?" 유형에 기인할 수 있고, 어떤 질문은 "그렇게 하는 방법 ..." 유형에 기인할 수 있습니까?

3. 모델링의 가장 잘 알려진 목표를 나열하십시오.

4. G. Oster의 "Problem Book"에서 장난기 넘치는 문제를 공식화하십시오.

27km 떨어진 두 개의 부스에서 두 마리의 사나운 개가 동시에 서로를 향해 뛰어올랐다. 첫 번째는 4km / h의 속도로 실행되고 두 번째는 5km / h의 속도로 실행됩니다.
언제까지 싸움이 시작될까요?

5. "신발 한 켤레" 개체의 특징을 가능한 한 많이 말하십시오. 다양한 목적을 위해 객체의 정보 모델을 구성합니다.
■ 하이킹을 위한 신발 선택;
■ 적절한 신발 상자 선택;
■ 신발 관리 크림 구입.

6. 직업 선택에 대한 권장 사항에 필요한 십대의 특성은 무엇입니까?

7. 컴퓨터가 시뮬레이션에 널리 사용되는 이유는 무엇입니까?

8. 당신이 알고 있는 컴퓨터 모델링 도구의 이름을 말하십시오.

9. 컴퓨터 실험이란 무엇입니까? 예를 들어 주십시오.

10. 모델 테스트란 무엇입니까?

11. 모델링 과정에서 어떤 오류가 발생합니까? 오류가 발견되면 어떻게 해야 합니까?

12. 시뮬레이션 결과의 분석은 무엇입니까? 일반적으로 어떤 결론을 내립니까?