테스트 케이스 작성 방법 : 예제가 포함 된 궁극적 인 가이드

how write test cases

테스트 케이스 작성 방법에 대한이 심층 실습 튜토리얼에서 테스트 케이스, 표준 정의 및 테스트 케이스 디자인 기술에 대한 세부 사항을 다루었습니다.

테스트 케이스는 무엇입니까?

테스트 케이스에는 애플리케이션의 기능이 올바르게 작동하는지 확인하기 위해 입력, 조치 및 예상 응답을 설명하는 구성 요소가 있습니다.

테스트 케이스는 특정 테스트 목표 / 목표를 검증하기위한 '방법'에 대한 일련의 지침으로, 시스템의 예상 동작이 충족되는지 여부를 알려줍니다.

이 테스트 케이스 작성 시리즈에서 다루는 튜토리얼 목록 :

쓰는 방법 :

튜토리얼 # 1 : 테스트 케이스 란 무엇이며 테스트 케이스를 작성하는 방법 (이 튜토리얼)
튜토리얼 # 2 : 예제가 포함 된 샘플 테스트 케이스 템플릿 (다운로드) (필독)
튜토리얼 # 3 : SRS 문서에서 테스트 케이스 작성
튜토리얼 # 4 : 주어진 시나리오에 대한 테스트 케이스를 작성하는 방법
튜토리얼 # 5 : 테스트 케이스 작성을 준비하는 방법
튜토리얼 # 6 : 부정적인 테스트 케이스를 작성하는 방법

예 :

튜토리얼 # 7 : 웹 및 데스크톱 애플리케이션을위한 180 개 이상의 샘플 테스트 사례
튜토리얼 # 8 : 100 개 이상의 즉시 실행 가능한 테스트 시나리오 (체크리스트)

쓰기 기법 :

튜토리얼 # 9 : 원인 및 결과 그래프 – 동적 테스트 케이스 작성 기법
튜토리얼 # 10 : 상태 전이 테스트 기법
튜토리얼 # 11 : 직교 배열 테스트 기법
튜토리얼 # 12 : 오류 추측 기법
튜토리얼 # 13 : FVT (Field Validation Table) 테스트 설계 기법

테스트 케이스 대 테스트 시나리오 :

튜토리얼 # 14 : 테스트 케이스 대 테스트 시나리오
튜토리얼 # 15 : 테스트 계획, 테스트 전략 및 테스트 케이스의 차이점

오토메이션:

튜토리얼 # 16 : 자동화 테스트를위한 올바른 테스트 케이스를 선택하는 방법
튜토리얼 # 17 : 수동 테스트 케이스를 자동화 스크립트로 변환하는 방법

테스트 관리 도구 :

튜토리얼 # 18 : 최고의 테스트 관리 도구
튜토리얼 # 19 : 테스트 케이스 관리를위한 TestLink
튜토리얼 # 20 : HP Quality Center를 사용하여 테스트 케이스 생성 및 관리
튜토리얼 # 21 : ALM / QC를 사용하여 테스트 케이스 실행

도메인 별 사례 :

튜토리얼 # 22 : ERP 적용을위한 테스트 케이스
튜토리얼 # 23 : JAVA 애플리케이션 테스트 케이스
튜토리얼 # 24 : 경계 값 분석 및 등가 분할

이 시리즈의 첫 번째 자습서를 계속해 보겠습니다.

권장 도구 :

테스트 케이스 작성 프로세스를 계속하기 전에이 테스트 케이스 관리 도구를 다운로드하는 것이 좋습니다. 이렇게하면이 튜토리얼에서 언급 한 테스트 케이스 작성 프로세스가 쉬워집니다.

# 1) TestRail

=> TestRail 테스트 케이스 관리 도구 다운로드

# 2) TestMonitor

최상위 온라인 테스트 관리. 혁신적인 쉬움.

TestMonitor는 모든 조직을위한 엔드-투-엔드 테스트 관리 도구입니다. 테스트에 대한 간단하고 직관적 인 접근 방식입니다. 엔터프라이즈 소프트웨어를 구현하든, QA가 필요하든, 고품질 앱을 구축하든, 테스트 프로젝트에 도움이 필요하든, TestMonitor가 지원합니다.

=> TestMonitor 웹 사이트 방문

학습 내용 :

• 테스트 케이스는 무엇이며 테스트 케이스를 작성하는 방법은 무엇입니까?
  • 테스트를 작성하는 이유는 무엇입니까?
  • 테스트 케이스를 작성하는 방법?
  • 테스트 케이스 진술의 기본 형식
• 시험 작성을위한 팁
  • • # 1) 단순하게 유지하되 너무 단순하지 않게하십시오. 복잡하지만 너무 복잡하지 않게 만드세요.
    • # 2) 테스트 사례를 문서화 한 후 테스터로 한 번 검토합니다.
    • # 3) 테스터를 편하게하고 바인딩 :
    • # 4) 기여자되기 :
    • # 5) 최종 사용자를 잊지 마십시오 :
• 테스트 케이스 문서에서 우수성을 달성하는 방법
  • 유용한 팁과 요령
    • # 1) 테스트 문서가 양호한 상태입니까?
    • # 2) 부정적인 사례를 다루는 것을 잊지 마십시오
    • # 3) 원자 테스트 단계
    • # 4) 테스트 우선 순위 지정
    • # 5) 시퀀스 문제
    • # 6) 댓글에 타임 스탬프 및 테스터 이름 추가
    • # 7) 브라우저 세부 정보 포함
    • # 8) 문서에 '버그'와 '요약'이라는 두 개의 별도 시트를 보관하십시오.
• 테스트를 작성하지 않는 방법
  • 테스트 케이스에서 가장 일반적인 3 가지 문제
    • # 1) 복합 단계
    • # 2) 애플리케이션 동작이 예상 된 동작으로 간주됩니다.
    • # 3) 하나의 경우에 여러 조건
• 테스트 케이스 효율성을 개선하는 방법
  • 시험 작성을위한 문서 수집
  • 실제 예
  • 테스트 케이스 문서
  • 테스트 데이터 수집
• 테스트 케이스 표준화의 중요성
  • 테스트 케이스를 재사용해야하는 이유
  • 웹 테스트에서 표준 테스트 란 무엇입니까?
  • 결론
  • 추천 도서

