본문내용 바로가기
무료배송 이벤트 소득공제

소프트웨어 테스트 자동화 테스팅 전문가들의 생생한 사례연구 스토리로 익히는

에이콘 소프트웨어 테스팅 시리즈 6
도로시 그레이엄 , 마크 퓨스터 지음 | 여용구, 김윤명, 황영석, 성찬혁 옮김 | 에이콘출판 | 2013년 12월 23일 출간
  • 정가 : 45,000원
    판매가 : 40,500 [10%↓ 4,500원 할인]
  • 통합포인트 :
    [기본적립] 2,250원 적립 [5% 적립] 안내 [추가적립] 5만원 이상 구매 시 2천원 추가적립 [회원혜택] 우수회원 5만원 이상 구매 시 2~3% 추가적립
  • 추가혜택 : 카드/포인트 안내 도서소득공제 안내 추가혜택 더보기
  • 배송비 : 무료 배송비 안내
  • 배송일정 : 서울특별시 종로구 세종대로 기준 지역변경
    당일배송 지금 주문하면 오늘(17일,금) 도착 예정 배송일정 안내
  • 바로드림 : 인터넷으로 주문하고 매장에서 직접 수령 안내
장바구니 담기 바로구매

책 그리고 꽃 서비스
책 그리고 꽃 | 책과 꽃을 함께 선물하세요 자세히보기

닫기

바로드림 주문 선물하기 보관함 담기
이벤트도서포함, 5만원이상 구매시 택1 (벚꽃/자동차/나뭇잎/번짐4종, 포인트 차감)
닫기
  • 월간 그림책 갤러리 vol.14
  • 2018 여름방학 유아/어린이/좋은부모 추천도서
  • Toy Book Festival_핑크퐁 썸머패치
  • 심리학 도서 x 피크닉 매트 마인드 바캉스
  • 7월 어린이 손수건
  • 더나은 해답은 반드시 있다
  • 과장K의 비즈니스 리포트
  • 지식인 추천도서 X 아이스 텀블러 2018 인문교양 마스터스 오픈 섬머
  • 이벤트도서포함, 5만원이상 구매시 택1 (블랙/네이비/웜그레이/그레이블루 4종, 포인트 차감)
  • 비치타월 증정 월간 생활책방 8월호
  • 취업콘서트
  • 역사는 여행이다 (유시민 여권케이스)
  • 역사에 부는 바람 (조선왕조실록 출간기념 역사도서전)
  • 교보문고  X 제주관광공사
  • 이기주 작가 사인 북케이스 증정 리-커버:K #19 이기주, 말의 품격
  • 이벤트도서포함, 2만원이상 구매시 택1 (마을/호텔/꽃잎/퍼플 4종, 포인트 차감)

이 책의 이벤트 해외주문/바로드림/제휴사주문/업체배송건의 경우 1+1 증정상품이 발송되지 않습니다.

  • MANNING, O'REILLY, PACKT, WILE..
    2016.03.07 ~ 2020.12.31
상품상세정보
ISBN 9788960775022(8960775029)
쪽수 728쪽
크기 188 * 250 mm 판형알림
이 책의 원서/번역서 Experiences of Test Automation: Case Studies of Software Test Automation/Graham, Dorothy

책소개

이 책이 속한 분야

테스트 자동화는 절대로 한 번에 끝나지 않는다. 그렇기에 계속해서 내 손에 익숙한 툴과 방법을 찾아 연습과 적용을 거듭하고, 인내하면서 가꿔 나가야 한다. 이 책에는 여러 분야에서 다양한 서비스와 제품을 맡은 테스트 엔지니어들의 자동화 스토리가 고스란히 담겨 있다. 무엇보다도, 효과적인 자동화 테스트의 본질을 설명하며 실제 자동화 프로젝트에서 얻은 가치 있는 경험과 팁, 교훈, 기억해야 할 점이 고스란히 담겨 있는 흥미진진하고 잘 작성된 광범위한 케이스 스터디 모음집이다.

이 책의 총서

저자소개

저자 : 도로시 그레이엄

저자 도로시 그레이엄(Dorothy Graham)은 전세계에서 유명한 컨설턴트이자 강사 및 저자로 약 40년간 소프트웨어 테스팅 분야에서 활약 중이다. 그로브 컨설턴트(Grove Consultants)에서 약 19년 동안 근무했고, 현재는 학술회와 저술에 힘쓰고 있다. 1993년과 2009년 유로스타 컨퍼런스에서 프로그램 위원장을 맡았고, 소프트웨어 테스팅 분야에서 유러피언 엑셀런스 어워드를 수상했다. 퓨스터와 함께 베스트셀러였던 『Software Test Automation(소프트웨어 테스트 자동화)』(Addison-Wesley, 1999)를 공저했다.

저자 : 마크 퓨스터

저자 마크 퓨스터(Mark Fewster)는 30년간 소프트웨어 테스팅과 자동화 분야에서 다양한 경험을 쌓았다. 다중 플랫폼 그래픽 애플리케이션의 개발자 및 관리자로서 견고한 테스트 자동화 아키텍처를 설계했다. 1993년 이후 지금까지 그로브 컨설턴트에서 소프트웨어 테스팅의 모든 분야에 관한 교육과 컨설팅에 힘쓰고 있다. 그레이엄과 함께 『Software Test Automation(소프트웨어 테스트 자동화)』(Addison-Wesley, 1999)를 공저했다.

