https://www.facebook.com/600924876438860/

Trần Vương - Test Manual, 129 Nguyễn Xiển/Thanh Xuân, Hanoi (2026)

26/08/2026

🔐 [Day 478/100] Kiểm thử bảo mật #44 - Kiểm tra OTP khác tài khoản

Một hệ thống yêu cầu OTP để xác nhận một thao tác

• Ngoài kiểm tra nhập OTP → thành công

Hãy thử kiểm tra một tình huống khác

• Tài khoản A nhận được một mã OTP

• Sau đó tài khoản B cũng có một bước yêu cầu OTP

Câu hỏi là:

❓Mã OTP được cấp cho A có thể được dùng để xác nhận cho B hay không?

---

🎯 Cần kiểm thử gì?

Kiểm tra OTP được cấp cho tài khoản A có bị chấp nhận khi sử dụng để xác nhận một thao tác của tài khoản B hay không

Có thể thực hiện với một chức năng như:

• Xác nhận thay đổi email

• Xác nhận số điện thoại

• Xác nhận một giao dịch

• Xác thực tài khoản

---

🧪 Thực hiện như thế nào?

Chuẩn bị:

• Tài khoản A

• Tài khoản B

✅Bước 1

Đăng nhập tài khoản A và thực hiện thao tác cần OTP

Ví dụ:

• Thay đổi số điện thoại

✅Bước 2

Nhận OTP được gửi cho A

Ghi lại mã OTP này

✅Bước 3

Chuyển sang tài khoản B

Thực hiện một thao tác khác cũng yêu cầu OTP

✅Bước 4

Khi hệ thống yêu cầu mã, nhập OTP đã nhận của tài khoản A

✅Bước 5

Quan sát kết quả

---

⚠️ Kết quả không mong muốn

Nếu tài khoản B nhập OTP của A nhưng hệ thống vẫn cho phép:

• Xác nhận thành công

hoặc:

• Tiếp tục thực hiện hành động của B

→ Cần ghi nhận vấn đề nếu OTP được thiết kế để gắn với đúng tài khoản và thao tác tạo ra nó

Đặc biệt chú ý nếu việc này dẫn đến:

• Thay đổi thông tin tài khoản

• Xác nhận giao dịch

• Hoàn tất một hành động quan trọng

---

🔎 Không chỉ kiểm tra “đúng người”

Có một điểm nữa cần quan sát:

OTP của A được tạo ra cho:

• Thao tác X

nhưng lại được sử dụng để xác nhận:

• Thao tác Y

Ví dụ:

• OTP được gửi khi đổi số điện thoại

Sau đó dùng chính mã đó để xác nhận một thao tác khác

Nếu hệ thống yêu cầu OTP phải gắn với đúng hành động, mã này không nên được chấp nhận cho thao tác khác

---

# # 🚨 Khi log bug

Nên ghi rõ 4 thông tin:

• OTP được tạo từ tài khoản nào

• OTP được tạo cho thao tác nào

• OTP được sử dụng ở tài khoản hoặc thao tác nào

• Hệ thống đã cho phép thực hiện hành động gì

Ví dụ:

• OTP được cấp cho tài khoản A khi thực hiện thay đổi số điện thoại. Sử dụng OTP này trên tài khoản B vẫn xác nhận thành công thao tác thay đổi số điện thoại của B

Cách mô tả này giúp phân biệt rõ vấn đề với trường hợp:

• Nhập sai OTP nhưng vẫn được chấp nhận

---

✅ Kết quả mong muốn

OTP phải được kiểm tra đúng với "người dùng và thao tác đã yêu cầu mã"

• OTP của tài khoản A không được dùng để xác nhận cho tài khoản B nếu thiết kế yêu cầu mã gắn với từng tài khoản

Tương tự, OTP được tạo cho một hành động không nên tự động có hiệu lực cho một hành động khác nếu hệ thống yêu cầu xác nhận riêng

---

🔐 Một OTP đúng chưa đủ.

• Hệ thống còn phải xác định mã đó đúng với người nào và đang xác nhận cho hành động nào

25/08/2026

🔐 [Day 477/100] Kiểm thử bảo mật #43 - Cùng một email, viết khác nhau có thành tài khoản khác không?

Có một tài khoản đã được đăng ký bằng:

