[CSTS 요약 정리] 1. 테스트 개요

오류→결함→장애
- 장애: 결함에 의해 발생(결함이 있다고 반드시 장애가 발생하진 않음), 요구사항과 다르게 동작.
- 결함: 오류에 의해 발생, 장애가 생긴 원인, 소프트웨어를 구성하는 요소에 부족한점(ex. 부정확한 구현)으로 인해 발생
- 오류: 결함이 생긴 원인, 코딩 등 개발자의 실수

소프트웨어 개발단계에 따른 결함 해결 비용
- 유지보수>>>인수테스팅>>단위테스팅>코딩>설계>요구분석

테스팅 → 디버깅 → 재테스팅
- 디버깅이란? 결함의 위치 파악 → 결함 제거 (소스코드 수정)
- 재테스팅이란? 결함이 제거되었는지 확인하기 위해 초기에 결함을 검출한 테스트케이스를 이용하여 테스팅을 다시 수행

V&V: Verification(검증)과 Validation(확인)

하나의 테스트 대상에 복수개의 피처가 있을 수 있다.
피처에는 기능피처와 비기능 피처(성능, 보안 등)가 있다.

컴포넌트 테스트
- 스텁과 같은 개념이 필요하다. →모의 객체
- 컴포넌트 테스트를 잘 수행하기위한 FIRST원칙
  1. Fast: 빠르게 수행되어야 한다.
  2. Isolated: 다른 컴포넌트테스트에 의존하지않도록 해야한다.
  3. Repeatable: 테스트를 몇번 실행해도 동일한 결과가 나와야 한다.
  4. Self-Validating: 사람의 개입없이 테스트가 통과 되었는지 알수있도록 작성한다.
  5. Timely: 제때(테스트 대상 코드가 작성되는 시점) 수행되어야 한다.

통합테스트
- 점진적 통합 방식: 적은 수의 컴포넌트를 차례로 통합
  - 상향식 통합 방식: 하위 컴포넌트들을 시작으로 상위 컴포넌트들을 통합
    - 하위 컴포넌트(서비스에 필요한 공통 기능, 빈번하게 사용하는 코드)를 충분하게 테스트 할 수있다.
    - 테스트 스텁을 제공하는 비용이 들지 않는다.
  - 하향식 통합 방식 : 최상위 컴포넌트부터 하위 컴포넌트들을 통합
    - 테스트 스텁을 사용하여 상위 모듈을 테스트 → 하향식 통합 테스트는 많은 테스트 스텁이 필요하다.
    - 상위 컴포넌트의 결함(시스템 설계의 문제)을 빠르게 발견할수있다.
  - 샌드위치 통합방식

테스팅 방법
- 리그레션 테스트 : 소프트웨어가 변경된 후, 각 레벨테스트마다 수행
  - Retest-All
  - 선택적 리그레션 테스트
  - 테스트 최소화: 중복된 테스트케이스를 제거
  - 테스트 우선순위화: 우선순위가 높은 테스트케이스만을 활용 (빨리 많은 결함을 검출할수있도록 테스트케이스의 실행순서를 결정)
    - APFD: 테스트케이스의 실행수 대비 검출된 결함의 비율을 측정 (높은 APFD는 많은 결함을 빨리 검출하였다는 의미)
- 위험기반테스트: 위험 분석을 바탕으로 테스트에 대한 계획,설계,실행 등의 활동을 수행
  - 위험분석: 테스트 대상과 범위를 결정할 때 테스트 미수행에 따른 위험을 고려 → 테스트가 수행되지 않았을 때 위험수준이 높은 것은 테스트 대상에 반드시 포함
- 모델기반테스트 : 정형화되고 상세한 모델(테스트 절차를 수행할 수 있는 정보를 자동으로 추출할수있는 모델)을 바탕으로 테스트
  - 모델링에는 정형적 표현법(ex 의사결정표, UML상태다이어그램, UML액티비티다이어그램)을 사용할 수 있다.
  - 테스트 계획에서 종료까지 대부분의 활동을 자동화할수있다.
  - 개발단계 산출물의 결함을 검출할수 있다. → 장애 발생 시, 많은 비용 유발되는 소프트웨어에 적합
  - 모델을 구축하는 비용이 추가된다.

소프트웨어 품질특성 ☆암기☆
Q. 8가지 품질 주특성에 속하지 않는 것은?
Q. 기능적합성테스트의 부특성에 대한 설명으로 올바른 것은?
Q. 다음 보기에서 설명하는 품질특성은 무엇인지 주특성을 기재하시오.

