Phương pháp sinh bộ kiểm thử từ biểu đồ tuần tự UML 2 0 và ứng dụng cho kiểm thử phần mềm

ii TÓM TẮT Luận văn này tập trung nghiên cứu phương pháp sinh bộ kiểm thử từ biểu đồ tuần tự UML 2.0 dựa trên lý thuyết kiểm thử mô hình nhằm tự động hóa quá trình kiểm thử, nâng cao hiệ

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ MÙI

PHƯƠNG PHÁP SINH BỘ KIỂM THỬ TỪ BIỂU ĐỒ TUẦN

TỰ UML 2.0 VÀ ỨNG DỤNG CHO KIỂM THỬ PHẦN MỀM

LUẬN VĂN THẠC SĨ

Ngành: Hệ thống thông tin

HÀ NỘI – 2015

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ MÙI

PHƯƠNG PHÁP SINH BỘ KIỂM THỬ TỪ BIỂU ĐỒ TUẦN TỰ UML 2.0 VÀ ỨNG DỤNG CHO KIỂM THỬ PHẦN MỀM

Ngành: Hệ thống thông tin Chuyên ngành: Hệ thống thông tin

Mã số: 60 48 01 04

LUẬN VĂN THẠC SĨ Ngành: Hệ thống thông tin

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Phạm Ngọc Hùng

HÀ NỘI – 2015

VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING AND TECHNOLOGY

TRAN THI MUI

A METHOD AND TOOL SUPPORTING FOR AUTOMATED

TESTING OF UML 2.0 SEQUENCE DIAGRAMS

THE MS THESIS Major: Information Systems

Supervisor: Dr Pham Ngoc Hung

HANOI - 2015

i

LỜI CẢM ƠN

Đầu tiên, tôi xin gửi lời cảm ơn chân thành và sâu sắc tới thầy Phạm Ngọc Hùng – Người đã trực tiếp hướng dẫn nhiệt tình, giúp đỡ và động viên tôi rất nhiều, cho tôi có cơ hội được tiếp xúc với các tài liệu tham khảo quý giá, góp ý cho tôi những lời khuyên chân thành trong quá trình nghiên cứu để hoàn thành đề tài này Tiếp theo tôi xin gửi lời cảm ơn đến các thầy cô giảng viên Trường Đại học Công Nghệ - Đại học Quốc Gia Hà Nội – những người đã tận tâm truyền đạt những kiến thức quý báu làm nền tảng cho tôi suốt 2 năm học

Cuối cùng, tôi xin gửi lời biết ơn sâu sắc tới gia đình vì đã luôn ở bên cạnh tôi, mang lại cho tôi nguồn động viên tinh thần to lớn và tạo mọi điều kiện thuận lợi cho tôi trong quá trình học tập và hoàn thành luận văn này

Mặc dù đã rất cố gắng nhưng luận văn sẽ không tránh khỏi những thiếu sót Rất mong nhận được ý kiến đóng góp quý báu của Thầy, Cô giáo và các bạn để luận văn được hoàn thiện hơn

Xin trân trọng cảm ơn!

Hà Nội, ngày 22 tháng 11 năm 2015

Học viên:

Trần Thị Mùi

ii

TÓM TẮT

Luận văn này tập trung nghiên cứu phương pháp sinh bộ kiểm thử từ biểu đồ tuần tự UML 2.0 dựa trên lý thuyết kiểm thử mô hình nhằm tự động hóa quá trình kiểm thử, nâng cao hiệu quả, tiết kiệm chi phí và thời gian Phương pháp này được thực hiện thông qua các bước chính sau Đầu tiên, để có được mô hình làm đầu vào cho kiểm thử, phương pháp thực hiện chuyển đổi biểu đồ tuần tự về đồ thị dòng điều khiển bằng cách tiến hành bóc, tách từng khối (fragment) trong biểu đồ tuần tự Các khối này có thể tuần tự hoặc lồng nhau, dựa vào quan hệ của chúng, tiến hành xây dựng đồ thị cho mỗi khối, sau đó lồng chúng lại nhằm sinh ra đồ thị dòng điều khiển tương ứng với biểu đồ tuần tự Kế tiếp, đồ thị dòng điều khiển được phân tích để xây dựng tập đường kiểm thử Vận dụng kỹ thuật thực thi tượng trưng (Symbolic Execution - SE) nhằm xây dựng hệ ràng buộc tương ứng cho tập đường kiểm thử Cuối cùng, sử dụng công cụ SMT solver để giải hệ các ràng buộc nhằm tìm kiếm nghiệm và từ đó sinh ca kiểm thử

Một công cụ hỗ trợ phương pháp này đã được cài đặt và thử nghiệm với một

số ví dụ đơn giản nhằm minh chứng cho tính đúng đắn và hiệu quả của phương pháp trên Kết quả thực nghiệm cho thấy tiềm năng ứng dụng của công cụ này trong việc kiểm thử tự động ở các công ty

Từ khóa: Kiểm thử dựa trên mô hình, kiểm thử tự động, biểu đồ tuần tự, đồ thị dòng điều khiển, ca kiểm thử, độ bao phủ

iii

ABSTRACT

This thesis researches a method to generate a set of test cases from the UML 2.0 sequence diagrams based on model-based testing in order to automate the testing process, increase effectiveness, reduce cost and time of testing The method follows the following steps At first, in order to have the input model for testing, it analyzes and divides the input diagram into fragments These fragments can be sequential or nested based on their relationship After that, it builds the corresponding graph for each of the fragments and merges them together in order to generate the corresponding control flow graph for the input sequence diagram The final control flow graph is analyzed to generate a set of testing paths Symbolic Execution (SE) technique is used to create restrictions associated with that set of testing paths Finally, the method uses SMT solver to solve the set of restrictions to find solution and then to generate a set of test cases

A tool is also implemented and tested with some simple examples in order to show the correctness and effectiveness of the method The experimental results give

us the potential application of the tool in automation testing in companies

Keywords: Model base testing, automated testing, sequence diagram, control flow

testing, test case

iv

LỜI CAM ĐOAN

Tôi xin cam đoan rằng những nghiên cứu về sinh tự động bộ kiểm thử từ biểu

