[CSTS 요약] 8 정적 테스트

소프트웨어 테스트 방법은 동적 테스트(프로그램 실행 필요)와 정적 테스트(프로그램 실행 불필요)로 분류

정적 테스트를 리뷰(Review)라고 하며 5종류로 분류(IEEE 1028-2008)

• 관리 리뷰(Management revie)
• 기술 리뷰(Technical review)
• 인스펙션(Inspection)
• 워크쓰루(Walk-through)
• 감사(Audit)

리뷰: 여러 전문가가 모여 프로그램을 검토하여 결함을 검출하는 방법
리뷰 대상 작업물은 프로그램 뿐만 아니라 소프트웨어 개발 중 생성되는 모든 산출물(요구사항 명세서, 설계 명세서, 테스트 계획서 등) 문서 방법에도 이용 가능. 테스트 대상으로 모든 산출물이 가능하다는 점은 결함 제거 비용 측면에서 큰 의미를 갖음.

 

리뷰 프로세스

1. 경영진 준비(Management preparation): 경영진은 성공적인 리뷰 수행을 위해 필요한 자원(스태프, 설비, 재원, 훈련 및 교육)을 제공하고 법규, 표준 및 관련 정책의 요구에 따른 리뷰 수행 보장
2. 리뷰 계획(Planning reivew): 리뷰 리더는 리뷰 목적 파악하여 팀을 구성하고 구성원에게 책임 할당하여 참가자들에게 리뷰에 필요한 자료들을 제공
3. 리뷰 절차 개요 설명(Overview of review procedures): 리뷰 리더의 요청이 있을 때 수행. 리뷰 목적과 리뷰 절차 설명
4. 작업물 개요 설명(Overview of software product): 리뷰 리더의 요청이 있을 때 수행. 리뷰 참가자들이 검토할 작업물을 친숙하게 느끼게 하고 사전 이해도를 높이기 위함
5. 개별 준비(Individual preparation): 그룹 검토에 앞서 리뷰팀 참여자들의 개별적인 작업물 혹은 프로세스 검토. 문제를 발견하면 문서화하여 리뷰 리더에게 보냄
6. 그룹 검토(Group examination): 모든 리뷰 멤버들이 참가하는 회의. 검토 결과를 모아 작업물 또는 프로세스의 상태에 관해 합의 도출
7. 재작업(Rework): 검출된 문제 목록을 개발자나 문제 해결 책임자에게 전달하여 문제 해결 작업 수행
8. 후속작업(Follow up): 리뷰 리더는 산출된 모든 조치 항목을 완료하였는지 확인

 

관리 리뷰

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

관리 리뷰 후 해당 계획이 적절히 변경되었는지를 확인해야 함

관리 리뷰 대상:

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

산출물들은 검토 회의 결과 영향을 받는 사람들에게도 전달되어야 함

 

기술 리뷰

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

대표 엔지니어가 주재하며 경우에 따라 관리자도 참가할 수 있음

 

인스펙션

비슷한 수준이나 역할을 가진 사람들이 코드 등을 포함한 소프트웨어 산출물을 검토하는 작업(동료 검토)

가능한 한 개발 초기에 검사해야만 개발 초기 작업물에서 문제를 찾아낼 수 있음

 

인스펙션 참가자의 역할

• 주재자: 검사할 작업물을 기초로 인스펙션 참가자들을 선정하고 인스펙션을 계획
  전문적으로 훈련된 퍼실리테이터가 담당
• 작성자: 회의에 필요한 자료 제출하며 자료 내용에 관한 설명을 하거나 질문에 대답
  작성자는 인스펙션 주재자가 될 수 없음
• 낭독자: 작업물에 대한 자신의 이해 및 해석을 바탕으로 작업물에 대해 회의 참가자들에 설명 및 회의를 이끄는 역할
• 기록자: 회의에서의 논쟁, 모든 질문 및 답변 등을 기록하며, 회의 이후 기록된 사항들을 정리하여 문서화 함
  회의 주재자나 개발자가 아닌 검토자 입장에서 참여
  주재자 역할과 병행 가능
