[소프트웨어 공학] 10. 테스팅 추가

 

 

 

검토, 확인

 

개정판에서 검증 -> 검토로 바뀌었다

 

 

- 검토 verification

    이게 리뷰다

    올바르게 하고 있는가?

    과정을 전부 검토

 

- 확인 validation

    이건 결과물에 대한 확인

 

   

 

 

테스트 기초

 

용어로 4가지가 있다

- 버그

   문제, 결함을 나타내는 일반적인 용어

 

- 오류

    개발자가 잘못하여 설계나 코딩에 실수한 것

    EX) 오버플로우를 고려하지 않고 설계한 것

 

- 결함

    시스템이 고장을 일으키게 하는 오류의 결과

 

- 고장

    시스템이 원하는 작업을 수행할 수 없는 상황

 

 

테스트 하네스

 

Test Harness

시스템 일부 기능만 시험하기 위해 소프트웨어에 변경을 가하는 경우이다.

 

 

키워드 기반 테스팅

테스트 자동화 프레임워크의 일종으로

테스트의 각 단계를 설명하는 키워드를 사용한다.

 

 

각 컬럼이 무엇을 뜻하는지 확인!

 

 

블랙박스 테스팅

 

내부 경로에 대한 지식을 보지 않고 테스트 대상의 기능이나 성능을 테스트한다.

 

입력과 출력만을 신경쓰는 것

 

장점

- 테스트를 하기 위한 기술적 배경이 필요하지 않다

- 테스터와 개발자가 독립적으로 개발 가능

- 크고 복잡할때 유용

 

단점

- 지식이 부족할때 테스트를 작성하는게 어려울 수 있음

- 특히 엣지 케이스를 놓칠 수 있음

 

블랙박스 테스팅에 기법으로

동등분할, 경쟁값 분석, 원인 결과 그래프 기법이 있다.

동등 분할 기법

시스템 동작이 같을 것으로 예상되는 입력으로 구성되어 있는 기법이다.

위에서 3개의 그룹으로 나누었으면

3개의 대푯값으로 테스트하면 된다는 뜻이다.

 

경곗값 분석

 

엣지케이스에 중점을 두는 분석이다.

 

 

그림처럼 변수 1개일때

경곗값 min, max 기준으로 경계, 경계-1, 경계+1을 테스트 해보는것 - 6개

 

만약 변수가 2개 이상일때는 테스팅 변수 제외 나머지 변수는 정상값으로 고정시켜야 하기 떄문에

변수의 개수를 n개라고 하면 6n+1개 라고 일반화 할 수 있다.

 

원인과 결과 그래프

 

입력 조건의 조합을 선택하는 텍스트 기법

 

 

이 그래프로 결정테이블을 그릴 수 있는데

don't care가 추가 되었다

위에서 E1은 C3, C4와 관계가 없으니 don't care (X)

 

 

 

화이트박스 테스트

 

블랙박스 테스트는 원인과 결과에만 집중했다면,

화이트박스 테스트에서는 모듈안의 작동을 자세히 관찰하는 시험 방법이다.

구조적 테스트라고도 한다.

문장 커버리지

각 코드의 라인이 적어도 한번 실행되는지 검증

올바른 로직만 실행되는지 테스트하기 때문에 충분하지 않다.

 

a=50, b=60 일때를 테스트 하면

각각 yes, yes를 타면서 라인별 로직이 실행이 되지만

c<100일때, A<45일때 어떻게 처리되는지 알 수 없다

 

그래서 사용하는 것이 분기 커버리지

 

분기 커버리지

IF문 안에서 이루어진다.

true, false 두가지 분기가 한번 이상 실행되는지 확인한다.

 

모든 조건이 true, false일때를 말하는 것 같다

즉 A = 50, B = 60

A = 30, B = 30인 2가지 테스트 케이스가 나온다

 

경로 커버리지

모든 실행 경로를 테스트한다.

 

