Bài viết chuyên sâu

[Software Testing] Performance testing

[Software Testing] Performance testing

by Admin Dathoc -
Number of replies: 0

#koolj_softwaretesting

#chiase

#những_mẫu_testcases_cơ_bản


Về THIẾT KẾ testcase và thực hiện performance test, load test, volume test, stress test.

.

.

.

Vấn đề/lỗi nghiêm trọng trong 1 dự án chiếm cỡ 2-5% tổng số lỗi. Song 90% lỗi/ vấn đề nghiêm trọng của hệ thống, chiếm 70% time sửa lại hệ thống, chi phí hệ thống, chỉ có thể tìm thấy qua kiểu test này.


Thời mình, 1996-2012, hiếm khi thấy tester được lead phân công làm kiểu kiểm định này, vì đơn giản khi đó tụi mình outsourcing là chính. Và đôi lúc khách hàng biết tỏng anh em tốc độ chất lượng code ra sao rồi. Và đôi khi nó cũng đếch cần cái này. Cũng có đôi dự án trong 1 năm nó cần. Và công cụ chính của a em dùng là Jmeter, Load Runner, sau này có a Microsoft tích hợp Loadtest trong VisualStudio tiện hơn.


Một điểm nữa là trung bình các dự án cỡ 15- 100 man months mới có kiểu kiểm định thế này. Hiểu cũng đơn giản là dự án phải dài hơn, và team đi sâu hệ thống và hệ thống đủ ổn định mới xử lý kiểu kiểm định này được.


👉Còn hệ thống đang chạy sẽ hơi khó làm cái này đơn giản là:

- Hệ thống đang chạy sẽ chặn/mã hoá và không cho multi request/ddos quá nhiều, và họ có nhiều cách để làm việc này

- Nếu bạn muốn perform/loadtest hệ thống đang chạy bắt buộc bạn phải bỏ các chặn/mã hoá như ý trên nêu


Một số sếp cứ bắt nhân viên tester phải đi làm việc trên: load test một hệ thống ngoài đời. Nhưng sẽ không mấy thành công. Trừ phi bạn build lại, bỏ các security về network và hạn chế băng thông lẫn các hệ thống bảo vệ ddos thi đó mới thực thi được.


Trong thời gian trên, mình cũng có trải nghiệm là: rất khó mô phỏng các trải nghiệm load hoặc tạo volume data nặng. Ý muốn nói là: không phù hợp với cơ sở hạ tầng và ngoài đời đôi khi khó đoán, ví dụ:


👉 Rất ít bạn làm loadtest/performance biết rằng, khi bạn đang đưa nhiều request vào sẽ bị tình trạng session này gối lên session kia, thread nọ đè lên thread kia. Cái này do dev lập trình chưa đủ cao siêu để xử lý hoặc engine server chưa đủ "ngầu" để giải quyết <--- đổ cho lỗi phần mềm và dev


👉 Rất ít bạn làm loadtest/performance biết rằng biệc chất liệu làm ống dẫn từ northbridge xuốn southbridge mainboard và ram của server phải đủ mạnh và đủ ổn định của cả 1triệu sessions thì thread mới xử lý xong và đủ nhanh như coder viết <--- đổ lỗi cho phần cứng


👉90% testers làm load/performance KHÔNG BIẾT là: việc chạy load/perform ở công ty cần vào lúc rảnh băng thông, khi và chỉ khi họ làm từ lúc 6h tối tới 7h sáng hôm sau ở VN. Khi đó thì 99% tester đang xxx với ng yêu, hay uống trà sữa, ngủ hoặc cho con bú


👉70% testers chưa rõ việc một con máy 8g ram thì cần bao nhiêu VU (virtual users) cỡ trung bình 1 thread ---> bạn cứ tính 4mb ram 1 VU là ra.


👉 99% testers làm kiểu kiểm định này sẽ mô phỏng trên một nhóm server hoặc cơ sở hạ tầng rồi ánh xạ sang hệ thống thật


.

.

