정적 테스트, 정적 분석

테스트의 목적은 '결함을 발견하는 것' 입니다. 그리고 기능이 정상적으로 동작하는 것을 확인하는 것입니다. 

 

그리고 소프트웨어를 실행하지 않고 결함을 찾아내는 것이 정적 테스트의 목적입니다. 

 

여러 참여자들이 모여 소프트웨어를 검토하면서 결함을 찾아내거나, 정적 검증 도구를 이용하여 수행하는 것을 

즉, 문서 또는 소스코드를 보면서 검토하는 것

 

소프트웨어 개발 중에 생성되는 모든 산출물들에 대해서 적용이 가능합니다.

 

동적 테스트의 경우, 구현 또는 테스트 단계까지 가야 결함을 찾을 수 있지만, 정적 테스트는 명세하는 활동/산출물(명세서) 부터 결함을 찾을 수 있습니다.

즉 제품 개발에서 초기에 결함을 찾음으로서 소프트웨어 품질을 향상시킬 수 있습니다. 

 

---

 

동력 검토 (Peer Review):

• 인스펙션 (Inspection) * 가장 엄격한 방법
• 워크쓰루 (Walktrhough)
• 데스크 체크 (Desk Check)

 

도구를 이용한 정적 분석:

• 룰(rule) 기반의 정적 분석 (PMD, BugFind 등)
• 의존성 분석
• 시맨틱 분석 (실행 오류 분석)
• 정형 검증

 

인스펙션의 경우 다음과 같은 특징이 있습니다. 

• 검토자, 작성자 외 진행자(Moderator)가 존재
• 프로세스 기반의 체크리스트 활용하여 수행
• 전문가 검토이며 공식적인 평가

 

인스펙션의 내용을 이해하기 위해서는 아래 링크 참고 부탁 드립니다.

https://helloblog.net/software-inspection/

 

인스펙션 회의에서는

• 발견된 결함을 논의 합니다.
• 반복되는 결함은 한 번만 논의하고, 이 후 반복된 결함에 대해서는 위치만 표기합니다.
• 결함 해결책을 논의하지 않습니다
• 기록자는 논의되는 내용을 기록합니다.
• 인스펙션 회의가 끝나면 진행자(Moderator)는 참여자(Reviewer, Inspector)들의 결함 기록을 회수합니다
• 발견한 결함에 대한 상세 검토가 필요한 경우 충분한 시간을 두고 결정합니다
• 인스펙션 재 시행 여부, 인스펙션 유형 등을 작성자에게 알려줍니다.

---

정적 분석의 목적은

• 소스 코드의 잠재적인 품질 문제 (낮은 품질) 발견
• 결함의 조기 발견
• 소스 코드 표준 준수여부 확인
• 설계 상의 낮은 품질, 표준 위반을 확인

 

룰 기반의 정적분석은 사전에 정해진 룰(rule) 가이드라인을 소스코드가 만족하는지 분석하는 것을 말합니다.

 

대표적인 룰 가이드라인 (코딩 표준)으로

• MISRA: Motor Industry Software Reliability Association에서 개발한 안전성, 호환성, 신뢰성을 위한 C, C++ 룰
  - 자동차 산업에서 시작하였으나, 임베디드 소프트웨어에서 대표적으로 활용 중 (철도, 항공 등의 산업에서도 활용)
• CERT: SEI CERT (Computer Emergency Response Team)의 SW 개발 보안을 위한 C, C++, Java 룰
• CWE: Common Weakness Enumeration
• 기타

도구 선택 시 1종 또는 2종 오류 발생율을 확인해야 합니다.

• 1종 오류: 결함인데 못 잡는 것, 미탐지 * 중요
• 2종 오류: 결함이 아닌데 결함이라고 하는 것, 오탐지

 

감사합니다.