태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
처음으로 댓글달기 무료구독 트위터

   
○ 소프트웨어 테스트
 
정의 ° 노출되지 않은 숨어있는 결함을 찾기위해 SW를 작동시키는 일련의 행위와 절차로 오류발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정
목표 ° 잠재된 오류의 발견
° 기술적인 기능 및 성능의 향상
° 사용자 만족도, 신뢰도 향상
특징 ° 결함이 있다는 가정하에 테스트 계획을 수립 및 테스트 케이스 작성하여 실행
° 개발자가 자신의 프로그램을 직접 테스트 하지 않음(테스트의 결과로 디버깅수행)
° 성공적인 테스트는 무결점이 아닌 결함을 찾는데 있음
° 소프트웨어 개발의 노력분포는 40-20-40 법칙을 따른다(설계-개발-시험)
절차 ° 테스트 목표 설정(What) → 테스트 방법 결정(How) → 테스트케이스 개발 → 예상결과 작성 → 테스트케이스 실행
단계별 분류

단위
테스트

° 컴파일된 독립모듈의 완전성을 따져보는 모듈시험(Module Test)
° 자료구조, 수행경로, 오류처리, 경계, 인터페이스 테스트 등이 있음(White Box기법을 주로 사용)

통합
테스트

 

Top-Down(하향식)

Bottom-Up(상향식)

내용

° 최상위 모듈에서 하위 모듈로 테스트 수행

° 최하위 모듈에서 상위 모듈로 테스트 수행

장점

° 실사용 환경과 유사한 테스트

° 테스트 용이, 초기에 병행 작업 가능
° 대형 시스템에 적합

단점

° Stub 모듈 작성에 많은 시간 소요

° Cluster분류 곤란
° I/F 점검이 가정상태로 진행됨

특징

° Stub모듈이 필요
° Menu방식 SW개발에 적용
° 회귀테스트(Regression Test)

° 모듈의 신뢰성 향상 가능
° 최종결과 산출 곤란
° 마지막 단계까지 주요 결함 발견이 어려움

° 모듈간의 인터페이스와 관련된 결함을 발견하고 제거하면서 모듈들을 체계적으로 통합시키는 작업

회귀테스트
- 이미 수행했던 시험의 부분집합을 다시 실행(테스트 재사용 관점)
- S/W의 변경으로 영향받게 될 S/W의 기능에 초점을 맞춘 추가 시험
- 변경이 다른 부분에 영향을 주는지, 통합이 제대로 이루어 졌는지 확인

연쇄식 테스트(Threads Test)
- 입출력과 최소 기본 기능을 갖는 중요 모듈들의 집합을 먼저 통합 테스트 진행
- 부가적 기능의 모듈들은 점차적으로 구현 테스트하여 통합해 나감
- 초기에 시스템의 골격을 알 수 있고 사용자의 의견을 빠르게 수정할 수 있음

시스템
테스트

° 사용자의 신뢰성을 확보하기 위해 컴퓨터, 네트워크 제반 모든 사항에 관계된 테스트
° 시험목적에 따른 분류 - 회복, 안전, 강도, 성능, 구조 테스트

인수
테스트

° 요구를 불만족하는 Negative한 케이스 추출, 사용자측 관점에서 SW요구사항을 충족시키는지를 평가
° 확인(Validation)
° 알파테스트 - 특정 사용자에 의해 개발자 관점에서 수행, 개발자는 사용상의 문제점을 기록, 반영
° 베타테스트 - 선정된 다수의 사용자들이 자신의 사용환경에서 일정기간 사용하면서 문제점, 개선사항을 기록하고 개발조직에 통보하여 반영되도록 함(잘못된 요구분석의 발견)

설치
테스트

° SW를 사용자 환경에 설치하는 과정중에 나타날 수 있는 결함을 발견할 목적으로 수행하는 테스트

시험 시각

검증(Verification)

