#5 Chiến lược kiểm thử hiệu năng Spiderum – Performance tesing thật vi diệu

Trước khi đi tiếp phần chiến lược kiểm thử hiệu suất thì hãy cùng xem nhiệm vụ chính của bước này là gì nhé!

– Quyết định xem nên sử dụng tài nguyên bên trong hay bên ngoài để thực hiện các thử nghiệm, tùy thuộc vào chuyên môn của kênh (hoặc thiếu nó)
– Phát triển một kế hoạch kiểm tra hiệu suất chi tiết (bao gồm các kịch bản chi tiết và các trường hợp thử nghiệm, khối lượng công việc, thông tin môi trường, v.v.)
– Chọn công cụ kiểm tra
– Phát triển kế hoạch dự án thử nghiệm hiệu suất chi tiết, bao gồm tất cả các phụ thuộc và các mốc thời gian liên quan.
– Định cấu hình môi trường kiểm tra (phần cứng giống hệt lý tưởng với nền tảng sản xuất), cấu hình bộ định tuyến, mạng yên tĩnh (chúng tôi không muốn người dùng khác buồn phiền về kết quả), triển khai thiết bị máy chủ, bộ kiểm tra cơ sở dữ liệu được phát triển, v.v.
– Chạy thử nghiệm khô – trước khi thực sự thực hiện thử nghiệm tải với người dùng được xác định trước, chạy khô được thực hiện để kiểm tra tính chính xác của tập lệnh.
– Thực hiện các thử nghiệm – có thể lặp đi lặp lại (lặp đi lặp lại) để xem liệu bất kỳ yếu tố nào không được tính có thể ảnh hưởng đến kết quả.

Ngoài ra bạn cần phải chú ý những vấn đề bên ngoài như:
– Xác định tiêu chí chấp nhận hiệu suất: xác định thời gian đáp ứng, thông lượng và các mục tiêu và ràng buộc sử dụng tài nguyên. Nói chung, thời gian đáp ứng là mối quan tâm của người dùng, thông lượng là mối quan tâm của doanh nghiệp và sử dụng tài nguyên là mối quan tâm của hệ thống. Ngoài ra, xác định các tiêu chí thành công của dự án có thể không bị bắt bởi các mục tiêu và ràng buộc đó. Ví dụ: sử dụng các kiểm tra hiệu suất để đánh giá sự kết hợp nào của cài đặt cấu hình sẽ dẫn đến các đặc tính hiệu suất mong muốn nhất.

Được rồi hãy bắt đầu chiến lược kiểm thử hiệu suất với các bước bên dưới nhé!

Mình sẽ chỉ nói sơ bộ về các bước giúp các bạn hiểu được cốt lõi của sự việc thôi chứ việc đi chi tiết từng bước sẽ được nêu ở bài viết bắt đầu thực hiện chiến dịch sau.

1. Hiểu thật rõ hệ thống mà mình test

Xác định môi trường thử nghiệm vật lý và môi trường sản xuất cũng như các công cụ và tài nguyên có sẵn cho nhóm thử nghiệm. Môi trường vật lý bao gồm phần cứng, phần mềm và cấu hình mạng. Có sự hiểu biết thấu đáo về toàn bộ môi trường thử nghiệm ngay từ đầu cho phép thiết kế và lập kế hoạch thử nghiệm hiệu quả hơn và giúp bạn xác định các thách thức thử nghiệm sớm trong dự án. Trong một số tình huống, quy trình này phải được xem xét lại định kỳ trong suốt vòng đời của dự án.

Phân tích công nghệ mà hệ thống xây dựng ví dụ như

– Hệ thống đó là hệ thống gì? Web Application, Log Handler, Text search, Web RTC
– Đọc về kiến trúc hệ thống, nếu có bản vẽ là dễ nhất –> phải biết được chức năng của mỗi thành phần và cách hoạt động của mỗi thành phần đó, input, output. Ví dụ như mình làm việc với Web App, mình sẽ phải hiểu về web server, load balancing, database, cache…
– Đọc kỹ về cái protocol mà mình sẽ thực hiện test, cơ chế, thành phần yêu cầu. Ví dụ như HTTP, HTTPS, web socket, TCP…

