노년코딩

4.3.1.5 유즈케이스 테스팅

▶ 유즈케이스 테스팅

 - 액터와 액터 사이의 상호작용을 표현 --> 유저에게 결과값 전달.

 - 시스템(SW)이 유즈케이스로 모델링 되었을 때, 유즈 케이스를 활용해 테스트 케이스를 도출하는 테스트 설계 기법.

   >> 유즈케이스를 어떻게 작성하느냐에 따라 유즈 케이스의 테스트 용이성이 달라짐 --> 잘못 만들면 테스팅하기 어려울 수 있음

 - 프로세스 흐름을 기술

   >> 기본 흐름

   >> 대체 흐름

 - 유즈케이스 상세(description) 

 - 시나리오를 짬

 - 프로세스 흐름 기술

 - 유즈케이스를 통해 생성된 테스트 케이스를 통해 시스템이 실제 사용되는 프로세스 흐름에서 결함을 발견하는 데 유용.

 - 고객이나 유저 그룹을 참여시키는 인수 테스트를 설계할 때 유용.

 - 통합 테스트 단계에서 컴포넌트 사이의 통합 결함을 찾는데 도움.

▶ 테스트 순서

 - 유즈케이스 상세를 문장별로 분석하여 테스트 케이스 도출 -- > 누락을 최소화하고 일정 수준의 보장성을 확보

1.  어떤 흐름을 테스트 할지 고려하여 테스트 시나리오 구성
2.  유즈케이스 상세에서 테스트에 필수적인 상황 선택
3.  유즈케이스 상세 내용을 입력값, 출력값, 상황 처리 등으로 분류하여 테스팅에 관여하는 상황을 선택.
4.  각각의 상황에 ID 부여
5.  각각의 상황에 가능한 값을 결정

▶ 컴포넌트(단위) 레벨 유즈케이스 테스팅

 - 유즈케이스 각각을 테스팅하는 방법

▶ 시스템 레벨 유즈케이스 테스팅

 - 유즈케이스 상호 간의 활동을 테스트

 - 상태관점에서 파악하고 활동의 흐름을 전이로 간주하여 상태 전이 테스팅 기법의 컨셉을 활용.

   >> 활동 기반 커버리지 : 각각의 활동만을 테스팅

   >> 전이 기반 커버리지 : 활동의 흐름을 테스팅

   >> 경로 기반 커버리지 : 재귀적인 흐름도 고려한 테스팅

   >> 활동 기반 ⊂ 전이 기반 ⊂ 경로 기반 --> 포함관계 존재

4.3.2 구조기반 기법(Structure -based)

▶ 화이트 박스 테스팅 --> 시스템의 구조를 중심으로 테스팅

 - SW코드나 설계 등 구조를 표현하는 정보로부터 테스트 케이스 도출

 - 작성한 테스트 케이스들로부터 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가

   >> 제어 흐름 테스트, 기본 경로 테스트, x커버리지 테스팅

 - 구문 커버리지 (statement coverage)
   >> 테스트 스위트(테스트 케이스 모아둔 거)에 의해 실행된 구문이 몇 퍼센트(%)인지 측정(가장 약함)
 - 결정 커버리지 (decision coverage)
   >> 실행된 결정 포인트 내의 전체 조건식이 최소한 참이 한 번 그리고 거짓이 한 번씩 선택되었는지 측정하여 퍼센트로 표현
 - 조건 커버리지
   >> 전체조건식의 결과와 관계없이 각 개별 조건식이 참 한번, 거짓 한 번을 모두 갖도록 개별조건식을 조합 (결정 커버리지 보다 강력) 

4.3.2.1 구문 테스팅과 커버리지

▶ 구문 커버리지

 - 테스트 스위트에 의해 실행된 구문이 몇 퍼센트 인지 측정

   >> 존재하는 가능한 경우를 모두 검증 못하는 보장성이 낮은 커버리지

 - 구문 테스팅은 구문 커버리지를 늘리기 위해 특정 구문을 테스트하는 테스트 케이스 도출

   >> 코드의 모든 구문을 실행할 수 있는 입력값이나 이벤트 등의 테스트 데이터를 제공해 주면 달성됨.

4.3.2.2 결정 테스팅과 커버리지

▶ 결정 커버리지

 - 분기 테스팅과 관련

 - 테스트 스위트(suite, 묶음)에 의해 실행된 조건문 분기 (if문의 참/거짓)가 전체 가능한 분기의 몇 퍼센트인지를 측정하고 평가

 - 결정 포인트 내의 전체조건식이 참과 거짓의 모든 값을 갖게 되어 모든 분기로 흐르게 되면 달성

▶  결정 테스팅

 - 결정 커버리지를 늘리기 위해 특정 조건문의 분기를 테스트하는 테스트 케이스를 도출하는 것

 - 제어 흐름 테스트

▶ 제어 흐름 테스트

 - 구조 기반 테스트 --> 코드 레벨의 커버리지 개념 필요

 - 프로그램 구조 테스트

 - 공식적인 화이트 박스 테스트 -- > 단위 / 통합 테스트에서 사용

   >> 테스트 깊이 레벨에 따라 강도 존재

   >> 테스트 케이스를 선택된 흐름에 따라 연속적인 구문의 집합으로 기술

   >> 테스트 깊이가 깊을수록 제품의 커버리지는 높아지는 반면 테스트 케이스가 기하급수적으로 많아져 비용, 시간, 리소스 많이 소요됨.

4.3.2.3 조건 테스팅과 커버리지

▶ 조건 커버리지

 - 결정 포인트 내에 있는 개개의 개별 조건식이 참 / 거짓의 모든 값을 갖게 되면 달성

 - 조건 커버리지(강력, 견고한 테스트) > 결정 커버리지

▶ 조건/ 결정 커버리지(응용버전)

 - 항상 결정과 조건 커버리지를 모두 만족시키는 것보다 강력

 - 결정과 조건 커버리지를 최소한 조합으로 달성하는 경우

   >> 항상 모든 개별 조건식이 참이고 이에 따른 전체 조건식이 참인 경우

   >> 모든 개별 조건식이 거짓이면서 이에 다른 전체 조건식이 거짓인 경우

▶ 커버리지 레벨(depth level) - 밑으로 갈수록 완화됨

 - 다중 조건 커버리지(Multiple condition coverage) -- > 가장 강력

   >> 결정 포인트 내의 개별 조건식 결과(참/거짓)에 대한 모든 가능한 논리적인 조합을 적어도 한 번 수행.

 - 변형 조건/ 결정 커버리지(MC/DC)

   >> 결정 포인트 내에 다른 개별 조건식의 결과와는 독립적으로 해당 개별 조건식이 전체 조건식의 결과에 영향을 줌.

 - 조건/ 결정 커버리지 (COndition/ decision coverage)

   >> 모든 개별 조건식이 전체 조건식 판단문의 결과값 확정에 관여하는 경우를 모두 고려함.

 - 조건 커버리지(Condition coverage)

   >> 프로그램 내에 있는 결정 포인트 내의 모든 각 개별 조건식에 대한 모든 가능한 결과(참/ 거짓)에 대해 적어도 한번 수행.

▶ 다중 조건 커버리지

 - 결정 포인트 내에 있는 모든 개별 조건식의 모든 가능한 논리적인 조합을 고려하여 100% 커버리지를 보장

 - 출시 전 모든 결함을 제거해야 하는 제품 테스트에서 주로 사용. 

4.3.2.4 변형 조건/ 결정 커버리지(MC/ DC)

