자동화된 테스트란 무엇입니까?
저는 몇년간 테스트를 해왔고, 1년 동안 자동화 테스트를 정말 많이 배우고 실천해 왔는데, 올해는 정말 많은 것을 얻은 것 같습니다. 나는 자동화된 테스트 실행에 대한 몇 가지 경험을 공유하기 위해 항상 기사를 쓰고 싶었습니다. 마침내 이 일을 하기로 결정했습니다.
먼저, 자동화된 테스트의 개념을 명확히 합니다.넓게 말하면 자동화에는 도구(프로그램)를 통해 수동 테스트를 대체하거나 지원하는 모든 동작이 포함되며, 이는 성능 테스트 도구(loadrunner, jmeter) 또는 직접 작성한 도구를 포함하여 자동화라고 볼 수 있습니다. 1~100개의 테스트 데이터를 생성하는 프로그램입니다. 좁은 의미에서는 수동 테스트 과정을 도구를 사용하여 기록하거나 스크립트를 작성하는 방식으로 시뮬레이션하고, 스크립트를 재생하거나 실행하여 테스트 케이스를 실행함으로써 시스템 기능에 대한 수동 검증을 대체합니다.
물론, 우리는 "자동화된 테스트"를 "제품이나 프로젝트의 UI 계층을 기반으로 하는 자동화된 테스트"로 더 일반적으로 생각합니다.
계층화된 자동화 테스트
이 개념은 최근에 많이 노출되었습니다. 전통적인 자동 테스트는 제품의 UI 계층에 대한 자동 테스트에 더 중점을 두는 반면, 계층화된 자동 테스트는 제품의 다양한 단계(레벨)에서 자동화된 테스트의 필요성을 옹호합니다.
테스트 학생들은 위의 피라미드에 익숙하다고 생각하는데, 이것은 제품 개발의 다양한 단계에 해당하는 테스트가 아닌가요? 단위 테스트를 표준화해야 하며 Java의 Junit 및 testNG, C#의 NUnit, Python의 단위 테스트, pytest 등과 같은 해당 단위 테스트 프레임워크도 필요합니다. 거의 모든 주류 언어에는 해당 단위 테스트 프레임워크가 있습니다.
통합 및 인터페이스 테스트는 많은 초보 테스터에게 이해하기 쉽지 않습니다. 단위 테스트는 if 분기 또는 for 루프 구현과 같은 코드의 구현 논리에 중점을 두는 반면, 통합 및 인터페이스 테스트는 함수 또는 클래스( 방법) 제공된 인터페이스가 안정적인지 여부. 예를 들어 add() 함수를 정의하여 두 매개변수의 결과를 계산하고 반환하는 경우 add()를 호출하여 매개변수를 전달하고 반환 값을 비교하여 두 매개변수가 추가되었는지 확인해야 합니다. 물론 인터페이스 테스트는 URL 형태로 전달될 수도 있습니다. 예를 들어, get 메소드를 통해 서버에 요청을 보내는 경우, 보내는 콘텐츠는 URL의 일부로 서버에 전달됩니다. 그러나 예를 들어 웹 서비스 기술이 제공하는 공용 인터페이스는 비누 UI와 같은 도구를 통해 테스트해야 합니다.
UI 레이어의 자동화된 테스트는 누구나 익숙해야 하며, 대부분의 테스터의 작업은 대부분 UI 레이어의 기능을 테스트하는 것입니다. 예를 들어, 양식 제출, 결과 쿼리 및 기타 기능을 반복적으로 테스트하고 해당 자동화 테스트 도구를 사용하여 이러한 작업을 시뮬레이션함으로써 반복적인 노동을 해방할 수 있습니다. UI 레이어에는 자동화된 테스트 도구가 많이 있으며, 가장 주류를 이루는 도구로는 QTP, Robot Framework, watir, Selenium 등이 있습니다.
왜 직사각형이나 역삼각형이 아닌 피라미드 형태로 그려야 할까요? 이는 다양한 단계에 투자된 자동화된 테스트의 비율을 나타냅니다. 제품이 단위 테스트와 인터페이스 테스트를 한 번도 해본 적이 없다면 UI 레이어에서만 자동화된 테스트를 하는 것은 비과학적이고, 본질적으로 제품의 품질을 보장하기 어렵습니다. UI 레이어에 대한 포괄적인 자동화 테스트를 구현하려고 한다면 시간과 비용의 낭비가 될 것이며, 많은 인력과 시간을 투자하게 되며 최종 이익은 지불한 비용보다 훨씬 낮을 수 있습니다. 레벨이 높을수록 유지 비용이 높아지기 때문입니다. 특히 UI 레이어의 요소는 수시로 변경됩니다. 따라서 단위 테스트와 인터페이스 테스트 단계에 더욱 자동화된 테스트를 적용해야 합니다.
UI 레이어의 자동화된 테스트는 시간과 비용이 많이 들기 때문에 단위 테스트와 인터페이스 테스트만 수행할 수 있습니다. NO!어떤 제품이던 결국 사용자에게 보여지는 것은 UI 레이어이기 때문입니다. 따라서 테스터는 UI 레이어에 더 집중해야 합니다. 글쎄요, 자동화를 통해 반복적인 노동을 "부분적으로 해방"하는 데 도움이 필요한 것은 바로 테스터가 UI 계층에 많은 에너지를 투자하기 때문입니다.
자동화된 테스트에서 가장 두려운 것은 변경입니다. 변경의 직접적인 결과는 테스트 케이스 실행 실패이므로 자동화 스크립트를 유지 관리해야 하기 때문입니다. 실패를 제어하고 유지 관리 비용을 줄이는 방법은 성공 또는 유지 관리 비용을 줄이는 데 중요합니다. 자동화 실패. 반면에 항상 성공적으로 실행되는 자동화된 테스트 사례는 가치가 없습니다.
피라미드에서 세 가지 유형의 테스트 비율은 실제 프로젝트 요구 사항에 따라 나누어야 합니다. 『구글 테스팅』이라는 책에서는 구글 제품에 대한 투자의 70%가 단위 테스트, 20%가 통합 및 인터페이스 테스트, 10%가 UI 레이어 자동화 테스트라고 나와 있습니다.
자동화된 테스트를 수행해야 하는 이유는 무엇입니까?
51testing의 "중국 소프트웨어 테스팅 실무자에 대한 조사 보고서"에 따르면 수동 테스트가 89%를 차지합니다. 개발에 비해 테스트 임계값이 낮고 급여도 일반적으로 낮습니다. 필요한 지식의 폭이 일정하지만 부족합니다. 깊이. 이는 테스트에서 흔히 볼 수 있는 현실입니다.
바로 수작업 기술 테스트의 문턱이 낮기 때문에 많은 수의 졸업생은 물론 비전문가까지 이 산업에 쏟아져 들어왔습니다. 이로 인해 이 업계의 경쟁이 더욱 치열해졌습니다. 수년간 매뉴얼 테스팅에 종사해 온 사람들에게는 위기의식이 강할 것이다. 업무의 기술적인 내용이 높지 않아 급여인상에 병목현상이 발생하였고, 한편으로는 신입사원에 의해 위협을 받고 있습니다. 같은 업무는 5만원에 사람을 고용하면 가능하므로 8만원을 지출하지 않습니다. 사람을 모집합니다.
글쎄요, 이 질문은 기술적인 토론에서 나올 수 없지만 대부분의 테스터가 직면해야 하는 문제입니다. 따라서 테스터 자체의 개발 관점에서 보면 실제로 경쟁력을 높이기 위해서는 자동화 기술을 활용해야 합니다. 물론, 일정 기간이 지나면 테스터는 관리직이나 다른 직위로 전환하는 것을 선택할 것입니다. 이것은 또 다른 주제입니다.
테스트 산업의 발전 관점에서 볼 때, 제품 특성으로 인해 국내 제품은 세계 일류 제품이 많지 않고 기술 함량이 상대적으로 낮으며 품질 요구 사항도 상대적으로 낮습니다.해외 프로젝트는 아웃소싱되어 테스트 인건비가 소요됩니다. 수치가 낮아 수동테스터가 많이 필요하다. .
따라서 가까운 미래에는 순수 수동 테스터에 대한 수요가 줄어들 것이며 기업에서는 더 높은 기술 역량을 갖춘 더 많은 테스트가 필요할 것이라고 생각합니다. 품질은 테스트를 거쳐야 하고, 테스트하는 행위는 절대 사라지지 않겠지만, 순전히 수동 테스터가 사라질 가능성도 있습니다.
글쎄요, 테스트는 유망한 산업이라고 말할 수 있지만 저는 단지 경각심을 갖고 있는 것뿐입니다. 미래가 어떻게 되든 우리 모두는 기술을 향상해야 합니다. 그렇죠?
자동화된 테스트에 적합한 프로젝트는 무엇입니까?
자동화된 테스트를 배우기로 결정했다면 다음 질문은 어떻게 배우는가입니다. 테스트 중인 제품을 기준으로 분석한 질문으로, 학습한 기술을 적용(검증)할 수 없으면 학습 과정이 어려워집니다.
먼저 제품이 자동화된 테스트에 적합한지 고려하십시오. 이 방법에 대한 일반적인 합의는 세 가지 측면에서 평가하는 것입니다.
소프트웨어 요구 사항은 자주 변경되지 않습니다.
테스트 스크립트의 안정성은 자동화된 테스트의 유지 관리 비용을 결정합니다. 소프트웨어 요구사항이 너무 자주 변경되는 경우 테스터는 변화하는 요구사항에 따라 테스트 케이스 및 관련 테스트 스크립트를 업데이트해야 합니다.스크립트 자체를 유지 관리하는 것은 필요할 때 수정, 디버깅 및 자동화된 테스트가 필요한 코드 개발 프로세스입니다.프레임워크, 비용이 드는 경우 이를 사용하여 절감된 테스트 비용보다 적지 않으면 자동 테스트가 실패합니다.
프로젝트의 일부 모듈은 상대적으로 안정적인 반면 일부 모듈의 요구 사항은 매우 다양합니다. 그런 다음 상대적으로 안정적인 모듈에 대해 자동화된 테스트를 수행할 수 있지만, 더 많이 변경되는 모듈에는 수동 테스트가 필요합니다.
긴 프로젝트 주기
자동화된 테스트 요구 사항 결정, 자동화된 테스트 프레임워크의 설계, 테스트 스크립트의 작성 및 디버깅을 모두 완료하는 데 오랜 시간이 걸리기 때문입니다. 이러한 프로세스 자체는 테스트 소프트웨어 개발 프로세스이며 완료하는 데 오랜 시간이 걸립니다. 프로젝트 주기가 상대적으로 짧고 이러한 프로세스를 지원할 시간이 충분하지 않은 경우 자동화된 테스트는 농담이 됩니다.
자동화된 테스트 스크립트는 재사용 가능
자동화된 테스트 스크립트의 재사용은 세 가지 측면에서 고려되어야 합니다: 한편으로는 테스트 대상 프로젝트 간에 큰 차이가 있는지(예: C/S 시스템과 B/S 시스템의 차이), 선택한 테스트가 선택되었는지 여부 도구가 이 차이에 적합한지, 마지막으로 테스터가 이 차이에 적응하는 자동화된 테스트 프레임워크를 개발할 수 있는지 여부입니다.
자동화된 테스트를 위해 선택할 도구
XX 프로젝트가 자동화된 테스트에 적합하다는 것을 확인했다면 다음으로 해야 할 일은 테스트 도구를 선택하는 것입니다.
우선, 테스트하고 있는 제품이 데스크톱 프로그램(C/S)인지, 웹 애플리케이션(B/S)인지 먼저 확인해야 합니다.
데스크탑 프로그램 도구에는 QTP, AutoRunner가 포함됩니다.
웹 애플리케이션용 도구에는 QTP, AutoRunner, Robot Framework, watir, Selenium이 포함됩니다.
B/S 아키텍처의 많은 장점으로 인해 몇 년 전에 수많은 C/S 아키텍처 애플리케이션이 B/S 구조로 전환되었습니다. 이는 또한 웹 개발 및 테스트 기술의 발전을 촉진합니다. 테스트 대상 제품이 C/S 아키텍처를 갖고 있다면 QTP를 추천합니다. QTP는 UI 자동화 테스트 분야에서 테스트 비율의 절반을 차지합니다. 따라서 자동화 분야에서 QTP가 강력하고 사용하기 쉽다는 것을 보여주는 것으로 충분합니다. 주류 도구를 배우면 더 많은 기회를 얻을 수도 있습니다. 시중에는 QTP에 관한 책도 많이 나와 있습니다. 물론, QTP를 잘 배우고 싶다면 VBS 스크립트 언어를 마스터해야 합니다.
테스트 중인 제품이 B/S 구조라면 셀레늄을 추천하는데 QTP나 다른 툴은 왜 안되나요? Selenium은 B/S 애플리케이션을 잘 지원하고, 더 중요하게는 다국어 개발을 지원하기 때문에 Selenium을 진정으로 사용하려면 도구뿐만 아니라 언어도 배워야 합니다. 셀레늄을 선택해야 하는 이유는 무엇입니까? 또한 언어를 배워야 하는데, 이는 의심할 바 없이 학습 비용을 증가시킵니다. 비용이 증가하는 동시에 경쟁력도 높아집니다.또한 이 과정에서 자동화 도구를 배울 수 있을 뿐만 아니라 배운 언어를 사용하여 더 많은 작업을 수행할 수 있습니다.
괜찮은! 셀레늄을 사용하기로 결정했다면 언어 선택이라는 새로운 문제에 직면하게 됩니다. Selenium은 Java, Python, Ruby, PHP, C# 및 JavaScript를 지원합니다.
언어 학습 용이성 측면에서는 Ruby와 Python이 선호됩니다.
언어 응용 범위 측면에서 java, C#, php,
언어 관련 테스트 기술(및 정보) 측면: Ruby, Python, Java
아니면 전체 기술팀이 공통적으로 사용하는 언어가 무엇인지 고려한 후 해당 언어를 선택할 수도 있습니다.
셀레늄을 사용하기 전에 알아야 할 사항
좋아요! 위의 과정을 거친 후에는 그에 맞는 선택을 해야 한다고 생각합니다. Selenium 도구를 선택했다면 계속 읽어보세요.
먼저, 셀레늄을 시작하기 전에 언어를 배우는 데 1~2개월 정도 시간이 필요합니다. 이는 언어 기초가 전혀 없는 학생을 기준으로 합니다. Ruby, Python, Java와 같은 언어를 배우는 것이 좋습니다.
물론, 이 링크를 건너뛸 수 있는 좋은 언어 기초가 있거나 풍부한 Java 프로그래밍 능력이 있다면 Python을 배우는 데 며칠 이내에만 걸릴 수 있습니다.
언어의 기본을 마스터했다면 먼저 셀레늄을 이해해야 합니다. 셀레늄은 단순한 도구가 아니라 도구의 집합이며 1.0과 2.0으로 나누어집니다. 물론 3.0도 나왔습니다.
Selenium은 단지 하나의 도구가 아니라 각각 고유한 특성과 응용 프로그램 시나리오를 가진 여러 도구로 구성됩니다.
셀레늄 IDE
Selenium IDE는 Firefox 브라우저에 내장된 플러그인으로 간단한 브라우저 조작 기록 및 재생 기능을 구현합니다. 그럼 언제 사용되나요?
버그 재현 스크립트를 신속하게 생성: 테스터의 테스트 과정에서 버그가 발견된 후 IDE를 통해 재현 단계를 기록하여 개발자가 버그를 보다 쉽게 재현할 수 있습니다.
IDE에서 기록한 스크립트는 다국어로 변환이 가능하여 빠른 스크립트 개발에 도움이 되며, 이 기능은 나중에 사용하게 되면 자세히 소개하도록 하겠습니다.
셀레늄 그리드
Selenium Grid는 자동화된 테스트 도구로, 기존 컴퓨터 인프라를 활용하여 웹앱의 기능 테스트 속도를 높일 수 있습니다. Grid를 사용하면 여러 시스템과 이기종 환경에서 동시에 여러 테스트 사례를 병렬로 쉽게 실행할 수 있습니다. 그 특성은 다음과 같습니다:
· 병렬 실행
· 하나의 호스트를 통해 다양한 환경과 다양한 브라우저에서 실행되는 사용 사례를 통합 제어합니다.
· 변화하는 시험기의 유연한 추가
셀레늄 RC
Selenium RC는 Selenium 제품군의 핵심 도구입니다. Selenium RC는 여러 언어로 자동화된 테스트 스크립트 작성을 지원합니다. Selenium RC 서버는 테스트 목적을 달성하기 위해 애플리케이션에 액세스하기 위한 프록시 서버로 사용됩니다.
Selenium RC는 클라이언트 라이브러리와 Selenium Server를 사용하며, 클라이언트 라이브러리 라이브러리는 주로 테스트 스크립트를 작성하고 Selenium Server 라이브러리를 제어하는 데 사용됩니다.
Selenium Server는 브라우저 동작 제어를 담당하며 일반적으로 Selenium Server는 크게 Launcher, Http Proxy, Core의 세 부분으로 구성됩니다. Selenium Core는 Selenium Server에 의해 브라우저 페이지에 내장되어 있습니다. 실제로 Selenium Core는 JS 기능의 모음입니다. 이러한 JS 기능을 통해 프로그램을 사용하여 브라우저를 작동할 수 있습니다. Launcher는 브라우저를 시작하고, Selnium Core를 브라우저 페이지에 로드하고, 브라우저의 프록시를 Selenium 서버의 Http 프록시로 설정하는 데 사용됩니다.
셀레늄 2.0
Selenium 1.0의 계열 관계를 명확히 한 후 Selenium 2.0은 이 계열에 WebDriver를 추가합니다. 이는 간단히 다음과 같이 표현됩니다.
셀레늄 2.0 = 셀레늄 1.0 + WebDriver
Selenium 2.0의 주요 권장 사항은 WebDriver라는 점을 강조할 필요가 있습니다. WebDriver는 Selenium RC를 대체합니다. Selenium은 이전 버전과의 호환성을 위한 것이기 때문에 Selenium RC가 완전히 버린 것은 아닙니다. Selenium을 사용하여 새로운 자동화 테스트 프로젝트를 개발한다면, 적극 권장합니다.WebDriver를 사용하는 것이 좋습니다. 그렇다면 셀레늄 RC와 웹드라이버의 주요 차이점은 무엇입니까?
selenium RC는 브라우저에서 JavaScript 애플리케이션을 실행하고 브라우저에 내장된 JavaScript 변환기를 사용하여 selenese 명령을 번역하고 실행합니다(selenese는 Selenium 명령 모음입니다).
WebDriver는 기본 브라우저 지원 또는 브라우저 확장을 통해 브라우저를 직접 제어합니다. WebDriver는 각 브라우저용으로 개발되었으며 테스트 중인 웹 애플리케이션에 포함된 JavaScript를 대체합니다. 브라우저와의 긴밀한 통합을 통해 JavaScript 보안 모델로 인한 제한을 피하는 고급 테스트를 생성할 수 있습니다. 브라우저 공급업체의 지원 외에도 WebDriver는 운영 체제 수준 호출을 사용하여 사용자 입력을 시뮬레이션합니다.
새로운 프로젝트라면 웹드라이버를 직접 배워도 괜찮습니다.RC는 시대에 뒤떨어진 기술입니다.
셀레늄 학습 경로
테스트 환경을 구성하세요. 학습 중인 언어에 해당하는 Selenium 테스트 환경을 구성하세요. Selenium은 정의된 의미와 같습니다. "say hello". 중국어를 사용하는 경우 안녕하세요를 표현하려면 "hello"를 쓰고, 영어를 사용하는 경우 "hello"를 씁니다. 따라서 동일한 의미라도 언어에 따라 쓰기 방법(문법)이 달라집니다.
그런 다음 webdriver API에 익숙해져야 합니다. API는 Selenium에서 정의한 메소드로 페이지의 다양한 요소를 찾아 조작하는 데 사용됩니다.
먼저 요소의 위치를 알아보세요. Selenium은 id, 이름, 클래스 이름, 태그 이름, 링크 텍스트, 부분 링크 텍스트, xpath, css와 같은 위치 지정 방법을 제공합니다. xpath와 CSS의 강력한 구문은 약간 복잡하므로 더 많은 프런트엔드 지식이 필요할 수 있습니다. xml, 자바스크립트 등
요소 위치 지정의 목적은 요소를 조작하는 것입니다. 그런 다음 입력 상자, 드롭다운 상자, 버튼 클릭, 파일 업로드, 다운로드, 페이징, 대화 상자, 경고 상자 등 다양한 요소의 작동을 배워야 합니다. 곧.
일정 기간 학습한 후에는 페이지의 다양한 요소를 쉽게 조작하여 수동 테스트를 시뮬레이션할 수 있습니다. 그런 다음 해야 할 일은 이러한 "사용 사례"를 구성하고 통합된 방식으로 실행하는 것뿐입니다.
그런 다음 단위 테스트 프레임워크를 배우고 사용하기만 하면 됩니다. 단위 테스트 프레임워크 자체가 사용 사례의 구성과 운영을 해결합니다.
몇 가지 "테스트 케이스"를 작성한 후에는 테스트 케이스에 반복되는 작업이 많이 있다는 것을 알게 될 것입니다. 이를 별도의 파일에 작성하고 필요할 때 이러한 작업을 호출할 수 있습니까? 물론 가능합니다. 프로그래밍 기술을 사용하여 이를 달성하는 것은 매우 간단합니다. 그러다가 각 유스 케이스에 일부 데이터가 있다는 것을 알게 되는데, 데이터는 동일하지만 변경되면 수정하기가 매우 번거로우며, 읽기 위해 별도의 파일에 쓸 수도 있습니다.
그러다가 새로운 질문이 생깁니다. 제가 작성한 스크립트(유스케이스)는 모두 파이프라인으로 되어 있는데, 유스케이스가 실패했는지, 성공했는지 어떻게 알 수 있나요? 그런 다음 스크립트에 몇 가지 확인 및 어설션을 추가해야 합니다.
그러면 더 많은 아이디어를 얻을 수 있습니다. 단위 테스트 프레임워크의 로그가 너무 간단합니다. 아름다운 테스트 보고서를 생성할 수 있습니까? 이 스크립트를 정기적으로 실행할 수 있나요? 각 스크립트 실행의 테스트 결과를 내 이메일로 직접 보낼 수 있나요? 할 수 있다...
이러한 문제를 해결하려면 더 많은 프로그래밍 기술을 배워야 하며, 그러면 "테스트 구조"가 점점 더 강력하고 유연해집니다. 어느 정도의 다양성과 휴대성을 갖추고 있습니다. 괜찮은 자동화 테스트 프레임워크가 탄생했습니다.
언젠가 자동화된 UI 테스트를 더 이상 수행하지 않는다면 단위 테스트나 인터페이스 테스트를 수행하는 것이 기본적으로 어렵지 않다는 것을 알게 될 것입니다. 테스트 도구 등을 개발하는 것은 문제가 되지 않습니다. Selenium님, 감사합니다! 그건 그렇고, 나도 고마워요!
마지막으로: [도움이 될 수 있는 튜토리얼]