테스트 케이스는 무엇이며 테스트 케이스를 작성하는 방법은 무엇입니까?

효과적인 사례를 작성하는 것은 기술입니다. 그리고 테스트중인 응용 프로그램에 대한 경험과 지식을 통해 배울 수 있습니다.

테스트 작성 방법에 대한 기본 지침은 다음 비디오를 확인하십시오.

위의 리소스는 테스트 작성 프로세스의 기본 사항을 제공해야합니다.

테스트 작성 과정의 수준 :

• 레벨 1: 이 레벨에서 당신은 사용 가능한 사양의 기본 사례 및 사용자 문서.
• 2 단계: 이것이 실용적인 무대 작성 사례는 응용 프로그램의 실제 기능 및 시스템 흐름에 따라 달라집니다.
• 레벨 3 : 몇 가지 케이스를 그룹화하고 테스트 절차 작성 . 테스트 절차는 소규모 케이스 그룹에 불과하며 최대 10 개까지 가능합니다.
• 레벨 4 : 프로젝트 자동화. 이렇게하면 시스템과의 인간 상호 작용이 최소화되므로 QA는 회귀 테스트에 바쁘게 남아 있지 않고 테스트 할 현재 업데이트 된 기능에 집중할 수 있습니다.

테스트를 작성하는 이유는 무엇입니까?

사례 작성의 기본 목표는 응용 프로그램의 테스트 범위를 확인합니다.

CMMi 조직에서 일하는 경우 테스트 표준을 더 면밀히 따릅니다. 사례 작성은 일종의 표준화를 가져오고 테스트에서 임시 접근 방식을 최소화합니다.

테스트 케이스를 작성하는 방법?

필드:

• 테스트 케이스 ID
• 테스트 할 단위 : 무엇을 확인해야합니까?
• 가정
• 테스트 데이터 : 변수와 그 값
• 실행할 단계
• 예상 결과
• 실제 결과
• 통과 실패
• 코멘트

테스트 케이스 진술의 기본 형식

확인
사용 (도구 이름, 태그 이름, 대화 상자 등)
와 (정황)
에 (반환, 표시, 시연)

확인: 테스트 문장의 첫 단어로 사용됩니다.
사용 : 테스트 대상을 식별합니다. 상황에 따라 사용하는 대신 여기에서‘입력’또는‘선택’을 사용할 수 있습니다.

모든 애플리케이션에 대해 다음과 같은 모든 유형의 테스트를 다루어야합니다.

• 기능성 사례
• 부정적인 경우
• 경계 가치 사례

이 모든 것을 쓰는 동안 TC는 간단하고 이해하기 쉬워야합니다. .

************************************************

시험 작성을위한 팁

소프트웨어 테스터 (SQA / SQC 담당자)의 가장 빈번하고 주요한 활동 중 하나는 테스트 시나리오와 사례를 작성하는 것입니다.

이 주요 활동과 관련된 몇 가지 중요하고 중요한 요소가 있습니다. 먼저 이러한 요소에 대한 조감도를 살펴 보겠습니다.

쓰기 과정과 관련된 중요한 요소 :

a) 최우수 사용자는 정기적으로 수정하고 업데이트하는 경향이 있습니다.

우리는 끊임없이 변화하는 세상에 살고 있으며 소프트웨어에도 마찬가지입니다. 소프트웨어 요구 사항 변경은 사례에 직접적인 영향을 미칩니다. 요구 사항이 변경 될 때마다 TC를 업데이트해야합니다.

그러나 TC의 수정 및 업데이트를 유발할 수있는 것은 요구 사항의 변경뿐이 아닙니다. TC를 실행하는 동안 많은 아이디어가 마음에 떠오르며 단일 TC의 많은 하위 조건이 식별 될 수 있습니다. 이 모든 것이 최우수 사용자를 업데이트하고 때로는 새로운 최우수 사용자를 추가하기도합니다.

또한 회귀 테스트 중에 여러 수정 및 / 또는 잔물결로 인해 수정되거나 새로운 TC가 필요합니다.

b) 최우수 사용자는 다음을 실행할 테스터 사이에 배포되기 쉽습니다.

물론 한 명의 테스터가 모든 TC를 실행하는 상황은 거의 없습니다. 일반적으로 단일 애플리케이션의 서로 다른 모듈을 테스트하는 여러 테스터가 있습니다. 따라서 TC는 테스트중인 애플리케이션의 소유 영역에 따라 테스터간에 나뉩니다.

애플리케이션 통합과 관련된 일부 TC는 여러 테스터가 실행할 수 있고 다른 TC는 단일 테스터 만 실행할 수 있습니다.

c) TC는 클러스터링 및 일괄 처리에 취약합니다.

단일 테스트 시나리오에 속한 TC가 일반적으로 특정 순서 또는 그룹 형태로 실행을 요구하는 것은 일반적이며 일반적입니다. 자신을 실행하기 전에 다른 TC의 실행을 요구하는 TC의 특정 전제 조건이있을 수 있습니다.

마찬가지로 AUT의 비즈니스 로직에 따라 단일 TC가 여러 테스트 조건에 기여할 수 있으며 단일 테스트 조건이 여러 TC로 구성 될 수 있습니다.

d) TC는 상호 의존하는 경향이 있습니다.

이것은 또한 TC가 서로 상호 의존 할 수 있음을 나타내는 흥미롭고 중요한 행동입니다. 복잡한 비즈니스 로직을 사용하는 중대형 애플리케이션에서 이러한 경향이 더 잘 보입니다.

이 동작을 확실히 관찰 할 수있는 응용 프로그램의 가장 명확한 영역은 동일하거나 심지어 다른 응용 프로그램의 서로 다른 모듈 간의 상호 운용성입니다. 간단히 말해서, 단일 애플리케이션 또는 여러 애플리케이션이 서로 다른 모듈이 상호 의존적 일 때마다 동일한 동작이 TC에도 반영됩니다.

e) 최우수 사용자는 개발자간에 배포되는 경향이 있습니다 (특히 테스트 기반 개발 환경에서).

최우수 사용자에 대한 중요한 사실은 이러한 최우수 사용자가 테스터 만 활용하는 것이 아니라는 것입니다. 일반적인 경우 개발자가 버그를 수정하면 간접적으로 TC를 사용하여 문제를 수정하는 것입니다. 마찬가지로 테스트 주도 개발을 따르는 경우 TC는 개발자가 로직을 구축하고 TC가 다루는 코드의 모든 시나리오를 다루기 위해 직접 사용됩니다.

