소프트웨어 테스트 결과. 소프트웨어 테스팅의 유형. 전체 목록. 테스트 시간별
동적 소프트웨어 테스트에는 다양한 방법론이 있습니다. 테스터가 프로그램의 소스 코드에 접근할 수 있는지 여부에 따라 다음과 같은 테스트 방법이 구분됩니다.
- 블랙박스 방식
- 화이트 박스 방식
- 그레이박스방식
블랙박스 방식.
"블랙박스"라는 용어는 정신과 의사 W. R. Ashby가 1959년 자신의 저서 "사이버네틱스 입문"에서 처음 언급했습니다. 그는 블랙박스 방법을 통해 내부 구조를 추상화하여 시스템의 동작을 연구할 수 있다고 썼습니다.
테스트 분야에서 블랙박스 방법은 시스템의 내부 작동에 대한 지식 없이 소프트웨어의 외부 인터페이스를 사용하여 작업하는 테스트 기술입니다.
이 방법을 "블랙박스"라고 합니다. 이 방법에서는 테스트 중인 소프트웨어가 테스터에게 블랙박스처럼 보이기 때문에 그 내부에서 일부 프로세스가 발생하지만 테스터는 이에 대해 전혀 알지 못합니다. 이 기술을 사용하면 다음 범주의 오류를 감지할 수 있습니다.
- · 인터페이스 오류.
- · 기능이 누락되었거나 잘못 구현되었습니다.
- · 시스템 성능이 부족하거나 동작 오류가 발생합니다.
- · 잘못된 데이터 구조 또는 외부 데이터베이스에 대한 액세스 구성이 잘못되었습니다.
따라서 테스터는 시스템의 내부와 구조에 대해 전혀 모르기 때문에 프로그램이 어떻게 작동하는지보다는 프로그램이 무엇을 하는지에 집중해야 합니다.
화이트박스 방식.
이름에서 알 수 있듯이 이 테스트 방식은 블랙박스 방식과 반대되는 방식이다. 이 테스트 방법은 시스템의 내부 구조 분석을 기반으로 합니다.
즉, 이 경우 테스터는 테스트 중인 소프트웨어 구현의 모든 측면을 알고 있습니다. 이 방법을 사용하면 특정 입력(예: 블랙박스의 경우)에 대한 프로그램 응답의 정확성뿐만 아니라 이를 처리할 코드에 대한 지식을 기반으로 개별 모듈 및 기능의 올바른 작동도 테스트할 수 있습니다. 입력. 테스트 중인 프로그램의 구현 기능에 대한 지식은 테스터가 이 기술을 성공적으로 사용하기 위한 필수 요구 사항입니다. 화이트박스 테스트를 통해 외부 인터페이스를 넘어 소프트웨어 내부에 더 깊이 들어갈 수 있습니다.
회색 상자 방법.
이 시스템 테스트 방법에는 White Box와 Black Box 접근 방식이 결합되어 있습니다. 따라서 테스터는 프로그램의 내부 구조를 부분적으로만 알고 있습니다. 예를 들어, 가장 효과적인 테스트 케이스를 개발하기 위해 소프트웨어의 내부 구조에 접근할 수 있다고 가정하고, 테스트 자체는 블랙박스 방식을 사용해 수행할 예정이다. 또는 테스터는 모든 면에서 블랙박스 방식을 따를 수 있지만 개별 알고리즘이 올바르게 작동하는지 확인하기 위해 로그의 정보를 보거나 데이터베이스의 프로그램 기록을 분석할 수 있습니다.
테스트 피험자가 여러 가지 특별한 작업을 수행하는 방식을 분석하여 지식, 기술, 능력 및 기타 성격 특성의 수준과 특정 표준 준수 여부를 식별할 수 있는 연구 방법입니다. 이러한 작업을 일반적으로 테스트라고 합니다. 시험은 연구자가 대상에서 연구 중인 속성의 표현 정도, 심리적 특성 및 특정 대상에 대한 태도를 진단할 수 있도록 하는 표준화된 작업 또는 특별한 방법으로 관련된 작업입니다. 테스트 결과, 일반적으로 개인에서 연구 중인 특성의 심각도를 보여주는 특정 정량적 특성이 얻어집니다. 이는 해당 주제 범주에 대해 설정된 표준과 상호 연관되어야 합니다.
이는 테스트를 통해 연구 대상에서 특정 속성의 현재 개발 수준을 결정하고 이를 표준 또는 이전 기간의 주제에서 이 품질 개발과 비교할 수 있음을 의미합니다.
테스트를 수행하고 얻은 결과를 해석하는 데에는 특정 규칙이 있습니다. 이러한 규칙은 매우 명확하게 개발되었으며 주요 규칙은 다음과 같은 의미를 갖습니다.
1) 피험자에게 테스트 목적을 알립니다.
2) 피험자가 테스트 작업을 수행하기 위한 지침을 숙지하고 지침이 올바르게 이해되었다는 연구자의 확신을 얻습니다.
3) 피험자가 조용하고 독립적으로 작업을 수행할 수 있는 상황을 보장합니다. 힌트와 도움을 피하고 응시자에 대해 중립적인 태도를 유지합니다.
4) 획득한 데이터를 처리하고 각 테스트 또는 해당 작업에 수반되는 결과를 해석하기 위한 방법론적 지침을 연구원이 준수합니다.
5) 검사 결과 얻은 정신 진단 정보의 유포를 방지하고 그 정보의 기밀성을 보장합니다.
6) "해를 끼치지 마십시오!"라는 원칙을 고려하여 피험자에게 테스트 결과를 숙지시키고 피험자 또는 책임자에게 관련 정보를 제공합니다. 이 경우 일련의 윤리적, 도덕적 문제를 해결할 필요가 있습니다.
7) 연구자가 다른 연구 방법 및 기술을 통해 얻은 정보를 축적하고, 서로의 상관 관계 및 일관성을 결정합니다. 해당 애플리케이션의 기능에 대한 테스트와 지식을 통해 귀하의 경험을 풍부하게 합니다.
또한 여러 유형의 테스트가 있으며 각 테스트에는 해당 테스트 절차가 수반됩니다.
적성검사특정 정신 기능과 인지 과정의 발달 수준을 확인하고 측정하는 것이 가능해집니다. 이러한 테스트는 개인의인지 영역 진단, 사고 특성과 가장 관련이 있으며 일반적으로 지적이라고도합니다.
여기에는 Raven 테스트, Amthauer 테스트, Wechsler 테스트의 해당 하위 테스트 등은 물론 일반화, 분류 및 연구 성격의 기타 여러 테스트를 위한 작업 테스트가 포함됩니다.
성취도 테스트구현 성공의 척도이자 일부 활동 수행 준비의 척도로서 특정 지식, 기술 및 능력의 개발 수준을 식별하는 데 중점을 둡니다. 모든 시험 시험 사례가 예시가 될 수 있습니다. 실제로는 성취도 테스트의 '배터리'가 일반적으로 사용됩니다.
성격 테스트피험자의 성격 특성을 식별하기 위한 것입니다. 그것들은 다양하고 다양합니다. 개인의 상태와 감정 구성에 대한 설문지(예: 불안 테스트), 활동 동기 및 선호도에 대한 설문지, 성격 특성 및 관계 결정이 있습니다.
태도, 무의식적 요구와 충동, 불안, 두려움 상태를 식별할 수 있는 투사적 테스트 그룹이 있습니다.
테스트의 사용은 항상 하나 또는 다른 심리적 특성의 발현을 측정하고 발달 또는 형성 수준을 평가하는 것과 관련이 있습니다. 그러므로 시험의 질이 중요하다. 테스트의 품질은 정확도 기준, 즉 신뢰성과 타당성.
테스트의 신뢰성은 얻은 결과가 얼마나 안정적인지, 무작위 요인에 대해 얼마나 독립적인지에 따라 결정됩니다. 물론 같은 주제의 증언을 비교하는 얘기다. 이는 신뢰할 수 있는 테스트는 여러 테스트에서 일관된 테스트 점수를 가져야 하며 테스트가 동일한 것을 감지하고 있다고 확신할 수 있음을 의미합니다.
재산. 테스트의 신뢰성을 확인하기 위해 다양한 방법이 사용됩니다.
한 가지 방법은 방금 언급한 재검사입니다. 특정 시간 이후 첫 번째 재검사와 반복 재검사 결과가 충분한 수준의 상관 관계를 나타내는 경우 이는 검사의 신뢰성을 나타냅니다. 두 번째 방법은 또 다른 동등한 형태의 테스트를 사용하고 이들 사이에 높은 상관 관계가 존재하는 것을 포함합니다. 테스트를 통해 두 부분으로 나누고 한 부분으로 나눌 수 있는 경우 신뢰성을 평가하는 세 번째 방법을 사용하는 것도 가능합니다.
동일한 피험자 그룹이 테스트의 두 부분을 모두 사용하여 검사됩니다. 테스트의 신뢰성은 심리적 매개변수가 얼마나 정확하게 측정되는지, 그리고 얻은 결과에 대한 연구자의 확신이 얼마나 높은지를 보여줍니다.
테스트 타당성은 테스트가 정확히 무엇을 드러내는지, 테스트의 의도를 식별하는 데 얼마나 적합한지에 대한 질문에 답합니다. 예를 들어, 능력 테스트는 종종 훈련, 관련 경험의 존재 또는 반대로 그것의 부족과 같은 다른 것을 드러냅니다. 이 경우 테스트는 유효성 요구 사항을 충족하지 않습니다.
정신진단에는 다양한 유형의 타당성이 있습니다. 가장 간단한 경우, 테스트의 타당성은 일반적으로 테스트 결과로 얻은 지표를 피험자의 이 속성(현재 타당성 또는 "동시" 타당성)의 존재에 대한 전문가 평가와 비교하고 분석하여 결정됩니다. 다양한 상황에서 피험자의 삶과 일, 그리고 해당 분야에서의 성과를 관찰한 결과 얻은 데이터입니다.
테스트의 타당성에 대한 문제는 타당성이 확립된 것으로 간주되는 특정 기술과 관련된 기술을 사용하여 얻은 지표와 해당 데이터를 비교하여 해결할 수도 있습니다.
활동제품 연구 개인의 활동 결과 분석을 기반으로 개인의 지식과 기술, 관심 및 능력의 형성을 간접적으로 연구 할 수있는 연구 방법입니다. 이 방법의 특징은 연구자가 개인과 직접 접촉하는 것이 아니라 이전 활동의 산물이나 무엇에 대한 생각을 다룬다는 것입니다.
그 과정에서 그리고 특정 상호 작용 및 관계 시스템에 포함된 결과로 주체 자체에 변화가 발생했습니다.
소프트웨어 테스트는 소프트웨어 개발 수명주기의 필수적인 부분입니다. 소프트웨어 테스팅의 기본 개념과 다양한 단계를 알아보려면 이 기사를 읽어보세요.
소프트웨어 개발 라이프사이클은 소프트웨어 제품 개발의 절차적 프로세스입니다. 이 프로세스는 소프트웨어 제품 개발의 전반적인 아이디어를 설명하는 일련의 단계로 수행됩니다.
소프트웨어 개발 프로세스 수명주기의 분류는 다음과 같습니다.
- 계획
- 분석
- 설계
- 소프트웨어 개발
- 구현
- 전개
- 유지
소프트웨어 테스트는 제품이 고객의 요구 사항에 따라 올바르게 작동하고 효과적인지 여부를 결정하므로 제품 수명주기의 중요한 부분입니다.
소프트웨어 테스팅 소개
오류:오류 또는 오류는 잘못되거나 부정확한 결과를 생성하는 인간의 행동입니다.
결함(버그, 오작동):구성 요소의 고장이나 오작동을 유발할 수 있는 시스템이나 제품의 고장.
거절:실제 결과와 예상 결과의 차이입니다.
위험:위험은 부정적인 결과를 초래할 수 있거나 손실이나 손해가 발생할 가능성이 있는 요소입니다.
따라서 소프트웨어 테스팅은 결과 제품의 실패로 이어질 수 있는 프로그램의 오류로 인해 발생하는 시스템의 결함/오류를 찾는 프로세스입니다. 간단히 말해서, 소프트웨어 테스팅에는 다음과 같은 다양한 목표와 목표가 있습니다.
- 결함 감지
- 자신감을 얻고 품질 수준에 대한 정보를 제공하세요.
- 결함 예방
소프트웨어 테스팅의 범위
테스트의 주요 기능은 오류를 감지하여 노출하고 감지하는 것입니다. 이 영역에는 다양한 환경에서 코드를 실행하는 것뿐만 아니라 코드 측면을 검사하는 것도 포함됩니다. 프로그램이 예상대로 수행하고 사양에 따라 작동합니까?
소프트웨어 개발의 초기 단계부터 테스트를 시작하는 것이 좋습니다. 이는 마지막 단계 이전에 오류를 수정하는 데 도움이 될 뿐만 아니라, 초기 단계에서 오류를 찾는 재작업을 줄여줍니다. 이는 시간을 절약하고 비용 효율적입니다. 소프트웨어 테스팅은 끝이 없을 수도 있지만 시간이나 예산 부족으로 인해 중단될 수 있는 지속적인 프로세스입니다. 이를 위해서는 시간과 비용의 제약 속에서 좋은 품질의 제품으로 최대의 이익을 달성해야 합니다. 테스터는 결론을 도출할 수 있는 몇 가지 절차적 방법을 따라야 합니다. 테스터가 이러한 일상 활동을 수행하는 데 도움이 되도록 체크리스트 형태로 제공되는 기본 세트가 있습니다.
주요 개념
결함 및 실패:앞서 논의한 것처럼 결함은 코딩 오류뿐만 아니라 유용성, 테스트 가능성, 확장성, 유지 관리 가능성, 성능 및 보안과 같은 비기능적 요구 사항의 차이로 인해 가장 자주 발생합니다. 실패는 실제 결과와 예상 결과 사이의 편차로 인해 발생합니다. 그러나 모든 결함이 실패로 이어지는 것은 아닙니다. 환경 변화나 시스템 요구 사항 구성 변경으로 인해 결함이 실패로 바뀔 수 있습니다.
입력 조합 및 전제 조건:입력과 초기 상태(전제 조건)의 모든 조합을 테스트하는 것은 불가능합니다. 이는 자주 발생하지 않는 많은 결함을 찾는 것이 매우 어렵다는 것을 의미합니다.
정적 및 동적 분석:정적 테스트에서는 결함을 감지하기 위해 코드 실행이 필요하지 않지만 동적 테스트에서는 테스트 결과를 보여주기 위해서만 프로그램 코드가 실행됩니다.
확인 및 검증:소프트웨어 테스트는 이 두 가지 요소를 염두에 두고 수행됩니다.
- 검증(Verification): 주어진 제품이 사양에 따라 설계되었는지 확인합니다.
- 검증: 제품이 고객 요구 사항을 충족하는지 확인합니다.
소프트웨어 품질 보증:소프트웨어 테스트는 품질 보증의 중요한 부분입니다. 품질 보증은 제품의 적합성을 확인하고 제품의 품질에 관심을 갖고 고객 요구 사항이 충족되는지 확인하는 활동입니다.
소프트웨어 테스팅의 유형
소프트웨어 테스트 유형은 특정 테스트 목표에 초점을 맞춘 구성 요소 또는 시스템 테스트를 목표로 하는 제어 활동 그룹입니다. 유용성, 테스트 가능성, 신뢰성과 같은 비기능적 요구사항. 특정 구성 요소의 결함을 찾는 일반적인 목적으로 다양한 유형의 테스트가 사용됩니다.
소프트웨어 테스팅은 수동 테스팅과 자동 테스팅이라는 두 가지 주요 유형으로 분류됩니다.
테스트 스크립트 지침:
- 블랙박스(블랙박스) 테스트
- 화이트박스 테스트
- 그레이 박스 테스트
소프트웨어 수명주기 테스트 수준은 다음과 같습니다.
- 단위 테스트
- 통합 테스트
- 시스템 테스트
- 승인 테스트(알파 테스트 및 베타 테스트)
다른 유형의 소프트웨어 테스트는 다음과 같습니다.
- 기능 테스트
- 성능 테스트(부하 테스트 및 스트레스 테스트)
- 연기 테스트
- 위생 테스트(일관성 확인)
- 회귀 테스트
- 복구 테스트.
- 유용성 테스트
- 호환성 테스트
- 구성 테스트
- 탐색적 테스트
자동화된 테스트
수동 테스트는 노동 집약적인 프로세스입니다. 테스트 자동화에는 수동 프로세스 자동화가 포함됩니다. 테스트 자동화는 테스트를 위해 컴퓨터 프로그램을 스크립트 형태로 작성하는 프로세스로, 일반적으로 수동으로 수행됩니다. 널리 사용되는 자동화 도구로는 Winrunner, Quick Test Professional(QTP), LoadRunner, SilkTest, Rational Robot 등이 있습니다. 자동화 도구에는 TestDirector 등과 같은 서비스 도구도 포함되어 있습니다.
소프트웨어 테스트 방법론
소프트웨어 제품을 개발하고 테스트하는 데 사용할 수 있는 다양한 테스트 기술이 있습니다. 이러한 모델은 다음과 같습니다.
- 캐스케이드 모델
- V 모델
- 나선형 모델
- 합리적인 통합 프로세스
- 유연한 모델
- 신속한 애플리케이션 개발
테스트 아티팩트
소프트웨어 테스트 프로세스 중에 다음과 같은 다양한 아티팩트가 생성될 수 있습니다.
테스트 계획:테스트 작업의 전체 범위를 설명하는 문서입니다. 테스트 계획 - 제품이나 시스템이 설계 사양을 준수하는지 확인하고 확인하는 데 사용할 수 있습니다.
매트릭스 추적성:테스트 문서에 맞게 문서를 매칭하거나 전개하는 테이블입니다. 이는 테스트 결과가 올바른지 확인하고 소스 문서가 변경될 때 테스트를 수정하는 데에도 사용됩니다.
테스트 사례:테스트 사례와 전략은 결과 제품을 생산하기 위해 통합된 개별 구성 요소의 성능을 확인하는 데 사용됩니다. 이러한 테스트 사례는 능력이나 기능의 적용을 평가하도록 설계되었습니다.
테스트 데이터:테스트 케이스, 테스트 값 및 가변 환경에서 특정 기능의 동일한 기능을 테스트하기 위해 여러 값 또는 데이터 세트가 사용되는 경우 구성 요소는 별도의 파일에 수집되어 테스트 데이터로 저장됩니다.
테스트 시나리오:테스트 케이스는 테스트, 테스트 절차, 테스트 데이터의 조합입니다.
테스트 세트:테스트 케이스 모음입니다.
소프트웨어 테스트 프로세스
소프트웨어 테스트 프로세스는 시스템 소프트웨어의 결함을 찾기 위해 다음 순서로 수행됩니다.
- 테스트 계획 만들기
- 테스트 케이스 디자인
- 테스트 케이스 설명
- 테스트 케이스 검토
- 테스트 실행
- 테스트 결과 연구
- 최종 리뷰 작성 중
다음은 몇 가지 테스트 예입니다.
시스템 페이지에 로그인하기 위한 테스트 소프트웨어:
표적:사용자는 홈 페이지로 이동할 수 있어야 합니다.
전제 조건:
- 소프트웨어는 운영 체제와 호환되어야 합니다.
- "로그인 항목" 페이지가 나타납니다.
- 사용자 ID 및 비밀번호 텍스트 필드는 적절한 레이블과 함께 사용할 수 있어야 합니다.
- 적절한 라벨이 있는 "로그인" 및 "취소" 버튼이 있어야 합니다.
테스트 1
테스트 이름:사용자 인터페이스 요구 사항을 확인합니다.
단계/조치:사용자는 페이지를 스캔하여 해당 레이블이 있는 텍스트 상자에 사용자 ID와 비밀번호가 포함되어 있는지 확인합니다. 또한 "로그인" 및 "취소" 버튼은 적절한 라벨을 통해 접근 가능해야 합니다.
예상 결과:화면에는 사용자의 요구 사항에 따라 사용자 인터페이스가 표시됩니다.
테스트 2
테스트 이름:사용자 ID의 텍스트 필드는 1) 알파벳 문자(a~z, A~Z)만 허용하고, 2) ("$","#","!","~ 등의 특수 문자는 허용하지 않아야 합니다.) ","*",...), 3) 숫자(0-9)는 허용되지 않습니다.
단계/조치: 1) 사용자가 텍스트 필드에 숫자를 입력합니다. 2) 사용자는 텍스트 필드에 영숫자 데이터를 입력합니다.
예상 결과: i) 수치 데이터의 경우 오류 메시지가 표시됩니다. 2) 사용자가 텍스트 필드에 알파벳 데이터를 입력하면 텍스트가 허용됩니다.
테스트 3
테스트 이름:비밀번호 텍스트 필드의 기능 확인: 1) 비밀번호 텍스트 필드는 6자 이상을 허용해야 합니다. 2) 데이터는 암호화된 형태로 표시되어야 합니다.
단계/조치: 1) 사용자는 비밀번호 텍스트 필드에 두 문자만 입력합니다. 2) 사용자가 비밀번호 텍스트 필드에 6자 이상을 입력했습니다. 3) 사용자는 데이터가 암호화된 형태로 표시되는지 확인합니다.
예상 결과:사용자가 비밀번호 텍스트 상자에 6자 미만을 입력하면 오류 메시지가 표시됩니다. 사용자가 비밀번호 텍스트 필드에 6자 이상을 입력하면 시스템은 데이터를 승인합니다. 시스템은 데이터를 암호화된 형식으로 표시합니다.
테스트 4
테스트 이름:"로그인" 버튼의 기능을 확인합니다.
단계/조치: 1) 사용자는 “로그인” 버튼이 활성화되어 있는지, 비활성화되어 있는지 확인합니다. 2) 사용자는 “로그인” 버튼을 클릭하고 애플리케이션의 메인 페이지를 보기를 기다립니다.
예상 결과: 1) 시스템에 "로그인" 버튼이 표시됩니다. 2) 시스템은 사용자가 "로그인" 버튼을 클릭하자마자 사용자를 애플리케이션의 메인 페이지로 리디렉션합니다.
테스트 5
테스트 이름:"취소" 버튼의 기능을 확인합니다.
단계/조치: 1) 사용자는 취소 버튼이 활성화되어 있는지 비활성화되어 있는지 확인합니다. 2) 사용자는 취소 버튼을 클릭했을 때 사용자 ID 및 비밀번호 텍스트 필드가 재설정되는지 확인합니다.
예상 결과: 1) 시스템에 “취소” 버튼이 표시됩니다. 2) 사용자가 취소 버튼을 클릭하면 시스템은 사용자 ID 및 비밀번호 텍스트 필드를 재설정합니다.
소프트웨어 테스팅을 위한 문제 해결 기술
소프트웨어 개발 초기 단계에서 결함이나 오작동을 찾아내는 것은 시간과 비용을 절약할 뿐만 아니라 안전성과 수익성 측면에서도 효과적입니다. 소프트웨어의 다양한 수준을 진행하면서 소프트웨어의 초기 단계로 돌아가서 문제를 찾는 것이 어렵고 지루해집니다. 비용도 상승하고 있습니다. 따라서 소프트웨어 개발 라이프사이클의 초기 단계부터 테스트를 시작하는 것이 좋습니다.
유형과 함께 다양한 소프트웨어 테스트 방법이 있습니다. 신청서에 오류가 발견되면 따라야 할 절차가 있습니다. 이 절차는 버그의 심각도와 우선순위에 따라 버그 수명 주기와 결합됩니다. 이 수명주기를 수명주기 오류라고 합니다.
소프트웨어 지표
소프트웨어가 개발 중이고 시스템을 사용할 준비가 되면 소프트웨어를 측정해야 할 필요성이 발생합니다. 이러한 추상적인 한계를 측정하기는 어렵지만 피할 수는 없습니다. 측정할 수 없는 항목은 통제되어야 합니다. 소프트웨어 측정의 이점에는 몇 가지 중요한 측면이 있습니다.
소프트웨어 지표는 다음과 같은 함정을 피하는 데 도움이 됩니다.
- 비용 초과
- 문제의 원인 파악
- 목표의 명확화
다음과 같은 질문에 대한 답변을 제공합니다.
- 각 활동 과정에 대한 평가는 어떻게 되나요?
- 개발된 코드의 품질은 어떤가요?
- 취약한 코드를 어떻게 개선할 수 있나요?
이는 소프트웨어 품질 평가, 비용 및 노력 평가, 데이터 수집, 성능 및 효율성 평가에 도움이 됩니다.
몇 가지 일반적인 소프트웨어 측정항목은 다음과 같습니다.
- 코드 적용 범위
- 순환적 복잡성
- 응집력
- 연결
- 포인트 분석 기능
- 리드타임
- 코드 줄의 소스
- 코드 줄에 오류가 있습니다.
간단히 말해서, 시스템 소프트웨어를 제어하고 개선하려면 소프트웨어 측정이 필요합니다. 소프트웨어는 환경 조건 변화, 사용자 요구 사항 변화, 구성 및 호환성 문제로 인해 변경될 수 있습니다. 이는 소프트웨어의 최신 및 업데이트 버전 개발에 자극을 줍니다. 그러나 이전 버전으로 쉽게 되돌리고 효율적으로 작업할 수 있는 소스도 있어야 합니다.
직업으로서의 소프트웨어 테스팅
소프트웨어 테스팅은 소프트웨어 산업에 관심이 있는 사람들에게 좋은 직업 기회입니다. 비디오 게임 테스트는 소프트웨어 테스트의 한 분야입니다. 이 분야를 전문으로 하는 산업이 많이 있습니다. 비디오 게임을 경험하고 돈을 받을 수도 있습니다.
소프트웨어 테스팅은 실제로 거대한 분야이며, 개발된 소프트웨어의 품질을 보장하려면 정확한 지식이 중요합니다. 이 소프트웨어 테스팅 튜토리얼이 다양한 유형의 소프트웨어 테스팅, 방법론 및 다양한 테스팅 전략에 대한 명확한 아이디어를 제공하기를 바랍니다.
안드레이 콜레소프
전체 소프트웨어 개발 프로세스에서 테스트의 중요성에 대해 이야기하는 것은 거의 의미가 없습니다. 애플리케이션 수명주기의 각 단계 구현이 고품질 소프트웨어 제품 출현을 위한 필수 조건이라는 것이 오랫동안 알려져 왔기 때문입니다. 그러나 모든 유형의 작업이 평등하다는 말은 인정해야 합니다. 소프트웨어 개발의 전체 역사를 통틀어 50년 이상 거슬러 올라가면 테스트는 가장 노동 집약적인 작업을 수행하는 의붓자식 역할을 했습니다. 일상적이고 명예롭지 않은 업무 *. 멀리서 예를 찾을 필요가 없습니다. 개발자의 저작권은 법으로 보호되며, 원하는 경우 개발자의 이름을 쉽게 찾을 수 있습니다. 애플리케이션을 테스트하는 사람들에 대해 우리는 무엇을 알고 있습니까? 이는 그들이 소프트웨어 개발 비용의 평균 약 3분의 1을 차지한다는 사실에도 불구하고입니까?
그러나 최근 상황이 눈에 띄게 바뀌었고 여기서 두 가지 주요 추세를 구분할 수 있습니다. 첫째, 특히 특수 자동화 도구를 사용하는 산업 테스트 방법의 필요성에 대한 이해가 높아지고 있습니다. 두 번째는 아웃소싱 모델 사용을 포함하여 전체 비즈니스 조직의 관점에서 이러한 작업 수행 비용을 최적화할 수 있는 기회를 찾는 것입니다.
역설적인 상황이 있다는 점에 유의해야 합니다. 소프트웨어 설계 및 코딩에 관한 방법론적 문헌과 강좌가 풍부함에도 불구하고 테스트 및 디버깅에 관한 자료는 거의 전혀 없습니다. 소프트웨어 개발에 관한 책을 집필한 미국의 유명한 작가 John Robbins는 다음과 같이 말했습니다. "특수 교육을 받았더라도 디버깅에 대한 특별 과정을 접해 본 적이 없을 것입니다."(PC Week/RE, No. 9/2004, p 참조) .61).
그러나 상황은 다소 변하고 있으며, 그 중 하나의 증거는 모스크바 대표의 지원을 받아 Aplana 회사가 2월 말 모스크바에서 개최한 "기업 시스템 개발 및 유지 관리 중 테스트 프로세스의 효과적인 구성" 실무 세미나입니다. IBM 사무실. 주제가 너무 관련성이 높아 IBM Technology Center가 하루에 모든 사람을 수용할 수 없어서 세미나를 두 번 개최해야 했습니다. 처음에는 자체 개발을 진행하는 기업의 IT 부서를 중심으로 행사가 열렸지만, 맞춤형 및 복제 가능한 소프트웨어를 만드는 전문 기업들도 큰 관심을 보였습니다. 이번 세미나에는 기업, 부서 개발 및 구현 센터, IT 기업의 관리자와 전문가 80여 명이 참석했습니다.
비록 IBM Rational 제품이 도구 기반으로 사용되었지만 세미나의 주요 초점은 일반적인 소프트웨어 개발 프로세스와 기업의 일반적인 비즈니스 기능 측면에서 테스트의 조직적, 방법론적 문제에 관한 것이었습니다. 여러면에서 이번 행사에 전문가의 적극적인 참여를 미리 결정한 것은 바로 이러한 접근 방식이었습니다.
시험기관의 특징
우선, 테스트 문제는 기술 사양 개발부터 애플리케이션 유지 관리까지 전체 소프트웨어 수명주기의 맥락에서 고려되어야 한다는 점에 유의해야 합니다. 아시다시피 테스트는 소프트웨어를 산업용으로 사용하기 전에 소프트웨어의 결함(오류)을 찾아내는 절차입니다. 분명히 이러한 작업의 복잡성은 오류 수 자체와 관련이 있으므로 오류 발생의 주요 원인을 명확하게 식별할 필요가 있습니다.
- 전체 개발 프로세스에 대한 불만족스러운 조직적, 방법론적, 기술적 지원
- 짧은 프로젝트 마감일;
- 프로젝트의 복잡성, 많은 요구 사항 및 작업 중 변경 사항
- 개발자의 자격이 부족합니다.
중요한 점이 하나 더 있습니다. 테스트는 디버깅의 구성 요소일 뿐입니다. 즉, 소프트웨어가 작동 상태로 작성된 후 소프트웨어를 미세 조정하는 프로세스입니다. 이 프로세스에는 오류 감지(테스트)와 오류 원인 검색 및 제거라는 두 가지 주요 절차가 포함됩니다. 그러나 이러한 작업의 가능한 모든 상호 관계를 고려하더라도(예: 오류 원인을 검색하려면 특별한 추가 테스트가 필요함) 테스트는 소프트웨어 수명 주기에서 상당히 자율적이고 독립적인 단계라는 점을 강조해야 합니다. 동시에 개발 품질을 높이면(애플리케이션의 오류 수에 반비례) 오류 제거 비용이 직접적으로 줄어들지만 테스트 양에는 그다지 영향을 미치지 않는다는 점을 강조합니다. 어떤 경우에도, 바람직하게는 "전체"로.
또한 구성 및 테스트 방법론은 박스형 제품, 맞춤형 프로젝트 또는 사내 프로젝트 등 개발 의도에 따라 크게 좌우된다는 것도 분명합니다. 그리고 여기서 과거 세미나가 주로 고객 IT 부서의 개발자를 대상으로 진행되었다는 사실에 다시 한 번 주목할 가치가 있습니다. 이에 대한 설명은 간단합니다. 첫째, 그러한 회사와 전문 IT 회사에서 수행되는 개발의 양은 적어도 비슷합니다. 둘째, 여러 가지 이유로 인해 사내 프로젝트를 수행할 때 테스트 작업은 매우 구체적이고 관련성이 높습니다.
IT 부서의 테스트 절차 기능에 대해 말하면 매우 모순되는 세 가지 주요 측면을 강조해야 할 것입니다.
- 테스트의 양이 매우 많습니다. 사실 내부 개발의 경우 변경이 매우 자주 발생합니다(많은 세미나 참가자가 고객 부서의 요청에 따라 지속적인 조정 흐름에 대해 이야기했습니다). 그러나 아시다시피 소프트웨어 개발의 고전적인 규칙은 다음과 같습니다. 코드 한 줄을 변경하려면 전체 테스트 주기를 반복해야 합니다.
- 냉소적으로 들릴지 모르지만 개발자는 프로덕션으로 전송되는 소프트웨어의 오류 수를 줄이는 데 관심이 없는 경우가 많습니다. 회사 경영진은 주로 예산(시간 및 비용)을 충족하는 능력을 기준으로 IT 부서의 작업을 평가하며 프로그램 운영 문제에는 훨씬 덜 관심을 갖습니다. 따라서 테스트 양을 늘리면 경영진의 적절한 리소스를 할당하지 않고 IT 부서의 비용이 증가하는 것으로 나타났습니다**.
- 고품질 테스트를 수행하려면 적절한 프로필의 전문가와 도구가 필요합니다. 그리고 포인트 2에서 IT 부서가 자체 테스터 그룹을 갖는 것은 단순히 수익성이 없다는 결론이 나옵니다.
일반적인 테스트 질문
이벤트 프로그램에는 테스트 프로세스를 구성하는 방법론적 측면과 해당 적용에 대한 실제 권장 사항이 모두 포함되었습니다. 일반적으로 핵심 아이디어는 매우 분명해 보입니다. 구현을 위한 합리적인 수준의 비용을 유지하면서 소프트웨어 테스트의 품질을 향상시키는 것은 이 작업을 수행하기 위한 현대 산업적 방법(조직적 및 기술적)을 통해 보장되어야 합니다.
Aplana 전문가의 여러 보고서에서 그들은 특히 소프트웨어 프로젝트 구현 비용(최적의 장비 구성 선택 포함)을 절감하고 적절한 구성을 통해 비즈니스 위험을 줄일 수 있는 방법에 대한 실제 사례를 통해 뒷받침되는 일반적인 상황에 대해 이야기했습니다. 적절한 자동화 도구를 테스트하고 사용하는 프로세스입니다.
이 기사의 범위에서는 특정 도구 사용과 관련된 문제를 자세히 제시할 수 없습니다. 이제 테스트 문제 분류에 대한 몇 가지 일반적인 문제를 고려하는 것이 더 유용해 보입니다. 보고서 중 하나에서 이에 대해 논의되었지만 제가 보기에는 몇 가지 중요한 사항이 다루어지지 않은 것 같습니다. 따라서 아래에서는 세미나에서 발표한 전문가들의 의견을 바탕으로 제 생각을 제시하겠습니다.
테스트는 설계부터 무한정 긴 운영 단계까지 전체 소프트웨어 수명 주기에 걸쳐 진행됩니다. 테스트의 목적은 프로그램이 명시된 요구 사항을 준수하는지 확인하는 것이기 때문에 이 작업은 요구 사항 및 변경 관리 작업과 직접적으로 관련됩니다.
테스트는 단계별 프로세스입니다. 실제로 코드를 작성하는 동안(프로그래머 자신이) 프로그램 기능을 테스트하는 것과 주요 코딩 단계가 완료된 후(아마도 특수 테스터가) 프로그램 기능을 테스트하는 것을 분리하는 것이 합리적일 것입니다. 여기에서 프로그래밍의 황금률을 기억할 수 있습니다. 20~30줄의 코드(특히 완전한 프로시저 및 기능)를 작성할 때마다 최소한 일부 기본 모드에서는 해당 기능을 확인해야 합니다. 동시에, 코딩하는 동안과 완료 시 테스트의 중요한 차이점을 강조할 필요가 있습니다. 첫 번째 경우에는 오류를 제거한 후에만 프로그램 작성을 계속하는 것이 좋습니다(다른 테스트 예제 실행도 포함). 두 번째에서는 간단한 고정을 통해 일련의 텍스트를 일괄 실행하여 결과를 수행합니다.
테스트는 반복적인 프로세스이기도 합니다. 각 오류를 식별하고 수정한 후에는 테스트를 반복하여 프로그램이 작동하는지 확인해야 합니다. 또한, 발견된 문제의 원인을 확인하기 위해 특정 추가 테스트가 필요할 수도 있습니다. 동시에, Edsger Dijkstra 교수가 1972년에 내린 근본적인 결론을 항상 기억해야 합니다. “테스트 프로그램은 오류의 존재를 증명할 수 있지만 오류의 부재를 결코 증명할 수는 없습니다!”
다양한 유형의 테스트는 다음과 같은 주요 특성에 따라 분류될 수 있습니다(분류는 매우 임의적이지만).
기능 및 부하 테스트. 첫 번째 유형의 작업은 소프트웨어가 기능 요구 사항을 준수하는지 확인하는 전통적인 작업으로 분류될 수 있습니다 ***. 최근에는 개발된 제품과 다양한 소프트웨어 및 하드웨어 플랫폼, 애플리케이션 등과의 호환성을 분석하는 등 비교적 새로운 작업의 관련성이 눈에 띄게 높아졌습니다. 두 번째 유형은 일반적으로 성능 평가 및 확장 문제와 관련이 있지만, 사실 그것은 훨씬 더 광범위한 문제에 영향을 미칩니다. 프로그램 코드의 병목 현상 식별, 리소스 누출 감지 등
구성 요소 및 통합 테스트. 분명히 첫 번째 유형의 테스트는 개발 초기 단계(완전한 모듈이 생성됨)에서 수행되고 두 번째 유형은 최종 단계에서 수행됩니다. 근본적인 차이점은 구성 요소 1이 주로 "화이트 박스" 방법(프로그램의 내부 논리 및 구조 고려)을 기반으로 하고 통합 1이 "블랙 박스" 방법(외부 사양만 알고 있음)을 기반으로 한다는 것입니다. 따라서 첫 번째 경우 테스트 작업의 상당 부분은 소프트웨어 설계자와 개발자에게, 두 번째 경우에는 독립 테스터에게 해당됩니다.
수동 및 자동 테스트. 프로젝트의 복잡성이 증가함에 따라 자동화된 방법(스크립트, 시뮬레이터 프로그램 사용 등)을 사용하여 작업을 해결하는 비율이 꾸준히 증가하고 있습니다. 대부분의 부하 테스트 문제는 이들의 도움을 통해서만 해결할 수 있습니다.
현재 시스템 구성을 테스트하는 것과 가능한 개발을 고려한 테스트를 구별하는 것이 합리적일 것입니다. 미래에 발생할 수 있는 문제에 대한 분석은 오늘날 확장 문제(예: 사용자 수 증가로 인한 시스템 부하 증가)와 가장 자주 연관됩니다. 물론 여기서는 더 넓은 범위의 문제, 특히 플랫폼 변경에 대한 전망을 염두에 두어야 합니다. 동시에 스케일링은 실제 애플리케이션을 테스트하는 것뿐만 아니라 전체 소프트웨어 구조 수준에서 시스템 모델링 방법을 통해서도 평가할 수 있다는 점을 강조하고 싶습니다. 최근 몇 년 동안 이 접근 방식이 적용되었습니다!).
문제의 해결책은 테스트 센터입니다
이미 언급했듯이 문제 테스트의 주요 역할은 방법론과 조직 구성 요소에 의해 수행됩니다. 도구의 경우 이 프로세스에서 도구의 역할은 부차적이며 테스트 작업 자동화를 위한 특정 제품의 선택은 프로젝트의 목표와 세부 사항, 기존 고객 선호도 및 예산에 따라 결정됩니다. 이제 시장에서는 IBM Rational, Mercury, Segue 및 Compuware가 선두를 달리는 등 다양한 자동화 테스트 도구를 제공하고 있습니다.
세미나 동안 Aplana 전문가들은 현재 러시아 개발자들 사이에서 널리 사용되고 있는 IBM Rational 테스트 도구의 예를 사용하여 자동화된 테스트의 가능성을 조사했습니다(사이드바 "IBM Rational 방법론 및 도구" 참조). 엔터프라이즈 수준 소프트웨어를 만들 때 사용하는 다양한 시나리오도 논의되었습니다. 특정 소프트웨어 제품 중에서 오늘날 가장 인기 있는 시스템인 IBM Rational Robot에 특별한 관심이 집중되었습니다.
그러나 올바른 방법과 도구를 사용하는 것이 중요하기는 하지만 전체 개발 프로세스 구조 내에서 테스트 작업의 전반적인 위치를 변경하는 것이 더 관련성이 있을 수 있습니다. 특히 이는 테스트를 별도의 서비스로 분리하여 사내에서 구현하거나 아웃소싱해야 함을 의미합니다.
맞춤형 소프트웨어 개발을 전문으로 하는 Aplana는 자신의 경험을 통해 이러한 접근 방식의 필요성을 깨달았습니다. 일반적으로 인정되는 품질 관리 표준에 따라 회사는 처음에 자체 서비스를 구성했으며 1년 전 회사 내부 문제에 대한 솔루션을 제공할 뿐만 아니라 외부 조직에도 서비스를 제공하는 테스트 센터로 전환했습니다.
세미나에서 별도의 프레젠테이션은 고객과 테스트 센터 간의 상호 작용 모델과 특정 프로젝트에 대한 고려에 전념했으며 청중의 반응으로 판단하면 많은 사람들이 그러한 제안에 관심을 보였습니다. 테스트 서비스 아웃소싱이 아직은 새로운 분야이기 때문에 이는 우연이 아닙니다. 가능한 주요 상호 작용 모델을 나열합니다.
- 센터 스탠드 또는 고객 사이트에서 소프트웨어 테스트 또는 개별 단계에 대한 전체 작업을 수행합니다.
- 조직 내 테스트 프로세스 구성에 대한 고객 컨설팅 및 교육
- 제3자 회사가 실시한 테스트 감사
- 테스트를 위한 기술 및 소프트웨어 리소스 아웃소싱.
결론적으로 한 가지 더 흥미로운 점에 주목할 가치가 있습니다. 세미나를 개최한 후 Aplana 회사는 소프트웨어 개발 분야에서 새로운 유형의 서비스 홍보를 실제로 발표한 우리나라 최초의 회사 중 하나였습니다. 개척자들은 종종 양가적인 입장에 처하게 됩니다. 그래서 이번 세미나에서는 잠재 고객뿐만 아니라 경쟁사에게도 무료 컨설팅 및 교육 과정을 제공해야 했습니다.
* 테스트 문제의 중요성을 잊지 않고, 지난 세기 60년대 후반에 현대 소프트웨어 개발 방법의 고전 중 하나인 네덜란드 교수 Edsjer Dijkstra가 구조화된 프로그래밍 방법을 사용할 필요성을 입증했다는 사실을 기억해야 합니다. 테스트를 위한 인건비 절감 작업.
** 테스트의 특이성은 완료를 위한 상당히 공식적인 기준이 있는 다른 소프트웨어 개발 단계와 달리 이 프로세스가 일반적으로 끝이 없다는 사실에도 있습니다. 결국, 아시다시피 "발견된 모든 마지막 오류는 실제로 두 번째 오류입니다." 실제로 필요한 테스트 양을 올바르게 결정하는 것은 별개의 어려운 작업입니다.
*** 테스트에 관해 말하면 소프트웨어 검증(정확성을 확인하기 위한 체계적인 절차)의 중요성도 언급할 필요가 있습니다. 이러한 개념 간의 미묘한 차이점은 테스트는 얻은 결과를 참조 결과와 비교하는 능력에 기반을 두고 있다는 것입니다. 그러나 단순히 참조 데이터가 없는 경우 상당히 많은 종류의 문제가 있습니다. 이 옵션의 전형적인 예는 수만 개의 미분 방정식의 해를 사용하여 복잡한 수학적 모델을 구축하는 것입니다. 그러나 비즈니스 응용 프로그램을 처리할 때 유사한 상황이 발생합니다. 이 경우 소프트웨어에 추가 기능을 포함하고 특별한 연구를 수행하여 사용자가 프로그램이 실제로 올바르게 작동한다는 확신(100%는 아니더라도)을 가질 수 있도록 해야 합니다.
| IBM Rational 방법론 및 도구 |
| 일반적인 소프트웨어 개발 방법론인 Rational Unified Process는 상당히 큰 테스트 유형 세트를 식별합니다(그림 참조). 어느 정도 관례에 따라 다음과 같이 나눌 수 있습니다. 기능 테스트
IBM Rational TestManager테스트의 모든 단계에 필요한 단일 제어판을 사용하여 테스트를 계획, 설계, 실행 및 분석하기 위한 공통 도구를 팀에 제공합니다. 이 제품에는 자체 데이터 저장소가 있어 더 나은 버전 관리가 가능합니다. 자체 API가 있는 모든 소프트웨어 테스트 도구는 단일 시스템에 쉽게 통합되며 대부분의 테스트 실행 플랫폼을 지원할 수 있습니다. IBM Rational PurifyPlus Visual C/C++, C#, VB, VB .NET, Java, Java .NET을 사용하여 개발된 애플리케이션 및 구성 요소의 실시간 분석을 위해 설계된 세 가지 도구가 포함되어 있습니다. Purify는 메모리 관련 오류를 자동으로 감지하여 오류의 소스와 위치를 강조 표시합니다. 소스 코드가 사용 가능한 경우 Purify에서 직접 패치할 수 있습니다. 특허 받은 개체 코드 삽입 기술을 사용하면 소스 코드뿐만 아니라 바이너리 소프트웨어 구성 요소(DLL, COM/DCOM 개체, ODBC)에서도 메모리 액세스 오류를 감지할 수 있습니다. PureCoverage는 테스트되지 않은 코드를 자동으로 감지하는 도구입니다. Quantify는 소스 코드 유무에 관계없이 애플리케이션 및 구성 요소 병목 현상을 식별하기 위해 성능 평가를 수행합니다. 내장된 데이터 분석 도구를 사용하면 다양한 코드 변형에 대한 테스트 실행 결과를 비교할 수 있습니다. IBM 래셔널 로봇- 인터넷 애플리케이션, ERP 시스템 및 클라이언트-서버 솔루션의 자동화된 테스트를 생성, 수정 및 실행하기 위한 도구입니다. 다양한 개발 도구를 사용하여 애플리케이션을 생성하기 위한 개체 수준 지원을 제공합니다. 기능 테스트 스크립트는 VB와 구문적으로 호환되는 SQABasic 환경에서 생성됩니다. 내장된 편집기를 사용하면 필요한 절차와 논리적 조건으로 테스트 스크립트를 확장할 수 있습니다. 다양한 유형의 소프트웨어 개체에 대한 특수 테스트를 만드는 것이 가능합니다. 스크립트를 생성하기 위해 우리는 C와 유사한 자체 언어를 사용합니다. IBM Rational TestFactory- 신뢰성 결함을 식별하기 위해 실행 중인 애플리케이션에 대한 포괄적인 분석을 통해 테스트 스크립트를 자동으로 생성하는 도구입니다. 프로그램에는 실행 경로가 너무 많기 때문에 최소한의 단계로 애플리케이션의 전체 기능을 테스트하는 테스트를 만드는 것이 과제입니다. IBM Rational XDE 테스터- Java 애플리케이션(J2EE, J2SE, SWT, AWT/JFC) 및 웹 애플리케이션(HTML, DHTML, XML, JavaScript, Java 애플릿)을 테스트하기 위한 전문 도구입니다. 텍스트 스크립트는 Java로 작성되며 ScriptAssure 기술은 동적 데이터의 유효성을 검사합니다. 테스트 환경은 Eclipse 쉘에서 구현되며, WebSphere Studio 및 Rational XDE Developer에 도구를 임베드할 수 있습니다. |
소프트웨어 테스팅은 개발 중인 소프트웨어/제품을 평가하여 기능, 기능 및 예상 결과 준수 여부를 확인하는 것입니다. 이 기사에서는 테스트 및 품질 보증 분야에서 사용되는 다양한 유형의 방법을 설명합니다.
소프트웨어 테스트는 소프트웨어 개발 주기의 필수적인 부분입니다.
소프트웨어 테스팅이란 무엇입니까?
소프트웨어 테스팅은 제어된 작동 조건과 제어되지 않은 작동 조건에서 코드 조각을 테스트하고 출력을 관찰한 다음 미리 정의된 조건을 충족하는지 검사하는 것에 지나지 않습니다.
다양한 테스트 사례 및 테스트 전략 세트는 코드의 버그와 오류를 제거하고 정확하고 최적의 소프트웨어 성능을 보장한다는 하나의 공통 목표를 달성하는 것을 목표로 합니다.
테스트 방법론
널리 사용되는 테스트 방법에는 단위 테스트, 통합 테스트, 승인 테스트 및 시스템 테스트가 있습니다. 소프트웨어는 특정 순서로 이러한 테스트를 거칩니다.
3) 시스템 테스트
4) 승인 테스트
우선, 단위 테스트가 수행됩니다. 이름에서 알 수 있듯이 이는 개체 수준 테스트 방법입니다. 개별 소프트웨어 구성 요소에 오류가 있는지 테스트됩니다. 이 테스트에는 프로그램과 설치된 각 모듈에 대한 정확한 지식이 필요합니다. 따라서 이 점검은 테스터가 아닌 프로그래머가 수행합니다. 이를 위해 소프트웨어가 의도한 대로 작동하는지 확인하는 테스트 코드가 생성됩니다.
이미 단위 테스트를 마친 개별 모듈은 서로 통합되어 결함이 있는지 확인합니다. 이러한 유형의 테스트는 주로 인터페이스 오류를 식별합니다. 통합 테스트는 시스템의 아키텍처 설계에 따라 하향식 접근 방식을 사용하여 수행할 수 있습니다. 또 다른 접근 방식은 제어 흐름의 맨 아래에서 구현되는 상향식 접근 방식입니다.
시스템 테스트
이 테스트에서는 전체 시스템에 오류와 버그가 있는지 확인합니다. 이 테스트는 전체 시스템의 하드웨어와 소프트웨어 구성 요소를 페어링한 후 테스트하는 방식으로 수행됩니다. 이 테스트는 사용자가 예상하는 소프트웨어의 작동 조건을 테스트하는 블랙박스 테스트 방식으로 분류됩니다.
승인 테스트
이는 소프트웨어가 클라이언트에 출시되기 전에 수행되는 마지막 테스트입니다. 개발된 소프트웨어가 모든 고객 요구 사항을 충족하는지 확인하기 위해 수행됩니다. 승인 테스트에는 두 가지 유형이 있습니다. 하나는 개발 팀 구성원이 수행하는 내부 승인 테스트(알파 테스트)이고 다른 하나는 고객이 수행하는 외부 승인 테스트입니다.
잠재 고객을 대상으로 테스트를 수행하는 것을 클라이언트 승인 테스트라고 합니다. 소프트웨어의 최종 사용자가 테스트를 수행하는 것을 승인 테스트(베타 테스트)라고 합니다.
소프트웨어 테스팅 체제의 일부를 구성하는 몇 가지 기본 테스팅 기술이 있습니다. 이러한 테스트는 일반적으로 전체 시스템에서 오류와 버그를 찾는 데 자급자족하는 것으로 간주됩니다.
블랙박스 테스트
블랙박스 테스트는 시스템 내부 작동에 대한 지식 없이 수행됩니다. 테스터는 다양한 입력을 제공하고 생성된 출력을 테스트하여 소프트웨어를 사용자 환경으로 구동합니다. 이 테스트는 블랙박스 테스트, 폐쇄형 테스트 또는 기능 테스트라고도 합니다.
화이트박스 테스트
블랙박스 테스트와 달리 화이트박스 테스트는 코드의 내부 기능과 논리를 고려합니다. 이 테스트를 수행하려면 테스터는 오류가 있는 코드의 정확한 부분을 알기 위해 코드에 대한 지식을 가지고 있어야 합니다. 이 테스트는 화이트박스, 오픈박스 또는 유리박스 테스트라고도 합니다.
회색 상자 테스트
그레이 박스 테스트 또는 그레이 박스 테스트는 화이트 박스와 블랙 박스 테스트 사이에 있으며 테스터는 테스트를 수행하는 데 필요한 제품에 대한 일반적인 지식만 가지고 있습니다. 이 검증은 문서 및 정보 흐름도를 통해 수행됩니다. 테스트는 최종 사용자 또는 최종 사용자로 보이는 사용자가 수행합니다.
비기능 테스트
애플리케이션 보안은 개발자의 주요 업무 중 하나입니다. 보안 테스트는 소프트웨어의 기밀성, 무결성, 인증, 가용성 및 부인 방지를 테스트합니다. 프로그램 코드에 대한 무단 액세스를 방지하기 위해 개별 테스트가 수행됩니다.
스트레스 테스트는 소프트웨어가 소프트웨어의 정상적인 작동 조건을 벗어난 조건에 노출되는 기술입니다. 임계점에 도달한 후 얻은 결과가 기록됩니다. 이 테스트는 전체 시스템의 안정성을 결정합니다.
소프트웨어는 운영 체제, 하드웨어 플랫폼, 웹 브라우저 등과 같은 외부 인터페이스와의 호환성 테스트를 거쳤습니다. 호환성 테스트는 제품이 모든 소프트웨어 플랫폼과 호환되는지 확인합니다.
이름에서 알 수 있듯이 이 테스트 기술은 단일 작업을 수행할 때 프로그램이 사용하는 코드 또는 리소스의 양을 테스트합니다.
이 테스트는 사용자를 위한 소프트웨어의 유용성과 실용성 측면을 확인합니다. 사용자가 장치에 쉽게 액세스할 수 있는지가 주요 테스트 지점을 형성합니다. 사용성 테스트는 학습, 효율성, 만족도, 기억력, 오류 등 테스트의 5가지 측면을 다룹니다.
소프트웨어 개발 중 테스트
폭포수 모델은 소프트웨어 개발이나 테스트에 사용되는 하향식 접근 방식을 사용합니다.
이 소프트웨어 테스트 방법론과 관련된 주요 단계는 다음과 같습니다.
- 요구 분석
- 설계 테스트
- 구현 테스트
- 코드 또는 제품 테스트, 디버깅 및 검토
- 구현 및 유지 관리
이 기술에서는 이전 단계를 완료한 후에만 다음 단계로 이동합니다. 이 모델은 비반복적 접근 방식을 사용합니다. 이 기술의 가장 큰 장점은 단순화되고 체계적이며 정통적인 접근 방식입니다. 그러나 코드의 버그와 오류는 테스트 단계까지 감지되지 않기 때문에 많은 단점이 있습니다. 이로 인해 시간, 돈, 기타 귀중한 자원이 낭비되는 경우가 많습니다.
민첩한 모델
이 방법론은 상당히 다양한 새로운 개발 방법 외에도 순차적 및 반복적 접근 방식의 선택적인 조합을 기반으로 합니다. 신속하고 진보적인 개발은 이 방법론의 핵심 원칙 중 하나입니다. 빠르고 실용적이며 가시적인 결과를 얻는 데 중점을 둡니다. 지속적인 고객 상호 작용 및 참여는 전체 개발 프로세스에서 필수적인 부분입니다.
신속한 애플리케이션 개발(RAD). 신속한 애플리케이션 개발 방법론
이름은 그 자체로 말합니다. 이 경우 방법론은 구성 요소 설계 원리를 사용하여 빠르게 진화하는 접근 방식을 취합니다. 특정 프로젝트의 다양한 요구 사항을 이해한 후 신속한 프로토타입을 준비한 다음 예상되는 출력 조건 및 표준과 비교합니다. 필요한 변경 및 수정은 고객 또는 개발팀(소프트웨어 테스트 맥락에서)과의 공동 논의 후에 이루어집니다.
이 접근 방식에는 장점이 있지만 프로젝트가 크고 복잡하거나 요구 사항이 지속적으로 변화하는 매우 동적인 성격을 갖는 경우에는 적합하지 않을 수 있습니다.
나선형 모델
이름에서 알 수 있듯이 나선형 모델은 계단식 모델의 모든 연속 단계에서 여러 주기(또는 나선형)가 있는 접근 방식을 기반으로 합니다. 초기 주기가 완료되면 달성된 제품 또는 결과물에 대한 철저한 분석 및 검토가 수행됩니다. 출력이 지정된 요구 사항이나 예상 표준을 충족하지 않으면 두 번째 주기가 수행됩니다.
RUP(합리적 통합 프로세스). 합리적인 통합 프로세스
RUP 기술은 전체 테스트 절차가 여러 주기로 나누어진다는 점에서 나선형 모델과 유사합니다. 각 주기는 창조, 개발, 구축, 전환의 4단계로 구성됩니다. 각 주기가 끝나면 제품/산출물을 검토하고 필요에 따라 주기(동일한 4단계로 구성)를 따릅니다.
정보 기술의 사용이 날로 증가하고 있으며 적절한 소프트웨어 테스트의 중요성도 크게 높아졌습니다. 많은 회사에서는 이러한 목적을 위해 개발자 수준의 역량을 갖춘 특별 팀을 운영합니다.