Trang chủ Kho kiến thức Lý thuyết Kiểm thử: KT theo ca sử dụng (Use Case Testing)

Lý thuyết Kiểm thử: KT theo ca sử dụng (Use Case Testing)

Khám phá phương pháp kiểm thử theo ca sử dụng (Use Case Testing) chuyên sâu giúp đảm bảo chất lượng phần mềm, tối ưu quy trình và phát hiện lỗi kịch bản nhanh.

kiểm thử theo ca sử dụnguse case testing là gìquy trình kiểm thửkỹ thuật kiểm thử phần mềmhướng dẫn use case testing

 
menu_book

1. Tổng Quan Về Use Case Testing

Kiểm thử theo ca sử dụng (Use Case Testing) là một kỹ thuật kiểm thử hộp đen (Black-box testing) mang tính chiến lược, tập trung hoàn toàn vào việc đánh giá hệ thống phần mềm từ góc nhìn của người dùng cuối (End-user perspective). Kỹ thuật này không quan tâm đến mã nguồn bên trong mà chỉ quan tâm đến các tương tác giữa người dùng và hệ thống.

Mục tiêu tối thượng của phương pháp này là đảm bảo rằng tất cả các chức năng của phần mềm hoạt động chính xác trong các tình huống thực tế đời sống. Nó xác minh xem phần mềm có cung cấp đúng giá trị, đúng quy trình cho những đối tượng tương tác với nó hay không.

fact_check

Đặc Điểm Nhận Diện Cốt Lõi

  • Hoàn toàn dựa trên các yêu cầu nghiệp vụ thực tế.
  • Mô tả chi tiết sự tương tác qua lại giữa Actor (Tác nhân) và System (Hệ thống).
  • Bao phủ các kịch bản thành công (Happy Path) và các kịch bản lỗi.
  • Được thiết kế dưới dạng luồng sự kiện (Flow of events) từng bước rõ ràng.
  • Giúp phát hiện sớm các lỗ hổng về mặt logic nghiệp vụ (Business logic gaps).
hub

1.1. Các Thành Phần Cấu Trúc Bắt Buộc

Một Use Case tiêu chuẩn không thể tồn tại nếu thiếu đi ba trụ cột cơ bản sau đây. Sự thiếu sót của bất kỳ thành phần nào cũng sẽ dẫn đến một kịch bản kiểm thử không hoàn chỉnh.

person

1.1.1. Tác Nhân (Actor)

Bất kỳ thực thể nào thực hiện hành động tương tác với hệ thống phần mềm.

Actor Chính (Primary): Người hoặc hệ thống khởi tạo Use Case để đạt được mục tiêu. (Ví dụ: Khách hàng mua hàng).

Actor Phụ (Secondary): Người hoặc hệ thống hỗ trợ hệ thống hoàn thành Use Case. (Ví dụ: Cổng thanh toán VNPay).

Lưu ý: Actor không nhất thiết phải là con người, có thể là một API, một hệ thống máy chủ khác, hoặc một thiết bị phần cứng.

developer_board

1.1.2. Ca Sử Dụng (Use Case)

Một tập hợp các hành động chi tiết mà hệ thống phải thực hiện để tạo ra kết quả có giá trị cho Actor.

Mục tiêu: Rõ ràng, đo lường được.

Mô tả: Bao gồm tiền điều kiện (Pre-conditions), các bước thực hiện (Steps), và hậu điều kiện (Post-conditions).

Độ phức tạp: Từ những hành động đơn giản như "Đăng nhập" đến các quy trình phức tạp như "Quyết toán thuế cuối năm".

settings_ethernet

1.1.3. Giao Tiếp (Communication)

Đường dây liên kết chỉ ra sự tương tác và truyền tải thông tin giữa Actor và Use Case.

Luồng dữ liệu: Xác định thông tin gì được gửi vào hệ thống và hệ thống phản hồi lại thông tin gì.

