'Beta'에 해당되는 글 2건

  1. 2015.08.28 [Elasticsearch] 2.0.0 beta 테스트를 위한 dependency 설정.
  2. 2008.06.19 [펌]소프트웨어 테스트 개요

[Elasticsearch] 2.0.0 beta 테스트를 위한 dependency 설정.

Elastic/Elasticsearch 2015. 8. 28. 12:27

오전에는 못찾았는데... 

지금은 2.0.0-bete1-SNAPSHOT 을 잘 찾내요.


===========================


기능 점검을 하기 위해서 maven dependency 수정을 해야 합니다.

beta 이고 snapshot 버전이다 보니 repository 설정을 제대로 해 놓지 않으면 jar 를 찾지 못하는 오류가 발생을 합니다.

혹시 테스트 해보실 분은 아래와 같이 정보 추가 또는 수정해 주시면 될 것 같습니다.


벌써 beta2 가 올라왔내요.


[pom.xml]

<elasticsearch.version>2.0.0-beta2-SNAPSHOT</elasticsearch.version>


<repositories>

  <repository>

    <id>elasticsearch-releases</id>

    <url>http://maven.elasticsearch.org/releases</url>

    <releases>

      <enabled>true</enabled>

    </releases>

    <snapshots>

      <enabled>false</enabled>

    </snapshots>

  </repository>

  <repository>

    <id>oss-snapshots</id>

    <name>Sonatype OSS Snapshots</name>

    <url>https://oss.sonatype.org/content/repositories/snapshots/</url>

  </repository>

</repositories>


<dependencies>

  <dependency>

    <groupId>org.elasticsearch</groupId>

    <artifactId>elasticsearch</artifactId>

    <version>${elasticsearch.version}</version>

    <type>jar</type>

  </dependency>

</dependencies>


:

[펌]소프트웨어 테스트 개요

ITWeb/스크랩 2008. 6. 19. 15:47

ref. http://blog.naver.com/sesangsari/20050249197

소프트웨어
테스트 개요

정의

  • 테스트는 프로그램이나 시스템이 자신이 해야 되는 일을 수행하는 믿음을 주는 과정이다. [Hetzel 73]
  • 컴퓨터 소프트웨어를 실행하여 그 결과가 올바른지 판단하는 과정이다. [Glass 79]
  • 에러를 발견한 목적으로 프로그램을 실행하는 과정이다. [Myers 79]
  • 프로그램 테스트는 오류가 존재함을 보일 수는 있지만, 오류가 없음을 보일 수는 없다 [Dijkstra 72]
  • 테스트소프트웨어 품질을 측정하고 개선하기 위한 테스트웨어를 공학화하여 사용하고 유지하기 위한 또 다른 아이프사이클 프로세스이다. [Crag and Jaskiel 02]

Beizer 소프트웨어 테스트 진화 과정

  • Level 1 (debugging-oriented) - 이 레벨에서는 테스트와 디버깅의 차이가 뚜렷하게 보이지 않는다. 즉, 우연히 발견된 오류를 수정하는 디버깅에 중점을 두며 프로그램의 오류를 착기 위한 별도의 노력을 기울이지 않는다.
  • Level 2 (demonstration-oriented) - 프로그램이 올바르게 동작한다는 사실을 입증하기 위해 테스트를 수행한다.
  • Level 3 (destruction-oriented) - 프로그램에 오류가 존재함을 보여주기 위해 테스트를 수행한다.
  • Level 4 (evaluation-oriented) - Level3의 테스트가 실제 프로그램 코드에 있는 오류를 발견하는 것에 초점을 맞추었다면, Level4에서는 소프트웨어 개발 전 단계에 발생하는 오류를 발견하는 개념으로 확장
  • Level 5 (prevention-oriented) - 프로그램의 오류를 사전에 발견하는 것이 아니라 오류가 발생하지 않도록 사전에 방지하자는 개념으로, 프로그램을 개발할 때 처음부터 테스트가 용이하도록 시스템을 설계/ 테스트 용이성을 고려한 프로그램 설계

