Công cụ kiểm thử máy quét mã vạch tốt nhất cho nhà phát triển

Điều gì khiến một công cụ kiểm thử thực sự hữu ích

Công cụ tốt không chỉ chứng minh đường đi thành công chạy được một lần. Nó giúp bạn đi nhanh khi có thứ gì đó thất bại. Với kiểm thử máy quét mã vạch, điều đó thường là bốn việc:

• thiết lập nhanh
• dữ liệu nhập lặp lại được
• nhìn thấy ứng dụng thực sự nhận được gì
• đủ quyền kiểm soát để tái tạo các trường hợp biên về thời điểm và hậu tố

Tôi thường đánh giá công cụ bằng một câu hỏi: nó có rút ngắn thời gian giữa “trông không đúng” và “tôi hiểu vì sao nó hỏng” không? Nếu câu trả lời là không, công cụ có lẽ đang thêm nghi thức thay vì giá trị.

1. Trình giả lập máy quét mã vạch thuộc bộ công cụ mặc định

Với phát triển hằng ngày, trình giả lập mã vạch là điểm bắt đầu thực tế nhất. Nó cho bạn mô phỏng hành vi máy quét mã vạch ngay từ máy trạm, rất hợp khi bạn xây luồng biểu mẫu, kiểm thử khôi phục tiêu điểm hoặc gỡ lỗi vì sao màn hình POS hành xử khác sau lần quét so với sau khi nhập tay.

Đó cũng là lý do một công cụ như Barcode Scanner Emulator hữu ích: nó rút ngắn vòng phản hồi. Bạn đổi giá trị mã vạch, chạy lại lần quét, thử hậu tố khác và so sánh kết quả ngay. Với phần lớn việc gỡ lỗi giao diện và quy trình, điều đó có giá trị hơn việc chờ được dùng máy quét vật lý.

2. Máy quét phần cứng thật vẫn quan trọng

Trình giả lập không thay thế mọi kiểm thử phần cứng. Bạn vẫn muốn ít nhất một máy quét thật trong vòng lặp trước khi phát hành, nhất là khi hỗ trợ nhiều hệ điều hành hoặc thiết bị đầu cuối bán lẻ bị khóa.

Phần cứng thật quan trọng để xác nhận:

• hành vi nút bấm của máy quét
• kết nối USB và các điểm lạ của trình điều khiển
• hạn chế của thiết bị đầu cuối
• khác biệt cấu hình phần cứng
• cảm giác của người vận hành thật

Cách làm thực tế rất đơn giản: dùng trình giả lập cho công việc hằng ngày và máy quét vật lý cho các lần kiểm tra độ tin cậy. Nếu đảo ngược, bạn lãng phí thời gian phần cứng cho những lỗi vốn có thể tìm thấy sớm hơn nhiều.

3. Dữ liệu kiểm thử ổn định bị đánh giá thấp

Quy trình mã vạch chỉ tốt bằng dữ liệu đứng sau chúng. Mã sản phẩm ánh xạ tới tồn kho, khuyến mại, logic gói hoặc quy tắc vị trí hữu ích hơn nhiều so với một số ngẫu nhiên gõ vào trường.

Giữ một bộ mã vạch kiểm thử đã ghi chép cho:

• một sản phẩm hợp lệ
• một mã vạch không xác định
• một mã vạch có số 0 ở đầu
• một mặt hàng bị hạn chế hoặc có kiểm tra độ tuổi
• một sản phẩm có giảm giá hoặc khuyến mại

Điều này đặc biệt quan trọng với kiểm thử POS. Nếu dữ liệu kiểm thử đổi mỗi ngày, cuối cùng bạn gỡ lỗi môi trường thay vì phần mềm.

4. Công cụ kiểm tra mạng và API cũng là một phần của kiểm thử mã vạch

Một số lượng đáng ngạc nhiên các thất bại liên quan đến lần quét xảy ra sau khi giá trị vào trường. Mã vạch đến đúng, nhưng yêu cầu tra cứu bị tạo sai, cắt sai, lưu đệm kém hoặc bị backend từ chối.

Vì thế nhật ký, công cụ kiểm tra mạng và công cụ API vẫn thuộc bộ kiểm thử máy quét mã vạch tốt nhất. Nếu một lần quét trong trường tìm POS không làm gì, tôi muốn biết mã vạch có được chuẩn hóa đúng không, ENTER có kích hoạt hai lần không và máy chủ có trả kết quả mong đợi không. Chỉ riêng công cụ máy quét không trả lời được những câu hỏi đó.

5. Hộp cát POS và môi trường thử đóng khoảng trống quy trình

Với kiểm thử POS và quy trình thanh toán, môi trường thử quan trọng vì việc quét không bao giờ chỉ là nhập văn bản. Nó chạm tới giá, thuế, quyền, tồn kho, gán khách hàng và logic hóa đơn.

Đây là nơi môi trường thử hoặc hộp cát trở nên thiết yếu. Một lần quét mô phỏng có thể chạy hoàn hảo trên trang demo thành phần rồi vẫn thất bại khi khuyến mại, quy tắc tồn kho và quyền thu ngân xuất hiện. Đó không phải lý do bỏ trình giả lập. Đó là lý do ghép nó với việc xác nhận quy trình tốt hơn.

Một bộ công cụ thực tế phù hợp với hầu hết nhóm

Nếu bạn cần thiết lập nhẹ nhưng đáng tin, đây là mặc định tốt:

1. trình giả lập mã vạch cho phát triển hằng ngày và các lần chạy lại của QA
2. một máy quét thật để xác nhận trước phát hành
3. mẫu mã vạch ổn định gắn với sản phẩm hoặc thực thể đã biết
4. nhật ký yêu cầu và ứng dụng để gỡ lỗi
5. môi trường thử hoặc hộp cát POS để kiểm tra toàn bộ quy trình

Nhóm nhanh nhất không nhất thiết dùng nhiều công cụ nhất. Họ dùng đúng một bộ nhỏ và bảo đảm mỗi công cụ phủ một loại thất bại khác nhau.

Một quy tắc nhỏ có chủ đích giúp tiết kiệm thời gian

Nếu phải cắt một sai lầm khỏi hầu hết nhóm, đó sẽ là: đừng dùng phần cứng thật cho những câu hỏi rõ ràng là về hành vi quy trình phần mềm. Nếu vấn đề là tiêu điểm, xử lý ENTER, thời điểm tìm kiếm hoặc thứ tự xác thực, hãy bắt đầu bằng giả lập và nhật ký. Đưa phần cứng trở lại khi bạn đã thu hẹp vấn đề.

Thứ tự đó giữ vòng gỡ lỗi tỉnh táo. Nó cũng ngăn chính máy quét trở thành cái cớ vì sao một lỗi vẫn mơ hồ sau nửa ngày điều tra.

Nơi điều này tạo khác biệt thật

Nhóm nhanh nhất không dựa vào một công cụ duy nhất.

Họ kết hợp vài công cụ đơn giản cho phép đi nhanh khi có thứ gì đó hỏng.

Nếu thiết lập của bạn giúp chạy lại cùng một lần quét, xem chuyện gì đã xảy ra và điều chỉnh nhanh, bạn đã đi trước.