Ứng dụng công cụ SOAP UI cho kiểm thử tự động các ứng dụng web

LỜI CAM ĐOANTô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.. Trong đó, kiểm thử dựa trên

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

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 tinChuyê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

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ọcHù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ôinhữ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ọcCông Nghệ - Đại học Quốc Gia Hà Nội – những người đã tận tâm truyền đạt nhữngkiế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 chotô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ậnvă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

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ìnhkiểm thử, nâng cao hiệu quả, tiết kiệm chi phí và thời gian Phương pháp này đượcthự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àocho kiểm thử, phương pháp thực hiện chuyển đổi biểu đồ tuần tự về đồ thị dòng điềukhiể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áckhố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âydựng đồ thị cho mỗi khối, sau đó lồng chúng lại nhằm sinh ra đồ thị dòng điều khiểntươ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 (SymbolicExecution - 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ếmnghiệ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áptrê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ệckiể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ủ.

This thesis researches a method to generate a set of test cases from the UML2.0 sequence diagrams based on model-based testing in order to automate the testingprocess, increase effectiveness, reduce cost and time of testing The method followsthe following steps At first, in order to have the input model for testing, it analyzesand divides the input diagram into fragments These fragments can be sequential ornested based on their relationship After that, it builds the corresponding graph foreach of the fragments and merges them together in order to generate thecorresponding control flow graph for the input sequence diagram The final controlflow 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 solutionand then to generate a set of test cases

A tool is also implemented and tested with some simple examples in order toshow 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

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ọcHù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ụngcá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à dotô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ànchị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

MỤC LỤC

DANH SÁCH BẢNG BIỂU

DANH SÁCH HÌNH VẼ

Ả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

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

Kiểm thử là giai đoạn quan trọng và không thể thiếu trong quá trình phát triểnphầ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ỏimộ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ểnphầ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ầnthiế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ờigian 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 chocá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ôngviệ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 chophần mềm đã được đề xuất bởi nhiều tác giả Một hướng là tập trung vào nghiêncứ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 đượccho 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á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ínhquy đặc tả hành vi của phần mềm, các tác giả sau đó đã sử dụng thuật toánThompson để 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 FiniteState 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ữacá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àmtrong 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ìnhphân tích, chuyển đổi thành phần gọi là Bandera mà tự động trích xuất mô hình chochươ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ềmcầ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ồncủ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 EnvironmentGenerator (BEG) Công cụ này tự động hóa việc sinh mô hình môi trường để cungcấ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ìnhJava 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ươngphá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ểnphầ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ả

người thiết kế phần mềm cũng khó có thể nhận biết được những thông tin đầy đủ vềmôi trường trong thời gian làm thiết kế hệ thống.

Một hướng tiếp cận khác là sinh mô hình trong khi thực hiện kiểm chứng môhình hay trong khi thực hiện kiểm thử dựa trên mô hình [23], [24], và [25] Trong[23], các tác giả đã sử dụng thuật toán học L* để học đặc tả của một thành phầnphần mềm thông qua một biểu thức chính quy để sinh ra mô hình cho thành phần

đó 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àysinh được mô hình cho phần mềm, nhưng sử dụng nhiều thời gian và bộ nhớ Đặcbiệ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ủaphần mềm Do đó, phương pháp này rất khó áp dụng được trong thực tế Nghiêncứu [24] đặt vấn đề cho việc kiểm thử hộp đen Trong nghiên cứu này, nhiều chiếnlượ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ìnhbày một phương pháp sinh mô hình thành phần phần mềm trong quá trình thànhphầ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 đúnghiệ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ápnà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ươngphá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 chothà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ìnhbằ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ápnhằ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ử

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 đườngkiểm thử tương ứng đặc tả hoạt động Đây chính là giá trị đầu vào Qua quá trìnhphâ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ềukhiể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ộctương ứng cho tập đường kiểm thử ở đây là thực thi tượng trưng (symbolicexecution - 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ụngthế 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ậptrì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ủakiể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ềukhiể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ểmthử 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ìmnghiệ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ữnghạn chế và hướng nghiên cứu phát triển trong tương lai

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

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ìnhthà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 đượctiế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ầnthiế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ậptrì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ươngnà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à ứngdụ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 racá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ểmthử 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ácnhau 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ứccủ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ìnhkiể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êucầ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ệctạ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ểmthử 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ểmthử 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ử đượcsinh 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

đượ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ạngthá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 địnhyê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ăngcủ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ếtthúc bước này, chúng ta đã có các ca kiểm thử [1] Các ca kiểm thử đó được tiếnhà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:

- 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ểmthử, đá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 ápdụng trong công nghiệp Nó có thể được sử dụng để đặc tả hành vi động (chuyểntrạ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ụngcho 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áchà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ộttrạ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 đượcquyế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 đốitượ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épchuyể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áitrong 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 trongcá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ệncô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à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ứahẹ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ự độngnê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ộtcá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ìnhkiể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ểmthử mô hình cũng cho phép giảm các lỗi chủ quan do người kiểm thử sinh ra trongquá 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 quantrọng trong quá trình phát triển phần mềm nói chung và quá trình kiểm thử phầnmề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 sinhthê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ữuhiệ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

- 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ậyngườ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ươngphá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êntiế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ôngthườ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ơncà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.

Chương 3. PHƯƠNG PHÁP SINH ĐỒ THỊ DÒNG ĐIỀU KHIỂN TỪ

BIỂU ĐỒ TUẦN TỰ

Chương này đề xuất phương pháp kiểm thử tính đúng đắn thiết kế cho cácphần mềm dựa trên mô hình Để có được mô hình làm đầu vào cho phương phápkiểm thử, phương phápchuyển đổi biểu đồ tuần tự về đồ thị dòng điều khiển, đồ thịdòng điều khiển được sinh ra trở thành đầu vào để sinh ca kiểm thử.Nếu bản thiết

kế 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ôngthỏ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ếtkiệ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ácthô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ửigiữ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ủabiể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ồntạ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

Với các luồng điều khiển phức tạp, chúng ta có thể dùng các phân đoạn(combined fragment) Mỗi phân đoạn có một từ khóa và có một hoặc nhiều cácđoạn con (gọi là các toán hạng tương tác –interaction operands) Tương ứng với cấutrú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áccủ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àikhoả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.2 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ánhạ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 duynhất Hình 3.2 là ví dụ minh hoạ thực hiện đăng bình luận (post_comments()) nếukhô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

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.

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

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

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

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

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ử loopvớ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ểmtra 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ạntươ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

Hình 3.7 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ạngkhá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 chomộ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.Hình 3.9 là ví dụ minh họa: Tìm kiếm bằng Google song song với Bing và Yahoo,tuy nhiên phải tìm bằng Bing trước khi tìm bằng Yahoo

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

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

Hình 3.10 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

Hình 3.11 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à

vô nghĩa và bị mặc nhiên bỏ qua Hình 3.11 là ví dụ minh họa: Bỏ qua thông điệpget() và set() nếu có

Hình 3.12 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ệpkhá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

Hình 3.13 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 đangnấu được minh họa trong hình 3.13

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ếuthông điệp w xảy ra thay cho q thì w không hợp lệ

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

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àykhô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ảimái

Hình 3.16 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ớisinh 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ựcquan 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êncủ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

thúc của hàm Đỉnh i nối đến đỉnh j thì câu lệnh tương ứng đỉnh j có thể được thực thi sau khi thực hiện câu lệnh tương ứng ở đỉnh i.

Các thành phần cơ bản của đồ thị dòng điều khiển gồm đỉnh xuất phát, đỉnh xử

lí, đỉnh quyết định, đỉnh kết nối và đỉnh kết thúc [4]

- Đỉ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.17 Đồ 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âulệ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ựchiệ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

v n , trong đó hai đỉnh liền kề có cạnh nối với nhau Nếu cạnh (v i ,v j ) (ij) 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 (ij) 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 cakiể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ôngthự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ớnhoặ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ìmkiế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 quantrọng Đây là quá trình chuyển đổi thiết kế sang biểu thức đặc tả các hành vi Đườngkiểm thử được sinh ra sẽ làm đầu vào sinh mô hình đặc tả hành vi cho thành phầnphần mềm, phục vụ cho quá trình kiểm thử tính đúng đắn của thiết kế

Hình 3.18 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ủacá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 filexmi 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ứ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 xmichuẩ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ácgiá 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ặcignore 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ấucá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ặccá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ồmtrườ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:

<sequence>

<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

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