3.3.2.1. Các nguyên tắc cơ bản
Trong phần này, có ba khái niệm chính liên quan trong cách tiếp cận đã được mô tả chi tiết. Mỗi khái niệm tương ứng với một bước làm mô hình xác định, như trong Hình 23.
Hình 23: Mô hình hóa các vùng trong thiết kế phần mềm
Cách tiếp cận được mô tả trong tài liệu này tập trung vào việc hệ thống hóa hoặc thậm chí tự động hóa các bước đã được chỉ ra trong quá trình để thực hiện được sự mở rộng một cách tối đa. (việc phát hiện lỗi được thiết lập trong phần ngoặc đơn bởi vì kiểm thử sử dụng thống kê tập trung vào các thước đo tin cậy và có thể xác định chỉ các lỗi kém).
3.3.2.2.Các mô hình sử dụng và kiểm tra cách sử dụng thống kê
Kiểm tra cách sử dụng thống kê là một kỹ thuật mức độ hệ thống cho việc biết chắc chắn rằng các sản phẩm phần mềm đáp ứng một mức độ nhất định của sự tin cậy[6]. Điều này và các hoạt động đánh giá khác cho phép các biện pháp thứ hai được xác định, chẳng hạn sự sẵn sàng của phần mềm và, thậm chí, một quyết định ít rủi ro trên việc phân phát phần mềm cho khách hàng.
Kiểm tra cách sử dụng thống kê được dựa trên ý tưởng mà các phần khác nhau của một chương trình không cần được test kỹ lưỡng giống như vậy. Có một nguyên tắc nổi tiếng là 90-10 mà bắt đầu rằng phần mềm tiêu biểu dùng 90% thời gian thực hiện và 10% của việc mã hóa. Điều này có nghĩa là, những phần chia khác nhau của phần mềm được thực hiện với một tần suất cao hơn những phần chia khác. Kiểm tra cách sử
dụng thống kê hướng tới xác định những phần chia này và điều chỉnh bộ test theo, buộc các phần đã được thực hiện thường xuyên hơn để test kỹ lưỡng hơn.
Bởi vì số lượng của Test case một hệ thống có thể tới là vô hạn, các kỹ thuật mẫu được yêu cầu để lựa chọn một tập hợp phù hợp của các Test case. Một kỹ thuật mẫu thông thường trong ngữ cảnh của statistic usage testing là một sự phân tích cách sử dụng và mô hình cách sử dụng. Mô hình cách sử dụng xác định hiện trạng cách sử dụng như cái gọi là các mô hình cách sử dụng.
Mô hình sử dụng (Usage models): “Một „usage model‟ là tiêu biểu cho việc sử dụng toán tử của một hệ thống phần mềm. „operational use‟ là sự sử dụng được mong đợi của phần mềm trong môi trường được mong đợi”. Usage models sử dụng cái gọi là các hiện trạng sử dụng để mô tả làm thế nào một hệ thống phần mềm có thể được sử dụng bởi những người sử dụng khác nhau và sự sử dụng có thể khác nhau thế nào. Chúng được dựa trên các đặc tả sử dụng và các chức năng cho phần mềm. Thông tin này có thể có được thậm chí trước khi sự thực hiện được bắt đầu. Kết quả là, các nỗ lực cho sự phát triển phần mềm và mô hình hóa cách sử dụng trở nên độc lập, do đó cho phép lập kế hoạch test để xuất hiện song song với hoặc thậm chí ưu tiên tới sự phát triển phần mềm, giảm bớt thời gian phát triển toàn diện và cung cấp thêm các thông tin cho người phát triển.
Hình 24. Các hoạt động của cách tiếp cận đƣợc đề xuất bên trong quá trình phát triển phần mềm.
Trong hình các chuỗi có một khởi đầu duy nhất và một trạng thái cuối cùng duy nhất miêu tả sự kết thúc và sự dẫn chứng của phần mềm. Các trạng thái khởi đầu giống với các trạng thái cách sử dụng được liên hệ với nhau bằng các chuyển tiếp (hình dung theo một hướng duy nhất trong một miêu tả đồ họa). Thuộc tính đòi hỏi sự độc lập của trạng thái kế tiếp tử tất cả các trạng thái trước đó đã đưa trạng thái hiện tại.
Một khi cấu trúc của mô hình cách sử dụng đã được xác định, các khả năng có thể được gán tới tất cả của các chuyển tiếp, được dựa trên sự sử dụng được mong đợi của phần mềm. Các khả năng có thể của tất cả các chuyển tiếp đưa đến việc mất đi một trạng thái cần thêm vào.
Thông thường có một số loại người dùng (trong các biểu đồ use case UML, những người này được mô tả như các tác nhân) một hệ thống có thể tương tác với, và thậm chí một vài loại phụ mỗi loại riêng của người sử dụng được xác định bởi tiêu chuẩn thứ yếu, chẳng hạn như kinh nghiệm. Một hiện trạng cách sử dụng đơn lẻ tiêu biểu sẽ không đủ để giải thích các kết quả khác biệt. Thay vào đó, một vài mô hình cách sử dụng khác biệt sẽ được tạo ra.
3.3.2.3. Nguồn gốc của các mô hình test và cách sử dụng dựa trên các biểu đồ UML
Trong phần này, những hướng dẫn từng bước một được đưa ra mô tả một cách tiếp cận có thể dẫn tới một hệ thống từ các biểu đồ use case được đưa ra tới một cơ sở cho việc sinh tự động của các Test case. Biểu đồ hoạt động (Hình 24) cho thấy trình tự của các hoạt động trong ngữ cảnh của quá trình phát triển phần mềm. Với các mục đích minh họa, một ví dụ đơn giản được lấy từ một dự án thư viện được sử dụng.
(1) Cải tiến các use case
Khởi đầu bằng việc định nghĩa các use case, một quan điểm toàn diện được đơn giản hóa về các chức năng được yêu cầu của hệ thống được tạo ra. Do sự giới hạn của việc diễn đạt, các biểu đồ use case bản thân chúng được sử dụng rất ít-trừ khi các use case riêng biệt được cải tiến trong một dạng nguyên bản thông thường, và thường có đăng ký.
Mục đích của hệ thống hóa bắt nguồn từ các mô hình cách sử dụng cho một hệ thống phần mềm mà đòi hỏi các khía cạnh động được mô hình hóa từ một quan điểm hướng tới cách sử dụng, cụ thể sự tương tác của hệ thống với môi trường, ví dụ, sự phản hồi của nó tới tác nhân hoạt động; các tương tác bên trong có liên quan chỉ khi chúng cho ra các kết quả.
Một mẫu được trình bày thành dạng bảng phù hợp cho việc cải tiến nguyên bản các use case. Ý tưởng đằng sau là để đạt được một sự mô tả hoàn chỉnh đơn nhất của một use case bằng việc xác định và liên hệ lẫn nhau tới tất cả của các kịch bản nó đưa vào. Thêm vào đó, các điều kiện trước và sau xác định trạng thái cách sử dụng trước và sau tương ứng, việc thực hiện các thủ tục use case tượng tự như vậy. Kể cả các use case phụ bên trong một use case cho phép các liên hệ có thứ bậc trong số các use case. Một phiên bản mẫu (bảng 2) được mở rộng bởi các tác nhân và các biến được cho thấy ở Hình 25; một ví dụ minh họa đầy đủ nữa của một mẫu được cho trong Hình 26.
Name identifying the use case.
Goal describing the overall purpose of the use case
Actors involved in the use case.
Pre-conditions needed to be matched in order for the use case to be “executed.”
Post-conditions describing the usage state after the “execution” of the use case.
Invariants Conditions or state attributes that hold both when the use case starts and
throughout its course.
Main Success scenario
Describes how the use case‟s goal can be achieved as an enumeration of alternating stimuli and responses of the system, starting with the stimulus triggering the use case.
Variations
An alternate course of action which, unlike what is named “extensions” below, is still within what resembles normal parameters for the use case. Variations are specified by referring to the respective step‟s number in the enumeration of the main success scenario and refining the step with one or more alternative steps.
Unless explicitly stated otherwise, the variation replaces the step in question, and the scenario continues with the following step in the main success scenario. Nested variations can be specified by further sub- references.
Extensions A scenario in response to exceptional circumstances (e.g., invalid input
data). Its specification adheres to the same formalism as that of variations described above.
Included use cases
A list of other use cases used by this one (usually those referred to via <<includes>> arcs in use case diagrams).
Bảng 2: Mẫu cải tiến các use case
Một mẫu như được nói trong công việc được đặt tên cần được mở rộng cho nhiều điều kiện:
Điều kiện trước: Điều kiên trước xác định ngữ cảnh, ví dụ, trạng thái cách sử dụng, trong đó một use case có thể được thực hiện; sự mở rộng này cho phép đa ngữ.
Điều kiện cao hơn: Một use case đơn nhất có thể dẫn tới một vài trạng thái có thể cao hơn (thông qua những biến đổi hoặc những sự mở rộng); các vị trí cao hơn có thể khác biệt phụ thuộc vào kịch bản nào được áp dụng. Cho sử dụng sau đó; nhiều điệu kiện cao hơn nên được đánh số, và việc định nghĩa các kịch bản nên được làm rõ điều kiện cao hơn nào chúng đưa đến.
Một mẫu chi tiết như vậy phải được điền vào trong cho mỗi use case. Tính chất bên trong của các đặc tả kịch bản xác định tính cốt lõi của các công việc test thậm chí cách tiếp cận dẫn đến, ví dụ, một bước kịch bản tương tự một tác nhân kích thích sẽ được đưa vào trong một đầu vào test nguyên tử và một bước kịch bản mô tả một câu trả lời sẽ trở thành một câu trả lời có thể quan sát được nguyên tử.
(2) Từ use case tới các biều đồ trạng thái
Trong bước kế tiếp các mẫu được chuyển vào trong các biểu đồ trạng thái. Mục đích của việc lấy được các Test case dựa vào các mô hình cách sử dụng đòi hỏi một sự miêu tả giống đồ thị hơn của quan điểm hướng đến cách sử dụng. Các biểu đồ trạng thái tạo ra một bước khởi đầu phù hợp với hai lý do:
Quan điểm là hướng đến trạng thái và sự phù hợp để đưa ra các trạng thái khác nhau của cách sử dụng.
Nguyên mẫu của các chuyển tiếp trạng thái là một biến khởi động, đó là, một tác nhân khiến cho hệ thống mô hình thay đổi trạng thái của nó.
Chi tiết các mẫu use case đã được giới thiệu được nâng cao để hỗ trợ sự bắt nguồn hệ thống của một đặc tả cách sử dụng được dựa vào biểu đồ trạng thái. Chi tiết use case đã được thực hiện bởi con người, nhưng sự chuyển tiếp theo sau có thể được tự động bởi cách tiếp cận này.
Name Lend a book
Goal Lend a book of this library to a user of this library for a limited time.
Actors Librarian
Pre-conditions The library system is running. The user is a valid user of the library. Post-conditions The book has been lent to the user. A due date for its return has been
defined.
Invariants None.
Main Success Scenario
1) The librarian opens the user selection dialog, the selected user is shown.
2) The librarian opens the lending dialog for selecting a book, the return date is shown. 3) He confirms the operation. 4) The system marks the book as lent and adds it to the lent-book-list of the user.
Variations None.
Extensions
2a) The user has to pay a fee or a fine. 2a1) The system displays a message that no new lending procedures are allowed before all due payments have been fulfilled, and switches to the cashing dialog. 2a2) After successful payment, the system returns to the book lending dialog. 2a3) If not successful, the system displays the user selection dialog. 2b) The book of interest is already lent or is for reference only. 2b1) The system displays a message and returns to the book selection dialog. 3a) The librarian cancels the operation. 3a1) The system returns to the book selection dialog.
Included use
cases Display books lent by a user; Collect payment from a user.
Bảng 3: Một ví dụ về mẫu chi tiết các use case
Ý tưởng (mà sinh ra một vài sự tương đồng là để mô hình hóa mỗi use case trong một biểu đồ trạng thái tách biệt và giữ chặt những biểu đồ đó trong một biều đồ
mức độ cao nhất. Biểu đồ mức độ cao nhất này tương tự một framework trong đó use case có thể được thực hiện phụ thuộc vào những điều kiện đầu tiên của chúng, và trong đó có thêm các trạng thái cách sử dụng toàn bộ, được ngoại suy từ các điều kiện ban đầu của tất cả các use case, có thể được chuyển đổi giữa chúng, thêm nữa bằng các công cụ của use case. Một biểu đồ trạng thái mức độ cao hoặc một trật tự như vậy, với các hệ thống phức tạp hơn) là được xây dựng bằng cách tôn trọng triệt để các hướng dẫn sau:
Từ tất cả các điều kiện ban đầu và cao hơn của tất cả các use case, các trạng thái toàn thể của cách sử dụng là được ngoại suy. Trong ngữ cảnh đó, “các trạng thái của cách sử dụng” tham chiếu tới sự liên hệ của hệ thống người sử dụng. Ví dụ, trong một ứng dụng dựa trên GUI tương tác, những trạng thái như vậy mô tả các thực đơn khác nhau.
Các biều đồ trạng thái của use case xuất hiện như những người có địa vị, có nghĩa là chỉ đường viền trạng thái của chúng và tên được đưa vào cùng, tham chiếu tới biểu đồ trạng thái thực tế. Bên trong chúng, các bộ nối biểu đồ phù hợp với các điều kiện cao hơn được lấy ra. Một bộ nối biểu đồ là một sự tham khảo biểu trưng tới một sự xuất hiện khác của cùng biểu tượng trong một biểu đồ khác, cho phép các kết nối này trong số các biểu đồ tách biệt. Cơ chế này là một sự mở rộng của các biểu đồ trạng thái UML. Các bộ nối cho phép các biểu đồ trạng thái tách biệt của mỗi use case hơn một biểu đồ phức tạp và giúp ích cho việc sửa lại/sử dụng lại (cải thiện tính dễ hiểu và tránh các lỗi). Sự đa dạng và sự mở rộng của các use case đưa thêm các điều kiện cao hơn trong các biểu đồ trạng thái được cải tiến thường xuyên cung cấp thêm các bộ nối biểu đồ.
Các trạng thái quan trọng của mỗi use case nhận các chuyển tiếp hồi lại từ tất cả các trạng thái toàn bộ mô tả các điều kiện ban đầu của use case trong tiều đề cập đến. Sự khởi động của mỗi chuyển tiếp là bước đầu tiên của kịch bản thành công chính (ví dụ, các tác nhân kích thích khởi động sự thực hiện của use case). Nếu có đa tác nhân kích thích khởi động, một sự chuyển tiếp tách biệt cần được đưa vào cho mỗi tác nhân kích thích.
Các bộ nối biểu đồ bên trong các trạng thái quan trọng (place-holding) của các use case là được kết nối tới các trạng thái hệ thống toàn bộ tương ứng với điều kiện cao hơn được tương đồng bởi bộ nối biểu đồ trong điều được đề cập đến. Những chuyển tiếp này được chuyển tiếp tự động (và sẽ khó tránh khỏi sự chuyển tiếp ở giai đoạn sau).
Các chuyển tiếp đầu tiên và kết thúc được thêm vào, mô tả sự kích hoạt và kết thúc của phần mềm, tương ứng.
Hình 25. Biểu đồ trạng thái mức độ cao nhất cho ví dụ use case của bảng 3.
Để giải thích cho các tác nhân khác nhau và các hiện trạng cách sử dụng khác nhau, người ta gợi ý để tạo ra một biểu đồ mức độ cao tách biệt cho mỗi tác nhân. Cách này, các hiện trạng cách sử dụng độc lập mà đã được mô tả bởi các biểu đồ trạng thái mức độ cao có thể được cải tiến độc lập, giữ lại và xây dựng trên đặc tả chung được bắt nguồn trong các bước trước đó. Hình 25 cho thấy một biểu đồ mức độ cao có thể cho một ứng dụng giả mạo không hoàn chỉnh mẫu use case trong bảng 3 có thể thuộc về nó.
Lấy ra mẫu các chi tiết được điền vào, mỗi use case được chuyển vào trong một biểu đồ trạng thái riêng biệt bằng cách theo sau các hướng dẫn bên dưới:
Mô hình hóa các kịch bản thành công chủ yếu như biểu đồ trạng thái: Các phản ứng hệ thống được đưa vào trong các trạng thái, các tác nhân kích thích trở thành