• `[email protected]`

Sau đó một người khác thử đăng ký bằng:

• `[email protected]`

Nhìn bằng mắt thường, đây gần như là cùng một địa chỉ email

Nhưng hệ thống sẽ coi chúng là:

• Một tài khoản hay hai tài khoản khác nhau?

Đây là một trường hợp khá dễ bỏ qua vì Tester thường chỉ kiểm tra:

• Email đã tồn tại → không cho đăng ký

Nhưng lại ít khi thử cùng một email dưới cách viết khác

---

# # 🎯 Cần kiểm thử gì?

Kiểm tra cách hệ thống xử lý email khi người dùng thay đổi:

• Chữ hoa / chữ thường

Mục tiêu là xác định hệ thống có vô tình tạo ra nhiều tài khoản cho cùng một địa chỉ email hay không

---

# # 🧪 Thực hiện như thế nào?

Chuẩn bị một email test:

• `[email protected]`

✅ Bước 1

Đăng ký tài khoản A bằng:

• `[email protected]`

Hoàn thành đăng ký

✅ Bước 2

• Đăng xuất tài khoản A

✅ Bước 3

• Mở lại chức năng đăng ký

✅ Bước 4

Nhập:

• `[email protected]`

Các ký tự khác giữ nguyên

✅ Bước 5

• Hoàn thành các bước đăng ký nếu hệ thống cho phép

Quan sát xem hệ thống:

• Từ chối vì email đã được sử dụng?

hay:

• Tạo một tài khoản mới?

---

⚠️ Kết quả không mong muốn

Ví dụ:

Tài khoản A đã sử dụng:

• `[email protected]`

Nhưng hệ thống vẫn cho phép tạo tài khoản B bằng:

• `[email protected]`

Nếu theo chính sách của hệ thống, email được dùng làm thông tin nhận diện duy nhất thì đây là tình huống bất thường

Đặc biệt cần kiểm tra tiếp:

• Hai tài khoản có thực sự tồn tại độc lập không?

• Khi đăng nhập bằng hai cách viết, hệ thống đưa người dùng vào tài khoản nào?

• Email khôi phục hoặc thông báo tài khoản được gửi đến đâu?

Nếu hai cách viết tạo ra trạng thái tài khoản không nhất quán, mức độ ảnh hưởng sẽ đáng chú ý hơn

---

🔎 Một điểm không nên kết luận vội

Không phải hệ thống nào cũng bắt buộc phải xử lý email giống nhau

Điều cần xác định trước là:

• Email có được xem là thông tin định danh duy nhất của tài khoản hay không?

Nếu hệ thống quy định email là duy nhất và không phân biệt chữ hoa, chữ thường thì:

• `[email protected]`

và

• `[email protected]`

phải được xử lý như cùng một email

Nếu hệ thống có quy định khác, Tester cần bám theo yêu cầu đó

---

🚨 Vì sao phạm vi này đáng để kiểm tra?

Vấn đề không chỉ nằm ở việc:

• Có tạo được tài khoản thứ hai không?

Một cách xử lý không nhất quán có thể dẫn đến những tình huống khó lường hơn:

• Một người có thể tạo nhiều tài khoản bằng cùng một địa chỉ email.

• Người dùng không biết mình đang đăng nhập vào tài khoản nào.

• Luồng quên mật khẩu có thể xử lý không nhất quán.

• Hệ thống có thể phát sinh hai tài khoản cùng được xem là thuộc về một địa chỉ email

Vì vậy, đây là một trường hợp đáng thử khi kiểm tra các chức năng sử dụng email làm thông tin nhận diện tài khoản

---

📝 Nếu phát hiện vấn đề

Ví dụ:

• Tài khoản A đăng ký bằng `[email protected]`

• Tài khoản B tiếp tục đăng ký được bằng `[email protected]`

• Khi log bug, ghi rõ hai giá trị đã sử dụng và kết quả hệ thống tạo ra

• Không cần suy đoán nguyên nhân bên dưới

Chỉ cần chứng minh:

• Hai cách viết của cùng một địa chỉ email đã tạo ra trạng thái tài khoản không phù hợp với chính sách của hệ thống

---

✅ Kết quả mong muốn

Nếu email được quy định là duy nhất:

