일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 성화봉송주자
- 다음 지도 api
- 이분탐색
- 평창동계올림픽
- yolo
- lower_bound
- 다음 API
- Segment Tree
- 위상정렬
- boj
- upper_bound
- 안드로이드 스튜디오
- 삼성 코딩테스트
- 성화봉송
- BFS
- 캘리그라피
- 생활코딩
- 다이나믹 프로그래밍
- multiset
- 외판원 순회
- 비트마스크
- 그리디 알고리즘
- DP
- 인간이 그리는 무늬
- 백트레킹
- MST
- BOJ 2098
- 언어의 온도
- 창훈쓰다
- 영어회화 100일의 기적
- Today
- Total
Hoon222y
[1231-1] / Test Design Techniques (명세 기반, 구조 기반) 본문
[접은 부분 추가하기 ]
+) 블랙박스 기법과 화이트박스 기법 차이 추가
10p부터 중간부터 필기 시작하고 있음.
프로그램 실행 여부 |
동적 테스트 (Dynamic Test) |
프로그램을 실행하며 소프트웨어 시스템의 기능, 자원 사용 및 성능 확인 등 비기는 테스트. 모든 레벨에서 테스트 가능 . 블랙박스 또는 화이트박스 테스트로 수행 |
정적 테스트 (Static Test) |
코드를 실행하지 않고 테스트 하는 기법으로 검토같은 수동적 기법과 정적 분석 같은 자동화 된 기법이 있음. 정적 테스트는 개발 프로세스 초기에 개발 산출물들에 대해 결함을 발견함으로써 개발 비용을 낮추는데 도움이 됨. 코드의 일부를 가지고도 툴, 혹은 코드리뷰를 통해서 테스트가 가능하다. |
- 즉 , 동적 테스트와 정적 테스트의 차이는 동작 시키느냐 안시키느냐의 차이이다.
품질 특성에 따른 분류 |
기능 테스트 |
기능 요구사항 검증 |
사용성 테스트 |
소프트웨어를 쉽게 사용할 수 있는 정도. 편의 기능 제공 정도를 측정하고 검증 확인하는 테스트 |
|
성능 테스트 |
시스템에 부하를 주면서 응답시간, 처리량, 속도 등 성능 지표 추이 측정 |
|
스트레스 테스트 |
복합 데이터 또는 대량의 데이터를 이용한 고부하 장기 테스트 |
|
회복 테스트 |
문제가 발생했을 때 복귀 능력 검증 |
|
보안 테스트 |
외부의 침입이나 해킹에 대응하는 능력 검증 |
접근방법 |
탐색적 테스트 (Exploratory Test) |
테스트 엔지니어의 경험, 지식과 직관에 기초한 테스트. 소프트웨어 시스템 분석을 위한 문서가 제대로 준비되어 있지 않은 경우 시스템 테스트에 유용 |
위험기반 테스트 (Risk-based Test) |
리스크 분석과 결정된 우선순위에 따른 테스팅 |
기타 |
설치/ 업그레이드 테스트 |
소프트웨어 제품의 설치 또는 제거. 이전 버전에서 업그레이드 확인 |
회기 테스트 |
앞 단계에서 정상적으로 수행된 테스트를 변경된 소프트웨어 시스템에 대해서 다시 테스트를 수행함으로써 변경에 의한 영향을 받음 Automated test의 좋은 후보이다. |
|
알파 테스트 |
개발이 거의 끝나는 단계이나 minor 변경이 있는 상태에서 개발팀 내 구성원이 아닌 사람 또는 사용자들에 의해 수행되는 테스트 |
|
베타 테스트 |
개발이 거의 끝나는 단계에서 출시 이전 출시에 문제가 되는 결함이 없을을 확인하기 위해 개발팀 내 구성원이 아닌 사람 또는 사용자들에 의해 수행되는 테스트 |
[Test Design Techniques]
<명세 기반 테스트 설계 기법>
- 등기 분항 / 동등 분할 ( Equivalence Partitioning )
명세서를 기준으로 여러 가능한 input에 대해 동일한 결과를 갖는 값들을 하나의 equivalence class( 또는 partition)로 구분하고 , 각 class 별로 input을 선택하는 테스트
모든 테스트에서 직관적으로 사용됨.
- 경계값 분석 ( Boundary Value Analysis )
경계 부분에 해당되는 입력 값에서 결함이 발견될 확률이 경험적으로 높자는 것 고려
경계값 : Min-1 , Min , Min+1, Normal , Max-1 , Max , Max+1
예외 처리 확인에 좋음
ex) 1부터 10까지의 값을 입력받을 수 있다면 입력값으로 {0,1,2,5,9,10,11}를 사용한다.
- 결정 테이블 테스팅( Decision Table Testing )
시스템이 구현해야 하는 복잡한 비즈니스 규칙을 condition에 따른 Action Table로 구성하여 테스트케이스 개발
<구조 기반 테스트 설계 기법>
- 화이트 박스 방식이랑 비슷
- 제어 흐름 테스트 (Control flow testing)
- 프로그램 코드상의 수행경로를 정의하고, 그 경로를 cover하는 테스트케이스 개발/수행
Level of Code coverage
- 커버리지란 품질에 얼마만큼 수행했는지를 말한다. ( 전체 코드에서 실행된 코드의 비율은 몇 %인가? ) 정형화된 비율이 딱 나오는데 그 비율을 정하는 기준이 나누어져 있다.
1. 구문 커버리지( Statement coverage )
2. 결정 커버리지 ( Decision Coverage, Branch Coverage )
3. 조건 커버리지 ( Condition Coverage )
4. 조건/ 결정 커버리지
5. 다중 조건 커버리지
1. 구문 커버리지
- 테스트에 의해 실행된 구문이 몇%인지 측정
2. 결정 커버리지
- 테스트에 의해 실행된 결정 포인트 내의 전체 조건식이 최소한 참 한 번, 거짓 한 번의 값을 가지는지 측정
- 개별 조건식의 개수와 관계없이 테스트 케이스의 최소 개수는 2개로 도출
3. 조건 커버리지
- 전체 조건식의 결과와 관계없이 각 개별 조건식이 참 한 번, 거짓 한 번을 모두 가지도록 조건식을 조합
(문제 예제들 학습하기)
'코딩 > 교육' 카테고리의 다른 글
[0102-1] UML / 구조 모델 (클래스 / 객체 / 패키지 다이어그램) (0) | 2019.01.02 |
---|---|
[1231-2] UML (0) | 2018.12.31 |
[1228] Secure Coding (0) | 2018.12.28 |
[1226-4] 전략(Strategy) 패턴 / 탬플릿 메소드 패턴 (0) | 2018.12.27 |
[1226-3] 추상 팩토리 패턴(abstractFactory) (0) | 2018.12.27 |