역자 : 여용구

역자 여용구는 현재 네이버 비즈니스플랫폼 QA팀에 재직 중이다. 1년이 지나도 살아있는, 내실 있는 테스트 자동화에 관심이 있다. 주요 번역서로는 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』(에이콘출판, 2009)가 있다.

역자 : 김윤명

역자 김윤명은 현재 GlobalEnglish Korea Inc.에서 시니어 QA 엔지니어로 근무하고 있다. 관심사는 애자일 테스팅으로 애자일 테스팅의 올바른 프랙티스와 애자일 방법론 내에서의 효율적인 테스트 자동화를 고민하고 있다. 주요 번역서로는 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』(에이콘출판, 2009)와 『뷰티풀 테스팅』(지앤선, 2011)이 있다.

역자 : 황영석

역자 황영석은 명지대학교에서 컴퓨터공학 석사학위를 받고, 네이버 비즈니스플랫폼 QA팀에서 품질 관리 업무를 하고 있다. 주요 관심 분야는 웹 테스팅, 모바일 테스팅, 자동화 테스팅이다.

추가역자

역자 : 성찬혁
현재 네이버 비즈니스플랫폼 QA팀에서 QA 엔지니어로 재직 중이다. 저녁이 있는 아름다운 삶을 꿈꾸며, 효과적이고 효율적인 테스트를 위한 연구에 많은 관심을 갖고 테스트 자동화 관련하여 다양한 시도를 해보고 있다. 우리나라 QA 분야의 발전에 조금이나마 기여할 수 있는 방법을 여러모로 모색하는 중이다.

목차

1장 애자일 팀의 테스트 자동화 여행: 첫 번째 해
___1.1 케이스 스터디의 배경
______1.1.1 문제
______1.1.2 목표
___1.2 팀 전체의 헌신
___1.3 자동화 전략 설정
______1.3.1 테스트가 용이한 아키텍처
______1.3.2 빌드 프로세스 구축
______1.3.3 테스팅 기반 생성: GUI 스모크 테스트
______1.3.4 단위 테스트 단계의 개발 추진
___1.4 FitNesse를 사용하여 GUI 뒤 단의 테스트에 ATDD 적용하기
______1.4.1 인메모리 테스트
______1.4.2 데이터베이스를 이용한 테스트
______1.4.3 FitNesse 테스트의 장점
___1.5 점진적 접근법 사용
___1.6 올바른 메트릭
___1.7 성공을 축하하라
___1.8 통합 엔지니어링 스프린트
___1.9 팀의 성공
___1.10 지속적인 개선
___1.11 정리

2장 최적화된 데이터베이스 자동화
___2.1 케이스 스터디의 배경
___2.2 테스트 대상 소프트웨어
___2.3 테스트 자동화 목표
___2.4 사내 테스트 도구 개발
______2.4.1 설정
______2.4.2 리소스 최적화
______2.4.3 보고서
______2.4.4 실패 분석
___ 2.5 결과물
___2.6 자동화 테스트 관리
___2.7 테스트 스위트와 타입
___2.8 현재 모습
___2.9 어려웠던 점과 배운 점
___2.10 테스트 자동화 서적의 가이드 적용
___2.11 정리
___2.12 감사의 말

3장 클라우드로의 이동: TiP의 진화, 프로덕션에서의 지속적인 리그레션 테스팅
___3.1 케이스 스터디의 배경
___3.2 클라우드 환경으로 테스트 전환
______ 3.2.1 TiP 테스트 전략에서 얻고자 한 것
______3.2.2 기본 원칙
___3.3 TiP 구현 방법
___3.4 월간 서비스 리뷰 평가표의 예
______3.4.1 평가표 읽기
______3.4.2 인시던트와 에스컬레이션 보고서로 한 일
___3.5 익스체인지 TiP v2: 윈도우 애저 클라우드로의 TiP 마이그레이션
___ 3.6 배운 점
______3.6.1 파트너 서비스 관련 이슈
______3.6.2 클라우드를 통한 모니터링이 직면한 도전
______3.6.3 TiP 테스트로 발견한 프로덕션 이슈의 예
______3.6.4 결과에서 방해요소 처리에 사용할 집계
______3.6.5 주의할 점
___3.7 정리
___3.8 감사의 말

4장 오토메이터 자동화
___ 4.1 케이스 스터디의 배경: 첫번째 일자리
______4.1.1. 첫 번째 역할: 기술 지원
______4.1.2 QA팀에 합류
___4.2 대단한 아이디어
______4.2.1 지속적인 노력
___4.3 돌파구
______4.3.1 일 시작
______4.3.2 체크포인트 검증
______4.3.3 그 후 어려워진 점
______4.3.4 최후를 예고하는 징조의 시작
___4.4 정리

