Kiểm thử thủ công hoạt động tốt cho đến khi nó không còn hiệu quả nữa. Một nhà phát triển có thể nhấp qua một vài điểm cuối trước khi phát hành. Một nhóm vận hành năm mươi dịch vụ trên hàng chục môi trường thì không thể, và vào ngày họ cố gắng, một thứ gì đó chưa được kiểm thử sẽ được triển khai. Kiểm thử tự động là câu trả lời cho vấn đề mở rộng quy mô đó: hãy để máy móc thực hiện các kiểm tra lặp đi lặp lại, mọi lúc, để con người tập trung vào những việc quan trọng.
Hướng dẫn này giải thích thử nghiệm tự động là gì, nó hữu ích ở đâu và không hữu ích ở đâu, đồng thời hướng dẫn từng bước thiết lập thử nghiệm API tự động trong Apidog.
Thử nghiệm tự động là gì
Thử nghiệm tự động có nghĩa là sử dụng phần mềm để chạy các thử nghiệm và kiểm tra kết quả, thay vì một người thực hiện từng bước thủ công. Bạn xác định một thử nghiệm một lần: đầu vào, hành động và kết quả mong đợi. Từ đó trở đi, một 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ã, và báo cáo kết quả đạt hoặc không đạt mà không cần ai giám sát.
Sự thay đổi không chỉ là tốc độ. Đó là sự nhất quán. Một người kiểm thử thủ công chạy cùng một kiểm tra năm mươi lần sẽ thực hiện nó hơi khác nhau mỗi lần và sẽ mệt mỏi vào lần thứ bốn mươi. Một thử nghiệm tự động chạy lần thứ năm mươi chính xác như lần đầu tiên. Khả năng lặp lại đó là sản phẩm thực sự của tự động hóa.
Thử nghiệm tự động áp dụng trên toàn bộ ngăn xếp: kiểm thử đơn vị (unit tests) cho các chức năng, kiểm thử tích hợp (integration tests) cho các thành phần, kiểm thử UI (UI tests) cho các giao diện và kiểm thử API (API tests) cho các điểm cuối. Kiểm thử API thường là nơi có giá trị cao nhất để bắt đầu, vì API ổn định, gọi nhanh và chứa đựng logic nghiệp vụ cốt lõi. Một thử nghiệm API chạy trong mili giây và không phải đối phó với trình duyệt không ổn định.
Tại sao các nhóm tự động hóa thử nghiệm
Kiểm thử thủ công không thể mở rộng quy mô. Mỗi điểm cuối mới bổ sung các kiểm tra. Mỗi môi trường nhân chúng lên. Vượt quá một kích thước nhất định, việc kiểm thử thủ công toàn diện trước mỗi lần phát hành trở nên không thể về mặt vật lý, vì vậy các công đoạn bị cắt giảm một cách âm thầm.
Lỗi hồi quy lọt qua mà không có nó. Một thay đổi trong một dịch vụ có thể phá vỡ hợp đồng của ba dịch vụ khác. Chỉ một bộ thử nghiệm chạy lại mọi thứ sau mỗi thay đổi mới có thể phát hiện điều đó, và chỉ tự động hóa mới giúp việc “chạy lại mọi thứ” đủ rẻ để thực hiện liên tục.
Các thử nghiệm trở thành tài sản có thể tái sử dụng. Một thử nghiệm thủ công sẽ hết giá trị ngay khi nó chạy xong. Một thử nghiệm tự động được viết một lần và chạy hàng nghìn lần. Chi phí ban đầu cao; lợi ích tích lũy theo thời gian.
Phản hồi nhanh chóng. Khi các thử nghiệm chạy tự động trong một pipeline, nhà phát triển biết được trong vòng vài phút rằng một thay đổi đã làm hỏng cái gì đó, trong khi bối cảnh vẫn còn mới. Một lỗi được tìm thấy trong môi trường production tốn nhiều chi phí để sửa hơn rất nhiều so với cùng một lỗi được tìm thấy trong CI.
Con người làm việc hiệu quả hơn. Tự động hóa không thay thế người kiểm thử. Nó giải phóng họ khỏi việc nhấp chuột lặp đi lặp lại để họ có thể thực hiện kiểm thử thăm dò, tìm kiếm các trường hợp biên và công việc về khả năng sử dụng, những điều mà máy móc không giỏi.
Những gì thử nghiệm tự động không giải quyết được
Tự động hóa không miễn phí, và việc giả vờ ngược lại sẽ dẫn đến thất vọng.
Các thử nghiệm tự động tốn công sức để viết và công sức để duy trì. Khi API thay đổi, các thử nghiệm cũng thay đổi theo. Một bộ thử nghiệm lỗi thời không đạt vì những lý do sai lệch còn tệ hơn là không có bộ thử nghiệm nào, bởi vì nhóm sẽ học cách bỏ qua các bản build báo lỗi.
Tự động hóa cũng không thể đánh giá phần mềm có tốt hay không, mà chỉ đánh giá xem nó có khớp với những gì bạn đã chỉ định trong thử nghiệm hay không. Nó sẽ không nhận ra rằng một quy trình làm việc gây nhầm lẫn hoặc một phản hồi, mặc dù đúng về mặt kỹ thuật, lại vô dụng đối với khách hàng. Việc đánh giá đó vẫn thuộc về con người.
Và không phải mọi thứ đều đáng để tự động hóa. Một kiểm tra bạn sẽ chạy hai lần thì không đáng. Một kiểm tra bạn sẽ chạy trên mỗi lần commit trong hai năm thì hoàn toàn đáng. Hãy tự động hóa các đường dẫn ổn định, lặp đi lặp lại, có giá trị cao trước; hãy để lại công việc hiếm khi xảy ra và mang tính thăm dò cho thủ công.
Cách thiết lập thử nghiệm API tự động trong Apidog
Apidog xây dựng các thử nghiệm API tự động một cách trực quan, vì vậy bạn không cần phải viết hoặc duy trì các script kiểm thử để có được một bộ thử nghiệm hoạt động. Dưới đây là toàn bộ quy trình.
Bước 1: Xác định hoặc nhập API của bạn. Nhập các điểm cuối của bạn từ một tệp OpenAPI, một bộ sưu tập Postman, hoặc định nghĩa trực tiếp trong Apidog. Mỗi điểm cuối mang theo lược đồ yêu cầu và lược đồ phản hồi của nó, những thứ này trở thành cơ sở cho các khẳng định (assertions). Nếu bạn bắt đầu từ một spec, hợp đồng API và các thử nghiệm sẽ tự động đồng bộ hóa.
Bước 2: Thêm các khẳng định vào mỗi yêu cầu. Đối với một điểm cuối, mở bảng khẳng định và thêm các kiểm tra mà không cần viết mã: trạng thái bằng 200, một trường body tồn tại và có kiểu đúng, phản hồi khớp với lược đồ, thời gian phản hồi nằm trong ngân sách của bạn. Các khẳng định API trực quan này là nội dung cốt lõi của thử nghiệm; một yêu cầu không có khẳng định chỉ chứng minh rằng máy chủ đã trả lời.
Bước 3: Tạo một kịch bản thử nghiệm. Nhóm các yêu cầu liên quan vào một kịch bản có tên, ví dụ “vòng đời người dùng”. Liên kết chúng để đầu ra chảy xuống: một lần đăng nhập trả về một token, yêu cầu tiếp theo sử dụng nó. Mỗi khối yêu cầu-cộng-khẳng định là một trường hợp thử nghiệm; cách viết các trường hợp thử nghiệm API bao gồm cấu trúc này.
Bước 4: Thêm phạm vi kiểm thử dựa trên dữ liệu. Đính kèm một tệp CSV hoặc JSON để một kịch bản chạy với nhiều hàng đầu vào. Thay vì viết hai mươi trường hợp gần như giống hệt nhau, bạn viết một trường hợp và cấp cho nó hai mươi bộ dữ liệu. Kiểm thử API dựa trên dữ liệu là cách một bộ thử nghiệm nhỏ có thể bao phủ một không gian đầu vào lớn.
Bước 5: Chạy kịch bản. Thực thi nó theo yêu cầu và đặt số lần lặp, ví dụ năm mươi lần chạy, để kiểm tra tính ổn định khi lặp lại. Apidog chạy mọi trường hợp, đánh giá mọi khẳng định và tạo ra một báo cáo nêu tên khẳng định chính xác đã thất bại, cùng với các giá trị mong đợi và thực tế.
Bước 6: Tổ chức thành các bộ thử nghiệm. Tập hợp các kịch bản vào các bộ thử nghiệm để toàn bộ API có thể chạy chỉ bằng một cú nhấp chuột. Các bộ thử nghiệm giúp quản lý cơ sở thử nghiệm đang phát triển khi phạm vi bao phủ mở rộng.
Bước 7: Tích hợp vào CI/CD. Đây là bước biến một bộ thử nghiệm thành thử nghiệm tự động. Chạy bộ thử nghiệm trên mỗi lần commit hoặc pull request để các lỗi hồi quy được phát hiện trước khi hợp nhất. Apidog chạy trong bất kỳ pipeline nào; tự động hóa thử nghiệm API trong CI/CD sẽ hướng dẫn bạn, và chạy thử nghiệm API trong GitHub Actions sẽ đề cập cụ thể nền tảng đó.
Tải Apidog để xây dựng kịch bản tự động đầu tiên của bạn và xem nó hoạt động.
Các loại thử nghiệm tự động chính
Thử nghiệm tự động không phải là một khái niệm duy nhất. Nó là một tập hợp các loại thử nghiệm theo lớp, mỗi loại bắt một loại lỗi khác nhau với chi phí khác nhau.
Kiểm thử đơn vị kiểm tra một chức năng hoặc lớp duy nhất một cách độc lập. Chúng nhanh, rẻ và chạy hàng nghìn lần, nhưng chúng không thể bắt được các vấn đề chỉ xuất hiện khi các thành phần giao tiếp với nhau.
Kiểm thử tích hợp kiểm tra xem các thành phần có hoạt động cùng nhau hay không: một dịch vụ và cơ sở dữ liệu của nó, hoặc hai dịch vụ qua một ranh giới mạng. Chúng bắt được các lỗi kết nối mà kiểm thử đơn vị bỏ lỡ, với chi phí chậm hơn và cần nhiều thiết lập hơn.
Kiểm thử API nằm ở một vị trí lý tưởng. Chúng thực thi một điểm cuối qua HTTP, giống như một client thực, vì vậy chúng xác minh hợp đồng thực tế. Chúng chạy nhanh, không cần trình duyệt và bao phủ logic nghiệp vụ quan trọng nhất. Đối với hầu hết các nhóm, đây là lớp mang lại hiệu quả tốt nhất so với nỗ lực bỏ ra.
Kiểm thử đầu cuối (End-to-end tests) thúc đẩy một quy trình làm việc hoàn chỉnh thông qua hệ thống thực tế, thường bao gồm giao diện người dùng (UI). Chúng là những thử nghiệm thực tế nhất và chậm nhất, đồng thời có xu hướng không ổn định nhất (flaky), vì vậy các nhóm giữ số lượng ít và tập trung vào các hành trình quan trọng.
Kim tự tháp thử nghiệm được trích dẫn rộng rãi nắm bắt sự cân bằng: nhiều thử nghiệm đơn vị nhanh ở phía dưới, ít thử nghiệm tích hợp và API hơn ở giữa, và một lớp mỏng các thử nghiệm đầu cuối ở trên cùng. Một bộ thử nghiệm có hình dạng ngược lại, chủ yếu là các thử nghiệm đầu cuối chậm, sẽ chạy chậm và thất bại không thể đoán trước. Kiểm thử API là nơi một nhóm có được phạm vi bao phủ rộng rãi, đáng tin cậy mà không phải trả phí cho kiểm thử đầu cuối, đó là lý do tại sao chúng là điểm khởi đầu được khuyến nghị.
Để tự động hóa mang lại hiệu quả
Một vài thói quen phân biệt các bộ thử nghiệm mang lại giá trị với các bộ thử nghiệm lỗi thời.
Giữ các thử nghiệm gần với thiết kế API. Khi hợp đồng và các thử nghiệm nằm ở một nơi, việc thay đổi hợp đồng khó bị bỏ qua trong các thử nghiệm. Sự sai lệch là lý do chính khiến các bộ thử nghiệm bị lỗi thời.
Khẳng định kết quả thực tế, không chỉ mã trạng thái. Một thử nghiệm tự động chỉ kiểm tra mã 200 sẽ vẫn vượt qua trong khi trả về dữ liệu rác. Hãy tự động hóa các khẳng định mạnh mẽ, nếu không bạn đã tự động hóa một cảm giác an toàn sai lầm.
Làm cho các lỗi dễ đọc. Một báo cáo tốt nêu tên khẳng định bị lỗi, không chỉ là thử nghiệm bị lỗi. Nhà phát triển càng đọc lỗi nhanh, nhóm càng tin tưởng bộ thử nghiệm.
Chạy chúng ở nơi đưa ra quyết định. Một bộ thử nghiệm chỉ chạy khi có người nhớ thì không phải là tự động hóa. Hãy đặt nó vào pipeline để nó chạy mà không cần yêu cầu.
Dựa vào AI cho các phần tẻ nhạt. Tạo bản nháp đầu tiên của các trường hợp từ một spec, hoặc mở rộng các trường hợp biên, rất phù hợp với sự hỗ trợ; Kiểm thử tự động API tăng cường AI cho thấy nơi nó hữu ích và nơi vẫn cần sự xem xét của con người.
Câu hỏi thường gặp
Thử nghiệm tự động có tốt hơn thử nghiệm thủ công không? Không cái nào thay thế cái nào. Tự động hóa các kiểm tra ổn định, lặp đi lặp lại, có giá trị cao. Giữ lại công việc kiểm thử thăm dò, đánh giá khả năng sử dụng và các công việc đòi hỏi nhiều phán đoán cho thủ công. Các đội tốt nhất thực hiện cả hai.
Tôi có cần biết lập trình để tự động hóa thử nghiệm API không? Không nếu bạn sử dụng một công cụ trực quan. Trong Apidog, bạn xây dựng các yêu cầu, khẳng định và kịch bản bằng cách nhấp chuột, và chỉ chuyển sang script khi có logic mà trình xây dựng trực quan không thể diễn đạt.
Một nhóm nên bắt đầu với tự động hóa ở đâu? Kiểm thử API. Chúng nhanh, ổn định và bao phủ logic cốt lõi, không có sự không ổn định như tự động hóa UI. Bắt đầu với các điểm cuối quan trọng và mở rộng.
Các thử nghiệm tự động cần bao nhiêu sự bảo trì? Chúng thay đổi bất cứ khi nào API thay đổi. Giữ các thử nghiệm gần với thiết kế API giúp giảm thiểu bất ngờ, nhưng hãy dự trù thời gian duy trì liên tục; một bộ thử nghiệm không được bảo trì sẽ không còn đáng tin cậy.
Điều gì khiến một thử nghiệm tự động không ổn định (flaky), và làm thế nào để khắc phục? Sự không ổn định thường đến từ các giả định về thời gian, trạng thái chia sẻ giữa các thử nghiệm, hoặc các khẳng định trên dữ liệu dễ thay đổi như dấu thời gian. Khắc phục bằng cách cô lập dữ liệu thử nghiệm, khẳng định dựa trên cấu trúc thay vì các giá trị dễ thay đổi chính xác, và loại bỏ thứ tự ngầm định giữa các thử nghiệm. Một bộ thử nghiệm không ổn định sẽ khiến nhóm bỏ qua các lỗi, vì vậy hãy coi sự không ổn định là một lỗi thực sự.
Làm thế nào để tôi đo lường xem thử nghiệm tự động của mình có hoạt động hiệu quả không? Theo dõi số lượng lỗi thực tế mà bộ thử nghiệm phát hiện trước khi phát hành so với số lượng lỗi lọt vào môi trường production, và tốc độ chạy của bộ thử nghiệm. Một bộ thử nghiệm luôn xanh trong nhiều tháng trong khi các lỗi production vẫn lọt qua không bảo vệ bạn; phạm vi bao phủ của các khẳng định có ý nghĩa quan trọng hơn số lượng thử nghiệm thô.