• 검토자: 회의 자료 검토 및 회의 준비, 검토할 작업물 이해하며 주어진 자료에서 결함 발견 및 기록
  관리자 직책 담당 팀 멤버로 참여 불가

 

인스펙션 과정

1. 리뷰 계획: 중재자가 리뷰 목적 파악 후 리뷰 팀 구성, 책임 할당하고 리뷰 일정 공지 및 필요한 자료 제공
2. 인스펙선 절차 개요 설명: 중재자는 참가자들의 역할을 할당하고 체크리스트나 역할 할당에 관한 질문에 대답
   참가자에게 최소 준비 시간, 희망하는 인스펙션 수행률 및 유사한 프로젝트의 인스펙션에서 검출한 문제 수 등 전달
3. 인스펙션 작업물에 대한 개요 설명: 작성자가 검토자들에게 작업물에 대해 설명
   작업물에 대한 이해도를 높이기 위한 질문 외 해결책을 제안하거나 결함 수정 작업은 하지 않음
4. 준비: 실제 리뷰 회의 전 인스펙션팀 구성원의 작업물 검토 단계
5. 검토 회의: 
   낭독자: 참가자들에게 작업물에 대해 설명
   참가자: 객관적으로 검사
   기록자: 검출한 문제들을 분류하고 관련 정보를 기록
   작성자: 자신의 작업물에 대한 검토자의 질문에 답하며 참가자들의 결함 검출에 도움. 검토자에게서 피드백을 받는 역할로, 작업물에 대해 더 설명하거나 옹호하는 행동은 피해야 함
   
   검토 회의 결과 분류
   1. Accept with no verification or with rework verification: 있는 그대로 작업물을 승인하거나 약간의 재작업 수행
   2. Accept with rework verification: 주재자가 재작업을 검증한 후에 작업물 승인
   3. Reinspect: 재작업 검증 위한 인스펙션 일정 계획
6. 재작업: 검출된 문제 목록 기반 작성자의 문제 해결 작업 수행
   검토 회의에서는 문제 해결 방안에 관한 토론은 하지 않음
7. 후속작업: 주재자가 발견된 모든 문제에 대해 재작업이 충분하게 이루어지는지 확인

 

워크쓰루

결함 검출 뿐만 아니라 참가자들의 교육이나 지식 공유를 위해 수행되기도 함

인스펙션에서 회의 주재자는 작성자가 아닌 사람이 맡지만, 워크쓰루는 작성자 본인이 보통 회의를 주재하며 기록자도 담당할 수 있음

인스펙션과 마찬가지로 관리자 직책의 팀 멤버 참여 금지

 

감사

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

 

정적 분석

정적 분석(Static analysis): 도구의 지원을 받아 정적 테스트를 수행하는 것
대표적으로 코딩 표준 부합, 코드 복잡도 계산, 자료 흐름 분석 등이 있음

 

코딩 표준(Coding Standard)

개발자가 프로그램을 작성할 때 지켜야 하는 규약

개발자가 자신의 스타일 대신 코딩 표준에 따라 일관되게 프로그램을 작성하게 하는 것이 목적

가독성이 좋고, 이해하기 쉬우므로 유지보수 용이한 프로그램 개발 가능

BSD	K&R	GNU
if (...) {      doSomething(); }	if (...){      doSomething(); }	if(...)      {           doSomething();      }
블록을 if문 아래 작성 중괄호는 들여쓰기하지 않음	블록문의 중괄호를 if와 같은 행에 배치	블록을 if 문 아래 작성하고 들여쓰기

 

복잡도 분석

복잡도를 통제하여 필요 이상으로 높은 복잡도로 인한 신뢰성, 테스트 비용, 유지보수성 측면에서 좋지 않은 프로그램 작성 예방

순환 복잡도(Cyclomatic complexity):

예제 프로그램과 제어 흐름 그래프

순환 복잡도 계산 방식

 

자료 흐름 분석(Data flow analysis)

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

 

자료 흐름 쓰임새 패턴

패턴		설명
~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~	제일 나중에 발생한 무효화	문제없음, 정상적인 경우