반응형
애플리케이션 테스트 : 애플리케이션에 잠재되어 있는 결함을 찾아내는 일련의 행위 또는 절차
애플리케이션 테스트의 기본원리
- 완벽한 테스트 불가능 : 소프트웨어의 잠재적인 결함은 줄일수있지만 소프트웨어에 결함이 없다고 증명할 수는 없음
- 파레토법칙 : 애플리케이션의 20%에 해당하는 코드에서 전체 결함의 80%가 발견된다는 법칙
- 살충제 패러독스 : 동일한 테스트 케이스로 동일한 테스트를 반복하면 더이상 결함이 발견되지 않는 현상
- 테스트는 정황 의존 : 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로, 정황에 따라 테스트를 다르게 수행해야한다
- 오류-부재의 궤변 : 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 해당 소프트웨어는 품질이 높다고 말할 수 없는 것
- 테스트와 위험은 반비레: 테스트를 많이 하면 미래에 발생할 위험을 줄일 수 있다
- 테스트의 점진적 확대 : 테스트는 작은 부분에서 시작하여 점점 확대하며 진행해야함
- 테스트의 별도 팀 수행 : 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함
프로그램 실행 여부에 따른 테스트
- 정적테스트 : 프로그램을 실행하지 않고 명세서나 소스코드를 대상으로 테스트 하는 것(워크스루, 인스펙션, 코드 검사)
- 동적테스트 : 프로그램을 실행하여 오류를 찾는 테스트(화이트 박스 테스트, 블랙 박스 테스트)
테스트 기반에 따른 테스트
- 명세기반테스트 : 사용자의 요구사항에 대한 명세를 빠짐없이 테스트 케이스로 만들어 구현하고 있는 지 확인하는 테스트(동등분할, 경계값분석)
- 구조기반테스트 : 소프트웨어 내부의 논리 흐름에 따라 테스트케이스를 작성하고 확인하는 테스트(구문기반, 결정기반, 조건기반 등)
- 경험기반테스트 : 유사 소프트웨어나 기술 등에 대한 테스터의 경험을 기반으로 수행하는 테스트(에러추정, 체크리스, 탐색적테스팅 등)
시각에 따른 테스트
- 검증(Verification)x테스트 : 개발자의 시각에서 제품의 생산 과정을 테스트 하는 것
- 확인(Validation)테스트 : 사용자의 시각에서 생산된 제품의 결과를 테스트 하는 것
목적에 따른 테스트
- 회복테스트 : 시스템에 여러가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 테스트
- 회귀테스트 : 소프트웨어의 변경 또는 수정된 코드에 새로운 결함이 없음을 확인하는 테스트
- 강도테스트 : 시스템에 과도한 정보량이나 빈도 등을 부과하여 과부하시에 소프트웨어가 정상적으로 실행되는지를 확인하는 테스트
- 안전테스트 : 시스템에 설치된 시스템 보호 도구가 불법적인 침입으로부터 시스템을 보호할 수 있는지를 확인하는 테스트
- 구조테스트 : 소프트웨어 내부의 논리적인 경로, 소스코드의 복잡도를 평가하는 테스트
- 성능테스트 : 소프트웨어의 실시간 성능이나 전체적인 효율성을 진단하는 테스트, 소프트웨어의 응답시간, 처리량 등을 테스트
- 병행테스트 : 변경된 소프트웨어와 기존 소프트웨어에 동일한 데이터를 입력하여 결과를 비교하는 테스트
화이트 박스 테스트 : 모듈의 원시코드를 오픈시킨 상태에서 원시코드의 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법
- 기초 경로 검사 : 테스트케이스 설계자가 절차적 설계의 논리적 복잡성을 측정 할 수 있게 해주는 테스트 기법
- 제어 구조 검사
- 조건검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트 하는 테스트 설계 기법
- 루프검사 : 프로그램의 반복 구조에 초점을 마주처 실시하는 테스트케이스 설계 기법
- 데이터 흐름 검사 : 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트케이스 설계 기법
화이트 박스 테스트의 검증 기준
- 문장 검증 기준 : 소스 코드의 모든 구문이 한번 이상 수행되도록 테스트 케이스를 설계
- 분기 검증 기준 : 소스 코드의 모든 조건문이 한번 이상 수행되도록 테스트 케이스를 설계
- 조건 검증 기준 : 소스 코드의 모든 조건문에 대해 조건이 true인 경우가 한번 이상 수행되로록 테스트 케이스를 설계
- 분기/조건 기준 : 소스코드의 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한번 이상 수행되도록 테스트케이스를 설계
블랙 박스 테스트 : 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 테스트
- 동치 분할 검사(동치 클래스 분해, 동등 분할 기법로도 나올 수 있음) : 프로그램의 입력조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정하고 해당 입력자료에 맞는 결과가 출력되는지를 확인하는 기법
- 경계값 분석 : 입력조건의 중간값보다 경계값에서 오류가 발생될 학률이 높다는 점을 이용하여 입력조건의 경계값을 테스트케이스로 선정하여 검사하는 기법
- 원인 효과 그래프검사 : 입력데이터간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석한 다음 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
- 오류 예측 검사 : 과거의 경험이나 확인자의 감각으로 테스트 하는 기법
- 비교 검사 : 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트 하는 기법
개발단계에 따른 애플리케이션 테스트 순서
- 단위테스트 : 코딩 직후 소프트웨어 설계의 최소 단위인 모듈이나 컴포넌트에 초점을 마주처 테스트 하는 것
- 통합테스트 : 단위테스트가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 테스트를 의미
- 시스템테스트 : 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 점검하는 테스트
- 인수테스트 : 개발한 소프트웨어가 사용자의 요구사항을 충족하는지에 중점을 두고 테스트하는 방법
인수테스트
- 사용자 인수테스트 : 사용자가 시스템 사용의 적절성 여부를 확인
- 운영상의 인수테스트 : 시스템관리자가 시스템 인수시 수행하는 테스트 기법
- 계약 인수 테스트 : 계약상의 인수/검수 조건을 준수하는지 여부를 확인
- 규정 인수 테스트 : 소프트웨어가 정부지침, 법규, 규정 등 규정에 맞게 개발되었는지를 확인
- 알파 테스트 : 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법
- 베타 테스트 : 선정된 최종 사용자가 여러명의 사용자 앞에서 행하는 테스트 기법
통합테스트
- 하향식 통합 테스트 : 프로그램의 상위모듈에서 하위모듈방향으로 통합하면서 테스트 하는 기법(깊이 우선 통합법, 넓이 우선 통합법)
- 스텁 : 제어모듈이 호출하는 타 모듈의 기능을 단순히 수행한느 도구, 일시적으로 필요한 조건만을 가지고 있는 시험용 모듈
- 상향식 통합 테스트 : 프로그램의 하위모듈에서 상위모듈방향으로 통합하면서 테스트하는 기법
- 드라이버 : 테스트 대상의 하위 모듈을 호출하고 파라미터를 전달하고 모듈 테스트 수행 후의 결과를 도출하는 도구
- 회귀 테스트 : 통합테스트로 인해 변경된 모듈이나 컴포넌트에 새로운 오류가 있는지 확인하는 테스트
테스트 오라클 : 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동을 말한다
테스트 오라클 특징
- 제한된 검증 : 테스트 오라클을 모든 테스트케이스에 적용할 수 없다
- 수학적 기법 : 테스트 오라클의 값을 수학적 기법을 이용하여 구할 수 있다
- 자동화 가능 : 테스트 대상 프로그램의 실행, 결과비교, 커버리지 측정 등을 자동화 할 수 있다
테스트 오라클의 종류
- 참 오라클 : 모든 테스크케이스의 입력값에 대해 기대하는 결과를 제공하는 오라클
- 샘플링 오라클 : 특정한 몇몇 테스트 케이스의 입력값들에 대해서만 기대하는 결과를 제공하는 오라클
- 추정 오라클 : 특정 테스트 케이스의 입력값에 대해 기대하는 결과를 제공하고 입력 값들에 대해서는 추정으로 처리하는 오라클
- 일관성 검사 오라클 : 애플리케이션에 변경이 있을 때 테스트 케이스의 수행 전과 후의 결과값이 동일한지를 확인하는 오라클
애플리케이션 성능 분석
애플리케이션 성능 측정 지표
- 처리량 : 일정시간 내에 애플리케이션이 처리하는 일의 양
- 응답시간 : 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간
- 경과시간 : 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간
- 자원사용률 : 애플리케이션이 의뢰한 작업을 처리하는 동안의 CPU사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률
성능 테스트 도구 : 애플리케이션의 성능을 테스트하기 위해 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구
시스템 모니터링 도구 : 애플리케이션이 실행되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구
소스코드 최적화
클린코드 : 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순 명료한 코드
나쁜코드 : 프로그램의 로직이 복잡하고 이해하기 어려운 코드
- 스파케티코드 : 코드의 로직이 서로 복잡하게 얽혀있는 코드
- 외계인코드 : 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 코드
클린코드 작성원칙
- 가독성 : 누구든지 코드를 쉽게 읽을 수 있도록 작성함
- 단순성 : 코드를 간단하게 작성함
- 의존성 배제 : 코드가 다른 모듈에 미치는 영향을 최소화함
- 중복성 최소화 : 코드의 중복을 최소화함
- 추상화 : 상위클래스에서는 간략하게 애플리케이션의 특성을 나타내고 상세 내용을 하위클래스에서 구현
소스코드 품질 분석 도구 : 소스 코드의 코딩스타일, 코딩표준, 코드의 복잡도 등을 발견하기 위해 사용하는 분석 도구
- 정적분석도구(static analysis) : 작성한 소스코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구
- 동적분석도구(dynamic analysis) : 작성한 소스코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구
반응형
'정보처리기사' 카테고리의 다른 글
소프트웨어 개발 보안 (0) | 2023.09.11 |
---|---|
운영체제 / 프로토콜 / 네트워크 (0) | 2023.09.10 |
미들웨어 / 인터페이스 / 화면설계 / 소프트웨어 품질 (0) | 2023.09.02 |
모듈 / IPC / 디자인 패턴 (0) | 2023.09.02 |
통합구현 / 웹서비스 활용 / 아키텍처 / 객체지향 (0) | 2023.08.27 |