소프트웨어 테스팅의 기본

October 18, 2022

소프트웨어 테스팅의 기초

💡 요구사항이란?(= 기획서, 명세서) : 독립적인 시각을 제공한다

오류의 정의

소프트웨어가 요구사항에서 동작해야 하는 일을 수행하지 않는다.
소프트웨어가 요구사항에서 동작하지 않아야 하는 일을 수행한다.
소프트웨어가 요구사항에서 언급하지 않은 일을 수행한다.
소프트웨어가 요구사항에서 언급하지 않지만 해야하는 일을 수행하지 않는다.
소프트웨어가 테스터 관점에서 이해하기 어렵거나, 사용하기 힘들고, 속도가 느리다면 사용자에게
편리하게 보이지 않을 것이다.

💡 오류 : 사람의 실수로 발생 (보편적으로 사용하는 용어 : 이슈, 버그, 결함)

오류의 발생 원인

인간의 실수

요구사항 오류 및 변경
시간적 압박
복잡한 코드 및 기반 환경
기술 및 시스템 변경
시스템 상호간의 연동
소프트웨어 또는 시스템 코드에 결함의 모든 것

환경적 요인

방사능, 자기장, 전기장장, 물리적 오염 등에 의한 소프트웨어 결함

💡 결함 : 오류에 의해 발생
💡 장애 : 예상과 다르게 동작함, 결함이 있는 소프트웨어 실행 시 발생 (모든 결함이 장애가 발생하진 않는다.)

소프트웨어 테스팅의 필요성

개발된 제품 요구사항 충족 여부 확인
제품 품질 수준 확인
금전적 손실
전체 비용 절감

: 마지막 운영 단계에서 테스팅을 할 경우, 테스트 기간 동안 사용자가 제품을 사용하지 못하는 기간의 금전적 손실이 발생하기 때문에 전체적인 비용이 절감된다.

소프트웨어 테스팅의 정의

응용프로그램 또는 시스템이 잘 작동하는지 확인하는 행위(전통적인 개념)
사용자의 기대 수준과 요구사항에 맞게 구현되고 동작하는 지를 확인하고 이를 통해 결함을 발견, 최종적으로 결함의 원인으로 프로젝트 리스크에 대한 수치적인 판단 근거를 의사결정권자에게 전달(현재의 개념)

테스트 기본 목적

잔존 결함 발견
명세 충족 확인
사용자 및 비즈니스의 요구 충족 확인
결함 예방

테스트 상세 목적

품질 수준에 대한 자신감 획득과 정보 제공
비즈니스 리스크를 감소시키는 정보에 근거한 조언 제공
발견된 결함 기반의 수치적 데이터 활용(ex: QA Status Report)
개발 프로세스 점검, 이슈 제기
논리적 설계의 구현 검증
시스템과 소프트웨어가 적절히 동작함을 확인

테스팅 관점에 따른 테스팅 목적

개발 과정 테스팅 : 소프트웨어의 결함을 찾아 내고 수정하기 위해서 가능한 많은 문제의 원인을 발생시키는 것
인수 테스팅 : 예상된 대로 시스템이 동작하는지 확인(요구사항과 일치여부 확인 후 인수 여부 확인)
소프트웨어의 품질을 평가하기 위한 테스팅: 특정 시간에 시스템을 출시하는 것의 리스크를 개발 프로젝트 관련자에게 전달
유지보수 테스팅 : 개발 과정에서 변경 작업이 일어나는 경우 새로운 오류가 유입되었는지 확인(회귀 테스팅)
운영 테스팅 : 사용자가 제품 사용 시 신뢰성 또는 가용성을 평가

소프트웨어 테스팅의 일반 원리

개발 초기에 테스팅을 시작하며, 결함 존재 여부 밝히는 활동
완벽한 테스팅은 불가능
결함이 집중된 곳에 리스크가 많이 발생
살충제 패러독스 : Test Case를 업데이트 해야 함(같은 살충제를 발포할 경우 점차 변화가 줄어든다)
정황에 의존적 : 상황마다 테스트가 다르다
오류 부재의 궤변 : 결함이 없어도 요구사항을 만족하지 못하거나, 사용성이 낮으면 품질이 높다고 말할수 없다.

테스트 유형

목적 : 가장 일반적인 구분

