메뉴

연기 테스트 대 온 전성 테스트 : 예제와의 차이

smoke testing vs sanity testing

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

예를 통해 연기 테스트와 위생 테스트의 차이점을 자세히 살펴보십시오.

이 튜토리얼에서는 소프트웨어 테스팅에서 Sanity Testing과 Smoke Testing이 무엇인지 배울 것입니다. 또한 간단한 예제를 통해 Sanity와 Smoke 테스트의 주요 차이점을 알아 봅니다.

대부분의 경우 Sanity Testing과 Smoke Testing의 의미를 혼동합니다. 우선,이 두 테스트는 ' 다른 ”이며 테스트주기의 여러 단계에서 수행됩니다.

연기 테스트 및 위생 테스트

학습 내용 :

온 전성 테스트

Sanity Testing은 QA로서 모든 테스트 케이스를 실행할 시간이 충분하지 않을 때 수행됩니다. 기능 테스트 , UI, OS 또는 브라우저 테스트.

따라서 나는 정의 할 것입니다.

'Sanity Testing은 각 구현과 그 영향을 다루기 위해 수행되는 테스트 실행으로서 철저하거나 심층적이지는 않지만 구현 및 그 영향에 따라 기능, UI, 버전 등 테스트를 포함 할 수 있습니다.'

우리 모두 하루나 이틀 안에 승인을해야하는데 테스트 용 빌드가 아직 출시되지 않은 상황에 빠지지 않습니까?

YouTube를 mp4 고품질로 변환

아, 그렇습니다. 소프트웨어 테스팅 경험에서 적어도 한 번은 이러한 상황에 직면했을 것입니다. 글쎄요, 제 프로젝트가 대부분 민첩하고 때로는 같은 날에 제공하라는 요청을 받았기 때문에 많은 문제에 직면했습니다. 죄송합니다. 몇 시간 내에 빌드를 테스트하고 릴리스하려면 어떻게해야하나요?

작은 기능이라해도 그 의미가 엄청날 수 있기 때문에 가끔 미쳐 가곤했습니다. 그리고 케이크의 장식으로 고객은 때때로 단순히 여분의 시간을 제공하기를 거부합니다. 몇 시간 안에 전체 테스트를 완료하고 모든 기능을 확인하고 버그 릴리스?

온 전성 테스트

이러한 모든 문제에 대한 답은 매우 간단했습니다. 온 전성 테스트 전략.

모듈이나 기능 또는 전체 시스템에 대해이 테스트를 수행하면 실행을위한 테스트 케이스 똑같은, 즉 넓지 만 얕은 테스트의 모든 중요한 비트와 조각을 만질 수 있도록 선택됩니다.

때때로 테스트는 테스트 케이스없이 무작위로 수행됩니다. 하지만 기억해, 온 전성 테스트는 시간이 부족할 때만 수행해야하며 정규 릴리스에는 사용하지 마십시오. 이론적으로이 테스트는 회귀 테스트 .

내 경험

온 전성 테스트 경험

소프트웨어 테스팅 분야에서 8 년 이상의 경력을 쌓은 후 3 년 동안 애자일 방법론 y 그리고 그때가 주로 온 전성 테스트를 사용했던 때였습니다.

모든 큰 릴리스는 체계적으로 계획되고 실행되었지만 때때로 작은 릴리스는 가능한 한 빨리 제공되도록 요청되었습니다. 테스트 케이스를 문서화하고, 실행하고, 버그를 문서화하고, 회귀를 수행하고, 전체 프로세스를 따를 시간이 많지 않았습니다.

따라서 다음은 이러한 상황에서 내가 따라 왔던 몇 가지 핵심 사항입니다.

#1) 빠르게 작업해야하므로 구현에 대해 논의 할 때 관리자 및 개발 팀과 함께 앉아 별도로 설명해 줄 수는 없습니다.

이것은 또한 그들이 구현할 내용, 영향을 미칠 영역 등에 대한 아이디어를 얻는 데 도움이 될 것입니다. 이것은 때때로 우리가 단순히 의미를 깨닫지 못하고 기존 기능이 있는지 깨닫지 못하기 때문에 매우 중요한 일입니다. (최악의 경우) 방해 될 것입니다.