5장 자동화 엔지니어의 자서전: 메인 프레임에서 프레임워크 자동화까지
___ 5.1 케이스 스터디의 배경
______5.1.1 초기 테스트 자동화: 테스팅 툴과의 첫 만남
______5.1.2 테스트 리플레이에 툴 사용 문제 극복
______5.1.3 메인 프레임 덤 터미널 시스템이 동작하는 방식과 캡처/리플레이 방식이 좋은 아이디어인 이유
______5.1.4 수동 리플레이와 장점
___5.2 메인 프레임 그린스크린 자동화 프로젝트
______ 5.2.1 확대 적용
______5.2.2 자동화 툴 스크립트에 자동화 툴 적용
______5.2.3 성공
______5.2.4 현재 자동화를 원하는 사람
___5.3 메인 프레임과 스크립트 기반 툴의 차이점
______5.3.1 상호작용의 수준
______5.3.1 동기화
_________5.3.1.2 유저 인터페이스 객체
___5.4 새로운 스크립트 기반 툴 사용
______5.4.1 기존 방법으로 새로운 툴의 사용 시도
______5.4.2 툴 프로그래밍
______5.4.3 프레임워크 구축
______5.4.4 프레임워크의 기타 기능
______5.4.5 소프트웨어 테스트 자동화 패러독스: 자동화 테스트에 대한 테스트
___ 5.5 IBM 맥시모의 테스트 자동화
______5.5.1 2010년
______5.5.2 리버레이션 프레임워크
______5.5.3 기술적 도전
_________5.5.3.1 동기화
_________5.5.3.2 UI 객체 인식 문제
_________5.5.3.3 사람과는 다르게 동작하는 툴
_________5.5.3.4 자동화의 3R
______5.5.4 테스트 자동화의 결과
______5.5.5 나머지 조직으로의 자동화 출시
___5.6 정리
___ 5.7 추가자료

6장 첫 번째 프로젝트의 실패와 두 번째 프로젝트의 성공
___ 6.1 케이스 스터디의 배경
___6.2 첫 번째 프로젝트의 실패
___ 6.3 두 번째 프로젝트의 성공
______6.3.1 ROI 추정
______6.3.2 시작
______6.3.3 파일럿 프로젝트의 목표
______6.3.4 첫 번째 달: 실무와 툴의 이해
_________6.3.4.1 공통된 이해와 툴 관련 지식
_________6.3.4.2 문서화
_________6.3.4.3 보험 신청서 관련 지식
_________6.3.4.4 보험 신청서 GUI의 일반 영역과 특정 영역
______6.3.5 전략과 계획
______6.3.6 애자일 테스트 방법론
______6.3.7 첫 번째 기간의 결과
___6.4 다음 기간: 실제 테스팅
______6.4.1 자동화 방향
______6.4.2 이해 관계자의 참여
______6.4.3 동일한 솔루션
______6.4.4 보험 신청서 구조와 QC의 테스트 케이스 구조
______6.4.5 3개월 후 결정의 순간
______6.4.6 파일럿 프로젝트 후의 실제 프로젝트
______6.4.7 운영 환경으로의 실제 릴리즈에 사용된 첫 번째 자동화 테스트
______6.4.8 운영 환경에서의 전체 자동화 테스트
___6.5 정리

7장 종합 정부 시스템 테스트 자동화
___7.1 케이스 스터디의 배경
___7.2 자동화 요구사항
______ 7.3 자동화 테스트 솔루션 ATRT
______ 7.3.1 테스트 대상 시스템에 방해가 되면 안 된다
______7.3.2 운영체제에 독립적이어야 한다
______7.3.3 GUI에 독립적이어야 한다
______7.3.4 디스플레이 기반이거나 디스플레이 기반이 아닌 인터페이스를 모두 자동화 테스트해야 한다
_________7.3.4.1 이클립스
_________7.3.4.2 플러그인
______7.3.5 다중 컴퓨터 네트워크 환경을 처리할 수 있어야 한다
______7.3.6 비 개발자가 도구를 사용할 수 있어야 한다
______7.3.7 자동화된 요구사항 추적 매트릭스를 지원해야 한다
___7.4 자동화 테스트 솔루션 적용
___7.5 정리

8장 디바이스 시뮬레이션 프레임워크
___8.1 케이스 스터디의 배경
___8.2 디바이스 시뮬레이션 프레임워크 탄생
___8.3 DSF 생성
___8.4 자동화 목적
___8.5 케이스 스터디
______8.5.1 USB 펌웨어
______8.5.2 USB 저장소
______8.5.3 비디오 캡처
______8.5.4 DSF의 기타 적용 사례
___8.6 만능 해결책은 없다
___8.7 정리
___8.8 감사의 말

9장 ESA 프로젝트에서의 모델 기반 테스트 케이스 생성
___9.1 케이스 스터디의 배경
___9.2 모델 기반 테스트와 테스트 케이스 생성
______9.2.1 IDATG를 사용한 모델 기반 테스트
_________9.2.1.1 IDATG의 작업 흐름 모델
_________9.2.1.2 테스트 데이터 생성
_________9.2.1.3 테스트 케이스 생성
___9.3 애플리케이션: ESA의 MMUS 소개
______9.3.1 MMUS의 테스트 접근 방법
_________9.3.1.1 주요 전략
_________9.3.1.2 테스트 프레임워크
_________9.3.1.3 일반적인 테스트 시나리오
___9.4 경험과 배운 점
______9.4.1 장점
______9.4.2 모델 기반 테스트의 ROI
_________9.4.2.1 테스트 생성
_________9.4.2.2 테스트 자동화 프레임워크 준비
_________9.4.2.3 테스트 실행
_________9.4.2.4 테스트 유지보수
_________9.4.2.5 전체 소요시간
______9.4.3 문제점과 배운 점
___9.5 정리
______ 9.5.1 요약
______9.5.2 전망
_________9.5.2.1 무작위 테스트 생성
_________9.5.2.2 최근 소식
___9.6 참고문헌
___9.7 감사의 말

