소프트웨어 테스트 가능성

소프트웨어 시험성은 소프트웨어 인공물(소프트웨어 시스템, 소프트웨어 모듈, 요구사항 또는 설계 문서)이 주어진 시험 상황에서 시험을 지원하는 정도를 말한다. 소프트웨어 아티팩트의 테스트 가능성이 높은 경우 테스트를 통해 시스템(있는 경우)의 결함을 찾는 것이 더 쉽다.

공식적으로, 어떤 시스템은 테스트할 수 있고, 어떤 시스템은 테스트할 수 없다. 이 분류는 입력 "I"를 사용하는 테스트 "S"에 있는 시스템의 기능에 대해 테스트할 수 있으려면 계산 가능한 기능 용어 "V"가 존재해야 하며, $V(S,I)$ S가 주어진 입력 I에서 유효한 출력을 생성하거나 그렇지 않으면 거짓인 경우 V $V(S,I)$ , $){\displaystyle V(S,I)}$ 가 참이어야 $V(S,I)$ 한다는 것을 알아봄으로써 달성될 수 있다. 이 함수 "V"는 입력 I을 가진 시스템의 검증 함수로 알려져 있다.

많은 소프트웨어 시스템은 테스트할 수 없거나 즉시 테스트할 수 없다. 예를 들어, 구글의 ReCAPtCHA는 이미지에 대한 메타데이터가 없는 것은 테스트 가능한 시스템이 아니다. 그러나 표시된 각 이미지에 대해 다른 곳에 저장된 태그가 있는 경우 Retraccha를 즉시 테스트할 수 있다. 이 메타 정보를 감안하면 시스템을 테스트할 수 있다.

따라서 시험가능성은 흔히 시험할 소프트웨어의 상호의존성과 시험목표, 사용된 시험방법 및 시험자원(즉, 시험내용)의 상호의존성에서 비롯되는 외적 속성으로 생각된다. 시험성을 직접 측정할 수는 없지만(소프트웨어 크기 등) 캡슐화, 결합, 응집성, 중복성 등 다른 주요 소프트웨어 품질과 높은 상관관계가 있기 때문에 소프트웨어 아티팩트의 본질적 속성으로 간주해야 한다.

우수한 설계에 대한 '시험성'과 '시험성'의 상관관계는 응집력이 약하고, 결합성이 긴밀하며, 중복성이 있으며 캡슐화가 부족한 코드는 시험하기 어렵다는 것을 확인함으로써 관찰할 수 있다.^[1]

시험성이 낮을수록 시험 노력이 증가한다. 극단적인 경우 시험성 결여는 소프트웨어 또는 소프트웨어 요건의 시험 부분을 전혀 방해할 수 있다.

테스트 가능성을 테스트하여 시스템의 잠재적 결함을 찾는 어려움(있는 경우)과 연결하기 위해 테스트 가능성을 평가하기 위한 관련 조치는 전체 테스트 제품군을 구성하기 위해 각 케이스에 필요한 테스트 사례의 수(즉, 시스템에 모든 테스트 케이스를 적용한 후 수집된 출력이 다음을 수행하도록 하는 테스트 제품군)이다.일부 규격에 따라 시스템이 정확한지 여부를 모호하게 판단한다. 이 크기가 작으면 시험성이 높다. 이 조치에 근거해 시험성 계층화가 제안되었다.^[2]^[3]

배경

경험적 가설에 적용되는 속성인 시험성에는 두 가지 요소가 포함된다. 소프트웨어 테스트의 노력과 효율성은 다음을 포함한 수많은 요인에 따라 달라진다.

소프트웨어 요구 사항의 속성
소프트웨어 자체의 속성(크기, 복잡성 및 테스트 가능성 등)
사용된 테스트 방법의 속성
개발 및 테스트 프로세스의 속성
시험과정 관련자의 자격 및 동기부여

소프트웨어 구성 요소의 테스트 가능성

소프트웨어 구성요소(모듈, 클래스)의 시험성은 다음과 같은 요인에 의해 결정된다.