đồ tuần tự được trình bày trong luận văn này dưới sự hướng dẫn của TS Phạm Ngọc

Hùng là của tôi Những gì tôi viết ra không sao chép từ các tài liệu, không sử dụng

các kết quả của người khác mà không trích dẫn cụ thể

Tôi xin cam đoan công cụ kiểm thử tự động tôi trình bày trong luận văn là do

tôi tự phát triển, không sao chép mã nguồn của người khác Nếu sai tôi hoàn toàn

chịu trách nhiệm theo quy định của Trường Đại học Công Nghệ - Đại học Quốc Gia

Hà Nội

Hà nội, ngày 22 tháng 11 năm 2015

Học viên:

Trần Thị Mùi

v

MỤC LỤC

LỜI CẢM ƠN i

TÓM TẮT ii

ABSTRACT iii

LỜI CAM ĐOAN iv

DANH SÁCH BẢNG BIỂU vii

DANH SÁCH HÌNH VẼ viii

BẢNG THUẬT NGỮ x

Chương 1 GIỚI THIỆU 1

Chương 2 TỔNG QUAN KIỂM THỬ DỰA TRÊN MÔ HÌNH 5

2.1 Khái niệm kiểm thử dựa trên mô hình 5

2.2 Quy trình chung của kiểm thử dựa trên mô hình 6

2.3 Phương pháp đặc tả mô hình bằng máy trạng thái UML 7

2.4 Thuận lợi và khó khăn của kiểm thử tự động dựa trên mô hình 7

Chương 3 PHƯƠNG PHÁP SINH ĐỒ THỊ DÕNG ĐIỀU KHIỂN TỪ BIỂU ĐỒ TUẦN TỰ 10 3.1 Biểu đồ tuần tự 10

3.2 Đồ thị dòng điều khiển 18

3.3 Đường kiểm thử 19

3.4 Chuyển đổi biểu đồ tuần tự sang đường kiểm thử 20

3.5 Định dạng chuẩn khi viết tệp xmi từ biểu đồ tuần tự 21

3.6 Thuật toán sinh tự động các đường kiểm thử 22

3.6.1 Thuật toán phân tích biểu đồ tuần tự 23

3.6.2 Thuật toán chuyển cấu trúc dữ liệu biểu đồ tuần tự sang đường kiểm thử 25

3.6.3 Thuật toán xác định đường kiểm thử cho khối alt 25

3.6.4 Thuật toán xác định đường kiểm thử cho khối opt và break 26

3.6.5 Thuật toán xác định đường kiểm thử cho khối loop 27

vi

3.6.6 Thuật toán xác định đường kiểm thử cho khối par và seq 29

3.6.7.Thuật toán xác định đường kiểm thử cho khối weak 30

3.6.8 Thuật toán xác định đường kiểm thử cho khối strict 31

3.6.9 Thuật toán xác định đường kiểm thử cho khối ignore 31

Chương 4 PHƯƠNG PHÁP SINH BỘ KIỂM THỬ TỪ ĐỒ THỊ DÒNG ĐIỀU KHIỂN 33

4.1 Xây dựng hệ ràng buộc 33

4.2 Tìm nghiệm thỏa mãn hệ ràng buộc 35

4.2.1 Giải hệ sử dụng kỹ thuật sinh ngẫu nhiên 35

4.2.2 Giải hệ sử dụng SMT-Solver 35

4.2.3 Nhận xét ưu điểm, nhược điểm của hai hướng sinh ca kiểm thử 43

Chương 5 THỰC NGHIỆM 44

5.1 Giới thiệu công cụ 44

5.2 Thực nghiệm 45

5.3 Ý nghĩa của thực nghiệm 54

Chương 6 KẾT LUẬN 55

TÀI LIỆU THAM KHẢO 57

vii

DANH SÁCH BẢNG BIỂU

Bảng 4.1 Độ ưu tiên các toán tử 39Bảng 5.1 Môi trường thử nghiệm công cụ sinh ca kiểm thử từ thiết kế 45

viii

DANH SÁCH HÌNH VẼ

Hình 2.1 Quy trình của kiểm thử dựa trên mô hình [11] 6

Hình 3.1 Toán tử tương tác alt 11

Hình 3.2 Toán tử tương tác opt 12

Hình 3.3 Toán tử tương tác loop vô hạn 12

Hình 3.4 Toán tử tương tác loop với cận trên = cận dưới = 10 12

Hình 3.5 Toán tử tương tác loop với cận trên = 5, cận dưới = 10 12

Hình 3.6 Toán toán tử tương tác break 13

Hình 3.7 Toán tử tương tác par 14

Hình 3.8 Một số thứ tự thực hiện của toán tử tương tác par 14

Hình 3.9 Toán tử tương tác seq 15

Hình 3.10 Toán tử tương tác strict 15

Hình 3.11 Toán tử tương tác ignore 16

Hình 3.12 Toán tử tương tác consider 16

Hình 3.13 Toán tử tương tác neg 17

Hình 3.14 Toán tử tương tác assert 17

Hình 3.15 Toán tử tương tác critical 18

Hình 3.16 Đồ thị dòng điều khiển tương ứng với biểu đồ tuần tự 19

Hình 3.17 Chuyển biểu đồ tuần tự thành đường kiểm thử 20

Hình 4.1 Ví dụ một hệ ràng buộc 33

Hình 4.2 Quá trình rút gọn câu lệnh 35

Hình 4.3 Mô tả đầu vào, đầu ra SMT-Solver 37

Hình 4.4 Ví dụ hệ ràng buộc tuân theo chuẩn SMT-Lib 38

Hình 4.5 Quá trình chuyển một biểu thức trung tố về chuẩn SMT-Lib 39

Hình 5.1 Kiến trúc công cụ 45

Hình 5.2 Hình vẽ biểu đồ tuần tự tương ứng với ví dụ 1 46

ix

Hình 5.3 Kết quả đầu ra công cụ của ví dụ 1 50 Hình 5.4 Hình vẽ biểu đồ tuần tự tương ứng với ví dụ 2 53 Hình 5.5 Kết quả đầu ra công cụ của ví dụ 2 53

x

BẢNG THUẬT NGỮ

1 CFG Control Flow Graph Đồ thị dòng điều khiển