Giao diện tương tác: Qua UI/UX, qua dòng lệnh (CLI), hoặc qua giao thức mạng (HTTP/REST).

Tính đồng bộ: Tương tác xảy ra ngay lập tức (Real-time) hay cần thời gian xử lý (Asynchronous).

2. Các Luồng Sự Kiện (Event Flows)

route

Để kiểm thử toàn diện, người kỹ sư QA không chỉ kiểm tra con đường suôn sẻ nhất. Một Use Case thực tế luôn bao gồm nhiều nhánh rẽ (Branches) khác nhau. Chúng được chia làm 3 loại luồng chính cần phải được thiết kế Test Case một cách nghiêm ngặt.

check_circle

2.1. Luồng Cơ Bản (Basic Flow / Happy Path)

Đây là kịch bản hoàn hảo nhất. Mọi thứ diễn ra chính xác như mong đợi, không có lỗi, không có ngoại lệ. Tác nhân cung cấp đúng dữ liệu, hệ thống xử lý trơn tru và trả về kết quả thành công.

Trường hợp áp dụng: Người dùng nhập đúng tên đăng nhập, đúng mật khẩu, mã OTP hợp lệ. Hệ thống cấp quyền truy cập ngay lập tức vào trang tổng quan (Dashboard).

Chiếm khoảng 20% số lượng Test Case nhưng phục vụ 80% thời gian sử dụng thực tế của người dùng bình thường.

alt_route

2.2. Luồng Thay Thế (Alternate Flow)

Đây là những con đường khác biệt so với luồng cơ bản nhưng vẫn dẫn đến việc hoàn thành mục tiêu của Use Case, hoặc chuyển hướng người dùng sang một mục tiêu hợp lệ khác một cách có chủ đích.

Trường hợp áp dụng: Người dùng quên mật khẩu. Thay vì đăng nhập bằng mật khẩu (luồng cơ bản), họ chọn luồng "Quên mật khẩu", nhận link xác thực qua email, đặt lại mật khẩu mới, sau đó mới đăng nhập thành công. Mục tiêu cuối cùng (truy cập hệ thống) vẫn đạt được qua một con đường khác.

Luồng thay thế kiểm tra tính linh hoạt của hệ thống, cung cấp nhiều tùy chọn trải nghiệm người dùng (UX) khác nhau.

error

2.3. Luồng Ngoại Lệ (Exception Flow)

Đây là kịch bản thất bại. Xảy ra khi có lỗi hệ thống, cấu hình sai, kết nối bị đứt, hoặc người dùng cố tình/vô tình nhập dữ liệu sai quy định khiến Use Case không thể hoàn thành.

Trường hợp áp dụng: Khách hàng đang thanh toán giỏ hàng nhưng thẻ tín dụng bị từ chối do hết tiền, hoặc máy chủ ngân hàng bị sập. Hệ thống phải ngắt luồng, hiển thị thông báo lỗi rõ ràng "Thanh toán thất bại do lỗi phía ngân hàng, vui lòng thử lại thẻ khác" thay vì crash ứng dụng.

Đây là khu vực quan trọng nhất để tìm ra Bug. Việc xử lý ngoại lệ tốt giúp ứng dụng không bị sập và giữ chân người dùng khỏi trải nghiệm tồi tệ.

format_list_numbered

3. Quy Trình Chuyên Nghiệp Thực Hiện Use Case Testing

Kiểm thử Use Case không phải là việc đọc tài liệu rồi "kiểm thử đại". Nó đòi hỏi một quy trình phân tích và thiết kế có hệ thống gồm 4 bước mang tính tuần tự, bắt buộc mọi kỹ sư QA phải tuân thủ.

1

