Biến Postman không lưu trong Runner: Nguyên nhân và cách khắc phục

TL;DR

Các biến được đặt trong quá trình thực thi yêu cầu thủ công thường biến mất khi bạn chạy cùng một collection trong Collection Runner của Postman. Nguyên nhân gốc rễ là sự không khớp phạm vi biến: pm.environment.set hoạt động khác trong trình chạy so với chế độ thủ công, và biến collection hoạt động khác với biến môi trường. Hướng dẫn này giải thích chính xác lý do tại sao điều này xảy ra và cách khắc phục, sau đó chỉ ra cách Apidog xử lý phạm vi biến theo cách khó bị cấu hình sai một cách vô ý hơn.

Giới thiệu

Bạn đã thử nghiệm một API thủ công trong Postman. Bạn chạy một yêu cầu đăng nhập, tập lệnh pre-request đặt một mã thông báo xác thực, và các yêu cầu tiếp theo nhận nó một cách ổn định. Mọi thứ hoạt động.

Sau đó bạn nhấp vào “Run Collection.” Trình chạy khởi động, yêu cầu đăng nhập thành công, nhưng yêu cầu tiếp theo thất bại với lỗi 401. Mã thông báo không có ở đó.

Kịch bản này xuất hiện liên tục trên Stack Overflow và các diễn đàn cộng đồng Postman. Các câu trả lời thường chỉ ra phạm vi biến, nhưng chúng hiếm khi giải thích đầy đủ lý do tại sao hành vi lại khác nhau giữa kiểm thử thủ công và trình chạy.

Hiểu điều này đòi hỏi phải hiểu hệ thống phân cấp phạm vi biến của Postman. Một khi bạn thấy rõ điều đó, cách khắc phục sẽ rất đơn giản.

Hệ thống phân cấp phạm vi biến của Postman

Postman có năm phạm vi biến, được liệt kê từ ưu tiên cao nhất đến thấp nhất:

1. Biến cục bộ (Local variables) – chỉ khả dụng trong lần thực thi tập lệnh hiện tại, không thể truy cập giữa các yêu cầu
2. Biến dữ liệu (Data variables) – được tải từ tệp CSV hoặc JSON cho các lần chạy theo dữ liệu
3. Biến collection (Collection variables) – có phạm vi trong collection, tồn tại xuyên suốt các yêu cầu trong collection đó
4. Biến môi trường (Environment variables) – có phạm vi trong môi trường đã chọn, tồn tại xuyên suốt các collection
5. Biến toàn cục (Global variables) – khả dụng trong bất kỳ collection nào trong bất kỳ môi trường nào

Khi Postman phân giải một tham chiếu biến như {{token}}, nó sẽ đi xuống danh sách này và sử dụng kết quả khớp đầu tiên mà nó tìm thấy.

Vấn đề là "tồn tại" có nghĩa khác nhau tùy thuộc vào cách bạn đang chạy collection.

Tại sao các biến biến mất trong Collection Runner

Sự khác biệt giữa giá trị hiện tại và giá trị ban đầu

Mỗi biến Postman có hai trường: “giá trị ban đầu” và “giá trị hiện tại.”

• Giá trị ban đầu được đồng bộ hóa với đám mây của Postman và chia sẻ với đồng đội.
• Giá trị hiện tại là cục bộ trên máy của bạn và không bao giờ được đồng bộ hóa.

Khi bạn đặt một biến theo chương trình trong một tập lệnh sử dụng pm.environment.set('token', value), Postman sẽ cập nhật giá trị hiện tại trong môi trường hoạt động của bạn.

Trong chế độ kiểm thử thủ công, điều này hoạt động như mong đợi vì các giá trị hiện tại cục bộ của bạn tồn tại xuyên suốt các lần thực thi yêu cầu riêng lẻ trong cùng một phiên.

Trong Collection Runner, hành vi thay đổi. Trình chạy bắt đầu mỗi lần chạy từ trạng thái hiện tại của môi trường khi bắt đầu chạy. Các tập lệnh cập nhật biến trong quá trình chạy hoạt động chính xác trong lần chạy đó. Nhưng nếu trình chạy được cấu hình để xóa biến giữa các lần chạy, hoặc nếu giá trị ban đầu trống và trình chạy sử dụng một bản chụp môi trường mới, bạn có thể kết thúc trong tình trạng tập lệnh của bạn chạy nhưng biến không có vẻ tồn tại.

Vấn đề biến môi trường so với biến collection

Đây là cái bẫy phổ biến hơn. Bạn đang đặt một biến trong một tập lệnh post-response:

pm.environment.set('token', pm.response.json().access_token);

Điều này đặt một biến trong môi trường hoạt động. Nhưng Collection Runner có một tùy chọn tên là “Keep variable values” (Giữ giá trị biến). Nếu hộp kiểm này không được chọn (mặc định là không chọn), trình chạy sẽ đặt lại các biến môi trường về giá trị ban đầu của chúng sau khi chạy. Bất kỳ giá trị nào được đặt trong quá trình chạy sẽ bị loại bỏ.

