테스팅 실무 기본 (+ 드라이버&스텁 사용이유, 데이터 컨버젼/마이그레이션)

ACAI BERRY DEVELOVER·2023년 8월 1일

❖ 테스트의 정의

소프트웨어 실행 : 테스팅의 일부
소프트웨어 실행전, 후에도 테스트 관련 활동이 다수 존재
계획 및 제어, 분석, 설계, 실행, 보고, 마감 등의 절차를 가지고 있는 프로세스
문서 또는 소스코드 리뷰를 통해 결함을 찾는 활동도 테스트

❖ 테스트의 목적

결함 발견
품질에 대한 확신을 얻기 위해
의사 결정 지원
결함 예방 (사용자보다 먼저 결함을 찾아야 함)
⁺ 개발 프로세스 개선
⁺ 테스트 프로세스 개선
모든 프로세스는 개선 가능성이 있다

❖ 테스트의 7가지 원리

테스트는 결함의 존재를 밝히는 것
- 제3자 Tester가 나오게 된 원리
완전한 테스트는 불가능
- 위험 기반 Testing
개발 초기부터 테스트는 시작
결함은 집중되어 있음
- 코드의 매커니즘 상 결함은 집중되어 있음.
살충제 패러독스
- 퀄리티 있는 제품과 TC를 통과하는 제품은 같지 않다!!
테스트는 정황에 의존
- usage, context에 따라 달라진다
- 공수예측,추정
오류 부재의 궤변
- 테스터의 역량이 가장 중요한 원리
- 도메인 지식과 유저의 니즈가 중요
- Senior Level에서 중요한 원리
❖ 소프트웨어 테스트 표준(ISO/IEC) 29119 - Part 2

테스트 관리 프로세스

❖ 테스트 유형

테스트 목적에 초점을 두고 분류
- 기능 테스트 : 소프트웨어의 기능 검증
- 비기능 테스트 : 신뢰성, 사용성 등의 비기능 품질 특성 검증
- 구조적 테스트 : 소프트웨어의 구조 및 아키텍처 검증
- 확인&리그레션 테스트 : 변경으로 인한 다른 영역의 소프트웨어 영향을 검증

❖ 기능 테스트

기능이란

- 소프트웨어가 무엇(what)을 해야 하나를 기술한 것

검증방법

- 요구사항 명세서 또는 각종 분석/설계 산출물 상의 기능을 적절히 수행하는지 검증
- 간혹 문서화 되어 있지 않은 경우, 제품을 사용하면서 경험을 기반으로 검증

수행 시기

-전체 테스트 레벨에서 수행 가능

주요 테스트 접근법

- 외부 입력에 대해 소프트웨어의 작동 결과를 검증하는 블랙박스 테스트 수행
- 명세기반 기법, 경험기반 테스트
- Verification and Validation

❖ 기능 테스트 관점

► 기능 정확도 (Functional Correctness)

Functional Correctness : Degree to which a product or system provides the correct results with needed degree of precision
제품 또는 시스템이 필요로 하는 정도에 맞게 정확한 결과를 내는지 검증
단위 기능 테스트 레벨, 시스템 테스트 레벨에서 주로 검증

► 기능 성숙도 (Functional Completeness)

Functional Completeness : Degree to which set of functions covers all the specified tasks and users objectives
제품의 기능들이 특정 작업 및 사용자 목적에 부합하는지 검증
시스템 테스트 레벨, 인수 테스트 레벨에서 주로 검증

► 기능 타당성 (Functional Appropriateness)

Functional Appropriateness : Degree to which the functions facilitate the accomplishment of specified tasks and objectives
제품의 기능이 특정 작업 및 목적을 달성하는데 용이한 정도를 검증
UI 검증 테스트 (단위, 시스템 테스트 레벨)에서 주로 검증

❖ 비기능 테스트

▶︎ 비기능(Non-Function) 이란

소프트웨어가 어떻게(How) 작동해야 하나를 기술한 것

