키워드 중심 테스트

Keyword-driven testing

키워드 기반 테스트동작 단어 기반 테스트라고도 하며(액션 기반 테스트와 혼동되지 않음) 수동자동 테스트 모두에 적합한 소프트웨어 테스트 방법론이다.이 방법은 사용할 데이터와 기능 모두를 포함하여 테스트 사례의 문서화를 테스트 사례의 실행 방식에 대한 처방과 분리한다.그 결과, 시험 생성 과정을 설계 및 개발 단계와 실행 단계라는 두 가지 뚜렷한 단계로 구분한다.설계 하위 영역에는 요구사항 분석 및 평가와 데이터 분석, 정의 및 모집단이 포함된다.

개요

이 방법론은 키워드(또는 동작 단어)를 사용하여 Enter Client와 같이 테스트할 기능을 상징한다.Enter Client 키워드는 데이터베이스에 새 클라이언트를 입력하기 위해 실행해야 하는 작업 집합으로 정의된다.키워드 문서에는 다음이 포함된다.

  • 테스트 대상 시스템의 시작 상태(SUT)
  • 시작할 창 또는 메뉴
  • 키 또는 마우스를 클릭하여 올바른 데이터 입력 창으로 이동
  • 찾을 필드의 이름 및 입력할 인수
  • 추가 대화 상자가 나타날 경우 수행할 작업(예: 확인)
  • 제출하기 위해 클릭하는 단추
  • 조치 완료 후 SUT의 상태가 어떻게 되어야 하는지에 대한 주장

키워드 중심 테스트 구문에는 테이블 형식을 사용하여 테스트 사례(데이터 및 작업 단어)가 나열된다(아래 예 참조).첫 번째 열(A열)에는 테스트 중인 기능인 Enter Client라는 키워드가 들어 있다.그런 다음 나머지 열인 B-E에는 키워드를 실행하는 데 필요한 데이터가 들어 있다.이름, 주소, 우편 번호 및 도시.

A B C D E
. 이름 주소. 우편번호 도시
클라이언트 입력 제인 스미스 하이 스트리트 6 SE25 6EP 런던

다른 클라이언트를 입력하기 위해 테스터는 다음 열에 Enter Client를 키워드로 하고 새 클라이언트의 데이터를 사용하여 표에 다른 행을 만든다.포함된 모든 조치를 다시 설명할 필요는 없다.

다음과 같은 방법으로 테스트 사례를 설계할 수 있다.

  • 테스트를 수행하기 위해 응용 프로그램 및 시스템과 상호 작용하는 데 필요한 높은 수준의 단계를 표시한다.
  • 기능의 유효성 확인 및 인증 방법이 올바르게 작동하는지 표시.
  • 검정의 전제 조건 지정.
  • 검정의 합격 기준 지정.

소프트웨어 개발의 반복적 성격을 고려할 때, 테스트 설계는 일반적으로 테스트의 수동 구현보다 더 추상적(구체적)이지만 쉽게 하나로 진화할 수 있다.

이점

키워드 중심 테스트는 테스트 대상 시스템/소프트웨어(SUT)의 변경으로 인한 유지보수에 대한 민감도를 감소시킨다.스크린 레이아웃이 변경되거나 시스템이 다른 OS로 마이그레이션되는 경우, 테스트 케이스에 키워드를 몇 번 사용하든 키워드 문서화, 키워드마다 하나의 문서로 변경되며, 이는 테스트 설계의 심층적인 과정을 의미한다.

또한 키워드(키워드 문서화) 실행방식에 대한 매우 상세한 설명으로 인해 거의 모든 사람이 테스트를 수행할 수 있다.따라서 키워드 중심 시험은 수동시험자동시험에 모두 사용될 수 있다.[1]

더욱이, 이 접근방식은 시험과 관련된 모든 도구, 자산 및 데이터를 통합하고 확장 가능한 프레임워크다.이 단일 프레임워크에서 모든 시험 참가자는 자신이 추진하고 있는 품질 목표를 정의하고 세분화할 수 있다.팀이 그러한 목표를 달성하기 위해 실행할 계획을 정의하는 곳이다.그리고, 가장 중요한 것은, 그것은 팀 전체가 언제라도 시스템의 상태를 결정하기 위해 갈 수 있는 한 장소를 제공한다는 것이다.

테스트는 소프트웨어 개발 프로세스의 피드백 메커니즘이다.그것은 개발 노력의 반복에 따라 항로를 유지하기 위해 수정해야 할 위치를 알려준다.또한 개발 중인 시스템의 현재 품질에 대해서도 알려준다.시험 시행 활동은 시험 사례를 구현하는 재사용 가능한 시험 대본의 설계와 개발을 포함한다.구현 후에는 테스트 사례와 관련될 수 있다.

