15. 정적 테스팅 (Static Testing)

소프트웨어 개발은 다음과 같이 동작한다.

 

요구사항정리 => 분석 => 설계 => 코딩 => 테스트

 

(정적테스트) ( 동적테스트 )

 

 

 

정적테스팅 vs 동적테스팅

 

- 동적테스팅

: 프로그램을 실제로 실행하여 결과를 확인하는 방법

: 주어진 입력 값에 대해 예상한 결과 값이 출력되는지 확인

: Validation

: 정적 테스팅에 비해 정확성을 뛰어나나 완전하진 않음

 

- 정적 테스팅

: 프로그램을 실제로 실행하지 않고, SW의 정ㅈ거인 형태를 검사, 검토, 분석하여 결함을 찾는 활동

: Run-time 시 발생할 수 있는 문제 현상에 대한 원인ㅇ르 파악하고 프로그램 코드를 분석하는 방법

: Verification 

: Checklist나 자동화된 도구를 사용하여 산출물 검증

 

 

정적테스트

=> 리뷰

    => 동료 검토

        => 탁상검사

        => 워크쓰루

        => 인스펙션

    => 공식 검토

=> 정적 분석

    => 심볼릭 실행

    => 자료흐름 분석

 

 

 

정적테스트 - 리뷰 

: 프로젝트 담당자, 관리자, 사용자 등의 이해 당사자에게 제품에 대한 의견이나 승인을 받기 위해 수행되는 프로세스나 회의

: 모든 산출물에 대해 리뷰가 가능함.

 

리뷰의 목적

: 산출물이 요구사항을 충족하는지

: 산출물로 부터 결함을 일찍 효과적으로 발견하고 제거

: 결함이 필드에 반영되는거 방지

: 산출물에 대한 위험 감소 및 신뢰 확보

 

리뷰의 효과

: 다른 관점의 확보

: 지식 전달

: 개발 시간 단축

: 재작업 및 테스팅 노력 감소

: 프로세스 개선

 

 

정적테스트 - 리뷰 - 동료검토

: 기술적인 내용이나 품질을 평가하기 위해 저자와 동료에 의해 산출물을 평가하는 소프트웨어 검토 방법

: 리뷰 대상은 모든 산출물.

 

정적테스트 - 리뷰 - 동료검토 유형

비공식 리뷰	공식 리뷰
공식적인 절차, 표준x	공식적인 절차, 표준 o
참여자 별 책임이 명확하지 않음	참여자 별 책임이 명확

 

정적테스트 - 리뷰 - 동료검토 - 탁상검사

: 1명 또는 1명 이상의 동료에게 개발 산출물에 대한 검토를 요청하여 결함을 찾아내는 기법

 

- 작성자가 동료에게 개발 산출물 검토를 요청하고 동료는 산출물에 대한 검토결과를 작성자에게 전달

- 팀을 구성하여 검토를 진행하지 않고, 개별적으로 검토를 진행

- 가장 비공식적인 형태의 동료 검토 방식

 

 

정적테스트 - 리뷰 - 동료검토 - 워크쓰루

: 개발 산출물을 작성하는 중에 산출물을 검토하고 결함을 찾아내는 기법

 

- 주로 작성자의 요청에 의해 이루어지며, 완성된 결과물이 아닌 중간산출물을 대상으로함

- 개발 산출물 작성자에 의해 진행 및 제어가 이루어진다.

- 참가자의 역할이 명확히 정의되지 않음

- 참가자들은 작업물의 개요정도만 파악하고 참여

- 산출물에 대해 자유롭게 토론하고 결함 찾고 조언

- 후속작업에 대한 검사 생략 가능

- 인스펙션에 비해 비형식적인 동료 검토

 

- 워크쓰루 단계

* 진행준비 - 계획 - 개요 - 준비 - 검토 - 후속작업

 

정적테스트 - 리뷰 - 동료검토 - 인스펙션

: 개발 표준 위반, 상위 레벨 산출물 불일치 등의 결함 발견을 위해 저자 외 다른 전문가가 검사하는 가장 공식적인 리뷰 기법으로 항상 문서화된 절차를 기반으로 한다.

 

인스펙션 목적

- 소프트웨어가 명세를 만족하는가?

- 소프트웨어가 명시된 품질 속성을 만족하는가?

- 규격, 표준과 일치하는가?

- 결함이나 수정사항 같은 데이터 수집

 

인스펙션 활동

- 요구사항분석

- 설계

- 구현

- 테스트

 -설치

 

 

일반적인 개발 vs 인스펙션을 도입한 개발

 

일반적인 개발

- 개발 초기 요구사항 정의, 분석 및 설계에 소수의 인력 투입

- 코딩이 시작되면서 투입인력 수요 급증

- 투입 인력 규모는 테스팅 단계에서 절정

