개념: 테스트 아이디어 카탈로그
테스트 아이디어 카탈로그는 발생하기 쉬운 대부분의 소프트웨어 결함을 주로 발견할 수 있는 테스트 아이디어를 나열합니다. 이 가이드라인은 작성 방법을 설명합니다.
관계
기본 설명

소개

대다수 프로그래밍은 이전에 반복적으로 사용한 것을 취하여 다른 컨텍스트에서 다시 사용합니다. 이러한 것들은 일반적으로 특정 클래스 데이터 구조(예: 링트된 목록, 해시 테이블 또는 관계형 데이터베이스) 또는 오퍼레이션(예: 검색, 정렬, 임시 파일 작성 또는 브라우저 창 팝업)입니다. 예를 들어, 두 고객의 관계형 데이터베이스에는 흔한 특성이 많이 있게 됩니다.

이러한 흔한 특성의 흥미로운 부분은 흔한 결함이 포함된다는 점입니다. 사람들은 이중 링크된 목록에 무엇인가를 잘못 삽입하는 가상의 새 방법을 만들지는 않습니다. 이들은 이전의 실수와 동일한 실수를 저지르기 쉽습니다. 브라우저 창을 팝업하는 프로그래머는 다음과 같은 흔한 실수를 저지를 수 있습니다.

  • 이미 열린 창을 다시 사용해야 할 때 새 창을 작성합니다.
  • 모호하거나 최소화된 브라우저 창을 볼 수 있게 만들지 못합니다.
  • 사용자가 다른 기본 브라우저를 선택했을 때 Internet Explorer를 사용합니다.
  • JavaScript의 사용 가능 여부를 검사하지 못합니다.

흔한 결함이므로 결함을 발견할 수 있는 테스트 아이디어도 흔한 내용이 됩니다. 이러한 테스트 아이디어를 재사용할 수 있도록 테스트 아이디어 카탈로그에 저장하십시오.

테스트 아이디어 카탈로그의 결함 발견 방법

카탈로그의 장점 중 하나는 둘 이상의 기초적인 결함을 발견하는 데 단일 테스트 아디어가 유용할 수 있다는 것입니다. 다음은 두 개의 결함을 발견하는 한 가지 아이디어에 대한 예입니다.

첫 번째 결함은 C 컴파일러에 있었습니다. 이 컴파일러는 "-table" 또는 "-trace" 또는 "-nolink"와 같은 명령행 옵션을 사용합니다. 해당 옵션들은 최소한의 고유 형식으로 줄일 수 있습니다. 예를 들어, "-ta"는 "-table"입니다. 그러나 "-t"는 모호하므로 허용되지 않습니다. 이것은 "-table" 또는 "-trace"를 의미할 수 있습니다.

내부적으로 명령행 옵션은 다음과 같은 테이블에 저장됩니다.

-table
-trace
-nolink

명령행에 옵션이 있으면 테이블을 찾습니다. 테이블 항목의 접두부인 경우 일치합니다. "-t"는 "-table"과 일치합니다. 한 가지 일치사항을 발견한 후 나머지 테이블은 다른 일치사항을 검색합니다. 또 다른 일치사항이 있으면 모호성을 나타내므로 오류입니다.

검색을 수행한 코드는 다음과 유사합니다.

for (first=0; first < size; first++)
{
  if (matches(entry[first], thing_sought))
  { /* at least one match */
    for(dup=first+1; dup < size; dup++) /* search for another */
    if (matches(entry[dup], thing_sought)) /* extra match */
      break; /* error out */
    return first;
  }
}
return -1; /* Not found or ambiguity */

문제점이 보입니까? 이것은 상당히 파악하기 어렵습니다.

문제는 break 명령문입니다. 이중 일치가 발견되면 가장 바깥쪽의 감싸는 루프 밖으로 나오려고 하지만 실제로 내부에서 중단됩니다. 이것은 두 번째 일치를 발견하지 않는 것과 동일한 결과입니다. 첫 번째 일치사항에 대한 색인이 리턴됩니다.