10장 10년간 계속되는 프로젝트
___10.1 케이스 스터디의 배경: 이전
___ 10.2 매달 자동으로 테스트되는 보험 견적 시스템
______10.2.1 배경: 영국 보험 산업
______10.2.2 참여하게 된 계기
______10.2.3 자동화 선택 이유
______10.2.4 테스트 전략
______10.2.5 테스트 자동화 툴 선택
______10.2.6 테스트 자동화 계획의 의사결정
_________10.2.6.1 테스터의 업무
_________10.2.6.2 자동화 기술자의 업무
______10.2.7 테스트 계획
______10.2.8 추가적으로 발생한 이슈
______10.2.9 한 가지 이야기: 테스터 대 자동화 기술자
______10.2.10 정리
______10.2.11 감사의 말
______ 10.3 현재 상황
___10.4 정리
______10.4.1 테스터와 자동화 기술자 분리
______ 10.4.2 관리자가 기대하는 것
______10.4.3 특정 툴과 벤더로부터 독립

11장 잿더미에서 날아오른 불사조
___11.1 케이스 스터디의 배경
______11.1.1 조직 구조
______11.1.2 비즈니스 도메인
___11.2 불사조의 탄생
___11.3 불사조의 죽음
___11.4 불사조의 부활
______11.4.1 자동화 프로젝트 다시 시작
______11.4.2 사용 편의성 향상
______11.4.3 자동화 업무 가시화 향상
______11.4.4 더 나은 테스트 방법 구현
______11.4.5 효과 계산: 투자 대비 수익
___11.5 불사조의 새로운 삶
______11.5.1 지식 공유
______11.5.2 자동화 프레임워크 테스트 실행 결과 추적
_________11.5.2.1 추적했던 것과 두 가지 주요 효과
_________11.5.2.2 회사 내 다른 파트로부터의 위협
______11.5.3 속도와 사용의 편이성을 고려한 설계
_________11.5.3.1 임의의 테스트를 선택해서 실행하는 능력
_________11.5.3.2 디버그 로그 옵션
_________11.5.3.3 사용자 친화 인터페이스
_________11.5.3.4 테스트 셋업의 자동화
_________11.5.3.5 리그레션 테스트
___11.6 정리

12장 관료의 수레바퀴 자동화
___12.1 케이스 스터디의 배경
______12.1.1 조직
______12.1.2 에이전시 테스트
___12.2 에이전시 자동화
______12.2.1 레코드 앤 플레이백 향상
______12.2.2 상태 점검과 스모커
______12.2.3 어려운 점과 배운 점
___12.3 2000년부터 2008년까지
______12.3.1 메인 프레임 툴의 효과
______12.3.2 웹 방식
______12.3.3 KASA
______12.3.4 어려운 점과 배운 점
______12.3.5 자동화 홍보
___12.4 행성 정렬
______12.4.1 게르손 리뷰
______12.4.2 독립 테스트 프로젝트
______12.4.3 핵심 리그레션 라이브러리 관리 방법론
______12.4.4 여정에서의 현재 위치
___12.5 테스트팀 역량 확대
______12.5.1 컨셉: 스크립트 개발과 비즈니스 지식 결합
______12.5.2 툴: KASA가 DExTA를 만났을 때
___12.6 향후 방향: 여정은 계속된다
______12.6.1 MBT 솔루션
______12.6.2 붙박이 자동화 엔지니어
______12.6.3 조직에서의 리그레션 테스트 접근 방법
______12.6.4 초기에 하는 자동화
___12.7 정리

13장 하드웨어 인터페이스를 사용한 신뢰성 테스팅의 자동화
___13.1 케이스 스터디의 배경
___13.2 즉각적인 조치의 필요성
___13.3 점증적 접근 방법으로 테스트 자동화 시작
___13.4 경영진의 선택
___13.5 테스트 프레임워크 추가 개발
______13.5.1 인크리먼트 2: 테스터용 언어 개발
______13.5.2 인크리먼트 3: 로그 파일 해석
___13.6 배포와 개선된 리포트
___13.7 정리

14장 안드로이드 애플리케이션의 모델 기반 GUI 테스팅
___14.1 케이스 스터디의 배경
______14.1.1 MBT
______14.1.2 경험: 안드로이드 애플리케이션에서 TEMA 사용
______14.1.3 앞으로 이야기할 것
___14.2 TEMA 툴세트에서 MBT
______14.2.1 도메인 한정 툴
______14.2.2 TEMA에서 역할
______14.2.3 TEMA 툴세트
______14.2.4 액션 머신과 정제 머신
______14.2.5 테스트 데이터 정의
______14.2.6 테스트 설정: 테스트 모델과 테스트 모드
______14.2.7 모델로부터 테스트 생성
______14.2.8 예제: SMS 메시지 전송
___14.3 애플리케이션 행위 모델링
______14.3.2 ATS4 앱모델을 사용한 모델링
___14.4 테스트 생성
______14.4.1 최적 경로 알고리즘의 기능과 선택
______14.4.2 최적 경로 알고리즘의 균형
___14.5 연결과 어댑테이션
______14.5.1 키워드를 실행하는 어댑터
______14.5.2 액션 키워드와 검증 키워드
______14.5.3 검증 구현의 어려운 점
______14.5.4 A-Tool 사용과 그에 따른 변경이 필요한 부분
______14.5.5 다른 문제점
___14.6 결과
___14.7 정리
___14.8 감사의 말
___ 14.9 참고 문헌

