랜덤 테스트

Random testing

무작위 시험은 무작위적이고 독립적인 입력을 생성하여 프로그램을 테스트하는 블랙박스 소프트웨어 시험 기법이다.출력 결과를 소프트웨어 사양과 비교하여 테스트 출력이 합격 또는 불합격인지 확인한다.[1]사양이 없는 경우 언어의 예외를 사용하며, 이는 시험 실행 중에 예외가 발생하면 프로그램에 결함이 있음을 의미하며, 편향된 시험을 피하기 위한 방법으로도 사용된다.

무작위 시험의 이력

하드웨어에 대한 무작위 시험은 1971년 멜빈 브뢰어에 의해 처음 조사되었고, 그 효과성을 평가하기 위한 초기 노력은 1975년 프라티마와 비슈와니 아그라왈에 의해 수행되었다.[2]

소프트웨어에서 듀란과 Ntafos는 1984년에 무작위 시험을 검사했다.[3]

무작위 검사에 대한 이론적 근거로서 가설 검사의 사용은 기능 검사 및 분석에서 Howden에 의해 설명되었다.이 책에는 또한 1/n 이하의 고장률에서 최소한 1-1/n의 신뢰도를 갖기 위해 필요한 시험 n의 수를 추정하기 위한 간단한 공식의 개발도 포함되어 있다.이 공식은 하한선 nlogn으로, 이것은 많은 수의 무고장 시험들이 심지어 약간의 고장률에 대한 약간의 신뢰도를 갖도록 요구되었음을 나타낸다.[4]

개요

다음 C++ 함수를 고려하십시오.

