[CSTS] PART 01. 테스트 개요

1장 테스트 개요

1.1 테스트 목적

테스트 : 시스템이 정해진 요구사항을 만족하는지 확인하고, 주어진 표준 등을 준수하는지 검증하기 위하여 수행됨

• 결함 검출과 제품 품질 개선 : 테스트는 결함을 검출하기 위한 목적으로 수행, 검출된 결함을 제거함으로써 소프트웨어의 품질을 개선하는 것이 목표
• 품질 평가와 의사 결정 지원 : 다양한 소프트웨어 품질 특성에 대한 충족 수준을 평가, 품질 평가 결과를 바탕으로 소프트웨어 제품에 대한 의사 결정을 수행할 수 있음
• 개발 프로세스 개선 지원 : 소프트웨어 개발 과정 중 어떤 단계에서 결함이 발생하는지 분석하고, 그 결함이 왜 검출되지 않았는지 파악함으로써 개발 프로세스 개선을 도울 수 있음

테스트 스크립트 : 가장 상세한 방식의 테스팅 문서화, 하나의 테스트를 수행하는데 필요한 모든 액션과 데이터를 한라인씩 기술한 것

테스트 케이스 : 두번째로 가장 상세한 방식의 테스팅 문서화, 입력 + 사전 조건 -> 사후 조건 + 예상 출력

테스트 시나리오 : 가장 상세하지 않은 타입의 문서화, 테스트가 필요한 상황

 

1.2 오류, 결함, 장애

장애(Failure) : 소프트웨어가 요구사항과 다르게 동작함. 즉, 프로그램의 실행 결과와 요구사항에 명시된 결과에 차이가 있음을 의미

결함(Defect) : 소프트웨어 내에 장애를 유발할 수 있는 문제, 결함이 있다고 해서 반드시 장애가 발생하는 것은 아님

오류(Error) : 결함의 원인으로 사람에 의해 생성된 실수, 사용자의 요구사항을 잘못 파악 및 이해하여 발생하는 실수, 오타, 잘못된 코딩 등등

 

결함 유형

• 누락 : 요구 명세에 명시된 요구사항이 시스템의 구현에 반영되지 않은 결함
• 부정확한 구현 : 요구 명세에 명시된 요구사항이 소프트웨어에 부정확하게 반영된 결함
• 비관련 결함 : 요구 명세와 관련되지 않은 구현, 비관련 결함은 당장 직접적인 장애를 유발하지 않을 수 있지만 무의미한 코드가 존재한다면 다른 결함을 초래하는 원인이 될 수 있음

결함 해결 비용

• 요구분석 < 설계 < 코딩 < 단위 테스팅 < 인수 테스팅 < 유지보수
• 결함이 발생한 시점에 제거되지 않고 이후 개발 단계에 전달되면 이 결함을 제거하기 위해 더 많은 비용이 소요됨
• 결함 해결 비용을 최소화하기 위해서는 각 개발 단계의 결과물을 테스트하여 해당 산출물에 존재하는 결함을 최대한 빨리 검출하고 제거해야 함

테스팅 : 소프트웨어의 실제 동작과 요구사항의 차이를 확인

디버깅 : 테스팅을 통하여 결함의 존재를 확인한 후에 수행됨, 결함의 위치를 파악하고 이를 제거하는 것을 목적으로 함

재테스팅 : 개발자가 결함을 제거하기 위해 코드를 수정하고 나면 실제로 결함이 제거되었는지 확인 해야 함. 이를 위해 초기에 결함을 검출한 테스트 케이스를 이용하여 테스팅을 다시 수행

 

1.3 테스트의 현실/실제

완벽한 테스트는 불가능함. 소프트웨어의 무한 입력값, 실행 시점의 무한 타이핑, 소프트웨어 코드 내 무한 경로 등을 모두 고려해 테스트할 수 없기 때문

다익스트라 "프로그램 테스트는 결함이 있음을 보일 수는 있지만, 결함이 없음을 보일 수는 없다."

 

테스트 원칙