.


Xin đưa ra mấy quan tâm từ việc thiết kế case, lẫn thực hiện test rồi làm báo cáo cho kiểu kiểm định này.


1. Phần thiết kế:

👉 Vậy các chiến lược performance test có thể nói vắn tắt như sau:

+ Khi bạn cần check tốc độ nội tại ứng dụng: dùng performance profile. Cái này làm luôn được sau Unit Test hoặc Tích hợp

+ Khi bạn cần check logic chạy chịu tải ra sao khi có nhiều dữ liệu: vol test. Chỉ làm đươc khi logic đã xong

+ Khi bạn cần check phần cứng hoạt động tốt ở nhiều điều kiện: stress test. Khi bạn có môi trường gần đúng với khách hàng

+ Khi bạn cần check khả năng phục vụ người dùng ổn định thế nào: load test. Khi có đủ thông tin yêu cầu loại này từ khách hàng.

.

.

Cụ thể

- Như hình là một gợi ý (từ tester D.Suffian), mặc dù việc thiết kế ...mình cho là DỄ, và nó chỉ mất time để chạy và ra được kết quả: https://www.researchgate.net/publication/288835218_The_Design_and_Execution_of_Performance_Testing_Strategy_for_Cloud-based_System


- Hoặc bạn có thể tìm hiểu case mình viết: mẫu case load test từ:  dathoc.net/booktest, quy trình test, biểu mẫu, cho performance test


- Case sẽ không coi là PASS hay FAILED nếu bạn không định nghĩa ra giới hạn, nếu bạn không biết thì tham khảo tương tự (bấm giờ, so cpu ram với hệ tương tự); hỏi khách hàng:

- Vậy Bạn cần học cách Hỏi và Đặt câu hỏi cho khách hàng về performance test thế nào cho phù hợp


👉 Nếu khách hàng nêu rõ quan điểm thời lượng thì rất dễ kiểu như sau:

- Chúng tôi thường dùng hệ thống lúc 10 sáng và 15h chiều

- Điểm đỉnh có 5k người dùng, 3k order

- Còn đôi khi 1 tháng 1 lần có 50k order trong 1 giờ


... đó như thế thì rất rõ phải không fans?


👉 Nếu khách hàng không biết thì bạn có thể dùng các KPI sau:

- Bạn có thể tham khảo mẫu case load test từ RUP - IBM Rational Unified Process:  dathoc.net/booktest, quy trình test, biểu mẫu, cho performance test


+ Hãy đặt câu hỏi cho khách hàng hoặc team phải tự tìm hiểu: tốc độ phản hồi từ 4 giây tới 12 giây cho 1 request. Và bao nhiêu ? + khi nào có lượng  X request?

+ Hãy đặt câu hỏi cho khách hàng hoặc team phải tự tìm hiểu: tốc độ request lại server với 1 lần request thực tế < 20 lần/giây

+ Hãy đặt câu hỏi cho khách hàng hoặc team phải tự tìm hiểu: lượng ngốn tài nguyên 1 request nhỏ (cho multi request) nên là 50 bytes - 200kb

+ Hãy đặt câu hỏi cho khách hàng hoặc team phải tự tìm hiểu: tốc độ giải phóng ram: cần là nhanh nhất có thể.


👉  Cần CHÚ Ý:

- Cần rất nhiều case cho performance profile, tức là việc bạn tìm ra nút cổ chai của từng hàm, class cú gọi. Mà cái này đáng nhẽ coder làm nhưng họ không làm. Ví dụ demo ở đây:


https://www.youtube.com/watch?v=_UCgzKPOHrU&list=PL751V5I3RIDFe8PeizjvWGWmcGBIdK1EY&index=2


- Việc tạo stress case khi các bạn là fan film HD thì rất dễ với volume test, hoặc bạn thạo multithread và truy vấn SQL thì rất có lợi cho control data với hệ thống, control session nào, bao nhiêu tới hệ thống.


