- vừa được xem lúc

Phân tích kết quả test JMeter với các Listener.

0 0 861

Người đăng: To Thi Trinh

Theo Viblo Asia

I.Listener trong JMeter là gì ?

  • Listener là các phương thức hiển thị kết quả test theo nhiều cách, trực quan hóa các kết quả trả về sau khi thực hiện gửi request đến server.
  • Một số các listener thường được sử dụng:
    • View Results Tree
    • Summary Report
    • Aggregate Report
    • Backend Listener
    • Aggregate Graph
    • Graph Result
    • ....

II. Phân tích kết quả test với một số listener thông dụng

1. Graph Result

Sau khi thực hiện một script test, Graph Results sẽ trả về kết quả dưới dạng đồ thị như sau:

  • Những thông số được biểu thị trên graph với những màu sắc khác nhau:
    • Samples (đen) : Tổng số samples hiện tại đã gửi lên server.
    • Deviation (đỏ) : Độ lệch chuẩn hiện tại.
    • Throughput (xanh lá): Thông lượng biểu thị số lượng requests mà server xử lý trong một đơn vị thời gian.
    • Average (xanh dương): Thời gian phản hồi trung bình của tất cả các requests.

Phân tích Graph Results

Ở đây chúng ta sẽ phân tích 2 thông số quan trọng:

  • Throughput : là thông số quan trọng nhất, nó đại diện cho khả năng xử lý độ tải của server. Chỉ số này càng CAO thì hiệu suất của server càng TỐT và ngược lại.
    • Trong ví dụ trên, ta có thể thấy được Throughput hiện tại của trang web Vietnamnet là 7,926.722/minute. Tức là server có thể xử lý 7,926.722 requests trong vòng một phút.
  • Deviation: thể hiện sự sai lệch hiện tại so với mức trung bình, con số này càng NHỎ thì performance của server càng TỐT.

2. Aggregate Report

Sau thêm Listener Aggregate Report, Run test thành công, JMeter sẽ trả về cho chúng ta một bảng kết quả dưới đây.

