Performance Testing Guide for web App

Chapter 1 을 읽고 성능 테스트의 정의를 정리하시오.

Core Activities of Performance Testing

  1. Identify the Test Environment
    • 실제 물리적(H/W, S/W, 네트워크 등..) 환경, 가용자원, 도구 등을 식별합니다.
  2. Identify Performance Acceptance Criteria
    • 응답시간(유저), throughput(business), 자원 최적화 등 목표와 제한을 만듭니다.
    • 이 이외에 여러가지 성공 기준들을 성립하는 기간입니다.
  3. Plan and Design Tests
    • 시나리오를 만들고 여러 변동성을 고려하여 테스트 케이스를 만듭니다.
    • 그리고 이러한 테스트를 하나 이상의 시스템으로 통합하여 분석하고 준비합니다.
  4. Configure the Test Environment
    • 테스트 환경, 도구, 자원 등 필요한 것들과 전략, 가능한 테스트 들을 고려합니다.
  5. Implement the Test Design
    • Test Design에 따라 성능 테스트를 개발합니다.
  6. Execute the Test
    • 테스트를 실행하고 모니터링 합니다. 분석을 위한 테스트 결과들을 수집합니다.
  7. Analyze Results, Report and Retest
    • 결과 데이터를 통합하고 교차 기능팀(cross-functional team)끼리 혹은 개별적으로 분석합니다.
    • 설정된 임계값 이내에 모든 값이 들었을 경우, 원하는 모든 정보를 수집했을 경우 테스트는 마무리 됩니다.
    • 하지만 불완전한 경우 나머지 테스트의 우선순위를 정하고 다시 테스트합니다.

Why Do Performance Testing

  1. 릴리즈 준비상태 평가
    • 프로덕션 환경에서 프로그램의 성능 특징을 예상할 수 있고 이러한 것들을 어떻게 해결할지 판단할 수 있습니다. 릴리즈 전 성능 향상, 하드웨어 업그레이드 등을 이해관계자가 판단할 수 있게 하는 중요 지표가 됩니다.
    • 사용자가 불만족 할만한 부분을 미리 판단, 회사의 신뢰도에도 직접적 영향이 가는 부분 예측
  2. 인프라 적합성 평가
    • 현재 인프라의 적합성을 판단하고 이 인프라 내에서 원하는 성능을 나타내고 있는지를 판단. 향후 자원 투입 등에도 예측, 영향을 줄 수 있다.
  3. 개발된 SW 퍼포먼스 적합성 평가
    • 현재와 이후 변경될 기능, 제품의 비교를 제공
  4. 퍼포먼스 튜닝의 효율성 증대를 위한 평가
    • 제품의 병목현상, 로드 등을 미리 판단

Project Context

Project Context에 대한 이해가 밑받침 되면서 성능 테스트가 일어나야 한다. Project Context에는

  1. 프로젝트의 전체적인 통찰, 의도
  2. 성능 테스팅의 목적
  3. 성능 성공 기준
  4. 개발 life cycle
  5. 프로젝트 스케줄
  6. 예산
  7. 환경
  8. 테스터, 팀의 역량
  9. 성능 고려의 우선순위
  10. 성능이 안좋을 때 비즈니스에 미치는 영향 이외에 프로젝트 비전, 시스템의 목적, 유저, 고객들의 기대 등을 생각해 볼 수 있다.

The Relationship Between Performance Testing and Tuning

Cooperative Effort

대부분 튜닝을 목적으로 성능 테스팅을 하게 되는데 이러한 테스트를 할 때 교차 기능팀(cross-functional team)이 모두 포함되어야 시스템 전반적으로 기대한 효과를 얻을 수 있습니다.

Tuning Process Overview

성능 테스팅과 다르게 반복적인 방식이 투입됩니다. 성능 테스트에는 일반적으로 빠른 변경과 테스트가 필요합니다. 테스트 도중 문제가 발생되면 독립적인 성능테스트 팀과 튜닝팀이 투입되어 수정에 나섭니다. 이후 개선점을 반영하여 변경을 확인합니다.

