테스트 케이스

Test case
이 기사는 소프트웨어 공학 용어에 관한 것입니다.법적 용어에 대해서는 검정 사례(법률)를 참조하십시오.다른 용도는 검정 사례(동음이의)를 참조하십시오.

소프트웨어 공학에서 테스트 케이스는 특정 프로그램 경로를 실행하거나 특정 [1]요건에 대한 적합성을 검증하는 등 특정 소프트웨어 테스트 목표를 달성하기 위해 실행되는 단일 테스트를 정의하는 입력, 실행 조건, 테스트 절차 및 예상 결과의 사양입니다.테스트 케이스는 계획적이지 않고 체계적인 테스트의 기초가 됩니다.테스트 대상 소프트웨어를 원하는 범위로 만들기 위해 테스트 케이스를 여러 개 구축할 수 있습니다.정식으로 정의된 테스트 케이스를 사용하면 연속된 소프트웨어 버전에 대해 동일한 테스트를 반복적으로 실행할 수 있으므로 효과적이고 일관된 회귀 [2]테스트가 가능합니다.

정식 테스트 케이스

신청서의 모든 요건이 충족되는지 완전히 테스트하기 위해서는 각 요건에 대해 적어도 두 가지 테스트 케이스가 있어야 합니다. 하나는 양성 테스트이고 다른 하나는 음성 [3]테스트입니다.요건에 하위 요건이 있는 경우, 각 하위 요건은 최소 2개의 테스트 케이스를 가져야 한다.요건과 테스트 사이의 링크 추적은 트레이서빌리티 매트릭스를 사용하여 자주 이루어집니다.서면 테스트 케이스에는 테스트하는 기능에 대한 설명과 테스트를 수행할 수 있는지 확인하는 데 필요한 준비가 포함되어야 합니다.

정식 필기 테스트 케이스는 기존의 입력과 테스트가 [4]실행되기 전에 산출되는 예상 출력으로 특징지어진다.기존의 입력은 전제조건을 테스트하고 예상되는 출력은 사후조건을 테스트해야 합니다.

비공식 테스트 케이스

정식 요건이 없는 응용 프로그램 또는 시스템의 경우, 유사한 등급의 프로그램이 정상적으로 작동하는 것을 기준으로 테스트 케이스를 작성할 수 있습니다.일부 테스트 학교에서는 테스트 사례가 전혀 작성되지 않지만 테스트 실행 후 활동 및 결과가 보고됩니다.

시나리오 테스트에서는, 시험자가 복잡한 문제나 시스템을 생각할 수 있도록 가상 스토리를 사용합니다.이러한 시나리오는 일반적으로 상세하게 기재되어 있지 않습니다.테스트 환경의 그림처럼 간단하거나 산문으로 작성된 설명일 수 있습니다.이상적인 시나리오 테스트는 동기 부여, 신뢰성, 복잡성 및 평가가 쉬운 스토리입니다.일반적으로 테스트 케이스는 단일 단계이지만 시나리오에서는 [5][6]키의 여러 단계를 다루므로 테스트 케이스와는 다릅니다.

일반적인 필기 테스트 케이스 형식

테스트 케이스는 일반적으로 애플리케이션의 올바른 동작/기능을 테스트하기 위한 한 단계 또는 일련의 단계를 말합니다.일반적으로 예상된 결과 또는 예상된 결과가 제공됩니다.[7]

포함할 [8]수 있는 추가 정보:

  • 테스트 케이스 ID - 이 필드는 테스트 케이스를 일의로 식별합니다.
  • 테스트 케이스 설명/개요 - 테스트 케이스의 목표를 설명합니다.
  • 테스트 단계 - 이 필드에는 테스트 케이스를 수행하기 위한 정확한 단계가 나와 있습니다.
  • 사전 요구 사항 - 이 필드는 테스트 단계 실행 전에 따라야 하는 조건 또는 단계를 지정합니다.
  • 테스트 카테고리
  • 작성자 - 시험자 이름.
  • 자동화 - 이 테스트 케이스의 자동화 여부.
  • 합격/불합격
  • 언급

