공부하면서 참 딴짓을 많이 했던 것 같다.
하기 싫기도 하고, 정리하다가 어디까지 정리를 하는게 맞나... 싶기도 하고
공부법 영상 같은거 괜히 찾아보고.
영향을 많이 받은 건 한페이지 공부법 ? 그런 거였다.
(한 페이지에 목차만 적어놓고 연상하는 기억을 활용하는..? 뭔가 그런거였는데)
결국 근데 정리하다 보면 한페이지는 절대 안되던데....
어쨌든 레쓰고 입니다
제 1장 테스트 개요
테스트 목적
결함 검출, 제품 품질 개선/평가, 의사결정 지원, 개발 프로세스 개선 지원
오류Error→ 결함Defect→ 장애Failure
사람이 잘못해서 오류만들고,
오류 때문에 결함이 발생,
결함은 장애를 일으킨다.
but. 결함이 무조건 장애는 아니다. (지금은 장애 없는 불발탄 지뢰같은 결함이 있음)
소프트웨어 개발단계에 따른 결함 해결 비용
유지보수>인수테스팅>단위테스팅>코딩>설계>요구 분석
(유지보수와 같은 마지막 단계로 갈수록 많이 높아짐)
테스팅하고 디버깅하고 재테스팅 하는거임.
상식적으로 보면 된다.
테스트 대상과 테스트 레벨
대상 : SW(전체, 또는 일부)
레벨 : 테스트 대상의 규모에 따라 구분
- 컴포넌트(단위) 테스트 : 개별적인 모듈의 테스트 ➔ 컴포넌트(작은 단위)
- 통합 테스트 : 전체 컴포넌트의 연결 ➔ 컴포넌트(모듈)들의 통합
- 시스템 테스트 : 전체
*나중에 다시 자세히 다룬다.
피처와 테스트 유형
피처(Feature) : 테스트 대상에 테스트하는 측면, 관점, 특성
- 종류 : 기능피처, 비기능피처
- 테스트 계획 수립 시 식별하여 테스트 범위로 기술한다.
- 테스트 설계 활동을 통해 피처 구체화화여 테스트 케이스(TC), 절차 개발
테스트 유형
기능에 따라 구분함
기능 적합성, 사용성, 신뢰성, 호환성, 이식성, 성능 효율성, 보안성, 유지 보수성
*앞글자 따서 기사신호이성보유 => (컴통시인과 구분하기)
https://olivegogo.tistory.com/294
[CSTS] 내용정리 및 암기법 1. 테스트 개념 및 용어 (7문제)
* 테스트 목적 * - 시스템이 정해진 요구사항을 만족하는지, 주어진 표준 등을 준수하는지 확인 - 결함을 검출해서 SW품질을 개선하기 위한 목표 - 어떤 단계에서 결함이 발생하는지 분석, 결함이
olivegogo.tistory.com
암기법 아이디어 감사합니다....
테스트 설계 기법(정적, 동적)
: 테스트 대상의 결함을 효과적으로 검출하려고 하는 것
1. 정적 테스트 (리정)
*대표적으로 리뷰와 정적분석
- 리뷰 : 개발 단계 별로 산출물이 품질 목표에 부합하는지 점검, 검토 결함 검출
대표적으로 : 관리 리뷰, 기술 리뷰, 인스펙션, 감사, 워크쓰루
- 정적 분석 : 결함으로 판단되는 패턴이 소스코드에 있는지 분석
코딩표준, 복잡도 측정**,**자료흐름 분석(시험범위 아님)
*T는 테스트
특징
- T대상 실행하지 않고 T수행함 = 실행 환경 필요 없음
- 소스 코드가 작성되기 이전에 사용가능 ➔ 빠르게 검출해서 보다 경제적이다. (요구분석, 구조설계, 상세설계 단계 등 에서 산출물에 대한 테스트 수행할 수 있음. )
- 자동화 도구 사용의 장점
- 동적 T에서 검출하기 어려운 오류 찾아냄
2. 동적 테스트 (명구경)
*TC는 테스트 케이스
명세 기반 방법
: 요구 사항 기반 = 소스 코드없이 TC결정 (=블랙박스 테스트)
= 내부 논리 참조 없이 요구 명세, 설계 정보로 테스트 케이스 개발, 여러 전 과정에 활용 가능 (컴통시인 등)
구조 기반 방법
: 소스 코드 참고하고 TC결정(=Whitebox Test) 내부 논리를 기반으로 테스트 케이스 개발 (= 구조적 테스트, 화이트박스 테스트, 글래스박스 테스트)
경험 기반 테스트
: 테스트케이스가 아닌, 경험과 직관을 활용해서 수행
- 오류 추정*
*이번 시험에 나왔었다.
처음엔 경험 기반 테스트 말하는거 아닌가 했는데 경험 기반 테스트의 ~ 이런 방식이 무엇인가? 라고 해서...
걍 오류 추정 인가...? 하고 그렇게 적었다.
그 정도는 그냥 외우고는 있어야 한다. 경험 기반 테스트에는 두가지가 있었지..? 각각 이런거지? 이런 방식 추천
- 개발자가 범할 수 있는 실수 추정, 이에 따른 결함 검출되도록 TC 설계
- T 대상에 테스터의 직관 경험을 바탕으로 개발자가 범할 실수 나열, 예측하여 테스트
- 명세 기반 테스트와 함께 사용될 수 있음.
- 탐색적 테스트*
- 사전에 구체적으로 TC 설계하고 기록, T대상에 대한 이해, TC설계, T실행 병행하는 방식
- T대상에 대한 이해를 바탕으로 즉석에서 TC를 결정 후 문서화 없이 T바로 수행
제 2장 테스트 분류와 테스팅 방법,
제 3장 SW 개발 단계와 테스트
테스트와 품질 평가(V모델 그림)
V&V: Verification(검증)과 Validation(확인)
품질 보증 > V&V > 테스트
테스트 레벨에 의한 분류 (컴통시인)
- 컴포넌트 테스트
- 통합 테스트
- 시스템 테스트
- 인수 테스트
1. 컴포넌트 테스트(스텁, FIRST)
: 시스템을 구성하는 단위 모듈을 대상으로 독립적으로 테스트
- 스텁(stub)과 같은 개념이 필요하다. => 모의 객체(mock)
- FIRST 원칙(컴포넌트 테스트를 잘 수행 하기 위한) Fast: 빠르게, Isolated(격리된):의존 안하는, Repeatable(반복가능한)동일한, Self-Validating(스스로 검증하기), Timely: 시기 적절한
2. 통합 테스트 (상향,하향,샌드위치,빅뱅)
: 컴포넌트(단위)를 통합하며 테스트
- 컴포넌트 들 통합했을 때, 상호 연동이 잘 되는지 검사하는 테스트
- 연결된 컴포넌트의 기능적 측면에 초점 : 연결된 컴포넌트의 정상 동작여부 모두 확인 (연결 후에 또 잘 안될 수 있음)
- 점진적 통합 방식(상향식 통합, 하향식 통합, 샌드위치),
- ↔ 빅뱅 방식 그냥 하면 된다. 대신 오동작시 결함 위치를 찾기 어렵다.
3. 시스템 테스트(전체, 기사신호..포함)
: 통합테스트 완료 후 전체 시스템 검증
- 기능 충족 여부, 비기능적 요구사항까지 모두 만족하는지 검증(기사신호이성보유 까지)
4. 인수 테스트(알파,베타)
: 고객의 입장에서 평가
- 결함 검출이 아니라 고객이 시스템을 인수해도 되는지 평가하는 것.
- 유형 : 알파테스트(알파남임 개발자 환경에서), 베타테스트(맘대로 ****해주세요)
Exercise Q. 시스템 테스트와 인수 테스트는
사용자도 사용 실행 주체가 될 수 있다.
테스팅 방법 (리그레션 테스트)
: 소프트웨어가 변경된 후**,** 각 레벨 테스트마다 수행
변경이 결함이 생기진 않았는가? , 기존 요구 사항 충족 하는가?
Retest-All, 선택적 리그레션 테스트, 테스트 최소화(중복된 테스트케이스를 제거), 테스트 우선순위화
- APFD = 감지된 결함의 평균 비율
→ APFD 가 높으면 효율이 좋다.
리그레션 수행 절차
애플리케이션 변경 ➔ 컴포넌트 ➔ 통합 ➔ 시스템 ➔ 테스트 유지보수