Test Cases: Quản lý Người dùng
| Module | CORE-01 | URD | User Management URD |
|---|
1. Tóm tắt Độ phủ
| Vùng | URD reqs | Test case | Đã phủ |
|---|---|---|---|
Xác thực (AUTH) | 14 | 13 | ⚠️ |
Tài khoản Người dùng (USR) | 11 | 12 | ✅ |
Vai trò & Phân phạm vi (ROLE) | 8 | 8 | ✅ |
Quản lý Nhân viên (EMP) | 8 | 8 | ✅ |
Quản lý Khách hàng (CUS) | 6 | 6 | ✅ |
Cấu hình Người dùng (CFG) | 3 | 3 | ✅ |
Mức ưu tiên = P1 (nghiêm trọng) / P2 (lớn) / P3 (nhỏ). Các bước dùng Cho / Khi / Thì.
2. Test Cases
2.1 Xác thực
| TC ID | URD ref | Tình huống | Các bước | Kỳ vọng | P |
|---|---|---|---|---|---|
| TC-AUTH-001 | URD-AUTH-001 | Đăng ký với username + mật khẩu hợp lệ | Cho một người dùng mới; Khi họ đăng ký | Tài khoản được tạo; vai trò Owner được gán | P1 |
| TC-AUTH-002 | URD-AUTH-001 | Đăng ký với username đã dùng | Cho một username đã đăng ký; Khi người dùng mới đăng ký với nó | Bị từ chối; định danh đã được sử dụng | P1 |
| TC-AUTH-003 | URD-AUTH-002, URD-CFG-001 | Đăng ký tạo mọi thứ cùng lúc | Cho một đăng ký hợp lệ; Khi nó hoàn tất | Tài khoản, hồ sơ, định danh và cài đặt mặc định đều tồn tại | P1 |
| TC-AUTH-004 | URD-AUTH-003 | Roll back đăng ký nguyên tử | Cho một đăng ký mà một bước thất bại; Khi transaction chạy | Không có gì được tạo — roll back toàn bộ | P1 |
| TC-AUTH-005 | URD-AUTH-004 | Đăng nhập với thông tin hợp lệ | Cho một người dùng đã xác minh; Khi họ đăng nhập với định danh + mật khẩu | Xác thực thành công | P1 |
| TC-AUTH-006 | URD-AUTH-004 | Đăng nhập với mật khẩu sai | Cho một người dùng đã đăng ký; Khi họ đăng nhập với mật khẩu sai | Bị từ chối; lỗi không tiết lộ tài khoản có tồn tại hay không | P1 |
| TC-AUTH-007 | URD-AUTH-005 | Token mang phạm vi | Cho một đăng nhập thành công; Khi token được kiểm tra | Token chứa user ID, vai trò, ID tổ chức, ID merchant | P1 |
| TC-AUTH-008 | URD-AUTH-006 | Mật khẩu được băm | Cho một tài khoản đã tạo; Khi lưu trữ credential được kiểm tra | Mật khẩu được lưu băm, không bao giờ dạng văn bản thuần | P1 |
| TC-AUTH-009 | URD-AUTH-007 | Đổi mật khẩu — hiện tại đúng | Cho một người dùng đã xác thực; Khi họ đổi mật khẩu với mật khẩu hiện tại đúng | Được cập nhật; người dùng đăng nhập với mật khẩu mới | P1 |
| TC-AUTH-010 | URD-AUTH-007 | Đổi mật khẩu — hiện tại sai | Cho một người dùng đã xác thực; Khi họ cung cấp mật khẩu hiện tại sai | Bị từ chối; mật khẩu hiện tại không đúng | P1 |
| TC-AUTH-011 | URD-AUTH-008, URD-USR-005 | Xác minh email qua OTP | Cho một email chưa xác minh; Khi người dùng yêu cầu và gửi OTP đúng | Định danh email được đánh dấu đã xác minh | P1 |
| TC-AUTH-012 | URD-AUTH-010 | Đặt lại mật khẩu đã quên | Cho một người dùng quên mật khẩu; Khi họ yêu cầu, xác minh mã và đặt mật khẩu mới | Mật khẩu được đặt lại; người dùng đăng nhập với mật khẩu mới | P1 |
| TC-AUTH-013 | URD-AUTH-012 | Ghi lại đăng nhập gần nhất | Cho một đăng nhập thành công; Khi xem chi tiết người dùng | Dấu thời gian đăng nhập gần nhất được cập nhật và hiển thị | P2 |
Khoảng trống đã biết — xác minh email khi đăng ký
Xác minh email hiện đang bị tắt khi đăng ký trong mã, trong khi đăng nhập yêu cầu một định danh đã xác minh. Một người dùng đăng ký rồi cố đăng nhập bằng email có thể bị chặn cho đến khi email được xác minh qua một luồng riêng. TC-AUTH-011 phủ luồng xác minh; đường đăng-ký→đăng-nhập-bằng-email là một lỗi đã biết, không phải case đạt. Xem tài liệu developer.
2.2 Tài khoản Người dùng
| TC ID | URD ref | Tình huống | Các bước | Kỳ vọng | P |
|---|---|---|---|---|---|
| TC-USR-001 | URD-USR-001 | ID hệ thống duy nhất | Cho một tài khoản được tạo; Khi nó được kiểm tra | Một ID duy nhất, bất biến, không bao giờ tái dùng được gán | P1 |
| TC-USR-002 | URD-USR-002 | Nhiều định danh | Cho một người dùng có email; Khi thêm một điện thoại | Cả hai định danh được lưu; người dùng tra cứu được bằng một trong hai | P1 |
| TC-USR-003 | URD-USR-003 | Tính duy nhất email | Cho người dùng A sở hữu một email; Khi người dùng B đăng ký với email đó | Bị từ chối; email đã được sử dụng | P1 |
| TC-USR-004 | URD-USR-003 | Tính duy nhất điện thoại | Cho người dùng A sở hữu một điện thoại; Khi người dùng B thêm điện thoại đó | Bị từ chối; định danh duy nhất theo loại | P2 |
| TC-USR-005 | URD-USR-004 | Username tự xác minh | Cho một tài khoản mới; Khi định danh username được kiểm tra | Username được xác minh ngay lập tức | P1 |
| TC-USR-006 | URD-USR-005 | Email bắt đầu chưa xác minh | Cho một email mới thêm; Khi kiểm tra trước khi xác minh | Trạng thái là chưa xác minh cho tới khi OTP hoàn tất | P1 |
| TC-USR-007 | URD-USR-006 | Xem / cập nhật hồ sơ | Cho một người dùng đã xác thực; Khi họ cập nhật tên và locale | Hồ sơ được cập nhật; thay đổi phản ánh ở lần đọc kế tiếp | P1 |
| TC-USR-008 | URD-USR-007 | Vô hiệu hóa rồi kích hoạt lại | Cho một tài khoản ACTIVATED; Khi admin vô hiệu hóa rồi kích hoạt lại | Trạng thái chuyển ACTIVATED → DEACTIVATED → ACTIVATED; khôi phục đăng nhập | P1 |
| TC-USR-009 | URD-USR-007 | Chặn vì bảo mật | Cho một tài khoản ACTIVATED; Khi admin chặn nó | Trạng thái thành BLOCKED; người dùng không thể đăng nhập | P1 |
| TC-USR-010 | URD-USR-008 | Đã vô hiệu hóa không đăng nhập được | Cho một tài khoản DEACTIVATED; Khi người dùng đăng nhập | Bị từ chối; tài khoản đã vô hiệu hóa | P1 |
| TC-USR-011 | URD-USR-009 | Soft-delete bảo toàn dữ liệu | Cho một người dùng có dữ liệu bị gỡ; Khi kiểm tra bản ghi | Dữ liệu được bảo toàn; không xóa vật lý | P1 |
| TC-USR-012 | URD-USR-011 | Archived là cuối | Cho một tài khoản ARCHIVED; Khi admin cố kích hoạt lại | Bị từ chối; ARCHIVED không thể kích hoạt lại | P2 |
Phát hiện QE — tính duy nhất định danh khi cập nhật
Kiểm tra tính duy nhất định danh khi cập nhật có logic bị đảo — nó có thể cho phép một email / điện thoại trùng giữa các người dùng trong khi cập nhật. TC-USR-003 / TC-USR-004 phủ đường tạo; đường cập nhật là một lỗi đã biết.
2.3 Vai trò & Phân phạm vi
| TC ID | URD ref | Tình huống | Các bước | Kỳ vọng | P |
|---|---|---|---|---|---|
| TC-ROLE-001 | URD-ROLE-001 | Tám vai trò cố định tồn tại | Cho một hệ thống đã khởi tạo; Khi liệt kê vai trò | Super Admin, Admin, Operator, Owner, Cashier, Employee, Customer, Guest tồn tại | P1 |
| TC-ROLE-002 | URD-ROLE-002 | Tạo tài khoản nội bộ tôn trọng phân cấp | Cho một Admin; Khi họ tạo một Operator | Operator được tạo; một Operator không thể tạo Operator khác | P1 |
| TC-ROLE-003 | URD-ROLE-003 | Người dùng nội bộ bỏ qua bộ lọc | Cho một Super Admin; Khi họ truy vấn dữ liệu | Trả mọi dữ liệu toàn hệ thống; không áp dụng lọc phạm vi | P1 |
| TC-ROLE-004 | URD-ROLE-004 | Owner giới hạn theo org của mình | Cho Owner của Org X; Khi họ truy vấn dữ liệu Org Y | Từ chối truy cập; Owner giới hạn theo org của mình và merchant của nó | P1 |
| TC-ROLE-005 | URD-ROLE-005 | Employee giới hạn theo merchant | Cho một nhân viên được gán Merchant A; Khi họ liệt kê đơn hàng trên A và B | Chỉ trả đơn hàng Merchant A | P1 |
| TC-ROLE-006 | URD-ROLE-006 | Count được lọc theo phạm vi | Cho một nhân viên chỉ trên Merchant A; Khi họ yêu cầu count sản phẩm | Count chỉ gồm sản phẩm Merchant A | P1 |
| TC-ROLE-007 | URD-ROLE-007 | Không tự nâng quyền | Cho một Employee; Khi họ cố tự cấp Owner | Bị từ chối; không thể quản lý vai trò ở mức hoặc cao hơn ưu tiên của mình | P1 |
| TC-ROLE-008 | URD-ROLE-008 | Owner tự gán khi đăng ký | Cho một đăng ký hoàn tất; Khi vai trò người dùng được kiểm tra | Vai trò Owner được gán tự động | P1 |
2.4 Quản lý Nhân viên
| TC ID | URD ref | Tình huống | Các bước | Kỳ vọng | P |
|---|---|---|---|---|---|
| TC-EMP-001 | URD-EMP-001 | Owner tạo nhân viên | Cho một Owner; Khi họ tạo một nhân viên | Tài khoản được tạo với vai trò Employee, liên kết tới tổ chức | P1 |
| TC-EMP-002 | URD-EMP-002 | Nhân viên liên kết với merchant | Cho một nhân viên được gán A và B; Khi ánh xạ được kiểm tra | Nhân viên ánh xạ tới org và tới Merchant A và B | P1 |
| TC-EMP-003 | URD-EMP-003 | Truy cập liên-merchant bị từ chối | Cho một nhân viên chỉ trên Merchant A; Khi họ truy cập dữ liệu Merchant B | Từ chối truy cập | P1 |
| TC-EMP-004 | URD-EMP-004 | Đăng nhập nhân viên | Cho một nhân viên với thông tin xác thực hợp lệ; Khi họ đăng nhập | Được xác thực với truy cập giới hạn theo merchant được gán | P1 |
| TC-EMP-005 | URD-EMP-005 | Truy vấn lọc theo gán | Cho một nhân viên trên Merchant A; Khi họ truy vấn đơn hàng | Chỉ trả đơn hàng Merchant A; B không hiển thị | P1 |
| TC-EMP-006 | URD-EMP-006 | Gán lại merchant | Cho một nhân viên trên Merchant A; Khi Owner cập nhật thành A + B | Gán trước được thay; nhân viên giờ thấy A và B; không có tài khoản mới | P2 |
| TC-EMP-007 | URD-EMP-007 | Vô hiệu hóa / gỡ nhân viên | Cho một nhân viên đang hoạt động; Khi Owner vô hiệu hóa rồi gỡ họ | Nhân viên không thể đăng nhập nữa; bản ghi soft-deleted; dữ liệu được bảo toàn | P1 |
| TC-EMP-008 | URD-EMP-008 | Xác thực quyền sở hữu | Cho một Owner; Khi họ tạo nhân viên cho một merchant họ không sở hữu | Bị từ chối; quyền sở hữu org / merchant được xác thực | P1 |
2.5 Quản lý Khách hàng
| TC ID | URD ref | Tình huống | Các bước | Kỳ vọng | P |
|---|---|---|---|---|---|
| TC-CUS-001 | URD-CUS-001 | Owner tạo khách hàng | Cho một Owner; Khi họ tạo một khách hàng | Tài khoản khách hàng được tạo và liên kết tới tổ chức | P1 |
| TC-CUS-002 | URD-CUS-002 | Vai trò Customer tự gán | Cho một khách hàng đã tạo; Khi tài khoản được kiểm tra | Vai trò Customer được gán; liên kết tới tổ chức | P1 |
| TC-CUS-003 | URD-CUS-003 | Hồ sơ khách hàng | Cho một khách hàng; Khi hồ sơ được kiểm tra | Hồ sơ gồm tên và thông tin liên hệ | P2 |
| TC-CUS-004 | URD-CUS-004 | Cập nhật / soft-delete khách hàng | Cho một khách hàng; Khi Owner cập nhật thông tin liên hệ rồi gỡ họ | Thay đổi được lưu; khách hàng soft-deleted, dữ liệu được bảo toàn | P1 |
| TC-CUS-005 | URD-CUS-005 | Nâng cấp khách hàng bán hàng | Cho một khách hàng cấp bán hàng; Khi kích hoạt nâng cấp | Người dùng đầy đủ được tạo với vai trò Customer | P2 |
| TC-CUS-006 | URD-CUS-006 | Kiểm tra xung đột khi nâng cấp | Cho một khách hàng bán hàng có email đã bị chiếm; Khi nâng cấp chạy | Bị chặn với lỗi xung đột | P2 |
Khoảng trống đã biết — khách hàng không đăng nhập được
Tài khoản khách hàng được tạo không có thông tin xác thực hoặc định danh đăng nhập, nên hiện chưa thể xác thực. TC-CUS-001..004 xác minh việc quản lý bản ghi khách hàng bởi Owner; tự phục vụ đăng nhập cho khách hàng chưa được hỗ trợ. Xem tài liệu developer.
2.6 Cấu hình Người dùng
| TC ID | URD ref | Tình huống | Các bước | Kỳ vọng | P |
|---|---|---|---|---|---|
| TC-CFG-001 | URD-CFG-001 | Mặc định tạo khi đăng ký | Cho một đăng ký mới; Khi tài khoản được tạo | Một bộ cấu hình người dùng mặc định tồn tại | P1 |
| TC-CFG-002 | URD-CFG-002 | Tính duy nhất config theo người dùng | Cho một người dùng có config; Khi thêm một code trùng | Bị từ chối; code duy nhất theo người dùng | P2 |
| TC-CFG-003 | URD-CFG-003 | Xem / cập nhật config | Cho một người dùng đã xác thực; Khi họ đọc và cập nhật một cài đặt | Cài đặt được trả về và cập nhật được lưu | P2 |
3. Truy vết
Mọi yêu cầu Must phải ánh xạ tới ≥1 test case. Khoảng trống được nêu rõ.
| Yêu cầu URD | Test case | Trạng thái |
|---|---|---|
| URD-AUTH-001 | TC-AUTH-001, TC-AUTH-002 | ✅ Đã phủ |
| URD-AUTH-002 | TC-AUTH-003 | ✅ Đã phủ |
| URD-AUTH-003 | TC-AUTH-004 | ✅ Đã phủ |
| URD-AUTH-004 | TC-AUTH-005, TC-AUTH-006 | ✅ Đã phủ |
| URD-AUTH-005 | TC-AUTH-007 | ✅ Đã phủ |
| URD-AUTH-006 | TC-AUTH-008 | ✅ Đã phủ |
| URD-AUTH-007 | TC-AUTH-009, TC-AUTH-010 | ✅ Đã phủ |
| URD-AUTH-008 | TC-AUTH-011 | ✅ Đã phủ |
| URD-AUTH-009 | — | ⚠️ Chưa phủ — xác minh OTP điện thoại (bản sao của TC-AUTH-011) |
| URD-AUTH-010 | TC-AUTH-012 | ✅ Đã phủ |
| URD-AUTH-011 | — | ⚠️ Chưa phủ (Should) — liên kết tài khoản |
| URD-AUTH-012 | TC-AUTH-013 | ✅ Đã phủ |
| URD-AUTH-013 | — | ⚠️ Planned — chưa xây bắt buộc 2FA |
| URD-AUTH-014 | — | ⚠️ Planned — chưa xây đăng nhập OAuth |
| URD-USR-001 | TC-USR-001 | ✅ Đã phủ |
| URD-USR-002 | TC-USR-002 | ✅ Đã phủ |
| URD-USR-003 | TC-USR-003, TC-USR-004 | ✅ Đã phủ |
| URD-USR-004 | TC-USR-005 | ✅ Đã phủ |
| URD-USR-005 | TC-USR-006, TC-AUTH-011 | ✅ Đã phủ |
| URD-USR-006 | TC-USR-007 | ✅ Đã phủ |
| URD-USR-007 | TC-USR-008, TC-USR-009, TC-USR-012 | ✅ Đã phủ |
| URD-USR-008 | TC-USR-010 | ✅ Đã phủ |
| URD-USR-009 | TC-USR-011 | ✅ Đã phủ |
| URD-USR-010 | TC-USR-007 | ✅ Đã phủ |
| URD-USR-011 | TC-USR-012 | ✅ Đã phủ |
| URD-ROLE-001 | TC-ROLE-001 | ✅ Đã phủ |
| URD-ROLE-002 | TC-ROLE-002 | ✅ Đã phủ |
| URD-ROLE-003 | TC-ROLE-003 | ✅ Đã phủ |
| URD-ROLE-004 | TC-ROLE-004 | ✅ Đã phủ |
| URD-ROLE-005 | TC-ROLE-005 | ✅ Đã phủ |
| URD-ROLE-006 | TC-ROLE-006 | ✅ Đã phủ |
| URD-ROLE-007 | TC-ROLE-007 | ✅ Đã phủ |
| URD-ROLE-008 | TC-ROLE-008 | ✅ Đã phủ |
| URD-EMP-001 | TC-EMP-001 | ✅ Đã phủ |
| URD-EMP-002 | TC-EMP-002 | ✅ Đã phủ |
| URD-EMP-003 | TC-EMP-003 | ✅ Đã phủ |
| URD-EMP-004 | TC-EMP-004 | ✅ Đã phủ |
| URD-EMP-005 | TC-EMP-005 | ✅ Đã phủ |
| URD-EMP-006 | TC-EMP-006 | ✅ Đã phủ |
| URD-EMP-007 | TC-EMP-007 | ✅ Đã phủ |
| URD-EMP-008 | TC-EMP-008 | ✅ Đã phủ |
| URD-CUS-001 | TC-CUS-001 | ✅ Đã phủ |
| URD-CUS-002 | TC-CUS-002 | ✅ Đã phủ |
| URD-CUS-003 | TC-CUS-003 | ✅ Đã phủ |
| URD-CUS-004 | TC-CUS-004 | ✅ Đã phủ |
| URD-CUS-005 | TC-CUS-005 | ✅ Đã phủ |
| URD-CUS-006 | TC-CUS-006 | ✅ Đã phủ |
| URD-CFG-001 | TC-CFG-001 | ✅ Đã phủ |
| URD-CFG-002 | TC-CFG-002 | ✅ Đã phủ |
| URD-CFG-003 | TC-CFG-003 | ✅ Đã phủ |
Khoảng trống mở: một yêu cầu Must (URD-AUTH-009, OTP điện thoại) thiếu test case riêng — hãy thêm một TC theo mẫu TC-AUTH-011. URD-AUTH-011 (liên kết tài khoản, Should) cũng chưa phủ. URD-AUTH-013/014 là Planned và cố ý không kiểm thử.