performance, Load, and Stress Testing
  • Performance testing: 시스템의 속도, 확장성, 안정성 등을 테스트합니다.
    • 응답시간, throughput, 자원 최적화 등에 초점이 맞춰서 테스팅이 이뤄집니다.
  • Load testing: 작업 중 발생하는 로드때문에 성능에 영향을 주는 것을 검증하는 과정이 주로 이뤄집니다.
  • Stress testing: 작업 중 예상되는 조건을 초과할 경우 프로그램의 특성, 유효성을 검증하는데 초점이 맞춰집니다. 제한된 메모리, 디스크 공간 부족, 서버 장애 등 stress상황이 주어졌을 때 성능 특성을 측정하는데 있습니다.
Baselines

baseline을 만드는 것은 성능 향상 후 얼마나 발전되는지 평가할 목적으로 테스트를 실행하는 프로세스 중 하나입니다. baseline은

  • 이후 비교기준이 되며
  • 측정항목이며 재사용이 가능해야 합니다.
  • 지나친 일반화는 금물이며(다른 버전에서 그 기준선이 유효하지 않을 수도 있음)
  • 진화되게 됩니다.(재정의)
Benchmarking

다른 조직에서 승인한 업계 표준과 시스템 성능을 비교하는 프로세스 입니다. 벤치마킹은

  • 규칙을 따라야하지만
  • 규칙을 따라 투명한 결과를 낼 수 있습니다.
Terminology(용어)
  • 프린트 참조

Chapter 2 를 읽고 성능 테스트의 종류를 정리하고, 해당 테스트가 어떤 상황에서 필요한지 직접 생각하여 정리하시오. (Word 2 page 분량)

테스트의 종류

  1. Performance Test
    • 속도, 확장성 및 안정성을 결정하거나 검증합니다.
    • 새로운 장비를 투입했거나 DB index 추가, 새로운 라이브러리, 프레임워크 적용 등 기존 성능과 비교할 경우 사용할 것 같습니다.
  2. Load Test
    • 정상 및 최대 조건에서 응용 프로그램의 동작을 검증합니다.
    • 한 페이지에 많은 사람들이 몰렸을 경우(예를 들어 조회수 같은) 혹은 회원 세션을 mysql, redis로 변경했을 떄 로드를 얼마나 감당할 수 있을지 지점을 조사할 때 사용할 수 있을 것 같습니다.
  3. Stress Test
    • 최대 조건을 초과하였을 때 동작을 확인합니다.
    • 그러한 상태에서 동기화, 메모리 누수 등을 확인 할 수 있습니다.
  4. Capacity Test
    • 주어진 시스템이 얼마나 많은 사용자, 트랜잭션을 지원하는지 결정하고 성능목표를 달성합니다.
    • 향후 얼마나 지원할 지 추가 리소스가 얼마나 필요한지(메모리, 디스크, 네트워크 등)을 알아내 스케일 업, 스케일 아웃 여부를 판단합니다.

해당 테스트를 통해 얻을 수 있는것

  1. Performance Test
    • 결과를 통해 비즈니스 결정을 내릴수 있습니다.
    • 사용자가 만족하는지를 판단 할 수 있습니다.
    • 튜닝 계획을 세우는 지표가 될 수 있습니다.
    • 하지만 신중하게 설계되지 않으면 아무 의미 없는 성능 테스트 일 수 있습니다.
  2. Load test
    • 예상 최대 생산로드를 지원하는데 필요한 처리량을 결정할 수 있습니다.
    • HW의 적합성을 평가, 로드밸런서의 적합성을 평가합니다.
    • 하지만 응답속도를 주로 고려하지 않습니다.
  3. Stress Test
    • 시스템 별 과부하를 통해 데이터가 손상이 있는지 알 수 있습니다.
    • 임박한 장애를 판단할 수 있습니다.
    • 하지만 이러한 테스트를 테스트 환경으로 격리하지 않는다면 큰 혼란에 빠질 수 있습니다.
  4. Capacity Test
    • 용량 계획자가 여러가지 판단을 할 수 있는 기준을 제공합니다.
    • 하지만 이러한 테스트들을 통해 용량 계획 모델의 모든 면을 검증할 수 있는 것이 아니고 테스트 작성이 어렵습니다.

