[소프트웨어공학] Software Testing

Program testing

의도1: 프로그램이 의도된 작업을 수행한다는 것을 보여주기 위함

의도2: 프로그램을 사용하기 전에 프로그램 결함을 발견하기 위함

만들어진 인위적 데이터를 가지고 한다.

error 발견, 예외 처리, non-funcitonal에 대한 비정상적 동작도 탐지

Error의 존재를 밝힐 수는 있지만, error가 없다는 것은 밝힐 수 없음

 

Testing's Goal

#1  개발자와 고객의 요구사항을 충족하는지 확인 (Validation testing)

• 대상이 있기에 입출력 값이 확실하다
• 예측 값이 나오는지 확인
• 의도한 대로 움직이는 것이 성공적인 테스트!

For custom software

• 요구사항 명세에 기재된 모든 요구 사항에 대하여 최소한 1개 이상의 test를 진행하여야 한다.

For generic software products

• 모든 system features에 대해서, feature들이 결합된 복잡한 case, 출시할 때 통합되는 features에 대하여 모두 testing이 이루어져야 한다.

 

#2  출시 전, 요구사항 위배 또는 예외 등 오동작 탐지 및 대응 (Defect testing)

• 시스템 장애 및 충돌, 의도하지 않은 타 시스템과의 interaction, 잘못된 계산, 데이터 오염 등
• 정상 입력에 잘못된 동작, 비정상 입력에 올바른 동작
• 예상하지 못한 경우
• 협업 상 다른 개발 환경에서의 문제
• 창의적으로 생각해 모든 케이스를 테스트해서 실제 배포 전에 나타날 상황을 방지해야 한다.

 

Verification vs Validation

Verification

"Are we building the product right”.

• 프로그램을 사양에 맞게 만들었는지
• 입력 -> 출력이 정상인지 개발의 관점에서 검증

 

Validation

"Are we building the right product”.

• 고객의 요구사항에 맞는 소프트웨어인지
• 유저가 원하는, 돈을 낼 만한 가치가 있는 제품인지 검증 (유저, 운영 면의 관점)
• 개발, 설계, 마케팅, 기획... 등 다양한 관점에서 유저 입장을 고려

 

V & V Confidence

V & V의 목적: 시스템이 목적에 부합한다는 확신을 만드는 것

Software purpose

• 신뢰성, 기능성 등 software specification에 부합하는지에 따라 confidence level이 결정된다.

User expectations

• 사용자는 초기의 소프트웨어에 대한 낮은 기대감을 가지고 있다. (의심의 관점)

Marketing environment

• 시장의 상황에 따라 defect를 발견하는 것보다 빠르게 출시하는 것이 중요할 수도 있다.
• Defect testing은 창의적인 case와 베타 테스터의 참여 등 시간이 오래 걸리기 때문에 시장의 상황에 따라 defect testing의 시간이 줄어들 수 있다.

 

Inspections and testing

• 둘은 상호보완적이다.
• V & V 에서 두 방법 모두 반드시 수행되어야함.

Software Inspections

• 성능, 코드 구조, reuse 가능여부 등을 머리로 판단
• 코드 분석하며 문제점을 발견한다 (code review 등..)
• 개발 중에도 검증 가능 (프로그램 동작 불필요)
• 요구사항부터 구현까지 전 영역에 관해 적용가능
• 테스팅중에는 연결 프로그램의 영향을 받지만, 이건 정적 과정이므로 별개로 탐지할 수 있다.
• 미완된 다른 프로세스가 필요한 경우 부분적 검증 가능
• 표준 준수 or 호환성 평가 or 유지보수/재사용 평가에 용이
• 단점? 명세서 부합 여부는 검토 가능하지만 실제 고객의 요구사항 및 프로그램 성능을 검증할 수 없다.

Software Testing

• 프로그램을 실행하며 동작 확인 -> dynamic verification
• 테스트 데이터로 출력을 확인

 

 

Development testing

• 개발 중 테스팅하여 bug와 defect 탐지
• 본인이 만든 시스템 및 모든 항목에 대해 진행

 

Unit testing

• development testing의 1단계다
• 가장 작은 함수나 객체를 테스팅한다
• 클래스를 묶는 등 unit 조합에 따른 인터페이스 또는 기능에 대해 검증한다

 

Object class testing

• 객체의 모든 method 검증
• 객체가 관리하는 상태, 데이터, 특성에 대해 제대로 세팅하고 수정하는 것이 가능한가 검증
• 시나리오별 testing이 유용하다

 

Automated Testing

• 자동화 단위 테스트에서는 Junit을 사용 (자동화 프레임워크)
• 가능하면 단위 테스트를 자동화하는 게 좋다. 

Automated test components

• a setup part : 입력과 예상된 출력은 가진 test case를 가지고 시스템을 설정한다.
• A call part : 검증될 객체나 메소드를 호출하는 단계
• An assertion part : 호출된 결과와 예상된 결과를 비교하는 단계

 

Choosing unit test cases

• Test case가 의도된 대로 사용될 때 testing하는 component가 무엇을 하는지 나타낸다.
• Component에 defect가 있다면 test case에서 드러나야 한다.
• 정상 입력 시에 예상된 동작을 하는 테스트 케이스를 만든다.
• 비정상적 입력 등 문제를 야기하는 입력을 만들어 프로그램이 죽지 않는지, 제대로 처리되는지, component와 충돌하는지에 대하여 테스트할 수 있도록 해야 한다.