메뉴

자동화 테스트 유형 및 일부 오해

types automation testing

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

테스트 자동화에 대한 오해와 함께 다양한 유형의 자동화 테스트에 대해 알아보십시오.

이 두 번째 부분에서 테스트 자동화 튜토리얼 시리즈 , 나는 자동화 된 테스트의 유형을 간략히 설명하고 가장 중요한 것은 테스트 자동화에 대한 오해를 제거 할 것입니다.

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

자동화 테스트는 수동으로 실행할 필요없이 일련의 테스트를 반복해서 실행하는 방법으로 정의 할 수 있습니다. 테스트 전략에 자동화 테스트를 도입하면 비용과 시간을 절약 할 수 있습니다.

자동화 테스트 유형

학습 내용 :

자동화 테스트 유형

자동화 테스트 유형은 자동화 할 수있는 테스트 스위트의 종류를 정의합니다. 많은 테스터가이 주제를 편리하게 실행할 수있는 자동화 팩으로 테스트 스위트를 디자인하는 방법을 정의하는 자동화 프레임 워크 유형과 혼동합니다.

이 기사에서는 자동화 테스트 유형을 자세히 살펴보고 마지막으로 자동화 프레임 워크에 대해 간략히 살펴 보겠습니다.

자동화 유형

위의 분류를 자세히 이해하겠습니다.

테스트 유형에 따른 자동화

기능 테스트 자동화 :

기능 테스트는 애플리케이션 뒤의 비즈니스 로직을 테스트하기 위해 작성되었습니다. 이를 자동화한다는 것은 비즈니스 로직과 애플리케이션에서 예상되는 기능을 검증하기위한 스크립트 작성을 의미합니다.

비 기능 테스트 자동화 :

비 기능 테스트는 응용 프로그램의 비 비즈니스 요구 사항을 정의합니다. 이러한 요구 사항은 성능, 보안, 데이터베이스 등과 관련된 요구 사항입니다. 이러한 요구 사항은 일정하게 유지되거나 소프트웨어 크기에 따라 확장 될 수 있습니다.

테스트 단계에 따른 자동화

단위 테스트 자동화 :

이러한 테스트는 개발 단계 자체에서 실행되며, 이상적으로는 개발 완료 후 테스트를 위해 시스템을 테스터에게 넘기기 전에 개발자가 실행합니다.

API 테스트 자동화 :

API 테스트는 통합 단계에서 실행됩니다. 이는 개발 또는 테스트 팀에 의해 실행될 수 있으며 애플리케이션에 대한 UI 계층이 빌드되기 전이나 후에 실행될 수 있습니다. 이러한 테스트는 애플리케이션이 빌드 된 요청 및 응답을 기반으로 테스트를 대상으로합니다.

UI 기반 테스트 자동화 :

UI 기반 테스트는 테스트 실행 단계에서 실행됩니다. 이들은 특별히 테스터에 의해 실행되며 애플리케이션의 UI가 전달되기 전에 한 번만 실행됩니다. 이들은 애플리케이션의 프런트 엔드에서 애플리케이션의 기능과 비즈니스 로직을 테스트합니다.

테스트 유형에 따른 자동화

단위 테스트 :

단위 테스트는 응용 프로그램의 코드를 테스트하기 위해 빌드 된 테스트이며 일반적으로 코드 자체에 빌드됩니다. 방법과 기능이 작성되는 방식과 같은 코딩 표준을 대상으로합니다.

이러한 테스트는 개발자가 직접 작성하는 경우가 많지만 오늘날의 세계에서는 자동화 테스터에게도 작성하라는 요청을받을 수 있습니다.

이러한 테스트를 실행하고 버그가 발생하지 않으면 코드 문제없이 코드가 컴파일되고 실행됩니다. 이러한 테스트는 일반적으로 애플리케이션의 기능적 측면을 대상으로하지 않으며 코드를 대상으로하기 때문에 개발자가 필요로 할 때 실행할 수 있도록 자동화하는 것이 더 적절합니다.

연기 테스트 :

