소프트웨어 테스팅 실무

Size: px

Start display at page:

Download "소프트웨어 테스팅 실무"

민지 종
5 years ago
Views:

1 웹어플리케이션성능테스팅사례 와이더댄박은영

2 목차 1. Introduction 2. Test Plan 3. Assumption 4. The Result 5. Conclusion Number of Slide l 2

3 1. Introduction 1.1 Base line of the performance level 1.2 Definition of transactions Number of Slide l 3

4 1. Introduction 웹어플리케이션성능테스트대상제품 Ring back tone 제품 (ex, 컬러링 ) Music on Demand 제품 (ex, 멜론 ) 성능테스트는 제품요구문서, 개발정의문서, 계약서, 운영중에수집된통계정보, 및시스템사이징문서를참조하여제품이만족해야할성능수준을정의하고실제구축된사이트의성능을검증하는작업이다. 와이더댄 HQ QA 성능시험은 top 10 business transaction 을기준으로부하를발생시킨후계획된요구수준을만족하는상태의측정결과값을수집하여서비스성능수준을확인및예측하는하는것을목표로한다. 성능테스트를통해트랜잭션응답속도, 시스템메모리및 CPU 사용량을측정하고 system architecture 와 software structure 를검증한다. Number of Slide l 4

5 1.1 Base line of the performance level 성능테스트시작조건 성능테스트요청이들어왔을때 부하발생대상 (Top 10 business) 모듈의개발이완료된상태 전체적인개발완료율은 90% 이상인상태 요구된테스트데이터가준비된상태 필요한정보및작업이완료되었을때 성능테스트종료조건 정해진기간에제품의성능수준예측값이도출되었을때 성능테스트결과보고서를작성하여보고메일을전송했을때 제품성능수준측정결과값을토대로추정치를예측하는데있어서포 함될수있는내용 만일 build acceptance test 및 system acceptance test 를진행하면서프로그램오류와 3rd party solution 에서결함이발견되면그상태를보고하고 정해진자원 (M/M) 을다사용한시점에위의문제가해결되지않았다면그때까지수집된측정결과값을토대로제품의성능수준을예측하고종료한다. Number of Slide l 5

6 1.2 Definition of transactions 트랜잭션은 고객마다그정의가변경될수있으며, 일반적으로하나의메시지를처리하는흐름들로구성되어, 하나의단위로수행되어야하는연산문장들의집합으로정의함 예 ) 입력한검색명령어에대해검색결과가출력완료되는시 점까지하나의트랜잭션으로정의한다. Number of Slide l 6

7 2. Test Plan 2.1 Planning Procedure 2.2 Test Procedure 2.3 System Architecture 2.4 Test Type 2.5 Test Scenario Overview 2.6 Contact Point Number of Slide l 7

8 2.1 Planning Procedure 성능테스트 Planning 단계에서의작업목록 성능테스트목적및범위정의 Contact point 및 R&R 명시 트랜잭션정의 성능수준정의 ( 동시사용자정의 ) 사용자사용패턴예측 (Top 10 business 정의 ) 테스트환경명시 전제조건정의 필요한테스트데이터정의 사전준비사항, 완료날짜및작업결과확인 (checklist) 리스크분석 Test script sample 을작성하여추가적인작업요건확인 ( 필요시별도의 simulator 나 UI 를개발팀에요청 ) Number of Slide l 8

9 2.1 Planning Procedure 성능테스트 Planning 과정에서계획된모든작업단위에 대해서는누가그작업을수행할것인지에대해지정하여 마무리한다. [ 작성예제 ] Steps Activities Owner Due Date Result 1 Decide the schedule of Helio s site load testing OK 2 Define pre-requirements for the testing 09.22~10.17 OK 3 Define the load testing scope 09.27~10.03 OK 4 Define the test environment OK 5 Assign each task s owner with the target date 10.03~ OK 6 Define transactions and estimate a user s activities OK Number of Slide l 9

10 2.2 Test Procedure 계획및설계 검토및업데이트 시스템및 App 준비 DEV QA SE PM System Acceptance Test Build Acceptance Test 실행 결과분석및평가 based on pre-requirements list System, Config, Log 확인등 based on top 10 business scenario Test Script / Test Scenario 작성시스템초기자원사용률측정계획한부하발생 (unit, Aging, Integration, end-to-end) 응답시간, 성공률, 시스템자원사용률, 동시사용자결과분석가용성, 성능, 시스템증설싯점예측 Saturation point 찾기 (3 회성공결과확보 ) Tuning & Fix a defect Number of Slide l 10