효과적인 테스트 작성 팁 :

위의 5 가지 요소를 염두에두고 효과적인 최우수 사용자를 작성하기위한 몇 가지 도움말입니다.

시작하자!!!

# 1) 단순하게 유지하되 너무 단순하지 않게하십시오. 복잡하지만 너무 복잡하지 않게 만드세요.

이 진술은 역설적으로 보인다. 그러나 나는 그렇지 않다고 약속합니다. 최우수 사용자의 모든 단계를 원자적이고 정확하게 유지하세요. 올바른 순서와 예상 결과에 대한 올바른 매핑으로 단계를 언급합니다. 테스트 케이스는 자체 설명이 필요하고 이해하기 쉬워야합니다. 이것이 제가 간단하게 만드는 것을 의미합니다.

이제 복잡한 것은 테스트 계획 및 기타 TC와 통합하는 것을 의미합니다. 필요할 때 다른 TC, 관련 아티팩트, GUI 등을 참조하십시오. 그러나 균형 잡힌 방식으로 수행하십시오. 단일 테스트 시나리오를 완료하기 위해 테스터가 문서 더미에서 앞뒤로 이동하도록 만들지 마십시오.

반면에 테스터가 이러한 TC를 매우 간결한 방식으로 문서화하도록 허용하지 마십시오. 최우수 사용자를 작성하는 동안 항상 본인이나 다른 사람이이를 수정하고 업데이트해야한다는 점을 기억하세요.

# 2) 테스트 사례를 문서화 한 후 테스터로 한 번 검토합니다.

테스트 시나리오의 마지막 TC를 작성한 후에는 작업이 완료되었다고 생각하지 마십시오. 시작으로 이동하여 모든 최우수 사용자를 한 번 검토합니다.하지만 최우수 사용자 또는 테스트 플래너의 사고 방식은 아닙니다. 테스터의 마음으로 모든 최우수 사용자를 검토합니다. 합리적으로 생각하고 최우수 사용자를 테스트 해보세요.

모든 단계를 평가하고 이해할 수있는 방식으로 명확하게 언급했는지, 예상 결과가 해당 단계와 조화를 이루는 지 확인하십시오.

확인하십시오 테스트 데이터 TC에 지정된 것은 실제 테스터에게만 가능할뿐만 아니라 실시간 환경에 따라 가능합니다. TC간에 종속성 충돌이 없는지 확인하고 다른 TC / 아티팩트 / GUI에 대한 모든 참조가 정확한지 확인하십시오. 그렇지 않으면 테스터가 큰 문제를 겪을 수 있습니다.

# 3) 테스터를 편하게하고 바인딩 :

테스터에게 테스트 데이터를 남겨 두지 마십시오. 특히 계산이 수행되거나 응용 프로그램의 동작이 입력에 의존하는 경우 입력 범위를 제공합니다. 테스트 데이터 항목 값을 결정하도록 할 수 있지만 테스트 데이터 항목을 스스로 선택할 수있는 자유를 절대로주지 않습니다.

의도적으로 또는 의도하지 않게 동일한 테스트 데이터를 반복해서 사용할 수 있으며 TC 실행 중에 일부 중요한 테스트 데이터가 무시 ​​될 수 있기 때문입니다.

테스트 카테고리 및 애플리케이션의 관련 영역별로 최우수 사용자를 구성하여 테스터를 편하게 유지하세요. 명확하게 어떤 TC가 상호 의존적이거나 일괄 처리되는지 지시하고 언급합니다. 마찬가지로 테스터가 그에 따라 전체 활동을 관리 할 수 ​​있도록 어떤 TC가 독립적이고 격리되어 있는지 명시 적으로 표시합니다.

이 시점에서 블랙 박스 테스트에 사용되는 테스트 케이스 설계 전략 인 경계 값 분석에 대해 읽어 보는 것이 좋습니다. 딸깍 하는 소리 여기 그것에 대해 더 알고 싶습니다.

# 4) 기여자되기 :

FS 또는 설계 문서를있는 그대로 받아들이지 마십시오. 당신의 임무는 FS를 통과하고 테스트 시나리오를 식별하는 것이 아닙니다. QA 리소스이기 때문에 주저하지 말고 비즈니스에 기여하고 애플리케이션에서 개선 할 수 있다고 생각되면 제안을 제공하십시오.

특히 TC 기반 개발 환경에서 개발자에게도 제안하십시오. 드롭 다운 목록, 캘린더 컨트롤, 선택 목록, 그룹 라디오 버튼, 더 의미있는 메시지,주의, 프롬프트, 유용성 관련 개선 사항 등을 제안합니다.

QA가 되려면 테스트 만하는 것이 아니라 차이를 만드세요!

# 5) 최종 사용자를 잊지 마십시오 :

가장 중요한 이해 관계자는 최종적으로 애플리케이션을 사용할 '최종 사용자'입니다. 따라서 최우수 사용자가 작성하는 단계에서 그를 잊지 마십시오. 사실, 최종 사용자는 SDLC의 모든 단계에서 무시되어서는 안됩니다. 그러나 지금까지 강조한 내용은 내 주제와 관련이 있습니다.

따라서 테스트 시나리오를 식별하는 동안 사용자가 주로 사용하는 사례 또는 덜 자주 사용 되더라도 업무상 중요한 사례를 간과하지 마십시오. 최종 사용자의 입장이되어 모든 TC를 살펴보고 문서화 된 모든 TC를 실행하는 실질적인 가치를 판단하십시오.

************************************************

테스트 케이스 문서에서 우수성을 달성하는 방법

소프트웨어 테스터이기 때문에 완벽한 테스트 문서를 만드는 것이 정말 어려운 작업이라는 점에 분명히 동의 할 것입니다.

우리는 항상 개선의 여지가 있습니다. 테스트 케이스 문서 . 때로는 TC를 통해 100 % 테스트 범위를 제공 할 수없고 때로는 테스트 템플릿이 동등하지 않거나 테스트에 대한 가독성과 명확성을 제공하지 못합니다.

테스터로서 테스트 문서를 작성하라는 요청을받을 때마다 임시로 시작하지 마십시오. 문서화 프로세스를 수행하기 전에 테스트 케이스 작성의 목적을 이해하는 것이 매우 중요합니다.

