정보처리기사 실기 정리 7강 [애플리케이션 테스트]

애플리케이션 테스트

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

 

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

기본 원리	설명
완벽한 테스팅 불가능	소프트웨어의 잠재적인 결함을 줄일 수 있지만 소프트웨어 결함이 없다고 증명할 수 없음
파레토 법칙	애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙
살충제 패러독스	동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 발견되지 않는 현상
테스팅은 정황 의존	소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야 함
오류-부재의 궤변	소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어 품질이 높다고 말할 수 없음
테스트와 위험은 반비례	테스트를 많이 할수록 미래에 발생할 위험을 줄일 수 있음
테스트의 점진적 확재	테스트는 작은 부분에서 시작하여 점점 확대하여 진행해야 함
테스트의 별도 팀 수행	테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함

---

애플리케이션 테스트의 분류

프로그램 실행 여부에 따른 분류

 

정적 테스트

- 프로그램을 실행하지 않고 명세서나 소스 코드를 대상으로 분석하는 테스트

- 소스 코드에 대한 코딩 표준, 코딩 스타일, 코드 복잡도, 남은 결함 등을 발견하기 위해 사용

- 예시 : 워크스루, 인스펙션, 코드 검사

 

워크스루 : 개발자가 모집한 전문가들이 개발자의 작업 내역을 검토하는 것, 절차에 따라 진행하며 발견된 오류는 문서화 

인스펙션 : 워크스루를 발전시킨 형태로 산출된 결과물의 품질을 평가하고 개선시키는 방법을 제시

 

동적 테스트

- 프로그램을 실행하여 오류를 찾는 테스트

- 소프트웨어 개발의 모든 단계에서 수행

- 예시 : 블랙박스 테스트, 화이트 박스 테스트

---

화이트 박스 테스트, 블랙 박스 테스트

화이트박스 테스트 => 화이트 = 밝다 = 내부 논리를 다 본다

원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법이다.

 

종류

- 기초 경로 검사 

테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법, 대표적인 화이트 박스 기법

- 제어 구조 검사

  조건 검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트하는 테스트 케이스 설계 기법

  루프 검사 : 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

  데이터 흐름 검사 : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

 

검증 기준 => 테스트 케이스들이 테스트에 얼마나 적합한지 판단

문장 검증 기준 : 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스를 설계함

분기 검증 기준 : 소스 코드의 모든 조건문이 한 번 이상 수행되도록 테스트 케이스를 설계함

조건 검증 기준 : 소스 코드의 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계

분기/조건 검증 기준 : 소스 코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False 경우가 한 번 이상 수행되도록 테스트 케이스 설계

 

블랙박스 테스트 =>  블랙 = 어둡다 =  과정은 못보지만 결과를 확실히 본다

각 기능이 완전히 작동되는 것을 입증하는 테스트로 기능 테스트라고도 합니다.

 

종류

- 동치 분할 검사(동치 클래스 분해) 

프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료를 균등하게 하여 테스트 케이스를 정의하고 그에 맞는 출력인지 확인

- 경계값 분석

입력 조건의 중간값보다 경계값에서 오류가 발생할 확률 높다는 점을 이용해 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법

- 원인-효과 그래프 검사

입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 테스트하는 기법

- 오류 예측 검사

과거의 경험이나 확인자의 감각을 테스트하는 기법

- 비교 검사

여러 버전의 프로그램에 동일한 테스트 자룔르 제공하여 동일한 결과가 출력되는지 테스트하는 기법

---

개발에 따른 애플리케이션 테스트

소프트웨어 개발 단계

요구사항 > 분석 > 설계 > 구현 

테스트 단계

> 단위 테스트 > 통합 테스트 > 시스템 테스트 > 인수 테스트

 

요군설구 단통시인

 

단위 테스트 : 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트

통합 테스트 : 단위 테스트가 완료된 모듈을 결합하여 하나의 시스템으로 완성시키는 과정에서 테스트

시스템 테스트 : 개발된 소프트웨어가 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트

인수 테스트 : 개발한 소프트웨어가 사용자의 요구 사항을 충족하는가에 중점을 두고 점검하는 테스트

 

인수 테스트 종류

- 사용자 인수 테스트 : 사용자가 시스템 사용의 적절성 여부 확인

- 운영상의 인수 테스트 : 시스템 관리자가 인수 시 수행하는 테스트

- 계약 인수 테스트 : 계약상의 인수/검수 조건을 준수하는지 여부 확인

- 규정 테스트 : 소프트웨어가 정부 지침, 법규 ,규정 등에 맞게 개발되었는지 확인

- 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트, 통제된 상황에서 개발자와 함께 오류 기록

- 베타 테스트 : 선정된 사용자가 여려 명의 사용자 앞에서 테스트, 실업무를 가지고 사용자가 직접 테스트

---

통합 테스트

단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트

 

종류

비점진적 통합 방식 : 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 있는 프로그램 전체를 테스트

ex) 빅뱅 통합 테스트 방식

점진적 통합 방식 : 모듈 단위로 단계적으로 통합하면서 테스트 

ex) 하향식 통합 테스트, 상향식 통합 테스트, 혼합식 통합 테스트

 

하향식 통합 테스트(Top Down Intergration Test)

상위 모듈에서 하위 모듈로 방향을 통합하면서 테스트

Keyword : 스텁, 회귀테스트

 

상향식 통합 테스트(Bottom Up Intergration Test)

하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트

Keyword : 클러스터, 드라이버

 

혼합식 통합 테스트

하위 수준에서는 상향식 통합, 상위 수준에서는 하향식 통합을 사용하여 최적의 테스트를 지원하는 방식

 

회귀 테스팅

통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트

---

애플리케이션 성능 개선

소스코드 최적화

나쁜 소스는 배제하고 클린 코드로 작성

 

클린 코드 작성 원칙

- 가독성 : 누구든지 코드를 쉽게 이해

- 단순성 : 코드를 간단하게 작성

- 의존성 배제 : 코드가 다른 모듈에 미치는 영향을 최소화

- 중복성 최소화 : 코드의 중복성 최소화

- 추상화 : 상위 클래스/메소드/함수에서는 간략하게 애플리케이션의 특성을 나타내고, 하위 클래스/메소드/함수에서 구현

 

소스 코드 품질 분석 도구

코드 스타일, 코드에 설정된 코딩 표준, 코드 복잡도, 코드 메모리 누수, 스레드 결함 등을 분석하는 도구

정적 분석 도구 : 작성한 소스 코드를 실행하지 않고 표준이나 코딩 스타일, 결함 등을 확인 하는 코드 분석 도구

동적 분석 도구 : 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함등을 분석하는 도구