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

Validation 사용자의 만족에 따라 소프트웨어가 실행되는지 확인 사용자의 니즈를 충족시키는지 확인 "올바른 제품을 만들고 있는가?"에 대한 대답 니즈에 맞춘 설계 검증 명시된 요구사항들을 만족하는지 여부를 확인하기 위해 개발 단계 말 또는 중간에 구성요소나 시스템을 평가하는 프로세스 (IEEE/ANSI) 컴퓨터 기반 테스팅 - 실제적으로 소프트웨어를 실행 예. 하위 레벨 테스팅 (단위 테스팅, 통합 테스팅), 상위 레벨 테스팅 (사용성 테스팅, 기능 테스팅, 시스템 테스팅, 인수 테스팅) 동적 테스트 Verfication 소프트웨어가 명세와 일치하며 그에 따라 실행하는지 확인 "제품을 올바르게 만들고 있는가?"에 대한 대답 스펙, 설계에 맞춘 구현과정 검증 개발 단계의 산출물이 그 단계의 초기에 설..

V-모델 소프트웨어 개발의 주요 단계들(비즈니스 요구사항 명세화에서 배포까지)과 상응하는 테스트 레벨(인수 테스팅에서 유닛 테스팅까지) 사이의 일대일 대응 관계를 설명하는 순차적 개발 수명주기 모델. 폭포수 모델의 확장형. 요구사항(Requirements) 설계 사용자가 요구사항을 정의. 사용자의 언어로 작성된다. ↓ 검증(Validation) 요구사항과 솔루션이 일치하는지 확인하기 위해 사용되는 테스트들로 이루어진 한 세트. 인수 테스트(acceptance tests)라고도 한다. 인수 테스팅(acceptance testing): 시스템이 사용자의 필요 및 요구사항 및 비즈니스 프로세스 측면에서의 인수 조건을 만족하는지 확인하고 사용자, 고객, 기타 권한을 지닌 사람이 시스템의 인수 여부를 결정하기 위..

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

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

테스트 케이스는 테스트 자료(입력값)와 예상되는 출력값으로 구성되어 있다. 테스트를 해부해보면, 셋업(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 → 소프트웨어 = 고객 니즈 제품..