15장 SAP 비즈니스 프로세스의 테스트 자동화
___15.1 케이스 스터디의 배경
______ 15.1.1 소프트웨어 회사로서 SAP의 특별한 요구사항
_________15.1.1.1 숫자
_________15.1.1.2 소프트웨어 릴리즈와 테스트 스크립트 버전
_________15.1.1.3 기술
_________15.1.1.4 분산 개발
______15.1.2 SAP에서 테스트 자동화 툴
_________15.1.2.1 eCATT 소개
_________15.1.2.2 eCATT의 장점
_________15.1.2.3 eCATT의 한계
___15.2 표준과 성공 사례
______15.2.1 리그레션 테스트 프로세스
______15.2.2 명세서와 설계
______15.2.3 코딩 가이드라인
______15.2.4 코드 인스펙션
______15.2.5 재사용 가이드라인
______15.2.6 체크맨: eCATT의 정적 분석 툴
___15.3 eCATT 사용 예제
______15.3.1 의료 서비스 프로세스용 데이터 기반 자동화 프레임워크
_________15.3.1.1 APT 모델 정의
_________15.3.1.2 테스트 케이스 계산
_________15.3.1.3 eCATT 설계
_________15.3.1.4 결과와 전망
______15.3.2 은행 업무 시나리오의 테스트 자동화 프레임워크
_________15.3.2.1 프레임워크의 효과와 전망
___15.4 정리
___15.5 감사의 말

16장 SAP 구현의 테스트 자동화
___16.1 케이스 스터디의 배경
___16.2 프로젝트의 개요
___16.3 단계 1: 개념 증명
______16.3.1 프로젝트 범위 정의
______16.3.2 기대결과 설정
______16.3.3 테스트 케이스 스크립팅의 시작
___16.4 단계 2: 프로젝트 시작
______16.4.1 승인
______16.4.2 코드 컨벤션과 문서화
______16.4.3 구조화된 접근 방법
______16.4.4 데이터 주도 테스트 케이스
______16.3.5 다국어 지원
______16.4.6 보안 권한 테스팅
___16.5 정리

17장 잘못된 툴의 선택
___17.1 케이스 스터디의 배경
______17.1.1 제품
______17.1.2 개발 팀
______17.1.3 구글에서의 개발 개요
______17.1.4 릴리즈 주기의 개요
___17.2 기존 자동화
______17.2.1 수동 테스트와 더 많은 자동화의 필요성
___17.3 필요한 결정: 새로운 툴 선택 vs 유지보수 노력
______17.3.1 가진 것을 바꿔야만 했던 이유
______17.3.2 에그플랜트의 개요
___ 17.4 에그플랜트를 활용한 진행
______17.4.1 개발 경험
______17.4.2 툴 언어의 사용
______17.4.3 이미지 기반 비교의 문제점
______17.4.4 테스터가 테스트 유지보수를 해야 한다
______17.4.5 지속적인 통합을 사용한 코드 제출
______17.4.6 제출 대기열이 한 일
______17.4.7 에그플랜트 자동화 시도
______17.4.8 에그플랜트 사용 포기
___17.5 에그플랜트 이후의 툴
___17.6 정리
______17.6.1 툴로서의 에그플랜트
______17.6.2 일반적인 경우에서의 테스트 자동화
______17.6.3 현재의 자동화 관련 문제점

18장 마켓 플레이스 시스템의 테스트 자동화: 십 년간 세 개의 프레임워크
___18.1 케이스 스터디의 배경
___18.2 자동화 테스트 프레임워크
______18.2.1 프레임워크 A
______18.2.2 프레임워크 B
______18.2.3 프레임워크 C
___18.3 테스트의 역할
______18.3.1 테스트 엔지니어
______18.3.2 테스트 자동화 아키텍트
______18.3.3 일일 빌드 엔지니어
___18.4 추상화 계층
___18.5 설정
___18.6 비용과 ROI
___18.7 정리

19장 자동화는 리그레션 테스팅에만 국한되는 것이 아니다
___19.1 케이스 스터디의 배경
___19.2 작업 자동화의 두 가지 이야기
______19.2.1 실패한 자동화와 테스터가 좋아진 이유
_________19.2.1.1 두 개의 툴과 실패
_________19.2.1.2 50라인의 코드로 3시간에서 30분으로 단축
_________19.2.1.3 테스터가 좋아진 이유
______19.2.2 테스트 자동화가 아닌 테스트 관련 자동화
___19.3 수동 탐색 테스트를 지원하는 자동화
___19.4 테이터 인터렉션 자동화
___19.5 자동화와 모니터링
______19.5.1 너무 빨리 통과된 테스트
_________19.5.2 잘못된 게 없다면 테스트는 반드시 통과해야 했다
___19.6 간단한 툴 조합으로 실환경 부하 시뮬레이션
___19.7 정리
___19.8 참고문헌

