* Problem Testing
- 하고자하는 일을 수행하는가?(validation)를 검사 // validation testing
- error가 나는가?(verification)를 검사 // defect testing
- test를 수행하는 전재 조건 : 실행 가능한 Program, 인위적인 data 자료
- error가 없다는 것은 검증이 불가능하다.
- 먼저, validation testing을 실시(미리 제작된 test case를 활용)
- validation testing이 끝나면, defect testing을 실시한다.
그때 생각나는 data를 즉흥적으로 입력하며, 잘못된 data에도 정상적으로 돌아가는지를 파악한다.
- 각각의 test는 goal을 정해둔후 실시한다.
* V&V confidence
- Testing의 신뢰성, Goal에 맞으면 신뢰성이 높다고 할수 있다.
- confidence측정은 3가지 측면에서 발생한다.
ⓐ SW 목적 ⓑ 사용자의 기대 ⓒ 마케팅 환경
* Software Inspection & testing
- software Inspection(감리) : static verification, check list를 이용한다.
tool을 사용할 수도 잇으며, System이 아니어도 검증이 가능하다.
(진행정도를 감리하는 것이 가능하다)
- software testing(테스트) : dynamic verification, 실제 system을 실행하여 검사하는 것
ⓐ software inspection
- "사회자(moderator, chairman), Inspector, 서기"들로 구성되어 있으며, Anomalie를 발견하는 것이 목표
- 돌아가는 System이 필요한 것이 아니며, 요구사항, design, 환경 data, test data등을 check한다.
- program error를 찾는 걱이 목표이다.
- checkList를 얼마나 잘 만드는 가가 성공요인에 영향을 끼친다.
ex) Variable check list : 초기화 되었는가? null point가 존재하는가? ...
- 장점
> testing은 error하나가 잡힘에 따라 연쇄적인 수정을 요구하지만, inspection은 그러하지 않다.
> 돌아가지 않는system에 대해서도 check 할 수 있다.
> 성능은 check 하기 못하지만, 회사 나름의 standard, code convention, portability...등을 측정 가능
ⓑ Inspection and testing
- 서로 상호 보완해주는 관계이다.
- 두 개 모두 V&V process에 사용된다.
- Inspection은 명세서에 부합하는지를 check하는데 사용한다.
- 고객이 원하는 것인지는 testing을 해야지 check가 가능하다.
- Inspection은 비기능적 요구사항을 검증하지 못한다.(System testing법으로 밝혀야 한다.)
// inspection의 단점을 testing이 보완해주며 반대도 성립.
* Testing process
- Test case 생성 > Test data 생성 > Testing > 결과 비교
( Test case와 Test data의 차이를 인지하자!)
- 테스팅 Stage
ⓐ Development testing : 개발하는 도중에 하는 Test > Bug발견이 목적
ⓑ Release testing : 별도의 test team이 존재 > 하나의 완벽한 version을 생성
ⓒ User Testing : 고객이 사용할 만한 사용자에게 Test 실시(Beta test)
* Development testing
- Unit testing : 독립적으로 Test할 수 있는 작은 단위를 Test, 기능이 올바르게 구현되 있는지를 확인
- Component testing : component Test, component interface 파악이 목적
- System testing : 모든 Component를 하나로 생성 > 원래 원하는 대로 동작을 잘하는가?
비기능적 요구사항을 만족하는가?를 Test
ⓐ Unit test
- 각 Component에서 독립적으로 Test
- defect testing process이다. > error발견이 주 목적
- Unit test : 관리자가 어디까지 분리하는지 결정, 이 단위가 Unit
- Object class testing : Unit을 class단위로 실시
> Class = Attribute + Operation
> Operation이 잘 작동하고 Attribute의 변화가 올바르게 일어나는가?
> 올바른 순서에 따라 실행되는가?(이벤트에 따른 System 실행 상태 변화가 올바르게 이뤄지는가?)
> SQA팀에서 test를 실시
> class는 상속의 개념이 추가되어 있으며, 이에 따라 test도 복잡해질 수 있다.
- 각각의 Unit은 2가지 경우에 대해서 Test를 실시한다.
> 해당 Unit이 정상적으로 작동할 경우 ( Correct data input )
> 해당 Unit이 비 정상적으로 작동할 경우 ( Incorrect data input )
※ Test 전략
- Test 전략은 Partition Testing과 Guideline-based testing 2가지가 존재한다.
ⓐ Partition Testing
- Input data와 Output data를 여러 클래스로 나눈 후 조합을 한다.
- 각 class에 해당하는 값은 동치(같은 역할로 사용)이다. 즉, class의 대표값을 정해서 test실시
- 각 class의 대표값은 class의 중앙값, 경계값, 극한의 값을 대표 값으로 저장을 한다.
ex) Input : 정수 / Output : 0이 아닌 정수 > 정상적인 경우만을 생각할 경우 6개의 최소 Test 값이 필요
ⓑ Testing Guideline
- partition을 나눌수 없는 경우 guideline을 사용한다.
ⓑ-1. Sequence ( 연속적인 data를 처리할 경우 ex) sort )
> 같은 Test에 대해서는 하나의 결과 값이 나오는가? 결과가 일관 되는가?
ex) Sort (3,1,2,4) = Sort(1,4,2,3) = (1,2,3,4) 가 되는가?
> 하나의 Sequence에 대한 Test가 종료 후 다른 Sequence test를 실시할때, Sequence의 길이를 다르게한다.
> 자신이 원하는 답이 처음, 중간, 끝에 나오게 Test를 해보아라.
> Sequence 길이가 0인 것을 Test해보아라(Exception Test)
ⓑ-2. Not Sequence
> error가 나오는 모든 경우를 Test해라.
> overflow를 내보아라.
> 같은 Input을 계속 넣어 보아라.
> 잘못된 Output이 나오나 확인해라.
> 극한의 값에서 값이 잘 나오는지 Test를 해라.
ⓑ Component Testing
- Unit + Unit test로 Component들을 합치면 interface가 존재하게 된다.
- Component가 Sepc에 명시된 대로 잘 작동하는지를 확인한다.
- Code는 보지 못하고, Spec을 본 후 Test를 뽑아낸다.
- interface type
1) Parameter interface : data 전달이 잘 되는가?
2) Shared Memory Interface : 정해진 양식대로 memory를 사용하는가?
3) Procedural interface : 다른 sub program의 procedural을 잘 불러오는가? (ex> C의 함수 포인터)
4) Message Passing interface : Sub-System 간의 message전달이 잘되는가?
- interface error
1) Interface misuse : 잘못된 request or response
2) Interface misunderstanding : 잘못된 행동(과정)으로 일을 처리
3) Timing error : 어떤 일을 처리하는데 interface 오류로 인해 타임초과가 발생
ex) real time에 spec에 정의된 time에 반응이 오는가?
- Interface testing guideline
1) parameter 값을 극한으로 준다.
2) pointer가 존재한다면 Null값을 준다.(Exception check)
3) 잘못된 Input 값을 넣어서 잘 뜨는지 확인한다.
4) message passing system일 경우 stress testing을 실시한다.
> "gracefully failed"가 되는지를 확인(Stress 영향이 다른 system/process에 영향을 끼치는지 확인)
ex) 5명 접속이 가능한 System에 100명이 접속 후 System에 request를 지속요청
case I) request를 기다리는 것에 의해 컴퓨터 System이 전반적으로 멈추거나 느려짐(Not gracefully)
case II) system측에서 처리량이 많다는 메세지와 함께 request를 거절함(gracefully)
5) Shared memory system일 경우 다양한 순서로 읽고 쓰는 Test를 한다.
ex) Producer and Consumer have shared memory
case I ) producer write 1 > consumer read (result : 1) > producer write 2 > consumer read(result : 2)
case II) producer write 1 > producer write 2 > consumer read (result : 1) > consumer read (result : 2)
ⓒ System Testing
- Component들이 합쳐져서 하나의 System이 되었을 때 수행하는 test
- System testing의 목적
> Component들의 호환성 check
> Component간의 interface test
※ Component 간의 Test를 하는 이유
- ⓐ, ⓑ단계에서 하는 test는 직접 개발한 것에 대한 Test이다.
- Component test의 결과물과 재사용하는 Component의 결합이 System testing에서 발생
- 이들관의 interface, 화환성을 Test하는 것이다.
> 창벌적 성질(emergent behavior : A System 단계에서만 나오는 성질) Test
- System test는 Programmer와 designer와 독립된 팀에서 실시한다.
- User case test
> Use case는 System의 상호작용이 잘나타나 있으며, Sequence diagram을 참조하여 원하는 순서에 따라
System이 동작하는지 Test한다.
> 이는 Design 명세서에 모두 잘 표현 되있다.
- Testing Guideline : 모든 경우에 대해 Test하라.
> menu에 있는 것은 모두 test한다.
> 기능들의 조합을 test한다. ( ex) 복사 > 붙여넣기 > undo > 잘나내기 > 붙여넣기 ... )
> Input이 필요한 test는 올바른 input과 잘못된 input을 모두 test한다.
* Test-driven development
- Code 작성(개발)전에 Test를 만든다.
- Code와 test case가 모두 incremental하게 발생한다.
- Increment의 test가 끝나기 전에 다음 Increment로 넘어면 안된다.
- TDD = Extreme Programming (XP process)
- TDD process Activity
1) Increment 단위를 작게 잡는다.
2) 자동으로 test가 될만큼의 test case를 생성한다.(tool 사용)
3) 이전의 Increment와 합쳐서 test를 실시한다.
4) Increment test가 성공할 때까지 개발, test를 반복한다.
5) 성공하면 다음 Increment로 이동한다.
- 장점
> Code Coverage : 모든 Code는 적어도 한번의 test를 수행한다.
> regression testing : 이전에 개발한 Increment는 지속적으로 testing된다.
> system documentation : 문서화 하기 쉽다.
> simplified debugging : error가 발생하면 어디가 문제인지 알기 쉽다.
* Release testing
- 사용자에게 사용해도 된다는 안심감을 주기 위한 testing
- 이 단계부터는 defect가 아닌 validation test이다.
- Source code를 볼수 없기 때문에 아무 입력이나 막 넣을수 있다.
- 독립된(development team에서) team에서 test를 실시한다.
( 이전의 독립된 team은 development team 내에서 개발자, 설계자와 독립된 팀이다.)
- Requirements based testing : 요구사항을 분석하여 test case를 제작한다.
- Features tested by Scenario : 시나리오를 분석하여 test case를 제작한다.
- Performance testing : 비기능적 요구사항 Test
> 여러개의 test를 점점 많이 load하면서 성능의 변화를 살펴본다.
> stress testing을 실시하며 관찰한다.
* User Testing
- user or customer가 만족하는지를 Test
- 사용자와 개발자의 환경이 다르기 때문에 "User testing은 필수적"으로 해야한다.
- Type
ⓐ Alpha test : 선택된 사용자가 개발자의 환경에서 Test
ⓑ Beta test : 고객이 고객의 환경에서 Test
ⓒ Acceptance test : 회사가 고객에게 System을 넘길때 하는 마지막 test
1) 인수 조건 정의
2) 인수 계획 수립
3) 인수 테스트 승인
4) 인수 테스트 실시
5) 결과에 대한 협상
6) 고객의 수락 및 거절