"자바 개발자도 쉽고 즐겁게 배우는 테스팅 이야기" 책에 있는 Ant 부분의 샘플을 올립니다.

만약 책에 있는 다른 샘플들도 필요하신 부분이 있다면, 
언제든지 GuestBook이나 필자의 메일로 말씀하시면
관련 부분을 올려드리도록 하겠습니다.


Posted by tuning-java
,
블로그에 이렇게 길게 제목을 지어도 되는구나...

아는 분들은 아시겠지만, 내가 좀 집요(?)한 편이다.

다른 분들은 책을 낸 다음에 어떻게 하는지 모르겠지만,
나는 모든 포인트를 관리하는 인터넷 서점의 포인트를 정리한다.
(책이 나온지 한달, 혹은 두달 정도의 기간동안...)

출판사에 요청하면 일별 판매량 추이를 볼 수 있고,
출판사 담당자에게 물어보면, 누적 판매치를 알 수도 있지만,
내가 직접 관리하는 재미가 있다. ^^;

아래 그래프는 Yes24의 포인트 추이다.

이벤트를 걸어서 이러한 그래프가 겨우 그려진 것으로 생각하고 있다.

그래도, 튜닝책이 한달에 팔린 양보다 70%에 달하는 양이 팔렸으면 어느 정도 선방한거 아닌가? 라는 개인적인 생각이다.

왜냐면 아무도 안팔릴 거라고한 테스트 책이기 때문에.
튜닝책도 마찬가지로 몇명빼고는 안살꺼라고 했지만...




Posted by tuning-java
,
이번에 나온 테스트 책과 관련된 이벤트가 진행됩니다.

아이팟 타치는 제 사비를 털어서 제공해 드리는 것이고,
제가 직접 주문하여 보내드릴 예정입니다.

보통 이런 이벤트하면 약간 내부의 조작이 있다고 생각할 수도 있지만,
그러한 문제를 없애기 위해서 만약 제가 잘 아는 분이 당첨되면,
그 다음 대상분에게 드릴겁니다. ㅎㅎㅎ

단 Yes24 로 구매하실 경우에 한해서입니다.
(왜냐면 제가 다니는 회사에서 매달 Yes24 상품권을 제공해 주기 때~문에~~)

실제 링크도 이제 걸렸네요.




Posted by tuning-java
,
자바 개발자도 쉽고 즐겁게 배우는 테스팅 이야기
의 별책 부록입니다.

지면상의 이유로 책 안에 모든 내용을 넣지 못한점 죄송스럽게 생각합니다.

별책 부록으로나마 미리 만나보세요.

다음주 금요일 정도면 전국에 책이 나갈겁니다. ^^;
아래 링크의 파일을 다운로드 하시면 됩니다. ^^;

이 파일에 있는 내용은 다음과 같습니다.
- 완전 초보 개발자를 위한 자바와 이클립스 설치 및 사용법
- Ant 설치 및 사용법
- Subversion 설치 및 사용법
- Internet Explorer Developer Toolbar설치 및 사용법
- Firebug 설치 및 사용법
입니다.

 
혹시나 해서 말씀드리지만,
이 파일에 대한 저작권은 저와 한빛 미디어에 있으니,
마음대로 퍼 가시는 것은 어쩔 수 없으나,
마음대로 게시하는 것은 법적으로 문제가 됩니다.

그리고, 책에 있는 제 이메일 주소는 잘못되었습니다.
제 이메일은 "javatuning 앳 지메일 닷 컴" 입니다. 
문의사항은 이 주소로 보내주세요.
책에 있는 이메일은 존재할 수 없는 주소랍니다. - -;
 
Posted by tuning-java
,
사용자 삽입 이미지


자바 개발자도 쉽고 즐겁게 배우는 테스팅 이야기
라는 책이 드디어 출간된다.
(나는 끝까지 "테스트 이야기"로 하고 싶었는데, 출판사에서는 끝까지
테스팅으로 밀고 있다. 왜 그런지는 좀더 이야기 해 봐야 겠지만...)

1년 2개월 동안(실제 쓴 기간은 그렇지 않지만... 여하튼...) 쓴 책이고,
개발자들이 재미없는 테스트에 보다 쉽게 접근할 수 있도록 쓴 책이다.
물론 고수분들은 이책을 살 필요 없다.
다 아는 내용일 것이기 때문에...