1. 테스트는 반드시 프로그램을 개발한 프로그래머나 팀과는 무관한 그룹이 수행해야 한다.
   
   • 자신이 작성한 프로그램에 대해서는 방어적 경향을 띔.
   • 요구사항을 제대로 해석하지 못했을 가능성도 있어 철저한 테스트에도 결함을 발견하지 못할 수 있음
2. 결함이 발견되지 않으리라는 가정하에 테스트 계획을 수립해서는 안된다.
   • 테스트는 프로그램이 올바르게 동작함을 보여주는 작업 X, 결함을 발견하려는 의도
3. 타당한 경우뿐만 아니라 타당하지 않고 예상하지 못한 경우에 대해서도 테스트를 수행하라.
4. 프로그램의 어떤 부분에 결함이 남아있을 확률은 그 부분에서 이미 발견된 결함의 수에 비례한다.
   • 파레토 원칙 "프로그램 결함의 80%는 20%의 모듈에서 발생한다."
5. 테스트 케이스를 체계적으로 관리하라.
   • 프로그램 수정시 다시 테스트 해야함. 이때 전부 새로 만들기보단 기존에 만들었던 테스트 케이스를 재사용하는 것이 바람직
6. 각각의 테스트 결과를 철저하게 점검하라.

 

1.4 테스트와 품질

테스트 < V&V < 품질 보증

• 테스트 : 시스템이 정해진 요구사항을 만족하는지 확인하고, 주어진 표준 등을 준수하는지 검증하기 위하여 수행됨
• V&V : Verification(검증)과 Validation(확인)의 약어
  • 검증 : 소프트웨어 개발 과정에서 수행한 활동의 적합성 검사에 초점
  • 확인 : 결과물의 적합성에 초점
• 품질 보증 : 의도한 목적에 적합한 품질의 소프트웨어 제품을 개발하였는지, 그러한 소프트웨어 프로세스가 적합한지에 대한 확신을 주기 위하여 수행되는 다양한 활동

 

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

레벨1 (Debugging oriented)

• 테스트와 디버깅의 차이가 없다.
• 즉, 우연히 발견된 오류를 수정하는 디버깅에 중점을 두며, 프로그램의 오류를 찾기위한 별도의 노력을 기울이지 않음
• 테스트를 안하는 조직

레벨2 (Demonstration oriented)

• 프로그램이 올바르게 동작한다는 사실을 입증하기 위해 테스트를 수행
• 단순히 동작기능만 테스트하는 조직

레벨3 (Destruction oriented)

• 프로그램에 결함이 존재함을 보여주기 위해 테스트를 수행
• 결함을 발견하기 위한 의지를 가지고 테스트

레벨4 (Evaluation oriented)

• 소프트웨어 개발 후에 결함을 찾는 것이 아닌, 개발 전 단계에 발생하는 결함을 발견하는 개념으로 확장
• 초기 단계 부터 테스트를 수행

레벨5 (Prevertion oriented)

• 프로그램의 오류를 사후에 발견하는 것이 아닌, 아예 결함이 발생하지 않도록 사전에 방지하는 개념
• 프로그램을 개발할 때 처음부터 테스트가 용이하게 시스템을 설계
• 테스트 용이성을 고려하여 프로그램을 설계
• 이상적인 조직

 

---

 

2장 테스트 분류와 테스팅 방법

2.2 테스트 분류

테스트 레벨

• 컴포넌트 테스트 : 시스템을 구성하는 단위 모듈을 테스트 대상, 개별 단위 모듈을 독립적으로 테스트
• 통합 테스트 : 시스템을 구성하는 단위 모듈들이 정확하게 통합되었는지 초점
• 시스템 테스트 : 전체 시스템을 테스트 대상, 요구사항 명세서에 명시된 방식대로 시스템이 동작하는지 확인하는 데 초점
• 인수 테스트 :   전체 시스템을 테스트 대상, 시스템 테스트와는 달리 고객/사용자의 관점에서 고객이 기대하는 방식으로 소프트웨어가 동작하는지 확인

테스트 유형

