dev + qa = hq sw dev + qa = hq sw

Q. V 모델은: 더보기 A. 소프트웨어 개발에 있어서 다른 단계들을 적절한 테스팅 과정과 짝을 이루는 소프트웨어 개발 방법론이다. 테스팅 프레임워크는 프로그램의 각 부분에 테스트 케이스들이 정의되는 프로그램이다. 테스트 케이스들을 실행하면, 생성된 결과값이 예상된 결과값과 일치하는지 자동적으로 체크한다. Q. 시스템 디자인을 테스트하는 것은? 더보기 A. 모듈 테스팅 모듈 테스팅은 시스템의 디자인을 테스트한다. 모듈 설계(또는 디테일 설계)와 짝을 이룬다. Q. 시스템 설계서을 테스트하는 것은? 더보기 A. 검증(Verification) 테스팅 Verification 테스팅에서 시스템이 시스템의 설계서(시스템이 어떻게 사용자의 필요조건들을 맞출지에 대한 이해)를 잘 따라가고 있는지 확인한다.

Q. 우리는 왜 종종 시스템 레벨보다 유닛 레벨에서 테스트를 더 엄격하게 할까? 더보기 A. 유닛 테스트는 빨리 실행되어, 더 많은 테스트들을 실행할 수 있다. 유닛 레벨에서는 내부 상태를 더 볼 수 있으므로 더 강력한 오라클을 생성할 수 있다. Q. 불필요한 확인(verification)이 필요하다는 건 무슨 뜻일까? 더보기 A. 같은 프로그램이나 서브 시스템을 검사하는 여러 다른 확인(verification) 테크닉들을 원한다. Q. 개발자들과 함께 시스템 오류를 줄일 수 있는 좋은 방법들은 무엇인가? 더보기 A. 언어 / IDE 들을 사용하여 컴파일 시간 체크를 통해 오류들을 제거한다. 흔한 오류의 종류들을 테스트/확인하기 위한 툴을 생성한다. 테스트에서 가장 흔하게 나타나는 오류들에 기반하여 개발..

Q. 소수점 숫자들은 왜 때때로 코드 에러를 발생시키나요? 더보기 A. 소수점 수들을 이용한 산수, 연산은 종종 부정확하다 → 에러 소수점 숫자들은 수가 아닌 값을 가지고 있다. 예를 들면, 무한대(Infinity)와 NaN(Not a Number)는 계산이 잘못되게 만들 수 있다. 소수점 수 계산들은 근사치다. 실제 수를 사용한 계산이 성공한 후에 소수점 수 계산값을 비교해보면 fail한다. Q. 상관적인(relational) 경계들은 왜 때때로 코드 에러를 발생시키나요? 더보기 A. 프로그래머들은 종종 off-by-one 에러를 만든다. 범위에서 엄격한 한계를 결정하는 것은 요구공학(requirements engineering)에 있어서 어렵다. 상관적인 경계들은 프로그램이 중된되는 포인트들을 정의한..

Q. 다음 단어들을 시간순으로 배열하라: (1) 오류 (error), (2) 결점 (fault), (3) 장애 (failure) 더보기 A. 2 - 1 -3 결점들은 오류를 일으킬 수 있고, 더 나아가서 오류는 장애를 일으킬 수 있다. Q. 테스팅은 어떤 신뢰성 기준을 도울까? 더보기 A. 오류 제거 Fail한 테스트들은 코드의 오류 제거로 이어진다. Q. 가용성(Availability)은 신뢰성(Reliability)과 같다. 더보기 A. 거짓. 가용성 = 시스템이 실행되고 있음, 신뢰성 = 올바른 일을 하고 있음 Q. 요구사항(requirement)들에 대하여 올바른(correct) 시스템은 안전하다. 더보기 A. 거짓. 요구사항들이 안전을 보장했을 때, 올바른 시스템은 안전하다. Q. 올바른 시스템..