3.1. Phân Tích & Xác Định Use Case

  • Thu thập tài liệu đặc tả yêu cầu (BRD - Business Requirement Document) hoặc User Stories.
  • Đọc hiểu toàn bộ tài liệu để xác định rõ ràng mục đích của từng tính năng.
  • Trích xuất danh sách tất cả các Use Case có trong tài liệu.
  • Vẽ lại sơ đồ Use Case (Use Case Diagram) nếu tài liệu chưa cung cấp để có cái nhìn trực quan về mối quan hệ giữa các Actor và Use Case.
2

3.2. Định Nghĩa Tác Nhân (Actors)

  • Lên danh sách mọi loại người dùng (Admin, User thường, Guest, Manager).
  • Liệt kê các hệ thống phần mềm bên thứ 3 (Third-party APIs) tham gia vào hệ thống (Cổng thanh toán, Hệ thống gửi Email, SMS Gateway).
  • Xác định quyền hạn (Permissions/Roles) của từng Actor. Điều này cực kỳ quan trọng vì hệ thống sẽ phản hồi khác nhau dựa trên quyền của Actor.
3

3.3. Viết Kịch Bản Luồng Chi Tiết

  • Phân rã mỗi Use Case thành các bước hành động cụ thể. (Ví dụ: Bước 1: Nhấn nút A. Bước 2: Hệ thống hiển thị B...).
  • Xác định các điều kiện tiên quyết (Pre-conditions) phải thỏa mãn trước khi bắt đầu (VD: Người dùng phải đang ở trạng thái đã đăng nhập).
  • Xác định hậu điều kiện (Post-conditions) sau khi kết thúc luồng.
  • Mô tả chi tiết Luồng Cơ Bản (Happy Path), mọi Luồng Thay Thế, và mọi Luồng Ngoại Lệ có thể xảy ra ở từng bước.
4

3.4. Thiết Kế & Thực Thi Test Case

  • Chuyển đổi từng Luồng Sự Kiện ở Bước 3 thành một hoặc nhiều Test Case cụ thể.
  • Gán dữ liệu kiểm thử (Test Data) thực tế vào các bước (Ví dụ: Thay vì "Nhập email", ghi rõ "Nhập email: test_error@gmail.com").
  • Thực thi chạy test trên hệ thống phần mềm (Execute).
  • So sánh kết quả thực tế (Actual Result) với kết quả mong đợi (Expected Result). Nếu khác nhau, tiến hành báo cáo lỗi (Log Bug).
science

4. Phân Tích Chuyên Sâu Các Ví Dụ Thực Tế

Việc hiểu lý thuyết là chưa đủ, dưới đây là việc bóc tách chi tiết kỹ thuật Use Case Testing thông qua 3 hệ thống cực kỳ phổ biến trong thực tế, với độ dài và độ phức tạp cao.

4.1. Hệ Thống Rút Tiền ATM Khách Hàng Cá Nhân

groups Tác nhân (Actors)

  • Actor Chính: Khách hàng (Người dùng thẻ ATM).
  • Actor Phụ 1: Hệ thống phần mềm của máy ATM (Giao diện người dùng phần cứng).
  • Actor Phụ 2: Hệ thống máy chủ ngân hàng (Xử lý giao dịch lõi - Core Banking).

rule Điều kiện tiên quyết (Pre-conditions)

  • Máy ATM đang ở trạng thái hoạt động (Online), không bảo trì.
  • Máy ATM còn đủ tiền mặt trong khay chứa và có đủ các loại mệnh giá cần thiết.
  • Đường truyền mạng nội bộ giữa ATM và Server Ngân Hàng ổn định.

