소프트웨어 테스팅 유형(100가지 예)

소프트웨어 테스팅 유형이란 무엇입니까?

소프트웨어 테스트 유형은 다양한 테스트 활동을 범주별로 분류한 것으로, 각 범주에는 명확하게 정의된 테스트 목표, 테스트 전략 및 테스트 산출물이 있습니다. 테스트 유형을 설정하는 목적은 정의된 테스트 목표에 따라 테스트 대상 애플리케이션(AUT)의 유효성을 검증하는 것입니다. 예를 들어, 접근성 테스트의 목표는 장애인이 AUT에 접근할 수 있는지 검증하는 것입니다. 따라서 소프트웨어 솔루션이 장애인 친화적이어야 한다면 접근성 테스트 케이스를 통해 검증해야 합니다.

QA 전문가, 개발자 및 프로젝트 관리자에게는 다양한 소프트웨어 테스트 유형을 이해하는 것이 필수적입니다. 각 테스트 유형은 특정 품질 문제를 해결하며, 적절한 조합을 선택하면 애플리케이션을 완벽하게 검증할 수 있습니다.

소프트웨어 테스팅의 유형

아래는 포괄적인 목록입니다. 105가지 소프트웨어 테스팅 유형 정의와 함께 수록되어 있습니다. 모든 QA 전문가에게 필독서입니다. 모든 소프트웨어 테스트 유형에 대한 안내서로서, 각 접근 방식을 빠르게 찾고 이해할 수 있도록 구성되어 있습니다.

1. 승인 테스트: 시스템이 승인 기준을 충족하는지 확인하고 고객이 시스템 승인 여부를 결정할 수 있도록 하기 위해 수행되는 공식 테스트입니다. 일반적으로 고객이 수행합니다. 자세히 알아보기 수락 테스트
2. 접근성 테스트: 장애인(청각 장애인, 시각 장애인, 정신 장애인 등)이 제품을 얼마나 쉽게 사용할 수 있는지 평가하는 테스트 유형입니다. 평가 과정은 장애인이 직접 진행합니다. 더 자세한 내용은 다음을 참조하세요. 접근성 테스트
3. 활성 테스트: 테스트 데이터를 도입하고 실행 결과를 분석하는 테스트 유형입니다. 일반적으로 테스트 팀에서 수행합니다.
4. 민첩한 테스트: 애자일 선언문의 원칙을 따르는 소프트웨어 테스팅 관행으로, 시스템을 활용할 고객의 관점에서 테스팅을 강조합니다. 일반적으로 QA 팀에서 수행합니다. 자세히 알아보기 애자일 테스트
5. 연령 테스트: 미래에 시스템의 성능을 평가하는 테스트 유형입니다. 평가 프로세스는 테스트 팀에 의해 수행됩니다.
6. 임시 테스트: 계획 및 문서화 없이 수행되는 테스트 – 테스터는 시스템 기능을 무작위로 시도하여 시스템을 '중단'시키려고 합니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 임시 테스트
7. 알파 테스트 : 알파 테스트는 베타 테스트를 위해 제품을 출시하기 전에 버그, 사용성 문제 및 기능 간극을 파악하기 위해 개발자 사이트에서 수행하는 소프트웨어 테스트 유형입니다. 여기에는 개발자 및 QA 팀과 같은 내부 테스터가 참여하며 때로는 통제된 환경에서 최종 사용자를 선택합니다. 자세한 내용은 알파 테스트
8. 어설션 테스트: 조건이 제품 요구 사항을 확인하는지 확인하는 것으로 구성된 테스트 유형입니다. 이는 테스트 팀에 의해 수행됩니다.
9. API 테스트 : 코드 수준을 대상으로 한다는 점에서 단위 테스트와 유사한 테스트 기술입니다. Api 테스트는 일반적으로 개발자 작업이 아닌 QA 작업이라는 점에서 단위 테스트와 다릅니다. 자세히 알아보기 API 테스팅
10. 모든 쌍 테스트: 입력 매개변수의 가능한 모든 개별 조합을 테스트하는 조합 테스트 방법입니다. 이는 테스트 팀에 의해 수행됩니다.