연기 테스트는 테스트 수명주기에서 수행되는 유명한 테스트입니다. 이는 빌드 후 테스트이며, 빌드가 완료된 후에도 애플리케이션이 계속 작동하는지 확인하기 위해 애플리케이션에서 빌드가 제공된 직후에 실행됩니다.

이것은 작은 테스트 스위트이며 여러 번 실행되므로 자동화하는 것이 합리적입니다. 이러한 테스트는 일반적으로 기능적 특성을 가지며 응용 프로그램 유형에 따라 도구를 선택할 수 있습니다.

API 테스트 :

API 테스트는 지난 몇 년 동안 매우 유명해졌습니다. API 아키텍처에 구축 된 애플리케이션은이 테스트를 수행 할 수 있습니다.

API 테스트에서 테스터는 애플리케이션이 구축 된 다양한 API에 대한 요청-응답 조합을 확인하여 애플리케이션의 비즈니스 계층을 검증합니다. API 테스트는 아래 통합 테스트의 일부로 수행 할 수도 있습니다.

통합 테스트 :

통합 테스트는 이름 자체에서 알 수 있듯이 모든 모듈을 통합하고 애플리케이션의 기능을 확인하여 애플리케이션을 테스트하는 것을 의미합니다.

통합 테스트는 API 테스트를 통해 수행하거나 애플리케이션의 UI 계층을 통해 수행 할 수 있습니다.

UI 테스트 :

UI 테스트는 UI 레이어 또는 애플리케이션의 프런트 엔드에서 수행됩니다. 이들은 기능 테스트를 대상으로하거나 단순히 애플리케이션의 UI 요소를 테스트 할 수 있습니다.

기능을 테스트하기 위해 UI를 자동화하는 것이 일반적인 관행입니다. 그러나 GUI 기능 자동화는 더 복잡한 자동화 중 하나입니다.

회귀 테스트 :

가장 일반적으로 자동화 된 테스트 스위트 중 하나는 회귀 테스트 스위트입니다. 이미 알고 계시 겠지만 회귀는 기존 모듈이 영향을받지 않았는지 확인하기 위해 새 모듈 테스트가 끝날 때 수행되는 테스트입니다.

테스트를 새로 반복 할 때마다 반복되며 기본 테스트 케이스는 일반적으로 새로운 반복 후에 몇 가지 새로운 추가 사항으로 고정 된 상태로 유지됩니다. 자주 실행되기 때문에 거의 모든 테스트 팀이이 팩을 자동화하려고합니다.

지속적인 통합으로서의 자동화 :

지속적 통합은 자동화 된 회귀 테스트 자체에서 다시 실행될 수 있지만 CI를 달성하기 위해 새로운 배포가 완료 될 때마다 회귀 또는 식별 된 테스트 스위트를 실행할 수 있습니다.

보안 테스트 :

보안 테스트는 기능적 일뿐만 아니라 취약점에 대한 애플리케이션 테스트를 포함하는 비 기능적 유형의 테스트 일 수 있습니다. 기능 테스트는 권한 부여 등과 관련된 테스트로 구성되지만 비 기능적 요구 사항은 SQL 주입, 교차 사이트 스크립팅 등에 대한 테스트 일 수 있습니다.

성능 테스트 및 품질 관리 :

성능 테스트는 애플리케이션의 부하, 스트레스, 확장 성 테스트와 같은 요구 사항을 대상으로하는 비 기능 테스트입니다.

합격 테스트 :

수락 테스트는 고객이 제공 한 수락 기준이 충족되었는지 확인하기 위해 일반적으로 수행되는 기능 테스트에 해당합니다.

지금까지 자동화 할 수있는 테스트 유형과 동일한 다양한 분류에 대해 설명했습니다. 모든 분류는 결국 자동화되는 테스트 스위트의 동일한 최종 결과로 이어질 것입니다. 앞서 말했듯이 프레임 워크와 어떻게 다른지에 대한 약간의 이해가 필요합니다.

