2과목 : 소프트웨어 개발 (3장. 애플리케이션 테스트: 주요 키워드 정리)

3장. 애플리케이션 테스트

 

3-0. 애플리케이션 테스트

- 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차

- 개발된 소프트웨어가 고객의 요구사항을 만족시키는지 확인하고 기능을 정확히 수행하는지 검증한다.

- 애플리케이션 테스트의 기본원리

• 잠재적 결함은 줄일 수 있지만, 완벽한 테스팅은 불가하다.
• 결함은 대부분 특정 모듈에 집중 되어 있다. (파레토 법칙 : 발견된 80% 결함은 20%모듈에서 발견)
• 살충제 패러독스 ( 동일 테스트 반복시 더이상 결함 발견X)
• 정황에 따라서 테스트를 다르게 수행
• 오류 부재의 궤변 (결함을 모두 제거해도 사용자 요구사항을 만족X)
• 테스트를 많이하면 미래 발생 위험 감소
• 테스트는 작은 부분에서 점점 확대된다.
• 개발자와 관계 없는 별도의 팀에서 수행

 

- 프로그램 실행 여부에 따른 테스트

• 정적 테스트 : 프로그램 실행 X, 명세나 소스코드 대상으로 분석.
  • ex) 워크스루 ( 개발자의 작업 내용을 모집한 전문가 들이 검토), 인스펙션 (개발 단계에서 산출된 결과물로 평가)
• 동적 테스트 : 프로그램 실행 O, 오류를 찾는 테스트, 모든 단계에서 테스트를 수행
  • ex) 블랙박스 Test, 화이트 박스 Test

 

- 테스트 기반에 따른 테스트

• 명세 기반 테스트 : 사용자 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는지 확인 Test
  • ex) 동등분할, 경계 값 분석
• 구조 기반 테스트 : 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인
  • ex) 구문 기반, 결정 기반, 조건 기반
• 경험 기반 테스트 : 경험을 기반으로 수행하는 테스트
  • ex) 에러추정, 체크리스트, 탐색적 테스팅

 

-  시각에 따른 테스트

• 검증 테스트 : 개발자의 시각에서 생산과정 테스트
• 확인 테스트 : 사용자의 시각에서 제품결과 테스트

 

- 목적

• 회복 테스트 : 여러가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지 확인하는 테스트
• 안전 테스트 : 불법적인 침입으로 부터 보호할 수 있는 지 테스트
• 강도 테스트 : 과부하시에도 정상적으로 실행되는지 테스트
• 성능 테스트 : 실시간 전체적인 효율성을 진단
• 구조 테스트 : 내부의 논리적인 경로, 소스코드의 복잡도를 평가
• 회귀 테스트 : 변경, 수정된 코드에 결함이 없음을 확인
• 병행 테스트 : 변경 S/W와 기존 S/W에 동일한 입력 값을 주고 결과를 비교

 

- 화이트박스 Test

• 모듈의 원시코드를 오픈 시킨 상태에서 원시코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계
• 종류
  • 기초 경로 검사 : 대표적인 화이트 박스 Test, 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 함.
  • 제어 구조 검사 : 조건 검사(모듈내에 있는 논리적 조건 test), 루프 검사(반복 구조에 초점을 맞춰 실시), 데이터 흐름검사(변수의 정의와 변수 사용의 위치에 초점)
• 화이트 박스 Test 검증기준
  • 문장 검증 기준 : 모든 구문이 한번 이상 수행되도록 설계
  • 분기 검증 기준 : 모든 조건문이 한번 이상 수행되도록 설계
  • 조건 검증 기준 : 모든 조건문이 True 나 false인 경우가 한번 이상 수행
  • 분기/조건 기준 : 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True, False가 한번 이상 수행

 

- 블랙박스 Test

• 각 기능이 완전히 작동되는 것을 입증하는 Test
• 종류
  • 동치 분할 검사 : 입력 자료에 초점을 맞춰 테스트 케이스를 만들고 검사
  • 경계 값 분석 : 입력 자료에만 치중한 동치분할 기법을 보완, 중간값 보다 경계값에서 오류가 발생될 확률이 높다는 점 이용
  • 원인-효과 그래프 검사 : 효용성이 높은 테스트 케이스를 선정하여 검사
  • 오류 예측 검사 : 과거 경험, 확인자 감각으로 Test
  • 비교 검사 : 동일한 테스트 자료제공 -> 동일한 결과가 출력하는지 Test

 

- V모델

• 애플리케이션 Test와 개발 단계를 연결하여 표현한 것
•  

V 모델

• 단위 Test : 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 Test
• 통합 Test : 단위 Test가 완료된 모듈들을 결합하여, 하나의 시스템으로 완성 시키는 과정에서의 Test
• 시스템 Test : 개발된 소프트웨어가 해당 컴퓨터에 완벽히 수행되는가 검증 Test
• 인수 Test : 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 Test
  • 알파 Test : 개발자의 장소에서 사용자가 개발자 앞에서 Test
  • 베타 Test : 선정된 사용자가 여러명의 사용자 앞에서 행하는 Test

 

