메뉴

자동화 테스트 란 무엇입니까 (테스트 자동화 시작을위한 궁극적 인 가이드)

  • 메인
  • 자동화 테스트
  • 자동화 테스트 란 무엇입니까 (테스트 자동화 시작을위한 궁극적 인 가이드)

what is automation testing

문제를 제거하기 위해 도구를 사용해보십시오

프로젝트에서 자동화 테스트를 시작하기위한 완전한 가이드 :

자동화 테스트 란 무엇입니까?

자동화 테스트는 실제 결과와 예상 결과를 테스트하고 비교하는 소프트웨어 테스트 기술입니다. 이는 테스트 스크립트를 작성하거나 자동화 테스트 도구를 사용하여 수행 할 수 있습니다. 테스트 자동화는 반복적 인 작업과 수동으로 수행하기 어려운 기타 테스트 작업을 자동화하는 데 사용됩니다.

자동화 테스트 가이드

프로젝트에서 자동화 테스트를 시작하고 싶지만 아래에 언급 된 가장 기본적인 단계로 어려움을 겪고 있습니까?

  • 프로젝트에 자동화를 도입하는 방법은 무엇입니까?
  • 최상의 자동화 도구를 선택하는 방법은 무엇입니까?
  • 스크립트를 효과적으로 개발하는 방법은 무엇입니까?
  • 테스트 스크립트를 실행하고 유지하는 방법은 무엇입니까?
  • 마지막으로 성공적인 자동화 테스트를 위해 따라야 할 모범 사례는 무엇입니까?

오늘 우리는 '에 대한 일련의 자습서를 통해 귀하의 지식을 풍부하게 할 계획입니다. 자동화 테스트 시작하기 ”. 이 일련의 자동화 자습서는 간단한 예제를 사용하여 위의 모든 질문에 단계별로 답변합니다.

프로젝트에서 자동화 시작에 대한 일련의 자습서를 살펴 보겠습니다 !!

자동화 엔드-투-엔드 프로세스 :

튜토리얼 # 1 : 프로젝트 자동화 시작을위한 최고의 가이드
튜토리얼 # 2 : 자동화 테스트 유형 및 일부 오해
튜토리얼 # 3 : 프로젝트에 자동화를 도입하는 10 단계
튜토리얼 # 4 : 최고의 자동화 도구 선택에 대한 A to Z 가이드
튜토리얼 # 5 : 스크립트 개발 및 자동화 프레임 워크
튜토리얼 # 6 : 자동화 실행 및보고
튜토리얼 # 7 : 테스트 자동화의 모범 사례 및 전략

자동화 팁 :

튜토리얼 # 8 : 테스트 작업을 자동화하기 전에 읽어야 할 10 가지 팁
튜토리얼 # 9 : 수동 및 자동화 프로젝트에 대한 테스트 계획의 차이점
튜토리얼 # 10 : 언제 자동화를 선택해야합니까?
튜토리얼 # 11 : 자동화 테스트 과제
튜토리얼 # 12 : 자동화에서 개념 증명 (POC) 구현 가이드
튜토리얼 # 13 : 자동화를위한 올바른 테스트 사례를 선택하는 방법
튜토리얼 # 14 : 수동 테스트 케이스를 자동화 스크립트로 변환하는 방법

자동화 경력 :

튜토리얼 # 15 : 더 나은 자동화 테스터가되기위한 팁
튜토리얼 # 16 : 테스트 자동화 – 전문 직업입니까? 일반 테스터도 자동화 할 수 있습니까?

인기있는 자동화 도구 :

튜토리얼 # 17 : Selenium 자습서 31+ 최고의 무료 Selenium 교육 자습서
튜토리얼 # 18 : QTP 튜토리얼
튜토리얼 # 19 : SoapUI 웹 서비스 테스트 도구
튜토리얼 # 20 : 성능 테스트 용 HP LoadRunner

자동화 프레임 워크 :

