1. SW는 무엇이고 testing이란 무엇인가

학습 목표

1. SW 공학이라고 부르는 이유에 대해 이해할 수 있다.

2. SW 필수 문제 4가지에 대해 이해하고 각각을 설명할 수 있다.

3. SW 공학을 배우는 주된 이유를 이해하고, 유지보수 비용을 줄이는 방법의 하나로서 SW 테스팅을 이해할 수 있다.

4. SW 테스팅의 목적과 원리를 알고, control-flow 기반 테스트 기법이랑 data-flow 기반 테스트 기법을 이해한다.

 

 

- 왜 SW과학이 아니라 소프트웨어 공학이라고 부르는가?

=> 과학은 법칙을 찾는것이고, 공학은 최적의 조합을 찾는것.

 

=> sw를 만드는 행위는 프로그래머의 독창성이 바로 드러나는 행위이기 때문이다.

==> art와 가깝다

===> sw를 만드는 것을 과학적으로 법칙이 있게 만들고 싶다.

====> 그래서 sw만드는 행위는 art인데 과학적으로 표현하기 떄문에 "공학"이라고 부르게 됨.

* sw art 상태를 극복하기 위해서는?

=> 코딩 컨벤션 : 특정 프로그래머의 개성이 드러나지 않게 해야한다.

 

=> sw를 만들면서 정확한 비용, 투입공수, 일정 등을 예측하는 평가 능력이 다른 공학적인 프로젝트에 비해서 현저히 떨어지기 때문이다.

==> 사용자 요구사항이 처음에는 명확하지 않다가 프로젝트 후반부에서 바뀌는 일이 있음

==> 거의 모든 작업이 사람에게 의존됨

==> 물리적으로 정말 얼마의 시간이 필요한지 표시할 방법이 없음

 

 

 

- sw 공학의 필수적인 문제는 무엇인가? (중요)

=> 복잡성

: sw는 이산상태를 다뤄서 복잡성이 기하급수적으로 증대된다.

: sw 복잡성은 시스템 전체에 대한 이해를 불가능하게 해서, 팀내에서 의사소통을 어렵게 하고, 대형 프로젝트 수행이 어렵게 된다.

: 또한, 복잡성으로 인한 예산과 개발기간의 부정확한 예측은 프로젝트 관리를 어렵게 만든다.

: 시스템에 대한 정확한 이해 없이 유지보수를 하면 또다른 문제를 야기할 수 있다.

 

=> 순응성

: 자연은 어떤 법칙에 확정되고 어떤 법칙을 따르지만, sw는 인공적으로 만들어지기 때문에 법칙이 존재하지 않는다.

 

=> 가변성

: 소프트웨어의 변경이 하드웨어 변경보다 용이하다.

: 성공한 sw도 변경이 될 수 있음.

: 사용자들은 분석단계에서 고려하지 못한 새로운 기능을 추가하는데 hw보단 sw변경이 훨씬 쉽다.

 

=> 비가시성

: 프로그램 코드를 눈으로 봐서는 뭘하는지 알기가 어렵다. 즉, sw는 가시성이 낮다.

: UML이 있지만 단편적인 도식화에 불과하다.

 

 

- 개발 vs 유지

: 소프트웨어는 개발에 들어가는 비용보다 유지보수에 들어가는 비용이 훨씬 많다.

=> 소프트웨어 전체비용을 줄이려면 유지보수 비용을 줄이는 것에 더 집중해야 한다.

: 유지보수 비용 중 대부분은 버그를 찾고 고치는데 소모 (디버깅 비용 )

=> 여기서도 버그를 재현하는 것이 비용이 가장 크다.

==> testable software를 만들기 위해서 개발 초기 부터 조치를 취해야한다.

 

- Construction vs Destruction

: sw를 만드는 행위는 생산하는 행위 construction

: 좋은 test는 sw에 stress주고 분해해서 버그를 잘 찾아내는 테스트이다. destruction

=> 개발자는 construction 성향이 있기 때문에  sw를 충분히 destruction성향인 테스트를 했다는 말이 성립되지 않는다.

==> 테스트는 독립적인 조직이 수행해야 한다.

 

 

- 소프트웨어 테스팅이란

: 목표=제품에 대해 수용가능한 비용의 레벨에 대한 자신감을 가지게 하는것.

=> 테스트 케이스를 통과할 수록 제품에 대해 가지는 자신감이 생기기 때문

1. 프로그램을 완벽하게 테스트하는 것은 불가능하다.

2. 모든 시나리오를 테스트하지 않기로 했다면, 테스트는 위험을 수반하는 행위

3. 테스트로 버그가 존재하지 않는다는 것을 증명할 수는 없다,

4. 찾은 버그가 많을수록 존재하는 버그도 많다. (버그는 몰려다님)

5. 살충제 역설: 같은방법의 테스트로는 잡히지 않는 버그 발생

6. 발견된 모든 버그들이 수정되지는 않음

7. 요구사항 명세서는 항상 바뀐다

8. 테스터는 프로젝트팀의 환영을 받지는 못한다.

9. 테스터는 훈련이 필요한 전문적인 일이다.

 

- Metric

: 소프트웨어는 LOC (line of code) , weight of listing 으로는 파악 불가능

: Halstead's Token Count & Vocabulary 등의 유니크한 요소 개수 또는

McCabe's Cyclomatic Complexity 순환 복잡도 등

: Metric은 자동화되어야 한다. 측정 -> 버그개수 -> 테스트로 조정

 

- CFG (Control Flow Graph)

: A -> B 는 A를 만족하는 테스트는 B도 만족한다는 의미

: 소스코드 컴파일하면 마지막 단계에 CFG를 얻을 수 있고 테스트 적정성 판단에 이용가능

: 가장 쉬운 방법은 CFG의 모든 문장을 한번씩은 통과했는지 보는것. 모든 경로를 테스트

=> 이거보다 세게 테스트할 수 있는 방법은 없다. cycle있으면 무한대경로가 되어서 현실적으로 불가

: statement coverage, all-nodes Criteria 라고도 한다.

 

- Data-Flow Testing

: CFG의 all-path 테스트는 너무 강하지만, all-nodes/all-edges는 약하다.

=> full-path가 아닌 sub-path 를 커버하는 테스트를 만들 필요가 있음

==> 의미있는 sub-path를 어떻게 추출할 것인가?

===> 데이터의 흐름(변수의 흐름)에 focus를 두고 추출

용어1: definition (x=100)

용어2: use (x=a+100)

=> 특정변수의 definition, use 사이를 잇는 path를 정하고 du-pair (definition과 use의 쌍)를 테스트가 통과했는지를 보는 기법

: 다양한 전략가능

 

- backward slice: 어떤 지점에서 문제발생하면 역추적하여 찾아낼 수 있음

- Forward Slice (impact analysis) : 어떤 지점을 수행한 후 이후에 문제가 생길 수 있는 부분을 찾아낼 수 있음

 

- data-flow testing의 문제점

=> 배열과 구조체같은 aggregate data 문제 (A[0], A[100] 이 있으면 du-pair로 보는가, 별개의 변수로 보는가)

=> 포인터, alias (동적으로 포인터가 여러 메모리 영역을 가리킬 수 있음)