Environments — dev / staging / production setup — API Testing with Postman Advanced

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là một QA vừa viết xong 40 request để test API của một sàn thương mại điện tử. Mọi thứ chạy ngon lành trên http://localhost:8080. Sếp bảo: "Chạy lại toàn bộ bộ test này trên môi trường staging để chuẩn bị release." Bạn hoảng hốt nhận ra mình phải mở từng request một, sửa localhost:8080 thành staging-api.shopee.vn, sửa từng token, từng ID, từng khóa API. 40 request, mỗi request vài chỗ cần sửa. Nửa tiếng sau bạn sửa xong, chạy, và lỗi tùm lum — vì bạn quên sửa 3 request. Đến lúc sếp bảo test trên production thì bạn muốn khóc.

Đây chính xác là vấn đề mà Environment (môi trường) trong Postman sinh ra để giải quyết. Environment là một bộ biến (variables) được áp dụng khi bạn chạy request. Thay vì viết cứng URL, token, ID vào từng request, bạn viết chúng dưới dạng biến — ví dụ {{base_url}}, {{token}} — rồi để mỗi environment giữ giá trị riêng của mình. Muốn chuyển từ dev sang staging sang production? Chỉ cần đổi environment ở góc trên bên phải Postman. Một cú click thay cho nửa tiếng sửa tay.

Với một QA chuyên nghiệp, kỹ năng tổ chức environment tốt là ranh giới giữa một bộ test "chạy được trên máy tôi" và một bộ test thực sự dùng được trong quy trình phát triển của cả team. Bài này sẽ dạy bạn cách thiết lập ba môi trường kinh điển — dev, staging, production — một cách bài bản, an toàn và dễ bảo trì.

Khái niệm cốt lõi

Environment là gì

Environment trong Postman là một tập hợp các cặp key-value (khóa-giá trị) được lưu chung một tên. Khi bạn "kích hoạt" một environment và trong request có tham chiếu {{ten_bien}}, Postman sẽ thay thế {{ten_bien}} bằng giá trị tương ứng trong environment đang active.

Ví dụ, cùng một request GET {{base_url}}/api/products:

Khi active environment Dev, base_url = http://localhost:8080 → request thực chạy tới http://localhost:8080/api/products.
Khi active environment Staging, base_url = https://staging-api.shopee.vn → request chạy tới staging.
Khi active environment Production, base_url = https://api.shopee.vn → request chạy tới production.

Request không đổi một chữ nào. Chỉ có environment đổi.

Vì sao tách dev / staging / production

Trong quy trình phát triển phần mềm thực tế, code đi qua nhiều "chặng":

Dev (development): nơi lập trình viên đang code, thường chạy trên máy cá nhân hoặc một server dev nội bộ. Dữ liệu ở đây là dữ liệu rác, tạo ra rồi xóa thoải mái. API có thể sập bất cứ lúc nào vì đang được sửa.
Staging: bản sao gần giống production nhất, dùng để test cuối cùng trước khi release. Cấu hình, phiên bản, dữ liệu mẫu đều mô phỏng thật. Đây là nơi QA "diễn tập" trước ngày công diễn.
Production: môi trường thật, nơi khách hàng thật đang dùng. Mọi thao tác ở đây có hậu quả thật — tạo đơn hàng thật, trừ tiền thật.

Việc tách environment không chỉ để tiện. Nó là một rào chắn an toàn. Bạn tuyệt đối không muốn vô tình chạy một request DELETE /api/users/all khi đang trỏ nhầm vào production. Environment giúp bạn luôn biết rõ mình đang "đứng" ở đâu.

Environment variable vs các loại biến khác

Postman có nhiều tầng biến (bài 6 sẽ đi sâu về scope), nhưng ở đây bạn cần phân biệt cơ bản:

Environment variable: chỉ tồn tại khi environment đó active. Đây là nơi bạn để những giá trị khác nhau giữa các môi trường — URL, token, ID người dùng test, khóa API.
Collection variable / Global variable: dùng cho những giá trị giống nhau ở mọi môi trường — ví dụ số phiên bản API v2, hay một hằng số dùng chung.