11. 자동화된 테스트: 자동화 테스트 도구를 사용하여 환경 설정, 테스트 실행 및 결과 보고를 제어하는 ​​테스트 기술입니다. 이는 컴퓨터에 의해 수행되며 테스트 팀 내부에서 사용됩니다. 자세히 알아보기 자동화 테스트
12. 기본 경로 테스트: 절차적 설계의 논리적 복잡성 측정을 도출하고 이를 기본 실행 경로 집합을 정의하기 위한 가이드로 사용하는 테스트 메커니즘입니다. 테스트 팀이 테스트 사례를 정의할 때 사용합니다. 자세히 알아보기 기본 경로 테스트
13. 이전 버전과의 호환성 테스트: 이전 버전의 테스트 환경에서 개발된 소프트웨어의 동작을 검증하는 테스트 방법입니다. 그것은 테스트 팀에 의해 수행됩니다.
14. 베타 테스트 : 상업적 목적으로 애플리케이션을 출시하기 전 최종 테스트입니다. 이는 일반적으로 최종 사용자나 다른 사람이 수행합니다.
15. 벤치마크 테스트: 주어진 구성에서 컴퓨터 하드웨어와 소프트웨어의 성능을 평가하기 위해 설계된 대표적인 프로그램 및 데이터 세트를 사용하는 테스트 기술입니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 벤치 마크 테스트
16. 빅뱅 통합 테스트: 모든 것이 준비된 경우에만 개별 프로그램 모듈을 통합하는 테스트 기술입니다. 이는 테스트 팀에 의해 수행됩니다.
17. 바이너리 이식성 테스트: 일반적으로 ABI 사양을 준수하는지 확인하기 위해 시스템 플랫폼과 환경 전반에 걸쳐 실행 가능한 애플리케이션의 이식성을 테스트하는 기술입니다. 이는 테스트 팀에 의해 수행됩니다.
18. 경계값 테스트: 경계 값의 대표자를 포함하도록 테스트를 설계하는 소프트웨어 테스트 기술입니다. 이는 QA 테스트 팀에서 수행됩니다. 자세히 알아보기 경계값 테스트
19. 상향식 통합 테스트: 상향식 통합 테스트에서는 가장 낮은 수준의 모듈이 먼저 개발되고 '메인' 프로그램으로 향하는 다른 모듈이 하나씩 통합되어 테스트됩니다. 일반적으로 테스트 팀에서 수행합니다.
20. 지점 테스트: 프로그램 소스 코드의 모든 분기를 한 번 이상 테스트하는 테스트 기술입니다. 이는 개발자가 수행합니다.
21. 폭 테스트: 제품의 전체 기능을 실행하지만 세부적인 기능을 테스트하지는 않는 테스트 모음입니다. 이는 테스트 팀에 의해 수행됩니다.
22. 블랙박스 테스트: 애플리케이션의 코드/내부 구조에 대한 구체적인 지식 없이 애플리케이션의 기능을 확인하는 소프트웨어 테스팅 방법입니다. 테스트는 요구 사항과 기능을 기반으로 합니다. QA팀에서 수행합니다. 자세히 알아보기 블랙박스 테스팅
23. 코드 기반 테스트: 단위 테스트를 실행하여 코드의 다양한 섹션이 다양한 상황에서 예상대로 작동하는지 확인하는 테스트 프레임워크(예: xUnit)를 사용하는 테스트 기술입니다. 개발팀에서 수행합니다.
24. 호환성 테스트: 특정 하드웨어/소프트웨어/운영 체제/네트워크 환경에서 소프트웨어가 얼마나 잘 수행되는지 검증하는 테스트 기술입니다. 테스트 팀에서 수행합니다. 자세히 보기 호환성 테스트
25. 비교 테스트: 제품의 강점과 약점을 이전 버전이나 다른 유사한 제품과 비교하는 테스트 기술입니다. 테스터, 개발자, 제품 관리자 또는 제품 소유자가 수행할 수 있습니다. 자세히 알아보기 구성 요소 테스트
26. 구성 요소 테스트: 단위 테스트와 유사하지만 통합 수준이 더 높은 테스트 기술 – 테스트는 특정 방법을 직접 테스트하는 대신 애플리케이션의 컨텍스트에서 수행됩니다. 테스트 또는 개발 팀에서 수행할 수 있습니다.
27. 구성 테스트: 하드웨어와 소프트웨어의 최소 및 최적 구성과 메모리, 디스크 드라이브, CPU 등의 자원을 추가하거나 수정했을 때의 효과를 결정하는 테스트 기술입니다. 일반적으로 성능 테스트 엔지니어가 수행합니다. 자세히 알아보기 구성 테스트
28. 조건 커버리지 테스트: 각 조건을 최소 한 번 이상 각 방법으로 참 및 거짓으로 만들어 실행하는 소프트웨어 테스트 유형입니다. 일반적으로 자동화 테스트 팀에서 수행합니다.
29. 규정 준수 테스트: 시스템이 표준, 절차 및 지침에 따라 개발되었는지 확인하는 테스트 유형입니다. 일반적으로 "인증된 OGC 준수" 브랜드를 제공하는 외부 회사에서 수행됩니다.
30. 동시성 테스트: 동일한 애플리케이션 코드, 모듈 또는 데이터베이스 기록에 액세스할 때의 효과를 확인하기 위한 다중 사용자 테스트입니다. 이는 일반적으로 성능 엔지니어가 수행합니다. 자세히 알아보기 동시성 테스트
31. 적합성 테스트: 구현이 기반이 되는 사양을 준수하는지 테스트하는 프로세스입니다. 일반적으로 테스트 팀에서 수행됩니다. 자세히 알아보기 적합성 테스트
32. 상황 기반 테스트: 공개된 잠재적인 정보와 특정 순간에 조직에 대한 해당 정보의 가치를 고려하여 테스트 기회에 대한 지속적이고 창의적인 평가를 옹호하는 Agile Testing 기술입니다. 일반적으로 Agile 테스트 팀에서 수행합니다.