- Đôi khi hơi mệt với kiểu case ngoài đời thực kiểu như: 20% VU login, 30% VU đang list hàng, 5% đang order, 40% đang


- Mệt hơn với kiểu ép xung như là: chạy 1000 VU trong 3 giây (thực tế mình đã test trên máy 12 core 16 gb ram với 100k thread mất 19 giây)


- Một số bạn tester hơi luống cuống kiểu cần lưu session (login) cho 1 VU để share cho 999VU còn lại để chạy tiếp


- Một số case cần monitor máy trạm vì tester muốn lấy đồ thị lên xuống ram cpu, hiện các tool hiện đại đã support rất tốt



Sách tham khảo bạn có thể xem:


(tham khảo link dưới)

- Beyond Performance test - series 14 artc

- .NET per & optimization


.

.

.


2. Phần thực hiện:


- Thời mình mình chưa thấy (có lẽ tới giờ) có tester nào làm từ 6h tối tới 2-3h sáng... như mình (khi đó quãng tháng 8,9 năm 2009). Bây giờ mình chưa quan sát thấy, chắc có nhiều hơn. Nên bạn cần chuẩn bị sức khoẻ tốt khi làm nghề kiểm định phần mềm.


👉 Cần học/thạo việc quan sát và theo dõi các thread chạy, cần xem ngay log vì sao thread bị đá ra, nếu không hiểu đưa ngay cho TechLead. Đưa thêm thông tin ram, và cpu của toàn hệ thống mà phán đoán chỗ nào logic code tồi.


- Với các tester mới làm thì nên chú ý máy test nên là riêng và ko nên cài/chạy cái gì lạ (anti virus, facebook, zalo, web, tiktok....) trên đó ngoài OS cơ bản và hệ thống cần test.


- Ví dụ cách mình loadtest với một hệ thống của Honda Vĩnh Phúc, bạn xem từ phút thứ 33:


https://www.youtube.com/watch?v=D8mPFH5P0Ho&list=PL751V5I3RIDFwgpwl-wvBEDsOd8w5TB75&index=2


- Có thể sau 5-10 lần chạy bạn phát hiện ra cần 20 lần chạy nữa. Sau 20 lần chạy bạn lại thấy cần thêm 10 lần nữa.... đấy ý đầu tôi nói là vì sao performace/loadtest cần một tester sức khoẻ dẻo dai là vậy. Và khó có tester nào làm đc cái này một cách đầy đủ.


👉 Lưu ý với những LỖI bị coi là kiến trúc hệ thống sẽ ảnh hưởng tới tốc độ thu thập: Xem các bài viết về Beyond performance testing



3. Làm báo cáo:


👉 Lưu ý số 1 là: có thể có rất nhiều báo cáo, song bạn nên nêu lên trên trang đầu những lần chạy, những phát hiện bạn cho là biến dị và không chấp nhận được (kể cả team chấp nhận, kể kả bạn không biết vì sao nó failed....) vì thường những ng quản lý có lý thuyết quản trị khác với devteam.


👉 Cần nêu rõ thông số:

- Khi nào hệ thống ở mức tài nguyên nào thì ... die

- Khi nào hệ thống ở mức tài nguyên nào thì phục vụ ??? request bao nhiêu, mỗi request phản hồi bao nhiêu giây


👉 Còn 90% báo cáo là từ các lần chạy hoặc tool chạy tự generate ra, bạn chỉ việc collect thôi.


.

.

.


Vậy bạn có thể kết hợp các gợi ý trên để tạo ra những performance/load test case hoàn hảo hơn.


Gluk!


--------------------------------

SÁCH - TẠP CHÍ - TÀI LIỆU ĐÚC KẾT KINH NGHIỆM làm về SOFTWARE TESTING cần tham khảo: dathoc.net/booktest

Bạn muốn thông thạo hơn việc viết thiết kế testcase, sử dụng công cụ automation test HERA để auto test, các framework Appium, TestNG, xin tham gia FREE tại: youtube.com/c/TesterPRO/

By: dathoc.net/cv