기능 테스트 : 소프트웨어의 기능 요구사항을 확인
비기능 테스트 : 소프트웨어 시스템의 성능, 안전성, 확장성 등 비기능적 측면을 확인
구조 테스트 : 소프트웨어가 어떻게 구성되었는지 확인 (= 화이트박스 테스트)
확인/리그레션 테스트(테스트 자동화에 적합)
- 확인 테스팅 : 결함에 대한 수정이 이루어 졌는지에 대한 확인 테스팅 문제가 해결되었는지 확인하기 위해 이전에 실패한 테스트를 다시 수행하는 것
- 리그레션 테스팅 : 수정으로 인해 변경되지 않은 SW영역에 새로운 결함이 유입되었는지, 또는 기존에 숨어있던 결함이 노출되지 않았는지를 확인하기 위해 이전에 테스트 된 프로그램을 다시 테스트 하는 것
회귀 테스트 : 의도하지 않은 변경을 찾음
모니터링 테스트

테스트 단계 : 순차적 개발 모델인 V-모델상에서의 구분

단위, 모듈 테스트 : 시스템을 구성하는 당위 모듈을 테스트 대상으로 해서 개별 단위 모듈을 독립적으로 테스트
통합 테스트 : 시스템을 구성하는 단위 모듈들이 정확하게 통합되었는지에 초점 두고, 시스템 내부 구성 모듈과 이들 간의 관계를 정의한 구조 설계 명세서를 바탕으로 테스트 진행
시스템 테스트 : 전체 시스템을 테스트 대상으로 하여 테스트가 진행. 요구사항 명세서에 명시된 방식대로 시스템이 동작하는지 확인
인수 테스트 : 사용자의 관점에서 고객이 기대하는 방식으로 소프트웨어가 동작하는지 확인

테스트 설계

동적테스트(Validation)
- 명세 기반 : 명세를 바탕으로 테스트 케이스 생성
- 구조 기반 : 프로그램 코드 정보를 바탕으로 테스트 케이스 생성
- 경험 기반 : 테스터의 경험을 기반으로 테스트 케이스 생성
정적 테스트(Verification)
- 리뷰 : 산출물에 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검
- 정적 분석 : 자동화된 도구를 이용하여 산출물의 결함을 검출하거나 복잡도를 측정

테스트 방법

블랙박스 테스트 : 소스코드, 내부 구조를 참고하지 않고 사용자의 요구사항이나 테스터의 경험 기반으로 TC를 결정하는 방법
화이트박스 테스트 : 구현된 소스코드와 내부 구조를 바탕으로 TC를 결정하는 방법

테스트 실행 여부

동적 테스트 : 실제 구현된 프로그램을 실행하여 테스팅하는 방법
정적 테스트 : 소프트웨어를 실행하지 않고 테스팅하는 기법(실제 시스템이 구현되기 전에 요구사항 정의서, 설계서 소스코드 등의 개발 산출물을 테스팅하는것을 의미)

테스트 기법

정적 테스팅의 종류 : 코드 리뷰, 인스펙션(Inspection), 워크쓰루(Walk-through)

코드 리뷰 : 초기 단계에서 소스 코드의 오류 또는 결함을 찾고 수정하기 위한 계획적인 검사
인스펙션 : 특정 코드 또는 산출물의 결함을 발견하기 위해 훈련된 팀원이 잘 정의된 프로세스를 가지고 수행하는 일종의 공식적인 동료 검토
워크쓰루 : 설계자 또는 개발자 주도하에 개발팀원을 모아 놓고 수행하는 공식적인 동료 검토 활동으로 팀원들이 질문을 통해 표준위반 또는 결함을 발견하고 코멘트하는 형태

동적 테스팅의 종류

단위 테스팅
통합 테스팅
시스템 테스팅
인수 테스팅

동적 테스팅과 디버깅

동적 블랙박스 테스팅 : 소프트웨어 내부 코드에 대한 동작 스펙을 알지 못하는 상태에서 수행하는 테스팅
동적 화이트박스 테스팅 : 소프트웨어 내부 코드를 검토하면서 수행하는 테스팅(구조적 테스팅, 컴포넌트나 시스템의 구조)

동적 화이트박스 테스팅과 디버깅의 차이

버그를 찾아낸다는 점에서 동일하나 디버깅의 목표는 버그를 수정하기 위한 목적

참고자료

https://m.blog.naver.com/dktmrorl/222121510562
https://webclub.tistory.com/458