웹 기반 소프트웨어 테스트

1. 웹 기반 소프트웨어 테스트

2. 웹 기반 프로그램의 테스트 • 개인용 PC와 인터넷 사용의 급증 • 전자 상거래의 발달 • 웹과 비즈니스의 연관성 • 사용자의 입장에서 웹 테스트가 필요하다. • 안전성과 편리성 제공

3. 웹 어플리케이션 테스트 분류(1/2) • 기능 테스트(functionality testing) • 명세서에 명시된 동작에 맞게 동작 하는가를 테스트 • 링크, 폼, 쿠키, 웹 인덱싱, 데이터베이스, 자바 애플릿, 액티브 X 등에 대한 테스팅 • 성능 테스트(performance testing) • 요구되는 성능에 대해 시스템의 감내 능력을 테스트 • 로드 테스트와 스트레스 테스트가 성능 테스트의 범주에 속한다 • 많은 사용자의 동시 접속, 많은 양의 데이터 유입, 실행 시간, 반응 시간, 커넥션 속도, 다운 시간 • 사용성 테스트(usability testing) • 다른 대부분의 산업에서는 규격이나 가이드 라인의 형태로 존재한다 • 웹 어플리케이션의 사용성은 사용자의 숙련도에 많은 영향을 받기 때문에 편리성 보증이 어렵다. • 웹 사이트에 기입 해야 할 사항 중 사용자가 필수 항목을 기입하지 않았다면, 에러 메시지를 출력

4. 웹 어플리케이션 테스트 분류(2/2) • 적합성 테스트 (Compatibility testing) • 서로 다른 구성이나 배열, 예를 들어 클라이언트와 서버 (또는 외부 DB)에 대한 서로의 적합성을 테스트 • 완벽한 제어가 어렵고 또한 모든 가능한 조합을 테스트한다는 것은 불가능하기 때문에 테스트가 난해해진다. • 웹 페이지가 버전이 다른 브라우저나 운영체제에서 올바르게 동작하는가를 체크하는 것 등 • 보안 테스트 (security testing) • 정보 접근 규제, 사용자 신원에 대한 인증 등의 총괄적인 보안을 통해 사용자의 신원 정보가 안전하게 전송 • SSL, logfile, firewall, login에 대한 테스트

5. 네비게이션 테스트 • 네비게이션 • 사용자가 얼마나 쉽고 빠르게 원하는 정보를 찾아 낼 수 있는가를 고려한 웹 페이지의 구성 • 네비게이션 테스트의 중요성 • 사이트의 성공과 실패의 중요한 열쇠- 사용자를 오래 머물 수 있게 • 기능과 성능에 대한 문제점도 발견

6. 네비게이션 테스트 • 네비게이션의 종류 • 링크와 URL • 내부 링크 • 같은 웹 사이트의 웹 페이지의 링크 • 외부 링크 • 다른 웹 사이트의 웹 페이지를 참조하는 링크 • 앵커 • 방문자가 페이지 안의 특정한 위치로 바로 이동할 수 있게 해주는 것

7. 네비게이션 테스트 • 깨진 링크를 방지하기 위한 지침

8. 네비게이션 테스트 • 네비게이션의 종류 • 간접 링크 • 링크가 존재하지 않는 페이지 대신 나타내는 페이지 • 간접링크의 종류 • 공손한 표현 • 요청한 웹 페이지가 존재 하지 않을 때 검색 엔진을 연결하여 페이지를 검색 • 요청 페이지는 존재하지 않지만 같은 웹 사이트 안에서 근접한 것을 검색해서 제공 • 단점 • 꾸준한 관리가 필요하며, 기대 하지 못한 이벤트에 대해서 제어하기 어렵다

9. 네비게이션 테스트 • 네비게이션의 종류 • 북마크 • 웹을 사용해서 특정 웹 페이지로 쉽게 찾아갈 수 있도록 페이지에 해당되는 링크를 목록 형태로 저장해 둔 것 • 해당 페이지의 주소를 입력하지 않고도 그 사이트로 빠르게 이동하기 위해 • 북마크 테스트를 위한 체크 리스트

