알고리즘 테스팅

분야	[[소프트웨어 공학]], [[컴퓨터 과학]]
관련 개념	[[소프트웨어 테스팅]], [[정형 검증]], [[코드 리뷰]]
최초 체계화 시기	1960년대~1970년대
주요 인물	[[에츠허르 다이크스트라]], [[토니 호어]], [[로버트 플로이드]]
주요 기법	단위 테스트, 퍼즈 테스팅, 형식 검증, 속성 기반 테스팅
적용 산업	금융, 의료, 항공우주, 자율주행, 인공지능
관련 도구	JUnit, pytest, QuickCheck, AFL, Coq
국제 표준	[[ISO/IEC 25010]], [[ISO/IEC 29119]]

'''알고리즘 테스팅'''(Algorithm Testing)은 [[알고리즘]]이 주어진 명세에 따라 올바르게 동작하는지, 요구되는 [[성능]] 기준을 충족하는지, 그리고 다양한 입력 조건에서 예측 가능한 결과를 산출하는지를 체계적으로 검증하는 과정이다. [[소프트웨어 공학]]과 [[컴퓨터 과학]]의 핵심 활동 중 하나로, 알고리즘의 '''정확성'''(correctness), '''효율성'''(efficiency), '''견고성'''(robustness), '''안정성'''(stability)을 보장하기 위해 수행된다. 알고리즘 테스팅은 단순한 [[버그]] 탐지를 넘어, 알고리즘이 모든 가능한 입력 공간에서 기대한 대로 작동하는지를 확인하는 광범위한 활동을 포괄한다. 현대 사회에서 알고리즘이 [[금융]], [[의료]], [[자율주행]], [[인공지능]] 등 안전과 생명에 직결되는 분야에 광범위하게 적용됨에 따라, 알고리즘 테스팅의 중요성은 지속적으로 증가하고 있다. == 개요 == 알고리즘 테스팅은 특정 [[알고리즘]]이 설계 의도대로 기능하는지를 확인하기 위해 다양한 입력 데이터를 제공하고 그 출력을 분석하는 과정이다. 이 과정은 알고리즘의 논리적 오류, 경계 조건에서의 실패, 예외적 상황에서의 비정상적 동작, 그리고 성능 저하 등을 식별하는 것을 목표로 한다. 알고리즘 테스팅의 범위는 크게 다음과 같은 영역으로 나뉜다. '''기능적 정확성 검증''': 알고리즘이 명세에 정의된 입력-출력 관계를 정확하게 구현하는지 확인한다. '''성능 검증''': [[시간 복잡도]]와 [[공간 복잡도]]가 이론적 분석과 일치하는지, 실제 실행 환경에서 허용 가능한 수준의 성능을 제공하는지 평가한다. '''견고성 검증''': 비정상적 입력, 극단적 경계값, 대규모 데이터셋 등 예외적 조건에서도 알고리즘이 안정적으로 동작하는지 확인한다. '''보안 검증''': 알고리즘이 악의적 입력에 의해 취약점을 노출하지 않는지 점검한다. [[에츠허르 다이크스트라]]는 "프로그램 테스팅은 버그의 존재를 보여줄 수 있지만, 버그의 부재를 보여줄 수는 없다"라는 유명한 경구를 남겼다. 이 말은 테스팅의 본질적 한계를 지적하면서도, 동시에 테스팅이 소프트웨어 품질 보증에서 불가결한 역할을 수행한다는 사실을 역설적으로 강조한다. == 역사 == === 초기 컴퓨팅 시대 (1940년대~1960년대) === 알고리즘 테스팅의 역사는 [[전자 컴퓨터]]의 등장과 함께 시작되었다. 1940년대 [[ENIAC]]과 같은 초기 컴퓨터에서는 프로그래밍이 하드웨어 배선 수준에서 이루어졌으며, 테스팅은 주로 수작업으로 계산 결과를 검증하는 형태였다. [[앨런 튜링]]은 1949년에 이미 프로그램의 정확성을 수학적으로 증명하는 방법에 대해 논의하였으며, 이는 [[정형 검증]]의 초기 개념으로 볼 수 있다. 1950년대와 1960년대에 [[포트란]]과 [[코볼]] 같은 고급 프로그래밍 언어가 등장하면서 소프트웨어의 복잡도가 급격히 증가하였고, 이에 따라 체계적인 테스팅 방법론의 필요성이 대두되었다. 이 시기의 테스팅은 대부분 '''디버깅'''(debugging)과 동의어로 사용되었으며, 오류를 발견하고 수정하는 사후적 활동에 가까웠다. === 구조적 테스팅의 발전 (1970년대~1980년대) === 1970년대는 알고리즘 테스팅이 독립적인 학문 분야로 자리 잡기 시작한 시기이다. [[로버트 플로이드]]는 1967년 발표한 논문에서 프로그램의 정확성을 [[순서도]]의 의미론을 통해 증명하는 방법을 제시하였고, [[토니 호어]]는 1969년 '''호어 논리'''(Hoare Logic)를 발표하여 프로그램의 부분적 정확성을 공리적으로 증명하는 체계를 확립하였다. 1976년 토마스 맥케이브(Thomas McCabe)는 '''[[순환 복잡도]]'''(Cyclomatic Complexity) 개념을 도입하여 프로그램의 논리적 복잡도를 정량적으로 측정하고, 이를 테스트 케이스 설계에 활용하는 방법을 제안하였다. 이 시기에 '''구조적 테스팅'''(Structural Testing), 즉 [[화이트박스 테스팅]]의 기본 개념이 확립되었으며, [[코드 커버리지]] 기준(문장 커버리지, 분기 커버리지, 경로 커버리지 등)이 체계화되었다. 1979년 글렌포드 마이어스(Glenford Myers)는 저서 ''The Art of Software Testing''에서 테스팅을 "오류를 발견하려는 의도로 프로그램을 실행하는 과정"으로 정의하며, 테스팅에 대한 근본적인 패러다임 전환을 이끌었다. === 객체지향과 자동화의 시대 (1990년대~2000년대) === 1990년대에 [[객체지향 프로그래밍]]이 주류가 되면서 테스팅 방법론도 이에 맞게 진화하였다. 1997년 [[켄트 벡]]이 [[Smalltalk]]용 테스팅 프레임워크인 SUnit을 개발하였고, 이를 바탕으로 2000년에 [[JUnit]]이 탄생하면서 '''[[단위 테스트]]''' 프레임워크의 시대가 열렸다. JUnit의 등장은 [[xUnit]] 패밀리의 확산으로 이어져, 거의 모든 프로그래밍 언어에 전용 테스팅 프레임워크가 등장하는 계기가 되었다. 2000년대에는 [[애자일 소프트웨어 개발]] 방법론의 부상과 함께 '''[[테스트 주도 개발]]'''(TDD, Test-Driven Development)이 광범위하게 채택되었다. 켄트 벡이 2002년 출간한 ''Test-Driven Development: By Example''은 TDD의 실천적 지침서로 자리 잡았으며, "테스트를 먼저 작성하고, 그 테스트를 통과하는 최소한의 코드를 작성한 뒤, 리팩토링한다"는 레드-그린-리팩토링 사이클을 대중화하였다. 같은 시기에 [[존 휴즈]]와 크랜 클라센은 [[Haskell]] 기반의 '''[[QuickCheck]]'''을 개발하여 '''속성 기반 테스팅'''(Property-Based Testing)의 개념을 정립하였다. 속성 기반 테스팅은 구체적인 테스트 케이스 대신 알고리즘이 만족해야 할 일반적 속성을 정의하고, 도구가 자동으로 수많은 무작위 입력을 생성하여 해당 속성의 위반 여부를 검사하는 방식이다. === 현대적 발전 (2010년대~현재) === 2010년대 이후 알고리즘 테스팅은 [[인공지능]], [[머신러닝]], [[분산 시스템]], [[클라우드 컴퓨팅]] 등 새로운 패러다임의 등장에 따라 급격한 변화를 겪고 있다. '''[[퍼즈 테스팅]]'''(Fuzz Testing)은 구글의 '''[[AFL]]'''(American Fuzzy Lop)과 '''[[libFuzzer]]''' 등의 도구를 통해 대중화되었으며, 보안 취약점 탐지에서 핵심적인 역할을 담당하고 있다. 구글은 2016년 '''[[OSS-Fuzz]]''' 프로젝트를 출범시켜 오픈소스 소프트웨어의 지속적 퍼즈 테스팅 인프라를 제공하기 시작하였다. [[머신러닝]] 알고리즘의 테스팅은 전통적인 결정론적 알고리즘 테스팅과는 근본적으로 다른 도전 과제를 제시한다. 기대 출력이 명확하게 정의되지 않는 경우가 많고, 학습 데이터에 대한 의존성, 비결정론적 행동, [편향] 문제 등이 새로운 테스팅 패러다임을 요구하고 있다. == 주요 테스팅 기법 == === 블랙박스 테스팅 === '''[[블랙박스 테스팅]]'''은 알고리즘의 내부 구현을 고려하지 않고, 오직 입력과 출력의 관계만을 기반으로 테스트를 수행하는 기법이다. 테스터는 알고리즘의 명세(specification)에 기술된 기능 요구사항에 따라 테스트 케이스를 설계한다. 주요 블랙박스 기법으로는 다음과 같은 것들이 있다. '''동치 분할'''(Equivalence Partitioning): 입력 도메인을 동등한 결과를 산출하는 클래스로 분할하고, 각 클래스에서 대표 값을 선택하여 테스트한다. '''경계값 분석'''(Boundary Value Analysis): 동치 클래스의 경계에 위치한 값들을 집중적으로 테스트한다. 경험적으로 오류는 경계 근처에서 가장 빈번하게 발생한다. '''결정 테이블 테스팅''': 복수의 조건과 그에 따른 동작을 결정 테이블로 정리하고, 모든 조건 조합을 테스트한다. '''상태 전이 테스팅''': 알고리즘이 내부 상태를 유지하는 경우, 가능한 상태 전이 경로를 식별하고 테스트한다. === 화이트박스 테스팅 === '''[[화이트박스 테스팅]]'''은 알고리즘의 내부 구조와 논리를 분석하여 테스트 케이스를 설계하는 기법이다. 소스 코드에 대한 접근이 전제되며, [[코드 커버리지]]를 극대화하는 것을 목표로 한다. 주요 커버리지 기준은 다음과 같다. '''문장 커버리지'''(Statement Coverage): 모든 실행 가능한 문장이 최소 한 번 이상 실행되었는지 확인한다. '''분기 커버리지'''(Branch Coverage): 모든 조건문의 참/거짓 분기가 최소 한 번 이상 실행되었는지 확인한다. '''경로 커버리지'''(Path Coverage): 가능한 모든 실행 경로가 테스트되었는지 확인한다. 이론적으로 가장 강력하지만, 루프가 포함된 경우 경로 수가 무한히 증가할 수 있어 실용성에 한계가 있다. '''조건/결정 커버리지'''(MC/DC, Modified Condition/Decision Coverage): 항공우주 분야의 [[DO-178C]] 표준에서 레벨 A 소프트웨어에 요구되는 엄격한 커버리지 기준으로, 각 조건이 결정의 결과에 독립적으로 영향을 미치는지를 검증한다. === 퍼즈 테스팅 === '''[[퍼즈 테스팅]]'''(Fuzz Testing 또는 Fuzzing)은 무작위 또는 반무작위적으로 생성된 입력 데이터를 알고리즘에 대량으로 주입하여 예상치 못한 오류, [[메모리 누수]], [[버퍼 오버플로]], [[크래시]] 등을 탐지하는 기법이다. 1988년 [[위스콘신 대학교]]의 바턴 밀러(Barton Miller) 교수가 유닉스 유틸리티에 무작위 입력을 제공하는 실험을 통해 처음으로 체계화하였다. 현대의 퍼즈 테스팅은 크게 세 가지 유형으로 분류된다. '''생성 기반 퍼징'''(Generation-based Fuzzing): 입력 형식의 문법이나 프로토콜 명세를 기반으로 유효하거나 반유효한 입력을 생성한다. '''변이 기반 퍼징'''(Mutation-based Fuzzing): 기존의 유효한 입력 데이터를 무작위로 변형하여 새로운 테스트 입력을 생성한다. '''커버리지 가이드 퍼징'''(Coverage-guided Fuzzing): 코드 커버리지 정보를 피드백으로 활용하여 새로운 코드 경로를 탐색하는 방향으로 입력을 진화시킨다. [[AFL]]과 [[libFuzzer]]가 이 범주의 대표적 도구이다. === 속성 기반 테스팅 === '''속성 기반 테스팅'''(Property-Based Testing)은 알고리즘이 만족해야 하는 일반적인 속성(property)을 정의하고, 테스팅 프레임워크가 자동으로 대량의 무작위 입력을 생성하여 해당 속성의 위반 여부를 검사하는 기법이다. 예를 들어, 정렬 알고리즘의 경우 "출력 배열의 길이는 입력 배열의 길이와 같아야 한다", "출력 배열의 각 원소는 이전 원소보다 크거나 같아야 한다", "출력 배열은 입력 배열의 순열이어야 한다" 등의 속성을 정의할 수 있다. 속성 기반 테스팅의 핵심 강점은 '''수축'''(shrinking) 기능에 있다. 속성 위반이 발견되면, 도구는 자동으로 해당 위반을 재현할 수 있는 최소한의 입력을 찾아 디버깅을 용이하게 한다. [QuickCheck], [Hypothesis], [fast-check] 등이 대표적인 속성 기반 테스팅 라이브러리이다. === 정형 검증 === '''[[정형 검증]]'''(Formal Verification)은 [[수학]]적 방법을 사용하여 알고리즘의 정확성을 증명하는 기법이다. 테스팅이 유한한 수의 입력에 대해서만 동작을 확인하는 반면, 정형 검증은 모든 가능한 입력에 대한 정확성을 보장할 수 있다. 주요 정형 검증 기법으로는 다음과 같은 것들이 있다. '''모델 검사'''(Model Checking): 시스템의 유한 상태 모델을 자동으로 탐색하여 특정 속성의 만족 여부를 확인한다. [[SPIN]], [[NuSMV]] 등이 대표적 도구이다. '''정리 증명'''(Theorem Proving): [[Coq]], [[Isabelle]], [[Lean]] 등의 증명 보조 도구를 사용하여 알고리즘의 정확성을 수학적으로 증명한다. '''추상 해석'''(Abstract Interpretation): 프로그램의 의미론을 수학적으로 추상화하여 정적으로 속성을 분석한다. 정형 검증은 가장 강력한 정확성 보장 수단이지만, 높은 전문성과 상당한 시간·비용이 요구되므로 주로 [[항공우주]], [[의료 기기]], [[원자력]] 등 안전 필수(safety-critical) 시스템에서 사용된다. == 성능 테스팅 == 알고리즘의 성능 테스팅은 이론적 [[복잡도 분석]]의 실증적 검증과 실제 실행 환경에서의 성능 측정을 포괄한다. === 시간 복잡도 검증 === 알고리즘의 [[시간 복잡도]]가 이론적 분석과 일치하는지를 검증하기 위해, 다양한 크기의 입력에 대해 실행 시간을 측정하고 그 성장률을 분석한다. 예를 들어 O(n log n)으로 분석된 정렬 알고리즘이 실제로 입력 크기에 비례하여 n log n에 가까운 성장률을 보이는지 확인한다. 이 과정에서 최선, 평균, 최악의 경우를 모두 고려하여 입력 데이터를 구성해야 한다. === 공간 복잡도 검증 === 알고리즘의 [[메모리]] 사용량이 이론적 [[공간 복잡도]]와 일치하는지를 검증한다. 특히 [[재귀]] 알고리즘의 경우 [[콜 스택]] 깊이에 따른 메모리 사용량 증가가 [[스택 오버플로]]를 유발하지 않는지 확인하는 것이 중요하다. === 벤치마킹 === '''[[벤치마킹]]'''은 동일한 문제를 해결하는 복수의 알고리즘을 동일한 조건에서 실행하여 성능을 비교하는 과정이다. 정확한 벤치마킹을 위해서는 [[JMH]](Java Microbenchmark Harness), [Google Benchmark], [criterion] 등의 전문 벤치마킹 도구를 사용하여 [[JIT 컴파일]], [[가비지 컬렉션]], [[캐시]] 효과 등 환경적 변수를 통제해야 한다. == 머신러닝 알고리즘 테스팅 == [[머신러닝]] 알고리즘의 테스팅은 전통적인 결정론적 알고리즘 테스팅과는 질적으로 다른 접근이 필요하다. 기대 출력이 사전에 완전하게 정의되지 않으며, 모델의 행동이 학습 데이터에 크게 의존하기 때문이다. === 데이터 품질 테스팅 === 학습 데이터의 품질은 머신러닝 알고리즘의 성능에 직접적인 영향을 미친다. 데이터의 완전성, 일관성, 대표성, 균형성 등을 체계적으로 검증해야 하며, [[데이터 드리프트]](Data Drift)나 [[개념 드리프트]](Concept Drift) 현상에 대한 모니터링도 필수적이다. === 공정성 및 편향 테스팅 === 머신러닝 알고리즘이 특정 인구통계학적 집단에 대해 불공정한 결과를 산출하지 않는지를 검증하는 공정성 테스팅이 중요한 영역으로 부상하였다. [[통계적 패리티]](Statistical Parity), [[동등 기회]](Equal Opportunity), [[예측 패리티]](Predictive Parity) 등 다양한 공정성 지표가 제안되었으며, [[IBM]]의 '''AI Fairness 360''', [[구글]]의 '''What-If Tool''' 등의 도구가 개발되었다. === 적대적 테스팅 === '''[[적대적 예제]]'''(Adversarial Examples)를 활용한 테스팅은 머신러닝 모델의 견고성을 평가하는 중요한 방법이다. 인간에게는 감지되지 않는 미세한 입력 변형이 모델의 예측을 크게 바꿀 수 있다는 사실이 밝혀진 이후, 적대적 테스팅은 특히 [[자율주행]], [[의료 영상 분석]] 등 안전 필수 응용 분야에서 필수적인 과정으로 자리 잡았다. == 자동화와 도구 == === 테스트 자동화 프레임워크 === 현대 알고리즘 테스팅은 자동화에 크게 의존한다. 주요 테스팅 프레임워크는 다음과 같다. '''[[JUnit]]''' / '''[[TestNG]]''': [[자바]] 생태계의 표준 단위 테스트 프레임워크 '''[[pytest]]''': [[파이썬]]의 가장 널리 사용되는 테스팅 프레임워크 '''[[Jest]]''': [[자바스크립트]] 및 [[타입스크립트]] 환경의 표준 테스팅 프레임워크 '''[[Google Test]]''': [[C++]]용 테스팅 프레임워크 '''[[Catch2]]''': 현대적 C++ 테스팅 프레임워크 === 지속적 통합과 테스팅 === '''[[지속적 통합]]'''(CI, Continuous Integration)은 코드 변경이 발생할 때마다 자동으로 테스트 스위트를 실행하여 회귀 오류를 조기에 탐지하는 실천 방법이다. [[Jenkins]], [[GitHub Actions]], [[GitLab CI]], [[CircleCI]] 등의 CI 도구가 알고리즘 테스팅의 자동화된 실행을 지원한다. === AI 기반 테스트 생성 === 최근에는 [대규모 언어 모델]을 활용한 자동 테스트 케이스 생성이 주목받고 있다. [[GitHub Copilot]], [코드위스퍼러] 등의 AI 코딩 도구가 테스트 코드의 자동 생성을 지원하며, 전문화된 도구들이 코드 변경에 따른 테스트 케이스의 자동 업데이트 기능을 제공하고 있다. 다만, AI 생성 테스트의 품질과 신뢰성에 대해서는 지속적인 연구와 검증이 필요하다. == 영향 및 의의 == 알고리즘 테스팅은 소프트웨어 산업 전반에 걸쳐 심대한 영향을 미치고 있다. '''경제적 영향'''으로는, 미국 [국립표준기술연구소]의 2002년 보고서에 따르면 소프트웨어 버그로 인한 미국 경제의 연간 손실이 약 595억 달러에 달하며, 개선된 테스팅 인프라를 통해 이 중 약 3분의 1을 절감할 수 있을 것으로 추산되었다. 소프트웨어 개발 생명주기에서 결함이 늦게 발견될수록 수정 비용이 기하급수적으로 증가한다는 '''결함 비용 증폭 법칙'''은 조기 테스팅의 경제적 가치를 뒷받침한다. '''안전성 측면'''에서, [[아리안 5호]] 로켓의 1996년 폭발 사고(64비트 부동소수점 값의 16비트 정수 변환 오버플로), [[테랙-25]] 방사선 치료기의 과다 조사 사고(1985~1987년), [[보잉 737 MAX]] 사고 등은 불충분한 알고리즘 테스팅이 초래할 수 있는 치명적 결과를 보여주는 사례이다. '''산업 표준화'''에서, 알고리즘 테스팅의 중요성이 인식됨에 따라 [[ISO/IEC 25010]](소프트웨어 품질 모델), [[ISO/IEC 29119]](소프트웨어 테스팅 표준), [[DO-178C]](항공 소프트웨어), [[IEC 62304]](의료 기기 소프트웨어) 등 분야별 테스팅 표준이 수립되었다. == 논란 및 비평 == === 테스팅의 본질적 한계 === 알고리즘 테스팅에 대한 가장 근본적인 비평은 다이크스트라가 지적한 대로 테스팅이 결함의 부재를 증명할 수 없다는 점이다. 유한한 수의 테스트 케이스로는 무한한 입력 공간을 완전히 탐색하는 것이 불가능하며, 이는 테스팅의 본질적 한계로 남아 있다. 이에 대한 대안으로 [[정형 검증]]이 제시되지만, 실용성과 비용 측면에서의 제약이 있다. === TDD 논쟁 === [테스트 주도 개발]의 효과에 대해서는 학계와 산업계에서 지속적인 논쟁이 있다. 지지자들은 TDD가 코드 품질을 향상시키고 설계를 개선한다고 주장하는 반면, 비판자들은 TDD가 개발 속도를 저하시키며 과도한 테스트 유지보수 부담을 초래한다고 반박한다. 2014년의 대규모 메타 분석 등 실증적 연구들은 TDD의 효과에 대해 혼재된 결과를 보여주고 있다. === 코드 커버리지의 한계 === [[코드 커버리지]]를 테스트 품질의 주요 지표로 사용하는 관행에 대해서도 비판이 존재한다. 높은 코드 커버리지가 반드시 높은 결함 탐지율을 보장하지는 않으며, 커버리지 목표를 달성하기 위해 의미 없는 테스트가 작성되는 부작용이 발생할 수 있다. 마틴 파울러(Martin Fowler)는 커버리지를 "충분한 테스팅이 이루어지지 않은 코드를 식별하는 유용한 도구"로는 인정하되, "테스트 스위트의 품질을 측정하는 지표"로 사용해서는 안 된다고 지적하였다. === AI 알고리즘 테스팅의 도전 === [[인공지능]]과 [[머신러닝]] 알고리즘의 테스팅은 전통적인 테스팅 패러다임에 근본적인 도전을 제기한다. '''오라클 문제'''(Oracle Problem), 즉 올바른 출력이 무엇인지를 사전에 결정하기 어려운 문제가 핵심적인 난제이다. 또한, [[딥러닝]] 모델의 '''해석 불가능성'''(Interpretability Problem)은 오류의 원인을 진단하고 수정하는 과정을 어렵게 만든다. 이러한 도전은 [설명 가능한 인공지능]과 새로운 테스팅 방법론 연구의 동력이 되고 있다. === ISO 29119 논란 === 2014년에 발표된 [[ISO/IEC 29119]] 표준에 대해 [[Context-Driven Testing]] 커뮤니티를 중심으로 강한 반발이 있었다. 비판론자들은 소프트웨어 테스팅이 맥락에 크게 의존하는 활동이므로 단일 표준으로 규격화하는 것이 부적절하며, 해당 표준이 실제 테스팅 실무의 다양성을 반영하지 못한다고 주장하였다. 제임스 바흐(James Bach)와 마이클 볼턴(Michael Bolton) 등이 이 비판을 주도하였다. == 미래 전망 == 알고리즘 테스팅의 미래는 여러 방향으로 발전이 예상된다. '''AI 기반 자율 테스팅'''의 발전으로 테스트 케이스 생성, 결함 탐지, 테스트 유지보수가 점차 자동화될 것으로 전망된다. '''양자 컴퓨팅'''의 발전은 [[양자 알고리즘]]의 테스팅이라는 새로운 영역을 개척할 것이며, 기존의 테스팅 방법론으로는 다루기 어려운 [[양자 중첩]], [[양자 얽힘]] 등의 현상에 대한 새로운 검증 기법이 필요하게 될 것이다. 또한 [[유럽연합]]의 '''[[인공지능법]]'''(AI Act) 등 AI 규제 법안의 시행에 따라 알고리즘의 투명성, 공정성, 안전성에 대한 법적 테스팅 요구사항이 강화될 전망이다. == 관련 문서 == [[소프트웨어 테스팅]] [[단위 테스트]] [[테스트 주도 개발]] [[정형 검증]] [[퍼즈 테스팅]] [[코드 커버리지]] [[소프트웨어 품질 보증]] [[지속적 통합]] [[화이트박스 테스팅]] [[블랙박스 테스팅]] [[회귀 테스트]] [[속성 기반 테스팅]] [[머신러닝]] [[알고리즘]] [[복잡도 분석]] == 외부 링크 == [https://www.iso.org/standard/81291.html ISO/IEC 25010:2023 소프트웨어 품질 모델] [https://www.istqb.org/ ISTQB 국제 소프트웨어 테스팅 자격 위원회] [https://google.github.io/oss-fuzz/ Google OSS-Fuzz 프로젝트] [https://hypothesis.readthedocs.io/ Hypothesis - Python 속성 기반 테스팅 라이브러리] [https://junit.org/ JUnit 공식 사이트] [https://llvm.org/docs/LibFuzzer.html LLVM libFuzzer 문서] [[분류:소프트웨어 공학]] [[분류:소프트웨어 테스팅]] [[분류:컴퓨터 과학]] [[분류:알고리즘]] [[분류:품질 보증]]