DEBUG ROOM
JP KR VN EN
Trang đầuQA trò chơiĐồ họaÂm thanhVăn bảnKhu vựcKiểm thử tiêu cựcDanh sách kiểm traBáo cáo lỗiGiám sátDấu hiệu của thất bạiLIÊN KẾT
Quay lại đầu trang

Danh sách kiểm tra

🧩 Hình thức danh sách kiểm tra


Dạng test case

ID Độ ưu tiên Mục Điều kiện tiên quyết Thủ tục Kết quả mong đợi Phán định Ghi chú/Log Môi trường
1 H Nhận quest
Hành động khi chọn YES
・Hộp thoại nhận quest đang hiển thị
・Stamina ≥10
1) Chọn "YES" trong hộp thoại nhận quest
2) Chờ cho đến khi tải xong
・Chuyển sang màn hình battle
・Tiêu hao 10 stamina
・Đổi BGM sang nhạc battle
OK Ảnh chụp
quest_yes_ok.png
iPhone 13
(iOS 17)
2 M Sử dụng item
Hồi HP bằng "Potion"
・Trong battle
・Có "Potion" ×1
・HP hiện tại nhỏ hơn tối đa
1) Mở menu item
2) Sử dụng "Potion"
・HP hồi +50
・Số lượng item giảm 1
・Xuất log sử dụng
OK Log
/battle/item_green_003.txt
Pixel 6
(Android 13)
3 H Cửa hàng
Hành vi khi hủy trong hộp thoại xác nhận
・Màn hình cửa hàng
・Nút mua "100 Gem" đang khả dụng
1) Nhấn "100 Gem" để hiển thị xác nhận mua
2) Chọn "Hủy" trong hộp thoại
・Không bắt đầu xử lý thanh toán
・Vẫn ở trong cửa hàng
NG Bug report №101
Chuyển hướng sang store bên ngoài
vid/cancel_bug.mp4
iPhone 14
(iOS 17)



Dạng ma trận

ID Tên kỹ năng Mô tả Đối tượng Hiệu quả Thời gian hiệu lực Ghi chú/Log
1 Liệt Hỏa Trảm OK NG OK OK Bug report №204
Đối tượng là kẻ địch đơn (Yêu cầu: nhóm kẻ địch)
2 Hộ Vệ Bầu Trời Xanh OK OK OK OK
3 Bó Bóng OK OK OK NG Bug report №207
Thời gian hiệu lực 60 giây (Yêu cầu: 30 giây)
4 Lời Cầu Nguyện Tinh Linh OK OK OK OK
5 Hư Không Xung OK OK NG OK Bug report №208
Sát thương 200~250 (Yêu cầu: khoảng 100)



Dạng sơ đồ luồng

Xác nhận mua
OK
Cửa hàng
Chờ
Xác nhận bán
OK
OK
NG
Chọn sản phẩm
OK
Chọn vật phẩm sở hữu
OK
OK
OK
Danh sách sản phẩm
NG
Mua/Bán
OK
Danh sách vật phẩm sở hữu






🧩 Nguyên tắc khi tạo test case


Không giao việc phán đoán đúng/sai cho tester

NG Xác nhận hành vi khi chọn item là đúng
"Đúng" là tiêu chí mơ hồ, mỗi tester có thể đánh giá khác nhau, dẫn đến kết quả không nhất quán

Cần ghi rõ kết quả mong đợi cụ thể
OK Xác nhận khi chọn item thì hộp thoại xác nhận được mở

NG Xác nhận hành vi của nhân vật không bất thường
"Việc có bất thường hay không" phụ thuộc vào cảm nhận của tester, nên kết quả không nhất quán

Nếu chỉ rõ tài liệu tham chiếu có thể thống nhất đánh giá, nhưng
Nếu vị trí tham chiếu khó hiểu, việc xác nhận mất thời gian hoặc có thể nhầm lẫn
OK Xác nhận hành vi của nhân vật đúng theo đặc tả



Tạo test case có thể thực hiện được

NG Xác nhận dữ liệu lưu không có vấn đề
Test có thể chỉ ra "có vấn đề", nhưng không thể chứng minh là "không có vấn đề"

Thay vì "không có vấn đề", cần ghi rõ trạng thái nào thì OK (điều kiện phán định)
OK Xác nhận khi load có thể tiếp tục từ điểm lưu

NG Xác nhận không có cách mở cửa mà không dùng "Chìa khóa vàng"
"Không có cách" sẽ dẫn đến việc tìm kiếm toàn bộ, phi thực tế