추가용어

  1. Component Test
    • 일반적으로 DB, Network, Firewall, 저장 장치 등 구성요소를 대상으로 테스트합니다.
  2. Investigation
    • 제품의 품질을 향상시킬 수 있는 정보를 수집하는 활동입니다. 가설을 만들거나 반증을 만들기 위해 주로 사용합니다.
  3. Smoke Test
    • 응용 프로그램이 정상적인 부하를 견딜 수 있는지 성능테스트 초기에 이뤄집니다.
  4. Unit Test
    • 기존 코드의 하위 집합인 코드 모듈을 테스트 하는 것입니다.
  5. Validation Test
    • 제품의 속도, 확장성 등을 테스트

Chapter 3 을 읽고 성능테스트시에 어떤 위험사항이 있는지 정리하시오. (Word 1 page 분량)

성능테스트 타입에 따라 해결될 수 있는 위험들

  1. Capacity
    • 시스템 용량이 최대로드, 정상 조건에서 만족하는지
  2. Component
    • 컴퍼넌트가 합리적으로 최적화 되어있는지
    • 성능 문제가 컴퍼넌트로 인해 발생하는지
  3. Endurance
    • 시간이 지나도 성능이 일관적인지
    • 느리게 성장하는 문제가 있지 않은지
  4. Investigation
    • 미래의 테스트와 어떻게 비교해야하는지
    • 시간 경과에 따른 실적 추이는 어떻게 하는지
  5. Load
    • 네트워크, 데이터베이스, 파일 서버에서 처리할 수 있는 양은 얼마나 되는지
  6. Smoke
    • 추가 성능테스트를 위해 빌드를 구성할 준비가 되었는지
    • 이 빌드가 마지막 것보다 성능이 향상 되었는지
  7. Spike
    • 생산 부하가 예상을 넘어서면 어떻게 될지
    • 어떤 종류의 실패를 계획해야 하는지
  8. Stress
    • 생산 부하가 예상 부하를 초과하면 어떻게 될지
    • 어떤 종류의 실패를 계획해야 할지
  9. Unit
    • 코드가 로드 하의 제대로 수행되는지
    • 효율적인 코드인지
  10. Validation
    • 목표, 요구사항에 만족하는지
    • SLA를 위반하게 되는지

속도와 관련된 위험은 유저 뿐 아니라 비즈니스 전반적으로 영향을 미치는 위험 요소입니다.

  • 최종사용자를 만족시킬 만한 속도인지
  • 최신 정보를 빠르게 제공할 수 있을지

  • 오류 전 최대 예상 응답시간 내 제대로 응답하는지 등을 성능 테스트로 판단할 수 있습니다.

  • 위험 완화 전략
    1. 요구사항이 사용자의 요구를 만족하는지 확인하기
    2. 개선 후 이전 버전과 경쟁사화 비교하기
    3. 실제 환경처럼 테스트 환경을 구축해서 테스트 해보기
    4. 트랜잭션을 포함하기(시간에 민감한)
    5. 다양한 조건, 부하 수준 시나리오를 만드시오(사용자는 일관된 속도를 중요하게 느낍니다.)