Trong bảng Aggregate Report bao gồm các giá trị cần quan tâm:

  • Label: Hiển thị tên của từng request có trong Test plan của bạn. Ở đây chúng ta có 5 requests tưng ứng: Chinh tri,, Giao duc, Thoi su, Kinh doanh, Du lịch.
  • Samples: Số lần run của request, được thực hiện với công thức:
    • Samples = Number of Threads (users)* Loop count
      • Ví dụ:
        • Number of Threads (users) = 1000
        • Loop count = 1
        • --> Samples = 1000.
  • Average (milliseconds): Thời gian phản hồi trung bình (Responsive time) của request cho đến lần run cuối cùng.
  • Min (milliseconds) : Response time thấp nhất trong tất cả các lần run.
  • Max (milliseconds): Responsive time cao nhất trong tất cả các lần run.
  • Median (milliseconds): 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 (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.
  • 95% Line (millisecond): Nghĩa là 95% số requests sẽ có response time nhỏ hơn giá trị hiển thị trong table, 5% số requests còn lại sẽ có response time lớn hơn giá trị hiển thị trong table.
  • 99% Line (millisecond): Nghĩa là 99% số requests sẽ có response time nhỏ hơn giá trị hiển thị trong table, 1% số requests còn lại sẽ có response time lớn hơn giá trị hiển thị trong table.
    • (Note: Các thông số (90%, 95%, 99%) này có thể được thay đổi thông qua file jmeter.properties)
  • Error%: % số lượng requests bị fail.
  • Throughput: Thông lượng. Con số này cho bạn biết được số lượng requests được server xử lý trong một đơn vị thời gian (s, m, h).
    • Throughput = ( Tổng số lượng requests)/ (Tổng thời gian) * (Đơn vị chuyển đổi)
    • Vớ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 là (1000x60) 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 bằng số request, mà đo bằng kilobytes/second. Công thức là Throughput KKB/sec = (Throughput * Average Bytes) / 1024
  • Total: Tổng kết toàn bộ kết quả từ những request bên trên. Ngoại trừ # Samples, Throughtput và KB/sec đưuọc tính cộng lại theo đúng nghĩa total. Còn các thông số còn lại được tính bằng cách lấy giá trị trung bình từ tất cả các request bên trên.

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 Peformance Report:

  • Response time: Chỉ ra việc xử lý request NHANH hay CHẬM, và đương nhiên, response time càng THẤP càng tốt.
  • Throughput: chỉ ra được số lượng request được server xử lý trong một đơn vị thời gian. Cho nên, cùng một thời gian, càng xử lý càng nhiều càng tốt. Nên với Throughput càng CAO càng tốt.

Dựa vào đó, chúng ta có các trường hợp sau:

  • Response time THẤP và Throughput CAO

    • 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. Và tất nhiên " No, chuyện này thật vô lý".
  • Response time THẤP và Throughput CAO

    • Đây là một kết quả lý tưởng phải không nào?
    • Thời gian xử lý thấp và số lượng request xử lý đồ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 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 và Througput THẤP

    • Ngược lại với trường hợp trên, đây là lúc mà Perfoemance test của bạn đã bị fail.
    • Kết quả test chỉ ra rằng thời gian xử lý quá cao, và lượng request đưuọc xử lý lại rất thấp. Phải xem lại để improve về phía server.
  • Response time CAO và Throughput CAO

    • Khá nhạy cảm nhỉ ???
    • 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 đến từ phía Client, hoặc cụ thể là đến từ Jmeter, có thể đoạn scripts 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 để chắc chắn rằng mình có một kết quả test chính xác nhé.

3. View Results Tree

Với phương thức hiển thị kết quả bằng Result Tree, sẽ cung cấp chi tiết các status (passed/failed), parameters và data của từng sample.

  • Sau khi gửi request, với mỗi Sample chúng ta sẽ nhận được Sampler result tương ứng, nó bao gồm: response code, headers, cookies và những thông tin về time, latency, response size in bytes,...

Tổng kết:

Với mỗi mục đích mà mình sẽ sử dụng các listener khác nhau. Thông thường, mình sẽ sử dụng kết hợp các loại listener để phân tích kết quả test:

  • Aggregate Report để nhận được tổng quan về perfomance của hệ thống đang test.
  • Trong trường hợp, thông qua bảng Aggregate nhận thấy có vấn về ở các Label, thì mình sẽ dùng View Results Tree để có thể kiểm tra được vấn đề của từng sample.

Tài liệu tham khảo

Bình luận

Bài viết tương tự

- vừa được xem lúc

Các mô hình phát triển phần mềm

1. Định nghĩa. Mô hình phát triển phần mềm hay quy trình phát triển phần mềm xác định các pha/ giai đoạn trong xây dựng phần mềm. Có nhiều loại mô hình phát triển phần mềm khác nhau ví dụ như:.

0 0 112

- vừa được xem lúc

Tìm hiểu về kỹ thuật phân tích giá trị biên và phân vùng tương đương trong kiểm thử hộp đen

Để đảm bảo được chất lượng của một hoặc nhiều dự án phần mềm QA cần phải tạo được bộ testcase phù hợp.Để thực hiện việc kiểm tra phần mềm với thời gian ngắn nhất mà vẫn đạt chất lượng cao nhất cần phải hiểu sâu về nghiệp vụ của phần mềm và linh hoạt trong việc thiết kế testcase.

0 0 237

- vừa được xem lúc

Single Page Application Concept

Bạn đã từng nghe về một trang wed Single page hay chưa? Dạo gần đây Single page application là một cái tên đang nổi trong xu hướng phát triển web. Mặc dù concept này đã ra đời hơn chục năm nay.

0 0 52

- vừa được xem lúc

Top 15 xu thế kiểm thử phần mềm trong năm 2021

. Năm 2021 dự kiến những công nghệ sau sẽ lên ngôi:. . AI (Artificial intelligence) và ML (Machine Learning). Robotics.

0 1 190

- vừa được xem lúc

Xử lý Table, Frame và Dynamic Element của Web trong Selenium Script – Selenium Tutorial #18

Table, Frame và Dynamic Element là các phần thiết yếu không thể thiếu của bất kỳ web project nào. Chúng ta hãy cùng nhau tìm hiểu cách xử lý chúng trong tập lệnh selenium nhé.

0 0 101

- vừa được xem lúc

Exploratory testing - Kiểm thử thăm dò

I. Định nghĩa. 1. Exploratory testing là gì.

0 0 142