#두) 시간이 부족하기 때문에 개발 팀이 구현 작업을 진행할 때 쯤이면 Evernote 등과 같은 도구에서 테스트 사례를 대략적으로 기록 할 수 있습니다.하지만 나중에 추가 할 수 있도록 어딘가에 작성해야합니다. 테스트 케이스 도구.

#삼) 구현에 따라 테스트 베드를 준비하고 테스트 베드가 시간이 걸리는 경우 (그리고 릴리스에 대한 중요한 테스트 인 경우) 특정 데이터 생성과 같은 위험 신호가 있다고 생각되면 즉시 해당 플래그를 올리고 관리자에게 알리거나 로드 블록에 대한 PO.

고객이 최대한 빨리 원한다고해서 반 테스트를 거쳤더라도 QA가 릴리스된다는 의미는 아닙니다.

# 4) 시간 경색으로 인해 개발 팀에 버그를 전달하고 추가하는 공식 프로세스 만 팀 및 관리자와 합의하여 시간을 절약하기 위해 나중에 버그 추적 도구의 여러 단계에 대한 버그를 표시 할 것입니다. .

# 5) 개발 팀이 최종 테스트를 할 때 그들과 페어링을 시도하고 (dev-QA 페어링이라고 함) 설정 자체에 대한 기본 라운드를 수행하면 기본 구현이 실패 할 경우 빌드의 앞뒤를 피하는 데 도움이됩니다. .

# 6) 이제 빌드가 완료되었으므로 먼저 비즈니스 규칙과 모든 사용 사례를 테스트하십시오. 필드 유효성 검사, 탐색 등과 같은 테스트를 나중에 보관할 수 있습니다.

# 7) 발견 한 버그가 무엇이든 모두 기록해두고 개별적으로보고하기보다는 개발자에게 함께보고하십시오.

# 8) 전체에 대한 요구 사항이있는 경우 성능 시험 또는 스트레스 또는 부하 테스트를 수행 한 다음 적절한 자동화 프레임 워크가 있는지 확인하십시오. 온 전성 테스트를 통해 수동으로 테스트하는 것은 거의 불가능하기 때문입니다.

# 9) 이것은 가장 중요한 부분이며 실제로 온 전성 테스트 전략의 마지막 단계입니다.“릴리스 이메일이나 문서를 초안 할 때 실행 한 모든 테스트 케이스, 발견 된 버그, 상태 표시기가있는 경우, 남은 것이 있는지 언급하십시오. 테스트되지 않은 이유와 함께 언급 ' 모든 사람에게 테스트되고 검증 된 것과 그렇지 않은 것에 대해 전달할 수 있도록 테스트에 대한 생생한 이야기를 작성하십시오.

이 테스트를 사용할 때 종교적으로 이것을 따랐습니다.

내 경험을 공유하겠습니다.

#1) 우리는 웹 사이트에서 작업하고 있었고 키워드를 기반으로 광고를 팝업하는 데 사용되었습니다. 광고주는 동일한 화면을 가진 특정 키워드에 대해 입찰가를 지정했습니다. 이전에는 기본 입찰가가 $ 0.25로 표시되었지만 입찰자가 변경할 수도 있습니다.

이 기본 입찰가가 표시되던 곳이 한 곳 더 있으며 다른 값으로도 변경할 수 있습니다. 클라이언트는 기본값을 $ 0.25에서 $ 0.5로 변경하라는 요청을 받았지만 분명한 화면 만 언급했습니다.

브레인 스토밍 토론 중에이 다른 화면은 그 목적에 많이 사용되지 않았기 때문에 잊어 버렸습니다 (?). 그러나 입찰의 기본 사례를 $ 0.5로 실행하고 끝까지 확인했을 때 테스트하는 동안 동일한 cronjob이 한곳에서 $ 0.25를 찾았 기 때문에 실패했음을 발견했습니다.

나는 이것을 우리 팀에보고했고 우리는 변경을하고 같은 날 성공적으로 전달했습니다.

#두) 동일한 프로젝트 (위에서 언급)에서 입찰에 대한 메모 / 댓글을위한 작은 텍스트 필드를 추가하라는 요청을 받았습니다. 매우 간단한 구현이었고 우리는 당일에이를 제공하기로 약속했습니다.

