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

테스트 유형 시스템의 특성을 목표로 하는 구체적인 테스트 목적에 기반한 테스트 활동의 집합 테스트 요구사항을 가장 효율적으로 다루는 적절한 방법을 사용하여, 주어진 레벨에 적용되는 접근 방식 및 기술 주요 목표에 따라 테스팅은 여러 유형으로 나누어진다 기능 테스트 방식으로 기능 요구사항을 어느정도 준수하는지 평가하는 테스트 블랙박스 방법 적용 & 모든 레벨에서 수행 처리하는 '과정'보다 '결과' 중시 기능성 테스트 프로세스 1. 소프트웨어가 수행할 기능들 열거 2. 기능 사양(specifications)에 따라 입력 데이터 구성 3. 기능 사양에 따라 출력값 결정 4. 테스트 케이스 실행 5. 실제 출력값과 예상된 출력값 비교 성능 테스트 대상 테스트 항목에 필요한 부하를 발생시켜, 테스트 실행 동안 성..

블랙 박스 테스트 애플리케이션의 내부적 작동 방식과 입력값 처리 방식에 대한 지식 없이 에 초점을 맞춤 목적: 소프트웨어의 기능이 올바르게 작동하고 사용자 요구를 충족하는지 확인 모든 테스트 레벨에 적용할 수 있지만, 대부분 단위 및 통합 테스트에 사용 외부로 노출되는 기능과 비기능에 대한 테스트 중점 ex. 자동차 테스트: 차가 잘 가는지 속도, 주행 능력 등을 테스트 화이트 박스 테스트 애플리케이션의 일부 구조적 부분에 대한 테스트를 수반하므로, 코드에 대한 깊은 지식이 필요 일반적으로, 코드 작성에 직접 관여하는 개발자가 테스트 담당 목적: 과 를 강화하고, 과 을 향상 주로, 시스템, 사용자 승인 테스트 수준에서 사용 ex. 자동차 테스트: 차의 엔진이 제대로 작동하는지 조향장치와 같이 내부 구조..

유닛 테스팅: 개발자들에 의해 행해지며, 본질적으로 화이트박스 테스팅에 속함. 리스크 기반 접근법으로, 유닛이 궁극적으로 지지하는 상위 레벨 시스템 행동에 집중하기보다는 코드 자체를 공격한다. off-by-one 오류에서 루프의 경계 등을 테스트함. 배열과 그 경계들, 구조상의 또 다른 오류들에도 적용된다. 모듈의 유닛은 그 것의 핵심 기능이 정확한지 확인하기 위해 실행된다. 기능은 유닛 레벨에서 저의되며, 모듈이나 시스템 레벨과는 상관없다. 단위 내부의 결함 제거를 주목적으로 함 구조 기반 (화이트박스 테스트) 설계 기법을 주로 사용 가능한 많은 결함 발견하고자 함 테스트 케이스와 결함을 공식적으로 관리 X (주로, 개발자에게 맡김) 단위 테스트 프레임워크 또는 디버깅 도구의 지원으로 테스트 수행 자동..

유닛 테스팅 개발자가 작성한 코드를 테스트하는 것 오류발생이 쉬운 구성, 하위 수준(low-level) 기능성 보증에 사용 개발자가 프로젝트를 하면서 유닛 테스팅 계획 생성 디자인 검증(Verification) 테스팅 개발자가 모듈의 통합을 테스트하는 통합 테스팅 실행 기능성 테스팅은 개발자들 또는 테스팅 팀에 의해 실행 예. 모든 기능성 요구사항들과 외적 요구사항들을 충족시키면서, 예상대로 기능하고 보기 좋은 유닛들을 많이 만들어낼 수 있는가? 시스템 검증(Validation) 테스팅 테스트 팀에 의해 실행 시스템이 완성되거나 개발이 거의 끝나면, 시스템은 상위 수준(high-level) 행동과 비기능적 퍼포먼스를 테스트 디자인 검증 테스트와 시스템 검증 테스트 계획들은 검증 레벨의 "시스템을 올바르게..

테스트 케이스는 테스트 자료(입력값)와 예상되는 출력값으로 구성되어 있다. 테스트를 해부해보면, 셋업(Setup) 테스트가 행해질 수 있도록 소프트웨어를 어떠한 상태나 조건으로 만든다. 딱, 테스트가 실행될 수 있는 환경으로 만들어 놓는 것! 예를 들어, 인벤토리에 있는 제품을 삭제하는 테스트를 실행하려면 우선! 제품이 인벤토리에 존재해야 함. 실시(Invocation) 실시는 하나의 테스트 케이스 실행을 의미한다. 입력값들을 제공하고, 테스트에 적용되는 소프트웨어를 실행한다. 평가(Assessment) 테스트가 적용된 소프트웨어의 행동을 관찰한다. 가능하면, 실행된 행동들을 기록하고 결과를 예상된 결과와 비교한다. 해체(Teardown) 테스트가 끝난 후에 정리하는 과정. 데이터베이스 연결 닫기, 추가..

sw 테스팅의 문제점 - 가능한 행동들의 세트"만" 샘플한다 - sw 시스템들은 불연속(discontinuous)적이다 - 테스트를 한 케이스에서 하지 않은 케이스를 추론할 만한 우수한 근거가 없다 - 그러므로, 시스템의 모든 가능한 경우의 수를 고려해야한다 - 작은 시스템들마저도 무수한 가능한 경우들이 있다 The Zune Killer '1980년도부터 몇 일' 에서 '1980년도부터 몇 년 + 몇 일'로 코드를 바꾸어보자 year = ORIGINYEAR; // = 1980 while (days > 365) { if (IsLeapYear(year)) { // 윤년 if (days > 366) { days -= 366; year += 1; } } else { days -= 365; year += 1; }..

소프트웨어 테스팅의 목표 소프트웨어가 고객의 니즈를 충족시키는지 검증 운영 중 소프트웨어의 장애 발생 가능성 감소 Verification "Are we building the product right?" 우리가 제품을 올바르게 만들고있는가? or 우리가 (설계한 방법으로) 제품을 올바르게 만들고 있는가? Software should coform to its specification → 소프트웨어 = 스펙 설계에 맞춘 구현 과정 검증 Validation "Are we building the right product?" 우리가 올바른 제품을 만들고있는가? or 우리가 올바르게 제품을 설계했는가? Software should do what user really requires → 소프트웨어 = 고객 니즈 제품..