2 SMT-Solver Satisfiability Modulo

Theories Solver

Lý thuyết modul thỏa mãn

3 SAT Boolean Satisfiability

Problem

Vấn đề thỏa mãn biểu thức logic

4 T-Solver Theory-specific Solvers Lý thuyết giải quyết đặc biệt

5 SE Symbolic Execution Kỹ thuật thực thi tƣợng trƣng

1

Kiểm thử là giai đoạn quan trọng và không thể thiếu trong quá trình phát triển phần mềm Quá trình kiểm thử trải qua hai giai đoạn: sinh ca kiểm thử và thực thi

ca kiểm thử Trong quá trình kiểm thử, việc sinh các ca kiểm thử đóng vai trò quyết định đến chất lượng kiểm thử Tuy nhiên, đây là bước khó khăn và thách thức nhất, đặc biệt đối với các hệ thống lớn không những phức tạp để kiểm thử mà còn đòi hỏi một số lượng lớn các ca kiểm thử được tạo ra Quá trình này tốn thời gian, công sức

và chi phí có thể chiếm 40% – 60% tổng chi phí trong toàn bộ quá trình phát triển phần mềm [9] Vì vậy, quá trình sinh các ca kiểm thử tự động trở nên thực sự cần thiết, nhất là đối với những phần mềm lớn và phức tạp Kiểm thử tự động đang được xem là giải pháp chính nhằm đảm bảo chất lượng mà vẫn giảm chi phí và thời gian trong quá trình phát triển các sản phẩm phần mềm

Trong đó, kiểm thử dựa trên mô hình là một trong những kỹ thuật kiểm thử đang được sử dụng ngày càng rộng rãi trong việc kiểm thử các sản phẩm phần mềm Tuy nhiên, để áp dụng phương pháp này, ta cần phải có các mô hình toán học đặc tả

chính xác hành vi của hệ thống và có sẵn trong thực tế Các mô hình này thường

được biểu diễn bằng các máy hữu hạn trạng thái đơn định Xây dựng mô hình cho các phần mềm là một công việc khó khăn và tiềm ẩn nhiều lỗi đối với các công ty Thay vào đó, việc phân tích và xây dựng nên các biểu đồ tuần tự UML là một công việc dễ dàng và phổ biến Do đó, việc kiểm thử tính đúng đắn cho thiết kế dựa trên

mô hình là một vấn đề mở và chưa có lời giải thỏa đáng

Hiện nay, có nhiều hướng nghiên cứu liên quan đến việc sinh mô hình cho phần mềm đã được đề xuất bởi nhiều tác giả Một hướng là tập trung vào nghiên cứu các phương pháp sinh mô hình cho phần mềm Với cách tiếp cận này, ta có thể

kể đến các phương pháp sinh mô hình được đề cập trong [19], [20], [21], và [22] Trong [19], các tác giả đã đặt ngữ cảnh là xây dựng mô hình cho phần mềm được cho dưới dạng một hộp đen và ta có thể thử nghiệm thực thi các hành động trên nó

để có thể xây dựng được một tập các chuỗi hành động của phần mềm Sau đó, tập

2

các chuỗi hành động của phần mềm thu được có thể được coi là một biểu thức chính quy đặc tả hành vi của phần mềm, các tác giả sau đó đã sử dụng thuật toán Thompson để sinh mô hình cho phần mềm được cho bởi biểu thức chính quy đó Phương pháp này bị giới hạn bởi độ dài tối đa của chuỗi các hành động có thể thử nghiệm trên phần mềm Nghiên cứu trong [20] trình bày một thuật toán gọi là GK-tail mà tự động sinh mô hình cho phần mềm dưới dạng các EFSM (Extended Finite State Machine) từ các chuỗi tương tác của nó EFSM mô hình hóa sự tương tác giữa các giá trị dữ liệu và phần mềm bằng cách ghi chú lên các cạnh của ôtômát hữu hạn

đó với các điều kiện trên các giá trị dữ liệu Trong nghiên cứu này, các tác giả đã đề cập một khía cạnh rất quan trọng của phần mềm Đó là mô hình hóa các lời gọi hàm trong quan hệ với các tham số của nó Phương pháp này dựa vào một phần mềm gọi

là phần mềm giám sát để có thể sinh ra được các chuỗi tương tác mà được dùng như

là đầu vào của nó Nghiên cứu [21] giới thiệu một tập tích hợp các chương trình phân tích, chuyển đổi thành phần gọi là Bandera mà tự động trích xuất mô hình cho chương trình phần mềm dựa trên mã nguồn Trong nghiên cứu này, Bandera lấy mã nguồn Java như là đầu vào để sinh mô hình dưới dạng đầu vào cho một số công cụ khác Ngoài ra, Bandera cũng tham chiếu trở lại mã nguồn ban đầu với mô hình đã được sinh ra Phương pháp này rõ ràng là phụ thuộc vào mã nguồn của phần mềm cần phân tích Do đó, đối với các phần mềm hướng thành phần không có mã nguồn của một số thành phần mua từ bên phát triển thứ ba thì phương pháp này rất khó khả thi Nghiên cứu [22] giới thiệu một công cụ gọi là Bandera Environment Generator (BEG) Công cụ này tự động hóa việc sinh mô hình môi trường để cung cấp một dạng hạn chế của việc kiểm chứng mô hình các mô đun của chương trình Java Công cụ này sinh mô hình cho đơn vị chương trình Java dựa trên một số giả định về môi trường được cung cấp bởi người dùng Mô hình đã được sinh ra có thể được dùng trong việc phân tích ảnh hưởng của môi trường lên đơn vị trong phương pháp kiểm chứng mô hình Đây là một vấn đề rất thách thức trong thực tế phát triển phần mềm vì hệ thống phần mềm luôn phải chạy trên một sự kết hợp của rất nhiều

hệ thống khác như hệ điều hành, các hệ thống khác,v.v Người dùng, thậm chí cả