10. 네비게이션 테스트 • 네비게이션의 종류 • 프레임과 프레임 셋 • 프레임 • 하나의 화면에 여러 개의 문서가 나타날 때 각 문서가 나타나는 영역 • 프레임 셋 • 한 페이지에 한 개 이상의 프레임이 존재하는 것 • 로딩에 따르는 대역폭을 줄인다 • 사용자 인터페이스에 유연성을 제공하지만 잠재적인 사용성 문제점 • 프레임의 사용은 방문객에게 그들이 가진 행동이나 기술적 습관을 바꿀 것을 요구

11. 네비게이션 테스트 • 프레임 테스트를 위한 체크 리스트

12. 네비게이션 테스트 • 사이트 재구성 • 사이트 확장으로 인해 무질서가 증가하고 웹 페이지에 대한 네비게이션이 힘든 경우 실행 • 무질서의 정도에 대한 평가 방법 • 사용자에게 특정 정보를 찾게 함 • 도구를 이용 • Watchfire사의 Linkbot: 웹 페이지가 얼마나 깊게 연결되어 있는지를 테스트 • 네비게이션의 효율성 • 사용자가 최소한의 페이지를 이동해서 원하는 곳에 도착 하는가 • 효율성의 평가는 비슷한 컨텐츠의 다른 웹 사이트와 비교해 같은 일을 수행하기 위해서 얼마나 적은 페이지를 거치는 가로 파악

13. 네비게이션 테스트 • 사이트 재구성 • 효율성 평가 B-Trade B&D

14. 사용자 구동 홈페이지 자동 가격 조회 심볼 탐색 쇼핑카트 디스플레이 가격 디스플레이 심볼 선택 네비게이션 테스트 • 네비게이션 문서화 • 모든 카테고리에 대한 테스트와 네비게이션 테스트가 용이하도록 문서화 • 사이트 네비게이션 다이어그램 • 사이트 코딩 전후 모두 사용 가능 • 웹 사이트 네비게이션의 요구를 파악하기 용이 • 시나리오를 작성해서 사용자가 목적한 일을 마치기 위해 무엇이 필요한지 알 수 있다 • 접근하기 쉽지 않은 페이지, 방문객이 없을 페이지,긴 경로, 전체적인 네비게이션이 불편하고 서투르게 작성 된 것 을 찾아냄 • 보통 다이어그램은 20개의 페이지를 넘지 않아야 한다

15. 네비게이션 테스트 • 네비게이션 문서화 • 사이트 네비게이션 매트릭스 • 계층적이지 않은 웹 사이트에서는 네비게이션 다이어그램 보다 효율적 • 체크 표시: 시작(from)의 페이지 리스트를 따라서 도착(to)에 이르는 접근 가능한 페이지를 의미 • 100개를 넘지 않는 페이지에 적합

16. 사용성, 접근성 테스트 • 사용성(usability)테스트 • 잠재적인 웹 사이트의 사용자가 적당한 노력과 시간 안에 그들이 원하는 것을 찾을 수 있는 가를 측정하는 것 • 처음 또는 자주 사용하지 않는 사용자가 얼마나 쉽게 웹사이트 사용법을 습득하는가 • 몇 번의 시도를 통해서 방문자가 웹사이트의 특정 페이지를 찾는데 얼마나 시간이 걸리는지를 측정 • 접근성(accessibility) 테스트 • 얼마나 쉽게 웹 사이트의 본문 내용을 읽고 이해할 수 있는가를 측정 • 개인의 능력 또는 클라이언트 컴퓨터의 하드웨어나 소프트웨어 구성(configuration)을 말한다 • 문맹이나 좋지 않은 시력으로 접근성이 떨어지는 사람들을 위해서는 문자를 소리로 바꿔주는 장치들이 요구

17. 사용성, 접근성 테스트 • 좋은 사용성, 접근성을 위해 • 기업이나 기관들은 사용자들의 방식을 이해하여야 한다 • 기업들은 자신들이 원하는 방식으로 사용자들을 몰아가지 말아야 한다 • in-house의 end-user와는 달리 인터넷 사용자들은 자유롭게 다른 웹 사이트를 선택 • 예: 개발자는 1280 *1024해상도의 20인치 모니터를 사용하며 사용자는 17인치 1024*768 해상도 모니터를 사용 • 사용자는 전체 화면을 보기 위해 스크롤 바를 이용해 위아래, 좌우로 이동 • 사용성과 접근성 테스트의 필요성 • 판매 감소로 인한 손실 vs. 사용성, 접근성에 대한 문제 해결 비용 • 판매 감소 손실 > 사용성, 접근성 해결 비용 • 사용자들이 그들이 원하는 것을 제대로 찾지 못하면, 기업은 약 50%의 잠재적 판매 손실