제어 가능성: 테스트에 필요한 테스트 대상 구성 요소의 상태(CUT)를 제어할 수 있는 정도.
관측 가능성: (중간 및 최종) 테스트 결과를 관찰할 수 있는 정도.
분리 가능성: 테스트 대상 구성 요소(CUT)를 분리하여 테스트할 수 있는 정도.
우려의 분리: 테스트 대상 구성 요소의 단일 잘 정의된 책임 정도.
이해 가능성: 테스트 대상 구성 요소가 문서화되거나 자체 설명되는 정도.
자동성: 테스트 대상 구성 요소의 테스트를 자동화할 수 있는 정도.
이질성: 다양한 기술의 사용이 요구하는 다양한 시험 방법과 도구를 병렬로 사용하는 정도.

소프트웨어 구성요소의 시험성은 다음을 통해 개선할 수 있다.

테스트 주도형 개발
테스트 가능성에 대한 설계(하드웨어 도메인에서 테스트에 대한 설계와 유사)

시험성 계층 구조

각 컨텍스트에서 완전한 테스트 제품군을 구성하는 데 필요한 테스트 사례의 수(즉, 테스트 중인 구현에 적용되는 경우, 시스템이 일부 사양에 따라 정확한지 또는 부정확한지를 판단할 수 있는 충분한 정보를 수집하는 테스트 제품군)에 기초하여 다음과 같은 테스트 가능성 계층을 제공한다.ng 시험성 등급이 제안되었다.^[2]

등급 I: 유한한 완전한 테스트 세트가 존재한다.
등급 II: 모든 부분 구분 비율(즉, 올바른 시스템과 잘못된 시스템을 구별하는 불완전한 기능)은 유한한 시험 세트로 도달할 수 있다.
클래스 III: 카운트 가능한 전체 테스트 제품군이 있다.
클래스 4: 완전한 테스트 세트가 있다.
5급 : 모든 경우.

각 등급이 다음 등급에 엄격히 포함되어 있다는 것이 증명되었다. 예를 들어, 시험 대상 구현의 동작이 일부 알려진 유한한 입력 및 출력 집합에 대해 결정론적 유한 상태 기계에 의해 지시될 수 있다고 가정할 때 시험하는 경우, 그리고 일부 상태 수는 등급 I(및 모든 후속 등급)에 속한다. 그러나 주의 개수를 알 수 없는 경우에는 2등급부터의 모든 등급에 속할 뿐이다. 시험 대상 구현이 단일 추적(및 그 연속성)에 대한 규격을 충족하지 못하는 결정론적 유한 상태 기계여야 하며, 상태 수를 알 수 없는 경우, 등급 III의 등급에만 해당된다. 입력이 실제 경계 구간 내에서 생성되는 경우 전환이 트리거되는 시간적 기계 테스트는 IV 등급의 클래스에만 속하는 반면, 많은 비결정론적 시스템을 테스트하는 것은 V 등급(전부는 아니지만 일부는 클래스 I에 속함)에만 해당된다. 어떤 프로그래밍 언어로 작성된 구현과 연속적인 크기에 따라 기계로 정의된 구현과 관련된 일부 테스트 사례가 클래스 I에 포함된 것으로 입증되었으므로 클래스 I에 포함된 가정된 계산 모델의 단순성은 요구하지 않는다. 매튜 헤네시에 의한 필수 의미론적 시험 체계와 합리적인 타임아웃이 있는 임시 기계와 같은 다른 정교한 사례들은 등급 2에 속한다.

요구 사항의 테스트 가능성

요건은 다음과 같은 기준을 충족해야 시험할 수 있다.

일관된
완성의
확실하지 않은
양적("빠른 응답 시간"과 같은 요구사항은 검증/검증이 될 수 없음)
실전에 있어서의 검증/검증(이론적인 것뿐만 아니라 한정된 자원으로 실전에 있어서도 시험이 실현 가능하다)