이 결함은 검색 중인 옵션이 "-t"와 같이 테이블에서 두 번 일치되는 경우에만 발견될 수 있습니다.

두 번째 완전히 다른 결함을 보십시오.

코드는 문자열을 사용합니다. 문자열의 마지막 '='를 '+'로 바꿉니다. '='가 없으면 아무것도 수행되지 않습니다. 코드는 표준 C 라이브러리 루틴 strchr을 사용합니다. 다음은 해당 코드입니다.

    ptr = strchr(string, '=');  /* Find last = */ if (ptr != NULL_CHAR)     *ptr = '+';

이 문제점 또한 다소 발견하기 어렵습니다.

strchr 함수는 문자열에서 마지막이 아닌 첫 번째 일치하는 값을 리턴합니다. 올바른 함수는 strrchr입니다. 문제점은 인쇄 오류입니다. (실제로 뿌리깊은 기초적인 문제점은 오직 한 문자만 다른 두 함수를 표준 라이브러리에 넣는 것입니다.)

이 결함은 입력에 둘 이상의 등호 부호가 있는 경우에만 발견할 수 있습니다. 즉 다음과 같습니다.

  • "a=b"는 올바른 결과 "a+b"를 리턴합니다.
  • "noequals"는 올바른 결과 "noequals"를 리턴합니다.
  • "a=b=c"는 올바르지 않은 "a+b=c"를 리턴하고 올바른 "a=b+c"를 리턴하지 않습니다.

여기에서 흥미롭고 유용한 점은 완전히 다른 근본 원인(오식, C 구성체에 대한 오해)과 동일한 테스트 아이디어(두 번 발생하는 사항 검색)로 발견될 수 있는 코드의 서로 다른 징후(잘못된 함수 호출, break 명령문의 잘못된 사용)가 있는 두 결함을 가지고 있다는 점입니다.

좋은 테스트 아이디어 카탈로그

무엇이 좋은 카탈로그를 만듭니까?

  • 대다수 기초적인 결함을 발견할 수 있는 작은 테스트 아이디어 세트를 포함해야 합니다.
  • 빨리 읽기 쉬어야 합니다(대충 훑기). 상황과 무관한 테스트 아이디어를 무시할 수 있어야 합니다.
  • 사용할 테스트 아이디어만 포함해야 합니다. 예를 들어, 웹 브라우저를 다루어 본 적이 없는 사람은 웹 브라우저를 사용하는 프로그램의 테스트 아이디어를 건너뛰어서는 안됩니다. 게임 소프트웨어에서 작업 중인 사람은 안전성이 필수인 소프트웨어에서 작업 중인 사람보다 간단한 카탈로그를 원하게 됩니다. 게임측 사람은 결함 발견 기회를 높여주는 테스트 아이디어에만 집중할 수 있습니다.

이러한 규칙을 보면 둘 이상의 카탈로그를 갖는 것이 적절한 것으로 보입니다. 일부 데이터 및 오퍼레이션은 모든 프로그래밍에서 공통되므로 해당 테스트 아이디어는 모든 프로그래머가 사용할 수 있는 카탈로그에 넣을 수 있습니다. 다른 사항은 특정 영역에 특정되므로 이에 대한 테스트 아이디어는 영역 특정 테스트 아이디어에 대한 카탈로그에 넣을 수 있습니다.

다음 예제에서 사용된 샘플 카탈로그 (Adobe Reader 얻기)는 시작하기에 적절합니다. AND 및 OR 혼용에 대한 테스트 아이디어에서는 또 다른 예제를 제공합니다.

테스트 아이디어 카탈로그 사용 예제

다음은 샘플 카탈로그 사용 방법입니다. 다음 메소드를 구현하고 있다고 가정합니다.

    void applyToCommonFiles(Directory d1,         Directory d2,         Operation op);

applyToCommonFiles는 두 디렉토리를 인수로 사용합니다. 첫 번째 디렉토리의 파일이 두 번째 디렉토리의 파일과 이름이 동일한 경우 applyToCommonFiles는 해당 파일 쌍에 몇 가지 오퍼레이션을 수행합니다. 이는 서브디렉토리로 내려갑니다.

