Luận văn Thạc sĩ Kỹ thuật phần mềm: Phương pháp sinh tự động các ca kiểm thử từ đặc tả ca sử dụng

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:68

Thêm vào BST

Báo xấu

8
lượt xem 2
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Luận văn đề xuất lý thuyết cho ngôn ngữ mô hình hóa ca sử dụng có giới hạn RUCM cho phép đặc tả ca sử dụng bằng mô hình. Các quy tắc hạn chế và mẫu ca sử dụng phải đƣợc áp dụng trong giai đoạn khởi tạo các yêu cầu của phát triển phần mềm hƣớng ca sử dụng (use case driven software development) để tạo ra các mô hình ca sử dụng chính xác và rõ ràng có thể mô hình hóa trong phạm vi có thể.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Luận văn Thạc sĩ Kỹ thuật phần mềm: Phương pháp sinh tự động các ca kiểm thử từ đặc tả ca sử dụng

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ PHÙNG THỊ HƢƠNG PHƢƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ TỪ ĐẶC TẢ CA SỬ DỤNG LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM Hà Nội - 2021
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ PHÙNG THỊ HƢƠNG PHƢƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ TỪ ĐẶC TẢ CA SỬ DỤNG Nghành: Kỹ thuật phần mềm Chuyên ngành: Kỹ thuật phần mềm Mã số: 8480103.01 LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM CÁN BỘ HƢỚNG DẪN: TS. ĐẶNG ĐỨC HẠNH Hà Nội – 2021
LỜI CẢM ƠN Đầu tiên, tôi xin đƣợc gửi lời cảm ơn sâu sắc tới Tiến sĩ Đặng Đức Hạnh – giảng viên bộ môn Công nghệ Phần mềm – ngƣời đã dành nhiều thời gian và công sức trong suốt năm vừa qua để hƣớng dẫn tôi hoàn thành luận văn này. Thầy đã giúp tôi từ những bƣớc đầu tiên, từ việc lựa chọn đề tài phù hợp với mình đến chia sẻ các phƣơng pháp nghiên cứu, kinh nghiệm làm việc, giao tiếp,... những kĩ năng cần thiết không chỉ trong chính luận văn này mà còn trong cuộc sống, sự nghiệp tƣơng lai của tôi. Tôi cũng xin đƣợc cảm ơn sự hỗ trợ của đề tài nghiên cứu khoa học cấp Đại học Quốc Gia Hà Nội, mã số QG.20.54. Tôi cũng xin gửi lời cảm ơn chân thành đến các thành viên trong nhóm nghiên cứu đã hỗ trợ tôi rất tận tình trong khoảng thời gian vừa qua. Các anh chị em trong nhóm đã biểu hiện một tình thần đoàn kết cao, tƣơng trợ lẫn nhau trong các công việc lớn nhỏ, cùng thảo luận, đóng góp ý kiến với mỗi vấn đề của mỗi thành viên. Đó chắc chắn sẽ là những kỉ niệm khó quên đối với mỗi ngƣời trong nhóm, đặc biệt là với tôi. Ngoài ra, tôi xin gửi lời cảm ơn đến các thầy cô giảng viên của Trƣờng Đại học Công nghệ - Đại học Quốc gia Hà Nội. Những kiến thức chuyên môn, nghiệp vụ và cả các kĩ năng mềm mà các thầy cô đã dạy cho tôi trong suốt khóa học đã trở thành nền tảng để tôi phát triển và xây dựng luận văn này. Cuối cùng, tôi xin cảm ơn gia đình, bạn bè và ngƣời thân đã đồng hành cùng tôi trong cuộc sống, cung cấp cho tôi ý chí và nghị lực để luôn vƣơn lên trong cuộc sống. ii
LỜI CAM ĐOAN Tôi là Phùng Thị Hƣơng, học viên khóa K24, chuyên ngành Kỹ thuật phần mềm thuộc chƣơng trình đào tạo Thạc sĩ của Trƣờng Đại học Công nghệ - Đại học Quốc gia Hà Nội. Tôi xin cam đoan luận văn “Phƣơng pháp sinh tự động các ca kiểm thử từ đặc tả ca sử dụng” là của tôi. Tôi đã trích dẫn đầy đủ các tài liệu tham khảo, công trình nghiên cứu liên quan ở trong nƣớc và quốc tế. Ngoại trừ các tài liệu tham khảo này, luận văn hoàn toàn là công việc của riêng tôi. Hà Nội, ngày 16 tháng 12 năm 2021 Học viên Phùng Thị Hƣơng iii
MỤC LỤC LỜI CẢM ƠN ..................................................................................................... ii LỜI CAM ĐOAN............................................................................................... iii MỤC LỤC .......................................................................................................... iv DANH MỤC CÁC KÝ HIỆU VÀ TỪ VIẾT TẮT ............................................ vi DANH MỤC CÁC BẢNG ................................................................................ vii DANH MỤC CÁC HÌNH VẼ .......................................................................... viii CHƢƠNG 1: GIỚI THIỆU............................................................................... 1 CHƢƠNG 2: KIẾN THỨC NỀN TẢNG ......................................................... 3 2.1. Giới thiệu chƣơng ................................................................................... 3 2.2. Đặc tả yêu cầu và đặc tả ca sử dụng ........................................................ 3 2.2.1. Đặc tả yêu cầu chức năng và phi chức năng .............................................. 3 2.2.2. Đặc tả ca sử dụng ........................................................................................ 4 2.3. Kiểm thử dựa trên mô hình ..................................................................... 7 2.3.1. Tổng quan kiểm thử dựa trên mô hình ........................................................ 7 2.3.2. Đặc tả ca kiểm thử ....................................................................................... 9 2.4. Kỹ nghệ hƣớng mô hình ....................................................................... 10 2.4.1. Chuyển đổi mô hình ................................................................................... 10 2.4.2. Các ràng buộc siêu mô hình UML/OCL ................................................... 11 2.4.3. Ngôn ngữ Kermeta ..................................................................................... 12 2.4.4. Ngôn ngữ lập trình toán học AMPL .......................................................... 13 2.5. Tổng kết chƣơng ................................................................................... 14 CHƢƠNG 3: PHƢƠNG PHÁP SINH TỰ ĐỘNG CÁC CA KIỂM THỬ TỪ ĐẶC TẢ CA SỬ DỤNG ................................................................................... 15 3.1. Giới thiệu chƣơng ................................................................................. 15 3.2. Tổng quan phƣơng pháp ....................................................................... 16 3.3. Đặc tả ca sử dụng .................................................................................. 18 3.3.1. Khuôn mẫu RUCM ..................................................................................... 18 3.3.2. Luật giới hạn sử dụng ngôn ngữ tự nhiên ................................................. 20 3.3.3. Luật giới hạn sử dụng các từ khóa ............................................................ 23 3.3.4. Đặc tả ca sử dụng bằng RUCM................................................................. 24 3.4. Chuyển đổi đặc tả ca sử dụng sang biểu đồ trạng thái........................... 25 3.4.1. Siêu mô hình UCMeta ................................................................................ 26 3.4.2. Luật chuyển đổi .......................................................................................... 27 iv
3.5. Phƣơng pháp sinh tự động các ca kiểm thử ........................................... 34 3.5.1. Chuẩn hóa mục tiêu kiểm thử .................................................................... 35 3.5.2. Quy hoạch toán học ................................................................................... 36 3.5.2.1. Chuyển đổi các biến của mô hình kiểm thử thành các biến AMPL ...... 36 3.5.2.2. Chuyển đổi tiền điều kiện của chuyển tiếp trên máy trạng thái sang AMPL ................................................................................................................... 38 3.5.2.3. Chuyển đổi hậu điều kiện của chuyển tiếp trên máy trạng thái sang AMPL ................................................................................................................... 38 3.5.2.4. Thêm các ràng buộc có tính liên tục vào mô hình AMPL ..................... 38 3.5.2.5. Chuyển đổi trạng thái bất biến thành ràng buộc AMPL....................... 39 3.5.3. Sinh ca kiểm thử trừu tượng và dữ liệu kiểm thử cụ thể ........................... 39 3.5.3.1. Phát hiện đường dẫn khả thi .................................................................. 41 3.5.3.2. Sự khởi động nóng.................................................................................. 42 3.5.3.3. Phân tích giá trị biên ............................................................................. 43 3.5.4. Sinh ca kiểm thử đơn vị .............................................................................. 43 3.6. Tổng kết chƣơng ................................................................................... 44 CHƢƠNG 4: CÀI ĐẶT VÀ THỰC NGHIỆM .............................................. 45 4.1. Giới thiệu chƣơng ................................................................................. 45 4.2. Công cụ hỗ trợ ...................................................................................... 45 4.2.1. Giới thiệu công cụ ...................................................................................... 45 4.2.2. Đánh giá kết quả ........................................................................................ 50 4.2.2.1. Tỷ lệ hài lòng của mục tiêu kiểm thử ..................................................... 51 4.2.2.2. Độ bao phủ mã nguồn ............................................................................ 51 4.2.2.3. Phân tích giá trị biên ............................................................................. 52 4.3. Thực nghiệm ......................................................................................... 53 CHƢƠNG 5: KẾT LUẬN .............................................................................. 56 5.1. Các đóng góp của luận văn ................................................................... 56 5.2. Hƣớng phát triển ................................................................................... 57 TÀI LIỆU THAM KHẢO ................................................................................. 58 v
DANH MỤC CÁC KÝ HIỆU VÀ TỪ VIẾT TẮT STT Ký hiệu, Nguyên nghĩa Tiếng Anh Ý nghĩa Tiếng Việt Từ viết tắt 1 UCS Use Case Specication Đặc tả ca sử dụng 2 RUCM Restricted Use Case Mô hình hóa ca sử dụng có Modeling giới hạn/bị hạn chế 3 SUT System Under Test Hệ thống kiểm thử 4 MBT Model Based Testing Kiểm thử dựa trên mô hình 5 MBD Model Based Design Thiết kế dựa trên mô hình 6 IXIT Implementation eXtra Thông tin bổ sung cho việc Information for Testing triển khai kiểm thử 7 MDE Model Driven Engineering Kỹ thuật hƣớng mô hình 8 MDD Model Driven Development Phát triển hƣớng mô hình MDA Model Driven Architecture Kiến trúc hƣớng mô hình 9 DFS Depth First Search Giải thuật tìm kiếm theo chiều sâu 10 POS Part-Of-Speech Từ loại (trong Tiếng Anh) 11 M2M Model-to-model Chuyển đổi mô hình sang transformation mô hình 12 M2T Model-to-text transformation Chuyển đổi mô hình sang văn bản 13 IEEE Institute of Electrical and Hội kỹ sƣ điện và điện tử Electronics Engineers thế giới 14 XML eXtensible Markup Ngôn ngữ đánh dấu mở Language rộng 15 UML Unified Modeling Language Ngôn ngữ mô hình hóa thống nhất 16 AMPL A Mathematical Ngôn ngữ lập trình toán Programming Language học 17 OCL Object Constraint Language Ngôn ngữ ràng buộc đối tƣợng 18 OMG Object Management Group Tổ chức quản lý đối tƣợng 19 QVT Query/View/Transformation Ngôn ngữ truy vấn/biểu diễn/chuyển đổi mô hình (của OMG) 20 MOF Meta Object Facility Cơ sở siêu đối tƣợng 21 EMOF Essential Meta Object Cơ sở siêu đối tƣợng cơ Facility bản 22 CMOF Complete Meta Object Cơ sở siêu đối tƣợng hoàn Facility chỉnh vi
DANH MỤC CÁC BẢNG Bảng 2.1: Đặc tả ca sử dụng “Đăng nhập” của phân hệ “Quản lý xác thực ngƣời dùng” ........................................................................................................................................... 6 Bảng 2.2: Cấu trúc ca kiểm thử ........................................................................................ 9 Bảng 3.1: Khuôn mẫu của RUCM ................................................................................. 19 Bảng 3.2: Bộ luật giới hạn của RUCM (R1 – R7)......................................................... 21 Bảng 3.3: Bộ luật giới hạn của RUCM (R8 – R16)....................................................... 22 Bảng 3.4: Bộ luật giới hạn của RUCM (R17-R26) ........................................................ 24 Bảng 3.5: Ca sử dụng Disconnect................................................................................... 25 Bảng 3.6: Tóm tắt các luật biến đổi ................................................................................ 28 Bảng 3.7: Các toán tử đƣợc hỗ trợ trong việc định nghĩa ràng buộc OCL ................... 36 Bảng 4.1: So sánh ParTeG với các công cụ thƣơng mại ............................................... 50 Bảng 4.2: Tỷ lệ đáp ứng mục tiêu kiểm thử của ParTeG .............................................. 51 Bảng 4.3: Báo cáo về độ bao phủ mã nguồn của ParTeG ............................................. 52 Bảng 4.4: Đặc tả bài toán sử dụng để đánh giá ParTeG ................................................ 52 Bảng 4.5: Ví dụ đặc tả ca sử dụng theo khuôn mẫu RUCM ......................................... 53 vii
DANH MỤC CÁC HÌNH VẼ Hình 2.1: Phân hệ “Quản lý xác thực ngƣời dùng”. ........................................................ 5 Hình 2.2: Cài đặt MBT thông thƣờng. ............................................................................. 8 Hình 2.3: Ví dụ quy trình kiểm thử dựa trên mô hình. .................................................... 8 Hình 3.1: Qui trình tạo các ca kiểm thử từ mô hình ca sử dụng. ................................... 16 Hình 3.2: Đoạn trích mã Kermeta để triển khai luật 5.3. ............................................... 30 Hình 3.3: Đoạn trích mã Kermeta để triển khai luật 5.4.2. ............................................ 32 Hình 3.4: Mối quan hệ Include và Extend giữa các ca sử dụng..................................... 33 Hình 3.5: Phân loại các cách tiếp cận MBT khác nhau. ................................................ 34 Hình 3.6: Cấu trúc dữ liệu cho việc lƣu trữ dữ liệu. ...................................................... 37 Hình 3.7: Mô tả đƣờng đi khả thi (infeasible path detection). ...................................... 42 Hình 3.8: Siêu mô hình kiểm thử đơn vị. ....................................................................... 44 Hình 4.1: Cấu trúc đầu vào của ParTeG. ....................................................................... 46 Hình 4.2: Giao diện máy trạng thái trong ParTeG. ........................................................ 46 Hình 4.3. Ví dụ máy trạng thái đƣợc sinh ra dƣới dạng biểu đồ. .................................. 47 Hình 4.4: Giao diện sinh ca kiểm thử từ sơ đồ máy trạng thái bằng ParTeG. .............. 49 Hình 4.5: Các tính năng của ParTeG. ............................................................................ 49 Hình 4.6: Biểu đồ máy trạng thái để phân loại một tam giác. ....................................... 54 Hình 4.7: Giao diện tạo các ca kiểm thử của ParTeG.................................................... 55 Hình 4.8: Các ca kiểm thử đƣợc tạo ra từ công cụ ParTeG. .......................................... 55 viii
CHƢƠNG 1: GIỚI THIỆU Hiện nay, hoạt động kiểm thử nhằm đảm bảo chất lƣợng phần mềm đóng vai trò hết sức quan trọng trong quá trình phát triển phần mềm. Chính hoạt động kiểm thử quyết định đến sự tồn tại và phát triển của một hệ thống phần mềm. Đối mặt với vấn đề thực tiễn đặt ra, hệ thống phần mềm ngày một gia tăng về quy mô cũng nhƣ độ phức tạp của nghiệp vụ thì để thực hiện hoạt động kiểm thử phần mềm hiệu quả cần tốn nhiều thời gian và công sức. Trong đó, việc sinh các ca kiểm thử là bài toán quan trọng nhất trong nghiên cứu kiểm thử phần mềm. Tuy nhiên thiết kế các ca kiểm thử thủ công sẽ tốn thời gian và dễ gặp lỗi. Do đó, việc nghiên cứu các phƣơng pháp để sinh tự động các ca kiểm thử là việc tối quan trọng trong quá trình sản xuất phần mềm ngày nay. Có nhiều hƣớng tiếp cận trong việc sinh ca kiểm thử tự động, có thể sinh từ đặc tả yêu cầu phần mềm, từ các ca sử dụng, từ mã nguồn... Thiết kế ca kiểm thử từ mã nguồn khó có thể tự động đƣợc bởi một phần mềm thƣờng do rất nhiều lập trình viên cùng phát triển, mỗi lập trình viên có một phong cách lập trình khác nhau dẫn đến sự không thống nhất trong quá trình xây dựng luật sinh tự động. Thiết kế ca kiểm thử từ ca sử dụng là hƣớng tiếp cận khả thi nhất, bởi các kí hiệu thiết kế trong ca sử dụng có các luật riêng, có thể làm sở cứ cho việc thiết kế đầu vào, đầu ra của kiểm thử, điều này giúp giảm đáng kể một phần chi phí của quá trình kiểm thử. Ngoài ra, trong quá trình sinh các ca kiểm thử từ các ca sử dụng còn giúp các kiểm thử viên phát hiện sớm vấn đề trong chính thiết kế phần mềm đó để điều chỉnh kịp thời, giảm thời gian và chi phí cho dự án. Mô hình ca sử dụng bao gồm biểu đồ ca sử dụng và đặc tả ca sử dụng dạng văn bản, thƣờng đƣợc áp dụng cho các yêu cầu về cấu trúc và tài liệu. Đặc tả ca sử dụng thƣờng là các tài liệu dạng văn bản tuân theo mẫu ca sử dụng thông thƣờng mô tả bằng ngôn ngữ tự nhiên. Tuy nhiên hạn chế của ngôn ngữ tự nhiên là sự liên kết lỏng lẻo, ý nghĩa mơ hồ, và khó tự động hóa. Vì vậy đặc tả ca sử dụng cần hƣớng đến phƣơng pháp đặc tả hình thức mà máy có thể hiểu đƣợc. Trong báo cáo, luận văn đề xuất phƣơng pháp tiếp cận mô hình hóa ca sử dụng bằng ngôn ngữ RUCM (Restricted Use Case Modeling). Mục đích chính là để hạn chế việc ngƣời dùng đặc tả ca sử dụng một cách mơ hồ, cải thiện tính dễ hiểu của các mô hình ca sử dụng và tạo điều kiện phân tích tự động để tạo ra các mô hình phân tích ban đầu. Trong ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language), nó đƣợc gọi là biểu đồ lớp, biểu đồ tƣơng tác, và có thể là các loại biểu đồ và ràng buộc khác nữa. 1
Luận văn đề xuất lý thuyết cho ngôn ngữ mô hình hóa ca sử dụng có giới hạn RUCM cho phép đặc tả ca sử dụng bằng mô hình. Các quy tắc hạn chế và mẫu ca sử dụng phải đƣợc áp dụng trong giai đoạn khởi tạo các yêu cầu của phát triển phần mềm hƣớng ca sử dụng (use case driven software development) để tạo ra các mô hình ca sử dụng chính xác và rõ ràng có thể mô hình hóa trong phạm vi có thể. Xuất phát từ cơ sở khoa học và nhu cầu thực tiễn nhƣ trên, luận văn đề xuất “Phƣơng pháp sinh tự động các ca kiểm thử từ đặc tả ca sử dụng”, đây cũng chính là tên đề tài luận văn sẽ thực hiện. Nội dung luận văn giải quyết các vấn đề chính sau đây: - Thứ nhất, luận văn trình bày một số kiến thức nền tảng liên quan trực tiếp đến vấn đề cần nghiên cứu bao gồm lý thuyết về đặc tả yêu cầu, đặc tả ca sử dụng, phƣơng pháp kiểm thử dựa trên mô hình. Luận văn cũng giới thiệu lý thuyết về chuyển đổi mô hình, các ngôn ngữ hỗ trợ cho việc sinh tự động các ca kiểm thử từ đặc tả ca sử dụng. - Thứ hai, luận văn đề xuất phƣơng pháp tiếp cận mô hình hóa ca sử dụng bằng khuôn mẫu RUCM để giảm sự mơ hồ trong việc đặc tả ca sử dụng, và đặc biệt là có thể dùng cho việc tự động hóa. Phƣơng pháp tiếp cận này cần đầu vào là biểu đồ ca sử dụng, các quy tắc hạn chế và mẫu ca sử dụng. Biểu đồ ca sử dụng để biểu diễn mối quan hệ giữa các tác nhân và ca sử dụng; các quy tắc hạn chế đƣợc áp dụng để hạn chế cách ngƣời dùng viết đặc tả ca sử dụng; mẫu ca sử dụng là phƣơng tiện để cấu trúc hóa đặc tả ca sử dụng. Với một mô hình ca sử dụng đƣợc ghi lại bằng cách áp dụng RUCM, các mô hình phân tích khởi tạo đƣợc sinh ra, các mô hình này chính là đầu vào trong việc sinh tự động các ca kiểm thử. Trên thực tế, bƣớc này có thể đƣợc thực hiện thủ công bởi các nhà phân tích hệ thống nhƣng cũng có thể tự động đƣợc, đặc biệt nếu các mô hình ca sử dụng ít mơ hồ, để tạo điều kiện thuận lợi cho việc phân tích tự động. - Thứ ba, luận văn trình bày phƣơng pháp sinh tự động các ca kiểm thử từ biểu đồ UML, biểu đồ này đƣợc sinh ra nhờ phƣơng pháp tiếp cận mô hình hóa ca sử dụng bằng RUCM đã đề cập ở trên. - Thứ tƣ, luận văn hƣớng dẫn cài đặt công cụ hỗ trợ sinh các ca kiểm thử tự động từ biểu đồ UML, đó chính là Parteg. Luận văn tiến hành thực nghiệm và đánh giá kết quả thu đƣợc dựa trên nhiều tiêu chí đảm bảo chất lƣợng phần mềm. 2
CHƢƠNG 2: KIẾN THỨC NỀN TẢNG 2.1. Giới thiệu chƣơng Mục đích của chƣơng này là cung cấp kiến thức nền tảng về kỹ nghệ hƣớng mô hình nói chung, phƣơng pháp kiểm thử dựa trên mô hình nói riêng. Các khái niệm cơ bản trong phát triển hƣớng mô hình và đặc tả yêu cầu chức năng dựa vào ca sử dụng. Mục 2.2 cung cấp những kiến thức tổng quan về khái niệm đặc tả yêu cầu và đặc tả ca sử dụng, kiến thức sẽ đƣợc sử dụng xuyên suốt luận văn. Mục 2.3 trình bày tổng quan về kiểm thử dựa trên mô hình, giới thiệu một khái niệm quan trọng trong đặc tả ca kiểm thử. Mục 2.4 trình bày một số khái niệm quan trọng trong kỹ nghệ hƣớng mô hình, kỹ thuật chuyển đổi mô hình, giới thiệu cái nhìn tổng quan nhất về ngôn ngữ Kermeta đƣợc sử dụng trong việc sinh biểu đồ trạng thái từ ca sử dụng và ngôn ngữ lập trình toán học AMPL đƣợc sử dụng trong việc sinh các ca kiểm thử từ biểu đồ trạng thái. 2.2. Đặc tả yêu cầu và đặc tả ca sử dụng Đặc tả yêu cầu phần mềm tạo cơ sở cho việc thỏa thuận giữa khách hàng và nhà thầu hoặc nhà cung cấp về những gì sản phẩm phần mềm có làm việc đúng nhƣ mong muốn không. Nó cho phép một đánh giá nghiêm ngặt các yêu cầu trƣớc khi có thể bắt đầu vào việc thiết kế và thực thi giảm tối đa việc thiết kế lại. Mục 2.2.1 sẽ mô tả thế nào là một đặc tả yêu cầu có chất lƣợng. Một nhiệm vụ rất quan trọng trong quy trình phát triển phần mềm là đặc tả ca sử dụng, nhằm nắm bắt yêu cầu chức năng của hệ thống. Mục 2.2.2 trình bày các thành phần cần phải mô tả trong một đặc tả ca sử dụng thông thƣờng. 2.2.1. Đặc tả yêu cầu chức năng và phi chức năng Yêu cầu có thể đƣợc hiểu là những phát biểu mong muốn (prescriptive statements) dùng để thể hiện một nhu cầu sử dụng và các ràng buộc, điều kiện liên quan của nó. Tài liệu đặc tả yêu cầu thể hiện các yêu cầu phần mềm dƣới một dạng cụ thể, hỗ trợ cho quá trình giao tiếp, sao chép, lƣu trữ. Tài liệu đặc tả yêu cầu cần phải đề cập đến mục tiêu và phạm vi của phần mềm, với các diễn đạt về những việc mà phần mềm sẽ làm, những lợi ích, đối tƣợng và mục đích mà phần mềm đƣợc ứng dụng. Ngoài những trình bày về các yêu cầu, tài liệu đặc tả yêu cầu cũng cần cung cấp những thông tin khác nhƣ hạn chế của phần mềm, các lệ thuộc bên ngoài có thể ảnh hƣởng tới yêu cầu, giao diện giao tiếp, bộ nhớ, các chuẩn dữ liệu và thủ tục đƣợc sử dụng. 3
Có thể chia yêu cầu thành hai loại: yêu cầu chức năng và yêu cầu phi chức năng. Trong kỹ thuật phần mềm, một yêu cầu phi chức năng là một yêu cầu phần mềm đƣợc sử dụng không phải để diễn tả phần mềm sẽ làm gì, mà sẽ diễn tả phần mềm sẽ làm điều đó nhƣ thế nào. Yêu cầu phi chức năng có nhiều thành phần, trong đó có thể kể đến các yêu cầu về hiệu năng phần mềm, yêu cầu giao diện bên ngoài, các ràng buộc thiết kế phần mềm, các thuộc tính đánh giá chất lƣợng phần mềm. Các yêu cầu phi chức năng thƣờng rất khó để kiểm chứng, vì vậy nên chúng thƣờng đƣợc đánh giá chủ quan. Yêu cầu phi chức năng có vai trò quan trọng đối với chất lƣợng phần mềm, ảnh hƣởng trực tiếp đến tính nhất quán của phần mềm và mức độ thỏa mãn của ngƣời sử dụng. Ngƣợc lại với yêu cầu phi chức năng là các yêu cầu chức năng. Yêu cầu chức năng nắm bắt những hành vi dự kiến của hệ thống. Những hành vi này có thể đƣợc thể hiện dƣới dạng dịch vụ, tác vụ hoặc chức năng mà hệ thống đƣợc yêu cầu thực hiện. Các yêu cầu chức năng có thể liên quan đến tính toán, chi tiết kỹ thuật, điều chỉnh và xử lý dữ liệu, và các chức năng cụ thể khác để mô tả chi tiết những mục tiêu của hệ thống. Các yêu cầu chức năng và các yêu cầu phi chức năng thƣờng hỗ trợ lẫn nhau, giúp áp đặt các ràng buộc đối với thiết kế hoặc triển khai, đảm bảo những yêu cầu về hiệu suất, bảo mật hoặc độ tin cậy. 2.2.2. Đặc tả ca sử dụng Ca sử dụng (use case) là tài liệu mô tả từ đầu đến cuối hành vi của hệ thống từ góc nhìn của ngƣời dùng [2]. Ca sử dụng mô tả sự tƣơng tác đặc trƣng giữa ngƣời dùng (actor) và hệ thống (system). Mỗi ca sử dụng sẽ mô tả cách thức ngƣời dùng tƣơng tác với hệ thống nhằm đạt đƣợc mục tiêu nhất định nào đó. Ngoài ra, ca sử dụng cũng xác định trình tự các bƣớc mô tả mọi tƣơng tác giữa ngƣời dùng và hệ thống. Tuy nhiên, ca sử dụng đƣợc định nghĩa theo thuật ngữ của ngƣời dùng, không phải của hệ thống, mô tả những gì mà ngƣời dùng làm và ngƣời dùng nhìn thấy hơn là những gì đầu vào hệ thống mong đợi và đầu ra của hệ thống là gì. Đặc tả ca sử dụng (use case specification) [3] tồn tại dƣới dạng một bảng ghi chú mô tả các thông tin về ca sử dụng, bao gồm các thành phần sau: (a) Tổng quan: - Use Case Name: tên ca sử dụng. - Use Case ID: mã ca sử dụng. - Use Case Description: mô tả sự tƣơng tác đƣợc thể hiện trong ca sử dụng. - Actor: đối tƣợng thực hiện sự tƣơng tác trong ca sử dụng. 4
- Priority: mức độ ƣu tiên của ca sử dụng so với các ca sử dụng còn lại. - Trigger: điều kiện kích hoạt ca sử dụng xảy ra. - Pre-condition: điều kiện cần để ca sử dụng thực hiện thành công. - Post-condition: những thứ sẽ xuất hiện sau khi ca sử dụng đƣợc thực hiện thành công. (b) Luồng tƣơng tác: - Basic Flow: luồng tƣơng tác chính giữa các tác nhân và hệ thống. - Alternative Flow: luồng tƣơng tác thay thế giữa các tác nhân và hệ thống. - Exeption Flow: luồng tƣơng tác ngoại lệ giữa các tác nhân và hệ thống. (c) Thông tin bổ sung: - Business Rule: quy định về nghiệp vụ mà hệ thống bắt buộc phải theo. - Non-funtional Requirement: vì ca sử dụng chỉ dùng để thể hiện yêu cầu chức năng nên các yêu cầu phi chức năng (nếu có) cần đƣợc bổ sung ở đây. Biểu đồ ca sử dụng (use case diagram) biểu diễn bằng hình ảnh về các hành vi của ngƣời dùng với hệ thống, cách ngƣời dùng tƣơng tác với hệ thống. Nó chỉ ra luồng đi từ hoạt động này sang hoạt động khác trong một hệ thống. Nó đặc biệt quan trọng trong việc xây dựng mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi quyền kiểm soát giữa các đối tƣợng ngƣời dùng. Hình 2.1 và Bảng 2.1 là ví dụ đơn giản nhất về đặc tả ca sử dụng, đó là ca sử dụng “Đăng nhập” vào ứng dụng quản lý nhân sự của công ty LG Electronic. Hình 2.1: Phân hệ “Quản lý xác thực ngƣời dùng”. 5
Bảng 2.1: Đặc tả ca sử dụng “Đăng nhập” của phân hệ “Quản lý xác thực ngƣời dùng” Use Case ID UC-1.1 Use Case Name Đăng nhập Description Ngƣời dùng muốn đăng nhập vào ứng dụng để sử dụng dịch vụ từ ứng dụng Actor(s) Ngƣời dùng Priority Cao nhất Trigger Ngƣời dùng muốn đăng nhập vào ứng dụng LG 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 mạng 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 lịch sử hoạt động Basic Flow 1. Ngƣời dùng truy cập ứng dụng LG 2. Ngƣời dùng chọn phƣơng thức đăng nhập bằng tài khoản LG 3. Ngƣời dùng nhập tài khoản LG 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 lịch sử hoạt động Alternative Flow Không có Exeption 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 Ca sử dụng dừng lại. 6
4c2. Ngƣời dùng chọn lệnh lấy lại mật khẩu Ca sử dụng tiếp tục ca sử dụng UC1-2. 4c3. Ngƣời dùng chọn lệnh tạo tài khoản mới Ca sử dụng tiếp tục ca sử dụng UC1-3. 4c4. Ngƣời dùng chọn lệnh khóa tài khoản Ca sử dụng tiếp tục ca sử dụng UC1-4. Business Rules BR1.1-1: Ngƣời dùng nhập sai thông tin đăng nhập ở lần thứ 5 liên tiếp sẽ bị khóa tài khoản 1 ngày. Non-functional NFR1.1-1: Thời gian cho màn hình đăng nhập dƣới 1 phút. Requirement NFR1.1-2: Mật khẩu của ngƣời dùng phải đƣợc mã hóa bằng MD5. 2.3. Kiểm thử dựa trên mô hình Phần này, luận văn sẽ trình bày các kiến thức nền tảng trong kiểm thử phần mềm nói chung và kiểm thử dựa trên mô hình nói riêng. Các kiến thức này đƣợc luận văn tìm hiểu khi nghiên cứu bài toán kiểm thử chức năng từ mô hình máy trạng thái và mô hình lớp. 2.3.1. Tổng quan kiểm thử dựa trên mô hình Kiểm thử dựa trên mô hình (Model Based Testing – MBT) [4] là một kỹ thuật của thiết kế dựa trên mô hình (Model Based Design – MBD) để tùy chọn thiết kế và thực thi các giả lập cần thiết nhằm tiến hành kiểm thử hệ thống. Nhƣ Hình 2.3 có thể thấy mô hình mô tả SUT (System Under Test) thƣờng là trừu tƣợng, trình bày một phần hành vi mong muốn của SUT. Các ca kiểm thử dẫn xuất từ mô hình nhƣ vậy đƣợc gọi chung là bộ kiểm thử trừu tƣợng (abstract test suite). Bộ kiểm thử trừu tƣợng không thể thực thi trực tiếp trên SUT, còn bộ kiểm thử thực thi đƣợc (executable test suite) có thể thực thi trực tiếp trên SUT. Các bộ kiểm thử trừu tƣợng chỉ tồn tại về mặt khái niệm chứ không phải tạo tác rõ ràng. Trong một vài môi trƣờng MBT, các mô hình chứa đầy đủ thông tin để tạo ra bộ kiểm thử thực thi đƣợc một cách trực tiếp. Các thành phần trong bộ kiểm thử trừu tƣợng phải đƣợc ánh xạ bằng câu lệnh hoặc phƣơng thức cụ thể trong phần mềm để tạo ra bộ kiểm thử cụ thể (concrete test case). Điều này đƣợc gọi là giải quyết “vấn đề ánh xạ”. 7
Hình 2.2: Cài đặt MBT thông thƣờng. IXIT (Implementation eXtra Information for Testing) đề cập đến việc thực thi thêm các thông tin cần thiết để chuyển đổi bộ kiểm thử trừu tƣợng thành bộ kiểm thử thực thi đƣợc. Thông thƣờng, IXIT chứa thông tin về khai thác kiểm thử, ánh xạ dữ liệu và cấu hình SUT. Hình 2.3: Ví dụ quy trình kiểm thử dựa trên mô hình. Các dẫn xuất kiểm thử (test derivation) có thể bắt nguồn từ các mô hình theo nhiều cách khác nhau. Bởi vì kiểm thử thƣờng dựa trên phƣơng phức phỏng đoán, không có cách tiếp cận tốt nhất nào cho việc dẫn xuất kiểm thử. Tất cả các 8
tham số liên quan đến dẫn xuất kiểm thử đƣợc hợp nhất trong gói “test requirements”, “test purpose” hoặc thậm chí là “use cases”. Gói này có thể chứa các thông tin về các phần của mô hình nên đƣợc tập trung vào hoặc các điều kiện để hoàn thành quy trình kiểm thử gọi là tiêu chí dừng kiểm thử (test stopping criteria). Vì bộ kiểm thử có nguồn gốc từ mô hình chứ không phải từ mã nguồn, MBT thƣờng đƣợc xem là một dạng kiểm thử hộp đen. MBT cho các hệ thống phần mềm phức tạ, quy mô lớn vẫn đang là một lĩnh vực khó, còn nhiều bài toán cần giải quyết để phát triển. 2.3.2. Đặc tả ca kiểm thử Tùy thuộc vào từng sản phẩm phần mềm, cấu trúc ca kiểm thử sẽ khác nhau. Tuy nhiên, về cơ bản thì một ca kiểm thử bao gồm các thành phần chính nhƣ mô tả Bảng 2.2 dƣới đây. Bảng 2.2: Cấu trúc ca kiểm thử Test Case ID Đánh số định danh (ID) theo thứ tự tăng dần Module Tên thành phần đơn vị đang kiểm tra Function Big function name Tên chức năng lớn nhất Name Medium function name Tên chức năng con Test Data Dữ liệu dùng để kiểm thử (có thể ghi tên dữ liệu hoặc đƣờng dẫn lƣu file) Pre-condition Điều kiện cần để thực hiện ca kiểm thử Test Steps Mô tả chi tiết từng bƣớc thực hiện Expected Results Kết quả mong muốn theo yêu cầu Actual Results Kết quả thực tế khi kiểm thử Comments Thêm thông tin bổ sung nhƣ ảnh chụp màn hình, thông tin đăng nhập, tên chức năng khác cũng bị ảnh hƣởng, … Date Excute Test Ghi ngày tháng năm thực hiện Excute Test By Tên ngƣời thực hiện ca kiểm thử 9
Ca kiểm thử (test case) mô tả bộ dữ liệu đầu vào (input), hành động (action) hoặc sự kiện (event) và kết quả mong muốn (expected response) đối với sản phẩm. Ca kiểm thử để kiểm tra từng chức năng của sản phẩm có hoạt động đúng hay không. Quá trình phát triển ca kiểm thử có thể giúp tìm ra lỗi trong yêu cầu hoặc thiết kế sản phẩm. Vì thế, việc chuẩn bị ca kiểm thử sớm nhất có thể thông qua quy trình phát triển phần mềm là rất hữu ích. Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá chất lƣợng và là hoạt động chủ chốt trong việc đảm bảo chất lƣợng cao của sản phẩm. Thông qua chu trình "kiểm thử - tìm lỗi - sửa lỗi", chất lƣợng của sản phẩm cải tiến ngày một tốt hơn. Mặt khác, thông qua việc tiến hành kiểm thử, chúng ta biết đƣợc sản phẩm tốt ở mức độ nào. Việc kiểm thử phần mềm là một quy trình kiểm chứng để đánh giá và tăng cƣờng chất lƣợng phần mềm. 2.4. Kỹ nghệ hƣớng mô hình Phần này sẽ cung cấp kiến thức nền tảng về kỹ nghệ hƣớng mô hình nói chung, phƣơng pháp phát triển ngôn ngữ mô hình hóa nói riêng. Các khái niệm cơ bản trong phát triển hƣớng mô hình và đặc tả yêu cầu chức năng dựa vào ca sử dụng. Mục 2.4.1 giới thiệu về một số khái niệm quan trọng trong kỹ nghệ mô hình, kỹ thuật chuyển đổi mô hình sẽ đƣợc áp dụng cho việc tự động sinh biểu đồ hoạt động. Mục 2.4.2 giới thiệu về ngôn ngữ, các kiến thức liên quan đến ràng buộc đối tƣợng OCL. Mục 2.4.3 và 2.4.4 giới thiệu cái nhìn tổng quan nhất về ngôn ngữ Kermeta đƣợc sử dụng trong việc sinh biểu đồ trạng thái từ ca sử dụng và ngôn ngữ lập trình toán học AMPL đƣợc sử dụng trong việc sinh các ca kiểm thử từ biểu đồ trạng thái. 2.4.1. Chuyển đổi mô hình Chuyển đổi mô hình (model transformation) [5] là kỹ thuật quản lý mô hình thƣờng đƣợc áp dụng trong MDE. Chuyển đổi mô hình là quá trình dịch các phần tử trong các mô hình nguồn sang các dạng biểu diễn khác thông qua đặc tả chuyển đổi mô hình đƣợc định nghĩa. Đặc tả chuyển đổi bao gồm các luật chuyển để ánh xạ giữa mô hình nguồn và đích. Chuyển đổi mô hình nhƣ là trái tim và linh hồn của MDE. Việc tái cấu trúc, sát nhập, xây dựng mô hình hay việc sinh mã từ mô hình… sẽ không thể thực hiện đƣợc nếu không có công cụ và lý thuyết về chuyển đổi. Chuyển đổi mô hình đƣợc áp dụng trong MDE để phục vụ các mục đích khác nhau bao gồm: nâng cao chất lƣợng mô hình, biểu diễn các mô hình không phụ thuộc vào nền tảng (platform-independent models) nhƣ các mô hình 10
đặc tả nền tảng (platform-specific models), tiến hóa phần mềm tự động hóa (automating software evolution), các mẫu phần mềm xác định (identifying software patterns), các mô hình kỹ thuật đảo ngƣợc (reverse engineering models). Hầu hết các thông số kỹ thuật chuyển đổi mô hình đƣợc xác định thông qua một bộ các luật chuyển đổi. Các luật này chỉ rõ các siêu mô hình nguồn đƣợc ánh xạ tới các siêu mô hình đích tƣơng ứng nhƣ thế nào. Nhiều ngôn ngữ chuyển đổi xuất phát từ biểu diễn bằng ngôn ngữ ràng buộc hƣớng đối tƣợng (Object Constraint Language – OCL). OCL cho phép đặc tả chính thức các thuộc tính mô hình ở dạng biểu thức giống nhƣ OCL. Một đặc tả chuyển đổi có thể chứa nhiều định nghĩa luật chuyển. Nhiều ngôn ngữ chuyển đổi có cơ chế kiểm soát thứ tự thực thi các luật này, đƣợc gọi là lập lịch luật chuyển đổi. Việc lập lịch luật chuyển đổi có thể là ngầm định hoặc chỉ định rõ ràng. Lập lịch ngầm định dựa vào việc thực hiện tự động các mối quan hệ giữa các luật. Lập lịch rõ ràng cho phép đặc tả thứ tự thực hiện các luật một cách thủ công. Các phép chuyển đổi mô hình có thể đƣợc phân loại theo mục tiêu (target) đề ra. Một phép chuyển đổi có thể tạo ra một mục tiêu, đó có thể là một mô hình hoặc một thủ tục có tính văn bản. Khi target của phép chuyển là một mô hình thì phép chuyển đó gọi là M2M (model-to-model transformation). Khi target của phép chuyển mang tính chất văn bản thì phép chuyển đó gọi là M2T (model-to- text transformation). 2.4.2. Các ràng buộc siêu mô hình UML/OCL OCL (Object constraint language) là ngôn ngữ xây dựng mô hình phần mềm đƣợc định nghĩa nhƣ một chuẩn thêm vào UML cho phân tích và thiết kế hƣớng đối tƣợng. Các biểu thức viết trong OCL phụ thuộc vào các kiểu lớp, giao diện…) đƣợc định nghĩa trong các biểu đồ UML. Các biểu thức viết trong OCL thêm các thông tin quan trọng cho các mô hình hƣớng đối tƣợng. Các thông tin này thƣờng không thể biểu diễn trong biểu đồ. Trong UML phiên bản 1.1 các thông tin này đƣợc giới hạn bởi các ràng buộc, mỗi ràng buộc đƣợc định nghĩa nhƣ một hạn chế về giá trị nhận đƣợc (một hay nhiều) của mộ hệ thống hay mô hình hƣớng đối tƣợng. Trong UML phiên bản 2, một mô hình có thể chứa nhiều thông tin thêm hơn là chỉ có ràng buộc. Tất cả các công việc nhƣ định nghĩa truy vấn, các giá trị tham chiếu, các quy tắc nghiệp vụ hay các điều kiện trạng thái đƣợc viết bằng biểu thức trong một mô hình. OCL là ngôn ngữ chuẩn trong đó các biểu thức đƣợc viết một cách rõ ràng dễ hiểu. 11