페이지 수가 400 페이지가 넘어서,
여러 고민을 하다가,
부록의 일 부분을 전자 문서(아마도 PDF)로 제공하기로 결정했다.
어느정도 페이지가 넘어가면, 출판사 손익 분기점이 높아져서,
책값이 올라가거나 다른 방법을 찾아야 한단다.
책값이 올라가면, 많은 독자들이 볼 기회를 놓칠 수도 있기 때문에,
이와 같이 부록을 별도로 빼기로 결정했다.
책 내에는 별책 부록이라고 표시될 것이다.

책 제목이 긴 이유는 출판사의 정책 때문이다.
(내가 긴 제목을 좋아 하는 것도 아니고, 누군가를 낚기 위한 것도 아니다.
분명 이책 보고도 낚였다는 사람이 있겠지 ? - -)



그리고

미리 이야기하지만,
책의 목차를 보면 알겠지만, 다루는 항목이 너무 많기 때문에,
깊이가 얕다고 실망하는 분들이 분명 있을 것이다.
사고 나서 낚였다고 "파닥 파닥"거리지 마시고,
본인이 알고자 하는 내용에 부합되는지 미리 확인하고 사시기 바란다.
일 예를 들어 JUnit 에 대해서만 다뤄도 JUnit in action과 같이 책 한권의 분량이고,
FitNess도 그렇고, CI 도 마찬가지다.
테스트에 대한 전반적인 흐름이 어떻게 되고,
어떤 툴들이 있구나 라는 정도의 지식을 전달하기 위해서 쓴 글이지,
바이블을 맹글기 위해서 쓴 글이 아니다.(바이블은 나중에 시간 나면...)



목차는 다음과 같은데,
실제 출간되는 책과 상이할 수도 있다.


A. 테스트 기본
1.테스트 전문가란 사람들이 항상 이야기하는 기본 내용들
- 테스트의 단계는 어떻게 되나?
- 기능적 테스트와 비 기능적 테스트는 또 뭐야 ?
- V-Model. 많이 들어는 봤는데 그게 뭐야 ?

2.또 재미 없는 테스트 이야기
- 정적 테스트의 종류에는 어떤 것들이 있을까?
- 일반적인 리뷰 프로세스를 알아보자.
- 동적으로 하는 테스트에는 이런 것들이 있다.
- 까만 상자 테스트와 하얀상자 테스트의 의미
- 회귀 테스트와 확정 테스트는 왜하는 거지?
- 테스트 케이스와 테스트 스윗의 차이는 뭘까 ?

3.테스트 그냥 하면 되지 뭘 분석해?
- 테스트 입력값 분석하기
- 입력값이 복잡할 때 제대로 분석하자.
- 상태가 바뀔때는 이렇게 한다.

B.단위 테스트 쉽게 해보기
1.JUnit. 이름은 많이 들어 봤는데
- xUnit 이란 ?
- JUnit 다운로드 및 설치하기
- 먼저 JUnit 3.x에 대해서 간단하게 알아보자
- JUnit 4.x는 뭐가 다른데?
- Stub만 있는게 아니었구나
- Mockito의 간단한 사용법
- Mockito는 이렇게 응용하여 사용할 수 있다.

2.TDD가 뭐야 ?
- TDD가 뭘까?
- 그럼 도대체 왜 TDD를 해야 하는겨?
- 말하는 만큼 TDD는 적용하기 쉬울까?
- 근데 도대체 리펙토링은 뭔데 ?

3.웹 UI도 자동화 테스트가 가능하구나~~~
- 웹 UI 테스트 툴도 있구나.
- Selenium 이 뭐지?
- Selenium IDE 사용법을 알아보자.
- Selenium IDE 를 이용하여 간단한 사이트의 스크립트를 작성 해보자.
- 이번에는 약간 복잡한 사이트를 테스트 해보자.
- Selenium Remote Control 사용법도 알아보자.

4.웹 URL 요청을 자동화 해서 테스트 해보자.
- HttpUnit 이란?
- HttpUnit은 어떻게 동작하나?
- 아주 간단한 사이트를 HttpUnit으로 테스트해 보자.
- 우리가 테스트하려는 사이트를 HttpUnit로 요청해보자.
- 자동 로그인 테스트를 해보자.
- JUnitPerf 라는 것도 있단다.

