초보자를위한 완전한 비 기능 테스트 가이드

complete non functional testing guide

비 기능 테스트에 대한 완전한 가이드 : 목적, 유형, 도구, 예제가있는 테스트 케이스

비 기능 테스트 란 무엇입니까?

비 기능 테스트는 성능, 사용성 등과 같은 애플리케이션의 비 기능적 요구 사항을 확인하기 위해 수행됩니다.

시스템의 동작이 요구 사항에 맞는지 여부를 확인합니다. 여기에서 다루지 않은 모든 측면을 다룹니다. 기능 테스트 . 일상적인 테스트에서 기능 테스트 및 기능 요구 사항에 많은주의를 기울입니다.

클라이언트는 또한 응용 프로그램의 기능과 직접 관련된 기능 요구 사항을 충족하는 데 관심이 있습니다. 그러나 실제 단계, 즉 기능 테스트를 거치면 소프트웨어가 시장에 출시되어 실제 최종 사용자가 사용하며 성능과 관련된 몇 가지 문제에 직면 할 가능성이 있습니다.

이러한 문제는 시스템의 기능과 관련이 없지만 부정적인 방식으로 사용자 경험에 영향을 미칠 수 있습니다. 따라서 부정적인 고객 경험을 피하기 위해 소프트웨어 또는 응용 프로그램의 비 기능 요구 사항을 테스트하는 것이 중요합니다.

테스트는 크게 두 가지 유형으로 분류됩니다.

• 기능 테스트
• 비 기능 테스트

학습 내용 :

• 중요성
• 목적
• 예
• 장점
• 비 기능적 요구 사항을 캡처하는 방법은 무엇입니까?
  • # 1) 사용자 / 기술 사례
  • # 2) 합격 기준
  • # 3) 인공물에서
• 기능 및 비 기능 요구 사항의 차이
• 이 블랙 박스 또는 화이트 박스 테스트입니까?
• 비 기능적 테스트 케이스 체크리스트
  • 성능 테스트를위한 체크리스트
  • 보안 테스트를위한 체크리스트
  • 문서 테스트를위한 체크리스트
• 접근 문서
  • 테스트 범위
  • 테스트 지표
  • 테스트 도구
  • 주요 날짜 및 결과물
• 비 기능 테스트 유형
• 비 기능 테스트 도구
  • # 1) 사용성 테스트 테스트 사례
  • # 2) 성능 테스트 테스트 사례
  • # 3) 보안 테스트 테스트 사례
• 결론
• 추천 도서

중요성

이 테스트는 시스템 기능에 영향을 미치지 않는다는 점을 고려할 때주의를 기울이지 않았습니다.

비 기능적 요구 사항도 초기 테스트주기에서 적절한주의를 기울이지 않았습니다. 그러나 이것은 지금 바뀌 었습니다. 비 기능 테스트는 오늘날 모든 애플리케이션 성능 및 보안 문제를 고려하므로 이제 가장 중요합니다.

이 테스트는 높은 사용자 트래픽에서 애플리케이션의 성능과 관련하여 애플리케이션에 더 큰 영향을 미칩니다. 이 테스트는 애플리케이션이 안정적이고 극한 조건에서 부하를 처리 할 수 ​​있는지 확인합니다.

이름 자체에서 알 수 있듯이이 테스트는 애플리케이션의 비 기능적 측면에 집중합니다. 그렇다면 비 기능적 측면은 무엇입니까? 아니면 응용 프로그램의 기능과 관련이없는 기능이 무엇인지 말해야합니까?

여기에 대한 답이 있습니다.

• 정상적인 상황에서 응용 프로그램이 어떻게 수행됩니까?
• 너무 많은 사용자가 동시에 로그인하면 애플리케이션이 어떻게 작동합니까?
• 애플리케이션이 스트레스를 처리 할 수 ​​있습니까?
• 애플리케이션은 얼마나 안전합니까?
• 재해로부터 애플리케이션을 복구 할 수 있습니까?
• 애플리케이션이 다른 환경이나 OS에서 동일한 방식으로 작동 할 수 있습니까?
• 다른 시스템에서 애플리케이션을 이식하는 것이 얼마나 쉬운가요?
• 애플리케이션과 함께 제공되는 문서 / 사용 설명서가 이해하기 쉽습니까?

