Xin chào mọi người, tôi là Mai Cường- đến từ công ty Japan Quality Co.,Ltd.
Bạn có đang phát triển API? Việc kiểm thử diễn ra như thế nào?
Chắc hẳn có nhiều người từng nghe về API Testing nhưng không hiểu rõ về nó lắm.
Chính vì vậy, bài viết hôm nay tôi sẽ viết về chủ đề này.
Về API
Tôi rất đam mê phát triển Web.
Dự án đầu tiên tôi làm là phát triển Web trên một PHP framework với tên gọi là Laravel. Laravel là một framework tuyệt vời, rất phổ biến trong việc phát triển bằng ngôn ngữ PHP. Tuy nhiên, tôi đã gặp một số vấn đề như: khá là vất vả trong việc quản lý server, phân chia công việc trong team, và việc kiểm thử cũng rất khó khăn.
Sau đó tôi biết đến một framework khác có tên là React. Đúng thời điểm đó, khái niệm Serverless đang là chủ đề rất hot, tôi đã bắt đầu phát triển bằng cách kết hợp giữa React và Serverless. Tôi đã từng nghe về API nhưng phải đến lúc đó tôi mới bắt đầu tìm hiểu kỹ về nó.
API là viết tắt của cụm từ Application Programming Interface. Như chúng ta biết, cơ chế để tương tác giữa người dùng và ứng dụng được gọi là giao diện người dùng (UI). Tương tự, bạn cũng cần một cơ chế để tương tác giữa các ứng dụng với nhau, đó chính là API.
Ban đầu, tôi chỉ sử dụng API chỉ bởi vì “thời thế xu đẩy”, nhưng trong quá trình phát triển sản phẩm, tôi nhận ra nó có rất nhiều ưu điểm.
Trước hết, điểm nổi bật nhất chính là đơn giản hóa được quá trình phát triển. Bằng cách chia thành Frontend và Backend, tốc độ phát triển sản phẩm được nâng cao hơn. Hơn nữa, nhờ việc không cần phải phát triển bản dành cho điện thoại, bản dành cho PC riêng biệt mà chúng ta có thể giảm bớt đi đáng kể lượng công việc.
Ưu điểm tiếp theo là dễ lắp ghép. API mang tính độc lập cao và có thể coi chúng như một "bộ phận" (object). Chúng ta có thể dễ dàng nhúng các bộ phận đó không chỉ vào các dự án mới mà cả những dự án đã có sẵn,và cũng có thể dùng chung giữa các dự án khác nhau. Chẳng hạn, chúng ta vẫn hay thấy Google Map API hay Facebook API được nhúng vào các trang Web hay ứng dụng.
Ngoài ra, việc triển khai (deployment) API cũng rất dễ dàng. Vì API mang tính độc lập, nên khi cập nhật, chúng ta không cần phải triển khai toàn bộ dự án mà chỉ cần triển khai những nội dung cần thiết.
Về API Testing
Thời gian đầu khi mới làm việc với API, mặc dù đã thay đổi quy trình phát triển, nhưng quy trình kiểm thử vẫn được tiến hành giống như trước đây vẫn làm. Sau khi viết Unit Testing cho Frontend và Backend, sẽ tiến hành kiểm thử kết hợp (Integration Testing). Sau đó là System Testing và cuối cùng là Acceptance Testing. Nhưng tôi bắt đầu nhận ra là có vấn đề.
Vấn đề nằm ở việc kiểm tra kết hợp, gồm kết hợp bên trong Backend và kết hợp Backend với các hệ thống bên ngoài. Chúng tôi không thể giải quyết được vấn đề này bằng Unit Testing, và chỉ có thể tiến hành trên UI. Tuy nhiên việc kiểm thử trên UI sẽ mất rất nhiều công sức và thời gian. Điểm mấu chốt hơn nữa là việc kiểm thử bắt đầu rất muộn trong tiến trình phát triển sản phẩm. Nếu phát hiện lỗi tại đây thì công sức cho việc chỉnh sửa là rất lớn. Để có thể hiểu rõ hơn về vấn đề này, mời bạn tham khảo biểu đồ của Capers Jones dưới đây.
Liệu chúng ta có thể tiến hành kiểm tra kết hợp sớm hơn?
Sau quá trình tìm hiểu, tôi biết được rằng việc kiểm tra ở cấp độ API có thể giải quyết được những vấn đề trên. Chúng ta có thể bắt đầu kiểm tra kết hợp ở giai đoạn sớm hơn, vì có thể bắt đầu kiểm thử ngay thời điểm vừa hoàn thành API mà không cần phải đợi UI hoàn thành.
Bên cạnh đó còn có nhiều lợi ích khác nữa. Đầu tiên, ngay cả khi Test case khó thực hiện với UI, nếu gọi trực tiếp API thì vẫn có thể thực hiện được. Ví dụ: giả sử bạn có một biểu mẫu có kiểm tra giá trị đầu vào (Input Validation). Nếu bạn nhập dữ liệu không đúng, thông báo lỗi sẽ được hiển thị và nút "Gửi" sẽ bị vô hiệu hóa.
Chúng ta cần xác nhận rằng phía Backend sẽ được xử lý như mong đợi ngay cả khi dữ liệu bất thường được gửi đi. Nếu làm kiểm thử từ UI, chúng ta sẽ phải tạm thời vô hiệu hóa chức năng Input Validation, sau đó nhập dữ liệu bất thường và gửi đi.Tuy nhiên, bằng việc kiểm thử API thì không cần thiết phải làm những điều đó.
Hơn nữa, kiểm thử API đơn giản hơn và mất ít thời gian hơn so với kiểm thử UI nên sẽ phù hợp hơn với việc tự động hóa.
Kiểm thử API sẽ được tiến hành sau khi thực hiện Unit Testing. Giống như Test Pyramid bên dưới, chúng ta thấy rằng, sau khi thực hiện một cách cẩn thận Unit Testing thì tiếp đến là việc tiến hành kiểm thử API với phạm vi càng rộng càng tốt.
Thực tế thì phải làm gì?
Vì API được coi như một "bộ phận", nên chúng ta sẽ thực hiện kiểm thử từng "bộ phận" (giống như Unit Testing) và kiểm thử kết hợp giữa các “bộ phận” với nhau.
Unit Testing của API ở đây cũng có nghĩa là Component Testing. Tại đây, chúng ta sẽ xác nhận xem đối với mỗi Request thì Response có được trả về như mong đợi hay không. Chúng ta sẽ tiến hành kiểm tra rằng đối với những trường hợp Request bình thường, bất thường hoặc bất kỳ trường hợp nào có thể xảy ra, thì máy chủ có xử lý và trả Response về đúng hay không. Vì có nhiều mẫu dữ liệu khác nhau nên thường có khá nhiều Test case tại đây.
Tiếp theo là việc kiểm tra kết hợp giữa “bộ phận” với nhau, nghĩa là việc kiểm tra kịch bản API. Chúng ta sẽ tưởng tượng các kịch bản xảy ra khi người dùng sử dụng ứng dụng và tiến hành kiểm tra chúng. Ví dụ, tại cửa hàng bán hàng trực tuyến, có thể giả định kiểm tra theo kịch bản sau:
Đăng nhập API
Danh sách sản phẩm API
Thông tin chi tiết sản phẩm API
Thêm giỏ hàng API
Thanh toán API
Những thách thức khi kiểm thử API
Khi bạn quyết định kiểm thử API, điều đầu tiên bạn phải đối mặt đó là “ Nên làm thế nào để kiểm thử?”. Nhìn chung là có thể tìm hiểu được ngay cách gửi Request và nhận Response, nhưng điều khó khăn hơn cả đó là “kiểm thử như thế nào”, hay nói cách khác đó là việc thiết kế kiểm thử.
Tiếp theo đó là khối lượng công việc. Trước hết, tạo Test case cũng là một việc không hề dễ dàng. Chúng ta sẽ phải suy nghĩ về dữ liệu kiểm thử và kết hợp các dữ liệu đó để tạo ra các Test cases. Sau khi đã có Test cases thì phải xây dựng môi trường kiểm thử và tiến hành việc kiểm thử. Do phải kết hợp các dữ liệu với nhau nên sẽ có nhiều Test case và thường sẽ mất khá nhiều thời gian để thực hiện kiểm thử.
Ngoài ra, việc quản lý Test case như tạo, chỉnh sửa Test case, cũng rất vất vả. Khi tiến hành cập nhật ở đâu đó của sản phẩm, chúng ta điều chỉnh testcase và chạy lại, và cứ thế lặp đi lặp lại.
Mặc dù có nhiều lợi ích, nhưng có rất nhiều người đã từ bỏ việc API Testing khi nghĩ đến khối lượng công việc lớn như vậy.
Liệu có thể giải quyết được các vấn đề đó hay không?
Khi tiến hành kiểm thử API, tôi đã phải thử đi thử lại nhiều bằng nhiều khác nhau và cảm nhận rất sâu sắc về sự vất vả của việc kiểm thử API. Với suy nghĩ, liệu có thể nào làm cho việc kiểm thử API trở nên đơn giản hơn không, tôi cùng đội ngũ của mình đã hợp tác để bắt đầu phát triển một công cụ có tên RakAPIt.
RakAPIt là từ viết tắt của "Raku API Testing", với ý nghĩa là hướng đến một “API Testing dễ dàng và thú vị”. Vậy, RakAPIt sẽ giải quyết các vấn đề trên như thế nào?
Đầu tiên, việc không biết phải thực hiện kiểm thử như thế nào, nói một cách khác là việc khó tiếp cận API Testing. RakAPIt hỗ trợ việc thiết kế và được tích hợp sẵn chức năng tự động tạo Testcase chỉ bằng việc nhập Data Pattern. Không những thế, khi định nghĩa API được viết bằng Swagger thì ngay cả dữ liệu kiểm thử, cũng như dữ liệu để kiểm tra Response (Response Assertion) cũng sẽ được tạo tự động. Chức năng thực thi cũng được trang bị sẵn và chỉ với thao tác nhấn nút là có thể thực hiện được việc kiểm thử.
vấn đề tiếp theo là khối lượng công việc nhiều. Với RakAPIt, việc thiết kế cũng như thực hiện kiểm thử đều được tự động hóa. Ngoài ra, từ việc tạo Test cases; thêm, chỉnh sửa Test cases; xác nhận kết quả, v.v., tất cả đều được quản lý trên nền tảng Web, do đó sẽ giúp tiết kiệm đáng kể công sức trong việc quản lý kiểm thử. Hơn nữa, do là Web Service, việc thiết lập môi trường là không cần thiết, và có thể bắt đầu ngay chỉ với việc đăng ký User.
Tóm lại
Trong bài viết này, tôi đã nói về thế nào là API Testing và cách suy nghĩ trong API Testing.
Bài viết tới tôi sẽ đề cập về việc làm thế nào để thực hiện API Testing bằng việc sử dụng RakAPIt. Hãy cùng chờ đón các nội dung tiếp theo trong lần tới nhé!