đó Biểu thức chính quy đó là kết quả của khâu thiết kế, có thể được sinh ra từ từ biểu đồ tuần tự theo phương pháp được đề cập trong [23] Tuy phương pháp này sinh được mô hình cho phần mềm, nhưng sử dụng nhiều thời gian và bộ nhớ Đặc biệt là phương pháp này bị giới hạn bởi độ dài tối đa của một chuỗi hành vi của phần mềm Do đó, phương pháp này rất khó áp dụng được trong thực tế Nghiên cứu [24] đặt vấn đề cho việc kiểm thử hộp đen Trong nghiên cứu này, nhiều chiến lược được trình bày để kiểm chứng phần mềm từ khi chúng ta chưa có mô hình Mô hình được sinh ra trong các lần lặp kiểm chứng phần mềm Nghiên cứu [25] trình bày một phương pháp sinh mô hình thành phần phần mềm trong quá trình thành phần đó tiến hóa Những mô hình này được sinh ra sử dụng các mô hình chưa đúng hiện có dựa vào các kỹ thuật kiểm thử hộp đen và học máy Tuy nhiên, phương pháp này sinh mô hình cho toàn bộ phần mềm Với những phần mềm lớn thì phương pháp này có thể dẫn đến sự bùng nổ trạng thái của mô hình Với cách tiếp cận này, những mô hình được sinh ra như là một phần của quá trình khác như kiểm thử hộp đen, kiểm chứng mô hình Luận văn này tập trung vào việc chỉ sinh mô hình cho thành phần phần mềm Bằng cách này, chúng ta tập trung vào việc có được

mô hình bằng một cách thực tế hơn như từ biểu đồ tuần tự [23] Những mô hình này sau đó có thể được dùng như là đầu vào cho các phương pháp khác như kiểm chứng

mô hình, kiểm thử dựa trên mô hình

Để giải quyết vấn đề trên, trong luận văn này, tôi nghiên cứu về phương pháp nhằm xây dựng một công cụ hỗ trợ phân tích biểu đồ dòng điểu khiển dựa trên biểu

đồ tuần tự UML 2.0 và ứng dụng để sinh bộ kiểm thử

4

Phương pháp nghiên cứu gồm hai quá trình chính là chuyển đồi biểu đồ tuần

tự về đồ thị dòng điều khiển và từ đồ thị dòng điều khiển sinh bộ kiểm thử Biểu đồ tuần tự được cung cấp dưới dạng tệp xmi sẽ được phân tích để cho ra một đường kiểm thử tương ứng đặc tả hoạt động Đây chính là giá trị đầu vào Qua quá trình phân tích, dữ liệu từ tệp xmi được chuyển đổi thành cấu trúc dữ liệu biểu đồ tuần tự tương ứng Ứng với mỗi khối trong biểu đồ tuần tự, tiến hành bóc, tách từng khối và dựa vào quan hệ giữa các khối để lồng các khối nhằm sinh ra đồ thị dòng điều khiển Kế tiếp, một đường kiểm thử tương ứng được trả về đặc tả chính xác hoạt động của đồ thị dòng điều khiển Kỹ thuật được sử dụng để xây dựng hệ ràng buộc tương ứng cho tập đường kiểm thử ở đây là thực thi tượng trưng (symbolic execution - SE) Cuối cùng, bằng cách kết hợp kỹ thuật sinh ngẫu nhiên và tận dụng thế mạnh các công cụ giải các hệ ràng buộc (SMT-Solver), hệ ràng buộc được giải

để sinh ca kiểm thử Bộ kiểm thử này sẽ được sử dụng để kiểm tra xem việc lập trình có đúng với thiết kế hay không

Phần còn lại của luận văn được cấu trúc như sau: Chương 2 trình bày cơ sở lý thuyết của kiểm thử mô hình, bao gồm các khái niệm cơ bản, quy trình thực hiện, phương pháp đặc tả mô hình bằng máy trạng thái UML, thuận lợi và khó khăn của kiểm thử dựa trên mô hình và áp dụng cho kiểm thử phần mềm Phương pháp sinh

đồ thị dòng điều khiển từ biểu đồ tuần tự bao gồm tổng quan về đồ thị dòng điều khiển, cách đặc tả biểu đồ tuần tự, phương pháp sinh đồ thị dòng điều khiển được trình bày trong chương 3 Chương 4 trình bày về phương pháp sinh ca kiểm thử từ đồ thị dòng điều khiển bao gồm bước xây dựng hệ ràng buộc và bước tìm nghiệm thỏa mãn hệ ràng buộc dựa trên SMT - Solver Chương 5 trình bày kết quả

đã đạt được Cuối cùng, chương 6 tóm tắt lại nội dung nghiên cứu, đưa ra những hạn chế và hướng nghiên cứu phát triển trong tương lai

5

Khi chạy một dự án phần mềm, yêu cầu từ phía khách hàng là yếu tố để hình thành và phát triển dự án Thực tế, các yêu cầu này thường không ổn định mà sẽ thay đổi tùy theo nhu cầu của khách hàng Mỗi khi có sự thay đổi xảy ra, thường sẽ kéo theo những thứ khác ảnh hưởng Vì thế, hoạt động kiểm thử phải thực hiện để đảm bảo chất lượng của sản phẩm Có những trường hợp, một sự thay đổi nhỏ cũng

có thể gây ảnh hưởng lớn, kéo theo việc kiểm thử viên có thể không đáp ứng được tiến độ của dự án đề ra

Như vậy, việc phát triển một phương pháp kiểm thử để hạn chế tác động của

sự thay đổi, đồng thời tiết kiệm được chi phí về thời gian và tiền bạc là thực sự cần thiết Phương pháp kiểm thử dựa trên mô hình nhằm kiểm tra tính đúng đắn của lập trình so với thiết kế, là giải pháp giúp giải quyết được vấn đề trên Trong chương này, tôi sẽ trình bày lý thuyết về phương pháp kiểm thử dựa trên mô hình và ứng dụng cho kiểm thử phần mềm

2.1 Khái niệm kiểm thử dựa trên mô hình

Trong quá trình kiểm thử tự động phần mềm, kiểm thử viên trước tiên sẽ tạo ra các kịch bản kiểm thử bằng cách ghi lại tính năng của phần mềm đó Sau đó, kiểm thử viên tiến hành kiểm thử theo kịch bản đã được tạo ra với những tham số khác nhau Quá trình kiểm thử được chạy tự động Tuy nhiên, việc tạo kịch bản kiểm thử lại được tiến hành thủ công Hầu hết các công cụ kiểm thử ngày nay đều kiểm thử