목록은 계속 진행됩니다. 그러나 여기서 요점은 – 이러한 기능이 애플리케이션의 품질에 기여하지 않는가? 대답은 '예'입니다. 이러한 기능은 똑같이 중요합니다.

응용 프로그램이 모든 사용자 요구 사항을 완벽하게 충족하지만 일부 권한없는 사용자가 응용 프로그램에서 사용자가 입력 한 데이터를 쉽게 찾아 크래킹하거나 5BB 이상의 파일이 업로드 될 때 응용 프로그램이 죽는다고 상상해보십시오. 응용 프로그램의 품질이 좋다고 말씀 하시겠습니까? 분명히 옳지 않습니다 !!

목적

이 유형의 테스트의 유일한 목적은 애플리케이션의 비 기능적 측면을 테스트하고 애플리케이션이 동일한 맥락에서 잘 작동하는지 확인하는 것입니다.

목적은 비즈니스 기대를 충족하는 애플리케이션을 제공하는 데 도움이되는 애플리케이션의 모든 특성을 테스트하는 것입니다.

예

이것은 중요한 테스트 유형입니다.

기능 테스트는 애플리케이션의 기능을 테스트하고 예상대로 작동하는지 확인하지만 비 기능 테스트는 애플리케이션이 비즈니스 기대치를 충족 할만큼 충분히 잘 작동하는지 확인합니다.

그 중요성을 이해하기 위해 간단한 예를 들어 보겠습니다.

응용 프로그램이 개발되고 기능에 대해 완전히 테스트되었지만 비 기능 테스트는 동일하게 수행되지 않습니다.

한편, 응용 프로그램이 활성화되면 응용 프로그램의 부하가 증가하면 너무 느려지고 여는 데 많은 시간이 걸리는 것과 같은 중요하거나 중요한 문제가 발생할 수 있습니다.

응답 시간이 증가하거나로드가 어느 정도 증가하면 애플리케이션이 충돌 할 수 있습니다. 이것은 애플리케이션의 비 기능적 측면을 테스트하는 것이 얼마나 중요한지를 보여줍니다.

장점

비 기능 테스트의 몇 가지 장점은 다음과 같습니다.

• 기능 테스트에서 다룰 수없는 테스트를 다룹니다.
• 응용 프로그램이 효율적으로 실행되고 충분히 신뢰할 수 있는지 확인합니다.
• 응용 프로그램의 보안을 보장합니다.

비 기능적 요구 사항을 캡처하는 방법은 무엇입니까?

테스트를 수행하는 동안 주로 제품의 기능을 테스트하는 기능 테스트에 중점을 둡니다. 그러나 비 기능적 테스트는 기능적 테스트만큼 중요하며 그 요구 사항은 제품 시작부터 바로 고려해야합니다.

비 기능적 요구 사항은 비 기능적 테스트를 수행하는 데 사용됩니다. 이러한 요구 사항에는 테스트중인 응용 프로그램 또는 소프트웨어에서 예상되는 성능 출력이 포함됩니다. 여기에는 기본적으로 소프트웨어가 특정 시스템을 작동하는 데 걸리는 시간이 포함됩니다.

비 기능적 요구 사항은 또한 많은 사람들이 동시에 소프트웨어를 사용할 때의 동작을 포착합니다. 대부분의 경우 과부하로 인해 서버가 사용 중이거나 사용할 수없는 경우가 많습니다 (즉, 더 많은 사람들이 동시에 사용하고 있음). 온라인 철도 티켓을 예약하는 것이 가장 좋습니다 예 그런 상황의.

따라서 비 기능 요구 사항을 적절하게 문서화하고 테스트를 올바르게 수행하면 잠재 고객의 유용성 측면에서 높은 만족도를 얻을 수 있습니다.

이 테스트는 시스템의 기능에 직접적인 비즈니스 영향을 미치지는 않지만 사용자 경험과 사용자 친 화성을 높일 수 있으며 이는 소프트웨어 품질에 더 큰 영향을 미칩니다.

예:

동일한 Facebook 로그인 페이지 예를 고려하십시오. 이 경우 비 기능 테스트의 범위는 유효한 자격 증명을 입력 한 후 시스템이 Facebook에 로그인하는 데 필요한 시간을 기록하는 것입니다.

또한 사용자가 동시에 로그인 할 때 (예 : 100 명) Facebook에 사용자가 로그인하는 데 걸리는 시간을 테스트 할 수 있습니다.

