Study_Note

순차적 개발 모델(sequential development model)순차적 개발 모델은 소프트웨어 개발 과정에서 각 단계를 순차적으로 진행하는 접근 방식으로, 대표적으로 폭포수 모델과 V-모델이 있습니다. 이들 모델은 각 단계에서 명확한 산출물이 나오고, 이전 단계가 완료된 후에야 다음 단계로 넘어가는 구조를 가지고 있습니다. 이 글에서는 폭포수 모델과 V-모델을 비교하고, 각 모델의 특징을 설명하겠습니다.폭포수 모델 (Waterfall Model)폭포수 모델은 소프트웨어 개발 생명 주기 중 가장 오래된 전통적인 모델입니다. 요구사항 분석에서부터 설계, 코딩, 테스트, 유지보수에 이르는 전체 과정을 순차적으로 진행하는 방식으로, 각 단계가 명확하게 구분되어 있습니다.주요 단계요구사항 분석소프트웨어가 제..

테스트 모니터링/제어 및 테스트 종료(test monitoring/control and test closure)위험 분석은 테스트 전반에 걸쳐 중요한 역할을 하며, 특히 테스트 모니터링, 제어 활동, 테스트 종료 단계에서 그 중요성이 더욱 부각됩니다. 위험 수준이 높은 기능에 대해서는 보다 철저한 모니터링과 신속한 제어가 이루어져야 하며, 테스트 종료 시에도 별도의 보고가 요구될 수 있습니다. 이를 통해 테스트의 효율성을 높이고, 중요한 기능이 적절히 검증되었는지 확인할 수 있습니다.테스트 모니터링 및 제어테스트 진행 중 모니터링과 제어는 위험 수준을 고려하여 보다 세밀하게 이루어져야 합니다. 특히, 위험도가 높은 기능에 대한 테스트 진행 상황은 더욱 면밀히 살펴보아야 하며, 이를 위해 다양한 메트릭을 ..

테스트 실행 및 결함 보고 (Run tests and report defects)위험 분석 결과는 테스트 실행과 결함 보고 과정에서도 중요한 역할을 한다. 이는 위험 수준에 따라 테스트 우선순위를 정하고, 결함 관리에서 심각도와 우선순위를 반영해 효과적인 문제 해결을 도모하는 것이다. 다음은 위험 기반 테스트에서 테스트 실행 및 결함 보고 절차를 보다 상세하게 정리한 내용이다.1. 테스트 절차 선택위험 수준이 높은 피처에 대해 우선적으로 테스트를 실행한다. 이는 해당 피처가 중요한 기능을 포함하거나, 실패 시 시스템에 미치는 영향이 크기 때문에 먼저 테스트해야 할 필요성이 있다는 것을 의미한다.테스트 설계 및 구현 단계에서 다양한 테스트 절차가 개발되지만, 위험 수준이 높은 피처와 연관된 테스트 절차를 ..

테스트 계획 (test plan) 테스트 레벨/유형 결정테스트 강도는 테스트 레벨과 유형을 결정하는 중요한 요소이다. 고강도 테스트 또는 균형적 테스트로 분류된 피처는 모든 테스트 레벨에 걸쳐 테스트가 적용된다. 이는 해당 피처와 관련된 모듈들을 대상으로 컴포넌트 테스트를 수행한 후, 해당 모듈들이 통합된 시나리오에 대해 통합 테스트를 진행하고, 최종적으로 시스템 테스트까지 수행하는 방식이다. 만약 피처가 비기능적 특성을 지닌다면, 비기능 요구사항에 맞춘 유형 테스트가 추가될 수 있다. 예를 들어, 성능 관련 피처가 고강도 테스트로 분류되면 컴포넌트, 통합, 시스템 테스트에서 성능 테스트가 추가적으로 수행될 수 있다. 반면, 부가적 테스트 등급에 해당하는 피처는 컴포넌트 및 통합 테스트 단계에서는 제외될..