33. 변환 테스트: 대체 시스템에서 사용하기 위해 기존 시스템의 데이터를 변환하는 데 사용되는 프로그램 또는 절차를 테스트합니다. 일반적으로 QA 팀에서 수행합니다.
34. 의사결정 범위 테스트: 각 조건/결정을 true/false로 설정하여 실행하는 소프트웨어 테스트 유형입니다. 일반적으로 자동화 테스트 팀에서 수행합니다.
35. 파괴적인 테스트: 시편이 파손될 때까지 시험을 수행하여 다양한 하중 조건에서 시편의 구조적 성능 또는 재료의 거동을 파악하는 시험 유형입니다. 일반적으로 품질보증(QA) 팀에서 수행합니다. 더 자세한 내용은 다음을 참조하십시오. 파괴적인 테스트
36. 종속성 테스트: 적절한 기능을 유지하기 위해 기존 소프트웨어, 초기 상태 및 구성에 대한 응용 프로그램의 요구 사항을 검사하는 테스트 유형입니다. 일반적으로 테스트 팀에서 수행됩니다.
37. 동적 테스트: 코드의 동적 동작 테스트를 설명하기 위해 소프트웨어 엔지니어링에서 사용되는 용어입니다. 일반적으로 테스트 팀에서 수행됩니다. 자세히 알아보기 동적 테스트
38. 도메인 테스트: 프로그램이 유효한 입력만 받아들이는지 확인하는 체크를 포함하는 화이트 박스 테스트 기술입니다. 일반적으로 소프트웨어 개발 팀에서 수행하고 가끔은 자동화 테스트 팀에서 수행합니다.
39. 오류 처리 테스트: 시스템이 오류 거래를 제대로 처리할 수 있는 능력을 결정하는 소프트웨어 테스트 유형입니다. 일반적으로 테스트 팀에서 수행합니다.
40. 엔드투엔드 테스트: 시스템 테스트와 유사하게 데이터베이스와의 상호 작용, 네트워크 통신 사용 또는 적절한 경우 다른 하드웨어, 애플리케이션 또는 시스템과의 상호 작용과 같이 실제 사용을 모방하는 상황에서 전체 애플리케이션 환경을 테스트하는 작업이 포함됩니다. QA팀에서 수행합니다. 자세히 알아보기 엔드 투 엔드 테스트
41. 내구성 테스트: 장기간 실행 시 발생할 수 있는 메모리 누수 또는 기타 문제를 확인하는 테스트 유형입니다. 이는 일반적으로 성능 엔지니어가 수행합니다. 자세히 알아보기 내구성 테스트
42. 탐색적 테스트: 계획 및 문서화 없이 수행되는 블랙박스 테스트 기술입니다. 일반적으로 수동 테스터가 수행합니다. 자세히 보기 탐색 적 테스트
43. 등가 분할 테스트: 소프트웨어 단위의 입력 데이터를 테스트 사례가 파생될 수 있는 데이터 파티션으로 나누는 소프트웨어 테스팅 기술입니다. 일반적으로 QA 팀에서 수행합니다. 자세히 알아보기 등가 분할 테스트
44. 결함 주입 테스트: 테스터가 테스트 중인 애플리케이션이 예외를 처리할 수 있는 방식에 집중할 수 있도록 하는 포괄적인 테스트 전략의 요소입니다. QA팀에서 수행합니다.
45. 공식 검증 테스트: 특정 공식 사양이나 속성에 대한 시스템의 기본이 되는 의도된 알고리즘의 정확성을 수학의 공식적 방법을 사용하여 증명하거나 반증하는 행위입니다. 일반적으로 QA 팀에서 수행합니다.
46. 기능 테스트 : 테스트 케이스를 테스트 대상 소프트웨어 구성 요소의 사양에 기반하는 블랙박스 테스트 유형입니다. 테스트 팀에서 수행합니다. 자세히 보기 기능 테스트
47. 퍼즈 테스트: 프로그램 입력에 유효하지 않거나 예상치 못한 또는 무작위 데이터를 제공하는 소프트웨어 테스트 기술 – 돌연변이 테스트의 특수 영역입니다. 퍼지 테스트는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 퍼지 테스트
48. 고릴라 테스트: 하나의 특정 모듈을 집중적으로 테스트하는 데 초점을 맞춘 소프트웨어 테스트 기술입니다. 이는 일반적으로 전체 테스트를 실행할 때 품질 보증 팀에 의해 수행됩니다.
49. 회색 Box 테스트 : 블랙의 조합 Box 과 백인 Box 테스팅 방법론: 소프트웨어의 명세를 기준으로 소프트웨어의 성능을 테스트하되, 내부 작동 방식에 대한 지식을 활용하는 것입니다. 개발팀이나 테스팅팀 모두 수행할 수 있습니다.
50. 유리 상자 테스트: 화이트 박스 테스트와 유사하며, 애플리케이션 코드의 내부 로직에 대한 지식을 기반으로 합니다. 개발팀에서 수행합니다.
51. GUI 소프트웨어 테스트: 그래픽 사용자 인터페이스를 사용하는 제품을 테스트하여 작성된 사양을 충족하는지 확인하는 프로세스입니다. 이는 일반적으로 테스트 팀에서 수행됩니다. 자세히 알아보기 GUI 소프트웨어 테스트
52. 세계화 테스트: 가능한 모든 유형의 국제 입력을 사용하여 문화/로케일 설정으로 제품의 올바른 기능을 확인하는 테스트 방법입니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 세계화 테스트
53. 하이브리드 통합 테스트: 이러한 종류의 테스트의 이점을 활용하기 위해 하향식 및 상향식 통합 기술을 결합한 테스트 기술입니다. 일반적으로 테스트 팀에서 수행합니다.
54. 통합 테스트 : 개별 소프트웨어 모듈을 그룹으로 결합하고 테스트하는 소프트웨어 테스팅 단계입니다. 일반적으로 테스트 팀에서 수행됩니다. 자세히 알아보기 통합 테스팅
55. 인터페이스 테스트: 시스템이나 구성 요소가 서로 데이터를 전달하고 올바르게 제어하는지 여부를 평가하기 위해 테스트가 수행되었습니다. 일반적으로 테스트 팀과 개발 팀 모두에서 수행됩니다. 자세히 알아보기 인터페이스 테스트
56. 설치/제거 테스트: 고객이 새 소프트웨어를 성공적으로 설치하고 설정하기 위해 무엇을 해야 하는지에 초점을 맞춘 품질 보증 작업입니다. 전체, 부분 또는 업그레이드 설치/제거 프로세스가 포함될 수 있으며 일반적으로 소프트웨어 테스트 엔지니어가 구성 관리자와 협력하여 수행합니다.
57. 국제화 테스트: 다른 언어와 로케일에서 사용될 때 제품의 기능이 손상되지 않고 모든 메시지가 적절하게 외부화되도록 보장하는 프로세스입니다. 일반적으로 테스트 팀에서 수행합니다.
58. 시스템 간 테스트: 애플리케이션 간 상호 연결이 올바르게 기능하는지 확인하는 데 중점을 둔 테스트 기술입니다. 일반적으로 테스트 팀에서 수행합니다.
59. 키워드 중심 테스트: 테이블 기반 테스트 또는 실행 단어 테스트라고도 하는 것은 테스트 생성 프로세스를 계획 단계와 구현 단계라는 두 가지 단계로 구분하는 자동화된 테스트를 위한 소프트웨어 테스트 방법론입니다. 수동 또는 자동화 테스트 팀에서 사용할 수 있습니다. 자세히 알아보기 키워드 중심 테스트
60. 부하 테스트: 시스템이나 장치에 수요를 두고 그 반응을 측정하는 테스트 기술입니다. 이는 일반적으로 성능 엔지니어가 수행합니다. 자세히 알아보기 부하 테스트
61. 현지화 테스트: 세계화된 애플리케이션을 특정 문화/로케일에 맞게 조정하는 데 초점을 맞춘 소프트웨어 테스트 프로세스의 일부입니다. 일반적으로 테스트 팀에서 수행합니다. 자세히 알아보기 현지화 테스트
62. 루프 테스트: 프로그램 루프를 연습하는 화이트 박스 테스트 기술입니다. 개발팀에서 수행합니다. 자세히 보기 루프 테스트
63. 수동 스크립트 테스트: 테스트 케이스를 실행하기 전에 팀에서 테스트 케이스를 설계하고 검토하는 테스트 방법입니다. 이는 수동 테스트 팀에서 수행됩니다.
64. 수동 지원 테스트: 데이터를 준비하고 자동화된 시스템에서 이러한 데이터를 사용하는 동안 사람이 수행하는 모든 기능을 테스트하는 테스트 기술입니다. 테스트 팀에 의해 수행됩니다.
65. 모델 기반 테스트: 소프트웨어 테스팅을 수행하는 데 필요한 아티팩트를 설계하고 실행하기 위한 모델 기반 설계를 적용합니다. 일반적으로 테스트 팀에서 수행됩니다. 자세히 알아보기 모델 기반 테스트
66. 돌연변이 테스트: 일반적인 테스트 실행 중에 거의 또는 전혀 액세스되지 않는 코드 섹션을 테스트하기 위해 프로그램의 소스 코드 또는 바이트 코드를 작은 방식으로 수정하는 소프트웨어 테스트 방법입니다. 일반적으로 테스터가 수행합니다. 자세히 알아보기 돌연변이 테스트
67. 모듈성 기반 테스트: 테스트 중인 애플리케이션의 모듈, 섹션 및 기능을 나타내는 작고 독립적인 스크립트를 생성해야 하는 소프트웨어 테스팅 기술입니다. 일반적으로 테스트 팀에서 수행합니다.
68. 비기능 테스트: 비기능적 요구사항에 대한 소프트웨어 애플리케이션 테스트에 초점을 맞춘 테스트 기술입니다. 성능 엔지니어 또는 수동 테스트 팀이 수행할 수 있습니다. 자세히 알아보기 비기능 테스트
69. 부정적인 테스트: "실패 테스트"라고도 알려진 테스트 방법은 테스트의 목적이 구성 요소나 시스템이 작동하지 않는다는 것을 보여주는 것입니다. 수동 또는 자동화 테스터가 수행합니다. 자세한 내용은 음성 테스트
70. Opera추가적인 테스트: 시스템이나 구성 요소를 운영 환경에서 평가하기 위해 수행되는 테스트 기술입니다. 일반적으로 테스트 팀에서 수행합니다. 자세히 보기 Opera선택적 테스트
71. 직교 배열 테스트: 사용자 인터페이스 테스트, 시스템 테스트, 회귀 테스트, 구성 테스트 및 성능 테스트에 적용할 수 있는 체계적이고 통계적인 테스트 방법입니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 직교 배열 테스트
72. 쌍 테스트: 두 팀 구성원이 하나의 키보드에서 함께 작업하여 소프트웨어 애플리케이션을 테스트하는 소프트웨어 개발 기술입니다. 하나는 테스트를 수행하고 다른 하나는 테스트를 분석하거나 검토합니다. 이는 한 명의 테스터와 개발자 또는 비즈니스 분석가 사이에서 또는 두 참가자가 교대로 키보드를 운전하는 두 명의 테스터 사이에서 수행될 수 있습니다.
73. 패시브 테스트: 특별한 테스트 데이터를 도입하지 않고 실행 중인 시스템의 결과를 모니터링하는 테스트 기술입니다. 이는 테스트 팀에 의해 수행됩니다.
74. 병렬 테스트: 이전 버전을 대체한 새 애플리케이션이 설치되어 올바르게 실행되고 있는지 확인하는 목적을 가진 테스트 기술입니다. 테스트팀에서 진행합니다. 자세히 알아보기 병렬 테스트
75. 경로 테스트: 프로그램의 각 논리적 경로에 대한 적용 범위 기준을 충족하는 것을 목표로 하는 전형적인 화이트 박스 테스트입니다. 일반적으로 개발 팀에서 수행합니다. 자세히 알아보기 경로 테스트
76. 침투 테스트: 악의적인 소스로부터의 공격을 시뮬레이션하여 컴퓨터 시스템이나 네트워크의 보안을 평가하는 테스트 방법입니다. 일반적으로 전문 침투 테스트 회사에서 수행합니다. 자세히 알아보기 침투 테스트
77. 성능 시험: 지정된 성능 요구 사항에 대한 시스템 또는 구성 요소의 준수 여부를 평가하기 위해 수행되는 기능 테스트입니다. 이는 일반적으로 성능 엔지니어가 수행합니다. 자세히 알아보기 성능 시험
78. 자격 테스트: 소프트웨어가 지정된 요구 사항을 충족하는지 입증하기 위해 일반적으로 개발자가 소비자를 위해 수행하는 이전 릴리스의 사양에 대한 테스트입니다.
79. Ramp 테스트 : 시스템이 고장날 때까지 입력 신호를 지속적으로 높이는 것으로 구성된 테스트 유형입니다. 테스트 팀이나 성능 엔지니어가 수행할 수 있습니다.
80. 회귀 테스트 : 프로그램 변경(예: 버그 수정 또는 새로운 기능)이 이루어진 후 프로그램을 다시 테스트하여 소프트웨어 오류를 찾아내려는 소프트웨어 테스트 유형입니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 Regression Testing
81. 복구 테스트 : 충돌, 하드웨어 오류 또는 기타 치명적인 문제로부터 시스템이 얼마나 잘 복구되는지 평가하는 테스트 기술입니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 복구 테스트
82. 요구사항 테스트: 요구 사항이 정확하고 완전하며 모호하지 않고 논리적으로 일관성이 있는지 검증하고 해당 요구 사항에서 필요하고 충분한 테스트 사례 세트를 설계할 수 있는 테스트 기술입니다. QA팀에서 수행합니다.
83. 보안 테스트 : 정보 시스템이 의도한 대로 데이터를 보호하고 기능을 유지하는지 확인하는 프로세스입니다. 테스트 팀이나 전문 보안 테스트 회사에서 수행할 수 있습니다. 자세히 알아보기 보안 테스트
84. 온전성 테스트: 새로운 소프트웨어 버전이 주요 테스트 노력에 적합할 만큼 잘 작동하는지 확인하는 테스트 기술입니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 온 전성 테스트
85. 시나리오 테스트: 가상 스토리에 기반한 시나리오를 사용하여 테스트 환경에서 복잡한 문제나 시스템을 생각하는 데 도움이 되는 테스트 활동입니다. 테스트 팀에서 수행합니다. 자세히 보기 시나리오 테스트
86. 확장성 테스트: 지원되는 사용자 로드, 트랜잭션 수, 데이터 볼륨 등 확장 기능을 측정하기 위해 소프트웨어 애플리케이션을 테스트하는 비기능 테스트 배터리의 일부입니다. 이 테스트는 성능 엔지니어가 수행합니다. 자세히 알아보기 확장성 테스트
87. 진술 테스트: 프로그램 테스트 중에 프로그램의 각 문장이 최소한 한 번은 실행된다는 기준을 충족하는 화이트 박스 테스트. 일반적으로 개발팀에서 수행합니다.
88. 정적 테스트: 소프트웨어를 실제로 사용하지 않고 실시하는 소프트웨어 테스트의 한 형태입니다. 주로 코드, 알고리즘 또는 문서의 타당성을 검사합니다. 코드를 작성한 개발자가 사용합니다. 더 자세한 내용은 다음을 참조하세요. 정적 테스트
89. 안정성 테스트: 애플리케이션이 충돌하는지 확인하는 테스트 기술입니다. 이는 일반적으로 성능 엔지니어가 수행합니다. 자세히 알아보기 안정성 테스트
90. 연기 테스트: 소프트웨어 시스템의 모든 기본 구성 요소를 검사하여 제대로 작동하는지 확인하는 테스트 기술입니다. 일반적으로 스모크 테스트는 소프트웨어 빌드가 완료된 직후 테스트 팀에서 수행됩니다. 자세히 알아보기 연기 테스트
91. 스토리지 테스트: 테스트 중인 프로그램이 데이터 파일을 올바른 디렉토리에 저장하고 공간 부족으로 인한 예기치 않은 종료를 방지하기 위해 충분한 공간을 확보하고 있는지 확인하는 테스트 유형입니다. 일반적으로 테스트 팀에서 수행합니다. 자세히 알아보기 스토리지 테스트
92. 스트레스 테스트: 지정된 요구 사항의 한계 이상으로 시스템이나 구성 요소를 평가하는 테스트 기술입니다. 이는 일반적으로 성능 엔지니어가 수행합니다. 자세히 알아보기 스트레스 테스트
93. 구조 테스트: 시스템이나 구성 요소의 내부 구조를 고려하고 각 프로그램 명령문이 의도한 기능을 수행하는지 확인하는 화이트 박스 테스트 기술입니다. 일반적으로 소프트웨어 개발자가 수행합니다.
94. 시스템 테스트: 시스템이 지정된 요구 사항을 충족하는지 확인하기 위해 통합된 하드웨어 및 소프트웨어 시스템을 테스트하는 프로세스입니다. 이는 개발 환경과 대상 환경 모두에서 테스트 팀에 의해 수행됩니다. 자세히 알아보기 시스템 테스트
95. 시스템 통합 테스트: 소프트웨어 시스템이 다른 시스템과 공존하는 테스트 프로세스입니다. 일반적으로 테스트 팀에서 수행합니다. 자세히 알아보기 시스템 통합 테스트
96. 하향식 통합 테스트: 사용자 인터페이스에서 시스템 계층 구조의 최상위에서 시작하고 스텁을 사용하여 전체 시스템이 구현될 때까지 위에서 아래로 테스트하는 테스트 기술입니다. 이는 테스트 팀에 의해 수행됩니다.
97. 스레드 테스트: 요구 사항의 하위 집합 구현에 따라 구성 요소를 점진적으로 통합하는 하향식 테스트 기술의 변형입니다. 일반적으로 테스트 팀에서 수행합니다. 자세히 알아보기 스레드 테스트
98. Upgrade 테스트 : 이전 버전으로 생성된 자산이 올바르게 사용될 수 있는지, 사용자의 학습에 어려움이 없는지 확인하는 테스트 기술입니다. 이는 테스트 팀에 의해 수행됩니다.
99. 단위 테스트: 프로그래머가 소스 코드의 개별 단위가 사용하기에 적합한지 테스트하는 소프트웨어 검증 및 검증 방법입니다. 일반적으로 개발팀에서 수행합니다. 자세히 알아보기 단위 테스트
100. 사용자 인터페이스 테스트: 애플리케이션이 얼마나 사용자 친화적인지 확인하기 위해 수행되는 테스트 유형입니다. 이는 테스트 팀에 의해 수행됩니다. 자세히 알아보기 사용자 인터페이스 테스트