주특성	부특성
기능적합성	기능완전성	모든 요구사항. 요구기능 얼마나 제공하는지
	기능정확성	정확한 결과. 얼마나 정확하게 동작하는지
	기능적절성	목적 달성률. 목적을 달성하는데 얼마나 도움주는지
성능효율성	시간반응성	응답.처리시간 및 처리율
	자원효율성	자원
	수용성	최대 한계
호환성	공존성	자원을 공유하며 기능 수행하는 정도
호환성	상호운영성	여러 시스템(구성요소)이 정보 교환 및 사용 가능한 정도 (IoT)
사용성	적합인식성	사용자의 필요
	학습용이성	사용법
	운영용이성	조작/제어 용이성
	사용자오류방지성	사용자오류방지성
	사용자인터페이스심미성	사용자 인터페이스 만족도
	접근성	누구나 사용 가능
신뢰성	성숙성	정상작동상태에서의 신뢰성
	가용성	사용 및 접근 가능한 정도
	결함허용성	결함이 있음에도 작동하는 정도
	복구성	데이터 복구 및 재설정
보안성	기밀성	접근권한있는 사람에게만
	무결성	데이터에 무단접근/변경 방지
	부인방지성	사건 및 행위 부인못하도록 입증
	책임성	행위자 추적
	인증성	실제 행위자임을 증명
유지보수성	모듈성	하나의 구성요소 변경이 미치는 영향 최소화
	재사용성	하나 이상의 시스템에서 사용. 또는 다른 자산 구축
	분석성	변경이 미치는 영향 평가 가능. 수정될 부분 식별 가능.
	변경용이성	결함이나 품질 저하없이 수정 가능
	테스트용이성	테스트 수행 용이성
이식성	적응성	다른 환경에 적용 가능
	설치용이성	특정 환경에 설치 및 제거 가능
	대체용이성	다른 제품으로 대체 가능

비기능 테스트

성능효율성 테스트
- 성능 테스트 방법에는 벤치마크 테스트(실제로 비교대상과 성능을 비교 시험, 평가)가 있다.
- 성능테스팅 종류
  - 부하테스팅: 부하를 계속 증가시킨다. (시스템의 임계점을 찾는다.)
  - 스트레스 테스팅: 임계점 이상의 부하를 가한다.
  - 스파이크 테스팅: 짧은 시간에 사용자가 몰릴때 시스템의 반응을 측정한다.
  - 내구성 테스팅: 오랜시간동안 시스템에 높은 부하를 가한다.

사용성 테스트
- 사용성의 수준을 측정하는 기준: 사용성은 효율성, 효과성, 만족도로 정의된다.
- 사용성 평가를 위한 방법
  - 휴리스틱 평가 : 사용성평가전문가가 체크리스트를 통해 사용성에 관한 문제점 도출
  - FGI : focus group interview. 공통점이 있는 사용자들이 그룹별로 모여 의견을 나눈다.
  - 인지적 워크쓰루 : 사전설명/안내 없이 제품을 사용하여 주어진 과제를 달성하도록 한다.

신뢰성 테스트
- 신뢰성 테스트는 주로 통계적 테스트 방법을 사용
  - 운영 프로파일(사용자들의 시스템 사용 패턴) 작성→ 운영 프로파일의 각 클래스의 발생확률에 따라 테스트케이스를 생성 → 오류가 발생하기까지 걸리는 동작시간 기록→ 신뢰성 추정

유지보수성 테스트
- 모듈성, 분석성, 재사용성, 변경용이성을 테스트 하기 위해서는 다음을 검토해야 한다.
  - 모듈화 정도 (fan-in, fan-out이 낮아야 한다.)
  - 모듈 간 결합도는 낮게 설계되어야 한다.
  - 모듈 응집도는 높을수록 좋다.
  - 모듈 복잡도 (순환복잡도가 75 이상이면 결함수정할때 새로운 결함 발생 가능성이 매우 높음)

소프트웨어생명주기모델
- 순차적 개발 모델
- 진화적 개발 모델
- 애자일 개발 모델

