dev + qa = hq sw dev + qa = hq sw

이상적인 지속적 통합은, 코드가 빌드되면 모든 자동화 테스트가 수행되어 '소프트웨어가 잘 작동하는지'와 '코드 변경에 의해 문제가 생기지 않았는지'를 확인한다 위 조건에 부합하기 어렵게 만드는 지속적 통합의 2가지 목적이 있다 1. CI 프로세스는 빠른 피드백을 얻기 위해 자주 수행되어야 한다 2. 매 빌드마다 전체 코드를 검증해야한다 자동화 테스트 설계, 구현, 유지에 있어서 깊은 주의가 필요하며, 하루에 여러번 실행되는 CI 프로세스에 모든 자동화 테스트를 수행하기에는 너무 오래 걸릴 수가 있다 이러한 문제점에 대한 여러 해결책들을 알아보도록 하자 1. 리스크 기반 테스트(RBT) 접근법을 적용하여, '기본 & 중요 테스트'를 우선 순위로 지정하고 항상 수행 리스크 기반 테스트는 제품의 특성(feat..

테스트 베이시스 테스트 분석 및 설계의 기초로 사용되는 지식 체계 테스트 분석, 설계 단계의 논리적인 케이스로 테스트 케이스 설계를 위한 기준이 되는 문서 (ex. 요구사항 명세서, 관련 기준 또는 표준) 요구사항을 내포하고 있는 모든 문서 테스트 컨디션 테스트 베이시스로 식별된 구성 요소 또는 시스템의 테스트 가능한 측면 테스트 케이스에 대한 트랜잭션, 기능 또는 구조적 요소와 같은 기능을 포함할 수 있는 특정 제약 조건 집합 특정 테스트 목적 달성과 관련있는 테스트 베이시스의 한 측면 하나 이상의 테스트 케이스에 의해 검증될 수 있는 컴포넌트나 시스템의 항목 또는 이벤트 (ex. fuction, transaction, quality attribute, 또는 structural element 등) 테스..

용도에 따라 적절한 툴 또는 프레임워크를 사용해야한다 예를 들어, 유닛 테스트와 기능 테스트는 본질적으로 다르다 유닛 테스트는 코드 내의 function과 method에 직접적으로 접근할 수 있으며, 기능 테스트는 여러 버전의 제품을 접할 수 있다 → 다양한 테스트 툴/프레임워크/솔루션이 필요 같은 Repository에 저장하는 경우 코드와 유닛테스트는 항상 같은 Repo에 저장되어야 한다 유닛 테스트는 소스코드에 의존 같은 언어로 작성되어야 한다 코드 변경이 있을 시, 유닛 테스트도 업데이트! 같은 언어로 작성 & 모든 소스코드가 한 개의 Repo에 저장되어있다면, 기능 테스트도 코드와 같은 Repo에 저장하는 것을 추천 (함께 버전 관리 가능) 다른 Repository에 저장하는 경우 소스코드와 다른..

프레임워크 사전적 정의, 복잡한 문제를 해결하거나 서술하는 데 사용되는 기본 개념 구조 (뼈대, 골조) 소프트웨어 프레임워크 소프트웨어 개발자가 응용 소프트웨어의 표준 구조를 구현하기 위해 사용 애플리케이션 프레임워크 프로그래밍에서 특정 운영 체제를 위한 응용 프로그램 표준 구조를 구현하는 클래스와 라이브러리 모임 공통적인 개발 환경 제공 (개발 시간 ↓ 리소스 비용 ↓ 생산성 ↑) 프로세스 프레임워크 규모나 복잡성에 관계없이 모든 소프트웨어 프로젝트에 적용 할 수 있는 소수의 프레임워크 활동을 식별 → '완전한 프로세스'의 기본 구조 구축 ex. 스크럼, 테스트 자동화 프레임워크 테스트 프레임워크 = 자동화 테스트 프레임워크, 테스트 자동화 프레임워크 테스트 케이스를 생성 및 설계하기 위한 가이드라인,..

테스트 설계 기법 테스트 케이스를 도출, 설계하는데 사용하는 절차 테스트 컨디션, 테스트 케이스, 테스트 데이터를 식별 테스트 케이스를 도출하고 테스트 대상이 어느 수준까지 테스팅되었는지 확인 (보장성 확보) 기법 선택 요인 테스트 대상 시스템의 종류 컴포넌트/시스템의 복잡도 규제 기준 고객/계약 요구사항 유즈케이스 모델 리스크 수준/유형 사용 가능 문서 테스터 지식 및 역량 사용 가능 문구 시간, 예산 소프트웨어 개발 수명주기 예상되는 결함 유형

테스트 프로세스를 구성하는 주요 활동 테스트 계획 - 테스트 모니터링 및 제어 - 테스트 분석- 테스트 설계 - 테스트 구현 - 테스트 실행 - 테스트 완료 테스트 계획 테스팅의 목적 & 정황으로 인한 제약 사항을 고려해 테스트 목적을 달성하기 위해 필요한 접근법을 정의하는 활동 적합한 테스트 기법 및 작업 명시 테스트 일정 수립 작업산출물 = 하나 이상의 테스트 계획 (+ 테스트 베이시스에 대한 정보 포함) 테스트 모니터링 및 제어 테스트 계획에 정의된 테스트 메트릭을 기반하여 모니터링 → 실제 & 계획을 지속적으로 비교 시간이 지나면서 업데이트 될 수 있는 테스트 계획의 목적 달성을 위해 필요한 활동을 수행 + 테스트 종료 조건 평가 (명시된 커버리지 조건 대비 테스트 결과 & 로그 확인 - 품질 수..

테스트 유형 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합 테스트 요구사항을 가장 효율적으로 다루는 적절한 방법을 사용하여, 주어진 레벨에 적용되는 접근 방식 및 기술 주요 목표에 따라 테스팅은 여러 유형으로 나누어진다 기능 테스트 방식으로 기능 요구사항을 어느정도 준수하는지 평가하는 테스트 블랙박스 방법 적용 & 모든 레벨에서 수행 처리하는 '과정'보다 '결과' 중시 기능성 테스트 프로세스 1. 소프트웨어가 수행할 기능들 열거 2. 기능 사양(specifications)에 따라 입력 데이터 구성 3. 기능 사양에 따라 출력값 결정 4. 테스트 케이스 실행 5. 실제 출력값과 예상된 출력값 비교 성능 테스트 대상 테스트 항목에 필요한 부하를 발생시켜, 테스트 실행 동안 성..

블랙 박스 테스트 애플리케이션의 내부적 작동 방식과 입력값 처리 방식에 대한 지식 없이 에 초점을 맞춤 목적: 소프트웨어의 기능이 올바르게 작동하고 사용자 요구를 충족하는지 확인 모든 테스트 레벨에 적용할 수 있지만, 대부분 단위 및 통합 테스트에 사용 외부로 노출되는 기능과 비기능에 대한 테스트 중점 ex. 자동차 테스트: 차가 잘 가는지 속도, 주행 능력 등을 테스트 화이트 박스 테스트 애플리케이션의 일부 구조적 부분에 대한 테스트를 수반하므로, 코드에 대한 깊은 지식이 필요 일반적으로, 코드 작성에 직접 관여하는 개발자가 테스트 담당 목적: 과 를 강화하고, 과 을 향상 주로, 시스템, 사용자 승인 테스트 수준에서 사용 ex. 자동차 테스트: 차의 엔진이 제대로 작동하는지 조향장치와 같이 내부 구조..