테스트

테스트(test)란 시스템의 성능을 시험하는 것을 말한다. 단위 테스트, 통합 테스트, 사용자 인수 테스트가 있다. 단위 테스트는 개별 시스템의 기능을 테스트하는 것이고, 통합 테스트는 전체 시스템의 상호 작용을 테스트하는 것이고, 사용자 인수 테스트(UAT)는 수요기관 담당자가 개발 결과물을 인수하기 전에 최종 테스트하는 것을 말한다.

개요

테스트란 안정적인 서비스를 위한 안정성 확보, 문제점 및 개선점을 파악한 후 해당사항을 수정하여 성능을 향상, 장애로 인한 데이터 손실, 신뢰도 저하, 추가비용 발생을 미연에 방지, 서버의 최적화를 위해 서버환경 검사를 목표로 한다.

시스템 테스트란 완벽하게 통합된 소프트웨어 제품을 테스트하는 것이다. 일반적으로 소프트웨어는 더 큰 컴퓨터 기반 시스템의 한 요소일 뿐이다. 궁극적으로 소프트웨어는 다른 소프트웨어/하드웨어 시스템과 인터페이스 된다. 시스템 테스트는 컴퓨터의 전체 시스템을 사용하는 유일한 목적의 테스트이다.

소프트웨어 테스트(software test)는 주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 소프트웨어 테스트는 또한 소프트웨어에 대한 객관적이고 독립적인 시각을 제공하여 사업 주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 한다. 시험 기술에는 프로그램이나 응용 프로그램을 실행하여 소프트웨어 버그를 찾는 절차를 포함되나 이에 국한되지는 않는다.

특징

테스트 범주

• 화이트박스 테스트

화이트박스 테스팅(White-box testing)는 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식으로, 블랙박스 검사와는 반대된다. 화이트박스 테스트(White Box Test) 기법은 소프트웨어 내부 소스 코드를 테스트하는 기법이다. 화이트박스 테스트를 하는 이유는 내부 소스코드의 동작을 개발자가 추적 할 수 있기 때문에, 동작의 유효성 뿐만아니라 실행 되는 과정을 살펴봄으로써, 코드가 어떤경로로 실행되며, 불필요한 코드 혹은 테스트 되지 못한 부분을 살펴볼 수 있다. 화이트박스 테스트을 하는 부분은 대개 코드의 실행 경로를 확인해야 하기때문에 시중에 나와 있는 커버리지 분석도구를 많이 활용한다. 화이트박스 검사 기법은 블랙박스 검사 기법에 비해 많은 과 같은 무료도구가 있는 반면에 크리티컬한 마켓에 사용되는 상용 도구 또한 있다.

문장 검증

프로그램의 모든 문장이 적어도 한 번씩 수행되는 검증 기준

선택 검증

선택하는 부분만 검증

경로 검증

수행 가능한 모든 경로 검사

조건 검증

IF 문장이나 While 문장 내 조건식을 조사하는 기준

• 블랙박스 테스트

블랙박스 검사(Black-box testing)는 소프트웨어 검사 방법 중 하나로 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법을 이르는 말이다. 주로 올바른 입력과 올바르지 않은 입력을 일일이 다 동원하여 올바른 출력을 판별하는 방식으로 검사가 이루어지기 때문에 검사의 진행에 있어 대상이 되는 소프트웨어의 코드나 내부 구조 및 개발 노하우에 대한 정보는 기본적으로 필요로 하지 않는다. 필요한 것은 특징, 요구 사항, 검사를 위해 공개된 설계도 등 대외적으로 공개된 사항들이며 '이 소프트웨어는 무슨 역할을 수행해야 되는가'와 같이 대상이 되는 소프트웨어의 특징이나 요구 사항 등에 초점을 맞춰 검사가 이루어진다. 검사 자체는 기능에 관한 것일 수도 있고 기능 외의 것에 관한 것일 수도 있다. 이 방법은 유닛 검사, 인테그레이션 검사, 기능 검사, 시스템 검사, 적합성 검사 이렇게 소프트웨어 검사의 모든 레벨에 적용 가능하다.