따라서 위에서 언급했듯이 모든 비즈니스 규칙과 사용 사례를 테스트했으며 일부 유효성 검사 테스트를 수행했을 때와 같은 특수 문자 조합을 입력하면 페이지가 충돌하는 것을 발견했습니다.

우리는 그것을 생각하고 실제 입찰자는 어떤 경우에도 그러한 조합을 사용하지 않을 것임을 알아 냈습니다. 따라서 우리는 문제에 대해 잘 짜여진 메모와 함께 릴리스했습니다. 클라이언트는이를 버그로 받아 들였지만 심각한 버그이지만 이전 버그가 아니기 때문에 나중에 구현하기로 동의했습니다.

#삼) 최근에 모바일 앱 프로젝트를 진행 중이 었는데, 시간대별로 앱에 표시되는 배송 시간을 업데이트해야했습니다. 앱에서 테스트 할뿐만 아니라 웹 서비스에서도 테스트했습니다.

개발 팀이 구현 작업을하는 동안 웹 서비스 테스트를위한 자동화 스크립트와 배달 항목의 시간대 변경을위한 DB 스크립트를 만들었습니다. 이것은 나의 노력을 절약했고 우리는 단기간에 더 나은 결과를 얻을 수있었습니다.

온 전성 테스트 대 회귀 테스트

다음은 둘 사이의 몇 가지 차이점입니다.


S. 아니.		회귀 테스트


온 전성 테스트
7이 테스트는 몇 주 또는 몇 달 동안 예정된 시간에 진행됩니다.

이는 대부분 최대 2 ~ 3 일에 걸쳐 진행됩니다.

1회귀 테스트는 전체 시스템 및 버그 수정이 제대로 작동하는지 확인하기 위해 수행됩니다.각 기능이 예상대로 작동하는지 확인하기 위해 온 전성 테스트가 무작위로 수행됩니다.
두이 테스트에서 가장 작은 부분은 모두 회귀합니다.
이것은 계획된 테스트가 아니며 시간이 부족할 때만 수행됩니다.
삼
잘 정교하고 계획된 테스트입니다.

이것은 계획된 테스트가 아니며 시간이 부족할 때만 수행됩니다.

4이 테스트를 위해 적절하게 설계된 테스트 케이스 세트가 작성됩니다.

매번 테스트 케이스를 생성 할 수있는 것은 아닙니다. 일반적으로 대략적인 테스트 케이스 세트가 생성됩니다.

5여기에는 기능, UI, 성능, 브라우저 / OS 테스트 등에 대한 심층 검증이 포함됩니다. 즉, 시스템의 모든 측면이 회귀됩니다.

여기에는 주로 비즈니스 규칙, 기능 확인이 포함됩니다.

6이것은 광범위하고 심층적 인 테스트입니다.

이것은 넓고 얕은 테스트입니다.

모바일 앱 테스트를위한 전략

모바일 앱 건전성 테스트

여기에서 모바일 앱에 대해 구체적으로 언급하는 이유가 궁금 하신가요?

그 이유는 웹 또는 데스크톱 앱의 OS 및 브라우저 버전이 크게 다르지 않고 특히 화면 크기가 표준이기 때문입니다. 그러나 모바일 앱의 경우 화면 크기, 모바일 네트워크, OS 버전 등이 모바일 앱의 안정성, 모양, 즉 성공에 영향을 미칩니다.

따라서 한 번의 실패로 인해 큰 문제가 발생할 수 있으므로 모바일 앱에서이 테스트를 수행 할 때 전략 수립이 중요해집니다. 테스트는 현명하고 신중하게 수행되어야합니다.

다음은 '모바일 앱'에서이 테스트를 성공적으로 수행하는 데 도움이되는 몇 가지 지침입니다.

#1) 우선, 팀과 함께 구현에 대한 OS 버전의 영향을 분석하십시오.

다음과 같은 질문에 대한 답을 찾으십시오. 버전에 따라 동작이 다를까요? 구현이 가장 낮은 지원 버전에서 작동합니까? 버전 구현에 성능 문제가 있습니까? 구현 동작에 영향을 줄 수있는 OS의 특정 기능이 있습니까? 기타

