SW Testing (소프트웨어 테스트 이론)

SW Testing(소프트웨어 테스트 이론)

테스팅 목적

결함 발견, 예방, 품질확보, 합리적인 의사결정을 위한 정보를 제공하기 위함

Defect가 검출되지 않고 문제를 일으키면 Failure가 됨

 

Test Oracle

기존 사용하던 System, Test basis, 요구사항, 전문가 의견 등 Test Actual Result와 비교하기 위한 Expected Result의 근거가 되는 정보들(예상 결과를 유추하기 위한 참값)

 

Test Basis 

테스트 분석작업과 케이스 작성을 위해 필요한 정보들

Test Basis로부터 Feature sets을 추출

 

Test Procedures

Test Suites에 있는 TC들을 수행하기 쉽게 순서들을 재배치(시간이 적게 들어가게 배치)

사용자의 행동패턴을 반영하면 Test Scenario

Test Conditions -> Test Coverage items -> Test Cases -> Test Suites -> Test Procedures -> Test Scenario

 

Waterfall model

Requirements(요구사항 명세) -> Specification(논리적 명세) -> Design -> Code -> Test

Test가 뒤에 있어서 허술해지거나 Test에서 문제가 생기면 처음으로 돌아가거나 하는 문제점이 생겨서 V-model 등장

 

V-Model 

Uni Testing(Code) -> Integration Testing(Design) -> System Testing(Specification) -> Acceptance Testing(Requirements)

각각에 매칭되는 상황에서 TC를 구현함

 

Verification

이전 단계에 산출물이 있는 내용이 현재 단계에 만들고 있는 산출물에 반영이 되어 있는지? = 요구사항을 반영하여 제품을 개발하고 있는가? = Are we building the product RIGHT? (제품을 올바르게 만들고 있는가?)

  

Validation

정말 고객들이 원하는 것인가? = Are we building the RIGHT product? (올바른 제품을 만들고 있는가?)

 

Test Level별 특징

	Unit Testing	Integration Testing	System Testing	Acceptance Testing
Object	Unit 내 결함제거	통합적 결함 제거	전체 시스템 기능상 결함제거 및 비기능적 요소 확인	요구사항과의 일치 여부 확인
Executor	개발자 or 팀내 SDET	개발자 or 독립적 SDET	독립적 Tester	사용자
Test Environment	개발환경	개발환경	실제 환경과 유사한 테스트환경	실사용 환경
Non-Functional Testing	Resource Utilization Testing (Resource leak, Buffer Overflow)	Performance Efficiency Testing, Interoperability Testing	ISO/IEC 25010의 제품 품질 특성	-

 

Functional Testing 

SW의 기능 품질 특성에 대한 테스팅

시스템이 무엇을 수행하는가를 테스팅(What)

명세기반 기법을 주로 사용

 

Non-Functional Testing

SW의 비기능 품질 특성에 대한 테스팅

시스템이 어떻게 동작하는지를 테스팅

ISO/IEC 25010을 주로 참조 (ISO/IEC 9126의 개정버전)

 

Structural Testing

SW나 시스템의 구조에 대한 테스팅

구조기반 기법을 주로 사용

커버리지를 평가하여 테스팅의 수행정도를 측정

 

Re-Testing/ Confirmation Testing

변경사항과 관련한 테스팅

새 버전의 SW에서 이전의 결함이 고쳐졌는지 확인하는 테스팅

 

Regression Testing

변경사항과 관련한 테스팅

SW가 변경된 후에도 정상적으로 동작하는지 확인하기 위한 테스팅

SW가 동작하는 환경(OS Upgrade)이 변경되어도 수행

수행 범위는 Risk를 기준으로 정함 (Impact * Likelihood)

 

Pre-Testing (Smoke Testing)

테스트가 가능한지에 대한 여부를 판단하기 위한 테스트

Testability를 평가

테스트 팀이 주체가 되고 TC가 없이 수행할 수 있음

 

Sanity Testing

기본 동작에 이상이 없는지를 점검하기 위한 테스트

Testability 평가

개발팀이 주체가 되고 TC가 없이 수행할 수 있음

 

Dynamic Testing

코드를 실행하며 시스템의 기능 뿐 아니라 메모리/CPU의 사용 및 성능 등 비기능에 대한 테스팅을 수행

모든 테스트 레벨에서 수행

Functional, Non-functional 모두 포함

결함을 찾아 수정하기 위한 활동

문제점을 찾아 수정하는 비용이 상대적으로 높음

수행하기 위한 TC가 필요함

  

Static Testing

리뷰와 정적분석이 존재함

Informal Review, Walkthrough, Technical Review, Inspection, Static code review

결함을 예방하기 위한 활동

문제점을 찾아 수정하는 비용이 상대적으로 낮음

리뷰를 위한 프로세스와 체크리스트가 필요함

 

Equivalence Partitioning

동일한 결과를 발생하는 Input 값들을 Equivalence Partition으로 정의

 

Boundary Value Analysis

중간값보다는 극단값에서 오류가 발생할 확률이 높다는 점을 감안하여 TC를 설계하는 방법임

일반적으로 해당 경계값, 경계보다 작은 값, 경계보다 큰 값을 선정

 

All Combinations Testing

가능한 모든 조합을 테스트

효과적이지만 비효율적임 -> Combinatorial Testing(Pair-wise가 대표적): Test Condition을 모두 포함하면서 All Combinations Testing보다 적은 수의 TC를 체계적으로 도출할 수 있는 기법들을 제공

 

Pair-wise Testing

N개의 파라미터에 대해 N-wise 기법