테스트
- IEEE : 테스트는 시스템이 명시된 요구를 잘 만족하는 지
예상된 결과와 실제 결과가 어떠 ㄴ차이를 보이는 지 검사하고 평가하는 작업 - 조하 만나 Xoha Manna : 테스트는 시스템의 명세까지 완벽하게 옳다고 확신할 수 없고, 테스트 시스템 그 자체가 맞다고 증명할 수 없기 때문에 프로그램을 완전히 테스트 할 수 없다.
- 달 Dahl, 다익스트라 Dijkstra, 호어 Hoare : 테스트는 결함이 있음을 보여줄 뿐, 결함 없음을 증명할 수 없다.
(공통으로 의미하는 것)
결함이 없는 소프트웨어는 없다.
테스트 수행 문제
- 테스트 케이스가 적어 효과에 한계가 있다.
- 완벽한 테스트 케이스를 도출하기 어렵다.
- 테스트를 위한 실제 사용 환경을 구축하기 어렵다.
- 작은 실수를 발견하기 어렵다.
- 테스트의 중요성에 대해 인식이 부족하다.
- 고객의 요구사항을 충족해야 한다.
- 테스트 단계에서만 수행되는 단순한 활동이 아니라 개발 단계와 함께한다.
- 파레토 원리 pareto prnciple 를 적용할 수 있다.
80%의 오류는 20%의 프로그램 모듈에서 발견된다. - 모듈 단위를 확대해 나가며 진행한다.
- 완벽한 테스트는 불가능하다
- 개발자와 다른 별도의 팀에서 수행한다.
테스트는 전문가나 전문 팀이 한다. - 살충제 패러독스 (테스트 내성) 문제 해결을 위해 테스트 케이스 업데이트가 필요하다.
동일한 테스트 반복 시 새로운 오류를 찾지 못한다.
이를 위해 정기적으로 검토하고 지속적으로 개선한다.
📌 오류, 결함, 고장은 다른 말임을 기억하자
-
오류 error
개발자에 의해 생기는 실수
결함의 원인이 된다. -
결함 defect, bug, fault
오류에 의해 프로그램이 완전치 못한 것
고장의 원인
ex) 필요 없는 정보 포함하는 경우
ex) 필요 정보 없는 경우
ex) 결함으로 인해 실행 중 멈추는 경우
ex) 작동 불능 상태에 빠지는 경우 -
고장, 실패 failure, 문제 problem, 장애
시스템이 요구사항대로 작동하지 않는 것
테스트 계획
1) 테스트 목표 정의
2) 테스트 대상 및 범위 결정
3) 테스트 계획서 작성 및 검토
테스트 분류
시각에 따른 테스트 - 확인 verification 테스트
개발자의 시각으로 테스트개발자가 착각해 개발했을 경우 확인 테스트만으로는 사용자가 원하는 것을 개발했는 지 알 수 없음.
시각에 따른 테스트 - 검증 validation 테스트
사용자의 시각으로 테스트사용자의 요구사항대로 만들었는 지 테스트
이 둘을 묶어 V & V Verification and Validation 이라고 함
사용 목적에 따른 테스트 - 성능 테스트
소프트웨어의 효율성을 진단하는 테스트사용자의 요구사항 중에서 성능과 관련된 요구사항을 얼마나 준수했는 지 테스트
中 부하테스트
: 부하의 양을 점차적으로 늘려 가면서
초당 처리 능력 Throughput per Second와 요청당 응답 시간 Response Time의 변화 추이 측정
사용 목적에 따른 테스트 - 스트레스 테스트
부하를 발생시켜 최고치인 상황에서 시스템의 반응을 살피고 발생하는 오류 찾는 것사용 목적에 따른 테스트 - 보안 테스트
부당하고 불법적인 침입 시도해 잘 막아내는 지 테스트사용 목적에 따른 테스트 - 안정성 테스트
오랫동안 운영이 되어야함.
며칠 동안 부하를 주면서 시스템이 안정적으로 돌아가는 지를 테스트사용 목적에 따른 테스트 - 복원 가능성 테스트
자체적으로 복구가 잘되는 지 테스트 자동 회복 시 재초기화 제대로 수행되는 지, 완전하게 복구 되었는 지 등 평가
전문가에 의해 회복 시 고장 수리 소요 평균 시간이 허용 범위 한계치 내인지 평가
프로그램 실행 여부에 따른 테스트 - 정적 테스트 static test
프로그램 코드를 실행하지 않고 여러 참가자가 모여 모든 명세, 코드를 검토해 결함 defect를 찾아내는 방법실패보다는 결함을 찾아내는 방법
📌 아닌 것은?
정적 테스트 - 비공식 검토 informal technical review
산출물(개발 과정에서 생성되는 문서)을 동료와 함께 책상에서 검사하는 것제품을 검토할 목적으로 하는 간단한 만남 등
정적 테스트 - 공식 검토 formal technical review
동료와 소프트웨어 기술 전문가들이 수행하는 소프트웨어 품질 제어 활동결함을 찾기 위해
(공식 검토에서는 해당사항을 검토한다)
- 원시 코드상에 존재하는 오류 검토
- 사용자의 요구를 충분히 반영했는 지 검토
- 미리 정의된 표준을 지키는 지 검토
- 개발 방식이 일관적인지 검토
- 관리하기 쉬운 지 검토
(절차)
1) 계획 planning
참가 인원, 누구 참여, 어떤 역할 정함
2) 착수 kick-off
참석자들에게 회의 문서를 배포하고 본 검토회의에 대해 설명한다
3) 개별 준비 preparation
본회의를 하기 전에 체크리스트를 사용해 참석자들에게 미리 한 번 검토하도록 한다.
토의할 내용 체크하며 질문 내용 정리
4) 검토회의 수행 review meeting
본회의에서 참석자들이 발견한 결함 내용 등을 정리하고 문서로 작성
상세 회의록도 작성한다.
5) 재작업 및 수정 rework
문서 작성자가 회의에서 정리한 결함을 담당 개발자에게 전달
개발자는 전달받은 결함 내용을 파악해 수정 작업을 한다.
6) 완료 작업 또는 후속 처리 확인 follow-up
정적 테스트 - 개별 검토 self review
가장 간단한 방법
상대적으로 객관성이 떨어진다
정적 테스트 - 동료 검토 peer review
누락과 같은 결함을 조기에 발견할 수 있다는 것
BUT, 누가 검토하느냐에 따라 성과가 달라진다.
정적 테스트 - 검토회의 walk-through
전문가들에 의해 개발자의 작업을 검토하는 과정3~5명 정도의 전문가들이 미리 제공된 검토 자료들을 정해진 절차에 따라 평가
문서들이 고객의 요구사항을 정확하게 명시하고 있는 지 여부 확인하고 작업진척상황 확인
- 개발자는 회의 자료를 준비하고 회의 일정을 계획한다.
- 검토회의의 결과를 인사 평가 자료로 사용해서는 안된다.
- 회의가 있기 4~6일 전에 전달에 참여자가 미리 살펴보고 올 수 있도록 한다.
- 검토회의는 문제점을 찾는데 주안점을 두고, 그 문제 해결은 검토회의 이후로 미룬다.
- 회의 때 작성한 오류 리스트는 회의가 끝난 후 개발자에게 전달한다.
- 검토회의 시간은 너무 길지 않아야 한다. 일반적으로 1~2시간 이내가 좋다.
소프트웨어 검사 software inspection
1) 계획
2) 개괄설명회 overview
피검열자는 참가자들에게 검열받을 내용을 전달한다.
3) 검사 준비 preparation
자료는 회의 개최 2~5일 전까지 전달한다.
- 주재자 moderator : 검사를 전체적으로 기획, 중재하는 사람
- 개발자 author : 검사받을 프로그램을 만드는 사람
- 기록자 recorder : 진행 상황을 기록하는 사람
- 검토자 reviewer : 전달받은 자료를 검토하는 모든 참가자
4) 검사 회의 inspection meeting
5) 수정
6) 후속 조치
[ 설계 검사 ]
- 완전성 검사 : 요구한 기능들이 설계에 반영되어있는가
- 일관성 검사 : 용어가 서로 다르게 해석되지 않았는가
- 정확성 검사 : 모듈 사이에 인터페이스가 잘 정의되어있는가
[ 원시 코드 검사 ]
- 데이터 결함 검사 : 변수를 사용하기 전에 선언이 되었는가
- 제어 결함 검사 : 제어문에서 조건이 정확한가
- 입출력 결함 검사 : 모든 입력 변수가 사용되고 있는가
- 인터페이스 결함 검사 : 인자의 데이터 타입, 개수, 순서가 일치하는가
동적 테스트 dynamic test
📌 난의도 높은 문제 여기서 출제
실제 프로그램을 실행함으로써 오류를 찾는 것
동적 테스트 - 명세 기반 테스트
예상 출력 값을 정해 놓고 그대로 결과가 나오는 지를 확인함으로써 오류를 찾는다.== 블랙박스 테스트 blackbox test
프로그램 내의 구조나 알고리즘을 보지 않고, 요구분석명세서에서 테스트 케이스를 추출해 테스트
사용자가 원하는 기능을 수행했는가에 대해 테스트
명세 기반 테스트 - 신택스 기법
문법에 기반을 둔 테스트
== 이 문제가 타당한가ex) 회원 가입 시 id, 비밀번호 규칙에 맞도록 요구한다.
명세 기반 테스트 - 동등 분할 기법 equivalence partitioning
해당 입력 값을 넣고 예상되는 출력 값이 나오는 지 실제 값과 비교예상 결과값을 미리 정해둠
명세 기반 테스트 - 경계 값 분석 기법 boundary value analysis
오류를 사전에 방지하기 위해 경계에 있는 값으로 테스트명세 기반 테스트 - 원인 - 결과 그래프 기법 cause-effect graph
여러 입력 조건을 결합해 결과를 하나 이상 얻을 수 있다.해당 그래프를 이용해 의사결정 테이블 decision table을 작성한다.
1) 프로그램을 적합한 크기로 분할한다.
2) 원인과 결과를 찾는다.
3) 원인-결과 그래프를 작성한다.
4) 그래프에 제한 조건을 표시한다.
5) 의사결정 테이블로 변환한다.
6) 테스트 케이스를 작성한다.
동적 테스트 - 구현 기반 테스트
코드의 내부 구조를 테스트 설계 기반으로 사용== 화이트박스 테스트 whitebox test
== 코드 기반 테스트 code based test
입력 데이터를 가지고 실행 상태를 추적함으로써 오류를 찾기에 동적 테스트에 속한다.
구현 기반 테스트 - 문장 검증 기준 Line coverage
모든 문장이 최소한 한 번은 실행될 수 있는 테스트 데이터를 갖는 테스트 케이스1) 원시 코드를 제어 흐름 그래프 형태로 표현한다.
2) 가능한 모든 경로를 구한다.
3) 모든 경로 중 문장 검증 기준을 만족하는 경로를 선택한다.
모든 문장이 하나도 빠지지 않고 최소한 한 번은 실행될 수 있어야 함.
4) 선택한 경로에 해당하는 테스트 데이터를 가지고 실행한다.
BUT, 조건문에서 오류를 찾지 못할 수 있음
이를 보안해서 분기 검증 기준이 나옴.
구현 기반 테스트 - 분기 검증 기준 dicision coverage
조건문을 만족하는 경우와 만족하지 않는 경우로 나뉘어 테스트
개별 조건식을 무시하고 조건문만 고려BUT, (개별 조건식에서) 오류 발견하지 못할 수 있음
이를 보안해서 조건 검증 기준이 나옴.
구현 기반 테스트 - 조건 검증 기준
전체 조건식을 무시하고 개별 조건식들에 대해서만 최소한 한 번은 수행할 수 있도록 하는 테스트 케이스
개별 조건 검증구현 기반 테스트 - 분기/조건 검증 기준
개별 조건식을 만족하면 모두 만족하면서 전체 조건식도 만족하는 테스트 케이스개별 조건문 오류나도 모름
마스크 mask : 어떤 개별 조건식이 다른 개별 조건식의 결과와 상관없이 이미 결정되는 것
구현 기반 테스트 - 다중 조건 검증 기준
전체 조건식의 조건문뿐 아니라 조건문 안의 개별 조건식도 최소한 한 번씩은 수행될 수 있는 테스트 케이스 (두 조건 모두 만족)
mask 해결- and로 연결된 개별 조건식
T,F인 경우를 각각 하나씩 추가해 테스트 - or로 연결된 개별 조건식
T인 경우와 F인 경우를 하나씩 추가해 테스트
구현 기반 테스트 - 기본 경로 테스트
원시 코드의 독립적인 경로를 모두 수행하는 것을 목적1) 순서도 작성
순서도는 문장 statement, 조건문 if then else, 반복문 for 3가지 기본 구조로 표현
위 순서도는 분기노드 2개, 순환 복잡도 3개로 구성
2) 흐름 그래프를 작성한다.
제어흐름도에서 R의 수는 3개, 순환 복잡도는 3개
3) 순환 복잡도를 계산한다. Cyclomatic Complexity
매트릭으로 원시 코드의 복잡도를 정량적으로 평가하는 방법
4) 독립적인 경로를 정의한다.
5) 테스트 케이스를 작성한다.