#두) 위의 메모에서 전화 모델에 대해서도 분석하십시오. 즉, 구현에 영향을 줄 전화 기능이 있습니까? GPS를 사용하여 동작이 변경됩니까? 구현 동작이 휴대 전화의 카메라로 변경 되나요? 영향이 없다고 판단되면 다른 휴대 전화 모델에서 테스트하지 마세요.

#삼) 구현에 대한 UI 변경 사항이없는 한 UI 테스트를 최우선 순위로 유지하는 것이 좋습니다. 원하는 경우 UI가 테스트되지 않는다고 팀에 알릴 수 있습니다.

# 4) 시간을 절약하려면 강력한 네트워크에서 구현이 예상대로 작동 할 것이 분명하므로 양호한 네트워크에서 테스트하지 마십시오. 4G 또는 3G 네트워크에서 테스트를 시작하는 것이 좋습니다.

# 5) 이 테스트는 더 짧은 시간에 수행되지만 단순한 UI 변경이 아니라면 하나 이상의 현장 테스트를 수행해야합니다.

# 6) 다른 OS와 그 버전의 매트릭스를 테스트해야한다면 현명한 방식으로 수행하는 것이 좋습니다. 예를 들어 테스트를 위해 가장 낮은, 중간 및 최신 OS 버전 쌍을 선택합니다. 릴리스 문서에서 모든 조합이 테스트되는 것은 아니라고 언급 할 수 있습니다.

# 7) 비슷한 맥락에서 UI 구현 온 전성 테스트를 위해 소형, 중형 및 대형 화면 크기를 사용하여 시간을 절약하십시오. 시뮬레이터와 에뮬레이터를 사용할 수도 있습니다.

예방 대책

Sanity Testing은 시간이 부족할 때 수행되므로 각각의 모든 테스트 케이스를 실행할 수 없으며 가장 중요한 것은 테스트를 계획 할 시간이 충분하지 않다는 것입니다. 비난 게임을 피하기 위해 예방 조치를 취하는 것이 좋습니다.

이러한 경우 서면 커뮤니케이션 부족, 테스트 문서 및 누락이 매우 흔합니다.

이것에 빠지지 않도록 다음 사항을 확인하십시오.

  • 클라이언트가 공유 한 서면 요구 사항이 제공되지 않을 때까지 테스트 용 빌드를 수락하지 마십시오. 고객은 변경 사항이나 새로운 구현을 구두로 또는 채팅으로 또는 이메일의 간단한 1 라이너로 전달하고이를 요구 사항으로 처리하기를 기대합니다. 고객이 몇 가지 기본 기능 포인트와 허용 기준을 제공하도록합니다.
  • 테스트 케이스와 버그를 깔끔하게 작성할 시간이 충분하지 않은 경우 항상 대략적인 메모를 작성하십시오. 문서화되지 않은 상태로 두지 마십시오. 시간이 있다면 리드 나 팀과 공유하여 빠진 것이 있으면 쉽게 지적 할 수 있도록합니다.
  • 귀하와 귀하의 팀이 시간이 부족한 경우 이메일에 버그가 적절한 상태로 표시되어 있는지 확인 하시겠습니까? 전체 버그 목록을 팀에 이메일로 보내고 개발자가 적절하게 표시하도록 할 수 있습니다. 항상 상대방의 코트에 공을 보관하십시오.
  • 당신이 가지고 있다면 자동화 프레임 워크 준비, 그것을 사용하고하지 마십시오 수동 테스트 , 그렇게하면 짧은 시간에 더 많은 것을 다룰 수 있습니다.
  • 제공 할 수 있다고 100 % 확신하지 않는 한 '1 시간 내에 릴리스'시나리오를 피하십시오.
  • 마지막으로 위에서 언급했듯이 테스트 대상, 누락 된 항목, 이유, 위험, 해결 된 버그, '나중에'등을 알리는 자세한 릴리스 이메일 초안을 작성합니다.

QA는 테스트해야하는 구현의 가장 중요한 부분과 생략하거나 기본 테스트 할 수있는 부분을 판단해야합니다.