tự động dựa trên các kịch bản có sẵn, do đó việc tạo kịch bản tốn nhiều công sức của kiểm thử viên và mất rất nhiều thời gian Để tránh việc sai sót trong quá trình kiểm thử, việc tạo kịch bản phải được xây dựng chu đáo Thêm vào đó, mỗi khi yêu cầu từ phía người dùng thay đổi thì kịch bản cũng phải thay đổi theo Vì vậy, việc tạo tự động các kịch bản kiểm thử là thật sự cần thiết Hướng tiếp cận ở đây là kiểm thử dựa trên mô hình nhằm khắc phục được các vấn đề về chi phí, thời gian Kiểm thử dựa trên mô hình là một phương pháp kiểm thử nơi mà các ca kiểm thử được sinh ra từ mô hình đặc tả hành vi của hệ thống đang được kiểm thử Mô hình này

6

được biểu diễn bằng máy hữu hạn trạng thái, ôtômat, đặc tả đại số, biểu đồ trạng thái bằng UML, v.v [1]

2.2 Quy trình chung của kiểm thử dựa trên mô hình

Quá trình kiểm thử tự động dựa trên mô hình được bắt đầu bằng việc xác định yêu cầu của hệ thống từ đó xây dựng mô hình dựa vào các yêu cầu và chức năng của hệ thống Việc xây dựng mô hình còn phải dựa trên các yếu tố dữ liệu đầu vào

và đầu ra Mô hình này được sử dụng để sinh đầu vào cho các ca kiểm thử Tiếp đến, chúng ta sẽ sinh giá trị đầu ra mong muốn ứng với mỗi bộ đầu vào Khi kết thúc bước này, chúng ta đã có các ca kiểm thử [1] Các ca kiểm thử đó được tiến hành chạy và kết quả thu được sẽ được so sánh với kết quả mong đợi Từ đó quyết định hành động tiếp theo như sửa đổi mô hình hoặc dừng kiểm thử, v.v

Hình 2.1 Quy trình của kiểm thử dựa trên mô hình [11]

Hình 2.1 mô tả về quy trình chung của kiểm thử tự động dựa trên mô hình Kiểm thử tự động dựa trên mô hình gồm các giai đoạn sau:

7

- Sinh mô hình dựa trên các yêu cầu và chức năng của hệ thống

- Sinh các ca kiểm thử (bộ đầu vào và giá trị đầu ra mong đợi cho mỗi ca kiểm thử)

- Chạy các kịch bản kiểm thử để phát hiện các lỗi/khiếm khuyết của sản phẩm

- So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến

- Quyết định hành động tiếp theo (sửa đổi mô hình, tạo thêm ca kiểm thử, dừng kiểm thử, đánh giá chất lượng của phần mềm) [1]

2.3 Phương pháp đặc tả mô hình bằng máy trạng thái UML

Theo [1], phương pháp đặc tả mô hình bằng máy trạng thái thường được áp dụng trong công nghiệp Nó có thể được sử dụng để đặc tả hành vi động (chuyển trạng thái) của các lớp đối tượng, các ca sử dụng (use cases), các hệ thống con và thậm chí là toàn bộ hệ thống Tuy nhiên, máy trạng thái UML thường được sử dụng cho các lớp đối tượng Theo [10], biểu đồ cộng tác đặc tả bằng UML là một mô hình quan trọng trong việc kiểm thử hệ thống bởi mô hình này đặc tả chính xác hành vi (tương tác giữa các đối tượng) của hệ thống cần kiểm thử Trong UML, một trạng thái ứng với một điều kiện quan trọng của một đối tượng Trạng thái này được quyết định bởi các giá trị hiện thời của đối tượng, các mối quan hệ với các đối tượng khác và các hành động (phương thức) mà đối tượng này thực hiện Một phép chuyển trạng thái là mối quan hệ giữa hai trạng thái Một phép chuyển trạng thái trong UML bao gồm một sự kiện được kích hoạt, điều kiện và hành động tương ứng Các sự kiện được kích hoạt của các phép chuyển trạng thái có thể là một trong các sự kiện sau:

- Một lời gọi ứng với một phương thức

- Một tín hiệu nhận được từ các trạng thái khác trong máy trạng thái

- Một sự thay đổi giá trị của một thuộc tính nào đó của một đối tượng

- Hết thời gian (timeout)

2.4 Thuận lợi và khó khăn của kiểm thử tự động dựa trên mô hình

Trong quá trình phát triển phần mềm, các kiểm thử viên thường thực hiện công việc của mình bằng các phương pháp truyền thống (thủ công) nên thời gian và

8

chi phí dành cho các hoạt động này thường rất cao Kiểm thử dựa trên mô hình hứa hẹn sẽ là một giải pháp hiệu quả nhằm góp phần giải quyết vấn đề này [1]

Cụ thể, kiểm thử dựa trên mô hình có các ưu điểm sau:

- Giảm chi phí và thời gian: Do quá trình kiểm thử hầu hết được thực hiện tự động nên tính hiệu quả của phương pháp này rất cao trong khi thời gian được giảm một cách tối thiểu

- Độ bao phủ tốt hơn: Nếu mô hình của hệ thống được xây dựng tốt thì quá trình kiểm thử dựa trên mô hình sinh ra nhiều ca kiểm thử và phát hiện nhiều lỗi Kiểm thử mô hình cũng cho phép giảm các lỗi chủ quan do người kiểm thử sinh ra trong quá trình kiểm thử sản phẩm

- Đầy đủ tài liệu: Mô hình hệ thống, các đường đi, các ca kiểm thử là các tài liệu quan trọng trong quá trình phát triển phần mềm nói chung và quá trình kiểm thử phần mềm nói riêng Các tài liệu này cũng giúp cho các kiểm thử viên hiểu hơn về các ca kiểm thử và các kịch bản kiểm thử

- Khả năng sử dụng lại cao: Mỗi khi phần mềm bị tiến hóa, chúng ta dễ dạng sinh thêm các ca kiểm thử và kiểm thử lại một cách nhanh chóng và hiệu quả