Luồng Cơ Bản (Rút tiền thành công)

  1. Khách hàng đưa thẻ ATM vào khe đọc thẻ.
  2. Hệ thống ATM nhận diện thẻ và yêu cầu nhập ngôn ngữ (Tiếng Việt/Tiếng Anh).
  3. Khách hàng chọn ngôn ngữ. ATM yêu cầu nhập mã PIN bảo mật.
  4. Khách hàng nhập đúng mã PIN gồm 6 chữ số.
  5. ATM gửi mã PIN lên Server Ngân Hàng xác thực. Server trả về kết quả hợp lệ.
  6. ATM hiển thị menu chức năng. Khách hàng chọn chức năng "Rút Tiền".
  7. ATM yêu cầu nhập số tiền. Khách hàng nhập số tiền 1.000.000 VNĐ.
  8. ATM kiểm tra số dư và hạn mức. Server báo số dư đủ (Vd: 5.000.000 VNĐ) và hạn mức ngày chưa vượt.
  9. ATM nhả tiền ra khe, in biên lai (tùy chọn) và trả lại thẻ.
  10. Tài khoản khách hàng bị trừ 1.000.000 VNĐ (cộng phí nếu có). Hệ thống cập nhật số dư mới.

Các Luồng Thay Thế Tiêu Biểu

  • In biên lai: Khách hàng có thể chọn in biên lai hoặc không in. Hệ thống vẫn trả tiền thành công ở cả 2 trường hợp, chỉ khác ở hành động in giấy.
  • Chọn mệnh giá: Khách hàng không chọn số tiền có sẵn mà chọn "Số khác". Máy yêu cầu nhập số tiền là bội số của 50.000đ. Hệ thống vẫn tiếp tục luồng thành công.

Các Luồng Ngoại Lệ Phức Tạp (Bug thường xuất hiện ở đây)

  • Sai mã PIN: Khách hàng nhập sai mã PIN lần 1. Hệ thống cảnh báo "Sai mã PIN, còn 2 lần thử". Khách hàng nhập sai lần 3. Hệ thống phải nuốt thẻ ngay lập tức và hiển thị thông báo liên hệ tổng đài, kết thúc Use Case.
  • Số dư không đủ: Khách hàng muốn rút 10.000.000 VNĐ nhưng số dư chỉ có 5.000.000 VNĐ. Hệ thống từ chối yêu cầu, hiển thị lỗi "Số dư trong tài khoản không đủ để thực hiện giao dịch", và đưa về menu chính.
  • Lỗi mệnh giá: Khách hàng nhập số tiền 130.000 VNĐ. Hệ thống báo lỗi "Số tiền phải là bội số của 50.000 VNĐ".
  • Hết tiền trong máy: Khách hàng yêu cầu rút 5.000.000 VNĐ, tài khoản đủ tiền, nhưng máy ATM chỉ còn 2.000.000 VNĐ. Hệ thống phải kiểm tra khay tiền vật lý, báo lỗi "Máy ATM không đủ số lượng tiền mặt đáp ứng", từ chối giao dịch và tuyệt đối không trừ tiền tài khoản.
  • Mất mạng giữa chừng: Đang ở bước 8, mạng rớt. Hệ thống phải Timeout, hủy bỏ giao dịch (Rollback transaction), nhả thẻ ra và thông báo lỗi kết nối.

4.2. Hệ Thống Thanh Toán Giỏ Hàng Điện Tử (E-Commerce Checkout)

Mua sắm trực tuyến là quá trình phức tạp vì có sự tham gia của rất nhiều Actor phụ trợ. Việc kiểm thử Use Case thanh toán (Checkout) là ưu tiên số một của mọi hệ thống thương mại điện tử như Shopee, Tiki, Lazada.

shopping_cart Các Bước Luồng Cơ Bản

  1. Người dùng vào giỏ hàng, chọn các sản phẩm cần thanh toán.
  2. Hệ thống tính tổng tiền (Tiền hàng + Phí ship).
  3. Người dùng nhập địa chỉ giao hàng hợp lệ.
  4. Người dùng chọn phương thức thanh toán "Thẻ tín dụng".
  5. Hệ thống chuyển hướng sang cổng thanh toán đối tác (Ví dụ: Momo/ZaloPay/Stripe).
  6. Người dùng nhập thông tin thẻ hợp lệ và xác thực OTP thành công.
  7. Cổng thanh toán trả tín hiệu Thành Công về ứng dụng mua hàng.
  8. Hệ thống trừ kho hàng (Giảm số lượng tồn kho).
  9. Hệ thống tạo mã đơn hàng thành công và gửi Email/SMS xác nhận.