위 분류에서 자동화 할 테스트를 식별 한 후에는 수동 개입없이 이러한 테스트를 원활하게 실행하는 방식으로 논리를 설계해야합니다. 이 수동 테스트 스위트를 자동화 된 테스트 스위트로 디자인 한 것이 프레임 워크가 등장하는 곳입니다.

이제 상위 3 가지 테스트 자동화 유형을 살펴 보겠습니다.

  1. 단위 테스트
  2. API 테스트
  3. GUI 테스트

#1) 자동화 된 단위 테스트

자동화 된 단위 테스트 코드 레벨을 테스트하기 위해 작성되었습니다. 버그는 개발자가 작성한 함수, 메소드 및 루틴에서 식별됩니다.

일부 회사는 개발자에게 자체 단위 테스트를 요청하고 일부는 전문 테스트 자동화 리소스를 고용합니다. 이러한 리소스는 소스 코드에 액세스 할 수 있으며 프로덕션 코드를 중단하기 위해 단위 테스트를 작성합니다.

단위 테스트의 존재로 인해 코드가 컴파일 될 때마다 모든 단위 테스트가 실행되고 모든 기능이 작동하는지 결과를 알려줍니다. 단위 테스트가 실패하면 프로덕션 코드에 버그가 있음을 의미합니다.

시장에서 가장 많이 사용되는 도구는 다음과 같습니다. NUnit 과 JUnit . Microsoft는 또한 단위 테스트를위한 자체 프레임 워크를 제공합니다. MSTest . 이러한 도구의 웹 사이트를 살펴보면 단위 테스트 작성 방법에 대한 더 많은 예제와 자습서가 제공됩니다.

#두) 자동화 된 웹 서비스 / API 테스트

API (응용 프로그래밍 인터페이스)를 사용하면 소프트웨어가 다른 소프트웨어 응용 프로그램과 통신 할 수 있습니다. 다른 소프트웨어와 마찬가지로 API도 테스트해야합니다. 이 유형의 테스트에서는 일반적으로 GUI가 관련되지 않습니다.

여기서 테스트하는 것은 일반적으로 기능, 규정 준수 및 보안 문제입니다. 웹 애플리케이션에서 애플리케이션의 요청 및 응답이 안전하고 암호화되었는지 여부를 테스트 할 수 있습니다.

이것은 API 테스팅을 사용할 수있는 예 중 하나입니다. API 테스트에 가장 많이 사용되는 도구는 비누 무료 버전과 유료 버전이 모두 있습니다. 필요에 따라 사용할 수있는 다른 도구도 있습니다.

#삼) 자동화 된 GUI 테스트.

이러한 유형의 자동화 된 테스트는 애플리케이션의 사용자 인터페이스 테스트를 포함하므로 가장 어려운 형태의 자동화입니다.

GUI는 매우 변경 될 수 있으므로 어렵습니다. 그러나 이러한 유형의 테스트는 사용자가 우리 애플리케이션으로 수행 할 작업과 가장 가깝습니다. 사용자가 마우스와 키보드를 사용하기 때문에 자동화 된 GUI 테스트는 마우스와 키보드를 사용하여 사용자 인터페이스에있는 개체를 클릭하거나 작성함으로써 동일한 동작을 모방합니다.

이로 인해 버그를 조기에 발견 할 수 있으며 회귀 테스트 또는 너무 많은 시간이 걸리는 양식 작성과 같은 많은 시나리오에서 사용할 수 있습니다.

가장 널리 사용되는 GUI 테스트 도구는 다음과 같습니다. Micro Focus 통합 기능 테스트 (UFT) , 셀렌 , 테스트 완료 과 Microsoft 코딩 UI (Visual Studio Ultimate 및 Premium Edition의 일부입니다).

자동화 테스트 유형과 마찬가지로 여러 유형의 프레임 워크도 있습니다.

자동화 프레임 워크

일반적으로 사용되는 자동화 프레임 워크는 다음과 같습니다.

  • 선형 (녹음 및 재생)
  • 키워드 기반
  • 데이터 기반
  • 페이지 개체 모델
  • 모듈 식

