[시스템 공학론] System Integration, Verification, and Validation ②

출처: vorticity, systems engineering

 

 

 

 

 

System Qualification (시스템 적격성평가)

---

Failure vs. Error vs. Fault

☐ Fault(결함)

• 내부적인 결함, structure 수준에서의 결함
• Physical defect, imperfection or flaw that occurs in HW or SW
• 예: 전선 간 단락, 트랜지스터 고장, 무한 루프 프로그램

 

☐ Error(오류)

• Deviation from correctness or accuracy
• 정확성 또는 정확도의 편차
• 예: 어떤 선이 물리적으로 0으로 단축되었다고 가정하자. 선의 값이 0이어야 한다면 오류는 없다.
• 일반적으로 시스템 상태의 잘못된(incorrect) 값과 관련 있음

 

☐ Failure(고장)

• function 단위에서의 결함, 서비스의 기대동작을 수행하지 못하는 상황
• Non-performance of some action that is due or expected
• 예상되거나 해야 할 작업을 수행하지 않음
• 예: 회로가 램프를 제어하고(0 = 끄기, 1 = 켜기) 출력이 물리적으로 0으로 단축된다고 가정하자. 사용자가 램프를 끄기를 원한다면 고장은 없다. 그러나 사용자가 램프를 켜기를 원한다면 고장이 발생한다.

 

 

∴ 이들간의 관계를 두 문장으로 표현하자면,

 

Faults can result in errors. Errors can lead to system failures.

Errors are the effect of faults. Failures are the effect of errors.

 

 

 

Taxonomy of Faults (결함의 분류)

• Mild(경미한)
• Moderate(중간 수준의)
• Annoying(성가신)
• Disturbing(불편한)
• Serious(심각한)
• Very serious(매우 심각한)
• Extreme(극단적인)
• Intolerable(견딜 수 없는)
• Catastrophic(재앙적인)
• Infectious(전염성 있는)

 

 

 

Software testing axioms (소프트웨어 테스팅에 관한 공리)

• 프로그램을 완전히 테스트하는 것은 불가능하다.
• 소프트웨어 테스팅은 위험 기반 활동이다.
• 테스팅으로 버그의 부재를 증명할 수 없다.
• 더 많은 버그를 발견할수록 더 많은 버그가 있다.
• 발견된 모든 버그가 수정되지는 않는다.
• 버그인지 아닌지 판단하기 어렵다.
• 명세는 절대 최종적이지 않다.
• 소프트웨어 테스터는 프로젝트 팀에서 가장 인기 없는 구성원이다.
• 소프트웨어 테스팅은 규율 있고 기술적인 전문 분야이다.

(From ‘Software Testing’ by Ron Patton)

 

 

 

Beizer’s 3 Laws of software testing (베이저의 소프트웨어 테스트 3가지 법칙)

1. Pesticide paradox(농약 역설)
   • 버그(faults)를 예방하거나 찾기 위해 사용하는 모든 방법은 해당 방법이 효과적이지 않은 미묘한 버그의 subtler를 남긴다.
   • 제1법치그이 결과: Test suites는 마모된다.
2. Complexity barrier(복잡성 장벽)
   • 소프트웨어 복잡성(따라서 버그의 복잡성)이 해당 복잡성을 관리하는 능력의 한계까지 증가한다.
3. Code migrates to data
   • 코드가 데이터로 마이그레이션(migration)한다.

 

 

 

테스트란 무엇인가?

• Everything is possible 모든 것이 가능하다.
• Key question to be asked 물어봐야 할 핵심 질문
  • What should we test? 우리는 무엇을 테스트해야 하는가?
  • Cf.) What did we forget to test? (in V&V activities)
• Acceptance tests는 developmental testers를 사용자로 대체한다.
• Exhaustive repetition(철저한 반복)
  • 시간적, 경제적 제약으로 인해 불가능하다.
  • 과거의 모든 테스트에도 의존한다.

 

테스트는 어떻게 하는가? (사용성 문제)

• 유용성 테스트
  • 이해관계자의 요구사항 충족 성공 여부 판단
• 유용성 테스트의 5가지 측면
  • 학습 가능성
  • 사용의 용이성
  • 기억력
  • 오류율
  • 만족
• 유용성 테스트는 전체 시스템의 개발이 완료될 때까지 적절하게 테스트할 수 없다.