카탈로그 사용 방법은 상황과 일치하는 주요 표제를 찾아서 훑어 내려가는 것입니다. 각 표제의 테스트 아이디어가 관련 있는지 확인한 후 테스트 아이디어 목록에 관련된 사항을 기록합니다.

주: 이 단계별 설명은 카탈로그 사용이 어려운 것처럼 보이게 할 수 있습니다. 실제로 작성하는 것보다 체크리스트 작성에 관해 읽는 데 더 많은 시간이 걸립니다.

따라서 applyToCommonFiles의 경우 이 섹션 나머지에서 설명된 방식대로 카탈로그를 적용할 수 있습니다.

첫 번째 항목은 임의의 오브젝트입니다. 인수가 널(null) 포인터일 수 있습니까? 이는 applyToCommonFiles 및 호출자 사이의 계약 문제입니다. 호출자가 널(null) 포인터를 전달하지 않게 계약할 수 있습니다. 널 포인터를 전달하는 경우 예상 동작을 신뢰할 수 없습니다. applyToCommonFiles는 임의 조치를 수행할 수 있습니다. 이러한 경우 applyToCommonFiles가 잘못 수행되지 않기 때문에 테스트가 부적절합니다. 그러나 applyToCommonFiles가 널(null) 포인터를 검사해야 하는 경우 테스트 아이디어는 유용하게 됩니다. 테스트 아이디어 목록을 시작하는 다음 사항을 제공하는 후자를 가정해 보십시오.

  • d1 is null (error case)
  • d2 is null (error case)
  • op is null (error case)

다음 카탈로그 항목은 문자열입니다. 파일 이름은 문자열이먀 일치 여부가 비교됩니다. 빈 문자열("")을 사용하는 테스트 아이디어는 바람직하지 않아 보입니다. 몇 가지 표준 문자열 비교 루틴이 사용되고 빈 문자열을 올바로 처리합니다.

그러나 비교되는 문자열이 있는 경우는 어떠합니까? d1에 "File" 파일이 포함되어 있다고 가정해 보십시오. d2 또한 "file"이라는 파일을 포함하고 있습니다. 이러한 파일이 일치되어야 합니까? UNIX에서는 분명 그렇지 않습니다. Microsoft® Windows®에서는 거의 확실히 그렇습니다. 다음은 또 다른 테스트 아이디어입니다.

  • 두 디렉토리에서 파일이 일치하지만 이름의 대소문자가 다릅니다.

이 테스트 아이디어는 카탈로그에서 직접 온 것이 아닙니다. 그러나 카탈로그를 통해 특정 프로그램 측면(문자열인 파일 이름)에 주의를 기울이게 되고 창조적으로 추가 아이디어를 제공하게 됩니다. 카탈로그를 너무 좁은 의미로 사용하지 마십시오. 새 아이디어를 끌어내는 방법인 브레인스토밍 기법으로 사용하십시오.

다음 항목은 콜렉션입니다. 디렉토리는 파일의 콜렉션입니다. 콜렉션을 처리하는 많은 프로그램은 빈 콜렉션에 실패합니다. 빈 콜렉션 또는 많은 요소를 가진 콜렉션을 처리하는 몇몇 프로그램은 한 요소만을 가지는 콜렉션에 실패합니다. 따라서 다음 아이디어가 유용합니다.

  • d1은 비어 있습니다.
  • d2는 비어 있습니다.
  • d1은 오직 한 개의 파일만 가지고 있습니다.
  • d2는 오직 한 개의 파일만 가지고 있습니다.

다음 아이디어는 최대 가능한 크기의 콜렉션을 사용하는 것입니다. applyToCommonFiles는 일반적으로 작은 디렉토리에서 사용됩니다. 그러면 일부 사용자는 안에 수 천개의 파일이 있는 두 개의 거대한 디렉토리 트리에 이를 적용하여 프로그램의 메모리 사용이 매우 비효율적이며 해당 경우를 처리할 수 없음을 알게됩니다.

