Jmeter tool

1
I. Jmeter là gì? Tại sao sử dụng Jmeter
1. Jmeter là gì
Apache JMeterTM là phần mềm mã nguồn mở Java thuần túy, được phát
triển lần đầu bởi Stefano Mazzocchi của Tổ chức phần mềm Apache.
Được thiết kế để thực hiện kiểm tra hiệu năng (performance testing), kiểm
tra tải (load testing) và đo lường hiệu suất. Bạn có thể sử dụng JMeter để phân
tích và đo lường hiệu suất của ứng dụng web hoặc nhiều dịch vụ.
Kiểm thử hiệu suất (performance testing) có nghĩa là kiểm thử một ứng
dụng web với tải nặng, lưu lượng truy cập ,nhiều người dùng và đồng thời.
JMeter ban đầu được sử dụng để thử nghiệm ứng dụng Web hoặc ứng dụng
FTP.Ngày nay, nó được sử dụng để kiểm tra chức năng, kiểm tra máy chủ cơ sở
dữ liệu, v.v.
2. Tại sao sử dụng Jmeter
Mã nguồn mở (Open Source): JMeter hoàn toàn miễn phí, cho phép nhà
phát triển sử dụng mã nguồn cho sự phát triển.
Giao diện thân thiện: JMeter cực kỳ dễ sử dụng và không mất thời gian
để làm quen với nó.
Nền tảng độc lập: JMeter là ứng dụng máy tính để bàn Java nguyên bản
100%. Vì vậy, nó có thể chạy trên nhiều nền tảng. Ví dụ có thể chạy trong bất kỳ
hệ điều hành: Window, Linux hoặc Mac.
Khung đa luồng đầy đủ: JMeter cho phép các sampler xảy ra đồng thời
của các chức năng khác nhau bởi một nhóm luồng(thread group) riêng biệt.
Hiển thị kết quả kiểm tra: Kết quả kiểm thử có thể được hiển thị ở định
dạng khác nhau như biểu đồ, bảng, cây và tệp nhật ký.
Cài đặt dễ dàng: Bạn chỉ cần sao chép và chạy tập tin * .bat để chạy
JMeter. Không cần cài đặt.

2
Khả năng mở rộng cao: Bạn có thể viết các bài kiểm thử của riêng mình.
JMeter cũng hỗ trợ các plugin trực quan cho phép bạn mở rộng kiểm thử của
mình.
Nhiều chiến lược kiểm thử: JMeter hỗ trợ nhiều chiến lược kiểm thử như
Load Testing, Distributed Testing, và Functional Testing.
Mô phỏng: JMeter có thể mô phỏng nhiều người dùng với các chủ
đề(threads) đồng thời, tạo một tải nặng đối với ứng dụng web đang được kiểm
thử.
Hỗ trợ đa giao thức: JMeter không chỉ hỗ trợ kiểm thử ứng dụng web, mà
còn đánh giá hiệu năng máy chủ cơ sở dữ liệu. Tất cả các giao thức cơ bản như
HTTP, JDBC, LDAP, SOAP, JMS và FTP đều được hỗ trợ bởi JMeter.
Record & Playback: Ghi lại hoạt động của người dùng trên trình duyệt và
mô phỏng chúng trong ứng dụng web bằng JMeter.
Script Test: Jmeter có thể được tích hợp với Bean Shell & Selenium để
kiểm tra tự động.
II. Cài đặt Jmeter
1. Cài đặt trên Window
Điều kiện: Jmeter viết bằng Java nên muốn chạy JMeter trước hết máy
của bạn phải cài JRE hoặc JDK
Bước 1: Truy cập trang web: http://jmeter.apache.org/download_jmeter.cgi click
on “apache-jmeter-4.0.zip” để download

3
Bước 2: Giải nén file zip vừa tải về
Bước 3: Click đúp vào file apacheJmeter.jar

4
Giao diện Jmeter hiển thị như sau:
2. Cài đặt trên Ubuntu
Bước 1. Download Java for jmeter: sudo apt-get install openjdk-7-jre-headless

5
Bước 2. Check java version: java -version
Bước 3. Download jmeter as command:
wget-c http://ftp.ps.pl/pub/apache//jmeter/binaries/apache-jmeter-3.0.tgz
Bước 4. Update version for jmeter(if any): sudo apt-get update
Bước 5. Go to Download directory: cd Downloads/
Bước 6. Unpack jmeter: tar -xf apache-jmeter-4.0.tgz
Bước 7. Go to Jmeter directory: cd apache-jmeter-4.0/
Bước 8. Run: ./bin/jmeter
3. Cài đặt trên Mac
Bước 1. Install HomeBrew:
/usr/bin/ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Homebrew/install/master/install)"
Bước 2. Update brew : brew update
Đảm bảo cập nhật brew trước khi cài đặt Jmeter , nếu không sẽ gặp vấn đề như
dưới đây.
Downloading
http://www.apache.org/dyn/closer.cgi?path=jmeter/binaries/ap ache-jmeter-
2.11.tgz ==> Best Mirror
http://apache.mirrors.hoobly.com/jmeter/binaries/apache-jmet er-2.11.tgz curl:
(22) The requested URL returned error: 404 Not Found Error: Failed to download
resource "jmeter" Download failed:
http://apache.mirrors.hoobly.com/jmeter/binaries/apache-jmet er-2.11.tgz
Sự cố này xảy ra thường xuyên khi có phiên bản JMeter mới, nhưng định nghĩa
gói HomeBrew local của bạn vẫn trỏ đến phiên bản cũ.
Bước 3. Install môi trường java
Download JRE :