• 기능 테스트 : 기능 요구사항 측면의 결함 검출 및 충족 여부 확인을 목적, 모든 테스트 레벨에서 진행
• 비기능 테스트 : 성능, 보안성, 신뢰성 등 품질 요구사항 측면의 결함 검출 및 충족 여부 확인 목적, 일반적으로 시스템 테스트와 인수 테스트 레벨에서 진행됨

테스트 설계 기법

• 정적 테스트 : 테스트 대상을 실행하지 않는 방식으로 테스트
  1. 리뷰 : 소프트웨어의 다양한 산출물에 존재하는 결함을 검출하거나 프로젝트의 진행 상황을 점검하기 위한 활동
     • 리뷰 순서 : 경영진 준비 -> 리뷰 계획 -> 리뷰 절차 개요 설명 -> 작업물 개요 설명 -> 개별 준비 -> 그룹 검토 -> 재작업 -> 후속 작업
     • 리뷰 유형 : 관리 리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사
  2. 정적 분석 : 산출물(주로 소스 코드)의 구조적 속성을 이용하여 자동화된 방식으로 도구에 의해 수행
     • 정적 분석 유형 : 코딩 표준, 복잡도 측정, 자료 흐름 분석
• 동적 테스트 : 테스트 대상을 실행하여 결함을 검출하는 방법
  1. 명세 기반 테스트 : 소스 코드를 참고하지 않고 테스트 케이스를 결정
  2. 구조 기반 테스트 : 구현된 소스 코드를 참고해서 테스트 케이스를 결정
  3. 경험 기반 테스트 : 기존의 테스트 경험, 테스트 대상이 되는 시스템 및 해당 도메인에 대한 경험 등을 바탕으로 수행하는 테스트 방법
     • 오류 추정 : 테스터의 경험과 직관을 바탕으로 개발자가 범할 수 있는 실수들을 나열하고, 해당 실수에 따른 결함을 노출하는 테스트를 수행하는 것
     • 탐색적 테스트 : 사전에 구체적으로 테스트 케이스를 설계 X 테스트 대상에 대한 이해를 바탕으로 즉석에서 테스트 케이스를 결정한 후, 문서화 없이 해당 테스트를 바로 수행, 테스터의 지식에 의존, 애자일 방법에 유용

2.3 대표적인 테스팅 방법

• 리그레션 테스트
  • 변경 후에 수행되는 테스트로, 소프트웨어에 가해진 변경이 의도하지 않게 겨함을 만들지는 않았는지, 시스템이 기존 요구사항을 충족하는지 검증하기 위해 수행됨
  • 다양한 테스트 전략 존재. Retest-all 전략, 선택적 리그레션 테스트 전략, 테스트 최소화 전략, 테스트 우선순위화 전략
  • 소프트웨어가 변경되면 각 레벨 테스트 순서대로(컴포넌트, 통합, 시스템, 인수) 각 레벨마다 리그레션 테스트 수행
• 소프트웨어 생명 주기 모델과 테스트
• 위험 기반 테스트 : 피처에 대한 위험 분석을 바탕으로 테스트에 대한 계획과 설계 그리고 실행 등의 활동을 수행하는 것
• 모델 기반 테스트 : 테스트 절차를 수행할 수 있는 정보가 자동으로 추출될 수 있을 정도로 정형화되고 상세한 모델을 바탕으로 함. 모델을 바탕으로 테스트 계획을 수립하고, 테스트 케이스, 테스트 절차, 테스트 입력 및 예상 결과 등을 결정
  • 테스트 계획에서 종료까지 대부분의 활동을 자동화 할 수 있음
  • 다양한 유형의 문제를 이른 시점에 식별하는 방법으로 개발 단계 산출물의 결함을 검출할 수 있음
  • 안전 필수 소프트웨어를 대상으로 수행됨
  • 의사결정표, UML 상태 다이어그램, UML 액티비티 다이어그램을 비롯한 정형적 표현법 사용

 

---

 

3장 소프트웨어 개발 단계와 테스트

3.2 컴포넌트 테스트

개별적인 모듈의 테스트, 구현 단계에서 각 모듈을 구현한 후에 수행

 