동등 분할 기법(Equivalence Partitioning)

프로그램의 입력 도메인을 테스트 케이스가 산출될 수 있는 데이터 클래스로 분류하는 방법이다.

경계값 분석 기법 (Boundary Value Analysis)

입력 조건의 중간 값보다 경계 값에서 에러가 발생 될 확률이 높다는 점을 이용하여 테스트 케이스를 생성한다.

오류 예측 기법(Error Guessing)

각 시험 기법들이 놓치기 쉬운 오류들을 감각 및 경험으로 찾아보는 방법이다.

원인 결과 그래프 기법 (Cause Effect Graph)

입력 데이터 간 관계가 출력에 미치는 영향을 그래프로 표현하여 오류를 발견하도록 한다.

의사결정 테이블 테스팅

논리적 조건이나 상황에서 입력 조건과 결과를 참, 거짓으로 표현하여 조합을 만들고 테스트케이스를 작성한다.

상태전이 테스팅

시스템에 반영되는 이전의 상태가 무엇인지, 상태간 전이, 상태를 변화시키는 이벤트와 입력값을 파악한다.

블랙박스 테스트와 화이트 박스 테스트 비교

구분	블랙박스 테스트	화이트 박스 테스트
정의	모듈사양서를 기초로 입력/출력 조건 등 모든 기능면의 테스트	모듈사양서 소스코드를 기초로 모듈의 논리 테스트
관점	사용자 관점	개발자 관점
기준	인터페이스 및 성능 오류	논리상 오류
V&V	상위 레벨 (사용자 환경)	하위 레벨 (시험 환경)
대상	시작/종료/인터페이스 결함	루프, Decision 결함, 비수행 구문
기법	동등 분할, 경계값분석 등	루프, 제어구조 테스트
활용	베타 테스트	알파 테스트

테스트 개발단계

테스트의 종류에는 단위 테스트, 통합 테스트, 사용자 인수 테스트가 있다. 거의 모든 기술 프로세스와 마찬가지로 소프트웨어 테스팅은 일을 해야 하는 미리 정해진 순서를 가지고 있다. 다음 마케팅을 준비하기 위해 새로운 소프트웨어를 완전히 테스트하는 단계이다.

• 단위 테스트

단위 테스트(unit test)는 프로그램의 기본 단위인 모듈을 테스트하여 모듈 테스트(module test)라고도 한다. 구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 명세서의 내용대로 정확히 구현되었는지를 테스트한다. 즉 개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트한다. 화이트박스 테스트와 블랙박스 테스트를 모두 사용할 수 있지만, 모듈 내부의 구조를 구체적으로 들여다볼 수 있는 화이트박스 테스트 같은 구조적 테스트를 주로 시행한다.

