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

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)에 있어서 어렵다. 상관적인 경계들은 프로그램이 중된되는 포인트들을 정의한..

원리 (Principles) 효과적인 테스팅을 하기 위한 토대 (foundation) ↓ 메소드 & 테크닉 원리를 기반으로 하여 메소드들과 테크닉들을 빌드할 수 있다. ↓ 방법(Methodologies) 메소드들을 효과적으로 적용시킨다. ↓ 마지막으로, 이 과정을 툴을 사용하여 자동화시킨다. 테스팅 & 분석의 원리 무엇: 품질공정(Quality process) 어디서: 버그를 가지고 있고 문제있는 구조와 모듈에 집중 언제: 가능한한 일찍 그리고 자주 테스팅 실행 누가: 효과적인 테스팅을 위해 조직(organization) 구조화(structuring) 어떻게: 효과적인 테스팅을 위한 전략들 무엇: 품질공정(Quality process) 품질(quality): 컴포넌트나 시스템 또는 프로세스가 특정한 요구..

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

신뢰성(Dependability) 정해진 시간 내에 방어적으로 신뢰할 수있는 서비스를 제공하는 능력 소프트웨어를 신뢰하는지? = 신뢰할 수 있는 서비스를 전달하는지? 서비스 사용자에게 인지(perceive)되는 시스템 행동 예. 비행기 서비스는 사람들을 이 도착지에서 저 도착지로 보내는 것이다. 장애(Failure) 원하는 서비스를 서술한 스펙(specification)에서 벗어났을 때 발생 예. 무언가를 살 수 있는 웹사이트에서 구매하려고 했을 때, 에러가 발생하는 것 → 사용자가 볼 수 있는 장애 오류(Error) 시스템의 한 부분으로서, 장애(failure)로 이끌 수 있는 요소 오류는 잠복(latent)해 있거나 활동적(effective or active)일 수 있다. 예. 코드에 버그가 있는데 ..

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. 메인 메소드 메인 메소드는 커피 메이커와..

이어지는 시리즈 자동화: 테스트 프레임워크(Junit) 자동화: JUnit 테스트 작성 JUnit을 사용하여, 유닛 테스트를 작성해보도록 한다. 테스트 주도 개발에 맞추어 작성해보기 전에 그 의미를 파악해보자. 테스트 주도 개발(Test Driven Development) 솔루션을 개발하기 위해 먼저 테스트 케이스들을 생성하고 그 테스트 케이스들에 맞추어 코드를 작성하는 방법이다. 코드를 먼저 작성하고 테스트를 생성하면, 테스트들은 솔루션이 아닌 작성된 "코드"에 맞추어 생성하게 된다. 그러므로, 테스트를 먼저 생성하는 것은 솔루션이 올바르게 작동하는지 확실히 알 수 있다. 테스트 케이스를 먼저 작성해보자. 프로그램의 조건들이다. 사용자에게 원의 반지름 값을 물어본다. "반지름 값은 ~다." 라고 화면에..

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