사용자 수 뿐 아니라 응용프로그램이 처리할 수 있는 데이터의 양, 용량을 식별합니다.

  • 과도한 사용으로 인해 기능이 손상되는지
  • 전체 사용자에게 수용 가능한 응답시간을 제공하는지
  • 모든 데이터를 저장할 수 있는지
  • 보안이 유지되는지

  • 용량이 일정 수준을 넘었을 경우 경고가 나타나는지

  • 위험 완화 전략
    1. 다양한 부하에서 측정된 속도를 비교하세요
    2. 실제 요구 사항에 매핑되는 의미있는 테스트를 수행하세요
    3. 확장성 한계를 찾으면 부하를 점차적으로 줄이고 재검사해서 대책을 적용할 수 있는 지표를 식별하세요
    4. 최대 로드를 초과하는 성능 테스트를 수행하고 성능 테스트 도중 혹은 후에 사용자가 사용하는 것을 관찰합니다.
  • 데이터 손상, 속도 저하, 서버의 부재 등을 극복할 수 있는지
  • 부분적으로 완료된 트랜잭션은 어떻게 작동되는지
  • 오류, 반복되는 기능의 조합으로 시스템 충돌이 발생할 수 있는지

  • 시스템을 패치하지 않고 업데이트 할 수 있는지 등 안정성을 판단하게 됩니다.

  • 위험 완화 전략
    1. 스트레스 테스트를 수행해서 지표를 추출하고 그것으로 비즈니스를 운영하세요
    2. 실제 생산환경을 최대한 비슷하게 복제해서 테스트 해봅니다.
    3. 테스트 중 서버를 오프라인으로 하여 나머지 시스템의 기능, 성능을 테스트 해봅니다.
    4. 성능 테스트 중 백업 등 업데이트를 강제 실행 해 봅니다.