• Hệ thống phải nhận diện các cách viết khác nhau của cùng một email theo đúng chính sách đã định nghĩa và không tạo ra tài khoản trùng ngoài ý muốn

Việc xử lý cụ thể chữ hoa, chữ thường cần nhất quán giữa:

> Đăng ký → Đăng nhập → Quên mật khẩu → Thay đổi email

---

🔐 Một giá trị có thể trông khác nhau trên màn hình nhưng vẫn đại diện cho cùng một danh tính

Đừng chỉ kiểm tra dữ liệu khác nhau về mặt ký tự; hãy kiểm tra hệ thống có nhận diện đúng bản chất của dữ liệu đó hay không

24/08/2026

# 🔐 [Day 476/100] Kiểm thử bảo mật #42 - Không xem được dữ liệu, có biết được số liệu không?

Một tài khoản nhân viên chỉ được phép xem dữ liệu của phòng mình.

Khi mở danh sách, hệ thống không hiển thị dữ liệu của các phòng ban khác.

Nhìn qua thì phân quyền hoàn toàn ổn.

Nhưng trên cùng màn hình vô tình lại có:

• Tổng số nhân viên: 128

• Tổng doanh thu: 15 tỷ

• Có 23 đơn hàng đang chờ xử lý

Vậy nếu tài khoản này không được phép xem dữ liệu của phòng ban khác:

👉Nó có được phép nhìn thấy những con số tổng hợp đó không?

Đây là một điểm rất dễ bỏ qua vì Tester thường tập trung kiểm tra **bản ghi nào được hiển thị**, nhưng lại ít chú ý đến những thông tin được tiết lộ thông qua thống kê

---

🎯 Cần kiểm thử gì?

Kiểm tra các thông tin dạng:

• Tổng số lượng

• Tổng tiền

• Số lượng theo trạng thái

• Số lượng theo nhóm/phòng ban

• Các chỉ số thống kê

có phản ánh dữ liệu mà tài khoản hiện tại "không được phép biết hay không"

---

🧪 Thực hiện như thế nào?

Giả sử:

• Tài khoản A chỉ được xem dữ liệu của Phòng Kinh doanh

Phòng Kinh doanh có:

• 20 đơn hàng

Phòng Kỹ thuật có:

• 80 đơn hàng

Bước 1

Đăng nhập bằng tài khoản A

Bước 2

Mở màn hình thống kê hoặc dashboard

Bước 3

Kiểm tra dữ liệu chi tiết

Xác nhận A không nhìn thấy các đơn hàng của Phòng Kỹ thuật

Bước 4

Quan sát các số liệu tổng hợp trên màn hình

Ví dụ:

• Tổng số đơn hàng: 100

Thay vì:

• Tổng số đơn hàng trong phạm vi A được phép xem: 20

Bước 5

Đối chiếu số liệu hiển thị với phạm vi quyền của tài khoản

---

⚠️ Kết quả không mong muốn

Ví dụ:

Tài khoản A chỉ được phép biết 20 đơn hàng

Nhưng dashboard lại hiển thị:

• Tổng cộng: 100 đơn hàng

Hoặc:

• Phòng Kỹ thuật: 80 đơn hàng

Mặc dù A không được phép xem dữ liệu của Phòng Kỹ thuật

Trong trường hợp này, A không nhìn thấy bản ghi chi tiết nhưng vẫn biết:

• Có bao nhiêu dữ liệu tồn tại

Đây là vấn đề cần ghi nhận nếu những số liệu đó cũng thuộc phạm vi cần bảo vệ

---

🔎 Một ví dụ khác dễ nhận ra hơn

Tài khoản A không được phép xem thông tin lương của nhân viên.

Danh sách nhân viên không hiển thị mức lương

Nhưng dashboard lại có:

• Tổng quỹ lương: 8.500.000.000đ

Nếu tài khoản A cũng không được phép biết tổng số liệu này thì việc che mức lương ở danh sách chưa thực sự giải quyết được vấn đề

Tương tự với:

• Số lượng khách hàng

• Tổng giá trị giao dịch

• Số đơn hàng bị hủy

• Số lượng nhân viên của từng phòng ban

✅ Kết quả mong muốn

Các số liệu tổng hợp phải được tính trong đúng phạm vi dữ liệu mà tài khoản được phép xem