추가 테스트 유형: 다음 다섯 가지 테스트 유형은 모든 QA 전문가가 알아두어야 할 추가적인 기법입니다.

101. 사용성 테스트 : 사용자가 시스템이나 구성 요소를 작동하고, 입력을 준비하고, 출력을 해석하는 방법을 배우는 용이성을 검증하는 테스트 기술입니다. 일반적으로 최종 사용자가 수행합니다. 자세히 보기 사용성 테스트
102. 볼륨 테스트: 시간이 지남에 따라 커질 수 있는 값(누적된 카운트, 로그, 데이터 파일 등)을 프로그램에서 수용할 수 있고 프로그램이 작동을 멈추거나 어떤 식으로든 작동을 저하시키지 않는지 확인하는 테스트입니다. 일반적으로 성능 엔지니어가 수행합니다. 자세히 알아보기 볼륨 테스트
103. 취약점 테스트: 애플리케이션 보안과 관련하여 애플리케이션 무결성 및 안정성에 영향을 미칠 수 있는 문제를 방지하기 위한 목적을 가진 테스트 유형입니다. 내부 테스트팀에서 수행할 수도 있고 전문업체에 아웃소싱할 수도 있습니다. 자세히 알아보기 취약점 테스트
104. 화이트 박스 테스트: 애플리케이션 코드의 내부 논리에 대한 지식을 기반으로 하는 테스트 기술이며 코드 문, 분기, 경로, 조건의 적용 범위와 같은 테스트가 포함됩니다. 소프트웨어 개발자가 수행합니다. 자세히 알아보기 화이트박스 테스팅
105. 작업 흐름 테스트: 최종 사용자가 활용할 것으로 예상되는 특정 작업 흐름을 복제하는 스크립트된 엔드투엔드 테스트 기술입니다. 일반적으로 테스트 팀에서 수행됩니다. 자세히 알아보기 작업 흐름 테스트

