메뉴

소프트웨어 테스트의 테스트 범위 (테스트 범위를 최대화하기위한 팁)

test coverage software testing

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

소프트웨어 테스팅 테스트 커버리지 전체 가이드 : 더 많이 테스트하고, 시간을 절약하고, 더 나은 테스트 결과를 얻는 방법 :

소프트웨어 테스트는 소프트웨어 개발 및 유지 관리 수명주기에서 필수적인 활동입니다. 소프트웨어 품질을 결정하고 개선하는 데 자주 사용되는 관행입니다.

오늘날 개발은 더 체계적이며 조직은 테스트 완료 기준을 보여주기 위해 테스트의 완전성과 효율성을 측정합니다. 그중에서도 보장은 특히 가치있는 것으로 간주됩니다.

학습 내용 :

테스트 커버리지 란 무엇입니까?

간단히 말해 범위는 '무엇을 테스트하고 있으며 얼마를 테스트하고 있습니까?'입니다.

테스트 커버리지는 테스트 품질을 모니터링하는 데 도움이되며 테스터가 누락되거나 검증되지 않은 영역을 다루는 테스트를 생성하는 데 도움이됩니다.

테스트 범위

대부분의 팀은 기능적 요구 사항만을 기준으로 커버리지 계산을합니다. 또한 무엇보다도 응용 프로그램이해야 할 일을해야하기 때문에 공정합니다. 그렇지 않다면 속도, 보안 또는 사용 용이성-그 어느 것도 중요하지 않습니다.

그러나 헌신적이고 독립적 인 경우 비 기능 테스트 팀은 성능, 보안, 사용성 테스트 등에 대해 작업하고 있으며 테스트 커버리지 분석을 통해 실행까지 요구 사항을 추적해야합니다.

테스트 커버리지 및 코드 커버리지

테스트 커버리지는 종종 코드 커버리지와 혼동됩니다. 기본 원칙은 동일하지만 두 가지가 다릅니다.

코드 커버리지 실제로 코드의 모든 영역을 한 번 이상 대상으로해야하고 개발자가 수행하는 단위 테스트 관행에 대해 이야기합니다.

반면에 테스트 범위는 모든 요구 사항 테스트 적어도 한 번은 분명히 QA 팀 활동입니다.

실제로 적용되는 요구 사항이되는 것은 각 팀의 해석에 따라 다릅니다.

예를 들면 , 일부 팀은 이에 대한 테스트 사례가 하나 이상있는 경우 해당 요구 사항을 호출합니다. 때로는 팀원이 한 명 이상 지정되면 보장됩니다. 또는 관련된 모든 테스트 케이스가 실행되는 경우.

  • 10 개의 요구 사항과 100 개의 테스트가 생성 된 경우 (이 100 개의 테스트가 10 개의 요구 사항을 모두 대상으로하고 하나도 생략하지 않은 경우)이를 설계 수준에서 적절한 테스트 범위라고합니다.
  • 생성 된 테스트 중 80 개만 실행되고 요구 사항 중 6 개만 대상으로하는 경우. 테스트의 80 %가 완료 되었음에도 불구하고 4 가지 요구 사항이 충족되지 않는다고 말합니다. 이것은 실행 수준의 커버리지 통계입니다.
  • 8 개의 요구 사항과 관련된 90 개의 테스트에만 테스터가 할당되고 나머지는 그렇지 않은 경우 테스트 할당 범위는 80 % (10 개 중 8 개 요구 사항)라고 말합니다.

보장을 계산하는시기에 대해서도 중요합니다.

프로세스 초기에이 작업을 수행하면 아직 불완전하기 때문에 많은 간격이 생깁니다. 따라서 일반적으로 마지막 빌드까지 기다려 즉, 최종 회귀 빌드입니다. 이것은 주어진 요구 사항에 대해 수행 된 테스트의 정확한 적용 범위를 제공합니다.

또한 읽기 => 릴리스 및 배포 관리 프로세스

