Test Case

테스트케이스 사양서에 대해 국제 표준규격을 정하는 IEEE Standard 829-1983에서는 다음과 같이 정의하고 있습니다.

“A test case specification documents the actual values used for input along with the anticipated outputs.”
즉, 예상되는 사용자의 사용 패턴에서 필요한 테스트 요건과 순서, 구체적인 방법 등을 문장화한 것입니다.
“이러한 입력을 해서 이러한 결과가 출력되면 그 SW는 올바르게 동작하고 있다”라는 것을 기록으로 남기고 다른 담당자와 개발자 등이 확인할 수 있도록 해 두는 것이라 할 수 있습니다.

📌 테스트케이스가 필요한 이유

테스트케이스를 작성하는 목적은 크게 두 가지입니다.

“테스트 누락 방지”와 “테스트 투명화”

SW는 사용자에 따라 상상을 뛰어넘는 여러가지 사용 패턴과 입력 방법이 존재할 것이라는 것을 예상할 수 있습니다.
테스트 담당자 개인의 판단으로 테스트 내용을 정해버리면 테스트 항목의 누락이 발생하기 쉽고 이것은 중대 결함 발생의 요인이 됩니다.
또한 릴리즈 후에 결함이 발견된 경우 개발 공정에서 어떤 테스트를 실시했는지 파악되지 않으면 다시 처음부터 발생 원인으로 예상되는 지점의 테스트를 반복해 실시해야 하므로 일정 지연과 프로젝트 비용 증가가 발생하게 됩니다.
효율적인 테스트를 실행하기 위해서는 제3자가 보아도 알 수 있는 투명한 상태의 테스트케이스를 남겨줄 필요가 있습니다.

📌 Bad Testcase

불필요한 테스트 패턴이 많은 테스트케이스

누락 없는 테스트케이스를 지향하기 위해 모든 테스트 항목을 망라하여 작성한 결과 테스트케이스를 너무 방대하게 만들어 일어나는 사태입니다.
시스템과 SW의 모든 동작에 대한 조합을 테스트하려고 하면 경우에 따라서는 천문학적인 조합 수가 만들어지게 됩니다.
물론 품질 향상을 위해 테스트 항목을 누락없이 만드는 것도 중요한 요소이지만 개발 공정 상 테스트에 부여된 시간은 한정되어 있기 때문에 불필요한 항목은 테스트케이스에서 빼는 결단도 필요합니다.

이상 상태 테스트케이스 부족

실제로 시스템과 SW를 사용하는 사용자 관점에서 작성하지 않으면 생각치 못한 결함이 발생할 수 밖에 없습니다.
테스트케이스를 작성할 때에는 개발자 관점에서 사용자 관점으로 변환하여 작성하는 것이 중요합니다.

애매모호한 표현

테스트케이스의 표현이 명확하지 않으면 테스트 담당자는 매우 괴로워집니다.
만약 테스트케이스 작성자가 아닌 제3의 담당자가 “여긴 어떻게 테스트하는 거예요?”라고 물어오는 경우라면 시간 손실만으로 끝나는 문제이지만, “음..여긴 대충 이렇게 하라는 소리겠지”라고 판단해서 잘못 테스트를 하면 올바른 결과를 얻지 못할 수도 있습니다.🙅

📢 효율적인 테스트케이스 작성 포인트
일반적으로 하나의 SW에 잠재되어 있는 모든 결함을 100이라고 했을 때 75가 발견되면 그 테스트는 성공적이다라고 할 수 있습니다. 한정된 시간 내에 모든 결함을 발견하는 일은 불가능하기 때문에 테스트케이스 작성에 있어 효율적으로 결함을 발견하기 위한 작성을 할 필요가 있습니다.

그 중 하나의 방법이 바로 “결함 분석”입니다. “80%의 결함은 20%의 코드에서 나온다”라는 말처럼 결함은 일정한 규칙성이 있는 경우가 존재합니다. 따라서 발견한 결함의 규칙성을 바탕으로 추측하여 테스트케이스를 작성하는 것이 중요한 포인트입니다.
또한, 테스트를 효율적으로 진행하기 위해서는 편리한 툴을 이용하는 것도 하나의 방법입니다.
관리 시스템 중에 Redmine과 Jira와 같은 BTS(Bug tracking system)으로도 활용 가능한 툴이 있습니다. 이러한 툴을 이용하면 프로젝트 관리는 물론 결함 추적도 매우 편리해져 프로젝트 공정을 단축할 수 있습니다.

📌 Testcase 작성 방법

• 핵심적인 제목을 사용한다.
  테스트 케이스 작성방법 중 가장 중요한 부분은 핵심적인 제목으로 선정하는 것입니다.
  좋은 사례로는, 테스트하는 모듈을 테스트 케이스 이름을 기입합니다. 예를 들어 만약 Login Page를 테스트하고 있다면 테스트 케이스 제목에 “Login Page”를 포함시킵니다.