적합한 소프트웨어 테스트 유형을 선택하는 방법

100가지가 넘는 테스트 유형 중에서 프로젝트에 맞는 접근 방식을 선택하는 것은 어려울 수 있습니다. 핵심은 테스트 전략을 프로젝트 목표, 제약 조건 및 위험 허용 수준에 맞추는 것입니다.

프로젝트 요구사항부터 시작하세요

먼저 애플리케이션이 제공해야 하는 기능을 분석하십시오. 소프트웨어가 민감한 데이터를 처리하는 경우 보안 테스트 및 침투 테스트를 조기에 우선적으로 수행해야 합니다. 고객 대면 애플리케이션의 경우 사용성 테스트 및 접근성 테스트를 최우선 순위에 두어야 합니다. 복잡한 통합이 필요한 엔터프라이즈 시스템은 철저한 통합 테스트 및 시스템 통합 테스트가 필수적입니다.

개발 방법론을 고려하십시오.

개발 방식은 테스트 선택에 직접적인 영향을 미칩니다. 애자일 팀은 자동화 테스트, 회귀 테스트, 탐색적 테스트 등 스프린트 내에서 지속적인 테스트를 수행함으로써 이점을 얻습니다. 워터폴 프로젝트는 일반적으로 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 등 명확한 단계를 거치는 순차적인 접근 방식을 따릅니다.

