Phần mềm hoạt động tốt không giống với phần mềm hoạt động tốt dưới tải. Một tính năng có thể vượt qua mọi bài kiểm thử chức năng, được phát hành sạch sẽ, và sau đó bị sập ngay khi lưu lượng truy cập thực tế ập đến. Kiểm thử hiệu năng là nguyên tắc thu hẹp khoảng cách đó: nó đo lường cách một hệ thống hoạt động khi bận rộn, không chỉ liệu nó có đúng khi không hoạt động hay không.
Hướng dẫn này giải thích kiểm thử hiệu năng là gì, các loại chính, các chỉ số định nghĩa kết quả và cách nó phù hợp với quy trình kiểm thử hiện đại.
Kiểm thử hiệu năng là gì
Kiểm thử hiệu năng đánh giá tốc độ, độ ổn định và khả năng mở rộng của một hệ thống dưới một khối lượng công việc xác định. Nó không hỏi “tính năng này có hoạt động không?” Nó hỏi “nó nhanh đến mức nào, nó có thể chịu đựng được bao nhiêu, và điều gì xảy ra khi nó đã đủ?”
Sự khác biệt đó rất quan trọng. Kiểm thử chức năng và kiểm thử hiệu năng trả lời các câu hỏi khác nhau và tìm ra các lỗi khác nhau. Một điểm cuối đăng nhập có thể trả về mã thông báo chính xác mỗi lần nhưng vẫn mất bốn giây để thực hiện dưới tải. Các bài kiểm thử chức năng vượt qua; người dùng bỏ đi. Kiểm thử hiệu năng là thứ làm lộ ra vấn đề thứ hai đó.
Kết quả của kiểm thử hiệu năng không phải là một kết quả đơn giản là đạt hay không đạt. Nó là một hồ sơ: ở tải này, hệ thống phản hồi nhanh như thế này, duy trì thông lượng này, và lỗi theo cách này một khi bị đẩy quá giới hạn. Hồ sơ đó là thứ cho phép một nhóm lập kế hoạch năng lực, đặt các mức dịch vụ thực tế và phát hiện các lỗi hồi quy trước khi phát hành.
Các loại kiểm thử hiệu năng chính
Kiểm thử hiệu năng là một tập hợp các loại kiểm thử, mỗi loại áp dụng tải theo một hình thức khác nhau để trả lời một câu hỏi khác nhau.
Kiểm thử đường cơ sở (Baseline testing) chạy hệ thống dưới tải bình thường, dự kiến và ghi lại kết quả. Đường cơ sở này là tham chiếu mà mọi bài kiểm thử sau này so sánh. Không có nó, bạn không thể biết liệu một con số là tốt, xấu hay chỉ đơn giản là khác biệt.
Kiểm thử tải (Load testing) áp dụng lưu lượng truy cập cao điểm dự kiến và xác nhận hệ thống hoạt động tốt: thời gian phản hồi nằm trong giới hạn ngân sách, lỗi gần như bằng không. Nó xác thực rằng hệ thống tồn tại qua một ngày bận rộn bình thường.
Kiểm thử căng thẳng (Stress testing) cố tình vượt quá năng lực, tăng tải cho đến khi hệ thống suy giảm hoặc lỗi. Mục tiêu là tìm ra điểm giới hạn và quan sát chế độ lỗi. Suy giảm duyên dáng (graceful degradation), chậm hơn nhưng vẫn phục vụ, là chấp nhận được; mất dữ liệu hoặc lỗi dây chuyền thì không.
Kiểm thử đột biến (Spike testing) áp dụng một sự tăng đột ngột, mạnh mẽ về tải và sau đó giảm xuống. Nó mô phỏng các đợt giảm giá chớp nhoáng, các sự kiện tin tức và các đợt bùng nổ khác. Một hệ thống được điều chỉnh cho lưu lượng truy cập ổn định vẫn có thể thất bại trong một đợt tăng đột biến vì nó không thể mở rộng quy mô đủ nhanh.
Kiểm thử năng lực (Capacity testing) tìm ra tải tối đa mà hệ thống có thể xử lý trong khi vẫn đạt được các mục tiêu của nó. Câu trả lời là một con số cụ thể, được sử dụng trực tiếp để lập kế hoạch năng lực và ngưỡng tự động mở rộng quy mô.
Kiểm thử ngâm (Soak testing), còn được gọi là kiểm thử ổn định hoặc độ bền, duy trì một tải vừa phải trong một thời gian dài để phát hiện các lỗi chậm: rò rỉ bộ nhớ, cạn kiệt tài nguyên, chậm dần. Những lỗi này vô hình trong các lần chạy ngắn và chỉ xuất hiện sau nhiều giờ.
Hầu hết các nhóm đều chạy kiểm thử đường cơ sở, tải và ngâm như tiêu chuẩn, và thêm kiểm thử căng thẳng và đột biến cho các hệ thống có lưu lượng truy cập cao hoặc không thể đoán trước.
Các chỉ số định nghĩa kết quả
Một bài kiểm thử hiệu năng chỉ hữu ích khi bạn đọc được các chỉ số từ nó.
Thời gian phản hồi (Response time) là khoảng thời gian từ yêu cầu đến phản hồi. Luôn đọc nó dưới dạng phân phối. Giá trị trung bình dễ gây hiểu lầm; một giá trị trung bình khỏe mạnh có thể che giấu một phần trăm thứ 99 tồi tệ hơn mười lần. Phần đuôi chậm là điều mà người dùng thực sự nhận thấy và phàn nàn.
Thông lượng (Throughput) là khối lượng công việc được hoàn thành trên một đơn vị thời gian, thường là yêu cầu mỗi giây. Nó được tính bằng tổng số yêu cầu chia cho thời gian kiểm thử và thể hiện năng lực thực sự của hệ thống.
Đồng thời (Concurrency) là số lượng người dùng hoặc kết nối đồng thời. Năng lực hệ thống thường được nêu là mức độ đồng thời mà thời gian phản hồi vượt quá ngưỡng chấp nhận được.
Tỷ lệ lỗi (Error rate) là tỷ lệ phần trăm các yêu cầu thất bại dưới tải. Một hệ thống vẫn nhanh nhưng bắt đầu thất bại các yêu cầu ở mức độ đồng thời cao thì chưa đạt; tốc độ mà không có độ tin cậy thì không phải là hiệu năng.
Sử dụng CPU và bộ nhớ (CPU and memory utilization) giải thích tại sao các con số khác lại thay đổi. Nếu độ trễ tăng trong khi CPU bị kẹt ở 100%, hệ thống bị giới hạn bởi tính toán. Nếu độ trễ tăng trong khi CPU không hoạt động, nút thắt cổ chai nằm ở hạ nguồn, thường là cơ sở dữ liệu, một khóa hoặc một phụ thuộc bên ngoài.
Một kết quả hoàn chỉnh đọc giống như một câu: ở mức độ đồng thời này, thông lượng đạt đỉnh ở đây, thời gian phản hồi ở phần trăm thứ 95 là thế này, tỷ lệ lỗi là thế kia, và máy chủ bị giới hạn bởi tài nguyên này.
Kiểm thử hiệu năng phù hợp với quy trình ở đâu
Kiểm thử hiệu năng từng là một cổng duy nhất gần cuối dự án, được chạy một lần trước khi ra mắt bởi một nhóm chuyên gia. Mô hình đó thất bại đối với các hệ thống được phát hành liên tục, vì hiệu năng suy giảm với gần như mọi thay đổi. Một truy vấn mới, một tích hợp bổ sung, một cột không được lập chỉ mục, mỗi thứ âm thầm làm tăng độ trễ mà không bài kiểm thử chức năng nào phát hiện được.
Mô hình tốt hơn coi hiệu năng giống như tính đúng đắn: được kiểm tra liên tục, với một ngân sách. Xác định ngân sách thời gian phản hồi và tỷ lệ lỗi cho các đường dẫn quan trọng. Chạy một bài kiểm thử tải nhẹ trong CI/CD để một lỗi hồi quy làm hỏng bản dựng ở yêu cầu kéo. Dành các lần chạy căng thẳng và ngâm nặng cho kiểm thử trước phát hành theo lịch trình, nơi thời gian chạy dài hơn của chúng là chấp nhận được.
Đối với hầu hết các hệ thống, nơi có giá trị cao nhất để kiểm thử hiệu năng là lớp API. Các API mang logic cốt lõi, chúng nhanh và xác định để gọi, và chúng không có giao diện người dùng không ổn định để phải vật lộn. Kiểm thử API dưới tải mang lại những con số đáng tin cậy với chi phí thấp; kiểm thử hiệu năng API bao gồm cách tiếp cận tập trung đó một cách chi tiết. Giữ các bài kiểm thử hiệu năng bên cạnh các bài kiểm thử API chức năng có nghĩa là mọi thay đổi đều được kiểm tra cả tính đúng đắn và tốc độ cùng một lúc.
Các lỗi phổ biến trong kiểm thử hiệu năng
Kiểm thử hiệu năng rất dễ thực hiện theo cách tạo ra những câu trả lời tự tin, sai lầm. Một vài lỗi xuất hiện lặp đi lặp lại.
Kiểm thử trên cơ sở hạ tầng không thực tế. Một bài kiểm thử tải trên máy tính xách tay của nhà phát triển, hoặc trên môi trường thử nghiệm với một phần nhỏ tài nguyên của sản xuất, tạo ra những con số vô nghĩa. Kiểm thử trên cơ sở hạ tầng khớp với sản xuất càng gần càng tốt với khả năng chi trả của bạn.
Bỏ qua hiệu ứng khởi động. Nhiều hệ thống chậm trong vài giây đầu tiên của một lần chạy trong khi bộ nhớ cache đầy và các nhóm kết nối mở. Việc đo lường trạng thái khởi động lạnh và trạng thái ổn định cùng nhau tạo ra một giá trị trung bình gây hiểu lầm. Bỏ qua cửa sổ khởi động hoặc báo cáo riêng.
Đọc giá trị trung bình thay vì phần trăm. Lỗi này đáng lặp lại vì nó rất phổ biến. Thời gian phản hồi trung bình 200 ms có thể che giấu phần trăm thứ 99 là ba giây. Giá trị trung bình mô tả một yêu cầu mà không ai thực sự thực hiện; các phần trăm mô tả người dùng thực.
Sử dụng dữ liệu không thực tế. Việc kiểm thử mọi yêu cầu bằng cùng một id người dùng hoặc cùng một sản phẩm có nghĩa là cơ sở dữ liệu phục vụ mọi thứ từ bộ nhớ cache. Lưu lượng truy cập thực tế trải rộng trên tập dữ liệu, chạm vào các hàng lạnh và các lần bỏ lỡ bộ nhớ cache. Thay đổi dữ liệu kiểm thử cho phù hợp.
Kiểm thử một điểm cuối riêng lẻ. Người dùng thực di chuyển qua các quy trình làm việc: đăng nhập, duyệt, tìm kiếm, thanh toán. Việc tấn công một điểm cuối duy nhất bỏ qua sự tranh chấp xuất hiện khi một số điểm cuối cạnh tranh cùng một cơ sở dữ liệu và nhóm kết nối. Kiểm thử các kịch bản đa bước thực tế, không chỉ các cuộc gọi riêng lẻ.
Coi bài kiểm thử là một lần và xong. Một bài kiểm thử hiệu năng trước khi ra mắt duy nhất sẽ trở nên lỗi thời ngay khi tính năng tiếp theo được phát hành. Hiệu năng suy giảm liên tục, vì vậy bài kiểm thử cũng phải chạy liên tục.
Tránh sáu lỗi này là phần lớn điều phân biệt một bài kiểm thử hiệu năng cung cấp thông tin cho một quyết định với một bài kiểm thử tạo ra một dấu kiểm màu xanh lá cây an ủi nhưng vô nghĩa.
Chạy kiểm thử hiệu năng với Apidog
Apidog tích hợp kiểm thử tải vào cùng một không gian làm việc được sử dụng để thiết kế API và kiểm thử chức năng, vì vậy việc kiểm tra hiệu năng không yêu cầu một công cụ riêng biệt hoặc một bản sao riêng biệt của định nghĩa API.
Bạn chọn một điểm cuối hoặc một kịch bản kiểm thử đa bước, xác nhận nó hoạt động tốt về mặt chức năng, sau đó chạy nó dưới một số lượng người dùng ảo được cấu hình trong một khoảng thời gian nhất định. Apidog tăng tải dần dần và báo cáo phần trăm thời gian phản hồi, thông lượng và tỷ lệ lỗi trực tiếp, để bạn có thể thấy mức độ đồng thời chính xác mà hiệu năng thay đổi. Đối với tải vượt quá một máy, kịch bản được xuất sang JMeter trong khi vẫn giữ nguyên định nghĩa.
Vì cùng một kịch bản kiểm thử phục vụ cả các lần chạy chức năng và hiệu năng, bạn duy trì một tạo phẩm thay vì hai. Tải xuống Apidog để tạo hồ sơ cho một điểm cuối mà bạn đã có.
Các câu hỏi thường gặp
Sự khác biệt giữa kiểm thử hiệu năng và kiểm thử chức năng là gì? Kiểm thử chức năng kiểm tra xem phần mềm có tạo ra kết quả đúng hay không. Kiểm thử hiệu năng kiểm tra mức độ nhanh chóng và đáng tin cậy mà nó thực hiện dưới tải. Cả hai đều cần thiết; không cái nào thay thế cái kia.
Loại kiểm thử hiệu năng nào tôi nên chạy trước? Đường cơ sở, sau đó là tải. Đường cơ sở cung cấp cho bạn một tham chiếu trong điều kiện bình thường; kiểm thử tải xác nhận hệ thống sống sót qua lưu lượng truy cập cao điểm dự kiến. Sau đó thêm kiểm thử căng thẳng, đột biến và ngâm.
Tại sao sử dụng phần trăm thay vì thời gian phản hồi trung bình? Giá trị trung bình bị kéo về giữa và che giấu phần đuôi chậm. Phần trăm thứ 95 và 99 tiết lộ những gì các yêu cầu kém may mắn nhất trải nghiệm, và phần đuôi đó là điều người dùng cảm nhận.
Kiểm thử hiệu năng có thể tự động hóa được không? Có. Một bài kiểm thử tải nhẹ chạy tốt trong CI trên mỗi thay đổi, với một ngân sách xác định làm hỏng bản dựng khi có lỗi hồi quy. Các bài kiểm thử căng thẳng và ngâm nặng hơn thường được lên lịch thay vì chạy trên mỗi commit.
Khi nào trong chu kỳ phát triển nên bắt đầu kiểm thử hiệu năng? Sớm hơn hầu hết các nhóm nghĩ. Bạn không thể có được các con số độ trễ cuối cùng mà không có cơ sở hạ tầng thực tế, nhưng bạn có thể thiết lập ngân sách và viết các kịch bản kiểm thử trong quá trình thiết kế. Chạy một bài kiểm thử tải cơ bản ngay khi một điểm cuối có chức năng sẽ phát hiện các vấn đề khi chúng còn dễ khắc phục.
Ai chịu trách nhiệm về kiểm thử hiệu năng? Trong các nhóm hiện đại, đó là trách nhiệm chung. Các nhà phát triển chạy các kiểm tra tải nhẹ trên các thay đổi của riêng họ; QA sở hữu các kịch bản kiểm thử và ngân sách rộng hơn; vận hành hoặc SRE cung cấp cơ sở hạ tầng giống sản xuất và các chỉ số phía máy chủ. Coi đó là công việc của một chuyên gia là cách các vấn đề hiệu năng đến được sản xuất.
Một bài kiểm thử hiệu năng nên chạy trong bao lâu? Đủ lâu để vượt qua cửa sổ khởi động và đạt trạng thái ổn định, thường là vài phút đối với một bài kiểm thử tải. Các bài kiểm thử ngâm chạy trong nhiều giờ hoặc nhiều ngày theo thiết kế, vì mục đích của chúng là để phát hiện sự suy giảm chậm mà các lần chạy ngắn bỏ lỡ.