6
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-
2133155.html
Download JDK :
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-
2133151.html
Bước 4. Install Jmeter : brew install jmeter
Bước 5. Khởi chạy Jmeter : jmeter
4. Cài đặt plugin cho Jmeter
Bước 1. Download plugin từ link: https://jmeter-plugins.org/
Tap Install tab => Tap Plugins Manager
Tap JAR file và download JAR file

7
Bước 2. Chuyển jar file vừa download tới thư mục
/usr/local/Cellar/jmeter/4.0/lib/ext
Bước 3. Thoát và mở lại Jmeter
Bước 4. Sử dụng UI : Options -> Plugins Manager
III. Tìm hiểu về Performance Testing
1. Performance Testing là gì ?
Kiểm thử hiệu năng được thực hiện để xác định hệ thống hoặc hệ thống
con thực hiện một khối lượng công việc cụ thể nhanh thế nào? Nó cũng có thể
dùng để xác nhận và xác minh những thuộc tính chất lượng khác của hệ thống
như xác định thời gian phản hồi, thông lượng, khả năng mở rộng, độ tin cậy và
sử dụng tài nguyên.

8
2. Các tiêu chí thực hiện performance testing
● Trả lời câu hỏi hệ thống có thể xử lý các mức chịu tải trong khi vẫn giữ
được thời gian hồi đáp ở mức chấp nhận được hay không?
● Chỉ ra được vào thời điểm nào thì hệ thống bắt đầu hư hỏng và những
thành phần nào là nguyên nhân của sự suy thoái đó.
● Hệ thống hiện tại có thể nâng cấp được k? để phù hợp với sự phát triển
trong tương lai?
● Khi mà hệ thống gặp lỗi thì nó sẽ gây ra những ảnh hưởng gì lên mục
đích kinh doanh của doanh nghiệp?
● Đưa ra tiêu chí cho rằng hiệu năng của hệ thống là tốt.
3. Các loại performance testing
Load test: tìm capacity của server, xác định ngưỡng có thể chịu tải được
của hệ thống.
VD về ngưỡng của hệ thống: Hệ thống chịu được 5k request và không
xảy ra lỗi. Quá 5k sẽ bắt đầu có lỗi, response time bị chậm và sẽ có issue xảy ra.
Vậy thì 5k là capacity của server hoạt động ổn định.
Stress test: Đánh giá hệ thống tại và bên trên ngưỡng limit (capacity của
hệ thống) , tìm ra breaking point của hệ thống (làm cho hệ thống die ko response
được nữa).
VD về Breaking point: Ngưỡng mà hệ thống sẽ chết: Ví dụ 5k là nó hoạt
động ổn ko lỗi, 7k là nó bắt đầu có issue, 10k thì nó chết hẳn, die luôn hệ thống.
Vậy 10k là breaking point.
Spike test: Test 1 lượng load lớn trong 1 khoảng thời gian ngắn, giống
như số lượng request đến server của 1 shop online sẽ tăng cao đột biến ở ngày
black friday.

9
Volume test: Test khả năng chịu tải của phần mềm với 1 lượng dữ liệu
nhất định (thông thường là ngưỡng do spec mong muốn).
VD1: khách hàng mong muốn application có thể chịu tải được 10k user,
nếu hệ thống k đáp ứng được thì cần mở rộng DB, ram, room… để hệ thống có
thể đáp ứng được
VD2: KH muốn hệ thống có thể đọc được file csv khoảng 1000 line.
Scalability test: Kiểm tra khả năng mở rộng của hệ thống, tức là: kiểm tra
khả năng đáp ứng của hệ thống với nhu cầu tăng dần.
VD: Trang web thương mại điện tử có thể xử lý đơn đặt hàng cho tối đa
100 người dùng tại một thời điểm nhưng có thể thực hiện kiểm tra khả năng mở
rộng để kiểm tra xem nó có thể xử lý tải cao hơn trong mùa mua sắm cao điểm
không.
https://docs.google.com/spreadsheets/d/1zzV-jpen9U0vwq03ed8uki3-
Lkows0LdFfboRssPIks/edit#gid=787126708
IV. Tìm hiểu các element của Jmeter
1. Thead Groups
Thread group elements là điểm bắt đầu của một test plan bất kỳ. Tất cả các
Controllers và Samplers phải được đặt dưới một thread group.
Những elements còn lại ( ví dụ Listeners ) có thể đặt trực tiếp dưới test plan.
Trong trường hợp đó chúng sẽ áp dụng đến tất cả thread group.
Thread group element điều khiển số lượng threads mà JMeter sẽ sử dụng để
thực thi kịch bản test.

10
Thread Group có những thành phần sau:
1.1 Action to be taken after a Sampler error
Nó xác định những gì sẽ xảy ra nếu một sampler xảy ra lỗi, hoặc vì bản thân
sampler bị lỗi . Các lựa chọn có thể là:
Continue (default): Bỏ qua lỗi và tiếp tục kiểm thử và chạy sampler tiếp theo.

11
Start Next Loop: Bỏ qua lỗi, bắt đầu vòng lặp tiếp theo và tiếp tục với bài kiểm
thử
Stop Thread: Thoát khỏi thread hiện tại

12
Stop Test: Toàn bộ kiểm thử được dừng lại ở cuối sampler hiện tại. Nó có nghĩa
là các sampler đang chờ xử lý vẫn chạy cho đến khi hoàn tất.
Stop Test Now: Toàn bộ kiểm thử được dừng lại ngay lập tức. Mọi sampler hiện
tại đều bị gián đoạn.

