예비 테스트

Exploratory testing

탐색 테스트는 소프트웨어 테스트에 대한 접근법으로, 동시 학습, 테스트 설계 및 테스트 실행으로 간결하게 설명됩니다.소프트웨어 시험의 지속적test-related를 배우는 것을 다룸으로써 자신의 일의 질을 최적화하기 위해 개별 검사의 개인적인 자유와 책임 강조하는 스타일, 테스트 설계, 시험 시행,mutually 지원 시험 결과 해석으로 Cem Kaner, 1984,[1]에이라는 용어를 만들었던 defines 탐색적 시험.ive프로젝트 [2]전체에서 병행되는 액티비티.

소프트웨어를 테스트하는 동안 테스터는 경험 및 창의성과 함께 실행하기에 좋은 새로운 테스트를 생성하는 것을 학습합니다.탐색 테스트는 종종 블랙박스 테스트 기술로 간주됩니다.대신, 이를 연구한 사람들은 개발 과정의 어느 단계에서나 모든 테스트 기술에 적용할 수 있는 테스트 접근법으로 간주한다.핵심은 테스트 기술이나 테스트 또는 검토 중인 항목이 아닙니다. 핵심은 테스트자의 인지적 참여와 [3]테스트자의 시간 관리에 대한 책임입니다.

역사

탐색 테스트는 항상 숙련된 테스트자에 의해 수행되었습니다.1990년대 초, 임시방편은 너무 자주 허술하고 부주의한 일과 동의어였다.그 결과, 테스트 방법론자 그룹(현재는 스스로를 컨텍스트 중심 학파라고 칭함)은 대본 없는 테스트와 관련된 지배적인 사고 과정을 강조하기 위해 "탐구적"이라는 용어를 사용하기 시작했고, 이를 학습 가능한 분야로 발전시키기 시작했습니다.이 새로운 용어는 Cem Kaner에 의해 그의 저서 Testing Computer Software에서 처음 발표되었으며 소프트웨어 테스트에서 [5]얻은 교훈에서 확장되었습니다.탐색 테스트는 다른 지적 활동과 마찬가지로 훈련될 수 있습니다.

묘사

탐색 테스트에서는 소프트웨어가 실제로 어떻게 동작하는지 알아보고 어렵고 쉬운 사례를 어떻게 처리할 것인지에 대한 질문을 던집니다.테스트의 품질은 테스트 케이스를 발명하고 결함을 찾아내는 테스트자의 기술에 따라 달라집니다.검사자가 제품과 다른 검사 방법에 대해 더 많이 알수록 검사가 더 잘 될 것입니다.

더 자세히 설명하기 위해 프리스타일 탐색 테스트를 대척점 스크립트 테스트와 비교할 수 있다.후자의 활동에서는 테스트 케이스를 사전에 설계합니다.여기에는 개별 단계와 예상 결과가 모두 포함됩니다.이러한 테스트는 나중에 실제 결과와 예상 결과를 비교하는 검사자에 의해 수행됩니다.탐색 테스트를 수행할 때 예상은 열려 있습니다.예측과 예측이 가능한 결과도 있고 그렇지 않은 결과도 있습니다.테스터는 제품과 그 동작을 구성, 운영, 관찰 및 평가하여 결과를 비판적으로 조사하고 버그(어떤 사람에게 제품의 가치를 위협하는 것) 또는 문제(테스트 작업의 품질을 위협하는 것)로 보이는 정보를 보고합니다.

실제로 테스트는 거의 항상 탐색 테스트와 스크립트 테스트의 조합이지만 상황에 따라 어느 쪽이든 선호하는 경향이 있습니다.

Kaner와 James Marcus Bach에 따르면, 사전 테스트는 [6]방법론이라기보다는 사고방식 또는 "시험에 대한 생각"에 가깝다.그들은 또한 이것이 약간 탐색적(약간 모호하거나 모호하게 작성된 테스트)에서 고도의 탐색적(프리스타일 탐색적 테스트)[7]까지 연속체를 가로지른다고 말한다.

탐색 테스트의 문서화는 수행된 모든 테스트에서 버그에 대한 문서화에 이르기까지 다양합니다.페어 테스트 중에 2명이 테스트 케이스를 작성하고 한쪽은 테스트 케이스를 실행하고 다른 한쪽은 문서를 작성합니다.세션 기반 테스트는 탐색 테스트를 감사 및 측정할 수 있도록 특별히 설계된 방법입니다.

탐색 테스터는 종종 탐색 세션의 기록으로 화면 캡처 또는 비디오 도구를 포함한 도구 또는 관심 상황을 신속하게 생성하는 데 도움이 되는 도구(예: James Bach의 Perlip)를 사용합니다.

장점과 단점

탐색 테스트의 주요 장점은 준비할 필요가 적고 중요한 버그가 빠르게 발견되며 실행 시 스크립트 형식의 테스트 실행보다 접근 방식이 더 지적으로 자극적인 경향이 있다는 것입니다.

또 다른 주요 이점은 시험자가 이전 결과의 결과에 기초한 연역적 추론을 사용하여 미래의 시험을 즉시 안내할 수 있다는 것이다.타겟이 풍부한 환경에 초점을 맞추거나, 타겟이 풍부한 환경을 탐색하기 전에, 현재의 일련의 스크립트 테스트를 완료할 필요는 없습니다.이것에 의해, 인텔리전트하게 사용했을 경우, 버그 검출도 고속화됩니다.