18. 웹 사용성 테스트 • 웹 사용성 테스트 • 시스템 테스트(또는 사이트 수준 테스트)와 단위 테스트(또는 페이지 수준 테스트)의 두 가지 종류 • 시스템 테스트 • 정보구조, 네비게이션, 페이지 템플릿, 사이트 레이아웃, 일관된 그래픽, 링크방법, 검색가능성 등을 테스트 • 단위 테스트 • 개별 웹 페이지에서 발생할 수 있는 특별한 이슈나 문제와 관련 • 언제 사용자가 링크, 그래픽, 아이콘, 폼, 에러 메시지에 대해서 개발자가 의도한 것과 다르게 이해하는가 • 사용성 테스트는 개인적인 문제이기 때문에 객관적인 테스트가 중요

19. 웹 사용성 테스트 • 다섯 가지 테스트 단계로 구성 • 단계 1: 목표를 정의한다 • 사용성 테스트를 통해서 무엇을 확인하고자 하는지를 결정 • 과제 완수를 위해서 얼마나 오랜 시간이 걸리는가 혹은 사용자가 얼마나 어려움을 겪는가에 대한 측정이 가장 효율적 • 단계 2: 테스트를 설정한다 • 사용성 테스트는 웹사이트의 사용성에 대한 정도를 객관적으로 측정 • 높은 비율로 잘못 선택되는 링크에 대해서도 관심을 가져야 한다 • 테스트 형식 • 실험(controlled laboratory), 현장 조사(field observation), 관찰 그룹(focus group), 설문(questionnaires), 의견조사(survey) 등 • 현장 조사는 테스트 전문가가 참여자들이 집이나 작업 환경에서 웹 사이트를 사용하는 것을 모니터링

20. 웹 사용성 테스트 • 단계 3: 참가자를 선택한다. • 동료들을 참가자로 테스트 • 조직의 풍토에 익숙하다면 정확한 테스트 결과를 반영할 수 없다 • 참가자를 테스트 하는 것이 아니란 것을 명심해야 한다 • 사용성 테스트의 목적은 디자인 실패 지점이나 사용자들을 실패로 이르게 하는 요소를 찾아내는 것 • 단계 4: 테스트를 수행한다 • 단계 2에서 선택한 사용성 테스트의 형식이 어떻게 테스트를 수행하는지를 결정한다 • 통제된 환경 하에서 관리 • 단계 5: 리포팅 • 결과는 참가자들의 개인적 편견이나 믿을 수 없는 기억에 의해 변형되지 않은 정확한 결과여야 한다 • 테스트 결과가 웹 사이트 변동에 대하여 어느 정도 품질 보증할 수 있다면 책임자 또는 부서에 넘겨진다

21. 사용성, 접근성 테스트 • 가독성(readability) • 사용자가 문자나 그림을 리뷰하고 이해하고 의미를 조합할 수 있는 능력 • 읽기 쉬움(legibility)이라는 특성과 함께 효과적이고 효율적인 커뮤니케이션을 위해서 중요한 요소 • 글자, 글자 크기, 글자 스타일, 색 조화, 배경 질감, 글자 간격과 같은 모든 것들이 웹 페이지 가독성과 연관이 있다 • 비례 간격 글자는 고정 간격 글자보다 읽기 쉽다

22. 사용성, 접근성 테스트 • 가독성 측정 방법 (1) Gunning FOG 가독성 인덱스 (2) The Fry Graph 1. 웹 사이트에서 무작위로 100 단어 구절을 선택한다. 2. 문장 마다 평균 단어 숫자를 확인한다. 3. 어려운 단어(셋 이상의 음절 단어) 퍼센트를 확인한다. 4. 두 개의 결과를 더해서 0.4를 곱한다. 5. 계산된 결과는 문장을 쉽게 읽고 이해 할 수 있는 미국 학년의 최소레벨을 나타낸다. 참고> 미국의 학년은 6세는 1학년, 16세는 11학년이다 • 웹 사이트에서 무작위로 100 단어 구절을 선택한다. • 100단어의 평균 문장 수에 대비되는 음절 수의 평균을 그림에서 찾아 할당 • Fry Graph를 사용해서 나이를 짐작한다. • 결과의 정확도를 높일 수 있는 구절을 좀 더 웹 사이트로부터 선택한다.