짧은 시간에도 원하는 방식에 대한 전략을 계획하면 주어진 시간 내에 최고를 달성 할 수 있습니다.

연기 테스트

연기 테스트는 철저한 테스트는 아니지만 특정 빌드의 기본 기능이 예상대로 제대로 작동하는지 확인하기 위해 실행되는 테스트 그룹입니다. 이것은 모든 '새'빌드에서 수행되는 첫 번째 테스트이며 항상 그래야합니다.

개발 팀이 테스트를 위해 QA에 빌드를 릴리스 할 때 전체 빌드를 테스트하고 구현에 버그가 있거나 작동 기능이 손상되었는지 즉시 확인하는 것은 분명히 불가능합니다.

이에 비추어 QA는 기본 기능이 제대로 작동하는지 어떻게 확인합니까?

이에 대한 대답은 연기 테스트 .

연기 테스트

테스트가 Smoke 테스트 (테스트 스위트에서) 통과로 표시되면 심층 테스트 및 / 또는 회귀를 위해 QA에서 빌드가 승인됩니다. 스모크 테스트 중 하나라도 실패하면 빌드가 거부되고 개발 팀은 문제를 수정하고 테스트를 위해 새 빌드를 출시해야합니다.

이론적으로 Smoke 테스트는 개발 팀이 QA 팀에 제공 한 빌드가 추가 테스트 준비가되었음을 증명하는 표면 수준 테스트로 정의됩니다. 이 테스트는 QA 팀에 빌드를 출시하기 전에 개발 팀에서도 수행합니다.

이 테스트는 일반적으로 통합 테스트, 시스템 테스트 및 수락 수준 테스트에서 사용됩니다. 이것을 실제 종단 간 완전한 테스트의 대체물로 취급하지 마십시오. . 빌드 구현에 따라 양성 및 음성 테스트로 구성됩니다.

연기 테스트 예

이 테스트는 일반적으로 통합, 수락 및 시스템 테스트 .

QA로서의 경력에서 나는 항상 연기 테스트를 수행 한 후에 만 ​​빌드를 수락했습니다. 따라서이 세 가지 테스트의 관점에서 몇 가지 예를 들어 연기 테스트가 무엇인지 이해하겠습니다.

# 1) 수락 테스트

빌드가 QA에 출시 될 때마다 연기 테스트는 수락 테스트 해야합니다.

이 테스트에서 첫 번째이자 가장 중요한 연기 테스트는 구현의 기본 예상 기능을 확인하는 것입니다. 이와 같이 특정 빌드에 대한 모든 구현을 확인해야합니다.

연기 테스트를 이해하기 위해 빌드에서 수행 된 구현으로 다음 예제를 사용하겠습니다.

  • 등록 된 드라이버가 성공적으로 로그인 할 수 있도록 로그인 기능을 구현했습니다.
  • 운전자가 오늘 실행할 경로를 표시하는 대시 보드 기능을 구현했습니다.
  • 지정된 날짜에 경로가없는 경우 적절한 메시지를 표시하는 기능을 구현했습니다.

위의 빌드에서 허용 수준에서 연기 테스트는 기본 세 가지 구현이 제대로 작동하는지 확인하는 것을 의미합니다. 이 세 가지 중 하나라도 고장난 경우 QA는 빌드를 거부해야합니다.

# 2) 통합 테스트

이 테스트는 일반적으로 개별 모듈이 구현되고 테스트 될 때 수행됩니다. 에서 통합 테스트 수준에서이 테스트는 모든 기본 통합 및 종단 간 기능이 예상대로 제대로 작동하는지 확인하기 위해 수행됩니다.

두 모듈을 통합하거나 모든 모듈을 함께 통합 할 수 있으므로 연기 테스트의 복잡성은 통합 수준에 따라 달라집니다.

이 테스트를위한 다음 통합 구현 예를 고려해 보겠습니다.

  • 경로 및 중지 모듈의 통합을 구현했습니다.
  • 도착 상태 업데이트 통합을 구현하고 정류장 화면에 동일하게 반영합니다.
  • 배달 기능 모듈까지 완전한 픽업 통합을 구현했습니다.

