테스트 자동화의 중요성 및 TDD 방법론에 대한 서명

1. 테스트 자동화와 TDD
KESTI 개발역량강화 세미나
2016-01-15

2. 목차
 소프트웨어 개발 수명주기
 소프트웨에 개발 수명주기 종류
 소프트웨어 개발 수명주기와 테스팅
 테스팅 기법
 정적 테스팅
 동적 테스팅
 TDD (Test Driven Development) 개요
2

3. 3
고객설명 PM이 이해한 것 분석가 설계 개발자 구현 컨설턴트 설명
설명서 설치본 비용청구서 유지보수 고객 실제요청

4. 소프트웨어 개발 수명주기
4

5. Software 개발
 Problem / Requirements ?
 Solution 이 있는가?
 어떻게 구현 할 것인가?
 해결되어야 할 문제는 무엇인가?
 고객이 원하는 산출물인가?
 보완이 필요한가?
 개발기간 동안 발생하는 변화/변경을 어떻게 관리할 것인가?
5

6. Software 개발
 Big Bang 접근
 제품이 한번에 전달된다
 Waterfall Model
 Iterative 접근
 제품이 단계마다 개발되고 전달된다
 Spiral Model
 Iteration Model
6
정의 (Definition)
개발
(Development)
유지보수
(Maintenance)
보호활동 (Umbrella Activities)
무엇 어떻게 변경

7. Software Lifecycle
 소프트웨어 개발 프로젝트의 필수 4 단계
 Requirements (Analysis, Specification)
 System Design
 Implementation
 Test
 소프트웨어 수명주기 (Wiki)
 컴퓨터 소프트웨어의 개발 단계의 총체로서, 초기 개발 단
계부터 마지막 출시를 모두 아우른다.
 프로젝트 성격별로 4개 단계를 다르게 해석
 왜 소프트웨어 수명주기 모델을 사용하는가?
 중요한 활동 식별, Milestone 정의, 진척도 측정 용이
 Devide & Conquer (과정을 나눔으로써 관리가 쉬움)
7

8. 수명주기 모델
 Single Version Models
 Big Bang Model
 Waterfall Model
 V Model (Integration Testing)
 Incremental Models
 Single-Version with Prototyping
 Iterative Models
 Spiral Model & Variants
 Scrum Model
 참고: 모델별 장단점
8
Incremental: add new items to the product at each phase
Iterative: re-do the product at each phase

9. Big-Bang Model
 Build and Fix
 개발자는 고객으로부터 요구사항을 받는다
 개발자는 독립적으로 개발하여 전달한다
 개발자는 고객이 만족하기를 바란다
9
Build First
Version
Modify until
client is satisfied
Maintenance
Development
Maintenance

10. Waterfall Model (link)
1
0
Design
Inplementation
Test
폭포수 모델을 따르기 위해서는, 완전히 순차적
으로 한 단계, 한 단계를 진행해 나가야 한다

11. V-Model (link)
11
V 모델은 소프트웨어 개발의 각 단계마다 상세한 문서화를 통해 작업을 진행하는 잘 짜인 방법을 사용한다.
또한 테스트 설계와 같은 테스트 활동을 코딩 이후가 아닌 프로젝트 시작 시에 함께 시작하여, 전체적으로
많은 양의 프로젝트 비용과 시간을 감소시킨다.

12. Incremental vs Iterative
12

13. Incremental Model
13
분석 설계 구현 테스트
분석 설계 구현 테스트
분석 설계 구현 테스트
Iteration 1 / Increment 1
Iteration 2 / Increment 2
Iteration 3/ Increment 3
Delivery 1st Iteration
Delivery 2nd Iteration
Delivery 3rd Iteration

14. W Model
14
W Model 이란

15. Spiral Model
15

16. 수명주기와 테스팅
 모든 개발활동은 테스팅 활동과 대응된다
 모든 개발 Activity와 관련 있는 Testing Activity 가 있다
 각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 있다
 하위 레벨 테스팅
 단위 테스팅 (Unit Testing)
 통합 테스팅 (Integration Testing)
 상위 레벨 테스팅
 사용성 테스트 (Usability Testing)
 기능 테스팅 (Function Testing)
 시스템 테스팅 (System Testing)
 인수 테스팅 (Acceptance Testing)
 주어진 레벨에 대한 테스트의 분석과 설계는 관련된 개발 Activity
