합격 시험과 기능 시험의 차이점은 무엇입니까?


답변:


172

우리 세상에서는 다음과 같은 용어를 사용합니다.

기능 테스트 : 이것은 검증 활동입니다. 제대로 작동하는 제품을 만들었습니까? 소프트웨어가 비즈니스 요구 사항을 충족합니까?

이러한 유형의 테스트에는 해당 시나리오가 "실제로 존재하지 않을"가능성이있을지라도 생각할 수있는 모든 시나리오를 다루는 테스트 사례가 있습니다. 이러한 유형의 테스트를 수행 할 때 최대한의 코드 적용 범위를 목표로합니다. 우리는 당시에 파악할 수있는 모든 테스트 환경을 사용합니다. 사용 가능한 한 "생산"수준 일 필요는 없습니다.

수락 테스트 : 이것은 검증 활동입니다. 우리는 올바른 것을 만들었습니까? 이것이 고객에게 실제로 필요한 것입니까?

일반적으로 고객과의 협력 또는 내부 고객 대행사 (제품 소유자)가 수행합니다. 이러한 유형의 테스트에는 소프트웨어가 사용될 것으로 예상되는 일반적인 시나리오를 다루는 테스트 사례를 사용합니다. 이 테스트는 "생산 방식"환경, 고객이 사용하는 것과 같거나 가까운 하드웨어에서 수행해야합니다. 이것은 우리가 "유일성"을 시험 할 때입니다.

  • 신뢰성, 가용성 : 스트레스 테스트를 통해 검증되었습니다.

  • 확장 성 :로드 테스트를 통해 검증되었습니다.

  • 사용성 : 고객에게 검사 및 데모를 통해 검증되었습니다. UI가 원하는대로 구성되어 있습니까? 고객 브랜딩을 모든 올바른 장소에 배치 했습니까? 그들이 요청한 모든 필드 / 스크린이 있습니까?

  • 보안 (일명 보안 성) : 데모를 통해 검증됩니다. 때로는 고객이 외부 회사를 고용하여 보안 감사 및 / 또는 침입 테스트를 수행하기도합니다.

  • 유지 관리 성 : 소프트웨어 업데이트 / 패치 제공 방법을 시연하여 검증되었습니다.

  • 구성 성 : 고객이 필요에 맞게 시스템을 수정하는 방법을 시연하여 검증합니다.

이것은 결코 표준이 아니며, 여기에 상충되는 답변이 보여주는 것처럼 "표준"정의가 없다고 생각합니다. 조직에서 가장 중요한 것은 이러한 용어를 정확하게 정의하고 준수하는 것입니다.


좋은 대답과 "일명, 보안 성, 딱 맞습니다"에 대해 1 더하기 :). 웃긴 일 :) 그래서 팀은 현실 세계에서 누군가가 + 기호를 실제 단어로 바꿀 수 있다는 사실을 고려하지 않았습니다. 따라서 주석에서 +1을 첫 단어로 입력 할 수는 없지만 "plus 1"은 허용합니다. :) 그래서 기능적으로, 그들은 이것을 올바르게 테스트하지 못했습니다 :). Myabe 그들은 방금 합격 테스트를 시도했습니다 :)
Geo C.

71

Patrick Cuff의 답변이 마음에 듭니다. 내가 추가하고 싶은 것은 테스트 레벨테스트 유형 이 눈에 띄는 것입니다.

테스트 레벨

테스트 레벨V 모델을 사용하여 쉽게 설명 할 수 있습니다 (예 : 여기에 이미지 설명을 입력하십시오테스트 레벨 에는 해당 개발 레벨이 있음) . 일반적인 시간 특성이 있으며 개발 수명주기의 특정 단계에서 실행됩니다.

  1. 구성 요소 / 장치 테스트 => 상세 설계 검증
  2. 구성 요소 / 장치 통합 테스트 => 글로벌 디자인 검증
  3. 시스템 테스트 => 시스템 요구 사항 확인
  4. 시스템 통합 테스트 => 시스템 요구 사항 확인
  5. 승인 테스트 => 사용자 요구 사항 확인