이 빌드에서 스모크 테스트는 이러한 세 가지 기본 구현을 확인할뿐만 아니라 세 번째 구현의 경우 몇 가지 경우도 완전한 통합을 확인합니다. 통합에 도입 된 문제와 개발 팀에서 알아 차리지 못한 문제를 찾는 데 많은 도움이됩니다.

# 3) 시스템 테스트

이름 자체에서 알 수 있듯이 시스템 수준의 경우 연기 테스트에는 시스템의 가장 중요하고 일반적으로 사용되는 워크 플로에 대한 테스트가 포함됩니다. 이는 전체 시스템이 준비 및 테스트 된 후에 만 ​​수행되며, 시스템 수준에 대한이 테스트는 회귀 테스트 전에 연기 테스트라고도 할 수 있습니다.

전체 시스템의 회귀를 시작하기 전에 연기 테스트의 일부로 기본적인 종단 간 기능을 테스트합니다. 전체 시스템을위한 스모크 테스트 스위트는 최종 사용자가 매우 자주 사용할 엔드 투 엔드 테스트 케이스로 구성됩니다.

이것은 일반적으로 자동화 도구의 도움으로 수행됩니다.

SCRUM 방법론의 중요성

요즘 프로젝트는 프로젝트 구현에서 Waterfall 방법론을 거의 따르지 않으며 대부분의 프로젝트는 Agile 및 스크럼 뿐. 전통적인 폭포수 방식에 비해 Smoke Testing은 SCRUM과 Agile에서 높은 평가를 받고 있습니다.

저는 SCRUM에서 4 년 동안 일했습니다 . 그리고 SCRUM에서 스프린트는 더 짧은 기간이므로이 테스트를 수행하는 것이 매우 중요하므로 실패한 빌드가 즉시 개발 팀에보고되고 수정 될 수 있습니다.

다음은 일부입니다 테이크 아웃 SCRUM에서이 테스트의 중요성에 대해 :

  • 2 주간 스프린트에서 하프 타임은 QA에 할당되지만 때때로 QA 빌드가 지연됩니다.
  • 스프린트에서는 문제가 초기에보고되는 것이 팀에게 가장 좋습니다.
  • 각 스토리에는 일련의 승인 기준이 있으므로 처음 2-3 승인 기준을 테스트하는 것은 해당 기능의 연기 테스트와 동일합니다. 고객은 단일 기준에 실패하면 배송을 거부합니다.
  • 개발 팀이 빌드를 제공 한 지 2 일이 지났고 데모를 위해 3 일만 남았는데 기본 기능 장애가 발생하면 어떻게 될지 상상해보십시오.
  • 평균적으로 스프린트에는 5 ~ 10 개의 스토리가 있으므로 빌드가 제공 될 때 테스트에 빌드를 수락하기 전에 각 스토리가 예상대로 구현되었는지 확인하는 것이 중요합니다.
  • 전체 시스템이 테스트되고 회귀 될 때 스프린트는 활동 전용입니다. 전체 시스템을 테스트하는 데 2 ​​주가 조금 걸리므로 회귀를 시작하기 전에 가장 기본적인 기능을 확인하는 것이 매우 중요합니다.

연기 테스트 대 빌드 수락 테스트

연기 테스트는 BAT (Build Acceptance Testing)와 직접 관련이 있습니다.

QA 테스트에 들어가는 방법

BAT에서는 빌드가 실패하지 않았는지, 시스템이 제대로 작동하는지 확인하기 위해 동일한 테스트를 수행합니다. 때때로 빌드가 생성 될 때 일부 문제가 발생하고 제공 될 때 빌드가 QA에 작동하지 않는 경우가 있습니다.

BAT는 연기 점검의 일부라고 말할 수 있습니다. 시스템이 실패하면 QA가 테스트를 위해 빌드를 어떻게 수락 할 수 있습니까? 기능뿐만 아니라 시스템 자체가 QA가 심층 테스트를 진행하기 전에 작동해야합니다.

연기 테스트주기

다음 순서도는 연기 테스트주기를 설명합니다.

빌드가 QA에 배포되면 기본주기는 스모크 테스트가 통과하면 추가 테스트를 위해 QA 팀이 빌드를 승인하지만 실패하면보고 된 문제가 수정 될 때까지 빌드가 거부됩니다.

