[소프트웨어공학][소프트웨어공학 개발공정][테스트]소프트웨어공학의 개념, 소프트웨어공학의 주제, 소프트웨어공학의 목적, 소프트웨어공학의 역사, 소프트웨어공학의 개발공정, 소프트웨어공학과 테스트 분석

소개글

[소프트웨어공학][소프트웨어공학 개발공정][테스트]소프트웨어공학의 개념, 소프트웨어공학의 주제, 소프트웨어공학의 목적, 소프트웨어공학의 역사, 소프트웨어공학의 개발공정, 소프트웨어공학과 테스트 분석에 대한 보고서 자료입니다.

목차

Ⅰ. 개요

Ⅱ. 소프트웨어공학의 개념

Ⅲ. 소프트웨어공학의 주제
1. 방법론
2. 도구
3. 프로세스

Ⅳ. 소프트웨어공학의 목적

Ⅴ. 소프트웨어공학의 역사

Ⅵ. 소프트웨어공학의 개발공정
1. 정의 단계
2. 개발 단계
3. 유지 보수단계
1) 수정 유지보수(corrective maintenance)
2) 환경 적응 유지보수(adaptive maintenance)
3) 기능 향상 유지보수(enhancement maintenance) 및 예방 유지보수

Ⅶ. 소프트웨어공학과 테스트
1. 특징
2. 테스트 단계
3. 단위 테스트
1) 점증적 코딩
2) 정적 분석
3) 동적 분석
4. 자료 구조중심 테스트

참고문헌

본문내용