C.정적인 테스트하기
1.이것도 테스트구나
- 리뷰란 ?
- 그렇다면 개발자가 할 수 있는 리뷰는?
- 코드 리뷰를 자동으로 해주는 착한 툴들

2.정적 테스트 툴 살펴보기
- 정적 테스트 툴을 이클립스에서 사용할 수 있다고?
- Find Bugs에서 제공하는 결과 확인하기
- PMD에서 제공하는 결과 확인하기
- PMD 리포트 작성하기
- Find Bugs UI는 정말 사용하기 쉽다.
- PMD 규칙 관리하기
- 나만의 PMD와 Find Bugs 규칙 추가하는 방법 링크

D.통합 테스트도 쉽게 해보기
1.통합 테스트도 자동화 할수 있어 ?
- Continuous Integration
- 통합 빌드의 수행 절차
- 통합 빌드의 부품들
- 통합 빌스시 유의 사항들
- 그럼 통합 빌드 툴에는 어떤 것들이 있을 까?
2.허드슨에 대해서 알아보자.
- 허드슨에 대해서
- 첫 빌드 프로젝트 만들어 보기
- 효과적으로 허드슨을 사용하기 위한 환경 확장하기
- 본격적인 빌드 작업 수행하기

E.성능 테스트는 이렇게
1.성능 테스트가 뭐 하는 거야 ?
- 성능 테스트를 왜 하는거야?
- Transaction 에도 종류가 있다고?
- TPS 라는게 도대체 뭐야?
- 응답 시간은 이렇게 나눌 수 있다.
- 응답시간이 젤 중요한거 아니야 ?
- TPS와 응답시간의 관계는 있을까?
2.성능 테스트 한번 해 볼까 ?
- 성능 테스트의 종류에는 이런 것들이 있다.
- 성능 테스트에서의 시간은 이렇게 구분한다.
- 어떤 게 동시 사용자야 ? - 성능 테스트 대상 식별하기
- 스크립트란 ? - 성능 테스트시에 고려해야 하는 사항들

3.JMeter 가 도대체 뭐야
- 무료 성능 테스트 툴에는 어떤 것들이 있을까?
- JMeter 테스트 준비 Step - 1 스크립트 레코딩하기 Part-1
- JMeter 테스트 준비 Step - 1 스크립트 레코딩하기 Part-2
- JMeter 테스트 준비 Step - 1 스크립트 레코딩하기 Part-3
- JMeter 테스트 준비 Step - 2 결과 검증하기
- JMeter 테스트 준비 Step - 3 데이터 준비하기
- JMeter로 성능 테스트를 수행해보자.
- 성능 테스트를 할 때 모니터링 해야 하는 것들

4.결과는 어떻게 분석하라고 ???
- 응답시간 분석 및 정리하기
- TPS 분석 및 정리하기
- CPU 사용량 분석 및 정리하기
- 보고서에 반드시 들어가야 하는 기본 내용들은 ?

F.보안 테스트도 어려운 것만이 아니네
1. 보안이 그렇게 중요한가?
- 보안이라고 하면 도대체 어떤걸 이야기 하는 거야?
- 웹 애플리케이션의 취약점에는 이런 것들이 있다.
- 웹 애플리케이션 보안 체크 리스트 Top 10
- 보안 테스트 툴에는 어떤 것들이 있을까?

2. 보안 테스트의 기초만 알아보자.
- 보안 테스트란?
- 보안 테스트를 하기 위해서는 데이터 암호화에 대한 지식은 필수다.
- Burp Suite를 이용한 요청 데이터 변환하기
- WebGoat를 이용한 보안 테스트하기

G.프로젝트를 마무리 하는 테스트는 이런 것이 있구나
1. 시스템의 오픈 여부를 결정하는 출하검사와 인수 테스트
- 경험에 의한 테스트 방법들
- 출하검사란?
- 결함율과 출하검사 유의사항
- 그렇다면 인수 테스트는 어떻게 해야 하는 거지?

2. 인수 테스트를 위한 FIT과 FitNesse.
-FitNesse가 뭐 하는 거야 ?
-FitNesse 설치하기
-먼저 FitNesse에 적응해보자.
-첫 테스트를 수행해보자.
-FitNesse 화면을 묶어서 Suite로 테스트하자.
-FitNesse의 기본 Fixture들을 이해하자.
Posted by tuning-java
,
https://www.ibm.com/developerworks/kr/views/java/libraryview.jsp?type_by=기술자료&view_by=Search&search_by=사람을+위한+자동화&S_TACT=105AGX55&S_CMP=EDU