Nguyên tắc vàng: cái gì thay đổi theo môi trường thì để trong environment; cái gì cố định thì để ở collection hoặc global.

Initial value vs Current value — điểm cực kỳ quan trọng

Mỗi biến trong environment có hai cột giá trị:

Initial value (giá trị khởi tạo): giá trị được đồng bộ lên cloud và chia sẻ cho cả team khi bạn share collection/environment.
Current value (giá trị hiện tại): giá trị chỉ nằm trên máy bạn, không đồng bộ, không ai khác thấy.

Điều này quyết định sống còn cho bảo mật. Nếu bạn nhét token production hay khóa API bí mật vào Initial value, nó sẽ bị đẩy lên cloud và lộ cho bất kỳ ai trong workspace. Rất nhiều vụ rò rỉ khóa API xuất phát từ đúng lỗi này. Với secret, bạn để Current value thôi, hoặc dùng loại biến secret (Postman sẽ ẩn giá trị dưới dạng dấu chấm).

Tình huống thực tế

Ví dụ 1 — Đội QA của một startup fintech Việt Nam sửa tay và trả giá

Một startup ví điện tử ở TP.HCM (tạm gọi là PayGo) có đội QA 4 người test API nạp/rút tiền. Ban đầu họ chưa dùng environment — mọi URL viết cứng trỏ về staging. Một hôm, bạn QA tên Linh cần kiểm tra nhanh một bug chỉ tái hiện trên dev, nên cô mở 12 request, thay tay staging-api.paygo.vn thành dev-api.paygo.vn. Test xong, cô quên đổi 3 request trở lại. Đồng nghiệp khác kéo (pull) collection về, chạy regression, và 3 request kia âm thầm bắn vào dev — nơi dữ liệu đang dở dang — khiến cả bộ test báo đỏ vô căn cứ. Cả buổi chiều trôi qua để truy ra rằng lỗi không nằm ở code mà nằm ở URL bị lẫn.

Diễn giải: vấn đề không phải Linh cẩu thả, mà là quy trình không có environment nên buộc con người phải sửa tay — và con người thì luôn quên. Bài học: đừng bao giờ viết cứng URL vào request. Tách URL thành {{base_url}} ngay từ request đầu tiên, để việc "đổi môi trường" trở thành thao tác chọn dropdown thay vì thao tác sửa 12 chỗ.

Ví dụ 2 — Sàn TMĐT tách token theo môi trường

Một team làm việc trên API của một sàn TMĐT (giả định tên TikiClone) xây dựng ba environment: Dev, Staging, Production. Mỗi environment có cùng bộ biến — base_url, access_token, test_user_id, api_key — nhưng giá trị khác nhau. Điều thông minh họ làm: token production được đặt là loại secret và chỉ điền vào Current value trên máy của trưởng nhóm QA. Các thành viên khác khi cần test production phải tự lấy token của mình. Nhờ vậy, khi họ share environment lên workspace, phần Initial value của access_token production để trống — không ai vô tình mang token quyền cao đi khắp nơi.

Kết quả: khi release phiên bản mới, họ chạy cùng một collection 200 request lần lượt trên Dev → Staging → Production chỉ bằng cách đổi dropdown environment. Toàn bộ diễn ra trong 15 phút thay vì cả buổi.

Bài học: cấu trúc biến giống nhau giữa các environment (cùng tên key), chỉ khác giá trị. Và secret production luôn ở Current value, không lên cloud.

Ví dụ 3 — Suýt xóa dữ liệu production vì không nhìn dropdown

Một anh QA ở công ty logistics kể lại: anh đang test API hủy đơn hàng, chạy vòng lặp DELETE /api/orders/{{order_id}} với một danh sách 50 order ID. Anh tưởng mình đang ở Staging. May thay, anh có thói quen đặt tên biến env_name trong mỗi environment (Dev → "DEV", Prod → "PROD") và in nó ra qua một dòng test console.log(pm.environment.get("env_name")). Console hiện chữ "PROD" đỏ chót. Anh dừng tay kịp lúc — vì environment đang active vô tình là Production do lần trước quên đổi lại.