튜토리얼 # 21 : 자동화를위한 프레임 워크가 필요한 이유
튜토리얼 # 22 : 가장 인기있는 자동화 프레임 워크

애자일의 자동화 :

튜토리얼 # 23 : 애자일 세계에서 효율적인 자동화를 구현하는 방법

기타 자동화 도구 :

튜토리얼 # 24 : 최고의 자동화 테스트 도구
튜토리얼 # 25 : Sikuli GUI 자동화 도구
튜토리얼 # 26 : PowerShell : PowerShell을 사용한 데스크톱 애플리케이션 UI 자동화
튜토리얼 # 27 : Catalon 자동화 레코더 (Selenium IDE 대안)
튜토리얼 # 28 : Geb 도구 : Geb 도구를 사용한 브라우저 자동화
튜토리얼 # 29 : AutoIt : AutoIt을 사용하여 Windows 팝업을 처리하는 방법
튜토리얼 # 30 : 오이 : 오이 도구와 셀레늄을 사용한 자동화
튜토리얼 # 31 : AngularJS 애플리케이션의 엔드-투-엔드 테스트를위한 각도기 테스트 도구

모바일 자동화 테스트 :

튜토리얼 # 32 : Appium Studio 실습 튜토리얼
튜토리얼 # 33 : 초보자를위한 Appium 튜토리얼
튜토리얼 # 34 : Selendroid 튜토리얼 : Android 모바일 자동화 프레임 워크
튜토리얼 # 35 : Ranorex 자습서 : 강력한 데스크톱, 웹 및 모바일 테스트 도구

도메인 별 자동화 예 :

튜토리얼 # 36 : JAVA / J2EE 애플리케이션 자동화

자동화 작업을위한 인터뷰 준비 :

튜토리얼 # 37 : 자동화 테스트 인터뷰 질문
튜토리얼 # 38 : 셀레늄 인터뷰 질문

“The Ultimate Guide to Automation Testing”시리즈의 첫 번째 자습서를 살펴 보겠습니다 !!

학습 내용 :

자동화 테스트 란 무엇입니까?

소프트웨어가 무엇이든 할 수 있다면 소프트웨어가 소프트웨어를 테스트 할 수없는 이유는 무엇입니까?

이 진술이 당신에게 논리적으로 들립니까?

그렇다면 축하합니다. 이제이 일련의 유익한 자습서에서 논의 할 중심점 인 테스트 자동화에 대해 생각하고 있습니다.

SQA로 일한 첫날 자신을 상상해보십시오. 테스트 할 응용 프로그램이 제공됩니다. 수백 개의 양식과 수천 개의 보고서가 포함 된 ERP 애플리케이션입니다. 약 50 개의 다른 필드가 포함 된 양식을 열어 탐색 테스트를 시작합니다.

약 20 분이 소요되는이 형식으로 임의의 데이터를 입력하려고합니다. 그런 다음 제출을 누릅니다. 월라 !! 처리되지 않은 예외처럼 보이는 오류 메시지가 표시됩니다. 당신은 매우 행복해집니다. 자랑스럽게 단계를 기록하고 버그 관리 시스템에서 버그를보고합니다. 큰 노력, 당신은 정말 자신감 있고 활력이 넘칩니다. 하루가 끝날 때까지 테스트를 계속하고 더 많은 버그를 찾습니다. “놀라운 첫날”이라고 생각했습니다.

이제 다음 날에 개발자가 문제를 해결하고 새 버전의 빌드를 출시합니다. 동일한 단계로 동일한 양식을 테스트하고 버그가 수정되었음을 확인했습니다. 고정으로 표시합니다. 엄청난 노력. 해당 버그를 식별하여 제품의 품질에 기여했으며이 버그가 수정되면 품질이 향상됩니다.

최고의 이메일 공급자는 누구입니까

이제 3 일째되는 날, 개발자가 다시 새로운 버전을 출시했습니다. 이제 회귀 문제가 없는지 확인하기 위해 해당 양식을 다시 테스트해야합니다. 똑같은 20 분. 이제 조금 지루함을 느낍니다.

