개요
오늘은 소프트웨어의 테스트 기법과 원리 그리고 이에 활용되는 다양한 분석 도구와 소프트웨어 재공학(Software Reengineering)에 대해서 알아보도록 하겠습니다.
지난 포스팅에서는 소프트웨어의 개발과 설계 그리고 실제 개발에서 활용되는 다양한 개발 방법론 등에 대해서 살펴 보았는데요.
오늘은 소프트웨어 개발을 위해 열심히 설계하고 만드는 과정을 거쳐 어떤 테스트, 즉 검증 과정을 거쳐야하는지 알아보도록 하겠습니다.
제법 규모가 있는 소프트웨어 회사라면 사내에 별도로 테스트를 전문으로 하는 인력이 존재하기도 합니다.
만들어진 소프트웨어 대해서 꼼꼼히 검증 작업을 수행하고, 결함이나 놓친 부분은 없는 지 체크를 해주는 일을
QA(Quality Assurance)라고 하며, 소프트웨어 뿐만 아니라 제조업에서도 많이 언급되는 개념입니다.
다시 본론으로 돌아와서 하나의 소프트웨어가 만들어진 후에 거치게 되는 알아보도록 하겠습니다.
소프트웨어 테스트란?
소프트웨어 테스트는 주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정
- 소프트웨어 테스팅은 소프트웨어 제품이 요구 사항을 충족하고 예상대로 동작하는지를 확인하기 위한 중요한 단계입니다.
- 테스팅은 소프트웨어의 신뢰성, 안정성, 보안성 및 성능을 보장하며, 버그나 결함을 식별하여 이를 수정하는 과정을 포함합니다.
- 다양한 테스트 수준과 유형이 존재하며, 유닛 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 등이 이에 해당합니다.
- 효과적인 소프트웨어 테스팅은 개발자, 테스터, 그리고 기타 이해 관계자들 간의 협력과 정확한 요구 사항의 이해가 필요합니다.
- 테스트는 소프트웨어 개발 생명주기(Life Cycle)의 일부로 여겨져, 과정 전반에 걸쳐 지속적으로 수행되는 것이 보편적입니다.
- 궁극적으로 이러한 과정은 소프트웨어의 품질을 향상시키고 사용자 만족도를 높이는 데 기여하기 때문입니다.
정적 테스트의 유형
| 유형 | 설명 |
| 동료 검토 (Peer Review) |
2~3명이 진행하는 리뷰의 형태로 요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행하는 검토 기법 |
| 워크 스루 (Walk Through) |
검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서로 만드는 기법 |
| 인스펙션 (Inspection) |
소프트웨어 요구 ,설계, 원시코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법 |
| 관리 리뷰 (Technical Review) |
프로젝트 진행 상황에 대한 전반적인 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사 결정을 지원하는 리뷰 |
| 기술 리뷰 (Technical Review) |
정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행하는 리뷰 변경 사항이 적절하게 구현되었는지를 평가하고, 여러 대안을 추천하거나 대안을 검토 대표 엔지니어가 주재하며 경우에 따라서 관리자도 참가 가능 |
소프트웨어 품질 특성의 종류
- 다음으로 이러한 테스트 기법을 사용하여 점검하는 대표적인 소프트웨어의 품질 특성에 대해서 알아보겠습니다.
| 품질 특성 | 설명 |
| ① 기능성 | - 소프트웨어가 특정 조건에서 사용될 때 명시된 요구와 내재된 요구를 만족하는 기능을 제공하는 소프트웨어 제품의 능력 - 품질 부특성에는 적합성, 정확성, 상호 운용성, 보안성, 준수성 등이 있음 |
| ② 신뢰성 | - 명시된 조건에서 사용될 때 성능 수준을 유지할 수 있는 소프트웨어 제품의 능력 - 옳고 일관된 결과를 얻기 위하여 요구된 기능을 수행할 수 있는 정도이고, 주어진 시간 동안 주어진 기능을 오류 없이 수행하는 정도 - 품질 부특성에는 성숙성, 결함 허용성, 회복성, 준수성 등이 있음 |
| ③ 사용성 | - 명시된 조건에서 사용될 경우, 사용자에 의해 이해되고, 학습되고, 사용되고 선호될 수 있는 소프트웨어의 제품의 능력을 말함 - 품질 부특성에는 이해성, 학습성, 운용성, 친밀성, 준수성 등이 있음 |
| ④ 효율성 | - 명시된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어 제품의 능력 - 품질 부특성에는 시간 반응성, 자원 효율성, 준수성 등이 있음 |
| ⑤ 유지보수성 | - 소프트웨어 제품이 변경되는 능력 - 변경에는 환경과 요구사항 및 기능적 명세에 따른 소프트웨어의 수정, 개선 혹은 개작등이 포함 - 품질 부특성에는 분석성, 변경성, 안정성, 시험성, 준수성 등이 있음 |
| ⑥ 이식성 | - 한 환경에서 다른 환경으로 전이될 수 있는 소프트웨어 제품의 능력 - 품질 부특성에는 적응성, 설치성, 공존성, 대체성, 준수성 등이 있음 |
소프트웨어 검증과 확인
- 한 편, 소프트웨어의 테스트 과정은 검수 목적에 따라서 아래와 같이 두 가지 종류로 구분지을 수 있습니다.
검증 (Verification)
- 소프트웨어 개발 과정을 테스트하는 것.
- 올바른 제품을 생산하고 있는지 검증하는 것이 목적
- 이전 단계에서 설정된 개발 규격과 요구를 충족시키는지 판단한다.
- 개발자 혹은 시험자의 시각으로 소프트웨어가 명세화된 기능을 올바르게 수행하는지 알아보는 과정
확인(Validation)
- 소프트웨어 결과를 테스트하는 것.
- 만들어진 제품이 제대로 동작하는지 확인하는 것이 목적.
- 최종 사용자 요구 또는 소프트웨어 요구에 적합한지 판단한다.
- 사용자 시각으로 올바른 소프트웨어가 개발되었는지 입증하는 과정
소프트웨어의 분석 도구
정적 분석 도구
- 작성된 소스 코드를 실행시키지 않고, 코드 자체만으로 코드 표준 준수 여부, 코딩 스타일 준수 여부, 잔존 결함 발견 여부를 확인하는 코드 분석 도구‘
- ex) pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura가 있음.
정적 테스트 기법의 종류
| 유형 | 설명 |
| 리뷰 (Review) | 소프트웨어의 다양한 산출물에 존재하는 결함을 검출하거나 프로제긑의 진행 상황을 점검하기 위한 활동으로, 전문가가 수행함 |
| 정적 분석 (Static Analysis) | 도구의 지원을 받아 정적 테스트를 수행하는 방법으로 자동화된 도구를 이용하여 산출물의 결함을 검출하거나 복잡도를 측정 |
동적 분석 도구
- 애플리케이션을 실행하여 코드에 존재하는 메모리 누수 현황을 발견하고, 발생한 스레드의 결함 등을 분석하기 위한 도구
- ex) Avalanche, Valgrind
분석 자동화 도구(CASE, Computer-aided software engineering)
시스템 개발 방법론들의 자동화를 지원하는 소프트웨어 도구를 제공해 개발자의 반복적인 작업량을 줄이도록 하는 것
- 컴퓨터 지원 소프트웨어 공학(CASE)은 컴퓨터 지원 시스템 공학이라고도 합니다.
- CASE는 개발자가 소프트웨어를 개발하는 전 과정에 거쳐서 작은 모듈의 단위부터 컴포넌트나 라이브러리의 단위까지
- 소프트웨어에 대한 품질을 체크하고 정상적으로 잘 동작할 수 있도록 검수하는 과정을 돕는 도구입니다.
CASE가 제공하는 기능
- 개발을 신속하게 할 수 있고, 오류 수정이 쉬워 소프트웨어 품질이 향상된다.
- 소프트웨어 생명주기의 전체 단계를 연결해주고, 자동화시켜 주는 통합된 도구를 제공해주는 기술이다.
- 소프트웨어 시스템의 문서화 및 명세화를 위한 그래픽 기능을 제공한다.
- 소프트웨어 개발 단계의 표준화를 기할 수 있으며 자료 흐름도 작성 기능을 제공한다.
- 모델들 사이의 모순 검사 기능을 제공하며, 다양한 소프트웨어 개발 모형을 지원한다.
* CASE의 원천 기술 : 구조적 기법, 프로토타이핑 기술, 정보 저장소 기술
CASE의 종류
| 종류 | 설명 |
| ① 상위 CASE(Upper CASE) | - 요구 분석 및 설계 단계 지원(모델 간 모순 검사 기능, 모델 오류 검증 기능, 자료 흐름도 작성 기능) - 계획수립, 요구분석, 기본설계 단계를 다이어그램으로 표현 - 모델들 사이의 모순 검사 및 모델의 오류 검증, 일관성 검증 지원 - 자료 흐름도 프로토토아핑 작성 지원 및 UI 설계 지원 |
| ② 하위 CASE (Lower CASE) | - 소스 코드 작성, 테스트, 문서화 과정 지원 - 구문 중심 편집 및 정적-동적 테스트 지원 - 시스템 명세서 생성 및 소스 코드 생성 지원 |
| ③ 통합(Integrate) CASE | - 소프트웨어 개발 주기 전체 과정 지원 |
요구사항 분석을 위한 CASE
- 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미
- 표준화와 보고를 통한 문서화 품질 개선, 변경이 주는 영향 추적의 용이성, 명세에 대한 유지보수 비용 축소, 교차 참조도와 보고서
- 를 통한 결함, 생략, 불일치 등의 발견 용이성 등의 특징을 갖습니다.
- DB를 모두가 이용 가능하다는 점에서 분석자들 간의 적절한 조정 기능을 제공합니다.
요구사항 분석을 위한 CASE 도구
| 종류 | 설명 |
| SADT(Structured Analysis and Design Technique) | SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계 도구, 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구 |
| SREM(Software Requirements Engineering Methodology) = RSL/REVS | TRW 사가 우주 국방시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 것으로, RSL과 REVS를 사용하는 자동화 도구 |
| RSL(Requirement Statement Language) | 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어 |
| REVS(Requirement Engineering and Validation System) | RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 분석 명세서를 출력하는 요구사항 분석기 |
| PSL/PSA | 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화된 도구 |
소프트웨어 테스트의 원리
소프트웨어의 테스트 과정은 수많은 개발자에 의해 과거부터 현재까지 수행되어 왔습니다.
다음은 이러한 테스트 과정에서 알아두면 좋은 다양한 소프트웨어 테스트의 원리에 대해서 알아보도록 하겠습니다.
| 원리 | 설명 |
| 결함 존재 증명 | - 테스트는 결함이 존재함을 밝히는 활동 - 결함이 없다는 것을 증명할 수 없음 |
| 완벽 테스팅은 불가능 | - 무한 경로(한 프로그램 내의 내부조건은 무수히 많을 수 있음) - 무한 입력 값(입력 값이 가질 수 있는 모든 조합이 무수히 많음)으로 인한 완벽한 테스트가 어렵다는 원리- |
| 초기 집중 | - 개발 초기에 체계적인 분석 및 설계가 수행되면 테스팅 기간 단축, 재작업을 줄여 개발 기간을 단축 및 결함을 예방할 수 있는 원리 - SW 개발 초기 체계적인 분석 및 설계가 수행되지 못하면 그 결과가 프로젝트 후반에 영향을 미치게 되어 비용이 커진다는 요르돈 법칙 적용(Snowball Effect, 눈덩이 법칙) |
| 결함 집중 | - 적은 수의 모듈(20%)에서 대다수의 결함(80% 결함)이 발견된다는 원리 - 파레토 법칙(Pareto Principle)의 내용인 80대 20 법칙을 적용 |
| 살충제 패러독스 |
- 동일한 테스트 케이스에 의한 반복적 테스트는 새로운 버그를 찾지 못한다는 원리 |
| 정황 의존성 | - 소프트웨어의 성격에 맞게 테스트를 수행해야 한다는 원리 |
| 오류-부재의 궤변 | - 요구사항을 충족시켜주지 못한다면 결함이 없다고 해도 품질이 높다고 볼 수 없다는 원리 |
| 파레토 법칙(Pareto Principle) | - 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 가리킨다. - 예를 들어, 20%의 고객이 백화점 전체 매출의 80%에 해당하는 만큼 쇼핑하는 현상 |
소프트웨어 테스트의 종류
| 종류 | 설명 |
| 단위 테스트 | 사용자 요구사항에 대한 단위 ,모듈, 서브루틴 등을 테스트하는 단계 |
| 통합 테스트 | 단위 테스트를 통과한 모듈 사이의 인터페이스, 통합된 컴포넌트 간의 상호작용을 검증하는 테스트 단계 |
| 시스템 테스트 | 통합된 단위 시스템의 기능이 시스템에서 정상적으로 수행되는지를 검증하는 테스트 단계 |
| 인수 테스트 | 계약상의 요구사항을 만족했는지 확인하기 위한 테스트 단계 |
소프트웨어 테스트 목적에 따른 기법들
| 분류 | 설명 |
| 회복 테스트 (Recovery Testing) |
시스템에 고의로 실패를 유도하여 시스템의 정상적 복귀 여부를 테스트하는 기법 |
| 안전 테스트 (Security Testing) |
불법적인 소프트웨어가 접근하여 시스템을 파괴하지 못하도록 소스 코드 내의 보안적인 결함을 미리 점검하는 테스트 기법 |
| 성능 테스트 (Performance Testing) |
사용자의 이벤트에 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 사용자 요구에 시스템이 반응하는 속도 등을 측정하는 테스트 기법 |
| 구조 테스트 (Structure Testing) |
시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트 기법 |
| 회귀 테스트 (Regression Testing) |
회귀 테스트는 오류를 제거하거나 수정한 시스템에서 오류 제거와 수정에 의해 새로이 유입된 오류가 없는지 확인하는 일종의 반복 테스트 기법 |
| 병행 테스트 (Parallel Testing) |
변경된 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트 기법 |
소프트웨어 검증을 위한 참고 자료 설계 - 명세 기법
정형 명세 기법
- 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법입니다.
- 정형 명세 언어인 Z-스키마, Petri Nets, 상태 차트를 활용합니다.
- 표현이 간결하고, 명확성이 있으며 근거가 명확하여 검증이 용이합니다.
- 하지만, 기법의 이해가 어려울 수 있습니다.
비정형 명세 기법
- 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법입니다.
- 사용자와 개발자의 이해가 용이합니다.
- 하지만, 명확성 및 검증에 때로는 어려움이 생길 수 있습니다.
종합적인 소프트웨어 검증을 위한 두 가지 주요 전략
블랙박스 테스트와 화이트 박스 테스트
블랙박스 테스트와 화이트 박스 테스트는 모두 소프트웨어의 품질을 평가하는 테스트 방법입니다.
블랙박스는 내부 동작을 알지 못하고 기능적인 측면에 중점을 두는 반면, 화이트 박스는 내부 로직과 코드에 집중하여 테스트를 수행합니다.
블랙박스 테스트는 소프트웨어의 외부 동작을 확인하며 사용자 관점에서의 기능, 성능, 신뢰성을 평가하는 반면,
화이트 박스 테스트는 소스 코드의 구조와 내부 동작을 검증하여 로직의 정확성과 효율성을 평가합니다.
블랙박스 테스트(=명세 기반 테스트, Black-Box Test)
- 프로그램 내부 논리 구조를 참고하지 않고, 사용자의 요구사항이나 설계, 명세 등을 이용하여 테스트 케이스를 개발하는 방법입니다.
- 소프트웨어의 특징, 요구사항, 설계 명세서 등에 초점을 맞춰 테스트가 이루어집니다.
- 블랙박스 테스트는 기능 및 동작 위주의 테스트를 진행하기 때문에 내부 구조나 작동 원리를 알지 못해도 가능합니다.
블랙박스 테스트 유형
| 유형 | 설명 |
| 동등분할 테스트=동치분할 테스트, 균등 분할 테스트, 동치 클래스 분해 테스트 (Equivalence Partitioning Testing) |
- 입력 데이터의 영역을 유사한 도메인 별로 유효 값/무효 값을 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트하는 기법 |
| 경곗값 분석 테스트=한곗값 테스트 (Boundary Value Analysis Testing) |
- 등가 분할 후 경곗값 부분에서 오류 발생확률이 높기 때문에 경곗값을 포함하여 테스트 케이스를 설계하여 테스트하는 기법 - 최솟값 바로 위, 최대치 바로 아래 등 입력값의 극한 한계를 테스트하는 기법 |
| 결정 테이블 테스트 (Decision Table Testing) |
- 요구사항의 논리와 발생 조건을 테이블 형태로 나열하여, 조건과 행위를 모두 조합하여 테스트하는 기법 |
| 상태 전이 테스트 (State Transition Testing) |
- 테스트 대상, 시스템이나 객체의 상태를 구분하고, 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법 |
| 유스케이스 테스트 (Use Case Testing) |
- 시스템이 실제 사용되는 유스케이스로 모델링 되어있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행하는 테스트 기법 |
| 분류 트리 테스트 (Classification Tree Method Testing) |
- SW 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하여 테스트하는 기법 |
| 페어와이즈 테스트 (Pairwise Testing) |
- 테스트 데이터 값 간에 최소한 한 번씩을 조합하는 방식이며, 이는 커버 해야할 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구성하기 위한 테스트 기법 |
| 원인-결과 그래프 테스트 (Cause-Effect Graphing Testing) |
- 그래프를 활용하여 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석하여 효용성이 높은 테스트 케이스를 선정하여 테스트하는 기법 |
| 비교 테스트 (Comparison Testing) |
- 여러 버전의 프로그램에 같은 입력값을 넣어서 동일한 결과 데이터가 나오는지 비교해보는 테스트 기법 |
| 오류 추정 테스트 (Error Guessing Testing) |
- 개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트 케이스를 설계하여 테스트하는 기법 - 특정 테스트 대상이 주어지면 테스터의 경험과 직관을 바탕으로 개발자가 범할 수 있는 실수들을 나열하고, 해당 실수에 따른 결함을 노출하는 테스트로 다른 블랙박스 테스트 기법을 보완할 때 사용하는 기법 |
화이트박스 테스트
응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 기법입니다.
| 유형 | 설명 |
| 구문 커버리지 = 문장 커버리지 (State Coverage) |
- 프로그램 내의 모든 명령문을 적어도 한 번 수행하는 커버리지 - 조건문 결과와 관계 없이 구문 실행 개수로 계산 |
| 결정 커버리지=선택 커버리지 (Decision Coverage) = 분기 커버리지 (Batch Coverage) |
- 각 분기의 결정 포인트 내의 전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행하는 테스트 커버리지 - 구문 커버러지를 포함 |
| 조건 커버리지 (Condition Coverage) |
- 각 분기의 결정 포인트 내의 개별 조건식이 적어도 한 번은 참과 거짓의 결과가 되도록 수행하는 테스트 커버리지 - 구문 커버리지를 포함 |
| 조건/결정 커버리지 (Condition/Decision Coverage) |
- 전체 조건식뿐만 아니라 개별 조건식도 참 한 번, 거짓 한 번 결과가 되도록 수행하는 테스트 커버리지 |
| 변경 조건/결정 커버리지 (Modified Condition/Decision Coverage) |
- 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 커버리지 |
| 다중 조건 커버리지 (Multiple Condition Coverage) |
- 결정 조건 내모든 개별 조건식의 모든 가능한 조합을 100% 보장하는 커버리지 |
| 기본 경로 커버리지=경로 커버리지 (Base Path Coverage) |
- 수행가능한 모든 경로를 테스트하는 기법 |
| 제어 흐름 테스트 (Control Flow Testing) |
- 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직을 테스트하는 기법 |
| 데이터 흐름 테스트 (Data Flow Testing) |
- 제어 흐름 그래프에 데이터 사용현황을 추가한 그래프를 통해 테스트하는 기법 |
| 루프 테스트 (Loop Testing) |
- 프로그램의 반복(Loop) 구조에 초점을 맞춰 실시하는 테스트 기법 |
성능 테스트의 유형
만들어진 소프트웨어 얼마나 사용자를 수용할 수 있는지 '성능'을 검사하는 성능 테스트 기법입니다.
| 유형 | 설명 |
| 부하 테스트 (Load Testing) |
시스템에 부하를 계속 증가시키면서 시스템의 임계점을 찾는 테스트 부하 테스트를 통해 병목 지점을 찾아서 병목 현상을 제거하는 과정을 반복하는 테스트 기법 |
| 강도 테스트 (Stress Testing) |
시스템 처리 능력의 이상, 부하, 즉 임계점 이상의 부하를 가하여 비정상적인 상황에서 시스템의 동작 테스트를 확인하는 테스트 |
| 스파이크 테스트 (Spike Testing) |
짧은 시간에 사용자가 몰릴 때 시스템의 반응을 측정하는 테스트 |
| 내구성 테스트 (Endurance Testing) |
오랜 시간 동안 시스템에 높은 부하를 가하여 시스템의 반응을 측정하는 테스트 |
경험기반 테스트 유형
| 유형 | 설명 |
| 탐색적 테스트 (Exploratory Test) |
- 테스트 스크립트 또는 테스트 케이스를 문서로 작성하지 않고 경험에 바탕을 두고 기능을 수행해보며 테스트함. - 사전에 구체적인 테스트 케이스를 설계하고 수행하는 방식은 아니고 테스트 대상에 대한 이해, 케이스 설계, 테스트 실행을 함께 병행. - 무작위 테스팅이 아닌 중대한 테스트 위주, 테스트 엔지니어의 휴리스틱한 능력을 요구. - 구성요소는 테스트 차터, 시간 제한(Time Boxing), 노트(Note), 회고 |
| 오류 추정 (Error Guessing) |
- 개발자가 범할 수 있는 실수를 추정하고 이에 따른 결함이 검출되도록 테스트 케이스를 설계하여 테스트하는 기법 - 특정 테스트 대상이 주어지면 테스터의 경험과 직관을 바탕으로 개발자가 범할 수 있는 실수들을 나열하고, 해당 실수에 따른 결함을 노출하는 테스트로 다른 블랙박스 테스트 기법을 보완할 때 사용하는 기법 |
| 체크리스트 (Checklist) |
- 테스트하고 평가해야할 내용과 경험을 분류하여 나열한 이후 하나씩 확인 - 체계적 도출보다는 경험과 노하우를 정리하고 목록화하여 재사용 |
| 특성 테스트 (Characteristics Test) |
- 국제 표준인 ISO/IEC 9126 등의 품질 모델에 있는 품질 특성을 염두에 두고 경험적으로 테스트 케이스를 설계하고 테스트 - ISO/IEC 9126-2에 명기된 품질 특성 활용 |
테스트에 사용 되는 객체의 유형
소프트웨어의 테스트에는 다양한 데이터의 묶음, 즉 객체(Object)를 사용할 수 있습니다.
| 유형 | 설명 |
| 더미 객체 (Dummy) |
테스트할 때 객체만 필요하고 해당 객체의 기능까지는 필요하지 않은 경우에 사용 더미 객체의 메서드가 호출되면 정상 동작은 수행하지 않고 예외 수행 |
| 테스트 스텁 (Stub) |
제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구로 더미 객체에의 단순 기능에 특정 상태를 가정해서 특정한 값을 리턴하거나 특정 메시지를 출력 |
| 테스트 드라이버 (Driver) |
테스트 대상 하위 모듈을 호출하고, 파라미터를 전달 및 모듈 테스트 수행 후의 결과를 도출 |
| 테스트 스파이 (Spy) |
주로 테스트 대상 클래스와 협력하는 클래스로 가는 출력을 검증하는 데 사용 |
테스트 오라클(Test Oracle)이란?
테스트의 통과 또는 실패 여부를 결정하는 메커니즘.
테스트 오라클의 종류
| 유형 | 설명 |
| 참(True) 오라클 | 모든 입력값에 대해 기대하는 결과를 생성함으로써 발생 된 오류를 모두 검출할 수 있는 오라클 |
| 샘플링(Sampling) 오라클 |
특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해주는 오라클 |
| 휴리스틱(Heuristic) 오라클 |
샘플링 오라클을 개선한 오라클로, 특정 입력값에 대해 올바른 결과를 제공하고 나머지 값들에 대해서는 휴리스틱(추정)으로 처리하는 오라클 |
| 일관성 검사(Consistent) 오라클 | 애플리케이션 변경이 있을 때, 수행 전과 후의 결과값이 동일한지 확인하는 오라클 |
소프트웨어 결함의 종류
소프트웨어에 존재하는 다양한 결함의 종류는 다음과 같습니다.
| 종류 | 설명 |
| 에러/오류 | - 에러는 결함의 원인이 되는 것, 일반적으로 사람(개발자, 분석가)등에 의해 생성된 실수 |
| 결함/결점/버그 | - 에러 또는 오류가 원인이 되어 소프트웨어 제품에 포함되어 있는 것 - 제거하지 않으면 소프트웨어 제품이 비정상적으로 동작하거나 문제를 일으킴 |
| 실패/문제 | - 소프트웨어의 제품에 포함된 결함이 실행될 때 발생할 수 있는 현상들 |
경험 생명주기별 결함 상태
| 결함 상태 | 설명 |
| 결합 등록 (Open) |
테스터가 테스트 절차를 실행하여 발견한 결함을 분석 후 구체화, 고립화, 일반화한 결함으로서 보고된 상태 |
| 결함 검토 (Reviewed) |
Open된 결함의 처리 방안을 검토하는 상태 |
| 결함 할당 (Assigned) |
결함을 수정할 개발자가 결정되고, 그 개발자에게 결함 해결이 요구된 상태 |
| 결함 수정 (Resoloved) |
개발자가 자신에게 할당된 수정 사항에 대한 해결책을 처리한 상태 |
| 결함 확인 (Verified) |
개발자의 결함 처리가 합당한지, 정확한 검증이 완료된 상태 |
| 결함 종료 (Closed) |
수정된 사항에 대하여 정확한 수정이 이루어졌다고 판단되어 종료된 상태 |
| 결함 재등록 (Reopen) |
결함이 정확하게 수정되지 않아서 다시 수정을 요구하는 상태 |
| 결함 조치 보류 (Deferred) |
Open된 결함을 곧바로 수정하지 않고 다음 릴리스에서 해결하기로 연기된 상태 Deferred된 결함은 적절한 시점에 Reopen되어 결함 처리가 시작될 수 있음 |
애플리케이션 모니터링 툴(APM, Applcation Performance Management)
인터페이스의 동작이 잘 진행되는지 지속적으로 확인하기 위해서 사용하는 감시 도구
데이터베이스, 웹 애플리케이션의 트랜잭션과 변수 값, 호출 함수, 로그 및 시스템 부하 등 종합적인 정보를 조회하고, 커넥션 풀(Connection Pools)등 지속적인 모니터링이 필요한 자원을 효과적으로 관리하는 도구
인터페이스 감시 도구(Interface Monitoring Tools)
| 도구 | 설명 |
| 스카우터 (SCOUTER) |
애플리케이션에 대한 모니터링 및 DB Agent를 통해 오픈소스 DB 모니터링 기능, 인터페이스 감시 기능을 제공 |
| 제니퍼 (Jennifer) |
애플리케이션의 개발부터 테스트, 오픈, 운영, 안정화까지 전 생애주기 단계 동안 성능을 모니터링하고 분석해주는 APM 소프트웨어 |
인터페이스 구현 검증 도구
| 도구 | 설명 |
| xUnit | - 자바(JUnit), C++(Cppunit), .Net(Nunit) 등 다양한 언어를 지원하는 단위 테스트 프레임워크 - 소프트웨어의 함수나 클래스 같은 서로 다른 구성원소를 테스트할 수 있게 해주는 도구 |
| STAF | - 서비스 호출, 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크 - 각 테스트 대상 분산 환경에 데몬을 사용하여 테스트 대상 프로그램을 통해 테스트를 수행하고, 통합하며 자동화하는 검증도구 |
| FitNesse | - 웹 기반 테스트 케이스 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임 워크 - 사용자가 테스트 케이스 테이블을 작성하면 빠르고 편하게 자동으로 원하는 값에 대해 테스트틀 할 수 있다는 장점이 있음 |
| NTAF | - FitNesse의 장점인 협업 기능과 STAF 의 장점인 재사용 및 확장성을 통합한 NHN(Naver)의 테스트 자동화 프레임워크 |
| Selenium | - 다양한 브라우저 지원 및 개발 언어를 지원하는 웹 어플리케이션 테스트 프레임 워크 - 테스트 스크립트 언어를 학습할 필요 없이 기능 테스트를 만들기 위한 도구 제공 |
| watir | - 루비(Ruby) 기반의 웹 어플리케이션 테스트 프레임워크 - 모든 언어 기반의 웹 어플리케이션 테스트와 브라우저 호환성 테스팅 가능 |
소프트웨어 재공학(Software Reengineering)이란?
- 소프트웨어 위기를 개발의 생산성이 아닌 유지보수의 생산성으로 해결하려는 방법을 의미합니다.
- 재구조화는 재공학의 한 유형으로 사용자의 요구사항이나 기술적 설계의 변경 없이 프로그램을 개선하는 것입니다.
- 소프트웨어 재공학 관점에서 가장 연광 깊은 유지보수 유형은 예방 유지보수(Preventative Maintenance)하는 것입니다.
- 소프트웨어 재공학의 목적은 소프트웨어의 재사용을 수월하게 하며, 소프트웨어의 수명을 연장하기 위해서입니다.
재공학의 장점
① 개발 시간과 비용을 감소시킵니다.
② 프로젝트의 실패의 위험을 감소 시킵니다.
③ 소프트웨어의 품질 및 생산성을 향상 시킵니다.
④ 구축 방법에 대한 개발 지식을 공유할 수 있습니다.
재공학의 과정
| 과정 | 설명 |
| 분석(Analysis) | 기존 소프트웨어의 명세서를 확인하여 소프트웨어의 동작을 이해하고 재공학 대상을 선정하는 것 |
| 재구성(Restructuring) | 소프트웨어 구조를 향상시키기 위해 코드를 재구성하는 것. |
| 역공학(Reverse Engineering) | 원시 코드를 분석하여 소프트웨어 관계를 파악하고, 기존 시스템의 설계 정보를 재발견하여 다시 제작하는 작업 |
| 이식(Migration) | 기존 소프트웨어 시스템을 새로운 기술 또는 하드웨어 환경에서 사용할 수 있도록 변환하는 작업 |
소프트웨어 재사용의 2가지 기본 기술
| 기술 | 설명 |
| ① 생성 중심 (Generation Based, 모듈화) |
재사용 단위를 찾아 발전시키는 기술로, 전자칩과 같은 유용한 소프트웨어 부품을 찾아내는 기술 |
| ② 합성 중심 (Composition Based, 모델화) |
모듈을 생산성 있게 조립하는 기술, 전자칩 같은 소프트웨어를 부품, 즉 블록(모듈)을 만들어서 끼워 맞추는 방식으로 소프트웨어를 완성시키는 기술 |
리팩토링(Refactoring)이란?
- 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것을 의미
소프트웨어 테스트 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. 소프트웨어 테스트(영어: software testing)는 주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 소프트웨어 테스
ko.wikipedia.org
컴퓨터 지원 소프트웨어 공학 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전. CASE 툴의 예. 컴퓨터 지원 소프트웨어 공학(computer-aided software engineering: CASE)은 컴퓨터 지원 시스템 공학이라고도 하는데 시스템 개발 방법론들의 자동화를 지원
ko.wikipedia.org
Software for the window and door industry | Soft Tech
Software for the window and door industry - Window and door design software for residential, commercial and shop fronts.
softtech.com
https://en.wikipedia.org/wiki/Structured_analysis_and_design_technique
Structured analysis and design technique - Wikipedia
From Wikipedia, the free encyclopedia SADT basis element. Structured analysis and design technique (SADT) is a systems engineering and software engineering methodology for describing systems as a hierarchy of functions. SADT is a structured analysis modell
en.wikipedia.org
https://en.wikipedia.org/wiki/TRW_Inc.
TRW Inc. - Wikipedia
From Wikipedia, the free encyclopedia American industrial company This article is about the former company. For the automotive company with a similar name, see TRW Automotive. TRW Inc., was an American corporation involved in a variety of businesses, mainl
en.wikipedia.org
https://en.wikipedia.org/wiki/Test_oracle
Test oracle - Wikipedia
From Wikipedia, the free encyclopedia In computing, software engineering, and software testing, a test oracle (or just oracle) is a mechanism for determining whether a test has passed or failed.[1] The use of oracles involves comparing the output(s) of the
en.wikipedia.org
'CS BASIC > 소프트웨어 설계와 방법론' 카테고리의 다른 글
| [CS BASIC] 익스트림 프로그래밍(XP, eXtreme Programming) (1) | 2023.12.30 |
|---|---|
| [CS BASIC] 사용자 요구 사항(User Requirements)과 사용자 인터페이스(User Interface) (1) | 2023.12.29 |
| [CS BASIC] 개발 일정 관리 모델(Development Managing Model)과 다양한 개발 도구(Development Kit)들 (1) | 2023.12.26 |
| [CS BASIC] COCOMO, 자료흐름도(DFD), 자료 사전(DD), 코드 설계(Code Design) (1) | 2023.12.25 |
| [CS BASIC] 모델(Model)과 UML, 다이어그램(Diagram) (1) | 2023.12.24 |