13
1.2. Threads Properties
Number of Threads (Users): Giả lập số user
Ramp-Up Period: Khi giá trị Ramp-up Period được thiết lập thì Jmeter sẽ
biết rằng mất bao lâu để "ramp-up" cho toàn bộ các Threads đã chọn.
Ví dụ có 10 threads và ramp-up period là 100 giây, thì JMeter sẽ mất 100
giây để chạy 10 threads. Mỗi thead sẽ bắt đầu 10 (100/10) giây sau khi thread
trước đó được bắt đầu.
Ví dụ 2: Nếu có 30 threads and ramp-up period là 120 giây, thì mỗi chuỗi
liên tiếp sẽ bị trì hoãn sau 4 giây. Việc khởi động cần đủ dài để tránh tải quá lớn
khi bắt đầu kiểm thử và đủ ngắn để thread cuối cùng bắt đầu chạy trước khi
thread đầu tiên kết thúc (trừ khi ai muốn điều đó xảy ra).
Bạn nên bắt đầu với Ramp-up = số thread và điều chỉnh lên hoặc xuống khi cần
thiết.
LƯU Ý: Nếu Ramp-up = 0, kiểm thử sẽ được diễn ra cho đến khi tất cả
các threads được tạo ra, sau đó bắt đầu tất cả các thread cùng một lúc.
Loop Count: Số lần thực thi kiểm thử cho mỗi thread group . Giá trị mặc
định là 1 nghĩa là không lặp lại.
Delay Thread creation until needed: Làm chậm việc tạo ra thread mới.
Hữu ích khi tạo Thread Group với lượng user lớn. Khi đó tránh được tải lớn do
tạo ra một lượng user lớn ngay lập tức.
Scheduler: Khi được tích, tùy chọn cho scheduler sẽ được enable để thiết
lập việc chạy/dừng test tại những thời điểm nhất định. Nếu không chọn, bản test
sẽ chạy ngay khi chúng ta bấm Start.
1.3. Scheduler Configuration
Duration (seconds): Nếu scheduler checkbox được chọn, có thể chọn
thời gian kết thúc tương đối. JMeter sẽ sử dụng tính năng này để tính Thời gian

14
kết thúc và bỏ qua giá trị Thời gian kết thúc. Khi kiểm thử chạy hết thời gian này,
nó sẽ dừng lại và đang sử dụng chế độ Stop Test như trên.
Startup delay (seconds): Nếu scheduler checkbox được chọn, có thể
chọn độ trễ khởi động tương đối. JMeter sẽ sử dụng điều này để tính thời gian
bắt đầu và bỏ qua giá trị thời gian bắt đầu.
Start Time: Nếu scheduler checkbox được chọn,có thể chọn thời gian bắt
đầu tuyệt đối. Khi bạn bắt đầu kiểm thử, JMeter sẽ đợi cho đến khi thời gian bắt
đầu được chỉ định bắt đầu kiểm thử.
End Time: Nếu scheduler checkbox được chọn, có thể chọn thời gian kết
thúc tuyệt đối. Khi bạn bắt đầu kiểm thử, JMeter sẽ đợi cho đến khi thời gian bắt
đầu được chỉ định bắt đầu kiểm thử và nó sẽ dừng lại ở thời gian kết thúc được
chỉ định.
2. Listeners
Cung cấp thông tin mà JMeter thu thập được về các test case trong lúc JMeter
chạy
Ví dụ: "View results tree" Listener đưa ra chi tiết thông tin của các sampler
requests và responses. Các Listeners khác cung cấp các thông tin tóm lược
hoặc tổng quát .
Listeners có thể trích xuất data thu thập ra file cho người dùng . Mỗi
listeners cung cấp một field để chỉ định file sẽ chứa data. Có thể tùy chọn định
dạng file là CSV hoặc XML.
Lưu ý rằng tất cả Listeners đều lưu trữ cùng một dữ liệu/kết quả test , chỉ
khác nhau ở cách mà data hiển thị trên màn hình.
Listeners có thể đặt bất cứ đâu trong test plan. Chúng sẽ chỉ thu thập data
từ các elements cùng cấp hoặc dưới cấp.

15
2.1 Aggregate Report.
Các số liệu trong report
Mọi người có thể thấy Aggregate Report là 1 report dạng table, với 12 columns
ứng với 12 thông số. Hãy tìm hiểu xem ý nghĩa của từng thông số là gì nhé
● Label: Hiển thị tên của từng requests có trong test plan.
Mặc định, tất cả những request bị trùng tên trong test plan, sẽ chỉ hiển thị
1 dòng duy nhất trong table này, cho dù nội dung của các request đó có khác
nhau hay nằm khác Thread Group đi chăng nữa. Vì vậy, khi đặt tên cho các
Request, mọi người lưu ý nhớ điều này, và đặt tên khác nhau. Xem hình bên
dưới:
“Include group name in the label?” trong ảnh trên có giá trị mặc định là
UNCHECK.
Nếu lựa chọn “Include group name in the label?” được check, thì những request
sẽ được gán thêm tiền tố = tên của Thread Group chứa request đó. Tham khảo
hình bên dưới:

16
● # Samples: Tổng số lần run của request.
Công thức: # Samples = Number of Threads (users) * Loop Count.
Ví dụ 1: Thread Group có cấu hình
– Number of Threads (users): 10
– Loop Count: 3
Thì 1 HTTP Request của Thread Group này sẽ run 10 x 3 = 30 (lần)
—> # Samples: 30
Tuy nhiên, công thức trên sẽ không còn đúng trong 1 số trường hợp: đó là
khi Request của bạn nằm bên dưới 1 Logic Controller nào đó, chẳng hạn như
Logic Controller, such as Loop Controller, Once Only Controller, While Controller,
v.v…
Ví dụ 2: Tiếp tục với ví dụ 1 ở trên, nhưng lần này thì hãy để HTTP
Request vào 1 Logic Controller, là Loop Controller, và để giá trị Loop Count cho
controller này là 2. Lúc này request của bạn sẽ run: 10 x 3 x 2 = 60 (lần).
—> # Samples: 60
● Average (millisecond): Thời gian phản hồi trung bình (Response Time)
của request, tính cho đến lần run cuối cùng.

