주제

소개 페이지 맨 위

테스트 설계에 사용되는 정보는 많은 곳(설계 모델, 분류자 인터페이스, 상태 차트 및 코드 자체)에서 수집됩니다. 어떤 점에서 이 소스 원본 정보는 실행 가능한 테스트로 변환해야 합니다.

  • 테스트 중인 소프트웨어에 지정된 특정 입력
  • 특정 하드웨어 및 소프트웨어 형상에서
  • 알려진 상태로 초기화
  • 예상된 특정 결과와 함께

소스 문서 정보에서 실행 가능한 테스트로 직접 이동할 수도 있지만 종종 중간 단계를 추가하는 것이 유용합니다. 이 단계에서 테스트 아이디어는 실행 가능한 테스트 작성에 사용되는 테스트 아이디어 목록으로 작성됩니다.

테스트 아이디어의 개념페이지 맨 위

테스트 아이디어(가끔 테스트 요구사항이라고도 지칭)는 수행될 수 있는 테스트에 대한 간단한 진술입니다. 간단한 예로 제곱근을 계산하는 기능을 생각하고 몇 가지 테스트 아이디어를 생각해봅시다.

  • 0 미만인 숫자 입력
  • 0 입력
  • 완전 제곱인(4 또는 16)인 숫자 테스트(결과가 정확히 2 또는 4인지?)

이러한 각 아이디어는 입력 및 예상 결과를 정확히 설명하여 쉽게 실행 가능한 테스트로 변환할 수 있습니다.

이 덜 특정적인 중간 형식에는 두 가지 장점이 있습니다.

  • 테스트 아이디어는 완전한 테스트보다 검토 및 이해가 쉽습니다. 그 이면의 이유를 이해하기가 쉽습니다.
  • 테스트 아이디어는 표제 목록을 사용하는 테스트 설계에서 나중에 설명하는대로 보다 강력한 테스트를 지원합니다.

제곱근 예는 모두 입력에 대해 설명하지만 테스트 아이디어는 실행 가능한 테스트의 모든 요소에 대해 설명할 수 있습니다. 예를 들어, "LaserJet IIIp로 인쇄"는 테스트 환경의 한 측면에 대해 설명합니다. 마찬가지로 "데이터베이스를 채우고 테스트"로도 가능합니다. 그러나 이러한 테스트 아이디어는 매우 불완전합니다. 도대체 프린터로 무엇을 인쇄할 것입니까? 데이터베이스를 채우기 위해 무엇을 수행합니까? 그러나 중요한 아이디어를 사장시키지 않고 나중에 테스트 설계에서 보다 자세히 설명할 수 있습니다.

테스트 아이디어는 종종 결함 모델(소프트웨어에서 나타나기 쉬운 결함과 이러한 결함을 가장 잘 발견할 수 있는 방법에 대한 개념)을 근거로 합니다. 예를 들어, 경계를 생각해봅시다. 제곱근 함수가 다음과 같은 사항을 구현할 수 있다고 가정하는 것이 안전합니다.