규모가 큰 테스트 케이스에는 전제 조건 상태 또는 단계와 [8]설명이 포함될 수도 있습니다.

필기시험 케이스에는 실제 결과를 위한 장소도 포함되어야 한다.

이러한 단계는 워드프로세서 문서, 스프레드시트, 데이터베이스 또는 기타 공통 저장소에 저장할 수 있습니다.

데이터베이스 시스템에서 과거 테스트 결과, 결과를 생성한 사용자 및 결과를 생성하는 데 사용된 시스템 구성을 볼 수도 있습니다.이러한 과거 결과는 보통 별도의 테이블에 저장됩니다.

테스트 스위트에는 다음 내용도 포함됩니다[9].

  • 테스트 요약
  • 배열

테스트하는 기능에 대한 설명과 테스트를 수행할 수 있도록 하기 위해 필요한 준비 외에 테스트 케이스에서 가장 시간이 걸리는 부분은 테스트를 작성하고 시스템이 변경되었을 때 이를 수정하는 것입니다.

특수한 상황에서는 테스트를 실행하고 결과를 생성한 후 전문가 팀이 결과를 합격으로 간주할 수 있는지 평가할 필요가 있을 수 있다.이는 신제품 성능 번호 결정 시 자주 발생합니다.첫 번째 테스트는 후속 테스트 및 제품 출시 사이클의 기준선으로 사용됩니다.

승인 테스트는 일반적으로 시스템의 최종 사용자 또는 클라이언트의 그룹에 의해 실행되며 개발된 시스템이 지정된 [10][11]요건 또는 계약을 충족하는지 확인합니다.사용자 수용 테스트는 행복 경로 또는 양성 테스트 사례를 포함하여 음성 테스트 [12]사례를 거의 완전히 배제함으로써 차별화된다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Systems and software engineering – Vocabulary. Iso/Iec/IEEE 24765:2010(E). 2010-12-01. pp. 1–418. doi:10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8.
  2. ^ Kaner, Cem (May 2003). "What Is a Good Test Case?" (PDF). STAR East: 2.
  3. ^ "Writing Test Rules to Verify Stakeholder Requirements". StickyMinds.
  4. ^ Beizer, Boris (May 22, 1995). Black Box Testing. New York: Wiley. p. 3. ISBN 9780471120940.
  5. ^ "An Introduction to Scenario Testing" (PDF). Cem Kaner. Retrieved 2009-05-07.
  6. ^ Crispin, Lisa; Gregory, Janet (2009). Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley. pp. 192–5. ISBN 978-81-317-3068-3.
  7. ^ https://www.softwaretestingstandard.org/part3.php ISO/IEC/IEEE 29119-4:2019, "Part 4: 테스트 기술"
  8. ^ a b Liu, Juan (2014). "Studies of the Software Test Processes Based on GUI". 2014 International Conference on Computer, Network: 113–121. doi:10.1109/CSCI.2014.104. ISBN 9781605951676. S2CID 15204091. Retrieved 2019-10-22.
  9. ^ Kaner, Cem; Falk, Jack; Nguyen, Hung Q. (1993). Testing Computer Software (2nd ed.). Boston: Thomson Computer Press. p. 123–4. ISBN 1-85032-847-1.
  10. ^ Goethem, Brian Hambling, Pauline van (2013). User acceptance testing : a step-by-step guide. BCS Learning & Development Limited. ISBN 9781780171678.
  11. ^ Black, Rex (August 2009). Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. Hoboken, NJ: Wiley. ISBN 978-0-470-40415-7.
  12. ^ Cimperman, Rob (2006). UAT Defined: A Guide to Practical User Acceptance Testing. Pearson Education. pp. Chapter 2. ISBN 9780132702621.

외부 링크