▶ 변형 조건 / 결정 커버리지(Modified Condition/ Decision)

 - 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함

 - 조건/ 결정 커버리지를 향상 시킴

 - 조건 커버리지나 결정 커버리지 보다 강력

   >> 프로그램에 있는 모든 결정 포인트 내의 전체 조건식은 적어도 한 번 모든 가능한 결과값(참, 거짓)을 취한다.

   >> 프로그램에 있는 결정 포인트 내의 모든 개별 조건식은 적어도 한번 모든 가능한 결과값(참,거짓)을 취한다.

   >> 결정 포인트에 있는 각각의 개별 조건식은 다른 개별 조건식에 영향을 받지 않고 그 결정 포인트의 결과값에 독립적으로 영향을 준다.

 - 가능한 의미 있게 조합의 수를 줄여 테스트 수행.

4.3.1.4 상태 전이 테스팅

▶ 상태 전이 테스팅 (state trasition)

 - 이벤트, 액션, 상태, 가드, 상태전이 사이의 관계를 검증.

 - 시스템/SW의 상태 기반 행위가 명세화(글자로 쓰여있던)된 내용과 일치함을 검증.

 - 상태기반 시스템의 결함은 상태, 상태전이, 가드, 이벤트 결함 등으로 분류.

 - "구현이 잘못된 경우"와 "명세가 잘못된 경우"의 결함으로 구분.

 - 모델(명세)상의 결함 -- > 인스펙션, 정적 분석으로 결함 발견.

   >> 초기 상태 누락

   >> 전이 또는 액션의 누락

   >> 가드를 "전이" 대신 상태에 표기

   >> 가드의 중복 또는 불일치

 - 구현상의 결함 -- > 테스트를 통해 결함 발견

   >> 여분/ 누락/ 훼손 상태(extra/ missing/ corrupt state)

   >> 액션이 틀리거나 누락됨

   >> 스니크 패스(sneak paths), 트랩 도어(trap doors)

      - 설계할 때 의도하지 않았으나 발생하여 정상적인 작동에 손상을 주는 경로.

• 상태 다이어그램 표기법

• 상태: [대기], [금액 투입], [음료 선택]
• [대기] 이벤트 : ev 금액투입[투입금액 < 가격], ev 금액투입[투입금액 >= 가격]
• [금액 투입] 이벤트 : ev 취소, ev 금액투입[투입금액 >= 가격], ev 금액투입[투입금액 < 가격]
• [음료 선택] 이벤트 : ev 취소, ev 음료버튼 선택

▶ 상태전이 테스트 케이스 절차

1. 상태-이벤트 테이블 구성
2. 전이 트리 구성
3. 반응(Legal, 또는 유효(Valid)) 테스트 케이스 구성
4. 무반응(Illegal, 또는 비유효(Invalid)) 테스트 케이스 구성
5. 가드(Guard) 또는 조건 테스트 케이스 구성
6. 테스트 프로시저(Test procedure) 구성

자판기로 상태전이 테스트 케이스를 알아보자.

1. 상태-이벤트 테이블

* 동일한 이벤트지만 가드가 다르면, 서로 다른 이벤트로 구분해 상태-이벤트 테이블을 작성한다.

2. 전이 트리 구성

3. 반응(유효) 테스트 케이스

* 음료가격 700원으로 가정

4. 무반응(비유효) 테스트 케이스

불가능한 상황들을 만들어서 테스트를 해보는 것.

5. 가드 테스트 케이스

* 음료가격 700원으로 가정 / 조건에 따라 기대결과가 달라짐.

6. 테스트 프로시저 구성  ( *가능한 겹치지 않으면서 내가 할 수 있는 모든 테스트 케이스를 만들어야 돼. )

• TP1 = V001 -> IV001 -> IV002 -> V002 -> V003 -> V006 -> V007 -> V010
• TP2 = V004 -> IV003 -> V011 -> V005
• TP3 = V008 -> V009 -> V013 -> V016 -> V012
• TP4 = V014 -> V004 -> G001 -> G002
• TP5 = V015 -> IV004 -> IV005

슬슬 한번씩 더 읽어봐야 이해가 되는 부분이 왔다. 그래도 꽤 재밌구만!!

4.1 테스트 설계 및 구현 프로세스

▶ 테스트 설계의 진행 방식
 - 테스트 조직 구성
 - 테스팅과 개발 프로세스의 성숙도
 - 시간 절약
 - 참여인원 등 테스트 정황에 따라 달라짐
▶ 무엇을 테스트할지 결정하기 위해 테스트 베이시스 문서 분석
 - 테스트 베이시스 - 요구사항 명세서, 개발 설계서 등
▶ 테스트 조건
 - 기능, 트랜잭션, 품질 특성 또는 구조적 요소
▶ 테스트 설계 과정
 - 테스트 설계 기법을 이용하여 테스트 케이스와 테스트 데이터를 설계하고 명세화 함
▶ 테스트 케이스
 - 입력 값의 묶음
 - 실행 사전 조건
 - 기대 결과와 실행 사후 조건으로 구성
▶ 테스트 표준 문서
 - 소프트웨어 테스트 문서 표준(IEEE 829)
 - 테스트 설계 명세와 테스트 케이스의 표준 양식 제안
▶ 테스트 용이성 평가

 
▶ 테스트 분석, 설계, 구현