20장 의료기기용 소프트웨어와 절실했던 소프트웨어 테스트 자동화
___20.1 케이스 스터디의 배경
______20.1.1 의료기기의 배경
______20.1.2 회사의 배경
______20.1.3 소프트웨어 테스트 자동화와 관련된 의료기기의 제약사항과 세부사항
______ 20.1.4 몇 가지 프로젝트와 시나리오
___20.2 각 프로젝트에 대한 여러 가지 접근 방법의 비교
______20.2.1 테스트 목적 정의: 핵심 기능에 집중
______20.2.1.1 의료기기 대상 테스트 범위에 적합한 일반적인 사례
_________20.2.1.2 대단한 기대
______20.2.2 테스트 흐름
_________20.2.2.1 자동화 시기: 벌레는 일찍 일어난 새가 잡을 수도 있지만, 치즈는 두 번째 쥐가 얻는다
_________20.2.2.2 자동화 초기: 자동화 대상과 비대상 기준
_________20.2.2.3 실제 적용
___20.3 HAMLET 프로젝트
___20.4 PHOENIX 프로젝트
______20.4.1 툴
______20.4.2 유지보수와 마이그레이션 이슈
_________20.4.2.1 유지보수의 한계점
_________20.4.2.2 제한된 자동화 테스트 유지보수 진행 방법
_________20.4.2.3 기법
___20.5 DOITYOURSELF 프로젝트
______20.5.1 툴
______20.5.2 유지보수와 툴 검증 이슈
______20.5.3 기법
______20.5.4 예상하지 못한 문제와 해결책
___20.6 MINIWEB 프로젝트
______20.6.1 툴
______20.6.2 유지보수
______20.6.3 기법
______20.6.4 예상하지 못한 문제와 해결책
___20.7 테스트 실행
___20.8 결과 보고
___20.9 정리
______20.9.1 프로젝트 회고
______20.9.2 다르게 할 수 있는 부분
______20.9.3 향후 계획

21장 수동 테스팅 지원을 통한 은밀한 자동화
___21.1 케이스 스터디의 배경
___21.2 기술적 해결책
______21.2.1 커맨드 기반 테스팅
______21.2.2 ISS 테스트 스테이션
_________21.2.2.1 ITS 클라이언트
_________21.2.2.2 ITS 엔진
___21.3 ISS 테스트 스테이션을 활용한 테스트 자동화 구현
______21.3.1 자동화 프로세스
_________21.3.1.1 전제 조건
_________21.3.1.2 테스트 스위트 준비
_________21.3.1.3 테스트 실행
___21.4 테스트 자동화 구현
______21.4.1 기존 절차
______21.4.2 취약점
___21.5 수동 테스트 지원
______21.5.1 구현된 기능
______21.5.2 현재 프레임워크에 구현되지 않은 기능
___21.6 새로운 수동 테스트 프로세스
______21.6.1 프레임워크로 마이그레이션
______21.6.2 프레임워크를 활용한 수동 테스트
_________21.6.2.1 테스트 케이스 개발과 유지보수
_________21.6.2.2 테스트 실행
_________21.6.2.3 결함 추적
_________21.6.2.4 통계
______21.6.3 수동 테스트의 자동화
_________21.6.3.1 개발
___21.7 정리
______21.7.1 시작 단계
______21.7.2 2010년의 상황
______21.7.3 다음 단계
___21.8 참고문헌

22장 이식성 테스팅의 가치를 더해주는 테스트 자동화
___22.1 케이스 스터디의 배경
___22.2 이식성 테스트
___22.3 해결책으로서 양쪽 진영의 결합
______22.3.1 LA-PORTA
______22.3.2 가상화 제품
______22.3.3 VixCOM
______22.3.4 테스트 자동화 툴
______22.3.5 파일 구조
___22.4 정리
___22.5 감사의 말

23장 보험 회사에서의 자동화 테스트
___23.1 케이스 스터디의 배경
___23.2 애플리케이션
___23.3 목표
___23.4 작업
______23.4.1 1 단계
______23.4.2 2 단계
______23.4.3 3 단계
______23.4.4 4 단계
___23.5 교훈
______23.5.1 화면 해상도
______23.5.2 더 적은 것이 때로는 더 많은 것이다
___23.6 정리
______23.6.1 가장 큰 성공
______23.6.2 흥분하지 마라

24장 테스트 멍키 대모험
___24.1 케이스 스터디의 배경
___24.2 자동 리그레션 테스팅의 한계
______24.2.1 자동화 리그레션 테스트는 정적이다
______24.2.2 자동화 리그레션 테스트는 단순하다
______24.2.3 자동 테스트의 재초기화
______24.2.4 애플리케이션과 동기화
______24.2.5 변경에 취약하다
___24.3 테스트 멍키
______24.3.1. 특징
______24.3.2 기본 기능
___24.4 테스트 멍키 구현
___24.5 테스트 멍키의 사용
______24.5.1 지표
___24.6 장점과 단점
___24.7 정리
___24.8 참고문헌

25장 NATS에서의 복합 시스템 테스트 자동화
___25.1 케이스 스터디의 배경
______25.1.1 복합 시스템 운영 상황
______25.1.2 테스트 자동화 초기 목표와 제약 사항
___25.2 테스트 실행 툴 통합
___25.3 툴을 위한 파일럿 프로젝트
___25.4 인서비스 모델
___25.5 구현
___25.6 일반적인 스크립트 템플릿
___25.7 배운 점
______25.7.1 일반적인 교훈
______25.7.2 기술적인 교훈
___25.8 정리