동화 도구 등 테스트 방법결정
3) 테스트 자료나 실행될 조건을 토대로 테스트 케이스를 개발
4) 테스트의 예상되는 결과를 작성. 테스트 케이스를 위한 예상된 결과를 테스트 오라클(test oracle)라 한다.
5) 테스트를 실행. 테스트 하니스(test harness):시스템의 일부 기능만 시험하기 위하여 소프트웨어에 변경을 가하는 경우
3. 단위 테스트
모듈단위의 소규모 프로그램을 테스트할 때 사용하는 방법
1) 점증적 코딩
모듈의 일부를 프로그램 한 후 간단히 테스트한다. 필요하면 수정한 뒤에 추가하여 코딩하고 테스트한다.
2) 정적 분석
프로그램을 컴퓨터에서 수행시키지 않고 원시 코드를 직접 시험해 보는 것. 코딩한 사람이 비공식적으로 프로그램을 분석하거나 공식적인 검토회를 열거나 자동화 도구를 사용한다.
자동화 정적 도구-오류 리스트, 이상이 있는 부분, 코딩 규칙에 어긋난 부분을 지적
3) 동적 분석
- 모듈이나 전체 프로그램이 수행하는 동안의 동작을 시험하는 것
① 화이트 박스 테스트
- 모듈안의 논리 흐름을 잘 관찰하는 방법으로 모듈의 논리 구조를 체계적으로 점검.(구조적 테스트)
장점 : 원시 코드의 제어 흐름을 잘 관찰할 수 있다.
단점 : 빠진 기능을 찾아내기는 어렵다.
검증 기준(coverage)
- 테스트에 의하여 확인되는 시스템의 범위
세그멘트 검증 기준
- 한 모듈의 모든 세그멘트가 적어도 한 번은 수행되어야 하는 기준
선택 검증 기준(decision coverage)
- 세그멘트 검증 기준에 더하여 선택구조의 모든 경우가 적어도 한 번씩은 테스트되어야 하는 기준
루프 검증 기준
- 세그멘트와 선택 구조의 검증 기준을 포함하고 루프에 대한 조건을 추가한 것
1. 반복 조건을 만족시키지 못하여 루프 내의 문장이 수행되지 않은 경우
2. 루프 안의 내용을 한번만 수행한 경우
3. 한 번 이상 수행하는 경우
*repeat구조-반복 구조가 적어도 한번은 수행되므로 나머지두가지경우만 테스트
*for 루프-일정한 횟수만큼만 반복되는 특수한 구조이므로 단순한 세그먼트로 간주
표현방법
논리 흐름도에 의한 표현
논리 흐름도 - 모듈 내의 제어 흐름을 간선으로 표시한 그래프로 모듈 내의 모든 세그먼트가 그래프의 정점으로 표현. 세그먼트와 선택 구조 사이의 제어흐름은 간선으로 표시
논리 흐름도와 흐름도의 차이
흐름도는 프로그램의 설계에 대한 표현이며 원시 코드를 작성하기 위하여 자세한 내용을 충분히 담고 있지 않으나 논리 흐름도는 원시 코드의 논리 흐름을 그대로 표현한 것으로 논리 흐름에 관계되지 않는 사항은 생략
표현법
While 루프 : 조건 선택이 반복 내용보다 먼저 나온다.
repeat-until 루프 : 조건 선택이 반복 내용보다 나중에 나온다.
논리 조건을 포함한 선택 구조
and를 포함한 구조 : 두 조건이 참인 경우에만 세그먼트 3이 수행된다.
or가 포함된 구조 : 참인 경우는 빠져 나와 다음 세그먼트로 입력되고 거짓인 경우는 다음 선택 노드로 들어간다.
case의 선택 구조 : 선택 노드 밑에 있는 세그먼트 노드는 case 개수만큼 그린다.
테스트 케이스
검증기준 : 논리 흐름도에 있는 경로를 적어도 한번씩 방문하도록 테스트 케이스를 만들어 수행시켜 본다.
화이트 박스 테스트의 수행
1.테스트 케이스를 만든다.
2. 테스트 결과를 예상하여 테스트 오라클을 만든다.
3. 테스트 케이스를 수행한다.
4.테스트 결과와 테스트 오라클을 비교.
②블랙 박스 테스트
-주어진 입력에 대항 예상한 결과를 보이면 내부의 동작은 자세히 관찰하지 않고 테스트를 통과한 것으로 본다. 주로 모듈의 기능을 테스트
장점 : 모듈이 완전히 작성되어 있지 않더라도 테스트가 가능하다.
단점 : 원시 코드에 요구 사항에 없는 불필요한 기능이 포함되었는지 찾아내기 어렵다.
사용 기법
동치 분해(equivalence partitioning)기법
입력 조건이 여러 개의 동치 클래스(equibalence class)로 나뉜다.
※동치 클래스-서로 같은 부류에 속할 수 있는 자료의 집합.
목적
입력이 일정한 범위 안의 값을 가져야 한다면 최소한 세 게의 동치 클래스가 존재한다. 범위보다 작은 값, 범위 내의 값, 범위를 넘어서는 큰 값.
ex)현금 자동 지급기의 총 지급액에 대한 범위가 1000원에서 30만 원까지일 때
1.1000원에서 30만 원 사이의 값(정상)
2.1000원 미만의 값(비정상)
3.30만 원보다 큰 값(비정상)
이산적 집합에 속하는 값이어야 정상 입력이라면 두 가지 동치 클래스가 존재한다. 정상 입력에 속하는 값 그 외의 값.
ex) 학적 관리 시스템에서 재학 상태가 어느 모듈의 입력일 때
1. 재학 상태의 정상적인 값(재학, 휴학, 졸업, 중퇴)
2. 그 외의 비정상적인 값
경계 테스트(boundary testing) 방법
자료값의 범위에서 경계에 있는 값이 오류를 유발하는 경우가 많다. 따라서 경계 테스트는 범위 밖에 있는 값과 경계에 있는 값으로 시험해 보는 방법
수행
테스트 드라이버나 스터브 모듈이 필요.
드라이브 모듈-모듈을 호출하고 테스트 결과를 출력하는 역할
스터브 작성-테스트되는 모듈이 다른 모듈을 호출할 때
테스트를 시작하기 전에 예상되는 결과와 함께 테스트 케이스를 준비
테스트 실행 후 그 결과를 테스트 오라클과 비교하여 오류가 있으면 수정 후 다시 테스트
테스트 수행 기록은 테스트 케이스와 함께 보관
4. 자료 구조중심 테스트
자료 구조와 관련된 오류를 찾기 위한 시험으로 실제 코드를 들여다보는 화이트 박스 테스트에 가까우나 모듈의 명세와도 면밀히 비교되어야 한다.
참고문헌
로버트 L. 글래스 저, 윤성준 역(2004) - 우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해, 인사이트
삼성SDS 기술사회(2010) - 소프트웨어공학, 한울아카데미
최은만(2011) - 소프트웨어 공학, 정익사
한혁수(2008) - 소프트웨어 공학의 소개, 홍릉과학출판사
ROGER S. PRESMAN 저, 김성규 외 2명(2011) - 역소프트웨어 공학
Stephen R. Schach 저, 유해영 역(2012) - 객체지향 소프트웨어 공학, ITC

키워드

소프트웨어공학,   소프트웨어,   산업,   정보처리,   개발공정