일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 파이썬
- 위험 기반 테스트
- maintainability test
- 자동화
- 테스트케이스
- SQA
- 유지보수성 테스트
- test
- 비기능테스트
- QA
- testcase
- Software life cycle model
- ISTQB
- agile
- 셀레니움
- 품질
- regression test
- 테스트 케이스
- 애자일
- RBT
- csts
- seleium
- risk-based testing
- testing method
- 테스트 설계 기법에 따른 분류
- 테스트
- Test Case
- Python
- selenium
- Testing
- Today
- Total
목록분류 전체보기 (95)
Study_Note

애자일 스크럼 (agile - scrum) 애자일 스크럼은 반복적이고 증분적인 개발 방법론으로, 작은 팀이 일정 기간 동안 일하는 프로세스를 중심으로 합니다. 각각의 스프린트(Sprint)라 불리는 이러한 기간 동안에는 팀이 완전한 제품 기능을 제공하는 것이 목표입니다. 다음은 애자일 스크럼의 주요 구성 요소와 예시를 보여줍니다. [구성 요소] 스크럼 팀(Team) 작은 규모의 팀으로 구성되며, 팀 멤버들은 서로 다른 역할을 가질 수 있습니다. 예를 들어, 개발자, 테스터, 디자이너 등이 포함될 수 있습니다. 스크럼 마스터(Scrum Master) 팀을 이끄는 역할을 수행하며, 스크럼 프로세스를 관리하고 팀이 최적의 결과를 얻을 수 있도록 지원합니다. 제품 소유자(Product Owner) 제품의 비전을..

애자일 개발 방법론 (agile development methodology) 애자일 개발 방법론은 소프트웨어 개발 프로세스에서 유연성과 반복적인 접근을 강조하는 방법론입니다. 애자일은 초기에는 소프트웨어 개발에서의 워터폴(Waterfall) 방식과 대비되며, 빠르게 변화하는 요구 사항과 비즈니스 환경에 더 잘 대응할 수 있도록 설계되었습니다. 아래는 애자일 개발 방법론의 주요 특징과 원칙을 설명한 것입니다. 고객 만족 애자일은 고객 만족을 최우선으로 합니다. 고객의 요구 사항을 이해하고 신속하게 대응함으로써 가치 있는 소프트웨어를 제공하는 것이 목표입니다. 반복적인 개발 애자일은 반복적인 개발을 통해 초기에 가치 있는 제품을 빠르게 전달하고, 이를 통해 피드백을 받아 지속적으로 개선합니다. 이를 통해 초..

테스팅 방법 - 리그레션 테스트 (testing method - regression test) 유지보수 단계에서는 다양한 이유로 소프트웨어 변경이 발생합니다. 사용자가 소프트웨어를 사용하다가 결함을 발견하거나, 새로운 기능 추가, 성능 향상, 새로운 환경 대응을 위한 수정 등이 그 이유입니다. 이렇게 소프트웨어가 변경되면 리그레션 테스트(regression test)가 필요합니다. 리그레션 테스트는 변경 후에 수행되며, 해당 변경으로 인해 의도치 않은 결함이 발생하지 않았는지 확인하고, 시스템이 여전히 기본 요구사항을 충족하는지 검증합니다. [사용 전략] 리그레션 테스트에는 여러 전략이 적용될 수 있습니다. 각 전략은 다양한 상황과 요구에 따라 선택됩니다. Retest-All 전략 이 전략은 모든 기존 ..

테스팅 방법 - 소프트웨어 생명 주기 모델과 테스트 (testing method - software life cycle model & testing) software life cycle model Software 생명 주기 모델 다양한 소프트웨어들은 고유한 설계 기법과 개발 과정을 갖고 있지만, 대부분은 공통적인 소프트웨어 개발 수명주기(SDLC, Software Development Life Cycle)를 따르고 있습니다. 이 staedtler1207.tistory.com 소프트웨어 생명 주기(software life cycle model)는 소프트웨어 개발 체계를 추상적으로 표현한 것으로, 일련의 순차적 또는 병렬적인 단계로 구성됩니다. 이러한 단계는 요구사항 수집과 이해, 분석부터 설계, 모듈 구현..

sanity test Sanity Test 는 소프트웨어 개발 과정의 초기 단계에서 수행되는 테스트로, 주로 소프트웨어의 기본적인 기능이나 설정이 제대로 작동하는지를 확인하는 데 중점을 둡니다. 이 테스트는 소프트웨어가 최소한의 기능을 갖추고 있는지, 기본 기능이 작동하는지를 빠르게 평가하여 소프트웨어가 사용 가능한지 여부를 판단하는 데 사용됩니다. 이는 개발 과정의 초기 단계에서 중요한 역할을 합니다. 예를 들어, 웹 응용 프로그램을 개발하는 경우, Sanity Test는 다음과 같은 것들을 포함할 수 있습니다. 웹 페이지에 로그인 폼이 제대로 표시되는지 확인 로그인 기능이 작동하여 사용자가 인증을 수행할 수 있는지 확인 메인 페이지에서 필수적인 메뉴나 버튼이 존재하고 클릭 가능한지 확인 데이터베이스와..