테스트는 항상 명확하고 명료해야합니다. 테스터가 각 테스트에 정의 된 단계를 따라 전체 테스트를 쉽게 수행 할 수 있도록 작성해야합니다.

또한 테스트 케이스 문서에는 완전한 제공에 필요한만큼의 케이스가 포함되어야합니다. 테스트 범위 . 예를 들어 , 소프트웨어 응용 프로그램 내에서 발생할 수있는 모든 가능한 시나리오에 대한 테스트를 다루어야합니다.

위의 사항을 염두에두고 테스트 문서에서 우수성을 달성하는 방법에 대해 살펴 보겠습니다.

유용한 팁과 요령

여기에서는 테스트 문서에서 다른 사람과 비교하여 도움이 될 수있는 몇 가지 유용한 지침을 제공 할 것입니다.

# 1) 테스트 문서가 양호한 상태입니까?

테스트 문서를 구성하는 가장 쉽고 간단한 방법은 여러 개의 유용한 섹션으로 분할하는 것입니다. 전체 테스트를 여러 테스트 시나리오로 나눕니다. 그런 다음 각 시나리오를 여러 테스트로 나눕니다. 마지막으로 각 사례를 여러 테스트 단계로 나눕니다.

Excel을 사용하는 경우 각 테스트 사례가 하나의 완전한 테스트 흐름을 설명하는 통합 문서의 별도 시트에 각 테스트 사례를 문서화합니다.

# 2) 부정적인 사례를 다루는 것을 잊지 마십시오

소프트웨어 테스터는 상자 밖에서 생각하고 응용 프로그램이 제공하는 모든 가능성을 도출해야합니다. 테스터로서 우리는 소프트웨어에 입력하려는 인증되지 않은 시도 나 애플리케이션을 통과하는 유효하지 않은 데이터 흐름을 중지하고보고해야하는지 확인해야합니다.

따라서 부정적인 경우는 긍정적 인 경우만큼 중요합니다. 각 시나리오에 대해 두 개의 테스트 케이스-하나의 양성 및 하나의 음성 . 긍정적 인 것은 의도 된 또는 정상적인 흐름을 커버해야하고 부정적인 것은 의도하지 않거나 예외적 인 흐름을 커버해야합니다.

# 3) 원자 테스트 단계

각 테스트 단계는 원자 적 단계 여야합니다. 더 이상 하위 단계가 없어야합니다. 테스트 단계가 간단하고 명확할수록 테스트를 진행하기가 더 쉬워집니다.

# 4) 테스트 우선 순위 지정

우리는 종종 애플리케이션 테스트를 완료하기 위해 엄격한 타임 라인을 가지고 있습니다. 이 경우 소프트웨어의 중요한 기능과 측면 중 일부를 테스트하지 못할 수 있습니다. 이를 방지하려면 각 테스트를 문서화하는 동안 우선 순위에 태그를 지정해야합니다.

테스트 우선 순위를 정의하기 위해 모든 인코딩을 사용할 수 있습니다. 일반적으로 3 단계 중 하나를 사용하는 것이 좋습니다. 높음, 중간 및 낮음 , 또는 1, 50 및 100. 따라서 엄격한 일정이있는 경우 우선 순위가 높은 모든 테스트를 먼저 완료 한 다음 중간 및 낮은 우선 순위 테스트로 이동해야합니다.

예를 들어 – 쇼핑 웹 사이트의 경우 앱 로그인 시도가 무효화되어 접근 거부를 확인하는 것이 우선 순위가 높을 수 있으며, 사용자 화면에 관련 상품이 표시되는지 확인하는 것은 중간 우선 순위가 될 수 있으며 표시되는 텍스트의 색상을 확인하는 것입니다. 화면 버튼은 낮은 우선 순위 테스트가 될 수 있습니다.

# 5) 시퀀스 문제

테스트 단계의 순서가 절대적으로 올바른지 확인하십시오. 잘못된 단계 순서는 혼란을 초래할 수 있습니다. 가급적이면 테스트중인 특정 시나리오에 대해 앱에 들어가고 앱을 종료 할 때까지 전체 시퀀스를 정의해야합니다.

# 6) 댓글에 타임 스탬프 및 테스터 이름 추가

애플리케이션을 테스트하는 경우, 누군가가 동일한 앱을 동시에 수정하거나 테스트가 완료된 후 누군가가 앱을 업데이트 할 수 있습니다. 이로 인해 테스트 결과가 시간에 따라 달라질 수있는 상황이 발생합니다.

따라서 테스트 결과 (합격 또는 실패)가 해당 특정 시간의 애플리케이션 상태에 기여할 수 있도록 테스트 주석에 테스터 이름과 함께 타임 스탬프를 추가하는 것이 항상 좋습니다. 또는‘ 실행 날짜 ’열은 테스트의 타임 스탬프를 명시 적으로 식별하는 테스트 케이스에 별도로 추가되었습니다.

# 7) 브라우저 세부 정보 포함

아시다시피 웹 애플리케이션 인 경우 테스트가 실행되는 브라우저에 따라 테스트 결과가 다를 수 있습니다. 다른 테스터, 개발자 또는 테스트 문서를 검토하는 사람의 편의를 위해 결함이 쉽게 복제 될 수 있도록 브라우저 이름과 버전을 케이스에 추가해야합니다.

# 8) 문서에 '버그'와 '요약'이라는 두 개의 별도 시트를 보관하십시오.

Excel로 문서화하는 경우 통합 문서의 처음 두 장은 요약 및 버그 여야합니다. 요약 시트는 테스트 시나리오를 요약하고 버그 시트는 테스트 중에 발생한 모든 문제를 나열해야합니다. 이 두 시트를 추가하는 것의 중요성은 문서의 독자 / 사용자에게 테스트에 대한 명확한 이해를 제공한다는 것입니다.

따라서 시간이 제한 될 때이 두 시트는 ​​테스트 개요를 제공하는 데 매우 유용 할 수 있습니다.

테스트 문서는 가능한 최상의 테스트 범위와 뛰어난 가독성을 제공해야하며 전체적으로 하나의 표준 형식을 따라야합니다.