더 읽을 거리 => 자동화 프레임 워크

유형, 프레임 워크 및 도구

자동화 프로세스의 첫 번째 단계는 자동화 유형을 식별하는 것입니다. 그런 다음 설계 할 프레임 워크를 식별하고이를 염두에두고 필요에 맞는 도구를 선택할 수 있습니다.

자동화 도구

대상 테스트 유형과이를 기반으로 구축 할 프레임 워크 유형에 따라 다음 도구를 사용할 수 있습니다.

  • 셀렌 : 웹 애플리케이션 테스트를위한 매우 강력한 도구입니다. 여러 브라우저 지원을 제공합니다.
  • Junit 및 Nunit : 개발자가 주로 단위 테스트에 사용하는 도구입니다.
  • QTP : 웹이 아닌 응용 프로그램을위한 훌륭한 도구이며 기본 제공 개체 저장소와 함께 제공됩니다.
  • Sikuli : GUI 테스트를위한 오픈 소스 도구입니다.
  • 비누 UI : API 테스트를위한 도구입니다.
  • 안심하십시오 : API 테스트 프레임 워크를 만들기위한 라이브러리입니다.
  • appium : 모바일 테스트, 네이티브 앱 테스트, 하이브리드 및 모바일 웹 애플리케이션 테스트를 지원하는 도구입니다.
  • Jmeter : 성능 테스트에 사용되는 도구입니다.
  • TestNG : TestNG는 그 자체로 자동화 도구는 아니지만 셀레늄, appium, 안심 등으로 구축 된 자동화 프레임 워크에 큰 지원을 제공합니다.

더 읽을 거리 => 테스트 자동화 도구

자동화 테스트에 대한 오해

수년 동안 테스트 자동화에 대한 오해를 들었습니다. 이 기사에서도 그것들을 정리해야한다고 생각합니다.

오해 # 1. 자동화는 수동 테스터를 대체하기위한 것입니다.

테스트 자동화는 테스터가보다 빠르고 안정적인 방식으로 테스트 할 수 있도록 지원합니다. 인간을 대체 할 수는 없습니다.

테스트 자동화를 자동차라고 생각하십시오. 걸 으면 집까지 약 20 분 정도 걸립니다. 하지만 자동차를 이용하면 2 분이면 도착합니다. 자동차의 운전자는 여전히 당신, 인간이지만 .. 자동차는 인간이 목표를 더 빨리 달성 할 수 있도록 도와줍니다. 또한 걷지 않았기 때문에 대부분의 에너지가 절약됩니다. 따라서이 에너지를 사용하여 더 중요한 일을 수행 할 수 있습니다.

자동화 테스트도 마찬가지입니다. 반복적이고 길고 지루한 테스트의 대부분을 빠르게 테스트하는 데 사용하고 새롭고 중요한 기능에 집중하고 테스트하는 데 시간과 에너지를 절약 할 수 있습니다.

같이 제임스 바흐 멋진 인용문을 말했습니다.

'도구는 테스트하지 않습니다. 사람 만 테스트합니다. 도구는 사람들이 테스트하는 데 도움이되는 작업 만 수행합니다. “

도구는 개체를 클릭 할 수 있습니다. 그러나 클릭 할 위치는 항상 수동 테스터가 알려줍니다. 이제 내 요점을 알 것 같아요.

오해 # 2 . 태양 아래에서 모든 것을 자동화 할 수 있습니다.

테스트 케이스를 100 % 자동화하려고한다면 그렇게 할 수있을 것입니다.하지만 그렇게 할 수 있다면 첫 번째 요점이 거짓이됩니다. 모든 것이 자동화 된 경우 수동 테스터는 무엇을할까요?

혼란스러워? 권리?

사실 요점은 테스트 케이스를 100 % 자동화 할 수 없다는 것입니다. 테스터로서 우리는 어떤 애플리케이션도 100 % 테스트 할 수 없다고 믿기 때문입니다. 우리가 놓칠 몇 가지 시나리오가 항상있을 것입니다. 클라이언트가 애플리케이션을 사용할 때만 발생하는 버그는 항상 있습니다.