23. 사용성, 접근성 테스트 커브의 아래 포인트는 평균보다 긴 문장 길이를 의미하며 커브 위의 포인트는 과학 교재 같은 어려운 단어를 포함하는 텍스트를 나타낸다

24. 사용성, 접근성 테스트 • 다중 언어 • 세계 시장에서 경쟁하기 위해서는 웹 사이트를 전세계의 사용자들이 사용할 수 있도록 구성하여야 한다 • 영문사이트는 전세계의 적은 퍼센트의 사람들에게만 수용가능 • 전세계적인 사용자를 위해서는 • 여러 개의 지역적인 웹 사이트 구축 • 한 개의 사이트에서 여러 언어를 지원 • 제2 외국어가 더해지면, 외국어 문서에 대한 충분한 증명을 할 수 있는 사람이나 서비스가 필요하다 • 번역한 웹 사이트를 역으로 영어로 번역 했을 때 영문과 근접 하다면 어느 정도 안전하다고 여긴다

25. 사용성, 접근성 테스트 • 다중 언어 • 언어 통역(해석) • 공격적인 terminology에 대한 고려 • 단어 또는 구문들이 특정 지역에 사는 사람에게는 일반적으로 받아 들여지지만 다른 지역 사람에게는 무례하고 무지하게 여겨질 수 있다 • 아랍권의 웹에는 여성에 대한 사진이나 그림은 올리지 않는다 • 클라이언트측 언어 속성 • 방문자들은 브라우저의 언어 옵션을 사용해서 선호언어 선택 • 서버측의 언어 속성 • 다중 언어 개발과 테스트할 때 기준으로 어떤 HTML기준을 선택할지 신경 써야 한다 • 유니 코드는 65000 glyph를 지원하며 세계 여러 나라의 다양한 문자를 포함할 만큼의 충분한 문자의 수를 지원한다 • Cyberbit는 유니코드 문자 집합을 포함하고 있으며 세계 주요언어의 문자를 모두 포함하고 있다

26. 사용성, 접근성 테스트 • 색상 조합 • 클라이언트 모니터의 기능을 뛰어 넘는 웹 페이지 색상의 사용으로 서로 다른 두 가지 색상이 같은 색상으로 디스플레이 될 수도 있다 • 그래픽에 많은 수의 색상이 사용될 수록 다운로드에 시간은 길어짐 • 클라이언트 환경에 웹 페이지를 맞춘다. • 색상 테스트 리스트

27. 사용성, 접근성 테스트 • 화면 크기와 해상도 • 개발자가 고해상도 모니터를 사용하면 낮은 해상도의 화면에서는 웹 페이지가 크게 나타날 확률이 높다. • 불필요하게 수평 수직 스크롤 바를 움직여야 한다 • 서로 다른 브라우저나 버전일 때도 정확하게 화면이 표시되는지 테스트해야 한다 • 브라우저가 다르거나 버전이 달라도 여백의 공간이 다르다 • 사용자가 어떤 장치를 통해서 웹 사이트에 접속하고자 하는지 파악 • PDA 의 Palm은 일반적으로 160 *160 해상도, Windows CE는 240 * 320, 모바일 전화는 96 *65정도의 해상도

28. 사용성, 접근성 테스트 • 접근성 • 장애가 있는 사람도 쉽게 웹 사이트를 접근할 수 있어야 한다. • 시각 장애 • 문자를 음성으로 바꾸어 주는 Home Reader(IBM)나 JAWS(Henter-Joyce)같은 도구 • 대표적인 접근성 테스트 도구 – bobby • W3C 가이드 라인을 준수하는지를 체크 • HTML 2.0, 3.0, 3.2, 4.0와 MS IE2.0 ~5.0, Netscape 1.1 ~ 4.5, 리눅스 2.5 ~ 2.7 등의 브라우저 사용이 가능한지 알 수 있다. • Bobby의 승인을 받은 웹 페이지는 ‘Bobby approved’표시 • Web Accessibility Initiative(WAI) • 접근가능을 정할 수 있는 가이드 라인과 체크 리스트를 제공 • W3C.org

