Scarnox · Blog

Giữ CI xanh khi ứng dụng của bạn có captcha

Form đăng ký của bạn có một PopularCaptcha. Bộ kiểm thử end-to-end của bạn cần đăng ký. Bây giờ CI bị đỏ, và cách sửa nhanh nhất là tắt captcha trong bản build kiểm thử, nhưng như vậy luồng bạn kiểm thử sẽ không còn là luồng mà người dùng thật nhận được.

Có vài cách để thoát khỏi tình huống này. Chúng khác nhau ở mức độ luồng thật mà chúng kiểm thử, nên hãy chọn cách phù hợp với câu hỏi mà bài kiểm thử của bạn trả lời. Dưới đây là các lựa chọn, sắp xếp từ rẻ nhất đến thực tế nhất.

Scarnox giải PopularCaptcha hiện nay. Các loại captcha khác sắp ra mắt, nên tùy chọn giải bên dưới chỉ dành cho PopularCaptcha.

1. Khóa thử nghiệm cho kiểm thử đơn vị và kiểm thử cục bộ

Nhiều nhà cung cấp captcha công bố khóa thử nghiệm luôn vượt qua. Hãy dùng chúng khi bạn kiểm soát môi trường và chỉ cần form hiển thị và gửi được. Khóa thử nghiệm không kiểm tra xác minh thật, và chúng không giúp ích khi bạn kiểm thử một môi trường đã triển khai dùng khóa thật.

2. Một đường bỏ qua cho staging của bạn

Một số đội thêm một header bí mật mà backend chấp nhận thay cho token captcha. Cách này nhanh và miễn phí, nhưng đó là một đường đi chỉ tồn tại cho kiểm thử, và chỉ một cấu hình sai là nó có thể xuất hiện trên production. Nếu bạn dùng nó, hãy đặt nó sau một kiểm tra môi trường, làm cho bí mật đủ dài và ngẫu nhiên, và kiểm thử để chắc chắn nó bị từ chối trên production.

3. Giả lập lệnh xác minh

Giả lập yêu cầu xác minh phía máy chủ trong các kiểm thử tích hợp. Cách này tốt để kiểm tra logic backend của bạn, chẳng hạn điều gì xảy ra khi xác minh thất bại. Nó không cho bạn biết liệu frontend có gửi đúng token hay không, nên hãy kết hợp nó với một trong các lựa chọn khác.

4. Giải thật trong staging và smoke test

Khi bạn cần chứng minh luồng thật hoạt động từ đầu đến cuối, với khóa thật, widget thật và xác minh thật, hãy lấy một token từ API giải ngay trong bài kiểm thử. Đây là lựa chọn duy nhất bắt được một tích hợp widget bị hỏng.

Một helper cho Playwright trông như thế này:

// Playwright test helper
export async function solveCaptcha(page) {
  const sitekey = await page.getAttribute("[data-sitekey]", "data-sitekey");
  const r = await fetch("https://api.scarnox.com/api/tasks/create", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SCARNOX_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      captcha_type: "PopularCaptchaTaskProxyless",
      site_key: sitekey,
      site_url: page.url(),
    }),
  });
  const { errorId, solution, errorCode, errorDescription } = await r.json();
  if (errorId !== 0) throw new Error(`${errorCode}: ${errorDescription}`);

  await page.evaluate((t) => {
    document.querySelectorAll('[name="h-captcha-response"],[name="g-recaptcha-response"]')
      .forEach((el) => { el.value = t; });
  }, solution.token);
}

Gọi nó ngay trước khi submit form trong bài kiểm thử, không phải ở đầu bài kiểm thử. Token hết hạn trong khoảng hai phút, và một bước chậm trước đó trong bài kiểm thử có thể dùng hết khoảng thời gian đó.

Giữ số lần giải ở mức tối thiểu

Một bộ kiểm thử đăng ký trên mỗi lần chạy có thể thực hiện rất nhiều lần giải trong một tuần. Hãy giữ con số đó xuống:

Chỉ chạy giải thật trong staging và trong một smoke test. Dùng các lựa chọn khác cho mỗi commit.
Chỉ chạy giải thật một lần cho mỗi pipeline, không phải một lần cho mỗi file kiểm thử.
Giới hạn số lần giải cho mỗi lần chạy trong helper của bạn. Một bài kiểm thử thất bại vì đã chạm giới hạn là tín hiệu rõ ràng để xem lại bộ kiểm thử.
Các lần giải thất bại không bị tính phí, nên một bước không ổn định chỉ tốn thời gian chứ không tốn tiền, nhưng một bộ kiểm thử thử lại một cách mù quáng vẫn lãng phí số phút chạy của runner.

Với các quy tắc thử lại bên trong helper, hãy dùng lại chính sách trong xử lý lỗi và backoff.

Giữ khóa ngoài repo

Lưu khóa thành một bí mật của CI, đặt tên như SCARNOX_KEY, và đừng bao giờ đặt nó trong mã kiểm thử hay fixture. Nếu nó bị rò rỉ, hãy tạo lại từ bảng điều khiển. Khóa cũ sẽ ngừng hoạt động ngay, nên khóa bị rò rỉ không thể dùng để chạy giải trong thời gian dài.

Dùng một khóa riêng cho CI. Nếu một pipeline hoạt động sai, bạn có thể đổi khóa của pipeline đó mà không ảnh hưởng đến thứ khác.

Thử trên staging của riêng bạn

Tạo tài khoản và bắt đầu với tín dụng dùng thử miễn phí, không cần thẻ. Hãy gắn helper vào một smoke test trước, xác nhận nó đăng ký thành công, rồi mới thêm nó vào phần còn lại của bộ kiểm thử. Về chi phí giải ở quy mô lớn, xem bảng giá hiện tại.

Kiểm tra gì sau khi submit

Một captcha được giải chỉ chứng minh bước widget đã thành công. Sau khi submit, hãy kiểm tra những điều quan trọng với người dùng: trang tiếp theo được tải, thông báo thành công xuất hiện, và tài khoản hoặc đơn hàng tồn tại trong cơ sở dữ liệu của bạn. Một bài kiểm thử chỉ dừng ở mức "form không có lỗi" có thể vẫn pass trong khi đăng ký thất bại âm thầm ở backend.

Giữ các khẳng định gần với kết quả nghiệp vụ. Kiểm tra URL, thông báo hiển thị và một bản ghi mà bài kiểm thử đã tạo. Dọn dẹp bản ghi đó khi kết thúc lần chạy để lần chạy tiếp theo bắt đầu từ một trạng thái đã biết.

Chạy smoke test theo lịch

Chạy smoke test giải thật theo lịch, ví dụ mỗi ngày một lần trên staging, thay vì mỗi pull request. Các lần chạy theo lịch bắt được những thay đổi mà website đã thực hiện qua đêm, chẳng hạn một phiên bản widget mới hoặc một sitekey đã di chuyển, mà không tốn lần giải nào cho mỗi commit. Thông báo cho đội khi lần chạy theo lịch thất bại, và giữ bộ kiểm thử theo từng commit trên các lựa chọn nhanh hơn.