노년코딩

이제 드디어 6장만 남겨두고 있다. 이런 저런 일들이 있었지만 다 정리해서 공부하고 새롭게 시작할 공부로 넘어가 보자.

6.1.1 테스트 도구의 분류

▶ 테스트 도구 자동화

 - 테스팅 자동화 --> 모든 테스팅 활동에 대해 고려

   >> 반복적인 작업 자동화 또는 테스트 계획, 테스트 설계, 테스트 리포팅과 모니터링과 같은 메뉴얼 테스트 지원 --> 테스트 효율성 향상.

   >> 수작업으로 진행 시 상당한 자원을 필요로 하는 업무 자동화 (e.g. 정적 테스팅)

   >> 사람이 수행할 수 없는 업무 자동화 (e.g. 클라이언트 - 서버 어플리케이션의 대단위 성능 테스팅)

   >> 테스팅 신뢰성 향상(e.g. 대량 데이터 비교 자동화, 시뮬레이션)

 - 테스팅 활동에 따른 도구 분류

6.1.2 테스트 관리 지원 도구

▶ 테스트 관리 도구

 - 실행된 테스트와 테스팅 활동 관리를 지원

 - 추적성 제공 : 소스 문서(요구사항명세 등)와 테스트 케이스, 테스트 결과, 인시던터(결함) 간의 추적성 제공.

 - 리포트 생성 : 테스트 결과 기록, 테스트 진행 상황에 대한 리포트 생성

 - 정량적 분석 지원 : 테스트 관련 지표(실행한 테스트, 합격한 테스트 등)와 발견된 결함 또는 인시던트와 같이 테스트 대상에 관련된 정량적인 분석(측정)을 지원

 - 조직의 요구에 맞는 양식으로 유용한 정보를 생산하기 위해 스프레드시트, 테스트 실행 도구, 결함 추적 도구, 요구사항 관리 도구와 같은 다른 도구들과 연동 필요

▶ 인시던트 관리 도구

 - 보고된 인시던트 리포트 간에 우선순위 결정

 - 결함 수명 주기 관리

   >> 결함이 발견(탄생)되고, 분배되고, (재)수정되고, (재)확인되고, 종료되는 결함 수명 주기 관리

   >> 결함 수정 불필요, 수정 완료 및 테스트 준비, 수정을 다음 릴리즈로 연기 등의 결함 상태 변경

 - 결함을 기록하고 결함 관리 상황에 대한 리포트 생성(누적 s커브 등)

 - 담당자에게 수정 및 확인 테스트 등의 임무 할당

▶  요구 사항 관리 도구 

 - 요구사항 명세서 저장

 - 요구사항에 대한 특성(우선순위 포함) 저장

 - 요구사항에 대한 고유 식별자 부여

 - 요구사항에 대한 개별 테스트의 추적성 제공

 - 누락된 요구사항 또는 일관성이 없는 요구사항을 식별

** 참고: 요구사항 커버리지가 100% 커버했다고 하더라도 요구사항이 최소한 1개의 테스트 케이스로 테스트되었다는 정도만 의미함

▶ 형상 관리 도구

 - 형상관리 지원 도구는 테스트를 위한 도구는 아니지만 테스트 업무에 활용 가능함

 - 테스트웨어의 버전 관리와 저장을 위해 활용

 - 하나이상의 운영체제, 컴파일러, 브라우저 등의 하드웨어/ 소프트웨어 환경 구성에 필요

6.1.3 정적 테스팅 지원 도구

▶  정적 테스팅 지원 도구

 - 개발 프로세스 초기에 많은 결함을 발견 -> 비용 대비 효과성 올라감

 - 리뷰 프로세스 지원 도구

   >> 리뷰 프로세스에 관한 정보를 저장, 리뷰 코멘트를 저장

   >> 의사소통, 결합 및 노력을 기록/ 보고

   >> 리뷰 규칙이나 체크리스트를 참조할 수 있도록 지원

   >> 문서와 소스 코드 사이의 추적성 확보를 가능하게 함

   >> 온라인 리뷰 지원

 - 정적 분석 도구(개발자에게 더 적절한 지원)

   >> 개발자, 테스터, 품질보증 담당자가 동적 테스팅을 하기 전에 결함을 발견할 수 있도록 지원

   >> 코딩 표준을 지킬 것을 강제

   >> 구조와 의존관계를 분석(링크된 웹페이지의 구조와 의존 관계 분석 등)

   >> 코드 이해 지원

   >> 최근에는 의미 분석, 룰 체크 등으로 구분

 - 모델링 도구 (개발자에게 더 적절한 지원)

   >> 소프트웨어 모델 유효성 검증 지원

   >> 소프트웨어 모델을 기반으로 테스트 케이스 생성 지원

 - 정적 분석 툴이나 모델링 툴에서 가장 큰 이점은 개발 프로세스 초기에 더 많은 결함을 발견하게 하는 비용 효과성을 들 수 있음.

6.1.4 테스트 설계 지원 도구

▶ 테스트 설계 도구

 - 코드, 디자인 모델, 사용자 인터페이스, 요구사항으로부터 테스트 입력값과 실제 테스트 케이스를 생성

 - 일부 도구는 테스트 오라클을 사용해 예상 결괏값을 생성

 - 상태나 객체 모델로부터 생성된 테스트 케이스는 모델 구현을 검증하는데 매우 유용

▶ 테스트 데이터 준비 도구

 - 데이터 베이스, 파일, 데이터 전송을 적적히 조작해 테스트 데이터 마련

   >> 실 데이터의 익명성을 보장하여 데이터를 보호하면서 실제와 거의 동일한 데이터로 테스트 수행함.

   >> 다량의 데이터가 필요한 경우나 특정 생성 규칙에 맞는 데이터가 필요한 경우에도 유용하게 활용됨.

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

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을 식별하는 것은 테스트 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -- > 시스템 설계에 의존적.
▶ 결정 테이블 장단점