warning Phân Tích Luồng Ngoại Lệ

  • Hết hàng (Out of stock) phút chót: Ở bước 1, sản phẩm còn hàng. Nhưng đến bước 8 (sau khi thanh toán), sản phẩm vừa bị người khác mua hết. Hệ thống phải hoàn tiền (Refund) tự động và thông báo xin lỗi. Đội ngũ kiểm thử thường hay bỏ sót kịch bản Race Condition này.
  • Thanh toán treo: Người dùng nhập thẻ ở cổng thanh toán, nhưng tắt trình duyệt đột ngột không quay lại app. Hệ thống phải đánh dấu đơn hàng là "Chờ thanh toán" trong 15 phút, sau đó tự động hủy đơn (Cancel) và trả lại số lượng tồn kho.
  • Mã giảm giá hết hạn: Áp dụng mã lúc 23:59 hợp lệ, nhưng bấm nút thanh toán lúc 00:01 hôm sau (mã đã hết hạn). Hệ thống phải tính lại tổng tiền, loại bỏ mã giảm giá, hiển thị cảnh báo và yêu cầu người dùng xác nhận lại tổng tiền mới.

4.3. Quản Lý Đăng Nhập Nhân Viên (Hệ thống ERP Doanh nghiệp)

Khác với ứng dụng người dùng thông thường, hệ thống doanh nghiệp yêu cầu bảo mật cao, do đó Use Case đăng nhập thường chứa rất nhiều luồng phụ để đảm bảo an toàn thông tin nội bộ.

Danh sách các Test Case bắt buộc (Được chuyển đổi từ Use Case Flow)

  • Test Case 01 (Cơ bản): Nhập Username hợp lệ, Password hợp lệ -> Đăng nhập thành công, điều hướng vào Dashboard ERP.
  • Test Case 02 (Ngoại lệ): Nhập Username không tồn tại trong CSDL -> Báo lỗi chung chung "Thông tin đăng nhập không chính xác" (không báo riêng lỗi sai user để tránh lộ danh sách nhân viên).
  • Test Case 03 (Ngoại lệ): Nhập sai Password 5 lần liên tiếp -> Khóa tài khoản (Lockout) tạm thời trong 30 phút, hiển thị bộ đếm ngược. Ghi log cảnh báo bạo lực (Brute-force alert) cho Admin.
  • Test Case 04 (Luồng thay thế SSO): Người dùng không nhập User/Pass mà bấm nút "Login with Google Workspace" -> Chuyển hướng sang Google, xác thực OAuth2, tạo phiên đăng nhập thành công.
  • Test Case 05 (Luồng thay thế 2FA): Nhập đúng User/Pass nhưng hệ thống phát hiện đây là thiết bị mới (IP lạ). Kích hoạt luồng 2FA (Xác thực 2 yếu tố). Gửi mã 6 số qua ứng dụng Authenticator. Người dùng nhập đúng mã -> Đăng nhập thành công.
  • Test Case 06 (Ngoại lệ): Nhập mã 2FA đã hết hạn (sau 30 giây) -> Báo lỗi "Mã xác thực hết hạn, vui lòng lấy mã mới".
  • Test Case 07 (Bảo mật): Tài khoản đã bị quản trị viên Vô hiệu hóa (Deactivated) do nhân viên nghỉ việc -> Nhập đúng mật khẩu vẫn bị chặn ở ngoài màn hình Login kèm thông báo liên hệ bộ phận IT.
  • Test Case 08 (Bảo mật): Mật khẩu đã sử dụng quá 90 ngày -> Yêu cầu bắt buộc đổi mật khẩu mới (Mật khẩu phải chứa chữ hoa, số, ký tự đặc biệt) trước khi cho phép truy cập hệ thống.
