(정보처리기사 실기) 애플리케이션 테스트 관리

 

애플리케이션 테스트 케이스 설계

소프트웨어 테스트 : 사용자가 요구하는 기능, 성능, 사용성, 안정성 만족하는지 확인하고 결함을 찾는 활동

 

소프트웨어 테스트 필요성

-오류 발견 관점 : 잠재된 오류 발견

-오류 예방 관점 : 동료검토, 워크스루, 인스펙션

-품질 향상 관점 : 신뢰도 향상을 위한 품질 보증 

 

소프트웨어 테스트 원리

-테스팅은 결함의 존재를 밝히는 것

-완벽한 테스팅은 불가능

-개발 초기에 테스팅 시작

-결함집중 : 20%의 모듈에서 80%의 결함 발견

-살충제 패러독스 : 동일한 테스트 케이스를 반복적으로 테스트를 수행해도 새로운 버그를 찾을 수 없다

-테스팅은 정황에 의존적 : 소프트 웨어의 성격에 맞게 테스트

-오류-부재의 궤변 : 요구사항을 만족시키지 못한다면 오류가 없어도 품질이 높다고 할 수 없다.

 

소프트웨어 테스트 케이스

테스트 계획 -> 테스트 분석 및 디자인 -> 테스트 케이스 및 시나리오 작성 -> 테스트 수행 

->테스트 결과 평가 및 레포팅

 

소프트웨어 테스트 산출물

-테스트 계획서 : 테스트 목적과 범위 정의, 시스템 구조 파악, 수행 절차 등 수행 계획 문서

-테스트 케이스 : 요구사항 준수를 위해 확인하는 입력값, 실행조건, 기대결과로 구성

-테스트 시나리오 : 여러개의 테스트 집합으로 테스트케이스의 동작 순서를 기술한 문서

-테스트 결과서 : 테스트 프로세스를 리뷰하고 결과를 평가

 

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

정적 테스트 : 프로그램 실행 x 구조 분석

-동료검토 : 작성자가 요구사항 명세서를 설명하고 이해관계자가 들으면서 수행

-워크스루 : 검토 자료를 회의전에 배포하여 사전 검토 후 진행

-인스펙션 : 저작자 외의 다른 전문가 팀이 분석

 

동적테스트 : 프로그램 실행

-화이트박스 테스트 : 내부 로직을 보면서 수행(구조 테스트)

-블랙박스 테스트 :  요구사항 명세를 보면서 수행(기능 테스트)

 

화이트 박스 테스트 종류

-제어구조 테스트

-루프 테스트

 

블랙박스 테스트 종류

-동등 분할 테스트 : 데이터가 유사한 도메인별 유효값/무효값을 그룹핑하여 대표값 테스트 케이스를 도출 하는 테스트

-경계 값 테스트 : 등가분할 후 경계 값 부분을 테스트

-결정 테이블 테스트 : 요구사항의 논리와 발생 조건을 테이블로 나열하여 조건과 행위를 모두 테스트

-상태전이 테스트 : 어느 한 상태에서 다른 상태로 전이 되는 경우의 수를 수행

-유스케이스 테스트 : 시스템이 실제로 사용되는 유스케이스로 모델링 되었을때 프로세스의 흐름을 기반으로 테스트

-분류 트리 테스트 

-페어와이즈 테스트 : Test Data 값들을 최소 한번씩은 조합하는 방식 

 

테스트 시각에 따른 분류

검증(Verification)

-소프트웨어 과정을 테스트

-올바른 제품을 생산하고 있는지 검증

 

확인(Validation)

-소프트웨어 결과를 테스트

-만들어진 제품이 제대로 동작하는지 확인

 

테스트 목적에 따른 분류

-회복 테스트 : 고의로 실패를 유도하고 시스템이 정상 복귀 하는지 확인

-안전 테스트 : 보안적인 결함을 미리 점검

-강도 테스트 : 정보량 과부하시에도 시스템이 정상 작동하는지 검증

-성능 테스트 : 응답 시간, 처리량, 반응 속도를 측정

-구조 테스트 : 내부 논리 경로, 소스코드 복잡도를 평가

-회귀 테스트 : 수정한 시스템에서 새로 유입된 오류가 없는지 확인

-병행 테스트 : 변경된 시스템과 기존의 시스템에 동일한 데이터를 입력하여 비교 

 

테스트 종류에 따른 분류

-명세 기반 테스트(블랙 박스) : 요구사항 명세서를 기반