26장 자동차 전자 기기 테스팅 자동화
___26.1 케이스 스터디의 배경
___26.2 자동화 프로젝트의 목적
___26.3 자동화 프로젝트의 약력
______26.3.1 첫 번째 툴
______26.3.2 첫 번째 툴의 제약 사항과 차세대 툴의 개발
___26.4 자동화 프로젝트의 결과
___26.5 정리

27장 BHAG, 변경과 테스트의 변신
___27.1 케이스 스터디의 배경
___27.2 설득
______27.2.1 임원진
______27.2.2 개발자의 ‘왜’
______27.2.3 QA 팀에 권한 부여
_________27.2.3.1 BHAG
_________27.2.3.2 역할의 재정비
_________27.2.3.3 테스트 자동화 리더십 팀
_________27.2.3.4 거듭되는 개선
___27.3 자동화 프레임워크 구축 이야기
______27.3.1 테스트 포인트 생성
______27.3.2 시작
______27.3.3 컨설턴트
______27.3.4 프레임워크의 재구축
___27.4 자동화 프레임워크의 설명
______27.4.1 프레임워크의 모듈
______27.4.2 모듈의 고려 사항
_________27.4.2.1 모듈 규칙
_________27.4.2.2 새로운 모듈
_________27.4.2.3 모듈의 이슈
______27.4.3 스크립트 실행
______27.4.4 실패 캡처 방법
___27.5 테스트 환경
______27.5.1 다중 LAN
______27.5.2 가상 머신
___27.6 지표
______27.6.1 자동화 효과
_________27.6.1.1 프로젝트 이전의 상황
_________27.6.1.2 프로젝트 이후의 상황
_________27.6.1.3 일일 리그레션 테스트 실행
______27.6.2 고객이 발견한 결함의 효과
___27.7 정리
______27.7.1 배운 점
______27.7.2 계속되는 도전
_________27.7.2.1 모바일 장비
_________27.7.2.2 자동화 대 수동 테스트
______27.7.3 다음 계획

28장 탐색적 테스트 자동화: 시대를 앞서간 자동화의 예
___28.1 케이스 스터디의 배경
___28.2 트러블 매니저
___28.3 트러블 매니저 트랜잭션 테스트
______28.3.1 모든 필수 필드 값이 존재할 때 CreateTicket 트랜잭션 성공 테스트
______28.3.2 빠진 필수 필드 값이 있을 때 CreateTicket 트랜잭션 실패 테스트
___28.4 테스트 케이스를 프로그램으로 생성
___28.5 자동화 테스트를 고민하는 새로운 방식
___28.6 트러블 매니저 워크플로 테스트
___28.7 실행에 옮긴 테스트 생성
___28.8 마지막 단계
___28.9 출시 후
___28.10 정리
___ 28.11 감사의 말

29장 테스트 자동화의 일화
___ 29.1 쌀 세 톨
______29.1.1 테스트웨어의 리뷰
______29.1.2 누락된 유지보수
______29.1.3 대단히 성공적인 POC
___29.2 이해가 깊어져야 한다
___29.3 자동화 테스트 첫 날
______29.3.1 초기 투자
______29.3.2 자동화할 부분
______29.3.3 자동화 테스트 첫 날
_________29.3.3.1 비즈니스 레벨 키워드
______29.3.4 문제와 해결책
______ 29.3.5 자동화 방식 첫 번째 날의 결과
___29.4 자동화를 시작하기 위한 시도
___29.5 경영진과의 투쟁
______29.5.1 무조건 자동화하자는 관리자
______29.5.2 테스터는 프로그래머가 아니라는 관리자
______29.5.3 버그를 자동화하라는 관리자
______29.5.4 잘못된 방법으로 고객을 감동시키라는 관리자
___29.6 탐색적 테스트 자동화: 데이터베이스 레코드 잠김
______29.6.1 케이스 스터디
___29.7 임베디드 하드웨어와 소프트웨어 컴퓨터 환경의 테스트 자동화에서 얻은 교훈
______29.7.1 VV&T 프로세스와 툴
______29.7.2 교훈
______29.7.3 결과 요약
___29.8 전염되는 시계
______29.8.1 기존의 시계
______29.8.2 유용성 향상
______29.8.3 부득이한 추진
______ 29.8.4 배운 점
___ 29.9 자동화 시스템의 유연성
___29.10 너무 많은 툴과 부서간 지원 부족
______29.10.1 프로젝트 1: DSTL을 이용한 시뮬레이션
______29.10.2 프로젝트 2: TestComplete를 사용한 GUI 테스트
______29.10.3 프로젝트 3: Rational Robot
______29.10.4 프로젝트 4: 최후의 파이썬 프로젝트와 QTP용 POC
______29.10.5 프로젝트 5: QTP2
______29.10.6 이야기의 끝
___29.11 놀라운 결말로 끝난 성공
______29.11.1 선택한 툴
______29.11.2 툴 인프라스트럭처와 흥미로운 이슈
______29.11.3 시작
______29.11.4 예상하지 못한 일의 발생
___29.12 협력이 자원의 제약을 극복할 수 있다
___ 29.13 대규모 성공을 위한 자동화 프로세스
______29.13.1 시작점
______29.13.2 궁극적인 성공의 열쇠: 자동화 프로세스
______29.13.3 배운 점
______29.13.4 투자수익률
___ 29.14 테스트 자동화는 항상 보이는 것이 전부는 아니다.
______29.14.1 예외 처리만 한다고 좋은 테스트가 되지는 않는다
______29.14.2 때론 실패한 테스트가 믿을 만한 테스트다
______29.14.3 때론 마이크로 자동화가 잭팟을 터뜨린다