활동 동안에 시작되어야 한다
 개발수명주기 모델에서 문서들의 배포판이 이용 가능하게 되면,
문서 리뷰 시작 시 반드시 테스터들이 포함되어야 한다
16

17. 테스팅 기법
17

18. 테스팅 기법 종류
 정적 테스팅
 테스트 대상 프로그램을 실행하지 않고 테스트
 동적 테스팅
 테스트 대상 프로그램을 실행하여 테스트
18

19. 정적 테스팅
 정의
 대상 소프트웨어가 사용되지 않고 테스팅을 한다
 소스코드, 알고리즘, 문서를 검증하는 것
 특징
 리뷰와 같이 장애(Failures) 보다 결함(Defects)을 발견
 대상 소프트웨어를 실행하지 않는 상태에서 검증 툴 활용
 정적 분석의 효과
 테스트 실행 전 조기 결함 발견
 복잡도 분석
 소프트웨어 모델상의 의존도와 불일치성 (Dependencies and
inconsistencies)
 코드와 설계의 유지보수성(Maintainability) 향상
19

20. 정적 테스팅 기법
 리뷰
 Review, Walkthrough, Inspection, Audit
 Static Analysis
 Coding Standards
 Code Metric
 Code Structure Analysis
 Control Flow Analysis
 Data Flow Analysis
 Data Structure Analysis
20

21. 동적 테스팅
 소스 코드를 실행하면서 테스트
 Code Coverage
 Test Bed 필요 (테스트계)
 블랙 박스
 소스 코드 없이 실행 프로그램만으로 테스트
 TestCase 를 만들고 기대 값을 산출 후 해당 TestCase가 기대값과
일치하는지 확인
 화이트박스
 소스코드를 가지고 테스트하는 방법
 디버깅, 단위 테스트, 스크립트 자동 실행
 검출 가능 결함
 기능의 구현 여부
 성능, 자원의 사용, 메모리 누수 등
21

22. 화이트박스 테스트
 소스코드를 이용하여 특정 부분에 대한 테스트를 수행한다.
 Unit Testing Framework 을 이용한다
 다양한 Testing Framework 이 존재
 Java : JUnit, TestNG 등 (8가지 Java 테스트 툴)
 Javascript: Karma, Jasmine 등
 테스트 검증을 위한 방법
 No Printf  Use logging framework
 테스트 자동화의 필수 조건 : Assertions ( AssertJ 등)
22

23. TDD
(Test Driven Development)
23

24. TDD 란
 Test-Driven Development
 요구사항의 테스트 요건을 먼저 고려
 Test-First Development
 실제 코드 구현 전에 테스트 코드를 먼저 작성하여 검증
 검증 완료된 코드를 구현 코드로 refactoring
 1999년 XP (eXtreme-Programming) 이라는 애자일 기반의 개발
방법론과 함께 소개
24

25. TDD
25
TDD
1.Red
2. Green3. Refactor
• 단위테스트 작성
• 테스트 코드 실패 확인
• 최소한의 필요 코드 작성
• 테스트 성공 검증
• 코드 Refactoring
• 단위테스트로 일관성 확인

26. 테스트 자동화
26

27. 테스트 자동화의 필요성
 Software 복잡성 증가
 Software 기능 변경 요청 빈번
 기능 변경 시마다 기능 검증이 필요
 Software 는 수시로 바뀐다
 이에 대응하기 위해 수시로 Refactoring 을 수행해야 한다
 이상: Refactoring  Test  Refactoring
 현실 : Refactoring  ???  포기  도태
27

28. 테스트를 하지 않는다면?
 소프트웨어 산출물의 품질 저하
 버그 양산  버그 찾기 힘듦
 새로운 기능 추가 어려움
 기능 변경 등이 어려움
28

29. 테스트 자동화가 없다면?
 자체 버그 검출 능력 저하
 모든 기능을 수동으로 테스트할 수 없음
 반복 테스트 불가능
 소스 코드 품질 저하
 소스 코드 수정에 대한 불안감
 Refactoring 불가 – 잘 도는 코드는 건드리지 마라
 자체 테스트 비용 증가
 작은 수정에도 모든 기능을 다시 테스트 해야 한다