위험 기반 테스트 수행 (Perform risk-based testing)위험 기반 테스트(Risk-Based Testing, RBT)는 자원이 제한된 상황에서 효율적이고 효과적인 테스트 계획을 수립하는 데 사용되는 기법입니다. 이 접근 방식은 결함 발생 가능성과 결함이 시스템에 미치는 영향을 분석하여, 가장 중요한 기능에 테스트 자원을 집중하는 것을 목표로 합니다. 위험도는 보통 세 가지 기준인 발생 가능성, 심각성, 긴급성으로 평가되며, 각 항목은 1부터 5까지의 값을 가질 수 있습니다. 이를 통해 산출된 위험도는 1에서 125까지의 값을 가질 수 있습니다. 이 값은 다음과 같은 방식으로 산정됩니다. RBT - risk analysis위험분석(Risk Analysis)위험 요소 식별 (Identify..

위험분석(Risk Analysis)위험 요소 식별 (Identifying Risk Factors)위험 분석 기반 테스트를 수행할 때, 첫 단계는 테스트가 필요한 피처들을 모두 나열하는 것이다. 이 과정은 테스트 범위를 설정하기 위한 출발점이 되며, 시스템의 기능적 및 비기능적 요소들이 모두 포함된다. 이렇게 식별된 피처들은 이후 위험 분석의 대상이 되며, 위험 분석 결과에 따라 테스트 계획이 수립된다. 피처들은 소프트웨어 요구사항 명세서를 바탕으로 식별할 수 있다. 요구사항 명세서는 시스템이 충족해야 할 기능적 요구사항뿐만 아니라 성능, 신뢰도, 가용성, 보안성과 같은 비기능적 요구사항도 포함하고 있다. 이 명세서는 테스트의 기준이 되는 중요한 문서이므로, 여기 나열된 요구사항들을 우선적으로 테스트할 피..

위험 기반 테스트 (risk-based testing, RBT)소프트웨어 위험기반 테스트는 잠재적인 위험을 식별하고 그에 따라 테스트 우선순위를 결정하는 테스트 전략입니다. 즉, 소프트웨어의 가장 중요한 부분, 가장 실패할 가능성이 높은 부분 또는 가장 큰 영향을 미치는 부분을 중점적으로 테스트하는 방식입니다. 모든 기능을 균등하게 테스트하는 것이 아니라, 위험이 큰 부분에 더 많은 자원을 집중하여 프로젝트의 품질을 보장하는 것이 핵심입니다. 소프트웨어 프로젝트는 일반적으로 제한된 시간과 비용 내에서 완료되어야 하며, 이를 효율적으로 관리하지 않으면 프로젝트 품질이 저하될 수 있습니다. 따라서 모든 소프트웨어 기능을 테스트하는 것은 이상적이지만, 현실적으로는 불가능한 경우가 많습니다. 이를 해결하기 위해..

이식성 테스트 (Portability Test)이식성 테스트는 특정 소프트웨어가 다양한 하드웨어 및 소프트웨어 환경에서도 동일하게 작동하는지를 확인하는 과정입니다. 주된 목적은 다양한 운영체제(OS), 브라우저, 장치(예: 태블릿, 스마트폰) 등에서 서비스나 애플리케이션이 문제 없이 일관된 사용자 경험을 제공하는지 검증하는 것입니다. 이식성 테스트는 디지털 환경이 점점 복잡해짐에 따라 그 중요성이 높아지고 있습니다.이식성 테스트의 필요성오늘날의 소프트웨어는 단일 플랫폼에서만 동작하는 것이 아니라, 여러 운영체제나 브라우저, 다양한 크기의 화면을 가진 장치에서도 사용됩니다. 이를테면, 웹 애플리케이션은 윈도우와 맥OS 같은 서로 다른 데스크탑 운영체제뿐만 아니라 iOS와 안드로이드 같은 모바일 환경에서도 ..

유지보수성 테스트(maintainability test)유지보수성 테스트는 시스템이 변경 요구를 얼마나 잘 수용할 수 있는지를 평가하는 과정입니다. 소프트웨어는 사용 중 반드시 변경 요구가 발생하게 되며, 유지보수성은 이러한 요구를 효율적으로 만족시키는 능력을 의미합니다. 유지보수성 테스트는 이 능력을 검증하기 위한 테스트입니다. 일반적으로 시스템 변경 요구는 다음과 같은 경우에 발생합니다.기능 개선 및 추가 : 기존 기능을 개선하거나 새로운 기능을 추가하기 위한 작업으로, 전체 시스템 변경 작업 중 약 50%를 차지합니다.변경된 환경에 적응 : 운영체제, 인프라, 기타 환경 변화에 맞춰 시스템을 수정하는 작업으로, 약 25%의 비중을 차지합니다.오류 수정 : 발견된 소프트웨어 오류를 수정하는 작업으로,..

LCOM(Lack of Cohesion of Methods)에는 여러 가지 종류가 있으며, 각 종류는 클래스 내의 응집도를 측정하는 방법이 다릅니다. 주요 LCOM 종류는 다음과 같습니다: LCOM1 (Henderson-Sellers 방식)특징클래스의 메소드 쌍들이 얼마나 많은 인스턴스 변수를 공유하는지 측정합니다.기본 개념은 클래스 내에 있는 메소드들이 얼마나 서로 관련성이 있는지를 확인하는 것입니다.계산 방식클래스의 각 메소드가 사용하는 인스턴스 변수들을 분석하여, 공통된 변수를 사용하지 않는 메소드 쌍의 수를 세어 LCOM을 계산합니다.만약 모든 메소드가 모든 인스턴스 변수를 공유하고 있으면, LCOM 값은 0이 됩니다.메소드 쌍이 변수를 공유하지 않는 경우의 수가 많을수록 LCOM 값은 증가합니다..