양이 너무 많다 ㅠㅠ
1. 테스트의 이해
테스트의 필요성과 특징
•
소프트웨어 내에 존재하지만 드러나지 않고 숨어 있는 오류를 발견할 목적으로 개발 과정에서 생성되는 문서나 프로그램에 있는 오류를 여러 기술을 이용해 검출하는 작업
•
프로그램이 완전하고 정확하다고 증명할 수는 없음
•
작게보면 원시코드 속에 남아있는 오류를 발견하는 것
•
크게 보면 개발된 소프트웨어가 고객의 요구를 만족하는지 확인하는 것
•
테스트 케이스가 적어서 효과가 떨어질 수 있다
•
완벽한 테스트 케이스를 도출하기 어렵다
•
테스트를 위한 실제 사용 환경을 구축하기 어렵다
•
작은 실수를 발견하기 어렵다
•
테스트의 중요성에 대한 인식이 부족하다
•
고객의 요구사항을 충족해야 한다.
•
테스트 단계에서만 수행되는 단순한 활동이 아니라 개발단계와 함께한다.
•
파레토 원리를 적용할 수 있다.
•
모듈 단위를 점점 확대해 나가며 진행한다
•
완벽한 테스트는 불가능하다
•
개발자와 다른 별도의 팀에서 수행한다.
•
테스트 내성 문제 해결을 위해 테스트 케이스를 업데이트 해야한다.
테스트 절차
1) 테스트 계획
•
테스트 목표 정의
•
테스트 대상 및 범위 결정
•
테스트 계획서 작성 및 검토
2) 테스트 케이스 설계
•
테스트 케이스 설계 기법 정의
•
테스트 케이스 도출
•
원시 데이터 작성
3) 테스트 실행 및 측정
•
테스트 환경 구축
•
테스트 실행 및 측정
4) 테스트 결과 분석
•
테스트 결과 분석
•
보고서 작성
5) 오류 추적 및 수정
•
오류 수정 계획
•
오류 수정
•
수정된 내용 검토
2. 테스트의 분류
시각에 따른 테스트
1) 확인 테스트
각 단계에서 개발자의 시각으로 테스트 하는것, 설계서 대로 만들었는지 테스트
2) 검증 테스트
사용자의 요구 사항대로 만들었는지를 테스트
둘을 섞어서 V&V라고도 함
사용 목적에 따른 테스트
•
성능 테스트 : 소프트웨어의 효율성 진단
◦
Throuput per Second나 Response Time의 변화 추이를 측정
•
스트레스 테스트 : 부하를 발생시켜 부하가 최고치인 상황에서 시스템의 반응을 살피고 오류를 찾는 것
•
보안 테스트
•
안정성 테스트 : 며칠동안 부하
•
복원 가능성 테스트 : 고장내고 복원이 잘 되는지 테스트
프로그램 실행 여부에 따른 테스트
3. 정적 테스트
프로그램 코드를 실행하지 않고 명세나 코드를 검토해서 실패보다는 결함을 찾아내는 방법.
•
비공식 검토 : 동료와 간단한 만남. 개별 검토와 동료 검토
•
공식 검토: 동료와 소프트웨어 전문가들이 수행하는 소프트웨어 품질 제어 활동, 결함을 찾기 위해 정의된 절차에 따라 적절히 계획되고 통제된다.
◦
코드상 오류 검토
◦
사용자의 요구 반영 검토
◦
표준 지켰는지 검토
◦
개발 방식 일관적인지 검토
◦
소프트웨어가 관리하기 쉬운지 검토
◦
계획
◦
착수
◦
개별 준비
◦
검토 회의
◦
재작업 및 수정
◦
완료 및 후속 처리 확인
1) 개별 검토
혼자 검토하는것
2) 동료 검토
동료가 검토하는 것
3) 검토 회의
개발자가 소집한 전문가들에 의해 개발자의 작업을 검토하는 과정
4) 소프트웨어 검사
검토회의를 발전시킴. 발견된 문제점들을 어떻게 수정해야 하는지 지침도 제시해준다.
•
계획
•
개괄 설명회
•
검사 준비
•
검사 회의
•
수정
•
후속 조치
4. 동적 테스트
테스트 데이터를 이용해 실제 프로그램을 실행함으로써 오류를 찾는 것
명세 기반 테스트
입력값과 출력값을 가지고 오류를 찾는다.
1) 신택스 기법
문법을 정해놓고 적합, 부적합 입력 값에 따른 예상 결과가 제대로 나오는지 테스트한다.
2) 동등 분할 기법
각 영역에 해당하는 입력 값을 넣고 예상되는 출력 값이 나오는지 실제 값과 비교한다.
입력 값에 대한 예상 결과 값을 미리 정해 놓고 각 영역에서 임의의 값을 하나 정해 입력 값으로 사용해 실제 결과가 예상 값과 같은지 확인한다.
3) 경계 값 분할 분석 기법
경계에 있는 값을 테스트 데이터로 사용해서 테스트 하는 방법. 경계 이전, 경계 값, 경계 이후 값을 가지고 테스트
4) 원인-결과 그래프 기법
•
프로그램을 적당한 크기로 분할한다.
•
원인과 결과를 찾는다.
•
원인-결과 그래프를 작성한다.
•
그래프에 제한 조건을 표시한다.
•
의사 결정 테이블로 변환한다.
•
테스트 케이스를 작성한다.
구현 기반 테스트
화이트 박스 테스트, 프로그램 내부에서 사용되는 변수나 서브루틴 등의 오류를 찾기 위해 프로그램 코드의 내부 구조를 테스트 설계의 기반으로 사용
•
테스트 데이터 적합성 기준을 선정한다.
•
테스트 데이터를 생성한다.
•
테스트를 실행한다.
1) 문장 검증 기준
원시 코드 내의 모든 문장이 최소한 한 번은 실행될 수 있는 테스트 데이터를 갖는 테스트 케이스를 선정.
•
원시 코드를 제어 흐름 그래프 형태로 표현
•
가능한 모든 경로를 구한다
•
모든 경로 중 문장 검증 기준을 만족하는 경로를 선택한다.
•
선택한 경로에 해당하는 테스트 데이터를 가지고 실행한다.
2) 분기 검증 기준
원시 코드에 존재하는 조건문에 대해 T가 되는 경우와 F가 되는 경우가 최소한 한 번은 실행되는 입력 데이터를 테스트 케이스로 사용하는 것이다.
•
원시 코드를 제어 흐름 그래프 형태로 표현
•
가능한 모든 경로를 구한다
•
모든 경로 중 분기 검증 기준을 만족하는 경로를 선택한다.
◦
없으면 여러개 묶어서 판단할 수 있다.
3) 조건 검증 기준
분기 검증과 달리 전체 조건식을 무시하고 개별 조건식에 대해서만 TF에 대해 최소한 한번 씩은 수행할 수 있도록 테스트 케이스를 선정
4) 분기/조건 검증 기준
개별 조건식을 모두 만족하면서 전체 조건식도 만족하는 테스트 케이스
•
조건이 OR로 묶인 경우 뒷 조건이 판단이 안되는 경우가 생기는 데 이를 마스크라고 한다.
5) 다중 조건 검증 기준
마스크 문제를 해결할 수 있도록 한것
6) 기본 경로 테스트
원시 코드의 독립적인 경로가 최소한 한 번은 실행되는 테스트 케이스를 찾아 테스트 수행
•
순서도 작성
•
흐름 그래프 작성
•
순환 복잡도 계산
◦
원시 코드의 복잡도를 정량적으로 평가하는 방법
◦
얼마나 많은 논리적인 경로를 가지고 있는지 계산한 값
◦
다각형의 면의 개수 = 모서리 개수 - 꼭짓점 개수 + 2
◦
CC = 엣지 - 노드 + 2
•
독립적인 경로 정의
◦
순환 복잡도가 3이면 독립적인 경로는 3개이다.
•
테스트 케이스 작성
5. 소프트웨어 개발 단계에 따른 테스트
단위 테스트
모듈의 개발을 완료한 후 개발자가 요구분석명세서대로 정확히 구현되어있는지 테스트한다.
상위나 하위 모듈이 없는 경우 가상의 상위 모듈 (테스트 드라이버)나 가상의 하위 모듈 (테스트 스텁)을 만들어서 테스트한다.
통합 테스트
단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트
모듈이 올바르게 연계되어 동작하고 있는지
•
빅뱅 테스트 : 모듈 통합을 한꺼번에 하는 방법 → 안좋음
•
점진적 모듈 통합 방법 : 하향식
◦
맨위 모듈부터 내려가면서 통합하는 방법 DFS나 BFS로 내려가면서 통합 테스트
◦
스텁 모듈 필요
•
점진적 모듈 통합 방법 : 상향식
◦
가장 아래에 있는 모듈부터 테스트
◦
테스트 드라이버 필요
시스템 테스트
개별 모듈의 단위 테스트가 끝나고 통합 테스트도 끝나면 시스템 전체가 정상적으로 작동하는지 체크하는 시스템 테스트를 해야한다.
인수 테스트
요구사항에 맞는지 확신하기 위해 하는 테스트
사용자 주도로 수행
제품의 출시 여부를 판단하는 것이 주목적
•
알파 테스트
◦
개발 완료된 소프트웨어를 회사 내의 다른 직원에게 개발자 환경에서 사용해보도록 하는것
•
베타테스트
◦
시장의 피드백을 얻기 위한 목적으로 수행
◦
특정 사용자에게 미리 사용해보도록 배포
회귀 테스트
원시 코드의 결합을 수정한 후 제대로 수정되었는지 확인하는 테스트
•
수정을 위한 회귀 테스트
◦
테스트 과정에서 미처 발견하지 못한 오류를 찾아 다시 테스트
•
점진적 회귀 테스트
◦
사용중에 일부 기능을 추가해 새로운 버전을 만들고 이 새 버전을 다시 테스트하는 것