테스트주기

연기 테스트주기

누가 연기 테스트를 수행해야합니까?

누가 아이콘

모든 QA의 시간 낭비를 피하기 위해 전체 팀이 이러한 유형의 테스트에 참여하는 것은 아닙니다.

연기 테스트는 추가 테스트를 위해 빌드를 팀에 전달할지 또는 거부할지 여부를 결과에 따라 결정하는 QA 책임자가 이상적으로 수행합니다. 또는 리드가없는 경우 품질 보증 담당자가이 테스트를 수행 할 수도 있습니다.

때때로 프로젝트가 대규모 프로젝트 인 경우 QA 그룹은이 테스트를 수행하여 뛰어난 사용자를 확인할 수 있습니다. 그러나 SCRUM의 경우에는 그렇지 않습니다. SCRUM은 리드 또는 관리자가없는 평면 구조이고 각 테스터는 자신의 스토리에 대해 자신의 책임이 있습니다.

따라서 개별 QA는 자신이 소유 한 스토리에 대해이 테스트를 수행합니다.

연기 테스트를 자동화해야하는 이유

이 테스트는 개발 팀이 출시 한 빌드에서 수행되는 첫 번째 테스트입니다. 이 테스트의 결과에 따라 추가 테스트가 수행됩니다 (또는 빌드가 거부 됨).

이 테스트를 수행하는 가장 좋은 방법은 자동화 도구를 사용하고 새 빌드가 생성 될 때 실행되도록 Smoke Suite를 예약하는 것입니다. 당신은 내가 왜 '연기 테스트 도구 모음 자동화'?

다음 사례를 살펴 보겠습니다.

출시가 일주일 남았고 총 500 개의 테스트 사례 중 연기 테스트 모음이 80-90 개로 구성되어 있다고 가정 해 보겠습니다. 이 모든 80-90 테스트 사례를 수동으로 실행하기 시작하면 얼마나 많은 시간이 걸릴지 상상해보십시오. 4 ~ 5 일 (최소)이라고 생각합니다.

그러나 자동화를 사용하고 이러한 모든 80-90 테스트 케이스를 실행하는 스크립트를 작성하는 경우 이상적으로는 2-3 시간 내에 실행되며 결과를 즉시 확인할 수 있습니다. 소중한 시간을 절약하고 빌드에 대한 결과를 훨씬 더 적게 제공하지 않았습니까?

5 년 전, 저는 당신의 급여, 저축 등에 대한 입력을 받아 재정 규칙에 따라 세금, 저축, 이익을 예상하는 재정 예측 앱을 테스트했습니다. 이와 함께 변경에 사용 된 국가 및 세금 규칙 (코드에서)에 의존하는 국가에 대한 사용자 정의가 있습니다.

이 프로젝트에서는 800 개의 테스트 케이스가 있었고 250 개는 연기 테스트 케이스였습니다. Selenium을 사용하면 3-4 시간 내에 250 개의 테스트 케이스를 쉽게 자동화하고 결과를 얻을 수있었습니다. 그것은 우리의 시간을 절약했을뿐만 아니라 흥행 자들에 대해 최대한 빨리 보여주었습니다.

따라서 자동화가 불가능하지 않는 한이 테스트를 위해 자동화의 도움을 받으십시오.

장점과 단점

몇 가지 단점과 비교할 때 제공 할 것이 많으므로 먼저 장점을 살펴 보겠습니다.

장점 :

  • 수행하기 쉽습니다.
  • 위험을 줄입니다.
  • 결함은 매우 초기 단계에서 식별됩니다.
  • 노력, 시간 및 비용을 절약합니다.
  • 자동화 된 경우 빠르게 실행됩니다.
  • 최소 통합 위험 및 문제.
  • 시스템의 전반적인 품질을 향상시킵니다.

단점 :

  • 이 테스트는 완전한 기능 테스트와 같거나 대체하지 않습니다.
  • 연기 테스트를 통과 한 후에도 눈에 띄는 버그를 찾을 수 있습니다.
  • 이 유형의 테스트는 특히 약 700-800 개의 테스트 케이스가있는 대규모 프로젝트에서 테스트 케이스를 수동으로 실행하는 데 많은 시간을 소비하는 경우 자동화 할 수있는 경우 가장 적합합니다.