이렇게하면 시스템이 부하와 트래픽을 처리 할 수 ​​있으며 이는 차례로 좋은 사용자 경험을 제공합니다.

애자일에서 비 기능적 요구 사항은 입력을 사용하여 캡처해야합니다.

비 기능적 요구 사항은 다음과 같이 캡처해야합니다.

• 사용자 / 기술 사례
• 수락 기준에서
• Artifact에서

9

# 1) 사용자 / 기술 사례

비 기능적 요구 사항은 다음을 사용하여 캡처 할 수 있습니다. 사용자 스토리 또는 기술적 인 이야기. 비 기능적 요구 사항을 사용자 스토리로 캡처하는 것은 다른 요구 사항을 캡처하는 것과 동일합니다. 사용자와 기술 스토리의 유일한 차이점은 사용자 스토리에는 토론이 필요하고 가시성이 있다는 것입니다.

# 2) 합격 기준

허용 기준 고객이 제품을 수락하기 위해 정의한 포인트입니다. 즉, 정의 된 포인트에 제품을 수락하려면 합격 상태 여야합니다.

비 기능적 요구 사항은 승인 기준에 포함되어야하지만 때로는 모든 스토리, 즉 모든 반복에서 비 기능적 요구 사항을 테스트 할 수 없습니다. 따라서 요구 사항은 관련 반복으로 만 추가하거나 테스트해야합니다.

# 3) 인공물에서

비 기능적 요구 사항에 대해 별도의 아티팩트를 준비해야합니다. 그러면 테스트해야 할 사항과 반복에서 수행 할 수있는 방법에 대한 더 나은 아이디어를 얻는 데 도움이됩니다.

기능 및 비 기능 요구 사항의 차이

기능적 요구 사항과 비 기능적 요구 사항 사이에는 몇 가지 차이점이 있으며 그중 몇 가지가 아래에 설명되어 있습니다.

추가 읽기 => 기능 테스트와 비 기능 테스트의 차이점

이 블랙 박스 또는 화이트 박스 테스트입니까?

비 기능 테스트는 블랙 박스 테스트 기술.

이 기술은 기능 테스트에만 국한되지 않고 성능, 유용성 등의 비 기능적 요구 사항 테스트에도 사용할 수 있습니다. 블랙 박스 테스트 기술은 내부 시스템에 대한 지식이 필요하지 않습니다. 테스터에게 코드에 대한 지식.

비 기능적 테스트 케이스 체크리스트

체크리스트는 테스트없이 중요한 측면이 남지 않도록하는 데 사용됩니다.

체크리스트는 일반적으로 문서화 할 시간이없고 제품을 테스트해야하거나 시간 제약이있는 경우 모든 중요한 측면이 다루어 졌는지 확인하기 위해 체크리스트를 사용할 수 있습니다.

보자예성능, 보안 및 문서 테스트 체크리스트.

성능 테스트를위한 체크리스트

• 응답 시간 즉, 애플리케이션을로드하는 데 걸리는 시간, 애플리케이션에 제공된 모든 입력이 얼마나 많은 시간에 출력을 제공하는지, 브라우저를 새로 고치는 지 등을 확인해야합니다.
• 처리량 로드 테스트 중에 완료된 트랜잭션 수를 확인해야합니다.
• 환경 설정은 실제 환경과 동일해야합니다. 그렇지 않으면 결과가 동일하지 않습니다.
• 처리 시간 – Excel의 가져 오기 및 내보내기와 같은 프로세스 활동, 응용 프로그램의 모든 계산을 테스트해야합니다.
• 상호 운용성 즉 소프트웨어가 다른 소프트웨어 또는 시스템과 상호 운용 될 수 있어야합니다.
• ETL 즉, 한 데이터베이스에서 다른 데이터베이스로 데이터를 추출, 변환 및로드하는 데 걸리는 시간을 확인해야합니다.
• 부하 증가 응용 프로그램에서 확인해야합니다.

보안 테스트를위한 체크리스트