17
Ví dụ 3: Một Request A run tổng cộng 4 lần với các kết quả Response
Time tương ứng là 101ms, 106ms, 153ms, và 128ms. Thì Response Time trung
bình của Request A sẽ là 122ms.
● Min (millisecond): Respone Time thấp nhất của request tính cho toàn bộ
tất cả các lần run.
Trong ví dụ 3 ở trên thì Min = 101ms
● Max (millisecond): Respone Time cao nhất của request tính cho toàn bộ
tất cả các lần run.
Trong ví dụ 3 ở trên thì Max = 153ms
● Percentiles (millisecond): Percentiles sẽ là một con số x, và đi kèm theo 1
giá trị A. Nghĩa là sẽ có x% có giá trị thấp hơn giá trị A, còn lại (100-x)% sẽ
có giá trị lớn hơn giá trị A.
● Median (millisecond): Nó gần giống với trung bình, nhưng ý nghĩa thì khác
hoàn toàn. Median + một giá trị A, sẽ chia toàn bộ các giá trị của bạn
thành 2 phần bằng nhau, một phần sẽ chứa những giá trị < A, phần còn lại
sẽ chứa những giá trị > A. Median cũng được hiểu như là 50th Percentile.
Quay lại Performance, thì Median sẽ chỉ ra, sẽ có 50% số request có
response time nhỏ hơn giá trị (hiển thị trên table), và 50% số request còn
lại có response time lớn hơn giá trị này.
● 90% Line (90th Percentile) (millisecond):nghĩa là 90% số requests sẽ có
response time nhỏ hơn giá trị hiển thị trong table, 10% số requests còn lại
sẽ có response time lớn hơn giá trị hiển thị trong table
● Error %: % số lượng request bị fail, bị lỗi.

18
Ví dụ bạn run request A 100 lần và thấy có 15% errors, nghĩa là request A
đã fail/error 15 lần (100*15%)
● Throughput: Thông lượng. Con số này cho bạn biết được số lượng
requests được hệ thống (server) xử lý trong 1 đơn vị thời gian, có thể là
giây, phút, hoặc giờ. Công thức tính throughput là
Throughput = (Tổng số lượng requests) / (Tổng thời gian) * (Đơn vị
chuyển đổi)
- Tổng số lượng requests = Tổng số lần request này được run
- Tổng thời gian = (Thời gian bắt đầu chạy của request cuối cùng) +
(Thời gian chạy/Response Time của request cuối cùng) - (Thời gian bắt
đầu chạy của request đầu tiên)
- Đơn vị chuyển đổi: Mặc định nó sẽ tính theo millisecond, nên để đổi về
second thì số này sẽ là 1000, hoặc 1000*60 nếu bạn muốn chuyển về phút.
● KB/sec: Cũng là thông lượng, nhưng không đo lường bằng số request,
mà đo bằng Kilobytes/second. Công thức là
Throughput KB/sec = (Throughput * Average Bytes) / 1024
Với Aggregate Report thì mình không thấy được thông số Average Bytes. Bạn
có thể xem thông số này từ Summary Report.
● Total: Trong report có 1 dòng cuối cùng đó là Total, nó sẽ tổng kết lại toàn
bộ kết quả từ những request bên trên. Ngoại trừ # Samples, Throughput
và KB/sec, nó sẽ được cộng lại theo đúng nghĩa "Total". Còn các thông số
còn lại đều được tính Total bằng cách lấy giá trị trung bình từ tất cả những
request ở trên.
2.2 Phân tích Report
Hãy tập trung vào 2 thông số quan trọng nhất của mọi Performance Report.
Response Time: Chỉ ra được việc xử lý request NHANH hay CHẬM. Và
đương nhiên, Response Time thì phải càng THẤP càng tốt.

19
Throughput: Chỉ ra được số lượng requests được server xử lý trong một
đơn vị thời gian. Vậy thì, cùng một thời gian, càng xử lý được càng nhiều càng
tốt. Nên với Throughput thì nó phải càng CAO càng tốt.
Dựa vào đó, chúng ta có những trường hợp như sau:
● Response Time: THẤP and Throughput: THẤP => Trường hợp này sẽ
không bao giờ xảy ra. Vì Response Time THẤP nghĩa là thời gian đáp ứng
rất nhanh, nhưng Throughput THẤP lại chỉ ra rằng số request được xử lý
rất ít. Chuyện này là vô lý.
● Response Time: THẤP and Throughput: CAO --> Đây là một kết quả lý
tưởng . Thời gian xử lý thấp và số lượng request xử lý cùng đồng thời lại
cao. Còn chần chờ gì nữa mà không tự tin báo cáo rằng Server đang rất
tốt. Hãy xem xét khả năng mở rộng các tính năng, hoặc tăng thêm số
lượng test để tìm xem giới hạn của server là bao nhiêu.
● Response Time: CAO and Throughput: THẤP --> Ngược lại với bên
trên, đây là lúc mà Performance Test của bạn đã bị fail. Test chỉ ra rằng
thời gian xử lý quá cao, và lượng request được xử lý lại rất thấp. Phải xem
xét để improve về phía sever.
● Response Time: CAO and Throughput: CAO --> Khá nhạy cảm, vì bạn
có thể thấy Throughput cao, tức là server đang làm việc rất tốt, vậy tại sao
thời gian xử lý lại cũng cao (không tốt). Có thể vấn đề lúc này đế từ phía
Client, hoặc cụ thể là đến từ JMeter, có thể đoạn script của bạn viết chưa
được tối ưu, khiến quá trình nó xử lý mất nhiều thời gian chẳng hạn? Hãy
kiểm tra lại để chắc chắn rằng mình có một kết quả test chính xác.
Link tham khảo :
https://jmetervn.com/2016/10/10/analyze-the-aggregate-report-in-jmeter/