테스트 케이스 문서의 구성으로 몇 가지 필수 팁을 염두에두고 TC의 우선 순위를 지정하고 TC를 실행하는 데 필요한 모든 필수 세부 정보를 포함하여 모든 것을 적절한 순서로 유지하고 명확하고 명료 한 테스트 단계를 제공함으로써 테스트 문서의 우수성을 달성 할 수 있습니다. 등.

************************************************

테스트를 작성하지 않는 방법

우리는 대부분의 시간을이를 작성, 검토, 실행 또는 유지하는 데 보냅니다. 테스트가 가장 오류가 발생하기 쉬운 테스트라는 것은 매우 불행한 일입니다. 이해, 조직 테스트 관행, 시간 부족 등의 차이는 우리가 종종 많은 것을 원하는 테스트를 보는 이유 중 일부입니다.

이 주제에 대한 우리 사이트에는 많은 기사가 있지만 여기에서는 테스트 케이스를 작성하지 않는 방법 – 독특하고 품질이 뛰어나며 효과적인 테스트를 만드는 데 도움이 될 몇 가지 팁입니다.

이 팁은 신규 테스터와 숙련 된 테스터 모두를위한 것입니다.

테스트 케이스에서 가장 일반적인 3 가지 문제

1. 복합 단계
2. 애플리케이션 동작이 예상 된 동작으로 간주됩니다.
3. 하나의 경우에 여러 조건

이 세 가지는 시험 작성 과정에서 자주 발생하는 문제의 상위 3 개 목록에 있어야합니다.

흥미로운 점은 이러한 문제가 신규 테스터와 숙련 된 테스터 모두에서 발생하며 몇 가지 간단한 조치로 문제를 쉽게 해결할 수 있다는 사실을 결코 깨닫지 못한 채 동일한 결함이있는 프로세스를 계속 따르고 있다는 것입니다.

이에 대해 자세히 논의 해 보겠습니다.

# 1) 복합 단계

먼저 복합 단계 란 무엇입니까?

예를 들어, 당신은 지점 A에서 지점 B로가는 길을 제공하고 있습니다. 만약 당신이“XYZ 장소로 가서 ABC로가”라고 말한다면 이것은 별 의미가 없을 것입니다. 먼저 XYZ에 도착하세요.”대신“여기에서 좌회전하여 1 마일 이동 한 다음 Rd에서 우회전하십시오. 더 나은 결과를 얻을 수 있습니다.

테스트와 단계에도 똑같은 규칙이 적용됩니다.

예를 들어 Amazon.com에 대한 테스트를 작성하고 있습니다. 모든 제품을 주문하십시오.

다음은 내 테스트 단계입니다 (참고 : 예상 결과와 같은 테스트의 다른 모든 부분이 아닌 단계 만 작성하고 있습니다.)

...에 . Amazon.com 시작
비 . 화면 상단의 '검색'필드에 제품 키워드 / 이름을 입력하여 제품을 검색합니다.
씨 . 표시된 검색 결과에서 첫 번째를 선택하십시오.
디 . 상품 상세 페이지에서 장바구니에 추가를 클릭합니다.
이다 . 결제 및 결제.
에프 . 주문 확인 페이지를 확인하십시오.

지금, 이 중 어느 것이 복합 단계인지 식별 ​​할 수 있습니까? 오른쪽 단계 (e)

테스트는 항상 테스트하는 '방법'에 관한 것이므로 테스트에서 '결제 및 지불 방법'의 정확한 단계를 작성하는 것이 중요합니다.

따라서 위의 경우는 아래와 같이 작성하면 더 효과적입니다.

...에 . Amazon.com 시작
비 . 화면 상단의 '검색'필드에 제품 키워드 / 이름을 입력하여 제품을 검색합니다.
씨 . 표시된 검색 결과에서 첫 번째를 선택하십시오.
디 . 상품 상세 페이지에서 장바구니에 추가를 클릭합니다.
이다 . 장바구니 페이지에서 결제를 클릭하십시오.
에프 . CC 정보, 배송 및 청구 정보를 입력합니다.
지 . 체크 아웃을 클릭합니다.
h . 주문 확인 페이지를 확인하십시오.

따라서 복합 단계는 여러 개별 단계로 나눌 수있는 단계입니다. 다음 번에 테스트를 작성할 때 모두이 부분에주의를 기울이고 우리가 생각하는 것보다 더 자주이 작업을 수행한다는 데 동의하실 것입니다.

# 2) 애플리케이션 동작이 예상 된 동작으로 간주됩니다.

요즘에는 점점 더 많은 프로젝트가이 상황을 다루어야합니다.

문서의 부족, 극단적 인 프로그래밍, 빠른 개발주기는 테스트를 작성하거나 테스트 자체를 기반으로하기 위해 애플리케이션 (이전 버전 등)에 의존해야하는 몇 가지 이유입니다. 항상 그렇듯이 이것은 입증 된 나쁜 습관입니다. 항상 그런 것은 아닙니다.

열린 마음을 유지하고 'AUT에 결함이있을 수 있습니다'라는 기대를 유지하는 한 무해합니다. 당신이 그렇게 생각하지 않을 때만 일이 나쁘게 작동합니다. 항상 그렇듯이 우리는 예제를 통해 이야기 할 것입니다.

다음이 테스트 단계를 작성 / 디자인하는 페이지 인 경우 :

사례 1 :

내 테스트 케이스 단계가 다음과 같은 경우 :

1. 쇼핑 사이트를 시작합니다.
2. 배송 및 반품을 클릭합니다. 예상 결과 : '여기에 정보 입력'및 '계속'버튼이있는 배송 및 반품 페이지가 표시됩니다.

그렇다면 이것은 잘못된 것입니다.

사례 2 :

1. 쇼핑 사이트를 시작합니다.
2. 배송 및 반품을 클릭하십시오.
3. 이 화면에있는 '주문 번호 입력'텍스트 상자에 주문 번호를 입력합니다.
4. 계속 클릭-예상 결과 : 배송 및 반품과 관련된 주문 세부 정보가 표시됩니다.

참조 응용 프로그램이 잘못 작동하더라도 사례 2는 더 나은 테스트 사례입니다. 왜냐하면 참조 응용 프로그램이 잘못 작동하더라도이를 지침으로 삼고 추가 조사를 수행하고 예상되는 올바른 기능에 따라 예상되는 동작을 작성하기 때문입니다.

