8.정적 테스트

5종류 구분

• 관리 리뷰
• 기술 리뷰
• 인스펙션
• 워크쓰루
• 감사

리뷰 - 여러 전문가가 모여 프로그램을 검토하여 결함을 검출하는 방법

(요구사항 명세서, 설계 명세서, 테스트 계획서와 같은 문서들이 올바르게 작성 되었는지를 판단하기 위해 리뷰 방법을 이용할 수 있다.)

 

리뷰 프로세스

1. 경영진 준비 - 자원을 제공하고 법규, 표준 및 관련 정책의 요구에 따른 리뷰 수행 보장
2. 리뷰 계획 - 리더는 리뷰 목적을 파악해서 리뷰 팀을 구성, 구성원에게 책임을 할당,참가자들에게 자료제공, 공지
3. 리뷰 절차 개요 설명 - 리더의 요청이 있을때 수행 ( 리뷰 목적,절차 설명)
4. 작업물 절차 개요 설명 - 리더의 요청이 있을때 수행 ( 사전 이해도를 높이기 위함 )
5. 개별 준비 - 개별적으로 작업물이나 프로세스 검토, 문제 발견시 문서화하여 리더에게 보냄
6. 그룹 검토 - 모든 리뷰 멤버 참가, 검토 결과를 모아 검토 대상이 되는 작업물의 상태에 관해 합의를 도출한다.
7. 재작업 - 검출된 문제 목록을 개발자나 문제 해결 책임자에게 전달하여 해결하는 작업을 수행
8. 후속 작업 - 리더는 조치 항목을 완료하였는지 확인

 

관리 리뷰

진행 상황을 모니터하고 계획과 현재 일정 상태를 평가하여 필요하다면 자원, 일정이나 프로젝트 범위 등을 변경하는 것

 

진행 상황을 파악할 수 있는 관련 문서

• 설치 계획
• 백업 및 회복 계획
• 안정성 계획
• 재난 계획
• 비상 대책 계획
• 진행 보고서
• 테스트 결과

관리 리뷰는 4.작업물 개요 설명 단계는 수행되지 않음

 

기술 리뷰

 

유능한 인력으로 구성된 팀이 아래에 작업을 수행하여 프로젝트의 기술적 상태를 확인하는 증거로 관리자에게 제공

 

• 대상 작업물이 의도된 사용에 적합한지 평가
• 대상 작업물이 계획, 법규, 표준이나 명세를 충실히 지키는지 평가
• 변경 사항이 적절하게 구현되었는지를 평가하고 변경 명세에 식별된 영역에만 해당 변경이 영향을 미치는지 평가
• 여러 대안을 추천하거나 대안들을 검토

기술 리뷰는 대표 엔지니어가 주재한다.

 

 

인스펙션

 

• 리뷰 종류 중에서 가장 형식화된 대표적인 방식
• 동료 검토라고 할 수 있다. ( 비슷한 수준이나 역할을 가진 사람들이 코드 등을 포함한 소프트웨어 산출물을 검토)
• 가능한 한 개발 초기에 검사해야만 개발 초기 작업물에서 문제를 찾아낼 수 있다.
• 회의 주재자는 작성자가 아닌 사람이 맡음
• 관리자 직책 담당자는 팀 멤버X

 

 

인스펙션 참가자의 역할

 

주재자

• 검사할 작업물을 기초로 참가자들 선정, 계획
• 참가자들에게 미리 검토할 자료 전달
• 회의를 주재하는 역할
• 회의에서 기록된 모든 자료를 보고서 형식으로 만들어 개발자에게 전달
• 프로세스를 개선하기 위해 사용되는 여러데이터를 수집
• 훈련된 퍼실리테이터가 담당 ( 목적을 달성하도록 작업 과정을 설계하고 참여를 유도해서 결과물이 잘 나오도록 도움을 주는 사람)
• 기록자 역할 수행가능

작성자

• 회의에 필요한 자료 제출
• 자료 내용에 관한 설명을 하거나 질문에 대답할 수 있어야 함
• 방어적인 자세로 회의 참여 금지
• 검출된 결함 내용에 관하여 재작업
• 4.작업물 개요 설명도 작성자가 수행
• 인스펙션 주재자가 될 수 없음

낭독자

• 작업물에 대한 자신의 이해 및 해석을 바탕으로 참가자들에게 설명
• 회의를 이끄는 역할
• 시간을 줄이기 위해 작업물을 여러 부분으로 분할하고 다른 낭독자들에게 할당하여 회의 진행 가능

