Mã OTP trong kiểm thử luôn là bước khiến ca kiểm thử đầu-cuối khó ổn định nhất, vì nó nối một chương trình đang chạy với một hộp thư nằm ở ngoài tầm kiểm soát. Bài này nói cách lấy mã từ hộp thư kiểm thử, vì sao vẫn hay gặp lỗi chờ quá lâu, những cái bẫy quanh việc gửi lại, và lúc nào thì nên giữ một bước làm bằng tay.
Vì sao xử lý mã xác minh lại khó trong kiểm thử tự động?
Khó vì thời điểm. Mọi bước khác trong một ca kiểm thử đầu-cuối diễn ra trong cùng một tiến trình, nên chương trình biết chính xác khi nào một hành động đã xong. Việc gửi thư thì khác: sản phẩm báo đã gửi, nhưng lá thư vẫn còn đang trên đường. Không có tín hiệu nào trong mã của bạn cho biết lúc nào nó tới nơi.
Khó vì nội dung. Mã xác minh nằm trong phần nội dung thư, thường lẫn với chữ, với đường dẫn, với phần chân trang. Muốn lấy ra bạn phải đọc và tách, và mọi cách tách đều có thể sai khi mẫu thư thay đổi. Một lần đổi câu chữ trong mẫu thư cũng đủ làm hỏng việc tách mã.
Khó vì trạng thái. Hộp thư kiểm thử thường đã có thư từ những lần chạy trước, nên ca kiểm thử phải chọn đúng lá thư của mình giữa nhiều lá thư trông giống nhau. Chọn sai lá nghĩa là điền sai mã, và thông báo lỗi bạn nhận được sẽ nói về mã sai chứ không nói về việc bạn đọc nhầm thư.
Lấy mã từ hộp thư kiểm thử như thế nào?
Cách làm gọn nhất là để hộp thư kiểm thử nằm trong cùng môi trường chạy kiểm thử, như đã bàn ở bài bắt email trong kiểm thử tự động. Khi đó ca kiểm thử đọc thư qua một hàm, không phải qua mạng công khai, và việc đọc gần như tức thì.
Quy trình gồm bốn bước, và mỗi bước đều có một quyết định cần chốt. Bước một: xác định địa chỉ của ca kiểm thử, tốt nhất là một địa chỉ chỉ dùng cho ca đó. Bước hai: đọc danh sách thư đã nhận và lọc theo đúng địa chỉ đó. Bước ba: chọn lá thư mới nhất, hoặc lá thư khớp với tiêu đề mà sản phẩm của bạn đang dùng. Bước bốn: tách mã ra khỏi nội dung và điền vào biểu mẫu.
Điểm cần nhấn là bước hai và bước ba phải cùng tồn tại. Nếu chỉ lọc theo địa chỉ mà không quan tâm thứ tự, bạn có thể lấy phải lá thư cũ. Nếu chỉ lấy lá thư mới nhất mà không lọc theo địa chỉ, bạn có thể lấy phải thư của ca kiểm thử khác đang chạy song song.
Với việc tách mã, hãy ưu tiên cách bám vào cấu trúc thay vì bám vào câu chữ. Nhiều mẫu thư đặt mã trong một khối riêng hoặc trong một phần tử có nhãn ổn định. Bám vào phần ổn định đó sẽ bền hơn nhiều so với việc tìm một câu tiếng Việt cụ thể, vì câu chữ có thể đổi bất cứ lúc nào.
Vì sao vẫn hay gặp lỗi hết thời gian chờ?
Lỗi hết thời gian chờ có bốn nguồn thường gặp. Nguồn thứ nhất là thời gian chờ đặt quá ngắn so với độ trễ thật của một vòng gửi nhận. Cách chữa không phải là tăng liên tục, mà là đọc lại theo chu kỳ cho tới khi thư xuất hiện, kèm một giới hạn trên đủ rộng để chịu được những lần chậm bất thường.
Nguồn thứ hai là lọc sai. Địa chỉ trong cấu hình không khớp với địa chỉ sản phẩm thật sự gửi tới, ví dụ vì tiền tố bị chuẩn hóa hoặc bị cắt bớt. Khi đó thư có tới nhưng ca kiểm thử không bao giờ nhìn thấy nó.
Nguồn thứ ba là thư cũ gây nhiễu theo hướng ngược lại. Ca kiểm thử tìm thấy một lá thư từ lần chạy trước, điền mã cũ, và thất bại với thông báo mã không hợp lệ. Hãy dọn hộp thư trước mỗi ca, hoặc dùng một địa chỉ chắc chắn chưa từng tồn tại.
Nguồn thứ tư là gửi lại. Khi người dùng hoặc ca kiểm thử yêu cầu gửi lại, sản phẩm có thể vô hiệu hóa mã cũ. Nếu ca kiểm thử vẫn giữ mã cũ trong tay, nó sẽ thất bại dù mọi thứ khác đều đúng. Hãy đảm bảo ca kiểm thử lấy thư sau thời điểm yêu cầu gửi lại, chứ không lấy thư trước đó.
Khi nào cần giữ bước làm bằng tay?
Có ba trường hợp nên giữ người thật trong vòng lặp. Trường hợp thứ nhất là khi bạn đang kiểm tra chính trải nghiệm nhận thư: thời gian thư tới, cách thư hiển thị trên ứng dụng thư phổ biến, việc thư có vào đúng hộp thư đến hay không. Những thứ này phụ thuộc vào bên nhận, nên máy không đánh giá thay được.
Trường hợp thứ hai là khi ca kiểm thử cần một tài khoản thật để đi tới bước tiếp theo, ví dụ một buổi kiểm tra tổng thể trước khi phát hành. Lúc đó bạn đang kiểm tra sản phẩm chứ không kiểm tra bộ kiểm thử, nên việc có người nhập mã là hợp lý.
Trường hợp thứ ba là khi bạn đang điều tra một lỗi chỉ xuất hiện thỉnh thoảng. Việc có người ngồi xem hộp thư trong lúc tái hiện lỗi thường cho bạn thông tin nhanh hơn là thêm log vào bộ kiểm thử.
Điều nên tránh là biến việc làm tay thành mặc định. Một bộ kiểm thử cần người nhập mã ở mỗi lần chạy sẽ không được chạy thường xuyên, và một bộ kiểm thử không được chạy thường xuyên thì gần như không có tác dụng.
Dùng hộp thư tạm thời trên trang này để thử
Với những buổi kiểm tra cần một hộp thư nhanh mà không muốn dựng gì, công cụ email tạm thời của trang này cấp một địa chỉ trong vài giây và tự tách mã xác minh để bạn sao chép thẳng vào biểu mẫu. Bạn có thể tạo nhiều hộp thư để tách riêng từng trường hợp, và đặt tiền tố theo quy ước của nhóm để nhìn là biết hộp thư nào thuộc ca nào.
Các hộp thư ở đây chỉ dùng cho kiểm thử, không phải danh tính thật và không dùng để mạo danh ai; cũng đừng dùng chúng cho tài khoản bạn cần giữ lâu dài. Nếu bạn muốn phủ đầy đủ các trường hợp quanh bước xác minh, bài kiểm thử luồng xác minh email có danh sách cần chạy.
Phần dành cho nhà phát triển
Độ bền của bước đọc mã quyết định độ bền của cả ca kiểm thử. Vài điểm nên chốt:
- Mỗi ca kiểm thử một địa chỉ riêng. Đây là cách duy nhất để chạy song song mà không phải tranh nhau lá thư mới nhất.
- Chọn thư theo hai tiêu chí cùng lúc: đúng người nhận và mới hơn mốc thời gian bạn bắt đầu chờ. Chỉ dùng một trong hai sẽ dẫn tới những lần hỏng khó hiểu.
- Tách mã bằng cấu trúc ổn định, không bằng câu chữ. Nếu mẫu thư có thể đổi, hãy để việc tách mã chịu được thay đổi đó, hoặc ít nhất hãy làm cho nó thất bại với thông báo rõ ràng.
- Đặt giới hạn cho số lần đọc lại và cho tổng thời gian chờ. Khi vượt giới hạn, ca kiểm thử nên thất bại kèm nội dung thư gần nhất, thay vì treo cho tới khi hệ thống chạy tự động hết giờ.
- Đừng tắt giới hạn gửi lại để cho kiểm thử dễ hơn. Nếu bạn tắt nó, bạn đang kiểm thử một sản phẩm khác với sản phẩm sẽ chạy thật. Hãy để ca kiểm thử sống chung với giới hạn đó, và coi việc vượt giới hạn là một trường hợp cần phủ.
- Kiểm tra cả trường hợp mã đã hết hiệu lực và trường hợp gửi lại. Đây là hai đường mà người dùng thật đi qua thường xuyên nhất khi họ gặp trục trặc.
- Xóa hộp thư hoặc xóa thư sau mỗi ca. Trạng thái còn sót là nguồn gây hỏng phổ biến nhất ở loại kiểm thử này.
- Không ghi mã xác minh vào nhật ký chạy tự động. Nhật ký thường được lưu lâu và đọc bởi nhiều người, nên hãy chỉ ghi rằng đã đọc được mã hay chưa.
Cuối cùng, hãy coi mẫu thư là một phần của hợp đồng kiểm thử. Khi ai đó sửa mẫu thư, ca kiểm thử nên là thứ bị đỏ trước tiên, và điều đó chỉ xảy ra nếu bạn đã khẳng định trên nội dung chứ không chỉ trên việc thư tồn tại.
Bước tiếp theo
Hãy đo trước khi chọn giới hạn: chạy một vòng gửi và nhận thủ công vài lần, ghi lại thời gian thư tới, rồi đặt giới hạn dựa trên con số bạn quan sát được. Nếu bạn chưa có hộp thư nào để đo, mở công cụ email tạm thời và tự gửi cho mình một lá thư để lấy một điểm tham chiếu thực tế.