테스트 설계 기법에 따른 분류 - 동적 테스트 (Classification according to test design techniques - dynamic testing) 테스트는 테스트 설계 기법에 따라 정적 테스트와 동적 테스트로 나뉩니다. 여기서 정적 테스트는 리뷰와 정적 분석으로 구분되며, 동적 테스트는 명세 기반 테스트, 구조 기반 테스트, 그리고 경험 기반 테스트로 분류됩니다. 동적 테스트(dynamic testing) 동적 테스트는 결함을 찾기 위해 소프트웨어를 실행하는 방법입니다. 이때, 적절한 입력값 또는 테스트 케이스를 선택하는 것이 중요합니다. 소프트웨어의 어느 부분에 결함이 있는지 확실히 알 수 없으므로 가능한 많은 경우의 수를 조사하여 테스트 케이스를 결정해야 할 것으로 보입니다..

테스트 설계 기법에 따른 분류 - 정적 테스트 (Classification according to test design techniques - static testing) 테스트는 테스트 설계 기법에 따라 정적 테스트와 동적 테스트로 나뉩니다. 여기서 정적 테스트는 리뷰와 정적 분석으로 구분되며, 동적 테스트는 명세 기반 테스트, 구조 기반 테스트, 그리고 경험 기반 테스트로 분류됩니다. 정적 테스트(static testing) 정적 테스트는 테스트 대상을 실행하지 않고도 테스트를 수행하는 방식입니다. 주요한 방법으로는 리뷰와 정적 분석이 있습니다. 리뷰(review) 리뷰는 소프트웨어의 다양한 산출물에서 결함을 발견하거나 프로젝트의 진행 상황을 확인하기 위한 중요한 활동입니다. 이를 전문가 그룹이 수행..

테스트 유형에 의한 분류 (classification by test type) 소프트웨어의 동작과 특성을 확인하기 위한 기준은 요구사항 명세서에 정의됩니다. 이 명세서는 주로 기능 요구사항과 품질 요구사항으로 구성됩니다. 기능 요구사항은 소프트웨어가 수행해야 하는 작업과 기능을 설명하고, 품질 요구사항은 소프트웨어의 품질과 성능에 대한 기준을 제시합니다. 이러한 요구사항에 기반하여 소프트웨어의 테스트가 이루어집니다. 테스트는 주로 기능 테스트와 비기능 테스트로 구분됩니다. 기능 테스트는 소프트웨어의 각 기능이 요구사항에 맞게 동작하는지를 확인하는 것에 중점을 둡니다. 반면에 비기능 테스트는 성능, 효율성, 신뢰성 등의 품질 특성에 초점을 맞추어 수행됩니다. 전통적으로 비기능 테스트는 성능 효율성 테스트,..

테스트 레벨에 의한 분류 (Classification by test level) 테스트 레벨에 따라 분류된 테스트는 주로 컴포넌트(또는 단위) 테스트, 통합 테스트, 시스템 테스트, 그리고 인수 테스트로 나눌 수 있습니다. 각 테스트 레벨에 대한 설명은 다음과 같습니다 컴포넌트(component) / 단위(unit) 테스트: 목적: 시스템을 구성하는 개별 단위 모듈을 테스트하여 각 모듈의 독립성과 정확성을 검증. 범위: 주로 함수, 메서드 또는 모듈 수준. 진행 방식: 개별 단위 모듈을 독립적으로 테스트. 통합(integration) 테스트: 목적: 시스템을 구성하는 단위 모듈들이 정확하게 통합되었는지 확인. 시스템 내부 구성 모듈과 이들 간의 관계를 테스트. 범위: 모듈, 컴포넌트, 서브시스템 수준. ..

테스트 분류 (test classification) 소프트웨어 테스트는 테스트 레벨, 테스트 유형, 그리고 테스트 설계 기법에 따라 다양하게 분류됩니다. 테스트 레벨 컴포넌트 테스트 : 개별 컴포넌트 또는 모듈을 테스트하여 기능을 확인. 통합 테스트 : 다양한 컴포넌트들이 함께 작동할 때의 상호 작용을 검증. 시스템 테스트 : 전체 시스템이 요구사항을 충족하는지 확인. 인수 테스트 : 사용자의 요구에 부합하는지 확인하고 시스템이 실제 환경에서 작동하는지 확인. 테스트 유형 기능 테스트 : 소프트웨어의 기능적 요구사항을 검증. 비기능 테스트 (성능, 신뢰성, 보안 등) 성능 테스트 : 시스템의 성능, 응답 시간, 처리량 등을 평가. 신뢰성 테스트 : 소프트웨어의 안정성, 오류 처리 능력 등을 평가. 보안 ..