테스트 유형

시험 유형 은 특정 테스트의 목적에 집중하는 특성이다. 테스트 유형 은 기술적 인 측면 또는 비 기능적인 측면으로 알려진 품질 측면을 강조합니다. 테스트 유형 모든 테스트 수준 에서 실행할 있습니다 . ISO / IEC 25010 : 2011에 언급 된 품질 특성 을 테스트 유형 으로 사용하고 싶습니다 .

  1. 기능 테스트
  2. 신뢰성 테스트
  3. 성능 시험
  4. 작동 성 테스트
  5. 보안 테스트
  6. 호환성 테스트
  7. 유지 보수성 테스트
  8. 전이성 테스트

완료하기 위해. 회귀 테스트 라고도 합니다. 이것은 테스트 레벨테스트 유형 옆에 추가 분류 입니다. 회귀 테스트는 이 제품에서 중요한 무언가를 접촉하기 때문에 반복하려는 테스트입니다. 실제로 각 테스트 수준 에 대해 정의한 테스트의 하위 집합입니다 . 제품에 작은 버그 수정이있는 경우 항상 모든 테스트를 반복 할 시간이 없습니다. 회귀 테스트 는 이에 대한 해답입니다.


2
이것은 "테스트 레벨 테스트 유형 사이의 구별"최선이 질문에 답하고 대부분의 해답이 여기 놓치는 무언가 당신이 맞다는 "아이 오프너"입니다
zmilan

23

차이점은 문제 테스트와 솔루션의 차이점입니다. 소프트웨어는 문제에 대한 해결책이며 둘 다 테스트 할 수 있습니다.

기능 테스트는 소프트웨어가 문제 해결 방법의 범위 내에서 기능을 수행하는지 확인합니다. 이것은 소프트웨어 개발에서 없어서는 안될 부분으로, 공장을 떠나기 전에 대량 생산 된 제품에서 수행되는 테스트와 비슷합니다. 기능 테스트는 제품이 실제로 사용자 (개발자)가 생각하는대로 작동하는지 확인합니다.

승인 테스트는 제품이 실제로 해결 한 문제를 해결하는지 확인합니다. 이는 소프트웨어가 지원하는 작업을 수행하는 등 사용자 (고객)가 수행하는 것이 가장 좋습니다. 소프트웨어가이 실제 테스트를 통과하면 이전 솔루션을 대체 할 수 있습니다. 이 승인 테스트는 특히 익명 고객 (예 : 웹 사이트)이있는 경우 프로덕션 환경에서만 제대로 수행 될 수 있습니다. 따라서 새로운 기능은 며칠 또는 몇 주 후에 만 ​​사용할 수 있습니다.

기능 테스트 -제품을 테스트하고 디자인하거나 빌드 한 특성 (기능, 속도, 오류, 일관성 등)이 있는지 확인하십시오.

승인 테스트 -제품의 맥락에서 제품을 테스트합니다. 여기에는 사람의 상호 작용 (시뮬레이션)이 필요합니다. 테스트는 원래 문제에 원하는 영향을 미칩니다.


9

답은 의견입니다. 나는 많은 프로젝트에서 일했고 testmanager와 issuemanager이고 다양한 역할과 다양한 책의 설명이 다르므로 여기 내 변형이 있습니다.

기능 테스트 : 기능적 관점에서 비즈니스 요구 사항을 가져 와서 모든 것을 훌륭하고 철저하게 테스트합니다.

수락 테스트 : "유료"고객은 자신이 원하는 테스트를 수행하여 제공된 제품을 수락 할 수 있습니다. 고객에 따라 다르지만 이해 관계자가 초기 테스트 단계에서 수행 한 테스트 결과를 검토하고 신뢰하기 때문에 특히 사내 프로젝트 인 경우 테스트는 기능 테스트만큼 철저하지 않습니다.

내가 말했듯이 이것은 내 관점과 경험입니다. 기능 테스트는 체계적이며 수용 테스트는 오히려 업무 부서를 테스트하는 것입니다.