컴포넌트 테스트를 잘 수행하기 위한 FIRST 원칙

• Fast : 컴포넌트 테스트는 빠르게 수행되어야 함
• Isolated : 컴포넌트 테스트가 다른 컴포넌트 테스트에 의존하지 않도록 해야 함
• Repeatable : 테스트를 몇 번 실행해도 동일한 결과가 나오도록 해야 함
• Self-Validating : 사람의 개입 없이 테스트가 통과되었는지 알 수 있도록 작성해야 함
• Timely : 컴포넌트 테스트는 제때 수행되어야 함

 

3.3 통합 테스트

컴포넌트를 통합하는 과정에서 수행되는 테스트, 컴포넌트 간의 상호 연동이 제대로 수행되는지 검사하는 테스트

 

빅뱅 방식 : 통합 대상 컴포넌트가 많은 경우, 전체 컴포넌트를 한 번에 통합하여 테스트하는 방법

➡️ 빅뱅 방식의 통합 테스트는 한 번에 많은 수의 컴포넌트가 통합되므로 테스트를 통해서 어떤 컴포넌트가 결함을 가지고 있는지 판단하기 어려움

 

점진적 방식 : 적은 수의 컴포넌트를 차례로 통합하는 방식, 결함이 있는 컴포넌트를 찾기 쉬운 반면 테스트 드라이버 및 스텁을 여러 번 개발해야 함

• 상향식 통합 방식 : 호출 관계의 하위에 있는 컴포넌트들을 시작으로 해서 상위에 있는 컴포넌트를 통합
  
  • 특별한 기능을 제공하는 하위의 컴포넌트를 식별하여 그룹화 및 클러스터링한 후에 테스트 드라이버를 작성하여 테스트를 수행
  • 하위 컴포넌트를 충분하게 테스트 할 수 있는 장점
  • 하향식 통합에서 필요한 테스트 스텁을 제공하는 비용이 들지 않는다는 장점
• 하향식 통합 방식 : 시스템을 구성하는 컴포넌트들의 계층 구조에서 가장 상위에 있는 컴포넌트부터 시작하여 하위에 있는 컴포넌트를 점진적으로 통합
  • 가장 상위에 있는 컴포넌트를 테스트하기 위해 하위 컴포넌트를 테스트 스텁으로 대치한 후 테스트를 수행
  • 깊이 우선 방식이나 너비 우선 방식을 사용하여 테스트 스텁을 한 번에 하나씩 실제 컴포넌트로 대체하고, 대치된 컴포넌트가 실제 호출하는 하위 컴포넌트를 테스트 스텁으로 대치
  • 테스트 스텁이 실제 모듈로 대치되어 시스템에 변경이 발생하였으므로 리그레션 테스팅을 수행
  • 상위 컴포넌트의 결함을 빠르게 발견 할 수 있다는 장점
  • 많은 수의 테스트 스텁 필요, 만약 테스트 스텁 구현 비용이 많이 드는 경우라면 효과적인 방법은 X
• 샌드위치 통합 방식 : 상향식 + 하향식 방법 결합하여 시스템을 통합

 

3.4 시스템 테스트 및 인수 테스트

시스템 테스트 : 통합 테스트가 완료된 후에 전체 시스템이 시스템 명세에 따라 개발되었는지 검증하기 위해 수행하는 테스트, 시스템의 기능 뿐만 아니라 비기능적인 요구사항도 만족하는지 검증

 

인수 테스트 : 시스템 테스트가 완료되면 실제 사용자의 요구사항을 만족하는지 확인하기 위한 테스트, 결함 검출이 아니라 시스템을 인수해도 되는지 고객의 입장에서 평가하는 것

• 알파 테스트 : 선택된 사용자가 개발자 환경에서 통제된 상태로 수행
• 베타 테스트 : 일정 수의 사용자에게 소프트웨어를 사용하게 하고 피드백을 받음(개발자 참여 X)

 

3.5 리그레션 테스트

유지보수 단계에서도 소프트웨어가 수정된 후에 변경이 올바르게 되었는지 검사하기 위하여 리그레션 테스트 수행

 