20
2.3 View Results Tree
Hiển thị kết quả dạng cây của tất cả các sample responses,cho phép bạn xem
phản hồi cho bất kỳ mẫu nào. Ngoài việc hiển thị phản hồi, bạn có thể thấy thời
gian cần để nhận phản hồi này và một số mã phản hồi.
To be up to date in next version...
3. Sampler
Sampler thực hiện công việc thực của Jmeter. Mỗi Sampler có thể tạo ra một
hoặc nhiều kết quả sample. Những kết quả sample có những thuộc tính đa dạng
được hiển thị ở listener

21
3.1 FTP request
Cho phép bạn gửi một request “upload file” đến server FTP. Nếu bạn gửi
nhiều request đến cùng một server FTP thì có thể dùng FTP Request Defaut
(chuột phải vào Thread Group/Config Element/FTP Request Defaut) và cấu hình
những thành phần mặc định.
Khi tải một một file, nó có thể được lưu trong đĩa (Local file) hay trong dữ
liệu trả về, hoặc cả hai.
Các thành phần chính:
+ Name: Tên của sampler này được hiển thị trong Test plan
+ Server Name or IP: tên miền hay địa chỉ IP của FTP server (*)
+ Port: Nếu nhập port >0 thì port được sử dụng, nếu không nhập sẽ sử
dụng port mặc định của FPT server.
+ Remote File: tên của tệp địch được tải lên (*)
+ Local file: Tệp để tải lên hoặc đích để tải xuống ( mặc định là tên Remote
File).
+ Local File Contents: cung cấp nội dung để upload. Sẽ được ghi đè lên
Local file.
+ get(RETR)/put(STOR): có thể truy xuất hoặc tải tệp hay không.

22
+ Use Binary mode? : kiểm tra chế độ nhị phân (mặc định ASCII).
Save File In Response?: Có lưu trữ nội dung của tệp đã truy xuất trong dữ
liệu phản hồi hay không. Nếu chế độ là ASCII, thì nội dung sẽ hiển thị trong View
Result Tree (Listener).
+ Username: Tên acc FTP.
+ Password: Password acc FTP
3.2 HTTP Request
HTTP Request này cho phép bạn gửi yêu cầu HTTP / HTTPS tới máy chủ
web. Nó cũng cho phép bạn kiểm soát hay không kiểm soát JMeter phân tích cú
pháp các tệp HTML cho hình ảnh, các sources được nhúng khác và gửi các yêu
cầu HTTP để truy xuất chúng. Các loại resource nhúng sau đây được truy xuất:
+ Hình ảnh
+ Applet
+ Bảng định kiểu (CSS) và tài nguyên được tham chiếu từ các tệp đó
+ external scripts
+ frames, iframes
+ background images (body, table, TD, TR)
+ background sound
Các thành phần chính: Basic

23
+ Name: Tên của HTTP request được biể thị trên Test plan.
+ Server Name or IP: tên miền hay địa chỉ IP của FTP server (*).
+ Port Number: Cổng Web server đang nghe, mặc định là 80.
+ Protocol: HTTP, HTTPS or FILE. Default: HTTP.
+ Method: GET , POST , HEAD , TRACE , OPTIONS , PUT ,DELETE ,
PATCH (không được hỗ trợ để thực hiệnJAVA ). Với HttpClient4 , các phương
thức sau liên quan đến WebDav cũng được cho phép: COPY, LOCK, MKCOL,
MOVE, PROPFIND, PROPPATCH, UNLOCK, REPORT, MKCALENDAR,
SEARCH.
+ Path: đường dẫn đến resource (ví dụ, /servlets/myServlet).
+ Content Encoding: Mã hóa nội dung sẽ được sử dụng (cho POST , PUT,
PATCH và FILE ). Đây là mã hóa ký tự được sử dụng và không liên quan đến
Content-Encoding HTTP header.
+ Redirect Automatically:Đặt trình xử lý giao thức http cơ bản để tự động
theo các chuyển hướng, vì vậy chúng không được JMeter nhìn thấy, và do đó sẽ

24
không xuất hiện như các sample. Chỉ nên được sử dụng cho các yêu cầu GET
và HEAD . Trình lấy mẫu HttpClient sẽ từ chối sử dụng nó cho POST hoặc PUT.
+ Follow Redirects: Điều này chỉ có tác dụng nếu " Redirect Automatically "
không được bật. Nếu được select, JMeter sampler sẽ kiểm tra xem phản hồi có
phải là một chuyển hướng hay không và follow theo nó nếu có.
+ Use KeepAlive.
+ Use multipart/form-data for HTTP POST: Sử dụng một request post
multipart/form-data or application/x-www-form-urlencoded
+ Browser-compatible headers: Khi sử dụng multipart / form-data , điều
này sẽ loại bỏ các tiêu đề Content-Type và Content-Transfer-Encoding ; chỉ tiêu
đề Content-Disposition được gửi.
+ Parameters: Mỗi param bao gồm Name và Value. Thường được sử
dụng cho method POST, PUT.
+ Files Upload: Tên của tệp cần gửi. Nếu để trống, JMeter không gửi tệp,
nếu được điền, JMeter sẽ tự động gửi yêu cầu dưới dạng multipart form request
(yêu cầu biểu mẫu nhiều phần).
Các thành phần chính: Advanced