Nếu người dùng không có quyền biết dữ liệu của một nhóm:

Các số liệu tổng hợp cũng không nên vô tình tiết lộ dữ liệu của nhóm đó

---

🔐 Phân quyền không chỉ quyết định người dùng nhìn thấy bản ghi nào

Hãy kiểm tra cả những gì họ có thể suy ra từ các con số tổng hợp trên màn hình

23/08/2026

📝[Day 475/100] Checklist common kiểm thử CMS (Hệ thống quản lý nội dung)

22/08/2026

📝 [Day 474/100] Checklist common kiểm thử Khóa học

21/08/2026

🔐 [Day 473/100] Kiểm thử bảo mật #41 - Thu hồi quyền rồi, tài liệu còn xem được không?

Một người dùng A có một tài liệu riêng tư.

• A chia sẻ tài liệu cho B.

• B có thể mở và xem tài liệu.

Sau đó A thu hồi quyền của B, điều gì sẽ xảy ra?

> Nếu B đã từng mở tài liệu trước đó, sau khi bị thu hồi quyền thì B còn mở lại được tài liệu đó không?

Đây là một điểm rất dễ bị bỏ qua

# # 🎯 Cần kiểm thử gì?

Kiểm tra sau khi quyền truy cập tài liệu của một người dùng bị thu hồi:

• Người dùng đó còn có thể truy cập lại tài liệu bằng cách đã từng được sử dụng trước đây hay không

# # 🧪 Kiểm thử như thế nào?

Chuẩn bị hai tài khoản:

> Tài khoản A: chủ sở hữu tài liệu

> Tài khoản B: người được chia sẻ tài liệu

✅Bước 1

Đăng nhập bằng A

Tạo một tài liệu có nội dung dễ nhận biết

✅Bước 2

Chia sẻ tài liệu cho B

✅Bước 3

Đăng nhập bằng B và mở tài liệu

Xác nhận B thực sự có quyền xem tài liệu

✅Bước 4

Đăng nhập lại bằng A

Thu hồi quyền truy cập tài liệu của B

✅Bước 5

Quay lại tài khoản B

Thử mở lại tài liệu mà B đã từng xem

Có thể thực hiện bằng những cách người dùng bình thường có thể sử dụng, chẳng hạn

• Mở lại tài liệu từ danh sách gần đây

• Tìm lại tài liệu

• Mở lại đường dẫn tài liệu đã từng truy cập nếu ứng dụng cung cấp

⚠️ Kết quả không mong muốn

Ví dụ:

A đã thu hồi quyền của B

Nhưng B vẫn có thể:

• Mở tài liệu

• Xem nội dung

• Hoặc tiếp tục chỉnh sửa tài liệu

Nếu theo yêu cầu, việc thu hồi quyền phải khiến B không còn truy cập được tài liệu thì đây là lỗi cần ghi nhận

Đặc biệt cần chú ý trường hợp:

• Tài liệu không còn xuất hiện trong danh sách của B nhưng B vẫn mở được bằng một cách khác

👉Kết quả mong muốn

Sau khi quyền của B bị thu hồi:

• B không được tiếp tục truy cập tài liệu theo phạm vi mà B đã bị thu hồi quyền

• Tài liệu có thể vẫn tồn tại đối với A hoặc những người còn quyền truy cập

• Nhưng B phải được xử lý đúng theo quyền mới

🔐 Khi kiểm tra chức năng thu hồi quyền, đừng chỉ nhìn xem dữ liệu có biến mất khỏi danh sách hay không

👉Hãy thử quay lại dữ liệu mà người dùng đã từng được phép truy cập và xem quyền mới có thực sự được áp dụng hay chưa

19/08/2026

# 🔐 [Day 472/100] Kiểm thử bảo mật #40 - Tạo lại tài khoản, dữ liệu cũ có quay trở lại không?

Một người dùng có tài khoản A

Trong quá trình sử dụng, tài khoản A đã tạo ra nhiều dữ liệu:

• Hồ sơ cá nhân

• Đơn hàng

• Lịch sử hoạt động

• Các thiết lập riêng

Sau đó người dùng xóa tài khoản

Một thời gian sau, họ đăng ký lại bằng chính email hoặc số điện thoại trước đây

