API Testing với Postman (Phần 13) – Những lưu ý khi code API test

Postman đã thay đổi, cải tiến rất nhiều kể từ khi mình viết những bài trước. Bài này sẽ giới thiệu 1 số tips mình sử dụng khi làm auto test API với postman.

I. Postman – Workspace

Trước kia, ta chỉ có 1 workspace và làm nhiều project trên đó nhưng đã có tính năng tách workspace thì ta nên tách mỗi project là 1 workspace, sẽ dễ nhìn hơn rất nhiều, tránh được những nhầm lẫn khi kéo thả các request từ folder này sang folder khác.

Ngoài ra, còn có nhiều tiện ích mà chúng ta ít sử dụng:

Trong số này thì mình hay sử dụng console log nhất vì console log sẽ show toàn bộ thông tin request và response, giúp ích cho việc debug nhiều. Nếu bạn thắc mắc là mỗi khi run Send API thì response sẽ trả về được hiển thị ở phía dưới rồi, cần gì phải console log? Có 2 trường hợp bạn sẽ cần phải sử dụng console log:

  1. Bạn test theo Runner. Runner dashboard chỉ lưu full thông tin của 10 request đầu tiên, những request phía sau, nó chỉ lưu thông tin cơ bản, bạn ko xem được full thông tin nếu có request nào đó bị lỗi.
  2. Nếu bạn viết các tham số của 1 API dưới dạng biến thì bạn cần có console log thì mới view được giá trị thực các tham số ở mỗi lần run.

II. Test

Ở phần test, mình có nói ở bài 9 rồi nhưng có 1 vài điểm mọi người cần chú ý:

  1. Các error code cần được check nếu các error code này được sử dụng đúng như định nghĩa của REST API ví dụ:
    • 200 - success: Dùng cho happly case: nhận request và trả response có data đúng.
    • 400 - bad request: Dùng trong các TH lỗi ở phía client ví dụ: sai data type, missing data parameter.
    • 401 - Unauthorized: Dùng trong việc thiếu token authen
    • 403 - Forbidden: Dùng cho việc access vào những resource không có quyền hạn
    • 500 - Server error: Dùng cho các vấn đề error của server: Thiếu library, disconnect DB…
  2. Ngoài error code thì có thể sử dụng response data để verify thêm. Đọc lại bài này để biết cách test API như thế nào.
  3. Ngoài ra, các built-in function của Postman đã được thay đổi khá nhiều, các bạn xem ở đây. Link docs

III. Environment

Phần này thì cũng không có nhiều sự thay đổi, nhưng có 1 số lưu ý nhỏ

  1. Nên đặt tên biến meaningfull. Ví dụ: ta thực hiện test 1 field là Phone, thì có 2 cases: phone sai và phone đúng, ta không nên đặt tên biến là phone và dùng chung cho cả hai trường hợp, ta nên tách ra thành wrongPhone và rightPhone.
  2. Environment có thể lưu được array. Ví dụ: Khi nhận response trả về 1 list các giá trị customerId và bạn muốn lưu list customerId đấy về thành 1 array để request khác bạn có thể lấy random các giá trị đấy.

Muốn biết thêm nhiều kỹ thuật nữa, hãy đăng ký lớp postman script!

IV. Run script

Để đảm bảo rằng test API lúc nào chạy cũng đúng, mình có 2 cách làm:
1. Với TH các API có đủ, “đủ” ở đây có nghĩa là với bất cứ cái dữ liệu, action nào trên UI thì cũng có API tương ứng. –> Mình sẽ tạo test data bằng cách dùng API cần thiết, sau đó mới run API test. Cách làm này sẽ giúp cho các Test case không bị phụ thuộc vào test data ở chỗ nào cả.
Ví dụ: Bạn cần test API update_info_user, bạn sẽ sử dụng API create_user trước, thay vì sử dụng 1 user đã có sẵn trong hệ thống

2. Với TH các API không có đủ, ta nên chuẩn bị sẵn các data test của mình và cả DB test nữa. Cách làm:

  1. Bạn tạo ra đủ các master data bằng cách thủ công: các data cần thiết để có thể run được API, ví dụ bạn tạo ra list các sản phẩm trước khi thực hiện mua hàng, đặt số lượng của sản phẩm ở mức cao tương đối, ví dụ đặt số lượng = 100.
  2. Chạy thử 1 lượt với tất cả các API bạn có với Runner, nếu có lỗi thì fix.
  3. Chạy lại lần 2 để đảm bảo đã hết lỗi. (Lưu ý, nên dynamic parameter nhiều nhất có thể, đừng hard code data)
  4. Dump DB ra thành 1 file sql để khi nào mình run lại script thì mình sẽ run lại file sql này trước.

IV. Tổng kết

Đây là những gì mình rút ra được trong 2 tuần viết code test API cho dự án, có thể nó còn sai ở đâu đó nhưng tính đến thời điểm hiện tại vẫn chạy OK. Trong tương lai nếu có thời gian mình sẽ viết chi tiết các case cụ thể như những bài trước để các bạn có thể áp dụng được luôn.

5 1 vote
Article Rating
Subscribe
Notify of
guest
15 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Thuận Trần
Thuận Trần
5 years ago

Hy vọng anh sẽ ra thêm các bài hướng dẫn và làm trực tiếp, để tụi em có thể làm theo và hình dung ra nhiều thứ hơn trong Postman. Em cảm ơn

noobtester
noobtester
5 years ago

Hi anh!
Anh có thể chia sẻ về cách làm sạch môi trường kiểm thử không ạ. Em cảm ơn

noobtester
noobtester
5 years ago
Reply to  Giang Nguyen

Vâng, em cảm ơn anh!
thông tin này rất hữu ích với những người mới bắt đầu như em

Hiếu
Hiếu
5 years ago

Em chỉ mới lần đầu sử dụng Postman nên chưa hiểu rõ. Anh cho em hỏi mình muồn get dữ liệu cụ thể về thì làm sao a ? ví dụ
{
“id”: “12”,
“name”: “dien thoai”,
“price”: “1000”,
“status”: “true”
}
Get theo name hoặc price để postman trả về cái đó thôi
em thử nhưng không dc chỉ có thể get hết dữ liệu về hoặc get theo id
API em sử dụng ở trang https://www.mockapi.io

Hannah Pham
Hannah Pham
4 years ago

Cảm ơn các bài viết của anh rất nhiều. Em đã học và áp dụng được rất nhiều thứ cho công việc hiện tại của mình.
Khi làm có 1 chỗ em thấy cũng rất hữu ích trong postman là phần Manage Presets chưa thấy anh đề cập trong bài viết.
Đó là một note nho nhỏ hi vọng anh cập nhật cho document của anh.
Em cảm ơn!

Nghĩa Nguyễn
Nghĩa Nguyễn
2 years ago

dạ em mới sử dụng postman nên trong quá trình sử dựng đã xảy ra lỗi Error: connect ECONNREFUSED 127.0.0.1:8080 mong anh có thể hướng dẫn cách e fix với ạ. em cảm ơn anh nhiều ạ.

Daisy Nguyen
Daisy Nguyen
1 year ago

Hi bạn, theo như mình gặp thì TH này do địa chỉ máy tính mình dùng không có quyền connect tới server của API nên không call được. Mong nhận được các góp ý khác từ mọi người!

Daisy Nguyen
Daisy Nguyen
1 year ago

Hi, do mình đang setting proxy, sau khi gg search, mình bỏ proxy config đi thì call đc.

uncheck proxy config.png
Last edited 1 year ago by Daisy Nguyen