이제 1 개월 후, 최신 버전이 지속적으로 출시되고 모든 릴리스에서 회귀가 없는지 확인하기 위해이 긴 양식과 이와 같은 다른 양식 100 개를 테스트해야합니다.

이제 화가났습니다. 피곤해 . 단계를 건너 뛰기 시작합니다. 전체 필드의 약 50 % 만 채 웁니다. 당신의 정확성은 같지 않습니다. 당신의 에너지는 같지 않으며 확실히 당신의 걸음은 같지 않습니다.

그리고 어느 날 클라이언트는 같은 형태로 같은 버그를보고합니다. 당신은 한심합니다. 이제 자신감이 없어요. 당신은 당신이 충분히 유능하지 않다고 생각합니다. 관리자가 당신의 능력에 의문을 제기하고 있습니다.

당신을위한 뉴스가 있습니다. 이것은 수동 테스터의 90 %에 대한 이야기입니다. 당신은 다르지 않습니다.

회귀 문제는 가장 고통스러운 문제입니다. 우리는 인간입니다. 그리고 우리는 매일 같은 에너지, 속도, 정확성으로 같은 일을 할 수 없습니다. 이것이 기계가하는 일입니다. 이것이 처음에 반복 된 것과 동일한 속도, 정확도 및 에너지로 동일한 단계를 반복하기 위해 자동화가 필요한 것입니다.

나는 당신이 나의 요점을 얻기를 바랍니다 !!

친구를 테스트하는 자동화

이러한 상황이 발생할 때마다 테스트 케이스를 자동화해야합니다. 테스트 자동화는 당신의 친구입니다 . 회귀를 처리하면서 새로운 기능에 집중하는 데 도움이됩니다. 자동화를 사용하면 3 분 이내에 해당 양식을 채울 수 있습니다.

스크립트는 모든 필드를 채우고 스크린 샷과 함께 결과를 알려줍니다. 실패한 경우 테스트 케이스가 실패한 위치를 정확히 찾아내어 쉽게 재현 할 수 있습니다.

자동화 – 회귀 테스트를위한 비용 효율적인 방법

처음에는 자동화 비용이 실제로 더 높습니다. 여기에는 도구 비용, 자동화 테스트 리소스 및 교육 비용이 포함됩니다.

그러나 스크립트가 준비되면 동일한 정확도로 다소 빠르게 반복적으로 수백 번 실행할 수 있습니다. 이렇게하면 많은 시간의 수동 테스트를 절약 할 수 있습니다. 따라서 비용은 점차 감소하고 궁극적으로 비용 효율적인 방법이됩니다. 회귀 테스트 .

자동화가 필요한 시나리오

위의 시나리오는 자동화 테스트가 필요한 유일한 경우가 아닙니다. 수동으로 테스트 할 수없는 몇 가지 상황이 있습니다.

예를 들어 ,

  1. 두 이미지를 픽셀 단위로 비교합니다.
  2. 수천 개의 행과 열이 포함 된 두 개의 스프레드 시트를 비교합니다.
  3. 100,000 명의 사용자 부하에서 애플리케이션 테스트.
  4. 성능 벤치 마크.
  5. 다른 브라우저에서 애플리케이션 테스트 병렬로 다른 운영 체제에서.

이러한 상황은 도구로 테스트해야하며 테스트해야합니다.

그렇다면 언제 자동화해야할까요?

이것은 시대 애자일 방법론 SDLC에서는 개발과 테스트가 거의 동시에 진행되며 자동화시기를 결정하기가 매우 어렵습니다.