25
+ Implementation: Java , HttpClient4 . Nếu không được chỉ định (và không
được xác định bởi các yêu cầu mặc định HTTP), giá trị mặc định sẽ phụ thuộc
vào giá trị của thuộc tính JMeter jmeter.httpsampler , thất bại, việc thực hiện
HttpClient4 được sử dụng.
+ Connect Timeout: Thời gian chờ kết nối. Số mili giây để chờ kết nối mở.
+ Response Timeout: Thời gian chờ phản hồi. Số mili giây để chờ phản
hồi( áp dụng cho mỗi lần chờ).
+ Retrieve All Embedded Resources: Yêu cầu JMeter phân tích cú pháp
HTML file và gửi HTTP / HTTPS request cho tất cả hình ảnh, Java applets,
JavaScript files, CSSs, v.v. được tham chiếu trong file.
+ URLs must match: URL được nhúng phải khớp bất kỳ URL nào được
tìm thấy. Nếu bạn chỉ muốn tải xuống resource được nhúng từ
http://example.com/ , hãy sử dụng biểu thức: http: // example .com /.*
+ Source address type: Chỉ dành cho HTTP request với triển khai
HTTPClient.
+ Chọn IP/Hostname để sử dụng địa chỉ IP cụ thể hoặc tên máy chủ (cục
bộ).

26
+ Chọn Device để chọn địa chỉ có sẵn đầu tiên cho giao diện đó, đây có
thể là IPv4 hoặc IPv6.
+ Chọn Device IPv4 để chọn địa chỉ IPv4 của tên thiết bị (như eth0 , lo ,
em0 , v.v.)
+ Chọn Device IPv6 để chọn địa chỉ IPv6 của tên thiết bị (như eth0 , lo ,
em0 , v.v.)
+ Source address field: Chỉ dành cho HTTP request với triển khai
HTTPClient. Thuộc tính này được sử dụng để kích hoạt tính năng giả mạo IP.
Nó ghi đè địa chỉ IP cục bộ mặc định cho sample này. Máy chủ lưu trữ JMeter
phải có nhiều địa chỉ IP (ví dụ: bí danh IP, network interfaces, device). Giá trị có
thể là IP address, hay network interface device như "eth0" or "lo" or "wlan0".
+ Proxy Server: Tên máy chủ hoặc địa chỉ IP của máy chủ proxy để thực
hiện yêu cầu. [Không bao gồm tiền tố http: // .]
+ Port: Cổng máy chủ proxy đang nghe.
+ Username: tên người dùng cho máy chủ proxy.
+ Password: mật khẩu cho máy chủ proxy.
+ Save response as MD5 hash?: Nhằm mục đích thử nghiệm một lượng
lớn dữ liệu. Nếu được select, thì phản hồi sẽ không được lưu trữ trong kết quả
mẫu. Thay vào đó, MD5 hash 32 ký tự của dữ liệu được tính toán và lưu trữ thay
thế.
3.3 Test Action
Được thiết kế để sử dụng trong một controller có điều kiện. Thay vì tạo một
sample, phần tử test sẽ pause hoặc stop mục tiêu đã chọn.
Test Action cũng có thể kết hợp hữu ích với Transaction Controller, vì nó
cho phép tạm dừng được bao gồm mà không cần tạo sample. Đối với sự delay
biến, thiết lập thời gian tạm dừng bằng không, và thêm một bộ đếm thời gian nhỏ.

27
Các thành phần của Test Action:
+ Name: Tên của sampler này được hiển thị trong Test plan.
+ Comments: Những comment cho sampler này.
+ Target:Current Thread / All Threads bỏ qua cho Pause and Go to next
loop iteration).
+ Action:
+ Pause: Tạm dừng các thread hay test
+ Stop: dừng các thread hay test sau khi hoàn thành bất kỳ sample
nào, cái mà đang progress
+ Stop now: dừng ngay lập tức các thread hay test mà không đợi
sample hoàn thành
+ Start Next Thread Group: bắt đầu với vòng lặp tiếp theo
+ Duration (mili seconds): thời gian Pause trong bao lâu (mili giây)
3.4 JDBC Request
JDBC Request cho phép bạn gửi một request (một SQL query) đến một
database.

28
Chi tiết thông số:
+ Variable Name of Pool declared in JDBC Connection Configuration: tên
biến của Jmeter. Tên biến phải phù hợp với tên biến trong JDBC Connection
Configuration..
+ Query Type: chọn loại query tương ứng.
+ SQL Query:
+ Parameter values: danh sách các tham số được ngăn cách bằng dấu
phẩy.
+ Parameter types: các loại param ví dụ như: INTEGER, DATE,
VARCHAR, DOUBLE.
+ Variable Names: tên biến, danh sách biến được ngăn cách bằng dấu
phẩy.
+ Result Variable Name: tên biến kết quả.
+ Handle ResultSet:
+ Store As String : tất cả các biến trên danh sách Variable
Names được lưu trữ dưới dạng chuỗi

29
+ Store As Object: Các biến của kiểu ResultSet trên các biến
Variable Names sẽ được lưu trữ dưới dạng Object
+ Count Records: Các biến của các kiểu ResultSet sẽ được lặp
lại thông qua hiển thị tổng số bản ghi là kết quả. Các biến sẽ
được lưu trữ dưới dạng Chuỗi.
3.5 Java Request
Cho phép bạn kiểm soát java class, triển khai interface
org.apache.jmeter.protocol.java.sampler.JavaSamplerClient. Bạn có thể sử dụng
JMeter để khai thác nhiều chủ đề, kiểm soát tham số đầu vào, và thu thập dữ
liệu.
Chi tiết các field trong Java Request:
+ Classname.
+ Send Parameters with Request: Một danh sách các đối số sẽ được
chuyển đến sampled class. Tất cả các đối số được gửi dưới dạng Chuỗi.
+ Sleep_time: sleep trong bao lâu (ms).