연기 테스트는 매우 초기 단계에서 주요 실패와 큰 문제를 지적하므로 모든 빌드에서 확실히 수행되어야합니다. 이는 새로운 기능뿐만 아니라 모듈 통합, 문제 수정 및 즉흥 연주에도 적용됩니다. 수행하고 올바른 결과를 얻는 것은 매우 간단한 프로세스입니다.

이 테스트는 기능 또는 시스템 (전체)의 완전한 기능 테스트를위한 진입 점으로 취급 될 수 있습니다. 하지만 그 전에 QA 팀은 연기 테스트로 수행 할 테스트에 대해 매우 명확해야합니다. . 이 테스트는 노력을 최소화하고 시간을 절약하며 시스템의 품질을 향상시킬 수 있습니다. 스프린트의 시간이 적기 때문에 스프린트에서 매우 중요한 위치를 차지합니다.

이 테스트는 수동 및 자동화 도구를 사용하여 수행 할 수 있습니다. 그러나 가장 좋고 선호되는 방법은 시간을 절약하기 위해 자동화 도구를 사용하는 것입니다.

연기와 위생 테스트의 차이점

대부분의 경우 Sanity Testing과 Smoke Testing의 의미를 혼동합니다. 우선,이 두 테스트는 ' 다른 ”이며 테스트주기의 여러 단계에서 수행됩니다.

S. 아니.연기 테스트

온 전성 테스트

1 스모크 테스트는 빌드에서 수행 된 구현이 제대로 작동하는지 확인 (기본)하는 것을 의미합니다.온 전성 테스트는 새로 추가 된 기능, 버그 등이 제대로 작동하는지 확인하는 것을 의미합니다.
두 이것은 초기 빌드에 대한 첫 번째 테스트입니다.빌드가 비교적 안정적 일 때 완료됩니다.
삼 모든 빌드에서 수행됩니다.회귀 후 안정적인 빌드에서 수행됩니다.

다음은 차이점을 다이어그램으로 나타낸 것입니다.

연기 테스트

연기 테스트

  • 이 테스트는 하드웨어 새 하드웨어를 처음으로 켜고 화재 나 연기가 나지 않으면 성공한 것으로 간주하는 테스트 연습. 소프트웨어 산업에서이 테스트는 너무 깊이 들어 가지 않고 애플리케이션의 모든 영역을 테스트하는 얕고 광범위한 접근 방식입니다.
  • 연기 테스트는 서면 테스트 세트 또는 자동 테스트를 사용하여 스크립팅됩니다.
  • Smoke 테스트는 응용 프로그램의 모든 부분을 간단하게 터치하도록 설계되었습니다. 얕고 넓습니다.
  • 이 테스트는 프로그램의 가장 중요한 기능이 작동하는지 여부를 확인하기 위해 수행되지만 세부 사항은 신경 쓰지 않습니다. (빌드 검증 등).
  • 이 테스트는 심층 테스트를하기 전에 애플리케이션 빌드에 대한 정상적인 상태 점검입니다.

위생 테스트

  • 온 전성 테스트는 하나 또는 몇 가지 기능 영역에 초점을 맞춘 좁은 회귀 테스트입니다. Sanity Testing은 일반적으로 좁고 깊습니다.
  • 이 테스트는 일반적으로 스크립트가 없습니다.
  • 이 테스트는 작은 변경 후에도 응용 프로그램의 작은 부분이 여전히 작동하는지 확인하는 데 사용됩니다.
  • 이 테스트는 간단한 테스트이며, 응용 프로그램이 사양에 따라 작동하고 있음을 증명하기에 충분한 테스트가있을 때마다 수행됩니다. 이 수준의 테스트는 회귀 테스트의 하위 집합입니다.
  • 이는 요구 사항이 충족되었는지 여부를 확인하고 모든 기능을 폭 우선적으로 확인하기위한 것입니다.

이 두 가지 방대하고 중요한 소프트웨어 테스팅 유형의 차이점에 대해 명확히 이해하시기 바랍니다. 아래 댓글란에 자유롭게 의견을 남겨주세요 !!

추천 도서

^