자동화를 시작하기 전에 다음 상황을 고려하십시오.

  • 제품은 초기 단계에있을 수 있습니다. 제품에 UI가없는 경우 이러한 단계에서 자동화하려는 항목에 대한 명확한 생각이 있어야합니다. 다음 사항을 기억해야합니다.
    • 테스트는 구식이되어서는 안됩니다.
    • 제품이 발전함에 따라 스크립트를 선택하고 추가하기가 쉬워야합니다.
    • 주의를 기울이지 않고 스크립트가 디버그하기 쉬운 지 확인하는 것이 매우 중요합니다.
  • UI가 빈번하게 변경되므로 스크립트가 실패 할 수 있으므로 초기 단계에서 UI 자동화를 시도하지 마십시오. 제품이 안정화 될 때까지 가능한 한 API 레벨 / 비 UI 레벨 자동화를 선택하십시오. API 자동화는 수정하고 디버그하기 쉽습니다.

최상의 자동화 사례를 결정하는 방법 :

자동화는 테스트주기의 필수적인 부분이며 자동화를 결정하기 전에 자동화를 통해 달성하고자하는 것을 결정하는 것이 매우 중요합니다.

자동화가 제공하는 이점은 매우 매력적이지만 동시에 잘못 구성된 자동화 제품군은 전체 게임을 망칠 수 있습니다. 테스터는 대부분의 시간 동안 스크립트를 디버깅하고 수정하여 테스트 시간이 손실 될 수 있습니다.

효율적인 테스트 자동화

이 시리즈에서는 올바른 테스트 사례를 선택하고 우리가 보유한 자동화 스크립트로 올바른 결과를 산출 할 수 있도록 자동화 제품군을 효율적으로 만드는 방법에 대해 설명합니다.

또한 자동화시기, 자동화 대상, 자동화하지 않을 항목 및 자동화 전략 방법과 같은 질문에 대한 답변을 다루었습니다.

자동화를위한 올바른 테스트

이 문제를 해결하는 가장 좋은 방법은 우리 제품에 적합한 '자동화 전략'을 신속하게 만드는 것입니다.

아이디어는 각 그룹이 우리에게 다른 종류의 결과를 제공 할 수 있도록 테스트 케이스를 그룹화하는 것입니다. 아래 그림은 테스트중인 제품 / 솔루션에 따라 유사한 테스트 케이스를 그룹화하는 방법을 보여줍니다.

테스트 케이스 그룹화

이제 깊이 들어가서 각 그룹이 우리가 달성하는 데 도움이 될 수있는 것이 무엇인지 이해하겠습니다.

#1) 모든 기본 기능의 테스트 스위트 만들기 양성 테스트 . 이 제품군은 자동화되어야하며이 제품군이 빌드에 대해 실행되면 결과가 즉시 표시됩니다. 이 제품군에서 실패한 스크립트는 S1 또는 S2 결함으로 이어지며 특정 빌드에 대한 자격이 박탈 될 수 있습니다. 그래서 우리는 여기서 많은 시간을 절약했습니다.

추가 단계로이 자동화 된 테스트 스위트를 BVT (빌드 검증 테스트)의 일부로 추가하고 QA 자동화 스크립트를 제품 빌드 프로세스에 확인할 수 있습니다. 따라서 빌드가 준비되면 테스터는 자동화 테스트 결과를 확인하고 빌드가 설치 및 추가 테스트 프로세스에 적합한 지 여부를 결정할 수 있습니다.

이는 다음과 같은 자동화 목표를 명확하게 달성합니다.

  • 테스트 노력을 줄입니다.
  • 초기 단계에서 버그를 찾으십시오.

#두) 다음으로, 우리는 종단 간 테스트 .

대규모 솔루션에서 엔드 투 엔드 기능 테스트는 특히 프로젝트의 중요한 단계에서 핵심이됩니다. 엔드 투 엔드 솔루션 테스트를 처리하는 몇 가지 자동화 스크립트가 있어야합니다. 이 제품군이 실행되면 결과에 제품 전체가 예상대로 작동하는지 여부가 표시되어야합니다.

통합 부분이 손상되면 자동화 테스트 스위트를 표시해야합니다. 이 제품군은 솔루션의 모든 작은 기능 / 기능을 모두 포함 할 필요는 없지만 제품 전체의 작동을 포함해야합니다. 알파, 베타 또는 기타 중간 릴리스가있을 때마다 이러한 스크립트가 유용하고 고객에게 어느 정도의 신뢰를줍니다.