부록: 툴
찾아보기

출판사 서평

★ 이 책에서 다루는 내용 ★

■ 애자일 개발에서 테스트 자동화
■ 경영진의 지원이 성공적인 자동화를 이끌거나 무너뜨릴 수 있는 이유
■ 테스트웨어 아키텍처와 추상화 레벨 선택의 중요성
■ 자동화 효과 및 투자 대비 수익(ROI) 계산 방법
■ 기술, 계획, 범위, 기대 결과를 포함하는 관리 관점의 이슈들
■ 모델 기반 테스팅(MBT) 자동화, 멍키 테스팅 자동화, 탐색적 테스트 자동화
■ 엔터프라이즈 급 자동화에서 표준, 커뮤니케이션, 문서, 유연성의 중요함
■ 지원 활동의 자동화
■ 자동화해야 할 테스트와 하... 더보기

북로그 리뷰 (0) 쓰러가기

도서 구매 후 리뷰를 작성하시면 통합포인트를 드립니다.
결제 90일 이내 작성 시 300원 / 발송 후 5일 이내 작성시 400원 / 이 상품의 첫 리뷰 작성 시 500원
(포인트는 작성 후 다음 날 적립되며, 도서 발송 전 작성 시에는 발송 후 익일에 적립됩니다.
외서/eBook/음반/DVD/GIFT 및 잡지 상품 제외)
안내
  • 해당도서의 리뷰가 없습니다.

Klover 평점/리뷰 (0)

교환/반품/품절안내

※ 상품 설명에 반품/교환 관련한 안내가 있는 경우 그 내용을 우선으로 합니다. (업체 사정에 따라 달라질 수 있습니다.)

교환/반품/품절안내
반품/교환방법 마이룸 > 주문관리 > 주문/배송내역 > 주문조회 > 반품/교환신청 ,
[1:1상담>반품/교환/환불] 또는 고객센터 (1544-1900)

※ 오픈마켓, 해외배송주문, 기프트 주문시 [1:1상담>반품/교환/환불]
    또는 고객센터 (1544-1900)
반품/교환가능 기간 변심반품의 경우 수령 후 7일 이내,
상품의 결함 및 계약내용과 다를 경우 문제점 발견 후 30일 이내
반품/교환비용 변심 혹은 구매착오로 인한 반품/교환은 반송료 고객 부담
반품/교환 불가 사유
  • 소비자의 책임 있는 사유로 상품 등이 손실 또는 훼손된 경우
    (단지 확인을 위한 포장 훼손은 제외)
  • 소비자의 사용, 포장 개봉에 의해 상품 등의 가치가 현저히 감소한 경우
    예) 화장품, 식품, 가전제품(악세서리 포함) 등
  • 복제가 가능한 상품 등의 포장을 훼손한 경우
    예) 음반/DVD/비디오, 소프트웨어, 만화책, 잡지, 영상 화보집
  • 소비자의 요청에 따라 개별적으로 주문 제작되는 상품의 경우 ((1)해외주문도서)
  • 디지털 컨텐츠인 eBook, 오디오북 등을 1회 이상 다운로드를 받았을 경우
  • 시간의 경과에 의해 재판매가 곤란한 정도로 가치가 현저히 감소한 경우
  • 전자상거래 등에서의 소비자보호에 관한 법률이 정하는 소비자 청약철회 제한 내용에
    해당되는 경우
(1) 해외주문도서 : 이용자의 요청에 의한 개인주문상품으로 단순변심 및 착오로 인한 취소/교환/반품 시 ‘해외주문 반품/취소 수수료’ 고객 부담 (해외주문 반품/취소 수수료 : ①양서-판매정가의 12%, ②일서-판매정가의 7%를 적용)
상품 품절 공급사(출판사) 재고 사정에 의해 품절/지연될 수 있으며, 품절 시 관련 사항에 대해서는
이메일과 문자로 안내드리겠습니다.
소비자 피해보상
환불지연에 따른 배상
  • 상품의 불량에 의한 교환, A/S, 환불, 품질보증 및 피해보상 등에 관한 사항은
    소비자분쟁해결 기준 (공정거래위원회 고시)에 준하여 처리됨
  • 대금 환불 및 환불지연에 따른 배상금 지급 조건, 절차 등은 전자상거래 등에서의
    소비자 보호에 관한 법률에 따라 처리함

이 책의 원서번역서

안내

이 분야의 베스트

더보기+

이 분야의 신간

  • 세스 스티븐스 다비도위츠
    16,200원
  • 김계철
    23,000원
  • 조현영
    28,800원
  • 김민준
    32,400원
  • 손민규
    22,500원
더보기+

바로가기

  • 우측 확장형 배너 2
  • 우측 확장형 배너 2

최근 본 상품