Nếu bạn đang chạy collection mà không chọn môi trường, pm.environment.set sẽ thất bại một cách âm thầm. Không có môi trường để ghi vào. Biến sẽ biến mất.

Sự không khớp phạm vi giữa chế độ thủ công và chế độ trình chạy

Trong kiểm thử thủ công, bạn thường có một môi trường được chọn và nó tồn tại xuyên suốt toàn bộ phiên Postman của bạn. Khi bạn chạy một yêu cầu, đặt một biến và chạy một yêu cầu khác, tất cả chúng đều diễn ra trong cùng một ngữ cảnh môi trường bền vững.

Collection Runner tạo ra một ngữ cảnh thực thi riêng biệt. Nó tải trạng thái môi trường khi bắt đầu, chạy tất cả các yêu cầu, và sau đó (trừ khi bạn chọn “Keep variable values”) đưa môi trường trở về trạng thái trước khi chạy.

Điều này có nghĩa là các biến được đặt bởi một yêu cầu trong trình chạy sẽ có sẵn cho các yêu cầu tiếp theo trong cùng một lần chạy, nhưng chúng không tồn tại trong bảng điều khiển môi trường của bạn sau khi lần chạy kết thúc trừ khi bạn rõ ràng giữ chúng.

Cách khắc phục

Cách khắc phục 1: Chọn “Keep variable values” trong trình chạy

Trong Collection Runner, trước khi nhấp vào Run:

1. Tìm tùy chọn “Keep variable values” trong bảng cấu hình trình chạy.
2. Đánh dấu vào hộp này.

Điều này yêu cầu trình chạy ghi lại bất kỳ thay đổi biến nào vào môi trường hoạt động của bạn sau khi lần chạy hoàn tất. Các biến được đặt bởi các tập lệnh trong quá trình chạy sẽ hiển thị trong bảng môi trường của bạn khi lần chạy kết thúc.

Khi nào nên sử dụng: Khi bạn muốn trình chạy cập nhật trạng thái chia sẻ, chẳng hạn như làm mới mã thông báo xác thực mà các công cụ khác hoặc các lần chạy tiếp theo sẽ sử dụng.

Khi nào không nên sử dụng: Khi bạn đang chạy nhiều lần lặp và các biến được đặt ở lần lặp 1 sẽ làm ô nhiễm lần lặp 2. Trong trường hợp đó, hãy sử dụng tệp dữ liệu hoặc đặt lại biến một cách rõ ràng khi bắt đầu mỗi lần lặp.

Cách khắc phục 2: Sử dụng biến collection thay vì biến môi trường cho trạng thái trong quá trình chạy

Nếu một biến chỉ cần được chia sẻ giữa các yêu cầu trong cùng một lần chạy collection, hãy sử dụng biến collection thay vì biến môi trường:

// Trong tập lệnh post-response của yêu cầu đăng nhập của bạn:
pm.collectionVariables.set('token', pm.response.json().access_token);

// Trong tập lệnh pre-request của các yêu cầu tiếp theo:
const token = pm.collectionVariables.get('token');

Biến collection luôn khả dụng trong trình chạy bất kể môi trường có được chọn hay không. Chúng tồn tại trong suốt thời gian chạy collection. Chúng là phạm vi phù hợp cho các giá trị được đặt và sử dụng trong một collection duy nhất.

Cách khắc phục 3: Đảm bảo một môi trường được chọn trước khi chạy

pm.environment.set thất bại một cách âm thầm khi không có môi trường nào hoạt động. Trước khi chạy collection:

1. Mở Collection Runner.
2. Xác minh rằng một môi trường được chọn trong danh sách thả xuống “Environment” (Môi trường).
3. Nếu bạn không cần biến cấp môi trường, hãy sử dụng biến collection thay thế (Cách khắc phục 2).

Cách khắc phục 4: Sử dụng giá trị ban đầu cho các biến phải luôn tồn tại

Nếu một biến như baseUrl cần có sẵn ngay từ yêu cầu đầu tiên trong một lần chạy, hãy đặt nó làm giá trị ban đầu trong môi trường của bạn, không chỉ là giá trị hiện tại.

Trong trình chỉnh sửa môi trường:

• Đặt trường “Initial value” (Giá trị ban đầu), không chỉ trường “Current value” (Giá trị hiện tại).
• Giá trị ban đầu là thứ mà trình chạy sử dụng làm trạng thái khởi đầu.

Nếu chỉ có giá trị hiện tại được đặt và trình chạy không có quyền truy cập vào các giá trị hiện tại cục bộ của bạn (ví dụ: một đồng đội chạy collection, hoặc một lần chạy Newman/Apidog CLI), biến sẽ bắt đầu trống.

Cách khắc phục 5: Gỡ lỗi bằng cách ghi log vào console

Thêm console.log vào tập lệnh pre-request và post-response của bạn để xem chính xác điều gì đang xảy ra:

// Tập lệnh Pre-request
console.log('token trước yêu cầu:', pm.collectionVariables.get('token'));
console.log('token môi trường:', pm.environment.get('token'));