내 경험

장면 8 년 전 : 소프트웨어 테스팅 업계에서 2 년의 경험을 쌓았을 때 소프트웨어 테스팅에 대한 기본 사항을 몰라도 경험으로 배울 수 있고 저도 그렇게 할 것이라고 생각했습니다.

나는 옳았 고 또한 틀렸다.

경험을 통해 더 큰 그림을 보는 법을 배우고 '중요 상황'의 진정한 의미를 이해하고 최종 사용자를 더 많이 이해하기 때문입니다.

언급 된 것 중 어느 것도 경험이 필요하지 않기 때문에 틀렸지 만, 아주 늦게 이해 한 조기 학습이었습니다. 이것이이 게시물을 작성하는 데 고무적인 요소입니다.

짧은 시간에 테스트 범위 최대화

그 당시 인터뷰 중 하나에서 얻은 경험은 다음과 같습니다.

테스트 범위가 완전하거나 최대인지 어떻게 확인합니까? 나는 물었다.

음 …… 모든 기능을 테스트하고 있는지 확인합니다 , 나는 말했다.

에스 o 모든 기능을 테스트하면 테스트 측면에서 최대 애플리케이션 / 제품을 다루었다고 생각합니다. , 면접관은 역효과를 냈습니다.

음… 음…. 음…. 예, 모든 기능을 테스트 할 때 응용 프로그램 / 제품의 동작에 대해 확신하고 나는 내 대답을지지했다 .

동의하지만 제 질문은 – 테스트 범위가 최대인지 완전하다는 확신을 줄 수 있습니까? 면접관은 나를 놓아 줄 기분이 아니었다.

이제 저는 소프트웨어 테스팅에 대한 가장 중요한 주제 중 하나를 배우게 될 것이라는 사실에 대해 알지 못하고 참을성이 없어졌습니다. ' 테스트 범위” .

YouTube를 mp4 고품질로 변환

인터뷰에서 발췌 한 부분을 재현하기보다는 그날 테스트 커버리지에 대해 배운 내용을 여기에 요약하겠습니다. 그러나 그 전에 한 가지 점을 분명히하겠습니다. 테스트 범위는 테스트가 충분한 지 여부를 아는 것을 의미하지 않으며 완벽하게 테스트하고 있는지 여부를 의미하지도 않습니다.

테스트 범위 의미

테스트 범위는 상황에 따라 다른 의미를 가질 수 있습니다. 이러한 컨텍스트를 하나씩 살펴 보겠습니다.

제품 범위 – 제품의 어떤 측면을 보셨습니까?

예, 테스트 범위를 제품 측면에서 측정 할 때 중점을 두어야 할 주요 영역은 테스트 한 제품 영역과 테스트되지 않은 영역입니다.

예 1 :

'나이프'가 제품이면 테스트하는 것입니다. 야채 / 과일을 제대로 자르는 지 확인하는 데 집중하지 마세요. 다음과 같이 찾아야 할 다른 측면이 있습니다. 사용자가 편안하게 처리 할 수 ​​있어야합니다.

예 2 :

'메모장'이 응용 프로그램 인 경우 테스트중인 경우 관련 기능을 확인하는 것이 필수입니다.

그러나주의해야 할 다른 측면은 다른 응용 프로그램을 동시에 사용하는 동안 응용 프로그램이 제대로 응답하고 응용 프로그램이 충돌하지 않는 것입니다. 사용자가 이상한 일을하려고 할 때 , 사용자에게 적절한 경고 / 오류 메시지가 제공되고, 사용자가 애플리케이션을 쉽게 이해하고 사용할 수 있으며, 필요할 때 도움말 콘텐츠를 사용할 수 있습니다.

언급 된 시나리오를 살펴 보지 않으면 애플리케이션에 대한 테스트 범위가 완료되었다고 주장 할 수 없습니다.

위험 범위 – 어떤 위험을 테스트 했습니까?

