애플리케이션 테스트 관리
애플리케이션 테스트 케이스 작성
소프트웨어 테스트 필요성 (발예향)
- 오류 발견 관점 : 잠재된 오류를 발견하고 수정하여 올바른 프로그램 개발
- 오류 예방 관점 : 동료 검토, 워크스루, 인스펙션 등을 통해 오류를 조기에 검출
- 품질 향상 관점 : 반복적인 테스트를 거쳐 제품의 신뢰도를 향상
소프트웨어 테스트의 원리 (결완초집살정오)
- 결함이 존재함을 밝히는 것 : 결함이 존재함을 밝히는 활동
- 완벽한 테스팅 불가 : 완벽한 테스팅 시도는 불필요한 시간과 자원낭비, 무한 입력값
- 초기에 테스팅 시작 : 초기에 테스팅 미진행 시 결과가 프로젝트 후반에 영향을 미치게 되어 비용이 커진다는 요르돈 법칙(Snowball Effect) 적용
- 결함집중 : 적은 수의 모듈에서 대다수 결함 발견, 파레토법칙(오류의 80%는 모듈 20%에서 발견)
- 살충제 패러독스 : 동일한 테스트 케이스의 반복 수행은 새로운 결함을 발견할 수 없음
- 정황에 의존 : 성격에 맞게 테스트를 실행, 정황에 따라 테스트를 다르게 수행
- 오류-부재의 궤변 : 요구 사항을 충족하지 못하면 결함이 없다고 해도 품질이 높다고 할 수 없음
소프트웨어 테스트 산출물
- 테스트 계획서 : 테스트 목적과 범위 정의
- 테스트 베이시스 : 논리적인 케이스로 테스트 설계를 위한 기준이 되는 문서
- 테스트 케이스 : 테스트를 위한 설계 산출물로 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과로 구성된 테스트 항목의 명세서
- 테스트 슈트 : 테스트 케이스를 실행 환경에 따라 구분해 놓은 테스트 케이스 집합
- 테스트 시나리오 : 테스트되어야 할 기능, 상황을 작성한 문서
- 테스트 스크립트 : 테스트 케이스의 실행 순서를 작성한 문서, 테스트 스텝=테스트 절차서
- 테스트 결과서 : 테스트 결과를 정리한 문서
소프트웨어 테스트 유형
프로그램 실행여부에 따른 분류 : 프로그램 실행 여부에 따라 정적테스트와 동적테스트로 나뉨
정적 테스트 : 테스트 대상을 실행하지 않고 구조를 분석하여 논리성을 검증 (리뷰, 정적 분석)
- 리뷰 : 다양한 산출물에 존재하는 결함을 검출, 프로젝트의 진행 상황을 점검하기 위해 전문가가 수행
*동료 검토, 인스펙션, 워크스루
- 정적 분석 : 자동화된 도구를 이용하여 산출물의 결함 검출 및 복잡도 측정(코딩 표준, 복잡도 측정, 자료 흐름 분석)
동적 테스트 : 테스트 대상을 실행하는 방식으로 테스트를 수행하여 결함을 검출 (화이트박스, 블랙박스, 경험 기반)
테스트 커버리지 유형 (기라코)
- 기능 기반 커버리지 : 전체 기능을 모수로 설정, 테스트가 수행된 기능의 수를 측정
- 라인 커버리지 : 전체 소스 코드의 라인의 수를 모수로 설정, 테스트를 수행한 소스 코드의 라인의 수를 측정
- 코드 커버리지 : 소스 코드의 문장, 분기, 조건 등의 구조 코드 자체가 얼마나 테스트되었는지를 측정
테스트 기법에 따른 분류 : 화이트 박스 테스트/ 블랙박스 테스트
화이트박스 테스트 : 구조 기반 테스트이며 내부 구조와 동작을 검사하는 테스트
- 각 응용 프로그램의 내부 구조와 동작을 검사하는 테스트
- 모듈 내부를 테스트하는 방법
화이트박스 테스트 유형 (문분조 조변다 기제데)
- 문장 커버리지(구문 커버리지) : 모든 명령문을 적어도 한 번 수행하는 커버리지
- 분기 커버리지(결정 커버리지) : 전체 조건식이 적어도 한 번은 참과 거짓의 결과를 수행
- 조건 커버리지 : 개별 조건식이 적어도 한번은 참과 거짓의 결과를 수행
- 조건/결정 커버리지 : 전체 조건식과 개별 조건식이 참 한번, 거짓 한번 결과를 수행
- 변경 조건/결정 커버리지 : 개별 조건식이 다른 개별 조건식에 영향을 받지 않고 전체 조건식에 독립적으로 영향을 주도록 함으로써 조건결정 커버리지를 향상 시킨 커버리지
- 다중 조건 커버리지 : 개별 조건식의 모든 가능한 조합을 100프로 보장하는 커버리지
- 기본 경로 커버리지 : 수행 가능한 모든 경로를 테스트하는 커버리지
*맥케이브의 순환복잡도 기반 복잡도=간선-노드+2 V(G)=E-N+2
- 제어 흐름 테스트 : 프로그램 제어 구조를 그래프 형태로 나타내어 내부 로직을 테스트하는 기법
- 데이터 흐름 테스트 : 제어 흐름 그래프에 데이터 사용 현황을 추가한 그래프를 통해 테스트하는 기법
블랙박스 테스트 유형 (동경결상 유분페원비) : 요구사항 명세서를 보며 수행하는 기능 테스트
- 동등 분할 테스트 : 입력 데이터를 유횻값/무효값으로 그룹핑하여 대푯값 테스트 케이스를 도출하여 테스트
- 경곗값 분석 테스트 : 경곗값 부분에서 오류 발생 확률이 높기 때문에 경곗값을 포함하여 테스트 케이스를 설계하여 테스트
*최솟값의 바로 위, 최댓값의 바로 아래 등 입력값의 한계를 테스트
- 결정 테이블 테스트 : 요구사항의 논리와 발생조건을 테이블 형태로 나열, 조건과 행위를 모두 조합하여 테스트
- 상태 전이 테스트 : 이벤트에 의해 어느 한 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트
- 유스케이스 테스트 : 프로세스 흐름을 기반으로 테스트케이스를 명세화하여 수행하는 테스트
- 분류 트리 테스트 : SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 테스트 케이스를 설계하여 테스트
- 페어와이즈 테스트 : 테스트 데이터 값들 간에 최소한 한번 씩 조합하는 방식
- 원인-결과 그래프 테스트 : 그래프를 활용하여 입력 데이터 간의 관계 및 출력에 미치는 영향을 분석
- 비교 테스트 : 여러 버전의 프로그램에 같은 입력 값을 넣어 동일한 결과 데이터가 나오는지 비교해 보는 테스트
테스트 시각에 따른 분류
- 검증 : 개발 과정을 테스트, 개발자 혹은 시험자의 시각으로 명세화된 기능을 올바르게 수행하는지 테스트
- 확인 : 결과를 테스트, 제대로 동작하는지 확인, 사용자 시각으로 올바르게 개발되었는지 입증하는 과정
테스트 목적에 따른 분류 (회안성 구회병)
- 회복 테스트 : 시스템에 고의로 실패를 유도하고 정상적 복귀 여부를 테스트
- 안전 테스트 : 소스 코드 내의 보안적인 결함을 미리 점검하는 테스트
- 성능 테스트 : 사용자의 이벤트의 시스템이 응답하는 시간, 특정 시간 내에 처리하는 업무량, 반응 속도 테스트
- 구조 테스트 : 시스템의 내부 논리 경로, 소스 코드의 복잡도를 평가하는 테스트
- 회귀 테스트 : 오류 제거와 수정에 의해 새로 유입된 오류가 없는지 확인하는 테스트
- 병행 테스트 : 변경 시스템과 기존 시스템에 동일한 데이터를 입력 후 결과를 비교하는 테스트
성능테스트의 유형 (부스스내)
- 부하 테스트 : 부하를 계속 증가시키면서 임계점을 찾는 테스트, 병목 지점을 찾아 병목 현상을 제거
- 스트레스 테스트 : 임계점 이상의 부하를 가하여 비정상적인 상황에서의 처리를 테스트
- 스파이크 테스트 : 짧은 시간에 사용자가 몰릴 때 시스템의 반응 측정 테스트
- 내구성 테스트 : 오랜 시간 동안 높은 부하를 가하여 시스템 반응 테스트
테스트 종류에 따른 분류 (명구경)
- 명세 기반 테스트(블랙박스 테스트) : 요구사항 명세서를 기반으로 테스트 케이스 작성 후 테스트
- 구조 기반 테스트(화이트박스 테스트) : 내부논리 흐름에 따라 테스트 케이스를 작성 후 테스트
- 경험 기반 테스트 : 테스터의 경험을 토대로 한 직관과 기술 능력을 기반으로 수행하는 테스트
경험 기반 테스트 유형 (탐오체특)
- 탐색적 테스트 : 경험을 바탕을 두고 탐색적으로 기능을 수행해 보면서 테스트하는 기법
- 오류 추정 : 개발자가 범할 수 있는 실수를 추정 이에 따른 결함이 검출되도록 테스트 케이스 설계 후 테스트
- 체크리스트 : 테스트하고 평가해야 할 내용과 경험을 분류하여 나열한 이후 하나씩 확인하는 테스트 기법
- 특성 테스트 : 국제 표준인 ISO/IEC 9126의 품질 특성을 기준으로 테스트 케이스 설계 후 테스트하는 기법
테스트 오라클 개념 : 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전의 정의된 참값을 입력하여 비교
테스트 오라클 유형 (참샘휴일)
- 참 오라클 : 모든 입력값에 대하여 기대하는 결과를 생성함으로써 발생된 오류를 모두 검출
- 샘플링 오라클 : 특정한 몇 개의 입력값에 대해서만 기대하는 결과를 제공해 주는 오라클
- 휴리스틱 오라클 : 샘플링 오라클을 개선한 오라클로 특정 입력 값에 올바른 결과를 제공하고 나머지 값들은 추정으로 처리하는 오라클
- 일관성 검사 오라클 : 애플리케이션 변경이 있을 때 수정 전과 후의 결괏값이 동일한지 확인하는 오라클
애플리케이션 통합 테스트
단위 테스트 개념 : 개별적인 모듈 또는 컴포넌트를 테스트한다.
- 모듈의 대해 컴포넌트 테스트를 수행하려면 모듈을 단독으로 실행할 수 있는 테스트 베드 환경 필요
통합 테스트 개념 : 각 모듈 간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 테스트 기법
통합테스트 수행 방법의 분류 : 점증적인 방법과 비점증적인 방법
점증적 방법 (상드하스)
- 하향식 통합(Top Down) 개념 : 메인 제어 모듈로부터 하향식으로 통합하며 테스트 진행, 스텁 필요
- 상향식 통합(Bottom Up) 개념 : 최하위 모듈로부터 상향식으로 통합하며 테스트 진행, 드라이버 필요
- 샌드위치 통합 개념 : 상향식과 하향식을 결합한 테스트 방식, 큰 규모의 통합테스트에서 사용, 스텁 드라이버 필요
비점증적 방법
- 빅뱅 테스트 : 모든 모듈을 동시에 통합 후 테스트 수행, 실제 모듈로 테스트
목 객체 생성 프레임 워크
- 객체지향 프로그램에서 컴포넌트 테스트 수행 시 테스트되는 메서드는 다른 클래스의 객체에 의존
- 독립적 테스트가 불가능하므로 테스트를 위해서 스텁의 객체지향 버전인 목 객체가 필요하다.
목 객체 유형 (더스드스가)
- 더미 객체 : 테스트 시 객체만 필요하고 기능은 필요 없을 때 사용
- 테스트 스텁 : 타 모듈의 기능을 단순히 수행하는 도구 특정한 값을 리턴하거나 특정 메시지 출력
- 테스트 드라이버 : 테스트 대상 하위 모듈을 호출하고 파라미터 전달, 결과를 도출
- 테스트 스파이 : 테스트 대상 클래스와 협력하는 협력클래스로 가는 출력을 검증하는 데 사용
- 가짜 객체 : 실제 협력 클래스의 기능을 대체해야 할 경우 사용
테스트 자동화 도구 개념 : 반복적인 테스트 작업을 스크립트 형태로 구현
테스트 자동화 도구 유형 (정실성통)
- 정적 분석 도구 : 애플리케이션을 실행하지 않고 분석하는 도구, 소스코드에 대한 코딩 표준, 스타일, 복잡도 측정
- 테스트 실행 도구 : 테스트를 위해 작성된 스크립트를 실행하여 테스트, 데이터, 키워드 주도 접근 방식
*데이터 주도 접근 방식 : 테스트 데이터를 스프레드시트에 저장
*키워드 주도 접근 방식 : 테스트를 수행할 동작을 나타내는 키워드와 테스트 데이터를 스프레드시트에 저장
- 성능 테스트 도구 : 애플리케이션의 처리량, 응답시간, 경과시간, 자원사용률에 대한 테스트 수행
- 테스트 통제 도구 : 테스트 관리 도구, 형상 관리 도구, 결함 추적관리 도구 등이 있다
테스트 하네스 : 테스트를 지원하기 위한 코드와 데이터
- 테스트 드라이버
- 테스트 스텁
- 테스트 슈트 : 테스트 케이스의 집합
- 테스트 케이스 : 입력값, 실행조건, 기대결과등의 집합
- 테스트 스크립트 : 테스트 케이스의 실행 절차
- 목 오브젝트 : 사용자의 행위를 조건부로 사전에 입력해 두면 그 상황에 예정된 행위를 수행하는 객체
소프트웨어 결함
- 에러/오류 : 결함의 원인이 되는 것으로 일반적으로 사람의 실수
- 결함/버그 : 에러가 원인이 되어 소프트웨어 제품에 포함되어 있는 결함
- 실패/문제 : 결함이 실행될 때 발생되는 현상
결함 관리 프로세스 (계기검수재추최)
- 결함 관리 계획
- 결함 기록
- 결함 검토
- 결함 수정
- 결함 재확인
- 결함 추척
- 최종 결함 분석 및 보고서 작성
결함 분석 방법 (구고일)
- 구체화 : 결함의 원인을 찾기 위해 입력값, 테스트 절차, 환경을 파악
- 고립화 : 입력값, 테스트절차, 환경 중 어떤 요소가 결함 발생에 영향을 끼치는지 파악
- 일반화 : 결함 발생에 영향을 주는 요소를 최대한 일반화시키는 방법
결함 분류 (시기지문)
- 시스템 결함 : 비정상적 종료, 응답시간 지연, 데이터베이스 에러
- 기능 결함 : 요구사항 미반영, 스크립트 에러, 시스템 연동 시 오류
- GUI 결함 : UI 비일관성, 부정확한 메시지, 데이터 타입 표시 오류
- 문서 결함 : 문서의 기록이 원활하지 않은 경우에 발생하는 결함
결함 심각도별 분류
- 치명 Critical : 기능이나 제품의 테스트를 완전히 방해하거나 못하는 결함
- 주요 Major : 기능이 기대와 많이 다르게 동작, 기능이 해야 하는 것을 못하는 결함
- 보통 Normal : 일부 기능이 부자연스러운 결함
- 경미 Minor : 사용자의 불편함을 유발하는 결함
- 단순 Simple : 기능에는 영향이 없지만 수정되어야 하는 결함
애플리케이션 성능 측정 지표 (처응경자)
- 처리량 : 주어진 시간에 처리할 수 있는 트랙잰션 수
- 응답 시간 : 사용자 입력이 끝난 후 응답 출력이 개시될 때까지의 시간
- 경과 시간 : 사용자 요구 입력 시점부터 트랜잭션을 처리 후 출력이 완료될 때까지의 시간
- 자원 사용률 : 트랜잭션을 처리하는 동안 사용하는 CPU, MEM, 네트워크 사용량
배드 코드 : 다른 개발자가 로직을 이해가이 어렵게 작성된 코드
배드 코드 사례
- 외계인 코드 : 아주 오래되어 참고문서 또는 개발자가 없어 유지보수가 어려운 코드
- 스파게티 코드 : 정상적으로 동작하지만 사람이 코드를 읽으면서 작동을 파악하기 어려운 코드
- 알 수 없는 변수명 : 변수나 메서드 이름의 정의를 알 수 없는 코드
- 로직 중복 : 동일한 처리 로직이 중복되게 작성된 코드
배드 코드 유형 (오문의결침)
- 오염 : 기능을 수행하지 못하는 컴포넌트들이 존재
- 문서 부족 : 현재 코드와 문서가 일치하지 않음
- 의미 없는 이름 : 함수, 클래스 등 이름들이 명확한 의미가 없는 경우
- 높은 결합도 : 컴포넌트 간 높은 의존성을 가지는 경우
- 아키텍처 침식 : 아키텍처가 구별되지 않고 여러 솔루션으로 이루어져 변형된 상태
클린 코드 : 깔끔하게 잘 정리된 코드
클린 코드의 작성 원칙 (가단의중추)
- 가독성 : 이해하기 쉬운 용어 사용, 들여 쓰기 사용
- 단순성 : 한 번에 한 가지 처리만 수행
- 의존성 : 코드의 변경이 다른 부분에 영향이 없게 작성
- 중복성 제거 : 중복된 코드를 제거
- 추상화 : 클래스, 메서드, 함수에 대해 동일한 수준의 추상화 구현
소스코드 품질 분석 : 도구정적분석도구 (PCS), 동적분석도구 (AV)
리팩토링의 개념 : 프로그램의 기능 수정하지 않고 중복 제거 및 단순화를 통해 유지보수성 향상
리팩토링의 목적 : 유지보수성 향상, 유연한 시스템, 생산성 향상, 품질 향상
'정보처리기사 실기 요약본' 카테고리의 다른 글
[정보처리기사] 5.인터페이스 구현 (3) | 2023.03.11 |
---|---|
[정보처리기사] 11.응용 SW 기초 기술 활용 (0) | 2023.03.09 |
[정보처리기사] 9.소프트웨어 개발 보안 구축 (0) | 2023.03.09 |
[정보처리기사] 8. 서버프로그램 구현 (0) | 2023.03.09 |
[정보처리기사] 7. SQL 응용 (0) | 2023.03.09 |