• 입증: 인증 된 사용자 만 로그인 할 수 있어야합니다.
• 인정 받은: 사용자는 권한이 있거나 사용자에게 액세스 권한이 부여 된 모듈에만 로그인 할 수 있어야합니다.
• 암호: 암호 요구 사항을 확인해야합니다. 즉, 암호는 요구 사항이 정의하는 방식 (예 : 길이, 특수 문자, 숫자 등)에 따라야합니다.
• 시간 초과 : 응용 프로그램이 비활성 상태이면 지정된 시간에 시간 초과되어야합니다.
• 데이터 백업: 데이터 백업은 지정된 시간에 수행해야하며 안전한 위치에 복사해야합니다.
• 내부 링크 브라우저에 직접 배치하는 경우 웹 애플리케이션에 액세스 할 수 없어야합니다.
• 모든 통신은 암호화되어야합니다.

문서 테스트를위한 체크리스트

• 사용자 및 시스템 문서.
• 훈련 목적을위한 문서.

접근 문서

전체 테스트 전략을 구체화하여 성능 테스트 단계에 대한 구체적인 접근 방식 문서를 개발합니다. 이 테스트 접근 방식은 모든 성능 테스트 작업의 계획 및 실행을 안내합니다.

Wi-Fi 보안 키는 무엇입니까

• 테스트 범위
• 테스트 지표
• 테스트 도구
• 주요 날짜 및 결과물

테스트 범위

사용자 성능, 비즈니스 프로세스, 시스템 안정성, 리소스 소비 등과 같은 다양한 관점에서 성능 테스트를 수행합니다. 실행할 성능 테스트 유형은 문서의 위 섹션 (예 : 부하 테스트, 스트레스 테스트 등)에서 설명합니다.

테스트 지표

테스트 접근 방식은 다음과 같이 테스트 중에 측정하고보고 할 메트릭을 구체화합니다.

• 응답 시간 (온라인)
• 배치 창 (배치)
• 처리량 ( 예를 들어 , 시간 단위당 거래 수)
• 활용도 ( 예를 들어 , 사용 된 리소스의 비율)

테스트 도구

대부분 성능 테스트에는 적절한 도구를 사용해야합니다.

• 부하 생성 도구
• 성능 모니터링 도구
• 성능 분석 도구
• 애플리케이션 프로파일 링 도구
• 베이스 라이닝 도구.

주요 날짜 및 결과물

성능 테스트 접근 문서는 다음을 설명해야합니다.

• 각 성능 테스트 수행 날짜 및 시간.
• 각 성능 테스트 수행에 포함될 테스트 유형 및 기능 조합.
• 성능 테스트 완료 날짜.

비 기능 테스트 유형

다음 이미지는 비 기능 테스트 유형을 보여줍니다.

성능 시험:

시스템의 전반적인 성능을 평가합니다. .

주요 요소는 다음과 같습니다.

• 시스템이 예상 응답 시간을 충족하는지 확인합니다.
• 애플리케이션의 중요한 요소가 원하는 응답 시간을 충족하는지 평가합니다.
• 통합 테스트 및 시스템 테스트의 일부로 수행 할 수도 있습니다.

부하 테스트 :

시스템의 성능이 정상 및 예상 조건에서 예상 한대로인지 평가합니다.

요점은 다음과 같습니다.

• 동시 사용자가 애플리케이션에 액세스하고 예상 응답 시간을 얻을 때 시스템이 예상대로 수행되는지 검증합니다.
• 응답 시간과 처리량을 얻기 위해 여러 사용자가이 테스트를 반복합니다.
• 테스트시 데이터베이스는 현실적이어야합니다.
• 테스트는 실제 환경을 자극하는 전용 서버에서 수행되어야합니다.

스트레스 테스트 :

리소스가 부족할 때 시스템의 성능이 예상대로인지 평가합니다.

요점은 다음과 같습니다.

• 정상적인 조건에서 찾을 수없는 결함을 드러내는 클라이언트 / 서버의 메모리 부족 또는 디스크 공간 부족에서 테스트합니다.
• 여러 사용자가 동일한 데이터에 대해 동일한 트랜잭션을 수행합니다.
• 워크로드가 다른 서버에 여러 클라이언트가 연결됩니다.
• 생각 시간을 '제로'로 줄여 서버에 최대 스트레스를가합니다.

생각 시간 : 사용자와 암호를 입력하는 시간 간격과 같습니다.

볼륨 테스트 :

많은 양의 데이터가 포함 된 경우 소프트웨어의 동작을 평가합니다.

요점은 다음과 같습니다.

