원숭이와 고릴라 테스트란 무엇입니까? 예, 차이점
토마스 해밀턴
⚡ 스마트 요약
몽키 테스팅은 실행 중인 애플리케이션에 무작위의 계획되지 않은 입력을 입력하고 애플리케이션이 제대로 작동하는지 관찰하는 방식입니다. 따라서 사전 정의된 테스트 케이스가 작성되기 훨씬 전에 충돌, 멈춤, 처리되지 않은 상태 등을 파악할 수 있습니다.
몽키 테스팅이란 무엇인가요?
원숭이 테스트 몽키 테스팅은 테스터가 미리 정의된 테스트 케이스 없이 애플리케이션에 임의의 입력을 입력하고 애플리케이션의 동작, 특히 충돌 여부를 확인하는 소프트웨어 테스트 기법입니다. 몽키 테스팅의 목적은 스크립트 없이 이루어지는 실험적인 상호 작용을 통해 버그와 오류를 찾는 것입니다.
이름은 아래 그림과 같은 간단한 그림에서 유래했습니다.
- 몽키 테스팅에서는 테스터(그리고 때로는 개발자)가 "원숭이"로 취급됩니다.
- 원숭이가 컴퓨터를 사용한다면 시스템을 이해하지 못한 채 무작위로 작업을 수행할 것입니다.
- 이와 마찬가지로 테스터는 테스트 케이스를 미리 정의하지 않고 테스트 대상 시스템에 임의의 입력을 적용하여 버그를 찾아냅니다.
- 어떤 경우에는 원숭이 실험이 다음과 같은 목적을 가지고 있습니다. 단위 테스트 or GUI 테스트.
고릴라 테스트란 무엇입니까?
고릴라 테스트 이는 프로그램의 한 모듈을 반복적으로 테스트하여 올바르게 작동하고 결함이 없는지 확인하는 소프트웨어 테스트 기법입니다.
하나의 모듈을 정확히 동일한 방식으로 100번 이상 실행할 수 있기 때문에 고릴라 테스트는 "짜증나는 테스트"라고도 불립니다. 몽키 테스트는 애플리케이션 전체에 무작위로 퍼져나가는 반면, 고릴라 테스트는 한 곳에 집중적으로 테스트를 진행하여 문제가 발생하거나 문제가 없음을 확인할 때까지 계속합니다.
원숭이 테스트 유형
몽키 테스팅은 테스터가 시스템에 대해 알고 있는 정도에 따라 여러 유형으로 나뉩니다. 아래 다이어그램은 세 가지 유형을 요약한 것입니다.
- 멍청한 원숭이: 테스터는 시스템이나 그 기능에 대해 전혀 알지 못하며, 입력값이 유효하다는 보장도 없습니다.
- 똑똑한 원숭이: 테스터는 시스템의 목적과 기능에 대해 정확히 이해하고 있으며, 시스템을 탐색하고 유효한 입력을 제공합니다.
- 똑똑한 원숭이: 테스터는 실제 사용자 행동을 기반으로 결함이 발생할 가능성이 높은 부분을 파악할 수 있습니다.
몽키 테스팅 vs 고릴라 테스팅 vs 애드혹 테스팅
원숭이 실험, 고릴라 실험 임시 테스트 즉흥적인 분위기가 비슷해서 종종 혼동되곤 합니다. 아래 두 표에서 둘을 구분했습니다.
원숭이 테스트 vs 고릴라 테스트
| 원숭이 테스트 | 고릴라 테스트 |
|---|---|
| 사전에 특별히 정의된 테스트 케이스 없이 무작위로 수행됩니다. | 사전에 정의된 것도 아니고 무작위적인 것도 아닙니다. 동일한 검사가 단순히 반복될 뿐입니다. |
| 전체 시스템을 대상으로 수행되며 여러 테스트 케이스가 포함될 수 있습니다. | 선별된 몇몇 모듈에 대해 몇 가지 테스트 케이스를 사용하여 수행했습니다. |
| 목표는 시스템 오류 발생 여부를 확인하는 것입니다. | 목표는 모듈이 제대로 작동하는지 확인하는 것입니다. |
몽키 테스트 vs. 애드혹 테스트
| 원숭이 테스트 | 임시 테스트 |
|---|---|
| 사전에 특별히 정의된 테스트 케이스 없이 무작위로 수행됩니다. | 계획이나 문서화 없이 수행되었으므로 테스트 케이스나 SRS는 준비되지 않았습니다. |
| 테스터들은 시스템이 무엇인지, 또는 무엇을 위한 시스템인지 모를 수도 있습니다. | 테스터는 테스트를 시작하기 전에 시스템을 충분히 이해해야 합니다. |
| 목표는 시스템 오류 발생 여부를 확인하는 것입니다. | 목표는 시스템을 무작위로 여러 하위 부분으로 나누고 각 부분의 기능을 확인하는 것입니다. |
원숭이 실험의 장점과 단점
이 기법은 계획을 희생하고 속도를 높이는 방식이기 때문에, 장점과 단점 모두 동일한 특성에서 비롯됩니다.
원숭이 실험의 장점
- 새로운 종류의 벌레: 테스터는 사전에 명시된 시나리오 외에서도 자유롭게 작업할 수 있으므로, 누구도 스크립트에 포함시키지 않았던 오류를 발견할 수 있습니다.
- 실행하기 쉬움: 무작위 데이터에 대해 무작위 동작을 배치하는 것은 시스템을 테스트하는 빠른 방법입니다.
- Less 숙련된 사람들: 숙련된 실험자가 없더라도 원숭이를 이용한 실험은 종종 가능합니다.
- Less 값비싼: 스크립트 기반 솔루션보다 설치 및 운영에 드는 비용이 훨씬 적습니다.
원숭이 실험의 단점
- 버그는 재현하기 어려울 수 있습니다. 입력값이 무작위이기 때문에 기록된 시드 없이는 오류를 재현하는 것이 불가능할 수 있습니다.
- Less 정확성: 테스터는 정확한 시나리오를 정의할 수 없으며 테스트 내용의 정확성을 보장할 수 없습니다.
- 기술적 전문 지식은 여전히 도움이 됩니다. 결과를 의미 있게 유지하려면 테스터는 해당 분야에 대한 충분한 지식을 갖춰야 합니다.
- 수확량 대비 속도가 느리다. 테스트 실행 시간이 길어질 수 있지만 결함이 거의 발견되지 않아 시스템에 공백이 생길 수 있습니다.
몽키 테스팅 수행 방법
툴을 활용하면 몽키 테스팅이 훨씬 효율적이 되며, 실행 가능한 기준에 따라 테스트할 수 있습니다. Android 빌드뿐만 아니라 데스크톱 및 웹 애플리케이션도 개발합니다. 일반적인 프로세스는 다음과 같습니다.
- 테스트 대상 애플리케이션을 해당 애플리케이션을 구동할 도구 또는 전용 서버에 등록하십시오.
- 테스트 스위트를 구축하는 데 필요한 참조 및 구성을 도구에 준비하십시오.
- 빌드된 테스트 스위트를 실행합니다.
- 도구가 로그를 작성하도록 하십시오. "몽키 테스트" 로그 파일에는 생성된 모든 이벤트와 결과가 기록됩니다.
- 시스템이 충돌하는 지점에 도달할 때까지 실행을 계속하십시오. 그러면 문제가 발생한 동작이 로그에 기록됩니다.
- 보고서를 담당 팀과 공유하고 향후 참조를 위해 테스트 데이터를 저장하십시오.
모든 로그를 보관하세요. 무작위 실행은 나중에 이벤트 순서와 해당 실행을 생성한 시드 값이 저장되어 있어야만 유용합니다. 결함 관리 충돌의 원인을 재현 가능한 입력값과 연결할 수 있습니다.
몽키 테스팅 도구
몽키 테스트는 일반적으로 자동화되어 있는데, 사람이 수십 개의 이벤트를 생성하는 동안 기계는 수천 개의 이벤트를 생성할 수 있기 때문입니다. 일반적으로 사용되는 옵션은 다음과 같습니다.
- UI/애플리케이션 연습용 원숭이: 내장된 명령줄 도구 Android 그것은 ~에서 실행됩니다 ADB 쉘 또한 탭, 제스처, 키 입력과 같은 사용자 이벤트와 시스템 수준 이벤트를 의사 난수 스트림으로 생성하여 기기 또는 에뮬레이터로 전송합니다.
- 원숭이러너: 분리 된 Python API 워크스테이션에서 장치와 에뮬레이터를 구동하고, 특정 명령을 전송하고, 스크린샷을 캡처하는 도구입니다. 이름과는 달리, 운동용 원숭이와는 다른 도구입니다.
- UI 오토메이터 및 Appium: 일반 모바일 테스트 빌드 시 반무작위적인 이벤트 시퀀스를 실행하도록 스크립트를 작성할 수 있는 프레임워크.
- AFL과 같은 퍼징 도구: 제스처가 아닌 데이터에 적용된 동일한 무작위 입력 개념은 다음에서 다룹니다. 퍼지 테스트.
스크립트 기반 테스트에 비해 몽키 테스트에 대한 도구 지원은 부족합니다. 자동화 테스트그래서 대부분의 팀은 전용 제품을 구매하기보다는 기존 프레임워크에 범용 이벤트 생성기를 결합하여 사용합니다.
몽키 테스팅은 언제 사용해야 할까요?
몽키 테스트는 계획된 테스트를 대체하는 일반적인 방법이라기보다는 특정 상황에서 그 가치를 발휘합니다.
다음과 같은 경우에 사용하세요:
- 정식 테스트 케이스가 마련되기 전에 초기 빌드에서 저렴한 안정성 검사가 필요합니다.
- 인터페이스는 게임, 그림 도구, 미디어 플레이어 등 매우 상호작용적이므로 실제 사용자 행동을 예측하기 어렵습니다.
- 몸을 담그고 싶으세요? 스트레스 이 프로그램은 여러 시간 동안 크래시, 메모리 누수 및 처리되지 않은 상태를 찾아냅니다.
- 배포된 버전이 스크립트에 따른 검사를 통과했지만, 스크립트에서 다루지 않은 부분에 대해 독립적인 검토를 원합니다.
다음과 같은 경우에는 피하세요:
- 요건이 충족되었음을 입증할 수 있는 반복 가능한 증거가 필요합니다. 바로 그것이 서면 증거의 역할입니다. 테스트 사례.
- 해당 빌드는 매우 불안정해서 실행할 때마다 즉시 충돌이 발생하며, 이로 인해 모든 문제가 첫 번째 실패 뒤에 숨겨집니다.
- 시간이 촉박합니다. 무작위로 시도한다고 해서 반드시 무언가를 찾을 수 있는 것은 아니기 때문입니다.
실제로 가장 좋은 결과는 다양한 접근 방식을 혼합할 때 얻을 수 있습니다. 스크립트 기반 테스트는 알려진 흐름을 다루고, 탐색적 테스트 미지의 것을 의도적으로 탐구하고, 원숭이 실험은 둘 다 결코 일어나지 않을 거라고 생각했던 모든 것을 공격한다.