책 쓰면서 알게된 사람을 위한 자동화 시리즈.
지금이라도 알게되어서 다행이다.

지속적인 통합이나 테스트에 대하여  관심있는 분이라면 꼭한번 읽어봐야하는 주옥같은 자동화에 대한 내용들이다.
Posted by tuning-java
,
http://www.rbcs-us.com/UserFiles/File/Articles/Test%20Driven%20Development.pdf

Test 교육을 받은 이후부터 RBCS 뉴스레터가 메일로 오는데,
TDD에 대한 좋은 글이 있어 링크를 올린다.

항상 이야기하지만, 이런 글의 단점은 영어라는거 ~~~.
(근데 문장이 그리 읽기 어려운 내용은 아니랍니다. ^^)

혹시나 해서, TDD가 뭐가 뭔지 잘 모르시는 분들을 위해서...
TDD란 코드를 만들고 테스트를 하는게 아니라,
테스트 코드를 먼저 맹글고, 운영될 코드를 만드는 개발 방식의 하나입니다.
(자세한건 현재 쓰고 있는 Blog2Book 테스트 책에 설명해 놓겠습니다. ^^)

Posted by tuning-java
,

이 글은 성능테스트를 로드런너를 하는 분이 이해를 하실 수 있는 내용이므로,
관련없는 분들은 바로 패쓰 하시기 바랍니다. ^^;

성능 테스트를 수행할때 반드시 해야하는 작업이 있다.

바로 오류 체크 로직을 넣는 작업이다.

 추가로 
lr_get_transaction_duration("트랜젝션이름")
함수를 사용하면 해당 트랜잭션의 응답속도를 얻을 수 있으며,
이 값이 허용치 이상일 경우 ERROR로 처리할 수도 있다.  

Posted by tuning-java
,
2주동안 열나 고생항 워크샵이 끝났다.

영어로 작성해야 하는 문서들과 프리젠테이션... 정말 지겨웠다.

그래도 어학연수 갔다온 덕은 톡톡히 본것 같다.

점심마다 Rex Black 아저씨를 챙겨주는게 쉽진 않았지만,
뭐 영어 학원 다닌다는 느낌으로 1주일간 점심을 먹은거 같다. ㅋㅋ

렉스 아저씨에 대한 느낌을 간단히 적어보면...
농담도 많이하고,
키도 크고, (197 ...)
절대 이기려고 하면 안되는... 특히 이론적인 부분을 이야기 할 경우에느...
모든 것을 그냥 넘어가면 안되고, 반드시 근거를 대야 하는,
그리고 열나 바쁜 아저씨다.

쌓이 메일이 150통이라서 커피 마실 시간도 없단다.
(내 gmail에 쌓이는 spam보다 많다. - -);

여하튼 좋은 기회였다.

이제 남은건 다음주 월요일 저녁에 보는 시험을 패스하는 것 !!!
(걱정이다~~~)

Posted by tuning-java
,

출처
http://www.theserverside.com/tt/articles/article.tss?l=PerformanceEngineering

Performance Engineering - a Practitioner's Approach to Performance Testing

나중에 심심할때 함 읽어봐야 겠다.


Context/Introduction

"The application is horribly slow.", "I don't get the response even after I get my coffee.", "This application is useless". Sounds familiar? How many times have we heard these quotes or or felt like that ourselves? The common thread between these statements is that the performance of the application is not good.

Performance - the (in)famous buzzword. What is it? What does it mean? In this article, we'll touch upon what is involved in testing an application for performance.

With every passing day, organizations are becoming more and more conscious about the performance of their Enterprise Solutions. As the IT industry matures and the technology evolves, so does the awareness about expectations from an Enterprise Application.

Focusing just on the design / implementation and Zero-functional-defect solutions are things of the past. With increasing maturity in technology and IT staff, the 'Non-functional' aspects of the system are fast becoming focus-areas.

So what exactly are the non-functional aspects and/or requirements?

Non-functional requirements (NFRs) tell the IT team, about the kinds of usage and load the application will be subjected to, and the expected response time. We'll go into the details of this "response time" shortly.

