Những khó khăn trong Performance Testing
Vào năm thứ 2 khi tôi làm ở công ty cũ, cũng tức là lúc product chính bước qua tuổi thứ 2, tôi bắt đầu nhận ra rằng chúng tôi có thiếu sót trong vấn đề hiệu năng. Không phải chúng tôi không làm, nhưng cái chúng tôi làm có vẻ không đưa được thông tin mà khách hàng của chúng tôi, các local countries cần. Dù bên tôi luôn đưa những thông số về kết quả API test, nhưng các country vẫn không hài lòng và cần test lại. Sau đây, tôi sẽ cố gắng list ra những vấn đề khi làm performance testing của 1 core Back End, và phải đưa nó sửa dụng cho nhiều nước, nhiều system khác nhau.
1/ Môi trường làm Performance test và môi trường production(s) quá khác biệt
Có thể nói là một trời 1 vực.
Môi trường test có resource rất hữu hạn. Không chỉ vậy, service còn được build trên máy ảo. Ví dụ 30 service đều nằm trên cùng 1 máy ảo. Trong khi môi trường thật thì khác hẳn, có thể không dùng máy ảo, có thể cấu hình rất mạnh, hoặc có thể chia services trên nhiều máy ảo.
Vấn đề là, cả chúng tôi cũng không chắc được. Có 6 country, mỗi 1 country có thể có cấu hình khác nhau cho từng service, cho cả system. Vậy, chúng tôi phải test dựa trên cấu hình nào, của local country nào? Đó cũng là một phần lý do mà một số feature thì local country A có thể complain nhưng local country B thì không.
Những khiếm khuyết trên dẫn đến rất nhiều vấn đề. Ví dụ tôi test API A, cho 100 ccu, với cấu hình của performance environment là ( 100GB ram, 1TB ổ cứng,... cho 32 service), kết quả ra 100tps, thì chúng tôi, hay là cả khách hàng của chúng tôi cũng không tài nào suy ra được rằng, thế nếu nó chạy trên môi trường thật của Philipine ( ví dụ 300 GB ram, 5TB ổ cứng,...), thì nó sẽ được bao nhiêu tps??
Để counter cho việc này, chúng tôi học theo những sản phẩm lớn, test nó trên một cấu hình định nghĩa sẵn (Performance env) và quy định rằng đó là "cấu hình chuẩn" và trả lời nếu bạn có cấu hình cao hơn thì expect bạn sẽ có response tốt hơn, còn bao nhiêu thì không biết. Cũng giống như khi Microsoft, hay Atlassian đưa Software cho người dùng, họ cũng chỉ có thể đưa recommendation settings vậy. Họ chả hơi đâu mà trả lời cho từng người dùng là "Ê, máy tui cấu hình thế này, thế expect tốc độ là thế nào?"
Tuy nhiên, khách hàng của chúng tôi vẫn chưa hài lòng, vì vấn đề tiếp theo sau đây:
2/ Việc làm API test của chúng tôi, khách hàng cho rằng là "không đúng thực tế" của họ
Với một đội làm API test, chúng tôi có nhiệm vụ kiểm tra hiệu năng của từng API mình tạo ra. Chiến lược test của chúng tôi là test từng API một, độc lập với nhau, để khi ra kết quả, chúng ta biết đó là hiệu năng của 1 chính API đó, nếu trong hệ thống tại khoảng thời điểm đó chỉ gọi cho nó.
Khách hàng của chúng tôi không hài lòng chút nào. Họ nhận ra rằng ở trên môi trường thật của họ, tại 1 thời điểm người ta không chỉ call 1 API, mà nó là tổng hợp của nhiều flow, nhiều API. Và họ yêu cầu rằng chúng tôi cần phải kiểm đúng cái tình hình thực tại của họ, cái mà tôi cho rằng là không hợp lý cho 1 đội chuyên làm core, đưa ra những API cần thiết và không quan tâm đến việc local country sẽ combine những API đó thế nào thành flow của họ, hay tình hình kinh doanh của họ cần những gì.
Việc test hiệu năng của toàn bộ hệ thống, để đáp ứng cho nhu cầu của business, cần phải làm ở "đầu cuối", tức là local country, những người đã tích hợp những API của chúng tôi thành 1 flow riêng biệt duy nhất của họ, và dựa vào yêu cầu kinh doanh của đất nước họ, nên là người làm. Tuy nhiên, vẫn là câu chuyện sếp chiều ý khách hàng và tôi sẽ không nói nhiều ở đây...
3/ Yêu cầu cho test hiệu năng chưa bao giờ rõ ràng
Đây là một trong những điều làm tôi buồn cười nhất trong 3.5 làm sản phẩm và nghiêm túc test performance. Thực ra nó cũng diễn ra trong suốt 10 năm tôi làm QC/QA: vì một lý do nào đó, người ta nghĩ rằng Perfomance và Security là "Technical requirement", và công việc này là công việc nội bộ của technical team, không liên can gì đến PO hay đội business cả.
Nghĩ lại, suy nghĩ này đến từ việc Performance và Security được coi là "non-functional requirement". Nhưng, non-functional requirement cũng phải từ PO và từ business yêu cầu mà ra. Nó không thể tự quyết bởi Tech team được. Thế nhưng, trong 3.5 năm làm việc, tôi đã nhìn thấy thấy không biết bao nhiêu câu chuyện hài khi mà các manager nghĩ rằng nó là "technical requirement" và chỉ nên được quản lý bởi Tech
Một PO nọ, đưa ra 1 business mới, và yêu cầu là sau khi làm xong phải có test hiệu năng. Nhưng khi chúng tôi hỏi những input đầu vào để có 1 performance test đúng đắn ví dụ như:
"Bạn kỳ vọng 1 ngày sẽ có khoảng bao nhiêu giao dịch là tối đa/tối thiểu?"
"Bạn kỳ vọng là ở giờ cao điểm, thì hệ thống chúng ta sẽ cần phải đủ đáp ứng cho bao nhiêu ccu (concurent user)?"
"Bạn kỳ vọng là khi hệ thống quá tải, thì chúng ta nên làm gì? Hoặc nếu có giao dịch bị fail, thì tỷ lệ fail bạn chấp nhận được là bao nhiêu?"
...
Không trả lời được. Thậm chí có người còn nói với tôi rằng "cái này thì để Tech team quyết chứ! Test ra được bao nhiêu thì report bấy nhiêu!"
Xin thưa với các vị rằng, chỉ riêng chuyện là "test với bao nhiêu ccu?", hay là "data sẵn có trong system nên là bao nhiêu khi call API?", nếu để Tech team quyết là đã sai rồi, vì nó nên dựa vào tình hình business, theo từng nhu cầu của từng flow mà có lượng ccu kỳ vọng khác nhau.
Có thời, tất cả các API chúng tôi test đều test với 20-30 ccu cả. Từ Login cho đến Payment, cho đến deactive user,... Nói chung là buồn cười!
Sự thiếu hiểu biết của PO về những kỳ vọng của business trong vấn đề performance hay security chính là một trong nguyên nhân chính dẫn đến việc Test hay implement feature có nghĩ đến việc handle Performance và Security trở nên mờ nhạt trong 1 thời gian dài. Ngoài cái đã kể trên, còn 1 nguyên nhân, mà tôi cho là hệ quả của điều trên sau đây:
4/ Performance improve + performance testing được coi là technical tasks
Tất nhiên, khi PO đã mù tịt và không tham gia vào việc thiết kế và đánh giá Performance, nghiễm nhiên nếu bạn muốn cải thiện, nó chỉ còn là "improvement tasks" của Tech team. Và tôi biết công ty tôi cũng như những công ty khác, "Tech improvements" có độ ưu tiên rất thấp so với features.
Nhận ra điều đó, cuối năm thứ 2 và đầu năm thừ 3 tôi cố gắng hết sức để bắt buộc team phải kêu gọi PO đồng ý làm và ưu tiên performance task. Như là core Payment, không có performance đồng nghĩa với chết. Tôi bảo QA member của mình liên tục nhắc nhở PO và lead add task performance vào sprint. Hối thúc PO tạo requirement và Epic cho performance task. Tôi cũng liên tục nhắc nhở các manager để có thông điệp từ trên xuống. Tuy nhiên, việc lơ là đến từ rất nhiều phía, bao gồm PO, lead và cả QA member của tôi, khi họ thấy rằng lời nói của họ bị bỏ đi trong sprint. Đã có những cuộc tranh cãi nảy lửa giữa tôi và member của tôi về việc nên ép PO add performance task vào sprint hay không. Một thời gian dài sau, những động thái rõ rệt mới xuất hiện, trong hoàn cảnh Client đã feedback rất nhiều về performance, và những thay đổi càng ngày càng khó hơn trong hệ thống.
5/ Focus vào Performance test để tìm ra vấn đề
Performance test, hay ít nhất là kiểu mà tôi đã áp dụng cho công ty tôi test, xét cho cùng cũng chỉ là End2End test. Nó bộc lộ nhiều nhược điểm:
- Test rất mất thời gian. Cái này đặc biệt đúng với Performance test. Prepare data thì lâu. 1 thời điểm thì chỉ có thể chạy 1 performance test, rồi phải xóa data mới test cái khác đúng đắn được.
- Test xong thìtìm ra nguyên nhân rất lâu.
- Tìm ra nguyên nhân thì sửa lại rất tốn thời gian ( ví dụ sửa câu SQL, hay change table cho những trường hợp nghiêm trọng).
- Rất rất khó để làm regression, vì Automation hoàn toàn cho Performance test là 1 thử thách rất lớn, đặc biệt là step prepare và xóa data.
Trong quá trình implementation, thiết kế table, đánh index, thiết kế SQl cũng như số lần hit API vào hệ thống cho 1 flow,.... Những việc đó hoàn toàn có thể review và giảm thiểu risk, nhưng những công việc này thường bị lơ là.
Lời kết
Mình đã cố gắng truyền tải những vấn đề mình gặp phải khi trực tiếp làm Performance test cho 1 hệ thống lớn, support nhiều country. Vấn đề nằm ở cả technical, communication và cả process, đôi khi là cả những kỳ vọng sai lệch của khách hàng. Hy vọng bạn có thể rút ra được bài học từ những việc tôi đã làm và thành công cho project của bạn.
Nguồn: Nguyễn Dương Hải, Quality Director