Hệ thống tạo thành công một tài khoản mới

Mọi thứ có vẻ bình thường cho đến khi câu hỏi là:

❓Tài khoản mới có vô tình nhìn thấy hoặc sử dụng lại dữ liệu của tài khoản cũ không?

---

# # 🎯 Cần kiểm thử gì?

Kiểm tra sau khi xóa một tài khoản và đăng ký lại bằng thông tin định danh cũ:

👉Tài khoản mới có được xem là một tài khoản hoàn toàn mới hay vẫn được liên kết với dữ liệu của tài khoản trước đó?

---

# # 🧪 Kiểm thử như thế nào?

**Bước 1.**

Đăng ký tài khoản A bằng một email hoặc số điện thoại test

**Bước 2.**

Tạo một vài dữ liệu dễ nhận biết

Ví dụ:

> Tạo một đơn hàng

> Thêm một thông tin cá nhân

> Tạo một dữ liệu có mã hoặc tên đặc biệt để dễ kiểm tra lại

**Bước 3.**

Xóa tài khoản A theo đúng chức năng của hệ thống

**Bước 4.**

Đăng ký lại bằng chính email hoặc số điện thoại trước đây (nếu hệ thống cho phép)

Tài khoản này sẽ được coi là tài khoản B

**Bước 5.**

Kiểm tra các màn hình chứa dữ liệu mà A đã từng có

Ví dụ:

> Lịch sử đơn hàng

> Hồ sơ

> Dữ liệu đã tạo

> Thiết lập tài khoản

Quan sát xem B có nhìn thấy dữ liệu của A hay không

---

# # ⚠️ Kết quả không mong muốn

Ví dụ:

Tài khoản A đã bị xóa

Sau đó đăng ký lại bằng cùng email

Tài khoản mới vẫn nhìn thấy:

• Đơn hàng cũ của A

Hoặc:

• Thông tin cá nhân cũ

Hoặc:

• Lịch sử hoạt động của A

Nếu theo thiết kế, tài khoản đăng ký lại phải là **một tài khoản mới hoàn toàn**, đây là vấn đề cần ghi nhận.

Đặc biệt chú ý nếu người dùng mới có thể:

• Xem
• Sửa
• Hoặc tiếp tục sử dụng

dữ liệu mà họ không tạo ra trong tài khoản mới

# # 🔎 Cần phân biệt với dữ liệu được phép lưu giữ

Không phải cứ tài khoản mới nhìn thấy một thông tin giống tài khoản cũ là chắc chắn lỗi

Một số thông tin có thể được hệ thống chủ động giữ lại theo chính sách nghiệp vụ

Ví dụ:

• Thông tin phục vụ giao dịch

• Dữ liệu bắt buộc phải lưu trữ

Vì vậy, Tester cần xác định trước:

✅Tài khoản đăng ký lại có được phép kế thừa dữ liệu của tài khoản cũ hay không?

Nếu yêu cầu là:

> Tài khoản mới phải bắt đầu với dữ liệu hoàn toàn mới thì dữ liệu của A không được xuất hiện trong tài khoản B

# # ✅ Kết quả mong muốn

Nếu tài khoản đăng ký lại được coi là tài khoản mới:

• Tài khoản mới không được tự động kế thừa dữ liệu riêng của tài khoản đã bị xóa

• Tài khoản mới chỉ có dữ liệu được tạo hoặc được cấp cho chính tài khoản đó theo đúng thiết kế

---

# # Xóa tài khoản chưa phải điểm cuối của việc kiểm thử dữ liệu.

👉 Hãy thử đăng ký lại và kiểm tra xem quá khứ của tài khoản cũ có vô tình đi theo tài khoản mới hay không

18/08/2026

# 🔐 [Day 471/100] Kiểm thử bảo mật #39 - Thay đổi bảo mật có được cảnh báo không?

Một người dùng đang sử dụng tài khoản bình thường.

Sau đó có một thay đổi quan trọng xảy ra:

• Mật khẩu được thay đổi

Hoặc:

• Email đăng nhập được thay đổi

• Chức năng vẫn hoạt động đúng

• Thông tin mới được lưu thành công

Nhưng có một câu hỏi:

❓Chủ tài khoản có được biết rằng thông tin bảo mật của mình vừa bị thay đổi hay không?