Part 2 를 읽고 성능테스트시 어떤 작업들이 필요한지 정리하시오. (Word 2 page 분량)

  • Chapter 4
    성능 테스팅 핵심 활동 요약
  1. Identify the Test Environment
    • 핵심 요소는 테스트 환경과 실제 프로덕션 환경간의 유사점, 차이점을 이해하는 것입니다.
    • 하드웨어(구성), 회로망, 모니터링 도구, 로깅 등을 고려합니다.
  2. Identify Performance Acceptance Criteria
    • 응답시간 / 처리량(Throughput) / 자원 활용(Resource utilization) 이 특성 클래스에 주로 포함됩니다.
    • 요구사항, 계약상 의무, 사용자의 기대치 등이 포함됨
  3. Plan and Design Tests
    • 현실적인 테스트 디자인
    • 외부 시스템과 상호작용
    • 이론, 예측이 아니기 때문에 신뢰성이 올라감
    • 적절한 도구 산정
  4. Configure the Test Environment
    • 로드 부하 고려
    • 시스템 동기화 고려
    • 리소스 사용률 체크
  5. Implement the Test Design
    • 테스트 데이터가 제대로 구성되어있는지
    • 트랜잭션의 유효성 검증
    • 핵심 성과 지표 모니터링
    • 사업 성과의 지표

  6. Execute the Test

  7. Analyze Results, Report and Retest
    • 보고서 작성
    • 기술보고서
    • 이해관계자 보고서
    • 직관적으로, 사실 그대로, 올바른 통계를, 바로바로 보고
  • Chapter 5
    반복적인 성능 테스트 활동
  1. Understand the Project Vision and Context.
    • 프로젝트의 전체적인 이해, 비전, 가치를 결정하는 시기
    • 일정, 구조, 사용가능한 리소스 파악, 성능 테스트 어떻게 할 지
    • 팀이 어떻게 의사소통 할 지
  2. Identify Reasons for Testing Performance.
    • 성능 테스트를 통해 완화 시킬수 있는 문제가 뭐가 있을까?
    • 어떤 성능 문제가 이미 존재하는지?
  3. Identify the Value Performance Testing Adds to the Project.
    • 1, 2를 통해 얻은 결과로 성능 테스트 전략을 변화, 성립합니다.
    • 현 시점에서 이런 성능 테스트가 도움이 되는지 등을 파악합니다.
  4. Configure the Test Environment.
    • 전략을 실행하기 위한 도구, 자원들을 준비하는 단계입니다.
    • 자원들이 어떤것들이 필요하고 누가 관리하는지 파악합니다.
  5. Identify and Coordinate Tasks.
    • 성과 목표가 무엇인지, 마지막 반복 이후 튜닝이 제대로 되었는지
    • 재검사의 가치가 있는지
    • 소요시간, 가능시간은 어떻게 되는지
  6. Execute Task(s).
    • 1 ~ 2일 단위로 작업을 수행합니다.
    • 테스트가 예상한 데이터를 제공하는지
    • 추가로 참여해야 되는 자원, 팀원은 어떤것이 있는지 판단합니다.
    • 알고리즘의 효율성, 자원 사용 경향, 데이터 수집 등을 알게 됩니다.
  7. Analyze Results and Report.
    • 테스트가 예상한 결과를 제공하는지
    • 그 데이터가 의미가 있는 데이터인지
    • 튜닝이 필요한지, 성능 목표를 달성했는지 판단합니다.
  8. Revisit Activities 1-3 and Consider Performance Acceptance Criteria.
    • 프로젝트 비전의 성과에 영향을 미쳤는지 판단합니다.
    • 우려되는 부분과 어떤 성능향상 활동이 있어야 하는지 판단합니다.
  9. Reprioritize Tasks.
    • 사이클의 성과 목표가 어떤것이 있는지 판단하고 우선순위를 재정의 한 뒤 5번 활동으로 돌아갑니다.



  • 챕터 4에서 나온 성능 테스팅 활동이 어떻게 매핑되는지 보여줍니다.

  • Chapter 6
    Agile 성능 테스트 관리 방법입니다. 총 9 가지 활동을 사용하여 나타낼 수 있습니다.



  • 챕터 4에서 나온 성능 테스팅 활동이 어떻게 매핑되는지 보여줍니다.
  1. Understand the Project Vision and Context
    • 위와 같이 이 단계에서 시스템에 대한 최초의 이해 비전을 이해합니다.
    • 고객의 기대, 예산, 직원 등을 이해합니다.
    • 시스템, 프로젝트 환경, 일정 등 전반적인 것을 이 단계에서 이해합니다.
  2. Identify Reasons for Testing Performance
    • 효율성, 알고리즘 판단
    • 성공 기준을 세운다.
  3. Identify the Value Performance Testing Adds to the Project
    • 1번, 2번 과정에서 얻은 정보를 기반으로 테스트 전략을 변경합니다.
    • 성능테스트의 이유, 외부리소스 파악, 완료, 합격 - 불합격 기준을 세웁니다.
  4. Configure the Test Environment
    • 테스트 환경구성
  5. Identify and Coordinate Tasks
    • 1~2일 마다 성능 테스팅 작업마다 성능 테스트 실행 계획을 세워야함
    • 작업을 어떻게 할지 , 어떤 데이터가 필요한지, 누가 도움을 주는지 등을 정합니다.
  6. Execute Task(s)
    • 1~2일 단위로 작업을 수행합니다. 결과를 즉시 분석하고 그에 따라 계획을 수정합니다.
    • 그리고 2일 이내로 성능 테스트 우선 순위를 재검토 합니다.
    • 전반적인 내용을 팀원들과 이야기 하고 의사소통 합니다.
  7. Analyze Results and Report
    • 결과를 분석하고 결정적이지 않은 경우 재시도를 해야합니다.
  8. Revisit Activities 1-3 and Consider Performance Acceptance Criteria
    • 결과를 바탕으로 새로운 정보와 함께 전략을 수정합니다.
  9. Reprioritize Tasks
    • 우선순위를 재정의 하고 5번 작업으로 다시 돌아가 수행합니다.
    • 스크럼을 통해 업무를 공유합니다.
  • Chapter 7
    CCMI 환경에서 성능 테스트 주기 관리하기
    CCMI(Capability Manuarity Model Integration)은 유연한 프로세스 패러다임의 일종입니다.