30
+ Sleep_mask: Bao nhiêu "randomness" để thêm. Thời gian ngủ được tính
như sau: totalSleepTime = SleepTime + (System.currentTimeMillis() %
SleepMask).
+ Label: Nếu điền sẽ ghi đè Name.
+ ResponseCode: Nếu điền sẽ cài đặt ResponseCode cho kết quả sample.
+ ResponseMessage: Nếu điền sẽ cài đặt ResponseMessage cho kết quả
sample.
+ Status: Nếu điền sẽ cài đặt Status cho kết quả sample.
+ SamplerData: Nếu điền sẽ cài đặt SamplerDataResponseCode cho kết
quả sample.
+ ResultData: Nếu điền sẽ cài đặt ResultData cho kết quả sample
3.6 Debug Sampler
4. Assertions
Assertions để xác nhận và kiểm tra lại các kết quả trả về.
4.1 Response Assertion
Response Assertion xác nhận phản hồi cho phép bạn thêm một chuỗi
được so sánh với các trường khác nhau của request hoặc response.

31
Chi tiết các field trong Response Assertion:
+ Name: Tên của Response Assertion này được hiển thị trong Test plan.
+ Apply to: Điều này là để sử dụng với các samplers có thể tạo các sub-
samples.
+ Main sample only: chỉ áp dụng cho sample chính
+ Sub-samples only: chỉ áp dụng cho sample phụ
+ Main sample and sub-samples: áp dụng cho cả hai
+ JMeter Variable Name to use: áp dụng cho nội dung biến
được đặt tên
+ Field to Test: chọn các field nào của Request hay Response để kiểm tra
+ Text Response: kiểm tra text trả về từ server
+ Request data: kiểm tra text của request đã gửi đến server
+ Response Code: Ví dụ: 200
+ Response Message: Ví dụ: OK

32
+ Response Headers: bao gồm Set-Cookie headers
+ Request Headers:
+ URL sampled
+ Document (text)
+ Ignore status: nếu được check thì status của response bắt buộc phải
thành công trước khi đánh giá Assertion
+ Pattern Matching Rules: các cách để kiểm tra
+ Contains: response trả về chứa pattern muốn kiểm tra
+ Matches : response trả về phù hợp hoàn toàn với pattern
muốn kiểm tra
+ Equals:
+ Substring: response trả về chứa một chuỗi string muốn kiểm
tra
+ Not: Đảo ngược lại kết quả kiểm tra
+ OR: sẽ có >2 pattern được kiểm tra. Nếu chỉ cần có 1 pattern
pass thì Assertion sẽ pas
+ Pattern to test: Nội dung muốn được kiểm tra từ response trả về
+ Custom failure message: cho phép thay thế thông báo lỗi ( hiển thị trong
Assertion results).
4.2 Duration Assertion
Duration Assertion để xác định khoảng thời gian phản hồi. Bất kỳ phản hồi
nào nhiều hơn số thời gian cho phép thì được coi là phản hồi không thành công.

33
Chi tiết các field trong Duration Assertion:
+ Name: Tên của Duration Assertion này được hiển thị trong Test plan
samples,
+ Duration to assert: Số lượng tối đa mili giây cho mỗi response/ phản hồi
4.3 Size Assertion
Size Assertion để kiểm tra xem mỗi response/ phản hồi có chứa đúng số
byte yêu cầu hay không (số Bytes trả về của response được hiển thị trong cột
Bytes tại View Results in Table)

34
Chi tiết các field trong Size Assertion:
+ Name: Tên của Size Assertion này được hiển thị trong Test plan
samples.
+ JMeter Variable Name to use: áp dụng cho nội dung biến
được đặt tên
+ Response Size Field to Test: test kích cỡ ở phần nào của response/
phản hồi.
+ Full Response: kiểm tra kích cỡ tại full response
+ Response Headers: Chỉ kiểm tra size tại phần Headers của
response
+ Response Body: Chỉ kiểm tra size tại phần Body của response
+ Response Code: Chỉ kiểm tra size tại phần Code của
response

35
+ Response Message: Chỉ kiểm tra size tại phần Message của
response
+ Size to Assert:
+ Size in bytes: Kích cỡ cho mỗi response
+ Type of Comparison: Các loại so sánh >;<;=;>=;<=;!=. Của
response trả về với “Size in bytes” được cài đặt.
4.4 XML Assertion
XML Assertion để kiểm tra rằng dữ liệu response bao gồm một documnent
XML chính xác
4.5 MD5Hex Assertion
MD5Hex Assertion cho phép người dùng kiểm tra MD5 Hex trong dữ liệu
phản hồi.

36
MD5 Hex: 32 chữ số thập lục phân đại diện cho MD5 hash
4.6 HTML Assertion
HTML Assertion cho phép người dùng kiểm tra cú pháp HTML của dữ liệu phản
hồi bằng cách sử dụng Jtidy.
Chi tiết các field trong HTML Assertion:
+ Name: Tên của HTML Assertion này được hiển thị trong Test plan
+ Doctype: omit/bỏ qua, auto/tự dộng, strict/Nghiêm ngặt, loose/Lỏng lẻo
+ Format: chọn định dạng HTML, XHTML, XML
+ Errors only: chỉ ghi chú với lỗi
+ Error threshold: Số lỗi được cho phép trước khi response không thành
công
+ Warning threshold: Số cảnh báo được cho phép trước khi phản hồi
không thành công.
+ Filename: Report được vào tệp frontpage_JTidy.txt

37
4.7 XPath Assertion
5. Logic controllers
Logic controller giúp bạn định nghĩa thứ tự xử lý request trong một Thread.
Ví dụ, ban có thể sử dụng Random controller để gửi HTTP request tới server
một cách ngẫu nhiên.
Logic controller định nghĩa thứ tự request để thực thi.