11 2.3 System Architecture 실행환경구성요소 ( 웹인프라스트럭처 ) WEB Server WAS: Application Server Database Server 부하분산장비 (Layer-4 4 Switch) 성능테스트검증대상 성능 (Performance) 확장성 (Scalability) 가용성 (Availability) 보안 (Security) 기존시스템과통합 (Legacy Interface) Number of Slide l 11

12 2.4 Test Type 성능테스트수행단계및단계별부하주는위치 Aging Test 1 단계 : Unit Test 2 단계 : Integration Test 3 단계 : End-to-End Test 각서비스를구성하고있는시스템한대에대한성능및안정성확인 L4 Switch 앞에부하를주어 load balancing 시서비스성능수준확인 Infrastructure 의영향분석및실제서비스될수있는 total TPS 확인 테스트진행시고려사항 (* 발취 : 성능시험소개서 -IBM 신규사이트 IBM 발표자료, Hark Young, Oh) 시스템설계당시산정된동시사용자수및성능 (TPS, 응답시간 ) 을만족하는가? 현개발중인시스템은최적화가제대로되어있는가? 기존사이트 다수의사용자가접속하였을때성능상의이슈사항은없는가? 계속증가하는사용자를언제까지대응할수있을까? 시스템증설시가장효과적인투자부분은어디인가? 개편 ( 통합 ) 사이트 개편전시스템의성능을제대로수행해내는가? 통합전시스템들의사용자를통합이후제대로수용할수있는가? Number of Slide l 12

13 2.5 Test Scenario Overview 테스트시나리오에서고려해야할부분 Think time 은 0으로설정하여시스템의성능을확인 실행시간 : peak time (1 시간 ) 성능수준이정의되었을때는 Peak load 로부하발생시킴 성능수준이정의되지않았을경우에는가상유저를점진적으로 lamp up 해서 saturation point 확인 트랜잭션설정내용확인 응답시간이 3초이상일경우 transaction fail 로처리 트랜잭션별 hit ratio 정의 작업환경에서테스트불가한기능정의 테스트데이터에따른파라메터호출방법정의 Number of Slide l 13

14 2.6 Contact Point 성능테스트를진행하는데있어서가장먼저파악해야하는 부분은아래와같은관련자정보를미리수집하는것이다. Category Name / Assigned Date Result Project Manager OK Technical Leader OK System Engineer OK Network Administrator OK Data base Administrator OK Preparing some desktop systems Product Designer Load Tester OK OK 박은영 (christenpark@widerthan.com) OK Number of Slide l 14

15 3. Assumption 3.1 Performance level 3.2 Resources to be required 3.3 Pre-requisites requisites Number of Slide l 15

16 3.1 Performance Level Assumption user activity (Depends on Local Market. This is for US Market) Total daily users using WEB and PC Client: 10% against subscriber WEB user vs PC Client user = 1: 2 WEB Subscriber: WEB Visitor: PC Client subscriber = 1 : 2 : 6 Activity user per day User activity happens for 11 hours a day Peak time load = 250 % higher Calculation user activity per second (** 필요시접속유지시간고려할수도있음 ) Daily Users = Subscriber * PC Client activity user per day (6.70%) Hourly Users = Daily Users / 11 hours (User activity duration a day) Minutely Users = Hourly Users / 60 minutes Secondly Users = Minutely Users / 60 seconds Peak time Users = User per sec * peak time load Expected Transaction per Second Peak time TPS = Peak time users * Hit ratio User 1 500,000 1,000,000 1,500,000 2,000,000 Per Day , , , , Per Sec Per Busy Sec Number of Slide l 16

17 3.2 Resources to be required Active user, Concurrent user (= Active user * Think time) Transaction information Transaction response time TPS (passed transactions per second) Transaction success rate in 3 seconds: : Should be over 99.98% System resource CPU : Should be under 70% Memory usage rate : Should be under 80% Database resource (Oracle 9i) The number of Connection: Should be covered the maximum concurrent user Enqueue Waits: Should be under 2,000,000 The Ratio of Buffer Cache hit : Should be more than 60% The Ratio of Memory Sort : Should be above 90% The Ratio of Index Utilization : Should be under 10% Number of Slide l 17