▶︎ 검증방법

ISO/IEC 25010의 품질 특성을 기반으로 비기능 요구사항에 대하여 정량적으로 측정하여 검증

▶︎ 수행시기

전체 테스트 레벨에서 수행 가능

▶︎ 주요 테스트 접근법

외부 입력에 대해 소프트웨어의 작동 결과를 검증하는 블랙박스 테스트 수행
명세기반기법

▶︎ 테스트 종류

성능 테스트, 부하 테스트, 사용성 테스트, 유지보수성 테스트, 신뢰성 테스트, 이식성 테스트, 현지화 테스팅, 글로벌화 테스팅 등

❖ 구조적 테스트

▶︎ 목적

소프트웨어 구조 커버리지를 높이기 위한 테스트

▶︎ 커버리지

시스템이 테스트 스위트에 의해 테스트된 정도를 말하며 퍼센트로 표시

▶︎ 수행시기

전체 테스트 레벨에서 수행 가능
단위 테스트 : 코드 커버리지 (구문, 결정문 등)
통합 테스트 : 인터페이스 커버리지, 컴포넌트 커버리지
시스템 테스트 : 메뉴 구조도, 비즈니스 모델의 커버리지

▶︎ 주요 테스트 접근법

구조기반기법 적용
해당 레벨에서 적용하고자 하는 명세기반기법을 적용 후, 커버리지가 부족한 부분에 대하여 구조적 설계를 통해 커버리지를 높이는 것이 효율적

❖ 확인&리그레션 테스트

▶︎ 확인 테스팅

결함 수정 후, 결함이 제거되었는지 확인하는 테스트 활동
개발자가 결함을 제거하는 디버깅은 테스트 활동이 아니다.

▶︎ 리그레션 테스팅

반복적인 테스트 수행
특정 영역에 대하여 결함 수정 혹은 요구사항 변경 등으로 인한 변경 발생 시, 이미 테스트되어 변경되지 않은 영역을 반복적으로 테스트

목적

  - 다른 어플리케이션의 결함으로 인하여 발견 하지 못했던 결함 발견
  - 요구사항 변경으로 새로운 결함이 유입되었는지 검증

검증 대상

      - 영향도 분석을 통한 관련 컴포넌트

▶︎ 확인 테스트와 리그레션 테스트는 항상 같이 고려 되어야 한다.

▶︎ 수행시기

전체 테스트 레벨에서 수행 가능

❖ 테스트 접근법

❖ 테스트 레벨의 특징

▶︎ 테스트 목적, 대상, 테스트 베이시스, 수행 주체, 테스트 보조장비( harness 및 지원도구), (테스트)접근법 및 책임 등이 각 레벨에서 다르게 식별 될 수 있다.

▶︎ 테스트 레벨의 종류

❖ 단위테스트 (Unit testing)

▶︎ 컴포넌트 테스트, 프로그램 테스트

▶︎ V & V

Validaation (확인) : 컴포넌트 내의 사용상 결함 찾기
Verification (검증) : 컴포넌트와 설계 및 요구사항과의 차잊 찾기

▶︎ 테스트 베이시스

컴포넌트 요구사항 정의서, 상세 설계, 프로그램 코드

▶︎ 테스트 대상

컴포넌트 or 프로그램 or 특정 단위
데이터 컨버전/ 마이그레이션 프로그램
데이터베이스 모델

▶︎ 수행 가능한 테스트 유형

기능 테스트 (기능 정확도, 타당성 등)
비기능 테스트 ( 메모리 릭, 유지보수성, 사용성 등)
구조적 테스팅 (코드 커버리지 달성을 위한)

