일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
- firstChild
- .ppk
- 깃허브 토큰 생성
- EL1021E
- 테스팅
- 깃허브 연동
- 클래스 참조
- AWS 생성
- dbeaver 백업/복구
- 채팅 프로젝트
- Quartz 라이브러리
- submit 기본동작
- css 리셋
- Node Property
- 되돌리기
- git 폴더 모으기
- 자바 swing 프로젝트
- 배포 자동화
- 타임리프 참조 오류
- ..gitignore
- document 함수
- 환경변수
- CI/CD
- 소프트웨어
- Jenkins
- deploy.sh
- 깃허브 토큰 발급
- 배열 call by value
- Quartz dependency
- reset
- Today
- Total
TY blog
소프트웨어 개발 테스팅 본문
1. 테스트 케이스 ( test case )
- 무엇을 테스트하는지, 테스트 입력 - 예상출력
- 테스트데이터 : 시스템을 테스트하기 위한 입력
- 테스트 결과 : 테스트 데이터 입력에 따른 출력
* 테스트 케이스 선정을 위한 전략
1. 동등분할(Equivaience partition) : 공통 특성을 가진 입력 그룹을 식별하여 각 그룹별로 테스트 케이스를 선정한다.
ex) 절댓값 함수를 구현한다고 하면 동등분할로 양수, 0, 음수 3가지 케이스로 분할이 가능하다.
2. 가이드라인 기반 : 프로그래머가 자주 범하는 오류를 찾아내기 위한 테스트 케이스를 선정한다.
ex) 회원가입 개발에서 아이디, 비밀번호와 같은 필수적인 값을 입력했을 때와 입력하지 않았을 때의 케이스로 분할이 가능하다.
2. 테스팅의 종류
- 자동화된 테스팅 : 테스트를 실행하는 프로그램 이용, 테스트 주도 개발(TDD)을 위해서는 자동화된 테스팅이 필수로 되어야 한다.
- 회귀 테스팅(regression testing) : 프로그램의 변경으로 새로운 버그가 생기지 않았는지(사이드 이펙트) 점검하기 위하여 이전에 수행한 테스트를 다시 수행
* TDD : Test Case부터 먼저 제작하고 그 후에 코드를 작성하는 방식으로 진행된다.
TDD의 장점으로 코드를 작은 단위로 나누고 각 단위에 대한 테스트를 작성하도록 되어있어 코드의 유연성을 향상시키고 테스크를 보면 코드를 이해하기가 쉽다.
3. 단위(unit) 테스팅 : 모듈의 기능을 테스트
- 스텁(stub) : 함수간 함수호출, 특정 모듈 또는 컴포넌트의 대체 구현이며, 해당 모듈이나 컴포넌트와의 상호 작용을 시뮬레이션, 아직 구현되지 않은 함수 B에 의존하며 다른 함수 A를 테스트할 때 구현되지 않은 함수 B의 예상 반환값을 반환하여 테스트 - (하향식 통합)
- 테스트 드라이버(Test Driver) : 컴포넌트와의 상호 작용을 시뮬레이션, 모듈은 완성이 되었지만, 모듈을 사용하는 클라이언트가 완성되지 않았을 때 임시로 클라이언트를 대체하여 테스트 - (상향식 통합)
4. 개발 테스팅의 단계
- 단위테스팅 : 함수, 클래스 등 프로그램의 단위를 테스팅, 단위의 기능을 테스트하는데 집중
- 컴포넌트 테스팅(Component Testing) : 단위들이 통합된 복합 컴포넌트를 테스팅, 컴포넌트의 인터페이스를 테스트하는데 집중
- 시스템 테스팅(System Testing) : 시스템을 전체로서 테스팅, 컴포넌트의 상호작용을 테스트하는데 집중
5. 테스팅의 목표 : 주로 시스템의 버그를 발견하는 결함 테스트
6. 코드 커버리지 (Code Coverage)
- 문장커버리지 : 테스트하려는 모든 경로를 최소 1번 이상 테스트 하게 하는 기법
- 분기커버리지 : 참 또는 거짓처럼 프로그램의 모든 분기들을 성공, 실패 케이스를 최소 1번 이상 테스트 하게 하는 기법
7. 블랙박스 & 화이트 박스 테스팅
1. 블랙박스 테스팅
- 테스트 케이스를 선정하기 위하여 시스템(테스팅 대상)의 명세만을 사용
- 코드나 시스템 내부에 대한 지식을 사용하지 않고 시스템 기능만 고려하여 테스트 케이스를 선정한다.
- 기법 : 동등분할
2. 화이트 박스 테스팅 - 기본경로 테스팅
- 알고리즘, 소스코드 등 시스템의 내부 구조를 고려하여 테스트 케이스를 선정한다.
- 테스트 케이스가 독립적인 경우의 수로 적어도 한 번의 테스트는 수행해야 한다.
- 기법 : 문장 커버리지, 분기 커버리지
8. Perfomance testing
- 성능 테스트 : 시간 당 처리량 (TPS), 응답시간 (response time) 등을 측정
- 스트레스 테스팅(stress testing) : 시스템의 최대 설계 부하를 초과하는 요청을 생성하여 테스트 진행
* 스트레스 테스팅의 목적 : 시스템의 장애 행동을 관찰하여 장애시점을 찾아낸다.
* 참고문헌 : (주)한티에듀 소프트웨어공학 제10판
'소프트웨어 공학' 카테고리의 다른 글
확실성 있는 소프트웨어 시스템 (0) | 2023.11.14 |
---|---|
소프트웨어 재공학 (0) | 2023.11.07 |
소프트웨어 아키텍처 설계 (0) | 2023.10.10 |
소프트웨어 시스템 모델링 (0) | 2023.10.03 |
소프트웨어 요구공학 (0) | 2023.09.19 |