NFRs define the Service Level Agreements (SLAs) for the system and hence the overall Performance of the Enterprise Application. Besides performance SLAs, NFRs also cover several other aspects, such as security, but for this article we are concerned with performance related objectives only.

Managing and ensuring the NFRs (SLAs) for an Enterprise Application is called Performance Engineering. Performance engineering is a vast discipline in itself which includes Performance Modeling, Performance Prototyping, Performance Testing, different types of analyses, Performance Tuning, etc. This article will not explain Performance Engineering, Queuing Theory and the science behind the various laws. This article just covers the basics about the Performance Engineering and key activities in Performance Testing.

How to describe Performance of a 'System'

The performance of any system can be expressed in many ways by different stakeholders of the system. For example, When a business analyst gives performance (or non-functional) requirements, it might be in some format as follows:

  1. "there will be at least 100 users on the system all the time",
  2. "System should respond back in 'acceptable time'".

These statements have to be translated to somewhat more technical terms as described below. Once we understand these terms, we'll reword these Performance requirements.

To define the performance of any System (Software/hardware/abstract) following technical parameters should always be used in conjunction -

  • Response Time: Response time specifies the time taken by the system to respond back with the expected output. For an enterprise application Response time is defined as the time taken to complete a single business transaction. It is usually expressed in seconds.
  • Throughput: Throughput refers to the rate which the system churns expected outputs when the designated input is fed in the system. In other words, for an Enterprise Application, throughput can be defined as the total number of business transactions completed by the application in unit time (per second or per hour).

Usually, per second or per hour is the standard, since per day (or per diem) is a very wide unit. Most business users utilize an Application during typical 8 hour business window. Normally there are some peaks & some troughs in the input, so the volumes per day should not be averaged to an hour. All the mathematical distributions (normal, Poisson, uniform) come handy over here.

  • Resource Utilization: For any system to consume an input and produce the designated output, certain resources would be required. The amount of resources consumed by the system during processing that request, defines the resource utilization. There can be different resources factored in, such as processor, disk (i/o controller), memory etc. Utilization of 80% is considered an acceptable limit. Normally utilization of 70% warrants ordering of additional hardware.

Now that we know basic technical terms for expressing performance facts about a system, we'll try to rephrase the above Performance Requirements.

  1. We should ask the question whether all the users would be carrying out a transaction simultaneously or they would be just logged on. The answer of this question would lead us to the throughput expectations. In case of pre-existing applications (or using applications having similar profile), we can also arrive at the transactions/sec or throughput requirements from logs files (e.g., HTTP logs of web-applications.)
  2. The vagueness of "acceptable" times needs to be removed by defining the response time requirements clearly, e.g. 2 seconds, 2 hours or 2 days.

Let's begin then...

Performance test planning

He who fails to plan, plans to fail

As in all aspects of life, planning is very important in Performance Testing. We present the simplistic approach to planning a Performance testing exercise in the sub-sections below.

How to represent the SLAs? - Workload model/distribution/pattern

The first step of any IT project is usually requirements gathering. Similarly, for any performance testing project, its very important to gather the SLAs / NFR of the system against which the tests will designed and executed.

Performance testing depends as much on how well the SLAs are gathered as much as on how well they are represented. A well represented non-functional requirement can help a long way in the rest of the planning and analysis activities.

The various throughput rates, load figures, list of transactions, types of transactions, response times and projected growth in coming years are captured in a document called the Workload. Workload captures the load pattern, load distribution, transaction distribution, peak windows etc.

The workload should be thoroughly reviewed by the various stakeholders of the system, like, architects, business users, analysts, designers and performance engineers.

What to test? - Identifying Transactions

Once the Workload model has been prepared and reviewed thoroughly, the next step is to Identify candidate transactions. If we select too few transactions, the system might contain a serious SLA mismatch and if we select all the transactions, we might be heading towards a never ending performance test cycle.

The famous 80-20 rule comes in handy here. In most applications, 20% of the transactions cover 80% of application's core functionality (to be confirmed with the help of application experts). Once the workload model has been created, this step is fairly easy and straight forward.