위험 및 영향 평가

테스트는 오류 발생 시 가장 큰 피해를 초래할 수 있는 부분에 집중해야 합니다. 금융 애플리케이션은 광범위한 정확성 및 보안 검증이 필요하며, 의료 시스템은 엄격한 규정 준수 테스트가 필수적입니다. 전자상거래 플랫폼은 최대 트래픽을 처리할 수 있도록 강력한 성능 테스트와 부하 테스트가 요구됩니다.

수동 및 자동 접근 방식의 균형

모든 테스트 유형에 자동화가 필요한 것은 아닙니다. 탐색적 테스트, 사용성 테스트, 그리고 임시 테스트는 사람의 판단에 의존합니다. 반면 회귀 테스트, 부하 테스트, 그리고 스모크 테스트는 자동화를 통해 상당한 이점을 얻을 수 있습니다. 가장 효과적인 전략은 가용 자원을 고려하여 두 가지 접근 방식을 결합하는 것입니다.

인공지능이 소프트웨어 테스트를 어떻게 혁신하고 있는가

인공지능은 이전에는 상당한 수작업이 필요했던 작업을 자동화함으로써 소프트웨어 테스트 환경을 혁신하고 있습니다. AI 기반 테스트 도구는 이제 애플리케이션 동작, 사용자 패턴 및 코드 변경 사항을 분석하여 테스트 케이스를 자동으로 생성할 수 있으므로 포괄적인 테스트 스위트를 구축하는 데 필요한 시간을 획기적으로 단축할 수 있습니다.