더 잘 이해하기 위해 우리가 온라인 쇼핑 포털 , 종단 간 테스트의 일부로 관련된 주요 단계 만 다루어야합니다.

아래에 주어진대로 :

  • 사용자 로그인.
  • 항목을 찾아 선택합니다.
  • 지불 옵션 – 프런트 엔드 테스트를 다룹니다.
  • 백엔드 주문 관리 (여러 통합 파트너와의 의사 소통, 재고 확인, 사용자에게 이메일 보내기 등이 포함됨) – 이는 개별 부품의 테스트 통합과 제품의 핵심을 지원합니다.

따라서 이러한 스크립트가 실행되면 전체 솔루션이 제대로 작동하고 있다는 확신을줍니다.!

#삼) 세 번째 세트는 기능 / 기능 기반 테스트 .

에 대한 예 , 파일을 찾아보고 선택할 수있는 기능이있을 수 있으므로이를 자동화 할 때 다양한 유형의 파일, 파일 크기 등의 선택을 포함하도록 사례를 자동화하여 기능 테스트를 수행 할 수 있습니다. 해당 기능에 변경 / 추가 사항이있는 경우이 제품군은 회귀 제품군으로 사용할 수 있습니다.

# 4) 다음 목록은 UI 기반 테스트. 페이지 매김, 텍스트 상자 문자 제한, 달력 버튼, 드롭 다운, 그래프, 이미지 및 이러한 많은 UI 전용 중심 기능과 같은 순수하게 UI 기반 기능을 테스트하는 또 다른 제품군을 가질 수 있습니다. UI가 완전히 다운되거나 특정 페이지가 예상대로 나타나지 않는 한 이러한 스크립트의 실패는 일반적으로 그다지 중요하지 않습니다!

# 5) 간단하지만 수동으로 수행하기에는 매우 힘든 또 다른 테스트 세트가있을 수 있습니다. 지루하지만 간단한 테스트가 이상적인 자동화 후보입니다. 예를 들어 1000 명의 고객 세부 정보를 데이터베이스에 입력하면 기능은 간단하지만 수동으로 수행하기에는 매우 지루하므로 이러한 테스트를 자동화해야합니다. 그렇지 않으면 대부분 무시되고 테스트되지 않습니다.

자동화하지 않는 것은 무엇입니까?

다음은 자동화해서는 안되는 몇 가지 테스트입니다.

# 1) 음성 테스트 / 장애 조치 테스트

자동화를 시도해서는 안됩니다. 음성 또는 장애 조치 테스트 , 이러한 테스트의 경우 테스터는 분석적으로 생각할 필요가 있으며 부정적인 테스트는 우리에게 도움이 될 수있는 합격 또는 불합격 결과를 제공하는 것이 실제로 간단하지 않습니다.

부정적인 테스트는 실제 재해 복구 시나리오를 시뮬레이션하기 위해 많은 수동 개입이 필요합니다. 예를 들어 웹 서비스 안정성과 같은 기능을 테스트하고 있습니다. 여기서 일반화하기 위해 이러한 테스트의 주요 목표는 의도적 인 실패를 유발하고 제품이 얼마나 신뢰할 수 있는지 확인하는 것입니다.

위의 실패를 시뮬레이션하는 것은 간단하지 않으며 일부 스텁을 삽입하거나 그 사이에 일부 도구를 사용할 수 있으며 자동화는 여기에 가장 좋은 방법이 아닙니다.

# 2) 임시 테스트

이러한 테스트는 항상 제품과 관련이 없을 수 있으며 이는 테스터가 프로젝트 시작 단계에서 생각할 수있는 것일 수도 있으며 임시 테스트를 자동화하려는 노력도 중요도에 대해 검증되어야합니다. 테스트가 다루는 기능의.

