Nội dung bài viết
I. Lý thuyết
- API là gì?
- Protocol
- Json và xml
- Authentication
- Cách test API như thế nào?
- Những việc bạn bắt buộc phải thành thạo khi làm API testing
- Tổng hợp các câu hỏi về api testing
- So sánh Postman và Rest-Assured
- API testing book from A to Y – for Vietnamese testers
- URL là gì?
- Mã lỗi 304 là gì? Nên hiểu thế nào?
II. Postman
- API Testing với Postman (Phần 5) – Giới thiệu chung về Postman
- API Testing với Postman (Phần 6) – Cách tạo Request
- API Testing với Postman (Phần 7) – Collections
- API Testing với Postman (Phần 8) – Environments
- API Testing với Postman (Phần 9) – Test Response
- API Testing với Postman (Phần 10) – Pre-request Script
- API Testing với Postman (Phần 11) – Xây dựng API Document
- API Testing với Postman (Phần 12) – Run Test Suites từ Runner
- API Testing với Postman (Phần 13) – Những lưu ý khi code API test
- API Testing với Postman (Phần 14) – Xử lý array
- API Testing với Postman (Phần 15) – Reuse test script
- API Testing với Postman (Phần 16) – Thực hành test sử dụng Echo service
- API Testing với Postman (Phần 17) – làm việc với “thời gian”
- API Testing với Postman (Phần 18) – validate json schema
- API Testing với Postman (Phần 19) – Phân biệt và sử dụng các loại variables
- API Testing với Postman (Phần 20) – Cách viết Assertion
- API Testing với Postman (Phần 21) – Cách đọc file data test
- API Testing với Postman (Phần 22) – Sử dụng newman cli
- API Testing với Postman (Phần 23) – Sử dụng newman như library
- API Testing với Postman (Phần 24) – Build dynamic request body
- API Testing với Postman (Phần 25) – Đặt biến cho đường dẫn file upload
- API Testing với Postman (Phần 26) – Quản lý loop và branching
- API Testing với Postman (Phần 27) – Lưu response body dưới dạng file csv
- API Testing với Postman (Phần 28) – Extract response từ Array
- API Testing với Postman (Phần 29) – Đọc file CSV
III.Rest-Assured
- [Bài 1] Rest-Assured là gì?
- [Bài 2] Setup project sử dụng Rest-Assured
- [Bài 3] Request GET sử dụng Rest-Assured
- [Bài 4] Request POST sử dụng Rest-Assured
- [Bài 5] Request PUT sử dụng Rest-Assured
- [Bài 6] Request DELETE sử dụng Rest-Assured
- [Bài 7] Project structure cho Automation Api Testing sử dụng Rest-Assured
- [Bài 8] Tách class, method để tránh duplicate code
- [Bài 9] Challenge-Build body object có cấu trúc phức tạp
- [Bài 10] Một số techniques liên quan đến log trong Rest-assured
- [Bài 11] Muốn dùng rest-assured thì học gì
- [Bài 12] Convert json sang POJO
- [Bài 13] Log thông tin request
- [Bài 14] Tạo request body là array
- [Bài 15] Convert json sang POJO (2) – Khi value có thể là 1 phần tử (object) hoặc nhiều phần tử (array)
- [Bài 16] Gọi 1 API nhiều lần cùng lúc
Bài rất bổ ích, cảm ơn anh Giang.
em đang tính apply api testing, về lý thuyết thì em tương đối hiểu, nhưng em muốn hỏi về thực tế 1 chút là khi em xem response request từ system bên em, thì cái nào response nó cũng dài dã man như hình dưới.
1/ em muốn hỏi kinh nghiệm thực tế của anh chút là, ví dụ như cái response bên dưới chẳn hạn, ngoài assert response code (200) thì mình cần phải assert thêm những fields nào nữa để coverage tốt nhất và test cases đủ tin cậy nhất ạ? anh cho em xin vài tips với chứ assert hết đống này chắc code dài hơn cái sớ =]]]]]
2/ Và em có 1 câu hỏi nữa là: giả sử 1 test flow mà UI auto cover rồi, thì liệu có cần làm api auto cho test flow đó nữa không anh (em đánh giá làm cả 2 có thể gây dup effort)? có trường hợp nào mà api detect được bug mà UI không detect được không anh?
Thanks anh nhiều!
1. Tùy em ạ, fields nào là field quan trọng để thực hiện được các flow của user thì đều cần phải assert, như test trên giao diện thôi.
2. UI flow sẽ là end-to-end. API flow chỉ là back-end, nên UI flow sẽ hướng vào user action, còn API flow hướng vào function. Việc trùng lặp là ko thể tránh khỏi, nhưng có 2 flow sẽ lợi thế cho em hơn. Ví dụ
– API flow sẽ làm smoke test –> kiểm tra bản build có đủ điều kiện để thực hiện test sâu hơn hay ko. (run nhanh)
– UI flow sẽ làm sanity test –> kiểm tra xem có đủ điều kiện để release hay ko. (run lâu)
Hi anh Giang,
cho em hỏi 2 câu ko liên quan lắm:
1/ có cách/dấu hiệu nào nhận biết 1 system là microservices system ko anh? em có hiểu khái niệm microservices nhưng nếu đưa em 1 system hỏi em cái này là microservices hay monolith thì em ko có kinh nghiệm để nhận dạng được.
2/ việc test api cho system microservices và 1 system monolith có khác nhau nhiều ko anh?
Thanks anh
Cảm ơn em, câu hỏi rất hay.
Vì microservices(mcs) và monolith(mnl) chỉ khác nhau về mặt architecture để phù hợp cho từng nhu cầu khác nhau, ko phải cứ mcs là tốt, là hay.
2/ API test là backbox testing nên test api cho 2 thằng gần như giống nhau.
1/ Để nhận biết thì chỉ có cách đọc document của dự án (xem bản vẽ architecture), dấu hiệu nhận biết thì mcs có rất nhiều service khác nhau nên ngta thường sử dụng docker và kubernetes (k8s) để manage từng service đấy. Còn đứng từ phía end-user, nhìn mỗi cái front-end (web, mobile) bảo trả lời được đây là mcs hay mnl thì cũng rất khó.
Rất đẳng cấp