애플리케이션을 100 % 테스트 할 수없는 경우 어떻게 100 % 자동화를 약속 할 수 있습니까?

또한 기존의 모든 테스트 사례를 자동화 할 수있는 가능성은 매우 희박합니다. 자동화하기 어렵고 수동으로 수행하기 쉬운 시나리오가 항상 있습니다.

예를 들면 , 한 명의 사용자가 데이터를 입력하고 두 번째 사용자가 데이터를 승인하고 세 번째 사용자가 데이터를보고 네 번째 사용자가 데이터를 볼 수 없습니다. 이러한 시나리오는 자동화 할 수 있지만 많은 시간과 노력이 필요합니다. 따라서 수동으로 수행하면 더 쉬울 것입니다.

우리는 거리를 가기 위해 자동차를 사용하지만 길에 긴 신호가있을 수 있고 연료 소비가 있고 주차 공간 문제, 주차 요금 및 훨씬 더 많은 두통이있을 수 있습니다. 일부 시나리오에서는 그냥 걸어 가서 목적지에 도달합니다. :) .

따라서 모든 것을 자동화하려고해서는 안됩니다. 중요한 시나리오와 수동으로 수행하는 데 많은 시간이 걸리는 시나리오 만 자동화하십시오.

오해 # 3 . 자동화에는 녹음 및 재생 만 포함됩니다.

환상의 세계에 살지 마세요. 이 환상은 실제로 다른 자동화 도구 공급 업체의 허위 광고에 의해 만들어졌습니다. 단계를 기록하고 재생하기 만하면 테스트 케이스가 자동화된다고합니다. 음, 그것은 큰 거짓말입니다!

자동화는 단지 녹음과 재생이 아닌 모든 것입니다. 순수 자동화 엔지니어는 일반적으로 녹음 및 재생 기능을 전혀 사용하지 않습니다. 기록 및 재생은 일반적으로 도구가 단계에 대한 스크립트를 생성하는 방법에 대한 아이디어를 얻는 데 사용됩니다.

스크립팅에 대해 알게되면 항상 스크립팅을 사용하여 자동화 된 테스트를 만듭니다. 생각해 내다, 테스트 자동화를하려면 프로그래밍을 알아야합니다. . 반면에 프로그래밍을 모른다고해서 낙담하지 마십시오. 다른 작업과 마찬가지로 프로그래밍도 연습과 헌신으로 배울 수 있습니다.

저는 컴퓨터 과학 배경이 아닌 사람들을 알고 있지만 그들은 프로그래밍을 배우고 이제는 멋진 자동화 엔지니어입니다. Microsoft에서는 프로그래밍을 할 수있는 테스터를 고용합니다. 그들 불리는 SDET (테스트 용 소프트웨어 개발 엔지니어). 작업 설명의 첫 번째 줄에는 'SDET가 많은 코드를 작성합니다….'라고되어 있습니다.

프로그래밍하는 법을 배우세요. 도망 치지 마세요. 그것은 당신을 만들 것입니다 놀라운 테스터 .

결론

이 기사가 테스트 자동화와 관련된 몇 가지 개념을 명확히하는 데 도움이 되었기를 바랍니다.

.torrent 파일을 여는 방법

우리는 다양한 분류 방법으로 높은 수준의 다양한 유형의 자동화 테스트를 다루었습니다.

주요 분류는 다음과 같습니다.

  • 테스트 유형 (기능적 또는 비 기능적)에 따른 자동화.
  • 테스트 단계 (단위, API 또는 UI)에 따른 자동화.
  • 다양한 유형의 테스트를 기반으로 한 자동화 (다중 테스트 유형).

또한 이러한 유형의 자동 테스트에 사용할 수있는 다양한 도구를 나열했습니다.

다음 기사에서 우리는 단계별 절차 조직에서 테스트 자동화를 시작하는 방법 .

이전 튜토리얼 # 1 | 다음 튜토리얼 # 3

추천 도서

^