먼지 쌓인 키보드

정적 정적 분석으로 검토가능한 작업 산출물 - 비즈니스, 기능, 보안 요구사항과 같은 명세 - 코드 - 사용자 가이드 정적 테스팅 효과 - 동적 테스트 실행 전에 보자 효율적으로 결함을 발견하고 수정 - 초기에 발견할수있어 비용이 적게들음 - 동적 테스팅으로 발견이 쉽지않은 결함 식별 - 개발/테스트 비용 및 기간 단축 - 리뷰에 참여하는 팀원 간의 의사소통 개선 - 결함을 발견하고 제거하는데 경제적임 - 사용자 요구사항에 대한 초기 확인 동적 테스팅 효과 - 수명주기 초기에 런타임 문제를 찾을수있음

기능 테스팅 - 시스템이 수행해야 하는 기능을 평가하기 위한 테스팅 - 시스템이 해야하는 그 "무엇"을 얘기 비기능 테스팅 - 사용성, 성능 효율성 또는 보안성과 같은 시스템 특성을 평가 - 시스템이 "얼마나 잘" 동작하는지에 대한 테스팅 - 가능한 초반에 수행하는게 좋음 화이트박스 테스팅 - 시스템의 내부 구조나 구현을 기반으로 테스트를 도출 - 내부구조 : 코드, 아키텍처, 워크플로우, 시스템 내 데이터 플로우 등 변경 관련 테스팅 * 확인 테스팅 - 확인 테스팅의 목적은 원래 제대로 결함을 제대로 수정했는지 확인 - 결함이 수정된 후 이 결함으로 인해 불합격했던 모든 테스트를 새로운 소프트웨어 버전에서 재실행 * 리그레션 테스팅 - 코드의 특정 부분에 대한 변경이 무언가를 수정하기 위해서거나 또는 ..

컴포넌트 테스팅 ( 모듈 테스팅) - 개별적으로 테스트할수있는 컴포넌트에 초점 목적 - 리스크 완화 - 컴포넌트의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단 - 컴포넌트 품질 수준에 대한 자신감 획득 - 컴포넌트에 존재하는 결함 발견 - 다음 단계로의 결함 전이 방지 통합 테스팅 - 컴포넌트나 시스템간의 상호작용에 초점 목적 - 리스크 완화 - 인터페이스의 기능과 비기능 동작이 설계 및 명세와 일치하는지 여부 판단 - 인터페이스 품질 수준에 대한 자신감 획득 - 결함 발견 - 다음 단계로의 결함 전이 방지 시스템 테스팅 -명시된 요구사항을 만족하는지 확인하기위해 통합된 시스템을 테스트 목적 - 리스크 완화 - 시스템의 기능/비기능 동작이 설계되로 이루어지는지 검증 - 완성된 시스템이 기대..

1. 테스트 계획 - 테스트 목적을 달성하기 위해 필요한 접근법을 정의 2. 테스트 모니터링과 제어 - 실제 진행상황을 테스트 계획과 지속적으로 비교 3. 테스트 분석 - "무엇을 테스트할지" 테스트 베이시스를 분석 4. 테스트 설계 - "어떻게 테스트할지" 테스트 환경 설계와 도구 식별 5. 테스트 구현 - "테스트 실행하기위한 모든것이 갖춰져 있는지" 테스트 실행에 필요한 테스트웨어를 생성하고 완성 6. 테스트 실행 - 테스트 스위트를 테스트 실행 일정에 따라 실행 7. 테스트 완료 - 완료한 테스트 활동에서 데이터를 정보를 축적

www.sten.or.kr https://www.sten.or.kr/ www.sten.or.kr 1. 먼저 STEN은 소프트웨어 테스트 커뮤니티로 커뮤니티인만큰 유저들간 정보 공유나 질문을 올릴수있음 또 ISTQB 시험 일정과 시험 신청을 할수있으며 시험비는 15만원정도로 꽤 비싼편에 들며 한글/영문으로 각각 다른 회차로 있음 2. 한글과 영문의 차이? 둘다 CTFL자격이 생기지만 사람들의 말로는 영문은 내용을 꼬아내지않아 쉽다고하는데 영어가 기본으로 깔려있어야함 한글은 한글로 나오지만 그만큼 내용을 꼬아내서 정확히 이해하지않으면 힘들다고함. 3. 시험 일정 시험일정에 들어가면 뭔가 엄청 많은데 "교육생 대상"은 해당 교육을 이수하고 시험을 보는거라서 시험만을 위해 신청하지는 못함 CTFL ㅁ회 정기 한..

(이해한대로 정리한거니 잘못되었다면 코멘트 부탁드립니다.) varification (검증) : - 정적 테스팅 - (개발자 관점) 개발하고 있는 시스템이 요구사항에 맞는지 - 제공된 요구사항이 실제 요구사항과 일치하다는 가정하에 요구사항대로 만들어지고있는지 - 제품을 올바르게 만들고 있는지 예방의 과정 ex1) (확인의 단계없이 검증만 했을때의 오류) 요구사항A가 아닌 다른 고객의 요구사항B가 개발자들에게 제공되었을때 실제로는 잘못된 결과지만 제공된 요구사항B에 일치하는 제품이라면 검증의 절차로는 올바르다. validation (확인) : - 동적 테스팅 - (사용자 관점) 개발되고 있는 시스템이 요구사항에 맞는지 - 실제 고객의 요구사항의 빠진 요소 없이 모든것을 포함하는지 - 요구사항에 맞게 만들고있..

2. 소프트웨어 수명주기와 테스팅 * 수명주기 모델에서 테스팅 - 모든 개발 활동은 테스팅 활동과 대응 - 각 테스트 레벨은 그레벨에 맞는 특정한 목적을 가짐 - 개발 활동과 같이 시작 - 테스터는 개발 수명주기동안 테스팅을 준비하고 개발 중간 산출물을 리뷰하는 활동에 참가 * 폭포수 모델 vs V-모델 * 폭포수 모델 - 개발활동이 순차적으로 이루어지며 테스트활동은 모든 개발활동을 완료한 후 이루어짐 * V-모델 - 테스팅을 초기에 시작하면 좋다는 원리를 토대로 테스트 프로세스를 전반적인 개발 프로세스에 통합 - 폭포부 모델을 변행해 개선 - 개발 단계와 테스팅 활동이 어떻게 통합될 수 있는 설명 - 각 개발 단계에 테스트 레벨을 부여함으로써 조기 테스팅을 좀 더 적극적으로 구현 - 개발 리스크를 조기..

1.소프트웨어 테스팅의 기초 * 소프트웨어 품질의 정의 - 컴포넌트, 시스템, 프로세스가 명시된 요구사항은 물론 사용자와 고객의 필요와 기대를 충족시키는 정도 * 오류, 결함, 장애 오류 : 잘못된 결과를 낳는 인간의 행위, 실수와 동의어 (결함발생) 결함 : 일반적으로 버그, 결함, 결점은 동의어로 사용 / 요구된 기능을 적절히 처리하지 못하는 것 (장애발생) 장애 : 코드에 존재하는 결함의 실행 * 테스팅을 종료하는 조건 - 미리 정해둔 기준을 모두 달성한 것이 가장 의미있는 조건 (+ 시간이나 예산 소요) * 독립적인 테스트 조직은 시스템 테스팅에 투입 * 효과적인 테스트 - 계획됐거나 원했던 테스트 결과 산출 - 효과적인 테스터 : 테스팅 노력으로부터 어던 결과를 도출할 것인지 결정 * 효율적인 ..