테스트
테스트(test)는 시스템의 성능을 시험한다. 단위 테스트, 통합 테스트, 사용자 인수 테스트가 있으며, 단위 테스트는 개별 시스템의 기능을 테스트하는 것이고, 통합 테스트는 전체 시스템의 상호 작용을 테스트하며, 사용자 인수 테스트(UAT)는 수요기관 담당자가 개발 결과물을 인수하기 전에 최종 테스트한다.
목차
개요[편집]
테스트란 안정적인 서비스를 위한 안정성 확보, 문제점 및 개선점을 파악한 후 해당사항을 수정하여 성능을 향상, 장애로 인한 데이터 손실, 신뢰도 저하, 추가비용 발생을 미연에 방지, 서버의 최적화를 위해 서버환경 검사를 목표로 한다. 테스트의 종류는 단위 테스트, 통합 테스트, 사용자 인수 테스트가 있다. 거의 모든 기술 프로세스와 마찬가지로 소프트웨어 테스팅은 일을 해야 하는 미리 정해진 순서를 가지고 있다. 마케팅을 준비하기 위해 새로운 소프트웨어를 완전히 테스트하는 단계이다.[1]
시스템 테스트란 완벽하게 통합된 소프트웨어 제품을 테스트하는 것이다. 일반적으로 소프트웨어는 더 큰 컴퓨터 기반 시스템의 한 요소일 뿐이다. 궁극적으로 소프트웨어는 다른 소프트웨어/하드웨어 시스템과 인터페이스 된다. 시스템 테스트는 컴퓨터의 전체 시스템을 사용하는 유일한 목적의 테스트이다.[2]
소프트웨어 테스트(software test)는 주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 소프트웨어 테스트는 또한 소프트웨어에 대한 객관적이고 독립적인 시각을 제공하여 사업 주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 한다. 시험 기술에는 프로그램이나 응용 프로그램을 실행하여 소프트웨어 버그를 찾는 절차를 포함되나 이에 국한되지는 않는다.[3]
구분[편집]
단위 테스트[편집]
단위 테스트(unit test)는 프로그램의 기본 단위인 모듈을 테스트하여 모듈 테스트(module test)라고도 한다. 구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 명세서의 내용대로 정확히 구현되었는지를 테스트한다. 즉 개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트한다. 화이트박스 테스트와 블랙박스 테스트를 모두 사용할 수 있지만, 모듈 내부의 구조를 구체적으로 들여다볼 수 있는 화이트박스 테스트 같은 구조적 테스트를 주로 시행한다.[4]
단위 테스트(unit test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다. 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로, 각 테스트 케이스는 서로 분리되어야 한다. 이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다. 유닛 테스트는 (일반적인 테스트와 달리) 개발자뿐만 아니라 보다 더 심도있는 테스트를 위해 테스터에 의해 수행되기도 한다.[5]
통합 테스트[편집]
단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트가 통합 테스트(integration test)이다. 실제 업무에서는 단위 모듈이 개별적으로 존재하는 것이 아니고 여러 모듈이 유기적 관계를 맺고 있으므로 이러한 모듈들을 결합한 형태로 테스트를 수행해봐야 한다. 이때 주로 확인하는 것은 '모듈 간의 상호작용이 정상적으로 수행되는가'이다. 즉 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지를 체크한다. 개별 모듈을 테스트하는 단위 테스트에서는 오류가 발견되지 않았어도, 모듈을 통합하면 상호 간의 인자나 공유 데이터 구조 등에서 오류가 발생할 수 있다. 또 단위 테스트 시 가상의 드라이버와 스텁 모듈을 만들어 테스트를 잘 수행했더라도, 상당히 제한적인 여건에서 테스트를 수행한 것이다. 그러므로 실제 모듈 통합 시에는 다른 결과가 나올 수도 있다. 실제 개발에서는 모듈 간의 상호작용과 인터페이스에서 많은 오류가 발생하는 것을 볼 수 있다. 그러므로 통합 테스트가 필요한데, 그 방법에는 모듈 통합을 한꺼번에 하는 방법과 점진적으로 하는 방법이 있다.[6]
- 하향식 기법
- 하향식(top-down) 기법은 시스템을 구성하는 모듈의 계층 구조에서 맨 상위의 모듈부터 시작하여 점차 하위 모듈 방향으로 통합하는 방법이다. 일반적으로 모듈의 종속 관계에서 상위 모듈은 시스템 전체의 흐름을 관장하고, 하위 모듈은 각 기능을 구현하는 형태로 구성되어 있다. 그러므로 하향식 기법을 이용하면 프로그램 전체에 영향을 줄 수 있는 오류를 일찍 발견하기가 쉽다. 그러나 하위 모듈이 임시로 만든 스텁들로 대체되어 결과가 완전하지 않을 수도 있고 스텁 수가 많으면 스텁을 만드는 데 시간과 노력이 많이 들 수 있다. 따라서 모듈 간의 인터페이스와 시스템의 동작이 정상적으로 잘되고 있는지를 빨리 파악하고자 할 때 하향식 기법을 사용하는 것이 좋다.[6]
- 상향식 기법
- 상향식(bottom-up) 기법은 하향식 기법과는 반대로 가장 말단에 있는 최하위 모듈부터 테스트를 시작한다. 하향식에서 스텁이 필요했다면, 상향식에서는 상위 모듈의 역할을 하는 테스트 드라이버가 필요하다. 이 드라이버는 하위 모듈을 순서에 맞게 호출하고, 호출할 때 필요한 매개 변수를 제공하며, 반환 값을 전달하는 역할을 한다. 상향식 기법의 장점은 최하위 모듈들을 개별적으로 병행하여 테스트할 수 있기 때문에 하위에 있는 모듈들을 충분히 테스트할 수 있다는 것이다. 또한 정밀한 계산이나 데이터 처리가 요구되는 시스템 같은 경우에 사용하면 좋다. 그러나 상위 모듈에 오류가 발견되면 그 모듈과 관련된 하위의 모듈을 다시 테스트해야 하는 번거로움이 생길 수 있다.[6]
시스템 테스트[편집]
개별 모듈의 단위 테스트가 끝나고 모듈 간의 인터페이스에는 문제가 없는지를 테스트하는 통합 테스트까지 끝나면, 시스템 전체가 정상적으로 작동하는지를 체크하는 시스템 테스트(system test)를 해야 한다. 시스템 테스트는 모듈이 모두 통합된 후 사용자의 요구 사항들을 만족하는지 테스트하는 것이다. 즉 사용자에게 개발된 시스템을 전달하기 전에 개발자가 진행하는 마지막 테스트라 할 수 있다. 앞에서 설명한 V&V에서 확인(verification)에 해당한다. 시스템 테스트는 실제 사용 환경과 유사하게 테스트 환경을 만들어놓고 요구 분석 명세서에 명시한 기능적 요구사항과 비기능적 요구 사항을 충족하는지 테스트한다. 주로 부하를 주는 상황에서 수행하고, 비기능적 테스트를 중심으로 수행한다. 기능적 요구 사항 테스트는 사용자가 요구하는 기능이 다 있는지, 필요 없는 기능이 포함되지는 않았는지 등을 테스트한다. 비기능적 요구 사항 테스트는 신뢰성, 안전성, 보안성, 사용자 편의성, 유지보수 용이성, 이식성 등을 테스트한다. 비기능적 요구 사항을 테스트할 수 있는 항목은 많으나, 테스트에서 그 모든 테스트 항목을 전부 수행할 수는 없고, 그중에서 시스템의 성격상 중요하다고 생각하는 항목만 테스트한다.[7]
인수 테스트[편집]
인수 테스트(acceptance test)는 시스템이 예상대로 동작하는지 확인하고, 요구 사항에 맞는지 확신하기 위해 하는 테스트이다. 그래서 시스템을 인수하기 전 요구 분석 명세서에 명시된 대로 모두 충족시키는지를 사용자가 테스트한다. 인수 테스트가 끝나면 사용자는 인수를 승낙한 것이다. 시스템이 사용자에게 정상적으로 인수되면 프로젝트는 종료된다. 인수 테스트 시 인수 테스트 계획서는 사용자가 직접 작성하거나, 개발자가 작성한 것을 사용자가 승인한다. 인수 테스트는 사용자 주도로 이루어지며, 오류 발견보다는 제품의 출시 여부를 판단하는 것이 주목적이다. 인수 테스트 결과에 따라 시스템을 출시할지, 출시 시기를 늦추더라도 보완할지를 결정한다. V&V의 검증(validation)에 해당한다. 사용자가 개발자에게 프로젝트를 발주하고 개발 완료된 것을 테스트할 때는 위와 같은 방법으로 인수 테스트를 하지만, 일반인을 대상으로 제품을 만들어 판매하는 경우에는 알파 테스트와 베타 테스트를 수행한다.[8]
- 알파 테스트(alpha test) : 내부 필드 테스트라고도 한다. 개발 완료된 소프트웨어를 베타 테스트 전에 회사 내의 다른 직원에게 개발자 환경에서 사용해보도록 하고, 개발자가 그들이 사용하는 것을 보면서 오류와 사용상의 문제점들을 파악한다.[8]
- 베타 테스트(beta test) : 개발 완료되어 알파 테스트를 거친 소프트웨어를 시장에 상품으로 내놓기 전에 시장의 피드백을 얻기 위한 목적으로 사용된다. 특정 사용자에게 미리 사용해보도록 배포하는데, 베타 버전을 받은 사용자들이 사용자 입장에서 사용해본 다음 문제점이나 오류를 발견하면 개발자에게 알려주는 방식으로 테스트한다. 그런 다음 개발자가 베타 테스트를 통해 보고된 문제점을 수정하여 제품을 출시한다.[8]
- 회귀 테스트
회귀 테스트(regression test)는 확정 테스트가 끝나면 다시 한 번 사용되는 테스트이다. 한 모듈의 수정이 다른 부분에 영향을 끼칠 수도 있다고 생각하여 수정된 모듈뿐 아니라 관련된 모듈까지 문제가 없는지 테스트하는 것이다. 따라서 회귀 테스트는 한 모듈의 수정이 다른 부분에 미치는 영향을 최소화하기 위해 필요하다. 수정 회귀 테스트(corrective regression test)는 수정을 위한 회귀 테스트는 모든 테스트를 완료하여 사용자에게 전달하기 전에 테스트 과정에서 미처 발견하지 못한 오류를 찾아 수정한 후 다시 테스트하며, 점진적 회귀 테스트(progressive regression test)는 사용 중에 일부 기능을 추가하여 새로운 버전을 만들고, 이 새로운 버전을 다시 테스트한다. 회귀 테스트는 테스트 케이스의 일부분을 재실행할 수도 있고, 캡처 및 플레이백 도구를 이용해 자동으로 수행할 수도 있다.[9]
특징[편집]
테스트 방법[편집]
루프백(Loop back) 테스트는 시스템 논리구간 중 특정 지점 이후로 거래가 발생하지 않도록 하는 테스트이며, 병목 지점을 찾는 데 유용하다. 루프백 코드를 추가해 테스트를 하는 것으로 소프트웨어가 여러 모듈 간에 통합이 되어있으므로 테스트 대상 코드에 바로 리턴하는 루프백 코드를 추가해 테스트하고자 하는 코드에 대한 성능 테스트를 진행해 성능적인 이슈가 없는지 검증하는 테스트이다. 계층(Tier) 테스트는 계층간의 통신을 재현하여 하위 계층 이후의 성능을 측정하여 성능 병목 지점을 찾는 테스트이다. 또한, 계층 테스트는 시스템의 구성이 여러 계층으로 구성되어 있을 때 병목이 발생한다면 어느 계층에 의해 병목이 발생했는지 알 수 없으며, 계층 간 분리를 해 각 계층에 병목이 없는지를 검증할 수 있도록 테스트 대상 계층에 직접 부하를 주어 테스트하는 방법이다. 모든 동시 단말 사용자가 동시에 거래를 발생시키는 테스트인 스파이크(Spike) 테스트는 해당상황의 시스템을 점검한다. 특정 기능이 특정 시점에 동시에 사용되며, 그로 인해 시스템의 성능은 피크치에 도달할 수 있다. 이러한 기능에 대해서는 정해진 시간 내에 모두 정상적으로 처리되는지 검증하고 시스템은 정상적인 상태를 유지하는지 체크한다.
물리적 시스템 증설 대수와 시스템 향상 비율이 일정하지 않아 실시하는 확장성 테스트는 시스템 확장성 보장 여부를 판단한다. 확장성 시험은 시스템 증설에 정확히 비례해 성능이 증가되지 않으므로 시스템 증설에 따른 성능 증가 폭을 측정하기 위한 테스트이며, 이 결과는 시스템 확장에 활용할 수 있는 중요한 자료가 된다. 장시간 거래를 발생시켜 일반 성능테스트에서 발견되지 않는 시스템 결함을 점검하는 가용성 테스트는 장기간(Long Run) 테스트라고도 불리며, 자원 불균형 현상으로 시스템의 성능 저하나 다운 등의 현상이 있는지를 검증하기 위해 오랜 시간 동안 진행하는 성능 테스트이다.[10]
시스템 테스트[편집]
50가지가 넘는 유형의 시스템 테스트가 있다. 대형 소프트웨어 개발 회사가 일반적으로 사용하는 시스템 테스트 유형으로, 사용성 테스트는 사용자들이 애플리케이션을 얼마나 쉽게 사용하는지와 제어를 처리하는 융통성(flexibility), 그것들의 객체를 충족시키기 위한 시스템 능력에 주로 초점을 맞춘다. 주로 사용자의 응용 프로그램 사용 용이성, 컨트롤 처리의 유연성 및 시스템의 목표 달성 능력에 중점을 둔다. 또한, 소프트웨어 솔루션이 실제 부하에서 작동할 것임을 알기 위해서는 부하 테스트가 필요하며, 개발 과정 동안 변경된 사항이 새로운 버그를 유발하지 않았는지 확인하기 위해 수행된 테스트를 포함하는 회귀 테스트가 있다. 시간이 지남에 따라 새로운 소프트웨어 모듈을 추가할 때 오래된 버그가 나타나지 않도록 한다. 복구 테스트는 소프트웨어 솔루션이 신뢰할 수 있고 가능한 충돌로부터 성공적으로 회수할 수 있음을 입증하기 위해 수행되고, 마이그레이션 테스트는 소프트웨어를 이전 시스템 인프라에서 현재 시스템 인프라로 아무런 문제없이 이동할 수 있는지 확인하기 위해 수행된다. 기능적 완성도 테스트라고도 불리는 기능 테스트에는 가능한 누락된 기능이 없는지 확인한다. 테스터는 기능 테스트 중에 제품이 기능을 향상시킬 수 있는 추가 기능 목록을 만들 수도 있다. IBM은 하드웨어 및 소프트웨어 테스팅을 'HW/SW 테스팅'이라고도 표현한다. 테스터가 시스템 테스트 중에 하드웨어와 소프트웨어 간의 상호작용에 집중할 수 있다.[2][10]
테스트 절차[편집]
성능테스트는 부하테스트툴을 사용하여 정보시스템의 최대 시간당 처리량(TPS)을 산출하며, 성능테스트의 테스트 절차는 다음과 같다.
- 성능테스트 시나리오 작성 : 현황 분석을 통해 실 사용과 가장 유사한 테스트 시나리오를 구성하며, 시나리오를 구성하는 대표적인 방법에는 현황분석 인터뷰나 웹서버의 로그파일(accesslog)을 활용한다.
- 부하모델 설계 : 가상 사용자 수, 부하발생방법인 부하 증가 패턴, 부하발생지속시간 등을 정의하여 테스트 스크립트를 작성한다.
- 성능테스트 실행 : 부하테스트툴을 실행시켜 트랜젝션을 발생한다.
- 성능테스트 분석 : 서버 자원 사용율 측정, 테스트 시나리오 별 응답시간 측정과 시나리오 별 시간당 처리량을 측정하여 애플리케이션 성능 및 서버 성능을 점검한다. 각 구간별 웹(web), 와스(WAS), 데이터베이스 별 성능 검증 및 구간과 구간 사이의 비효율 요소를 분석한다.
- 결과분석 및 개선 : 애플리케이션 오류 수정, 비효율 요소 튜닝, 서버 파라미터 조정 등이 있다.
- 반복 수행 : 성능테스트를 반복적으로 수행한다.[11]
비교[편집]
화이트박스 테스트[편집]
화이트박스 테스팅(White-box testing)은 응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식으로, 블랙박스 검사와는 반대된다. 화이트박스 테스트(White Box Test) 기법은 소프트웨어 내부 소스 코드를 테스트하는 기법이다. 화이트박스 테스트를 하는 이유는 내부 소스코드의 동작을 개발자가 추적 할 수 있기 때문에, 동작의 유효성 뿐만아니라 실행 되는 과정을 확인하여 코드가 어떤경로로 실행되며, 불필요한 코드 혹은 테스트 되지 못한 부분을 확인할 수 있다. 화이트박스 테스트를 하는 부분은 대개 코드의 실행 경로를 확인해야 하기때문에 시중에 나와 있는 커버리지 분석도구를 많이 활용한다. 화이트박스 검사 기법은 블랙박스 검사 기법에 비해 많은 과 같은 무료도구가 있는 반면에 크리티컬한 마켓에 사용되는 상용 도구도 있다. [12]
화이트박스 테스트에는 여러가지 검증 방법이 있다. 화이트박스 테스트의 문장 검증은 프로그램의 모든 문장이 적어도 한 번씩 수행되는 검증 기준이다. 또한, 선택하는 부분만 검증하는 선택 검증, 수행 가능한 모든 경로를 검사하는 경로 검증, IF 문장이나 While 문장 내 조건식을 조사하는 기준의 검증인 조건 검증 등이 있다.[13]
블랙박스 테스트[편집]
블랙박스 검사(Black-box testing)는 소프트웨어 검사 방법 중 하나로 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법을 이르는 말이다. 주로 올바른 입력과 올바르지 않은 입력을 일일이 다 동원하여 올바른 출력을 판별하는 방식으로 검사가 이루어지기 때문에 검사의 진행에 있어 대상이 되는 소프트웨어의 코드나 내부 구조 및 개발 노하우에 대한 정보는 기본적으로 필요로 하지 않는다. 필요한 것은 특징, 요구 사항, 검사를 위해 공개된 설계도 등 대외적으로 공개된 사항들이며 '이 소프트웨어는 무슨 역할을 수행해야 되는가'와 같이 대상이 되는 소프트웨어의 특징이나 요구 사항 등에 초점을 맞춰 검사가 이루어진다. 검사 자체는 기능에 관한 것일 수도 있고 기능 외의 것에 관한 것일 수도 있다. 이 방법은 유닛 검사, 인테그레이션 검사, 기능 검사, 시스템 검사, 적합성 검사 이렇게 소프트웨어 검사의 모든 레벨에 적용 가능하다. [14]
블랙박스 테스트에는 사용자가 소프트웨어와 제품에대한 요구사항과 결과물이 일치하는 지 확인하기 위해 테스트 기법이 사용된다. 동등분할 기법(Equivalence Partitioning)은 프로그램의 입력 도메인을 테스트 케이스가 산출될 수 있는 데이터 클래스로 분류하는 방법이며, 경계값분석 기법(Boundary Value Analysis)은 입력 조건의 중간 값보다 경계 값에서 에러가 발생 될 확률이 높다는 점을 이용하여 테스트 케이스를 생성한다. 오류예측 기법(Error Guessing)은 각 시험 기법들이 놓치기 쉬운 오류들을 감각 및 경험으로 찾아보며, 입력 데이터 간 관계가 출력에 미치는 영향을 그래프로 표현하여 오류를 발견하도록하는 기법은 원인 결과그래프 기법(Cause Effect Graph)이다. 논리적 조건이나 상황에서 입력 조건과 결과를 참, 거짓으로 표현하여 조합을 만들고 테스트케이스를 작성하는 의사결정 테이블 테스팅과 시스템에 반영되는 이전의 상태가 무엇인지, 상태간 전이, 상태를 변화시키는 이벤트와 입력값을 파악하는 상태전이 테스팅도 있다.[13]
소프트웨어 테스트[15] 구분 블랙박스 테스트 화이트 박스 테스트 정의 모듈사양서를 기초로 입력 및 출력 조건 등 모든 기능면의 테스트 모듈사양서 소스코드를 기초로 모듈의 논리 테스트 관점 사용자 관점 개발자 관점 기준 인터페이스 및 성능 오류 논리상 오류 V&V 상위 레벨의 사용자 환경 하위 레벨의 시험 환경 대상 시작, 종료, 인터페이스 결함 루프, 결정 결함, 비수행 구문 기법 동등 분할, 경계값분석 등 루프, 제어구조 테스트 활용 베타 테스트 알파 테스트
활용[편집]
- 기능 테스팅
- 기능 테스팅은 시스템이 수행하는 그 무엇을 의미하며, 모든 테스트 레벨에서 수행되어 진다. 명세 기반 기법을 이용해서 시스템 이나 소프트웨어 기능성에서 테스트 조건과 테스트 케이스를 도출하고, 소프트웨어의 외부적인 행동을 고려한다. 기능 테스팅의 종류 중 하나인 보안성 테스팅은 악의적인 코드와 같은 외부 위협을 감지해내는 방화벽을 확인 하기도 한다. 상호운용성 테스팅은 하나 또는 여러 개의 컴포넌트나 시스템이 서로 상호작용하는 능력을 평가한다.[16]
- 비기능 테스팅
- 비기능 테스팅은 응답시간과 같은 다양한 척도 및 스케일로 정량화 가능한 소프트웨어나 시스템의 특성을 측정하는 테스트이다. 성능 테스팅, 이동성 테스팅, 스트레스 테스팅, 부하 테스팅 등이 있다. 시스템이 어떻게 동작을 하는 것에 따라 다르며, 모든 테스트 레벨에서 수행되어 지고, 품질 모델을 참고한다.[16]
- 구조적 테스팅
- 구조적 테스팅은 화이트박스로, 모든 테스트 레벨에서 수행된다. 특정 유형의 구조의 커버지리를 평가하여 테스팅의 보장성과 충분함을 측정한다. 또한, 커버리지란 시스템 및 소프트웨어 구조가 테스트 스위트에 의해 테스트된 정도(%)를 의미한다. 코드레벨과 호출 체계 및 구조와 같은 시스템 아키텍처 기반을 두고 수행할 수 있다.[16]
- 변화 관련 테스팅
- 확인 테스팅은 결함이 발견되고 끝나지 않는다. 결함이 발견 되고 수정된 후에 원래 결함이 성공적으로 제거되었는지 확인해야하는데 이를 확인 테스팅이라 한다. 결함을 수정하는 것은 테스팅 활동이 아니다. 리그레션 테스팅은 이미 테스팅된 프로그램의 테스팅을 반복적으로 테스팅한다. 수정 이후에도 새롭게 만들어지거나 이전 결함으로 인해 발견되지 않은 결함을 다시 발견하며, 전혀 관련성 없는 컴포넌트에서도 발생할 수 있다. 이들 모두 반복적인 성향을 갖는다.[16]
- 유지보수 테스팅
- 유지보수 테스팅은 시스템이 단종되거나 변경, 마이그레이션이 발생되고 시스템이 운영중일 때 진행된다. 변경은 계획적인 변경, 환경의 변경, 긴급 변경이 있다. 흔히 운영체제, 데이터베이스 업데이트 등이 있다. 마이그레이션은 새로운 환경에서도 테스팅이 진행되어야 하며, 단종 될 때는 마이그레이션도 포함해야 하고 데이터 보유기간이 필요하다면 그에 따른 테스팅도 해야한다.[16]
각주[편집]
- ↑ ihcho, 〈성능테스트〉, 《인코덤》, 2019-12-02
- ↑ 2.0 2.1 testmanager, 〈시스템 테스트란 무엇입니까? 예제를 사용한 유형 및 정의〉, 《티스토리》, 2018-11-23
- ↑ 소프트웨어 테스트 위키백과 - https://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%ED%85%8C%EC%8A%A4%ED%8A%B8
- ↑ 쉽게 배우는 소프트웨어 공학, 〈단위 테스트〉, 《네이버 지식백과》, 2019-01-25
- ↑ 유닛 테스트 위키백과 - https://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%9B_%ED%85%8C%EC%8A%A4%ED%8A%B8
- ↑ 6.0 6.1 6.2 쉽게 배우는 소프트웨어 공학, 〈통합 테스트〉, 《네이버 지식백과》, 2019-01-25
- ↑ 쉽게 배우는 소프트웨어 공학, 〈시스템 테스트〉, 《네이버 지식백과》
- ↑ 8.0 8.1 8.2 쉽게 배우는 소프트웨어 공학, 〈인수 테스트〉, 《네이버 지식백과》
- ↑ 쉽게 배우는 소프트웨어 공학, 〈회귀 테스트〉, 《네이버 지식백과》
- ↑ 10.0 10.1 도서관, 〈소프트웨어 성능 테스트 〉, 《티스토리》, 2018-11-23
- ↑ 비투엔, 〈(기고) 정보시스템 성능 관리 이야기〉, 《티스토리》, 2017-07-06
- ↑ 화이트박스 검사 위키백과 - https://ko.wikipedia.org/wiki/%ED%99%94%EC%9D%B4%ED%8A%B8%EB%B0%95%EC%8A%A4_%EA%B2%80%EC%82%AC
- ↑ 13.0 13.1 Crocus, 〈블랙박스 테스트, 화이트박스 테스트 개념〉, 《개인 사이트》, 2020-04-27
- ↑ 블랙박스 검사 위키백과 - https://ko.wikipedia.org/wiki/%EB%B8%94%EB%9E%99%EB%B0%95%EC%8A%A4_%EA%B2%80%EC%82%AC
- ↑ 도리, 〈블랙박스 테스트, 화이트박스 테스트〉, 《개인 블로그》, 2019-01-25
- ↑ 16.0 16.1 16.2 16.3 16.4 사용자 플밍장군, 〈테스트 - 테스트유형〉, 《티스토리》, 2019-08-05
참고자료[편집]
- ihcho, 〈성능테스트〉, 《인코덤》, 2019-12-02
- testmanager, 〈시스템 테스트란 무엇입니까? 예제를 사용한 유형 및 정의〉, 《티스토리》, 2018-11-23
- 소프트웨어 테스트 위키백과 - https://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%ED%85%8C%EC%8A%A4%ED%8A%B8
- 화이트박스 검사 위키백과 - https://ko.wikipedia.org/wiki/%ED%99%94%EC%9D%B4%ED%8A%B8%EB%B0%95%EC%8A%A4_%EA%B2%80%EC%82%AC
- 블랙박스 검사 위키백과 - https://ko.wikipedia.org/wiki/%EB%B8%94%EB%9E%99%EB%B0%95%EC%8A%A4_%EA%B2%80%EC%82%AC
- Crocus, 〈블랙박스 테스트, 화이트박스 테스트 개념〉, 《개인 사이트》, 2020-04-27
- 도리, 〈블랙박스 테스트, 화이트박스 테스트〉, 《개인 블로그》, 2019-01-25
- 쉽게 배우는 소프트웨어 공학, 〈단위 테스트〉, 《네이버 지식백과》, 2019-01-25
- 〈유닛 테스트〉, 《위키백과》, 2020-02-20
- 쉽게 배우는 소프트웨어 공학, 〈통합 테스트〉, 《네이버 지식백과》, 2019-01-25
- 쉽게 배우는 소프트웨어 공학, 〈시스템 테스트〉, 《네이버 지식백과》
- 쉽게 배우는 소프트웨어 공학, 〈인수 테스트〉, 《네이버 지식백과》
- 쉽게 배우는 소프트웨어 공학, 〈회귀 테스트〉, 《네이버 지식백과》
- 사용자 플밍장군, 〈테스트 - 테스트유형〉, 《티스토리》, 2019-08-05
- 도서관, 〈소프트웨어 성능 테스트 〉, 《티스토리》, 2018-11-23
- 비투엔, 〈(기고) 정보시스템 성능 관리 이야기〉, 《티스토리》, 2017-07-06
같이 보기[편집]
| ||||||||||||||||||||||||||||||||||||||