29

30. 테스트 자동화란?
 인간의 개입 없이, 테스트를 완료하는 것
 이를 위해 Test Case를 정의하고 코드로 구현해야 함
 테스트 자동화 도구를 이용하여, 수작업이 아닌 배치 작업을
수행하는 것
 소스 변경에 따른 주기적, 자동적으로 테스트 실행
 테스트 실행 결과를 Notification
30

31. 테스트 자동화 Tools
타입 설명 도구
테스트 관리도구 테스트 관리와 수행된 활동에 대한 지원 및 관리 Test Link
Test Director
Test Manager
결함추적 결함관리, 결함 추적, 변경 요구사항 및 작업 할당 Trac
Jira
정적분석 SW를 실행하지 않고 소스코드에서 실행 시 발생할
수 있는 결함 발견
FindBugs
CheckStyle
WhiteBox 소스코드를 실행하여 단위, 통합 테스트 Junit, AssertJ
Qunit, Karma, Protractor, Jasmine
성능/부하
테스트
시스템 시뮬레이션 된 다양한 조건에서 어떻게
동작하는지 모니터링과 테스트 및 Profile
Jmeter
Gatling
9 tools for Java Performance
Tuning
형상 관리 SW, 테스트 관련 산출물의 버전 관리 및 빌드 추적 SVN
Git
빌드&배포 빌드, 단위테스트, 배포 등의 반복 작업을 자동화 Maven, Gradle
Grunt, gulp
지속적 통합 빌드 및 배포 자동화 Jenkins
31

32. 테스트 자동화 Tools 도입의 장단점
 장점
 반복적인 업무 감소
 테스트 노력 절감 및 실수 감소
 객관적인 평가 기준 제공 (정적 측정치, 커버리지)
 효율적인 비용으로 유지보수 가능
 제품의 품질 향상과 고객 만족도 향상
 단점
 테스트 관리 도구 유지비용
 초기 환경 및 테스트 설정에 많은 시간, 비용이 소요
 도구에 의해 생성된 테스트 자산(Assets)을 유지비용
 테스트 스크립트 유지보수가 어려움
32

33. Test Terms
 Test Basis
 요구사항을 내포하는 모든 문서
 테스트 케이스는 테스트 베이시스를 토대로 만들어진다
 Test Harness
 시스템 및 시스템 컴포넌트를 시험하는 환경의 일부분으로 시험
지원을 목적으로 생성된 코드와 데이터
 Test Oracle
 테스트 실행 결과의 참/거짓 판별 기준
 Test Suite
 여러 테스트 케이스의 집합
 False-fail result (False Alarm)
 결함이 아닌데도 결함으로 보고된 테스트 결과
33

34. Testing Principle
 원리 1. 테스팅은 결함이 존재함을 밝히는 활동
 결함이 없다는 것을 증명할 수 없다
 원리 2. 완벽한 테스팅(Exhaustive)은 불가능하다
 무한경로, 무한입력값, 무한 타이밍
 리스크 분석과 결정된 우선 순위에 테스팅을 집중
 원리 3. 테스팅을 개발 초기에 시작한다
 개발시작과 동시에 테스트를 계획, 전략적으로 접근
 Test case를 도출하면서 문서상의 결함 발견
 원리 4. 결함 집중 (Defect Clustering)
 적은 수의 모듈에서 대다수의 결함 발견(결함과 장애가 집중)
 원리 5. 살충제 패러독스 (Pesticide Paradox)
 동일한 테스트를 반복적으로 수행하면 버그를 찾기 힘듦
 경험기반기법을 통해 테스트 방법을 다양화
 원리 6. 테스팅은 정황(Context)에 의존적이다
 효율적, 효과적 테스트 팀 조직, 독립적 테스트 환경
 원리 7. 오류-부재의 궤변 (Absence-of-errors fallacy)
 사용자의 요구사항에 맞지 않는다면 결함을 찾고 수정하는 것은 무의미
 결함을 모두 발견했다고 해도 품질이 높다고 할 수 없다
34