소프트웨어 오류 원인 및 분포

  • 요구사항의 잘못된 정의 -
  • 고객과 개발자간의 잘못된 의사 소통이나 부재
  • 고의적인 요구사항 미 준수
  • 설계 오류
  • 코딩 오류
  • 문서나 코딩 표준에 따르지 않는 경우
  • 미흡한 테스트 프로세스
  • 요구사항(56%), 설계(27%), 코드(10%), 기타(7%)

테스트 오라클

  • 테스트 실행 결과가 올바른 결과인지를 판별할 수 있는 매커니즘을 일컬음.
  • 테스트 오라클의 분류
    1. 참 오라클 (true oracle) - 모든 입력값들에 대해 원하는 결과들을 생성하여 발생된 오류를 놓치지 않고 검출할 수 있는 오라클을 말함. ex) sin을 계산하는 프로그램을 검사하기위해, 다른 알고리즘을 사용하여 직접 계산
    2. 샘플링 오라클 (sampling oracle) - 특정 몇몇 입력 값들에 대해서만 원하는 결과를 제공해 주는 오라클. ex) sin 함수 테스트 시 0, 90, 180, 270, 360도에 대해서만 결과를 제공함.
    3. 휴리스틱 오라클 (heuristic oracle) - 샘플링 오라클의 단점을 개선하기 위해 특정 몇몇 입력 값들에 대해서는 샘플링 오라클의 경우처럼 올바른 결과를 제공하고, 나머지 입력 값들에 대해서는 휴리스틱으로 처리하는 오라클 ex) sin함수 테스트시 0, 90, 180, 270, 360도에 대해서 올바른 결과를 확인하고, 나머지는 x의 값이 증감에 따라 sin(x)가 증감함을 비교하여 실행결과가 올바른지 판단
    4. 일관성 검사 오라클 (consistent oracle) - 대부분의 상업용 테스트 도구에서 지원하는 테스트 오라클 형태로써, 리그레션 테스트에서의 테스트 오라클은 수정되기 전의 프로그램의 실행 결과와 수정된 후의 테스트 실행 결과를 비교하는 역할을 담당하며, 이는 자동화할 수 있다.

소프트웨어 테스트 전략

소프트웨어 테스트 분류