수정이 이루어지는 이유

• 결함 수정 작업
• 기능 보강 작업
• 적응 작업
• 예방 작업

 

리그레션 테스트 방법

• Retest-All 방식 : 기존에 개발된 모든 테스트 케이스를 사용하는 방식, 복잡한 테스트 절차를 요구하지 않지만 많은 시간과 자원이 필요
• 선택적 리그레션 테스트 방식 : 기존의 테스트 케이스 중 일부만 선정하는 방식
• 테스트 최소화 방식 : 중복된 테스트 케이스를 제거하여 테스트 케이스의 수를 줄이는 방식
• 테스트 우선 순위화 방식 : 테스트 케이스에 우선순위를 두어 우선순위가 높은 테스트 케이스만을 활용하는 방식
  • APFD : 테스트 케이스 우선순위의 효과성을 평가하기 위한 척도
  • 테스트 케이스의 실행 수 대비 검출된 결함의 비율 측정
  • 높은 APFD -> 많은 결함을 빨리 검출하였다는 의미
  • 가능한 높은 APFD를 갖도록 테스트 케이스에 우선순위 등급을 부여하는 것
  • 리그레션 테스트에 소요되는 시간과 비용이 제한된 상황이라면, 가능한 한 결함 검출을 빠르게 할 수 있는 테스트 케이스의 우선순위를 높게 설정하여 테스트의 효용성을 높일 수 있음

 

---

 

4장 품질 특성과 비기능 테스트

주특성	부특성	설명
기능 적합성	기능 완전성	사용자가 요구하는 기능을 얼마나 제공하는지 정도
	기능 정확성	사용자가 기대하는 수준으로 얼마나 정확하게 동작하는 정도
	기능 적절성	사용자의 사용 목적 달성에 도움을 주는 정도
성능 효율성	시간 반응성	시스템의 응답/처리 및 처리율이 요구사항을 충족시키는 정도
	자원 효율성	시스템이 사용하는 자원이 요구사항을 충족시키는 정도
	수용성	시스템 매개 변수의 최대 한계가 요구사항을 충족시키는 정도
호환성	공존성	다른 소프트웨어와 환경 및 자원을 공유하면서 요구된 기능을 효율적으로 수행하는 정도
	상호운영성	여러 시스템이 정보를 교환하거나 교환된 정보를 성공적으로 사용할 수 있는 정도
사용성	적합 인식성	사용자가 자신의 필요에 시스템이 적합한지를 인식할 수 있는 정도
	학습 용이성	사용자가 소프트웨어 사용법을 배워 명시된 목적을 달성할 수 있는 정도
	운영 용이성	시스템이 쉽게 조작하고 제어할 수 있는 속성을 갖는 정도
	사용자 오류 방지성	시스템이 사용자로 하여금 오류를 범하지 않게 하는 정도
	사용자 인터페이스 심미성	사용자 인터페이스가 사용자에게 만족스러움을 주는 정도
	접근성	사용자의 특성이나 능력에 관계없이 시스템을 사용할 수 있는 정도
신뢰성	성숙성	시스템이 정상 작동 상태에서 신뢰성 요구를 충족시키는 정도
	가용성	시스템을 사용하고자 할 때 사용 및 접근에 가능한 정도
	결함 허용성	결함이 있는데도 시스템이 의도한 대로 작동하는 정도
	복구성	중단 또는 장애가 발생한 경우 시스템이 영향 받은 데이터를 복구하고 상태를 재설정할 수 있는 정도
보안성	기밀성	접근 권한이 있는 사람에게만 데이터에 엑세스 할 수 있도록 하는 정도
	무결성	무단으로 접근 또는 변경되는 것을 방지하는 정도
	부인 방지성	사건 및 행위 후에 부인하지 못하도록 행동 및 사건에 관해 입증할 수 있는 정도
	책임성	각 개인을 유일하게 식별하여 행위를 기록하고 필요시 그 행위자를 추적할 수 있는 능력
	인증성	사건 및 행동에 관해 실제 행위자임을 증명할 수 있는 정도