° 개발자, 시험자의 시각으로 SW가 명세화된 기능을 올바로 수행하는지 알아보는 과정
° 어느 단계의 산출물이 이전 단계에서 설정된 개발규격과 요구들을 충족하는지의 여부를 판단

확인(Validation)

° 사용자 시각으로 올바른 SW가 개발되었는지를 입증하는 과정
° 어느 단계의 개발제품이 최초의 사용자 요구 또는 SW 요구에 적합한지 입증하기 위한 활동

공인(Certification)

° 사용자 혹은 사용자를 보호하는 입장의 전문가가 SW 품질을 공식적으로 확인하는 것

시험 방법

Black Box

(Dynamic Test)

° 명세기반시험(Spec-based testing), 입출력시험(Input/Output testing), 기능시험(Functional testing) 으로 지칭됨
° 데이터, 입출력 위주 시험
° 동등분할 기법, 경계값 분석, Cause-Effect Graph, 결함예측기법, 비교검사

White Box

(Static Test)

° 프로그램상의 모든 논리적 경로, 복잡도를 계산하여 시험사례를 만들어 테스트를 수행하는 기법
° 데이터 흐름 검사(Data flow testing), 구조시험, 루프시험

※ 구조시험 - Macabe에 의해 제안된 대표적 화이트 박스 기법
  - condition coverage > branch coverage(Decision Coverage) > statement coverage

※ 복잡도 척도

Macabe

Halstead

° 사이클로매트릭의 수(보통 10을 넘지 않음)
° 경계된 영역들과 그래프 외부의 비경계지역의 수

° 원시코드에 표현된 사실로부터 계산되는 여러 가지 척도를 제안
° 프로그램의 유사성 검출 용도로도 사용

° V(G) = Edge - Node + 2(= DecisionCount + 1)
° 복잡도 평가
      ~ 10 : 매우 간단한 Program
      ~ 20 : 구조적이고 안정된 Program
   21 ~ 50 : 복잡한 구조의 Program
   50 ~  : 비구조적, 불안정 Program

° 연산자의 종류(n1), 피연산자의 종류(n2)
° 총연산자의 수(N1), 총피연산자의 수(N2)
° 프로그램의 길이
 


° 프로그램의 부피

° 언어추상화 레벨(최소부피)

° 프로그래밍 노력 E = V/L

TMM (Test Maturity Model)

 

정의

활동

초기

° 시험 프로세스가 정립되지 않음

 

정의

° 시험과 디버깅의 구분
° 시험이 SW 생명주기에서 하나의 독립된 단계로 정의됨

° 목표설정, 계획수립, 변경제어, 추적 및 감시

통합

° 시험이 SW 생명주기 전체에 걸쳐 이루어짐

° 조직 구성, 교육훈련, 회귀시험
° 시험 프로세스의 제어 및 감시

관리/측정

° 시험 활동이 측정되고 정량화 됨

° 검토, 측정, 품질평가

최적화

° 결점예방 및 품질제어 활동

° 결점예방, 품질제어, 프로세스 최적화

V & V Model

° 분석과 설계에 대한 반복적인 검증으로 요구사항에 대한  정확한 이해를 높인다

[관련 포스트]
2008/09/25 - [IT 노트/소프트웨어공학] - 소프트웨어비용산정(Doty, Putnam, COCOMO, COCOMO II, Function Point)
2008/08/21 - [IT 노트/소프트웨어공학] - 소프트웨어 분석 및 설계

블로그뉴스추천버튼 믹시추천버튼 올블로그추천버튼 블코추천버튼 구글리더기구독버튼 한RSS구독버튼
  1. Favicon of http://www.massagemtantrica.flog.br/ BlogIcon massagem tantrica 2014.05.12 10:12  address  modify / delete  reply

    하긴 우리들 마음속이 이러하니까...ㅎ
    즐거운 하루 되세요~빛님^^