테스트이론 (11) 썸네일형 리스트형 구조적 커버리지의 종류 커버리지 기준을 정의하는 목표 커버리지 기준을 달성함으로써 주어진 프로그램 소스 코드를 다양하고 체계적으로 프로그램의 모든 부분을 최대한 넓게 실행할 수 있게 되는 것이 목표입니다 함수 커버리지 단순히 프로그램 내에 존재하는 모든 함수가 한 번이라도 호출되었는지를 측정 결정 커버리지 여기서 결정이 의미하는 바는 프로그램 흐름에 변화가 있을 때 해당 변화에 가능한 모든 조건을 다 테스트 조건 커버리지 모든 Boolean Subexpression이 각각 참과 거짓으로 한 번씩 설정되었는지를 체크하는 커버리지 기준 Modified Condition/Decision 커버리지 줄여서 보통 MC/DC 커버리지라고 합니다 이 경우에는 Condition/Decision 커버리지를 만족하고 추가로 조건에 사용되는 모든 .. 테스트 적합도 테스팅을 어느 정도 해야 충분한가? - 실행이 불가능한 답은 주어진 프로그램에서 실행할 수 있는 모든 입력을 다 실행했을 때 하지만, 가능한 입력은 사실상 무한대에 가깝기 때문에 완벽한 테스팅은 불가합니다 이 경우 테스팅은 영영 끝나지 않습니다 - 모든 결함을 다 잡았을 때 하지만, 결함이 존재하는지 존재하지 않는지, 몇 개가 존재하는지를 미리 알 수 없기 때문에 실질적으로 쓸모없습니다 언제 멈춰야 하는지 정확히 알 수 없으므로 적어도 지금 테스트 입력을 한 개 더 실행하면 얼마만큼의 이득을 얻을 수 있는가 라고 질문할 수 있습니다 이 경우에는 테스트 입력을 한 개 더 실행하기 위해서 필요한 비용 대비 하나 더 수행했을 때 얻는 이익을 비용을 비교하여 비용이 더 크면 테스트를 멈추면 됩니다 이 질문의 답.. 조합적 상호작용 테스팅과 제약조건 Airline jeju air air France City osaka paris Out 20 May Return 27 May 항공사에 두 가지 옵션이 있다 갈 수 있는 도시는 오사카, 파리 비행기를 타는 날짜는 5/20, 비행기에서 돌아오는 날짜는 5/27 페어와이즈 CIT기법을 적용하면 Airline City Out Return jeju air paris 20 May 27 May air France paris 20 May 27 May jeju air paris 20 May 27 May air France osaka 20 May 27 May 위와 같은 커버링 어레이가 도출된다 하지만 위 어레이의 경우, 제주항공을 이용하여 파리로 가는 일정이 없으므로 잘못된 테스트 입력이다 마찬가지로 에어프랑스를 이용하여.. 조합적 상호작용 테스팅 조합적 상호작용 테스팅, Comvinatorial 테스팅이라고 하며 보통 CIT라고 한다. CIT가 적용되는 예제 비행기 티켓 예약 시스템을 예로 든다 항공사 - 제주 도착지 - 오사카 혹은 도쿄 출발 - 5/20 도착 - 5/27 또는 5/28 전체 조합의 개수 2*2*2로 8가지 이 경우는 조합적인 상태작용을 테스트할 정도로 복잡한 시스템이 아니라고 할 수 있다 하지만 인천공항에 드나드는 모든 항공사를 대상으로 항공사들이 출항하는 모든 도시에 대해 아무런 제약 조건 없이 모든 가능한 입력의 조합을 계산해보고 싶다고 하면 적어도 18억 개에 가까운 조합의 개수가 필요하다. 그러므로 종합적인 폭발이 일어난다 테스팅할 떄 발생하는 문제는 가능한 모든 조합을 모두 테스트하는 것이 너무 비싸다는 점 → 해결책.. 경계값 분석 경계값 분석이 효과적인 테스팅 기법인 까닭? off by one error off by one error 프로그램의 분기 등을 결정하는 논리적 조건문에서 조건이 값 1만큼의 차이로 서로 다른 행동을 하게 되는 결함 예로는 "작다"와 "작거나 같다"의 차이를 구별하지 못해 오는 실수로 인한 오류 검출을 경계값 분석이 돕는다 Loof 올바른 루프로, for(i=0; i 등가 파티션 분기문 if, else, else if, switch case 프로그램 작성시 다양한 기능을 각각의 부분에서 구현 특정 조건을 만족하는 입력은 항상 같은 방향으로 프로그램 내에 분기 → 프로그램 같은 동작을 하도록 하게 함 Equivalence Partitioning 해당 입력이 프로그램에 적용되었을 때 같은 행동을 하게 하는 기준(조건)을 바탕으로 구별 각 구획에 있는 입력은 프로그램에 실행되었을 때 같은 동작을 하게 됨 프로그램의 기능 Equivalence Partition이 1:1의 대응 관계를 가짐 프로그램 처리 불가능한 입력 방어적 프로그래밍. 즉 프로그램이 받아서는 압되는 입력이 들어왔을 때 이상 행동 대신 적절한 안내와 정상적인 종료를 하는 메커니즘 Expected or Leagal Inpu.. 블랙박스 테스팅 Black Box Testing? 실행 가능한 프로그램을 대상으로 소스코드 등의 내부 정보 이용 없이, 테스트 입력 설계 실행하여 관찰된 결과물로 테스트를 수행한다. 내부 구조는 전혀 알 수 없고 사용할 수 없다. (= Functional Testing, Behavioural Testing) 기능적인 프로그램 스펙을 따르는 Black box Testing 예로는 유틸리티 파인드(Find)가 있다. 기능 어떠한 텍스트 패턴 지정 ↓ 주어진 텍스트 파일 안에서 해당 패턴 감지 유무를 찾음 ↓ 1회 또는 그 이상의 패터이 발생하는지 텍스트 파일 내에서 감지 ↓ 텍스트가 해당 패턴을 포함흘 경우 그 줄을 화면에 출력 조건 기능이 설명되어 있는 스펙만을 보고 적절하게 테스트 입력 디자인 ↓ 실행 ↓ 기능이 구현 .. 테스트 불가능한 프로그램 "Exhaustive 테스팅은 불가능 하다. 테스팅을 하는 이유는, 안하는 것보다 낫기 때문이다. Oracle을 이용하여 샘플한 입력에 대해 프로그램이 맞게 작동하는지 확인한다." -Elaine Weyuker Oracle Assumption (Oracle 가정) 테스트하고 있는 프로그램의 행동의 옳고 그름을 결정해줄 수 있는 메커니즘 아래와 같은 경우엔 오라클을 만들 수 있다는 자체가 무너짐 Assumption 1. Oracle을 애초에 쓸 수 없다 (예: 원주율의 정답을 정확히 모름) Assumption 2. Oracle이 존재하더라도, 많은 비용이 듦 테스팅이 불가능한 프로그램의 종류 Type 1. 프로그램 자체가 답을 모르는 문제를 풀기 위해 작성된 경우 (예: 원주율 계산 프로그램) → 명백한 이.. 이전 1 2 다음