Test chức năng nhập tệp: một tệp mẫu đúng và những cách làm hỏng nó

Sáng thứ Hai, cô Tấm nhận bảng giá mới từ nhà cung cấp: một tệp Excel 1.200 dòng. Cô mở phần mềm quản lý của Tạp Hóa Cô Tấm, bấm Nhập từ tệp, chọn tệp, và màn hình báo màu xanh: "Nhập thành công". Chiều hôm đó, thủ kho đếm lại và thấy danh mục chỉ tăng thêm 962 sản phẩm. 238 dòng biến mất mà không có dòng nào được báo lỗi.

Tester của đợt phát hành trước đã thử chức năng này đúng một lần, bằng tệp 10 dòng do chính anh gõ tay, và ghi "Đạt".

Trước khi đọc tiếp, hãy viết ra giấy: tệp 10 dòng gõ tay đó đã thiếu những kiểu dữ liệu nào so với tệp thật của nhà cung cấp? Hãy nêu ít nhất ba kiểu, rồi đối chiếu với bảng test case ở giữa bài.

Sau bài này, bạn có thể

• Chia chức năng nhập tệp thành bốn cổng kiểm tra (tệp, tiêu đề, từng dòng, kết quả) và nghĩ ra test case cho từng cổng.
• Dùng bảng 25 test case có sẵn, kèm tệp mẫu đúng và tệp trộn dòng lỗi, để test chức năng nhập tệp của một hệ thống bán hàng nhỏ.
• Đối chiếu ba con số (dòng trong tệp, dòng hệ thống báo đã nhập, dòng thật sự có trong cơ sở dữ liệu) để biết hệ thống có đang báo sai hay không.

Cần biết trước: phân vùng tương đương và giá trị biên (chương 3), cách test ô nhập liệu (chương 5). Bài này dùng lại hai kỹ thuật đó để chọn dữ liệu cho từng dòng trong tệp.

Quy tắc nghiệp vụ của chức năng nhập sản phẩm

Một test case chỉ có kết quả mong đợi xác định khi quy tắc rõ ràng. Cả chương này dùng một hệ thống ví dụ: phần mềm quản lý bán hàng của Tạp Hóa Cô Tấm. Chức năng của bài này là nhập danh sách sản phẩm từ tệp, với các quy tắc sau.

Trước khi nhập, bảng products đang có 120 sản phẩm. Con số này dùng xuyên suốt bài để bạn tính được kết quả mong đợi.

Tệp mẫu: một tệp đúng và một tệp trộn

Tệp đầu tiên là tệp đúng, ba dòng dữ liệu. Tên tệp products_ok.csv:

sku,name,price,stock,unit
GAO-ST25-5K,Gạo ST25 túi 5kg,185000,40,tui
NUOC-MAM-500,Nước mắm 500ml,42000,25,chai
DUONG-1K,Đường cát trắng 1kg,24000,60,kg

Kết quả mong đợi: "Đã nhập 3/3 dòng, 0 dòng lỗi", bảng products tăng từ 120 lên 123 dòng, tên có dấu hiển thị đúng.

Tệp thứ hai là tệp trộn: 10 dòng dữ liệu, trong đó có dòng đúng và dòng sai theo từng kiểu. Tên tệp products_mixed.csv:

sku,name,price,stock,unit
GAO-ST25-5K,Gạo ST25 túi 5kg,185000,40,tui
NUOC-MAM-500,Nước mắm 500ml,42000,25,chai
DUONG-1K,Đường cát trắng 1kg,24000,60,kg
TRA-TUI-LOC,Trà túi lọc 25 gói,abc,30,hop
MI-TOM-30,Mì tôm thùng 30 gói,98000,-5,thung
GAO-ST25-5K,Gạo ST25 bao 5kg,190000,10,tui
BIA-LON-24,,330000,8,thung
BANH-QUY-HOP,"Bánh quy, hộp thiếc",65000,18,hop
XA-PHONG-1K,Xà phòng giặt 1kg,52000,22,tui
MUOI-IOT-500,Muối i-ốt 500g,8000,100,goi

Hãy tự duyệt từng dòng theo bảng quy tắc ở trên rồi mới xem đáp án. Bạn dự đoán bao nhiêu dòng được nhập, bao nhiêu dòng lỗi, và lỗi nằm ở những dòng số mấy?

