소프트웨어공학) Application Test Management

Verification vs Validation

Verification

개발자 입장에서 개발한 소프트웨어가 명세서에 맞게 정확한 기능을 수행하는지 검증하는 것

Validation

사용자 입장에서 개발된 소프트웨어가 고객 요구사항을 만족시키는지 확인하는 것

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

• 완벽한 테스트 불가
• 결함 집중
• 파레토 법칙 : 80%의 결함이 20%의 코드에 집중되어 있다.
• 살충제 패러독스→ 지속적으로 테스트 케이스를 보완 및 개선해야 한다.
• 동일한 테스트 케이스로 동일한 테스트를 반복하면 더 이상 결함이 반복되지 않는다.
• 테스팅은 정황 의존
• 소프트웨어의 특징, 테스트 환경, 테스트 역량 등 정황에 따라 결과가 달라진다.
• 오류 부재 궤변
• 결함을 모두 제거해도 사용자를 만족시킬 수 있는 것은 아니다.
• 테스트의 위험을 반비례
• 테스트를 많이 수행할수록 위험이 적어진다.
• 테스트는 점진적 확대
• 작은 부분에서 큰 부분으로 점점 확대하며 테스트를 진행해야 한다.
• 테스트는 별도의 팀에서 수행
• 개발자와 관계없는 팀에서 수행해야 한다.

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

정적 테스트

• 워크스루오류 조기 검출을 목적으로 하며 발견된 오류는 문서화한다.
• 개발자가 모집한 전문가들이 검토를 위해 준비된 자료를 바탕으로 평가한다.
• 인스펙션
• 개발 단계에서 산출된 결과물의 품질을 평가한다.
• 코드 검사

동적 테스트

• 화이트박스 테스트코드 내부 동작을 직접 관찰하며 모든 문장을 한번 이상 실행시킨다.— 제어 구조 검사
• — 기초 경로 검사
• 원시 코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
• 블랙박스 테스트소프트웨어 인터페이스에서 실시된다.
• 각 기능이 제대로 작동하는지 입증하는 테스트

테스트 기반에 따른 테스트

명세 기반 테스트

• 사용자 요구사항을 빠짐 없이 테스트 케이스로 만들어 구현하는지 확인
• 동등 분할, 경계값 분석

구조 기반 테스트

• 소프트웨어 내부의 논리 흐름에 따라 테스트 케이스를 작성하고 확인
• 구문 기반, 결정 기반, 조건 기반

경험 기반 테스트

• 유사한 소프트웨어나 기술에 대한 경험을 기반으로 수행
• 요구사항 명세가 불충분하거나 시간이 부족한 경우 사용하는 기법이다
• 에러 추정, 체크 리스트, 탐색적 테스팅

개발 단계에 따른 테스트

단위 테스트

• 코딩 직후 모듈, 컴포넌트에 초점을 맞추어 테스트 하는 것
• 인터페이스, 자료구조, 기초 경로, 오류 처리, 경계 조건 등을 검사한다.

통합 테스트

• 모듈을 결합하는 과정에서 하는 테스트
• 하향식 통합 테스트상위 모듈에서부터 통합을 시작하는데 주요 제어 모듈의 종속 모듈은 스텁으로 대체한다.모듈이 통합될때마다 테스트한다.
• 스텁은 테스트를 거쳐 하나씩 실제 모듈로 교체된다.
• 깊이 우선, 또는 넒이 우선 통합법을 사용한다.
• 상향식 통합 테스트클러스터 단위로 테스트를 하며 상위 모듈에서 데이터 입출력을 확인하기 위해 더미 모듈인 드라이버를 작성한다 .
• 드라이버 역시 통합 과정에서 실제 모듈로 교체된다.
• 종속 모듈을 그룹화하여 클러스터로 만든다.
• 회귀 테스트
• 통합 테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인한다.

시스템 테스트

• 개발된 소프트웨어가 텀퓨터 시스템에서 완벽하게 수행되는지 확인한다.
• 실제 실행 환경과 유사한 환경에서 진행해야 한다.
• 기능적, 비기능적 요구사항을 만족하는지 테스트한다.

인수 테스트

