정적 테스트: Difference between revisions
From IT Wiki
No edit summary |
No edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 13: | Line 13: | ||
* 개발 전주기에 반복적으로 수행될 수 있다. | * 개발 전주기에 반복적으로 수행될 수 있다. | ||
== | == 이점 및 효과성 == | ||
* [[정형 기술 검토 | * 이점 | ||
* [[ | ** 조기 결함 발견 및 수정 | ||
* [[소프트웨어 | ** 개발 생산성 향상 및 개발 기간 단축 | ||
** 테스팅 비용 및 시간 단축 | |||
** 커뮤니케이션 향상 | |||
* [[동적 테스트]] 대비 발견하기 쉬운 결함 | |||
** 표준 위반 | |||
** 요구사항 결함 | |||
** 개발 설계 결함 | |||
** 불충분한 유지보수성 | |||
** 부정확한 인터페이스 명세 | |||
== 종류 == | |||
[[파일:정형기술검토 Formal 정도.jpg]] | |||
{| class="wikitable" | |||
! 구분 | |||
! Inspection | |||
! Peer Review | |||
! Walk Through | |||
|- | |||
| 공식성 | |||
| Formal | |||
| Mid Formal | |||
| Informal | |||
|- | |||
| 개념 | |||
| 산출물 대상 공식 검토 | |||
| 개발단계별 산출물 대상 동료 검토 | |||
| 소팀 내 결함 해결방안 상호 검토 | |||
|- | |||
| 목적 | |||
| 요구사항 확인 | |||
| 계획의 적합성 평가 | |||
| 결함 발견 | |||
|- | |||
| 기법 | |||
| 이해관계자 산출물 검사 | |||
| 검토 회의 | |||
| 집중 검토 기법 | |||
|- | |||
| 규모 | |||
| 3 ~ 6명 | |||
| 3명 이상 | |||
| 2 ~ 7명 | |||
|- | |||
| 참석자 | |||
| 이해관계자 | |||
| 경영자, 개발 관리자 | |||
| 개발자 | |||
|- | |||
| 리더십 | |||
| 훈련된 중재자 | |||
| 선임 관리자 | |||
| 개발자 본인 | |||
|- | |||
| 결함 기록 | |||
| 공식 기록 | |||
| 공식 기록 | |||
| 개인별 기록 | |||
|} | |||
=== Inspection === | |||
* 공식적 검사 | |||
* 프로그램을 실행하지 않고 산출물을 대상으로 공식적 검토, 결함 발견 과정 | |||
* 구성: 이해 관계자, 중재자, 검토자, 기록자 | |||
=== Peer Review === | |||
* 동료 검토 | |||
* 프로젝트 수행과정에서 각 단계 별 산출물, 제품에 대해 동료들이 상호교차하여 검토 수행 활동 | |||
* 구성: 프로젝트 팀원, 체크리스트 | |||
=== WalkThrough === | |||
* 비공식 검토 | |||
* 프로젝트 개발 초기에 팀 내에서 수행하는 검토 과정 | |||
* 구성: 프로젝트 팀원 | |||
== 같이 보기 == | |||
* [[정형 기술 검토]] | |||
* [[동적 테스트]] | |||
* [[소프트웨어 테스트]] | |||
== 참고 문헌 == | |||
* [http://blog.naver.com/PostView.nhn?blogId=jtum&logNo=220920845393 지식스폰지] | |||
* 개발자도 알아야할 소프트웨어 테스팅 실무, STA |
Latest revision as of 00:09, 11 March 2020
- 상위 문서: 소프트웨어 테스트
- Static Test
- 소프트웨어를 실행하지 않고 코드나 문서를 리뷰하는 방식 등으로 수행하는 소프트웨어 테스트 종류
테스트 대상[edit | edit source]
- 소스 코드
- 개발 산출물
- 테스트 산출물
수행 시기[edit | edit source]
- 동적 테스트를 수행하기 전에 수행하는 것이 권장된다.
- 개발 전주기에 반복적으로 수행될 수 있다.
이점 및 효과성[edit | edit source]
- 이점
- 조기 결함 발견 및 수정
- 개발 생산성 향상 및 개발 기간 단축
- 테스팅 비용 및 시간 단축
- 커뮤니케이션 향상
- 동적 테스트 대비 발견하기 쉬운 결함
- 표준 위반
- 요구사항 결함
- 개발 설계 결함
- 불충분한 유지보수성
- 부정확한 인터페이스 명세
종류[edit | edit source]
구분 | Inspection | Peer Review | Walk Through |
---|---|---|---|
공식성 | Formal | Mid Formal | Informal |
개념 | 산출물 대상 공식 검토 | 개발단계별 산출물 대상 동료 검토 | 소팀 내 결함 해결방안 상호 검토 |
목적 | 요구사항 확인 | 계획의 적합성 평가 | 결함 발견 |
기법 | 이해관계자 산출물 검사 | 검토 회의 | 집중 검토 기법 |
규모 | 3 ~ 6명 | 3명 이상 | 2 ~ 7명 |
참석자 | 이해관계자 | 경영자, 개발 관리자 | 개발자 |
리더십 | 훈련된 중재자 | 선임 관리자 | 개발자 본인 |
결함 기록 | 공식 기록 | 공식 기록 | 개인별 기록 |
Inspection[edit | edit source]
- 공식적 검사
- 프로그램을 실행하지 않고 산출물을 대상으로 공식적 검토, 결함 발견 과정
- 구성: 이해 관계자, 중재자, 검토자, 기록자
Peer Review[edit | edit source]
- 동료 검토
- 프로젝트 수행과정에서 각 단계 별 산출물, 제품에 대해 동료들이 상호교차하여 검토 수행 활동
- 구성: 프로젝트 팀원, 체크리스트
WalkThrough[edit | edit source]
- 비공식 검토
- 프로젝트 개발 초기에 팀 내에서 수행하는 검토 과정
- 구성: 프로젝트 팀원
같이 보기[edit | edit source]
참고 문헌[edit | edit source]
- 지식스폰지
- 개발자도 알아야할 소프트웨어 테스팅 실무, STA