Bài học: thêm một biến "cột mốc" như env_name vào mỗi environment và in ra ở console (hoặc kiểm tra trong pre-request script) để luôn tự nhắc mình đang đứng ở đâu. Một dòng phòng thủ nhỏ có thể cứu cả cơ sở dữ liệu.

Hướng dẫn từng bước

Bước 1 — Tạo environment đầu tiên

Ở thanh bên trái Postman, chọn tab Environments, nhấn dấu + để tạo mới. Đặt tên rõ ràng, ví dụ Shopee - Dev. Tên nên gồm tên dự án + tên môi trường để khi có nhiều dự án bạn không bị lẫn.

Bước 2 — Khai báo các biến

Trong bảng environment, thêm các dòng biến. Một bộ khởi đầu điển hình cho test API:

Variable	Type	Initial value	Current value
`base_url`	default	`http://localhost:8080`	`http://localhost:8080`
`env_name`	default	`DEV`	`DEV`
`api_key`	secret	(để trống)	`dev_key_abc123`
`access_token`	secret	(để trống)	(điền sau khi login)
`test_user_id`	default	`1001`	`1001`

Lưu ý: api_key và access_token để type là secret, và không điền Initial value nếu đó là giá trị nhạy cảm.

Bước 3 — Nhân bản cho các môi trường còn lại

Nhấn chuột phải vào environment vừa tạo, chọn Duplicate, đổi tên thành Shopee - Staging. Giữ nguyên tên các biến, chỉ đổi giá trị:

base_url → https://staging-api.shopee.vn
env_name → STAGING

Làm tương tự để có Shopee - Production với base_url = https://api.shopee.vn, env_name = PROD. Việc duplicate đảm bảo cấu trúc biến giống hệt nhau — đây là điều kiện để cùng một request chạy mượt trên cả ba.

Bước 4 — Dùng biến trong request

Trong request, thay URL cứng bằng biến:

GET {{base_url}}/api/products?limit=20

Trong tab Headers:

Authorization: Bearer {{access_token}}
X-API-Key: {{api_key}}

