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ụ:
    1. 200 – success: Dùng cho happly case: nhận request và trả response có data đúng.
    2. 400 – bad request: Dùng trong các TH lỗi ở phía client ví dụ: sai data type, missing data parameter.
    3. 401 – Unauthorized: Dùng trong việc thiếu token authen
    4. 403 – Forbidden: Dùng cho việc access vào những resource không có quyền hạn
    5. 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.

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. Conclusion

Đâ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.

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

  1. 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

    • Thanks! Hiện tại thì anh ko còn dùng postman nhiều nữa nên cũng không có update gì cả. Và postman nó cũng chỉ thế thôi, chắc cũng ko có gì hơn 😀 Còn TH cụ thể thì chắc lúc nào rảnh thì mới làm được, chứ hiện tại bị bận sang những tools khác.

    • Cách làm sạch đơn giản nhất là run lại script SQL. Nó giống như là restore lại version trước.
      1. Khi môi trường test đã tạo đủ dữ liệu cần thiết –> từ DB export file .sql
      2. Run test API
      3. Run lại script ở bước 1 –> nó sẽ clear hết các data đã được add thêm vào DB ở bước 2.

  2. 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

    • Cái đó ko hề liên quan đến postman em ạ, cái đó thuộc về API design. Ko ai Get dữ liệu theo name và price cả. Thông thường sẽ làm 2 bước:
      1. GET all data –> xác định được cái data mình cần đang có Id bao nhiêu
      2. Từ Id, get toàn bộ thông tin detail của cái object đó.

  3. 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!

    • Ôi, Cảm ơn em rất nhiều. Rất vui là những gì anh chia sẻ lại giúp em áp dụng được vào công việc.
      Hiện tại, anh đã move hoàn toàn công việc API testing bằng postman sang rest-assured nên anh đã không follow những update của postman nữa, nhưng anh sẽ vẫn ngó qua phần Manage Presets. Thank you for your recommmendation!

Leave a Reply

Your email address will not be published. Required fields are marked *