또 다른 장점은 초기 테스트 후 대부분의 버그가 일종의 탐색 테스트에 의해 발견된다는 것입니다.이는 논리적으로 "특정 테스트를 통과한 프로그램은 동일한 테스트를 계속 통과하고 아직 조사되지 않은 다른 테스트나 시나리오에 실패할 가능성이 더 높다"고 말하는 것으로 입증될 수 있다.

단점은 발명되어 즉석에서 실행되는 테스트는 사전에 리뷰할 수 없고(그리고 코드와 테스트 케이스의 오류를 방지할 수 있음), 어떤 테스트가 실행되었는지 정확하게 보여주는 것이 어려울 수 있다는 것입니다.

프리스타일 탐색 테스트 아이디어는 다시 검토할 때 정확히 동일한 방식으로 수행될 가능성이 낮으며, 새로운 오류를 찾는 것이 중요한 경우 장점이 될 수 있으며, 이전 테스트의 특정 세부 사항을 반복하는 것이 더 중요한 경우 단점이 될 수 있다.이는 검사자에 대한 특정 지침에 따라 제어하거나, 실현 가능하고 적절하며 필요한 경우 자동 테스트를 준비하여 이상적으로는 장치 수준에 근접하게 제어할 수 있습니다.

과학 연구

반복실험에 따르면 스크립트 테스트와 탐색 테스트가 유사한 결함 검출 효과(발견된 총 결함 수)를 가져오지만, 테스트 [8]케이스를 사전 설계하는 데 아무런 노력도 들이지 않기 때문에 탐색을 통해 더 높은 효율성(시간 단위당 결함 수)을 얻을 수 있습니다.탐색 테스트에 대한 관찰 연구는 도메인, 테스트 대상 시스템 및 고객에 대한 지식의 사용이 탐색 [9]테스트의 효과를 설명하는 중요한 요소라고 제안했다.3개 기업을 대상으로 한 사례 연구에서 신속한 피드백을 제공하는 것이 탐색 테스트의 이점인 반면 테스트 범위를 관리하는 것은 [10]단점으로 지적되었습니다.조사에 따르면 탐색 테스트는 중요한 영역에서도 사용되며 탐색 테스트 접근법은 [11]테스트를 수행하는 사람에게 높은 요구를 가하는 것으로 나타났다.

사용.

요건과 규격이 불완전하거나 시간이 [12][13]부족한 경우 탐색 테스트가 특히 적합합니다.이 접근방식은 이전 테스트에서 가장 중요한 결함이 [12]발견되었는지 확인하는 데도 사용할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Cem Kaner, "탐색 테스트 튜토리얼", 페이지 2
  2. ^ Cem Kaner, A Tutorial in Prevestive Testing, 페이지 36.
  3. ^ Cem Kaner, A Tutorial in Exploreral Testing, 37-39, 40-.
  4. ^ Cem Kaner, Testing Computer Software, Tab Books, Blue Ridge Summit, PA, 1988. 페이지 6, 7-11.
  5. ^ Kaner, Cem; Bach, James; Pettichord, Bret (2001). Lessons Learned in Software Testing. John Wiley & Sons. ISBN 978-0-471-08112-8.
  6. ^ Cem Kaner, James Bach, 탐색 및 리스크 기반 테스트, www.testingeducation.org, 2004, 페이지 10
  7. ^ Cem Kaner, James Bach, 탐색 및 리스크 기반 테스트, www.testingeducation.org, 2004, 페이지 14
  8. ^ Itkonen, Juha; Mäntylä, Mika V. (2013-07-11). "Are test cases needed? Replicated comparison between exploratory and test-case-based software testing". Empirical Software Engineering. 19 (2): 303–342. CiteSeerX 10.1.1.363.6524. doi:10.1007/s10664-013-9266-8. ISSN 1382-3256.
  9. ^ Itkonen, J.; Mäntylä, M. V.; Lassenius, C. (2013-05-01). "The Role of the Tester's Knowledge in Exploratory Software Testing". IEEE Transactions on Software Engineering. 39 (5): 707–724. doi:10.1109/TSE.2012.55. ISSN 0098-5589.
  10. ^ Itkonen, J.; Rautiainen, K. (2005-11-01). Exploratory testing: a multiple case study. 2005 International Symposium on Empirical Software Engineering, 2005. pp. 10 pp.–. doi:10.1109/ISESE.2005.1541817. ISBN 978-0-7803-9507-7.
  11. ^ Pfahl, Dietmar; Yin, Huishi; Mäntylä, Mika V.; Münch, Jürgen (2014-01-01). How is Exploratory Testing Used? A State-of-the-practice Survey. Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ESEM '14. New York, NY, USA: ACM. pp. 5:1–5:10. doi:10.1145/2652524.2652531. hdl:10138/153363. ISBN 9781450327749.
  12. ^ a b Bach, James (2003). "Exploratory Testing Explained" (PDF). satisfice.com. p. 7. Retrieved October 23, 2010.
  13. ^ Kaner, Cem (2008). "A Tutorial in Exploratory Testing" (PDF). kaner.com. pp. 37, 118. Retrieved October 23, 2010.

외부 링크