Khi gõ {{, Postman sẽ gợi ý danh sách biến khả dụng. Rê chuột lên {{base_url}} để xem giá trị hiện tại — cách kiểm tra nhanh xem biến đã được resolve đúng chưa.

Bước 5 — Kích hoạt và chuyển đổi environment

Ở góc trên cùng bên phải Postman có một dropdown (mặc định ghi "No Environment"). Chọn Shopee - Dev để kích hoạt. Từ giờ mọi {{base_url}} sẽ lấy giá trị của Dev. Muốn chạy trên staging? Chỉ cần đổi dropdown sang Shopee - Staging. Không đụng vào bất kỳ request nào.

Bước 6 — Ghi token động vào environment sau khi login

Thực tế token thường lấy được sau khi gọi request đăng nhập. Trong tab Tests của request login, bạn có thể lưu token trả về vào environment để các request sau dùng lại:

const data = pm.response.json();
pm.environment.set("access_token", data.token);

Từ lúc này, mọi request dùng {{access_token}} sẽ tự động có token mới nhất của đúng environment đang active. Đây là cầu nối tự nhiên sang bài "Chained Requests" ở phần sau của khóa học.

Lỗi thường gặp & mẹo

Lỗi: quên kích hoạt environment. Request gọi {{base_url}} nhưng dropdown đang "No Environment" → biến không resolve, Postman báo URL sai hoặc gửi tới undefined. Luôn liếc dropdown góc phải trước khi bấm Send.

Lỗi: nhét secret vào Initial value. Đây là lỗi nguy hiểm nhất. Initial value đồng bộ lên cloud và chia sẻ cho cả team. Token production của bạn có thể lộ ra ngoài. Mẹo: với mọi giá trị nhạy cảm, đặt type là secret và chỉ điền Current value.

Lỗi: đặt biến giống nhau nhưng khác tên giữa các environment. Ví dụ Dev dùng baseUrl còn Prod dùng base_url. Cùng một request sẽ chạy được ở môi trường này nhưng gãy ở môi trường kia. Mẹo: duplicate environment thay vì tạo mới thủ công, để bộ tên key luôn khớp.

Lỗi: nhầm environment và không nhận ra. Mẹo phòng thủ (như ví dụ 3): thêm biến env_name và in ra console; hoặc thêm một cảnh báo trong pre-request script khi env_name === "PROD" để bắt bạn xác nhận trước khi chạy request phá hủy dữ liệu.

Mẹo: đặt tên environment có tiền tố dự án. Shopee - Dev, Shopee - Prod thay vì chỉ Dev, Prod. Khi bạn làm nhiều dự án, dropdown sẽ không thành một mớ hỗn độn.

Mẹo: dùng màu/thứ tự để phân biệt. Đặt Production ở cuối danh sách, tên viết hoa PRODUCTION, để mắt bạn tự cảnh giác mỗi khi chọn phải nó.

Mẹo: đừng để rác trong environment. Sau mỗi kỳ test, xóa các biến tạm không dùng nữa. Environment gọn giúp cả team đọc hiểu nhanh.

Bài tập thực hành

Tạo bộ ba environment. Tạo ba environment Demo - Dev, Demo - Staging, Demo - Prod cho API công khai https://reqres.in (giả lập bằng cách cho base_url cả ba trỏ về https://reqres.in nhưng đặt env_name khác nhau). Mỗi environment có: base_url, env_name, test_user_id.

Viết request dùng biến. Tạo request GET {{base_url}}/api/users/{{test_user_id}}. Chuyển lần lượt qua ba environment và quan sát: nếu bạn để test_user_id khác nhau (2, 3, 4), response trả về user khác nhau mà request không đổi.

Bảo mật secret. Thêm biến api_key type secret, điền một giá trị giả vào Current value nhưng để trống Initial value. Kiểm chứng bằng cách rê chuột và xác nhận giá trị bị ẩn.

Ghi biến động. Ở tab Tests của một request bất kỳ, viết pm.environment.set("last_run", new Date().toISOString());. Chạy request, rồi mở environment ra xem biến last_run đã được ghi. Đây là bước đệm cho việc lưu token động.

Dòng phòng thủ. Thêm vào pre-request script của một request "nguy hiểm" đoạn kiểm tra: nếu pm.environment.get("env_name") === "PROD" thì console.warn("Bạn đang chạy trên PRODUCTION!"). Chạy thử trên từng environment và quan sát console.

Tóm tắt

Environment là bộ biến áp dụng khi chạy request, cho phép chuyển giữa dev / staging / production chỉ bằng một dropdown, không sửa từng request.
Tách URL, token, ID thành biến {{...}} ngay từ đầu — đừng bao giờ viết cứng — để việc đổi môi trường thành thao tác một click.
Ba môi trường kinh điển: dev (nghịch thoải mái), staging (diễn tập trước release), production (thật, cẩn trọng tối đa). Việc tách chúng là một rào chắn an toàn.
Giữ tên biến giống nhau giữa các environment, chỉ đổi giá trị; hãy dùng Duplicate để đảm bảo điều đó.
Phân biệt Initial value (đồng bộ lên cloud, cả team thấy) và Current value (chỉ trên máy bạn). Secret luôn để Current value, dùng type secret.
Dùng biến "cột mốc" như env_name in ra console để luôn biết mình đang đứng ở môi trường nào — một dòng nhỏ có thể cứu cả cơ sở dữ liệu production.

Nắm vững environment, bạn đã có nền móng để mọi bài tiếp theo — từ variables scope, pre-request scripts, tới data-driven testing và CI/CD — vận hành trơn tru trên nhiều môi trường khác nhau.