29. 사용성, 접근성 테스트 • 접근성 • 접근성 테스트 체크 리스트

30. 사용성, 접근성 테스트 • 정보유출과 외부 감사 • 기관에서 사용하는 프로세서는 웹 사이트의 개인보호 정책과 충돌해서는 안 된다 • Public accounting profession은 WebTrustTM을 통해서 B2C 전자 상거래의 원칙과 정책을 개발 • WebTrust의 세가지 원칙 • Business practices disclosure • 트랜잭션 무결성 • 정보 보호 • 인증은 사용자가 웹 사이트를 사용할 때 안심할 수 있다. • 588 개 기업이 TRUSTe 인증마크를 받았고 47개의 기업들이 BBB(Better Business Bureau) 인증마크를 받았다. • 20개의 기업들이 WebTrust 마크를 받았다 (1999년 기준)

31. 사용성, 접근성 테스트 • 정보유출과 외부 감사 • 프라이버시 체크 리스트

32. 성능 테스트 • 성능 테스트의 필요성 • 시스템은 비즈니스가 요구하는 로드를 견뎌 낼만한 능력을 가져야 한다. • 오랜 시간 기다리게 된다면 사용자는 불편을 느낄 것 이다 • 로드 테스트 • 이미 정해진 로드 레벨을 견뎌내는가를 테스트 • 성능테스트 • 다양한 로드 레벨에서 성능의 변화를 체크하는 것 • 스트레스 테스트 • 시스템이 견딜만한 브레이킹 포인트까지 스트레스를 준다 • 성능 평가의 주요한 세 가지 요소 • 시스템 환경과 사용가능 한 자원 • 부하(workload) • 응답시간 (response time)

33. 성능 테스트 • 성능 테스트 • 특정 웹 사이트가 제공하는 서비스 레벨에 대한 측정을 시도 • 하드웨어 용량(capacity) 계획과 확장 계획에(scalability) 도움 • 사전 준비 • 테스트 담당 • 테스트 엔지니어, 시스템 관리자, 네트워크 관리자, 사용자 등 • 측정을 위한 요구 • 안정적인 시스템 • 생산 환경, 도구, 프로세스 등 • 성능 테스트 절차 • 명세: 무엇을 어떻게 테스트 할지 테스트의 요구사항을 확인 • 준비: 디자인, 개발 스크립트, 데이터 준비, 환경 설정 • 실행: 테스트를 실행 • 분석: 시스템 자원, 툴, 테스트로부터 얻은 자료를 분석하여 제출

34. 성능 테스트 (명세) • 성능 테스트의 종류 • 스모크/초벌 테스트 • 부하와 확장 계획 테스트 • 스트레스와 핫 스팟 (Hot Spot) 테스트 • 스파이크 테스트 • 무결성(Integrity) 테스트

35. 성능 테스트 (명세) • 스모크 및 초벌 테스트 • 테스팅을 위해 소프트웨어 릴리즈가 준비 되었는지를 테스트 하는 것 • 간단한 매뉴얼 테스트 • 실행 전에 테스트의 범위를 확실히 하고, 환경의 공유된 자원을 확인 • 네트워크 대역폭 • ‘Sanity test’ , ‘Skim test’, ‘Crash test’, ‘Wash-down test’, ‘Drive by test’라고도 불린다 • 사례 • 성능 테스트의 모든 트랜잭션을 확인한다. 하한 값, 상한 값, 중간 값을 사용한 세 개의 스크립트를 작성 • 한 사람의 사용자의 모든 트랜잭션을 테스트 한다. • 두 명의 사용자의 모든 트랜잭션을 테스트 한다. 이것은 시스템의 안정성을 입증할 뿐 아니라 트랜잭션 준비 정도를 알 수 있다

36. 성능 테스트 (명세) • 부하 테스트와 확장계획 테스트 • 부하테스트 • 짧은 시간 동안 실제 세계에서 예상되는 모델을 시도해 본다 • 주어진 시간 동안 사용자의 행동을 정확하게 나타내는지를 평가한다 • 테스트의 결과는 특정 하드웨어와 소프트웨어(웹 서버, 어플리케이션 서버, DB, 대역폭)의 조합이 성능요구에 적합한지를 확인하는데 도움이 된다