18 3.3 Pre-requisites 성능테스트전완료되어야할작업확인기술 Network ID Condition Owner Network Network bandwidth should be guaranteed minimum 100Mbps between the target systems and load generator systems. Due Date Result Network Bandwidth Network Card Maintenance Window System Information Configurations Process and Cron tab info Software SPEC Initial system resource usage rate Load Balancing System Information Fake Data System list and the login ID/password (Input this information on chapter 4.1) The maximum connection number to Database (DB connection pool number) (Input this information on chapter 4.3) User accounts for all servers are needed to for running prtdiag, top or netstat command for checking system information and processes. Put 500,000 subscribers in the DB sequentially Prepare 100,000 contents at least Application Fake Data ( 테스트데이터 ) 기능별작업완료률 Link 정보및 Log 정보 Application Process list with % development completion (Input this information on chapter 4.4) Log path for checking the result of a transaction (Input this information on chapter 4.4) Simulator 종류, 실행경로 Number of Slide l 18

19 4. The Result 4.1 Transaction 4.2 System Resource 4.3 Database 4.4 System Performance Level Number of Slide l 19

20 4.1 Transaction 성능에가장많은영향을주는것은 Application 프로그램임 성능테스트대상은사용자가많이사용하는 UI 가대상이되며관 리자페이지는제외됨 측정된결과를통해튜닝기준은성공적인 TPS (3 초이내의 Transaction per Second) 대비응답시간이높은순서로진행됨 아래표에서 Songs 트랜잭션의성공율이낮음으로원인분석 PC Client Response Time (second) Transaction Transaction Name TPS Min Mean Max Total In Time % Authentication ,036 16, % Purchase Songs ,012 7, % Songs , % In Time TPS Number of Slide l 20

21 4.1 Transaction Saturation Point 가확인되면해당 Active user 수로지속적으 로 peak time 동안부하를발생시킨후응답시간을측정한결 과 Number of Slide l 21

22 4.2 System Resource 실제성능테스트과정에서측정된결과 DB 의초기값이비정상적으로높은사용율을보이는경우 CPU Measurement Initial Value (Average) Minimum Average Maximum Recommend Result Database % Fail Search Engine % Need to monitor 시스템 Load balancing 설정이잘못되어분산되지않은경우 Measurement Initial. Ave. Max. Recommend Result CPU Utilization : (Search) % Need to check CPU Utilization : (Search) % Pass CPU Utilization : (DB) % Pass CPU Utilization : (DB) % Pass Number of Slide l 22

23 4.2 System Resource CPU 와 TPS 상관계수가 1에가까울수록정상적인활동임. 오른쪽하단그림과같은결과는시스템이비정상적으로튜닝필요. 오른쪽그림은최대 6.4 TPS 까지증가하다가 CPU 77% 정도로여유로운상태에서 process 가 hang 되는문제. Number of Slide l 23