• 소프트웨어에 많은 양의 데이터가있는 경우 소프트웨어가 실패하는 한계를 확인합니다.
• 최대 데이터베이스 크기가 생성되고 여러 클라이언트가 데이터베이스를 쿼리하거나 더 큰 보고서를 생성합니다.
• 예 – 애플리케이션이 보고서를 작성하기 위해 데이터베이스를 처리하는 경우 볼륨 테스트는 큰 결과 세트를 사용하고 보고서가 올바르게 인쇄되는지 확인하는 것입니다.

사용성 테스트 :

사람이 사용할 수 있도록 시스템을 평가하거나 사용하기에 적합한 지 확인합니다.

요점은 다음과 같습니다.

• 출력이 정확하고 의미가 있으며 비즈니스별로 예상했던 것과 동일합니까?
• 오류가 올바르게 진단 되었습니까?
• GUI가 정확하고 표준과 일치합니까?
• 사용하기 쉬운 응용 프로그램입니까?

사용자 인터페이스 테스트 :

GUI를 평가합니다.

요점은 다음과 같습니다.

• GUI는 사용하기 쉽도록 도움말과 툴팁을 제공해야합니다.
• 모양이 일관 적입니까?
• 데이터가 한 페이지에서 다른 페이지로 올바르게 이동합니까?
• GUI는 사용자를 귀찮게하거나 이해하기 어렵게해서는 안됩니다.

호환성 테스트 :

응용 프로그램이 최소 및 최대 구성으로 다른 하드웨어 / 소프트웨어와 호환되는지 평가합니다.

요점은 다음과 같습니다.

• 최소 및 최대 구성으로 각 하드웨어를 테스트합니다.
• 다른 브라우저로 테스트하십시오.
  테스트 케이스는 기능 테스트 중에 실행 된 케이스와 동일합니다.
• 하드웨어와 소프트웨어의 수가 너무 많은 경우 OATS 기술을 사용하여 테스트 케이스에 도달하여 최대 범위를 가질 수 있습니다.

복구 테스트 :

오류 발생시 응용 프로그램이 정상적으로 종료되고 하드웨어 및 소프트웨어 오류로부터 데이터가 적절하게 복구되는지 평가합니다.

테스트는 아래 사항에 국한되지 않습니다.

• CURD 활동을 수행하는 동안 클라이언트에 대한 전원 중단.
• 잘못된 데이터베이스 포인터 및 키입니다.
• 데이터베이스 프로세스가 중단되었거나 너무 일찍 종료되었습니다.
• 데이터베이스 포인터, 필드 및 키는 데이터베이스 내에서 직접 수동으로 손상됩니다.
• 물리적으로 통신을 끊고 전원을 끄고 라우터와 네트워크 서버를 끕니다.

불안정성 테스트 :

소프트웨어가 올바르게 설치 및 제거되었는지 평가하고 확인합니다.

예제로 소프트웨어 테스트에서 테스트 케이스를 작성하는 방법

요점은 다음과 같습니다.

• 시스템 구성 요소가 지정된 하드웨어에 올바르게 설치되었는지 확인합니다.
• 새 컴퓨터의 탐색이 기존 설치 및 이전 버전을 업데이트하는지 확인합니다.
• 디스크 공간이 부족하면 허용 할 수없는 동작이 없는지 확인합니다.

문서 테스트 :

문서 및 기타 사용자 설명서를 평가합니다.

핵심 사항은 다음과 같습니다.

• 제품에서 명시된 문서를 사용할 수 있는지 확인합니다.
• 모든 사용자 가이드, 설정 지침, read me 파일, 릴리스 정보 및 온라인 도움말을 확인합니다.

장애 조치 테스트 :

장애 조치 테스트는 시스템 장애시 시스템이 서버와 같은 추가 리소스를 처리 할 수있을만큼 충분한 지 확인하기 위해 수행됩니다.

이러한 상황을 방지하기 위해 백업 테스트가 큰 역할을합니다. 백업 시스템을 만드는 것이 프로세스의 전부입니다. 백업을 사용할 수있는 경우 시스템을 복구하는 데 도움이됩니다.

보안 테스트 :

보안 테스트 애플리케이션에 데이터 손실이나 위협을 초래할 수있는 허점이 없는지 확인하기 위해 수행됩니다. 비 기능적 테스트의 중요한 측면 중 하나이며 제대로 수행되지 않으면 보안 위협으로 이어질 수 있습니다.