예를 들면 , 데이터 압축 / 암호화를 처리하는 기능을 테스트하는 테스터는 여러 데이터, 파일 유형, 파일 크기, 손상된 데이터, 데이터 조합, 여러 알고리즘을 사용하여 다양한 임시 테스트를 수행했을 수 있습니다. 플랫폼 등

우리가 계획 할 때 오토메이션 해당 기능에 대한 모든 임시 테스트의 우선 순위를 지정하고 철저한 자동화를 수행하지 않고 다른 주요 기능을 자동화하는 데 약간의 시간이 소요될 수 있습니다.

# 3) 대규모 사전 설정 테스트

엄청난 전제 조건이 필요한 테스트가 있습니다.

예를 들면, 제품은 시스템에 설치, 대기열 설정, 대기열 생성 등이 필요한 모든 메시징 대기열 시스템과 통합되므로 일부 기능에 대해 타사 소프트웨어와 통합되는 제품이있을 수 있습니다.

3rd파티 소프트웨어는 무엇이든 될 수 있으며 설정은 본질적으로 복잡 할 수 있으며 이러한 스크립트가 자동화 된 경우 이러한 스크립트는 해당 타사 소프트웨어의 기능 / 설정에 영원히 의존하게됩니다.

전제 조건은 다음과 같습니다.

현재 양측 설정이 완료되고 모든 것이 정상이므로 상황이 간단하고 깨끗하게 보일 수 있습니다. 우리는 프로젝트가 유지 보수 단계에 들어가면 프로젝트가 다른 팀으로 옮겨지고 실제 테스트는 매우 간단하지만 스크립트가 3으로 인해 실패하는 스크립트를 디버깅하는 것을 여러 번 보았습니다.rd파티 소프트웨어 문제.

위의 내용은 일반적으로 다음과 같은 간단한 테스트를 위해 힘든 사전 설정이있는 테스트를 주시하는 예일뿐입니다.

테스트 자동화의 간단한 예

소프트웨어 (웹 또는 데스크탑에서)를 테스트 할 때 일반적으로 마우스와 키보드를 사용하여 단계를 수행합니다. 자동화 도구는 스크립팅 또는 프로그래밍 언어를 사용하여 동일한 단계를 모방합니다.

예를 들어 , 계산기를 테스트하고 있고 테스트 케이스는 두 개의 숫자를 더하고 결과를 확인해야한다는 것입니다. 스크립트는 마우스와 키보드를 사용하여 동일한 단계를 수행합니다.

최고의 무료 맬웨어 제거 도구는 무엇입니까

예는 아래와 같습니다.

수동 테스트 케이스 단계 :

  1. 계산기 시작
  2. 2 번
  3. +를 누릅니다.
  4. 3 번
  5. 누르기 =
  6. 화면에 5가 표시되어야합니다.
  7. 계산기를 닫습니다.

자동화 스크립트 :

//the example is written in MS Coded UI using c# language. (TestMethod) public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }

위의 스크립트는 수동 단계를 복제 한 것입니다. 스크립트는 작성하기 쉽고 이해하기 쉽습니다.

어설 션이란 무엇입니까?

스크립트의 마지막 두 번째 줄에는 더 많은 설명이 필요합니다.

Assert.AreEqual (“5”, txtResult.DisplayText,”Calculator가 5를 표시하지 않음);

모든 테스트 케이스에서 마지막에 예상 또는 예측 결과가 있습니다. 위의 스크립트에서는 화면에“5”가 표시되어야한다고 예상합니다. 실제 결과는 화면에 표시되는 결과입니다. 모든 테스트 사례에서 예상 결과와 실제 결과를 비교합니다.

자동화 테스트도 마찬가지입니다. 여기서 유일한 차이점은 테스트 자동화에서 비교를 수행 할 때 모든 도구에서 다른 것으로 불린다는 것입니다.