24 4.3 Database Database Server 데이터베이스서버는지속적인데이터저장과조회서비스를제공함 데이터베이스는웹어플리케이션의성능을결정하는가장중요한요소임 웹어플리케이션서버가데이터베이스에게요청할때권고하는요청방법은여러번의요청보다는한번의요청혹은요청수를줄이는방법으로처리 Connection pool Connection pool 설정이잘못된경우심각한성능저하유발 성능테스트수행시 Connection 수가지속적으로증가한다면세션을종료하지못함 Application DB 와 Master DB 와의상호참조되는정보정확성검증 Measurement Minimum Average Maximum Recommend Result enqueue waits (V$SYSSTAT1/RGRTEST1) (absolute) enqueue timeouts (V$SYSSTAT1/RGRTEST1) (absolute ,626 1,626 1,626 The number of Connection The Ratio of Buffer Cache hit Over 60% Pass The Ratio of Index Utilization Under 10% Pass The Ratio of Memory Sort Over 90% Pass Number of Slide l 24

4.4 System Performance Level 시스템용량산정을위한선형회 귀모델채택한성능수준 수학적모델 선형회귀분석모델 독립변수 : 분석주기 종속변수 : Peak 시간대의 Max TPS 용량산정결과 < 선형회귀분석모델예 > Requirements Subscriber 500,000 Peak time load 4.

25 4.4 System Performance Level 시스템용량산정을위한선형회 귀모델채택한성능수준 수학적모델 선형회귀분석모델 독립변수 : 분석주기 종속변수 : Peak 시간대의 Max TPS 용량산정결과 < 선형회귀분석모델예 > Requirements Subscriber 500,000 Peak time load 4.34 The Result on Staging Server Estimation the acceptable subscriber on Production Server Active user (Concurrent user) * Success rate: over 99.5% * Under the recommendation regarding system resource usage rate 1.2 Maximum 6 Performance Level 139,392 Maximum 464, ,568 (* think time) * This estimation will be satisfied under running the xxx Service only on Production Number of Slide l 25

26 5. Conclusion 5.1 Lessons learned 5.2 Summary Number of Slide l 26

5.1 Lessons learned 성능테스트활동 Application Process Log 파일목록및설치경로 Assumption 성능수준 ( 운영통계정보기반 ) Top 10 Business Transaction 감시할시스템및적정수준 성능테스트결과분석 -> 성능수준도출 Transaction, 응답시간, 자원사용률,

27 5.1 Lessons learned 성능테스트활동 Application Process Log 파일목록및설치경로 Assumption 성능수준 ( 운영통계정보기반 ) Top 10 Business Transaction 감시할시스템및적정수준 성능테스트결과분석 -> 성능수준도출 Transaction, 응답시간, 자원사용률, 동시사용자 성능테스트 H/W SPEC, S/W Configuration System Architecture, Network 성능시험목적및범위 Contact point, R&R Test procedure, Test Scenario Test Environment Test Planning Number of Slide l 27

5.2 Summary 성능테스트목표및측정항목 System System Architecture Architecture ( 시스템 ( 시스템최적화최적화확인확인 ) ) 연동시스템구조 / 시스템사양등 동시동시사용자사용자 (Saturation (Saturation Point) Point) 최대최대수용수용가능가능사용자사용자 ( 시스템 ( 시스템증설증설시점시점결정결정

28 5.2 Summary 성능테스트목표및측정항목 System System Architecture Architecture ( 시스템 ( 시스템최적화최적화확인확인 ) ) 연동시스템구조 / 시스템사양등 동시동시사용자사용자 (Saturation (Saturation Point) Point) 최대최대수용수용가능가능사용자사용자 ( 시스템 ( 시스템증설증설시점시점결정결정 ) ) 목표수준확인, 성능수준예측 서비스서비스최대최대 TPS TPS ( 응답시간 ( 응답시간 3 3 초이내의이내의 transaction) transaction) 시스템시스템안정성안정성 ( 개편 ( 개편전시스템시스템기능과기능과성능성능변동변동 ) ) 병목병목지점지점확인확인 ( 다수의 ( 다수의사용자가사용자가접속시접속시발생발생이슈이슈 ) ) ( 시스템 ( 시스템자원자원사용률사용률및응답시간응답시간확인확인 ) ) Number of Slide l 28

29 5.2 Summary 제품개발단계 : 제품요구문서, 계약서, 개발정의문서또는시스템사이징자료에서제품이만족해야할성능수준을확인하고그도출된수준을성공기준으로정의한다. 주로개발초기에작성된시스템사이징자료를기반으로그성능수준을도출하는경우가많다. 제품이서비스되고있는상태 : 제품개발단계의시스템사이징에따른성능수준정의는실제서비스사용패턴과많이다를수있다. 따라서서비스가직접운영되었을때의실제측정된사용자패턴정보를수집하여이정보를바탕으로트랜젹션을발생시켜현재운영시스템의증설싯점을확인하기위해수행된다. 서비스환경을변경하고자점검하는단계 : 현재운영중인시스템의유지보수비용의비효율성및시스템에큰결함이발생되었을때, 신규로직추가및현재서비스를수행하고있는시스템을다른시스템으로대체할경우현재의성능수준을유지하면서시스템의가용성과안정성에문제가없는지확인하기위해수행된다. 예를들면, Oracle DB 에서 Memory DB 로변경하고자할때그변경에대한영향력을확인하기위해성능테스트를수행한다. Number of Slide l 29

30 감사합니다.

PowerPoint 프레젠테이션

PowerPoint 프레젠테이션 Reasons for Poor Performance Programs 60% Design 20% System 2.5% Database 17.5% Source: ORACLE Performance Tuning 1 SMS TOOL DBA Monitoring TOOL Administration TOOL Performance Insight Backup SQL TUNING