Viết một kịch bản kiểm thử tự động thì dễ. Viết một kịch bản vẫn giữ được giá trị sau sáu tháng mới là phần khó. Nhiều kịch bản kiểm thử được viết ra, chạy thành công một lần, rồi sau đó dần "thối rữa", hỏng hóc do những thay đổi không liên quan, không kiểm tra được điều gì có ý nghĩa, và khiến nhóm quen với việc bỏ qua các bản dựng lỗi. Một kịch bản kiểm thử tốt cần chính xác, cô lập và bền vững.
Hướng dẫn này bao gồm khái niệm về kịch bản kiểm thử tự động, cấu trúc giúp nó đáng tin cậy, hai cách để viết kịch bản kiểm thử API, và cách xây dựng từng bước trong Apidog.
Kịch bản kiểm thử tự động là gì
Một kịch bản kiểm thử tự động là một tập hợp các hướng dẫn được định nghĩa, có thể lặp lại, nhằm kiểm tra một phần mềm của bạn và kiểm tra kết quả, mà không cần con người thực hiện các bước. Kịch bản gửi một đầu vào, thực hiện một hành động và so sánh kết quả với một kỳ vọng. Nếu chúng khớp, nó vượt qua. Nếu không, nó thất bại và báo cáo lý do.
Một kịch bản kiểm thử là dạng thực thi của một trường hợp kiểm thử. Trường hợp kiểm thử mô tả mục đích, đầu vào, hành động và kết quả mong đợi bằng ngôn ngữ con người. Kịch bản biến mục đích đó thành thứ mà máy có thể chạy trên mỗi commit. Một trường hợp kiểm thử có thể trở thành một kịch bản; một kịch bản kiểm thử (test scenario) thường bao gồm nhiều kịch bản được liên kết với nhau.
Toàn bộ giá trị của một kịch bản kiểm thử tự động là nó chạy theo cùng một cách mỗi lần. Điều đó chỉ đúng nếu kịch bản được viết để có tính xác định. Một kịch bản phụ thuộc vào thứ tự chạy của các kịch bản khác, hoặc vào dữ liệu còn sót lại từ lần chạy trước, thì không phải là tự động hóa đáng tin cậy; nó là một rủi ro không ổn định.
Cấu trúc của một kịch bản kiểm thử đáng tin cậy
Hầu hết mọi kịch bản kiểm thử được viết tốt, bằng bất kỳ ngôn ngữ hoặc công cụ nào, đều tuân theo cùng một hình dạng bốn phần. Nó thường được gọi là Arrange-Act-Assert, với bước dọn dẹp được thêm vào.
Sắp xếp (Arrange). Thiết lập mọi thứ mà kiểm thử cần: dữ liệu đầu vào, xác thực, bất kỳ điều kiện tiên quyết nào. Kịch bản nên tạo trạng thái riêng của nó thay vì giả định rằng nó đã tồn tại. Nếu kiểm thử cần một người dùng, nó sẽ tạo một người dùng, hoặc sử dụng một đối tượng cố định đã biết, chứ không phải bất cứ thứ gì có sẵn trong cơ sở dữ liệu.
Thực thi (Act). Thực hiện một hành động duy nhất đang được kiểm thử. Một kịch bản tốt kiểm thử một hành vi duy nhất. Gửi một yêu cầu, gọi một hàm, kích hoạt một sự kiện, đó là hành động, và chỉ nên có chính xác một hành động đó cho mỗi kịch bản.
Xác nhận (Assert). Kiểm tra kết quả so với các kỳ vọng. Đây là phần mà các nhóm ít đầu tư. Một kịch bản chỉ xác nhận “không có lỗi nào được ném ra” hoặc “trạng thái là 200” hầu như không kiểm thử được gì. Các xác nhận mạnh mẽ kiểm tra các giá trị thực tế: thân phản hồi, schema, các tác dụng phụ, thời gian.
Dọn dẹp (Cleanup). Hoàn tác những gì kịch bản đã tạo để nó có thể chạy lại từ một trạng thái sạch sẽ. Một kịch bản để lại dữ liệu kiểm thử sẽ cuối cùng xung đột với chính nó hoặc với một kịch bản khác.
Ba thói quen giúp phân biệt các kịch bản bền vững với các kịch bản dễ hỏng. Kiểm thử một thứ duy nhất cho mỗi kịch bản, để khi có lỗi thì chỉ có một nguyên nhân rõ ràng. Giữ các kịch bản độc lập, để chúng có thể chạy theo bất kỳ thứ tự nào. Và xác nhận dựa trên các giá trị ổn định, không bao giờ dựa trên dữ liệu dễ thay đổi như ID được tạo tự động hoặc dấu thời gian, điều này sẽ khiến kịch bản thất bại mà không có lý do thực sự.
Hai cách để viết kịch bản kiểm thử API
Đối với kiểm thử API nói riêng, có hai phương pháp phổ biến và chúng phù hợp với các nhóm khác nhau.
Cách tiếp cận ưu tiên mã (code-first) viết các kịch bản kiểm thử bằng một ngôn ngữ lập trình đa năng. Trong Python, điều đó có nghĩa là một framework như pytest cộng với một thư viện HTTP; trong JavaScript, một test runner cộng với fetch. Bạn viết yêu cầu, các xác nhận và thiết lập dưới dạng mã thực tế, và các kịch bản nằm trong kho lưu trữ của bạn cùng với ứng dụng.
Cách tiếp cận này mang lại quyền kiểm soát lập trình đầy đủ. Logic phức tạp, các đối tượng cố định tùy chỉnh và các xác nhận bất thường đều chỉ là mã. Cái giá phải trả là mỗi kịch bản là mã bạn tự viết và duy trì, nhóm cần có kỹ năng về ngôn ngữ, và rất nhiều mã mẫu (boilerplate), xử lý xác thực, xây dựng yêu cầu, phân tích phản hồi, được viết lại trên các kịch bản. Nó phù hợp với các nhóm kỹ thuật muốn kiểm thử được quản lý phiên bản cùng với mã và sẵn sàng chịu trách nhiệm bảo trì đó.
Cách tiếp cận trực quan xây dựng kịch bản kiểm thử trong một công cụ kiểm thử API chuyên dụng. Bạn định nghĩa yêu cầu, thêm các xác nhận bằng cách nhấp chuột, và liên kết các yêu cầu thành các kịch bản, mà không cần viết hoặc duy trì mã kịch bản cho các trường hợp phổ biến. Các công cụ như Apidog đi theo hướng này.
Cách tiếp cận này loại bỏ mã mẫu và làm cho các kịch bản dễ đọc bởi bất kỳ ai trong nhóm, không chỉ những người biết ngôn ngữ lập trình. Bạn vẫn phải sử dụng mã tùy chỉnh cho những logic hiếm gặp mà trình xây dựng trực quan không thể thể hiện. Nó phù hợp với các nhóm hỗn hợp, kiểm thử do QA dẫn dắt, và bất kỳ ai muốn một bộ kiểm thử chạy nhanh mà không cần một dự án kịch bản đi kèm.
Cả hai cách đều không sai. Câu hỏi quyết định là ai sẽ duy trì các kịch bản và liệu chúng có nên nằm trong kho lưu trữ ứng dụng hay không. Đối với hầu hết các kiểm thử API, cách tiếp cận trực quan giúp có một bộ kiểm thử đáng tin cậy chạy nhanh hơn với ít công việc bảo trì hơn.
Viết một kịch bản kiểm thử API tự động trong Apidog
Sau đây là quy trình hoàn chỉnh để xây dựng một kịch bản kiểm thử API bền vững một cách trực quan.
Bước 1: Định nghĩa yêu cầu. Đưa endpoint vào Apidog từ tệp OpenAPI hoặc định nghĩa trực tiếp. Đây là bước Sắp xếp (Arrange); yêu cầu mang theo phương thức, đường dẫn, tiêu đề và phần thân của nó.
Bước 2: Thêm dữ liệu kiểm thử. Đặt tải trọng đầu vào cho trường hợp bạn đang kiểm thử. Để bao phủ nhiều đầu vào bằng một kịch bản, hãy đính kèm một tệp CSV hoặc JSON để kịch bản chạy một lần cho mỗi hàng; kiểm thử dựa trên dữ liệu thay thế hàng tá kịch bản gần giống nhau bằng một kịch bản duy nhất.
Bước 3: Viết các xác nhận. Đây là phần cốt lõi. Thêm các kiểm tra trực quan: trạng thái bằng với mã dự kiến, các trường chính trong phần thân tồn tại và có giá trị đúng, phản hồi tuân thủ schema, thời gian phản hồi nằm trong giới hạn. Đối với các trường hợp tiêu cực, xác nhận hình dạng lỗi, chứ không chỉ mã lỗi. Hạn chế việc xác nhận dữ liệu dễ thay đổi.
Bước 4: Nối các yêu cầu thành một kịch bản. Các quy trình làm việc thực tế bao gồm nhiều lệnh gọi. Xây dựng một kịch bản đăng nhập, tạo một tài nguyên, đọc lại nó và xóa nó, truyền giá trị từ bước này sang bước tiếp theo. Mỗi bước là một kịch bản; cùng nhau chúng kiểm thử một luồng hoàn chỉnh.
Bước 5: Thêm logic kịch bản tùy chỉnh chỉ khi cần thiết. Đối với các kiểm tra mà xác nhận trực quan không thể thể hiện, logic điều kiện, giá trị được tính toán, so sánh giữa các yêu cầu, hãy thêm một bộ xử lý trước hoặc sau bằng JavaScript. Giữ điều này ở mức tối thiểu; hầu hết các kịch bản không bao giờ cần nó.
Bước 6: Chạy và đọc báo cáo. Thực thi kịch bản. Apidog chạy mọi kịch bản, đánh giá mọi xác nhận và báo cáo chính xác kiểm tra nào đã thất bại với các giá trị mong đợi và thực tế cạnh nhau.
Bước 7: Tự động hóa việc chạy. Tích hợp kịch bản vào CI/CD để nó chạy trên mỗi commit. Một kịch bản kiểm thử chỉ chạy khi có người nhớ thì không thực sự là tự động. Tải Apidog để xây dựng kịch bản đầu tiên của bạn.
Giữ cho kịch bản kiểm thử khỏe mạnh
Một bộ kiểm thử là một thứ sống động. Các kịch bản hoàn hảo lúc phát hành sẽ trở nên lỗi thời khi API thay đổi. Ba cách thực hành giúp giữ cho một bộ kiểm thử đáng tin cậy.
Cập nhật kịch bản cùng với API, chứ không phải sau khi API thay đổi. Khi hợp đồng của một endpoint thay đổi, kịch bản cũng thay đổi trong cùng một commit. Một kịch bản xác nhận một schema cũ sẽ thất bại vì lý do sai và làm xói mòn niềm tin vào mọi kịch bản khác.
Coi các kịch bản không ổn định (flaky) như những lỗi thực sự. Một kịch bản thường xuyên vượt qua thì tệ hơn là không có kịch bản nào, bởi vì nó dạy cho nhóm rằng màu đỏ không có nghĩa là hỏng. Tìm ra nguyên nhân, thường là trạng thái chia sẻ hoặc giả định về thời gian, và khắc phục nó.
Đánh giá các kịch bản như mã sản xuất. Một kịch bản với các xác nhận yếu, chỉ kiểm tra mã 200, trông có vẻ xanh (pass) và an toàn nhưng thực chất không kiểm tra được gì nhiều. Một người đọc thứ hai sẽ phát hiện ra điều đó.
Các câu hỏi thường gặp
Sự khác biệt giữa trường hợp kiểm thử (test case) và kịch bản kiểm thử (test script) là gì? Một trường hợp kiểm thử mô tả mục đích bằng ngôn ngữ con người, đầu vào, hành động, kết quả mong đợi. Một kịch bản kiểm thử là phiên bản thực thi mà máy chạy. Trường hợp là kế hoạch; kịch bản là việc triển khai.
Tôi có cần biết lập trình để viết các kịch bản kiểm thử tự động không? Không cần đối với kiểm thử API bằng một công cụ trực quan. Trong Apidog, bạn xây dựng các yêu cầu, xác nhận và kịch bản bằng cách nhấp chuột, và chỉ viết mã cho các logic bất thường. Các framework ưu tiên mã thì yêu cầu kỹ năng về ngôn ngữ lập trình.
Tại sao các kịch bản kiểm thử của tôi cứ bị hỏng liên tục? Các nguyên nhân thông thường là xác nhận dựa trên dữ liệu dễ thay đổi, các kịch bản phụ thuộc vào trạng thái của nhau và không cập nhật kịch bản khi API thay đổi. Cô lập dữ liệu kiểm thử, giữ các kịch bản độc lập và cập nhật chúng cùng với hợp đồng API.
Một kịch bản kiểm thử nên có bao nhiêu xác nhận? Đủ để thực sự xác minh kết quả, điển hình là trạng thái, các trường chính trong phần thân, schema và thời gian. Một xác nhận mã trạng thái duy nhất là quá ít; nó sẽ vượt qua trong khi phản hồi thực sự sai.
Các kịch bản kiểm thử có nên nằm trong kho lưu trữ ứng dụng không? Với cách tiếp cận ưu tiên mã, thường là có, để kiểm thử được quản lý phiên bản cùng với mã. Với một công cụ trực quan, các kịch bản nằm trong nền tảng kiểm thử và đồng bộ hóa với định nghĩa API thay vì vậy. Cả hai đều hoạt động; tính nhất quán quan trọng hơn sự lựa chọn.
Làm cách nào để viết kịch bản kiểm thử trước khi API được xây dựng? Viết chúng dựa trên thiết kế API. Nếu bạn có một đặc tả OpenAPI, bạn có thể định nghĩa các yêu cầu và xác nhận từ đó, sau đó chạy chúng với một máy chủ giả (mock server) cho đến khi endpoint thực sự tồn tại. Các kịch bản sẽ sẵn sàng ngay khi việc triển khai hoàn tất.
Sự khác biệt giữa một kịch bản kiểm thử (test script) và một bộ kiểm thử (test suite) là gì? Một kịch bản kiểm thử chạy một kiểm tra duy nhất. Một bộ kiểm thử là một tập hợp các kịch bản được nhóm lại để chạy cùng nhau, thường bao phủ toàn bộ một API hoặc một tính năng. Các bộ kiểm thử giữ cho một tập hợp kịch bản đang phát triển được tổ chức và cho phép bạn chạy kiểm thử bao phủ rộng rãi chỉ bằng một lệnh.
Một kịch bản kiểm thử tự động nên dài bao nhiêu? Ngắn nhất có thể mà vẫn thực hiện đủ bốn phần: sắp xếp, thực thi, xác nhận, dọn dẹp. Nếu một kịch bản dài, nó thường kiểm thử nhiều hơn một thứ và nên được chia nhỏ. Một hành vi cho mỗi kịch bản giúp dễ dàng chẩn đoán lỗi.