- 통합 Test

• 비 점진적 통합방식 : 단계적 통합 절차 없이 미리 결합되어 있는 프로그램 전체를 Test
• 점진적 통합방식 : 모듈 단위로 단계적 통합하면서 Test
  • 하향식 통합 Test : 프로그램 상위 모듈에서 하위 모듈로 통합하여 Test ( 모듈 대체 : 스텁)
  • 상향식 통합 Test : 프로그램 하위 모듈에서 상위 모듈로 통합하여 Test ( 모듈 대체 :클러스터, 더미모듈:드라이브)
  • 혼합식 Test : 하위수준 -> 상향식 통합, 상위 수준 -> 하향식 통합
  • 회귀 Test : 이미 Test된 프로그램 Testing을 반복한다.

 

- 결함 관리 프로세스

• 에러 발견 -> 에러 등록 -> 에러 분석 -> 결함 확정 -> 결함 할당 -> 결함 조치 -> 결함 조치 검토 및 승인

 

3-1. 테스트 도구

• 테스트 케이스 : 구현된 S/W가 사용자의 요구사항을 정확하게 준수했는지, 확인하기 위해서 구성된 Test 항목에 대한 명세서
• 테스트 시나리오 : 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서
• 테스트 오라클 : 테스트 결과가 올바른지 판단하기 위해 정의된 참 값을 대입, 비교
  • 참 오라클 : 모든 케이스 입력값에 대해 기대하는 결과를 제공
  • 샘플링 오라클 : 특정한 몇몇 테스트 케이스 입력값에 대해 기대하는 결과를 제공
  • 추정 오라클 : 샘플링 오라클 + 나머지 입력 값 들에 대해 추정
  • 일관성 검사 : 테스트 케이스의 수행 전, 후의 결과 값이 동일한지 검사

 

3-2. 테스트 자동화 도구

• 정적 분석 도구 : 프로그램을 실행 X, 분석하는 도구. 작성된 소스코드를 이해해야함.
• 테스트 실행 도구 : 스크립트 언어를 사용하여 Test를 실행.
• 성능 테스트 도구 : 인위적으로 적용한 가상의 사용자를 만들어 Test를 수행함으로써 성능 목표 달성 여부 확인
• 테스트 통제 도구 : 테스트 계획 및 관리, 테스트 수행, 결함 관리
• 테스트 하네스 도구 : 애플리케이션의 컴포넌트 및 모듈을 Test 하는 환경의 일부분, Test를 지원하기 위해 생성된 코드와 데이터를 의미

 

3-3. 결함관리

• 오류 발생, 작동 실패 등 개발자가 설계한 것과 다르게 동작하거나, 다른 결과가 발생하는 것
• 결함  추적 순서
  • 결함 등록 - 결함 검토 - 결함 할당 - 결함 수정 - 결함 조치 보류 - 결함 종료 - 결함 해제

 

3-4. 복잡도

• 시스템이나 시스템의 구성 요소 또는 소프트웨어의 복잡한 정도를 나타냄.
• 주유 복잡도 측정 방법에는 LOC 기법, 순환 복잡도가 있음.
• 종류
  • 빅오 표기법 : 알고리즘 실행시간이 최악일 때 표기 ( O )
    • O(1) : 오직 하나의 단계만을 거침
    • O(logn) : 입력 값 또는 조건에 의해 감소
    • O(n) : 1:1 관계
    • O(nlogn) nlogn 번만큼 수행
  • 세타 표기법 : 알고리즘 실행시간이 평균일 때 표기 ( θ )
  • 오메가 표기법 : 알고리즘 실행시간이 최상일 때 표기 (Ω)
• 순환 복잡도 : 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도

 

3-5. 애플리케이션 성능 개선

• 소스코드 최적화 : 나쁜 코드를 배제하고, 클린 코드로 작성하는 것
  • 스파게티 코드 : 코드의 로직이 서로 복잡하게 얽혀있는 코드
  • 외계인 코드 : 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수가 어려운 코드
• 클린코드 작성 원칙
  • 가독성 : 누구나 코드를 쉽게 읽을 수 있도록 작성
  • 단순성 : 코드를 간단하게 작성
  • 의존성 배제 : 코드가 다른 모듈에 미치는 영향을 최소화
  • 중복성 최소화 : 코드의 중복을 최소화
  • 추상화 : 상위클래스에서는 간략한 특성을 나타내고, 상세 내용은 하위클래스에서 구현
• 소스코드 최적화 유형
  • 클래스 분할 배치, 느슨한 결합, 코딩 형식 준수, 좋은 이름 사용, 적절한 주석문 사용
• 소스코드 품질 분석 도구의 종류
  • pmd : 결함을 유발할 수 있는 코드 검사
  • cppcheck : c/c++ 코드에 대해 분석
  • sonarQube : 코딩 설계 등을 분석
  • checkStyle : 자바 코드에 대해 검사