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 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 vă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 diện mạo động được mô hình hóa từ một điểm được định hướng tới cách sử dụng của quan điểm, 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 phản hồi bên trong thì chỉ liên quan đến bởi vì chúng cho ra các kết quả bên ngoài.
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 lượng bất 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.
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:
Nhiều đ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ữ cảnh.
Nhiều đ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 như hột của các đặc tả kịch bản xác định tính chất có hột 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
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.
Bảng 3: Một ví dụ về mẫu chi tiết các use case (adsbygoogle = window.adsbygoogle || []).push({});
Ý 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.
Để 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 sự chuyển tiếp được khởi động. Các trạng thái và chuyển tiếp được đặt tên và đánnh mã trong một hình thức mà giúp tương quan giữa chúng với các thực thể tương đương trong mẫu use case tương ứng.
• Các thay đổi và mở rộng được kết hợp bằng cách thêm vào các trạng thái và các chuyển tiếp. Có thể trong các biểu đồ trạng thái thấp hơn.
• Mỗi một điều kiện cao hơn khác nhau trở thành một bộ nối biểu đồ mà chỉ các chuyển tiếp trở về được phép kết nối với. Ghi nhớ rằng nó là hợp pháp để có các đa chuyển tiếp kết nối tới bộ nối biểu đồ giống nhau bởi vì những vạch dấu này tại trạng thái muốn được thay thế bởi các trạng thái ở mức độ cao hơn.
• Các điều điện đầu tiên không được mô hình hóa bên trong biểu đồ trạng thái use case tương ứng, và không là các tác nhân kích thích mà là các bước đầu tiên của các kịch bản chính (trừ khi có các biến đổi và /hoặc sự chấp thuận của bước đầu tiên trong các kịch bản thành công chính, các case trong đó biểu đồ chuyển tiếp ban đầu có thể bị tách rời việc sử dụng một thanh mẫu điều kiện (using a conditional fork).
• Các hành động hệ thống có thể được quan sát đã được mô hình hóa như các hành động (thực thể) trong các trạng thái tương ứng.
Hình 26 cho thấy một biểu đồ trạng thái được cải tiến cho ví dụ thư viện. Các bộ nối biểu đồ tham chiếu tới biểu đồ của hình 25 và tới các mở rộng trong bảng 3.
Kết quả của bước này là một hệ thống cấp bậc của các biểu đồ trạng thái và một trình độ cao hơn của sự hình thức hóa. Các use case giờ đây được buộc lại cùng nhau thông qua một biểu đồ trạng thái mức độ cao nhất. Một lợi thế khác của việc sử dụng các biểu đồ trạng thái là một bước đầu tiên gồm vào trong đó, nếu được yêu cầu và tính khả thi đã cho ra một cấu trúc của hệ thống, các mô hình cách sử dụng tách biệt có thể được tạo ra mỗi biểu đồ trạng thái, cho phép ứng dụng về cách tiếp cận tại một thành phần hơn là mức hệ thống.
Hình 26. Cải tiến biểu đồ trạng thái cho ví dụ use case của bảng 3.2 (3) Từ các biểu đồ trạng thái tới đồ thị cách sử dụng
Trong bước này, các biểu đồ trạng thái mức độ cao nhất được chuyển vào trong