- Hiểu hơn về hệ thống: Kiểm thử dựa trên mô hình giúp người phát triển hiểu hơn về hệ thống cần kiểm thử thông quan việc xây dựng và phân tích mô hình hệ thống

- Sớm phát hiện lỗi và sự không rõ ràng trong đặc điểm kỹ thuật và thiết kế vì vậy sẽ tăng thời gian giải quyết vấn đề trong kiểm thử

- Tự động tạo và kiểm tra nhằm tránh các ca kiểm thử trùng nhau hoặc không hữu hiệu

- Kiểm thử dựa trên mô hình có khả năng đánh giá chất lượng phần mềm

Tuy nhiên, kiểm thử dựa trên mô hình không dễ được áp dụng trong thực tế vì một số khó khăn sau:

- Khó xây dựng mô hình chính xác: Kiểm thử dựa trên mô hình cần có mô hình đặc tả chính xác hành vi của hệ thống Trong thực tế, việc xây dựng mô hình là rất khó, tốn kém và tiềm ẩn nhiều lỗi

9

- Yêu cầu cao về kiểm thử viên: Do phải xây dựng mô hình của hệ thống vì vậy người kiểm thử phần mềm phải yêu cầu là những người có khả năng phân tích và thiết kế hệ thống Hơn nữa, người kiểm thử cần có kiến thức tốt về các phương pháp hình thức và đặc tả hình thức, có hiểu biết chi tiết và chính xác về hệ thống

- Tạo giá trị đầu ra mong đợi cho các ca kiểm thử là một trong những vấn đề khó khăn nhất của kiểm thử dựa trên mô hình

- Khó khăn trọng việc sử dụng các ca kiểm thử được tạo ra từ mô hình: Lập trình viên tiến hành cài đặt hệ thống một cách độc lập nên khi đã cài đặtxong thường khó thực thi các ca kiểm thử được tạo ra từ mô hình vì rấtnhiều lý do khác nhau Thông thường, họ phái tiền hành nghiên cứu mô hình và đặc tả lại các ca kiểm thử mới sử dụng được chúng Hơn nữa, mô hình hệ thống thường trừu tượng

và tổng quát hơn cài đặt của nó Vấn đề này là một trong những lý do chính của hạn chế này

là đúng đắn phương pháp đưa ra một mô hình giả định đặc tả môi trường của hệ thống Ngược lại, phương pháp trả về một phản ví dụ chứng minh thiết kế không thỏa mãn thuộc tính của hệ thống Điều đó giúp quá trình kiểm thử đơn giản và tiết kiệm chi phí hơn

3.1 Biểu đồ tuần tự

Biều đồ tuần tự là biểu đồ thể hiện các trình tự sự kiện dẫn đến các kết quả mong muốn Biểu đồ ít quan tâm vào các thông điệp, mục đích chính là trình tự các thông điệp xảy ra, biểu đồ tuần tự sẽ truyền đạt nội dung những thông điệp được gửi giữa các đối tượng trong một hệ thống cũng như thự xảy ra Thành phần chính của biểu đồ tuần tự gồm: Đối tượng, thông điệp và phân đoạn

- Đối tượng:

Được biểu diễn bằng 2 phần: phần tiêu đề khai báo đối tượng và chu kỳ sống, các đối tượng tương tác với nhau thông qua các thông điệp Thời gian đối tượng tồn tại được biểu diễn bằng đường đứt nét, chu kỳ sống biểu diễn bằng đường nét đôi

11

đoạn con (gọi là các toán hạng tương tác –interaction operands) Tương ứng với cấu trúc điều khiển trong các ngôn ngữ lập trình như lặp, rẽ nhánh, song song, chúng ta

có các phân đoạn khác nhau với các nhãn tương ứng là loop, alt, par, v.v

Toán tử tương tác lựa chọn đầy đủ (Alternative) chỉ ra rằng phân đoạn kết hợp

(Combined Fragment) biểu diễn một sự lựa chọn hành vi Toán hạng trong phân đoạn có biểu thức gác (guard expression), nếu biểu thức gác đúng thì toán hạng được thực thi Nếu toán hạng không có biểu thức gác thì biểu thức được ngầm hiểu

là true Nếu biểu thức gác là else, toán hạng sẽ được thực thi khi các điều kiện gác của các toán hạng khác sai Hình 3.1 là ví dụ minh họa nếu số dư (balance) trong tài khoản lớn hơn 0 thì cho phép rút tiền (accept()), nếu không thì từ chối (reject())

Hình 3.1 Toán tử tương tác alt

Toán tử tương tác lựa chọn không đầy đủ (Option) chỉ ra rằng phân đoạn kết

hợp biểu diễn một sự lựa chọn hành vi Trong phân đoạn chỉ có một toán hạng, toán hạng này có thể được thực thi hoặc không được thực thi tùy vào điều kiện gác Toán

tử opt gần giống với toán tử alt, chỉ có điều trong opt chỉ có một toán hạng duy nhất Hình 3.2 là ví dụ minh hoạ thực hiện đăng bình luận (post_comments()) nếu không có lỗi (no errors)

Toán tử tương tác lặp (Loop) chỉ ra rằng phân đoạn kết hợp biểu diễn một vòng

lặp.Toán hạng lặp sẽ được lặp đi lặp lại một số lần Điều kiện gác có thể gồm một cận dưới (minint), một cận trên (maxint) và một biểu thức Boolean Sau minint lần lặp, biểu thức được kiểm tra, chừng nào biểu thức còn đúng và số lần lặp còn nhỏ hơn hoặc bằng maxint thì vòng lặp vẫn tiếp tục

13

Hình 3.3 miêu tả toán tử loop với vòng lặp vô hạn Hình 3.4 miêu tả toán tử loop với vòng lặp với cận trên bằng cận dưới và bằng 10, không có điều kiện cần kiểm tra Hình 3.5 miêu tả sau khi lặp hết 5 lần, nếu điều kiện size < 0 đúng thì dừng lặp, việc kiểm tra này còn thực hiện chừng nào số lần lặp còn <= 10

Toán tử tương tác break chỉ ra rằng khi điều kiện gác đúng thì toán hạng trong

phân đoạn kết hợp break sẽ được thực thi thay cho phần còn lại của phân đoạn tương tác (Interaction Fragment) bao gói bên ngoài Hình 3.6 là ví dụ minh họa: Nếu y > 0 thì thực hiện save() rồi thoát luôn khỏi vòng lặp