나는이 대답을 좋아한다 :) 그들은 거의 똑같다.
anbanm

1
UAT는 궁극적으로 "유료"고객이 수행합니다. 그러나 대부분의 경우 QA 담당자가 시스템을 중단하고 "유료"고객이 손을 잡기 전에 모든 "작은"항목을 찾기 위해 "좋은"테스트와 "시도"를 수행합니다. 지루한 작업을 반복하기위한 Selenium 자동화는 QA 테스터의 진정한 UAT 테스트와 함께 사용할 수 있지만 모든 예상 브라우저에서 예상되는 모든 기능을 테스트하기 위해 실제 테스트를 반복하지는 않습니다. UAT는 매우 자명하다. 대부분의 기능 테스트 설명은 로봇 및 사전에 대한 것 같습니다.
Tom Stickel

내가 말했듯이 이것은 용어를 해석하는 방법에 대한 나의 경험입니다.
hol

괜찮습니다. 이 모호한 정의를 발견했을 때 나는 단지 "기능 테스트 : 비즈니스 요구 사항을 취하고 기능 관점에서 모든 것을 훌륭하고 능숙하게 테스트합니다"라고 언급했습니다.
Tom Stickel

하하, 이제 이해합니다. 좋아, 이것은 당신이 그것에 대한 전체 책을 쓸 수있는 것입니다. 내가 쓴 순간에 너무 많이 들어가고 싶지 않았습니다.
hol

8
  1. 청중. 기능 테스트는 팀 구성원이 소프트웨어를 기대하는대로 수행하는지 확인하는 것입니다. 승인 테스트는 소비자가 자신의 요구를 충족하는지 확인하는 것입니다.

  2. 범위. 기능 테스트는 한 번에 한 구성 요소의 기능 만 테스트합니다. 수락 테스트는 소프트웨어를 수락하기 전에 테스트하기에 충분한 소비자에게 중요한 제품의 모든 측면 (즉, 수락 가능성을 결정하기 위해 테스트하는 데 시간이나 돈이들 수있는 모든 것)을 포함합니다.

소프트웨어는 기능 테스트, 통합 테스트 및 시스템 테스트를 통과 할 수 있습니다. 고객이 기능이 요구 사항을 충족하지 못한다는 사실을 발견 한 경우에만 승인 테스트에 실패합니다. 이것은 일반적으로 누군가가 사양을 망쳤다는 것을 의미합니다. 소프트웨어는 일부 기능 테스트에 실패 할 수 있지만 고객이 소프트웨어가 수용해야하는 핵심 기능을 수행하는 한 일부 기능 버그를 기꺼이 처리 할 수 ​​있기 때문에 승인 테스트를 통과 할 수 있습니다 (베타 소프트웨어는 종종 사용자의 하위 집합에 의해 수용되기도합니다) 완전히 작동합니다).


2

기능 테스트 : 최종 프로그램 구조와 상관없이 지정된 기능 요구 사항에서 파생 된 테스트 데이터 적용. 블랙 박스 테스트라고도합니다.

수락 테스트 : 시스템이 승인 기준을 충족하는지 여부를 확인하기 위해 수행되는 공식 테스트 – 최종 사용자가 시스템을 수락할지 여부를 결정할 수 있습니다.


1

내 견해로는 주된 차이점은 누가 테스트 성공 또는 실패 여부를 말합니다.

기능 테스트는 시스템이 사전 정의 된 요구 사항을 충족하는지 테스트합니다. 시스템 개발을 담당하는 사람들이 수행하고 점검합니다.

수락 테스트는 사용자에 의해 서명됩니다. 이상적으로 사용자는 테스트하고자하는 것을 말하지만 실제로 사용자가 충분한 시간을 투자하지 않기 때문에 기능 테스트의 일몰이 될 수 있습니다. 이보기는 다른 사용자 집합을 다루는 비즈니스 사용자의 정보입니다 (예 : 항공 및 기타 안전 중요도에는 이러한 차이가 없을 수 있음)