$F_{S}:I\to O$ 을 공리로 취급하면, 시험성은 입력 $I_{k}$ k ${\$ 가 출력 $O_{k}$ $F_{S}:I\to O$ k ${\$ $F_{S}:I\to O$ $}$ 를 생성하는 $I_{k}$ 기능 F $F_{S}$ ${\displaystyle F_{S}($ 소프트웨어)의 존재를 주장하여 처리할 수 있다 $F_{S}:I\to O$ $I\to O$ $(I_{k},O_{k})$ 그러므로 이상적인 소프트웨어는 규격의 입출력 세트인 $\Sigma$ (I k , O k $(I_{k},O_{k})$ ) ${\displaystyle$ (I_ $\Sigma$ k $(I_{k},O_{k})$ ${k$ $}}}$ 을(를 $(I_{k},O_{k})$ 생성한다.

Now, take a test input $I_{t}$ , which generates the output $O_{t}$ , that is the test tuple $\tau =(I_{t},O_{t})$ . Now, the question is whether or not $\tau \in \Sigma$ or ${\displaystyle \tau \not \in \$ $시그마 }$ . 세트 안에 있으면 테스트 튜플 $\tau$ $\tau$ 이 $\tau$ (가) 통과하지 않으면 시스템이 테스트 입력을 실패함. 따라서 반드시 알아내야 할 중요한 사항: 규격 집합 ${\displaystyle$ \ $Sigma$ $\Sigma$ 에 대한 설정 지표 함수의 개념으로 효과적으로 변환할 수 있는 함수를 만들 수 있는가, 만들 수 있는가?

개념에 따르면, $1_{\Sigma }$ $\Sigma$ ${\$ $displaystyle$ $1_$ ${\Sigma}}$ 규격의 시험성 함수로, 존재는 $1_{\Sigma }$ 단순히 주장되어서는 안 되며, 엄격하게 입증되어야 한다 $\Sigma$ 따라서 분명히 대수적 일관성이 없으면 그러한 함수를 찾을 수 없으며 따라서 명세서는 시험 가능한 것으로 더 이상 불리지 않는다.

참고 항목

시험성

참조

^ Shalloway, Alan; Trott, Jim (2004). Design Patterns Explained, 2nd Ed. p. 133. ISBN 978-0321247148.
^ ^a ^b Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "A General Testability Theory: Classes, properties, complexity, and testing reductions". IEEE Transactions on Software Engineering. 40 (9): 862–894. doi:10.1109/TSE.2014.2331690. ISSN 0098-5589.
^ ^a ^b Rodríguez, Ismael (2009). "A General Testability Theory". CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings. pp. 572–586. doi:10.1007/978-3-642-04081-8_38. ISBN 978-3-642-04080-1.

로버트 5세 바인더: 객체 지향 시스템 테스트: 모델, 패턴 및 도구, ISBN 0-201-80938-9
스테판 융마이어: 객체 지향 시스템의 시험성 향상, ISBN 3-89825-781-9
Warelei Souza: 추상적 시험성 패턴, ISSN 1884-0760
Boris Beizer: [1], 소프트웨어 테스트 기술

[DesignPatternsExplained2ndEd-1] Shalloway, Alan; Trott, Jim (2004). Design Patterns Explained, 2nd Ed. p. 133. ISBN 978-0321247148.

[RodriguezLlanaRabanal-2] Rodríguez, Ismael; Llana, Luis; Rabanal, Pablo (2014). "A General Testability Theory: Classes, properties, complexity, and testing reductions". IEEE Transactions on Software Engineering. 40 (9): 862–894. doi:10.1109/TSE.2014.2331690. ISSN 0098-5589.

[Rodriguez-3] Rodríguez, Ismael (2009). "A General Testability Theory". CONCUR 2009 - Concurrency Theory, 20th International Conference, CONCUR 2009, Bologna, Italy, September 1–4, 2009. Proceedings. pp. 572–586. doi:10.1007/978-3-642-04081-8_38. ISBN 978-3-642-04080-1.

[1]

[2]

[3]

Search

소프트웨어 테스트 가능성

네임스페이스

더

목차

배경

소프트웨어 구성 요소의 테스트 가능성

시험성 계층 구조

요구 사항의 테스트 가능성

참고 항목

참조