어플리케이션 테스트 관리
어플리케이션 테스트
어플리케이션 테스트란 어플리케이션 잠재된 결함을 찾는 행위 또는 절차.
소프트웨어가 요구사항을 만족하는지 확인(validation), 기능을 정확히 수행하는 지 검증(verification)
- 어플리케이션 기본 원리
- 완벽한 테스트 불가능 : 완벽한 테스팅은 불가능하다.
- 결함 집중 (Defect Clustering) : 겷마은 특정 모듈에 집중되어 있다.
- 파레토 법칙 : 어플의 20%의 코드에서 80%의 결함이 검출된다.
- 살충제 패러독스 : 동일 테스트 케이스로 테스트를 반복하면 더 이상 결함이 발견되지 않는다.
- 테스트 케이스를 계속해서 보완, 개선해야 한다.
- 테스팅은 정황 의존 : 테스트는 정황(상황)에 따라 다르게 수행해야 한다.
- 오류-부재의 궤변 : 결함을 모두 제거해도 요구사항 만족을 못하면 품질 높은 소프트웨어가 아니다.
- 테스트와 위험은 반비례 : 테스트를 많이 하면 미래 위험은 적다.
- 테스트의 점진적 확대 : 테스트는 작은 부분부터 확대해가며 진행해야 한다.
- 테스트의 별도 팀 수행 : 테스트는 개발자와 관계 없는 별도의 팀에서 수행해야 한다.
어플리케이션 테스트의 분류
- 실행 여부에 따른 테스트
- 정적 테스트 : 프로그램을 실행하지 않고 소스 코드를 분석하는 테스트
- 워크스루(개발자가 모집한 전문가가 검토), 인스펙션(워크스루 발전 형태), 코드 검사 등
- 동적 테스트 : 프로그램을 실행해 오류를 찾는 테스트
- 블랙박스 테스트(기능 테스트) : 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 테스트.
- 종류
- 동치 분할 검사/동등 분할 기법(Equivalence Partitioning Testing) : 입력 자료에 초점을 맞춰 테스트 케이스 제작, 검사. 타당한 입력 자료, 타당하지 않은 입력 자료 개수를 균등하게 해 테스트 케이스 설정.
- 경계값 분석(Boundary Value Analysis) : 입력 조건의 경계값을 테스트 케이스로 선정하여 검사하는 기법
- 원인 - 효과 그래프 검사(Cause-Effect Graphing Testing) : 입력 데이터 간 관계와 출력에 영향을 미치는 상황을 체계적으로 분석 후 효용성 높은 테스트 케이스를 선정해 검사하는 기법
- 오류 예측 검사(Error Guessing) : 과거 경험이나 확인자의 감각으로 테스트. 일련의 보충적 검사 기법이며 데이터 확인 검사라고도 함.
- 비교 검사(Comparison Testing) : 여러 버전 프로그램에 동일한 테스트 자료를 제공해 동일한 결과가 출력되는지 테스트.
- 종류
- 화이트박스 테스트 : 원시 코드의 논리적 모든 경로를 테스트해 테스트 케이스를 설계하는 방법
- 종류
- 기초 경로 검사 : 대표적 화이트박스 테스트 기법. 절차적 설계의 논리적 복잡성을 측정할 수 있게 해준다.
- 제어 구조 검사
- 조건 검사 : 모든 논리적 조건 테스트
- 루프 검사 : 반복 구조에 초점을 맞춰 테스트
- 데이터 흐름 검사 : 변수 정의와 변수 위치에 초점을 맞춰 테스트
- 검증 기준
- 문장 검증 : 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계
- 분기 검증 : 모든 조건문이 한 번 이상 수행되도록 테스트 케이스 설계
- 조건 검증 : 모든 조건문에 대해 조건이 True인 경우, False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계
- 분기 / 조건 검증 : 모든 조건문과 각 조건문에 포함된 개별 조건식 결과가 True인 경우와 False인 경우가 한 번 이상 수행되도록 테스트 케이스 설계+
- 종류
- 블랙박스 테스트(기능 테스트) : 소프트웨어가 수행할 특정 기능을 알기 위해 각 기능이 완전히 작동되는 것을 입증하는 테스트.
- 정적 테스트 : 프로그램을 실행하지 않고 소스 코드를 분석하는 테스트
- 테스트 기반에 따른(무엇을 기반으로 할지에 따른) 테스트
- 명세 기반 : 요구사항 명세를 다 테스트 케이스로 만들어 구현하고 있는지 확인
- 동등 분할, 경계 값 분석
- 구조 기반 : 내부 논리 흐름에 따라 테스트 케이스 작성 및 확인
- 구문 기반, 결정 기반, 조건 기반
- 경험 기반 : 유사 소프트웨어나 기술 등에 대한 테스트 경험을 기반으로 수행하는 테스트
- 에러 추정, 체크 리스트, 탐색적 테스팅
- 명세 기반 : 요구사항 명세를 다 테스트 케이스로 만들어 구현하고 있는지 확인
- 시각에 따른 테스트
- 검증(verification) 테스트 : 개발자의 시각
- 확인(validation) 테스트 : 사용자의 시각
- 목적에 따른 테스트
- 회복 : 일부러 결함을 줘 실패하게 한 후 제대로 복구하는지 확인
- 안전 : 불법적 침입으로 시스템을 보호하는지 확인
- 강도 : 과도한 정보량이나 빈도를 부과해 과부하 시 정상적으로 실행하는지 확인
- 성능 : 실시간 성능, 전체적인 효율성 진단. 응답 시간, 처리량 등 테스트
- 구조 : 논리적 경로, 복잡도 등 평가
- 회귀 : 변경 또는 수정된 코드에 새로운 결함이 없을을 확인
- 병행 : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과 비교
- 개발 단계에 따른 테스트
https://devuna.tistory.com/98 - 검증(Verification) 테스트 - 개발자 단에서의 테스트
- 단위 테스트 : 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
- 인터페이스, 외부적 IO, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등 검사.
- 방법
- 구조 기반 테스트 : 화이트박스 테스트 시행
- 목적 : 제어 흐름, 조건 결정
- 주로 시행됨
- 명세 기반 테스트 : 블랙박스 테스트 시행
- 목적 : 동등 분할, 경계값 분석
- 구조 기반 테스트 : 화이트박스 테스트 시행
- 통합 테스트(Intergration Test) : 단위 테스트 완료 모듈들을 결합해 하나의 시스템으로 완성시키는 과정에서의 테스트
- 방법
- 비점진적 통합 방식
- 빅뱅 통합 테스트 방식
- 점진적 통합 방식 : 모듈 단위 단계적으로 통합하며 테스트
- 하향식 통합 테스트 : 상위 모듈에서 하위 모듈 방향으로 통합하며(위에서 아래로) 테스트
- 절차
- 주요 제어 모듈은 작성된 프로그램 사용. 종속 모듈들은 스텁으로 대체
- 깊이 우선 / 넓이 우선 통합 방식에 따라 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체
- 모듈이 통합될 때마다 테스트 실시
- 회귀 테스트(이미 했던 테스트 반복. 변경 사항으로 인해 오류가 있는지 확인하기 위해) 실시
- 절차
- 상향식 통합 테스트 : 하위 모듈에서 상위 모듈 방향으로 통합하며(아래에서 위로) 테스트
- 절차
- 하위 모듈들을 클러스터(종속 모듈 그룹)로 결합
- 상위 모듈에서 데이터의 입*출력 확인을 위한 더미 모듈인 드라이버 작성
- 통합된 클러스터 단위 테스트
- 테스트 완료 시 클러스터는 프로그램 구조 상위로 이동해 결합하고 드라이버는 실제 모듈로 대체
- 절차
- 혼합식 통합 테스트(샌드위치 통합 테스트)
- 하위에선 상향, 상위에선 하향식 통합을 사용해 최적의 테스트를 지원하는 방식.
- 하향식 통합 테스트 : 상위 모듈에서 하위 모듈 방향으로 통합하며(위에서 아래로) 테스트
- 비점진적 통합 방식
- 방법
- 시스템 테스트 : 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽히 수행되는가 점검하는 테스트. 실제 사용 환경과 유사하게 만든 테스트 환경에서 테스트 수행해야 함.
- 방법
- 기능적 요구사항 : 명세서 기반 블랙박스 테스트 시행
- 비기능적 요구사항 : 구조적 요소에 대한 화이트박스 테스트 시행
- 방법
- 단위 테스트 : 최소 단위인 모듈이나 컴포넌트에 초점을 맞춰 테스트
- 확인(Validation) 테스트 - 사용자 단에서의 테스트
- 인수 테스트(Acceptance Test) : 개발한 소프트웨어가 사용자 요구사항을 충족하는지 중점을 두고 테스트
- 종류
- 사용자 인수 테스트 : 사용자가 시스템 사용 적절성 여부 확인
- 운영상 인수 테스트 : 시스템 관리자가 시스템 인수 시 수행하는 테스트 기법.
- 계약 인수 테스트 : 계약상 인수 / 검수 조건을 준수하는지 여부 확인
- 규정 인수 테스트 : 소프트웨어가 정부 지침, 법규, 규정 등 규정에 맞게 개발되었는지 확인
- 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트. 통제된 환경(개발자가 있는)에서 개발자와 사용자가 함께 확인하며 오류와 문제점 기록
- 베타 테스트 : 선정된 최종 사용자가 여러 명 사용자 앞에서 행하는 테스트 기법. 제어되지 않은 환경에서 실 업무를 갖고 직접 테스트. 오류와 문제점을 주기적으로 개발자에게 보고
- 종류
- 인수 테스트(Acceptance Test) : 개발한 소프트웨어가 사용자 요구사항을 충족하는지 중점을 두고 테스트
- 검증(Verification) 테스트 - 개발자 단에서의 테스트
어플리케이션 테스트 프로세스
- 테스트 계획 : 프로젝트 계획서, 요구 명세서 등 기반으로 테스트 목표 정의 및 테스트 대상 및 범위 결정
- 절차
- 테스트 대상 시스템 구조 파악
- 테스트에 투입되는 조직 및 비용 산정
- 테스트 시작 및 종료 조건 정의
- 테스트 계획서 작성
- 절차
- 테스트 분석 및 디자인 : 테스트 목적과 원칙을 검토하고 사용자 요구 사항 분석
- 테스트 케이스 및 시나리오 작성 : 테스트 케이스 설계 기법에 따라 테스트 케이스 작성, 검토 및 확인 후 테스트 시나리오 작성.
- 테스트 수행 : 테스트 환경 구축 후 테스트 수행
- 테스트 결과 평가 및 리포팅 : 테스트 결과 비교 분석해 테스트 결과서 작성
- 결함 추적 및 관리 : 테스트 수행 후 결하밍 어디에서 발생했는지, 어떤 종류 결함인지 추적 및 관리
- 결함 관리 프로세스
- 에러 발견
- 에러 등록
- 에러 분석
- 결함 확정
- 결함 할당
- 결함 조치
- 결함 조치 검토 및 승인
- 결함의 원인이 되는 것이 오류. 일반적으로 사람에 의해 발생한 실수 의미. 오류로 인해 소프트웨어 제품에 발생한 것이 결함.
- 결함 관리 프로세스
- 최종 산출물 : 테스트 계획서, 테스트 케이스, 테스트 시나리오, 테스트 결과서
테스트 케이스 / 테스트 시나리오 / 테스트 오라클
- 테스트 케이스 : 구현된 소프트웨어가 요구사항을 준수했는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서.
- 작성 순서
- 테스트 계획 검토 및 자료 확보
- 위험 평가 및 우선순위 결정
- 테스트 요구사항 정의
- 테스트 구조 설계 및 테스트 방법 결정
- 테스트 케이스 정의
- 테스트 케이스 타당성 확인 및 유지 보수 : 소프트웨어 기능 또는 환경 변화에 따라 테스트 케이스 갱신
- 작성 순서
- 테스트 시나리오 : 테스트 케이스 적용 순서에 따라 여러 테스트 케이스들을 묶은 집합. 테스트 적용 구체적 절차를 명세한 문서. 순서를 기입해 테스트 항목 빠짐없이 수행 가능
- 테스트 오라클 : 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입해 비교하는 기법 및 활동
- 특징
- 제한된 검증 : 모든 테스트 케이스에 적용 불가
- 수학적 기법 : 값을 수학적 기법을 이용해 산출 가능
- 자동화 기능 : 테스트 대상 프로그램 실행, 결과 비교, 커버리지 측정 등 자동화 가능
- 종류
- 참 오라클 : 모든 테스트 케이스 입력 값에 대해 기대하는 결과를 제공하는 오라클. 모든 오류 검출 가능
- 샘플링 오라클 : 특정한 몇몇 테스트 케이스 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
- 추정(Heuristic) 오라클 : 샘플링 오라클 개선 오라클. 특정 테스트 케이스 입력값에 대해 기대하는 결과 제공, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
- 일관성 검사(Consistent) 오라클 : 애플리케이션 변경이 있을 때 테스트 케이스 수행 전과 후의 결과 값이 동일한지 확인하는 오라클
- 특징
테스트 자동화 도구
스크립트 형태로 구현하는 자동화 도구를 적용해 쉽고 효율적으로 테스트 수행. 휴먼 에러를 줄이고 테스트 정확성을 유지하며 테스트 품질 향상 가능
- 유형
- 정적 분석 도구 : 프로그램을 실행하지 않고 분석하는 도구. 코딩 표준, 코딩 스타일, 코드 복잡도 및 남은 결함 등을 발견하기 위해 사용
- 테스트 실행 도구 : 스크립트 언어를 사용해 테스트를 실행하는 방법
- 데이터 주도 접근 방식 : 스프레드시트에 테스트 데이터를 저장해 이를 읽어 실행하는 방식
- 키워드 주도 접근 방식 : 스프레드시트에 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 저장하여 실행하는 방식
- 성능 테스트 도구 : 인위적으로 적용한 가상의 사용자를 만들어 테스트 수행. 성능 목표 달성 여부 확인
- 테스트 통제 도구 : 테스트 계획 관리, 테스트 수행, 결함 관리 등 수행
- 테스트 하네스 도구 : 어플리케이션 컴포넌트 및 모듈 테스트하는 환경의 일부분. 테스트를 지원하기 위해 생성된 코드와 데이터를 의미.
- 구성 요소 - 테스트 드라이버, 테스트 스텁, 테스트 슈트(순서가 없는 테스트 케이스 집합), 테스트 케이스, 테스트 스크립트(순서가 있는 테스트 케이스 집합), 목 오브젝트(사전에 사용자 행위를 조건부 입력해두면 상황에 맞는 예정된 행위를 수행하는 객체)
결함 관리
결함의 정의 : 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것
- 결함 관리 프로세스
- 결함 관리 계획 : 전체 프로세스에 대한 계획 수립
- 결함 기록 : 발견된 결함을 결함 관리 DB에 등록
- 결함 검토 : 등록된 결함을 검토하고 결함을 수정할 개발자에게 전달
- 결함 수정 : 개발자 결함 수정
- 결함 재확인 : 수정한 내용 확인, 다시 테스트 수행
- 결함 상태 추적 및 모니터링 활동 : 결함 관리 DB를 이용해 프로젝트별 결함 유형, 발생률 등을 한 눈에 볼 수 있는 대시보드 또는 게시판 형태 서비스 제공
- 결함 관리 측정 지표 (결함의 상태 변화에 대해 관리, 측정)
- 결함 분포 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
- 결함 추세 : 테스트 진행 시간에 따른 결함 수 추이 분석
- 결함 에이징 : 특정 결함 상태로 지속되는 시간 측정
- 결함 추적 순서
- 결함 등록
- 결함 검토
- 결함 할당
- 결함 수정
- 결함 조치 보류
- 결함 종료
- 결함 해제
- 결함 관리 측정 지표 (결함의 상태 변화에 대해 관리, 측정)
- 최종 결함 분석 및 보고서 작성 : 발견된 결함에 대한 정보와 이해관계자들의 의견이 반영된 보고서를 작성하고 결함 관리 종료
- 결함 분류
- 시스템 결함 : 시스템 다운, 어플 작동 정지, 종료, 응답 시간 지연, DB 에러 등
- 기능 결함 : 사용자 요구사항 미반영 / 불일치, 부정확한 비즈니스 프로세스, 스크립트 오류, 타 시스템 연동 시 오류 등
- GUI 결함 : UI 비일관성, 데이터 타입 표시 오류, 부정확한 커서 / 메시지 오류 등
- 문서 결함 : 사용자 요구사항과 기능 요구사항의 불일치로 인한 불완전한 상태의 문서, 사용자의 온라인/오프라인 매뉴얼 불일치 등
- 결함 심각도 / 우선순위 : Critical - High - Medium - Low
- 결함 관리 도구 : Mantis, Trac, Redmine, Bugzilla
어플리케이션 성능 분석
- 성능 측정 지표 : 처리량(Throughput), 응답 시간(Response Time), 경과 시간(Trun Around Time), 자원 사용률(Resource Usage)
- 성능 테스트 도구 : 어플에 부하나 스트레스를 가해 성능 측정 지표 점검
- JMeter, LoadUI, OpenSTA
- 시스템 모니터링(Monitoring) 도구 : 어플이 실행됐을 때 시스템 자원 사용량 확인 및 분석
- Scouter, Zabbix
어플리케이션 성능 개선
- 소스 코드 최적화 : 나쁜 코드 배제, 클린 코드로 작성하는 것.
- 클린 코드 작성 원칙 : 가독성, 단순성, 의존성 배제, 중복성 최소화, 추상화
- 유형
- 클래스 분할 배치 : 하나의 클래스는 하나의 역할만. 응집도는 높이되, 크기는 작게
- 느슨한 결합(Loosely Coupled) : 인터페이스 클래스를 이용해 추상화된 자료 구조와 메소드를 구현함으로써 클래스 간 의존성 최소화. 결합도 낮추기
- 코딩 형식 준수 : 줄 바꿈 사용 / 개념적 유사성 높은 종속 함수 사용 / 호출하는 함수는 선배치, 호출되는 함수는 후배치 / 지역 변수는 함수 맨 처음에 선언
- 좋은 이름 사용
- 적절한 주석문 사용
- 소스 코드 품질 분석 도구
- 정적 분석 도구 : 실행하지 않고 분석
- pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura
- 동적 분석 도구 : 코드를 실행하여 코드 속 메모리 누수, 스레드 결함 등 분석
- Avalanche, Valgrind
- 정적 분석 도구 : 실행하지 않고 분석
'그 외 공부 > 정처기-실기(완)' 카테고리의 다른 글
| 9장 소프트웨어 개발 보안 구축 (0) | 2021.07.06 |
|---|---|
| 8장 SQL 응용 (0) | 2021.07.06 |
| 6장 화면 설계 (0) | 2021.07.02 |
| 5장 서버 프로그램 구현 (0) | 2021.06.29 |
| 4장 통합 구현 (0) | 2021.06.27 |