“Kiểm thử chức năng so với kiểm thử tự động” là một trong những so sánh phổ biến nhất trong QA, nhưng nó được xây dựng trên một sai lầm. Hai thuật ngữ này không đối lập nhau. Chúng mô tả những điều hoàn toàn khác biệt, và bạn có thể có cái này mà không có cái kia, hoặc có cả hai cùng lúc. Coi chúng như một lựa chọn, chức năng *hoặc* tự động, sẽ dẫn các nhóm xây dựng chiến lược kiểm thử sai lầm.
Hướng dẫn này sẽ gỡ rối hai thuật ngữ, giải thích hai trục riêng biệt mà chúng thuộc về, và chỉ ra vị trí của mỗi thuật ngữ trong một quy trình kiểm thử API thực tế.
Sai lầm phân loại
Sự nhầm lẫn đến từ việc so sánh câu trả lời cho hai câu hỏi khác nhau.
Kiểm thử chức năng trả lời: chúng ta đang kiểm thử cái gì? Nó kiểm thử xem phần mềm có hoạt động đúng như mong đợi hay không, các tính năng, hành vi, đầu ra.
Kiểm thử tự động trả lời: chúng ta đang chạy kiểm thử như thế nào? Nó chạy kiểm thử bằng các công cụ phần mềm thay vì một người thực hiện các bước thủ công.
Những điều này là độc lập. “Bạn kiểm thử cái gì” và “bạn chạy nó như thế nào” là hai trục riêng biệt. Một kiểm thử chức năng có thể chạy thủ công hoặc tự động. Một kiểm thử tự động có thể kiểm tra hành vi chức năng hoặc hành vi phi chức năng như hiệu suất. Vì vậy, sự so sánh thực sự không phải là chức năng so với tự động; đó là hai chiều khác nhau mà tình cờ được nhắc đến cùng nhau.
Một khi bạn hiểu điều đó, câu hỏi “chúng ta nên thực hiện kiểm thử chức năng hay kiểm thử tự động?” sẽ không còn ý nghĩa nữa. Những câu hỏi đúng là: chúng ta nên kiểm thử cái gì, và những kiểm thử nào trong số đó chúng ta nên tự động hóa?
Kiểm thử chức năng là gì
Kiểm thử chức năng xác minh rằng mỗi tính năng của một ứng dụng hoạt động theo yêu cầu của nó. Nó thường là hộp đen: người kiểm thử kiểm tra đầu vào và đầu ra mà không nhìn vào mã bên trong. Cung cấp một đầu vào cho tính năng, quan sát đầu ra, so sánh nó với những gì yêu cầu nói rằng sẽ xảy ra.
Đối với API, kiểm thử chức năng có nghĩa là xác nhận rằng một điểm cuối trả về dữ liệu đúng, mã trạng thái đúng và phản hồi lỗi đúng. Liệu POST /orders có tạo một đơn hàng không? Nó có từ chối một payload không hợp lệ bằng mã 400 không? Phản hồi có khớp với lược đồ được tài liệu hóa không? Đó là các kiểm tra chức năng, và chúng dựa trên các xác nhận API so sánh phản hồi thực tế với phản hồi mong đợi.
Điểm mạnh của kiểm thử chức năng là sự liên quan trực tiếp: nó kiểm tra điều mà người dùng thực sự quan tâm, liệu tính năng có hoạt động hay không. Giới hạn của nó là phạm vi. Kiểm thử chức năng đơn thuần không nói lên điều gì về tốc độ, độ ổn định dưới tải, hoặc bảo mật. Một điểm cuối có thể hoàn hảo về chức năng nhưng vẫn sụp đổ dưới lưu lượng truy cập; khoảng trống đó là điều mà kiểm thử hiệu suất bao gồm. Kiểm thử chức năng là cần thiết, nhưng nó không phải là toàn bộ bức tranh.
Đối lập với kiểm thử chức năng là kiểm thử phi chức năng, hiệu suất, tải, bảo mật, khả năng sử dụng, đó mới là đối tác chính xác của thuật ngữ, chứ không phải “kiểm thử tự động”.
Kiểm thử tự động là gì
Kiểm thử tự động sử dụng các công cụ và tập lệnh để thực thi kiểm thử và kiểm tra kết quả, thay vì một người nhấp chuột qua các bước thủ công. Bạn định nghĩa một kiểm thử một lần, với các đầu vào và kết quả mong đợi của nó, và công cụ sẽ chạy nó theo yêu cầu, theo lịch trình, hoặc mỗi khi có thay đổi mã.
Đối lập với kiểm thử tự động là kiểm thử thủ công, nơi một con người thực hiện từng bước. Đó mới là đối tác chính xác của thuật ngữ.
Giá trị của tự động hóa là tính nhất quán và khả năng mở rộng. Một cỗ máy chạy kiểm thử thứ một nghìn chính xác như kiểm thử đầu tiên và không bao giờ mệt mỏi. Nó giúp kiểm thử hồi quy đủ rẻ để chạy trên mỗi commit. Chi phí của nó là các kiểm thử tự động phải được viết và bảo trì, và chúng không thể thực hiện đánh giá, chúng chỉ kiểm tra những gì bạn đã bảo chúng mong đợi. Một phân tích sâu hơn có trong bài kiểm thử tự động là gì.
Điều quan trọng là, tự động hóa là một cơ chế phân phối, không phải là một loại kiểm thử. Bạn tự động hóa *một loại* kiểm thử nào đó, chức năng, hiệu suất, bảo mật. “Kiểm thử tự động” tự thân nó không nói lên điều gì đang được kiểm tra.
Hai trục kết hợp như thế nào
Đặt hai trục lại với nhau và bạn sẽ có bốn loại thực tế, tất cả đều tồn tại trong thực tế.
| Chức năng | Phi chức năng | |
|---|---|---|
| Thủ công | Một người kiểm thử nhấp qua quy trình thanh toán để xác nhận nó hoạt động | Một người kiểm thử đánh giá liệu giao diện người dùng có cảm giác phản hồi nhanh hay không |
| Tự động | Một tập lệnh gọi một điểm cuối và xác nhận phản hồi là đúng | Một kiểm thử tải tạo ra 500 người dùng ảo và đo độ trễ |
Mọi ô đều là một loại kiểm thử hợp pháp, phổ biến. Ô trên cùng bên trái, kiểm thử chức năng thủ công, là điều mà hầu hết mọi người hình dung khi họ nghe “kiểm thử”. Ô dưới cùng bên trái, kiểm thử chức năng tự động, là phần lớn những gì một bộ kiểm thử API hiện đại là: các tập lệnh hoặc kịch bản tự động kiểm tra các tính năng. Cột bên phải là công việc phi chức năng, cũng được thực hiện theo cả hai cách.
Vì vậy, các quyết định có ý nghĩa không phải là “chức năng hay tự động”. Chúng là:
- Kiểm thử hành vi nào: cả chức năng và phi chức năng đều cần được bao phủ.
- Tự động hóa kiểm thử nào: những kiểm thử ổn định, lặp đi lặp lại, có giá trị cao; để kiểm thử thăm dò và kiểm tra nặng về đánh giá ở dạng thủ công.
Một kiểm thử có thể nằm ở bất kỳ ô nào, và một chiến lược lành mạnh sử dụng cả bốn.
Vị trí của điều này trong kiểm thử API
Kiểm thử API là nơi hai trục thẳng hàng rõ ràng nhất, bởi vì API rất phù hợp với kiểm thử chức năng tự động.
Một API có một hợp đồng rõ ràng, các yêu cầu và phản hồi có cấu trúc, và không có giao diện người dùng để hiển thị. Điều đó làm cho hành vi chức năng của nó dễ kiểm tra bằng tập lệnh và dễ xác nhận một cách chính xác. Vì vậy, đối với API, phần lớn kiểm thử chức năng nên được tự động hóa. Có ít lý do để gửi lại thủ công cùng một yêu cầu và nhìn chằm chằm vào phản hồi hàng trăm lần khi một công cụ có thể làm điều đó trên mỗi commit.
Một cách tiếp cận kiểm thử API thực tế trông như thế này. Các kiểm tra chức năng, mã trạng thái, thân phản hồi, tuân thủ lược đồ, dạng lỗi, được viết dưới dạng trường hợp kiểm thử và nhóm thành kịch bản kiểm thử. Những kịch bản đó chạy tự động, trên mỗi thay đổi, thông qua CI/CD. Các kiểm tra phi chức năng, tải và hiệu suất, cũng chạy tự động, theo lịch trình. Nỗ lực thủ công dành cho kiểm thử thăm dò và để xác thực rằng API thực sự giải quyết vấn đề, công việc xác thực mà sự đánh giá, chứ không phải tập lệnh, phải thực hiện.
Những gì nên tự động hóa và những gì nên giữ thủ công
Khi nhìn rõ hai trục, chúng ta sẽ đi đến câu hỏi thực sự quan trọng: trong số tất cả các kiểm thử chức năng bạn có thể chạy, những kiểm thử nào xứng đáng được tự động hóa? Tự động hóa mọi thứ là lãng phí, và tự động hóa những thứ sai lầm sẽ tạo ra một bộ kiểm thử chậm, dễ vỡ. Một vài quy tắc có thể giúp ích.
Tự động hóa những cái lặp đi lặp lại và ổn định. Một kiểm tra chức năng mà bạn sẽ chạy trên mỗi commit trong hai năm tới là một ứng cử viên tự động hóa hoàn hảo. Chi phí viết nó được hoàn lại hàng trăm lần. Kiểm thử hồi quy, các kiểm tra xác nhận các tính năng cũ vẫn hoạt động, là trường hợp rõ ràng nhất.
Ưu tiên tự động hóa các đường dẫn có giá trị cao trước. Luồng đăng nhập, thanh toán, các điểm cuối API cốt lõi, bất cứ điều gì mà sự thất bại của nó là một sự cố nghiêm trọng, nên được tự động hóa sớm. Đây là những kiểm thử bạn không thể bỏ qua dưới áp lực thời hạn, và tự động hóa loại bỏ sự cám dỗ.
Không tự động hóa những cái hiếm hoặc không ổn định. Một kiểm tra bạn sẽ chạy hai lần không đáng để viết tập lệnh. Một tính năng vẫn thay đổi hàng ngày sẽ làm hỏng kiểm thử của nó hàng ngày; hãy đợi cho đến khi nó ổn định. Tự động hóa quá sớm một mục tiêu đang di chuyển chỉ tạo ra tiếng ồn bảo trì.
Giữ kiểm thử thăm dò thủ công. Kiểm thử tự động chỉ tìm thấy những gì bạn đã bảo chúng tìm kiếm. Một con người tự mày mò phần mềm theo những cách không có kịch bản sẽ tìm ra lỗi mà không ai đoán trước được. Công việc này cũng là kiểm thử chức năng, và nó nên được cố ý giữ thủ công.
Giữ kiểm tra dựa trên đánh giá thủ công. Liệu một thông báo lỗi có thực sự hữu ích hay không, liệu một quy trình làm việc có cảm giác mạch lạc hay không, liệu API có thực sự giải quyết vấn đề của người dùng hay không, những điều này cần một người. Không có xác nhận nào có thể nắm bắt được chúng.
Kết quả là một sự phân chia có chủ ý: một bộ kiểm thử chức năng tự động lớn bao gồm các đường dẫn ổn định, quan trọng, lặp đi lặp lại, và một nỗ lực thủ công nhỏ hơn, liên tục tập trung vào khám phá và đánh giá. Các nhóm tự động hóa một cách có suy nghĩ sẽ nhận được phản hồi nhanh chóng mà không có một bộ kiểm thử dễ vỡ; các nhóm tự động hóa mọi thứ cuối cùng chỉ bảo trì kiểm thử thay vì triển khai sản phẩm.
Xây dựng kiểm thử API chức năng tự động trong Apidog
Apidog được xây dựng cho kiểm thử API chức năng tự động mà không cần viết tập lệnh. Bạn định nghĩa một điểm cuối, thêm các xác nhận trực quan cho trạng thái, các trường trong thân phản hồi, lược đồ và thời gian phản hồi, sau đó nhóm các yêu cầu thành các kịch bản kiểm thử. Những kịch bản đó chạy theo yêu cầu hoặc trong một pipeline CI, tự động thực hiện các kiểm tra chức năng và báo cáo chính xác xác nhận nào đã thất bại.
Bởi vì cùng một không gian làm việc cũng chạy kiểm thử tải, bạn bao gồm cả hai trục, chức năng và phi chức năng, tự động, tại một nơi. Kịch bản chức năng bạn xây dựng để kiểm tra tính đúng đắn trở thành kiểm thử tải bạn chạy để kiểm tra hiệu suất. Tải xuống Apidog để xây dựng một bộ kiểm thử chức năng tự động cho một API bạn đã có.
Các câu hỏi thường gặp
Kiểm thử tự động có phải là một loại kiểm thử chức năng không? Không. Kiểm thử tự động là một cách chạy kiểm thử. Kiểm thử chức năng là một danh mục những gì bạn kiểm thử. Một kiểm thử tự động có thể là chức năng hoặc phi chức năng; một kiểm thử chức năng có thể là thủ công hoặc tự động.
Kiểm thử chức năng có thể tự động hóa không? Có, và đối với API thì thường là nên như vậy. Kiểm thử chức năng tự động, các tập lệnh hoặc kịch bản kiểm tra các tính năng trên mỗi thay đổi, là cốt lõi của một bộ kiểm thử API hiện đại.
Đối lập thực sự của kiểm thử chức năng là gì? Kiểm thử phi chức năng: hiệu suất, tải, bảo mật và khả năng sử dụng. Chúng kiểm tra các thuộc tính khác ngoài việc liệu một tính năng có tạo ra đầu ra đúng hay không.
Mọi kiểm thử chức năng có nên được tự động hóa không? Không. Tự động hóa các kiểm tra ổn định, lặp đi lặp lại, có giá trị cao. Giữ kiểm thử thăm dò và xác thực dựa trên đánh giá thủ công, vì tự động hóa không thể quyết định liệu một thứ gì đó thực sự tốt hay không, chỉ có thể quyết định liệu nó có khớp với một kỳ vọng hay không.
Một nhóm nên bắt đầu từ đâu? Với kiểm thử API chức năng tự động. Chúng nhanh chóng, ổn định và bao phủ logic cốt lõi. Từ đó, thêm kiểm thử phi chức năng tự động và kiểm thử thăm dò thủ công.
Kiểm thử tự động có thay thế người kiểm thử thủ công không? Không. Nó thay thế phần công việc lặp đi lặp lại của họ, chạy lại các kiểm tra giống nhau, để người kiểm thử có thể tập trung vào kiểm thử thăm dò, các trường hợp biên và đánh giá liệu phần mềm có thực sự tốt hay không. Những nhiệm vụ đó cần con người, và chúng có giá trị cao hơn việc tự tay nhấp qua danh sách kiểm tra hồi quy.
Cùng một kiểm thử có thể vừa chức năng vừa tự động không? Có, và hầu hết các kiểm thử API đều chính xác là như vậy: kiểm thử chức năng tự động. Một tập lệnh gọi một điểm cuối và xác nhận phản hồi là đúng sẽ kiểm tra chức năng và chạy tự động. Hai nhãn này mô tả các khía cạnh khác nhau của cùng một kiểm thử, không phải là một sự mâu thuẫn.