개발 단계별 분류별

  • 단위테스트 : 구현 단계에서 각 모듈이 구현된 후에 단위 테스트를 수행, 모듈이 단독적으로 실핼할 수 있는 환경 필요
  • 통합테스트 : 단위 테스트가 완료된 모듈 간의 인터페이스 상호작용이 올바르게 되는지를 테스트함으로써 (1) 개별적인 모듈에 대한 테스트가 불충분하게 수행됨을 보완 (2) 제한된 상황만을 고려한 테스트 스텁 때문에 실제 모듈과 통합하는 과정에서 오류가 발생을 확인 (3) 전역 변수 등으로 인해 모듈간의 예기치 못한 상호 작용 때문에 발생하는 부작용(side effect) 인한 오류 발생 부분을 확인 가능하다.
    1. 빅뱅테스트
    2. 점진적 테스트
      1. 하향식 통합 : 가장 상위 모듈을 테스트하기 위해 하위 모듈들을 테스트 스텁들로 대치한 후에 테스트를 수행하는 방식임. 설계상의 오류를 빨리 발견할 수 있다는 장점이 있는 반면에, 많은 수의 테스트 스텁이 필요하기 때분에 비용이 많이 소요될 수 있다. 블랙박스 테스트만 사용하는 경우 하위 모듈이 충분하게 테스트되지 않을 가능성 있음.
      2. 상향식 통합 : 하위 모듈을 먼저 테스트하고 상위에 있는 모듈들을 통합하는 방식임. 하위에 있는 모듈들을 충분하게 테스트할 수 있고, 테스트 스텁 비용이 들지 않는 장점이 있는 반면 설계 오류를 조기에 발견하는 못하는 단점이 있다.
      3. 샌드위치 통합 : 하향식+상향식의 통합하는 방법
  • 시스템 테스트 : 전체 시스템에 대한 초기의 목적을 만족시키는가를 테스트로 통합 테스트가 완료된 후에 완전한 시스템에 대해 시스템 명세에 따라 개발되었는지를 검증하기 위해 수행하는 테스트임. 단위 테스트나 통합 테스트는 기능이 올바르게 수행되는지를 검증하는 것에 중점을 두지만, 시스템 테스트는 시스템의 기능 측면에서뿐만 아니라 신뢰성, 견고성, 성능, 안정성과 같은 비기능적 요구사항을 시스템이 만족하는 지도 검증함.
  • 인수테스트 : 사용자의 요구 사항을 만족하는 가를 확인, 사용자 입장에서 실제 사용자 환경에서 테스트, 시스템테스트에서 사용한 테스트 케이스들을 이용할 수 있음
    1. 알파 테스트 : 사용자에 의해 테스트가 수행되지만 개발자 환경에서 통제된 상태로 수행
    2. 베타 테스트 : 소프트웨어를 일정 수의 사용자들에게 사용하고 피드백을 받는다. 보통 베타 테스트에서는 개발자가 참여하지 않음.
  • 리그레션 테스트 ; 유지보수 단계에서 변경이 제대로 이루어지는 지를 테스트
    1. 오류 수정 작업 (corrective maintenance) - 21%
    2. 기능 보강 작업 (perfective maintenance) - 50%
    3. 적응 작업 (adaptive maintenance) - 25%
    4. 예방 작업 (preventive maintenance) - 4%

  • 테스트드라이버 역할
    1. 테스트 케이스가 저장되어 있는 파일이나 DB로부터 하나의 테스트 케이스를 읽는다.
    2. 읽은 테스트 케이스를 입력 인자로 사용하여 테스트 대상이 되는 모듈을 호출한다.
    3. 모듈의 실행 결과를 저장하고 다음 테스트 케이스를 읽는다. 경우에 따라서는 테스트 드라이버가 테스트 오라클 역할을 수행할 수 있다. (즉 실행결과가 원하는 결과인지를 판별하여 프로그램에 오류가 검출되었는지를 판별하는 기능을 수행)
    4. 2-3과정을 더 이상 실행할 테스트 케이스가 없을때까지 반복하여 수행

  • 테스트 스텁 : 호출되는 모듈의 완전한 기능에 의존되지 않는 경우에는 단순히 호출되는 모듈명과 인자들을 출력할 수 있는 형태, 인자 값들과 관계 없이 특정 싱핼 겨로가를 미리 파일에 전달해서 이를 전달할 수 있다.
  • 모의 객체
    1. 객체 지향 프로그램에서 단위 테스트를 수행할 때 테스트되는 메소드가 다른 클래스 객체에 의존
    2. 독립적인 단위 테스트를 위해서는 절차 지향적 프로그램밍에서 스텁과 같은 개념을 사용하는 것이 필요하며 일정의 스텁의 객체 지향 버전임
    3. 수작업으로 만들거나, 모의 객체 라이브러리(ex: easymock / http://www.easymock.org )를 이용

테스트케이스 생성별

  • 블랙박스 테스트 : 명세를 기반으로 테스트 케이스 작성
    1. 동등분할 클래스
    2. 경계값 분석
    3. 결정 테이블 기반 테스트
    4. 도메인 테스트
    5. Pairwise 테스트
    6. 상태 전이 테스트
    7. Cause-effect graph
  • 화이트박스 테스트 : 프로그램 코드 정보 (제어 및 자료흐름)을 바탕으로 테스트 케이스 작성
    1. 제어흐름 기반 테스트
    2. 자료흐름 기반 테스트
    3. 결함 기반 테스트

테스트 목적별

  • 침입(penetration) 테스트 - 시스템의 보안을 테스트
  • 견고성(robustness) 테스트 - 시스템이 비정상적인 운영환경하에서 얼마나 동작이 원활하게 이루어 지는지를 시험
    1. 네거티브 테스트 : 시스템이 기대하지 않는 입력들을 테스트 데이터로 사용
  • 성능 테스트
  • 스트레스 테스트 및 볼륨 테스트
  • 신뢰성(reliability) 테스트 - 시스템이 어느 기간 동안에 요구되는 서비스를 제공하는 능력을 측정, 통계적 테스트(statistical testing)방법을 사용함.
    1. 가용성(availability) : 시스템이 주어진 기간 동안 서비스를 실제로 제공할 수 있는지 나타내는 속성 (ex : 가용성이 0.995 : 시스템은 1,000시간 단위 동안 995시간 단위 동안 서비스를 제공)
    2. MTTF(mean time to failfure) : 시스템이 운영된 후 오류가 발생할 때까지의 평균 동작 시간 (ex : MTTF가 100 : 100시간 단위마다 1개의 오류가 발생할 수 있다는 것을 의미 )

테스트 대상별

  • 컴파일러 테스트
  • 임베디드 시스템 소프트웨어
  • 운영 체제
  • 웹시스템
  • 컴포넌트 테스트

소프트웨어 테스트 Rule

소프트웨어 테스트 원칙

  1. 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹에 의해서 수행되어야 한다.
  2. 테스트 작업을 가장 능력이 뛰어난 사람에 할당하라.
  3. 오류가 발견되지 않을 것이란 가정하에서 테스트 계획을 수립해서는 안된다.
  4. 타당한 경우뿐만 아니라 타당하지 않고 예상하지 못한 경우들에 대해서도 테스트를 수행하라.
  5. 프로그램의 어떵 부분에 오류가 남아있을 확률은 이미 발견된 오류의 수에 직접적으로 비례한다. (Pareto원칙)
  6. 테스트 케이스를 체계적으로 관리하라
  7. 각각의 테스트 결과를 철저하게 검증하라

테스트기법의 Cam. Kaner 분류

  • 테스트 기법을 구분하는 5가지 요인
  1. Tester : 누가 테스트를 수행하는가?
    • 사용자 테스트, 알파, 베타, 전문가, 짝 테스트
  2. 범위 : 어떤 측면을 테스트 하는가?
    • 함수, 기능 또는 통합 함수, 메뉴, 도메인, 동등 클래스, 경계값, 입력 필드, 논리, 상태, 경로, 요구사항, …
  3. 잠재적 문제(risk based) : 찾고 있는 문제의 형식은?
    • 실패에 대한 예측 비용 관점에서 우선 순위 부여
    • 오류 비용 가능성이 클수록 초기에 주의 깊게 테스트
  4. 행위 : 어떤 테스트를 수행하는가?
    • 회귀, 스크립트 기반, 시나리오, 설치, 부하, 성능…
  5. 평가 : 테스트를 통과했는지 어떻게 알 수 있을까?
    • 자가검증데이터, 저장된 결과와 비교, 다른 공인문서와 비교, 일관성
  • 생각하는 방식에 따라 기법이 분류된다.

Joel Test

  • SW팀 평가 테스트 방법 ( Joen on Software )
  1. 소스코드 관리 시스템을 사용하고 있습니까?
  2. 한번에 빌드를 만들어 낼 수 있습니까?
  3. 일일 빌드를 하고 있습니까?
  4. 버그 추적 시스템을 운영하고 있습니까?
  5. 코드를 새로 작성하기 전에 버그를 수정합니까?
  6. 일정을 업데이트하고 있습니까?
  7. 명세서를 작성하고 있습니까?
  8. 조용한 작업 환경에서 일하고 있습니까?
  9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
  10. 테스터를 별도로 두고 있습니까?
  11. 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
  12. 무작위 사용편의성 테스트를 수행하고 있습니까?

Test Paradigm Shift

  • 테스트 단계 활동 –> 모든 단계 활동
  • 정상 수행 확인 –> 오류(Error) 발견
  • 단위 테스트 중심 –> 시스템 테스트 중심

Effective Test

  • How to make testing more effective (by Boris Beizer)
  1. Know which test techniques work best
  2. Automate retesting and test management
  3. Minimize test design labor
  4. Know when to stop testing

Test CheckList

  1. Configuration/설치 테스팅
    1. HW 및 SW가 정확히 설치되었는가?
    2. 모든 파일과 연결(connection)이 생성되었는가?
    3. 모든 적절한 데이터 파일이 load되었는가?
    4. System defaults가 적절히 구성되었는가?
    5. 다른 시스템과의 인터페이스 및 주변 기기가 잘 작동하는가?
  2. 호환성 및 상호운영성 테스팅
    1. 호환성: 실제 환경에서 운영할 때 기존의 시스템에 대해 오동작이 없는가?
    2. 상호운영성 : 실제 환경에서 대상 시스템을 운영할 때 다른시스템과 성공적으로 연동 하는가?
  3. 문서 및 도움말 테스팅
    1. 문서 검토, 상호 참조 등을 활용하여 작성해야 함, 신규 또는 익숙하지 않은 사용자의 경우 필수적임.
  4. 장애회복(Fault recovery) 테스팅
    1. 에러 또는 예외 상황 발생 후 정상 상태로 회복되어 성공적으로 운영될 수 있는가?
    2. 적절한 백업데이터가 유지되는가?
    3. 백업데이터가 안정한 장소에 저장되는가?
    4. 회복 절차가 문서화되어 있는가?
    5. 회복 전담요원이 할당되고 훈련되었는가?
    6. 회복 도구가 개발되고 가용한가?
  5. 성능 테스팅: 자동화 도구를 활용하는 경우가 많음.
    1. 어떤 측면을 주로 테스트할 것인가?
    2. 성능 요구사항은 무엇인가?
    3. 시스템 사용시 어떻게 변화되는가?
    4. 어떻게 시험하는가?
  6. 자동화된 테스팅
    1. Test automation tools 활용 재사용 가능한 테스트 생성 및 예상결과외 실제 결과를 기록으로 남김)
    2. 적용분야 : 기능 테스팅, 성능/볼률/스트레스 테스팅, 특히 regression testing시 유용함
  7. Intrusive 테스팅
    1. 테스트 결과를 테스터가 볼 수 없을 때 프로그램 일부를 수정하여 테스트
    2. 수정된 시스템은 원상 복귀하여야하며, 엄격한 change control 및 형상관리가 요구됨
  8. Thread 테스팅
    1. Business 기능을 처음부터 끝까지 테스트 함 (사용자 혹은 운영자가 시스템을 사용하는 것과 같은 방식)
  9. ETC
    1. Security 테스팅 - 요구되는 수준의 보안을 구현하였는지 테스트함 (비밀보장,가용성,데이터및 SW무결성을 점검)
    2. Stress 테스팅 - Peak Load일 때 정확하게 작동하는지 점검
    3. Usability 테스팅 - User-based surveys등 수행
    4. Volume 테스팅 - 데이터의 양이 많을 때 정확하게 작동하는지 점검
    5. Compliance 테스팅 - 표준 및 절차에 따라 개발되었는지 점검

Testability

  • 제어용이성 (controllability) 프로그램의 실행을 제어하기 용이하도록 설계. 제어 용이성이 높아지면 테스트를 자동화할 수 있는 부분이 많아지고 최적화 할 수 있다.
  • 관찰가능성 (observability) - 프로그램의 내부 상태가 현재 어떤 상태인지를 쉽게 파악할 수 있는 기능을 갖추도록 설계
  • 단순성 (simplicity) - 가능한 시스템 구조 등을 단순하게 설계하면 더 효율적으로 테스트를 수행할 수 있다.
  • 분할용이성 (decomposability) - 테스트할 대상 영역을 제어함으로써 문제가 발생된 곳을 고릅시켜 독립적으로 모듈에 대한 테스트를 수행할 수 있도록 설계
  • 운영용이성 (operability) - 프로그램이 결함이 발생하여도 테스트 작업을 계속할 수 있도록 설계
  • 안정성 (stability) - 테스트 동안에 소프트웨어에 대한 변경이 자주 발생되지 않도록 설계
  • 이해용이성 (understandability) - 소프트웨어 설계 정보가 잘 조직화되어 쉽게 접근 가능하도록 하여 소프트웨어를 더욱 잘 이해할 수 있도록 설계
: