8. 정적 테스트

• 정적 테스트는 리뷰라고 하고 관리리뷰, 기술 리뷰, 인스펙션, 워크쓰루, 감사로 분류
• 리뷰는 여러 전문가가 모여 프로그램을 검토하여 결함을 검출하는 방법
• TomGilb, 리뷰를 이용하면 결함을 발견하고 제거하는 평균 비용울 60~80% 감소할 수 있다.

---

리뷰테스트

---

리뷰 프로세스

• 경영진 준비 : 필요한 자원 제공, 법규 표준 관련 정책의 요구에 따른 리뷰 수행 보장
• 리뷰 계획 : 리뷰 리더가 목적을 파악해서 팀을 구성하고 책임 할당, 자료 제공, 일정 결정, 공지
• 리뷰 절차 개요 설명 : 리더의 요청이 있을 때 수행, 목적과 절차 설명. 리더가 할 필요 없음.
• 작업물 개요 설명 : 리더의 요청이 있을 때 수행, 리뷰 참가자가 작업물을 더 친숙하게 느끼고 이해도를 높이기 위함
• 개별 준비 : 멤버들이 개별적으로 작업물이나 프로세스 검토, 검토 중 문제를 발견하면 문서화하여 리더에게 보고
• 그룹 검토 : 검토 결과를 모아 검토 대상 작업물의 상태에 관해 합의를 도출
• 재작업 : 검출된 문제 목록을 개발자나 책임자에게 전달하여 문제 해결하는 작업
• 후속 작업 : 리뷰 리더의 회의에서 산출된 모든 조치 항목을 완료하였는지 확인

 

---

관리 리뷰

---

진행 상황을 모니터하고 계획과 현재 일정 상태를 평가하여

필요하다면 자원, 일정이나 프로젝트 범위를 변경한느 것

 

프로젝트 진행 상황을 파악할 수 있는 문서 :

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

 

---

기술 리뷰

---

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

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

소프트웨어 요구 설계 명세, 테스트 문서, 유지보수 메뉴얼, 설치 절차 등이 기술 리뷰 대상

관리자도 기술 리뷰에 참가 가능

---

인스펙션

---

• 리뷰 종류 중 가장 형식화된 대표적인 리뷰 방식
• 동료 검토
• 인스펙션으로 검출한 문제의 유형이나 투자한 시간 등을 포함한 자료를 수집해서 인스펙션 지원 문서 개선에 활용

인스펙션 참가자의 역할

• 주재자 : 인스펙션 주재자의 주된 임무는 검사할 작업물을 기초로 인스펙션 참가자를 선정하고 인스펙션 계획
• 작성자 : 인스펙션 회의에 필요한 자료를 제출, 자료 내용에 관한 설명 또는 질문에 대답할 수 있어야 함
  '작업물 개요 설명'도 작성자가 수행
• 낭독자 : 작업물에 대한 자신의 이해 및 해석을 바탕으로 작업물에 대해 참가자들에게 설명, 회의를 이끔
• 기록자 : 인스펙션 회의에서 논쟁, 모든 질문 및 답변 등을 기록해야 함
  인스펙션 회의를 마치면 기록된 사항들을 정리하여 문서화해야 함
• 검토자 : 인스펙션 회의를 위해 전달받은 자료를 충분히 검토하고 회의를 준비
  검토할 작업물을 충분히 이해하고 결함을 찾아내고 기록

퍼실리레이터

검토 회의 또는 워크숍과 같이 여러 사람이 일정한 목적을 갖고 함께 작업을 수행할 때,

효과적으로 그 목적을 달성하도록 작업 과정을 설계하고 참여를 유도해서 결과물이 잘 나오도록 도움을 주는 사람

주재자가 담당

 

---

인스펙션 과정

리뷰계획

• 리뷰 리더인 중재자가 리뷰 목적을 파악해서 리뷰틱을 구성
• 인스페션에 필요한 자료를 참가자들에게 제공하고 필요한 시간 할애

인스펙션 절차 개요 설명

