how select correct test cases
지금은 테스트 자동화의 시대입니다 . 대부분의 테스트 프로젝트는 생산성과 적용 범위를 개선하기 위해 수동 테스트 케이스를 자동화 된 테스트 케이스로 변환하려고합니다.
자동화 테스트를 시작하는 주요 단계 중 하나는 적절한 테스트 사례를 선택하고 ROI (투자 수익률)를 결정하는 것입니다.
이 기사에서 무엇을 기대합니까?
이 기사에서는 내 경험을 바탕으로 올바른 후보자를 선택하는 데 도움이되는 몇 가지 중요한 사항을 인용하려고했습니다. 자동화하고 더 나은 테스트 결과와 이점을 얻을 수있는 다양한 기타 요소를 결정합니다.
왜 자동화 테스트인가?
자동화는 수동 테스트를 압도하거나 대체하지 않지만이를 보완합니다. 수동과 마찬가지로 자동화에는 적절한 계획, 모니터링 및 제어가 가능한 전략이 필요합니다. 자동화가 올바르게 구현되면 팀, 프로젝트 및 궁극적으로 조직의 자산이 될 수 있습니다.
자동화에는 많은 이점이 있습니다. 다음은 언급해야 할 몇 가지 중요한 사항입니다.
- 다음과 같은 일상적인 작업을 실행하는 데 유용합니다. 연기 테스트 과 회귀 테스트 .
- 준비에 유용합니다 테스트 데이터 .
- 실행하는 데 도움이 복잡한 비즈니스 로직을 포함하는 테스트 케이스 .
- 크로스 플랫폼 테스트 케이스 (다른 OS, 브라우저 등)를 실행하는 것이 좋습니다.
- 수동으로 실행하기가 조금 어려운 테스트 케이스를 실행하는 것이 좋습니다.
- 테스트 케이스 실행의 반복 횟수를 알 수없는 경우.
많은 이해 관계자가 테스트 자동화가 수동 테스트를위한 지원 도구 역할을한다고 생각하므로 자동화가 테스트의 효과, 효율성 및 범위를 높이는 가장 좋은 방법이라는 것을 이해하는 것이 중요합니다. 수동 접근 방식을 통한 반복적 인 작업은 인적 오류가 발생하기 쉽고 시간이 많이 걸릴 수 있으므로 시간을 절약 할뿐만 아니라 정확성도 향상시킵니다.
자동화 후보
피해야 할 기본적인 실수 :
테스터가 저지르는 가장 기본적인 실수 중 하나는 자동화를위한 올바른 테스트 케이스를 선택하지 않는 것입니다.
테스트 도구 모음 만 선택하지 마십시오. 테스트 사례를 철저히 분석하고 가장 중요한 요소 인 ROI를 고려하여 자동화 후보를 선택합니다. 먼저, 우리는 더 높고 긍정적 인 ROI를 얻는 방법을 이해하고 찾아야합니다.
셀레늄 자바 인터뷰 질문 및 답변
( ROI – 투자 수익 – 비용 절감, 효율성 향상 및 품질 측면에서 이점을 계산 한 것입니다.)
자동화를위한 올바른 테스트 케이스를 결정하기위한 표준 절차는 없습니다. 그것은 모두 테스트하는 응용 프로그램에 따라 다릅니다.
내 경험을 바탕으로 테스트 사례를 선택하고 궁극적으로 자동화를위한 긍정적 인 ROI를 달성하기위한 몇 가지 통찰력을 제공 할 수있는 몇 가지 단계를 작성하려고했습니다.
참조 => 수동 테스트 케이스를 자동화 스크립트로 변환하는 방법은 무엇입니까?
학습 내용 :
자동화 테스트를 위해 올바른 테스트 케이스를 선택하는 방법
1 단계:
자동화 후보로 테스트 케이스의 기반이 될 매개 변수를 식별하십시오.
현재 아래 매개 변수를 식별하고 있으며, 애플리케이션에 따라 고유 한 매개 변수를 가질 수 있습니다.
- 다른 데이터 세트로 실행 된 테스트 케이스.
- 다른 브라우저에서 실행 된 테스트 케이스.
- 다른 환경에서 실행 된 테스트 케이스.
- 복잡한 비즈니스 로직으로 실행되는 테스트 케이스
- 다른 사용자 세트로 실행 된 테스트 케이스
- 많은 양의 데이터가 포함 된 테스트 케이스
- 테스트 케이스에 종속성이 있습니다.
- 테스트 케이스에는 특수 데이터가 필요합니다.
2 단계:
각 애플리케이션을 모듈로 나눕니다. 각 모듈에 대해 매개 변수를 기반으로 자동화해야하는 테스트 케이스를 분석하고 식별하십시오. 이 목록은 프로젝트마다 다르며 필요에 맞게 향상 될 수도 있습니다.
그림 1.0
그 - 그래
N – 아니오
비슷한 방식으로 모든 모듈에 대해이 목록을 사용하여 자동화 후보 테스트 케이스를 식별 할 수 있습니다.
3 단계 :
아래 표시된 각 모듈에 대한 테스트 사례 수를 통합하고 그룹화합니다.
그림 2.0
그림 2.0은 매우 간단하고 이해하기 쉽습니다. 여기에서는 세부 사항을 정량화하고 테스트를 수동으로 완료하기위한 추정치를 제공하려고합니다.
4 단계 :
모든 세부 수준 세부 정보를 확인한 후에는 아래 방법으로 표시 할 수 있습니다. 우리는 이제 ROI 계산을 진행하고 있습니다.
그림 3.0 :
우리는 또한 아래 사항을 고려해야합니다 ROI 억제의 기초를 형성하는 속성 :
- 도구 구매 및 라이센스 비용
- 스크립트를 개발할 시간
- 스크립트를 유지할 시간입니다.
- 결과를 수동 및 자동으로 분석하는 시간
- 리소스 교육에 소요되는 시간과 비용.
- 관리 오버 헤드
테스트 자동화 ROI 계산 예
대부분의 경우 ROI는 5 년 동안 계산되지만 필수 사항은 아닙니다. 위의 요인을 바탕으로 5 년간 ROI 계산에 대해 자세히 설명하겠습니다. 평소와 같이 언제든지 맞춤화하고 향상시킬 수 있습니다.
* ROI = (누적 저축 / 자동화를 통한 투자) * 100
자동화 테스트에 대한 수동 – 프로세스 문제는 무엇입니까?
저는 테스트 스위트를 자동화하려고 할 때 큰 도전이라고 생각하는 요점을 인용하려고했습니다.
# 1) 자동화 요구 : 모든 테스트 팀은 고유하며 자동화에 대한 독점적 인 요구가 있습니다. 우리는 고정 된 표준을 개발할 수 없지만 우리의 필요에 맞는 표준을 조정할 수 있습니다. 이러한 이유로 자동화에는 개발 팀뿐만 아니라 경영진의 좋은 지원이 필요합니다.
# 2) 전체 애플리케이션 자동화 : 100 % 애플리케이션을 자동화하는 것은 큰 작업입니다. 불가능하다는 것은 아니지만 적절한 계획과 모니터링이 필요합니다. 언젠가. 많은 순열과 데이터 조합이 있으며, n 개의 인증 및 권한 부여 속성이있는 n 개의 환경에서 유효성을 검사해야하므로 자동화 전략이 필요합니다.
# 3) 수동 대 자동화 사고 방식 : ' 우리는 일반적으로 중요하고 반복적 인 것을 자동화하지만 중요한 기능을 수동으로 테스트하는 것을 선호합니다. ”. 혼란스러워? 나도 !! 그러나 이것은 사실입니다. 우리는 어떤 것을 결정할 기준을 가져야합니다. 중대한 테스트 케이스. 이러한 기준은 복잡한 비즈니스 로직, 고객에게 더 관심이있는 영역, 위험이 발생하기 쉬운 영역 등과 같은 여러 요소를 기반으로 할 수 있습니다.
# 4) 프레임 워크 결정 : 프레임 워크 디자인 자동화의 가장 중요한 측면입니다. 스크립팅보다는 프레임 워크 개발에 상대적으로 더 많은 시간을 할애해야한다고 생각합니다. 자동화 계획을 개발할 때마다 프레임 워크 설계가 주요 초점이어야합니다.
프레임 워크 설계를 계획하십시오. 프레임 워크를 구성 할 항목을 식별하고 체크리스트를 작성하십시오. 프레임 워크가 견고하면 스크립팅 및 유지 관리가 쉬워집니다.
# 5) 팀에 대한 지식 : 자동화를 생각할 때마다 즉시 프로그래밍 언어 또는 스크립팅 언어를 배우게됩니다. 이 언어를 배우는 것은 확실히 도움이되지만 논리를 구축하고 개발하는 데 더 중점을 두어야합니다.
자동화는 일부 리소스의 책임이 아니라 전체 팀이 이에 기여해야합니다. 이것은 자원의 기술을 향상시키는 데 도움이 될뿐만 아니라 그들에게 동기를 부여하십시오 .
# 6)보고 : 모든 도구에는 테스트 결과를보고하는 표준이 있습니다. 그것을 사용자 정의하려면; 도전적인 작업입니다. 테스트 결과를보고하려면 조정 및 유지 관리가 필요하므로 비용이 추가됩니다.
# 7) 신뢰 : 우리는 자동화를 신뢰해야합니다. 우리는 자동화 제품군을 구축하기 위해 인건비를 투자하지만 여전히 테스트 결과를 믿지 않습니다. 스크립트를 유지하기 위해 노력해야합니다. 또한 응용 프로그램의 수동 테스트를 수행하는 팀이 응용 프로그램을 알고있는대로 자동화에 참여해야합니다.
대부분의 경우 제 3 팀이 자동화를 수행하므로 실제 테스트 팀은 스크립트를 인식하지 못하고 결국 스크립트에 대한 후속 조치를 취하고 작업에 추가한다고 느끼기 때문에 테스트를 수동으로 실행하게됩니다.
또한보십시오=> 수동 및 자동화 테스트 과제.
결론
대부분의 경우 우리는 회귀 제품군 자동화 ( 민첩한 환경에서 회귀 제품군을 자동화하는 데 몇 가지 문제가 있습니다. ) 더 많은 수의 테스트 케이스가 포함되어 있습니다. 이 경우 회귀 슈트를 더 작은 슈트로 나누고 릴리스 요구 사항에 따라 적절한 슈트를 실행하기로 결정할 수 있습니다.
회귀 스위트에 1500 개의 테스트 케이스가 포함되어 있다고 가정하면,이를 슈트 당 500 개의 테스트 케이스로 구성된 3 개의 슈트로 나누고 자동화 할 수 있습니다.
3 년 경력의 안드로이드 인터뷰 질문과 답변
전체 제품군을 자동화하는 대신 다음을 수행 할 수 있습니다. 단계적 자동화 선택 . 즉, 자동화 제품군 개발을위한 프로토 타입 모델을 따를 수 있습니다. 더 적은 수의 테스트 케이스를 구현하여 구조 또는 프레임 워크를 만들고이를 사용하고 더 많은 테스트 케이스를 추가하여 점진적으로 향상시킵니다.
우리는 따라야합니다 데밍 휠 (PDCA 사이클) 자동화를 위해. 지속적인 활동이기 때문에 프레임 워크를 적절하게 구축하는 데 중점을 두어야합니다. 유지 관리 및 새로운 기능 구현이 쉬워집니다.
개발팀과 경영진의 적절한 지원이 필요합니다. 우리는 테스트 팀이 다른 누구보다 제품을 더 많이 알고 있기 때문에 자동화 테스트에 가장 많이 기여하도록 장려해야합니다.
저자 정보 : 이것은 Shilpa Chatterjee Roy의 게스트 기사입니다. 그녀는 지난 8.5 년 동안 다양한 영역에서 소프트웨어 테스팅 분야에서 일하고 있습니다.
우리가 이것을 단순화하기를 바랍니다.'수동-자동화 테스트'방법. 프로세스 문제를 어떻게 극복했는지에 대한 경험과 생각을 자유롭게 공유하십시오.