Đáp án, đã đối chiếu bằng một đoạn mã đọc tệp và kiểm tra theo đúng quy tắc: 6 dòng được nhập, 4 dòng lỗi. Các dòng 2, 3, 4, 9, 10, 11 hợp lệ nên là sáu dòng. Báo cáo lỗi mong đợi:

Chú ý dòng 9 có ô "Bánh quy, hộp thiếc" chứa dấu phẩy nằm trong dấu nháy: đây là dòng đúng, và một hệ thống đọc tệp ngây thơ bằng cách tách chuỗi theo dấu phẩy sẽ hiểu nhầm thành 6 cột rồi báo lỗi oan.

Mô hình tư duy 1: tệp đi qua bốn cổng

Nhìn chức năng nhập tệp như một con đường có bốn cổng. Mỗi cổng có một nhóm rủi ro riêng, và bạn nghĩ test case bằng cách đứng ở từng cổng hỏi "thứ gì có thể lọt qua hoặc bị chặn nhầm ở đây?".

Hai cổng đầu quyết định cả tệp sống hay chết. Hai cổng sau quyết định từng dòng. Nghĩ theo thứ tự này giúp bạn không bỏ sót: tester của cô Tấm chỉ đi qua cổng 1 và 2 bằng tệp đúng, rồi dừng.

Cách đọc hình: đi từ trên xuống. Hai hình thoi đầu là hai cổng của cả tệp: nói "không" ở đây thì đi thẳng sang khối đỏ bên trái và không có dòng nào được nhập. Hình thoi thứ ba lặp lại cho từng dòng: dòng đúng được chèn vào bảng, dòng sai rơi vào báo cáo lỗi, và cả hai cùng đổ về một bản tổng kết. Vì thế tổng "đã nhập" cộng "lỗi" luôn phải bằng tổng số dòng dữ liệu.

Mô hình tư duy 2: mỗi tệp thử có một mục đích

Ở chương 3 bạn đã học đổi một giá trị mỗi lần để biết giá trị nào gây lỗi. Với tệp, nguyên tắc đó thành hai loại tệp thử:

• Tệp lỗi đơn: hỏng đúng một chỗ (thiếu cột price, hoặc 2.097.153 byte). Nếu hệ thống phản ứng sai, bạn biết ngay nguyên nhân.
• Tệp trộn: có nhiều dòng với nhiều kiểu lỗi, như products_mixed.csv. Mục đích không phải tìm nguyên nhân, mà kiểm tra hành vi nhập một phần: dòng đúng vẫn vào, dòng sai bị báo đúng dòng.

Tệp trộn chỉ có giá trị khi bạn đã chạy các tệp lỗi đơn trước. Nếu tệp trộn cho kết quả sai mà bạn chưa có tệp lỗi đơn, bạn không biết lỗi đến từ kiểu dòng nào.

Mô hình tư duy 3: đối chiếu ba con số

Thông báo trên màn hình chỉ là lời hệ thống tự nói về mình. Câu chuyện của cô Tấm cho thấy lời đó có thể sai: màn hình báo "thành công" nhưng thiếu 238 dòng. Vì vậy sau mỗi lần nhập, hãy lấy ba con số và so với nhau:

1. Số dòng dữ liệu trong tệp (không tính dòng tiêu đề và dòng trống).
2. Số dòng hệ thống báo đã nhập và số dòng báo lỗi trên màn hình.
3. Số dòng thật sự tăng trong cơ sở dữ liệu.

Ba con số phải thỏa hai điều kiện: đã nhập cộng lỗi bằng tổng dòng dữ liệu, và số dòng tăng của bảng bằng đúng số đã nhập. Cách lấy số thứ ba, dùng một câu lệnh SQL mà chương 8 sẽ dạy kỹ hơn:

SELECT COUNT(*) FROM products;

Chạy câu lệnh này trước khi nhập và sau khi nhập. Với products_mixed.csv, kết quả mong đợi là 120 rồi 126 (số liệu của hệ thống ví dụ). Nếu màn hình báo "Đã nhập 6/10" mà bảng chỉ tăng 5, bạn đã tìm thấy một lỗi nghiêm trọng hơn mọi lỗi giao diện.

Bạn vừa xem tệp trộn đi qua các cổng. Hãy bấm nút biến thể để thấy điều gì xảy ra khi tệp thiếu một cột bắt buộc: toàn bộ cổng dòng không bao giờ được chạy, và con số 120 trong bảng không đổi.

Bảng test case nhập tệp