thumb_up

5. Ưu Điểm Tuyệt Vời

  • check_circle

    Lấy Người Dùng Làm Trung Tâm (User-Centric)

    Hoàn toàn mô phỏng hành vi của người dùng thực. Điều này giúp phần mềm khi phát hành sát với nhu cầu thị trường, không chỉ đúng về code mà còn đúng về trải nghiệm (UX).

  • check_circle

    Phát Hiện Lỗi Tích Hợp Hệ Thống

    Một Use Case thường trải dài qua nhiều Module khác nhau (Ví dụ: Thêm vào giỏ -> Thanh toán -> Trừ kho -> Gửi Email). Nhờ đó, phương pháp này cực kỳ hiệu quả trong việc tìm ra lỗi kết nối (Integration Bugs) giữa các thành phần phần mềm.

  • check_circle

    Dễ Dàng Đọc Hiểu Cho Mọi Thành Viên

    Vì Use Case được viết bằng ngôn ngữ con người (thường là tiếng Anh hoặc ngôn ngữ bản địa), không dùng thuật ngữ code phức tạp, nên khách hàng (Client), nhà quản lý dự án (PM) và nhà phân tích nghiệp vụ (BA) đều có thể cùng đọc, đánh giá và đóng góp vào bộ Test Case.

  • check_circle

    Hiệu Quả Đối Với Hệ Thống Phức Tạp

    Quản lý được luồng nghiệp vụ lớn thông qua việc chia nhỏ thành các Use Case phụ. Giảm thiểu rủi ro bỏ sót chức năng trong quá trình kiểm thử phần mềm ngân hàng, y tế hay hàng không.

thumb_down

6. Nhược Điểm Cần Chú Ý

  • cancel

    Không Phủ Sóng Được Giá Trị Biên (Boundary Values)

    Use Case Testing tập trung vào luồng (Flow), không phải là mức độ chi tiết của dữ liệu. Việc nhập tuổi 17, 18, 19 sẽ không được mô tả kỹ trong Use Case. Nó cần được kết hợp với kỹ thuật Phân Tích Giá Trị Biên (Boundary Value Analysis) và Phân Vùng Tương Đương (Equivalence Partitioning).

  • cancel

    Không Dành Cho Kiểm Thử Giao Diện (GUI)

    Kịch bản chỉ nói "Người dùng nhấn nút Đăng ký". Nó hoàn toàn không quan tâm nút đó màu gì, nằm ở vị trí nào, có bị méo hay bị che khuất trên màn hình điện thoại nhỏ hay không. Cần các kỹ thuật UI Testing hỗ trợ thêm.

  • cancel

    Phụ Thuộc Quá Lớn Vào Tài Liệu

    Nếu người BA (Business Analyst) viết Use Case sơ sài, thiếu luồng ngoại lệ, QA sẽ tạo ra Test Case rất hời hợt. Chất lượng kiểm thử bị trói buộc hoàn toàn vào chất lượng của tài liệu yêu cầu ban đầu (Garbage In - Garbage Out).

  • cancel

    Bỏ Qua Kiểm Thử Phi Chức Năng (Non-functional)

    Việc hệ thống phản hồi trong 1 giây hay 10 giây (Performance), hệ thống có chịu tải được 10,000 người cùng lúc (Load Testing) hay không hoàn toàn nằm ngoài phạm vi của Use Case Testing.

workspace_premium

7. Tiêu Chuẩn Thực Hành (Best Practices)

Để triển khai Use Case Testing đạt hiệu quả cao nhất trong dự án thực tế, các chuyên gia kiểm thử (QA/QC/Testers) cần ghi nhớ nằm lòng 4 nguyên tắc vàng sau:

alt_route

Phủ Kín Ngoại Lệ