loop(10)

add()

save()

Hình 3.6 Toán toán tử tương tác break

Toán tử tương tác song song (Parallel) chỉ ra rằng các toán hạng trong phân đoạn

kết hợp có thể được thực thi song song với nhau Các sự kiện trong các toán hạng khác nhau có thể đan xen vào nhau theo bất cứ cách nào, miễn là thứ tự của các sự kiện trong mỗi toán hạng được bảo toàn Hình 3.7 và 3.8 là ví dụ minh họa thứ tự thực hiện các toán tử

Toán tử tương tác tuần tự yếu (weak sequencing) chỉ ra rằng phân đoạn kết hợp

biểu diễn một trình tự yếu giữa các hành vi của các toán hạng Trình tự yếu được định nghĩa bởi tập các vết với các đặc tính:

- Thứ tự của các sự kiện (EventOccurences) trong mỗi một toán hạng được duy trì

- Các sự kiện trên các lifeline khác nhau ở các toán hạng khác nhau được có thể xảy

ra theo thứ tự bất kỳ

- Các sự kiện trên cùng lifeline ở các toán hạng khác nhau được sắp thứ tự sao cho một sự kiện của toán hạng thứ nhất xảy ra trước sự kiện của toán hạng thứ hai

1b: searchBing() 3: readResult()

2: readResult() 1a: searchGoogle()

Hình 3.7 Toán tử tương tác par

15

seq

search_google()

search_yahoo() search_bing()

Hình 3.9 Toán tử tương tác seq

Toán tử tương tác tuần tự ngặt (Strict sequencing) chỉ ra rằng phân đoạn kết hợp

biểu diễn một trình tự ngặt giữa các hành vi của các toán hạng Hình 3.10 là ví dụ minh họa: Tìm bằng Google, rồi đến tìm bằng Bing, sau đó là Yahoo

strict

search_google()

search_yahoo() search_bing()

Hình 3.10 Toán tử tương tác strict

Toán tử tương tác từ chối (ignore) chỉ ra rằng có một số kiểu thông điệp không

được hiển thị trong phân đoạn kết hợp này Các kiểu thông điệp này có thể bị coi là

Hình 3.11 Toán tử tương tác ignore

Toán tử tương tác lưu ý (consider) chỉ ra những thông điệp nên được lưu ý trong

phân đoạn kết hợp này Điều này tương đương với việc định nghĩa mọi thông điệp khác là bị bỏ qua Ví dụ minh họa trong hình 3.12: Lưu ý đến add() và remove(), bỏ qua các thông điệp khác

consider {add, remove}

add()

remove()

Hình 3.12 Toán tử tương tác consider

Toán tử tương tác phủ định (Negative) chỉ ra rằng phân đoạn kết hợp biểu diễn

các vết (traces) được định nghĩa là không hợp lệ Phân đoạn neg được sử dụng trong

ví dụ trên để xác định rằng không được phép mở cửa của lò vi sóng trong khi đang nấu được minh họa trong hình 3.13

17

Chef

Open Insert Food

Close Set time and Power

Start

Lock Open

neg

loop Cooking

[1, time]

Rotate Platter Generate

Unlock Open

Remove Food Finish

Hình 3.13 Toán tử tương tác neg

Toán tử tương tác quyết định (Assertion) chỉ ra rằng phân đoạn kết hợp biểu diễn

các vết hợp lệ Toán tử assert thường được sử dụng cùng với ignore hoặc consider Hình 3.14 minh họa: Khối assert chỉ chấp nhận thông điệp q là hợp lệ, do đó nếu thông điệp w xảy ra thay cho q thì w không hợp lệ

consider{q ,v ,w}

2 : q() assert

1 : v()

Hình 3.14 Toán tử tương tác assert

18

Toán tử tương tác vùng then chốt (Critical region) chỉ ra rằng phân đoạn kết hợp

biểu diễn một vùng then chốt Một vùng then chốt nghĩa là các vết trong vùng này không thể bị đan xen bởi các sự kiện (EventOccurence) khác (trên các lifeline bị phủ bởi vùng này) Hình 3.15 minh họa: Các cuộc gọi cho 911 phải nối tiếp, không được chồng lấn nhau Điều hành viên (operator) phải chuyển tiếp cuộc gọi cho số

911 trước khi làm bất cứ thứ gì khác Các cuộc gọi thường thì đan xen nhau thoải mái

call(101) call(101)

call(911) call(911)

Hình 3.15 Toán tử tương tác critical

3.2 Đồ thị dòng điều khiển

Sinh ca kiểm thử dựa trên biều đồ tuần tự phức tạp và khó khăn hơn so với sinh ca kiểm thử dựa trên đồ thị dòng điều khiển (Control Flow Graph – CFG) CFG là một đồ thị có hướng mô tả cấu trúc lôgic của chương trình một cách trực quan và đơn giản hơn, gồm có các đỉnh tương ứng với các câu lệnh/nhóm câu lệnh

và các cạnh là các dòng điều khiển giữa các câu lệnh/nhóm câu lệnh Đỉnh đầu tiên của CFG là trạng thái đầu tiên của hàm, đỉnh cuối cùng của CFG là trạng thái kết

- Đỉnh xuất phát: là điểm bắt đầu của đơn vị chương trình

- Khối xử lý: chứa các câu lệnh khai báo hoặc tính toán

- Điểm quyết định: ứng với các câu lệnh điều kiện trong các khối lệnh rẽ

nhánh hoặc lặp

- Điểm nối: ứng với các câu lệnh ngay sau các lệnh rẽ nhánh

- Điểm kết thúc: ứng với điểm kết thúc của đơn vị chương trình

Hình 3.16 Đồ thị dòng điều khiển tương ứng với biểu đồ tuần tự

3.3 Đường kiểm thử

Với một bộ giá trị đầu vào, một tập các câu lệnh gán, câu lệnh khai báo và câu lệnh điều kiện được đi qua Danh sách các câu lệnh này được sắp theo thứ tự thực hiện chính là một đường đi Trong số tất cả các đường đi có thể, một tập đường đi được chọn sao cho thỏa mãn tiêu chí phủ kiểm thử được gọi là tập đường kiểm thử Đường kiểm thử là một đường đi từ đỉnh đầu tiên đến đỉnh cuối cùng của đồ

