Tổng kết chiến dịch kiểm thử hiệu năng spiderum

Ntech_Developers · January 25, 2021, 4:45pm

Đây là bài tổng kết của series kiểm thử hiệu năng lần này. Một lần nữa hi vọng loạt bài này giúp ích được các bạn một chút nào đó.

Series Kiểm Thử Hiệu Năng Spiderum:

Bài viết thứ nhất: Lỗ hổng spiderum hay chỉ là tính năng – Cái nhìn từ một Performance testing

Bài viết thứ 2: Performance testing – Nó là cái quái gì mà lại dùng nó để vọc phá spiderum

Bài viết thứ 3: Chiến lược kiểm thử hiệu năng Spiderum - Kịch bản chức năng

Bài viết thử 4: Chiến lược kiểm thử hiệu năng Spiderum - Đừng vội! hãy hiểu bản chất vấn đề với API Testing

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

Bài viết thứ 6: Bắt đầu chiến dịch – Phát hiện một số tính năng nhỏ với Manual Testing

Bài viết thứ 7: Bắt đầu chiến dịch – Tôi kiểm thử API của spiderum như thế nào

Bài viết thứ 8: Bắt đầu chiến dịch – Cách lấy dữ liệu spiderum thông qua Postman

Bài viết thứ 9: Jmeter và thế giới Performance Testing

Bài viết thứ 10: Record script spiderum – Cách mà tôi tạo ra script performance test

Bài viết thứ 11: Update script jmeter spiderum – Cách mà tôi tổ chức cấu trúc kịch bản kiểm thử

Bài viết thứ 12: Update script jmeter spiderum - Script Performance Test không phải chỉ record là xong! Còn nhiều thứ hay ho lắm

Bài viết thứ 13: Update script jmeter spiderum - Làm sao để có thể chuẩn bị data cho cả triệu CCUs

Bài viết thứ 14: Bắt đầu chạy kiểm thử hiệu năng - Chúc mừng bạn đã nằm trong tầm ngắm của tôi

Bài viết thứ 15: Báo cáo kiểm thử hiệu năng spiderum và phân tích báo cáo sau khi chạy script

Bài viết thứ 16: Tổng kết chiến dịch kiểm thử hiệu năng spiderum

Tổng hợp Issue

Issue phát hiện từ manual test:

Không xác thực khi quên mật khẩu
Không có duyệt bài hoặc chặn post bài auto
Không thể xem thêm tin nổi bật
Không chặn upvote/downvote liên tục
Đếm số lượng upvote trong thông báo sai chỉ dựa trên số lượng click upvote chứ không tính trung bình
Trả lời bình luận đệ quy quá nhiều khiến vỡ layout
Chức năng tìm kiếm không thực sự là chứa từ tìm kiếm
Mặc dù xóa hết bình luận rồi nhưng trong trang cá nhân vẫn đếm được số bình luận và số trang

Issue phát hiện từ api test:

End point /api/v2/message/requestSingleChat không có phân trang, khi có lượng chat nhiều call sẽ bị timeout
End point /api/v1/post/create có thể tạo bài viết bao nhiêu tag tùy thích

Issue phát hiện từ performance test:

Response time cao ở bước kiểm tra home page, kiểm tra domain topUser hay không
Tỉ lệ lỗi ở bước tìm kiếm và upvote/downvote còn cao
Độ lệch giữa lần đầu login và các lần sau còn cao

Toàn bộ script, data test, report cho chiến dịch lần này mình đều để hết trên github cá nhân của mình nhé!

library · January 26, 2021, 12:54am

Cảm ơn Nam nhé!

Tớ có theo dõi series này từ trước, và đánh giá cá nhân của tớ thì series này rất có ích về performance test, khi đưa ra toàn bộ quá trình từ đánh giá, phân tích, lên chiến lược, lập kế hoạch, thu thập dữ liệu, implement, tiến hành thực thi và tổng hợp kết quả, một cách thực tiễn. Việc thực hiện performance test chưa bao giờ là task dễ dàng.

Tuy nhiên, có một vài điểm trừ mà tớ sẽ để ra ở đây, không phải để chỉ trích bài viết, mà để những bạn khác có cái nhìn tốt hơn về performance test:

Có vẻ như cậu đã thực hiện performance test trên production chứ không phải trên 1 môi trường biệt lập. Đây không phải best practice, sẽ tốt hơn nếu performance test được thực hiện trên production-like environment hơn là production thật, vì nó ảnh hưởng tới dịch vụ, và cậu cũng có thể cô lập được test của cậu khỏi nhiễu.
Ngoài ra, tớ không chắc admin bên đó có cho phép không, nhưng sẽ hơi thô lỗ nếu như mình generate high load lên website của họ mà không xin phép.
Với performance test, sẽ tốt hơn nếu cậu tổ chức theo dõi nhiều chỉ số hơn các chỉ số mà jmeter có.
Thường cậu cần cân nhắc phải theo dõi tất cả các resource của các component trong hệ thống: CPU, Memory, Load average, database metrics, web server metrics, etc…
Các chỉ số đó sẽ giúp cậu biết được cách hệ thống phản ứng lại với high load như thế nào, và nó có rất nhiều ý nghĩa.
Tớ hiểu vì mình là bên thứ 3, nên rất khó để thực hiện việc này. Tuy nhiên, với những bạn cần phải làm performance test trong tương lai, tớ hi vọng các bạn ấy cân nhắc cả điều này.

Nhìn chung, đây là series rất tốt, cung cấp rất nhiều insight về performance test. Rất cảm ơn cậu đã chia sẻ series này, và mong chờ những series mới khác tới từ cậu!