38
Dưới đây là một vài Logic controller thường được sử dụng:
5.1 Recording controller
Jmeter có thể ghi lại các thao tác test. Recording controller là một Place holder
để lưu trữ lại các Recording step này.

39
5.2 Simple controller
Simple controller chỉ là một container cho user request. Simple controller cho
phép bạn tổ chức và lưu trữ các bộ điều khiển khác.
5.3 Loop controller
Loop controller làm cho các request chạy trong số lần được chỉ định or
forever, ngoài giá trị vòng lặp mà bạn đã thiết lập cho thread group.

40
Ví dụ: Trong 1 HTTP request, bạn thiết lập loop controller có loop count là
2 và thread group cũng có loop count là 2. Thì lúc này Jmeter sẽ chạy tổng 4
HTTP requests.
Và loop controller chỉ chạy cho các child request được thiết lập trong loop
controller.
Ví dụ: Thread group có loop count là 1 và thiết lập loop controller cho
News Page request có loop count là 3.
Như điều kiện trên thì Jmeter sẽ chạy theo thứ tự sau: Home page, News page,
news page, new page.
5.4 Once only controller
Thiết lập once only controller cho phép Jmeter xử lý các bộ điều khiển bên
trong nó chỉ một lần cho mỗi thread. Nếu once only controller được thiết lập thì
nó sẽ được chạy duy nhất trong lần đầu tiên của thread group, còn các lần chạy
sau đó thì request được pass over.
Ví dụ: Thread group có loop count là 3 và bên trong HTTP request thiết lập
once only controller cho một HTTP request như hình bên dưới.

41
Lúc này, Jmeter sẽ chạy theo thứ tự sau: Home page, Bug page, Bug page, Bug
page.
5.5 Random controller
Random controller làm cho tất cả các yêu cầu người dùng chạy với
random order trong mỗi vòng lặp.
Ví dụ: Bạn có 3 yêu cầu tới trang google.com theo thứ tự như sau:
+ 1. HTTP request
+ 2. FTP request
+ JDBC request.
Và yêu cầu là, 3 request này chạy 5 lần. Tổng sẽ có 5 request gửi tới server bởi
jmeter.
- Trường hợp gửi tuần tự: HTTP request -> FTP request -> JDBC request cho
mỗi vòng lặp.
- Trường hợp random thì các request sẽ được gửi ngẫu nhiên: FTP -> JDBC ->
HTTP OR JDBC -> HTTP -> FTP cho mỗi vòng lặp.
6. Timer
Timer cho phép Jmeter delay giữa mỗi request mà Thread tạo ra. Timer có
thể giải quyết được vấn đề quá tải của server. Trong thực tế, sẽ không có trường
hợp nhiều người truy cập cùng lúc vào server mà nó trong một khoảng thời gian
khác nhau. Timer giúp mô tả lại hành vi này.
6.1 Một số Rule cho Timer
Rule 1: Timer sẽ được chạy trước Sampler nhưng sau PreProcessor.

42
Rule 2: Timer sẽ được apply cho tất cả element cùng cấp và nhỏ hơn. Hoặc
apply cho duy nhất một sampler cha.
Hãy nhìn vào ví dụ ở các hình dưới đây:
Ở ví dụ này, Timer sẽ apply cho Request 1 và Request 2 cùng cấp với Timer 1
Ở ví dụ này, Timer sẽ apply cho Request 1, Request 2 và Request 3.

43
Lúc này, Timer 1 không apply cho Request 0 bởi vì sampler này có level cao hơn
Timer 1.
Timer 1 chỉ apply cho Request 1 và không apply cho request 2.
Note: Nếu Timer được thiết lập bên dưới Sampler thì nó chỉ apply cho duy nhất
1 sampler đó.
Rule 3: Nếu có nhiều Timer apply cho một sampler thì thời gian dừng của
sampler đó bằng tổng thời gian của tất cả Timer.

44
Trong ví dụ này, thời gian delay trước khi thực hiện Request A bằng total của
Timer 1 + Timer 2 + Timer 3 + Timer 4.
Rule 4: Response Timer không bao gồm thời gian thực thi các Timer.
Ví dụ: Thiết lập cho Sampler thực hiện trong 5s và sampler này có Timer 2s.
Đồng nghĩa với việc tổng thời gian cho bài test là 7s, nhưng Response time của
Sampler vẫn là 5s.
Dưới đây là một số loại Timer thường dùng trong jmeter.
6.2 Constant timer
Constant timer delay cho mỗi request cùng một khoảng thời gian.
6.3 Gaussian Random Timer
Gaussian Random Timer delay cho mỗi request một khoảng thời gian ngẫu
nhiên.

45
+ Deviation: Độ lệch tính bằng milliseconds
+ Constant Delay Offset: Add thêm value và cũng tính bằng milliseconds.
Trong trường hợp này, tổng thời gian delay sẽ được tính như sau:
6.4 Uniform Random Timer
Uniform Random Timer delay cho mỗi request một khoảng thời gian ngẫu nhiên.

46
+ Random Delay Maximum: Giá trị delay ngẫu nhiên lớn nhất, tính bằng
milliseconds.
+ Constant Delay Offset: Add thêm value và cũng tính bằng milliseconds.
Tổng thời gian delay bằng tổng của Random Value và Offset Value.
Uniform Random Timer khác với Gaussian Random Timer ở chỗ: Trong Uniform
thì chỉ xác định được giới hạn của Random value còn không xác định được giá
trị cụ thể, còn Gaussian thì Random value mình đã thiết lập trước.
7. PreProcessor Elements
Preprocessor thực hiện một vài action trước khi thực thi Sampler Request.

Jmeter tool

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Jmeter tool

Similar to Jmeter tool (20)

Recently uploaded

Recently uploaded (20)

Jmeter tool