-구조 기반 테스트(화이트 박스) : 내부 논리 흐름에 따라

-경험 기반 테스트 : 테스터의 경험을 토대로

 

테스트 케이스 : 입력값, 실행 조건, 예상 결과의 집합

테스트 케이스 작성 절차

1. 테스트 계획 검토 및 자료 확보

2. 위험 평가 및 우선 순위 결정

3. 테스트 요구사항 정의

4. 테스트 구조 설계 및 테스트 방법 결정

5. 테스트 케이스 정의

6. 테스트 케이스 타당성 확인 및 유지보수

 

테스트 오라클 : 테스트 결과가 참인지 거짓인지 판단하기 위해 사전에 정의된 값과 비교

-참 오라클 : 모든 입력값에 대하여 결과를 생성

-샘플링 오라클 : 특정한 몇개의 입력값에 대해서만 결과를 제공

-휴리스틱 오라클 : 특정 입력값 올바른 결과 제공 나머지는 추정해서 처리

-일관성 검사 오라클 : 애플리 케이션 변경이 있을때 수행전과 수행 후의 결괏값이 동일한지 확인

 

테스트 레벨 종류

-단위 테스트 : 모듈, 서브루틴 등을 테스트

-통합 테스트 : 통합된 컴포넌트간 상호작용 테스트

-시스템 테스트 : 통합된 단위의 시스템이 정상 수행 되는지 확인

-인수 테스트 : 요구사항 만족했는지 확인

 

v모델 : 소프트웨어 생명주기 각 단계별로 개발자 관점에서 검증과 최종 산출물에 대한 테스트 확인

V 모델과 테스트

 

 

테스트 시나리오 : 테스트 케이스의 동작 순서를 기술한 문서, 설계 단계에서 중요시 되었던 요구사항이나 대안을 빠짐없이 테스트

 

테스트 환경 구축 : 실제 운영 시스템에서 정상적으로 작동하는지 테스트하기 위해 실제 운영 시스템과 동일한 사양의 하드웨어, 소프트웨어, 네트워크 등의 환경 시설을 구축

테스트 환경 구축 유형 

-하드웨어 기반의 테스트 환경 구축 : 서버 장비(was, dbms), 클라이언트 장비(노트북, pc), 네트워크 장비 설치

-소프트웨어 기반의 테스트 환경 구축 : 필요한 소프트웨어 설치 

-가상 시스템 기반의 테스트 환경 구축 : 가상 머신 또는 클라우드 환경을 이용

 

애플리케이션 통합 테스트

통합 테스트 : 모듈간의 오류 및 결함을 찾기 위한 테스트, 설계 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지 확인 

통합 테스트 수행 방법 분류 : 점증적 방법과 비점증적 방법

 

점증적 방법

-하향식 통합 테스트(스텁 사용) : 메인 모듈에서 아래 방향으로 테스트 수행, 깊이우선과 너비 우선 방식

순서 : 메인 제어 모듈 프로그램 사용 -> 시스템 구조 파악 -> 스텁 개발 -> 스텁을 실제 모듈로 교체 -> 통합 테스트 수행->테스트 완료 후 실제 모듈 작성

-상향식 통합 테스트(드라이버 사용) : 최하위 레벨 모듈에서 위쪽으로 테스트 수행

순서 : 클러스터로 결합 -> 드라이버 작성 -> 클러스터 단위 테스트 -> 테스트 완료 후 드라이버 실제 모듈로 교체

 

비점증적 방법 : 모든 컴포넌트를 사전에 통합하여 전체 프로그램을 한꺼번에 테스트

 

스텁 : 모듈 및 하위 컴포넌트를 대신하는 더미 모듈

드라이버 : 상위 모듈에서 데이터의 입력과 출력 확인을 위한 더미 모듈

 

통합 테스트 수행 방법 비교

빅뱅 테스트 : 모든 모듈 동시 통합, 드라이버/스텁 사용X, 장애 위치 파악 어려움

상향식 테스트 : 최하위 부터 점진적 수행, 테스트 드라이버 필요, 중요 모듈이 마지막 테스트 가능성 높음

하향식 테스트 : 최하위 부터 점진적 수행, 테스트 스텁 필요, 하위 모듈들의 불충분한 상태로 테스트 수행

 

테스트 자동화 도구 : 반복적인 테스트 작업을 스크립트 형태로 구현하여 시간단축, 비용 최소화

 