▶ 테스트 케이스
 - 정의
   >> 특정 프로그램 경로의 실행, 구체적인 요구사항과의 일치 여부 확인을 위해 디자인된 입력 값의 묶음.
   >> 실행 사전 조건, 기대 결과와 실행 사후 조건의 집합
   >> 테스트 돼야 하는 Test Condition((상황)을 입력 값과 기대결과로 표현
 - 작성 목적
   >> 요구되는 보장성을 갖는 최소개의(최적의) 테스트 케이스로 가능한 많은 결함을 발견할 수 있도록 정의한 목표 수준의 테스트 보장성 확보

< 테스트 케이스의 목적 >
1. 최소한의 테스트 케이스로 많은 결함을 발견하는 것.
2. 테스트 대상을 가능한 빠짐없이 테스트하여 테스트 보장성을 확보할 수 있도록 설계되어야 함.
3. 공식적 기법과 경험 기반의 비공식적 기법을 모두 이용해야 함.
 - 공식적 기법을 먼저 작성한 후에 비공식적인 기법으로 보완이 필요함.

 
  - 예시 테스트 케이스                                                                                                            결과값, 데이터나 상태 변화

▶ 테스트 케이스 개발 및 작성
 >> 테스트 케이스 개발 시 우선순위 선정 - 테스트 프로시져 명세서(테스트 케이스의 실행 순서) 만듦 - 테스트 실행 스케쥴 작성(테스트 실행도구를 사용하여 테스트를 수행하면 테스트 프로시저는 테스트 스크립트로 기술할 수 있음)
▶ 테스트 수행 절차
 >> 얼마나 상세하게 작성하는 것이 좋을 지 작성해야 함 - 테스터의 스킬, 능력, 해당시스템에 대한 이해를 고려하여 테스트 케이스의 상세함을 조절해야 함.
 >> 만약 외주를 주는 경우는 자주 테스터가 바뀌더라도 작업을 수행할 수 있도록 상세하게 수행 절차를 기록하여야 함.
▶ 테스트 케이스 작성
 >> 테스트 수행 절차를 얼마나 상세하게 작성하는 것이 적절한 지 결정해 주어야 함(테스트 케이스당 7스탭이내로 수행 절차를 작성하는 것이 바람직)
 >> 7스텝이 넘을 경우는 두 개로 분리하여 관리하는 것이 좋음

4.2 테스트 설계 기법의 종류

▶ 블랙박스 기법 VS. 화이트박스 기법

 
▶ 테스트 설계의 근원(Origin)을 기준
 - 명세 기반 기법, 구조 기반 기법, 경험 기반 기법으로 분류

명세가 나오면 블랙박스, 구조가 나오면 화이트박스

4.3.1 명세 기반 기법(Specification - based)

▶ 명세 기반 기법

 - 종류 : 동등 분할, 경계값 분석, 조합 테스팅, 결정 테이블 테스팅, 상태전이 테스팅, 유즈케이스 테스팅.

4.3.1.1 동등 분할

▶ 동등 분할
 - 입력 / 출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대표값을 선택하여 테스트 케이스를 도출하는 방법.
 - 동일한 입력에 대해 항상 동일한 결과를 갖도록 클래스 구분
 - 적용 방법
   >> 주어진 시스템 정보를 분석해 입력/ 출력 영역을 유사한 특징을 가진 클래스로 분할
   >> 분할된 클래스에서 각 클래스를 대표하는 테스트 케이스 도출
   >> 모든 Valid equivalence class(유효)가 커버될 때까지 테스트 케이스 생성
   >> 모든 Invalid equivalence class가 커버될 때까지 테스트 케이스 생성

4.3.1.2 경계값 분석

▶ 경계값 분석
 - 동등 분할의 경계에서 결함이 발견될 확률이 높기 때문에 결함을 예방하기 위해 경계값까지 포함하여 테스트
 - 분할 영역의 최대값과 최소값이 그 영역의 경계값
 - 동등 분할과 마찬가지로 모든 테스트 레벨, 테스트 유형에 적용
 - 동등 분할의 확장으로 여겨지며 동일한 방식으로 커버리지 보장

4.3.1.3 결정 테이블 테스팅

▶ 결정 테이블
 - 시스템의 동작을 결정하는 비즈니스 규칙을 정의하는 방법
 - 입력 값들이 논리적인 관계(Binary Condition - 참과 거짓)를 갖는 경우, 입력 값을 원인 / 결과로 나누어 기술
    -- > 테스트 케이스 작성
 - 구현이나 명세에 잠재된 오류를 찾는 데 효과적으로 이용
▶ 특징
 - 테이블 분석을 통해 중복, 발생 불가능한 상황, 모순이 생기는 상황을 제외시키고 나머지의 결정과 액션 조합
 - 좋은 테스트 데이터 선택을 위해, 경계 값 또는 동등 분할 기법 사용
 - 불가능한 Rule을 식별하는 것은 테스트 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -- > 시스템 설계에 의존적.
▶ 결정 테이블 장단점

3.1.1 리뷰의 이점과 목적

▶ 정적기법
 - SW를 실행하지 않고 테스팅 하는 기법
 - 동적 테스팅과 달리 장애보다는 장애의 원인(결함)을 발견
▶ 리뷰
 - 코드를 포함하여 SW개발 및 테스트 산출물을 검토하고 테스팅 하는 방법.
 - 동적 테스팅 전에 수행 --> 초기 결함의 수정은 비용 절감
 - 대상
   >> 요구사항 명세, 설계 명세, 코드, 테스트 계획, 테스트 명세, 테스트 케이스, 테스트 스크립트, 사용자 가이드, 웹페이지 등 모든 SW개발 및 테스트 산출물.
- 리뷰의 이점
   >> 조기 결함 발견 및 수정
   >> 개발 생산성 향상
   >> 개발 기간 단축
   >> 테스팅 비용 감소 및 시간 단축
   >> 개발 생명 주기 전체에 걸친 비용 감소
   >> 결함 감소(품질 향상)
   >> 커뮤니케이션 향상
 - 리뷰를 통해 발견하기 쉬운 결함
   >> 표준 위반, 요구사항 결함, 개발 설계 결함, 불충분한 유지보수성, 부정확한 인터페이스 명세.
 

3.1.2 리뷰와 테스팅

▶ 최근 테스팅
 - 결함 예방 활동 강조
 - 조기 테스트 설계 -- > 초기에 결함을 줄임
   >> 시스템 명세(요구사항 문서, 설계 기준서)에 대한 테스트 케이스 생성
   >> 요구사항 분석서를 통한 테스트 케이스 -- > 시스템 또는 인수 테스팅에 사용
 - 프로젝트 초기 모든 테스트 케이스 생성은 부적절
 - BUT, 리스크가 높거나 중요한 기능에 한해 테스트 케이스를 도출 하면서 문서를 테스트 -- > 조기 발현 중요.
 

3.2 리뷰 프로세스

▶ 리뷰 목적
 - 결함 발견, 이해도 증진, 합의에 의한 결정과 이를 위한 토론
 - 체계적인 리뷰를 통해 고품질 SW 개발과 비용 절감은 물론 개발 기간 단축의 효과
 - 페이건 스펙션
   >> 초기에 많은 인력, 코딩 단계 부터 인력이 줄게 됨, 품질 비용이 감소하고 개발 기간 단축.
 

3.2.1 공식적 리뷰의 단계

▶ 정적 테스트 활동의 중요성이 높아지고 있음
▶ 정적 테스트 프로세스
 - 정적 테스트 준비 단계
 - 리뷰 / 분석 단계
 - 후속 처리 확인 단계
   >> 비공식적인 리뷰도 일반적인 프로세스를 준수하는 것이 좋음
▶ 공식적 리뷰의 절차
 - 계획 활동 -- > 시작 -- > 개별 준비 -- > 리뷰 미팅 -- > 재작업 -- > 후속 처리 확인

3.2.2 역할과 책임

▶ 역할과 책임
 - 관리자(Manager)
   >>리뷰 진행 결정, 프로젝트 일정에 리뷰 시간 할당, 리뷰의 목적 달성 여부 확인하고 승인
 - 중재자(Moderator)
   >> 리뷰 회의 리드(리뷰 계획, 미팅 진행, 미팅 후속 조치 추적 관리 등)
   >> 다양한 관점을 중재하는 자로 리뷰의 성패를 좌우
 - 저자(Author)
   >> 리뷰 대상 문서(산출물)의 작성자 또는 책임자
 - 검토자(Reviewer) - 테스트 전문가 참여
   >> 리뷰 대상 제품에서 인시턴트를 발견하고 기술할 사람(검사자 또는 인스펙터) - 기술적 또는 비즈니스 배경을 갖춘자
   >> 리뷰어는 다양한 관점과 역할을 대표하도록 선택되어야 함
 - 기록자(Scribe or recorder)
   >> 리뷰 미팅에서 발견된 모든 이슈, 문제점, 미해결점 등을 기록하고 문서화함
▶ 체크리스트 활용
 - 효과적 /효율적인 리뷰를 위해 사용자, 유지보수 담당자, 테스터, 시스템 운영자 등 다양한 관점의 체크리스트 또는 문서 유형별 체크리스트 이용 및 개발 권고
▶ 테스트 케이스 -- > 시간과 노력 많이 필요
 - 변경된 요구사항과 설계 반영을 위해 지속적으로 업데이트 필요  (초반에 다 만들지 않아. 계속해서 업데이트)
 

3.2.3 리뷰의 유형

▶ 리뷰에 리스크 분석을 연계한 사례

 
▶ 워크쓰루(Walkthrough) -- > 이해 향상과 결함 발견
 - 저자(Author: 산출물 작성자)에 의한 진행 및 제어
 - 성격 : 시나리오 사용, 예행 연습(Dry runs), 동료 그룹 검토
 - 시간 및 인원수 등에 제한이 없고 상황에 따라 변경할 수 있는(Open - ended) 세션
 - (선택적) 미팅 전 준비 과정 거침 -- > 역할 지정(검토자, 기록자 등), 리뷰 리포트 준비, 인시던트(조사가 요구되는 이벤트) 목록 준비
 - 실무에서는 비공식적 또는 공식적일 수 있음.
 - 주요 목적 : 학습, 시스템에 대한 이해 향상, 결함 발
▶ 인스펙션(Inspection) --> 결함 발견
 - 저자가 아닌 중재자가 주도적으로 진행 및 제어
 - 주로 동료 검사
 - 역할이 정의되어 있음
 - 메트릭(측정 척도와 방법)을 수집하고 활용함
 - 체크리스트와 규칙을 기반으로 시작과 종료 조건이 있는 정식 프로세스 존재
 - 미팅 전 준비 과정 필요
 - 인스펙션 리포트와 발견 사항(인시턴트(조사가 요구되는 이벤트)) 리스트 산출
 - 정식적인 후속 처리 확인(Follow -up) 프로세스 존재
 - (선택적) 리뷰 프로세스 개선 활동 수행
▶ 인스펙션 대상
 - 모든 개발 산출물과 테스트 산출물
 - 리스크 분석 결과를 활용하여 장애 발생 가능성이 높고 발생한 장애로 인한 영향이 심각할 수 있는 부분을 중심으로 진행
   >> 비즈니스와 연관성이 높거나, 복잡도, 변경율, 결함률이 높은 부분이 이에 해당.
 - 리스크 기반 테스트 전략 -- > 리뷰 강도 조절
▶ 워크쓰루 vs. 인스펙션 
 - 사업적 리스크가 높은 영역 - 워크쓰루
 - 기술적 리스크가 높은 영역 - 인스펙션이나 기술적 리뷰
 

3.2.4 리뷰의 성공 요소

3.3 도구에 의한 정적 분석

- 정적 분석 특징
   >> 정적 분석은 동적 테스팅으로 찾기 힘든 결함을 발견
   >> 리뷰와 마찬가지로 정적분석은 장애보다는 결함을 발견함 > 코드를 돌리기 전에 문제점을 찾아내자!!
   >> 도구의 도움을 받아 수행
   >> 정적 분석 도구는 프로그램 코드를 분석하는 것은 물론, HTML이나 XML과 같이 생성된 결과물도 분석
 - 정적 분석의 가치
   >> 테스트 실행 전 조기 결함 발견
   >> 의심스러운 코드와 설계에 대한 조기 경보(프로그램 복잡도- 메트릭)
   >> 동적 테스팅으로 발견하기 어려운 결함 발견
   >> SW 모델상의 의존도와 불일치성 발견
   >> 코드와 설계의 유지보수성 향상
   >> 결함 예방 가능
 - 정적 분석을 통해 발견될 수 있는 결함
   >> 정의되지 않은 값으로 변수 참조
   >> 모듈과 컴포넌트 간의 일관되지 않은 인터페이스
   >> 사용되지 않는 변수
   >> 사용되지 않는 코드
   >> 코딩 표준 위반
   >> 보안 취약성
   >> 코드와 소프트웨어 모델의 구문 규칙 위반
 - 정적 분석 도구
   >> 기 정의된 규칙이나 코딩표준을 준수하는지 확인하는 용도로 컴포넌트 테스팅과 통합 테스팅 동안에 주로 개발자에 의해 사용.
   >> SW 모델링하는 동안 설계자에 의해 사용.
 
 
 

2.1 소프트웨어 개발 모델

▶ 테스팅 vs. 소프트웨어 개발

 - 서로 밀접하게 연계

 - 개발 수명 주기에 기반하여 테스팅 접근법을 다르게 적용

2.1.1 V-모델(순차적 개발 모델)

▶ 개발 산출물(Work product)

 - 비즈니스 시나리오 또는 유즈 케이스, 요구사항 명세, 설계 문서나 코드 --> 테스트 베이시스(Basis)로 사용

▶ V-모델의 역할

 - 각각의 개발 단계에서 테스팅을 접근하는 방법을 개략적으로 이해하기 쉽게 모델화하여 보여주는 것.

 - V-모델을 통해 테스팅 기본 개념 이해

   >> 테스트 레벨의 의미 이해

   >> 개발 초기 단계에서 테스팅을 수행하다는 것의 의미

   >> 결함 예방 차원에서 테스팅이 의미하는 바 이해

   >> V & V (Verification(검증) and Validation(확인))의 의미 (검증과 확인 구분가능 해야 돼.)

▶ 테스트 레벨의 의미

 - 컴포넌트 / 단위 테스팅, 통합 테스팅, 시스템 테스팅, 인수 테스팅

   >> 테스트 레벨에 따라 테스트 전략, 테스트 기법, 테스트 수행 주체, 테스트 완료 기준 등이 달라짐.

   >> 테스트 레벨은 독립적.

▶ 개발 초기 단계에서 테스팅을 수행하다는 것의 의미

 - 개발 산출물을 리뷰 형태로 검토하면서 결함을 발견하는 정적 테스팅을 의미 (문서만으로 발견)

   >> 결정 테이블 테스팅, 상태전이 테스팅, 유즈 케이스 테스팅 등

 - 개발 초기의 테스팅을 통해서 후반부에서 발생할 비용을 줄임.

▶ 초기에 테스트 설계를 통해 결함을 사전에 예방 ★

2.1.2 반복적 - 검증적 개발 모델

▶ 반복적 & 점진적 개발 모델 

▶ 폭포수 개발 모델 VS. 반복적 & 점진적 개발 모델 

>> 폭포수 모델은 코딩단계까지 리스크가 남아잇기 때문에 거의 쓰지 않아.

>> 반복적 & 점진적 개발 모델이 안정성도 더 높음. -리스크를 처음부터 수정해기 때문.(그대신 초반에 더딤.)

2.1.3 개발 생명 주기 모델에서의 테스팅

▶ 성공적인 테스팅을 위한 조건

   >> 모든 개발 활동은 이에 상응하는 테스트 활동을 동반.

   >> 각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 있음.

   >> 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발 활동 동안에 시작.

   >> 개발 생명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가.

▶ 테스팅 레벨 조절

 - 테스팅은 프로젝트나 시스템 아키텍처의 성격에 따라 재조정하거나 합쳐질 수 있음.

2.2 테스트 레벨(Test Levels)

- 테스트 레벨의 일반적인 구분

   >> 단위, 통합, 시스템, 인수.

▶ 테스트 레벨에 따라 독립적으로 정의할 수 있는 사항

 - 테스트 레벨의 일반적인 목표(목적)

 - 테스트 케이스를 도출해 내는 데 참조되는 개발 산출물(베이시스)

 - 테스트 대상(테스트할 그 무엇)

 - 발견된 전형적인 결함과 장애

 - 테스트 하네스(드라이버/ 스텁) 필요 여부와 툴 지원의 필요성

 - 상세한 테스트 접근법

 - 테스트 수행 주체 또는 조직  

2.2.1 컴포넌트 테스팅

▶ 단위 테스트(Unit Test)

 - 테스트가 가능한 최소 단위로 나누어진 소프트웨어 모듈, 프로그램, 객체, 클래스 등에서 결함을 찾고 그 기능을 검증 ->대부분 개발자가 하는데 본인이 직접 코드 짠 경우 동료 개발자가 함. 

   >> 소프트웨어 각각의 단위를 다른 부분과 연계성을 고려하지 않고 격리해서 독립적으로 테스트 수행.

   >> 스텁, 드라이버, 시뮬레이터 사용.

 - 일반적으로 프로그램 소스코드를 대상 -- > 구조기반(화이트 박스)

 - 컴포넌트 테스트의 일반적인 목적

   >> 기본 경로 확인

   >> 모든 오류 처리 경로 확인

   >> 컴포넌트 내의 인터페이스 확인

   >> 로컬 데이터 확인, 데이터의 경계값 확인

2.2.2 통합 테스팅(Integration testing)

▶ 통합 테스팅

 - 컴포넌트 간에 인터페이스를 테스트하는 것은 물론 OS, 파일 시스템, 하드웨어 또는 시스템 간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트.

 - 컴포넌트 통합 테스트

 - 시스템 통합 테스트

 - 통합 테스팅은 기능적 특성은 물론 비기능적 특성(성능, 연결성 등)을 테스팅 수행.

 - 통합 테스팅 설계는 기능적 접근법, 구조적 접근법을 모두 사용.

   >> 통합 그 자체에만 집중하는 오류 주의!!!!

2.2.3 시스템 테스팅(System testing)

▶ 시스템 테스팅

 - 개발 프로젝트 차원에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트

-- > 리스크 최소화를 위해 실제 환경과 유사한 상태.

 - 시스템 관련 고객의 요구사항이 완벽하게 실행되는지를 테스트.

 - 테스트 베이시스(개발 산출물) 이용.

   >> 리스크 분석서, 요구사항 명세, 비즈니스 프로세스, 유즈 케이스, 기타 비즈니스 레벨의 시스템 동작 명세, os 및 시스템 리소스와 상호작용 명세.

 - 기능 및 비기능 요구사항 모두 검증

   >> 기능적 테스트 : 명세기반(블랙박스) 기법으로 수행 - 문서 기반 테스팅( 테스트 베이시스(개발 산출물) 이용).

   >> 비기능적 테스트 : 기능적 외의 나머지 부분에 대한 요구사항 검증.

 - 일반적으로 독립적인 테스트 팀이 수행 --> 검수 테스팅이라 함 (이후 출시)

2.2.4 인수 테스팅(Acceptance testing)

▶ 인수 테스팅

 - 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 확신을 얻는 것. --> 결함 발견이 목적이 아님. (시스템이 잘 돌아가는지 확인, 결함은 이전 테스팅에서 끝내야 돼)

 - 품질에 대한 확신.

 - 시스템을 베포 하거나 실제 사용할 준비가 되었는지 평가.

 - 인수 테스팅 이후에 대규모 시스템 간의 통합 테스트 수행.

   >> 인스테스팅이 반드시 최종 단계의 테스팅은 아님.

 - 인수 테스팅은 프로젝트 전 개발 과정에서 수행(프로젝트 진행하면서 계속 진행).

   >> 상용(COTS) SW제품은 설치, 통합하면서 테스팅.

   >> 컴포넌트의 사용성에 대해서는 컴포넌트 테스팅 동안 실행 가능.

   >> 새로운 기능 개선에 대해서는 시스템 테스팅 전에 실행 가능.

▶ 인수 테스팅 형태

 - 사용자 인스 테스팅(비즈니스 사용자가 확인)

 - 운영상의 테스팅

   >> 백업/복원, 재난 복구, 사용자 관리, 유지보수 작업, 보안 취약성 점검

 - 계약 인수 테스팅과 규정 인수 테스팅

   >> 맞춤식 - 개발 SW가 계약상의 인수 통과 조건/ 규정을 준수하는지 확인.

 - 알파 테스팅과 베타(필드) 테스팅 --> 고객의 피드백

(알파 테스트 : 회사의 다른 팀 테스트 / 베타 테스트: 외부 고객들이 테스트)

   >> 알파 테스트 : 개발 조직 내에서 고객에 의해 수행

      -고객 사이트로 이동하기 전에 개발 완료 후 테스팅인 공장 인수 테스팅을 의미

   >> 베타 테스트 : 실제 환경에서 사용자 혹은 잠재 고객에 의해 수행.

      - 고객 사이트로 이동한 후에 테스팅하는 사이트 인수 테스팅을 의미.

2.3 테스트 유형(Test types)

▶ 테스트 유형은 테스트 목적에 따라 구분

1. 소프트웨어가 수행하는 기능에 대한 테스팅.

2. 호환성, 신뢰성, 사용성과 같은 비기능적인 품질 특성 테스팅.

3. 소프트웨어나 시스템의 구조나 아키텍처에 대한 테스팅.

4. 변경 내용에 관련된 테스팅(확인 테스팅, 리그레션 테스팅)

- 기능적, 구조적 테스팅은 SW 모델 활용.

   >> 기능적 테스팅 --> 명세 기반 기법(블랙박스 테스팅) -프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 이용.

   >> 구조적 테스팅 --> 구조기반 기법(화이트박스 테스팅 (개발능력 반드시 필요)) - 제어흐름 모델, 메뉴 구조 모델 이용.

2.3.1 기능 테스팅( Functional testing)

▶ 기능 테스팅

 -  문서화되어 있거나 테스터가 알고 있는 기능과 특징, 그리고 그것들과 특별한 시스템과의 상호 운용성을 수행하며 모든 테스트 레벨에서 수행 --> 시스템이 수행하는 무엇(what)을 의미.

 - 명세 기반 기법(블랙박스 테스팅)을 이용해서 테스트 조건과 테스트 케이스를 도출하고 소프트웨어의 외부적인 행동을 고려.

▶ 보안성 테스팅

 - 악의적인 코드(바이러스 등)와 같은 외부로부터의 위협을 감지해 내는 것과 관련이 있는 기능을 확인.

   >> 보안 정책 확인, 트랩도어(진입점) 파악, 보안 관련 평가(가용성, 무결성, 기밀성, 부인 방지 등).

2.3.2 비기능 테스팅

▶ 소프트웨어 제품 특성 테스팅

 - 어떻게(How) 동작하는 가를 테스팅

   >> 성능 테스팅, 부하 테스팅, 스트레스 테스팅, 사용성 테스팅, 유지보수성 테스팅, 신뢰성 테스팅 그리고 이동성 테스팅 등을 포함한 개념.

 - 전문적 지식인과 도구 필요.

 - 모든 테스트 레벨에서 수행.

 - 다양한 척도 또는 비율로 정량화 가능한 SW품질 특성 측정. - 무조건 수치로 표현되야 돼

 - 소프트웨어 품질 모델 참조(ISO/IEC 9126)

   >> 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성(6가지 척도) 이라는 품질 특성으로 분류.

2.3.3 구조적 테스팅(Structural testing)

▶ 구조 테스팅

 - 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성 또는 충분함을 측정하는 것이 목적인 테스트 유형.

 - 커버리지

   >> 시스템 또는 SW구조가 테스트 스위트(test suite)에 의해 테스트된 정도.

   >> 테스팅의 충분함을 측정(100%로 표시 --> 추가 테스트 설계)

 - 모든 테스트 레벨에서 수행 가능

   >> 구조적 테스트 기법(화이트 박스 테스트)

   >> 시스템 아키텍처에 기반을 두고 수행

   >> 비즈니스 모델이나 메뉴 구조(인수 or 시스템 테스트 레벨)

2.3.4 확인/ 리그레션 테스팅

▶ 확인(confirmation/re- testing) 테스팅

 - 결함이 발견되고 수정된 후에 SW는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 경우.

   >> 결함을 수정하기 위한 디버깅은 테스팅이 아닌 개발 활동.

▶ 리그레션(regression) 테스팅

 - 이미 테스트된 프로그램의 테스팅을 반복.

 - 결함 수정 이후 변경의 결과로 새롭게 만들어지거나 이전 결함으로 인해 발견되지 않았던 다른 결함을 발견.

 - SW 또는 환경이 변경되면 실시.

 - 모든 테스트 레벨에서 수행.

 - 리그레션 테스팅 -- > 반복적인 성향 -- > 자동화 대상.

2.4 유지보수 테스팅

▶ 유지보수 테스팅

 - 이미 운영되고 있는 시스템에서 수행되며, SW나 시스템이 변경, 단종되었거나 마이그레이션 될 때 발생.

 - 변경에 대한 유지 보수 테스팅.

   >> 계획된 개선을 위한 변경, 수정에 의한 변경과 환경의 변경.

   >> 계획된 OS, DB 업그레이드, OS의 새로 드러난 취약점 패치.

 - 마이그레이션에 대한 유지보수 테스팅.

   >> 변경된 SW에 대한 운영 테스트 + 새로운 환경에서의 운영 테스트

 - 변경된 것 + 변경되지 않은 시스템 요소(영향도 분석 후)에 대한 방대한 리그레션 테스팅 고려.

 - 범위는 변경 범위 및 기존 시스템의 리스크와 크기 고려.  

(참고)

테스트 정책

▶ 소프트웨어 테스팅에 대한 조직의 철학을 정의한 문서

▶ 테스팅 관련 최상위 레벨 문서(일반적으로 간단한 형태)

 - 테스팅 정의

 - 테스팅 미션 및 목적

 - 테스팅 조직의 핵심 역할

 - 고객 만족을 위한 테스팅 관점과 시각

 - 테스트 프로세스 개선

소프트웨어 테스트 윤리강령

▶ 공공성 우선 : 공공의 이익을 위해

▶ 고객과 고용주의 이익 고려 : 고객, 고용주, 공공의 이익 고려

▶ 전문성 있는 결과물 : 표준화된 전문적 산출물

▶ 판단의 독립성 : 판단에 무결성과 독립성 보장

▶ 윤리적 관리 : 윤리적으로 테스팅을 관리해야 함

▶ 직업 의식 : 공공의 이익에 부합하도록 무결성과 신뢰 제공

▶ 동료 의식 : 동료를 공정하게 대하고 개발자와 협력을 촉진

▶ 자기 조직 : 전문성을 확보하고 윤리적 사고로 활동을 함   

테스터 사명

▶ 책임감 : 고객의 입장에서 대변하고 적극적으로 리스크 관리를 함

▶ 태도 : 끊임없는 호기심과 열정으로 창의적이고 혁신적인 테스팅을 위해 노력함

▶ 프로의식 : 테스팅을 사랑하고 자긍심을 갖고 끊임없는 학습으로 전문성을 확보함

▶ 커뮤니케이션 : 개발자는 완성도가 높은 제품을 함께 만들어가는 동반자로 누구에게나 배우려는 열린 마음 지향

1.5 테스팅의 심리학

▶ 개발자와 테스팅 엔지니어 분리 -- > 각자의 활동에 집중

▶ 테스팅 독립성(-- > 단계가 오를수록 독립성 높아짐)

1. 테스트 대상 소프트웨어의 개발자가 설계한 테스트(독립성 떨어짐)
2. 개발팀 내의 다른 인원이 설계한 테스트
3. 다른 그룹의 독립적인 테스트 팀의 인원, 또는 테스트 전문가(사용자 또는 성능 테스트 전문가 등)가 설계한 테스트.
4. 다른 조직 또는 다른 회사의 인원이 설계한 테스트(외부적 조직에 의한 인증, 아웃소싱)

- 명확한 테스팅의 목표설정은 테스팅을 성공적으로 수행하는 데 있어 중요.

▶테스팅 진행하는 동안 결함을 식별하는 과정

 - 작성자에 대한 비판으로 오해될 소지 존재

   >> 호기심, 전문적인 비평, 비판적인 시선, 세밀한 것에 주목하는 태도, 개발자 또는 개발팀 동료와의 원활한 의사소통, 그리고 결함을 유추해 내는 경험을 필요

 - 오류나 결함, 장애가 긍정적인 방법으로 의사소통 된다면, 테스트와 개발자 간에 발생할 수 있는 감정 악화를 피할 수 있다.

 - 테스터, 테스트 리더 사이

   >> 좋은 대인 관계가 필요

 - 결함 정보

   >> 결함 발견 --> 시간과 비용 절감 및 리스트 요소 줄임  

▶테스터의 역할

 - 다툼보다는 협력으로 시작 --> 코드를 짠사람과 테스터와의 관계 : 공통적인 목표로 인식하는게 중요.

 - 소프트웨어를 개발한 사람에게 비평을 배제하고 중립적이고 사실에 근거한 제품의 결함만 전달하려고 노력한다.

 - 다른 인원이 어떻게 느끼는지, 왜 그렇게 반응하는지 이해하도록 노력한다. (대화의 기술을 높여야 돼)

 - 상호간에 의사소통 했던 것을 상대방이 정확하게 이해했는지 확인한다. (문서화- 체크리스트 만들어서 전달)

1.6 소프트웨어 테스팅을 제약하는 요소

▶ 최근 SW

 - 전통적인 컴퓨팅 영역 탈피

   >> 가전, 무선단말기, 산업 기기, 휴대폰, 자동치(ECU) 분야

 - SW 개발 프로세스 품질의 중요성과 함께 SW 결함을 사전에 진단하고 정상 동작여부를 시험하는 테스팅의 중요성 부각.

   >> 전체 개발비의 40% ~60% 이상이 테스팅 비용(개발 << 테스팅 비용)

   >> 하지만 기존 개발자들은 테스팅에 소극적 --> 하위레벨 테스트 부족

 - 품질에 대한 인식 높아져 기대 수준 높아짐 --> 리스크 관리 필요

   >> 체계적인 테스팅을 위해서는 테스트의 우선순위 중요. 

▶테스트에 대한 문제점

 - 테스터가 테스팅에 대해 너무 단편적으로 알고 있는 것은 체계적인 테스팅을 제약하는 요인

   >> 개념과 연관성 이해

   >> 리스크 기반 테스팅 접근법 / 테스트 기법 / 테스트 커버리지 올리는 방법

   >> 이론을 실무에 적용하는 노력 필요.

 - 의사결정권자와 매니저의 테스팅에 대한 인식 부족

   >> 임시방편

   >> 테스트 자동화 도구의 중장기적 계획 or 테스트 프로세스 정립 필요

 - 테스팅을 투자가 아닌 불 필요한 비용으로 인식(X)

   >> 테스팅은 개발보다 더 확실한 ROI(Return On Investment) 활동

1.7 테스팅 분야의 매력

▶ 테스팅 분야의 전문가

 - 체계적인 지식 체계를 갖는 전문 분야

   >> 기존적인 컨셉과 테스트 전략, 계획, 설계 기법, 테스트 케이스 작성, 결함 관리, 지원 도구, 정적 테스트 기법, 비기능성 테스팅, 테스트 프로세스 관리, 기반 설비 및 환경, 메트릭과 리포팅 등의 분야 포함.

 - 테스팅 분야는 넓고 다양함

   >> 자동화 도구에 대한 전문적 기술

   >> 보안성 테스트, 신뢰성 테스팅 분야 전문가

   >> 테스팅 컨셉, 기법 및 관리 방법을 소프트웨어 종류별 최적화하여 적용

 - 테스팅 필요성 급증

 - 테스팅 분야에서 연령 제한(X), 경험 중시

1.8 테스트 전문가

▶ 테스트 전문가에 대한 수요

 - 계속적으로 증가 --> 소비자의 품질에 대한 마인드와 기대 수준 up.

 - 전문 인력 수급 어려움

   >> 협력사 파견 인력 진원

   >> 테스팅 전문 회사에 아웃소싱

   >> 고급인력이 부족한 경우엔 테스트 컨설턴트 활용

 - 능력 있는 테스트 전문가

   >> 기술 능력 - 소프트웨어 공학 이해, 테스트 수행 능력

   >> 개인 능력 - 커뮤니케이션, 분석력, 문서화, 결함 유추

   >> 습성 - 충분한 이해와 도구 사용, 표준화 노력

   >> 사고방식과 태도 - 주인의식, 열정, 적극, 긍정, 호기심, 비판적인 시선 등

< 테스팅의 일반적인 원리 >
원리 1. 테스팅은 결함이 존재함을 밝히는 것.
원리 2. 완벽한 테스팅은 불가능.
원리 3. 개발 초기에 테스팅 시작.
원리 4. 결함 집중.
원리 5. 살충제 패러독스.
원리 6. 테스팅은 정황에 의존적.
원리 7. 오류 - 부재의 궤변.

1.3 테스팅의 일반적인 원리

- 원리 1. 테스팅은 결함이 존재함을 밝히는 활동이다.

>> 잠재적으로 존재하는 결함 줄임. BUT, 결함이 없다고 증명할 수는 없음.

- 원리 2. 완벽한 테스팅은 불가능하다.

>> 한 프로그램 내에 내부 조건이 많음.

>> 입력이 가질 수 있는 모든 값의 조합이 무수히 많음. (실제로 발생하는 현상이 무수히 많음.)

>> 이벤트 발생 시 발생 순서에 대한 조합도 무수히 많음.

>> 리스크에 따라 테스트 강도 높게 수행 -- > 실제 완벽은 불가. >> 가능성이 높은 것부터 수정해 나가야 돼.

- 원리 3. 테스팅을 개발 초기에 시작한다.

>> 개발의 시작과 동시에 테스트를 계획하고 전략적으로 접근.

>> 요구사항 분석서와 설계서 등의 개발 산출물 분석 후 테스트 케이스 도출.

- 원리 4. 결함 집중

>> 대다수의 결함들은 소수의 특정 모듈에 집중되어 발생하는 경향을 보임.

>> 결함의 집중은 운영상의 장애를 초래. (리스크가 높은 애들 먼저 수정)

   >> 복잡한 구조의 모듈.

   >> 다른 모듈과 다량의 상호작용을 하는 모듈

   >> 개발 난이도가 높거나 최신 기술을 사용한 모듈

   >> 크기가 큰 모듈

   >> 경험이 미흡한 팀에서 개발한 모듈

   >> 새롭게 개발한 모듈

- 원리 5. 살충제 패러독스  (면역력이 높아져서 결함 찾기가  어려워지는 상황)

 >> 동일한 테스트 케이스로 동일한 테스트를 반복하면 결함을 찾기 어려워짐.

 >> 더 많은 결함을 찾기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선.

- 원리 6. 테스팅은 정황에 의존적.

 >> 테스팅은 정황과 도메인에 따라 다르게 진행.

 >> 모든 테스트에 적용되어야 하는 것. -표준화된 적용 방 (상황이나 도메인에 맞춰서 적절하게 적용해야 됨.)

   >>  테스트 프로젝트 기획

   >> 표준적인 기법 적용.

   >> 독립적인 테스트 환경.

   >> 효율적/ 효과적 테스트 팀 조직

   >> 정식 리포팅 등

- 원리 7. 오류-부재의 궤변 (사용자의 요구 수준에 맞지 않는다면 버그 수정은 의미가 없다.)

 >> 개발된 소프트웨어가 사용자 요구 수준을 만족하지 않는다면 버그를 수정하는 것은 의미가 없음.

1.4 테스트 프로세스의 기초

▶ 테스트 프로세스

- 테스팅 관련 행동이 체계적으로 진행되어 의도된 테스트 목적과 목표를 달성할 수 있도록 테스팅의 구성 요소를 엮어주는 역할.

>> 테스트 베이시스 -- > 계획 단계부터 필요설계 시 반드시 요구.

>> 테스트 조직 -- > 계획 단계부터 필요, 실행 단계에서 다수 인력 필요.

>> 테스트 전략

>> 테스트 기법 --> 분석 및 설계 단계에서 필요

>> 테스트 대상 --> SW는 가장 이른 시기 준비, 늦어도 실행 단계엔 필수.

>> 테스트 기반 설비 및 환경 --> 실행 단계 전에 구축

- 체계적으로 발견한 결함과 관련 정보를 바탕으로 정량적(수치적)으로 개발 프로젝트에 조언(분석한 리스크)을 제공.

1.4.1 테스트 계획과 제어(통제)

▶ 테스트 계획과 제어

- 주요 활동

>> 테스트 목적/ 목표 및 대상 연구.

>> 테스트 전략 개발

>> 테스트 완료 조건의 결정

>> 테스트를 추정

>> 테스트 조직 구성

>> 테스트 계획 활동

>> 테스트 관리 및 제어

>> 리포팅

▶테스트 제어

- 계획 대비 실제 진행 상황을 비교하는 지속적인 활동.

- 계획과의 차이 확인 > 지속적 모니터링

- 제어 작업 

   >> 테스트 결과에 대한 측정과 분석

   >> 테스트 진척사항, 완료조건의 모니터링과 문서화

   >> 테스트 계획과의 차이 교정

   >> 테스팅의 진행과 변경에 대한 의사 결정 활동.

   >> 테스팅 계획은 테스팅의 제어와 모니터링 활동으로부터 받은 피드백을 반영

1.4.2 테스트 분석과 설계

▶ 테스트 분석과 설계

- 일반적이고 추상적인 테스팅 목적을 실제적이고 구체적인 테스트 상황과 테스트 케이스로 변환하는 활동.

- 주요 작업

 >> 테스트 베이시스 리뷰(가장 기초 문서 - 요구사항 명세서, 설계 계획서 등)

 >> 테스트 상황 / 테스트 케이스 / 필요한 테스트 데이터 식별

 >> 테스트 케이스 설계와 우선순위 선정★

 >> 테스트 기법 할당

 >> 테스트 용이성 평가

 >> 테스트 환경 구축(실제 환경과 동일)

 >> 필요한 도구 식별 

1.4.3 테스트 구현과 실행

▶ 테스트 구현과 실행

- 테스트 케이스를 조합하고 테스트 실행에 필요한 다른 정보를 포함하는 테스트 프로시저 또는 테스트 스크립트를 명세화.

- 테스트에 필요한 환경이 구축되어야 함.

- 주요 작업

 >> 테스트 케이스 개발, 구현과 우선순위 설정

 >> 자동화 테스트 스크립트 작성

 >> 테스트 하네스 준비 (환경 준비)

 >> 효율적인 테스트 실행을 위해 테스트 수트(테스트 케이스 묶음) 생성

 >> 선행 테스트

 >> 테스팅 실행(결과 기록 - 식별과 버전 관리)

 >> 기대 결과와 비교 -- > 예상 결과와 실제 결과 간의 차이에서 오는 불일치를 인시던트 또는 결함으로 보고 - > 불일치 원인 파악. 

- 예상과 실제의 불일치

 >> 테스트 케이스 결함

 >> 테스트 정황 결함

 >> 어플리케이션 결함

- 불일치를 조치한 결과를 확인하기 위한 테스트 활동 반복.

 >> 수정이 되었는지 테스트 실행  -- > 확인 테스팅

 >> 수정으로 새로운 버그가 발생하지 않았는지 테스트 실행 -- > 회귀 테스팅

- 결함의 유형

 >> 기획 시 유입된 결함 - 요구사항의 표준 미준수, 테스트 불가능 등

 >> 설계 시 유입된 결함 - 설계의 표준 미준수, 테스트 불가능 등

 >> 코딩 시 유입된 결함 - 코드의 표준 미준수 등

 >> 테스트 부족으로 유입된 결함

 >> 마무리 부족

 >> 팀간 의사소통 부족

 >> 코딩 실수

- 결함 심각도에 따른 결함 유형

 >> 치명적 결함, 매우심각, 심각, 보통, 경미 (-> 4단계)

 >> 치명적 결함, 주요 결함,  일반 결함, 사소한 결함, 개선 사항( -> 5단계)

- 결함 유형으로 부적절한 경우

 >> Major, Minor, Trifle(Minor를 결함의 심각도가 낮은 것으로 인식 가능 - 다 문제가 있어)

 >> A,B,C(어느 것이 결함이 높은 것인지 알 수 없음)

- 결함의 우선 순위 표현

 >> 즉시 해결, 주의 요망, 대기, 낮은 순위

1.4.4 테스트 완료 조건과 리포팅

▶ 테스트 완료 조건의 평가

 - 초기 목표 대비 완료 조건의 달성 여부 확인(->95% 만족 시)

 - 테스트 레벨에 따라 다 수행함.

 - 완료 조건 작업

 >> 테스트 실행 결과인 테스트 로그가 테스트 계획에 명시된 완료 조건을 만족하는지 확인.

 >> 추가 테스트 필요 여부 및 명세화된 테스트 완료 조건 변경 여부

 >> 이해관계자들에게 배포할 테스트 요약 보고서 작성. 

▶리포팅에 표현되는 내용

 -  발견된 결함과 미해결 된 결함의 추이 및 우선순위

 -  테스트 진척도

 - 리스크 및 메트릭으로 실증된 조건

 - 테스트 환경의 가용성(다음에 사용 가능한지 여부)

   >> 테스트 커버리지(참 인지 거짓인지 다 훑고 넘어가는 테스트)

   >> 결함 발견 효율성/ 효과성

   >> 품질 평가 결과

   >> 결함 상태별 결함수

   >> 소프트웨어 사이즈 대비 결함수

   >> 요구사항별 테스트 일수

   >> 해결되지 않은 결함과 영향 및 오래 수정되지 않은 결함 

1.4.5 테스트 마감 활동

▶ 테스트 마감 활동

 - 산출물 확인, 테스트웨어(산출물) 보관(-> 다음 프로젝트를 위해)

 - 테스트 프로세스 평가 심사

 - 주요 활동

   >> 테스트 결과 마감(예정된 산출물, 인시턴트(결) 레포트 종료, 해결되지 않은 요구사항에 대한 처리, 시스템 인수에 대한 문서화 등)

   >> 테스트웨어, 테스트 환경, 테스트 기반설비를 차후에 사용 위해 마감, 보관

   >> 테스트웨어를 유지보수 조직에 이관

   >> 테스트 프로세스 심사 및 개선 사항

   >> 이후 릴리즈나 프로젝트, 테스트 성숙도의 개선에 지침이 될 수 있도록 테스트 프로젝트를 통해 얻은 교훈을 분석.   

1, 소프트웨어 테스팅의 기초
용어: 커버리지, 디버깅, 결함, 오류, 장애, 밸리데이션, 베리피케이션
 
※ 학습목표
1.1. 테스팅이란 무엇인가?
1.2. 테스팅이 왜 필요한가?
1.3. 테스팅의 7가지 원리.
1.4. 테스트 프로세스(의 과정)
1.5. 테스팅의 심리학(어떤 마음으로 테스팅을 하는지)
 

1.1.1 SW 시스템 관점에서 테스팅의 필요성

▶ SW관점에서 테스팅
- 비즈니스 어플리케이션에서 소비자 제품에 이르기까지 폭넓게 생활의 많은 부분에 사용 > 비중은 계속 증가.
- 금전적인 손실, 시간 낭비, 비즈니스의 이미지 손상, 그리고 부상이나 사망(ex>에스컬레이터)에 이르기까지 다양하고 심각.
- 테스팅은 소프트웨어 시스템의 문제를 최소화하기 위해 필요.
 

1.1.2 소프트웨어 결함의 원인

▶ 소프트웨어 결함

장애는 실제로 벌어져야 장애로 이어지고, 리스크가 큰애 부터 장애를 해결. 리스크가 없으면 나중에 수정.  
리스크 분석을 통해 어떤 것 부터 수정해야 하는지 판단, 우선순위로 해결 가능.
 

1.1.3 SW 개발, 유지보수, 운영 시 테스팅의 역할

▶ 테스팅
- 개발 초기의 요구사항 분석 단계부터 리뷰와 정적 분석을 통해 정적으로 시작 -- > 각각의 개발 단계에 대응하는 테스트 레벨별.
- 컴포넌트, 통합 테스팅은 개발 조직(개발자들) 중심으로 수행.
- 시스템이 갖춰진 이후의 테스팅은 독립적인 테스트 조직(전문 테스터들) 중심
- 테스트 레벨에 따른 테스트 
>> 소프트웨어 품질을 높이고, 결함 발생 가능성을 최소화.
- 유지보수 활동으로 변경 및 단종되거나 환경이 변경
>> 변경된 환경에 대해 운영 테스팅(리그레션 테스팅 -반복 테스팅).
>> 변경으로 인한 결함과 장애를 예방.
- 계약상 요구 조건 및 산업에 특화된 표준 만족
 

1.1.4 테스팅과 품질

▶ 품질 특성 및 향상
- ISO / IEC 9126 소프트웨어 제품 품질(기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성)
- 품질 향상 > 테스팅이 결함을 찾아내고, 발견된 결함 수정
- 품질 보증(Quality Assurance)
>> 이전 프로젝트를 통해 많은 테스트 경험과 정보 확보.
>> 발견된 결함의 근본 원인 이해를 통해 프로세스 개선.
>> 결함의 재발 방지 (품질보증(QA)을 통해 하고 싶은 것)
- 개발 표준이나 교육 훈련 그리고 결함 분석. 
 

1.1.5 테스팅, 얼마나 해야 충분한가?

▶ 적절한 테스팅 정도
- 리스크 수준을 고려
- 프로젝트 제약 사항(기술적인 내용, 비즈니스, 제품, 프로젝트 리스크, 시간(얼마나 시간이 있는가), 비용(테스트를 위해 쓸 수 있는 돈))
- 테스팅은 테스트된 SW나 시스템을 다음 단계로 전달하는 데 있어 프로젝트 이해관계자들이 릴리즈 결정을 내릴수 있도록 충분한 정보 제공.
 

1.2 테스팅이란 무엇인가?

▶ 테스팅 (테스팅의 목적 - 결함 발견 후 해결)
- 응용 프로그램 또는 시스템의 동작과 성능, 안정성이 사용자가 요구하는 수준을 만족하는지 확인하기 위해 결함을 발견 하는 메커니즘
> 정상 동작 여부 확인, 사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는지 확인, 개발 프로젝트의 리스크 정보를 정량적 수치(숫자로)로 의사결정권자에게 전달.
- 초기 개발 산출물 > 리뷰
- 테스트 케이스 작성 과정(결함 예방 활동)
- 다양한 테스팅 활동
- 테스팅의 일반적인 목적
>> 남아있는 결함 발견, 명세 충족 확인, 사용자 및 비즈니스의 요구 충족, 결함 예방, 품질 수준에 대한 자신감 획득과 정보 제공, 비즈니스 리스크를 감소 시키는 정보에 근간한 조언 제공, 개발 프로세스 점검, 이슈 제기, 논리적 설계의 구현 검증, 시스템과 소프트웨어가 적절히 동작함을 확인. 
- 관점에 따른 테스팅의 목적
>> 개발 과정 - 결함을 찾고 수정하기 위해 가능한 많은 장애 상황 재연
>> 인수 테스팅 - 예상대로 시스템이 동작하는지 확인, 요구사항 확인
>> 소프트웨어 품질 - 출시하는 것의 리스크를 관련자에게 전달
>> 유지보수 테스팅 - 변경에 대해 새로운 결함의 유입을 확인 (반복 테스트)
>> 운영 테스팅 - 신뢰성 또는 가용성 같은 시스템 특성을 평가
>> 테스팅은 문서의 리뷰와 함께 정적 분석에 의한 테스트 포함.

테스트 베이시스 - 요구사항 명세서(요구사항 분석) >> 가장 기초적인 문서