Use case diagram và lý do sử dụng trong kiểm thử phần mềm (P1)

Hế lô các bạn, là mình đây 😗 … Mình đã quay lại =)) Sau một vài lần phải tham gia vào dự án ở giai đoạn đang phát triển thì mình nhận ra Use case diagram hỗ trợ việc tiếp cận dự án và quá trình test rất nhiều. Bài viết này mình sẽ

Hế lô các bạn, là mình đây 😗 … Mình đã quay lại =))

Sau một vài lần phải tham gia vào dự án ở giai đoạn đang phát triển thì mình nhận ra Use case diagram hỗ trợ việc tiếp cận dự án và quá trình test rất nhiều. Bài viết này mình sẽ nói một chút về lý do nên sử dụng nó trong kiểm thử phần mềm nhé >.O

Tuy nhiên chắc sẽ nhắc lại 1 chút xem “Use case diagram” là gì nhỉ! Phòng trường hợp ai đó chưa biết hoặc lâu rồi không động đến xong quên xừ mất! >.<

1. Về Use case diagram

Use case diagram là một trong số các biểu đồ trong UML. Ai mà còn chưa nhớ UML là gì thì đọc lại ở đây nhó :3 → https://viblo.asia/p/phan-tich-thiet-ke-he-thong-thong-tin-su-dung-bieu-do-uml-phan-1-PjxMe6yNG4YL

Use case diagram: Biểu diễn sơ đồ chức năng của hệ thống. Mỗi use case mô tả chức năng mà hệ thống cần phải có xét từ góc độ người dùng.

Sự tương tác trong biểu đồ use case có thể là:

  • Cách thức mà người dùng tương tác với hệ thống
  • Cách thức mà hệ thống tương tác với các hệ thống khác

Ví dụ: Hệ thống quản lý thư viện

  • Admin: Đăng nhập vào hệ thống, thực hiện cập nhật thông tin và quản lý các giao dịch mượn, trả sách
  • Bạn đọc: Chỉ có thể tìm kiếm, tra cứu thông tin

image.png

2. Các thành phần của Use case diagram

Actor: Chỉ người dùng hoặc một đối tượng bên ngoài có khả năng tương tác với hệ thống.

Use case: Là các chức năng mà các actor sẽ sử dụng để thể hiện sự tương tác giữa những người dùng và hệ thống.

Communication link: Kết nối giữa Actor và Use case giúp thể hiện được sự tương tác giữa hệ thống và người dùng.

Boundary of system: Thể hiện phạm vi xảy ra của Use case

Relationships: Quan hệ trong Use case bao gồm 3 loại chính là: include, extend và generalization

  • Include: Là mqh bắt buộc phải có giữa các Use case với nhau.

    Xét về nghĩa: include nghĩa là bao gồm → tức là nếu nói: use case A có mqh include với use case B thì điều đó có nghĩa là Use case A bao gồm Use case B

    Ví dụ: image.png

  • Extend: Là mối quan hệ mở rộng giữa các use case với nhau.

    Nó thể hiện mqh có thể có hoặc không giữa các use case với nhau. Nếu use case A là extend của use case B thì use case A chỉ là một optional và chỉ xảy ra trong một hoàn cảnh cụ thể được xác định.
    image.png

  • Generalization: là mqh cha/con giữa các use case với nhau, nó được dùng để thể hiện mqh giữa các actor với nhau.

    Nhìn chung, generalization giúp thể hiện rõ hơn các yêu cầu bằng việc gom nhóm các use case lại theo quan hệ cha/con, và generaliozation có tính kế thừa: tức là thằng cha có gì thì thằng con sẽ có cái đó.

3. Các bước xây dựng Use case diagram

Bước 1: Tìm Actor

Trả lời các câu hỏi sau để tìm actor cho hệ thống:

  • Ai sẽ là người sử dụng các chức năng của hệ thống?
  • Ai cần sự hỗ trợ của hệ thống để thực hiện các công việc hàng ngày?
  • Ai cần bảo trì, quản trị và đảm bảo hệ thống hoạt động?
  • Hệ thống sẽ tương tác với các hệ thống nào khác?

Bước 2: Xác định các Use case

Trả lời cho câu hỏi các actor sử dụng chức năng gì trong hệ thống để từ đó xác định được các use case cần thiết cho hệ thống:

  • Actor cần chức năng nào từ hệ thống?
  • Actor cần phải xem, cập nhập hay lưu trữ thông tin gì trên hệ thống?
  • Actor cần thông báo cho hệ thống những sự kiện gì? Sự kiện đó đại diện cho chức năng nào?
  • HT có cần thông báo cho actor khi có sự thay đổi không?

Bước 3: Xác định mối quan hệ

Phân tích và xác định các quan loại hệ giữa các Actor và Use case; giữa các Actor với nhau; giữa các Use case với nhau → sau đó nối chúng lại chúng ta sẽ được bản vẽ Use case.

4. Các ứng dụng trong dự án

Một vài ứng dụng điển hình của Use case diagram trong dự án:

  • Phân tích và hiểu hệ thống
  • Thiết kế hệ thống
  • Làm cơ sở cho việc phát triển, kiểm tra các bản vẽ như Class Diagram, Activity Diagram, Sequence Diagram, Component Diagram
  • Làm cơ sở để giao tiếp với khách hàng, các nhà đầu tư
  • Giúp cho việc kiểm thử chức năng, kiểm thử chấp nhận

Bên trên là một vài thông tin tóm tắt về Use case diagram. Mình chỉ tóm tắt sơ lược, các bạn có thể đọc thêm để rõ hơn nha. >.O

Có bạn từng hỏi mình rằng: “Em thấy cái use case diagram này nó có khác gì bản đồ tư duy đâu?” Híc … thực tế là khác nhau đó các bạn 😄

  • Bản đồ tư duy: là mind map, nó đơn giản là mình liệt kê ra các ý hiểu, các idea hoặc function theo dạng sơ đồ cây.
  • Còn use case diagram: nó được vẽ dưới góc nhìn của user tương tác với hệ thống như thế nào; các hệ thống khác tương tác với hệ thống của mình như thế nào. Nó liên quan trực tiếp đến nghiệp vụ dự án.

Vậy CÂU HỎI đặt ra: Vì sao tester nên biết và ứng dụng Use case diagram trong kiểm thử phần mềm?

Oh … overview 1 chút lý thuyết vậy đã :<

Nội dung có vẻ hơi dài nên mọi người tìm hiểu tiếp phần 2 ở đây nha: ###Buồn ngủ quá nên chưa edit xong phần 2 :< , mình sẽ update link sớm nhất nha###

Nguồn: viblo.asia

Bài viết liên quan

Thay đổi Package Name của Android Studio dể dàng với plugin APR

Nếu bạn đang gặp khó khăn hoặc bế tắc trong việc thay đổi package name trong And

Lỗi không Update Meta_Value Khi thay thế hình ảnh cũ bằng hình ảnh mới trong WordPress

Mã dưới đây hoạt động tốt có 1 lỗi không update được postmeta ” meta_key=

Bài 1 – React Native DevOps các khái niệm và các cài đặt căn bản

Hướng dẫn setup jenkins agent để bắt đầu build mobile bằng jenkins cho devloper an t

Chuyển đổi từ monolith sang microservices qua ví dụ

1. Why microservices? Microservices là kiến trúc hệ thống phần mềm hướng dịch vụ,