- 테스팅 완료 후 소수의 유지보수 인력만 유지

 

인스펙션을 도입한 개발

- 코딩 전까지는 일반적인 개발보다 소요 인력 2배이상

- 초기 프로젝트 비용이 증가하지만, 성공적인 인스펙션 결과, 코딩 단계에서의 재작업과 투입인력 감소

- 결과적으로 품질 비용 감소, 개발 기간 단축

 

인스펙션 팀

- 저자를 포함하여 관련된 작업 산출물들의 개발자이거나 품질 보증에 대해 비슷한 관심을가진 구성원

- 경영자는 팀에서 제외 (표면적인 오류들만 찾아내려는 경향 발생)

 

인스펙션 참가자

- 주재자 (필수)

: 계획, 자료전달, 상황관리

- 검토자 (필수)

: 오류 발견 및 보고, 오류해결을 위해 노력하지말고 간단한 의견만 제시

- 작성자 (필수)

: 자료내용설명, 적극적으로 토의 참가, 후속조치

- 기록자

: 기록, 문서화, 충분한 도메인 지식, 검토자입장

- 판독자

: 회의 진행속도 조절, 작성자가 맡으면 안됨, 부연설명

- 테스터

: 부수적인 참가자, 실제로 테스트진행할사람.

 

 

인스펙션 단계

- 계획

: 주재자는 인스펙션 계획하고 팀편성 후 역할 할당.

: 체크리스트 이요해서 인스펙션 착수 조건 확인

: 사전교육 유무 결정

: 일정 및 장소 결정

- 개요

: 작성자가 수행하는 간단한 형태의 교육

: 소프트웨어에 대해 간단한 설명

: 해결책 제시는 하지 말기

: 생략가능

- 준비

: 참가자에게 인스펙션 자료 제공하고 개인별 역할 준비

: 2시간 내에 할 수있는 분량

- 인스펙션 회의

: 실제 결함을 찾는 과정으로 체크리스트 이용

: 작성자에 대한 평가하지말기 (방어적이 될 수있음)

: 오류를 제거하고 해결하는 방안에 대한 토론은 하지말기

: 결함이라고 판단되면 기록하고 종류 구별

- 프로세스 개선

: 주재자 책임하에 인스펙션 결과 분석

- 재작업

: 작성자는 결함의 내용을 충분히 이해한 뒤 작업을 면밀히 살펴보고 수정

: 인스펙션 회의 필요시 다시 개최

- 후속작업

: 결함이 바르게 수정되었는지 확인

: 직접만나서 검사

: 품질관리자에게 종합보고하고 제출하고 종료

 

 

 

정적테스트 - 리뷰 - 공식검토

: 소프트웨어 각 개발 단계의 종료시점에서 산출물에 대해 수행되어지는 정적 테스팅 기법

: 검토결과에 따라 다음단계로 진행할지 여부 확인

: 직급의 높은 참가자로 팀 구성

 

공식검토 종류

- 요구사항 검토

- 예비설계 검토

- 상세설계 검토

- 테스트 준비 검토

 

공식검토 참가자

- 관리자

- 주재자

- 작성자

- 검토자

- 기록자

 

공식검토 단계

- 계획

- 킥오프

- 개별 준비

- 리뷰 회의

: 완전승인 or 부분승인

- 재작업

- 후속 작업

 

 

 

 

워크쓰루 vs 인스펙션 vs 공식검토

 

	검토시점	검토대상	진행주체	검토규정	검토산출물	후속처리
워크쓰루	임의 시점	중간 산출물	개발 산출물 작성자	정식 검토 규정이 존재하지 않음	-	-
인스펙션	개발 산출물 작성 완료 시점	개발 산출물 완성본	훈련된 리더	정식 검토 규정 및 프로세스가 존재	인스펙션 결과서, 결함 리포트	검토 재작업 후속처리 확인
공식검토	개발 단계 종료시점	각 개발 단계 전체 산출물	훈련된 리더	정식 검토 규정 및 프로세스가 존재	공식검토 결과서, 후속 작업 계획	승인 결과에 따른 후속처리

 

 

 

정적테스트 - 정적분석

 

정적테스트 - 정적분석 - 심볼릭실행

: 프로그램의 입력 변수를 기호화해서 표현하며, 심볼릭 실행 수행 시 프로그램의 출력은 기호화된 입력 변수들로 이루어진 논리적, 수학적 수식

: 심볼릭 실행 트리를 통해 주어진 경로가 실행가능한지를 검사

: 심볼릭 실행 결과의 활용

 

(교재 참고, 실습 필요)

 

 

정적테스트 - 정적분석 - 자료흐름분석

: 프로그램 상에서 자료의 흐름에 이상 패턴이 있는지 분석하는 방법

: 변수가 정의되고 참조된 위치에 따라 프로그램의 테스트패스 결정

 

(교재 참고, 실습 필요)