Ntech_Developers · January 30, 2021, 9:13am

Vấn đề thứ nhất, do mình không phải đội ngũ phát triển spiderum, Nếu bạn theo dõi bài đầu tiên thì mình đã xin phép admin để thực nghiệm kiểm thử trên site product hiện tại rồi. Có report và báo dev bên spriderum rồi nhé nên bạn yên tâm
Vấn đề thứ hai hình như bạn đang hiểu sai về idea testing và idea monitor system rồi thì phái. Những thông số và công nghệ bạn nêu chỉ dành cho đội ngũ phát triển monitor thôi. Còn bên kiểm thử sẽ chỉ report một số thông số theo chiến lược ban đầu họ đề ra độc lập khách quan không dính dáng gì đến đội ngũ phát triển cả.
Dù sao thì cũng cám ơn bạn đã góp ý. Mình sẽ có loạt bài khác về những ý của bạn đề cập nhưng không phải là testing mà mà monitor system.
Thanks!

library · February 1, 2021, 1:18am

Cảm ơn cậu về phản hồi nhé.

Về vấn đề này:

Tớ nghĩ cậu đang refer tới:

Đầu tiên, phải nói là mình đã email cho admin về vấn đề này khá là lâu rồi. Nhưng có thể đây là một tính năng của Spiderum thì sao (Câu nói kinh điển của dân dev “Đây không phải là bug, đây là tính năng”).

Tớ thực ra đã hiểu nó sang việc cậu email nói với admin bên đó về lỗ hổng performance, chứ chưa nói về thỏa thuận thực hiện performance test.
Do đó, tớ có 1 đề nghị nho nhỏ, có khi cậu nên cân nhắc đề cập cụ thể thêm về thỏa thuận thực hiện performance test với bên spiderum trong bài viết, nếu cậu không muốn ai đó hiểu nhầm giống tớ

Ừ, tớ có đọc thấy cậu đề cập tới việc đó Nên tớ hoàn toàn yên tâm về điều này.
Ngoài ra, tớ đoán cậu cũng đồng ý với việc nên test trên production-like environment hơn là production luôn, do cậu không đề cập gì tới nó

Hm, tớ hiểu quan điểm của cậu, và nó hoàn toàn đúng. Tuy nhiên, tớ không nhầm giữa 2 khái niệm đó, tớ đang nói tới sự liên quan giữa 2 khái niệm đó
Để tớ giải thích rõ hơn nhé!

Theo kinh nghiệm có giới hạn của cá nhân tớ, performance test được dùng để xác nhận performance của hệ thống, thường là:

Xác nhận hoạt động của hệ thống trong điều kiện high load (đối với load test).
Xác nhận bottleneck của hệ thống trong điều kiện cực đoan (đối với stress test).

Do đó, ngoài response time và throughput (2 thông tin này thực chất là symptom), bọn tớ cần thông tin resource đã được sử dụng như thế nào. Từ đó bọn tớ mới biết vấn đề ở đâu, và có giải pháp cải thiện performance. Giống như việc khám bệnh, khi cậu thấy bệnh nhân ho, mất vị giác, mệt mỏi, sốt (symptom), cậu cần các thông số về sự xuất hiện của virus trong dịch nước bọt, hay thậm chí đo nồng độ kháng thể, để xác định bệnh nhân có bị Covid hay không.
Đó là lý do tớ có đề cập tới việc cần monitor hệ thống khi thực hiện performance test. Thường thì performance test có cost rất cao, nên nếu tổ chức thực hiện, thu thập thêm dữ liệu là điều nên làm (không thì chúng ta phải thực hiện 1 test nhiều lần ).

Tớ cũng muốn đề cập chút về responsibility khi thực hiện performance test. Như cậu có chỉ ra, các thông tin resource chỉ có thể lấy được thông qua monitor, và kỹ sư là người duy nhất làm việc đó, vậy nên, trong kinh nghiệm hạn chế của cá nhân tớ, performance test được lên kế hoạch và thực thi bởi kỹ sư luôn. Nếu có 1 bên khác chịu trách nhiệm viết script và thực thi (thường là QC, khi cần test trên UI là chủ yếu), bên kỹ sư sẽ là người:

Đưa ra mục tiêu test. Họ là người duy nhất hiểu tính cách và cấu trúc của hệ thống.
Đưa ra các thông số thông thường trên production, thường là traffic. Họ là người duy nhất biết điều này qua monitor.
Thiết lập production-like environment. Họ là người duy nhất làm được.
Khi thực hiện test, họ phải monitor để lấy dữ liệu. Đây đồng nghĩa với việc họ và bên thứ 3 cần liên kết chặt chẽ trong quá trình test.
Tổng hợp và phân tích dữ liệu.

Vậy nên, series của cậu chia sẻ đứng ở quan điểm của bên thứ 3, và nó hoàn toàn đúng. Đề cập của tớ nói về monitor là từ quan điểm của engineer, và tớ muốn mở rộng để các bạn engineer tương lai khác có cái nhìn toàn diện hơn về vấn đề này.

Oh, tớ khá mong chờ loạt bài đó đó

Cuối cùng, tớ vẫn là fan của loạt bài performance test của cậu. Như tớ có đề cập, đây là series có lẽ là hoàn thiện và thực tiễn nhất về từng bước thực hiện performance test, và thú vị ở chỗ cậu có đưa ra từng vấn đề khi trong quá trình thực hiện, và đưa ra giải pháp cho chúng, một cách rất tỉ mỉ.
Một lần nữa, cảm ơn chia sẻ của cậu tới diễn đàn, và mong có thể được thấy series mới của cậu về system monitoring!