thị dòng điểu khiển (CFG) được biểu diễn dưới một tập các đỉnh từ đỉnh v 1 đến đỉnh

20

v n , trong đó hai đỉnh liền kề có cạnh nối với nhau Nếu cạnh (v i ,v j ) (i≠j) là nhánh false, câu lệnh lưu ở đỉnh v i được viết phủ định Tập đường đi độc lập gồm k đường

đi PATH 1 , PATH 2 , …,PATH k thỏa mãn: giữa mọi cặp đường đi độc lập PATH i và

PATH j (i≠j) không chung ít nhất một cạnh trở lên

Tìm kiếm tập đường kiểm thử là bước trung gian trong quá trình sinh tập ca kiểm thử Hai vấn đề liên quan đến tập đường kiểm thử rất quan trọng gồm:

- Vấn đề thực thi được hay không thực thi được Một đường kiểm thử gọi là

thực thi được nếu tìm kiếm được một ca kiểm thử sao cho khi thực thi trong môi trường thật thì đường kiểm thử nêu trên được đi qua Ngược lại, đường kiểm thử gọi

là không thực thi được

- Tính phức tạp thiết kế Một biểu đồ tuần tự gọi là phức tạp nếu chứa nhiều

vòng lặp như nhiều vòng lặp lồng nhau hoặc nhiều vòng lặp nối tiếp nhau, kích thước lớn hoặc thuật toán phức tạp Biều đồ tuần tự càng phức tạp càng khiến quá trình tìm kiếm đường kiểm thử trở nên khó khăn hơn và mất thời gian hơn

3.4 Chuyển đổi biểu đồ tuần tự sang đường kiểm thử

Việc biến đổi biểu đồ tuần tự sang đường kiểm thử là một công việc quan trọng Đây là quá trình chuyển đổi thiết kế sang biểu thức đặc tả các hành vi Đường kiểm thử được sinh ra sẽ làm đầu vào sinh mô hình đặc tả hành vi cho thành phần phần mềm, phục vụ cho quá trình kiểm thử tính đúng đắn của thiết kế

Biểu đồ tuần tự

(đặc tả bởi tệp xmi)

Đồ thị dòng điều khiển(CCFG)

(hiển thị dưới dạng đường kiểm thử)

Hình 3.17 Chuyển biểu đồ tuần tự thành đường kiểm thử

Phương pháp đề xuất yêu cầu thiết kế được biểu diễn bởi biểu đồ tuần tự của các thành phần dưới dạng xmi Một công cụ đã đượctôi xây dựng để phân tích file xmi và sinh ra đồ thị dòng điều khiển hiển thị dưới dạng đường kiểm thử Tôi sẽ cung cấp tập các quy tắc (định dạng) để xây dựng file xmi từ biểu đồ tuần tự tương

21

ứng Từ đó việc đọc và xử lý file xmi chuyển sang đường kiểm thử biểu diễn hoạt động cho thành phần thiết kế sẽ thuận lợi hơn vì file xmi đã được quy chuẩn

3.5 Định dạng chuẩn khi viết tệp xmi từ biểu đồ tuần tự

Trên thực tế, quá trình lưu biêu đồ tuần tự sẽ sinh ra tệp xmi, tuy nhiên tệp xmi này

có ID dài, khó nhớ nên để cho quá trình nghiên cứu, tác giả định nghĩa lại tệp xmi chuẩn theo các quy tắc như sau:

- Cặp thẻ bao ngoài cùng là <sequence> và </sequence>

- Lifeline bao gồm id và trường type = ―Lifeline‖

- Tiếp theo là Event hoặc fragment

+ Event : Gồm trường id, type=‘event ‗, coverd; trong đó coverd là id của lifeline

mà event bao phủ (điểm đầu và điểm cuối của message)

+ fragment: Gồm trường id, type = ‗combined frament‘, operator (operator có các giá trị là alt, loop, par….)

- Operand: Bắt buộc phải nằm trong fragment và ngay sau khai báo<fragment id=― ―, type=― ―, operator=― ―> gồm id, type=―operator‖ (nếu là fragment consider hoặc ignore thì operand nằm ngay sau khai báo <constraint value=― ―/>

- Constraint: Gồm trường value, trường này chứa tên các message cách nhau bởi dấu cách, ví dụ: <constraint value=―get set‖/> Thẻ này đặt giữa 2 thẻ fragment

và operand, được dùng để khai báo các message bị loại bỏ trong fragment ignore hoặc các message cần giữ lại trong fragment consider

- Event nằm trong sequence hoặc trong operand, không nằm trực tiếp trong fragment

- Message: Chỉ nằm trong sequence, không nằm trong operand hoặc fragment, gồm trường id, type=―message‖, name=―tên message‖, sendEvent và là id của event đầu, receiveEvent là id của event cuối

- Thẻ guard gồm trường value = ―điều kiện‖

- Thẻ option gồm trường value = ―True‖ hoặc ―False‖

Dưới đây là một ví dụ minh họa tệp xmi tương ứng với khối consider:

<lifeline id="001" type="Lifeline"/>

<lifeline id="002" type="Lifeline"/>

<fragment id="003" type="CombinedFragment" operator="consider">

<constraint value=“add remove"/>

<operand id="015" type="Operand">

<event id="004" type="event" covered="001"/>

<event id="005" type="event" covered="002"/>

<event id="006" type="event" covered="001"/>

<event id="007" type="event" covered="002"/>

3.6 Thuật toán sinh tự động các đường kiểm thử

Dưới đây là chín thuật toán sinh tự động các đường kiểm thử do tác giả tự đề xuất

23

3.6.1 Thuật toán phân tích biểu đồ tuần tự

Thuật toán 1: Thuật toán phân tích biểu đồ tuần tự

Đầu vào: Biểu đồ tuần tự biểu diễn bằng file xmi

Đầu ra: Danh sách các phân đoạn và mối quan hệ giữa chúng

1: create stack with an operand on top

2: create array lifelineList and array messageList

3: for all element in xmi file do

4: if meet open tag then