왜 소프트웨어 테스팅은 어려울까?

sw 테스팅의 문제점

- 가능한 행동들의 세트"만" 샘플한다

- sw 시스템들은 불연속(discontinuous)적이다

- 테스트를 한 케이스에서 하지 않은 케이스를 추론할 만한 우수한 근거가 없다

- 그러므로, 시스템의 모든 가능한 경우의 수를 고려해야한다

- 작은 시스템들마저도 무수한 가능한 경우들이 있다

 

---

 

 

The Zune Killer

'1980년도부터 몇 일' 에서 '1980년도부터 몇 년 + 몇 일'로 코드를 바꾸어보자

 

year = ORIGINYEAR;   // = 1980
while (days > 365) {
    if (IsLeapYear(year)) {      // 윤년
        if (days > 366) {
            days -= 366;
            year += 1;
        }
    } else {
        days -= 365;
        year += 1;
    }
}

 

if (days > 366) {

윤년일 경우는 366일, 이 경우 while로 인해 무한반복이 되어버림

→ if (days >= 366)

 

 

---

 

 

이 버그를 찾으려면 무엇이 필요할까?

1. 날(day)과 년(year)의 구성에 관한 지식

2. 프로그래머들의 실수가 어디서 나는지에 대한 지식

- 경계 조건(Boundary Conditions)

- 복잡한 불 연산식(Complex Boolean Expressions)

3. "도움되는 적수"처럼 생각하자 → "어떻게 이 걸 break할 수 있을까?" 

 

테스트를 잘 하려면,

★ 필요 조건(requirements)들을 조사할 것!  →  블랙박스 테스팅

☆ 코드를 조사할 것!  →  화이트박스 테스팅

 

 

---

 

 

블랙박스 테스팅

명세 기반 기법(or 입출력 테스팅)과 경험 기반 기법 포함

테스트 대상 내부 구조(코드) 참조 X → 테스트 베이시스, 개발자와 테스터, 유저 경험 바탕

기능적 또는 비기능적 테스트 케이스 도출, 선택

기능이 오류없이 작동하고 명세(Specification)에 맞게 작동하는지를 시험 → 기능 테스팅

 

명세 기반 기법

개발 산출물(요구사항 정의서, 제품 백로그, 프로그램 스펙, 사용자 메뉴얼 등)을

토대로 제품이 구현되었는지 검증(verification)

구현된 제품의 기능의 품질 및 사용상에 문제가 없는지 확인(validation)

해결할 문제를 명세화하기 위해 공식적, 비공식적 모델 사용

모델에서 테스트케이스를 시스템적으로 도출 가능

커버리지 측정 가능 BUT, 구조기반기법의 커버리지에 비해 제한적

 

경험 기반 기법

테스트 관련 인력의 지식 / 경험  → 테스트케이스 도출

 

 

화이트박스 테스팅

구조 기반 기법, 소프트 내부를 보고 필요한 정보 사용 (Glass-Box Testing)

컴포넌트(단위) 또는 소프트웨어(시스템)의 구조(코드)를 중심으로 케이스 도출 → 유닛테스팅

 

구조 기반 기법

코드와 개발 설계 등의 소프트웨어 구현 정보를 기반으로 테스트 케이스 도출

수행된 테스트 케이스를 바탕으로 테스트 커버리지 측정 가능

커버리지를 높이기 위해 테스트 케이스를 시스템적으로 도출

단점: 명세서에 있으나 제품에 구현되지 않은 부분

또는 명세서에서 요구한 대로 구현되지 않은 부분을

찾는 것은 불가능하거나 어려움

 

 

---

 

 

테스팅을 멀리서 보자

 

범위

- 유닛 테스트: 개개의 클래스, 함수(Function), 메소드에 대한 테스트 → 의존도(dependency) 체크 (※버그방지)

- 통합 테스트(Integration tests): 패키지/하위시스템(subsystems) 테스트, 서로 다른 시스템(DB, API)들의 상호작용 테스트 

- 시스템 테스트: 시스템 전체 테스트 (※ 웹, 서비스 세계에서 시스템의 개념은 매우 유동적!)

프로세스

- 전 테스트(Test first): 테스트 주도 개발(TDD) → 코드 전에 테스트 작성, 테스트를 통과할 수 있는 코드 작성

- 후 테스트(Test after): 작성된 코드가 테스트를 통과하는지 확인, TDD도 후에 테스트하는 경우가 대부분 많음(refactoring)

- 반복(Iteration): 전이든 후든, 다시 테스팅(re-testing)을 하게 될 것

 

목적

기능성 테스팅(Functional Testing), 퍼포먼스 테스팅, 보안 테스팅,

사용성 테스팅(Usuability Testing), 접근성 테스팅(Availability Testing)