Điều kiện chung (ĐK chung): đăng nhập bằng tài khoản chủ tiệm, bảng products đang có 120 sản phẩm, đang ở màn hình Sản phẩm có nút Nhập từ tệp. Các bước chung: 1) bấm Nhập từ tệp; 2) chọn tệp; 3) bấm Nhập. Mỗi dòng dưới đây chỉ ghi phần khác biệt.

Nhóm 1: tệp và định dạng

Nhóm 2: dòng tiêu đề

Nhóm 3: từng dòng dữ liệu

Nhóm 4: mã hóa và ký tự đặc biệt

Nhóm 5: kết quả, nhập lại và số lượng lớn

Bẫy và lỗi hay gặp khi test nhập tệp

Bẫy 1: BOM làm hỏng tên cột đầu tiên. BOM (byte order mark) là ba byte EF BB BF mà một số chương trình, như Excel khi lưu "CSV UTF-8", chèn vào đầu tệp. Mắt bạn không nhìn thấy chúng. Bạn có thể kiểm tra bằng lệnh xxd -l 8 trên Linux hoặc macOS. Kết quả thật khi chạy lệnh này trên tệp có BOM của bài:

00000000: efbb bf73 6b75 2c6e                      ...sku,n

Một hệ thống đọc tệp mà không bóc ba byte này sẽ hiểu tên cột đầu là sku thay vì sku (đây là kết quả thật khi đọc tệp bằng bảng mã utf-8 thường của Python, trong khi utf-8-sig cho kết quả đúng). Hệ quả: hệ thống báo "Thiếu cột bắt buộc: sku" dù bạn mở tệp bằng mắt thấy đủ. Đây là lý do IMP-20 tồn tại.

Bẫy 2: tệp bảng mã cũ trông bình thường trong Excel. Tệp products_cp1258.csv mở được trong Excel ở máy Windows tiếng Việt cũ, nhưng khi đọc bằng UTF-8 thì lỗi UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf2. Nếu hệ thống bỏ qua lỗi và thay bằng ký tự thay thế, tên sản phẩm lưu vào cơ sở dữ liệu sẽ hỏng mà không ai báo lỗi.

Bẫy 3: tạo tệp thử bằng Excel rồi lưu lại. Excel tự đổi 00123 thành 123, đổi 1/2 thành ngày, và bỏ số 0 đầu của số điện thoại. Hãy tạo tệp mẫu bằng trình soạn thảo văn bản thuần, và kiểm tra tệp bằng xxd hoặc trình soạn thảo trước khi dùng.

Bẫy 4: chỉ nhìn thông báo. Thông báo màu xanh không phải bằng chứng. Hãy luôn đối chiếu ba con số. Hãy mở thêm một vài sản phẩm vừa nhập, xem giá, tồn kho, đơn vị có lẫn cột không, vì lỗi lẫn cột (IMP-12) không làm tổng số dòng sai.

Bẫy 5: số dòng báo lỗi lệch một. Dòng 1 là tiêu đề nên dòng đầu tiên chứa dữ liệu là dòng 2. Nếu báo cáo ghi "dòng 4" cho lỗi nằm ở dòng 5 của Excel, người dùng sẽ sửa nhầm dòng. Hãy luôn mở tệp bằng Excel và đếm số dòng thật.

Bẫy 6: tệp thử quá đẹp. Tệp 10 dòng gõ tay, tên không dấu, không dấu phẩy, giá đẹp tròn, là tệp mà mọi hệ thống đều qua. Tệp thật có tên dài, dấu phẩy, nháy kép, ô trống, số 0 đầu. Hãy thử với dữ liệu thô gần giống thật.

Hiểu lầm thường gặp

• "Tệp thử một lần, đủ dòng, đạt là xong." Một tệp đúng chỉ chứng minh đường đi đúng hoạt động. Chức năng nhập tệp hỏng nhiều nhất ở những dòng không đẹp, nên cần cả tệp lỗi đơn lẫn tệp trộn.
• "Thông báo thành công nghĩa là dữ liệu đã vào." Thông báo là một dòng chữ do chương trình sinh ra. Chỉ đếm dòng trong cơ sở dữ liệu mới chứng minh được dữ liệu đã vào, như vụ 238 dòng mất của cô Tấm.
• "Đuôi tệp quyết định định dạng tệp." Đuôi chỉ là tên. Người dùng hoặc kẻ tấn công có thể đổi tên một chương trình thành .csv. Hệ thống đúng phải kiểm tra nội dung thật, và tester phải có ca thử đuôi giả (IMP-04, IMP-05).
• "Tệp lỗi một dòng thì cả tệp nên bị từ chối." Điều đó tùy quy tắc nghiệp vụ. Ở hệ thống ví dụ, nhập một phần là quy tắc, nên từ chối cả tệp vì một dòng sai mới là lỗi. Luôn đọc đặc tả trước khi viết kết quả mong đợi, và hỏi người đặt yêu cầu khi đặc tả không nói.

