Sử dụng biến trong POSTMAN: Cách tối ưu hóa kiểm thử API
Biến (Variable) có thể là một khái niệm mới đối với những người không chuyên trong lĩnh vực công nghệ thông tin, nhưng lại rất quan trọng đối với các Automation Tester thực hiện Kiểm thử tự động. Nếu bạn đang bắt đầu tìm hiểu về Kiểm thử tự động API, thì Biến chính là một trong những khái niệm đầu tiên và quan trọng nhất bạn cần nắm vững. Hãy cùng Test Mentor khám phá về cách hoạt động của Biến trong Kiểm thử API bằng POSTMAN nhé!
Xem bài trước: Hướng dẫn cài đặt môi trường kiểm thử local
Nội Dung Bài Viết
- Một số vấn đề khi kiểm thử thủ công API bằng POSTMAN
- Vấn đề 1: Lặp lại khai báo các giá trị chung như URL cơ sở (base URL) ở nhiều request.
- Vấn đề 2: Tạo dữ liệu kiểm thử duy nhất cho mỗi lần thực thi.
- Vấn đề 3: Tạo và quản lý bộ dữ liệu kiểm thử (test data) riêng cho từng môi trường kiểm thử (test environment).
- Vấn đề 4: Gán thủ công giá trị trả về từ API đầu tiên cho các API tiếp theo.
- Biến là gì?
- Biến hoạt động như thế nào trong POSTMAN?
- Sample Script và cách giải quyết những vấn đề được đề cập ở đầu bài viết
- Các cú pháp sử dụng trong test script
- Kết luận
- Tài liệu tham khảo
Một số vấn đề khi kiểm thử thủ công API bằng POSTMAN
Vấn đề 1: Lặp lại khai báo các giá trị chung như URL cơ sở (base URL) ở nhiều request.
Giả sử dự án có 2 phases và tổng cộng có 50 API cần kiểm thử.
- Phase 1, URL cơ sở là https://developapi-phase1.com/
- Phase 2, thay đổi thành https://developapi-phase2.com/
Nếu thực hiện kiểm thử thủ công, chúng ta sẽ phải thực hiện tới 100 lần cho thao tác khai báo và sửa đổi URL cơ sở cho cả 2 phases. Ngoài ra, khi thực hiện kiểm thử ở phase 2, trường hợp quên không sửa lại URL cơ sở sẽ dẫn đến việc kiểm thử sai đối tượng. Điều này sẽ gây lãng phí thời gian và tạo ra nhiều sai sót trong quá trình kiểm tra API.
Vấn đề 2: Tạo dữ liệu kiểm thử duy nhất cho mỗi lần thực thi.
Trong thực tế, chúng ta sẽ phải thực hiện kiểm thử một số API yêu cầu dữ liệu đầu vào là duy nhất (unique) cho mỗi lần thực thi. Tức là, nếu chúng ta cần chạy một API 50 lần, chúng ta phải thay đổi dữ liệu đầu vào để đảm bảo tính duy nhất trong mỗi lần thực thi. Tuy nhiên, việc tạo và thay đổi dữ liệu khác nhau trong 50 lần chạy sẽ mất rất nhiều thời gian và dễ gây ra sự trùng lặp.
Vấn đề 3: Tạo và quản lý bộ dữ liệu kiểm thử (test data) riêng cho từng môi trường kiểm thử (test environment).
Thông thường, Tester sẽ phải thực hiện kiểm thử ít nhất trên hai môi trường, ví dụ: môi trường develop và môi trường staging. Dữ liệu sử dụng cho kiểm thử, như URL cơ sở hay giá trị Authorization, thường khác nhau giữa các môi trường này. Giả sử trường hợp khách hàng báo cáo bug trên môi trường production, Tester cần tái hiện bug đó trên các môi trường develop và staging để xác định nguyên nhân và giai đoạn xảy ra lỗi. Nếu không quản lý và lưu trữ dữ liệu kiểm thử theo từng môi trường, khi đó chúng ta sẽ phải mất thời gian để tạo lại từ đầu.
Vấn đề 4: Gán thủ công giá trị trả về từ API đầu tiên cho các API tiếp theo.
Đối với các API cần chứng thực trước khi gọi, như API GET product, chúng ta cần sử dụng token được trả về từ API Login (ví dụ: thời hạn hiệu lực của token là 30 phút). Trong trường hợp thực hiện kiểm thử thủ công, chúng ta phải sao chép giá trị token và dán nó vào trường Authorization của từng request. Sau mỗi 30 phút token hết hiệu lực, cần lặp lại thao tác trên. Cũng giống như vấn đề 1, việc sao chép và dán thủ công như vậy sẽ gây mất thời gian để sửa những sai sót do quá trình thực hiện bằng tay không đảm bảo là luôn đúng.
Liệu rằng có cách nào để giải quyết các vấn đề trên hay không? Sau một thời gian tìm hiểu về các tính năng nâng cao của POSTMAN, Hà đã học được cách sử dụng Biến để giải quyết các vấn đề trên. Vì vậy, trong bài viết này, Hà muốn chia sẻ về Biến và những cách mà Biến đã giúp Hà nâng cao hiệu suất trong quá trình kiểm thử API.
Xem thêm: Manual test là gì? Sự khác biệt giữa manual test và automation test
Biến là gì?
Theo Wikipedia, Biến được định nghĩa là một vị trí lưu trữ kết nối với một tên tượng trưng (định danh) liên quan, chứa một lượng thông tin đã biết hoặc chưa biết được gọi là giá trị.
Để dễ hiểu hơn, bạn hãy tưởng tượng bộ nhớ máy tính như một chiếc tủ và Biến là những chiếc hộp được đặt bên trong chiếc tủ đó. Mỗi hộp được dán nhãn (tên biến – variable name) để biết nội dung của nó, và bên trong mỗi hộp chứa các đồ vật hoặc thông tin cụ thể (giá trị của biến – variable value). Bạn có thể đặt hoặc thay đổi các đồ vật trong hộp bất cứ khi nào.
Vậy, trong lập trình, Biến bao gồm hai thành phần: tên biến (variable name) và giá trị của biến (variable value). Và nó được sử dụng để lưu trữ và quản lý dữ liệu một cách linh hoạt trong chương trình.
Tham khảo thêm khóa học API Testing từ cơ bản đến nâng cao của Test Mentor:
Biến hoạt động như thế nào trong POSTMAN?
Cú pháp khai báo Biến:
- Khai báo Biến Environment, Collection, Global
Đối với những loại biến này, ở tab Variables của mỗi loại, chúng ta chỉ cần nhập tên biến, giá trị khởi tạo (Initial Value) và giá trị hiện tại (Current Value). Khi được gọi, Biến sẽ sử dụng giá trị hiện tại.
- Khai báo biến ở Tab Pre-request Script và Tab Tests
Ở Tab Pre-request Script và Tab Test, chúng ta sẽ sử dụng cú pháp khai báo biến của Javascript. Dưới đây là cách khai báo và gán giá trị cho biến:
let a → khai báo biến với tên là a và giá trị mặc định là null
let b = 123 → khai báo biến với tên là b và gán giá trị là 123 (dữ liệu kiểu số)
let c = “abc” → khai báo biến với tên là c và gán giá trị là abc (dữ liệu kiểu chuỗi)
Cú pháp gọi Biến:
- Cú pháp gọi Biến được sử dụng trong Endpoint, Method, Header, Request Parameter ở tab Params hoặc Body:
{{tên_biến}}
- Cú pháp gọi Biến động (Dynamic Variable):
{{$tên_biến_động}}
Tham khảo thêm về Dynamic Variable: Use predefined variables to return values
Phân loại và phạm vi hoạt động Biến trong POSTMAN
Trong POSTMAN, Biến được phân chia thành 5 loại để phục vụ các mục đích sử dụng khác nhau. Dưới đây là 5 loại Biến trong POSTMAN, được sắp xếp theo phạm vi hoạt động từ hẹp đến rộng:
1. Biến cục bộ (Local Variables)
- Định nghĩa: Là các biến dùng để lưu trữ tạm thời thông tin trong quá trình chạy một API cụ thể. Tức là, khi bắt đầu chạy API, các biến này được khai báo và tồn tại trong bộ nhớ. Sau khi API chạy xong, chúng sẽ bị xóa khỏi bộ nhớ. Trong môi trường POSTMAN, Biến cục bộ chỉ có hiệu lực trong phạm vi Tab cụ thể mà chúng được khai báo.
- Ví dụ 1: Trong cùng một API Login, khi khai báo Biến ở Tab Pre-request Script thì chỉ có thể truy cập và sử dụng Biến này trong phạm vi Tab Pre-request Script. Nếu bạn cố gắng truy cập vào biến đó từ các Tab khác, chẳng hạn như Tab Tests thì sẽ nhận được thông báo lỗi not defined (chưa được khai báo).
→ Điều này có nghĩa rằng, dù trong cùng một API, Biến cục bộ chỉ có hiệu lực trong phạm vi Tab mà nó được khai báo.
- Ví dụ 2: Khi khai báo Biến “a” trên Tab Pre-request Script của API Login thì Biến này chỉ có hiệu lực trong phạm vi Tab Pre-request Script của API Login. Chúng ta không thể truy cập vào Biến “a” trong Tab Pre-request Script của các API khác như API GET productId.
2. Biến dữ liệu (Data Variables)
- Định nghĩa: Trong ngữ cảnh kiểm thử API với POSTMAN, Biến dữ liệu là biến được khai báo trên các file test data như CSV hoặc JSON. Chúng cũng có giá trị tạm thời khi chạy API bằng chức năng Runner hoặc Newman.
- Ví dụ: Hãy tưởng tượng chúng ta đang kiểm thử API Login với 3 trường hợp khác nhau trong cùng 1 lần chạy Collection. Các test data cho mỗi trường hợp kiểm thử như TestcaseID, Description, Email, Password, và httpStatusCode được tạo và lưu trữ trong file CSV.
Khi thực thi API Login bằng chức năng Runner Collection, chúng ta cần lấy các test data tương ứng từ file CSV. Để làm điều này, đầu tiên chúng ta cần upload CSV tương ứng lên POSTMAN, đồng thời trong Tab Body của API Login, chúng ta cần sử dụng cú pháp {{Email}} và {{Password}} gọi đến các biến Email và Password đã khai báo trong CSV. Trong quá trình chạy Collection, các giá trị tương ứng từ file CSV sẽ được trích xuất và sử dụng làm test data cho từng trường hợp kiểm thử.
3. Biến môi trường (Environment Variables)
- Định nghĩa: Là biến được sử dụng để tạo và quản lý các thông tin chung hoặc thông tin được được sử dụng ở nhiều API theo từng môi trường kiểm thử. Lưu ý rằng chỉ một môi trường kiểm thử có thể hoạt động tại một thời điểm. Khác với Biến cục bộ và Biến dữ liệu, tất cả các API thuộc tất cả collection đều có thể truy cập vào các biến được định nghĩa trong môi trường đã chọn.
- Ví dụ: Thông thường, các thông tin như URL cơ sở, Token sẽ khác nhau giữa các môi trường kiểm thử. Khi quản lý thông tin này theo từng môi trường, chúng ta có thể dễ dàng chuyển đổi giữa các môi trường kiểm thử bằng cách chọn môi trường tương ứng từ danh sách môi trường đã thiết lập trên POSTMAN. Lúc này, hệ thống sẽ tự động sử dụng các giá trị bạn đã khai báo cho môi trường đó, bạn không cần phải sửa đổi thủ công các giá trị.
4. Biến bộ sưu tập (Collection Variables)
- Định nghĩa: Là biến dùng để lưu trữ, quản lý các thông tin chung của các API trong cùng một Collection. Biến này chỉ hoạt động trong phạm vị Collection được định nghĩa, tức là, không thể truy cập vào biến này từ các Collection khác. Thông thường, chúng ta sử dụng Biến bộ sưu tập khi muốn lưu trữ các thông tin không có sự thay đổi giữa các môi trường test, chẳng hạn như JSON Schema.
- Ví dụ: Đối với API được thiết kế theo tiêu chuẩn RESTful, phần “response body” cho mỗi trường hợp thành công hoặc thất bại sẽ được xây dựng theo một cấu trúc nhất định, được gọi là JSON Schema (các cặp key-value). Số lượng “key” và tính chất của “key” trong JSON Schema sẽ không thay đổi dù API được thực thi trên bất kỳ môi trường kiểm tra nào, bao gồm môi trường Develop, môi trường Staging hay môi trường Production. Do đó, trong trường hợp này, chúng ta nên định nghĩa Biến JSON Schema trong Biến bộ sưu tập. Và sau đó, sử dụng chung JSON Schema này cho tất cả các môi trường kiểm thử, không cần phải tạo lại mỗi khi chuyển đổi giữa các môi trường test khác nhau. Điều này giúp đảm bảo tính nhất quán và đồng nhất trong kiểm thử API.
5. Biến toàn cục (Global Variables)
- Định nghĩa: Là biến có phạm vi hoạt động rộng nhất trong POSTMAN. Tất cả các API của toàn bộ Collection trong cùng một Workspace đều có thể truy cập vào biến này. Thông thường, Biến toàn cục được sử dụng khi muốn lưu trữ các thông tin chung cho toàn bộ dự án như Tài khoản đăng nhập sử dụng chung cho tất cả các môi trường, dữ liệu kiểm thử theo quyền hạn, các khóa API khi sử dụng dịch vụ của bên thứ 3, v.v.
- Ví dụ: Giả sử bạn tạo một test account với cùng một địa chỉ email là “apitesting@testmentor.com”, password = “123456” cho tất cả các môi trường kiểm thử, trong trường hợp này, chúng ta nên lưu thông tin này vào Biến toàn cục để có thể sử dụng cho tất cả các API trên toàn bộ môi trường test mà không cần phải khai báo lại.
Sample Script và cách giải quyết những vấn đề được đề cập ở đầu bài viết
Sau khi nắm vững về Biến và cách chúng hoạt động trong POSTMAN, chúng ta sẽ cùng nhau thực hành sử dụng Biến để giải quyết các vấn đề đã đặt ra ở đầu bài viết nhé!
Cài đặt môi trường kiểm thử local
Trước khi thực hành, hãy đảm bảo bạn đã cài đặt thành công môi trường kiểm thử local với ứng dụng Juice Shop. Tham khảo hướng dẫn cài đặt tại hướng dẫn cài đặt môi trường kiểm thử local.
Thực hành chạy script với POSTMAN
Đầu tiên, hãy tải Sample Script và file Test Data được đính kèm phía dưới. Sau đó, truy cập video “Sử Dụng BIẾN Trong POSTMAN: Cách Tối Ưu Hóa Kiểm Thử API” và video “5 Loại Biến Trong POSTMAN” được đăng tải trên kênh YouTube chính thức của Test Mentor và thực hành chạy Script theo các hướng dẫn được cung cấp trong video.
Các cú pháp sử dụng trong test script
- Cú pháp gọi Biến: {{variable name}}
- In thông tin ở cửa sổ Console: console.log()
- Lấy dữ liệu từ file CSV hoặc JSON khi chạy một collection: pm.iterationData.get()
- Thiết lập một Biến trong Environment: pm.environment.set(“variable_name”,”variable_value”)
- Lấy giá trị của Biến từ Environment: pm.environment.get(“variable_name”)
- Thiết lập một Biến trong Collections: pm.collectionVariables.set(“variable_name”,”variable_value”)
- Lấy giá trị của Biến từ Collections: pm.collectionVariables.get(“variable_name”)
- Chuyển đổi một chuỗi JSON thành một đối tượng JavaScript tương ứng: JSON.parse()
Kết luận
Vậy là chúng ta đã hoàn thành việc tìm hiểu về Biến và những đóng góp quan trọng của chúng trong Kiểm thử tự động API bằng POSTMAN. Hy vọng thông qua những ví dụ thực tế, Test Mentor đã giúp bạn hiểu rõ về Biến và cách áp dụng chúng để cải thiện hiệu suất công việc kiểm thử hằng ngày.
Nếu bạn muốn khám phá thêm về Kiểm thử API với POSTMAN, hãy xem thêm các bài viết hữu ích trong danh mục API Testing của chúng tôi.
Đặc biệt, nếu bạn nâng cao kiến thức về Kiểm thử API và mong muốn nhận được hướng dẫn trực tiếp, bạn có thể tham khảo Khóa học kiểm thử API tại Test Mentor.
Xem bài tiếp theo: Cú Pháp pm.environment.set(), get(): Trao Đổi Dữ Liệu Giữa Các API
Tài liệu tham khảo
Giới thiệu về Biến trong POSTMAN: Store and reuse values using variables
Hoàng Hà
One Comment