프로그램 테스트(1)

테스트와 소프트웨어 테스트

• 자동차 생산 등에서도 소프트웨어가 차지하는 비중이 늘고 있다.
  • 최근 리콜 차량을 보면 대부분 기계적인 부분보다 소프트웨어 결함인 부분이 많아지고 있다.
• 소프트웨어의 사소한 결함은 큰 사고로 이어진다. → 이 사소한 결함은 테스트를 통해 줄일 수 있다.

---

테스트 필요성과 특징

• 소프트웨어 테스트는 전문가에 따라 다양하게 규정되고 있다. 다음은 소프트웨어 테스트에 대한 몇 가지 정의이다.

  • IEEE : 테스트는 시스템이 명시된 요구를 잘 만족하는지, 즉 예상된 결과와 실제 결과가 어떤 차이를 보이는지 수동이나 자동으로 검사하고 평가하는 작업을 의미한다.
  • 조하 만나(Zoha manna) : 테스트는 시스템의 명세까지 완벽하게 옳다고 확신할 수 없고, 테스트 시스템 그 자체가 맞다고 증명할 수 없기 때문에 프로그램을 완전히 테스트할 수 없다.
  • 달(Dahl), 다익스트라(Dijkstra), 호어(Hoare) : 테스트는 결함이 있음을 보여줄 뿐, 결함이 없음을 증명할 수는 없다.

• 소프트웨어 테스트란?

  • 소프트웨어 내에 존재 하나, 드러나지 않고 숨어 있는 오류를 발견할 목적으로 개발 과정에서 생성되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업
  • 테스트를 하였어도 그 소프트웨어에 오류가 없음을 확인해 주지는 못한다.
  • 목표 : 개발된 소프트웨어에 신뢰성을 높여주는 것
  • 소프트웨어가 완성이 된 이후에 오류를 찾으려면 많은 비용과 인력이 필요함으로 소프트웨어를 사요하기 전에 충분히 테스트를 해야 한다.

소프트웨어 테스트 문제

• 테스트 케이스가 적어 효과에 한계가 있다.

  • 소프트웨어 규모가 커짐에 따라 복잡도도 높아진다. 이에 따라 테스트해야 할 케이스도 많아진다.
  • 그러나 현실적으로 모든 경우의 수만큼 테스트할 케이스를 선정해 사요할 수 없음으로 최소한의 케이스로 테스트 효과를 보는데는 한계가 있다.

• 완벽한 테스트 케이스를 도출하기 어렵다.

  • 개발자들은 산출된 요구분석명세서를 기반으로 설계하고 구현한다. → 요구분석명세서가 정확하다는 가정 아래에 작업
  • 현실적으로 요구분석명세서는 완벽할 수 없다. 몇 가지 기능이 빠져 있을 수도 있으며, 제약 사항이 정확하지 않을 수도 있다.
  • 완벽하지 못한 요구분석명세서를 기반으로 한 테스트 케이스도 완벽하지 못해 테스트하는 데 어려움을 준다.

• 테스트를 위한 실제 사용 환경을 구축하기 어렵다.

  • 개발하며 테스트를 하는 경우도 있지만, 개발이 완료된 후에도 실제 사용 환경에서 문제 없이 잘 작동하는지 테스트해야 한다.
  • 하지만 시스템이 너무 광대하거나 실시간으로 작동하는 매우 중요한 경우에는 사용자 환경에서 테스트 환경을 구축하기가 상당히 어려울 수 있다.
  • 그러므로 사용자 환경과 유사한 테스트 환경을 구축할 수 있는 경험과 기술이 필요

• 작은 실수를 발견하기 어렵다.

  • 사소한 문법 실수도 큰 문제를 야기하는 경우가 있다. 이런 경우 테스트에서도 찾지 못하는 경우가 있다.

• 테스트의 중요성에 대한 인식이 부족하다.

  • 대형 프로젝트의 경우 테스트의 중요성을 인식하고 있기에 요구분석 과정부터 체계적으로 테스트 케이스 도출을 위한 준비를 한다.
  • 하지만, 규모가 작은 프로젝트일수록 테스트보다는 개발에 더 많은 비중을 두어 테스트를 소홀이 하는 경향이 있다.
    • 그 결과, 테스트가 우선순위에서 뒤로 밀림며, 테스트의 중요성에 대한 인식도 미약해지기에, 경험이 부족한 인력을 투입하고, 개발자들이 테스트에 매우 비협조적인 경우가 발생한다.

• 고객의 요구사항을 충족해야 한다.

  • 테스트는 프로그램이 저상적으로 작동하는 것을 보여주는 것 이상으로 프로그램에 잠재된 오류를 찾아내는 활동이다..
  • 품질을 떨어뜨릴 수 있는 요소를 찾아야 한다.

• 테스트 단계에서만 수행되는 단순한 활동이 아니라 개발 단계와 함께한다.

  • V모델처럼 요구사항을 분석하고, 설계하는 단계부터 계획되고 테스트 케이스 도출을 위한 준비를 해야 한다.
  • 단순 구현 단계 이후에 테스트 단계에서만 테스트하는 것이 아닌, 개발 활동과 함께 준비해 이를 토대로 테스트가 이루어져야 한다.

• 파레토 원리를 적용할 수 있다.

  • 20/80의 법칙 이라고도 한다.
  • 다음에..

• 모듈 단위를 점점 확대해 나가며 진행한다.

  • 테스트는 프로그래머가 수행하는 단위 모듈을 시작으로 사용자가 수행하는 확인 과정까지 점점 확대해 간다.

• 완벽한 테스트는 불가능하다.

  • 테스트가 완벽하다고, 그 프로그램에 오류가 없음을 보장하는 것은 아니다.
  • 프로그램 자체의 경로가 너무 많고, 복잡해 모든 경우의 수를 테스트하기 어렵다.
  • 주어진 시간, 목적에 맞게 가장 효율적인 테스트 케이스를 도출해 수행한다.

• 개발자와 다른 별도의 팀에서 수행한다.

  • 프로그램을 개발한 사람이 테스트를 하면 아무리 여러 번 검토해도 숨겨진 오류가 잘 보이지 않을 수 있다.
  • 효율성 면에서도 테스트는 전문가나 전문 팀이 하는 것이 좋다.

• 살충제 패러독스(테스트 내성) 문제 해결을 위해 테스트 케이스 업데이트가 필요하다.

  • 동일한 살충제를 벌레에게 계속 뿌리면, 벌레에 내성이 생겨 살충제의 효과를 더 이상 볼 수 없다는데서 유래
  • 테스트를 할 때에도 동일한 테스트 케이스로 동일한 테스트를 반복하면, 나중에는 더 이상 새로운 오류를 찾지 못한다.
  • 테스트케이스를 정기적으로 검토하고 지속적으로 개선하며, 다른 시각을 통해 테스트 케이스를 업데이트 해야 한다.

• 오류

  • 소프트웨어 개발자에 의해 생기는 실수로 결함의 원인이 된다.

• 결함

  • 오류로 인하여 프로그램이 완전치 못한 것으로 고장의 원인이 된다.
  • 주로 프로그램에 필요 없는 정보를 포함하거나 필요한 정보가 없는 경우이다.

• 고장, 실패, 문제, 장애

  • 시스템이 요구사항대로 작동하지 않는 것을 말한다.
  • 요구분석명세서가 잘못되었거나, 이 명세서에 요구사항이 충분히 반영되지 않은 경우
  • 기술적으로 불가능한 요구사항이 포함된 경우
  • 하지만 모든 결함이 반드시 실패를 부르지는 않는다.