Điều kiện và giới hạn

Bảng 25 test case ở trên bám theo quy tắc của hệ thống ví dụ: định dạng, giới hạn 2 MB và 1.000 dòng, nhập một phần, không ghi đè. Hệ thống thật của bạn sẽ có quy tắc khác (ví dụ ghi đè khi trùng, hoặc từ chối cả tệp khi có một dòng lỗi). Khi đó bạn giữ nguyên nhóm rủi ro và đổi kết quả mong đợi. Bảng cũng chưa kiểm tra hiệu năng sâu, phân quyền người nhập, hay ghi nhật ký (log); các điều này thuộc chương sau và các bài kế tiếp.

Tự kiểm tra (có đáp án)

Câu 1. Màn hình báo "Đã nhập 8/10 dòng, 2 dòng lỗi", nhưng SELECT COUNT(*) FROM products chỉ tăng 7. Bạn kết luận gì và làm gì tiếp? Đáp án: ba con số không khớp (8 báo nhập, 7 thật sự tăng), nên đây là lỗi nghiêm trọng về toàn vẹn dữ liệu, dù giao diện báo thành công. Bước tiếp theo là tìm dòng nào thiếu bằng cách đối chiếu từng sku của tệp với bảng, rồi báo bug kèm tệp, thông báo và hai kết quả đếm.

Câu 2. Vì sao cần cả tệp 1.000 dòng và tệp 1.001 dòng, chứ không chỉ một tệp 5.000 dòng? Đáp án: đây là giá trị biên của quy tắc 1.000 dòng. Tệp 1.000 dòng chứng minh hệ thống nhận đủ tới giới hạn, tệp 1.001 dòng chứng minh hệ thống chặn đúng ngay sau giới hạn. Tệp 5.000 dòng chỉ chứng minh hệ thống chặn khi vượt quá nhiều, không phát hiện được lỗi lệch một (hệ thống chặn từ dòng 1.000).

Câu 3 (tình huống mới). Tạp Hóa Cô Tấm thêm chức năng nhập danh sách khách hàng từ tệp customers.csv với các cột full_name, phone, email. Quy tắc: phone gồm 10 chữ số bắt đầu bằng 0 và không trùng; email tùy chọn. Hãy nêu 5 test case quan trọng nhất cho chức năng này và nhóm rủi ro của mỗi ca. Đáp án: ví dụ năm ca: (1) tệp đúng 3 dòng, nhóm tệp và định dạng; (2) số điện thoại bị Excel mất số 0 đầu, 901234567, nhóm giá trị từng dòng và biên độ dài; (3) hai khách cùng phone trong cùng tệp, nhóm trùng; (4) họ tên có dấu Nguyễn Văn An trong UTF-8 có BOM, nhóm mã hóa; (5) nhập hai lần cùng tệp, nhóm kết quả và nhập lại. Ca nào nêu đủ nhóm rủi ro và dữ liệu cụ thể đều được chấp nhận.

Điều cần nhớ

• Nghĩ test case theo bốn cổng: tệp, tiêu đề, từng dòng, kết quả; hai cổng đầu quyết định cả tệp, hai cổng sau quyết định từng dòng.
• Dùng tệp lỗi đơn để tìm nguyên nhân và tệp trộn để kiểm tra nhập một phần.
• Đối chiếu ba con số (tệp, màn hình, cơ sở dữ liệu); đã nhập cộng lỗi phải bằng tổng dòng.
• Bài kế tiếp làm chiều ngược lại: xuất dữ liệu ra tệp, nơi lỗi hay nằm ở dữ liệu thiếu, dấu tiếng Việt và ô bắt đầu bằng dấu =.

Nguồn tham khảo

• RFC 4180, định dạng tệp CSV (dấu phẩy, dấu nháy, xuống dòng trong ô): https://www.rfc-editor.org/rfc/rfc4180
• OWASP, File Upload Cheat Sheet (kiểm tra nội dung tệp, không tin đuôi tệp, giới hạn dung lượng): https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
• ISTQB Glossary, thuật ngữ kiểm thử: https://glossary.istqb.org/