Thử nghiệm là một bước quan trọng để xây dựng thành công một quy trình tích hợp Google Ads API, cho dù bạn mới bắt đầu, đang duy trì một ứng dụng hay đang thêm các tính năng mới vào một quy trình tích hợp hiện có. Hướng dẫn này trình bày một số phương pháp hay nhất để thử nghiệm quy trình tích hợp Google Ads API.
Tài khoản thử nghiệm và tài khoản chính thức
Tài khoản thử nghiệm được cung cấp cho mục đích phát triển. Với tài khoản thử nghiệm, bạn có thể xác thực rằng mã xử lý ứng dụng và cấu hình của bạn đang hoạt động như dự kiến.
Tuy nhiên, không phải tính năng nào cũng có thể được kiểm thử trong tài khoản thử nghiệm.
Khi các hạn chế của tài khoản thử nghiệm khiến bạn không thể thử nghiệm một số tính năng trong quá trình tích hợp, bạn có thể sử dụng tài khoản chính thức để phát triển. Dự án Google Cloud của bạn phải có ít nhất cấp truy cập Explorer (Explorer, Cơ bản hoặc Tiêu chuẩn) để gọi một tài khoản chính thức. Xin lưu ý rằng quyền truy cập của Người khám phá vẫn hạn chế một số dịch vụ nhất định, bao gồm cả dịch vụ thanh toán (BillingSetupService và AccountBudgetProposalService), lập kế hoạch, tạo tài khoản và lời mời người dùng (xem phần Các quy định hạn chế về tính năng của Người khám phá). Những dịch vụ này yêu cầu quyền truy cập Cơ bản hoặc Tiêu chuẩn. Khi bạn cố gắng gọi một tài khoản chính thức từ một dự án có cấp truy cập Thử nghiệm, hệ thống sẽ trả về lỗi AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION kể từ v25 hoặc AuthorizationError.ACTION_NOT_PERMITTED trong v24 trở về trước.
Tài khoản chính thức dùng cho việc phát triển khác với tài khoản thử nghiệm theo những cách sau:
- Phân phát quảng cáo mà người dùng có thể nhìn thấy
- Yêu cầu URL hợp lệ
- Phải tuân thủ chính sách quảng cáo
Vì tài khoản chính thức phân phát quảng cáo, nên các tài khoản này sẽ tạo ra các chỉ số cho phép bạn kiểm tra báo cáo hiệu suất, cũng như mở khoá tất cả các tính năng khác của API Google Ads. Tuy nhiên, bạn cần hết sức thận trọng khi sử dụng các API này cho mục đích phát triển. Bạn nên thực hiện các biện pháp sau:
- Chỉ cấp quyền truy cập cho những người dùng cần quyền này cho mục đích phát triển.
- Đặt ngân sách tài khoản hằng ngày cố định và thấp.
- Chỉ sử dụng tài khoản chính thức cho mục đích phát triển khi không thể sử dụng tài khoản thử nghiệm.
Do đó, để kiểm thử đầy đủ quá trình tích hợp, bạn có thể cần cả thông tin đăng nhập thử nghiệm và thông tin đăng nhập chính thức.
Thông tin đăng nhập cho mục đích thử nghiệm
Để giảm thiểu rủi ro vô tình sửa đổi tài khoản phát hành công khai khi cố gắng sửa đổi tài khoản nhà phát triển, bạn nên duy trì một bộ thông tin đăng nhập cho mục đích thử nghiệm tách biệt với thông tin xác thực ứng dụng phát hành công khai.
Để tạo một bộ thông tin xác thực thử nghiệm, hãy làm theo các bước sau:
- Tạo một tài khoản email (ví dụ:
api.test@example.com) hoặc một tài khoản dịch vụ chỉ dùng cho mục đích thử nghiệm. - Thêm người dùng hoặc tài khoản dịch vụ này làm người dùng hợp lệ trong tài khoản Google Ads mà bạn đang chạy thử nghiệm. Hãy nhớ cấp cấp truy cập phù hợp cho người dùng hoặc tài khoản dịch vụ này. Không cấp cho người dùng hoặc tài khoản dịch vụ này quyền truy cập vào bất kỳ tài khoản sản xuất nào.
- Nếu bạn đang sử dụng quy trình xác thực người dùng OAuth 2.0 thay vì quy trình tài khoản dịch vụ, hãy tạo mã làm mới cho tài khoản người dùng thử nghiệm của bạn.
- Sử dụng thông tin xác thực mới này khi thử nghiệm ứng dụng. Bạn có thể sử dụng lại mã ứng dụng khách và khoá bí mật của ứng dụng khách cho mục đích thử nghiệm, vì chúng không ảnh hưởng đến việc xác định tài khoản Google Ads nào có thể truy cập được. Lưu trữ tất cả thông tin đăng nhập và mã làm mới một cách an toàn, đồng thời không bao giờ đưa chúng vào hệ thống quản lý mã nguồn.
Yêu cầu xác thực
Nếu chỉ cần kiểm tra xem một yêu cầu có hợp lệ hay không (ví dụ: để xác minh rằng yêu cầu đó có cấu trúc chính xác và không vi phạm chính sách), bạn có thể sử dụng trường validate_only. Trường này có sẵn cho các yêu cầu GoogleAdsService.Search (lưu ý rằng GoogleAdsService.SearchStream không hỗ trợ validate_only) và hầu hết các yêu cầu thay đổi tài nguyên. Tham khảo tài liệu tham khảo để xác minh xem trường này có sẵn cho một phương thức nhất định hay không.
API REST
Để thử nghiệm đặc biệt, chẳng hạn như để xác thực rằng một yêu cầu mang lại kết quả như mong đợi, việc sử dụng API REST thường là lựa chọn dễ dàng nhất. Tham khảo ví dụ về REST để tìm hiểu cách sử dụng curl khi đưa ra yêu cầu cho API REST. Ngoài ra, hãy thử kiểm tra trong Trình khám phá REST.