Cập nhật nội dung chi tiết về Bản Vẽ Use Case (Use Case Diagram) mới nhất trên website Hanoisoundstuff.com. Hy vọng thông tin trong bài viết sẽ đáp ứng được nhu cầu ngoài mong đợi của bạn, chúng tôi sẽ làm việc thường xuyên để cập nhật nội dung mới nhằm giúp bạn nhận được thông tin nhanh chóng và chính xác nhất.
Trong bài trước chúng ta đã biết vai trò của bản vẽ Use Case là rất quan trọng, nó giúp chúng ta hiểu yêu cầu, kiến trúc chức năng của hệ thống và chi phối tất cả các bản vẽ còn lại. Trong bài này chúng ta sẽ tìm hiểu về các thành phần cấu tạo nên bản vẽ này, cách xây dựng và sử dụng nó.1. Các thành phần trong bản vẽ Use Case
Đầu tiên, chúng ta xem một ví dụ về Use Case Diagarm.
Bây giờ chúng ta sẽ tìm hiểu kỹ hơn về các thành phần của bản vẽ.
1.1 Actor
Actor được dùng để chỉ người sử dụng hoặc một đối tượng nào đó bên ngoài tương tác với hệ thống chúng ta đang xem xét. Lưu ý, chúng ta hay bỏ quên đối tượng tương tác với hệ thống, ví dụ như Bank ở trên.
Actor được biểu diễn như sau:
Use Case là chức năng mà các Actor sẽ sử dụng. Nó được ký hiệu như sau:
1.3 Relationship(Quan hệ)
Relationship hay còn gọi là conntector được sử dụng để kết nối giữa các đối tượng với nhau tạo nên bản vẽ Use Case. Có các kiểu quan hệ cơ bản sau:
– Association
– Generalization
– Include
– Extend
1.4 System Boundary
System Boundary được sử dụng để xác định phạm vi của hệ thống mà chúng ta đang thiết kế. Các đối tượng nằm ngoài hệ thống này có tương tác với hệ thống được xem là các Actor.
2. Các bước xây dựng Use Case Diagram
Chúng ta đã nắm được các ký hiệu của bản vẽ Use Case, bây giờ là lúc chúng ta tìm cách lắp chúng lại để tạo nên bản vẽ hoàn chỉnh. Thực hiện các bước sau để xây dựng một bản vẽ Use Case:
+ Bước 1: Tìm các Actor
Trả lời các câu hỏi sau để xác định Actor cho hệ thống:
– Ai sử dụng hệ thống này?
– Hệ thống nào tương tác với hệ thống này?
Xem xét ví dụ về ATM ở trên chúng ta thấy:
Như vậy có 03 Actor: Customer, ATM Technician và Bank
+ Bước 2: Tìm các Actor
Trả lời câu hỏi các Actor sử dụng chức năng gì trong hệ thống? chúng ta sẽ xác định được các Use Case cần thiết cho hệ thống.
Xem xét ví dụ ở trên ta thấy:
Customer sử dụng các chức năng: Check Balance, Deposit, Withdraw và Transfer
ATM technician sử dụng: Maintenance và Repair
Bank tương tác với tất cả các chức năng trên.
Tóm lại, chúng ta phải xây dựng hệ thống có các chức năng: Check Balance, Deposit, Withdraw, Transfer, Maintenance và Repair để đáp ứng được cho người sử dụng và các hệ thống tương tác.
+ Bước 3: Xác định các quan hệ
Phân tích và cá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.
Nhìn vào bản vẽ trên chúng ta nhận biết hệ thống cần những chức năng gì và ai sử dụng. Tuy nhiên, chúng ta chưa biết được chúng vận hành ra sao? Sử dụng chúng như thế nào? Để hiểu rõ hơn hệ thống chúng ta cần phải đặc tả các Use Case.
Có 2 cách để đặc tả Use Case.
Cách 1: Viết đặc tả cho các Use Case
Chúng ta có thể viết đặc tả Use Case theo mẫu sau:
Tên Use Case
Mã số Use Case
Mô tả tóm tắt// Hiển thị thông tin chi tiết của Account
Các bước thực hiện
Điều kiện thoát
Yêu cầu đặc biệt// Ghi rõ nếu có
Yêu cầu trước khi thực hiện// Phải đăng nhập
Điều kiện sau khi thực hiện
Cách 2: Sử dụng các bản vẽ để đặc tả
Chúng ta có thể dùng các bản vẽ như Activity Diagram, Sequence Diagram để đặc tả Use case. Các bản vẽ này chúng ta sẽ bàn ở những bài tiếp theo.
4. Sử dụng UseCase Diagram
– 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.
5. Kết luận
Đến đây, chúng ta đã tìm hiểu được bản vẽ đầu tiên và rất quan trọng (use case diagram), các bạn cần tiếp tục thực hành để nắm rõ hơn về bản vẽ này cũng như cách xây dựng và sử dụng chúng trong quá trình phát triển sản phẩm phần mềm.
Để giúp các bạn hiểu rõ hơn về bản vẽ Use Case trong bài tiếp theo chúng ta sẽ thực hiện qua từng bước bài thực hành xây dựng Use Case Diagram.
Bài tiếp: Thực hành xây dựng bản vẽ Use Case
Bài trước: Cơ bản về phân tích và thiết kế hướng đối tượng
User Story Và Use Case
Các lập trình viên thường có thói quen đi vào dự án và bắt đầu lập trình ngay. Họ nói với người dùng của mình rằng: “Tôi biết tất cả những gì mà bạn cần” khi nghe người dùng nói về yêu cầu của họ.
Những phương pháp Agile chỉ ra rằng đó là một cái bẫy cho các lập trình viên. Agile cũng cho thấy những nhà phát triển phải làm việc với người dùng trong suốt dự án để hiểu người dùng cần gì nếu muốn tránh bẫy lỗi lập trình.
Đó là lý do tại sao User Story là một trong những công cụ tốt nhất để triển khai theo phương pháp Agile.
1. User Story là gì?
Khái niệm User Story
User Story còn được một số người gọi với cái tên là Scenario (kịch bản) để mô tả một yêu cầu từ người dùng.
Hầu hết User Story được viết bằng ngôn ngữ của người dùng. Vì thế, bất kì người dùng nào cũng có thể đọc và hiểu ngay. User story thường gần gũi với từ ngữ thường ngày của người dùng.
User Story thường được viết trên Card, giấy note, tài liệu Words, Excels… tùy dự án.
2. Use Case là gì?
Khái niệm Use Case
Use case cũng có vài điểm gần giống như một User Story nhưng nó sẽ mô tả cách tương tác giữa người dùng và phần mềm. Use Case là một mô tả đầy đủ về tất cả những trường hợp mà người dùng sử dụng phần mềm sẽ gặp phải.
Qua đó, giúp người lập trình nắm bắt những cách giúp người dùng tương tác với phần mềm để đạt kết quả mong muốn. Đồng thời, loại bỏ những thao tác sai khiến người dùng không đạt kết quả khi sử dụng phần mềm.
3. Sự giống và khác nhau giữa User Story và Use Case
3.1 Giống nhau:
Các User Story thường được bắt đầu giống như các Use Case. Mỗi User Story sẽ mô tả một cách sử dụng phần mềm, tập trung vào kết quả và đều được viết bằng ngôn ngữ người dùng.
Cả User Story và Use Case đều sử dụng ngôn ngữ tự nhiên của của doanh nghiệp và chỉ kể một phần chứ không phải tất cả.
3.2 Khác nhau:
Mặc dù User Story và Use Case được định nghĩa khá giống nhau chúng vẫn có những khác biệt. Đảm nhận những vai trò khác nhau trong một dự án phần mềm và giúp dự án được vận hành tốt hơn.
“Tính năng tìm kiếm và thay thế trong trình soạn thảo văn bản”
Hãy so sánh một User Story cho chức năng tìm kiếm và thay thế bằng một Use Case với cùng tính năng sẽ giúp bạn hiểu được sự khác nhau.
Không khó để tìm ra User Story cho ví dụ trên. Có rất nhiều cách để tìm ra User Story bạn có thể bắt đầu bằng cách viết ra một tấm thẻ (card) như sau:
Ví dụ về chức năng tìm kiếm và thay thế User Story (Serch and Replace)
Bây giờ, nếu bạn không quen với User Story, bạn có thể nghĩ rằng: “chức năng tìm kiếm và thay thế trong trình soạn thảo của tôi cần nhiều hơn thế”.Thông thường User Story sẽ không đủ thông tin để giúp người dùng hiểu được phần mềm sẽ cần gì.
Còn đây là ví dụ về Use Case để bạn có thể hiểu được cách mà Use Case hoạt động:
Nếu tôi là một nhà phát triển và đang xây dựng một trình soạn thảo, tôi có thể viết một chức năng tìm kiếm và thay thế theo một Use Case cụ thể như trên.
Một vài điểm thú vị của Use Case đó là trong khi bạn đọc về ví dụ trên hẳn bạn đang nghĩ về thứ gì đó giống như khung tìm kiếm và thay thế (Replace dialog) trong Notepad hoặc Microsoft Word.
Chức năng tìm kiếm và thay thế của Microsoft Word
Và có rất nhiều cách khác nhau để bạn xây dựng phần mềm để thực hiện Use Case. Bạn đã từng sử dụng chức năng tìm kiếm và thay thế trong Word hoặc Notepad chưa? Chúng có gì khác nhau?
Chức năng tìm kiếm và thay thế của Notepad++
Có rất nhiều điểm khác biệt giữa chúng về giao diện, cách sử dụng… Tuy nhiên, nếu bạn so sánh chúng với Use Case trong ví dụ trên, bạn sẽ thấy rằng chúng đều đi theo cùng diễn biến của những sự kiện cơ bản.
User Story là những gì cần thiết:
User Story thường được viết trên Cards
Khi bạn viết một User Story, những gì bạn mô tả là nhu cầu của người dùng. Một điều gì đó mà người dùng cần để thực hiện công việc của họ mà nếu bạn không tạo ra phần mềm cho họ thì điều đó sẽ tồn tại mãi.
Chẳng hạn trong ví dụ trên là chức năng tìm kiếm và thay thế. Nếu không có phần mềm người dùng sẽ phải tìm và thay thế một cách thủ công, mất nhiều thời gian và không hiệu quả.
Use Case là cách mà phần mềm sẽ tương tác đối với yêu cầu của người dùng:
Một nhà phát triển phần mềm cần khả năng đọc một Use Case và hiểu phần mềm cần làm gì. Có rất nhiều chi tiết và mô tả mọi thứ mà người phát triển cần xây dựng để đáp ứng nhu cầu người dùng.
Đó là lý do tại sao Use Case cần được chi tiết, rõ ràng và không mơ hồ. Bạn có thể thấy Use Case trong ví dụ trên được viết chi tiết từng bước thao tác người dùng và cách mà phần mềm phản hồi.
User Story phải dễ đọc và hiểu đối với người dùng:
Cấu trúc thường có của 1 user story
Khi bạn viết một User Story, điều bạn cần tập trung là làm cách nào để bất kì ai cũng có thể đọc hiểu. User Story cần được mô tả một cách đầy đủ trong vài câu, đó là lý do vì sao User Story thường là một bảng tóm tắt và được viết trong những tấm thẻ, giấy note, ghi chú…
Use Case sẽ mô tả một đầy đủ về cách phần mềm tương tác với người dùng:
Khi bạn lên danh sách các Use Case, điều bạn cần làm chính là đưa ra một giải pháp về chức năng phần mềm cho nhu cầu của người dùng. Nó phải là một giải pháp mà những người phát triển có thể triển khai khi xây dựng phần mềm.
Một User Story có thể có nhiều Use Case và khi bạn tập hợp tất cả Use Case vào một tài liệu. Lúc đó, bạn sẽ có một tập hợp đầy đủ mô tả những tương tác giữa người dùng với phần mềm mà bạn sẽ làm.
Và nếu phần mềm của bạn phải tương tác với nhiều hệ thống, bạn có thể xem các hệ thống như là những người dùng trong Use Case.
Để hiểu rõ hơn về user story và use case trong quá trình sử dụng bạn có thể tham gia khóa đào tạo phân tích nghiệp vụ phần mềm của BAC. Nguồn:
Tham khảo bài viết: Phân biệt User Scenirio, User Story và Use Case
CÁC KHOÁ HỌC BUSINESS ANALYST chúng tôi DÀNH CHO BẠN
Khoá học Online:
Khoá học Offline:
Tại Tp.HCM:
Tại Hà Nội:
Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.
BAN BIÊN TẬP NỘI DUNG BAC
Viết Đặc Tả Use Case Sao Đơn Giản Nhưng Hiệu Quả?
Ô kayyyy lét xờ gâuuuu 😎
Giả dụ trường hợp ở đây: Anh em đã có Use Case Diagram, đã capture được tổng quan các requirement theo góc nhìn của người dùng. Đó là thứ để chúng ta bỏ vào các document như FRD hoặc SRS.
Tuy nhiên, Use Case Diagram khá là chung chung để các stakeholders có cái nhìn trực quan về những requirements được mô tả. Do đó, anh em cần phải diễn đạt nó một cách chi tiết hơn nữa.
Use Case Specification, hay nói cách khác là ĐẶC TẢ USE CASE sẽ giúp anh em làm chuyện đó.
Đặc tả Use Case tồn tại dưới dạng một cái bảng ghi chú. Nó mô tả tất tần tật các thông tin về Use Case, giúp anh em đọc vào một phát là hiểu ngay Use Case Diagram nó vẽ vậy là ý gì.
Một cách tổng quan, Use Case Specification gồm 3 thành phần chính:
Use Case Name: Tên Use Case
Use Case ID: Mã Use Case
Use Case Description: Tóm gọn nhanh sự tương tác được thể hiện trong Use Case là gì.
Actor: Những đối tượng thực hiện sự tương tác trong Use Case.
Priority: Mức độ ưu tiên của Use Case so với các Use Case còn lại trong dự án.
Trigger: Điều kiện kích hoạt Use Case xảy ra.
Pre-Condition: Điều kiện cần để Use Case thực hiện thành công.
Post-Condition: Những thứ sẽ xuất hiện sau khi Use Case được thực hiện thành công.
Basic Flow: luồng tương tác CHÍNH giữa các Actor và System để Use Case thực hiện thành công.
Alternative Flow: luồng tương tác THAY THẾ giữa các Actor và System để Use Case thực hiện thành công.
Exception Flow: luồng tương tác giữa các Actor và System mà Use Case thực hiện thất bại.
Business Rule: các quy định về mặt Business mà hệ thống bắt buộc phải nghe theo, làm theo.
Non-Funtional Requirement: Vì Use Case chỉ dùng để thể hiện Functional Requirement, nên anh em phải bổ sung các yêu cầu về Non-Functional ở đây luôn.
…………………………………………………………………..
Một số thông tin bổ sung thêm cho anh em.
Use Case Description chỉ cần mô tả ngắn gọn theo cú pháp của User Story: Là “Actor”, tui muốn làm “Use Case Name”, để đạt được “mục đích – lý do” gì đó. Đẹp là không quá 3 dòng cho phần tóm gọn Use Case này.
Ví dụ đối với diễn đàn Medium đi chẳng hạn. Chúng ta sẽ vẽ Use Case Diagram và viết đặc tả Use Case cho phân hệ quản lý xác thực người dùng như sau.
USE CASE SPECIFICATION
Pre-Condition(s):
Tài khoản người dùng đã được tạo sẵn
Tài khoản người dùng đã được phân quyền
Thiết bị của người dùng đã được kết nối internet khi thực hiện đăng nhập
Post-Condition(s):
Người dùng đăng nhập ứng dụng thành công
Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.
Basic Flow1. Người dùng truy cập ứng dụng Medium.
2. Người dùng chọn phương thức đăng nhập bằng tài khoản Medium
3. Người dùng nhập tài khoản Medium và chọn lệnh đăng nhập
4. Hệ thống xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng
5. Hệ thống ghi nhận hoạt động đăng nhập thành công vào Activity Log.
Alternative Flow2a. Người dùng chọn phương thức đăng nhập bằng tài khoản Gmail
2a1. Hệ thống chuyển sang màn hình đăng nhập của Google
3a. Người dùng nhập tài khoản Google và chọn lệnh đăng nhập
4a. Google xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng
Use Case tiếp tục bước 5.
2b. Người dùng chọn phương thức đăng nhập bằng tài khoản Facebook
2b1. Hệ thống chuyển sang màn hình đăng nhập của Facebook
3b. Người dùng nhập tài khoản Facebook và chọn lệnh đăng nhập
4b. Facebook xác thực thông tin đăng nhập thành công và cho phép người dùng truy cập ứng dụng
Use Case tiếp tục bước 5. Exception Flow
4c. Hệ thống xác thực thông tin đăng nhập không thành công và hiển thị thông báo.
4c1. Người dùng chọn lệnh hủy đăng nhập.Use Case dừng lại.
4c2. Người dùng chọn lệnh lấy lại mật khẩuUse Case tiếp tục Use Case UC1-3
4c3. Người dùng chọn lệnh khóa tài khoảnUse Case tiếp tục Use Case UC1-4
Non-Functional RequirementNFR1.1-1: Time out cho màn hình đăng nhập dưới 60 giây.
NFR1.1-2: Mật khẩu của người dùng phải được hash bằng MD5.
Đó là đặc tả Use Case. Hi vọng ví dụ này đủ để anh em hình dung, mường tượng ra được chân tay mặt mũi của Use Case Specification.
Anh em có thể làm một Use Case Specification cho một Use Case (tức một hình Oval). Vậy ở ví dụ trên thì anh em sẽ có 1 sơ đồ Use Case Digram, gồm 5 Use Case, thì sẽ ứng với 5 Use Case Specification.
Tuy nhiên, có thể anh em sẽ thấy confuse ở một số chỗ…
Thường khi làm đặc tả Use Case mình sẽ rất dễ bị nhầm lẫn ở hai chỗ:
Trigger và Pre-Condition
Alternative Flow và Exception Flow.
4.1. Trigger và Pre-Condition
Trigger nghĩa là một thứ gì đó để kích hoạt cho Use Case chạy, khởi xướng cho Use Case chạy. Còn Pre-Condition nghĩa là một thứ gì đó, mà phải có nó thì Use Case mới chạy được.
Use Case có thể có Pre-Condition hoặc không, nhưng Trigger thì thường phải có.
Ví dụ Use Case rút tiền tại máy ATM.
Tức Use Case chỉ xảy ra khi ông khách hàng này ổng thực hiện lệnh rút tiền. Cụ thể thì có thể là ổng bấm cái nút “Rút tiền” trên màn hình. Đó là trigger để Use Case xảy ra.
Còn Pre-Condition là các điều kiện cần phải có để ông này ổng rút tiền thành công. Vì ổng không thể nào rút tiền được nếu trong tài khoản không còn tiện hoặc ổng chưa đút thẻ vô máy.
Hoặc Output (hoặc Post-Condition) của Use Case này có thể là trigger của Use Case khác.
Cũng ở ví dụ rút tiền tại máy ATM bên trên, Post-Condition ở đây có thể là:
Khách hàng nhận được tiền mặt sau khi thực hiện rút tiền.
Số dư của khách hàng đã bị trừ đi khoảng tiền đã rút.
Nếu những post-conditions này xảy ra thì Use Case: Rút tiền tại máy ATM đã được thực hiện xong. Và đồng thời nó cũng là trigger cho Use Case tiếp theo: Gửi tin nhắn SMS thông báo cho khách hàng.
…
Để phân biệt rõ hơn giữa Trigger và Pre-Condition thì anh em cứ tưởng tượng như thế này…
Trong giải điền kinh xóm chiếu mở rộng, ông Tèo là trọng tài, ông Tủn là vận động viên thi đấu. Cả 2 ông này đều là Actor. Một ông là Actor ở vai trò trọng tài, còn một ông là Actor ở vai trò vận động viên tham dự.
Use Case thì thể hiện sự tương tác của Actor trong một môi trường/ phạm vi cụ thể nào đó. Vậy ở đây, Use Case thể hiện sự tương tác chạy đua trong một giải điền kinh, mà cả Actor trọng tài và Actor vận động viên đều tham gia vào.
Vậy thì đâu là Trigger, và đâu là Pre-Condition?
Trigger chính là cò nổ của ông Tèo trọng tài. Ổng giơ súng lên trời, bắn cái đùng, là ông Tủn vận động viên bắt đầu chạy. Hay nói cách khác, khi cò nổ, thì là lúc Use Case bắt đầu.
Còn Pre-Condition là những điều kiện tiên quyết mà ông Tủn phải ô kê hết thì mới cho ổng tham dự giải đấu, ví dụ:
Ví dụ vậy, không đạt được những điều kiện này, ông Tủn không được phép tham gia chạy ở giải điền kinh xóm chiếu mở rộng. Hay nói cách khác, không đạt được những điều kiện này, Use Case sẽ không được thực hiện thành công.
Đó là sự khác biệt giữa Trigger và Pre-Condition.
Tuy nhiên thực tế thì anh em cũng không cần quá quan tâm vấn đề này làm gì. Trigger trong Use Case có thể là bất kỳ thứ gì, có thể là tác động từ phía người dùng, hoặc tác động từ chính hệ thống. Miễn nó thể hiện được hình ảnh cò nổ để Use Case chạy là được.
4.2. Alternative Flow và Exception Flow
Flow là các luồng tương tác giữa các Actor và hệ thống với nhau. Basic Flow là luồng tương tác chính, là happy case đơn giản nhất có thể xảy ra.
Ví dụ chạy từ Quận 1 ra Quận 7 thì cứ men theo Cách Mạng Tháng 8 ra Hoàng Diệu, rồi cứ cắm đầu Nguyễn Văn Linh là ra. Đó chính là Basic Flow, là đường ngắn nhất, cơ bản nhất.
Nhưng thực tế còn rất nhiều đường khác mà anh em có thể đi: như quẹo qua Quận 8, đi Võ Văn Kiệt, Phạm Thế Hiển…. Hoặc thậm chí đi giữa đường xe bị lủng bánh, không có chỗ vá, phải dắt bộ ngược zề, và không qua được Quận 7 nữa, chuyến đi thất bại.
Những trường hợp đó mình sẽ gom hết lại, và quy nó thành Alternative Flow hoặc Exception Flow. Cụ thể:
Alternative Flow: những hướng khác giúp anh em đi từ Quận 1 tới Quận 7 thành công, như các tuyến đường khác chẳng hạn.
Exception Flow: những trường hợp mà nó ngăn chặn, khiến cho anh em không qua Quận 7 được, làm kế hoạch qua Quận 7 mình bị thất bại, như: lủng xe, hết xăng, bị công an giam xe…
Vậy xét qua lăng kính Use Case, đặc tính của 3 luồng tương tác này như sau:
…
Ví dụ trong mô hình quản lý e-Learning, anh em có một Use Case: Hủy kích hoạt tài khoản học viên chẳng hạn. Use Case này sẽ có các Flow như sau.
Admin mở tài khoản học viên cần hủy kích hoạt
Hệ thống hiển thị màn hình thông tin học viên
Admin chọn lệnh hủy kích hoạt
Hệ thống yêu cầu nhập mã OTP để xác nhận
Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt
Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt
Hệ thống hiển thị thông báo đã hủy kích hoạt.
1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên.Use Case tiếp tục bước 3.
4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha
4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận
5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt
6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạtUse Case tiếp tục bước 7.
5b. Admin nhập sai mã reCaptcha.
5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
5c. Admin nhập sai mã OTP.
5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
Đối với luồng chính (Basic Flow), anh em sẽ đánh số thứ tự xuất hiện 1, 2, 3, 4, 5…., theo số nguyên. Còn đối với Alternative hay Exception Flow, anh em nên thêm các ký tự chữ cái a, b, c, d… bên cạnh để làm dấu cho dễ phân biệt.
Và để dễ hình dung và quản lý các steps có trong flow hơn, mình sẽ bonus thêm cho anh em phần sau đây, kaka 😎
4.3. Bonus: Mô tả Flow sao cho ngầu
Mình cá là 69% anh em lần đầu viết flow cho use case sẽ thấy hơi… rối bời, và không biết tổ chức các steps sao cho logic hết.
Để giải quyết vấn đề này, hãy vẽ nó. Một lần nữa, việc vẽ lên ngôi.
Dùng chữ khó quá thì chúng ta phải dùng hình. Anh em sẽ thể hiện Basic Flow, Alternative Flow và Exception Flow kèm hình vẽ như sau.
BASIC FLOW
1. Admin mở tài khoản học viên cần hủy kích hoạt
2. Hệ thống hiển thị màn hình thông tin học viên
3. Admin chọn lệnh hủy kích hoạt
4. Hệ thống yêu cầu nhập mã OTP để xác nhận
5. Admin nhập đúng mã OTP để xác nhận lệnh hủy kích hoạt
6. Hệ thống kiểm tra mã OTP và tiến hành hủy kích hoạt
7. Hệ thống hiển thị thông báo đã hủy kích hoạt.
ALTERNATIVE FLOW
1a. Admin chọn học viên cần hủy kích hoạt ở lưới học viên.Use Case tiếp tục bước 3.
4a. Admin chọn phương thức xác nhận khác: Xác nhận qua reCaptcha
4a1. Hệ thống hiển thị mã reCaptcha và yêu cầu nhập mã reCaptcha để xác nhận
5a. Admin nhập đúng mã reCaptcha để xác nhận lệnh hủy kích hoạt
6a. Hệ thống kiểm tra mã reCaptcha và tiến hành hủy kích hoạtUse Case tiếp tục bước 7.
EXCEPTION FLOW
5b. Admin nhập sai mã reCaptcha.
5b1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
5c. Admin nhập sai mã OTP.
5c1. Hệ thống báo lỗi và hủy bỏ lệnh hủy kích hoạt học viên.Use Case dừng lại.
Đó là những gì mình dùng để mô tả Flow, một cách rõ ràng, logic và sáng sủa nhất có thể.
Các step ở Basic Flow, Alternative Flow hay Exception Flow nó đều đối xứng với nhau, thể hiện rõ thằng nào là thay thế của thằng nào, và thằng nào là Exception của thằng nào.
Riêng luồng tương tác nào Exception thì anh em để dạng nét đứt cho dễ phân biệt.
Các step bắt đầu (có thể là Trigger hoặc không) và kết thúc anh em hãy tô màu đen, để các Stakeholder có thể nắm được độ phức tạp của Use Case một cách nhanh nhất.
Còn đối với các Exception Flow – những flow làm fail Use Case, anh em hãy tô đỏ các step cuối cùng mà Use Case xảy ra không thành công (chẳng hạn step 5b1 hoặc 5c1).
.
.
.
TÓM GỌN
Đặc tả Use Case về bản chất rất đơn giản vì nó mang ngôn ngữ tự nhiên của người dùng. Vấn đề chỉ nằm ở một số điểm hay nhầm lẫn và cách chúng ta tổ chức các Use Case như thế nào cho logic và hiệu quả mà thôi 🙂
Mình sẽ tóm gọn giá trị của Use Case (cả Diagram và Specification) qua 2 bài notes về Use Case như sau:
Use Case giúp anh em thể hiện được rõ Requirement theo góc nhìn của người dùng cuối (rất quan trọng, vì nó giúp mình hiểu rõ bản chất vấn đề hơn).
Theo đó, những gì được thể hiện trong Use Case rất tự nhiên, ai đọc vô cũng hiểu hết trơn.
Use Case có thể chia nhỏ phạm vi theo nhiều phân hệ, hoặc cụm tính năng. Và nó cũng có thể nhìn dưới góc độ high-level. Do đó, dễ hơn cho mình rất nhiều để cover đủ các yêu cầu trong một dự án lớn.
Use Case là bước đệm tuyệt vời giữa việc mô tả tổng quát và mô tả chi tiết sự tương tác thông qua Sequence Diagram (con nhà UML).
Use Case được dùng để tạo các Epic, và các User Stories trong dự án Scrum, làm mọi thứ được nhất quán và rất chặt chẽ.
Use Case còn được dùng để tạo các Test Case sau này.
…
Bái bai và hẹn gặp lại 😎
Mobile Apps Testing: Mẫu Test Case &Amp; Kịch Bản Kiểm Thử
Câu hỏi thường gặp mà tôi cũng đã thắc mắc là “Cách kiểm thử App dành cho thiết bị di động?” Trong hướng dẫn này, tôi cung cấp Mẫu kiểm thử, Kịch bản / Các trường hợp kiểm tra để thử nghiệm một ứng dụng di động.
Bạn có thể thực hiện một số hoặc tất cả các Test Cases dựa trên các yêu cầu thử nghiệm trên thiết bị di động của bạn. Các test cases được tổ chức dựa trên các loại thử nghiệm trên thiết bị di động.
Functional Testing Test Cases
Loại ứng dụng dựa trên việc sử dụng chức năng kinh doanh (ngân hàng, chơi game, xã hội hoặc kinh doanh)
Loại đối tượng mục tiêu (người tiêu dùng, doanh nghiệp, giáo dục)
Kênh phân phối được sử dụng để truyền bá ứng dụng (ví dụ: Apple App Store, Google play, phân phối trực tiếp)
Các kịch bản thử nghiệm cơ bản nhất trong thử nghiệm chức năng có thể được coi là:
Để xác nhận xem tất cả các trường bắt buộc bắt buộc có đang hoạt động theo yêu cầu hay không.
Để xác nhận rằng các trường bắt buộc được hiển thị trên màn hình theo cách đặc biệt hơn các trường không bắt buộc.
Để xác nhận xem ứng dụng có hoạt động theo yêu cầu bất cứ khi nào ứng dụng bắt đầu / dừng lại hay không.
Để xác nhận xem ứng dụng có chuyển sang chế độ thu nhỏ bất cứ khi nào có cuộc gọi đến không. Để xác nhận điều tương tự, chúng ta cần sử dụng điện thoại thứ hai để gọi điện thoại.
Để xác nhận xem điện thoại có thể lưu trữ, xử lý và nhận SMS bất cứ khi nào ứng dụng đang chạy hay không. Để xác nhận tương tự, chúng ta cần phải sử dụng một điện thoại thứ hai để gửi sms đến thiết bị đang được thử nghiệm và nơi ứng dụng đang thử nghiệm hiện đang chạy.
Để xác thực rằng thiết bị có thể thực hiện các yêu cầu đa nhiệm bất cứ khi nào cần thiết.
Để xác nhận rằng ứng dụng cho phép các tùy chọn mạng xã hội cần thiết như chia sẻ, đăng và điều hướng, v.v.
Để xác nhận rằng ứng dụng hỗ trợ bất kỳ giao dịch cổng thanh toán nào như Visa, Mastercard, Paypal, vv theo yêu cầu của ứng dụng.
Để xác thực rằng các tình huống cuộn trang đang được kích hoạt trong ứng dụng khi cần thiết.
Để xác nhận rằng các lỗi cắt ngắn là hoàn toàn nằm trong khẳ năng giải quyết.
Để xác thực rằng người dùng nhận được thông báo lỗi thích hợp như “Lỗi mạng. Hãy thử sau một thời gian “bất cứ khi nào có bất kỳ lỗi mạng nào.
Để xác thực rằng ứng dụng đã cài đặt cho phép các ứng dụng khác thực hiện thỏa đáng, và nó không ăn vào bộ nhớ của các ứng dụng khác.
Để xác thực rằng ứng dụng sẽ tiếp tục hoạt động sau cùng trong trường hợp khởi động lại hoặc hỏng hệ thống.
Để xác nhận xem việc cài đặt ứng dụng có thể được thực hiện trơn tru miễn là người dùng có các tài nguyên cần thiết và nó không dẫn đến bất kỳ lỗi đáng kể nào.
Để xác nhận rằng ứng dụng thực hiện cơ sở khởi động tự động theo các yêu cầu.
Để xác thực xem ứng dụng có thực hiện theo yêu cầu trong tất cả các phiên bản của thiết bị di động là 2g, 3g và 4g hay không.
Để thực hiện Kiểm tra hồi quy để phát hiện các lỗi phần mềm mới trong các khu vực hiện có của một hệ thống sau khi đã thực hiện các thay đổi đối với chúng. Cũng chạy lại các kiểm tra đã thực hiện trước đó để xác định rằng hành vi của chương trình đã không thay đổi do các thay đổi.
Để xác nhận xem ứng dụng có cung cấp hướng dẫn sử dụng có sẵn cho những người không quen thuộc với ứng dụng hay không.
Performance Testing Test Cases
Loại mục tiêu cơ bản của thử nghiệm này là đảm bảo rằng ứng dụng thực hiện chấp nhận được theo các yêu cầu hiệu suất nhất định như quyền truy cập của một số lượng lớn người dùng hoặc loại bỏ phần cơ sở hạ tầng quan trọng như máy chủ cơ sở dữ liệu.
Các kịch bản thử nghiệm chung cho Kiểm tra hiệu suất trong ứng dụng dành cho thiết bị di động là:
Để xác định xem ứng dụng có thực hiện theo yêu cầu trong các điều kiện tải khác nhau hay không.
Để xác định xem mức độ phủ sóng của mạng hiện tại có thể hỗ trợ ứng dụng ở mức cao nhất, trung bình và tối thiểu hay không.
Để xác định xem thiết lập cấu hình máy khách-máy chủ hiện có có cung cấp mức hiệu suất tối ưu được yêu cầu không.
Để xác định các tắc nghẽn ứng dụng và cơ sở hạ tầng khác nhau ngăn cản ứng dụng thực hiện ở các mức chấp nhận được yêu cầu.
Để xác nhận xem thời gian phản hồi của ứng dụng có đúng với các yêu cầu không.
Để đánh giá sản phẩm và / hoặc phần cứng để xác định xem nó có thể xử lý khối lượng tải dự kiến hay không.
Để đánh giá liệu tuổi thọ pin có thể hỗ trợ ứng dụng thực hiện theo khối lượng tải dự kiến hay không.
Để xác nhận hiệu suất ứng dụng khi mạng được chuyển thành WIFI từ 2G / 3G hoặc ngược lại.
Để xác nhận mỗi chu kỳ CPU được yêu cầu là tối ưu hóa
Để xác nhận rằng mức tiêu thụ pin, rò rỉ bộ nhớ, tài nguyên như GPS, hiệu suất Máy ảnh cũng nằm trong các hướng dẫn bắt buộc.
Để xác nhận tuổi thọ của ứng dụng bất cứ khi nào người dùng tải nghiêm ngặt.
Để xác thực hiệu suất mạng trong khi di chuyển xung quanh với thiết bị.
Để xác nhận hiệu suất của ứng dụng khi chỉ cần có các giai đoạn kết nối liên tục.
Security Testing Test Cases
Mục tiêu cơ bản của kiểm tra bảo mật là đảm bảo rằng các yêu cầu về bảo mật mạng và dữ liệu của ứng dụng được đáp ứng theo các nguyên tắc.
Để xác thực rằng ứng dụng có thể chịu được bất kỳ tấn công bạo lực nào, đó là quá trình thử nghiệm và lỗi tự động được sử dụng để đoán tên người dùng, mật khẩu hoặc số thẻ tín dụng của một người.
Để xác nhận xem một ứng dụng có cho phép kẻ tấn công truy cập vào nội dung nhạy cảm hoặc chức năng mà không cần xác thực thích hợp hay không.
Để xác thực rằng ứng dụng có hệ thống bảo vệ mật khẩu mạnh và không cho phép kẻ tấn công lấy, thay đổi hoặc khôi phục mật khẩu của người dùng khác.
Để xác nhận rằng ứng dụng không bị hết hạn phiên.
Để xác định các phụ thuộc động và thực hiện các biện pháp để ngăn chặn bất kỳ kẻ tấn công nào truy cập các lỗ hổng này.
Để xác định và phục hồi từ bất kỳ kịch bản mã không được quản lý nào.
Để đảm bảo các chứng chỉ có được xác nhận hay không, ứng dụng có triển khai Chứng chỉ ghim hay không.
Để bảo vệ ứng dụng và mạng khỏi các cuộc tấn công từ chối dịch vụ.
Để phân tích lưu trữ dữ liệu và yêu cầu xác thực dữ liệu.
Để cho phép quản lý phiên để ngăn chặn người dùng trái phép truy cập thông tin không được yêu cầu.
Để kiểm tra xem mã mật mã có bị hỏng hay không và đảm bảo rằng mã đã được sửa chữa.
Để xác thực xem việc thực hiện logic nghiệp vụ có được bảo mật hay không và không dễ bị tấn công từ bên ngoài.
Để phân tích các tương tác hệ thống tệp, hãy xác định bất kỳ lỗ hổng nào và sửa các vấn đề này.
Để xác thực các trình xử lý giao thức, ví dụ như cố gắng cấu hình lại trang đích mặc định cho ứng dụng bằng một iframe độc hại.
Để bảo vệ chống lại tiêm bên khách hàng độc hại.
Để bảo vệ chống lại tiêm thời gian độc hại.
Để điều tra bộ nhớ đệm của tệp và ngăn chặn mọi khả năng độc hại từ cùng một tệp.
Để ngăn không cho lưu trữ dữ liệu không an toàn trong bộ đệm ẩn của bàn phím của ứng dụng.
Để điều tra cookie và ngăn chặn bất kỳ hành động độc hại nào từ cookie.
Để cung cấp kiểm toán thường xuyên cho phân tích bảo vệ dữ liệu.
Điều tra các tệp được tạo tùy chỉnh và ngăn chặn bất kỳ hành động độc hại nào từ các tệp được tạo tùy chỉnh.
Để ngăn chặn tràn bộ đệm và các trường hợp tham nhũng bộ nhớ. 24.Để phân tích các luồng dữ liệu khác nhau và ngăn ngừa bất kỳ lỗ hổng nào từ các luồng này.
Usability Testing Test Cases
Quy trình kiểm tra khả năng sử dụng của ứng dụng Di động được thực hiện để có một ứng dụng bước nhanh chóng và dễ dàng với ít chức năng hơn so với ứng dụng chậm và khó khăn với nhiều tính năng. Mục tiêu chính là để đảm bảo rằng chúng ta sẽ có một giao diện dễ sử dụng, trực quan và tương tự như các ngành được chấp nhận trong ngành được sử dụng rộng rãi.
Để đảm bảo rằng các nút phải có kích thước cần thiết và phù hợp với các ngón tay lớn.
Để đảm bảo rằng các nút được đặt trong cùng một phần của màn hình để tránh nhầm lẫn với người dùng cuối.
Để đảm bảo rằng các biểu tượng là tự nhiên và nhất quán với ứng dụng.
Để đảm bảo rằng các nút có cùng chức năng cũng phải có cùng màu.
Để đảm bảo rằng việc xác thực cho các tiện ích phóng to thu nhỏ và thu nhỏ phải được bật.
Để đảm bảo rằng đầu vào bàn phím có thể được giảm thiểu một cách thích hợp.
Để đảm bảo rằng ứng dụng cung cấp một phương thức để quay lại hoặc hoàn tác một hành động, khi chạm vào mục sai, trong một khoảng thời gian chấp nhận được.
Để đảm bảo rằng các menu ngữ cảnh không bị quá tải vì nó phải được sử dụng nhanh chóng.
Để đảm bảo rằng văn bản được giữ đơn giản và rõ ràng để hiển thị cho người dùng.
Để đảm bảo rằng các câu ngắn và đoạn văn có thể đọc được cho người dùng cuối.
Để đảm bảo rằng kích thước phông chữ đủ lớn để có thể đọc được và không quá lớn hoặc quá nhỏ.
Để xác thực ứng dụng sẽ nhắc người dùng bất cứ khi nào người dùng bắt đầu tải xuống một lượng lớn dữ liệu có thể không có lợi cho hiệu suất ứng dụng.
Để xác thực rằng việc đóng ứng dụng được thực hiện từ các trạng thái khác nhau và xác minh xem nó có mở lại trong cùng một trạng thái hay không.
Để đảm bảo rằng tất cả các chuỗi được chuyển đổi thành các ngôn ngữ thích hợp bất cứ khi nào có sẵn một cơ sở dịch thuật ngôn ngữ.
Để đảm bảo rằng các mục ứng dụng luôn được đồng bộ hóa theo các hành động của người dùng.
Để đảm bảo rằng người dùng cuối được cung cấp hướng dẫn sử dụng giúp người dùng cuối hiểu và vận hành ứng dụng có thể không quen thuộc với các thủ tục của ứng dụng.
Kiểm tra khả năng sử dụng thường được thực hiện bởi người dùng thủ công vì chỉ có con người mới có thể hiểu được khả năng nhạy cảm và thoải mái của những người dùng khác.
Compatibility Testing Test Cases
Thử nghiệm tương thích trên thiết bị di động được thực hiện để đảm bảo rằng thiết bị di động có kích thước, độ phân giải, màn hình, phiên bản và phần cứng khác nhau nên ứng dụng sẽ được kiểm tra trên tất cả các thiết bị để đảm bảo ứng dụng hoạt động như mong muốn.
Để xác nhận giao diện người dùng của ứng dụng là theo kích thước màn hình của thiết bị, không có văn bản / điều khiển nào là vô hình hoặc không thể truy cập được.
Để đảm bảo rằng văn bản có thể đọc được cho tất cả người dùng cho ứng dụng.
Để đảm bảo chức năng gọi / báo thức được kích hoạt bất cứ khi nào ứng dụng đang chạy. Ứng dụng này được thu nhỏ hoặc tạm ngưng trong trường hợp có cuộc gọi và sau đó bất cứ khi nào cuộc gọi dừng lại, ứng dụng sẽ được tiếp tục.
Recoverability Testing Test Cases
Phục hồi sự cố và gián đoạn giao dịch
Xác nhận tình hình phục hồi ứng dụng hiệu quả sau các tình huống gián đoạn / sự cố bất ngờ.
Xác minh cách ứng dụng xử lý giao dịch trong khi mất điện (tức là pin chết hoặc đột ngột tắt thiết bị thủ công)
Việc xác nhận quá trình mà kết nối bị treo, hệ thống cần phải thiết lập lại để khôi phục dữ liệu bị ảnh hưởng trực tiếp bởi kết nối bị treo.
Important Checklist
Cài đặt thử nghiệm (cho dù các ứng dụng có thể được cài đặt trong một khoảng thời gian hợp lý và với tiêu chuẩn bắt buộc)
Gỡ cài đặt thử nghiệm (cho dù ứng dụng có thể được gỡ cài đặt trong một khoảng thời gian hợp lý và với tiêu chí bắt buộc)
Các trường hợp kiểm tra mạng (xác nhận xem mạng có hoạt động theo tải yêu cầu hay không, cho dù mạng có thể hỗ trợ tất cả các ứng dụng cần thiết trong quá trình thử nghiệm)
Kiểm tra các phím chưa được ánh xạ
Kiểm tra màn hình splash của ứng dụng
Tiếp tục nhập bàn phím trong quá trình ngắt và các thời điểm khác như sự cố mạng
Các phương thức xử lý việc thoát khỏi ứng dụng
hiệu ứng sạc trong khi một ứng dụng đang chạy trong nền
Pin yếu và nhu cầu hiệu suất cao
Loại bỏ pin trong khi một ứng dụng đang được thực hiện
Tiêu thụ pin theo ứng dụng
Kiểm tra tác dụng phụ của ứng dụng
Nguồn dịch: https://www.guru99.com/testing-mobile-apps.html
All Rights Reserved
Bạn đang đọc nội dung bài viết Bản Vẽ Use Case (Use Case Diagram) trên website Hanoisoundstuff.com. Hy vọng một phần nào đó những thông tin mà chúng tôi đã cung cấp là rất hữu ích với bạn. Nếu nội dung bài viết hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!