2. Tạo các kịch bản test

Sau khi hiểu rõ về technical rồi, mình sẽ suy nghĩ về các kịch bản mà mình sẽ sử dụng, kịch bản cho mỗi hệ thống sẽ khác nhau.
Xác định các kịch bản chính, xác định tính biến đổi giữa những người dùng đại diện và cách mô phỏng sự biến đổi đó, xác định dữ liệu thử nghiệm và thiết lập các số liệu sẽ được thu thập. Hợp nhất thông tin này thành một hoặc nhiều mô hình sử dụng hệ thống sẽ được triển khai, thực hiện và phân tích.

3. Xây dựng test script

Chọn công cụ test

Việc chọn công cụ test cũng khá quan trọng mình phải cân nhắc các chỉ tiêu sau khi chọn công cụ
– Tool đó có support được cái bạn định test không? HTTP, TCP, LDAP …
– Tool đó được viết bằng ngôn ngữ gì? tool GUI hay code? Cơ chế hoạt động của tool
– Làm thế nào để config lượng load? lượng load đó được sinh ra như thế nào?
– Các thành phần xử lý những bài toán nhỏ hơn: variable, extract value, code snippet…
– Có hỗ trợ debug ko?
– Output có định dạng gì? file, database…Output đó có dễ thể hiện trên các visual tool không?
Đối với chiến dịch kiểm thử lần này thì mình chọn Jmeter nhé!
Còn vì sao chọn jmeter mình sẽ nói sâu hơn ở bài viết sau

Chuẩn bị dữ liệu test

Bước này thường nhằm mục đích tạo đầu vào cho mỗi kịch bản. Ví dụ như các tài khoản test được tạo ra, hay các bài viết mẫu, các comment được xây dựng trước nhằm là input với số lượng lớn để script kiểm thử có thể đọc đầu vào.

Bài viết trước mình có nhắc đến vì sao mình lại test API trước và thu thập dữ liệu từ các api đó. Bạn có thể đọc lại tại đây
# http://blog.ntechdevelopers.com/cao-du-lieu-u-crawling-u-tai-sao-microsoft-excel-lai-khong-the/

Việc thu thập dữ liệu từ bước kiểm thử API trước giúp rất nhiều và rất cần thiết để có được đầu vào chất lượng và đúng đắn cho script của bạn.

Record kịch bản

Kịch bản là trình tự các thao tác, các script sẽ được thực hiện trong một khoảng thời gian với 1 số người dùng xác định để đạt được các mục đích test khác nhau.

Việc ghi lại những bước của kịch bản, kiểm tra đầu vào đầu ra hay phân tích lấy dữ liệu đầu vào cho mỗi bước mất khá nhiều thời gian. Công cụ sẽ hỗ trợ bạn record giống như bạn quay lại màn hình và thực hiện các bước đó. Khi đó các bước giả lập sẽ được ghi lại. Từ đó bạn có thể chỉnh sửa kịch bản theo nhu cầu thực tế dựa trên bản recording đó.

Update script theo kịch bản record

Scripts là những thao tác thực tế của người dùng được lưu lại nhằm phục vụ cho việc kiểm thử hiệu năng.Với những công cụ hỗ trợ cho việc kiểm thử hiệu năng, chúng ta có thể lưu lại các bước thực hiện kịch bản đó dưới dạng mã lệnh. Mã lệnh này cũng có thể được chỉnh sửa một cách phù hợp nhất để phục vụ nhu cầu của tester trong tình huống đề ra.

Thử nghiệm kiểm tra tính đúng đắn của script