기록자

• 회의에서 논쟁, 모든 질문 및 답변 등을 기록
• 기록된 사항들을 정리하여 문서화
• 회의에서 회의 주재자나 개발자 입장이 아닌 검토자 입장에서 참가

검토자

• 회의를 위해서 전달받은 자료를 충분히 검토, 회의 준비
• 주어진 자료에서 결함을 찾아내고 기록
• 간단히 의견만 제시
• 관리자 직책을 담당하는 사람은 팀멤버로 참여 금지

 

이상적인 인스펙션 팀의 규모

• 작성자 이외에 검토자가 최소한 한 명
• 익스펙션 팀 두 명 이상
• 4명의 팀이 가장 이상적인 규모
• 더 나은 품질의 소프트웨어 개발 목적 팀 구성원 모두가 인식

 

인스펙션 과정

리뷰 프로세스

1. 리뷰 계획
2. 인스펙션 절차 개요 설명
3. 인스펙션 작업물에 대한 개요 설명
4. 준비
5. 검토회의
6. 재작업
7. 후속작업

 

워크쓰루

작성자가 작업물을 따라 돌아다니면서 작업물에 대한 설명을 검출된 결함에 대한 권고 및 조치 사항들을 기록

• 인스펙션보다는 비형식적인 결함 검출 방법
• 참가자들의 교육이나 지식 공유를 위해 수행되기도 함
• 회의 주재자를 작성자 본인이 함
• 기록역할자 담당도 가능
• 관리자 직책 담당자는 팀 멤버X

 

감사

소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지 독립적으로 평가하는 것

• 소프트웨어 제품의 제공자, 소비자, 또는 FDA와 같은 제 3기관에서 필요에 따라 요구
• 대표 감사자가 감사를 주도하며 언터뷰나 문서들을 점검, 법규나 표준등에 부합되는지 증거 수집
• 비준수 사항의 사례를 식별
• 해당팀이 교정 활동을 요구하는 보고서를 산출하게 함

 

정적 분석

 

정적분석 - 도구의 지원을 받아 정적 테스르를 수행하는 것

 

 

코딩표준

 

코딩 표준 또는 코딩 지침 - 개발자가 프로그램을 작성할 때 지켜야하는규약

• 코딩 표준에 따라 일관되게 프로그램을 작성하게 하는 것
• 코딩 스타일에는 대표적으로 BSD, K&R, GNU 가 있다

undefined behavior 가 발생할 수 있는 경우

• 초기화되지 않은 변수의 사용
• 배열의 범위를 넘어서는 인덴스를 사용하여 배열 참조
• 0으로 나눗셈 연산 수행

 

복잡도 분석

공식 (두가지)

1. 순환 복잡도 = E(선 수) - N(노드칸 수) + 2

복잡도 계산 예 <a(조)을 치환한것>

 

간단하게

 

2. 순환 복잡도 = 분기 노드들의 개수 + 1

 

예 : if (( X > 0 ) && ( y > 0)) {

         doSomething1;

      }

      doSomething2;

조건 X > 0 과 조건 Y > 0 은 노드 개수 1 + 1 임으로 마지막에 +1 을 하면 3이 된다.

 

위에 예를 그래프로 나타냄 T는 진실 , F 거짓

 

순환 복잡도와 신뢰성과의 관계

 

순환 복잡도와 신뢰성과의 관계

 

 

자료 흐름 분석 

• 프로그램의 자료 흐름에 이상이 있는지 분석
• 개발자는 변수를 먼저 정의하지 않고 사용
• 변수를 초기화하지 않은 상태로 조건문 사용

변수의 참조 두가지

• 계산참조-일반 수식을 계산할 때 사용 c-use
• 조건참조-변수가 조건의 참,거짓을 결정할 때 사용 p-use

변수가 선언된 영역 밖으로 벗어날 때 그 변수는 무효화

 

자료 흐름 쓰임새 패턴

자료 흐름 쓰임새 패턴

예제문제

결함 패턴

• dk (define - kill ) - 정의하고 날림
• ~u (use) - 처음 사용
• ~k (kill) - 정의되지않고 처음으로 무효화(날림)
• ku (kill use) - 날리고 사용
• dd (define define) - 정의하고 또 정의
• kk (kill kill) - 무효화 무효화(날리고 또 날리고)
• d~ (define) - 제일 나중에 정의