스텁에 해당하는 프로그램이 있어도 테스트 용이성을 높이기 위해서 데이터를 자유자재로 바꿔가면서 테스트해야하기때문에 스텁을 사용한다.
데이터 컨버전/마이그레이션
컨버젼: 체계를 바꾸는 것
마이그레이션: 시스템변경시 정보를 옮기는 것
-대부분의 마이그레이션에는 컨버전이 포함되어 있다,
-컨버전만 하는 경우도 많다
수행가능한 테스트 유형
비기능 테스트 (유지보수성) 조기에 발견하는게 좋다
사용성테스트 - 막판에 고치면 비용(시간, 노력)이 늘어난다
메모리 릭 - 메모리반납이 안되는 경우 메모리는 자원의 일정량만 있음 (한정자원) 메모리가 쓸 수 없는 상태가 됨
메모리릭은 동적테스트로 찾을 수 없다 (주로 도구를 이용해서 찾음, 가급적 단위테스트마다 도구를 사용해서 찾으면 때마다 제거할 수 있어서 좋다)

구조적 테스팅
코드를 커버하는 건 단위테스트에서만 가능하다(나중에하면 비용이 늘어난다)
코드커버를 요구하는 제품: 이커머스 솔루션은 뻔하다,이미 있는 모듈을 변형해서 사용하기에 로우레벨테스트에서 강도있게 하지 않는다
카드대출, 채권 모듈 개발시 코드커버테스팅은 중요하다, 리스크가 있는 제품들, 자동차 소프트웨어(safety),선박,항공,의료기기,철도,무기,원자력,에너지등
은 강도있는 코드 커버리지 테스팅을 원한다.

❖ 통합 테스트 (Integration testing)

▶︎ 컴포넌트 간 또는 각기 다른 시스템간의 인터페이스 검증

컴포넌트 통합 테스트 : 소프트웨어 컴포넌트간의 인터페이스 또는 상호 연동
시스템 통합 테스트 : 다른 시스템간 또는 SW와 HW 인터페이스 및 상호 연동

▶︎ 테스트 베이시스

소프트웨어 및 시스템 설계
아키텍처 구성도, 업무 흐름도, 유즈 케이스

▶︎ 테스트 대상

서브 시스템
데이터 베이스 구현
인터페이스
시스템 구성 및 구성 데이터

▶︎ 수행 가능한 테스트 유형

기능 테스트
비기능 테스트 : 성능 테스트, 인터페이스 테스트 등

★ 통합 테스팅
각각의 단위를 결합하는 테스팅
integration(통합?)
: 통합보다는 결합이 더 의미있다
결합테스팅이다
결합이란? 하나씩 통합 탑다운,바텀업 어프로치,백본(중요한 것부터 결합,핵심업무),빅뱅(한번에 다 결합, 시스템이 크지 않을 경우)
앤드투앤드테스트 (통합테스트떄는 할 수 없다, 시스템테스트에서 가능)
a-> b->c-> d
통합
a->b
b->c
c->d
컴포넌트 테스트 이후에 컴포넌트 통합 테스트
시슽템 통합 (시스템간의 인터페이스)
소프트웨어적 단위 뿐만 아니라 하드랑 소프트웨어간의 인터페이스
시스템테스트 후에 함 (각 단위 시스템의 테스트 후에 진행)
테스트 대상에선 인터페이스가 제일 중요

❖ 시스템 테스트 (System testing)

▶︎ 전체 시스템(제품)의 작동 상태를 최종 시스템 운영 환경(또는 최대 유사 환경)에서 검증

▶︎ 테스트 베이시스

시스템 & 소프트웨어 (기능, 비기능) 요구사항 명세서
유즈 케이스/기능 명세서
(제품) 리스크 분석
비즈니스 프로세스 모델
시스템 자원 및 OS와의 상호작용 명세서

▶︎ 테스트 대상

시스템(사용자, 운영) 메뉴얼
시스템 구성 및 구성 데이터

▶︎ 수행 가능한 테스트 유형

기능 테스트, 비기능 테스트
구조적 테스트