결론 : 참고로 응용 프로그램은 빠른 지름길이지만 자체 위험이 따릅니다. 우리가 조심스럽고 비판적인 한 놀라운 결과를 낳습니다.

# 3) 하나의 경우에 여러 조건

다시 한 번 예 .

아래 테스트 단계를 살펴보십시오. 다음은 로그인 기능에 대한 한 테스트 내의 테스트 단계입니다.

ㅏ. 유효한 세부 정보를 입력하고 제출을 클릭합니다.
비. 사용자 이름 필드는 비워 둡니다. 제출을 클릭하십시오.
씨. 비밀번호 필드를 비워두고 제출을 클릭하십시오.
디. 이미 로그인 한 사용자 이름 / 비밀번호를 선택하고 제출을 클릭하십시오.

4 개의 다른 케이스 여야했던 것이 하나로 결합됩니다. 당신은 생각할 수 있습니다-그게 뭐가 잘못 됐나요? 많은 문서를 절약하고 4에서 할 수있는 작업은 1-에서 수행하고 있습니다. 글쎄요. 원인?

읽어:

• 조건 중 하나가 실패하면 전체 테스트를 '실패'로 표시해야합니다. 전체 사례를 '실패'로 표시하면 4 가지 조건이 모두 작동하지 않는 것이며 이는 사실이 아닙니다.
• 테스트에는 흐름이 있어야합니다. 전제 조건에서 1 단계 및 모든 단계까지. 이 경우를 수행하면 (a) 단계에서 성공하면 '로그인'옵션을 더 이상 사용할 수없는 페이지에 로그인됩니다. 그래서 (b) 단계에 도달하면 테스터가 사용자 이름을 어디에 입력할까요? 보시다시피 흐름이 끊어졌습니다.

그 후, 모듈 형 테스트 작성 . 많은 작업처럼 들리지만 필요한 것은 사물을 분리하고 가장 친한 친구 인 Ctrl + C와 Ctrl + V를 사용하여 우리를 위해 일하는 것입니다. :)

************************************************

테스트 케이스 효율성을 개선하는 방법

소프트웨어 테스터는 소프트웨어 개발 수명주기의 초기 단계에서 테스트를 작성해야하며 소프트웨어 요구 사항 단계에서 가장 적합합니다.

테스트 관리자 또는 QA 관리자는 아래 목록에 따라 가능한 최대 문서를 수집하고 준비해야합니다.

시험 작성을위한 문서 수집

# 1) 사용자 요구 사항 문서

비즈니스 프로세스, 사용자 프로필, 사용자 환경, 다른 시스템과의 상호 작용, 기존 시스템 교체, 기능 요구 사항, 비 기능 요구 사항, 라이선스 및 설치 요구 사항, 성능 요구 사항, 보안 요구 사항, 유용성 및 동시 요구 사항 등을 나열하는 문서입니다. .,

# 2) 비즈니스 사용 사례 문서

이 문서는 사용 사례 비즈니스 관점에서 기능 요구 사항의 시나리오. 이 문서는 비즈니스 행위자 (또는 시스템), 목표, 사전 조건, 사후 조건, 기본 흐름, 대체 흐름, 옵션, 요구 사항에 따라 시스템의 각 비즈니스 흐름에 대한 예외를 다룹니다.

# 3) 기능 요구 사항 문서

이 문서에서는 요구 사항에 따라 시스템에 대한 각 기능의 기능 요구 사항을 자세히 설명합니다.

일반적으로 기능 요구 사항 문서는 모든 소프트웨어 개발에서 가장 중요한 문서로 취급되어야하는 커밋 된 (때때로 고정 된) 요구 사항에 대한 고객을 포함하여 개발 및 테스트 팀뿐만 아니라 프로젝트 이해 관계자들에게 공통 저장소 역할을합니다.

# 4) 소프트웨어 프로젝트 계획 (선택 사항)

프로젝트, 목표, 우선 순위, 마일스톤, 활동, 조직 구조, 전략, 진행 상황 모니터링, 위험 분석, 가정, 종속성, 제약 조건, 교육 요구 사항, 클라이언트 책임, 프로젝트 일정 등에 대한 세부 정보를 설명하는 문서

# 5) QA / 테스트 계획

이 문서는 품질 관리 시스템, 문서화 표준, 변경 제어 메커니즘, 중요 모듈 및 기능, 구성 관리 시스템, 테스트 계획, 결함 추적, 승인 기준 등을 자세히 설명합니다.

그만큼 테스트 계획 문서는 테스트 할 기능, 테스트하지 않을 기능, 테스트 팀 할당 및 해당 인터페이스, 리소스 요구 사항, 테스트 일정, 테스트 작성, 테스트 범위, 테스트 결과물, 테스트 실행을위한 전제 조건, 버그보고 및 추적을 식별하는 데 사용됩니다. 메커니즘, 테스트 메트릭 등

실제 예

아래 그림과 같이 친숙하고 간단한 '로그인'화면의 테스트 케이스를 효율적으로 작성하는 방법을 살펴 보겠습니다. 그만큼 테스트 접근 방식 더 많은 정보와 중요한 기능이있는 복잡한 화면에서도 거의 동일합니다.

#1) 테스트 케이스 프로세스의 첫 번째 접근 방식은 가능한 경우 위와 같이 화면 프로토 타입 (또는 와이어 프레임)을 얻는 것입니다. 이는 일부 기능에 대해 사용 가능하지 않을 수 있으며 개발 초기 단계에서 프로토 타입 설계의 중요성에 따라 다릅니다.

그러나 SRS (소프트웨어 요구 사항 사양) 문서 대부분의 화면 프로토 타입은 프로젝트 팀에서 개발합니다. 이러한 종류의 화면은 테스터의 작업을 단순화하고 테스트의 효율성을 높입니다.

#두) 다음으로 기능 요구 사항 사양 . 조직 프로세스에 따라 다르며 여러 문서 모음에서 사용할 수 있습니다.

따라서 사용자 요구 사항 문서 또는 기능 요구 사항 사양 (또는 테스트 팀이 편안하게 이해할 수있는 경우 SRS 문서) 중 하나를 사용하여 사례 작성에 가장 적합한 문서를 결정하십시오. 테스트 할 기능입니다.

#삼) 스크린 프로토 타입과 기능 사양이 준비되면 테스터는 다음 접근 방식과 기준으로 사례 작성을 시작해야합니다.