여기에는 인증, 권한 부여, 무결성 및 가용성 테스트가 포함됩니다.

확장 성 테스트 :

확장 성 테스트는 응용 프로그램이 증가 된 트래픽, 트랜잭션 수, 데이터 볼륨 등을 처리 할 수 ​​있는지 확인하기 위해 수행됩니다. 시스템은 데이터 볼륨 또는 데이터 크기 변경이 수행 될 때 예상대로 작동해야합니다.

적합성 테스트 :

규정 된 표준이 준수되고 있는지 확인하기 위해 적합성 테스트가 수행됩니다. 동일한 사항을 확인하기 위해 감사가 수행됩니다.

에 대한 예 , 테스트 케이스 / 테스트 계획을 작성하고 수행중인 표준 이름으로 공유 위치에 배치하는 프로세스를 확인하기 위해 감사가 수행됩니다. QC에서 테스트 케이스의 이름을 지정하는 동안 표준 테스트 케이스 이름을 따르거나 따르지 않습니다. 문서가 완전하고 승인되었는지 여부.

감사하는 동안 다루는 몇 가지 지침입니다.

내구성 테스트 :

내구성 테스트 장시간 부하가 증가 할 때 시스템의 동작을 확인하기 위해 수행됩니다.

소크 테스트 및 용량 테스트라고도합니다. 시스템에 메모리 누수가 있는지 확인하는 데 도움이됩니다. 내구성 테스트는 부하 테스트의 하위 집합입니다.

현지화 테스트 :

현지화 테스트 다른 언어, 즉 다른 로케일로 애플리케이션을 확인하기 위해 수행됩니다. 응용 프로그램은 특정 문화권 또는 로캘에 대해 확인되어야합니다. 주요 초점은 애플리케이션의 콘텐츠, GUI를 테스트하는 것입니다.

국제화 테스트 :

국제화 테스트 i18n 테스트라고도합니다.

I18n은 I – 열 여덟 글자-N을 나타냅니다. 응용 프로그램이 모든 언어 설정에서 예상대로 작동하는지 확인하기 위해 수행됩니다. 모든 기능 또는 응용 프로그램 자체가 중단되지 않는지 확인합니다. 즉, 응용 프로그램이 모든 국제 설정을 처리 할 수 ​​있어야합니다.

또한 응용 프로그램이 문제없이 설치되는지 확인합니다.

신뢰성 테스트 :

신뢰성 테스트는 애플리케이션이 신뢰할 수 있고 정의 된 환경에서 특정 기간 동안 테스트되는지 확인하기 위해 수행됩니다. 응용 프로그램은 매번 예상 한 것과 동일한 출력을 제공해야하며 그래야만 신뢰할 수있는 것으로 간주 될 수 있습니다.

이식성 테스트 :

이식성 테스트는 소프트웨어 / 애플리케이션이 다른 시스템 또는 다른 플랫폼에 설치된 경우 예상대로 실행될 수 있는지 확인하기 위해 수행됩니다. 즉, 환경 변화로 인해 기능에 영향을주지 않아야합니다.

테스트하는 동안 하드 디스크 공간, 프로세서 및 다른 운영 체제와 같은 하드웨어 구성으로 변경 사항을 테스트하여 애플리케이션의 올바른 동작과 예상되는 기능이 손상되지 않았는지 확인해야합니다.

기준 테스트 :

기준 테스트는 벤치 마크 테스트 테스트 할 새로운 애플리케이션의 기반을 만듭니다.

예를 들면 : 첫 번째 반복에서 애플리케이션의 응답 시간은 3 초였습니다. 이제 이것은 다음 반복에 대한 벤치 마크로 설정되었으며 다음 반복에서 응답 시간이 2 초로 변경됩니다. 기본적으로 향후 참조를위한 기반으로 사용되는 유효성 검사 문서입니다.

효율성 테스트 :

효율성 테스트는 애플리케이션이 효율적으로 작동하는지, 필요한 리소스의 수, 필요한 도구, 복잡성, 고객 요구 사항, 필요한 환경, 시간, 프로젝트 종류 등을 확인하기 위해 수행됩니다.

고려되는 모든 매개 변수가 예상대로 작동하는 경우 애플리케이션이 얼마나 효율적으로 작동하는지 정의하는 데 도움이되는 몇 가지 포인터입니다.

