똑똑한 웹사이트 성능 테스트. sitespeed.io


웹 사이트 성능을 테스트해주는 곳은 많다.
온라인에서 사이트 성능을 측정해주는 핑돔(http://tools.pingdom.com/fpt/) 같은 서비스도 있고,
크롬을 주로 쓰는 개발자라면 크롬 개발자 도구에 Pagespeed(https://developers.google.com/speed/pagespeed/)을 깔아 쓰는 방법도 있다.

sitespeed.io(http://www.sitespeed.io/)는 우연히 찾아낸 웹사이트 성능 테스트 도구인데,
이걸 보고 웃음이 절로 나왔다.
스머프처럼 랄랄라랄랄라 노래를 흥얼거리고 깡총 거리면서 걷게 되었다.

나를 기분 좋게 한 sitespeed.io의 특징

  • 여러 페이지를 한 번에 테스트할 수 있다.
  • 다양한 뷰포트를 지원한다.
  • 유저 에이전트를 직접 지정해도 된다.
  • 결과를 html 페이지로 깔끔하게 보여준다.
  • 덤으로 페이지별 스크린 샷도 찍어 준다.
'아! 정말 아름다운 테스트 도구다!'
라는 감탄이 절로 나왔다.
그러나 기대가 크면 좌절도 큰 법.
내가 원하는 용도로 쓰려면 기능이 부족했다.

아쉬운 점 두 가지.

  • RESTful 사이트를 지원하지 않는다.
  • 테스트에 쿠키 정보를 넘기지 못한다.
이 두 가지가 되지 않는다면, 이 도구는 내게 아무 쓸모가 없다.
보기만 좋지, 제대로 된 능력을 발휘하지 못하는 것이다.
마치 사막에 버려진 고래처럼...

다행인 점은 sitespeed.io(http://www.sitespeed.io/)가 오픈소스라는 점이다.
그래서 나는 이 녀석과 불금을 보내고, 주말까지 함께했다.
덕분에 RESTful테스트는 해결되었고, 쿠키부분은 몇 부분 더 손 봐야 하지만,
곧 두 가지를 보완한 정식 버전이 나올 예정이다.

혹시 정식 버전이 나오기 전에 써보고 싶다면 아래 두 저장소를 clone 받아 사용하면 된다.
* https://github.com/dorajistyle/yslow
* https://github.com/dorajistyle/sitespeed.io

yslow를 컴파일해서 sitespeed.io/dependencies/yslow-3.1.5-sitespeed.js로 붙여넣으면 테스트가 가능하다.

yslow 컴파일 방법

sudo make phantomjs

curl 쿠키 저장 (여기서 나오는 쿠키 정보를 텍스트로 넣어주면 된다.)

curl -c sitespeed.io/cookie -X POST -H "Content-Type:application/x-www-form-urlencoded;charset=UTF-8" -d 'loginEmail=admin@dorajistyle.pe.kr&loginPassword=password' http://dorajistyle.url/authentications

yslow 쿠키 테스트(yslow 폴더에서 실행)

phantomjs ./build/phantomjs/yslow.js --info basic --format plain 'http://dorajistyle.url/admin' -C '{"name":"session","value":"sessionvaluestring","domain":"localhost"}'

screenshot 쿠키 테스트 (sitespeed-result 폴더에 저장됨)

phantomjs --ignore-ssl-errors=yes sitespeed.io/dependencies/screenshot.js 'http://localhost/#!test/page' sitespeed.io/sitespeed-result/screenshots/screenshot.png 1280 800 'Mozilla/5.0 (Macintosh; Intel Mac OS X 1084) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36' true '{"name":"session","value":"sessionvaluestring","domain":"localhost"}'

로그를 포함한 sitespeed.io 쿠키 테스트 (sitespeed.io 폴더에서 실행)

sh -x ./bin/sitespeed.io -f batchlist -k true -p 10 -C '{"name":"session","value":"sessionvalue_string","domain":"localhost"}'



by


Tags : , , , , ,

  • 재미있게 읽으셨나요?
    방랑자의 이야기.
    월풍도원에선 기부를 받습니다.

서버에 부하가 얼마나 걸리나? Jmeter Http 부하(Load) 테스트.



여러 테스트 도구 중 Apache Jmeter를 선택한 이유.

  • 오픈소스.
  • 간편함.
  • 결과를 직관적으로 보여줌.
  • 사용자가 많음.
  • 문서 잘 된 편임.

Jmeter Http 부하 테스트 작성 순서

  1. Jmeter를 내려받는다. (http://jmeter.apache.org/download_jmeter.cgi)
  2. 압축을 풀고 Jmeter를 실행한다.
  3. Test Plan에 자식 노드 Thread Group를 추가한다.
  4. Therad Grup에서 Properties에 원하는 값을 넣어준다.
    Number of Thread는 테스트할 사용자의 수이고,
    Ramp-Up Period는 테스트를 몇 초에 걸쳐서 실행할 것인지 기간을 말한다.
    만약 Number of Thread가 10이고, Ramp-Up Period가 100이라면 각각의 Thread가 10초마다(100/10) 시작된다.
    하나의 Thread가 실행되고 10초의 여유 시간을 가지고 다음 Thread를 실행하는 것이다.
    Loop count에는 이 Thread를 몇 번 반복할지 적어준다.
  5. *만약 요청(Request)에 헤더 값을 설정해 줘야 한다면, Thread Group에 자식노드 HTTP Header Manager를 추가한다.
    Name과 Value값을 넣어주면 설정이 완료된다.
    예를 들자면 Name란에 Content-Type, Value란에 application/json을 적어주면 Content-Type이 application/json으로 설정된다.
  6. Thread Group에 자식 노드 HTTP Request를 추가한다.
  7. HTTP Request의 Web Server 란에 서버 이름(혹은 IP)와 포트 번호를 설정 한다.
  8. HTTP Request의 Path에 요청을 보낼 경로를 적어준다. (예: /about/company.html)
  9. HTTP Request의 Method를 Get으로 설정한다.
  10. HTTP Request에 자식 노드 Listener를 추가한다.
    여러 종류의 Listener가 있는데, View Results Tree는 각각의 요청에 대한 응답 결과를 보여주고,
    Summary Report는 종합적인 테스트 결과를 테이블로 보여준다.
    그리고 Spline Visualizer는 종합 결과를 그래프로 보여준다.
  11. *만약 여러 Thread Group에 대한 종합 결과를 보고 싶다면, Test Plan에 자식 노드로 Listener를 추가하면 된다.

아래는 예시를 위해 Jmeter로 테스트한 Spline Visualizer 결과값이다.

Flask 개발용 서버-'Jmeter로 Http 부하 테스트하기'
Flask 개발용(dev) 서버.

twisted-'Jmeter로 Http 부하 테스트하기'
twisted

twisted + Nginx -'Jmeter로 Http 부하 테스트하기'
twisted + Nginx

gunicorn + Nginx -'Jmeter로 Http 부하 테스트하기'
gunicorn + Nginx

각 테스트의 Summary Report를 정리한 표.-'Jmeter로 Http 부하 테스트하기'
각 테스트의 Summary Report를 정리한 표.

배포하기 전에 어떤 조합 성능이 좋을지 궁금하다면,
Jmeter를 이용해 각각 환경을 간단히 시험해 보면 좋다.

참고 자료



by


Tags : , , , , ,

  • 재미있게 읽으셨나요?
    방랑자의 이야기.
    월풍도원에선 기부를 받습니다.

소프트웨어 품질보증,소프트웨어 테스팅 (SQA - Software Quality Assurance & SW Testing) [소프트웨어공학,소프트웨어 품질보증,소프트웨어 테스팅,SQA,software quality assurance,software testing)

이미지출처 : www.secc.org.eg

소프트웨어 품질보증과 테스팅 (SQA - Software Quality Assurance & SW Testing)











Quality

- Small ‘q‘: 제품의 품질

- Big ‘Q : 제품을 개발하는 절차, 고객의 만족도 등을 고려한 품질

- 향상방법3가지


  # 사람에 투자

  # 프로세스에 투자 (효율이 좋다)
# 도구나 기법에 투자
- Software Engineering 에서 말하는 품질을 확보하기 위한 수단
# 소프트웨어 형상관리(SCM)
# 프로젝트 관리(PM)
# 데이터 관리(SQE)
- 관리 계획
1. 목적 & 범위
2. 프로젝트 내에서의 SQA 활동 계획
3. 양적 절차관리에 대한 계획
4. 결함방지를 위한 계획
소프트웨어 공학의 목적 - 많은 사람들이 함께 개발을
할 때 더욱 큰 효과를 내기 위함
구현 -> 설계 -> 분석 -> 테스팅 -> 유지보수 · 재사용성 (생산성, 품질)

효율적인 설계, 분석


-
일반성(Generality)과 향상성(Incrementality)고려 필요

- ‘무엇에 중점을 둘 것인가’ 고려 필요(Ex.Risk, Bussiness Value)

# Liner ->Incremental

# Rigid ->Flexible

# Monolitic-> Interactive



CMMI






















1. INITIAL(실행)


 


2. REPEATABLE(관리)

– 반복 가능


기본적인 프로젝트 관리


3. DEFINED(정의)


프로세스 표준화


4. MANAGED – 개량화 가능


정량적인 관리(수치화 시킴)


5. OPTIMIZING(5) 지속적인 프로세스

개선


체계적인 계획으로 overhead를 처리해야 한다.


 

유지보수 활동

- 수정되는 것(Corrective) : 20%

- 환경의 변화에 맞추는 것 (Adaptive) : 20%

- 잘 돌아가는 것을 더 완벽하게 만드는 것 (Perfective): 80%



프로세스 적용 시 성공 사례를 가지고 유연하게 적용해야 한다.

- 조직에 맞는지 검토 후 적용 가능성을 탐색

- Risk를 가지고 단계적으로 완화시키는 활동을 해야 한다.

 

Inspection

정의

- ‘무엇을개선할 수 있는가’를 찾는 활동 (WHAT)

- 사람에 대한 평가가 아니라 조직관점의 성능을 평가하는 것

- 조직의 문화를 바꾸는 것!

- 모호한 것을 명확하게 함

특징 & 방법

- 결함 발견 및 데이터 수집

- 산출물에 대한 전문지식 교환

- 해결안 지양(결함을 찾는데 주력)

-&Defect를 빨리 찾을수록 fix 비용

소요 감소

- Inspection의 데이터를 통해 업무에 집중 가능

- 테스팅은 결함의 존재 여부만 식별하는데 반해, 결함의 내용과 위치를 식별

- 코드 인스펙션은 컴파일이 문제없이 되었을 때

- 사전 준비를 철저히 하고 회의 시작

- 2시간이 넘지 않게 함

- 데이터를 수집하여 차후 inspection시history로 참고

# 데이터의 오염 (정보의 조작이 일어날 수 있다.)
팀 크기
- 인원은 3~7명이 좋다. (4명적절)
- Code Inspection시Producer를 제외한 2명의 Inspector가적절
-&Document Inspection시 2명보다많은 Inspector가 요구됨.
- Moderator는 Reader또는 Recoder를 겸임 할 수 있음.
단계
- Planning


# 역할 선정

# 일정 잡음, inspection 그룹만 참여하도록


# 일정에 Inspection 일정 계획을 task마다

추가.

# Code Inspection


  ## Unit Test 이전에 실시

- Overview

  # 검토 대상 산출물에 대한 설명


  # 산출물의 이전버전에 대한 Inspection이 실시된 적이 없는 경우

# 한명의 Engineer가 산출물을 작성한 경우

  # 새로운 기술이 도입되거나, 복잡도가 높은 경우
- Preparation


  # Checklist, Rule Set(코딩 규칙등)과 같은 도구를 사용해

대상 산출물의 완전성과 시정대상 여부 및 적절성을 판단

  # 이 과정을 거치지 않는다면 Walkthrough.


  # 일반적인 규칙에 어긋나는 것들(타이핑 에러, 스펠링 틀림, 포멧이상 등)은 Typo list로 제공

  # Reader와 Recorder에게 매우 중요한 단계


  # 미팅의 2.6배정도 시간이 소요

  # Defect를 많이 발견하기 위해 여러 번 검토 하는

것이 좋다.

- Meeting


  # 정리하는 시간.

  # Inspection Summary Report 작성
- Rework


  # 각종 보고서를 가지고 최종 산출물 작성

  # 시간의 제약을 두어야 함

- Follow-up


  # 프로세스 수행이 적절히 이루어 졌는지 검증하는 단계

- Causal Analysis


  # Process Brainstorming 단계





역할

- Reader(Presenter) : 산출물에 대해서

설명하는 역할

- Recorder : Defect, 이슈 및 기타 내용을 기록하는 역할을 수행함


- Verifier : 최종확인 작업

- Producer : 산출물 작성자
- Moderator : Inspection 총괄
성공적인
Inspection 을 위해

- 관리자들에게 약속을 받음
- 데이터 수집 및 분석
# 알맞은 수집 양식을
작성 하는 것이 중요


- 훈련



Inspection
Metric


- Defect.Density : 산출물의 품질을 평가함.

[Defects.Found.Total /Size.Actual]  Inspection 대상 산출물의 단위당 발견된 Defect수
- Defect.Corrected.Total : Defect당 평균 Rework Effort를 계산


[Defect.Corrected.Major + Defects.Corrected.Minor] Correct된 (Major+Minor) Defect

- Defect.Found.Total : Inspection의 효과성(Effectiveness)과 효율성(Efficiency)을 평가

[Defects.Found.Major + Defects.Found.Minor] 발견된
(Major+Minor) Defect


- Effort.Inspection : 근무 시간 또는 금액으로 Inspection의

전체 비용을 계산함.

[Effort.Planning + Effort.Overview + Effort.Preparation + Effort.Meeting +
Effort.Rework] Inspection을 수행하는데 투입된 Effort 합계
- Effort.per.Defect : 프러덕트 Life-Cycle의
Inspection 이후 단계에서 발견되는 Defect의 처리 비용과, Inspection에서 발견된 Defect의 비용을 비교함.


[(Effort.Planning + Effort.Overview + Effort.Preparation + Effort.Meeting)/Defects.Found.Total]

Defect를 발견하는데 투입된 전체 근무 시간의 평균

- Effort.per.Unit.Size

: 프로젝트에서 발생하는 산출물들을 Inspection하는데 소요되는 비용을 견적

[Effort.Inspection / Size.Actual] Inspection 산출물의 기본 단위당 투입된 시간의 평균값
- Percent.Inspected : Inspection Planning의 정확도를 평가


[100*Size.Actual / Size.Planned ] 실제로 Inspection을

수행한 산출물에 대한 계획 대비 비율

- Percent.Majors : Inspection의 초점이 Major Defect인지 Minor Defect 인지 판단

[100 * Defects.Found.Major / Defects.Found.Total] 전체
Defect중에서 Major Defect의 비율
- Rate.Inspection : 향후의 Inspection Effort를 계획하는데 사용
[Size.Actual / Time.Meeting] Inspection
Meeting 시간당 수행된 산출물의 평균 분량
- Rate.Preparation : 향후의 Inspection Effort를 계획하는데 사용


[Size.Planned / (Effort.Preparation / Number.of.Inspectors)] Inspector들이 Preparation의 단위 시간당 처리한 산출물의 평균 분량

- Rework.per.Defect : Inspection의 Benefit을 판단하기 위해, 프러덕트 Life-Cycle의

Inspection이후 단계에서 발견된 Defect를 처리하는데 소요되는 비용과 비교


[Effort.Rework / Defects.Corrected.Total] 1개의 Defect를

처리하고 검증하는데 필요한 시간의 평균값



결함 발견하는데 소요 시간

- 테스팅 : 4 hours / fault

- 인스펙션 : 1 hour / fault



Peer Review의 3대

장벽


지식(Knowledge), 변화 거부 (Resistance to Change), 조직 문화 (Culture)



Testing

제한된 테스트 케이스를 가지고, 신뢰성을 높인다.(테스트는 100% 될 수 없다.)

- Error : 사람이 한 실수

- Fault : Error로 인해 발생된 문제점

Correct -> Reliable -> Safe -> Robust

 

Test Planning

- ‘무엇을 테스트 할 것인가’(WHAT)



- ‘테스트를 어떻게 할 것인가’(HOW)



- 설계, 개발 단계에서 진행하는 것이다.



Testing Techniques

Structural (Whitebox)

Test
– 코드를 보는 테스트

Coverage
- Statement Coverage : 모든 라인을 거쳐 가는지 확인
- Path Coverage : 가능한 모든 길을 확인
- Branch Coverage : 조건문의 양쪽 가지를 다 통과하는지 확인
- Condition Coverage : 조건이 True일 때 , False일 때를 모두 확인

Functional(Blackbox) Test
- 문서(코드 이외에 알 수 있는 모든 정보들) 위주의 테스트
- Equivalence Partitioning : 비슷한 그룹으로 나눔
- Boundary Value Coverage : 경계를 기준으로 확인


  # 경계 -> 경계안 -> 경계밖 -> 중간 -> 겹치는 경계

- Special value
Coverage : 알려진 값을 기준으로 확인

Testing Phases
Unit Testing – 모듈 중심

Integration Testing – 인터페이스 중심

System Testing –환경 고려

Regression Testing – 버전 변경 시 바뀐 부분이 제대로 바뀌었는지 확인을 위해

Non-Functional Testing도 고려해야 한다.



대량의 데이터를 처리할 때 유용한 툴

- 정규 표현식(Regular Expression)

- Flex (The Fast Lexical Analyzer)

 

TimeTracker

- 실제 일하는 시간을 체크하여 업무 효율을 증가 시킬 수 있다.

 

도표

Control Chart – Control 영역을 설정하여, 품질을 관리 할 수 있다.

Pareto Chart – 가장 높은 Bar가 전체적 문제 해결을 위해 가정 공헌도가 큼을 의미


Run Chart – 시간의 순서에 따라서 데이터의 변동 상태를 보여준다.

Scatter Diagram – 상관관계를 볼 때 사용

 

용어정리

80-20 Rule - 20%의 부분에서 80%의 문제가 발생한다

Heuristics – 경험적 지식

GQM(Goal, Question& Answer, Metrics)

- Goal을 달성하기 위한 질문과 답변을 통하여 기준이 되는 데이터를 찾는 것

FAULT 

- ERROR(Review 시점에 발견한 것) + DEFECT(Review시점 이후에 발견한것)

PMO(Project Management Office) – Project의

전체적인 일정을 수립하고, 지켜가야 할 원칙을 설정하고,

Project 성공을 위한 수행전략을 수립하고, 전체적인 예산과 인력을 관리

SQA(Software Quality Assurance) – 세팅된 프로세스를 가지고, 잘 따라가고 있는가를 관찰하는 그룹 [감사]

EPG(Engineering Process Group) – 조직의 프로세스의 개선을 위한 그룹 [재정]

COQ(Cost Of Quality) - Review, Rework, Etc / Total Effort

COPQ(Cost Of Poor Quality) - Rework / Total Effort


QPM – Process Control + Process Improvement : Use Statistical techniques

      =>

Stable Process + Capable Process

LOC(Line Of Code)

ReqB(Requirement Book)

SPMP(Software Project Management Plan)

SCMP(Software Configuration Management Plan)

SQMP(Software Quality Assurance Plan)

CMMI(Capability Maturity Model Integration)

 

Reference

Peer Reviews in Software, Karl

E.Wiegers,  Addison-Wesley

Computer based software inspection

 


———————————————————————

4일간의 Software Quality Assurance & SW Testing 교육

재미있는 이야기가 많았다.



by


Tags : , , , , , , ,

  • 재미있게 읽으셨나요?
    방랑자의 이야기.
    월풍도원에선 기부를 받습니다.