이제 디렉토리의 절대적인 최대 크기를 테스트하는 것은 중요하지 않습니다. 사용자가 시도할만큼의 크기만 필요합니다. 그러나 최소한 디렉토리에 세 개 이상의 파일이 있는 일부 테스트가 있어야 합니다.

  • d1은 매우 많은 파일을 포함합니다.
  • d2는 매우 많은 파일을 포함합니다.

최종 테스트 아이디어(중복 요소)는 파일의 디렉토리에 적용되지 않습니다. 즉 동일한 이름을 가지는 두 개의 파일을 포함하는 디렉토리가 있는 경우 applyToCommonFiles와 상관없는 문제점(파일 시스템이 손상됨)이 발생합니다.

다음 카탈로그 항목은 검색입니다. 이 아이디어는 다음과 같은 applyToCommonFiles 용어로 변환될 수 있습니다.

  • d1 및 d2에는 공통적인 파일이 없습니다(모든 이름이 다릅니다).
  • d1 및 d2에는 공통으로 정확히 한 파일만 있습니다(디렉토리에서 영문자순으로 마지막 요소).
  • d1 및 d2에는 공통으로 둘 이상의 파일이 있습니다.

최종 테스트 아이디어는 applyToCommonFiles를 확인합니다. 첫 번째 일치사항을 발견하자마자 리턴합니까? 해당 앞의 테스트 아이디어에 삽입된 설명은 프로그램이 영문자순으로 정렬된 리턴하는 일부 라이브러리 루틴을 사용하여 디렉토리의 파일 목록을 페치한다고 가정합니다. 그렇지 않은 경우 마지막 요소를 일치하는 값으로 사용하는 것이 좋을 수도 있습니다. 많은 시간을 파일의 정렬 방식을 알아내는 데 할애하기 전에 일치하는 마지막 요소를 넣은 것이 결함 발견을 쉽게 만드는지 스스로에게 질문해보십시오. 콜렉션에서 마지막 요소를 넣는 것은 코드가 명백하게 색인을 사용하여 콜렉션 단계를 밟는 경우 훨씬 유용합니다. 반복기를 사용하는 경우 순서는 거의 문제되지 않습니다.

샘플 카탈로그에서 하나 이상의 항목을 보십시오. 링크된 구조 항목은 일반적인 파일 콜렉션이 아닌 디렉토리 트리를 비교하고 있다는 것을 주지시킵니다. applyToCommonFiles를 테스트하는 방법을 결정하면 불완전한 설명 문제에 직면하게 됩니다.

디렉토리 구조가 다음과 같은 경우,

디렉토리 구조 다이어그램

그림 1: 디렉토리 구조

applyToCommonFilesCdir 디렉토리로 내려옵니까? 이것은 이치에 닿지 않는 것 같습니다. 다른 디렉토리 트리의 어느 것과도 일치하지 않을 수 있습니다. 사실 서브디렉토리의 파일은 서브디렉토리 이름이 일치하는 경우에만 일치하는 것처럼 보입니다. 즉 다음 디렉토리 구조를 가지고 있다고 가정해 보십시오.

보조 디렉토리 구조 다이어그램

그림 2: 두 번째 디렉토리 구조

"File" 이름의 파일들이 다른 서브디렉토리에 있기 때문에 일치되는 결과를 찾을 수 없습니다. d1 d2 양쪽 모두에 동일한 이름이 있는 경우에만 서브디렉토리로 내려가야 합니다. 이것은 다음 테스트 아이디어로 이어집니다.

  • d1의 일부 서브디렉토리는 d2에 없음(내리기 없음)
  • d2의 일부 서브디렉토리는 d1에 없음(내리기 없음)
  • 일부 서브디렉토리가 d1과 d2에서 모두 나타남(내리기)

그러나 다른 질문이 제기됩니다. 오퍼레이션(op)을 일치하는 파일 또는 일치하는 서브디렉토리에 적용해야 합니까? 서브디렉토리에 적용하는 경우 내리기 이전 또는 나중에 적용해야 합니까? 예를 들어, 오퍼레이션이 일치하는 파일 또는 디렉토리를 삭제하는 경우 차이가 있습니다. 이러한 문제에서 오퍼레이션은 디렉토리 구조를 반드시 수정할 수 있어야 합니까? 더 세부적으로 보면 이 경우 applyToCommonFiles의 올바른 동작은 무엇입니까? (이것은 반복기와 함께 수반되는 동일한 문제점입니다.)

