Software testing - PDF 무료 다운로드

Software testing 소프트웨어공학개론 유준범교수님 CLASS A T8 200611478 성두훈 200611494 원스타 200611518 조민경 200611458 김영승

1. Software testing 이란? 소프트웨어테스팅 (software testing) 은개발된컴퓨터소프트웨어의품질을측정하기위해사용되는과정이다. IEEE 에서의 Software testing 정의 - 시스템이나컴포넌트가특정된상황에서실행되며, 그결과가채집되거나기록되고, 시스템이나컴포넌트의특정관점에서평가 (evaluation) 가이루어지는일련의활동, 또는이를지휘, 통제. - 하나이상의테스트케이스의집합, 또는테스트프로시져집합. - 혹은이둘의집합. - 디버깅과의차이말하기.

2. 하드웨어결함의이유 소프트웨어결함은다음의과정을통해일어난다. - 인간은코드, 소프트웨어, 시스템, 또는문서안에결함을만들어내는실수를범할수있다. 결함코드가실행되면시스템은바라던결과에대해실패할수있다. - 소프트웨어, 시스템, 문서안의결함은실패로이어질수있지만모든결함이그러한것은아니다. 또한결함이없다해도환경이바뀌면실패할수도있다. 이러한변화의예는새로운하드웨어플랫폼에서실행되거나, 소스데이터가바뀌거나다른소프트웨어와상호작용하는것을들수있다.

3. Software testing 의필요성 금전적손실 시간낭비 - 프랑스의 Ariane 5 호 비즈니스이미지손실 - 기업이나사용자의요구에오류로인해충족을못했을때 부상, 사망에이르는심각한문제발생 - 자동차나비행기같은몸체에내장된소프트웨어에문제가있을때

4. Software testing 의종류 1. 블랙박스테스팅 13. 사용성테스팅 2. 화이트박스테스팅 14. 설치 / 삭제테스팅 3. 유닛테스팅 15. 회복테스팅 4. 통합테스팅 16. 보안테스팅 5. 기능테스팅 17. 호환성테스팅 6. 앤드-투-앤드테스팅 18. 비교테스팅 7. 새너티테스팅 19. 알파테스팅 8. 리그레션테스팅 20. 베타테스팅 9. 인수테스팅 21. 시스템테스팅 10. 부하테스팅 11. 스트레스테스팅 12. 퍼포먼스테스팅

5. Software testing 의유형 SWEBOK 에서는가능한테스트의유형에대한리스트를제공한다. 이리스트는테스트의유형을다음과같은속성에기반해나눈다. - 직관과경험 - 결함 (Fault) - Specifications - 사용법 (Usage) - 코드 - Application의본질 - 데이터흐름

5. Software testing 의유형 (Con.) 가장많이사용되는다음의유형에대해서는더많은정보가있다. - Equivalence class partitioning - Boundary value - Decision table - Exploratory - Operational Profile

(1) Equivalence class partitioning 각각의 INPUT 을수용가능한범위에대해검사해서 INPUT 에대한다음과같은클래스를판별한다. - Valid : 올바른코드에의해성공적으로처리될수있는값의리스트나범위 - Invalid : 올바르지않고 Software 에서허용되진않지만, 그렇다고해서아예잘못된결과를초래하지는않는값의리스트나범위

1 Equivalence class partitioning 의단계 - 가능한입력값을 Valid, invalid 클래스로분류. - Valid 클래스의값은최대한많이테스트. - Invalid 클래스의값은각각에대해한번씩만테스트. 역시모든값테스트. Invalid 클래스는 Valid 클래스와는달리연계되지않음.

(2) Boundary value testing INPUT에대해 4개의값을테스트한다. - Valid 의최소값. - Valid 의최대값. - 최소값 1. - 최대값 + 1. ( 숫자에대해선매우명확하다 )

(3) Dicision table - Dicision table 은모든 INPUT 과그결과로생긴모든결과를테이블의첫컬럼에열거. 그뒤, 가능한모든 INPUT 상태의조합에대해 Rule 이있다. - 특정한 INPUT 에대해 Y(yes), N(no), I(immaterial) 로나타낸다.