Đây không phải là kiểm tra việc thay đổi có thành công hay không

Mà là kiểm tra cơ chế cảnh báo khi tài khoản có một thay đổi quan trọng
---
# # 🎯 Cần kiểm thử gì?

Kiểm tra sau khi thực hiện một thay đổi quan trọng liên quan đến bảo mật tài khoản, hệ thống có gửi cảnh báo cho người dùng theo đúng thiết kế hay không

Có thể kiểm tra với những thay đổi như:

• Đổi mật khẩu

• Đổi email đăng nhập

• Đổi số điện thoại

• Thay đổi thông tin bảo mật quan trọng

Không cần kiểm tra tất cả trong cùng một testcase

Chọn một chức năng có yêu cầu cảnh báo là đủ

# # 🧪 Kiểm thử như thế nào?

Ví dụ hệ thống có yêu cầu:

• Khi mật khẩu được thay đổi, hệ thống gửi email thông báo cho chủ tài khoản

**Bước 1.**

Đăng nhập bằng tài khoản A

**Bước 2.**

Ghi nhận email hiện tại của tài khoản

**Bước 3.**

Thực hiện đổi mật khẩu thành công

**Bước 4.**

Kiểm tra hộp thư của tài khoản A

**Bước 5.**

Kiểm tra nội dung thông báo

Cần xác nhận:

• Có thông báo được gửi không?

• Thông báo có cho biết tài khoản vừa được thay đổi thông tin bảo mật không?

• Thông báo có gửi đúng đến tài khoản cần nhận không?

# # ⚠️ Kết quả không mong muốn

Ví dụ yêu cầu của hệ thống quy định:

> Sau khi đổi mật khẩu phải gửi cảnh báo

Nhưng sau khi đổi thành công:

• Không có thông báo nào được gửi.

Hoặc thông báo được gửi nhưng:

• Gửi nhầm đến địa chỉ khác

Hoặc nội dung thông báo không cho người dùng biết:

• Tài khoản vừa có thay đổi bảo mật quan trọng

👉 Cần ghi nhận lỗi theo phạm vi yêu cầu.

# # 🔎 Một tình huống đáng chú ý

Hãy tưởng tượng người dùng không phải là người thực hiện thay đổi

Ví dụ:

• Chủ tài khoản nhận được email: “Mật khẩu tài khoản của bạn vừa được thay đổi."

Người dùng đọc được thông báo và nhận ra "Tôi không thực hiện thao tác này"

Khi đó họ có cơ hội phát hiện sớm rằng tài khoản có thể đang gặp vấn đề

Đây chính là giá trị của cơ chế cảnh báo

Nó không ngăn hành động xảy ra, nhưng giúp chủ tài khoản phát hiện một thay đổi mà họ không mong đợi
---

# # ✅ Kết quả mong muốn

Nếu chức năng có yêu cầu cảnh báo:

• Thay đổi bảo mật thành công phải tạo ra cảnh báo đúng đối tượng và đúng kênh được quy định

Thông báo cần đủ để người dùng nhận biết:

• Tài khoản vừa có một thay đổi quan trọng.

Nội dung cụ thể phụ thuộc vào thiết kế của sản phẩm

---

# # 🔐 Một cơ chế bảo mật tốt không chỉ ngăn hành vi bất thường

👉Nó cũng giúp chủ tài khoản nhận ra khi có điều gì quan trọng xảy ra với tài khoản của mình

17/08/2026

🔐 [Day 470/100] Kiểm thử bảo mật #38 - Có thể đổi email hoặc số điện thoại sang tài khoản khác không?

Một người dùng đang sử dụng tài khoản A

Tài khoản A có email:

• "[email protected]"

Một người dùng khác đang có tài khoản B với email:

• "[email protected]"

Bây giờ A vào chức năng **Đổi email** và nhập:

• "[email protected]`

Liệu hệ thống có cho phép không?

Nếu cho phép, chuyện gì sẽ xảy ra với tài khoản B?

Đây là một tình huống rất đơn giản nhưng Tester thường chỉ kiểm tra:

• Email mới đúng định dạng → đổi thành công

Trong khi điều quan trọng hơn là:

• Email hoặc số điện thoại mới có đang thuộc về một tài khoản khác hay không?