37. 성능 테스트 (명세) • 부하 테스트와 확장계획 테스트 • 부하 테스트 체크 리스트 • 확장계획(scalability) 테스트 • 초기 로드는 계획의 점진적인 성장과 다른 요소들을 기초로 정의 • 시스템의 흡입력을 평가 할 수 있다 • 성능의 요구레벨에서의 시스템의 유지 시간을 대략적으로 알 수 있다

38. 성능 테스트 (명세) • 스트레스와 핫 스팟 테스트 • 스트레스 테스트 • 가장 최악의 시나리오를 적용하여 짧은 시간 동안 기대치 보다 큰 로드를 부과한다 • 한계에 달했을 때 어떤 일이 발생하는지 알 수 있다 • 목적은 최악의 상황을 피하고자 하는 것 • 사례 • 동시에 많은 접속자들이 같이 특정 버튼을 누르도록 테스트하여 네트웍의 대역폭, 서버의 자원이 충분한지, 데이터베이스에 병목은 없는지 체크한다. • 핫 스팟 테스트 • 특정 지역에 집중되어 있는 문제를 테스트한다 • 사례 • 어느 증권사 사이트가 있는데 이 사이트는 초당 100개의 거래를 처리할 수 있다. 과연 이 사이트는 같은 주식에 대해서 초당 25개 이상의 거래를 처리 할 수 있는지 알아보는 테스트

39. 성능 테스트 (명세) • 스트레스와 핫 스팟 테스트 • 스트레스 테스트 체크 리스트

40. 성능 테스트 (명세) • 스파이크 테스트 • 웹 사이트에 예외적인 로드(spike)의 증가를 테스트 • 태풍을 예측하는 것은 스파이크 테스트와 유사 • 일부 스파이크는 인공적인 원인에서 비롯되기도 한다 • 바운드 테스트 • 스파이크 테스트의 일종 • 부하를 줄였다 늘였다 함으로써 얼마나 시스템이 부하에 대한 변화를 잘 처리하는지 테스트 • 스파이크 테스트 체크 리스트

41. 성능 테스트 (명세) • 무결성 테스트 • 모든 로드에서 웹 사이트 기능이 보전되는지를 테스트 • 기능 테스트와 스트레스 테스트의 조합 • 모든 경우의 기능 변화를 테스트 하는 것으로 기능 테스트와 밀접한 관계가 있다 • IDS는 평상시에는 침입을 탐지하지만, 스트레스가 부과된 상태에서는 탐지율이 떨어지거나 못하는 상황이 발생한다

42. 성능 테스트 (명세) • 테스트 지표 • 응답시간 • 작업을 시작해서 원하는 결과가 표시될 때까지의 시간 • 주로 퍼센트로 표시: 응답시간은 ‘N회를 95%의 시간으로 수행했다 • 웹사이트의 응답 시간 • 평균 < 5.0 초 • 95% < 10.0 초 • 99% < 12.5 초 • 95%~99% 웹 어플리케이션 컨트롤에 문제가 있다는 것을 의미

43. 성능 테스트 (명세) • 테스트 지표 • 응답시간 서버응답시간 네트워크 서비스 시간 브라우저 반응 시간

44. 성능 테스트 (명세) • 테스트 지표 • 부하(workload) • 시스템에 요구되는 트래픽 매니지먼트와 프로세서의 양을 의미 • 사용자, 어플리케이션, 자원의3가지가 고려 • 사용자의 행위를 처리할 어플리케이션의 요구, 시스템의 자원에 대한 이해를 가지고 시스템의 부하를 측정한다. • 사용자 프로파일 • 사용자가 웹 사이트에서 무슨 일들을 하고, 웹 사이트 성능에 영향을 주는 어떤 특성을 가지고 있는지를 아는데 도움 • 사용자의 작업, 생각하는 시간, 사이트의 이동 등의 여러 가지를 고려 • 테스트 모델이 더 현실과 유사할수록 정확한 사용자 프로파일을 얻을 수 있다

45. 성능 테스트 (명세) • 테스트 지표 • 사용자 작업(user activities) • 자주 이용하는 기능 • 사용자들이 많이 행하는 기능을 중심으로 현실 세계를 반영한 테스트 스크립트를 만들어야 한다 • 50명의 사용자 중 1명만이 구매를 하는데, 브라우징과 구매의 비율을 절반으로 잡는 것은 비현실적이다. 50:1이 사용자 행위를 반영한 현실적인 비율이다. • 시스템 레벨에서의 성능 테스트는 긴 스크립트를 이용한 전체 사용자 세션 • unit 레벨 테스트(예: 웹 사이트의 컴포넌트)는 짧고 집중적인 스크립트를 사용하여 분석