★ 시스템 테스트
사용자 테스트(제3자테스트)
가급적 사용자 환경에서
테스트 베이시스
-비즈니스프로세스 모델(프로세스를 정리한 문서) ->엔드투엔드테스팅시나리오 설계 가능
시스템 테스팅은
데이터마이그레이션이 끝난 상태에서 테스팅해야함
실제 데이터를 갖고 테스팅해야함
상황이 여유치 않다면 테스트 데이터만 특별히 마이그레이션 해달라 요청할수도 있음

❖ 인수 테스트 (Acceptance testing)

▶︎ 시스템이 사용할 준비가 되어 있는지에 대한 확신을 얻기 위한 테스트

결함을 찾으려는 것이 주 목적은 아니다

▶︎ 테스트 베이시스

사용자 요구사항
시스템 요구사항
유즈케이스, 비즈니스 프로세스
리스크 분석

▶︎ 테스트 대상

비즈니스 프로세스
운영 프로세스, 유지보수 프로세스
Forms, Reports
구성 데이터

▶︎ 인수 테스트 종류

사용자 인수 테스트, 운영 인수 테스트, 규정 인수 테스트
알파 테스트, 베타 테스트

★인수 테스팅

요구사항 대로 시스템이 작용을 하느냐
주로 인수테스팅은 알파,베타로 구분됨
알파 = 테스터가 하는 것
베타 = 훈련받지 않는 특정 사용자들이 정해져 있지 않는 시나리오로 자기들의 목적대로 사용하는 것
필드테스트 : (베타와 같음)
베타중에서도 사용자의 현장이 중요한 것, 현장에 나가서 테스트해라
테스트 베이시스

사용자 요구사항과 시스템 요구사항(사용자 요구사항을 해석한것) 을 분리해놓으면 사용자의 이해와 내가 이해한 것이 다른지 맞는지 확인하기 쉬워짐

내가 뭘 요구했는지(사용자 요구사항) 그걸 어떻게 해석했는지(시스템요구사항)

유즈케이스, 비즈니스 프로세스는 시스템 요구사항을 토대로 설계한 것
테스트 대상 :
비즈니스 프로세스(앤드투앤드)
운영p(만들어진 것들이 잘 작동하게 관리), 유지보수p(수정 및 추가, 변경이 필요한 것)

❖ 개발 단계의 테스트 레벨의 의미 (V-모델, 애자일 )

테스터는
개발 모델에 대해서도 잘 알고 있어야 한다
가장 표준적으로 기본적으로 개발 절차를 표현한 것 : V 모델
리스크가 있다.비용이 많이 드는 방법론, 절차대로 하지 못하느느 경우가 많다
프로젝트:제한된 기간안에 제한된 자원으로 원하는 목표를 달성
소프트웨어 프로젝트의 성공요인 : 납기, 예상 비용을 넘어가지 않음, 품질
납기, 비용은 소프트웨어 성공요인의 정량적 지표임
품질을 보여줄 수 있는 게 테스트 결과서
v모델은 원천적으로 폭포수 모델
각각테스트는 대응하는 개발단계에서 의미있는 테스트베이시스를 참조한다
(v모델이 된이유)

에자일 모델(대중화는 10년전, 나온 건 20년전)
프토젝트단위를 1,4주로 쪼개서 그 안에서 개발, 테스팅 프로세스를 진행하자

우리가 만들려고 하는 핵심을 먼저 생각하고 핵심만 먼저 만드는 것
만일 시장이 변했다? 요구사항을 추가하거나 수정하는 것
장점: 시장의 변화에 빨리 대응할 수 있다.(요즘 시장환경에 적절한 모델)

제품 책임자 vs pm

셀프 컨트롤이 되는 방법론 (에자일 모델)

테스트는 어떻게 달라지나?

매주 혹은 매달 테스팅을 함
제품에 대한 이해도가 높아진다(테스터들)

ACAI BERRY DEVELOVER

쓸때 대충 쓰지 말고! 공부하면서 써!

이전 포스트

[Springboot]-서비스계층과 DTO에 관하여

다음 포스트