Mở Bảng điều khiển Postman (View > Show Postman Console) trước khi chạy collection. Các log sẽ cho bạn thấy chính xác phạm vi nào mà mỗi biến đang được đọc từ đó và giá trị nó giữ ở mỗi bước.

Cách Apidog xử lý phạm vi biến

Apidog sử dụng cùng hệ thống phân cấp phạm vi: global, environment, collection và local. Sự khác biệt chính nằm ở giao diện người dùng (UI).

Trong trình chỉnh sửa biến của Apidog, giá trị ban đầu và giá trị hiện tại được hiển thị với các nhãn và màu sắc rõ ràng. Giao diện này làm cho việc vô tình chỉ đặt giá trị hiện tại trở nên khó khăn hơn. Khi một tập lệnh đặt một biến bằng cách sử dụng pm.environment.set (mà Apidog hỗ trợ để tương thích với Postman), bảng điều khiển môi trường sẽ cập nhật trực quan theo thời gian thực để bạn có thể thấy sự thay đổi xảy ra.

Trình chạy thử nghiệm của Apidog cũng không đặt lại giá trị biến giữa các bước trừ khi bạn cấu hình rõ ràng để làm như vậy. Hành vi mặc định là duy trì trạng thái biến trên các yêu cầu trong một lần chạy, điều này phù hợp với những gì hầu hết các nhà phát triển mong đợi từ việc kiểm thử thủ công.

Đối với các kịch bản nhóm, mô hình ưu tiên cục bộ của Apidog có nghĩa là các biến môi trường được lưu trữ trên đĩa. Không có đồng bộ hóa đám mây nào ghi đè lên các giá trị hiện tại của bạn giữa các lần chạy.

Tóm tắt các lỗi thường gặp

Câu hỏi thường gặp

Tại sao pm.environment.set hoạt động ở chế độ thủ công nhưng không hoạt động trong trình chạy? Ở chế độ thủ công, bạn có một phiên môi trường bền vững. Trong trình chạy, môi trường được tải khi bắt đầu chạy và theo mặc định được đặt lại khi kết thúc. Các tập lệnh đặt biến trong quá trình chạy vẫn hoạt động cho các yêu cầu tiếp theo trong lần chạy đó, nhưng các thay đổi không tồn tại trong môi trường của bạn trừ khi “Keep variable values” được chọn.

Sự khác biệt giữa pm.environment.set và pm.collectionVariables.set là gì? pm.environment.set ghi vào môi trường hoạt động, được chia sẻ trên tất cả các collection sử dụng môi trường đó. pm.collectionVariables.set ghi vào một phạm vi gắn liền với collection cụ thể. Đối với các giá trị chỉ quan trọng trong một lần chạy collection, biến collection phù hợp hơn và không yêu cầu phải chọn môi trường.

Vấn đề này có xảy ra trong Newman không? Có. Newman có cùng mô hình phạm vi. Theo mặc định, Newman bắt đầu mỗi lần chạy với các giá trị ban đầu của môi trường đã xuất và không duy trì các thay đổi sau khi chạy trừ khi bạn sử dụng cờ --export-environment để ghi trạng thái môi trường cuối cùng vào một tệp.

Cờ --export-environment trong Newman là gì? Nó yêu cầu Newman ghi trạng thái cuối cùng của môi trường, bao gồm bất kỳ giá trị nào được đặt bởi các tập lệnh trong quá trình chạy, vào một tệp JSON sau khi lần chạy hoàn tất. Sau đó, bạn có thể truyền tệp đó làm môi trường cho lần chạy tiếp theo. Điều này hữu ích cho các quy trình mà một lần chạy tạo ra các mã thông báo được sử dụng bởi lần chạy tiếp theo.

Apidog có hỗ trợ pm.collectionVariables.set không? Có. Apidog hỗ trợ đầy đủ API tập lệnh của Postman, bao gồm pm.collectionVariables.set, pm.collectionVariables.get, pm.environment.set và pm.environment.get. Các collection được di chuyển từ Postman sử dụng cùng cú pháp tập lệnh.

Làm cách nào để truyền biến từ collection này sang collection khác trong Postman? Sử dụng biến toàn cục: pm.globals.set('token', value). Biến toàn cục tồn tại trên các collection và môi trường trong suốt thời gian của phiên Postman. Hãy cẩn thận với phương pháp này trong cài đặt nhóm vì biến toàn cục không có phạm vi và có thể gây ra xung đột tên.

Các vấn đề về phạm vi biến trong Postman là một trong những nguyên nhân đáng tin cậy nhất gây ra lỗi âm tính giả trong bộ thử nghiệm API. Một thử nghiệm vượt qua thủ công nhưng thất bại trong trình chạy không phải là một thử nghiệm mà bạn có thể tin cậy. Hiểu mô hình phạm vi, sử dụng bộ thiết lập phù hợp cho ngữ cảnh phù hợp và chọn “Keep variable values” khi thích hợp là ba bước giải quyết hầu hết các vấn đề này.