인트로 myAbs(인트로 x) {     만일 (x > 0) {          돌아오다 x;     }     다른 {         돌아오다 x; // 버그: '-x'여야 함     } }

이제 이 기능에 대한 무작위 테스트는 {123, 36, -35, 48, 0}이(가) 될 수 있다.'-35' 값만 버그를 트리거한다.결과를 확인할 참조 구현이 없다면 버그는 여전히 눈에 띄지 않게 될 수 있다.그러나 다음과 같은 주장을 추가하여 결과를 확인할 수 있다.

공허하게 하다 testAbs(인트로 n) {     을 위해 (인트로 i=0; i<n; i++) {         인트로 x = getRandomInput();         인트로 결과 = myAbs(x);         주장하다(결과 >= 0);     } }

참조 구현은 예를 들어, 성능을 향상시키기 위해 훨씬 더 복잡한 방법으로 간단한 알고리즘을 구현할 때 이용할 수 있다.예를 들어 Shönhage-Strassen 알고리즘의 구현을 테스트하기 위해 정수에 대한 표준 "*" 연산을 사용할 수 있다.

인트로 getRandomInput() {     // … }  공허하게 하다 테스트고속 곱하기(인트로 n) {     을 위해 (인트로 i=0; i<n; i++) {         장기의 x = getRandomInput();         장기의 y = getRandomInput();         장기의 결과 = 빠른 곱하기(x, y);         주장하다(x * y == 결과);     } }

이 예는 단순한 유형(단순 무작위 생성기를 사용할 수 있는 유형)으로 한정되지만, 객체 지향 언어를 대상으로 하는 도구는 일반적으로 프로그램을 탐색하여 생성기(구조자 또는 해당 유형의 객체를 반환하는 방법)를 테스트하고 찾아 무작위 입력(자체도 동일한 방식으로 생성되거나 또는 를 사용하여 생성됨)을 사용하여 호출한다.가능한 경우 의사-유도 생성기 발생기).그런 다음 이러한 접근방식은 무작위로 생성된 개체의 풀을 유지하고 생성된 개체를 재사용하거나 새 개체를 생성할 확률을 사용한다.[5]

무작위로

D의 무작위 시험에 관한 세미날 논문에 따르면.햄릿

[..] "시험평가"의 기술적, 수학적 의미는 시험 데이터의 선택에서 명시적으로 "시스템"이 부족하여 다른 시험들 사이에 상관관계가 없음을 의미한다.[1]

장단점

무작위 시험은 다음과 같은 강도에 대해 칭찬한다.

  • 그것은 사용하는 것이 싸다: 그것은 시험 중인 프로그램에 대해 현명할 필요가 없다.
  • 그것은 어떤 편향도 가지고 있지 않다: 수동 테스트와 달리, 일부 코드에서 잘못된 신뢰가 있기 때문에 버그를 간과하지 않는다.
  • 버그 후보를 찾는 것은 빠르다: 일반적으로 테스트 세션을 수행하는 데 몇 분이 걸린다.
  • 소프트웨어가 제대로 지정되면: 실제 버그를 발견한다.

다음과 같은 약점이 설명되었다.

  • 기본 버그(f.ex. null 포인터 비참조)만 찾는다.
  • 그것은 명세서와 명세가 전형적으로 부정확한 것만큼 정확할 뿐이다.
  • 버그를 찾는 다른 기술(예: 정적 프로그램 분석)과 비교가 잘 안 된다.
  • 각 시험 주행에서 서로 다른 입력을 무작위로 선택하는 경우, 동일한 시험이 무작위로 통과하거나 실패하기 때문에 연속 통합에 문제가 발생할 수 있다.[6]
  • 어떤 이들은 무작위성에 의존하기보다는 수동으로 구성한 테스트로 모든 관련 사례를 화이트박스 방식으로 신중하게 다루는 것이 낫다고 주장한다.[6]
  • 이 경우, 중간 정도의 고장률에 대한 신뢰도를 얻기 위해 매우 많은 수의 시험이 필요할 수 있다.예를 들어, 고장 확률이 100분의 1 미만이라는 최소 99%의 신뢰도를 가지려면 459개의 무고장 시험이 필요하다.[4]

랜덤 테스트 유형

입력과 관련하여

  • 임의 입력 시퀀스 생성(즉, 일련의 메서드 호출)
  • 데이터 입력의 무작위 순서(가동성 테스트라고도 함) - f.ex. 방법 호출의 무작위 순서
  • 기존 데이터베이스에서 랜덤 데이터 선택

안내식 대 비안내식

  • 리디렉션되지 않은 무작위 테스트 생성 - 검색을 안내하는 경험적 접근 없음
  • 지시 랜덤 테스트 생성 - 예: "임의 방향 랜덤 테스트 생성"[7] 및 "임의 랜덤 테스트"

구현

무작위 테스트를 구현하는 일부 도구:

  • QuickCheck - 원래 Haskell용으로 개발되었지만 많은 다른 언어로 포팅된 유명한 테스트 도구로서, 모델을 기반으로 API 호출의 무작위 시퀀스를 생성하고 각 실행 후 true를 유지해야 하는 시스템 속성을 검증한다.
  • Randoop - 테스트 대상 클래스에 대한 메서드 및 생성자 호출 시퀀스를 생성하고 이러한 클래스에서 JUnit 테스트를 생성
  • Simulant - 다양한 에이전트(예: 서로 다른 행동 프로파일을 가진 사용자)의 행동을 통계적 모델에 기초하여 시뮬레이션을 실행하고, 이후의 탐색 및 확인을 위해 모든 조치와 결과를 데이터베이스에 기록하는 Clojure 도구
  • 오토테스트 - 에펠스튜디오 테스트에 통합된 도구로, 에펠탑 코드 자동화에 기반한 계약서 포함.[5]·
  • YETI(York Extensible Testing Infrastructure) - 다양한 프로그래밍 언어(Java, JML, CoFoJa, .NET, C, Kermeta).
  • GramTest - Java로 작성된 문법 기반 무작위 시험 도구로서, 입력 그래머를 지정하기 위해 BNF 표기법을 사용한다.

비평

무작위 시험은 주로 효과적인 오라클을 거의 이용할 수 없기 때문에 실무에 있어 전문화된 틈새만을 가지고 있을 뿐 아니라 운영 프로파일과 유사 입력값의 생성이 어렵기 때문이기도 하다.[1]

테스트 오라클은 결과가 프로그램 사양과 일치하는지 여부를 검증하는 도구다.운영 프로필은 프로그램의 사용 패턴과 그에 따라 어떤 부분이 더 중요한지에 대한 지식이다.

계약서가 있는 프로그래밍 언어 및 플랫폼(예: 에펠탑).NET 또는 JML, CoFoJa...)와 같은 자바의 다양한 확장 계약은 자연스러운 경구로 작용하여 접근법이 성공적으로 적용되었다.[5]특히, 무작위 테스트는 수동 검사나 사용자 보고서보다 더 많은 버그를 발견한다.[9]

참고 항목

참조

  1. ^ a b c Richard Hamlet (1994). "Random Testing". In John J. Marciniak (ed.). Encyclopedia of Software Engineering (1st ed.). John Wiley and Sons. ISBN 978-0471540021.
  2. ^ Agrawal, P.; Agrawal, V. D. (1 July 1975). "Probabilistic Analysis of Random Test Generation Method for Irredundant Combinational Logic Networks". IEEE Transactions on Computers. C-24 (7): 691–695. doi:10.1109/T-C.1975.224289.
  3. ^ Duran, J. W.; Ntafos, S. C. (1 July 1984). "An Evaluation of Random Testing". IEEE Transactions on Software Engineering. SE-10 (4): 438–444. doi:10.1109/TSE.1984.5010257.
  4. ^ a b Howden, William (1987). Functional Program Testing and Analysis. New York: McGraw Hill. pp. 51–53. ISBN 0-07-030550-1.
  5. ^ a b c "AutoTest - Chair of Software Engineering". se.inf.ethz.ch. Retrieved 15 November 2017.
  6. ^ a b "Is it a bad practice to randomly-generate test data?". stackoverflow.com. Retrieved 15 November 2017.
  7. ^ Pacheco, Carlos; Shuvendu K. Lahiri; Michael D. Ernst; Thomas Ball (May 2007). "Feedback-directed random test generation" (PDF). ICSE '07: Proceedings of the 29th International Conference on Software Engineering: 75–84. ISSN 0270-5257.
  8. ^ T.Y. Chen; F.-C. Kuo; R.G. Merkel; T.H. Tse (2010), "Adaptive random testing: The ART of test case diversity", Journal of Systems and Software, 83 (1): 60–66, doi:10.1016/j.jss.2009.02.022, hdl:10722/89054
  9. ^ Ilinca Ciupa; Alexander Pretschner; Manuel Oriol; Andreas Leitner; Bertrand Meyer (2009). "On the number and nature of faults found by random testing". Software Testing, Verification and Reliability. 21: 3–28. doi:10.1002/stvr.415.

외부 링크