지금 if문이 2개니까 2*2 -> 4가지 경우가 나온다

A= 50, B = 60

A = 55, B = 45

A = 40, B = 65

A = 30, B = 30

 

루프 테스트

 

현실적으로 경로 커버리지는 사용하기 어렵기 때문에 나온 기법

 

- 단순 반복문 테스트

- 중첩된 반복문 테스트

- 연속된 반복

- 비구조적 반복

 

 

 

 

상태기반 테스트

 

같은 입력에 대해 언제나 같은 동작을 보이고 동일한 결과를 생성하는 프로그램을

-> stateless 프로그램이라고 한다.

 

하지만 동일한 입력에 대해 시간에 따라 다르게 동작하고 다른 결과를 출력하는 프로그램도 존재한다

이는 상태때문이다.

예를 들어 과거의 상태가 데이터베이스나 파일에 저장되어 시스템 동작 제어에 사용된다.

이런 시스템을 위한 테스트 케이스 선택 방법이 상태 기반 테스트이다.

 

 

 

상태 모델

 

위와 같은 프로그램에서 무한히 많은 상태를 표현하기 위해

상태 집합을 표현해야하는데

이를 위해 상태 모델을 구축한다.

 

구성요소는

- 상태

    과거 입력에 대한 영향

- 트랜지션

    어떻게 변하는지?

- 이벤트

    입력

- 액션

    출력

 

 

상태 기반 테스팅

 

 

먼저 상태 모델을 만든다

예시로

 

 

이걸 기반으로 테스트 케이스를 선택해야 하는데 방법은 주로 3가지가 있다

 

- 모든 트랜지션

    모든 트랜지션을 점검

- 모든 트랜지션 쌍

     모든 이웃 트랜지션의 쌍을 점검하는 것.

     예를 들어 a->b b->c 관계가 있다면 이 모든 관계를 점검하는 것

- 트랜지션 트리

     모든 단순 경로를 만족시키는 기준이다.

     즉 시작 상태에서 출발해 다른 상태로 중복되지 않고 방문될 수 있는 경로를 말한다

 

 

 

 

통합 테스트

 

각 개발자들이 만든 모듈들의 결합을 테스트하는 것이다.

 

모듈 결합 순서에 따라 분류할 수 있는데

- 빅뱅 통합

    모듈을 따로 구현하고 전체 시스템을 단번에 묶어 테스트

    다른 테스트는 모두 점증적으로 통합한다

 

- 하향식 통합

    (최상위 모듈)명령어 처리 모듈을 먼저 구현하고 시험한다

    다음 단계의 모듈이 구현, 시험 완료되었으면 추가한다

    

- 상향식 통합

    상위 모듈을 더하면서 전체 시스템을 통합

 

- 연쇄식 통합

    특수하고 중요한 기능을 수행하는 최소 모듈 집합을 먼저 구현

    보조적인 기능의 모듈은 나중에 구현하고 테스트, 계속 추가

 

 

자세하게 살펴보면

빅뱅 통합

한번에 모든 모듈을 모아 통합

장점

- 일정에 대한 관리가 편하다

- 통합을 위해 스텁을 구축할 필요가 없다

 

 

하향식 통합

 

 

최상위 모듈부터 드라이버와 스텁을 작성한 후 통과되면 스텁을 대상 모듈로 교체하는 방식

 

장점으로

- 점증적이기 때문에 하드웨어 사용이 분산되고 오류 원인을 찾기 쉽다

- 스텁을 사용하니 시스템 모습을 사용자에게 빠르게 보여줄 수 있다

 

단점

- 입출력을 담당하는 모듈이 대부분 최하위에 존재하므로 테스트에 어려움이 있다

- 최하위층이 중요한 기능을 담당하는데 충분한 테스트가 어렵다

 

 

심리적 측면을 고려했을때는

-> 하향식이 좋다고 한다. 시스템에 대한 확증을 계속 유지할 수 있기 때문

 

 

 

 

 

