Testing
- 프로그램이 의도된대로 동작하는지를 확인하고 프로그램의 결함을 확인하는 과정
- 특정 데이터를 이용해 프로그램을 실행시킨다.
- 에러/부정확한 동작 혹은 Non-functional attribute 가 결과로 나올수 있다
- 에러가 있다는것을 확인했다는 이유로 에러가 없다고는 할수 없다.
Validate testing
- 의도된 동작을 하는지 확인
Defect testing
- 결함을 찾아내는 과정
Verification
- 제품을 잘 만드는것
- 요구사항에 걸맞는 프로그램을 만들기
Validation
- 좋은 제품을 만들기
- 사용자가 진짜 요구하는 프로그램을 만들기
V&V confidence
- 시스템이 목적에 부합하는지에 대한 확신을 제공한다.
- 시스템이 얼마나 중요한지, 사용자의 기대는 얼마인지, 일찍 내보내는게 테스트보다 더 좋을지 등을 파악한다.
Inspection & testing
Inspection
- 정적 시스템의 분석이다.
- 문제를 찾기위해 사용한다.
- 문서와 프로그램을 보며 진행된다.
- 비정상적 행동과 결점을 파악할수 있다.
장점
- 테스트 도중 다른 에러가 묻힐수도 있는데, 이 또한 찾아낼수 있다.
- 완성되지 않은 프로그램 또한 확인할수 있다.
- 표준, 이식성, 유지보수성의 확인이 가능하다.
Inspection 과 testing 의 경우 서로 상호보완적으로 둘 다 필요하다.
Inspection 은 명세서의 적용 여부는 확인할수 있으나 소비자의 실제 요구사항은 확인하기 까다롭다.
Stage of testing
- Development testing
- 개발도중 확인하는것
- Release testing
- 출시 직전에 테스트하는것
- User test
- 잠재적 고객 혹은 고객들에게 테스트를 맡기는것
Development testing
Unit test
- 객체/함수 단위의 테스트이다.
- 객체-메소드의 작동방식을 테스트하는데 초점을 둔다.
- 결함 확인에 중점을 둔다.
예시
- 객체 내부의 메소드/함수
- 객체 자체
Object test class
- Test coverage ( 테스트 한 부분 ) 이 클래스 전체가 되도록 완성해야 한다.
- 객체가 하는 모든 행동을 테스트 해야한다.
Automation
- 가능하면 Unit test들은 반드시 자동화되어 실행 및 체크되어야 한다.
- JUnit과 같은 프레임워크를 사용할수 있다.
SETUP - 테스트 케이스에 따라 시스템을 초기화 하고 입력과 원하는 출력을 정한다.
CALL - 테스트하길 원하는 메소드/객체를 불러온다.
ASSERTION - 결과와 원하는 출력을 비교한다.
Unit test case 고르기
- 프로그램의 일반적인 동작을 반영하는것
- 일반적인 문제가 발생하는 경우를 테스트하는것
- 이상한 입력과 같은것
Testing strategy
Partition testing : 비슷한 출력을 가지는 입력끼리 묶어서 테스트하는것
- Equivalence class
Guideline-based testing : 테스트케이스를 만드는데 이전의 경험을 기반으로 한 가이드라인을 두는것
Component testing
- 컴포넌트 내에서의 개별 유닛들이 제대로 융합되어 동작하는지를 확인한다.
- 컴포넌트의 인터페이스를 위주로 확인한다.
Interface testing
- 인터페이스 타입
- Parameter interface
- 컴포넌트간 데이터 전송, 패러미터
- Shared memory interface
- 컴포넌트가 메모리를 공유하는 인터페이스에 대한것
- Procedural interface
- 여러 프로시저를 담고 있어 다른 시스템에서 호출될수 있는것
- Message passing interface
- 소켓 등을 이용해 컴포넌트간 데이터를 전송하는것
- 인터페이스 에러
- Interface misuse
- 컴포넌트를 호출하는데 실수를 하는것
- 예를 들면 패러미터의 순서나 타입이나 갯수를 잘못 사용하는것
- Interface misunderstanding
- 컴포넌트를 올바르지 않은 때에 사용하는것
- 곱셈을 해야하는데 덧셈 컴포넌트를 사용하는것
- Timing error
- 컴포넌트간 실행 속도의 차이로 인해 발생
- Async/Await 처리가 되지 않은 fetch 문
인터페이스 테스트 가이드라인
- 반드시 널 포인터 문제를 확인해야 한다.
- 패러미터가 잘 정의 되었는지 확인한다.
System testing
- 컴포넌트의 일부 혹은 전체를 테스트한다.
- 컴포넌트간의 상호작용을 중점적으로 테스트한다.
- Non-functional 한 부분을 포함한다, 즉 성능적인 부분의 테스트를 수반한다.
- 계획한 시나리오대로 동작하는지를 확인한다.
- 이 과정에서 외부에서 개발한 컴포넌트를 합치는 과정이 일어난다.
- 각각의 프로세스보단 모음으로서 테스트한다.
Use-case testing
- 시스템 상호작용의 확인
- 각각의 usecase는 다수의 컴포넌트를 포함한다.
- sequence diagram과 use case 를 통해 상호작용이 테스트된다.
Testing policy
- 전체 테스트는 완벽히는 불가능하기에, 테스트를 할 부분을 정해는것이 중요하다.
Test Driven Development
- 테스트와 개발을 번갈아가며 진행한다.
- 테스트 할 요소를 미리 적어놓고 개발, 개발 완료된것은 반드시 테스트를 통과할때까지 진행한다.
- 테스트가 통과시 다음 요소의 테스트를 만들어두기 시작한다.
- 즉 증분적으로 개발을 한다.
장점
- Code coverage
- 대부분의 코드가 테스트를 하게 된다.
- Regression testing
- 프로그램의 개발에 따라 테스트의 내용도 추가적으로 개발된다.
- Simplified debugging
- 이전에 개발된 내용들은 이미 테스트가 완료되었기에, 버그 발생시 테스트하지 않은 부분만 고려하면 된다.
- System documentation
- 테스트 자체가 코드가 어떤 동작을 하는지에 대한 문서화와 동일하다.
Release testing
- 배포 직전의 테스트, System testing 의 일부이다.
- 개발자가 아닌 사람들이 테스트를 진행하는 경우가 많다.
- 프로그램이 궁극적으로 쓸만 한지에 대해 테스트한다.
- 결점을 찾는것 만이 목표가 아닌것이다.
Requirement based testing
- 요구사항에 만족하는지를 테스트 하는것이다.
Performance testing
- Release test 에서 성능과 신뢰성 또한 시험될수 있다.
- 의도적인 오버로드를 걸어서 성능의 검사를 할수 있다.
- 시스템이 동작 불능이 되기 직전까지 테스트를 진행한다.
User testing
- 필수적인 실제 유저들의 테스트
Alpha testing
- 개발팀과 같이 일하는사람들이 테스트
Beta testing
- 사람들에게 테스트를 해보고 문제점을 찾을수 있도록 해준다.
Acceptance testing
- 시스템이 받아들여질수 있을지 확인 하는 과정이다.
- Agile에선 개발팀에 반드시 유저를 포함하고 있어야 한다.
- 개발 도중 틈틈히 테스트를 해야 한다.
만능 컴덕후 겸 번지 팬