재해 복구 테스트 :

이 테스트는 심각한 오류가 발생하는 경우 응용 프로그램 또는 시스템의 복구 성공률을 확인하고 시스템이 데이터 및 응용 프로그램을 복원 할 수 있는지 또는 시스템이 이전 작업 방식으로 쉽게 복구 할 수 있는지 확인하기 위해 수행됩니다. 작전 전선.

유지 보수성 테스트 :

애플리케이션 / 제품이 활성화되면 라이브 환경에서 문제가 발생할 가능성이 있거나 고객이 이미 활성화 된 애플리케이션에 대한 개선을 원할 수 있습니다.

이 경우 유지 관리 테스트 팀이 위에서 언급 한 시나리오를 테스트 할 수 있습니다. 애플리케이션이 가동되면 유지 관리 테스트 팀이 작업하는 유지 관리가 여전히 필요합니다.

비 기능 테스트 도구

성능 (부하 및 스트레스) 테스트를 위해 시장에서 사용할 수있는 여러 도구가 있습니다.

그 중 몇 가지는 아래에 나열되어 있습니다.

• JMeter
• 로드스터
• 로드 러너
• 로드 스톰
• Neoload
• 예보
• 로드 완료
• 웹 서버 스트레스 도구
• WebLoad 전문가
• 로드 트레이서
• vPerformer

비 기능 테스트는 항상 문서 및 테스트 케이스없이 수행됩니까? 왜?

“우리는 항상 기능 테스트 케이스를 작성하는 방법을 배웁니다. 왜 그런 겁니까? '비 기능 테스트'가 문서없이 (즉, 임시 기준으로) 수행됩니까? 아니면 이해하기 훨씬 더 어려운 별도의 프로세스입니까? 애플리케이션에서 발생하는 다양한 종류의 테스트를 위해 테스트 케이스가 어떻게 작성됩니까?”

이것은 최근에 제가받은 가장 독창적이고 독특하며 바로 사용할 수있는 질문 중 하나입니다. 답을 찾아 봅시다.

비 기능적 테스트 케이스 작성을보고 연습 할 수없는 이유는 무엇입니까?

우리가 알고있는 것과 늘 그렇듯이 실용적인 시나리오부터 시작하겠습니다.

예: 다음은 송금을 수행하기 위해 온라인 뱅킹 애플리케이션에서 수행해야하는 단계입니다. 참고 용 테스트로 사용하겠습니다.

1. 사이트에 로그인하십시오.
2. 은행 계좌를 선택하십시오.
3. 수취인을 선택합니다 (이 수취인은 동일한 은행에 속하거나 다른 은행에 속할 수 있습니다. 이는이 단계를 실행하기위한 데이터 선택에 따라 다릅니다. 어떤 경우 든 하나를 선택하십시오. 또한 수취인이 이미 추가되었다고 가정합니다.) .
4. 전송할 금액을 입력합니다 (양수 값, 한도 이내, 올바른 형식 등).
5. 전송을 클릭하고 확인이 수신되었는지, 계정 잔액이 업데이트되었는지 확인하십시오.

이것은 기능 테스트 케이스입니다. 맞습니까?

동일한 응용 프로그램에서 동일한 전송 페이지에서 성능, 보안 및 사용성 테스트 . 비 기능적 유형입니다. 맞습니까?

테스트 케이스를 어떻게 작성합니까?

# 1) 사용성 테스트 테스트 사례

사용성 테스트는 사용자 경험을 다루는 소프트웨어 테스트의 장르입니다. 이것들은 우리가 대답하려고하는 몇 가지 질문입니다.

• 응용 프로그램을 사용하기가 얼마나 쉬운가요?
• 시스템 사용 경험이 얼마나 만족 스럽습니까?
• 지금 당장 익숙하지 않다면 배우기가 얼마나 쉬울까요?

이에 대한 자세한 정보는 다음과 같습니다. 사용성 테스트 가이드

사용자는 사용성 테스트의 맥락에서 위 질문에 대한 답을 어떻게 결정합니까?

사용자는 기능 테스트 케이스에서와 똑같은 단계를 수행합니다. 내가 맞아?

# 2) 성능 테스트 테스트 사례

성능 테스트에는 몇 가지 변형이 있지만 핵심은 다양한로드 포인트에서 시스템, 리소스 사용률, 응답 시간, 네트워크 소비 등에 대한 통계를 얻는 데 사용됩니다.