유지보수성	모듈성	하나의 변경이 다른 요소에 미치는 영향이 최소화되도록 시스템이 개별 구성요소로 구성된 정도
	재사용성	시스템 자산이 하나 이상의 시스템에서 사용될 수 있는 정도. 또는 다른 자산을 구축할 수 있는 정도
	분석성	부분에 의도된 변경이 전체 시스템에 미치는 영향을 평가하거나 결함 또는 결함 원인에 대해 제품을 진단하거나 수정될 부분을 식별할 수 있는 정도
	변경 용이성	결함이나 품질 저하 없이 효과적이고 효율적으로 수정 될 수 있는 정도
	테스트 용이성	테스트 수행을 용이하게 하는 정도
이식성	적응성	시스템이 다른 하드웨어, 소프트웨어 혹은 기타 사용 환경에 효과적이고 효율적으로 적용될 수 있는 정도
	설치 용이성	특정 환경에서 시스템을 성공적으로 설치 및 제거할 수 있는 정도
	대체 용이성	시스템이 동일한 환경에서 동일한 목적을 위해 다른 지정된 소프트웨어 제품으로 대체될 수 있는 정도

 

4.2 기능 적합성 테스트 (기능 완전성, 기능 정확성, 기능 적절성)

사용자의 요구사항을 시스템이 얼마나 만족하는지에 대한 정보를 제공

• 기능 완전성 : 사용자가 요구하는 기능을 얼마나 제공하는지를 보는 것
• 기능 정확성 : 사용자가 기대하는 수줁ㅇ느로 얼마나 정확하게 동작하는지를 의미
• 기능 적절성 : 사용자의 사용 목적을 달성하는 데 도움을 주는 정도

 

4.3 성능 효율성 테스트 (시간 반응성, 자원 효율성, 수용성)

명시된 조건하에서 사용된 자원의 양에 대한 성능의 정도

 

성능 테스팅 종류

• 부하 테스팅 : 부하를 계속 증가시키면서 시스템의 임계점을 찾음, 이 테스팅을 통해 병목 지점을 찾고 병목 현상을 제거하는 과정을 반복
• 스트레스 테스팅 : 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트
• 스파이크 테스팅 : 짧은 시간에 사용자가 몰릴 때 시스템의 반응을 측정
• 내구성 테스팅 : 오랜 시간 동안 시스템에 높은 부하를 가하여 시스템의 반응을 파악

 

4.4 호환성 테스트 (공존성, 상호운영성)

제품, 시스템 또는 구성 요소가 다른 제품, 시스템 또는 구성 요소와 정보를 교환하거나 필요한 하드웨어 또는 소프트웨어 환경을 공유하면서 필요한 기능을 수행할 수 있는 정도

• 공존성 : 다른 소프트웨어와 환경 및 자원을 공유하면서 요구된 기능을 효율적으로 수행하는 정도
• 상호운영성 : 여러 시스템이 정보를 교환하거나 교환된 정보를 성공적으로 사용할 수 있는 정도

 

4.5 사용성 테스트 (적합 인식성, 학습 용이성, 운영 용이성, 사용자 오류 방지성, 사용자 인터페이스 심미성, 접근성)

주어진 사용 환경에서 특정한 목적을 달성하기 위해 제품이나 시스템을 사용할 때 효율성, 효과성 및 만족도 대한 정도

 

사용성 평가를 위한 다양한 방법

• 휴리스틱 평가 : 제품과 관련된 사용성 원칙을 기준으로 체크리스트를 통해 사용성에 관한 문제점을 도출하는 방법
• FGI : 그룹 인터뷰 방법, 개발 이전에 사용자의 요구사항을 파악하는 데 많이 사용, 시스템이나 문제점 등에 관해 의견을 나누고 필요한 정보를 수집
• 인지적 워크쓰루 : 학습 용이성 분석에 중점, 실제 사용자에게 사전 설명 또는 안내 없이 제품을 사용하여 주어진 과제를 달성하도록 함, 각 단계에서 적합한 행동을 취하는지 분석

 