Q. r은 사용자에 의해 제공된 구의 반지름이며, 아래의 공식으로 구 A의 겉넓이를 계산하는 프로그램이 있다. 도출할 수 있는 테스트 케이스들은? $$A = 4 \pi r^2$$ 더보기 A. 입력값 r = 1/2, 예상된 출력값 = 3.14 입력값 r = -1/2, 예상된 출력값 = 사용할 수 없는 입력값 입력값 r = 0 예상된 출력값 = 사용할 수 없는 입력값 → 경계조건(boundary condition) 체크 입력값 r = 100, 예상된 출력값 = 11309.73 입력값 r = -1/2, 예상된 출력값 = 사용할 수 없는 입력값 Q. 커피 메이커 예제에 대해 시스템 입력값과 출력값을 재전송(redirection)한다. ~을 테스트하기 위해서: 더보기 A. 메인 메소드 메인 메소드는 커피 메이커와..

Q. 테스팅 실행 프레임워크들(예. JUnit)은 중요하다. 왜냐하면: 더보기 A. 테스트를 통과하는지 안 하는지 결정하기 위해 오라클(예. 프로그램의 출력값을 예상값과 일치시킨다)에 반대하여 자동화 체크를 허용한다. 모든 테스트들을 실행하고, 어떤 테스트들이 pass했고 fail했는지에 대해 피드백을 제공한다. 프로그래머들이 각각의 메소드들에 유닛 테스트를 할 수 있도록 한다. 테스팅 프레임워크는 테스터들이 테스트 케이스들을 생성하고 프로그램(실험대상시스템, System under Test - SUT)에 반하여 실행할 수 있게 한다. 테스트 실행 중, 프레임워크는 자동적으로 SUT에 의해 생성된 출력값과 예상된 출력값이 일치하는지 체크하고, 테스터에게 테스트 케이스가 pass/fail했는지 피드백을 제..

Q. 자동화된 오라클은: 더보기 A. 실제 프로그램의 출력값과 테스트 케이스에서 예상된 출력값을 자동적으로 맞추는 프로그램이다. 오라클은 사람 또는 프로그램일 수 있다. 오라클의 기능은 테스트를 실행할 프로그램의 출력값과 테스트 케이스에서 도출한 예상된 출력값을 매치한다. Q. 테스트 케이스에서 셋업 단계는 테스트를 실행할 수 있도록 프로그램을 어떤 상태로 설정하는데 있어서 중요하다. 더보기 A. True Q. 해체 단계에 속하는 과제들은: 더보기 A. 테스팅이 끝난 후, 데이터를 지운다. 테스팅이 끝난 후, 연결을 닫는다. 테스팅 중에 사용했던 데이터들을 청소해야하므로 정답! 테스팅에서 열었던 연결들은 테스팅이 끝나면, 닫거나 정리해야한다. Q. 평가(Assessment)에는 어떤 과정이 속할까? 더보..

테스트 주도 개발 방법론(TDD)은 좋은 아이디어일까? 이 접근법은 어떠한 이익을 가져다줄까? 단점은 무엇일까? 더보기 Test-Driven Development "테스팅 → 개발", 짧은 사이클을 반복하며 진행 (실패 - 성공 - 리팩토링) - 실패: 실패 예상 테스트 케이스 작성 - 성공: 작성된 테스트에 통과하기 위한 최소한의 코드 작성 - 리팩토링: 통과한 코드 수정 및 개선 장점 1. 객체지향적 개발: 좀 더 명확한 구조 및 기능 설계 가능. 재사용성 기반으로 테스트를 철저히 구조화시켜 작성되므로 기본적으로 객체지향성을 띄게 됨. 2. 품질 보장: 먼저 테스팅을 함으로서, 버그 방지 및 시간 축소. 기본적으로 단위 테스트를 작성하기에 문제의 지점을 쉽게 찾아낼 수 있음. 3. 방향성 유지: 요구..