Kiểm thử phần mềm mà, thứ dùng để kiểm thử một phần mềm khác cần được kiểm tra nó có đảm bảo đúng đắn hay không trước đã.

Mình đã từng gặp một trường hợp script kiểm thử sai mà đem đi kiểm thử một phần mềm khác. Lấy cái sai để kiểm thử một thứ chưa biết đúng hay sai là một điều vô nghĩa, thế là cãi nhau loạn xạ cả lên.
Vậy nên để kiểm tra ai đó, cái gì đó, thì trước tiên phải kiểm tra bản thân mình trước, script của mình làm ra trước. Nhớ nhé!

Setup các thông số phù hợp

Trong quá trình kiểm thử hiệu năng, các số liệu thu thập được là không giới hạn. Tuy nhiên, việc thu thập quá nhiều số liệu có thể gây khó khăn khi phân tích cũng như tác động tiêu cực đến thực tế của ứng dụng. Vì vậy, điều quan trọng là xác định các số liệu có liên quan nhất đến mục tiêu hiệu năng, những điều cần thiết sẽ giúp xác định điểm tắc nghẽn.Chỉ những số liệu được phân tích một cách chính xác và cung cấp những thông tin có giá trị mới được lựa chọn.

Phân tích lập kế hoạch giới hạn test

Xác định mức tải mục tiêu được áp dụng chó việc phân phối khối lượng công việc được xác định trong các bước trước. Mục đich của việc xác định các mức tải mục tiêu là để đàm bảo rằng các kiểm thử có thể được sử dụng để dự đoán hoặc so sánh với các điều kiện tải trọng hiệu suất.

4. Báo cáo kết quả test

Thông thường, quá trình test xảy ra trong 1 giai đoạn thời gian, có thể là 30min, 1h, 2h. Kết quả của test là các thông số sẽ được sắp xếp theo thứ tự thời gian. Sau đó từ cái bảng kết quả theo kiểu time-series data đó, mình sẽ có được kết quả dưới dạng các thông số của thống kê, như min, max, mean, median, percentile… 

Càng hiểu ý nghĩa của các con số thống kê, mình càng hiểu kết quả và đưa ra kết luận chính xác. Đây cũng có lẽ là nguyên nhân chính mà các bạn tester thường rất bối rối không biết phải đọc kết quả như thế nào.

Ví dụ, average của response time cho request A là 3s, ta nghĩ là response time trung bình là 3s, nhưng ta không nên đưa 3s làm con số report. Vì sao? Vì ta cần nhìn vào toàn quá trình run test, có 4/5 requests là 500ms, và 1 request run dài 13s. Nó khác hoàn toàn với 5/5 requests có average xấp xỉ 3s.

Phân tích kết quả, điều chỉnh và kiểm tra lại: phân tích, Hợp nhất và chia sẻ dữ liệu kết quả. Thực hiện một sự thay đổi điều chỉnh và kiểm tra lại. So sánh kết quả của cả hai bài kiểm tra. Mỗi cải tiến được thực hiện sẽ trả lại cải tiến nhỏ hơn so với cải tiến trước đó. Khi nào bạn dừng lại Khi bạn gặp nút cổ chai CPU, các lựa chọn sau đó sẽ cải thiện mã hoặc thêm CPU.

Đến đây bạn đã hiểu được quy trình để có thể chạy được Performance testing rồi đúng không?
Bước 1: Tìm hiểu hệ thống thì mình đã thực hiện thông qua thao tác Manual Testing.
Bước 2: Tạo kịch bản và thu thập dữ liệu kiểm thử thì mình đã thực hiện ở bước API Testing.
Bước 3: Viết script performance testing
Bước 4: Viết báo cáo kiểm thử

Đây là bài viết kết thúc phần chiến lược kiểm thử spiderum. Bắt đầu từ bài viết sau là mình bắt đầu chiến dịch kiểm thử hiệu suất spiderum rồi nhé! Hi vọng các bạn đón đọc.