위험 범위는 완전한 테스트 범위를 갖는 또 다른 측면입니다. 관련 위험도 테스트 할 때까지 제품 또는 애플리케이션에 '테스트 됨'태그를 지정할 수 없습니다. 관련 위험의 범위는 전체 테스트 범위에서 중요한 요소입니다.

예 1 :

비행기를 테스트하는 동안 테스터가 비행기의 내부 시스템을 완전히 테스트했으며 정상적으로 작동하고 있지만 테스트 중에 비행기의 비행 능력 만 다루지 않았다고 말하면 어떻게 반응할까요?

글쎄, 그것이 위험 보장이 의미하는 바입니다. 애플리케이션 / 제품에 따라 위험을 식별하고 철저히 테스트하는 것은 항상 좋은 방법입니다.

예 2 :

전자 상거래 사이트를 테스트하는 동안 테스터는 모든 효과적인 요소를 고려했지만 동시에 웹 사이트에 액세스하는 사용자 수의 위험을 고려하지 않았으며 Super OFFER 당일에 고려되지 않은 위험은 큰 실수로 판명되었습니다.

추천 도서 =>

요구 사항 범위 – 어떤 요구 사항을 테스트 했습니까?

제품이나 응용 프로그램이 매우 잘 개발되었지만 고객의 요구 사항에 맞지 않으면 소용이 없습니다. 테스트 중 요구 사항 범위는 제품 범위만큼 중요합니다.

예 1 :

가족 행사에 흥분한 당신은 재단사에게 드레스를 꿰매고 목선에 공작 파란색 쇼 버튼을 달도록 요청했습니다.

재단사는 드레스를 꿰매는 동안 그 단추를 목선에 두는 것이 좋지 않을 것이라고 생각하여 대신 황금색 테두리를 꿰매 었습니다. 평가판 당일에 불만족스러운 고객은 요구 사항을 고수하지 않는다고 재단사에게 소리 쳤습니다.

예 2 :

채팅 애플리케이션을 테스트하는 동안 테스터는 여러 사용자가 그룹으로 채팅을하고, 두 명의 사용자가 독립적으로 채팅을하고, 모든 유형의 이모티콘이 사용 가능하며, 사용자에게 즉시 업데이트가 전송되는 등 모든 중요한 사항을 처리했지만 요구 사항 문서를 확인하는 것을 잊었습니다. 두 명의 사용자가 독립적으로 채팅 할 때 화상 통화 옵션을 활성화해야한다고 언급했습니다.

클라이언트는 두 명의 사용자가 독립적으로 채팅하는 동안 통화를 허용한다고 주장하는 채팅 애플리케이션을 마케팅했습니다. 채팅 애플리케이션에 무슨 일이 일어 났을 지 상상할 수 있습니다.

또한 읽다 => 요구 사항 추적 성 매트릭스를 만드는 방법

적절한 테스트 커버리지 방법을 채택하는 방법은 무엇입니까?

인식이 전부입니다.

우선, QA 팀은 얼마나 많은 작업이 관련되고 디자인 작업이 어디에 있는지 알아야합니다. 이렇게하면 더 많은 테스트가 추가되어야하는지 알 수 있습니다. 이를 위해 일반적인 관행대로 RTM을 사용할 수 있습니다.

=> 자세한 내용과 사용 방법을 알아 보려면이 기사를 확인하십시오. 요구 사항 추적 성 매트릭스 생성 방법 – 샘플 템플릿을 사용한 정확한 프로세스

둘째, 자원 할당을 확인하고 테스트 실행 프로세스 모든 것이 더 효과적인 방식으로 테스트되는지 확인합니다.

다음과 같은 표가 도움이 될 수 있습니다.

테스트 유형총 케이스실행 된 사례상태코멘트
기능의1008050 회 통과, 30 회 실패
적합성100오십45 회 통과, 5 회 실패
유용성10010098 회 통과, 2 회 실패
최종 회귀10010099 회 통과, 1 회 실패