CCMI 성능 테스팅 방법입니다.

  1. Understand the Process and Compliance Criteria.
    • 프로세스가 어떤식으로 진행되고 성능테스트가 어떻게 진행되는지 결정
    • 규정 준수 기준 결정
  2. Understand the System and the Project Plan.
    • 프로젝트 세부사항을 이해
    • 프로젝트 계획을 검토합니다.
  3. Identify Performance Acceptance Criteria.
    • 성능 특성을 식별하는 단계입니다. 각각 특성을 검증하고 어떻게 기록할 지 파악합니다.
    • 성능 테스트이 목적을 파악합니다.
  4. Plan Performance-Testing Activities.
    • 프로젝트 계획에 작업 항목 매핑
    • 예상기간 파악
    • 우선순위 지정
    • 계획 상세정보 추가
  5. Design Tests.
    • 시나리오 식별(계약상 의무가 되는 사항, 일반적인 업무, 기술관련 등등..)
    • 주요 시나리오의 경로를 파악
    • 개별 사용자 데이터 및 분산 결정
    • 기간별 페이지 뷰
    • 사용자 세션
    • 세션기간
    • 상호작용 속도 등.. * 목표로드 식별
  6. Configure the Test Environment.
    • 테스트 환경 구성
  7. Implement the Test Design.
    • 디자인한 테스트 구현
  8. Execute Work Items.
    • 작업 수행
    • 결과를 기록하고 테스트 우선순위를 재검토 합니다.
  9. Report Results and Archive Data.
    • 결과를 통합하고 분석합니다.
    • 트랜드와 패턴을 알아내는데 시간이 많이 걸릴 수 있습니다.
  10. Modify the Plan and Gain Approval for Modifications.
    • 성능 테스트 계획을 검토하고 예외 사례등을 파악합니다.
  11. Return to Activity 5.
    • 계획이 업데이트 되면 다시 테스트를 디자인하는 5단계로 넘어감
  12. Prepare the Final Report.
    • 성능 테스트가 완료 된다면 보고서를 만듭니다.



  • CCMI 성능 테스팅 활동 Flow 입니다.



  • 챕터 4에서 나온 성능 테스팅 활동이 어떻게 매핑되는지 보여줍니다.

Part 3 를 읽고 테스트 환경에 대해 정리하시오. (Word 1 page 분량)

  • Chapter 8
    성능향상을 위한 시스템 evaluating하는 법
    1. 접근법
  • 시스템의 사용자 지향적 기능을 정의
  • 사용자가 시작하지 않은 프로세스, 기능을 정의
  • 실제 사용자 환경에 합리적인 아키텍처를 개발하는지
  • 예상 밖의 잠재적 유저들에 대한 합리적 이해를 하라


시스템의 기능, 비즈니스 프로세스, 요구사항 등과 주요 사용자들을 파악하고 그들의 기대, 경험 등을 수집합니다. 이런 것들을 기반으로 시스템을 결정하게 됩니다.

  • 시스템을 결정할때는 경쟁 업체를 분석하거나
  • 사용자를 유도한다면 모든 범주의 사용자를 고려하면서 결정해야합니다.
  1. 하드웨어와 소프트웨어 구조의 관계를 식별합니다.
  2. 계층 아키텍쳐(논리적 구조) * 관련 기능의 그룹으로 나타내는 것이 좋습니다.
  3. 물리적 아키텍쳐 * 실제 컴퓨터와 함께 표시되어 나타내짐

Part 4 를 읽고 성능테스트의 목적에 대해 정리하시오. (Word 2 page 분량)

  • Chapter 9
  • Chapter 10
  • Chapter 11

Part 5 를 읽고 테스트의 계획과 디자인에 대해 정리하시오.(Word 2 page 이상)

  • Chapter 12
  • Chapter 13

Part 6 을 읽고 테스트 실행에 대해 정리하시오.(Word 2 page 이상)

  • Chpater 14

Part 7 을 읽고 테스트 결과 분석에 대해 정리하시오.(Word 2 page 이상)

  • Chpater 15
  • Chpater 16

Part 8 을 읽고 Load 테스트와 Stress 테스트의 차이를 정리하시오. (Word 1 page)

  • Chpater 17
  • Chpater 18