• UI 테스트 :사용자에게 표시되는 컨트롤 / 필드입니다. 테스트 할 기능에 사용할 수있는 정적 제어 및 동적 제어가 있습니다. 예를 들어, 위의 로그인 화면에서 '사용자 이름 및 비밀번호'텍스트는 텍스트 만 표시하기 위해 사용자 상호 작용이 필요하지 않은 정적 필드입니다.

• 기능성 케이스 :반면에 로그인 버튼과 하이퍼 링크 (비밀번호 분실? 및 등록)는 컨트롤을 클릭하여 사용자 상호 작용이 필요한 동적 필드이며 나중에 몇 가지 작업을 수행합니다.

• 데이터베이스 사례 :사용자가 사용자 이름과 암호를 입력하면 사용자 이름과 암호가 올바른 데이터베이스와 테이블에서 확인되었는지 여부와 사용자가 테스트중인 애플리케이션에 로그인 할 수있는 권한이 있는지 여부를 관련 데이터베이스를 확인하기 위해 테스트를 작성할 수 있습니다.
  

• 공정 테스트 :이는 기능 및 기능과 관련된 프로세스 (화면에서 사용 가능한 표시 컨트롤과 관련된 작업이 아님)와 관련이 있습니다. 예를 들어, 위 샘플 화면에서 비밀번호 분실 링크를 클릭하면 사용자에게 이메일이 전송 될 수 있습니다. 따라서 적절한 프로세스와 확인을 위해 이메일을 테스트해야 할 수도 있습니다.

4) 마지막으로 ' BAOE 만트라 ”, 의미 i) 기본 흐름 ii) 대체 흐름 iii) 옵션 및 iv) 예외 테스트 할 기능 흐름 및 기능의 전체 범위를 확인하십시오. 모든 개념은 양성 및 음성 테스트에 적용되어야합니다.

예를 들어, 위의 샘플 로그인 화면에 대한 간단한 BAOE 접근 방식을 살펴 보겠습니다.

• 기본 흐름 : 브라우저에서 로그인의 URL 경로를 입력하고 필요한 정보를 입력하고 애플리케이션에 로그인합니다.
• 대체 흐름 : 모바일 장치에 응용 프로그램을 설치하고 필요한 정보를 입력하고 응용 프로그램에 로그인합니다.
• 옵션 : 동일한 로그인 화면에서 사용할 수있는 옵션은 무엇입니까? 예를 들어, 애플리케이션에 로그인 한 후 '로그 아웃'을 클릭하면 동일한 화면이 표시되거나 세션 시간 초과 또는 세션이 만료 된 경우 사용자가 로그인 화면으로 이동할 수 있습니다.
• 예외 : 검사 결과가 음성이면 예외는 무엇입니까? 예를 들어, 로그인 화면에 잘못된 자격 증명을 입력 한 경우 사용자에게 오류 메시지가 표시되는지 여부와 관련된 작업이 없습니다.

이 모든 정보를 가지고 로그인 화면에 대한 TC를 완전한 커버리지와 추적 가능성이있는 형식으로 자세한 정보와 함께 작성해 보겠습니다. '를 식별하는 논리적 순서 및 번호 매기기 테스트 케이스 ID’ 테스트 케이스의 빠른 식별 실행 기록에 매우 유용합니다.

또한 읽으십시오=> 웹 및 데스크톱 애플리케이션에 사용할 수있는 180 개 이상의 샘플 테스트 케이스.

테스트 케이스 문서

jar 파일 사용 방법

노트 : 테스트 열은 아래의 샘플 테스트 문서에 국한되지 않으며, 전체 추적 성 매트릭스 즉, 우선 순위, 테스트 목적, 테스트 유형, 오류 스크린 샷 위치에 필요한만큼의 열을 포함하도록 Excel 시트에서 유지 관리 할 수 ​​있습니다. 기타.,

또한 읽으십시오=> 예제가 포함 된 샘플 테스트 케이스 템플릿입니다.

이 문서의 단순성과 가독성을 위해 로그인 화면에 대한 테스트의 재현, 예상 및 실제 동작을 아래에 자세히 작성하는 단계를 작성하겠습니다.

노트 :이 템플릿 끝에 실제 동작 열을 추가합니다.

테스트 데이터 수집

테스트 케이스가 작성 될 때 모든 테스터에게 가장 중요한 작업은 테스트 데이터를 수집하는 것입니다. 이 활동은 테스트 케이스가 일부 샘플 데이터 또는 더미 데이터로 실행될 수 있고 데이터가 실제로 필요할 때 공급 될 수 있다는 가정하에 많은 테스터가 건너 뛰고 간과합니다. 이것은 테스트 케이스를 실행할 때 마인드 메모리에서 샘플 데이터 또는 입력 데이터를 공급한다는 중대한 오해입니다.

테스트 작성시 테스트 문서에서 데이터가 수집 및 업데이트되지 않으면 테스터는 테스트 실행시 데이터를 수집하는 데 비정상적으로 더 많은 시간을 소비하게됩니다. 기능의 기능 흐름의 모든 관점에서 양성 및 음성 사례 모두에 대해 테스트 데이터를 수집해야합니다. 비즈니스 사용 사례 문서는이 상황에서 매우 유용합니다.

위에 작성된 테스트에 대한 샘플 테스트 데이터 문서를 찾으십시오. 그러면 테스트 실행시 작업을 용이하게하는 데이터를 얼마나 효과적으로 수집 할 수 있는지에 도움이 될 것입니다.

************************************************

테스트 케이스 표준화의 중요성

이 바쁜 세상에서 아무도 같은 수준의 관심과 에너지로 매일 반복되는 일을 할 수 없습니다. 특히 직장에서 똑같은 일을 반복하는 것에 열정이 없습니다. 나는 물건을 관리하고 시간을 절약하는 것을 좋아합니다. IT 전문가라면 누구나 그렇게해야합니다.

모든 IT 회사는 다양한 유형의 프로젝트를 실행합니다. 이러한 프로젝트는 제품 기반이거나 서비스 기반 일 수 있습니다. 이 프로젝트 중 대부분은 웹 사이트와 웹 사이트 테스트 . 그것에 대한 좋은 소식은 모든 웹 사이트가 많은 유사점을 가지고 있다는 것입니다. 그리고 웹 사이트가 동일한 도메인에 대한 경우 몇 가지 공통 기능도 있습니다.