가장 영향력 있는 응용 분야 중 하나는 지능형 결함 예측입니다. 머신 러닝 모델은 과거 버그 데이터와 코드 복잡성 지표를 분석하여 결함이 발생할 가능성이 가장 높은 모듈을 식별함으로써 팀이 문제가 발생할 가능성이 가장 높은 곳에 노력을 집중할 수 있도록 합니다.

자체 복구 테스트 스크립트는 또 다른 중요한 발전입니다. 기존의 자동화 테스트는 사용자 인터페이스가 변경될 때 자주 오류가 발생합니다. AI 기반 도구는 이러한 변경 사항을 감지하고 테스트 선택기와 어설션을 자동으로 업데이트하여 유지 관리 비용을 크게 줄입니다.

AI 기반 시각적 회귀 테스트는 빌드 간 스크린샷을 비교하여 의도적인 디자인 변경과 실제 시각적 결함을 지능적으로 구분합니다. AI 기술이 계속 발전함에 따라 QA 전문가들은 AI를 자신의 전문 지식을 대체하는 것이 아니라 보완하는 도구로 여겨야 합니다.

수동 테스트와 자동화 테스트의 주요 차이점

수동 테스트와 자동화 테스트를 언제 사용해야 하는지 이해하는 것은 프로젝트 일정, 예산 및 품질 결과에 영향을 미치는 매우 중요한 결정입니다. 다음 비교를 통해 이 두 가지 기본적인 접근 방식의 핵심적인 차이점을 살펴보겠습니다.