double sqrt(double x) {
    if (x < 0) 
      // signal error
    ...

또한 <<=으로 잘못 입력되기 쉽습니다. 사람들은 종종 이러한 유형의 실수를 하므로 확인할 가치가 있습니다. 잘못된 표현식(x<=0)과 올바른 표현식(x<0)은 if 명령문이 동일한 분기를 사용하므로 2 값을 가진 X로 결함을 발견할 수 없습니다. 마찬가지로 X에 -5 값을 지정하면 결함을 발견할 수 없습니다. 이 결함을 찾을 수 있는 유일한 방법은 X0 값을 제공하는 것입니다. 이것은 두 번째 테스트 아이디어를 증명합니다.

이 경우 결함 모델은 분명합니다. 다른 경우에는 암시적입니다. 예를 들어, 프로그램이 링크된 구조를 다룰 때마다 순환적인 것에 테스트를 수행하는 것이 바람직합니다. 많은 결함이 잘못 처리된 순환 구조로 이어질 수 있습니다. 테스트 목적으로 이것을 열거할 필요는 없습니다. 테스트를 수행할만한 몇 가지 결함의 가능성을 알고 있는 것만으로 충분합니다.

다음 링크는 다른 종류의 결함 모델에서 테스트 아이디어를 얻는 것에 대한 정보를 제공합니다. 처음 두 가지는 명시적인 결함 모델이고 마지막은 암시적 모델입니다.

이러한 결함 모델은 여러 가지 많은 결과물에 적용할 수 있습니다. 예를 들어, 첫 번째 모델은 부울 표현식으로 수행하는 사항에 대해 설명합니다. 이러한 표현식은 코드, 보호 조건, 상태 차트 및 순서 다이어그램, 메소드 작동에 관한 자연 언어 설명(예: 공개 API에서 찾을 수 있음)에서 찾을 수 있습니다.

가끔씩 특정 결과물에 대한 가이드라인을 알고 있는 것도 도움이 됩니다. ../../modguide/md_tstidssttact.htm -- This hyperlink in not present in this generated website가이드라인: 상태 차트 및 플로우 다이어그램에 대한 테스트 아이디어를 참조하십시오.

특정 테스트 아이디어 목록은 많은 결함 모델의 테스트 아이디어를 포함할 수 있고 이러한 결함 모델은 둘 이상의 결과물에서 도출되었을 수 있습니다.

목록을 사용하는 테스트 설계 페이지 맨 위

순차적인 콜렉션에서 문자열을 검색하는 메소드에 대한 테스트를 설계하고 있다고 가정합시다. 해당 검색에서 대소문자를 구분하거나 구분하지 않을 수 있고 발견된 첫 번째 일치사항의 색인 또는 일치사항이 없는 경우 -1을 리턴합니다.

int Collection.find(String string,
                    Boolean ignoreCase);

다음은 이 메소드에 대한 몇 가지 테스트 아이디어입니다.

  1. 첫 번째 위치에서 발견된 일치
  2. 마지막 위치에서 발견된 일치
  3. 일치하는 것이 없음
  4. 콜렉션에서 둘 이상의 일치 발견
  5. 대소문자 무시, 일치하는 것이 있지만 대소문자를 구분하는 경우 일치하지 않음
  6. 대소문자 구별, 정확히 일치하는 것 발견
  7. 대소문자 구별, 대소문자를 무시하는 경우 일치하는 문자열이 생략됨

각 테스트 아이디어마다 하나씩 이러한 7가지 테스트를 구현하는 것은 간단합니다. 그러나 여러 가지 다른 테스트 아이디어를 단일 테스트로 모을 수 있습니다. 예를 들어, 다음 테스트는 테스트 아이디어 2, 6, 7을 충족시킵니다.

설정: ["dawn", "Dawn"]으로 콜렉션 초기화
호출: collection.find("Dawn", false)
예상 결과: 리턴값 1 ("dawn"이 무시되지 않으면 0)

테스트 아이디어를 불특정적으로 만들면 조합하기가 쉬워집니다.

세 가지 테스트에서 모든 테스트 아이디어를 충족시킬 수 있습니다. 7개 테스트 아이디어를 충족시키는 3가지 테스트가 각각의 다른 7가지 테스트보다 좋은 이유는 무엇입니까?

  • 다수의 간단한 테스트를 작성하는 경우 테스트 N을 복사하여 새 테스트 아이디어를 충족시키는 정도로만 조금 변경한 뒤 테스트 N+1을 작성하는 것이 일반적입니다. 그 결과, 특히 복잡한 소프트웨어에서는 테스트 N+1이 테스트 N과 거의 동일한 방식으로 프로그램을 테스트하게 됩니다. 거의 완전히 동일한 코드 경로를 취합니다.

    각각이 몇 가지 테스트 아이디어를 충족시키는 소수의 테스트에서는 "복사 후 변경" 방법이 허용되지 않습니다. 각 테스트는 다른 방식으로 코드를 수행하고 다른 경로를 사용하여 마지막과 어느 정도 다르게 됩니다.

    그 방법이 더 나은 이유는 무엇입니까? 테스트 아이디어 목록이 프로그램의 모든 결함에 대한 테스트 아이디어로 채워진 경우 테스트 작성 방법은 문제가 되지 않습니다. 그러나 목록은 항상 버그를 발견할 수 있는 몇 가지 테스트 아이디어를 누락하고 있습니다. 각 테스트를 마지막 것과 매우 다른 방식으로 수행하면(겉보기에 불필요한 다양성을 추가하여) 테스트 중 하나에서 우연한 기회로 버그를 발견하게 되는 기회가 증가합니다. 결국 소수의 보다 복잡한 테스트는 필요성을 자각하지 못한 테스트 아이디어까지 테스트하는 기회를 높여줍니다.

  • 가끔 보다 복잡한 테스트를 작성할 때 새로운 테스트 아이디어가 떠오릅니다. 단순한 테스트에서는 수행하는 대부분이 마지막 테스트와 거의 동일하기 때문에 이러한 일이 거의 발생하지 않습니다. 결국 생각을 둔화시킵니다.

그러나 복잡한 테스트를 작성하지 않는 이유가 있습니다.

  • 각 테스트가 단일 테스트 아이디어를 충족시키고 아이디어 2의 테스트가 실패하는 경우 즉시 가능한 원인을 알 수 있습니다. 프로그램은 마지막 위치에서 일치한 사항을 처리하지 않습니다. 테스트가 아이디어 2, 6, 7을 충족하는 경우 문제를 분리시키는 것이 더 어렵습니다.

  • 복잡한 테스트는 이해 및 유지보수가 훨씬 어렵습니다. 테스트 목적도 덜 분명합니다.

  • 복잡한 테스트는 작성하기가 훨씬 어렵습니다. 5개 테스트 아이디어를 충족시키는 테스트를 작성할 때는 종종 각각이 하나씩을 충족시키는 5가지 테스트를 작성하는 것보다 많은 시간이 소요됩니다. 또한 오직 4개만 충족시키면서 5개를 모두 충족시킨다고 생각하는 오류를 범하기 쉽습니다.

실제로 복잡도와 단순성 사이에 적절한 균형점을 찾아야 합니다. 예를 들어, 첫 번째로 소프트웨어에 행하는 테스트(일반적으로 스모크 테스트))는 간단하며 이해 및 유지보수가 쉽고 가장 명백한 문제점을 파악할 수 있어야 합니다. 나중 테스트는 보다 복잡해야 하지만 유지보수가 가능한 정도로만 복잡해야 합니다.