승인 테스트는 시스템이 주어진 사용 사례 또는 상상할 수있는 모든 사용 사례의 승인 기준을 충족시키는 지 여부를 결정합니다. 일반적으로 전문가 사용자가 시스템의 사용 가능 여부를 결정합니다. 항공에서 시험 조종사는 특정 기동을 통해 새 항공기를 시험하는 비행사입니다. 최고의 조종사, 항해사 및 엔지니어는 비행 테스트를 수행하고 테스트 임무가 끝나면 평가 및 인증 데이터를 제공합니다.
jjpcondor

1

수락 테스트 :

... 배송 전에 시스템 (예 : 소프트웨어, 제조 된 많은 기계 부품 또는 화학 제품 배치)에서 블랙 박스 테스트를 수행합니다.

이 말을 계속하지만 :

기능 테스트, 블랙 박스 테스트, 릴리스 승인, QA 테스트, 응용 프로그램 테스트, 신뢰도 테스트, 최종 테스트, 유효성 검사 또는 공장 승인 테스트라고도합니다.

"인용 필요"표시와 함께.

기능 테스트 (실제로 시스템 테스트로 리디렉션) :

시스템이 지정된 요구 사항을 준수하는지 평가하기 위해 완전한 통합 시스템에서 수행되었습니다. 시스템 테스트는 블랙 박스 테스트 범위에 속하므로 코드 또는 로직의 내부 디자인에 대한 지식이 필요하지 않습니다.

이 정의에서 그들은 거의 같은 것입니다.

필자의 경험에 따르면 수용 테스트는 일반적으로 기능 테스트의 하위 세트이며 고객이 공식 사인 오프 프로세스에 사용하는 반면 기능 / 시스템 테스트는 개발자 / QA 부서에서 수행하는 테스트입니다.


0

이 둘의 관계 : 합격 테스트에는 일반적으로 기능 테스트가 포함되지만 추가 테스트가 포함될 수 있습니다. 예를 들어 라벨링 / 문서 요구 사항 확인

기능 테스트테스트 대상 제품이 테스트 환경에 배치되어 테스트 대상 장치의 응답을 검사하면서 대상 환경에서 일반적으로 생성하거나 그 이상으로 다양한 자극을 생성 할 수있는 테스트 환경에 배치하는 것입니다.

실제 제품 (소프트웨어 아님)의 경우 두 가지 주요 수락 테스트 ( 디자인 테스트 및 제조 테스트)가 있습니다. 설계 테스트는 일반적으로 제조 테스트를 통과 한 많은 수의 제품 샘플을 사용합니다. 소비자마다 다른 방식으로 디자인을 테스트 할 수 있습니다.

설계가 제품 사양과 비교하여 테스트 될 때 승인 테스트를 확인하고, 제품을 소비자의 실제 환경에 배치 할 때 승인 테스트를 확인이라고합니다.


0

승인 테스트 는 고객이 수행 한 테스트 일 뿐이며 다른 종류의 테스트도 포함됩니다 .

  • 기능 테스트 : "이 버튼이 작동하지 않습니다"
  • 작동하지 않는 테스트 : "이 페이지는 작동하지만 너무 느립니다"

기능 테스트와 비 기능 테스트 (하위 유형)에 대해서는이 SO 질문에 대한 나의 답변을 참조하십시오 .


-1

그들은 같은 것입니다.

승인 테스트는 시스템을 배포하거나 제공하기 전에 실제 프로덕션 / 배포 환경과 최대한 동일하게 완성 된 시스템에서 수행됩니다.

자동 또는 수동으로 수락 테스트를 수행 할 수 있습니다.


1
Selenium 및 Watin (또는 Watir) 등을 사용한 자동화는 매우 중요한 첫 번째 방어선이지만 "시스템 중단"에 설정된 숙련 된 QA 담당자를 능가하는 것은 아닙니다. 자동화는 훌륭하지만 현대적인 AJAX 및 자바 스크립트 프레임 워크 개발을 통해 모든 것을 자동화하기 위해 페이지에서 출력을 변경하는 것은 스크립트 업데이트의 악몽이며, 똑같지는 않습니다
Tom Stickel
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.