모든 것이 테스트되었는지 확인하는 방법은 무엇입니까?

  • 모든 테스터는 요구 사항과 테스트 방법을 알고 있어야합니다.
  • 요구 사항의 우선 순위를 정하고 가장 필요한 곳에 에너지를 집중하십시오.
  • 특정 릴리스가 이전 릴리스와 어떻게 다른지에 대한 정보를 받아 중요한 요구 사항을보다 정확하게 식별하고 최대한의 긍정적 인 범위에 집중할 수 있습니다.
  • 테스트 자동화 조정
  • 테스트 관리 도구 사용 항상 알고 있습니다
  • 현명한 작업 할당-최고의 리소스를 중요한 작업에 전달하고 새로운 테스터가 새로운 관점을 더 많이 탐색하도록합니다.
  • 유지 모든 작업에 대한 체크리스트 및 기타 활동
  • Dev / Scrum / BA 팀과 더 많이 상호 작용하여 애플리케이션 동작에 대한 통찰력을 얻으십시오.
  • 모든 빌드주기 및 수정 사항을 추적하십시오.
  • 가능한 경우 초기 빌드 자체에서 가장 큰 영향을 미치는 문제를 식별하여 나중에 문제가 더 나은 안정성을 위해 작동하고 이전 문제로 차단 된 영역에 도달 할 수 있도록합니다.

효과적인 테스트를위한 중요 영역 및 방법

효과적인 테스트

#1)리소스 배팅 : 팀 구성원간에 작업을 교환합니다. 이는 참여를 개선하고 지식 집중을 방지하는 데 도움이됩니다.

C #의 oops 개념과 숙련 된 예제

#두)호환성 범위 : 당신이 알고 있는지 확인하고 다른 브라우저 과 플랫폼 응용 프로그램을 테스트하십시오.

#삼)소유권: 테스터에게 책임감을 부여하고 그들이 작업중인 모듈 / 작업에 대해 (물론 모니터링 및 지원과 함께) 무료 관리를 제공합니다. 이것은 책임감을 키우는 데 도움이되며 구타당한 길을 따르는 대신 창의적인 방법을 시도 할 수 있습니다.

# 4)마감일 : 테스트 단계를 시작하기 전에 출시 기한을 알면 효과적인 계획에 도움이됩니다.

# 5)통신 : 개발자 및 다른 팀과 연락 유지 출시주기 사이에 무슨 일이 일어나고 있는지 알 수 있습니다.

# 6)RTM 유지 : 좋은 파생물로 작용합니다 이해 관계자 또는 고객 , 출시 일정을 확인할 수있는 기준

테스터를위한 범위 인식 테스트의 장점 :

  • 주로 테스트 작업의 우선 순위를 지정하는 데 도움이됩니다.
  • 100 % 요구 사항 커버리지 달성 또는 요구 사항 누출 방지
  • 영향 분석 쉬워진다
  • 결정에 유용합니다 EXIT 기준
  • 테스트 리드가 명확한 준비를 할 수 있도록합니다. 테스트 마감 보고서

결론

테스트 범위는 언급 된 컨텍스트로 끝나지 않습니다. 테스트 커버리지와 관련하여 고려해야 할 다른 많은 사항이 있습니다.

더 많이 테스트 할 때 결과가 더 좋다는 것은 항상 사실이 아닙니다. 사실, 분명한 전략없이 더 많은 것을 테스트 할 때 아마도 많은 시간을 투자하게 될 것입니다.

보다 체계적인 접근 방식, 100 % 요구 사항 범위 및 효과적인 테스트 방법을 목표로하면 품질에 타협하지 않을 것입니다.

이 기사에 설명 된 기술이 몇 가지 지침을 제공하기를 바랍니다.

게시물에 대한 의견과 견해를 입력하십시오. 평소와 같이 여러분의 의견을 듣고 싶습니다.

추천 도서

^