테스트 자동화 도구 유형 

정적 분석도구 : 애플리케이션을 실행하지않고 분석하는 도구, 코딩 스타일, 코드 복잡도, 남은 결함 확인을 위해 사용

-데이터 주도 방식 : 데이터를 이용하여 동일한 테스트 케이스 반복 실행

-키워드 주도 방식 : 키워드를 이용하여 테스트 수행 동작 정의, 특성에 맞추어 키워드 테일러링 수행 가능

 

테스트 하네스 : 컴포넌트 및 모듈 테스트 환경의 일부분, 테스트 지원하기 위한 코드와 데이터

테스트 하네스 구성요소

-테스트 드라이버 : 상향식 테스트에 사용

-테스트 스텁 : 하향식 테스트에 사용

-테스트 슈트 : 컴포넌트나 모듈에 사용되는 테스트 케이스의 집합

-테스트 케이스 : 입력값, 실행조건, 기대결과 등의 집합

-테스트 스크립트 : 자동화된 테스트 실행 절차 명세

-목 오브젝트 : 행위를 조건부로 사전에 입력하면, 그 상황에 예정된 행위 수행

 

테스트 단계별 테스트 자동화 도구

테스트 계획  - 요구사항 관리

테스트 분석/설계 -테스트 케이스 생성

테스트 수행 - 테스트 자동화

                 - 정적 분석

                 - 동적 분석

                 - 성능 테스트

                 - 모니터링

테스트 관리 - 커버리지 측정 : 테스트 완료 후 테스트 충분성 검증

                 - 형상 관리

                 - 결함 추적/관리

 

소프트웨어 결함

-에러/오류 : 에러는 결함의 원인이 되는 것으로 사람의 실수로 발생

-결함/결점/버그 : 에러 또는 오류가 원인이 되어 발생, 제거하지 않으면 제품이 실패하거나 문제 발생

-실패/문제 : 결함이 실행될때 발생하는 현상

 

테스트 리포팅

-테스트 결과 정리 : 테스트 케이스 설계, 테스트 시나리오, 테스트 결과까지의 문서

-테스트 요약 문서 : 계획, 소요비용, 테스트 결과의 내용 문서

-품질 상태 : 테스트 성공률, 테스트 커버리지, 결함의 수 등

-테스트 결과서 : 결함과 관련된 정보 기록

-테스트 실행 절차 및 평가 : 결과에 대한 평가를 수행하고 절차 최적화 

 

테스트 결함 관리 : 테스트 수행 후 발생한 결함의 재발 방지, 유사 결함 발견시 시간 단축을 위해 결함 추적 관리

결함 관리 프로세스 

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

 

결함 추이 분석 : 어떤 모듈 또는 컴포넌트에서 결함이 발생할지 추정

결함추이 분석 유형 

-결함 분포 분석 : 특정 속성에 해당하는 결함의 수 측정

-결함 추세 분석 : 테스트 진행 시간의 흐름에 따른 결함의 수 측정

-결함 에이징 분석 : 결함 상태의 지속시간을 측정 분석

 

테스트 커버리지 : 테스트 범위를 측정하는 테스트 품질 측정 기준, 정황성과 신뢰성을 향상시키는 역할

테스트 커버리지 유형

-기능 기반 커버리지 :  실제 테스트가 수행된 기능의 수 측정

-라인 커버리지 : 소스 코드의 라인수 측정

-코드 커버리지 : 소스 코드의 구문, 조건, 결정 등의 코드가 얼마나 테스트 되었는지 측정

 

코드 커버리지 유형

-구문 커버리지 : 모든 명령문을 적어도 한번 수행

-결정 커버리지 : 전체 결정문이 적어도 한번은 참과 거짓의 결과 수행

-조건 커버리지 : 결정 명령문 내 각 조건이 적어도 한번은 참과 거짓의 결과 수행

-조건/결정 커버리지 : 전체 조건식 뿐만 아니라 개별 조건식도 참 한번, 거짓 한번 결과가 되게 수행

-변경 조건/결정 커버리지 : 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 줌

-다중 조건 커버리지 : 결정 조건 내 모든 개발 조건식의 모든 가능한 조합을 100% 보장

 

단계별 결함 유입 종류

-기획시 유입되는 결함

-설계시 유입되는 결함

-코딩시 유입되는 결함

-테스트 부족으로 유입되는 결함

 

결함 심각도별 분류

-치명적(Critical) 결함 : 기능이나 제품의 테스트를 완전히 방해

