본문 바로가기
TIL

D-62 Testing Methods

by 홍차23 2019. 12. 5.

오늘 배운 것>

  1. 테스팅기법
  2. static test
  3. black-box test
  4. white-box test

테스팅이 중요한 이유?

can save tens of millions of dolloars, all test are fully automated -google

developers are measured by their unit test's quality -amazon

developers who specialize in testing -microsoft

=> 문제발생으로 인한 비용절감, 테스팅전문 개발자 및 영역이 따로 있을만큼 중요한 부분!

 

  • Verification_Validation

verification: Are we building the product right?

validation: Are we building the right product? (according to the customer's requirements)

review -> static test

testing -> dynamic test

 

 

  • V-model

단위 테스트(unit test)

: 개발자가 구현한 모듈을 테스트, low-level design 단계의 설계서 상에 정의된 내용을 이용하여 테스트 케이스 생성. 주로 whit-box test 사용

 

통합 테스트(integration test)

: 단위 테스트를 통과한 개발 sw 모듈, 컴포넌트 사이 인터페이스 및 상호 연동 동작 테스트, 제3자 테스터 필요, high-level 단계에서 나오는 설계산출물 정보 이용하여 테스트 데이터 생성

 

시스템 테스트(System test)

: 분석 단계의 요구사항에 따라 시스템이 개발되었는지를 검사. 기능테스트와 비기능테스트

 

인스 테스트(Acceptance test)

: 완성된 시스템이 얼마나 사용자의 요구사항을 만족하였는지 테스트. 알파테스트(개발환경에서 테스트), 베타테스트(사용자 환경에서 테스트)

 

테스트 케이스: 케이스명, 목적, 사전조건, 테스트 데이터, 절차, 예상결과, 환경, 결과, 테스트소요시간/우선순위/비교

 

  • Error, Fault, Failure

Error: 사용자가 만드는 에러. 실수

Fault: 프로그램의 문제. software/hardware fault, bug

Failure: 잘못된 결과. Incorrect result, system crash

 

테스팅을 요구사항문서를 작성할 때 같이 계획해야 최소 레벨3정도는 된다고 한다..테스팅 레벨5중에!

 

리뷰의 종류

 

  • 비공식적 리뷰

-이인일조 프로그래밍에 의한 리뷰, 선택적 문서화, 리뷰어에 따라 성과 좌우, 저렴함.

 

  • 기술적 리뷰 

절차>

킥오프: 문서배포, 리뷰 목표  절차, 문서 설명, 시작 기준 점검.

개별준비

리뷰미팅

재작업

후속처리

 

  • Walkthrough

-(문서/코드)작성자에 의한 진행  제어

-목적: 학습, 시스템에 대한 이해 향상, 결함 발견

 

  • Inspections

-훈련된 리더(moderator) 의한 진행  제어

-공식적인 리뷰 프로세스를 따름, 검토자와 별도로 테스터 역할이 있음.

테스터는 어떻게 테스트할 것인가의 관점을 가지고 인스펙션 참여.

-목적: 결함 발견

 

 

정적 분석(Static Analysis) : Non execution-based test

-특징: 코드를 실행하지 않고 테스트.

설계/코드 메트릭 측정(응집력, 결합력), -타임 오류 가능성 검사(메모리 접근 문제, 초기화된 변수 문제 ). 코드를 직접 보기보다 자동화된 도구로 오류 검사(Code inspector )

설계 검증을 위한 품질 측정 도구는 simulink

 

 

*SW 설계 품질 측정

-설계 가이드라인

-설계 메트릭

) 효율성->   이내 반응과 같은 기준을 만든다.

계층적 구조: 함수 호출 계층(depth) ) 5까지만 들어가도록 한다.

서브시스템 개수

블록 개수

인터페이스 사이즈

복잡도: 사이클이 형성되는지 여부

 

 

*SW 코드 품질 측정

가이드라인: MISRA-C 2012 Category

 

 

*코드 메트릭 

Complexity : 함수 분기 여부

McCabe’s metric

 

Cyclomatic complexity - number of independent paths through a program (사이클이 형성되는지)

L = number of edges

N = number of nodes

P = number of disconnected parts

 

V(G) = L - N + 2P

 

-> 자동화해주는 도구

함수호출관계 분석.

함수별 복잡도를 표현.

  

 

*런-타임 오류 가능성 검사

: 시스템 실행 전에 소프트웨어 도구로 결함 찾아내기

유형>

초기화 문제-초기화되지 않은 변수, 포인터 사용

변수 및 배열 범위 오류-overflow, out of bound array index

수식 연산 오류-0으로 나누기, 음수를 루트화한 것

잘못된 값의 반환

무한 루프

수행되지 않는 문장

 

문제점>

모든 RTE 검출은 불가능.

False Alarm

 

 

포인트>>

-리뷰 타입 구분

-정적 분석의 특징

 

 

Black-box test(Specification-based test)

 

최종 산출물이 나오고, 기능이 제대로 동작하는지 검사.

무엇을 기반으로?

요구사항문서를 기반으로 함.

코드의 내용은 보지 않고, 입력 값에 대한 프로그램 실행 결과가 올바른 출력인지 테스트.

 

종류>

-equivalence partitioning

-boundary value analysis

-pair-wise test

 

 

  • 동치분할 equivalence partitioning

-프로그램의 입력 데이터를 여러 부류로 분류하여, 각각의 대표값을 설정하여 테스트.

유효한 입력 데이터: 들어갈 수 있는 것.

유효하지 않은 입력 데이터: 입력되지 말아야 할 값.

 

단점은 주관적인 분할.

 

 

  • 경계값 분석 boundary value analysis

 

 

  • 결정 테이블

입력값이 다양하거나, 입력값들이 논리적 관계를 갖는 경우 테이블화하여 체계적으로 분석.

if) 5개요소라면 2^5 만큼의 테스트 케이스 존재.

 

 

  • 상태 기반 테스트

상태도의 state(상태), transition(전이), (이벤트, 조건, 액션)을 커버하는 테스트.

-state coverage: execute every state (node coverage)

-transition coverage: execute every transition (edge coverage)

-transition-pair: execute pairs of transition (edge-pair coverage)

 

 

  • Pair-wise 조합 테스트

입력조건에 대한 모든 조합을 테스트.

2개 이상 요소의 상호작용에 의한 테스트.

 

 

White-box test

모든 코드를 알고 있다고 가정하고 테스트 수행.

Structure based

  • Code-coverage based test (statement coverage(실제 소스코드가 얼마나 실행되었는지), branch coverage(분기문 실행 여부), decision coverage, mc/dc coverage(조건문의 decision과 각 condition의 T,F 가 모두 수행되도록 하는 테스트))

 

  • Data-flow test 

: 실행 경로와 함께 변수들의 데이타 흐름을 참고하는 기법

C-use: 변수에 값이 정의된 후 그 변수값을 조건문을 제외한 프로그램 문장에서 사용되도록

P-use: 조건문 문장에서 사용되도록

All-use

 

  • Mutation test

: Fault injection

 

 

실무에서는, 
White-box 라면 mc/dc coverage 를 주로 사용.
Black-box 라면 요구사항 문서를 기반으로 함!

그외 대다수는 경험기반으로 여기에 결함이 많을 것 같다!하는 포인트에서 주로 함.

 

우리 프로젝트에서는 어떤 테스팅을 사용하는 것이 적절할지 고민하며 정리했다. 시험은 내일..🌟 

댓글