단위 테스트(unit test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다. 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로, 각 테스트 케이스는 서로 분리되어야 한다. 이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다. 유닛 테스트는 (일반적인 테스트와 달리) 개발자뿐만 아니라 보다 더 심도있는 테스트를 위해 테스터에 의해 수행되기도 한다.

• 통합 테스트

단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트가 통합 테스트(integration test)이다. 실제 업무에서는 단위 모듈이 개별적으로 존재하는 것이 아니고 여러 모듈이 유기적 관계를 맺고 있으므로 이러한 모듈들을 결합한 형태로 테스트를 수행해봐야 한다. 이때 주로 확인하는 것은 '모듈 간의 상호작용이 정상적으로 수행되는가'이다. 즉 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지를 체크한다.

개별 모듈을 테스트하는 단위 테스트에서는 오류가 발견되지 않았어도, 모듈을 통합하면 상호 간의 인자나 공유 데이터 구조 등에서 오류가 발생할 수 있다. 또 단위 테스트 시 가상의 드라이버와 스텁 모듈을 만들어 테스트를 잘 수행했더라도, 상당히 제한적인 여건에서 테스트를 수행한 것이다. 그러므로 실제 모듈 통합 시에는 다른 결과가 나올 수도 있다. 실제 개발에서는 모듈 간의 상호작용과 인터페이스에서 많은 오류가 발생하는 것을 볼 수 있다. 그러므로 통합 테스트가 필요한데, 그 방법에는 모듈 통합을 한꺼번에 하는 방법과 점진적으로 하는 방법이 있다.

하향식 기법

하향식(top-down) 기법은 시스템을 구성하는 모듈의 계층 구조에서 맨 상위의 모듈부터 시작하여 점차 하위 모듈 방향으로 통합하는 방법이다. 일반적으로 모듈의 종속 관계에서 상위 모듈은 시스템 전체의 흐름을 관장하고, 하위 모듈은 각 기능을 구현하는 형태로 구성되어 있다. 그러므로 하향식 기법을 이용하면 프로그램 전체에 영향을 줄 수 있는 오류를 일찍 발견하기가 쉽다. 그러나 하위 모듈이 임시로 만든 스텁들로 대체되어 결과가 완전하지 않을 수도 있고 스텁 수가 많으면 스텁을 만드는 데 시간과 노력이 많이 들 수 있다. 따라서 모듈 간의 인터페이스와 시스템의 동작이 정상적으로 잘되고 있는지를 빨리 파악하고자 할 때 하향식 기법을 사용하는 것이 좋다.

상향식 기법

상향식(bottom-up) 기법은 하향식 기법과는 반대로 가장 말단에 있는 최하위 모듈부터 테스트를 시작한다. 하향식에서 스텁이 필요했다면, 상향식에서는 상위 모듈의 역할을 하는 테스트 드라이버가 필요하다. 이 드라이버는 하위 모듈을 순서에 맞게 호출하고, 호출할 때 필요한 매개 변수를 제공하며, 반환 값을 전달하는 역할을 한다. 상향식 기법의 장점은 최하위 모듈들을 개별적으로 병행하여 테스트할 수 있기 때문에 하위에 있는 모듈들을 충분히 테스트할 수 있다는 것이다. 또한 정밀한 계산이나 데이터 처리가 요구되는 시스템 같은 경우에 사용하면 좋다. 그러나 상위 모듈에 오류가 발견되면 그 모듈과 관련된 하위의 모듈을 다시 테스트해야 하는 번거로움이 생길 수 있다.

• 시스템 테스트

개별 모듈의 단위 테스트가 끝나고 모듈 간의 인터페이스에는 문제가 없는지를 테스트하는 통합 테스트까지 끝나면, 시스템 전체가 정상적으로 작동하는지를 체크하는 시스템 테스트(system test)를 해야 한다. 시스템 테스트는 모듈이 모두 통합된 후 사용자의 요구 사항들을 만족하는지 테스트하는 것이다. 즉 사용자에게 개발된 시스템을 전달하기 전에 개발자가 진행하는 마지막 테스트라 할 수 있다. 앞에서 설명한 V&V에서 확인(verification)에 해당한다. 시스템 테스트는 실제 사용 환경과 유사하게 테스트 환경을 만들어놓고 요구 분석 명세서에 명시한 기능적 요구사항과 비기능적 요구 사항을 충족하는지 테스트한다. 주로 부하를 주는 상황에서 수행하고, 비기능적 테스트를 중심으로 수행한다. 기능적 요구 사항 테스트는 사용자가 요구하는 기능이 다 있는지, 필요 없는 기능이 포함되지는 않았는지 등을 테스트한다. 비기능적 요구 사항 테스트는 신뢰성, 안전성, 보안성, 사용자 편의성, 유지보수 용이성, 이식성 등을 테스트한다. 비기능적 요구 사항을 테스트할 수 있는 항목은 많으나, 테스트에서 그 모든 테스트 항목을 전부 수행할 수는 없고, 그중에서 시스템의 성격상 중요하다고 생각하는 항목만 테스트한다.

• 인수 테스트

인수 테스트(acceptance test)는 시스템이 예상대로 동작하는지 확인하고, 요구 사항에 맞는지 확신하기 위해 하는 테스트이다. 그래서 시스템을 인수하기 전 요구 분석 명세서에 명시된 대로 모두 충족시키는지를 사용자가 테스트한다. 인수 테스트가 끝나면 사용자는 인수를 승낙한 것이다. 시스템이 사용자에게 정상적으로 인수되면 프로젝트는 종료된다. 인수 테스트 시 인수 테스트 계획서는 사용자가 직접 작성하거나, 개발자가 작성한 것을 사용자가 승인한다. 인수 테스트는 사용자 주도로 이루어지며, 오류 발견보다는 제품의 출시 여부를 판단하는 것이 주목적이다. 인수 테스트 결과에 따라 시스템을 출시할지, 출시 시기를 늦추더라도 보완할지를 결정한다. V&V의 검증(validation)에 해당한다. 사용자가 개발자에게 프로젝트를 발주하고 개발 완료된 것을 테스트할 때는 위와 같은 방법으로 인수 테스트를 하지만, 일반인을 대상으로 제품을 만들어 판매하는 경우에는 알파 테스트와 베타 테스트를 수행한다.

알파 테스트

알파 테스트(alpha test)는 내부 필드 테스트라고도 한다. 개발 완료된 소프트웨어를 베타 테스트 전에 회사 내의 다른 직원에게 개발자 환경에서 사용해보도록 하고, 개발자가 그들이 사용하는 것을 보면서 오류와 사용상의 문제점들을 파악하는 것이다.

베타 테스트

베타 테스트(beta test)는 개발 완료되어 알파 테스트를 거친 소프트웨어를 시장에 상품으로 내놓기 전에 시장의 피드백을 얻기 위한 목적으로 한다. 특정 사용자에게 미리 사용해보도록 배포하는데, 베타 버전을 받은 사용자들이 사용자 입장에서 사용해본 다음 문제점이나 오류를 발견하면 개발자에게 알려주는 방식으로 테스트한다. 그런 다음 개발자가 베타 테스트를 통해 보고된 문제점을 수정하여 제품을 출시한다.

• 회귀 테스트

확정 테스트가 끝나면 또 한 번의 테스트를 해야 하는데 그것이 회귀 테스트(regression test)이다. 회귀 테스트는 한 모듈의 수정이 다른 부분에 영향을 끼칠 수도 있다고 생각하여 수정된 모듈뿐 아니라 관련된 모듈까지 문제가 없는지 테스트하는 것이다. 따라서 회귀 테스트는 한 모듈의 수정이 다른 부분에 미치는 영향을 최소화하기 위해 필요하다.

수정을 위한 회귀 테스트

수정을 위한 회귀 테스트(corrective regression test)는 모든 테스트를 완료하여 사용자에게 전달하기 전에 테스트 과정에서 미처 발견하지 못한 오류를 찾아 수정한 후 다시 테스트하는 것이다.

점진적 회귀 테스트

점진적 회귀 테스트(progressive regression test)는 사용 중에 일부 기능을 추가하여 새로운 버전을 만들고, 이 새 버전을 다시 테스트하는 것이다.

회귀 테스트는 테스트 케이스의 일부분을 재실행할 수도 있고, capture/playback 도구를 이용해 자동으로 수행할 수도 있다.

테스트 유형

• 기능 테스팅

시스템이 수행하는 그 무엇을 의미한다. 기능 테스팅은 모든 테스트 레벨에서 수행된다. 명세 기반 기법을 이용해서 시스템 이나 소프트웨어 기능성에서 테스트 조건과 테스트 케이스를 도출한다. 즉 소프트웨어의 외부적인 행동을 고려한다. 기능 테스팅 종류 중 하나인 보안성 테스팅은 악의적인 코드와 같은 외부 위협을 감지해내는 방화벽을 확인한다. 상호운용성 테스팅은 하나 또는 여러 개의 컴포넌트나 시스템이 서로 상호작용하는 능력을 평가한다.

• 비기능 테스팅

성능 테스팅, 이동성 테스팅, 스트레스 테스팅, 부하 테스팅 등이 있다. 시스템이 어떻게 동작을 하는 것이냐이다. 마찬가지로 모든 테스트 레벨에서 수행된다. 응답시간과 같은 다양한 척도, 스케일로 정량화 가능한 소프트웨어나 시스템의 특성을 측정하는 테스트이다. 즉 품질 모델을 참고한다.

• 구조적 테스팅

이는 화이트박스로 모든 테스트 레벨에서 수행 가능하다. 특정 유형의 구조의 커버지리를 평가하여 테스팅의 보장성, 충분함을 측정한다. 커버리지란 시스템 또는 소프트웨어 구조가 테스트 스위트에 의해 테스트된 정도(%)를 의미한다. 코드레벨 뿐만 아니라 호출 체계/구조와 같은 시스템 아키텍처 기반을 두고 수행할 수 있다.

• 변화 관련 테스팅: 재 테스팅/ 리그레션 테스팅

결함이 발견되고 끝나는 것이 아니다. 결함이 발견 되고 수정된 후에 원래 결함이 성공적으로 제거되었는지 확인해야하는데 이를 확인 테스팅이라 한다. 결함을 수정하는 것은 테스팅 활동이 아니다. 리그레션 테스팅은 이미 테스팅된 프로그램의 테스팅을 반복적으로 테스팅한다. 수정 이후에도 새롭게 만들어지거나 이전 결함으로 인해 발견되지 않은 결함을 또 발견하는 것이다. 전혀 관련성 없는 컴포넌트에서도 발생할 수 있다. 이들 모두 반복적인 성향을 갖는다.

• 유지보수 테스팅

시스템이 단종되거나 변경, 마이그레이션이 발생되고 시스템이 운영중일 때 진행된다. 변경은 계획적인 변경, 환경의 변경, 긴급 변경이 있다. 흔히 OS ,DB 업데이트 등이 있다. 마이그레이션은 새로운 환경에서도 테스팅이 진행되어야 한다. 단종 될 때는 마이그레이션도 포함해야 하고 데이터 보유기간이 필요하다면 그에 따른 테스팅도 해야한다.

활용

테스트 방법

• Loop back 테스트

시스템 논리구간 중 특정 지점 이후로 거래가 발생하지 않도록 하는 테스트, 병목 지점을 찾는 데 유용하다. Loop Back 코드를 추가해 테스트를 하는 것으로 소프트웨어가 여러 모듈 간에 통합이 되어있으므로 테스트 대상 코드에 바로 리턴하는 Look Back 코드를 추가해 테스트하고자 하는 코드에 대한 성능 테스트를 진행해 성능적인 이슈가 없는지 검증하는 테스트다.

• Tier 테스트

Tier간의 통신을 재현하여 하위 Tier 이후의 성능을 측정하여 성능 병목 지점을 찾는 테스트이다. Tier 테스트는 시스템의 구성이 여러 Tier로 구성되어 있을 때 병목이 발생한다면 어느 Tier에 의해 병목이 발생했는지 알 수 없으므로 Tier간 분리를 해 각 Tier에 병목이 없는지를 검증할 수 있도록 테스트 대상 Tier에 직접 부하를 주어 테스트하는 방법이다.

• Spike 테스트

모든 동시 단말 사용자가 동시에 거래를 발생시키는 테스트, 해당상황의 시스템을 점검한다. Spike 테스트는 특정 기능이 특정 시점에 동시에 사용되며 그로 인해 시스템의 성능은 피크치에 도달할 수 있다. 이러한 기능에 대해서는 정해진 시간 내에 모두 정상적으로 처리되는지 검증하고 시스템은 정상적인 상태를 유지하는지 체크하는 테스트다.

• 확장성 테스트

물리적 시스템 증설 대수와 시스템 향상 비율이 일정하지 않아 실시하는 테스트, 시스템 확장성 보장 여부를 판단한다. 확장성 시험은 시스템 증설에 정확히 비례해 성능이 증가되지 않으므로 시스템 증설에 따른 성능 증가 폭을 측정하기 위한 테스트다. 이 결과는 시스템 확장에 활용할 수 있는 중요한 자료가 된다.

• 가용성 테스트

장시간 거래를 발생시켜 일반 성능테스트에서 발견되지 않는 시스템 결함을 점검한다. Long Run 테스트라고도 불리는 가용성 시험은 자원 불균형 현상으로 시스템의 성능 저하나 다운 등의 현상이 있는지를 검증하기 위해 오랜 시간 동안 진행하는 성능 테스트다.

시스템 테스트

50가지가 넘는 유형의 시스템 테스트가 있다. 아래는 대형 소프트웨어 개발 회사가 일반적으로 사용하는 시스템 테스트 유형이다.

• 사용성 테스트

사용성 테스팅은 사용자들이 애플리케이션을 얼마나 쉽게 사용하는지와 제어를 처리하는 융통성(flexibility), 그것들의 객체를 충족시키기 위한 시스템 능력에 주로 초점을 맞춘다. 주로 사용자의 응용 프로그램 사용 용이성, 컨트롤 처리의 유연성 및 시스템의 목표 달성 능력에 중점을 둔다.

• 부하 테스트

소프트웨어 솔루션이 실제 부하에서 작동할 것임을 알기 위해서는 부하 테스트가 필요하다.

• 회귀 테스트

회귀 테스트는 개발 과정 동안 변경된 사항이 새로운 버그를 유발하지 않았는지 확인하기 위해 수행된 테스트를 포함한다. 또한 시간이 지남에 따라 새로운 소프트웨어 모듈을 추가할 때 오래된 버그가 나타나지 않도록 한다.

• 복구 테스트

복구 테스트는 소프트웨어 솔루션이 신뢰할 수 있고 가능한 충돌로부터 성공적으로 회수할 수 있음을 입증하기 위해 수행된다.

• 마이그레이션 테스트

마이그레이션 테스트는 소프트웨어를 이전 시스템 인프라에서 현재 시스템 인프라로 아무런 문제없이 이동할 수 있는지 확인하기 위해 수행된다.

• 기능 테스트

기능적 완성도 테스트라고도 하는 기능 테스트에는 가능한 누락된 기능을 생각해 보는 것이 포함된다. 테스터는 기능 테스트 중에 제품이 기능을 향상시킬 수 있는 추가 기능 목록을 만들 수 있다.

• 하드웨어/소프트웨어 테스트

IBM은 하드웨어/소프트웨어 테스팅을 "HW/SW 테스팅"이라고도 한다. 테스터가 시스템 테스트 중에 하드웨어와 소프트웨어 간의 상호작용에 집중할 때이다.

테스트 절차

성능테스트는 부하테스트툴을 사용하여 정보시스템의 최대 시간당 처리량(TPS)을 산출한다.

• 1. 성능테스트 시나리오 작성

현황 분석을 통해 실 사용과 가장 유사한 테스트 시나리오를 구성합니다. 시나리오를 구성하는 대표적인 방법에는 현황분석 인터뷰나 웹서버의 로그파일(accesslog)을 활용하는 것이 있습니다.

• 2. 부하모델 설계

가상 사용자 수, 부하발생방법(부하 증가 패턴), 부하발생지속시간 등을 정의하여 테스트 스크립트를 작성합니다.

• 3. 성능테스트 실행

부하테스트툴을 실행시켜 트랜젝션을 발생합니다.

• 4. 성능테스트 분석

서버 자원 사용율 측정, 테스트 시나리오 별 응답시간 측정, 시나리오 별 시간당 처리량을 측정하여 애플리케이션 성능, 서버 성능을 점검하고, 각 구간별(WEB/WAS/DB)별 성능 검증 및 구간과 구간 사이의 비효율 요소 분석합니다.

• 5. 결과분석 및 개선

애플리케이션 오류 수정, 비효율 요소 튜닝, 서버 파라미터 조정

• 6. 성능테스트 반복 수행

참고자료

• ihcho, 〈성능테스트〉, 《개인 블로그》, 2019-12-02
• testmanager, 〈시스템 테스트란 무엇입니까? 예제를 사용한 유형 및 정의〉, 《티스토리》, 2018-11-23
• 〈소프트웨어 테스트〉, 《위키백과》, 2020-08-16
• 〈화이트박스 검사〉, 《위키백과》, 2018-11-12
• 〈블랙박스 검사〉, 《위키백과》, 2019-04-16
• Crocus, 〈블랙박스 테스트, 화이트박스 테스트 개념〉, 《개인 블로그》, 2020-04-27
• 도리, 〈블랙박스 테스트, 화이트박스 테스트〉, 《위키백과》, 2019-01-25
• 쉽게 배우는 소프트웨어 공학, 〈단위 테스트〉, 《네이버 지식백과》, 2019-01-25
• 〈유닛 테스트〉, 《위키백과》, 2020-02-20
• 쉽게 배우는 소프트웨어 공학, 〈통합 테스트〉, 《네이버 지식백과》, 2019-01-25
• 쉽게 배우는 소프트웨어 공학, 〈시스템 테스트〉, 《네이버 지식백과》
• 쉽게 배우는 소프트웨어 공학, 〈인수 테스트〉, 《네이버 지식백과》
• 쉽게 배우는 소프트웨어 공학, 〈회귀 테스트〉, 《네이버 지식백과》
• 플밍장군, 〈테스트 - 테스트유형〉, 《티스토리》
• 도서관, 〈소프트웨어 성능 테스트 〉, 《티스토리》, 2018-11-23
• 비투엔, 〈정보시스템 성능 관리 이야기〉, 《개인 블로그》, 2017-07-06

같이 보기

• 시스템
• 트렌잭션
• 애플리케이션

이 테스트 문서는 프로그래밍에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.

개발 : 프로그래밍 □■⊕, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 프로그래밍 언어 ASP • C 언어 • C++ • C# • CSS • D 언어 • HTML • HTML5 • JSP • PHP • R • XHTML • XML • XSLT • 고(Go) • 고급언어 • 기계어 • 델파이 • 러스트 • 루비 • 루아 • 리액트 • 리퀴디티 • 무브 • 미켈슨 • 베이직 • 브이비스크립트 • 비주얼 C++ • 비주얼베이직(VB) • 비주얼베이직닷넷(VB.NET) • 솔리디티 • 스몰토크 • 스위프트 언어 • 스칼라 • 스크립트 언어 • 알골 • 어셈블리 • 언리얼스크립트 • 얼랭 • 에이잭스(Ajax) • 엠에프씨(MFC) • 오브젝티브-C • 오브젝트 파스칼 • 오카멜 • 웹어셈블리(WASM) • 이와즘(eWASM) • 자바 • 자바스크립트 • 저급언어 • 제이슨(JSON) • 제이쿼리(jQuery) • 카멜 • 코볼 • 코틀린 • 콜드퓨전 • 타입스크립트 • 파스칼 • 파워스크립트 • 파이썬 • 펄(Perl) • 포트란 • 프로씨(Pro-C) • 피엘에스큐엘(PL/SQL) • 피엘원(PL/I) • 하스켈 개발방법론 CBD 개발방법론 • EA • 구조적 개발방법론 • 객체지향 개발방법론 • 라이브러리 • 람다 아키텍처 • 모듈 • 모듈화 • 벤치마킹 • 소프트웨어 개발방법론 • 스크럼 • 스프린트 • 아키텍처 • 아키텍트 • 애자일 • 웹개발방법론 • 정보공학 개발방법론 • 컴포넌트 • 테일러링 • 템플릿 • 폭포수 모델 • 프로젝트 • 프로토타입 • 피드백 코딩 EUC-KR • UTF-8 • 값 • 글루웨어 • 노팔로우 링크 • 두팔로우 링크 • 디버깅 • 디코딩 • 마크업 • 버그 • 부트스트랩 • 세이브포인트 • 소스코드 • 시큐어코딩 • 아스키 • 액티브엑스 • 오픈소스 • 유니코드 • 인코딩 • 재컴파일 • 주석 • 컴파일 • 컴퓨터 프로그램 • 코드 • 코딩 • 태그 • 테스트 • 테이블 • 텍스트 • 파싱 • 퍼블리싱 • 퓨니코드 • 하드코딩 • 하이퍼링크 • 하이퍼텍스트 프로그래밍 C 명령어 • 객체 • 객체지향 • 객체지향 프로그래밍 • 거짓 • 관계연산자 • 기본형 변수 • 널 • 논리 • 논리연산 • 논리연산자 • 다중상속 • 다형성 • 대입 • 대입문 • 대입연산자 • 더블 • 도스 명령어 • 디폴트 • 레지스터변수 • 루프 • 리눅스 명령어 • 리턴 • 메모리 주소 • 메소드 • 멤버 • 명령문 • 명령어 • 무한루프 • 문자 • 문자열 • 바이트 • 반복문 • 배열 • 변수 • 분기 • 분기문 • 불린 • 브레이크 • 비교연산자 • 비트연산자 • 산술연산자 • 상속 • 상수 • 생성자 • 선언 • 선언문 • 설정자 • 속성 • 스위치 • 스태틱 • 시프트연산자 • 실행 • 실행문 • 어노테이션 • 에코 • 역참조 • 연산 • 연산문 • 연산자 • 오버로딩 • 오버라이딩 • 외부변수 • 윈도우 명령어 • 유닉스 명령어 • 인스턴스 • 인스트럭션 • 인클루드 • 인터페이스 • 임포트 • 입력 • 입력문 • 입출력 • 입출력문 • 자료형(데이터 타입) • 자바 명령어 • 자바 예약어 • 자바 컬렉션 • 전역변수 • 접근자 • 접근제어자 • 정보은닉 • 정수형 • 정적변수 • 제어 • 제어문 • 제어자 • 조건 • 조건문 • 조건연산자 • 주소 • 증감연산자 • 지역변수 • 참 • 참조 • 참조변수 • 초기화 • 추상메소드 • 추상클래스 • 추상화 • 출력 • 출력문 • 캡슐화 • 케이스 • 클래스 • 파라미터(매개변수) • 파이널 • 패키지 • 퍼블릭 • 포인터 • 프라이빗 • 프로텍티드 • 필드(멤버변수) • 함수 • 환경변수 명령어 abstract • array • boolean • break • byte • case • char • continue • default • double • do while • echo • elif • else • else if • false • final • float • for • gosub • goto • if • if else • import • include • int • join • long • long long • null • print • printf • println • private • protected • public • return • scanf • short • stdio.h • static • string • switch • temp • then • true • unsigned • void • while 디자인패턴 구조패턴 • 동시성패턴 • 동시실행패턴 • 모델-뷰-컨트롤러 패턴 • 상태패턴 • 생성패턴 • 싱글톤패턴 • 아키텍처패턴 • 전략패턴 • 커맨드패턴 • 행동패턴 프로그래밍 인물 귀도 반 로썸 • 그레이스 머레이 호퍼 • 니클라우스 비르트 • 댄 브릭클린 • 더그 커팅 • 데니스 리치 • 리누스 토르발스 • 리처드 그린블라트 • 마거릿 해밀턴 • 마크 앤드리슨 • 빈트 서프 • 빌 게이츠 • 빌 조이 • 스티브 잡스 • 에이다 러브레이스 • 제임스 고슬링 • 척 벤턴 • 켄 톰슨 • 팀 패터슨 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반