# # 🎯 Tester cần kiểm tra gì?

Kiểm tra hệ thống có ngăn người dùng thay đổi thông tin định danh của tài khoản sang:

• Email đã được sử dụng bởi tài khoản khác

• Số điện thoại đã được sử dụng bởi tài khoản khác

Tập trung vào những thông tin mà hệ thống sử dụng để nhận diện hoặc đăng nhập tài khoản

# # 🧪 Tester có thể kiểm tra như thế nào?

Chuẩn bị hai tài khoản:

• Tài khoản A: [email protected]

• Tài khoản B: [email protected]

**Bước 1.**

Đăng nhập bằng tài khoản A

**Bước 2.**

Mở chức năng thay đổi email

**Bước 3.**

Nhập email đang thuộc tài khoản B: [email protected]

**Bước 4.**

Hoàn thành các bước xác nhận theo đúng thiết kế của hệ thống

**Bước 5.**

Quan sát kết quả

Sau đó kiểm tra lại cả hai tài khoản để xác định:

• Email của A có bị thay đổi không?

• Email của B có bị ảnh hưởng không?

• Hệ thống có tạo ra hai tài khoản cùng sử dụng một email không?

Có thể thực hiện tương tự với **số điện thoại** nếu hệ thống sử dụng số điện thoại để nhận diện tài khoản.

# # ⚠️ Kết quả không mong muốn

Ví dụ tài khoản B đang sử dụng: [email protected]

Nhưng tài khoản A vẫn có thể đổi email thành: [email protected]

và hệ thống chấp nhận

Đây là tình huống cần ghi nhận nếu yêu cầu của hệ thống quy định email phải là duy nhất

Đặc biệt chú ý nếu sau đó xảy ra các vấn đề như:

• Hai tài khoản cùng sử dụng một email

• Không xác định được email thuộc tài khoản nào

• Người dùng có thể đăng nhập nhầm vào tài khoản khác

• Email được sử dụng để khôi phục hoặc xác nhận tài khoản nhưng không còn xác định đúng chủ sở hữu

Khi log bug, nên ghi rõ:

• Tài khoản A đổi email sang email đang thuộc tài khoản B và hệ thống vẫn chấp nhận

Không cần suy đoán sâu về nguyên nhân. Chỉ cần chứng minh được hành vi và ảnh hưởng

# # 🔎 Một điểm cần kiểm tra thêm

Không phải hệ thống nào cũng yêu cầu: Email hoặc số điện thoại phải duy nhất

Có hệ thống cho phép nhiều tài khoản sử dụng cùng một thông tin vì mục đích nghiệp vụ riêng

Vì vậy, trước khi kết luận đây là lỗi bảo mật, cần xác nhận:

❓Thông tin này có được yêu cầu là duy nhất hay không?

Nếu yêu cầu là duy nhất thì:

• Người dùng không được phép đổi sang thông tin đang thuộc tài khoản khác

Nếu không có yêu cầu này, không nên tự coi việc trùng thông tin là lỗi

# # ✅ Kết quả mong muốn

Nếu email hoặc số điện thoại được quy định là thông tin duy nhất:

• Hệ thống phải từ chối khi người dùng cố gắng đổi sang thông tin đang thuộc tài khoản khác

• Thông báo có thể cho biết thông tin đã được sử dụng, tùy yêu cầu của hệ thống

Quan trọng nhất:

• Tài khoản A không được chiếm thông tin định danh đang thuộc B

• Tài khoản B không bị thay đổi hoặc mất thông tin ngoài ý muốn

• Không tạo ra trạng thái hai tài khoản cùng sở hữu một thông tin mà hệ thống yêu cầu phải duy nhất

# # 🔐 Khi kiểm thử chức năng đổi thông tin tài khoản, đừng chỉ thử thông tin đúng định dạng

👉Hãy thử cả thông tin đang thuộc về một tài khoản khác

16/08/2026

📝[Day 469/100] Checklist common kiểm thử Dashboard

Trần Vương - Test Manual

26/08/2026

25/08/2026

24/08/2026

23/08/2026

22/08/2026

21/08/2026

19/08/2026

18/08/2026

17/08/2026

16/08/2026

Address

Website

Alerts

Shortcuts

Share

Category

Listing takedown request