4.6 신뢰성 테스트 (성숙성, 가용성, 결함 허용성, 복구성)

특정 조건에서 특정 기간 동안 시스템이 요구되는 서비스를 오동작 없이 제공하는 정도

 

4.7 보안성 테스트 (기밀성, 무결성, 부인 방지성, 책임성, 인증성)

시스템이 정보 및데이터를 보호하는 정도

 

보안성 검증

• 침임 테스트 : 침입자 관점에서 소프트웨어 시스템의 취약성을 찾는 테스트 방법
• 정적 분석 : 보안성 높은 소프트웨어가 준수해야 할 소스 코드 수준에서 코딩 규칙을 정의하고, 코딩 규칙을 준수하는지를 정적 분석 도구로 검사

 

4.8 유지보수성 테스트 (모듈성, 분석성, 재사용성, 변경 용이성, 테스트 용이성)

시스템이 변경 요구를 만족시키는 능력

 

테스트 용이성 : 프로그램을 얼마나 손쉽게 테스트할 수 있는지를 나타내는 특성

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

 

4.9 이식성 테스트 (적응성, 설치 용이성, 대체 용이성)

서비스 이용자 단말기의 하드웨어 및 소프트웨어 환경이 달라도 동등한 서비스를 제공하는지 테스트하는 것

 

---

 

5장 위험 기반테스트

5.2 위험 분석

위험 요소 식별 : 테스트가 필요한 피처들을 모두 나열, 나열된 피처는 위험 분석의 대상이 되며 위험 분석 결과에 따라서 테스트 계획이 수립됨

위험도 산정 : 도출된 각 피처 후보 중 무엇을 테스트 대상에 포함할 것인지에 관한 결정과 효과적인 테스트 전략의 결정을 위하여 위험도 산정을 해야함

• 발생 가능성 : 해당 피처와 관련된 장애가 실행 시에 발생할 가능성을 의미
  • 기술적인 복잡성 : 구현 자체에 복잡성이 많다면 장애 발생 가능성도 높음
  • 해당 피처와 관련된 결함이 소프트웨어 개발 공정에서 검출되어 제거될 수 있는지 고려할 필요가 있음
  • 사용자가 해당 기능을 사용하는 빈도도 장애 발생 가능성에 영향을 줌
• 심각성 : 피처에 기술된 시스템의 기능 및 비기능적 요소가 기대한 대로 동작하지 않을 때 사용자에게 미치는 영향의 정도
• 긴급성 : 해당 피처와 관련된 장애가 발생하였을 때 얼마나 시급한 수정이 필요한가를 나타냄

 

5.3 위험 기반 테스트 수행

산정된 위험도 값을 바탕으로 수행할 테스트의 강도를 결정함, 위험 수준을 바탕으로 해당 피처의 테스트에 투입할 자원과 비용 등을 결정

위험도에 따른 테스트 강도

• 고강도 테스트 : 매우 높은 위험도, 즉각적인 수정이 요구되는 결함에 해당되는 피처는 가능한 한 많은 자원을 사용하여 높은 강도로 테스트를 수행
• 균형적 테스트 : 프로젝트의 주어진 예산과 일정을 고려하여 효과적이고 효율적인 테스트를 수행하는데 초점
• 부가적 테스트 : 수행되는 테스트 활동에 일부 추가적인 작업 - 일부 테스트 케이스의 추가, 일부 테스트 데이터의 추가 등 - 을 수행하여 검출을 시도
• 결함 보고 : 테스트 범위에 포함시키지 않음

 

---

 

6장 소프트웨어 생명 주기 모델과 테스트

6.1 순차적 개발 모델

요구사항이 개발 초기에 완전하게 정의되어 있을 때 적합

 

폭포수 모델

• 가장 오래된 전통적인 모형
• 소프트웨어 개발 전 과정을 체계적이고 순차적으로 접근
• 사용자의 요구사항이 개발자에게 익숙한 경우, 요구사항 변경이 개발 도중에 빈번하게 이루어지지 않는 경우에 적합
• 테스트 작업을 코딩 단계 후의 한 단계로만 취급

V-모델