• 핵심적인 설명을 포함한다.
  설명은 테스터가 무엇을 테스트해야 하는지와 다른 관련된 정보를 말해줘야 합니다.
  테스트 환경, 테스트 데이터 그리고 사전 조건 등과 같은 정보가 포함되어야 합니다.

• 사전 조건을 포함한다.
  테스트가 진행되기 전에 충족되어야 하는 테스트와 사전 조건에 적용되는 어떤 상황들을 포함해야 합니다.
  이 정보는 사용자가 어떤 상황에서 테스트를 시작하는지, 테스트 환경에 의존되는 정도 그리고 테스트가 진행되기 전에 특별히 설정해야 할 요구 사항들 등이 포함될 수 있습니다.
  사전 조건은 테스트 스텝을 간결하게 할 수 있도록 해줍니다.

• 테스트 절차를 명확하고 간결하게 유지한다.
  테스트 절차는 테스트를 실행하는 데이터와 정보가 포함되어야 합니다.
  절차는 테스트 케이스에서 가장 중요한 부분입니다. 이부분을 명확하고 간결하게 유지하되 필수 세부사항을 빼지 말아야합니다.

• 기대 결과를 포함한다.
  기대 결과는 테스트 절차의 결과로 예상되는 동작을 말해야 합니다.
  테스터가 테스트 케이스가 ‘PASS’인지 ‘FAIL’인지 판단합니다.

• 재사용 용이성
  좋은 테스트 케이스는 재사용이 가능하고 소프트웨어 테스트 팀에게 장기적인 활용도를 제공합니다.
  테스트 케이스를 작성할 때 이점을 유의해야 합니다. 테스트 케이스를 다시 작성하는 대신 재사용 하는 것으로 차후에 시간을 절약할 것입니다.

📌 Example

• 제목 : 로그인 페이지
• 설명 : 등록된 사용자만 사이트에 접속 가능함
• 사전 조건
  1. 사용자는 아이디와 패스워드를 등록되어 있어야 함.
  2. 지원되는 브라우저를 사용해야 함.
• 테스트 절차
  1. 사이트에 접속
  2. 아이디 입력란에 등록된 사용자 아이디 입력
  3. 패스워드 입력란에 등록된 사용자 패스워드 입력
  4. 로그인 버튼 선택
• 기대 결과 : 사용자 로그인 정보가 출력되고 사용자 이메일 내역이 로딩되고 표시됨.

📌 코드 커버리지 ( Test Coverage )

코드 커버리지란 소프트웨어의 테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표중 하나입니다.

커버리지 측정을 위한 예시 코드

if(a and b):
    print('1')
else: print('2')

해당코드로 다양한 커버리지를 측정하면 다음과 같습니다.

구문 커버리지

구문 커버리지는 모든 구문(코드라인)이 한번 이상 수행되면 됩니다.
여기서는 조건문이 있으므로 a and b 전체 조건에 따라 T한번 F한번을 만족해야 합니다.

• if문이 참인 경우 1,2번 라인 구문을 커버합니다.
• if문이 거짓인 경우 1,3번 라인 구문을 커버합니다.
  
  python coverage 를 사용한 커버리지 특정 시 위의 경우 각 라인별로 총 3개의 구문으로 판단하며,
• A=1, B=1만 테스트 했을 때 3개구문중에 2개를 커버했으므로 66% 로 표시됩니다.
• A=1, B=0만 테스트 했을 때 3개구문중에 2개를 커버했으므로 66%로 표시됩니다.

결정 커버리지

• 전체 조건이 T, F 만 나오게 만들면 됩니다.
• 단점 : 개별 조건식에 오류가 있는 경우 찾지 못할 수 있습니다.

조건 커버리지

• 개별조건식이 각각 T, F 만 나오게 만들면 됩니다.
• 개별조건식의 T/F는 커버되었지만 전체 조건식의 T/F를 보장하지 못합니다.

조건/결정 커버리지

전체 조건식 T/F, 개별조건식 T/F를 모두 나오게 만들면 됩니다.

변형 조건/결정 커버리지(MC/DC)

• 모든 결정 포인트 내의 전체 조건식은 적어도 한번 T, F를 가져야 합니다.
• 결정 포인트 내의 개별 조건식은 적어도 한번 T, F를 가져야 합니다.
• 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주어야 합니다.
• 이론적으로 가장 안전한 조합이며 케이스도 줄일 수 있으나 수동으로 적용하기엔 리소스 많이 소모됩니다.
• 수동으로 하면 실수 가능성이 많습니다!

다중 조건 커버리지

• 모든 개별 조건식의 논리적 조합을 고려하면 됩니다. (여기서는 a and b 의 모든 조합)

📌 정리

• SC : 구문 커버리지 (Statement Coverage)
• DC : 결정 커버리지 (Decision Coverage)
• CC : 조건 커버리지 (Condition Coverage)
• C/DC : 조건/결정 커버리지 (Condition / Decision Coverage)
• MC/DC : 변경 조건/결정 커버리지 (Modified Condition/Decision Coverage)
• MCC : 다중 조건 커버리지 (Multiple Condition Coverage)