CHƯƠNG 3: CÁC RỦI RO ĐƯỢC GIẢI QUYẾT NHỜ KIỂM THỬ HIỆU SUẤT
Bài đăng này đã không được cập nhật trong 7 năm
MỤC TIÊU
- Hiểu được tốc độ, khả năng mở rộng và ổn định của phần mềm nhìn từ góc độ kiểm thử hiệu suất
- Hiểu được cách kiểm thử hiệu suất được sử dụng để giảm thiểu rủi ro liên quan đến tốc độ, khả năng mở rộng, và sự ổn định.
- Hiểu được các khía cạnh của những rủi ro mà kiểm thử hiệu suất không giải quyết thỏa đáng.
TỔNG QUAN Kiểm thử hiệu suất là không thể thiếu để quản lý những rủi ro kinh doanh có ý nghĩa nhất định. Ví dụ: nếu trang web của bạn không thể xử lý được lượng truy cập mà nó nhận được, khách hàng của bạn sẽ đi mua hàng ở một nơi khác. Ngoài việc xác định những rủi ro rõ ràng, kiểm thử hiệu suất có thể là một cách hữu hiệu để phát hiện nhiều vấn đề tiềm năng khác. Trong khi kiểm thử hiệu suất không thay thế các loại kiểm thử khác, nó có thể biết được thông tin liên quan đến khả năng sử dụng, tính năng, bảo mật, và hình ảnh công ty trong khi những loại kiểm thử khác khó khăn để có được. Nhiều doanh nghiệp và người kiểm thử hiệu suất thấy được giá trị của nó để nghĩ về những rủi ro mà thực hiện kiểm thử có thể giải quyết về ba mặt: tốc độ, khả năng mở rộng, và sự ổn định.
SỬ DỤNG CHƯƠNG NÀY NHƯ THẾ NÀO Sử dụng chương này để tìm hiểu về những rủi ro hiệu suất, các loại kiểm thử hiệu suất liên quan đến những rủi ro và các chiến lược để giảm thiểu những rủi ro. Để nhận được nhiều nhất từ chương này:
- Sử dụng "Summary Matrix" để hiểu rõ về các loại kiểm thử khác nhau và những rủi ro sẽ được giải quyết.
- Sử dụng các loại rủi ro khác nhau để hiểu chiến lược liên quan có thể giúp bạn xác định phương pháp kiểm thử tốt nhất cho từng tình hình cụ thể
MA TRẬN TÓM TẮT NHỮNG RỦI RO ĐƯỢC GIẢI QUYẾT BỞI CÁC LOẠI KIỂM THỬ HIỆU SUẤT
| Các loại kiểm thử hiệu suất | Các loại rủi ro được giải quyết |
|---|---|
| Capacity (sức chứa) | Công suất của hệ thống có thể đáp ứng được khả năng hoạt động kinh doanh dưới điều kiện tải trọng bình thường hoặc cao điểm hay không? |
| Component | --- Nó có đáp ứng được kỳ vọng hay không? --- Nó có tối ưu hóa được hay không? --- Các vấn đề gây ra bởi thành phần này là gì? |
| Endurance | --- Có được thực hiện nhất quán theo thời gian hay không? --- Có vấn đề nào mà chưa được phát hiện hay không? --- Có sự can thiệp bên ngoài hay không? |
| Investigation | --- Xu hướng nào đang được sử dụng nhiều? --- Sẽ dựa vào cái gì để so sánh trong tương lai? |
| Load | --- Bao nhiêu người dùng là được phục vụ trước khi những vấn đề không mong muốn xảy ra khi ứng dụng chịu phải một khối lượng công việc cụ thể nào đó? --- Có bao nhiêu dữ liệu mà cơ sở dữ liệu có thể xử lý? --- Các thành phần mạng có đầy đủ? |
| Smoke | --- Cấu hình hiện tại có đáp ứng được các kiểm tra hiệu suất bổ sung? --- Loại kiểm thử hiệu suất nào nên được thực hiên sau đó? --- Build này có tốt hơn build trước hay không? |
| Spike | --- Những gì sẽ xảy ra nếu tải vượt quá tải trọng của hệ thống? --- Các loại thất bại nào mà chúng ta nên lên kế hoạch trước? --- Chúng ta nên tìm kiếm những chỉ số gì? |
| Stress | --- Điều gì sẽ xảy ra nếu tải trọng vượt quá tải trọng dự kiến? --- Các loại thất bại nào mà chúng ta nên lên kế hoạch trước? --- Chúng ta nên tìm kiếm những gì số gì để can thiệp vào trước khi thất bại |
| Unit | --- Đoạn code này có hợp lý hay không? --- Đã bao giờ sử dụng vừa đúng ngân sách hoạt động hay chưa? --- Đoạn code này có hoạt động như dự kiến dưới tải hay không? |
| Validation | --- Ứng dụng có đáp ứng được mục đích và yêu cầu? --- Version này có tốt hơn version trước đó hay không? --- Có vi phạm thỏa thuận hợp đồng nếu phát hành hay không? |
| Các Rủi Ro | Các loại kiểm thử hiệu suất | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Capacity | Component | Endurance | Investigation | Load | Smoke | Spike | Stress | Unit | Validation | |
| Speed-related risks | ||||||||||
| User satisfaction | x | x | x | x | x | |||||
| Synchronicity | x | x | x | x | x | x | x | |||
| Service Level Agreement (SLA) violation | x | x | x | x | ||||||
| Response time trend | x | x | x | x | x | x | ||||
| Configuration | x | x | x | x | x | x | ||||
| Consistency | x | x | x | x | x | x | ||||
| Scalability-related risks | ||||||||||
| Capacity | X | x | x | x | x | x | ||||
| Volume | X | x | x | x | x | x | ||||
| SLA violation | x | x | x | x | ||||||
| Optimization | x | x | x | x | ||||||
| Efficiency | x | x | x | x | ||||||
| Future growth | x | x | x | x | x | |||||
| Resource consumption | x | x | x | x | x | x | x | x | x | x |
| Hardware / environment | x | x | x | x | x | x | x | x | ||
| Service Level Agreement (SLA) violation | x | x | x | x | x | x | ||||
| Stability-related risks | ||||||||||
| Reliability | x | x | x | x | x | x | x | |||
| Hardware / environment | x | x | x | x | x | x | ||||
| Failure mode | x | x | x | x | x | x | x | x | ||
| Slow leak | x | x | x | x | x | |||||
| Service Level Agreement (SLA) violation | x | x | x | x | x | x | x | x | ||
| Recovery | x | x | x | x | x | x | ||||
| Data accuracy and security | x | x | x | x | x | x | x | x | ||
| Interfaces | x | x | x | x | x | x | x |
RỦI RO LIÊN QUAN ĐẾN TỐC ĐỘ
Rủi ro liên quan đến tốc độ không chỉ giới hạn về sự hài lòng của người sử dụng, mặc dù đó là những gì mà hầu hết mọi người nghĩ đến đầu tiên. Tốc độ là một yếu tố có lợi cho kinh doanh và những rủi ro liên quan đến dữliệu. Một số rủi ro liên quan đến tốc độ mà kiểm thử hiệu suất có thể giải quyết được bao gồm:
- Ứng dụng đủ nhanh để đáp ứng người dùng?
- Doanh nghiệp có thể xử lý và thu thập dữ liệu từ ứng dụng trước khi nó lỗi thời?
- Ứng dụng có thể đưa ra các thông tin mới nhất
- Có dịch vụ nào đáp ứng được trong thời gian nhanh nhất trước khi lỗi xảy ra?
Chiến lượt giảm nhẹ các rủi ro liên quan đến tốc độ
Các chiến lược sau đây có tác dụng giảm thiếu các rủi ro liên quan đến tốc độ:
- Đảm bảo rằng các yêu cầu hiệu suất và mục đích đại diện cho nhu cầu và mong muốn của người dùng, không phải của người khác.
- So sánh tốc độ với cái version trước và với các ứng dụng cạnh tranh.
- Thiết kế các kiểm thử hiệu suất với các loại dữ liệu, phân phối và khối lượng người dùng như thực tế. Bạn có thể cho phép dữ liệu lưu trữ trong cơ sở dữ liệu và máy chủ hoặc tạo ra các khối dữ liệu trước khi thực hiện kiểm tra tải.
- Sử dụng kết quả của kiểm thử hiệu suất giúp các bên liên quan quyết định cấu trúc và thông báo.
- Cố gắng lấy được phản hồi của người dùng đối với hệ thống trong lúc nó đang ở tải cao
- Bao gồm các khoản thời gian giao dịch quan trọng trong kiểm thử hiệu suất
- Đảm bảo rằng một số trường hợp kiểm thử hiệu suất được thực hiện định kì
- Đo tốc độ dưới các điều kiện khác nhau, các mức tải và kịch bản hỗn hợp. Xác nhận rằng các dữ liệu chính xác đang được hiển thị và lưu trữ trong kiểm thử hiệu suất của bạn
RỦI RO LIÊN QUAN ĐẾN KHẢ NĂNG MỞ RỘNG Rủi ro mở rộng không chỉ ở số lượng người dùng mà ứng dụng có thể hỗ trợ, nó còn là khối lượng dữ liệu mà ứng dụng có thể chứa, quy trình cũng như khả năng để xác định khi một ứng dụng đang vận hành hết khả năng. Rủi ro mở rộng thông thường có thể được giải quyết thông qua kiểm thử hiệu suất bao gồm:
- Các ứng dụng có thể cung cấp thời gian phản ứng phù hợp và chấp nhận được cho toàn bộ người dùng.
- Các ứng dụng có thể lưu hết tất cả các dữ liệu được thu thập?
- Có những cách nào chỉ ra rằng việc áp dụng đó tiếp cận công suất đỉnh cao?
- Ứng dụng vẫn an toàn khi sử dụng nhiều?
- Chức năng có bị tổn hại khi sử dụng nhiều?
Chiến lược giảm nhẹ các rủi ro liên quan đến khả năng mở rộng Các chiến lược sau đây có giá trị trong việc giảm thiểu các rủi ro liên quan đến khả năng mở rộng:
- So sánh tốc độ theo các tải trọng khác nhau (Hãy nhớ rằng người dùng không quan tâm có bao nhiêu người sử dụng khác đang sử dụng)
- Kiểm tra tải trọng ở cả hai thời gian bình thường và cao điểm
- Tiến hành kiểm thử hiệu suất với các loại dữ liệu, phân phối và khối lượng tương tự như những người dùng trong thực tế. Bạn có thể cho phép dự liệu tích lũy trong cơ sở dữ liệu, bổ sung tạo ra khối lượng dữ liệu trước khi thực hiện kiểm tra tải.
- Sử dụng kết quả của kiểm thử hiệu suất giúp các bên liên quan quyết định cấu trúc và thông báo.
- Làm sao cho các trường hợp kiểm thử hiệu suất có ý nghĩa hơn và đúng với yêu cầu thực tế
- Khi bạn tìm thấy một giới hạn khả năng mở rộng, từng bước giảm tải và kiểm tra lại để giúp bạn xác định được chỉ số và có các biện pháp đối phó.
- Xác định tính chính xác của chức năng ứng dụng theo các tải trọng khác nhau bằng cách kiểm tra các mục cơ sở dữ liệu được tạo ra hoặc xác nhận nội dung trở lại để đáp ứng với yêu cầu sử dụng cụ thể.
- Tiến hành kiểm thử hiệu suất vượt tải cao điểm dự kiến và quan sát hành vi của người sử dụng đại diện cho các bên liên quan và truy cập vào ứng dụng trong và sau khi thực hiện kiểm thử.
TÓM TẮT Hầu như tất cả những rủi ro liên quan đến ứng dụng và kinh doanh đều có thể được giải quyết thông qua kiểm thử hiệu suất, bao gồm cả sự hài lòng của người sử dụng và khả năng của ứng dụng để đạt được mục tiêu kinh doanh. Nói chung, những rủi ro mà kiểm thử hiệu suất giả quyết được phân loại về tốc độ, khả năng mở rộng và sự ổn định. Tốc độ thường là một mối quan tâm của người dùng cuối cùng, khả năng mở rộng là một mối quan tâm kinh doanh và ổn định là một mối quan tâm kỹ thuật hoặc bảo trì. Xác định các rủi ro liên quan đến dự án và các chiến lược giảm thiểu liên quan đến nơi thực hiện thử nghiệm có thể được sử dụng gần như được xem là một thực tế có giá trị và tiết kiệm thời gian.
All rights reserved