Đừng chỉ chăm chăm chạy Luồng Thành Công. Hơn 70% lỗi phần mềm (Bugs) nằm ở các kịch bản ngoại lệ, khi người dùng thao tác sai hoặc hệ thống gặp sự cố hạ tầng.

view_timeline

Truy Xuất Dấu Vết

Luôn duy trì Ma trận truy xuất yêu cầu (RTM - Requirement Traceability Matrix) để đảm bảo 100% Use Case trong tài liệu đã được chuyển đổi thành Test Case.

diversity_3

Review Chéo

Các Test Case tạo ra từ Use Case cần được Review chéo bởi các Developer và BA. Developer sẽ giúp chỉ ra các điểm phi logic về mặt hệ thống khó thực thi.

handshake

Kết Hợp Kỹ Thuật

Use Case Testing là kỹ thuật cấp cao (High-level). Phải luôn kết hợp nó với các kỹ thuật cấp thấp (Low-level) như bảng quyết định, chuyển đổi trạng thái để đảm bảo phần mềm hoàn hảo.

Công Thức Đánh Giá Mức Độ Bao Phủ (Coverage)

Sử dụng công thức toán học sau để tính toán tỷ lệ độ bao phủ của bộ kiểm thử so với hệ thống:

Test Coverage (%)=(Soˆˊ Use Case đa˜ được test thaˋnh coˆngTổng soˆˊ Use Case của hệ thoˆˊng)×100 \text{Test Coverage (\%)} = \left( \frac{\text{Số Use Case đã được test thành công}}{\text{Tổng số Use Case của hệ thống}} \right) \times 100

Mục tiêu của mọi dự án là đạt Test Coverage > 95% trước khi phát hành sản phẩm ra thị trường (Go-Live).

Nội dung thiết kế dựa trên các nguyên tắc chuẩn quốc tế về kiểm thử phần mềm.
Mục lục
1. Tổng Quan Về Use Case Testing
1.1. Các Thành Phần Cấu Trúc Bắt Buộc
2. Các Luồng Sự Kiện (Event Flows)
2.1. Luồng Cơ Bản (Basic Flow / Happy Path)
2.2. Luồng Thay Thế (Alternate Flow)
2.3. Luồng Ngoại Lệ (Exception Flow)
3. Quy Trình Chuyên Nghiệp Thực Hiện Use Case Testing
3.1. Phân Tích & Xác Định Use Case
3.2. Định Nghĩa Tác Nhân (Actors)
3.3. Viết Kịch Bản Luồng Chi Tiết
3.4. Thiết Kế & Thực Thi Test Case
4. Phân Tích Chuyên Sâu Các Ví Dụ Thực Tế
4.1. Hệ Thống Rút Tiền ATM Khách Hàng Cá Nhân
4.2. Hệ Thống Thanh Toán Giỏ Hàng Điện Tử (E-Commerce Checkout)
4.3. Quản Lý Đăng Nhập Nhân Viên (Hệ thống ERP Doanh nghiệp)
5. Ưu Điểm Tuyệt Vời
6. Nhược Điểm Cần Chú Ý
7. Tiêu Chuẩn Thực Hành (Best Practices)
Khoá học liên quan
Khóa học Tester: Lý thuyết Kiểm thử phần mềm cơ bản từ A-Z

2.371 xem 12 kiến thức 5 đề thi

Kiến thức tương tự
img
Lý thuyết Kiểm Thử: KT CD Trạng Thái (State Transition Test)

21.101 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: KT Cặp (Pairwise Testing)

21.151 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: KT Phân tích Giá trị Biên BVA

21.038 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử phần mềm: Quy trình & Vòng đời SDLC STLC

20.974 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử phần mềm: Các thuật ngữ quan trọng

20.945 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: PP phân vùng tương đương

21.069 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: Lập kế hoạch và chiến lược test

20.991 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: Test Case & Test Data

21.012 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử Phần mềm: Bảng quyết định Decision Table

21.093 lượt xem 11/04/2026