kiến thức Mở đầu về API Testing
- Thread starter phanthilinh95
- Start date
Georgi_Zhukop
Senior Member
Cắm full mắt theo dõi
Head First Java
Senior Member
biết test api thì người ta mặc định sẵn là biết test mobile và web phải k mấy thím?
Hàn Quá Nhanh
Senior Member
Em xin chia sẻ hiểu biết của em về token ạ:còn token đâu, cái này mới quan trọng chứ?
Token là thông tin hoặc công cụ rất cần thiết để truy cập giao diện tài nguyên (API). Token bao gồm:
- Uid (danh tính duy nhất của người dùng)
- Thời gian (dấu thời gian của dấu thời gian hiện tại)
- Biểu tượng (chữ ký, một vài chữ số đầu tiên củaToken là được nén thành một chuỗi thập lục phân có độ dài nhất định bằng cách sử dụng thuật toán Hashingcòn gọi là băm)
Lợi ích của việc sử dụng token:
- Hỗ trợ máy chủ không trạng thái và khả năng mở rộng tốt
- Hỗ trợ cho thiết bị di động rất tốt về mặt nhận tài nguyên
- Hỗ trợ bảo mật tốt hơn
- Hỗ trợ các cuộc gọi ứng dụng hoặc tên miền chéo. Ví dụ: nếu ứng dụng được triển khai trên web1.com, dịch vụ api được triển khai trên web2.com và các yêu cầu ajax được gửi từ web1.com đến web2.com.
Đậu Moè
Junior Member
E kb nữa ý, hồi đó BE là php được đứa bạn code cho vì hồi đó làm CNPM thì e dựng FE thôi ấy. Cái CORS hình như do chrome chặn ấy, lúc đó phải disable cái CORS của chrome đi thì mới POST được. Ehs :<
hdcompany123
Senior Member
co ai test bằng jest ko
king_king
Senior Member
API test thì theo mình sẽ có:
1. Single- manual API test: test chức năng theo từng API, chủ yếu là check business của dự án, chức năng đó có đúng thiết kế hay không ( dựa theo check thông tin request và response) ví dụ:
bạn cần check chức năng đăng nhập( login) - xem logic có đúng ko, vậy việc cần test API cũng tương tự như check manual thông thường khi có FrontEnd rồi. đó là:
gửi request: chắc chắn sẽ bao gồm - username+ password ( có thể thêm thông tin khác, tùy yêu cầu) - chỗ này thường sẽ chia các cases:
2. Auto API: test bằng việc viết script để gửi + nhận api response theo các kịch bản có sẵn. thông thường sẽ dành cho các chức năng đã code xong 1 vòng để check nghiệp vụ xem phần backedn có ok ko. các kịch bản test cũng tương tự nhưng gom nhiều single API lại
vậy có thể viết 1 cycle API theo đó API sau sẽ lấy thông tin trả về từ API trước, viết các script với kết quả dự trù sẵn để trả về ....
1. Single- manual API test: test chức năng theo từng API, chủ yếu là check business của dự án, chức năng đó có đúng thiết kế hay không ( dựa theo check thông tin request và response) ví dụ:
bạn cần check chức năng đăng nhập( login) - xem logic có đúng ko, vậy việc cần test API cũng tương tự như check manual thông thường khi có FrontEnd rồi. đó là:
gửi request: chắc chắn sẽ bao gồm - username+ password ( có thể thêm thông tin khác, tùy yêu cầu) - chỗ này thường sẽ chia các cases:
- đúng username + pass
- đúng username, sai pass
- sai cả 2 ....
2. Auto API: test bằng việc viết script để gửi + nhận api response theo các kịch bản có sẵn. thông thường sẽ dành cho các chức năng đã code xong 1 vòng để check nghiệp vụ xem phần backedn có ok ko. các kịch bản test cũng tương tự nhưng gom nhiều single API lại
- Thêm nữa, có thể nối các API thành 1 vòng cycle : ví dụ chức năng A: tạo order trên Grab sẽ gồm các API:
- Login
- Shop filter
- Menu filter
- Create order
vậy có thể viết 1 cycle API theo đó API sau sẽ lấy thông tin trả về từ API trước, viết các script với kết quả dự trù sẵn để trả về ....
foreveryoung1992
Senior Member
BE có nghĩa là gì vậy thím, trước h em hay hiểu là API server.
P/S: À ý thìm là BackEnd hả. Theo em thì gọi backend thì chưa chuẩn lắm nhỉ, bởi vì backend vẫn có thể là API client lẫn API server
foreveryoung1992
Senior Member
nếu chặn CORS của Chrome thì theo em nghĩa là sai nguyên tắt của API và ý nghĩa bảo vệ server của CORS rồi. Đúng ra là phải bảo API Server cho phép API Client được phép truy cập.
rainbow007
Senior Member
Thực ra thì các phương thức có thể gọi lẫn lộn nhưng để cho m.n đều hiểu thì nên có quy chuẩn chung ... và đa số theo Restful API ... đây là doc cho b tham khảo thêm ... tuy nhiên sẽ có vài usecases
rainbow007
Senior Member
test = jest là test cho code cũng như server mà thým đag viết ... theo như e hiểu là v ...
phanthilinh95
Junior Member
Các method mà client gửi lên server, status code mà server trả về, vậy ngoài status code thì nó còn có dữ liệu trả về, vậy dữ liệu đó là gì? Và nó chứa những gì trong đó? Trong lập trình ứng dụng web, các API sẽ trả kết quả về dạng XML hoặc JSON để các hệ thống khác có thể nói nói chuyện với nhau được.
Hiện nay tuy JSON được sử dụng phổ biến hơn, nhưng XML cũng vẫn đang được dùng bởi nhiều hệ thống lớn.
I. JSON
JSON là viết tắt của JavaScript Object Notation, là một kiểu định dạng dữ liệu tuân theo một quy luật nhất định mà hầu hết các ngôn ngữ lập trình hiện nay đều có thể đọc được. JSON là một tiêu chuẩn mở để trao đổi dữ liệu trên web.
JSON là 1 định dạng đơn giản với 2 thành phần: keys và values.
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, 1 Key sẽ có Value là 1 dãy key + value. Trong hình trên Key có tên là Data có Value là 2 cặp Key + value.
II. XML
XML là từ viết tắt của từ Extensible Markup Language nghĩa là ngôn ngữ đánh dấu mở rộng. XML có chức năng truyền dữ liệu và mô tả nhiều loại dữ liệu khác nhau.
Tác dụng chính của XML là đơn giản hóa việc chia sẻ dữ liệu giữa các nền tảng và các hệ thống được kết nối thông qua mạng Internet.
Trong JSON dùng { } và [] để dánh dấu dữ liệu. XML thì tương tự như HMTL, dùng thẻ <> để đánh dấu và được gọi là nodes.
Lấy luôn ví dụ ở trên nhưng viết bằng xml, nó sẽ như thế này:
III. Định dạng dữ liệu trong HTTP
Quay lại bài 1, phần header có chức năng lưu những thông tin mà người dùng không biết, trong đó có 1 thành phần xác định format của data: Content-Type
Khi client gửi Content-Type trong header của request, nó đang nói với server rằng dữ liệu trong phần body của request là được định dạng theo kiểu đó.
Khi client muốn gửi JSON nó sẽ đặt Content-Type là “application/json”. Khi bắt đầu nhận request, server sẽ check cái Content-Type đầu tiên và như thế nó biết cách đọc dữ liệu trong body.
Ngược lại, khi server gửi lại client 1 response, nó cũng gửi lại Content-Type để cho client biết cách đọc body của response.
Đôi khi client chỉ đọc được 1 loại định dạng, ví dụ là JSON mà server lại trả về XML thì client sẽ bị lỗi.
Vì vậy, một thành phần khác ở trong header là Accept sẽ giúp client xử lý vấn đề trên bằng cách nói luôn với server loại nó có thể đọc được. Ví dụ : Accept : “application/json” .
Chốt lại:
Dựa vào 2 thành phần Content-Type và Accept, client và server có thể hiểu và làm việc một cách chính xác. Ở những bài sau, sẽ lấy ví dụ và minh họa rõ ràng cho Content-Type và Accept trong Header.
[To be continnued ...]
ặc,,, tui lập thread mới có thím @rainbow007 nhắc nên gộp chung zô đây cho các thím tiện cắm mắt zậy .... tui sẽ viết tiếp phần 3 nha ... ^^
Hiện nay tuy JSON được sử dụng phổ biến hơn, nhưng XML cũng vẫn đang được dùng bởi nhiều hệ thống lớn.
I. JSON
JSON là viết tắt của JavaScript Object Notation, là một kiểu định dạng dữ liệu tuân theo một quy luật nhất định mà hầu hết các ngôn ngữ lập trình hiện nay đều có thể đọc được. JSON là một tiêu chuẩn mở để trao đổi dữ liệu trên web.
JSON là 1 định dạng đơn giản với 2 thành phần: keys và values.
- Key thể hiện thuộc tính của Object
- Value thể hiện giá trị của từng Key
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, 1 Key sẽ có Value là 1 dãy key + value. Trong hình trên Key có tên là Data có Value là 2 cặp Key + value.
II. XML
XML là từ viết tắt của từ Extensible Markup Language nghĩa là ngôn ngữ đánh dấu mở rộng. XML có chức năng truyền dữ liệu và mô tả nhiều loại dữ liệu khác nhau.
Tác dụng chính của XML là đơn giản hóa việc chia sẻ dữ liệu giữa các nền tảng và các hệ thống được kết nối thông qua mạng Internet.
Trong JSON dùng { } và [] để dánh dấu dữ liệu. XML thì tương tự như HMTL, dùng thẻ <> để đánh dấu và được gọi là nodes.
Lấy luôn ví dụ ở trên nhưng viết bằng xml, nó sẽ như thế này:
III. Định dạng dữ liệu trong HTTP
Quay lại bài 1, phần header có chức năng lưu những thông tin mà người dùng không biết, trong đó có 1 thành phần xác định format của data: Content-Type
Khi client gửi Content-Type trong header của request, nó đang nói với server rằng dữ liệu trong phần body của request là được định dạng theo kiểu đó.
Khi client muốn gửi JSON nó sẽ đặt Content-Type là “application/json”. Khi bắt đầu nhận request, server sẽ check cái Content-Type đầu tiên và như thế nó biết cách đọc dữ liệu trong body.
Ngược lại, khi server gửi lại client 1 response, nó cũng gửi lại Content-Type để cho client biết cách đọc body của response.
Đôi khi client chỉ đọc được 1 loại định dạng, ví dụ là JSON mà server lại trả về XML thì client sẽ bị lỗi.
Vì vậy, một thành phần khác ở trong header là Accept sẽ giúp client xử lý vấn đề trên bằng cách nói luôn với server loại nó có thể đọc được. Ví dụ : Accept : “application/json” .
Chốt lại:
Dựa vào 2 thành phần Content-Type và Accept, client và server có thể hiểu và làm việc một cách chính xác. Ở những bài sau, sẽ lấy ví dụ và minh họa rõ ràng cho Content-Type và Accept trong Header.
[To be continnued ...]
ặc,,, tui lập thread mới có thím @rainbow007 nhắc nên gộp chung zô đây cho các thím tiện cắm mắt zậy .... tui sẽ viết tiếp phần 3 nha ... ^^
TrungNgaoNgo
Senior Member
Dự án chỗ tôi dùng PATCH chứ không dùng PUT mấy, mới vào nên cũng ngại hỏi cứ theo flow thôi 
sigel
Đã tốn tiền
thím nên dẫn link cái post này lên post #1 để mọi người dễ theo dõi.
phanthilinh95
Junior Member
aww, tui có edit #1 rồi á thím