일부 도구는이를“ 역설 ”, 일부는“ 검문소 ”및 일부는이를“유효성 검사”라고합니다. 그러나 기본적으로 이것은 단지 비교 일뿐입니다. 이 비교가 실패하면 예 : 화면에 5 대신 15가 표시되면이 어설 션 / 체크 포인트 / 검증이 실패하고 테스트 케이스가 실패로 표시됩니다.

어설 션으로 인해 테스트 케이스가 실패하면 테스트 자동화를 통해 버그를 발견했음을 의미합니다. 수동 테스트에서 일반적으로하는 것처럼 버그 관리 시스템에보고해야합니다.

위의 스크립트에서 우리는 마지막 두 번째 줄에서 어설 션을 수행했습니다. 5는 예상되는 결과이고, txtResult . DisplayText 실제 결과이며 같지 않으면 '계산기가 5를 표시하지 않습니다'라는 메시지가 표시됩니다.

결론

종종 테스터는 테스트 예상치를 개선하기 위해 모든 사례를 자동화해야하는 프로젝트 기한과 의무에 직면합니다.

자동화에 대한 일반적인 '잘못된'인식이 있습니다.

그들은:

  • 모든 테스트 케이스를 자동화 할 수 있습니다.
  • 테스트를 자동화하면 테스트 시간이 크게 단축됩니다.
  • 자동화 스크립트가 원활하게 실행되면 버그가 발생하지 않습니다.

자동화는 특정 유형의 테스트에 대해서만 테스트 시간을 단축 할 수 있다는 점을 분명히해야합니다. 계획이나 순서없이 모든 테스트를 자동화하면 과도한 유지 관리가 필요하고 자주 실패하고 많은 수동 개입이 필요한 대규모 스크립트가 생성됩니다. 또한 지속적으로 진화하는 제품에서 자동화 스크립트는 쓸모 없어지고 지속적인 점검이 필요할 수 있습니다.

적합한 후보자를 그룹화하고 자동화하면 많은 시간을 절약하고 자동화의 모든 이점을 얻을 수 있습니다.

이 훌륭한 튜토리얼은 7 가지 요점으로 요약 할 수 있습니다.

자동화 테스트 :

  • 프로그래밍 방식으로 수행되는 테스트입니다.
  • 도구를 사용하여 테스트 실행을 제어합니다.
  • 예상 결과를 실제 결과 (Assertions)와 비교합니다.
  • 반복적이지만 필요한 작업을 자동화 할 수 있습니다 ( 예 : 회귀 테스트 사례).
  • 수동으로 수행하기 어려운 일부 작업을 자동화 할 수 있습니다 (예 :부하 테스트 시나리오).
  • 스크립트는 빠르고 반복적으로 실행할 수 있습니다.
  • 장기적으로 비용 효율적입니다.

여기서 자동화는 간단한 용어로 설명되지만 이것이 항상 간단하다는 의미는 아닙니다. 그것에 관련된 도전, 위험 및 기타 많은 장애물이 있습니다. 테스트 자동화가 잘못 될 수있는 방법은 여러 가지가 있지만 모든 것이 잘되면 테스트 자동화의 이점은 정말 엄청납니다.

이 시리즈의 다음 항목 :

다음 튜토리얼에서는 자동화와 관련된 몇 가지 측면에 대해 논의 할 것입니다.

여기에는 다음이 포함됩니다.

  1. 자동 테스트 유형 및 일부 오해.
  2. 조직에 자동화를 도입하고 테스트 자동화를 수행 할 때 일반적인 함정을 피하는 방법.
  3. 도구 선택 프로세스 및 다양한 자동화 도구의 비교.
  4. 예제가 포함 된 스크립트 개발 및 자동화 프레임 워크.
  5. 테스트 자동화의 실행 및보고.
  6. 테스트 자동화의 모범 사례 및 전략.

자동화 테스트의 모든 개념에 대해 더 많이 알고 싶으십니까? 이 시리즈의 예정된 튜토리얼 목록을 확인하고 계속 지켜봐 주시고 아래 댓글 섹션에 자유롭게 의견을 표현하십시오.

다음 튜토리얼 # 2

추천 도서

^