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
11. V-Model (link)
11
V 모델은 소프트웨어 개발의 각 단계마다 상세한 문서화를 통해 작업을 진행하는 잘 짜인 방법을 사용한다.
또한 테스트 설계와 같은 테스트 활동을 코딩 이후가 아닌 프로젝트 시작 시에 함께 시작하여, 전체적으로
많은 양의 프로젝트 비용과 시간을 감소시킨다.
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
16. 수명주기와 테스팅
모든 개발활동은 테스팅 활동과 대응된다
모든 개발 Activity와 관련 있는 Testing Activity 가 있다
각 테스트 레벨은 그 레벨에 맞는 특정한 목적이 있다
하위 레벨 테스팅
단위 테스팅 (Unit Testing)
통합 테스팅 (Integration Testing)
상위 레벨 테스팅
사용성 테스트 (Usability Testing)
기능 테스팅 (Function Testing)
시스템 테스팅 (System Testing)
인수 테스팅 (Acceptance Testing)
주어진 레벨에 대한 테스트의 분석과 설계는 관련된 개발 Activity
활동 동안에 시작되어야 한다
개발수명주기 모델에서 문서들의 배포판이 이용 가능하게 되면,
문서 리뷰 시작 시 반드시 테스터들이 포함되어야 한다
16
18. 테스팅 기법 종류
정적 테스팅
테스트 대상 프로그램을 실행하지 않고 테스트
동적 테스팅
테스트 대상 프로그램을 실행하여 테스트
18
19. 정적 테스팅
정의
대상 소프트웨어가 사용되지 않고 테스팅을 한다
소스코드, 알고리즘, 문서를 검증하는 것
특징
리뷰와 같이 장애(Failures) 보다 결함(Defects)을 발견
대상 소프트웨어를 실행하지 않는 상태에서 검증 툴 활용
정적 분석의 효과
테스트 실행 전 조기 결함 발견
복잡도 분석
소프트웨어 모델상의 의존도와 불일치성 (Dependencies and
inconsistencies)
코드와 설계의 유지보수성(Maintainability) 향상
19
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
24. TDD 란
Test-Driven Development
요구사항의 테스트 요건을 먼저 고려
Test-First Development
실제 코드 구현 전에 테스트 코드를 먼저 작성하여 검증
검증 완료된 코드를 구현 코드로 refactoring
1999년 XP (eXtreme-Programming) 이라는 애자일 기반의 개발
방법론과 함께 소개
24
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