api testing là gì
Chúng ta đang sống trong một thời đại trí tuệ tuyệt vời, nơi sự tiến bộ chuyển động với tốc độ chóng mặt. Chúng ta được kết nối với thế giới và tất cả mọi thứ. API (Application Programming Interface) là anh hùng không được biết đến trong thế giới kết nối đó. Dưới đây là những điều bạn cần biết về API và kiểm thử API đóng một vai trò quan trọng như thế nào.
Các API được sử dụng để tích hợp các hệ thống với nhau. Bạn có thể tạo sẵn dữ liệu cho các hệ thống khác truy cập thông qua API hoặc chấp nhận dữ liệu từ các hệ thống khác. Đây là cách các thiết bị và ứng dụng khác nhau nói chuyện với nhau và chia sẻ thông tin.
Các công ty thành công như Facebook, YouTube và Twitter sử dụng API để ứng dụng của họ có thể giao tiếp với các chương trình của bên thứ ba. Thông thường, API hoạt động tương tự như cách hoạt động của bất kỳ trang web nào. Yêu cầu (request) được gửi từ client tới server và kết quả phản hồi (response) thông qua giao thức http.
Ví dụ như người phục vụ trong một nhà hàng. Người phục vụ nhận yêu cầu – request (đơn đặt hàng) từ khách hàng (client) và chuyển nó đến nhà bếp (là server) và nhận thức ăn (phản hồi – response) từ bếp cho khách hàng. API thực hiện chính xác những điều đó. Một API là một sứ giả đưa ra yêu cầu của bạn và nói với các hệ thống những gì cần làm và sau đó trả về phản hồi cho bạn.
API testing là một loại kiểm thử phần mềm bao gồm kiểm tra trực tiếp các giao diện lập trình ứng dụng (API) và là một phần của kiểm thử tích hợp để xác định xem chúng có đáp ứng mong đợi về chức năng, độ tin cậy, hiệu suất và bảo mật không.
Vì API thiếu GUI, API testing được thực hiện ở tầng nghiệp vụ (business layer).
API testing được coi là quan trọng cho automation testing vì các API đóng vai trò là giao diện chính cho logic ứng dụng và do GUI test rất khó duy trì với các chu kỳ release ngắn và các thay đổi thường được sử dụng trong Agile và DevOps.
API testing phù hợp hơn cho test automation và test liên tục (đặc biệt trong Agile và DevOps) so với GUI testing. Bởi vì:
Vì những lý do này, chúng ta nên tăng API testing và giảm sự phụ thuộc vào GUI testing. API testing được khuyến nghị cho phần lớn các automation test và thử nghiệm càng nhiều càng tốt. GUI testing sau đó được dành riêng để xác thực các trường hợp ở system level, mobile testing, và usability testing.
Kiểm thử API là rất cần thiết cho sản phẩm công nghệ phần mềm, thiếu API testing có thể bị bỏ qua những lỗi rất nghiêm trọng, gây ảnh hưởng lớn tới trải nghiệm người dùng khi nhà phát triển không thể đo đạc được hành vi người dùng nhằm tăng cường chất lượng sản phẩm.
Khi bạn tìm thấy lỗi càng muộn thì càng mất nhiều thời gian, công sức để fix nó. API testing đưa người kiểm thử tham gia sớm vào vòng đời phát triển sản phẩm. Với API testing, bạn có thể bắt đầu kiểm thử ứng dụng sớm ngay cả khi không có giao diện người dùng. Điều này giúp xác định và khắc phục sớm các vấn đề trong vòng đời phát triển, nếu không thì sẽ tốn kém để khắc phục khi được xác định trong quá trình kiểm thử GUI. Ưu điểm của việc kiểm thử API là rất nhiều logic có thể được kiểm tra mà không bị phụ thuộc vào UI.
Nếu chúng ta hiểu được “Kim tự tháp Tự động hoá” ( Automation pyramid), chúng ta có thể đưa ra một chiến lược tự động hóa hiệu quả.
Khái niệm kim tự tháp được Mike Cohn phát triển và đã được mô tả trong cuốn sách “Thành công với Agile”. Tầng thứ nhất của kim tự tháp là Unit test. Thực hiện unit test là cách nhanh nhất và mang lại kết quả cao nhất. Tầng thứ 2 là kiểm thử API dựa trên service layer. Cuối cùng, ở đỉnh của kim tự tháp là kiểm thử UI.
Đi từ tầng dưới kim tự tháp lên trên, chi phí liên quan đến việc tạo ra và duy trì các phương pháp kiểm thử, thời gian thực hiện kiểm thử, phạm vi kiểm thử sẽ tăng lên. Các kim tự tháp tự động (Automation pyramid) nói rằng bạn nên làm nhiều hơn nữa kiểm thử tự động thông qua Unit test và API hơn là kiểm thử dựa trên GUI. Sự thành công của Agile rất phụ thuộc vào phản hồi (feedback) sớm. Trong các thực tiễn, việc tích hợp liên tục, thời gian kiểm thử hồi quy GUI và nhận lại phản hồi quá dài. Kiểm tra giao diện người dùng rất tốn kém để phát triển và duy trì. Một sự thay đổi nhỏ trong giao diện người dùng cũng có thể dẫn đến việc thực hiện kiểm thử lại rất nhiều.
Trong một số trường hợp, người kiểm thử bắt buộc phải thực hiện tự động hoá ở tầng UI. Tuy nhiên, kiểm thử có thể chậm và tốn nhiều chih phí. Đây là một trong những lý do khiến nhiều công ty thất bại trong nỗ lực thực hiện chiến lược tự động hoá hiệu quả.
Theo một cuộc khảo sát gần đây của VersionOne, 95% người được hỏi cho biết tổ chức của họ sử dụng phương pháp Agile. Agile không chỉ sử dụng ở những công ty startup và những nhóm phát triển sản phẩm nhỏ. Lý do chính để áp dụng Agile thay vì phương pháp truyền thống là đẩy nhanh việc phân phối sản phẩm và chấp nhận những thay đổi. Agile cũng đã tăng tần số mà các ứng dụng được phát hành, do đó đã tạo ra nhu cầu ngày càng tăng về những phương pháp mới để nhanh chóng kiểm tra chúng. Kiểm tra tự động hóa đã trở thành một yếu tố quan trọng để duy trì tính nhanh chóng. Vì vậy, cần thiết cho các đội Agile tăng mức độ kiểm thử API và giảm sự phụ thuộc của họ vào việc kiểm tra GUI.
Tự động hóa API có thể giảm đáng kể áp lực của kiểm thử hồi quy của nhóm QA. Bằng cách tích hợp kiểm thử tự động API , nhóm QA có thể cung cấp phản hồi nhanh về chất lượng ứng dụng ngay khi được triển khai (deploy). Điều này cung cấp một đánh giá nhanh chóng về hệ thống trước khi kiểm thử GUI. Kiểm thử tự động API yêu cầu code ít hơn và cung cấp kết quả kiểm tra nhanh hơn và phạm vi kiểm tra tốt hơn. API được ổn định sớm và không thay đổi thường xuyên như giao diện người dùng.
API testing là một hình thức thử nghiệm phần mềm độc đáo và đặc biệt có giá trị đối với các doanh nghiệp nắm bắt quá trình hội nhập liên tục. Việc xây dựng trường hợp kiểm thử API trong quá trình phát triển bất kỳ phần mềm hoặc dịch vụ nào có những lợi ích sâu rộng trong các đội, tất cả đều là cách khách hàng trải nghiệm sản phẩm. Làm phần mềm mà khách hàng mục tiêu của bạn sẽ yêu thích là điều thiết yếu cho sự thành công của doanh nghiệp và bằng cách kiểm thử API một cách nghiêm túc và thường xuyên, là một cách đáng tin cậy để đạt được nó.
Postman là một ứng dụng Google Chrome giúp bạn tạo, lưu, gửi yêu cầu HTTP (HTTP request) và kiểm tra dữ liệu phản hồi ( request) . Nó giúp tự động hoá quá trình tạo ra các yêu cầu API và kiểm tra các phản hồi API, cho phép thiết lập một quy trình làm việc rất hiệu quả. Hầu hết các lập trình viên và người kiểm thử đều quen thuộc với Postman. Tuy nhiên, nhiều người sử dụng nó chỉ để kiểm tra phản hồi cho các dịch vụ mà họ đang làm việc trên. Họ không biết về các tính năng mạnh mẽ mà Postman đưa ra như: Collections, Tests and Pre-request scripts. Bài viết này sẽ ra một cái nhìn tổng quát của Postman .
Lý do chính tôi thích Postman là vì khả năng tự động hóa mạnh mẽ của nó. Hơn nữa, việc học tập để sử dụng nó là rất dễ dàng và ứng dụng cung cấp một giao diện người dùng rất trực quan để kiểm tra yêu cầu máy chủ của bạn.Nó sẽ xác nhận hợp lệ mỗi lần nếu đáp ứng đúng. Viết test trên Postman được thực hiện dễ dàng bằng các đoạn mã JavaScript, cho phép cả những tester thiếu kinh nghiệm kiểm thử một cách hiệu quả.
Postman là hệ thống thời gian thực giúp lập trình viên và QA kiểm thử API dễ dàng hơn. Postman giúp làm giảm áp lực khi thực hiện kiểm thử hồi quy của nhóm QA. Việc tự động hoá kiểm thử API giúp tiết kiệm thời gian hơn là tự động hoá kiểm thử UI. Ưu điểm chính của tự động hóa API là chúng ta có thể truy cập vào ứng dụng mà không có giao diện người dùng. Điều này cung cấp một đánh giá ban đầu về tổng thể sức mạnh hệ thống trước khi bắt tay vào kiểm thử GUI.
Bằng cách tích hợp tự động hoá kiểm thử API, nhóm QA có thể cung cấp phản hồi nhanh về chất lượng của ứng dụng ngay khi được triển khai.
API testing khác với các loại kiểm thử phần mềm khác vì GUI không khả dụng.
Tuy nhiên, bạn được yêu cầu thiết lập môi trường ban đầu gọi API với một bộ tham số bắt buộc và cuối cùng là kiểm tra kết quả.
Do đó, thiết lập môi trường thử nghiệm API testing khá phức tạp.
Cơ sở dữ liệu và máy chủ nên được cấu hình theo yêu cầu ứng dụng.
Sau khi cài đặt xong, Hàm API sẽ được gọi để kiểm tra xem API đó có hoạt động không.
Đầu ra của API có thể là
Hãy xem xét ví dụ về từng loại trên:
Ví dụ: một hàm API sẽ thêm hai số nguyên.
Long add(int a, int b)
Các số phải được đưa ra làm tham số đầu vào. Đầu ra phải là tổng của hai số nguyên. Đầu ra này cần phải được xác minh với một kết quả mong đợi.
Call phải là
add (1234, 5656)
Các ngoại lệ phải được xử lý nếu số lượng vượt quá giới hạn số nguyên.
Hãy xem xét API function bên dưới
Nó trả về bất kỳ giá trị nào như True (trường hợp thành công) hoặc false (trường hợp có lỗi).
Một Test Case chính xác hơn sẽ có thể gọi các hàm trong bất kỳ tập lệnh nào và sau đó kiểm tra các thay đổi trong cơ sở dữ liệu hoặc application GUI.
Trong trường hợp này, khi ta gọi một trong các hàm API, và hàm này sẽ gọi một hàm khác.
Ví dụ: Hàm API đầu tiên có thể được sử dụng để xóa một record đã chỉ định trong bảng và tiếp đó, hàm này gọi một hàm khác để REFRESH cơ sở dữ liệu.
Test case trong API testing dựa vào:
– Giá trị trả về dựa trên điều kiện đầu vào: tương đối dễ kiểm tra, vì đầu vào có thể được xác định và kết quả có thể được xác thực.
– Không trả về bất cứ điều gì: Khi không có giá trị trả về, một hành vi API trên hệ thống sẽ được kiểm tra
– Kích hoạt một số API / Event / Interupt: Nếu đầu ra của API kích hoạt một số event hoặc gián đoạn, thì những listerner của event hoặc interupt đó sẽ được theo dõi.
– Cập nhật cấu trúc dữ liệu: Cập nhật cấu trúc dữ liệu sẽ có một số kết quả hoặc ảnh hưởng đến hệ thống và cần được xác thực.
– Sửa đổi một số tài nguyên: Nếu lệnh gọi API sửa đổi một số tài nguyên thì nó phải được xác thực bằng cách truy cập các tài nguyên tương ứng.