이러한 종류의 질문은 일반적으로 테스트 아이디어 작성 방법의 설명을 주의깊게 읽을 때 제기됩니다. 그러나 지금은 잠시 옆에 보류해두십시오. 응답이 무엇이든간에 해당 사항에 대한 테스트 아이디어가 있어야 합니다(코드가 응답을 제대로 구현하는지 여부를 검사하는 테스트 아이디어).

카탈로그로 돌아갑시다. 여전히 테스트 아이디어 모두를 고려하지 못했습니다. 첫 번째 구조(비어 있는 구조)는 빈 디렉토리를 요청합니다. 이미 이것은 콜렉션 항목으로부터 얻었습니다. 또한 단일 요소가 있는 디렉토리인 비어 있지 않은 최소 구조도 있습니다. 이러한 유형의 중복은 드물지 않지만 무시하면 됩니다.

순환 구조는 어떠합니까? 디렉토리 구조는 순환적일 수 없습니다(디렉토리는 자신의 하위 또는 자체 내에 있을 수 없습니다). 바로 가기(Windows) 또는 기호 링크(UNIX)는 어떠합니까? d1의 디렉토리 트리에 d1로 다시 연결되는 바로가기가 있는 경우 applyToCommonFiles 의 내림차순을 계속 유지해야 합니까? 응답은 하나 이상의 새로운 테스트 아이디어로 이어질 수 있습니다.

  • d1은 바로 가기 또는 기호 링크 때문에 순환적입니다.
  • d2는 바로 가기 또는 기호 링크 때문에 순환적입니다.

올바른 동작에 따라 그보다 많은 테스트 아이디어가 있을 수 있습니다.

마지막으로 둘 이상의 깊이는 어떠합니까? 초기 테스트 아이디어는 한 레벨의 서브디렉토리로 내려가는 것을 테스트하는 것이었지만 applyToCommonFiles가 계속 내려가는지 확인해야 합니다.

  • d1의 서브디렉토리의 몇 레벨(>1)을 내려갑니다.
  • d2의 서브디렉토리의 몇 레벨(>1)을 내려갑니다.

자체 테스트 아이디어 카탈로그 작성 및 유지보수

이전에 언급한 바와 같이 일반 카탈로그는 필요한 모든 테스트 아이디어를 포함하지 않습니다. 그러나 특정한 도메인에 대한 카탈로그는 작성한 회사 밖에서는 공표된 적이 없습니다. 그것을 원하는 경우 빌드해야 합니다. 다음은 몇 가지 조언입니다.

  • 결함 찾기에 적절한 아이디어에 대한 추측으로 카탈로그를 채우지 마십시오. 카탈로그에 넣은 각 테스트 아이디어에는 시간과 비용이 들어갑니다.
    • 카탈로그를 유지보수하는 시간
    • 테스트 아이디어에 관핸 생각하는 다른 프로그래머의 시간
    • 테스트를 구현하는 다른 프로그래머의 시간

    시연된 트랙 레코드가 있는 아이디어만 추가하십시오. 테스트 아이디어가 파악했을 수 있는 최소 하나의 실제 결함을 지시할 수 있어야 합니다. 이상적으로 결함은 다른 테스트에서 누락된 부분이어야 합니다(즉 필드에서 보고된 부분). 카탈로그 작성의 한 가지 좋은 방법은 회사의 버그 데이터베이스를 통해 찾아보고 각 결함이 얼마나 일찍 발견되었는지 질문을 던지는 것입니다.


  • 테스트 아이디어를 작성 및 유지보수하는 것은 여가 시간에 수행할 작업이 아닙니다. 다른 중요사항과 마찬가지로 이 타스크에 특별히 할당된 시간이 필요합니다. 활동: 테스트 자산 개선 중에 테스트 아이디어 카탈로그를 작성하고 유지보수하는 것이 좋습니다.