-주요(Major) 결함 : 기능이 기대와 많이 다르거나 다르게 동작

-보통(Normal) 결함 : 특정 기준 충족하지 못하거나 일부 기능이 부자연

-경미한(Minor) 결함 : 사용상의 불편함 유발

-단순(Simple) 결함 : 사소한 버그, 기능에 영향 X

 

결함 우선 순위

결정적(Critical) : 

높음(High)

보통(Medium)

낮음(Low)

 

애플리케이션 성능 개선

애플리케이션 성능 측정 지표

-처리량 : 주어진 시간에 처리할 수 있는 트랜잭션 수

-응답 시간 : 입력이 끝난 후, 응답 출력이 개시될 때 까지의 시간

-경과 시간 : 입력 요구 시점부터 트랜잭션 처리 후 그 결과의 출력이 완료될 때 까지의 시간

-자원 사용률 : 트랜잭션 처리동안 사용하는 자원의 양

 

성능 분석 도구 유형

성능 테스트 도구

-JMeter : HTTP,FTP 등 안전성, 확장성, 부하 테스트

-LoadUI : UI를 통해 HTTP, JDBC등 웹 서비스를 대상으로 서버 모니터링 지원

-OpenSTA : HTTP, HTTPS 지원하는 부하 테스트 및 생산품 모니터링 도구

 

시스템 모니터링 도구

-Scouter : 단일 뷰 통합/실시간 모니터링, 튜닝 최적화

-Zabbix : 웹기반 서버, 서비스, 애플리케이션 모니터링 도구

 

데이터베이스 관련 성능 저하 원인

-데이터베이스 락 : 대량의 데이터 조회, 과도한 업데이트로 Lock 해제 까지 대기하거나 타임 아웃 .

-불필요한 데이터베이스 패치 : 실제 필요한 데이터보다 많은 대량의 데이터 요청이 들어올 경우

-연결 누수 : JDBC, 객체를 사용후 종료 하지 않을 경우 

-부적절한 커넥션 풀 크기 : 너무 작거나 크게 설정한 경우 성능 저하 현상이 발생 가능성

-확정(Commit 관련) : 트랜잭션이 commit 되지 않고 커넥션풀에 반환

 

내부 로직인한 성능 저하 원인

-웹 어플리케이션의 인터넷 접속 불량

-특정 파일 업로드, 다운로드로 인한 성능 저하

-정상적으로 처리 않은 오류 처리로 인한 성능 저하

 

애플리케이션 성능 테스트 

-성능 테스트 도구 설치

-테스트 환경 설정

-시나리오 생성

-성능 테스트 실행 및 모니터링

 

애플리케이션 성능 테스트 수행 절차

성능 테스트 도구 설치 -> 테스트 환경 설정 -> 시나리오 생성 -> 성능 테스트 실행 및 모니터링

 

소스 코드 최적화 : 클린 코드를 작성 하는 것

 

나쁜 코드 : 다른 개발자가 로직을 이해하기 어렵게 작성된 코드, 스파게티 코드, 변수나 메서드 정의를 알 수 없는 코드

 

나쁜 코드 유형 

-오염 : 비즈니스 기능 수행 불가

-문서부족 : 현재 코드와 문서가 일치하지 않음

-의미 없는 이름 

-높은 결합도

-아키텍처 침식 : 아키텍처가 구분 되지 않음

 

클린코드 : 가독성이 높고, 단순, 의존성을 줄이고, 중복 최소

-의미 있는 이름

-간결하고 명확한 주석

-보기 좋은 배치

-작은 함수

-읽기 쉬운 제어 흐름

-오류처리

 

소스 코드 품질 분석 : 코딩 스타일, 코딩 표준, 코드 복잡도, 메모리 누수 현황 파악 

정적 분석 도구 : 코딩 표준 준수, 코딩 스타일 적정 여부

동적 분석 도구 : 코드에 발생하는 메모리 누수 발견

 

소스 코드 품질 분석 도구

정적 분석 도구 : pmd, cppcheck, SonarQube, checkstyle

코드 복잡도 : ccm, cobertura

동적 분석 도구 : Avalanche, Valgrind

 

애플리케이션 성능 개선 방안

-소스 코드 최적화

-아키텍처 조정

-소스 코드 품질분석 도구 활용

1) 메모리 사용 최소화

2) 입출력 발생 최소화

3)System.out.print() 사용 제외

-애플리케이션 성능 관리