It's also important to classify the transactions as the Performance Testing would be carried out differently for each type. The transactions could be very broadly categorized as online - where user submits a request and gets a response, and batch - where user submits a list of jobs and does not wait for the completion. The transaction mix also has to be identified, viz. transaction A has 50% requests, transaction B has 30%, and transaction C has 20%. All of A, B, C can occur together. This helps in deciding the mixed tests.

Also at times, there might be certain transactions which do not qualify as candidate transactions according to the 80/20 rule, but might be critical to business. Such transactions should also be considered for performance tests and all such transactions can be clubbed in one run to get a benchmark reading for analysis.

Where to perform tests? - Environment Setup & Planning

For Performance Testing, it is ideal to get an environment with the same capacity as the production/live environment. Many developers are of the opinion that one deliverable/outcome of performance testing/engineering exercise is to provide hardware projection for production use, which is perfectly right. Capacity projection and Production hardware gauging is altogether a vast topic. So for simplicity sake, we restrain ourselves to Production like environment (considering an earlier release of the application is already live on some hardware).

Besides the deployment hardware, there are many other pieces of hardware that would be needed to facilitate load testing. These can be broadly classified as load generation nodes, stub nodes and monitoring.

Load generation nodes are the machines used to generate load for the applications. These nodes are used to host the load generating software, such as LoadRunner, WinRunner, etc. Some open source alternatives are also available. Some custom scripts will have to be written which can run on these nodes to generate load on the system. These tools also help in monitoring the resource utilizations.

However it is not mandatory to use only these tools. Depending on the complexity some custom stubs may be written to do the testing.

Monitoring nodes usually can be the same as load generating nodes, since most of the load-generating software packages are also equipped with monitoring capabilities. Monitoring is an inherent aspect of Performance Testing. All the resource utilizations need to be monitored throughout the duration of the test to

  • ensure all the utilizations are within limits
  • identify the bottlenecks
  • The rate at which transactions are completing
  • Number of failed transactions...etc...

Stub nodes are the ones which will be usually hosting a stub to simulate some part of the software or external system that can not be included in the performance test runs - such camera or scanner devices that are operated manually, which wouldn't be a valid option for a repeatable performance test.

Data Preparation

Any enterprise system is usually programmed to process data. Thus, data planning for the performance testing of the system is a vital step. This directly affects the success of the Performance Testing exercise.

Data required for load tests can be broadly categorized as -

Initial/Retention Data - The performance of database is very much dependent on the amount of data present in the tables. When the application is in production, there is certain amount of data present in respective tables. While carrying out performance testing, it is necessary to have at least equal amount of data in the Test environment. In fact, depending on the system upgrade plans, the data in the test environment could be a multiple of production data.

Having same amount of data is one thing, and using the same distribution of data as in production is another. The distributions of data straight away affect the index performance and in turn the application performance.

The amount of data and its distribution should be validated by business and/or IT dept. before proceeding with Performance Testing.

Test Data - Once the retention data is fine, we turn our attention to test data. The same concepts as amount and distribution apply to test data as well. This time, we have to take concurrency into consideration too.

Designing scenarios

Any testing activity is comprised of the test cases and test-suite encompassing those tests. For performance testing there are some standard tests which are usually conducted on the candidate transactions of the system, depending on the nature of those transactions. The following subsections give a brief insight in each of those test scenarios.

Isolated runs

"Isolated" means running one transaction at a time. By running a single transaction and observing its behavior, we can see if it is able to utilize the hardware well. We can also see if it is able to meet its throughput requirements by running alone at least. The readings taken can also help in capacity planning (part of advanced Performance Engineering).

Usually isolated runs are preceded by Baseline / Calibration runs, where in just a single run of each transaction is executed to get the benchmark response times for all candidate transactions.

Mixed runs

"Mixed" means running all/multiple transactions simultaneously. This helps in identifying if all the transaction throughputs are met when multiple transactions are occurring parallely, i.e., it also tells us the effect of transactions on each other.

There are two schools of thought in the order of execution of these tests.

  • First, run mixed test in the beginning. If everything is fine, then we are saved efforts for isolated tests.
  • Second, run isolated tests in the beginning followed by mixed test. This is more useful when you want to determine the scalability of the application and do any capacity planning.

Trickle feed

This is mainly applicable in case of batch type of loads - e.g. the load may come as 'n' messages per five minute block.

Backlog runs