테스트 세트를 완료한 후 개념: 개발자 테스트에 논의된 특징적인 테스트 설계 오류에 대해 확인하는 것이 좋습니다.

테스트 전에 테스트 아이디어 사용 페이지 맨 위

테스트 아이디어 목록은 설계 결과물의 검토 및 검사에 유용합니다. 예를 들어, 부서와 직원 클래스 간에 연관성을 보여주는 다음 설계 모델 부분을 생각해봅시다.

설계 모델 예 이미지

그림1: 부서와 직원 클래스 간 연관성

이러한 모델로부터 테스트 아이디어를 작성하는 규칙은 부서에 많은 직원이 있는 경우를 생각해보는 것입니다. 설계를 훑으면서 "이 시점에 부서에 직원이 많다면 어떨까?" 질문함으로써 설계 또는 분석 오류를 발견할 수 있습니다. 예를 들어, 한 번에 한 명의 직원만 부서 간에 이동할 수 있다는 사실을 인식할 수 있습니다. 그것은 회사가 많은 직원을 이동시켜야 하는 광범위한 개편을 하려는 경우 문제점이 될 수 있습니다.

이러한 결함(가능성이 간과되기 쉬운 경우)을 누락된 결함이라고 합니다. 결함 자체와 마찬가지로 이러한 결함을 발견하는 테스트가 테스트 노력에서 생략되었을 수 있습니다. 예를 들어, [GLA81], [OST84], [BAS87], [MAR00]와 누락된 결함이 전개에서 생략되는 빈도를 보여주는 기타 연구를 참조하십시오.

설계 활동에서 테스트 역할은 개념: 테스트 우선 설계에서 자세히 논의합니다.

테스트 아이디어 및 추적성 페이지 맨 위

추적성은 취사선택의 문제입니다. 그 가치가 그것의 유지보수 비용을 사용할 만큼 가치 있습니까? 이 질문은 ../../activity/ac_tst_dfnasstrcnds.htm -- This hyperlink in not present in this generated website활동: 평가 및 추적성 요구사항 정의 중에 고려되어야 합니다.

추적성이 가치 있는 경우 테스트를 유발시킨 결과물로 다시 테스트를 추적하는 것이 일반적입니다. 예를 들어, API와 그 테스트 간에 추적성이 있을 수 있습니다. API가 변경되면 변경할 테스트를 알아야 합니다. 코드(API를 구현하는)가 변경되면 실행할 테스트를 알아야 합니다. 테스트로 당황하게 되는 경우 테스트 수행을 계획한 해당 API를 찾을 수 있습니다.

테스트 아이디어 목록은 또 다른 레벨의 추적성을 추가합니다. 테스트로부터 테스트를 충족시키는 테스트 아이디어까지 추적한 후 테스트 아이디어에서 원래 결과물로 추적할 수 있습니다.



Rational Unified Process   2003.06.15