우리를 확인하십시오 성능 테스트 자습서 그것에 대해 더 알고 싶습니다.

이제 전송 트랜잭션의 성능을 테스트하려면 10, 20, 30, 100… 1000 등의 사용자가 내가 대상으로하고 데이터를 수집하려는 대상에 따라 전송 작업을 동시에 또는 점진적으로 수행하게됩니다.

성능 테스트가 진행되는 동안 전송을 사용하기 위해 각 사용자가 수행해야하는 단계는 무엇입니까?

기능 테스트와 동일한 단계, 맞습니까?

# 3) 보안 테스트 테스트 사례

보안 테스트는 소프트웨어 시스템의 해킹 방지를 돕는 QA의 한 분야입니다. 취약점 (소프트웨어 시스템의 잠재적 인 문제 영역)을 식별하고 침투 또는 화이트 햇 테스트 기술을 통해이를 악용하며 허점을 발견하면 작업합니다.

전송이 해킹에 대비하고 의도 한 수신자에게 올바르게 전달되었는지, 전체 프로세스에 블랙 스팟이 없는지 언제 확인하고 싶습니까? 보안 유출에 대한 모니터링 프로세스가 병렬로 진행되는 동안 전송을 수행합니다.

따라서 실제로 기능 테스트 케이스의 경우 일반적으로 수행하는 것과 동일한 단계를 수행하고 있습니다.

우리는 모든 상황의 단계가 동일하다는 것을 입증하기에 충분하다고 생각합니다. 프로세스 뒤에있는 방법과 의도는 다릅니다.

비교해 보겠습니다.

주목할 점은 어떤 형태의 테스트를 수행하든 모든 단계가 동일합니다. .

실제 차이점은 다음과 같습니다.

1. 누가이 단계를 수행합니까?
2. 의도는 무엇입니까, 즉이 테스트를 통해 달성하려는 것이 무엇입니까?
3. 사용 된 도구 및 기술.

우리의 질문으로 돌아가서, 왜 우리는 거기에있는 모든 세부 단계로 비 기능적 테스트 케이스를 작성하는 법을 배우지 않습니까?

왜냐하면 ,핵심에서 특정 기능에 대한 테스트 유형의 변형에 대한 테스트 단계는 모두 동일하거나 기능적이거나 그렇지 않습니다. 차이를 만드는 것은 의도이며 방법 일 수도 있습니다.

결론

비 기능적 테스트를 수행하기 전에 적절한 테스트를 보장하기 위해 테스트 전략을 올바르게 계획하는 것이 중요합니다. Load Runner, RPT 등과 같은 이러한 유형의 테스트를 수행하기 위해 시장에서 사용할 수있는 다양한 도구가 있습니다.

이 테스트는 애플리케이션의 성공과 좋은 고객 관계 구축에 중요한 역할을하므로 무시해서는 안됩니다. 이것은 소프트웨어 테스트의 중요한 부분 중 하나이며 이것 없이는 테스트가 완료된 것으로 간주 될 수 없습니다.

테스트 계획에 비 기능 테스트 세부 정보를 포함하거나 별도의 전략을 만들 수 있습니다. 두 경우 모두 목표는 소프트웨어의 비 기능적 측면을 적절하게 다루는 것입니다.

이 주제를 깊이 파고 드는이 과정이 여러분 모두에게 제시된 것만 큼 재미 있었기를 바랍니다. 이 주제에 대한 귀하의 의견과 의견을 듣고 싶습니다.

팀에서 비 기능 테스트를 어떻게 처리합니까? 그리고 항상 그렇듯이 동의하거나 동의하지 않거나 여기에서 진행되는 일에 추가 할 사항이 있으면 알려주십시오.

추천 도서

• 기능 테스트 대 비 기능 테스트
• 알파 테스트 및 베타 테스트 (전체 가이드)
• 웹 애플리케이션 보안 테스트 가이드
• 유형 및 예가 포함 된 완전한 기능 테스트 가이드
• 빌드 검증 테스트 (BVT 테스트) 전체 가이드
• 최고의 소프트웨어 테스트 도구 2021 (QA 테스트 자동화 도구)
• 웹 애플리케이션 침투 테스트에 대한 초보자 가이드
• 초보자를위한 부하 테스트 전체 가이드