This is a typical batch load. Sometimes it might happen that the application receiving messages (say Application A) is down for long time, but the feeding application (say Application B) is continuously putting messages. Now when the application A comes up, how it behaves, can be found out by this testing.

Endurance

It has been observed that whenever a system is running for multiple days or months without downtime, its memory utilization increases or throughput falls or some exceptions occur. To find out if the application behaves fine even if run for longer duration, this test is used.

Stress

Sometimes, as the load on the system increases, e.g. on Christmas Eve for retail or shipping applications, the system throws errors or behaves unexpectedly. The stress test targets exactly this behavior. Determining that the software handles the load gracefully without crashing is the aim of this test.

Preparing Reports

Presenting results in an understandable format is normally a neglected area. If you don't do that, you are reaping only 20-30% benefits of Performance Testing. Properly presented results will enable business stakeholders to make informed decisions. Also, when it is time to do Performance Testing for the next version of the same application and if you don't have properly documented results (and if the people who did the exercise are gone), then you need to start all over again.

Key graphs

Here are some key graphs that should be created while executing Performance Testing and should be presented in a Performance Test Report.

CPU Utilization vs. No. of users

This graph tells us whether the CPU utilization increases with increasing users. It also tells us about bottlenecks as well as what is the maximum number of users that can be supported.

Throughput vs. number of users

This graph tells us if throughput increases with increasing number of users. This graph should have a similar shape as CPU Utilization graph.

Response Time vs. throughput

The response time should be fairly constant with increasing throughput. If it is not, it is most likely a bottleneck.

Besides the above mentioned graphs, depending on the nature of transactions and criticality of various components, a few other graphs can also be included in the report, such as network bandwidth & latency graphs, memory utilization graphs, disk / i-o utilization graphs for disk/i-o intensive operations, etc.

Best Practices

Automation with handy scripts

Script writing is an inherent part of any Performance Testing exercise. A lot of time is spent in ensuring the begin state of the test is proper. It might involve restarting servers, deleting extra data other than retention data, cleaning up log files, taking backup of some data, checking if some pattern exists in a log file, etc. Since each test needs to be run for 'n' number of times, automating these small tasks goes a long way in reducing time needed for each run.

Identify DB backups after crucial runs

During the course of Performance Testing activity there are bound to be different patches on application, database side. These changes are seemingly trivial but potentially devastating. It is a good idea to take the backup of data in the database and configuration files for the application before applying new patches to either application or DB.

Cross check Little's law

One of the basic queuing theory principles applied in SPE (Software Performance Engineering) is Little's law (a). It states that the total number of users in the system is equal to the product of throughput and response time. While calibrating your load test runs, one should always cross check the test results (throughput, response time, user-load simulated) to identify whether the load generator nodes themselves are not becoming the bottleneck in the system.

Designing scenarios to achieve right mix of transactions

Do not tune, if you don't have to.

There is a thin line separating Performance testing from Performance tuning. Unless really required, the tuning of various parameters of different components in the system should not be done. You will find many articles, which warn against tuning the systems. Most of the system components come with default values that are optimal. If we start looking for tuning of all the components, the duration of performance testing exercise will no longer be under control.

People Aspect

Performance Testing is a very strategic activity in the lifecycle of any Application. More often than not, you will have to deal with stakeholders who are apprehensive about the need of this activity, some people (especially DB, OS admins) who don't want the extra load this activity puts on them, software vendors who don't want additional defects on them, and many more. For the success of Performance Testing, it is important to take all these people along & explain (or thrust as the case might be) the inevitability of this exercise & how life would be easier when the application goes in production.

Environment availability is the biggest constraint which might force working in shifts, long hours, etc.

References

Authors

Alok Mahajan is Technical Architect with Infosys Technologies and specializes in Performance Engineering and Database designs. He has a total experience of more than7 years and has worked extensively on Performance Engineering assignments for more than 2 years, which uniquely positions him to write on the subject of performance. His areas of interest include Business Intelligence, Databases, Datawarehouse design/modeling.

Nikhil Sharma is Technical Architect with Infosys Technologies. For more than7 years, he has been involved in architecting and designing Enterprise Applications primarily on J2EE platform. For past2 years he has been working on Performance Engineering projects. He is also a Sun Certified Enterprise Architect for J2EE Platform (SCEA). His areas of interests are SOA, Integration Architectures, Portals.

Posted by tuning-java
,