상향식 통합

 

최하위 모듈을 먼저 통합

그렇기 때문에 스텁이 필요 없다

다만 드라이버는 필요

 

장점

- 하드웨어 사용을 분산

 

단점

- 뼈대가 갖추어지지 않아 상위층의 중요한 인터페이스를 확인할 수 없다

- 상위층 시스템 골격이 상대적으로 적게 반복되어 테스트를 충분히 하지 못한다

 

연쇄식 통합

특정 기능을 수행하는 모듈의 최소 단위 (Thread)부터 시작하며

상대적으로 중요한 모듈부터 개발한다

 

 

 

시스템 및 인수 테스트

 

단위 테스트, 통합 테스트를 통해 개별 컴포넌트끼리 인터페이스 오류에 초점을 두었다면

 

통합 후에는 시스템 테스트 기법으로 전체 시스템이

기능적 요구, 비 기능적 요구를 잘 만족하는지 확인한다.

 

기능 테스트, 성능 테스트, 보안 테스트, 사용성 테스트, 인수 테스트, 설치 테스트가 있다

 

기능 테스트

요구 테스트라고도 부른다

 

기능적 요구와 시스템의 차이를 발견한다

블랙박스 기법 사용

 

 

성능 테스트

 

여러 시스템의 측면

- 작업 부하 workload

- 작업량 throughput

- 반응 시간 response time

- 효율성

- 자원 효율성

등을 평가하기 위한 목적이 있다.

 

테스트 방법으로

- 스트레스 테스트

    처리 설계의 몇배 부하를 견딜 수 있는지 확인

    

- 시뮬레이션

     현실 세계 동작과 비슷하게 어떻게 반응하는지 확인

     프로파일링 기법이 있다

 

 

보안 테스트

 

의도하지 않는 기능과 동작

시스템의 보안 약점을 이용할 수 있는 시스템의 취약점을 찾아내려는 목적

 

- 정적 분석

    테스트 케이스를 생성할때 화이트 박스 테스트를 적용할 수 있음

    원시 코드를 분석해 취약 패턴을 찾아냄

 

- 침입 테스트

    이걸 하는 이유는 정적 분석 도구가 취약점이 아님에도 취약점으로 잡아내는 잘못된 경우 때문

    시스템을 공격하기 위한 악의적인 입력을 제공하는데 도움이 된다고 나와 있는 것으로 보아

    이건 블랙박스 테스팅인 것 같다

 

- 랜덤 테스트

    무작위로 입력값을 주는 랜덤 테스트를 사용한다

    조금 변화시킨 것으로 입력 퍼징 input fuzzing이 있다고 한다 (정상적인 입력을 약간 변형해 시스템을 테스트)

 

 

UI 테스트

인간 공학적인 결함을 발견하기 위한 테스트

 

당연히 완전하게 자동화는 힘들다

 

인수 테스트

 

시스템을 당장 사용할 수 있는지 모든 준비가 되어 있는지를 보이는 것

개발자가 하지 않고 개발을 의뢰한 사람이나 대리인이 한다고 한다.

 

대부분의 테스트와 비슷하지만 실제 사용할 하드웨어나 소프트웨어를 기반으로 테스트를 진행한다는 점이 다르다

 

결국 개발한 사람이 시스템을 사용할 준비가 되었다는 것을 확인 시켜주는 작업이다.

 

 

시스템 요구 분석서를 기반으로 테스트를 진행하며 불특정 다수의 사용자를 위한 인수 시험으로 2가지가 있다

 

- 알파 테스트

    선택된 사용자가 개발 환경에서 테스트 하는것

    개발자가 함께 모니터링하며 오류, 문제점을 기록한다

 

- 베타 테스트

    고객 사용 환경에서 테스트 하는 것

    개발자 없이 설치, 테스트를 진행하며 고객이 모든 문제를 기록

    그 후 개발자에게 보고하도록 제품 평가서를 작성