(4) Exploratory testing 테스팅프로세스의초점을계획하는것에중점을둔다 이전 Realease 와 Product Line 과의호환성이나, 한프로젝트내에서처음부터끝까지일관성있게움직이는지를테스트한다.

(5) Operation profile 운영도중, 각각시스템기능에대해실행되는테스트의횟수를알수있다. 실제사용량이측정될수도있다. 따라서더많이사용되는기능을더많이테스트함으로써소프트웨어의견고성을높힐수있다.

6. 테스트레벨 소프트웨어가개발되고유지됨에따라한레벨에서한번이상의테스트가수행된다. 작은범위부터큰범위로테스트한다. 소프트웨어의범위, 테스트목적, 테스트테크닉, 환경에따라테스트레벨이변한다. 요인 - 시스템크기 - 복잡도 - 안전성의중요도 - 관리자의경험 / 경력 - 수요자의요구

7. 테스트전략 테스트전략은보통 Macro 나 Micro 중하나에초점을둔다. Macro - Time to market( 테스트개발과수행속도 ) - 제공되어야하는기능의양 - 제품의품질 ( 테스트의완벽성 )

7. 테스트전략 (Con.) 개발을빠르게하기위해서는 - 테스트수행을더빠르게하기위해자동화도입 - 러닝타임을줄이기위해테스트스탭교체를덜하는것 - 실행되는테스트케이스를잘선택해서심각한문제를빨리찾을수있도록함 제품의퀄리티를위해 - 더좋은툴로현재테스트커버리지를측정 - 개발자들을위해더좋은유닛테스트툴을제공 - 테스트유형을더다양하게만듬.

7. 테스트전략 (Con.) 테스트비용을줄이기위해 - 프로젝트관리툴을사용해테스트활동을예측, 실제비용지출을확인. - 기저원인분석을추가해발생한문제의원천을찾고프로세스를변경해문제가다시발생하지않도록함.

8. 테스트디자인 테스트디자인은예술과과학을접목해각각의테스트레벨에서사용할가장알맞은테스트기법을선택하는것이다. 모든기법을사용하려면리소스를너무많이먹을것이고, 쓸모없는테스팅결과를유발할것이다. 대부분의테스트디자인의목표는최소한의노력으로최대한의결과를얻어내는것이다.

8. 테스트디자인 (Con.) 테스트디자인은 Structured 와 Unstructured 기법을모두포함한다. - Unstructured 의예 - Structured 의예 1. Random 1. Equivalence class partitioning 2. Ad hoc 2. Boundary value 3. Exploratory 3. Decision table

8. 테스트디자인 (Con.) Structured 테스트기법의장점 - Linear 한커버리지를제공. - 모든 Attribute 가같은관점에서같은방식으로테스트 Unstructured 테스트기법의장점 - Structured 기법보다많은문제를발견 - 심각한문제를발견할확률높음

9. 코드의테스트커버리지 코드커버리지의목적은테스트레벨에따라달라짐 System testing 에서는커버리지가측정될수도있지만목표치는 100% 에근접하지못한다. 모든명령문을 100% 커버할수있는기법은 Tom McCabe s Basis Path Testing.

(1) Tom McCabe s Basis Path Testing. Flowgraph 를그린다. - 각각의논리적명령문을원 ( 노드 ) 이라고표현. - 결정사항의결과로컨트롤이이전되는것을화살표 ( 엣지 ) Cyclomatic cimplexity를계산 ( 엣지갯수 노드갯수 + 2) 경로를정한다

10. 테스트범위 개발을위한원본문서는포괄적인용어인 Specifications 로통합됨. 몇몇테스트레벨의목표는하나또는그이상의 Specification 을모두다루는것 - Specification 이어떤방법으로목록화되어야만측정가능.

11. 테스트실행 테스트실행을위해서는 Test Plan( 계획 ) 이필요. 모든입력과절차의실제테스트는테스트경우와테스트사례와테스트절차를자세하게기술해야함 테스트결과는각각의테스트사례의성공과실패의평가가포함된테스트계획을실행하는동안에기록됨 -> Incident report

12. 테스트문서화 테스트문서화는다양한매체에기록한다.