API testing với postman update

LỜI NÓI ĐẦU Cuốn ebook thành việc tổng hợp kiến thức tìm hiểu test API Nó chưa đúng, phù hợp cho người tiếp cận test API sử dụng công cụ Postman Read and enjoy it! Giang Nguyen API TESTING VỚI POSTMAN CONTENT I API gì? Và phải test API ? II Protocol dùng Restful API III Định dạng liệu JSON XML IV Giới thiệu chung Postman 10 V Cách tạo Request 14 VI Collections Postman 17 VII Cách sử dụng Environments 21 VIII Test Response 25 IX Sử dụng Pre-request Script 30 X Xây dựng API Document 34 XI Run Test Suites từ Runner 41 XII Cách test API nào? 46 https://giangtester.com I API gì? Và phải test API ? API gì? Nói đơn giản, API cầu nối client server Client máy tính, điện thoại sử dụng hệ điều hành khác viết ngơn ngữ khác nhau, ví dụ Swift, Objective-C, Java Tương tự, server back-end viết ngôn ngữ khác Để thằng nói chuyện với chúng phải nói ngơn ngữ Ngơn ngữ API Chúng ta lấy ví dụ đơn giản cho vấn đề : Giả sử bạn người hướng dẫn viên du lịch, quản lý nhóm du lịch hợp chủng quốc Trong nhóm có người Nga, Mỹ, Nhật, Thụy Điển, Đức, Việt Nam Để làm việc cách suôn sẻ, tất nhóm phải nói ngơn ngữ, tiếng anh tiếng Việt Ở người hướng dẫn viên đóng vai trị Server, người du lịch đóng vai trị client Khi đường đến thăm địa danh du lịch, người khách hỏi hướng dẫn viên nhiều câu hỏi khác “Cái gì?”, “Quả ăn nào?”, “Bạn ơi, chỗ WC đâu nhỉ?”… Với hành động hỏi vậy, tương ứng với việc gửi request gửi lên server với tham số đầu vào “Cái kia” hay “quả này” (Gửi request gọi Call API) Với câu hỏi, người hướng dẫn viên trả lời cách khác – gọi response “Cái để đập vào đầu đứa hỏi nhiều”, “Quả cho vào mồm xong” :))) https://giangtester.com Định dạng việc hỏi trả lời thơng qua trò chuyện trực tiếp viết giấy Ở API có định dạng xml json Hiện tại, có kinh nghiệm với json nên giới thiệu lấy ví dụ phần sau json thơi Vì phải test API? Trong trình triển khai dự án, phần server client làm độc lập với nên có nhiều chỗ client chưa làm xong, khơng thể chờ client làm xong để test liệu mà test API cơng cụ khác ln –> Lúc việc test hồn tồn khơng phụ thuộc vào client Kể client làm xong rồi, test client mà thấy lỗi liên quan đến logic liệu cần test thêm API để biết xác server sai hay client sai –> fix lỗi nhanh Khi làm hệ thống web services, dự án viết API cho bên khác dùng, khơng có client để test giống dự án khác –> phải test API hoàn toàn https://giangtester.com II Protocol dùng Restful API Ở phần I, giải thích vai trị API client server, phần nói cách mà thằng (sau gọi máy tính) nói chuyện với Protocol gì? Giả sử: Có người A B nói chuyện với qua điện thoại, người A hỏi câu im lặng, người B biết người A chờ đợi câu trả lời đến lượt người B nói Hai máy tính giao tiếp cách lịch mô tả với thuật ngữ “Protocol” – giao thức Giao thức luật lệ chấp thuận để máy tính nói chuyện với Tuy nhiên, luật lệ chặt chẽ nhiều so với giao tiếp người với người Máy tính khơng thơng minh để nhận biết câu “A chồng B” hay “B vợ A” có ý nghĩa Để máy tính giao tiếp hiệu quả, server phải biết xác cách mà client xếp message gửi lên Chúng ta nghe đến Protocol cho mục đích khác nhau, ví dụ Mail có POP hay IMAP, message có XMPP, Kết nối thiết bị: Bluetooth Trong web Protocol HTTP – HyperText Transfer Protocol, phổ biến mà hầu hết cơng ty chọn giao thức cho API Lưu ý: API viết Protocol khác, ví dụ SOAP Trong phần này, giới thiệu HTTP HTTP hoạt động nào? Cuộc sống HTTP xoay quanh vòng luẩn quẩn: Request Response Client gửi request, server gửi lại response liệu server làm client muốn hay khơng Và API xây dựng thành phần: Request Reponse Trước tiên, ta phải hiểu cấu trúc thành phần https://giangtester.com Request Một request chuẩn cần có thứ: URL Method Header Body OK, săm soi thứ ● URL​ địa cho thứ (dùng danh từ), web page, image, video API mở rộng ý tưởng gốc URL cho thứ khác, ví dụ: customers, products Và client dễ dàng cho server biết muốn gì, gọi chung “resources” – nguồn lực ● Method​: hành động client muốn tác động lên “resources”, thường động từ Có loại Method hay dùng: – GET: Yêu cầu server đưa lại resource: Hãy tưởng tượng cảnh vào fb, tay vuốt new feeds – POST: Yêu cầu server cho tạo resource Ví dụ: đăng ký chuyến GrabBike – PUT: Yêu cầu server cho sửa / thêm vào resource có hệ thống Ví dụ: Edit post fb – DELETE: Yêu cầu server cho xóa resourse Cái chả cần ví dụ ● Header​: nơi chứa thơng tin cần thiết request end-users có tồn Ví dụ: độ dài request body, thời gian gửi request, loại thiết bị sử dụng, loại định dạng response mà client có đọc được… ● Body​: nơi chứa thơng tin mà client điền Giả sử bạn đặt bánh pizza, thơng tin phần body là: Loại bánh pizza, kích cỡ, số lượng đặt https://giangtester.com Response: Sau nhận request từ phía client, server xử lý request gửi ngược lại cho client response Cấu trúc response tương đối giống phần request Status code thay cho URL Method Tóm lại, có cầu trúc phần: Status code Header Body ● Status code​ số có chữ số có ý nghĩa Chắc bạn khơng cịn lạ lẫm với Error “404 Not Found” “503 Service Unavailable” Full list có đây​ ● Header​ ​Body​ tương đối giống với request https://giangtester.com III Định dạng liệu JSON XML Như phần có giới thiệu, định dạng data API thường dùng loại JSON (JavaScript Object Notation) XML (Extensible Markup Language) Hơm nay, nói kỹ loại định dạng Định dạng JSON Ngày nay, JSON sử dụng nhiều Restful API Nó xây dựng từ Javascript, ngơn ngữ mà dùng nhiều, tương thích với front-end back-end web app web service JSON định dạng đơn giản với thành phần: keys values – Key thể thuộc tính Object – Value thể giá trị Key Ví dụ: Trong ví dụ trên, keys nằm bên trái, values nằm bên phải Có nhiều trường hợp, Key có Value dãy key + value Ví dụ hình: https://giangtester.com Trong hình Key có tên Data có Value cặp Key + value Định dạng XML Trong JSON dùng { } [ ] để dánh dấu liệu XML tương tự HMTL, dùng thẻ để đánh dấu gọi nodes Lấy ln ví dụ viết xml, này: https://giangtester.com https://giangtester.com Sample Response Bạn lấy Reposne mẫu theo Sample Request phía Paste vào 44 https://giangtester.com Sau đó, bạn xem lại thành link Public Private phía đầu nói Nó có dạng sau: Phần bên trái List API có dự án, click vào API để xem chi tiết 45 https://giangtester.com XI Run Test Suites từ Runner Theo phần trước bạn biết cách tạo test đơn giản cho API, mà dự án có q nhiều API q nhiều task khác nhau, task tập hợp vài API phải giải Cùng với cách quản lý mà bạn nghĩ có áp dụng cho Postman hay không? Và làm để run test đỡ tốn công sức I Quản lý Test Suites Trong Postman quản lý API theo dạng Collections tùy vào dự án có cách quản lý khác Vì đặc thù dự án tuần lại release lần nên cách quản lý Vấn đề task nhỏ xếp nào??? Phần trước, hướng dẫn với API đơn lẻ có kiểu test tương ứng: Syntax Testing (Validation) Functional Testing Theo gợi ý từ Bloggers Postman​, bạn không nên dùng request cho tất loại test mình, mà nên với trường hợp bạn tạo request, khác phần Description Test thơi Do cách cấu trúc API cho task 46 https://giangtester.com Trên Postman, có hình thù sau: Các API hình từ đến có phần Description Test khác 47 https://giangtester.com API_1: API_2: Tương tự bạn làm với trường hợp khác 48 https://giangtester.com II.Run Test Suites chức Runner Từ đầu series đến bạn biết cách test API theo cách “thủ công”, ấn SEND check API Postman cung cấp tính run List API theo Folder tính Runner Màn hình Runner ra, bạn quan tâm đến thành phần sau Folder run Environment theo dự án Số lần lặp lại Option cho bạn xem lại Log request bạn muốn 49 https://giangtester.com Sau run xong, bạn nhìn thấy report sau: Lưu ý: Số Pass or Fail tính số Test​ ​bạn viết, khơng tính số Request bạn run Bạn có xem short version report Summary lưu Log Export Result Nếu bạn muốn xem chi tiết thông số request bạn click vào tên Request 50 https://giangtester.com XII Cách test API nào? Sau đọc xong phần “test API với Postman” mình, bạn nắm kiến thức API chức Postman đem lại Nhưng cách xếp test viết Testcase cho API chưa thơng lắm, nên phần cách test API cho hợp lý Nhắc lại kiến thức chút: API cầu nối nói chuyện Client Server API khơng thực business logic cả, đơn thằng giao thư, chuyển thông tin Thế test API test thằng giao thư ah? Hay test gì? Xin phép trả lời ln: dùng API để test business logic phía server Hãy xem ví dụ để hiểu rõ Ví dụ: Tôi muốn check API update_profile gồm trường Name Birthday Trong trường Name bắt buộc phải lớn ký tự Trường Birthday khơng bắt buộc nhập Cách xử lý Server Client (có thể không giống với cty bạn): User vào hình Profile, sửa lại trường Name Birthday User ấn vào nút Update Profile (Code client check điều kiện trường Name, submit gửi API, gọi request, sai thông báo tương ứng) Thông tin gồm Name Birthday theo phong bì thư API cập bến Server Server đọc thư check điều kiện lại lần Nếu thông tin Name Birthday Valid thơng tin cập nhật vào Database Server trả lại thông tin, gọi response, lại cho client thơng báo cập nhật thành cơng User nhìn thấy Name Birthday thay đổi hình Profile 51 https://giangtester.com Khi thực test API, việc test bước 4, Dó đó, với API đơn lẻ, check phần chính: – tạm gọi Syntax Testing​ (Validate liệu – bước + bước 6) – ​Funtional Testing​ (Test business logic – bước 6) Syntax Testing Loại tập trung vào Method check điều kiện: Accept với data Reject với data sai hay khơng Một vài ví dụ: ▪ Bỏ trống trường bắt buộc → Trong Response phải có thơng báo lỗi, thơng tin khác khơng cập nhật Server không thực business logic ▪ Bỏ trống trường không bắt buộc → Không có lỗi cả, Server thực business logic ▪ Điền thơng tin sai kiểu định dạng, ví dụ trường thời gian lại điền chữ → Trong Response phải có thơng báo lỗi… Chốt lại: Cái giống hệt trường hợp Validate liệu, hay làm hàng ngày Functional Testing Loại check Method xử lý liệu thực chức có hay khơng Ví dụ: ▪ Giá X số phần trăm discount Y số tiền phải trả X*(1-Y) hay khơng → Nó việc test Method tính tốn với tham số X Y mà Việc thực business logic khơng lưu kết vào DB ▪ Việc Update trường Name ví dụ ban đầu có lưu vào DB hay khơng? → mở DB check kết ▪ Yêu cầu trả thơng tin user có tên “Nam” → Vào DB thực câu Query so sánh với Response xem kết có khớp hay khơng… Ấy ấy, chưa hết =)))) loại test phục vụ cho test API đơn lẻ Còn Test scenarios Cuối ta ghép API lại với có bị lỗi đâu khơng? Chỗ Test Suite, gộp nhiều Test Case lại Ví dụ hình: 52 https://giangtester.com Phần khơng phải nói nhiều, bạn quen thuộc với Lưu ý test API: Khi sử dụng Postman, để trường hợp API riêng biệt, không test đè lên nhau, sau khó kiểm sốt khơng tạo test case cho automation Để căng mắt check response trường hợp đơn lẻ, đọc lại phần Test Response 53 https://giangtester.com XIII Những lưu ý code API test Postman – Workspace Trước kia, ta có workspace làm nhiều project có tính tách workspace ta nên tách project workspace, dễ nhìn nhiều, tránh nhầm lẫn kéo thả request từ folder sang folder khác 54 https://giangtester.com Ngồi ra, cịn có nhiều tiện ích mà sử dụng: Trong số hay sử dụng console log console log show tồn thơng tin request response, giúp ích cho việc debug nhiều Nếu bạn thắc mắc run Send API response trả hiển thị phía rồi, cần phải console log? Có trường hợp bạn cần phải sử dụng console log: ● Bạn test theo Runner Runner dashboard lưu full thông tin 10 request đầu tiên, request phía sau, lưu thông tin bản, bạn ko xem full thông tin có request bị lỗi ● Nếu bạn viết tham số API dạng biến bạn cần có console log view giá trị thực tham số lần run 55 https://giangtester.com Test Ở phần test, có nói ​bài 9​ ​rồi có vài điểm người cần ý: Các error code cần check error code sử dụng định nghĩa REST API ví dụ: ● 200 – success: Dùng cho happly case: nhận request trả response có data ● 400 – bad request: Dùng TH lỗi phía client ví dụ: sai data type, missing data parameter ● 401 – Unauthorized: Dùng việc thiếu token authen ● 403 – Forbidden: Dùng cho việc access vào resource khơng có quyền hạn ● 500 – Server error: Dùng cho vấn đề error server: Thiếu library, disconnect DB… Ngoài error code sử dụng response data để verify thêm Đọc lại ​bài này​ ​để biết cách test API Ngoài ra, built-in function Postman thay đổi nhiều, bạn xem ​Link docs Environment Phần khơng có nhiều thay đổi, có số lưu ý nhỏ Nên đặt tên biến meaningfull Ví dụ: ta thực test field Phone, có cases: phone sai phone đúng, ta không nên đặt tên biến phone dùng chung cho hai trường hợp, ta nên tách thành wrongPhone rightPhone Environment lưu array Ví dụ: Khi nhận response trả list giá trị customerId bạn muốn lưu list customerId thành array để request khác bạn lấy random giá trị 56 https://giangtester.com Run script Để đảm bảo test API lúc chạy đúng, có cách làm: - Với TH API có đủ, “đủ” có nghĩa với liệu, action UI có API tương ứng –> Mình tạo test data cách dùng API cần thiết, sau run API test Cách làm giúp cho Test case không bị phụ thuộc vào test data chỗ Ví dụ: Bạn cần test API update_info_user, bạn sử dụng API create_user trước, thay sử dụng user có sẵn hệ thống - Với TH API khơng có đủ, ta nên chuẩn bị sẵn data test DB test Cách làm: Bạn tạo đủ master data cách thủ cơng: data cần thiết để run API, ví dụ bạn tạo list sản phẩm trước thực mua hàng, đặt số lượng sản phẩm mức cao tương đối, ví dụ đặt số lượng = 100 Chạy thử lượt với tất API bạn có với Runner, có lỗi fix Chạy lại lần để đảm bảo hết lỗi (Lưu ý, nên dynamic parameter nhiều có thể, đừng hard code data) Dump DB thành file sql để run lại script run lại file sql trước 57 https://giangtester.com Reference An Introduction to APIs - Brian Cooksey ​https://zapier.com/learn/apis/ Postman Document ​https://www.getpostman.com/docs/ API testing best practices - Bas Dijkstra https://www.ontestautomation.com/api-testingbest-practices/ 58 https://giangtester.com ... thiệu chung Postman Ưu, nhược điểm Postman Postman công cụ để test API cty Postdot Technologies bắt đầu phát triển từ năm 2012 Hiện Postman có phiên bản: Postman, Postman Pro (2016) Postman Enterprise... https://giangtester.com Vấn đề API Docs gồm thành phần thể phần Postman nào? Các thành phần API Document: ▪ Tên API Document ▪ Mô tả API Docs ▪ Tên API ▪ Mô tả API: Mục đích API, note lại mục cần lưu... thành có API với tham số động, linh hoạt, API với liệu cố định 36 https://giangtester.com 37 https://giangtester.com X Xây dựng API Document Postman ngồi việc cung cấp cơng cụ test API cịn hỗ