• 테스트를 개발과 동등하게 취급한 모델
• 생명 주기를 크게 개발에 관련된 단계들과 테스트에 관련된 단계들로 명확하게 구분
• 테스트 활동은 개발이 시작됨과 동시에 시작

 

 

6.2 진화적 개발 모델

불확실한 요구사항 또는 요구사항 변경이 빈번하게 발생하는 경우에 적합

사이클마다 리스크 분석이 수행되므로 발생하는 문제점을 해결할 방안을 마련할 수 있음

 

나선형 개발 모델

• 요구사항이 개발 초기에 완전하게 정의되어 있지 않고 부분적으로 정의된 경우에 반복적으로 요구사항을 정제하고 확장하는 과정을 사용자가 받아들일 수 있는 완전한 시스템에 개발될 때까지 반복
• 매 단계에서 적당한 테스트가 이루어지므로 개발 과정에서 발생하는 많은 문제점을 해결할 수 있는 기회를 제공

 

6.3 애자일 개발 모델

애자일 방법론이 추구하는 가치

• 사람 및 상호 의사 교환이 프로세스나 도구보다 우선
• 동작하는 소프트웨어가 포괄적인 문서보다 우선
• 고객과의 협력이 계약 협상보다 우선
• 변화에 반응하는 것이 계획을 따르는 것보다 우선

애자일 방법론 : 소프트웨어 테스트를 매우 강조

TDD : 프로그램에 대한 테스트 케이스를 먼저 작성하고, 이 테스트 케이스로 테스트 되는 실제 프로그램의 코드를 나중에 작성하는 방식

TDD 프로세스

 

---

 

7장 테스트 자동화

• 도구를 사용하여 테스트 프로세스의 일부 혹은 전부를 자동화 하는 것을 의미
• 단순하고 반복적인 일에 도구를 사용하여 효율적으로 작업을 수행
• 테스터의 부담을 줄여 좀 더 창의적인 작업에 집중할 수 있게 함
• 테스터는 단순하면서 반복적인 업무에서 벗어나 일관성을 유지하면서 빠르게 테스트를 수행할 수 있음

 

7.2 테스트 자동화 분야 및 테스트 도구

SEARCH 모델

• 셋업, 실행, 분석, 보고, 정리, 도움말 총 6단계로 구성
• 각 단계를 자동화 함으로써 효율을 높이고 사람의 실수를 예방하며 전문성과 일관성을 가진 테스트를 할 수 있음

테스트 실행 도구 : 테스트 케이스를 자동으로 실행할 수 있도록 스크립트로 변환하여 실행

테스트 실행 프레임워크

• 선형 프레임워크 : 프로그래밍 지식 필요X, 테스트 케이스 쉽게 작성, Recode & PlayBack을 지원하는 도구에서 주로 볼 수 있음
• 모듈 기반 프레임워크 : 하나의 큰 스트립트를 유지가 용이한 여러 개의 작은 스크립트로 분할하여 관리할 수 있음
• 데이터 주도 프레임워크 : 테스트에 사용되는 데이터를 테스트 스크립트의 로직과 분리하여 보관하는 프레임워크, 테스트 데이터 셋을 하드 코딩하지 않고 CSV 파일 등에 보관하여 전달하면 테스트 효율을 높일 수 있음
• 키워드 주도 프레임워크 : 키워드를 사용한 테스트 케이스를 이용하여 애플리케이션 간에 결합을 줄여줌

 

7.3 테스트 도구 산정

테스트 도구를 선정하는 프로세스

• 요구사항 정의 : 테스트 도구에 대한 요구사항을 식별하여 정의
• 도구 조사 : 도구 조사, 자체 개발 가능성도 검토
• 도구 평가 : 도구가 요구사항에 얼마나 부합하는지 평가
• 파일럿 프로젝트 : 도구의 시험판 버전을 사용하거나 파일럿 프로젝트를 수행하여 도구의 품질을 평가
• 도구 선정
• 도구 도입

 

 

---

 

 

📚 참고 문헌 : 소프트웨어 테스트 전문가(CSTS) 가이드