• 사용자의 요구사항을 충족하는지 초점을 맞추어 테스트한다.
• 사용자가 직접 테스트한다.
• 사용자 인수 테스트, 운영상 인수 테스트, 계약 인수 테스트, 규정 인수 테스트
• 알파 테스트 : 사용자가 개발자 앞에서, 통제된 환경에서 사용해보고 개발자와 함께 사용장 문제점을 발견하는 것
• 베타 테스트 : 선정된 사용자가 여러 명의 사용자 앞에서 테스트한다. 개발자의 개입 없이 실제 업무에서 사용하여 발견된 오류는 기록하고 개발자에게 보고한다.

테스트 프로세스

1. 테스트 계획

• 산출물 : 테스트 계획서
• 테스트 목표, 대상 및 범위 설정

2. 테스트 분석 및 디자인

• 테스크 원칙과 목적 검토
• 테스트 환경, 도구 준비

3. 테스트 케이스 및 시나리오 작성

• 산출물:— 테스트 시나리오 : 테스트 케이스릐 동작 순서를 기술한 문서
• ** 테스트 오라클 : 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참값을 대입하여 비교하는 기법
• — 테스트 케이스: 사용자 요구사항 준수 여부를 확인하기 위해 입력값, 실행 조건, 기대 결과 등의 테스트 항목 명세서

4. 테스트 수행

5. 테스트 결과 평가 및 리포팅

• 산출물 : 테스트 결과서

6. 결함 추적 및 관리

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

테스트 자동화 도구

• 테스트 절차를 스크립트 형태로 구현하는 도구
• 정적 분석 도구 : 프로그램을 실행하지 않고 코드를 확인하는 것
• 테스트 실행 도구 : 스크립트 언어를 사용하여 테스트를 자동으로 실행한다.
• 성능 테스트 도구 : 처리량, 응답시간, 경과 시간, 자원 사용률 등 측정하여 목표 달성 여부를 확인한다.
• 테스트 통제 도구 : 형상 관리 도구, 결함 추적 및 관리 도구
• 테스트 하네스 도구 : 테스트를 지원하기 위한 코드나 데이터

결함 관리 도구

Mantis

• 결함 및 이슈 관리 도구
• 소프트웨어 설계 시 단위별 작업 내용을 기록할 수 있어 결함 추적이 가능하다

Trac

• 결함 추적
• 결함 통합 관리

Redmine

• 프로젝트 관리 및 결함 추적이 가능한 도구

Bugzilla

• 결함 신고, 확인, 처리
• 결함의 심각도와 우선순위 지정이 가능하다.

어플리케이션 성능 분석

어플리케이션 성능 지표

• throughput : 일정 시간 내에 어플리케이션이 처리하는 작업의 양
• response time : 어플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
• turn around time : 어플리케이션에 작업을 의뢰한 시간부터 처리가 완료되기까지 걸린 시간
• resource usage : 어플리케이션이 의뢰한 작업을 처리하는 동안 사용한 자원량 (CPU, 메모리, 네트워크 등)

성능 테스트 도구

어플리케이션에 스트레스를 가하면서 성능 지표를 검사하는 도구

• JMeter : 다양한 프로토콜을 지원하는 부하 테스트 도구
• LoadUI : 서버 모니터링 등 사용자의 편리성이 강화된 부하 테스트 도구
• OpenSTA : HTTP 부하 테스트

시스템 모니터링 도구

어플리케이션 실행 시 시스템 자원 사용량을 확인하고 분석하는 도구

• Zabbix, Scouter

어플리케이션 성능 개선

소스코드 최적화 - 클린 코드 작성 원칙

• 가독성이해하기 쉬운 용어를 사용하고, 들여쓰기를 잘한다.
• 누구든 쉽게 읽을 수 있도록 작성한다.
• 단순성최대한 코드는 하나당 하나의 기능을 수행하도록 한다.
• 간단하게 작성한다.
• 의존성 배제
• 코드가 다른 모듈에 미치는 영향을 최소화한다.
• 중복성 최소화
• 추상화
• 상위 클래스/함수/메소드에서는 간략하게 어플리케이션 특성을 나타내고 상세 내용은 하위에서 구현한다.

소스 코드 최적화 유형

• 클래스 분할 배치 : 하나의 클래스는 하나의 역할만 하여 응집도를 높인다.
• 느슨한 결합 : 클래스간 의존성을 최소화한다.
• → 인터페이스 클래스, 추상화된 자료 구조나 메소드를 구현한다.
• 코딩 형식 준수
• 이름 명명 규칙 준수
• 적절한 주석 사용