기준	수동 테스트	자동화 테스트
실행	인간 테스터가 단계별로 수행함	스크립트 및 테스트 도구에 의해 실행됨
속도	더 느리고, 인간의 속도에 제한을 받는다.	더 빠르고, 테스트를 병렬로 실행합니다.
초기 비용	사전 투자 비용 절감	도구 설정 및 스크립팅으로 인해 비용이 더 높습니다.
Repeatability	반복 작업 시 인적 오류 발생 가능성이 높음	실행 전반에 걸쳐 일관적이고 신뢰할 수 있음
가장 좋은	탐색적 테스트, 사용성 테스트, 임시 테스트	회귀 테스트, 부하 테스트, 연기 테스트
유연성	변화에 빠르게 적응합니다	변경 사항에 대한 스크립트 업데이트가 필요합니다.
장기 ROI	반복적인 작업은 시간이 지남에 따라 비용이 더 많이 듭니다.	자주 실행하는 테스트에 비용 효율적입니다.

가장 성공적인 QA 팀은 한 가지 접근 방식을 택하지 않습니다. 오히려 인간의 통찰력이 필요한 영역에는 수동 테스트를, 반복적이고 데이터 집약적이거나 시간 제약이 있는 검증에는 자동화 테스트를 활용하는 균형 잡힌 테스트 전략을 구축합니다.

이것으로 목록이 끝났습니다. 이러한 유형의 테스트 및 기타 테스트에 적합한 도구를 찾으려면 이 모음을 살펴보세요. 테스트 도구.

자주 묻는 질문