46. 성능 테스트 (명세) • 테스트 지표 • 생각하는 시간(think time) • 현재 페이지의 마지막 데이터 패킷을 받은 시점으로부터 새로운 페이지를 요구하는 시간 • 현재의 페이지에서 다음 페이지로 넘어갈 때 정지기간 • 숙달된 사용자는 정지기간이 짧을 것이고 그렇지 못한 사용자는 다음페이지의 로딩을 시도할 때까지 오랜 시간이 걸리 것이다 • 사이트 포기(site abandonment) • 브라우저가 완료 될 때까지 기다리지 않고 다른 페이지로 이동 • 현실성을 고려해서 테스트 스크립트에도 사이트 포기를 반영 • 전송 속도와 대역폭 • 웹 어플리케이션의 종류에 따라 접속 속도에 영향 • 모뎀을 사용하는 곳에서는 중요하게 고려되어야 할 사항

47. 성능 테스트 (준비) • 테스트 준비 단계 • 테스트 스크립트와 데이터를 얻는다. • 테스트 아키텍처와 환경을 명시한다. • 실행 로드를 확인한다. • 도구, harness, 드라이버를 선택한다. • 스크립트와 데이터 얻기 • 데이터의 요구를 확인 • 스크립트를 위하여 필요한 데이터가 로컬 DB파일인지, 웹 DB 파일인지, 레거시 DB파일인지를 파악 • 이후에 데이터의 출처를 확인 • 도구로부터 자동생성이 된 것인지 또는 수동으로 생성된 것인지 파악 • 스크립트는 반복이 없는지 살펴 본다 • 레거시 시스템, DB, Back Office application에 대한 접근이 정확한지 주의 깊게 체크

48. 성능 테스트 (준비) • 환경 명시 • 현실과 가까운 환경을 구축 • 최소의 테스트 시스템을 주요한 아키텍쳐 환경에 반영 • 테스트 시스템은 닮은 꼴의 아키텍쳐 • 동일한 형의 시뮬레이션 환경에서 테스트 • 양이 같아야 한다는 것이 아닌 유형과 수가 같아야 한다 • 실제 로드는 방화벽이나 proxy 서버를 거쳐가므로 이러한 종류의 플랫폼 역시 성능 테스트에 포함되어야 한다. 절충 (compromise) 최소 (miniature) 로드 생성기 모든 범위 (Full scale)

49. 성능 테스트 (준비) • 실행 로드 • 로드의 레벨을 정하고 로드 수행 방식을 선택 • 수동식 • 범위 선정이 어렵고 여러 번 반복과 아주 큰 로드에 대해서는 테스트 할 수 없다 • 소프트웨어나 하드웨어를 이용 • 사용법을 배우고 지속적인 유지개발이 필요 , 로드에 대해서 제어가 가능하고 비용이 절감 • ASP(Application Service Provider)를 이용 • 큰 테스트의 비용절감과 유지비용이 적고 위험을 낮출 수 있다. 테스트를 위해서 숙련도가 요구되는 단점이 있다. • 초기 테스트(1~5 가상 사용자)는 수동으로 실행 • 중간 테스트(5~100의 가상 사용자)는 제작하거나 로드 생성기 사용 • 가상의 사용자가 100명 이상이 되는 마지막 테스트는 ASP를 주로 이용한다

50. 성능 테스트 (준비) • 도구, harness, 드라이버를 선택 • 가상 사용자(virtual user) 또는 가상 클라이언트(virtual client) • 사용자들이 연결을 시도하는 것처럼 보여지게 하는 것 • 탐색 클라이언트(probing client) • 가상 사용자들의 자원 요구 계산 예시 • 가상 사용자의 자원 요구량 • 스크립트의 크기, 쿠키의 사용 여부, 웹 페이지의 암호화 사용 여부 • 각각 가상 사용자들의 자원 요구량 : 2M • 사용 컴퓨터 수 : 4 PCs • 컴퓨터의 램 용량 : 64MB • 수용가능 사용자 수: 4 * 64/2=128