항상 저를 당황하게하는 질문은 다음과 같습니다.“예를 들어, 수천 번 테스트를 거친 소매 사이트와 같이 대부분의 애플리케이션이 유사하다면“왜 우리는 또 다른 소매 사이트에 대한 테스트 케이스를 처음부터 작성해야합니까? ” 이전 소매 사이트를 테스트하는 데 사용 된 기존 테스트 스크립트를 가져 와서 시간을 많이 절약하지 않을까요?

물론 우리가해야 할 사소한 조정이있을 수 있지만 전반적으로 더 쉽고 효율적이며 시간과 비용을 절약 할 수 있으므로 항상 테스터의 관심 수준을 높게 유지하는 데 도움이됩니다. 누가 동일한 테스트 케이스를 반복적으로 작성, 검토 및 유지하는 것을 좋아합니까? 기존 테스트를 재사용하면이 문제를 크게 해결할 수 있으며 고객도이 문제를 현명하고 논리적이라고 생각할 것입니다.

그래서 논리적으로 비슷한 웹 기반 프로젝트에서 기존 스크립트를 가져 와서 변경 한 후 빠르게 검토했습니다. 또한 검토자가 변경된 부분에만 집중할 수 있도록 색상 코딩을 사용하여 변경 사항을 표시했습니다.

테스트 케이스를 재사용해야하는 이유

#1) 웹 사이트의 대부분의 기능 영역은 거의 로그인, 등록, 장바구니에 추가, 위시리스트, 체크 아웃, 배송 옵션, 결제 옵션, 제품 페이지 콘텐츠, 최근에 본, 관련 제품, 프로모션 코드 기능 등입니다.

#두) 대부분의 프로젝트는 기존 기능의 향상 또는 변경 일뿐입니다.

#삼) 정적 및 동적 방식으로 이미지 업로드 슬롯을 정의하는 콘텐츠 관리 시스템도 모든 웹 사이트에서 일반적입니다.

# 4) 소매 웹 사이트에는 CSR (고객 서비스) 시스템도 있습니다.

# 5) JDA를 사용하는 백엔드 시스템 및웨어 하우스 애플리케이션도 모든 웹 사이트에서 사용됩니다.

# 6) 쿠키, 시간 제한 및 보안의 개념도 일반적입니다.

# 7) 웹 기반 프로젝트는 요구 사항이 자주 변경되기 쉽습니다.

# 8) 그만큼 테스트 유형 필요한 것은 브라우저와 같이 일반적입니다. 호환성 테스트 , 성능 시험 , 보안 테스트

보시다시피, 공통적이고 유사한 것이 많이 있습니다.

재사용 가능성은 갈 길이라고 말했지만 때로는 수정 자체에 다소 시간이 걸리거나 걸리지 않을 수도 있습니다. 때로는 너무 많이 수정하는 것보다 처음부터 시작하는 것이 더 낫다고 느낄 수도 있습니다.

이는 공통 기능 각각에 대한 표준 테스트 케이스 세트를 작성하여 쉽게 처리 할 수 ​​있습니다.

웹 테스트에서 표준 테스트 란 무엇입니까?

• 단계, 데이터, 변수 등 완전한 테스트 케이스를 생성합니다. 이렇게하면 유사한 테스트 케이스가 필요할 때 유사하지 않은 데이터 / 변수를 간단히 교체 할 수 있습니다.
• 입구 및 출구 기준은 적절하게 정의되어야합니다.
• 수정 가능한 단계 또는 단계의 설명은 빠른 찾기 및 바꾸기를 위해 다른 색상으로 강조 표시되어야합니다.
• 표준 테스트 케이스 작성에 사용되는 언어는 일반적이어야합니다.
• 각 웹 사이트의 모든 기능은 테스트 케이스에서 다루어야합니다.
• 테스트 케이스의 이름은 테스트 케이스가 다루는 기능 또는 기능의 이름이어야합니다. 이렇게하면 세트에서 테스트 케이스를 훨씬 쉽게 찾을 수 있습니다.
• 기능의 기본 또는 표준 샘플 또는 GUI 파일 또는 스크린 샷이있는 경우 관련 단계와 함께 첨부해야합니다.

위의 팁을 사용하여 표준 스크립트 세트를 만들고 다른 웹 사이트에 대해 거의 또는 필요한 수정없이 사용할 수 있습니다.

이러한 표준 테스트 사례도 자동화 할 수 있지만 다시 한 번 재사용성에 초점을 맞추는 것은 항상 장점입니다. 또한 오토메이션 GUI를 기반으로하므로 여러 URL 또는 사이트에서 스크립트를 재사용하는 것은 개인적으로 결코 효과적이지 않은 것입니다.

웹 사이트 테스트를 수행하는 가장 좋은 방법은 여러 웹 사이트에 대해 표준 수동 테스트 케이스 세트를 사용하는 것입니다. 우리에게 필요한 것은 적절한 표준과 사용으로 테스트 케이스를 만들고 유지하는 것입니다.

결론

테스트 케이스 효율성 개선은 단순히 정의 된 용어가 아니라 연습이며 성숙한 프로세스와 정기적 인 연습을 통해 달성 할 수 있습니다.

테스트 팀은 품질 세계에서 더 큰 성과를 달성 할 수있는 최고의 도구이므로 이러한 작업의 개선에 지치지 않아야합니다. 이는 전 세계의 많은 테스트 조직에서 미션 크리티컬 프로젝트 및 복잡한 애플리케이션에 대해 입증되었습니다.

테스트 케이스의 개념에 대해 방대한 지식을 얻었기를 바랍니다. 테스트 사례에 대해 자세히 알아 보려면 튜토리얼 시리즈를 시청하고 아래 댓글 섹션에 자유롭게 의견을 표현하십시오!

다음 튜토리얼

추천 도서

• 기능 테스트 대 비 기능 테스트
• 실용적인 예제가 포함 된 이식성 테스트 가이드
• 소프트웨어 테스트 유형 : 세부 정보가있는 다양한 테스트 유형
• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 알파 테스트 및 베타 테스트 (전체 가이드)
• 시스템 테스트 란 무엇입니까-궁극의 초보자 가이드
• ISTQB 테스트 인증 샘플 질문 문서 (답변 포함)
• 소프트웨어 테스트 주간 상태 보고서 작성 방법