Thay vì phủ định toàn diện, cần ghi rõ kết quả mong đợi dựa trên đặc tả
OK ・Xác nhận với "Chìa khóa bạc" thì không mở được
・Xác nhận với "Chìa khóa đồng" thì không mở được



Thống nhất dạng khẳng định / phủ định khi mô tả

NG ・Xác nhận cửa không mở bằng chìa khóa đỏ
・Xác nhận cửa mở bằng chìa khóa xanh
・Xác nhận cửa không mở bằng chìa khóa vàng
・Xác nhận cửa đóng khi gạt cần
Khi pha trộn mô tả khẳng định và phủ định, tiêu chí đánh giá trở nên khó theo dõi.

Việc thống nhất theo dạng khẳng định như “được hiển thị”, “được chuyển trạng thái” giúp tránh hiểu sai.
OK ・Chìa khóa đỏ hiển thị “không mở” cửa
・Xác nhận cửa mở bằng chìa khóa xanh
・Chìa khóa vàng hiển thị “không mở” cửa
・Xác nhận cửa đóng khi gạt cần



Sử dụng tên chính thức cho thuật ngữ

NG Xác nhận khi clear nhận được Thuốc hồi phục (lớn)
Không dùng "tên tạm" hay "tên gọi thông dụng" trong quá trình phát triển

Phải thống nhất dùng tên chính thức hiển thị trong game để tránh sai lệch và nhầm lẫn
OK Xác nhận khi clear nhận được Potion xanh lá



Luôn ghi rõ điều kiện tiên quyết

NG Khi hoàn thành mission, 「Nhân vật A」 gia nhập
Nếu không ghi điều kiện tiên quyết thì kết quả test sẽ không chính xác

Trong test case NG, khi 「Nhân vật B」 đã tham gia thì việc A gia nhập sẽ không bị phát hiện là lỗi
OK Điều kiện: 「Nhân vật B」 chưa gia nhập
Khi hoàn thành mission, 「Nhân vật A」 gia nhập



Không viết theo cách khiến độ sâu xác nhận khác nhau tùy người đọc

NG Xác nhận có hiển thị hình ảnh
Nếu test case chỉ ghi "có hiển thị hay không"
có thể nhầm rằng bất kỳ hình nào hiển thị cũng OK

Cần chỉ rõ tài liệu hình ảnh phải hiển thị
OK Xác nhận hình ảnh đúng theo đặc tả được hiển thị



Kết quả của case trước không được cản trở việc thực hiện case tiếp theo

NG 1.「YES」→ Bắt đầu quest
2.「NO」 → Không bắt đầu
Nếu chạy YES trước thì không thể thử NO trong cùng flow

Để kiểm chứng NO cần quay lại save/restart, gây tốn công thừa

Xét theo tiêu chí công sức, thứ tự test case này là không phù hợp
OK 1.「NO」 → Không bắt đầu
2.「YES」→ Bắt đầu quest



Không gộp các yếu tố có nhiều tổ hợp vào một test case

NG Xác nhận toàn bộ tổ hợp giữa vũ khí mới và 「Mũ」「Giáp」 có sẵn
Dù mỗi loại có 10, cũng thành 10×10×10=1000 case, công sức phình to

Kiểm tra toàn bộ tổ hợp là phi thực tế

Nếu thực hiện, nên kiểm tra bằng bảng ma trận hoặc tổ hợp đại diện
OK Xác nhận tổ hợp giữa vũ khí mới và 「Mũ lửa」「Giáp nước」



Chỉ bao gồm 1 điểm kiểm tra trong một test case

NG Xác nhận hành vi khi bắt đầu battle đúng theo đặc tả
Nếu gộp nhiều góc nhìn vào 1 case thì khi thất bại khó tách nguyên nhân và báo cáo cũng mơ hồ

Cần ghi theo nguyên tắc 1 test case = 1 góc nhìn
OK ・Xác nhận chuyển sang màn hình battle
・Xác nhận phát animation
・Xác nhận phát BGM

NG Xác nhận sau khi quest bắt đầu thì hiển thị đúng lời thoại và BGM được đổi
Đây là một test case dài và chứa nhiều góc nhìn

Cần tách thành nhiều test case riêng cho từng góc nhìn
OK ・Xác nhận quest bắt đầu
・Xác nhận hiển thị lời thoại đúng đặc tả
・Xác nhận đổi BGM