순차적 개발 모델: 요구사항이 개발초기에 완전히 정의되어있을 때 적합
- 폭포수 모델
  - 요구사항 분석 → 구조 설계 → 상세 설계 → 코딩 → 테스팅 → 운영
  - 요구사항이 개발자에게 익숙하거나, 요구사항 변경이 개발도중 빈번하지 않은 경우에 적합
  - 개발과정에서 소프트웨어에 관한 문서와 정보가 많이 산출된다.
  - 개발중심모델: 폭포수 모델은 테스트 작업을 코딩 단계 후의 한 단계(하나의 개발단계)로만 취급하는데, 이는 심각한 영향을 끼칠 수 있다. 개발이 완료될 무렵 결함을 발견하면, 수정할때 비용과 시간이 훨씬 많이 든다.
- V-모델
  - V&V(Verification&Validation) 모델
    - 검증은 시스템이 명세를 만족하는지 검사, 확인은 시스템이 사용자의 요구사항을 만족하는지 검사
  - 테스트활동이 개발이 시작됨과 동시에 시작된다.
  - 개발관련단계(SDLC)↘, 테스트관련단계(STLC)↗

진화적 개발 모델 : 요구사항이 명확하지 않을 때 적합
- 초기 요구사항 → 개발(이터레이션) → 고객평가 (새로운 요구사항 +피드백) → 개발(이터레이션) → 고객평가 (새로운 요구사항 +피드백) → ... → 최종 릴리즈
- 여러 이터레이션을 통해 계속 개선 발전시켜, 최종 완성품을 개발
- 각 개발 단계에서 테스트 관련 프로세스 수행
- 코드가 구현되면 컴포넌트테스트 → 통합테스트 → 시스템테스트 가 수행된다.

나선형 개발 모델
- 진화적 모델처럼 반복적·점진적으로 개발하는 모델
- 나선형의 각 타원에서 생명주기모델들을 여러개 혼합하여 개발할 수 있다. (메타생명주기모델)
- 개발주기가 시작될때마다 위험분석을 수행하므로, 잠재적 위험분야를 파악하여 해결해나갈 수 있다.
- 매단계에서 테스트가 이루어지므로, 많은 문제점을 해결할 수 있는 기회를 제공한다.
- 요구사항 → 설계 → 프로토타입 → 테스트 및 고객평가 → 재설계 → 프로토타입 → 테스트 및 고객평가 → ... → 구현 → 컴포넌트테스트 → 통합테스트 → 시스템테스트 → 인수테스트

애자일 개발 모델
- 애자일 선언
  - 사람 및 상호 의사교환이 프로세스나 도구보다 우선한다. (대표적인 애자일 방법인 XP는 개발자가 과도한 작업을 피하는 것이 중요하단 사실을 강조한다.)
  - 동작하는 소프트웨어가 포괄적인 문서보다 우선한다.
  - 고객과의 협력이 계약 협상보다 우선한다.
  - 변화에 반응하는 것이 계획을 따르는 것보다 우선한다.
- 반복적이면서 점진적인 개발 접근 방식(IDD)을 따른다.
  - IDD는 소프트웨어 개발주기를 여러개의 이터레이션으로 구분
- 이터레이션이 짧기 때문에, 고객이 실제 동작하는 소프트웨어(일의 진척도)를 빠르게 볼 수 있다.
- 애자일 방법론은 소프트웨어 테스트를 매우 강조한다.
  - TDD (테스트주도개발) : 프로그램에 대한 테스트 케이스를 먼저 작성하고, 이 테스트케이스로 테스트되는 실제 프로그램의 코드를 나중에 작성하는 방식 → 테스트되지않는 코드가 없어 결함발생가능성 줄어든다. 테스트용이성 높은 코드가 산출된다.
  - TDD프로세스
    - 실패하는테스트 작성 → 통과하는 테스트 코드 작성 → 리팩토링 (코드개선)

테스트 스크립트 : 테스트 절차를 문서로 기록하는 대신에, 자동화도구가 해석하고 실행하는 언어로 작성한 것

728x90

'CS기본지식' 카테고리의 다른 글

[CSTS 합격 후기] 2024.3.16 CSTS 자격시험(FL) 합격 후기/공부방법 (3)	2024.03.30
[CSTS 요약 정리] 3. 테스트 프로세스 (0)	2024.03.10
[CSTS 요약 정리] 2. 테스트 설계기법 (0)	2024.03.02

back end tutorial

[CSTS 요약 정리] 1. 테스트 개요

'CS기본지식' 카테고리의 다른 글

티스토리툴바

[CSTS 요약 정리] 1. 테스트 개요

'CS기본지식' 카테고리의 다른 글

관련글

티스토리툴바