• 중재자는 참가자들의 역할을 할당하고 체크리스트나 역할 할당에 관한 질문에 대답
• 최소 준비 시간, 희망하는 인스펙션 수행률 및 유사한 프로젝트의 인스펙션에서 검출된 문제 수 전달

인스펙션 작업물에 대한 개요 설명

• 작성자가 검토자들에게 검토할 작업물 설명, 사전 이해도를 높임

준비

• 검출된 문제를 활용해 적절하게 분류하여 인스펙션을 계속할지 판단

검토 회의

• 낭독자가 인스펙션 참가자들에게 작업물에 대한 설명을 하며 참가자들은 객관적으로 작업물 검사
• 검토자에게 피드백을 받는 역할로 참가하여 작업물에 대해 더 설명하거나 옹호하는 행동을 피해야 함

 

• Accept with no verification or with rework verification 있는 그대로 작업물 승인, 약간의 재수정만 수행
• Accept with rework verification : 주재자나 주재자에게서 위임 받은 사람이 재작업을 검증하고 작업물 승인
• Reinspect : 작업물을 승인할 수 없어 문제가 해결된 후에 재작업을 검증하기 위해 다시 인스펙션 일정 계획

재작업

• 검출된 문제 목록이 작성자에게 전달되면 작성자는 실제 작업물에서 문제를 해결하는 작업 수행

후속작업

• 주재자나 주재자에게서 위임받은 사람이 발견된 모든 문제에 대해 재작업이 충분하게 이루어지는지 확인

---

워크쓰루

---

• 인스펙션보다는 비형식적인 결함 검출 방법
• 결함 검출, 참가자들의 교육, 지식 공유를 위해 수행
• 인스펙션에서는 회의 주재자는 작성자가 아닌 사람, 워크쓰루는 작성자가 회의를 주재, 기록자 역할도 담당
• 작업물을 따라 돌아다니면서 작업물에 대한 설명을 진행하고 검출된 결함에 대한 권고 및 조치 사항을 기록
• 재작업 및 후속 단계에서 작성자는 모든 조치 사항을 종결되었음을 확인

---

감사

---

• 목적을 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지 독립적으로 평가
• 대표 감사자, 감사자, 기록자, 개시자 역할 부여, 피감사 조직의 대표도 됨
• 대표 감사자가 감사를 주도하며 인터뷰나 문서들을 점검함으로써 법규나 표준 등에 부함되는지 증거 수집
• 비준수 사항의 사례를 식별하고 해당팀이 교정 활동을 요구하는 보고서를 산출

---

정적 분석

---

코딩 표준

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

복잡도 분석

• 소프트웨어 개발의 핵심은 복잡도를 통제하여 필요 이상으로 복잡도가 높지 않도록 하는 일
• McCabe가 발표한 순환 복잡도가 가장 널리 사용되고 있으며 많은 정적 도구가 이 지표를 지원함\
• 순환 복잡도 = E-N+2 = 닫힌 영역의 개수 + 1 = 분기 노드 개수 + 1

자료 흐름 분석

• 프로그램의 자료 흐름에 이상이 있는지 분석

패턴		설명
~d	처음 정의됨	문제 없음
du	define-use	문제 없음, 정상적인 경우
dk	define-kill	잠재적 결함, 전혀 자료가 사용되지 않음
~u	처음 사용됨	잠재적 결함, 자료가 정의되지 않고 바로 사용됨
ud	use-define	문제 없음, 자료가 사용된 후 다시 정의됨
uk	Use-kill	문제 없음
~k	처음으로 무료화	잠재적 결함, 자료가 정의되지 않고 바로 무효화됨
ku	kill-use	심각한 결함, 무효화되었는데 사용
kd	kill-define	문제 없음, 무효화된 후에 다시 정의가 됨
dd	define-define	잠재적 결함, 두 번 연의어 정의됨
uu	use-use	문제 없음, 정상적인 경우
kk	kill-kill	잠재적 결함
d~	제일 나중에 발생한 정의	잠재적 결함
u~	제일 나중에 발생한 참조	문제 없음
k~	제일 나중에 발생한 무효화	문제 없음, 정상적인 경우