모든 테스트 프로젝트에서 구현은 다르다.한 프로젝트에서 자동화된 테스트 스크립트수동 테스트 스크립트를 모두 작성하기로 결정할 수 있다.[2]대신, 시험을 설계하는 것은 반복적인 과정이다.유스케이스 사양, 요구사항, 프로토타입 등에 근거하여 테스트 설계를 시작함으로써 시스템 구현 전에 테스트 설계를 시작할 수 있다.시스템이 더욱 명확히 구체화되고 함께 작업할 수 있는 시스템 구축이 이루어짐에 따라, 설계의 세부사항을 상세히 설명할 수 있다.시험 설계 활동은 "어떻게 시험을 수행할 것인가?"라는 질문에 답한다.완전한 시험 설계는 독자들에게 시스템을 가지고 어떤 조치를 취해야 하는지, 그리고 시스템이 적절하게 기능할 경우 어떤 행동과 특성을 관찰할 것으로 예상해야 하는지를 알려준다.

테스트 설계는 테스트 구현을 구축하는 방법을 결정할 때 수행해야 하는 설계 작업과 다르다.

방법론

키워드 중심 테스트 방법론은 테스트 프로세스 실행을 다음과 같은 여러 단계로 나눈다.

  1. 모델 기반/프로토타이핑: 요구사항 분석 및 평가
  2. 테스트 모델 정의: 결과 요구사항 평가에서 자체 소프트웨어 모델에 접근하십시오.
  3. 테스트 데이터 정의: 정의된 자체 모델에 기반하여 시작 키워드 및 기본/완료 데이터 정의
  4. 시험준비 : 섭취시험기준 등
  5. 테스트 설계: 테스트 기준 분석, 테스트 사례/절차 설계, 테스트 데이터 설계.
  6. 수동 테스트 실행: 키워드 문서를 실행 지침으로 사용하여 테스트 사례의 수동 실행.
  7. 테스트 실행 자동화: 키워드 문서에 따라 작업을 수행하는 자동 스크립트 생성.
  8. 자동화된 테스트 실행.

정의

키워드 또는 액션 워드는 테스트 라인이 실행되어야 하는 방법을 설명하는 테스트 개체에 대한 동작의 정의된 조합이다.조치 단어는 인수를 포함하며 시험 분석가에 의해 정의된다.

테스트는 모든 개발 과정의 핵심 단계로, 일련의 테스트 또는 점검을 물체에 적용해야 한다(시스템/SW 테스트 - SUT).항상 테스트는 오류의 존재만 보여줄 수 있고, 결석만 보여줄 수 없다는 것을 기억한다.RT 시스템 테스트에서는 SUT가 올바른 출력을 생성하는지 점검하기에 충분하지 않다.또한 해당 출력을 생성하는 데 걸리는 시간이 예상대로인지 확인해야 한다.또한, 이러한 출력의 타이밍은 입력의 타이밍에 따라 달라질 수 있다.차례로, 적용 가능한 미래 입력의 타이밍은 출력에서 결정된다.[2]

테스트 실행 자동화

구현 단계는 도구 또는 프레임워크에 따라 다르다.자동화 엔지니어들은 종종 "체크"와 "입력"[1]과 같은 키워드를 제공하는 프레임워크를 구현한다.테스터 또는 테스트 설계자(프로그래밍 방법을 알 필요가 없는 사람)는 엔지니어가 구현한 계획 단계에서 정의한 키워드를 바탕으로 테스트 케이스를 작성한다.키워드를 읽고 해당 코드를 실행하는 드라이버를 사용하여 테스트를 실시한다.

다른 방법론에서는 일체형 구현 단계를 사용한다.시험 설계와 시험 엔지니어링의 업무를 분리하는 대신 시험 설계는 시험 자동화다."편집" 또는 "체크"와 같은 키워드는 필요한 코드가 이미 작성된 도구를 사용하여 만들어진다.이는 키워드에 대한 구현이 이미 도구의 일부분이기 때문에 테스트 프로세스에서 추가 엔지니어가 필요하지 않다.예로는 GUI댄서QTP가 있다.

프로스

  • 장기적으로 유지보수가 낮음:
    • 테스트 사례가 간결함
    • 시험 케이스는 이해관계자에 대해 판독 가능
    • 테스트 케이스의 수정이 용이함
    • 기존 키워드를 보다 쉽게 재사용할 수 있는 새로운 테스트 사례
  • 여러 테스트 사례에서 키워드 재사용
  • 특정 도구 또는 프로그래밍 언어에 종속되지 않음
  • 노동분업
    • 테스트 사례 구축 시 보다 강력한 도메인 전문 지식이 필요함 - 툴/프로그래밍 기술 부족
    • 키워드를 구현하려면 상대적으로 낮은 도메인 스킬을 가진 더 강력한 도구/프로그래밍 스킬이 필요함
  • 층 추상화

단점

  • 시장 출시 기간 연장(수동 테스트 또는 기록 및 재생 기술에 비해)
  • 처음에는 적당히 높은 학습 곡선

참고 항목

참조

  1. ^ a b Faught, Danny R. (November 2004). "Keyword-Driven Testing". Sticky Minds. Software Quality Engineering. Retrieved September 12, 2012.
  2. ^ a b Mandurrino, José L. (July 2014). "Gestione e approccio alla validazione in sistemi RT (Real-Time)". UTIU. {{cite web}}:누락 또는 비어 있음 url=(도움말)

외부 링크