Luận án Tiến sĩ Toán học: Một số cải tiến về ràng buộc xâu trong sinh dữ liệu kiểm thử tự động cho thực thi tượng trưng

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

Thêm vào BST

Báo xấu

26
lượt xem 4
download

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

Mục tiêu của đề tài là nghiên cứu các phƣơng pháp mô hình hóa ràng buộc giải ràng buộc từ đó cải tiến khả năng giải ràng buộc và áp dụng kỹ thuật thực thi biểu trƣng trong tự động sinh các ca kiểm thử. Cài đặt thử nghiệm các phƣơng pháp đề xuất trong sinh tự động các ca kiểm thử trên kiểu dữ liệu xâu và kiểu dữ liệu hỗn hợp. Phân tích, đánh giá kết quả sau khi thử nghiệm.

Chủ đề:

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

Lưu

Nội dung Text: Luận án Tiến sĩ Toán học: Một số cải tiến về ràng buộc xâu trong sinh dữ liệu kiểm thử tự động cho thực thi tượng trưng

BỘ GIÁO DỤC VÀ ĐÀO TẠO VIỆN HÀN LÂM KHOA HỌC VÀ CÔNG NGHỆ VIỆT NAM HỌC VIỆN KHOA HỌC VÀ CÔNG NGHỆ ----------------------------- TÔ HỮU NGUYÊN MỘT SỐ CẢI TIẾN VỀ RÀNG BUỘC XÂU TRONG SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG CHO THỰC THI TƢỢNG TRƢNG LUẬN ÁN TIẾN SĨ TOÁN HỌC Hà Nội - 2020
BỘ GIÁO DỤC VÀ ĐÀO TẠO VIỆN HÀN LÂM KHOA HỌC VÀ CÔNG NGHỆ VIỆT NAM HỌC VIỆN KHOA HỌC VÀ CÔNG NGHỆ ----------------------------- TÔ HỮU NGUYÊN MỘT SỐ CẢI TIẾN VỀ RÀNG BUỘC XÂU TRONG SINH DỮ LIỆU KIỂM THỬ TỰ ĐỘNG CHO THỰC THI TƢỢNG TRƢNG LUẬN ÁN TIẾN SĨ TOÁN HỌC Chuyên ngành : Cơ sở toán học cho tin học Mã số: 9 46 01 10 Ngƣời hƣớng dẫn khoa học: 1. TS. Nguyễn Trƣờng Thắng 2. PGS. TS. Đặng Văn Đức Hà Nội - 2020
i MỤC LỤC MỤC LỤC ....................................................................................................................i LỜI CAM ĐOAN ..................................................................................................... iii LỜI CẢM ƠN ............................................................................................................iv DANH MỤC THUẬT NGỮ VÀ TỪ VIẾT TẮT ......................................................v DANH MỤC BẢNG BIỂU .......................................................................................vi DANH MỤC HÌNH VẼ ........................................................................................... vii MỞ ĐẦU .....................................................................................................................1 CHƢƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ THỰC THI BIỂU TRƢNG .......................................................................................................................5 1.1. Kiểm thử phần mềm ......................................................................................... 5 1.1.1. Các khái niệm cơ bản.................................................................................5 1.1.2 Các phƣơng pháp kiểm thử .......................................................................10 1.2. Kỹ thuật kiểm thử hộp trắng dòng điều khiển ................................................ 12 1.2.1. Kiểm thử hộp trắng dòng điều khiển theo hƣớng động ...........................12 1.2.2 Kiểm thử hộp trắng dòng điều khiển theo hƣớng tĩnh ..............................14 1.2.3. Các tiêu chí phủ kiểm thử ........................................................................15 1.2.4. Đồ thị dòng điều khiển ............................................................................16 1.2.5. Đƣờng kiểm thử .......................................................................................17 1.3. So sánh kiểm thử hộp trắng dòng điều khiển theo hƣớng tĩnh và động ......... 17 1.4. Thách thức trong kiểm thử phần mềm ........................................................... 18 1.5. Thực thi biểu trƣng ......................................................................................... 19 1.5.1. Tổng quan về thực thi biểu trƣng.............................................................19 1.5.2. Thực thi biểu trƣng tĩnh ...........................................................................24 1.5.3. Thực thi biểu trƣng động .........................................................................27 1.5.4 Thực thi Concolic .....................................................................................33 1.5.5. Thực thi biểu trƣng với các lời gọi phƣơng thức .....................................37 1.6.6. Ràng buộc xâu và vai trò của giải ràng buộc xâu ....................................40 1.6. Kết luận chƣơng 1 .......................................................................................... 42 CHƢƠNG 2. THỰC THI BIỂU TRƢNG VÀ MÔ HÌNH HÓA RÀNG BUỘC .....44 2.1. Đặt vấn đề ....................................................................................................... 44 2.1.1. Bùng nổ đƣờng đi ....................................................................................44
ii 2.1.2. Mô hình hóa bộ nhớ .................................................................................46 2.2. Thực thi biểu trƣng và công cụ mở rộng ........................................................ 47 2.2.1. Thực thi biểu trƣng và kiểm thử phần mềm ............................................47 2.2.2. Thực thi biểu trƣng trên ngôn ngữ Java ...................................................48 2.3. Giải các ràng buộc và thực thi biểu trƣng ...................................................... 54 2.4. Ràng buộc hỗn hợp và cải tiến trong giải ràng buộc xâu ............................... 56 2.4.1. Đồ thị xâu.................................................................................................58 2.4.2. Xây dựng lại ràng buộc ............................................................................58 2.4.3. Quá trình tiền xử lý ..................................................................................59 2.4.4. Sinh các ràng buộc xâu và kết quả thực hiện...........................................60 2.4.5. Giải ràng buộc sử dụng Otomat ...............................................................62 2.5. Kết luận chƣơng 2 .......................................................................................... 62 CHƢƠNG 3. GIẢI RÀNG BUỘC XÂU ..................................................................63 3.1. Đặt vấn đề ....................................................................................................... 63 3.2. Các vấn đề liên quan đến Bitvector và bộ thỏa mãn SMT (satisfiability modulo theories) .................................................................................................... 64 3.2.1. Lý thuyết thỏa mãn SMT .........................................................................64 3.2.2. Giải ràng buộc xâu dựa trên phƣơng pháp BitVector ..............................66 3.3. Giải ràng buộc xâu dựa trên phƣơng pháp sử dụng OTOMAT ..................... 67 3.4. Đề xuất giải ràng buộc xâu trong thực thi biểu trƣng .................................... 70 3.4.1 Mô hình hoá ràng buộc xâu sử dụng đồ thị ..............................................71 3.4.2 Phát hiện thêm ràng buộc kiểu nguyên trên dữ liệu xâu ..........................72 3.5. Thực nghiệm và đánh giá kết quả................................................................... 72 3.6. Kết luận chƣơng 3 .......................................................................................... 85 KẾT LUẬN VÀ KIẾN NGHỊ...................................................................................86 DANH MỤC CÔNG TRÌNH CỦA TÁC GIẢ .........................................................87 TÀI LIỆU THAM KHẢO .........................................................................................88
iii LỜI CAM ĐOAN Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi đƣợc hoàn thành dƣới sự hƣớng dẫn tận tình của tập thể hƣớng dẫn gồm. Các kết quả đƣợc viết chung với các tác giả khác đã đƣợc sự nhất trí của đồng tác giả khi đƣa vào luận án. Các kết quả nêu trong luận án là trung thực và chƣa từng đƣợc công bố trong bất kỳ công trình nào trƣớc thời gian công trình của tôi và cộng sự đƣợc công bố. Hà Nội, ngày…..tháng….năm … Tác giả luận án
iv LỜI CẢM ƠN Trƣớc hết, tác giả xin bày tỏ lòng biết ơn chân thành và sâu sắc tới các thầy giáo hƣớng dẫn, TS. Nguyễn Trƣờng Thắng và PGS. TS. Đặng Văn Đức. Sự tận tình giúp đỡ, chỉ bảo, động viện tận tình và quí báu mà các thầy đã dành cho tác giả trong suốt quá trình thực hiện luận án là không thể nào kể hết đƣợc. Xin chân thành cảm ơn các thầy các cô, các nhà khoa học thuộc Viện Công nghệ thông tin và Học viện khoa học và Công nghệ đã tận tình giúp đỡ và tạo một môi trƣờng làm việc hết sức thuận lợi giúp tác giả thực hiện tốt công việc nghiên cứu của mình. Xin chân thành cảm ơn Ban Giám Hiệu Trƣờng đại học Công nghệ thông tin và Truyền thông – Đại học Thái Nguyên đã hết sức tạo điều kiện về thời gian và công việc để tác giả có thể tập trung hoàn thành quá trình học tập, nghiên cứu của mình. Đặc biệt xin gửi lời cảm ơn đến các thầy cô, các bạn đồng nghiệp trong Khoa Công nghệ thông tin đã động viên, giúp đỡ tác giả trong suốt quá trình nghiên cứu. Cuối cùng, xin gửi lời cảm ơn sâu sắc nhất tới gia đình, bạn bè và ngƣời thân, những ngƣời đã luôn là nguồn động viên để tác giả có thể học tập và nghiên cứu, luôn sẻ chia những khó khăn vất vả trong quá trình nghiên cứu và hoàn thiện đề tài. Hà Nội, ngày…..tháng….năm …. Tác giả luận án
v DANH MỤC THUẬT NGỮ VÀ TỪ VIẾT TẮT Từ viết tắt Từ đầy đủ JPF Java Path Finder MJI Model Java Interface DFA Deterministic Finite Automaton PC Điều kiện đƣờng dẫn (path condition) QTKT Quy trình kiểm thử SAT Boolean satisfiability problem SDLC Software Development Life Cycle SE Thực thi biểu trƣng (Symbolic Execution) SET Cây thực thi biểu trƣng (Symbolic Execution Tree) SMT Satisfiability Modulo Theories SQA Software quality assurance STLC Software Test Life Cycle TPPM Thành phần phần mềm UT Kiểm thử đơn vị - Unit Testing VSUnit Visual Studio Unit Testing
vi DANH MỤC BẢNG BIỂU Bảng 1.1. Ví dụ về thực thi biểu trƣng động ................................................................. 29 Bảng 1.2. So sánh thực thi Concolic với thực thi biểu trƣng ........................................ 34 Bảng 1.3. Minh họa việc chuyển đổi từ mã nguồn Java sang mã Jimple ..................... 35 Bảng 1.4. Mô tả ràng buộc xâu ..................................................................................... 41 Bảng 2.1. Xây dựng các ràng buộc cho các phép toán trên xâu. .................................. 61 Bảng 3.1. Xây dựng ràng buộc tƣơng ứng với các phép toán trên xâu. ........................ 66 Bảng 3.2. Kết quả đánh giá mô hình cải tiến trên bộ dữ liệu ........................................ 79
vii DANH MỤC HÌNH VẼ Hình 1.1. Mối quan hệ giữa phát triển phần mềm và kiểm thử phần mềm .................... 9 Hình 1.2. Quy trình chung của kiểm thử hộp trắng theo hƣớng động .......................... 13 Hình 1.3. Ví dụ về chèn mã nguồn trong DMS/SRT .................................................... 14 Hình 1.4. Mã nguồn hàm triangle sau khi thêm mã nguồn ........................................... 14 Hình 1.5. Quy trình chung của kiểm thử hộp trắng theo hƣớng tĩnh ............................ 15 Hình 1.6. Các cấu trúc điều khiển phổ biến .................................................................. 17 Hình 1.7. Ví dụ về ý tƣởng thực hiện cụ thể của thực thi biểu trƣng ........................... 23 Hình 1.8. Cây thực thi biểu trƣng ................................................................................. 26 Hình 1.9. Thực thi biểu trƣng với phƣơng thức nhận đầu vào là đối tƣợng ................. 31 Hình 1.10. Cây thực thi biểu trƣng đƣợc quản lý riêng ................................................ 33 Hình 1.11. Thực thi biểu trƣng trên lời gọi phƣơng thức ............................................. 38 Hình 2.1. Mô hình hoạt động của JPF ........................................................................... 49 Hình 2.2. Sơ đồ trạng thái trong quá trình kiểm thử ..................................................... 50 Hình 2.3. Biểu diễn sơ đồ kiến trúc mức cao của JPF. ................................................. 51 Hình 2.4. Ví dụ về trừu tƣợng hoá dữ liệu. ................................................................... 52 Hình 2.5. Một ví dụ khác về trừu tƣợng hoá dữ liệu..................................................... 52 Hình 2.6. Quy trình sàng lọc dữ liệu. ............................................................................ 53 Hình 2.7. Đồ thị xâu ...................................................................................................... 57 Hình 2.8. Thuật toán giải ràng buộc hỗn hợp ............................................................... 58 Hình 2.9. Đồ thị sau khi loại bỏ phép toán equals. ....................................................... 60 Hình 2.10. Các ràng buộc không thỏa mãn sau khi loại bỏ phép toán equals .............. 60 Hình 2.11. Các đỉnh mới đại diện cho độ dài xâu đƣợc bổ sung .................................. 61 Hình 3.1. Giải ràng buộc xâu dựa trên Otomat ............................................................. 69 Hình 3.2. Phƣơng thức giải ràng buộc phủ định ........................................................... 70 Hình 3.3. Sơ đồ mô hình hoá ràng buộc xâu sử dụng đồ thị ......................................... 71 Hình 3.4: Thuật toán giải ràng buộc xâu. ...................................................................... 73 Hình 3.5. Chƣơng trình Java kiểm thử .......................................................................... 75 Hình 3.6. Kết quả sinh dữ liệu biểu trƣng trên một số phép toán trên xâu ................... 76 Hình 3.7. Code kiểm thử ............................................................................................... 78
viii Hình 3.8. Kết quả đánh giá mô hình cải tiến trên bộ dữ liệu ........................................ 80 Hình 3.9. Chƣơng trình Java ......................................................................................... 81 Hình 3.10. Đồ thị xâu 1 ................................................................................................. 82 Hình 3.11. Đồ thị xâu 2 ................................................................................................. 83
1 MỞ ĐẦU Kiểm thử phần mềm (testing) là một trong những hoạt động quan trọng nhất trong chu trình phát triển phần mềm. Theo số liệu thống kê thực tế, kiểm thử phần mềm chiếm tới 50-60% tổng chi phí toàn bộ quy trình phát triển phần mềm. Để giảm chi phí kiểm thử và tăng mức độ tin cậy của phần mềm, các nhà nghiên cứu đang cố gắng tự động hoá các hoạt động phục vụ công việc kiểm thử phần mềm [1, 2]. Một cách tổng quát, với mỗi kỹ thuật đƣợc dùng trong một giai đoạn kiểm thử động (dynamic run-time testing) thì bất cứ phần mềm nào cũng có thể đƣợc phân ra làm hai công đoạn con: chuẩn bị các ca kiểm thử (test case) cho việc kiểm tra phần mềm và thực hiện chạy chƣơng trình cần kiểm thử trên một nền tảng hỗ trợ các nghiệp vụ kiểm thử (testing framework) với các ca kiểm thử đã có. Công việc đầu tiên và hết sức quan trọng đó là chuẩn bị bộ dữ liệu kiểm thử. Việc này thƣờng đƣợc làm thủ công nên cần rất nhiều nhân lực để tạo ra bộ dữ liệu đầy đủ, có tính bao phủ cao (coverage criteria) trên toàn bộ các đƣờng tính toán (computation paths) của chƣơng trình. Các ca kiểm thử bao gồm dữ liệu kiểm thử và các giá trị đầu ra mong muốn. Một trong các hoạt động quan trọng để giảm chi phí kiểm thử phần mềm là sinh các ca kiểm thử một cách tự động và có tính đầy đủ. Các tổ chức phát triển phần mềm thƣờng phải chi phí một lƣợng lớn về tài chính cho các hoạt động liên quan đến kiểm thử phần mềm. Tính hiệu quả của tiến trình xác minh và thẩm định phụ thuộc nhiều vào số lỗi đƣợc tìm ra và đƣợc sửa chữa trƣớc khi sản phẩm đƣợc chuyển giao. Điều này đồng nghĩa với quan điểm chất lƣợng của phần mềm phụ thuộc chặt chẽ vào chất lƣợng các ca kiểm thử đƣợc sinh ra. Trong những năm qua, nhiều nghiên cứu của các nhà khoa học trên thế giới nhằm ―sinh dữ liệu kiểm thử một cách tự động‖ [3, 4] để giảm thiểu chi phí cho phần mềm. Có hai cách tiếp cận căn bản để sinh dữ liệu kiểm thử đó là dựa vào mã nguồn (code) và dựa vào mô hình (model). Đối với phƣơng pháp dựa vào mã nguồn là phƣơng pháp cho khả năng bao phủ cao, có khả năng loại bỏ các dòng lệnh không cần thiết chứa các tiềm ẩn gây lỗi nhƣng cần thiết phải có khả năng tối ƣu tính toán của các phần mềm phân tích kiểm thử, do vậy gần đây có nhiều nghiên cứu tập trung vào phƣơng pháp này [5, 6, 7].
2 Trong những năm qua, nhiều nghiên cứu về việc sinh các ca kiểm thử một cách tự động nhƣ: sinh các ca kiểm thử dựa vào đặc tả, sinh các ca kiểm thử dựa vào mô hình, sinh ca kiểm thử hƣớng đƣờng dẫn và kỹ thuật thông minh. Tuy nhiên, kiểm thử dựa vào thực thi biểu trƣng đã và đang là hƣớng nghiên cứu đƣợc nhiều ngƣời quan tâm. Các kỹ thuật cơ bản sinh dữ liệu kiểm thử tự động mà các nhà nghiên cứu đã đề xuất đó là: Dựa vào chứng minh định lý (test case generation by theorem proving) [8, 9]; Dựa vào thực thi biểu trƣng (test case generation by symbolic execution [5, 7, 10- 12]); Dựa vào kiểm chứng mô hình (test case generation by model checking) [13]; Dựa vào một mô hình luồng sự kiện (test case generation by an event-flow model [14]); Dựa vào việc sử dụng mô hình xích Markov (test case generation by using a Markov chains model) [15]. Trong đó kỹ thuật thực thi biểu trƣng (symbolic execution) đang là vấn đề đƣợc nhiều nhà khoa học trên thế giới tìm hiểu, phát triển và xây dựng các ứng dụng [5, 6, 7]. Hiện nay kỹ thuật này đã và đang đƣợc phát triển trên nhiều công cụ, nhiều ngôn ngữ nhƣ: C/C++, JavaScrip, .Net, java, HTML vv... Trong phạm vi giới hạn nghiên cứu, nội dung của luận án tập trung nghiên cứu về một số cải tiến trong bộ giải ràng buộc xâu áp dụng sinh các ca kiểm thử. Các cài đặt thực nghiệm và đánh giá đƣợc thực hiện bằng ngôn ngữ Java do Java là ngôn ngữ mạnh mẽ, hiện đại. Hơn nữa, Java đang đƣợc sử dụng rộng rãi với các thƣ viện trên kiểu dữ liệu xâu đa dạng, phong phú và đƣợc sử dụng trong nhiều dự án lớn trong hiện tại và tƣơng lai. Mục tiêu nghiên cứu của luận án: Nghiên cứu các phƣơng pháp mô hình hóa ràng buộc giải ràng buộc từ đó cải tiến khả năng giải ràng buộc và áp dụng kỹ thuật thực thi biểu trƣng trong tự động sinh các ca kiểm thử. Cài đặt thử nghiệm các phƣơng pháp đề xuất trong sinh tự động các ca kiểm thử trên kiểu dữ liệu xâu và kiểu dữ liệu hỗn hợp. Phân tích, đánh giá kết quả sau khi thử nghiệm. Đối tƣợng và phạm vi nghiên cứu: Tổng quan về các phƣơng pháp tự động sinh các ca kiểm thử phần mềm, kỹ thuật thực thi biểu trƣng và ứng dụng trong sinh tự động các ca kiểm thử. Các kỹ thuật mô hình hóa ràng buộc, giải ràng buộc trên các kiểu dữ liệu dựa trên hai phƣơng pháp Otomata và Bitvector, Nghiên cứu, phân tích đánh giá các phƣơng pháp hiện có sinh
3 ca kiểm thử trên các kiểu dữ liệu khác nhau. Đánh giá hiệu quả, chất lƣợng của các ca kiểm thử đƣợc tạo ra so với thực tế chƣơng trình. Nội dung nghiên cứu: Các phƣơng pháp kỹ thuật sinh tự động cá ca kiểm thử, các vấn đề liên quan mô hình hóa ràng buộc trên các kiểu dữ liệu. Nghiên cứu cải tiến mô hình hóa và giải ràng buộc trên kiểu dữ liệu xâu kí tự, từ đó ứng dụng trong kỹ thuật thực thi biểu trƣng thực hiện sinh các ca kiểm thử tự động trên kiểu xâu kí tự cho các chƣơng trình kiểm thử. Phƣơng pháp nghiên cứu: Nghiên cứu, phân tích, tổng hợp các liệu liên quan đến thực thi biểu trƣng, vai trò của giải ràng buộc cũng nhƣ giải ràng buộc triên kiểu dữ liệu xâu trong thực thi biểu trƣng trong sinh tự động các ca kiểm thử (các bài báo, tạp chí, trên mạng Internet...). Cải tiến mô hình hóa ràng buộc và nâng cao khả năng giải ràng buộc trên kiểu dữ liệu xâu và ràng buộc hỗn hợp, phân tích, đánh giá các kết quả đã công bố. Các đóng góp của luận án: Xây dựng mô hình hóa ràng buộc trên kiểu dữ liệu xâu và ràng buộc hỗn hợp, cải tiến khả năng giải ràng buộc trong phƣơng pháp thực thi biểu trƣng. Cài đặt kỹ thuật mô hình hóa và giải ràng buộc dựa trên Otomat và Bitvector trong giải ràng buộc xâu, đánh giá so sánh các kết quả thu đƣợc với các các kết quả đã công bố. Bố cục của luận án: Cấu trúc luận án bao gồm phần mở đầu, ba chƣơng nội dung, phần kết luận, danh mục công trình công bố và danh mục các tài liệu tham khảo. Nội dung chính của các chƣơng trong luận án nhƣ sau: Chƣơng 1 của luận án trình bày tổng quan về kiểm thử phần mềm và kỹ thuật thực thi biểu trƣng ứng dụng trong tự động sinh các ca kiểm thử. Đồng thời trình bày các lý thuyết cơ sở sử dụng trong luận án nhằm đƣa ra cái nhìn tổng quan về bài toán nghiên cứu, về sử dụng kỹ thuật thực thi biểu trƣng ứng dụng trong sinh tự động các ca kiểm thử và hƣớng nghiên cứu cụ thể của luận án. Chƣơng 2 của luận án trình bày kết quả nghiên cứu về các phƣơng pháp mô hình hóa ràng buộc, giải ràng buộc trong thực thi biểu trƣng. Áp dụng các công cụ này vào các trƣờng hợp cụ thể cùng với các đánh giá tính hiệu quả của các phƣơng pháp này trên kiểu dữ liệu cụ thể.
4 Chƣơng 3 của luận án trình bày các kết quả nghiên cứu của các cải tiến mô hình hóa ràng buộc trên kiểu xâu và ràng buộc hỗn hợp, giải ràng buộc trong thực thi biểu trƣng trên kiểu dữ liệu xâu và dữ liệu hỗn hợp. Đồng thời trình bày việc mở rộng kỹ thuật thực thi biểu trƣng, cách thực hiện giải ràng buộc xâu dựa trên phƣơng pháp Otomat. Phần kết luận nêu những đóng góp, hƣớng phát triển, những vấn đề quan tâm; danh mục các công trình đã đƣợc công bố của luận án và danh sách các tài liệu tham khảo đƣợc sử dụng trong luận án cũng đƣợc trình bày.
5 CHƢƠNG 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM VÀ THỰC THI BIỂU TRƢNG Chƣơng này trình bày lý thuyết tổng quan về kiểm thử và sinh dữ liệu kiểm thử, thực thi biểu trƣng và ứng dụng của thực thi biểu trƣng trong sinh các ca kiểm thử. Trong đó, trình bày các khái niệm cơ bản và các phân tích liên quan đến kỹ thuật thực thi biểu trƣng. Đồng thời, một vài thách thức và hƣớng phát triển của luận án cũng đƣợc trình bày trong chƣơng này. 1.1. Kiểm thử phần mềm 1.1.1. Các khái niệm cơ bản Để đảm bảo một hệ thống phần mềm hoặc các thành phần của phần mềm làm việc nhƣ mong muốn là một thách thức lớn trong ngành công nghiệp phần mềm. Các phần mềm lỗi gây ra những tổn thất về kinh tế cũng nhƣ những hậu quả nghiêm trọng khác tùy thuộc vào lĩnh vực mà phần mềm đƣợc sử dụng. Do đó cần phải phát hiện và khắc phục các lỗi của phần mềm trƣớc khi sử dụng. Có các phƣơng pháp khác nhau để phát hiện lỗi của phần mềm bao gồm kiểm chứng mô hình (model checking) [16], các kỹ thuật phân tích tĩnh (static analysis) [17] và kiểm thử (software testing) [18 - 23]. Trong kiểm chứng mô hình, một mô hình của hệ thống đƣợc tạo ra để hỗ trợ phân tích mọi sự thực thi có thể trong mô hình. Kiểm chứng mô hình có thể kiểm chứng đƣợc rằng mô hình của hệ thống hoạt động chính xác trong tất cả trƣờng hợp có thể. Hạn chế của kiểm chứng mô hình đó là không gian trạng thái của mô hình thƣờng quá lớn do đó việc khám phá tất cả các trạng thái không phải lúc nào cũng thực hiện đƣợc. Trong khi đó, các kỹ thuật phân tích chƣơng trình tĩnh thƣờng đƣa ra nhiều cảnh báo (warnings) không tƣơng ứng với các lỗi thực sự. Các kỹ thuật kiểm thử phát hiện ra các lỗi thực sự nhƣng thƣờng không phát hiện ra đƣợc tất cả các lỗi do chỉ phân tích một số sự thực thi trong chƣơng trình. Kiểm thử phần mềm là quá trình thực thi một chƣơng trình với mục đích tìm ra lỗi. Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra. Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Kiểm thử phần mềm là một phần trong tiến trình bảo đảm chất lƣợng phần mềm (Software Quality Assurance -SQA). Trong SQA, phần mềm chuyên xử lý và kiểm
6 toán viên đƣợc quan tâm đến quá trình phát triển phần mềm hơn là chỉ các hiện vật nhƣ tài liệu, mã số và hệ thống. Họ kiểm tra và thay đổi phần mềm quy trình kỹ thuật riêng của mình để giảm số lƣợng các lỗi mà kết thúc trong phần mềm đƣợc gửi: cái gọi là "tỷ lệ khiếm khuyết". Chúng tạo nên cái mà một "tỷ lệ lỗi chấp nhận đƣợc" phụ thuộc vào bản chất của phần mềm. Một chuyến bay mô phỏng trò chơi video sẽ có khả năng chịu lỗi cao hơn nhiều so với phần mềm cho máy bay thực tế. Mặc dù có những liên kết chặt chẽ với SQA, các phòng kiểm thử thƣờng tồn tại một cách độc lập, và có thể không có chức năng SQA trong một số công ty. Kiểm thử phần mềm đƣợc hiểu là quá trình phát hiện lỗi trong phần mềm bằng cách đối chiếu kết quả kỳ vọng từ một chƣơng trình máy tính với kết quả thực tế của nó cho một tập hợp các yếu tố đầu vào. Ngƣợc lại, bảo đảm chất lƣợng là việc thực hiện các chính sách và thủ tục nhằm ngăn ngừa khiếm khuyết xảy ra trong chƣơng trình. Kế hoạch kiểm thử (Test plan) Kế hoạch kiểm thử chính là tài liệu tổng quan về việc kiểm thử một dự án bao gồm: phạm vi kiểm thử, hƣớng tiếp cận, quy trình kiểm thử (QTKT), tài nguyên và nhân lực kiểm thử cần có, các chức năng/mô đun cần đƣợc kiểm thử, các công cụ và môi trƣờng kiểm thử cần có. Kế hoạch kiểm thử bao gồm cả kế hoạch ai kiểm thử chức năng nào, khi nào bắt đầu thực hiện viết và hoàn thành ca kiểm thử, khi nào bắt đầu thực hiện kiểm thử và kế hoạch hoàn thành kiểm thử. Dựa vào kế hoạch chung của dự án để lên kế hoạch cho bên kiểm thử. Trong trƣờng hợp khi làm thực tế thấy có khả năng không đúng nhƣ kế hoạch đã lên thì phải báo cáo lại trƣởng nhóm kiểm thử hoặc quản trị dự án sớm. Ca kiểm thử Mỗi ca kiểm thử chứa các thông tin cần thiết để kiểm thử từng thành phần của phần mềm theo một mục tiêu xác định. Thƣờng ca kiểm thử gồm bộ ba thông tin {tập dữ liệu đầu vào, trạng thái của thành phần phầm mềm (TPPM), tập kết quả kỳ vọng}. Trong đó, tập dữ liệu đầu vào gồm các giá trị dữ liệu cần thiết để các thành phần của phần mềm dùng và xử lý. Trạng thái của thành phần phần mềm đƣợc tạo ra bởi các giá trị tiền tố và hậu tố. Tập kết quả kỳ vọng là kết quả mong muốn sau khi các thành phần của phần mềm xử lý dữ liệu nhập.
7 Mục tiêu thiết kế ca kiểm thử là tìm ra nhiều lỗi nhất với chi phí và thời gian ít nhất. Trong các thập kỷ 80-90 của thế kỷ XX, ngƣời ta đã nghiên cứu nhiều loại phƣơng pháp thiết kế ca kiểm thử. Câu hỏi đặt ra là khi nào thì kiểm thử xong? Làm thế nào để biết rằng kiểm thử đã đủ? Về nguyên tắc là không bao giờ kiểm thử đƣợc tất cả đồng thời vận hành chƣơng trình là đang kiểm thử và kiểm thử tiếp tục khi chƣơng trình còn hoạt động Kỹ sƣ phần mềm cần các tiêu chuẩn nghiêm ngặt để xác định có cần phải tiếp tục kiểm thử không. Thiết kế ca kiểm thử trong kiểm thử phần mềm là quá trình xây dựng các phƣơng pháp kiểm thử có thể phát hiện lỗi, sai sót, khuyết điểm của phần mềm để xây dựng phần mềm đạt tiêu chuẩn. Thiết kế ca kiểm thử giữ vai trò quan trọng trong việc nâng cao chất lƣợng phần mềm bởi bƣớc thiết kế ca kiểm thử. Mục đích thiết kế ca kiểm thử nhằm tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần mềm một cách nhiều nhất và tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và công sức nhất. Một trong những yêu cầu quan trọng nhất trong kiểm thử chƣơng trình là thiết kế và tạo ra các ca kiểm thử có hiệu quả. Với những ràng buộc về thời gian và chi phí đã cho, thì vấn đề then chốt của kiểm thử trở thành xác định tập con nào của tất cả ca kiểm thử có thể có khả năng tìm ra nhiều lỗi nhất. Thông thƣờng, phƣơng pháp kém hiệu quả nhất là kiểm tra tất cả đầu vào ngẫu nhiên – quá trình kiểm thử một chƣơng trình bằng việc chọn ngẫu nhiên một tập con các giá trị đầu vào có thể. Về mặt khả năng tìm ra nhiều lỗi nhất, tập hợp các ca kiểm thử đƣợc chọn ngẫu nhiên có rất ít cơ hội là tập hợp tối ƣu hay gần tối ƣu. Sau đây là một số phƣơng pháp để chọn ra một tập dữ liệu kiểm thử một cách thông minh. Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể. Do đó, một chiến lƣợc kiểm thử hợp lý là chiến lƣợc có thể kết hợp sức mạnh của cả hai phƣơng pháp trên. Nghĩa là phát triển một cuộc kiểm thử nghiêm ngặt vừa bằng việc sử dụng các phƣơng pháp thiết kế ca kiểm thử hƣớng hộp đen nào đó và sau đó bổ sung thêm những ca kiểm thử này bằng việc khảo sát tính logic của chƣơng trình, sử dụng phƣơng pháp hộp trắng.
8 Do kiểm thử thƣờng là khâu cuối cùng trong quá trình phát triển phần mềm (trƣớc khi phần mềm đƣợc phân phối đến ngƣời sử dụng) nên cũng có thể đặt câu hỏi tƣơng đƣơng ―Khi nào thì kết thúc việc kiểm thử và phân phối sản phẩm?‖ Có nhiều câu trả lời khác nhau cho những câu hỏi trên, mỗi câu trả lời hƣớng tới những kĩ thuật và hành động khác nhau. Khi không có một sự đánh giá chuẩn thì quyết định dừng kiểm thử sản phẩm phần mềm dựa trên hai yếu tố chính, một là Tài nguyên: Quyết định có tiếp tục quá trình kiểm thử hay không dựa trên sự tiêu tốn tài nguyên, hai tiêu chuẩn trạng thái để dừng kiểm thử là ―Vƣợt quá thời gian và tiêu tốn quá nhiều tiền‖. Hai là quyết định dừng kiểm thử khi đã hoàn thành tất cả các hoạt động kiểm thử theo nhƣ kế hoạch kiểm thử đã đề ra. Đối với những giai đoạn đầu của quá trình kiểm thử hay các tiêu chuẩn kết thúc kiểm thử, liên quan tới các hành động kiểm thử cục bộ, những tiêu chuẩn tin cậy dựa trên những kịch bản sử dụng của khách hàng và tần suất sử dụng có thể không còn ý nghĩa nhiều. Ví dụ, trong một số hệ thống phần mềm, một số thành phần không bao giờ đƣợc sử dụng trực tiếp bởi ngƣời sử dụng và một số thành phần thì có tần suất sử dụng rất thấp. Do vậy việc lựa chọn các tiêu chuẩn khác là cần thiết. Những tiêu chuẩn mới này là các tiêu chuẩn bao phủ, nó bao hàm các tiêu chuẩn khác nhau, định nghĩa các kĩ thuật dùng trong tình huống kiểm thử và các thành phần khác có liên quan. Các kĩ thuật kiểm thử hƣớng tới các tiêu chuẩn này đƣợc gọi là các kĩ thuật kiểm thử hƣớng bao phủ. Ngoài các ràng buộc về tài nguyên và giới hạn của con ngƣời, có hai loại tiêu chuẩn để kết thúc hành động kiểm thử. Tiêu chuẩn thứ nhất dựa trên thống kê sử dụng của ngƣời dùng để xác định các thành phần cũng nhƣ các yếu tố liên quan để kiểm thử, còn đƣợc gọi là kiểm thử thống kê hƣớng sử dụng. Tiêu chuẩn thứ hai bao gồm các tiêu chuẩn về mọi vấn đề liên quan tới kiểm thử đơn vị, xét tới mọi khả năng gây lỗi của chƣơng trình (kết thúc kiểm thử) có các kĩ thuật kiểm thử hƣớng bao phủ. Vai trò của kiểm thử trong phát triển phần mềm, bảo trì và vận hành: Kiểm thử nghiêm ngặt hệ thống và tài liệu có thể giúp giảm thiểu những vấn đề rủi ro xảy ra trong quá trình vận hành và góp phần nâng cao chất lƣợng của hệ thống phần mềm, nếu nhƣ các lỗi đƣợc tìm thấy và sửa chữa trƣớc khi hệ thống đƣợc vận hành thực tế.
9 Kiểm thử và chất lượng: Kiểm thử mang lại sự tự tin về chất lƣợng của phần mềm nếu nó tìm thấy một vài lỗi hoặc không tìm thấy lỗi. Kiểm thử đúng sẽ giảm thiểu đƣợc tổng thể mức độ rủi ro của hệ thống. Khi quá trình kiểm thử tìm thấy lỗi, chất lƣợng của hệ thống phần mềm đƣợc nâng cao sau khi những lỗi đó đƣợc sửa chữa. Kiểm thử bao nhiêu là đủ: Việc quyết định kiểm thử bao nhiêu là đủ phụ thuộc vào mức độ của rủi ro bao gồm kỹ thuật, độ an toàn, rủi ro trong kinh doanh và hạn mức của dự án nhƣ là thời gian và ngân sách. Kiểm thử nên cung cấp đủ thông tin để các bên liên quan có thể quyết định về việc bàn giao phần mềm hoặc hệ thống đã qua kiểm thử cho các bƣớc phát triển tiếp theo hay bàn giao cho khách hàng. Kiểm thử chính là kỹ thuật đƣợc sử dụng phổ biến nhất để phát hiện và khắc phục các lỗi của phần mềm nhằm đảm bảo chất lƣợng của phần mềm. Chi phí dành cho việc kiểm thử chiếm khoảng 50% tổng chi phí trong phát triển phần mềm. Kiểm thử là một tiến trình quan trọng trong kỹ nghệ phần mềm. Kiểm thử đơn vị chính là bƣớc đầu tiên trong quá trình kiểm thử đó. Hình 1.1. Mối quan hệ giữa phát triển phần mềm và kiểm thử phần mềm Trong hình 1.1, phía bên trái của mô hình là vòng đời phát triển phần mềm - SDLC (Software Development Life Cycle), phía bên phải của mô hình là vòng đời kiểm thử Phần mềm - STLC (Software Test Life Cycle) và toàn bộ nội dung đƣợc thể hiện dƣới dạng chữ V, do đó mô hình này đƣợc gọi là Mô hình chữ V (V - model). Ngoài mô hình chữ V, còn có các mô hình phát triển lặp, trong đó việc phát triển đƣợc thực hiện theo từng giai đoạn, với mỗi giai đoạn sẽ phát triển thêm một chức năng
10 cho phần mềm. Mỗi giai đoạn bao gồm các hoạt động xây dựng và kiểm thử độc lập nhau. 1.1.2 Các phương pháp kiểm thử Các kỹ thuật kiểm thử phổ biến [24] bao gồm: Kiểm thử hộp đen (Black box testing) Kiểm thử hộp đen là một phƣơng pháp kiểm thử mà ngƣời kiểm thử sẽ chỉ xem xét đến đầu vào và đầu ra của chƣơng trình mà không quan tâm mã nguồn bên trong đƣợc viết ra sao. Kỹ thuật viên kiểm thử thực hiện kiểm thử dựa hoàn toàn vào đặc tả yêu cầu. Mục đích của kiểm thử hộp đen là tìm ra các lỗi ở giao diện, chức năng của phần mềm. Kiểm thử hộp trắng (White box testing) Kiểm thử hộp trắng là phƣơng pháp kiểm thử mà cấu trúc thuật toán của chƣơng trình đƣợc đƣa vào xem xét. Các ca kiểm thử đƣợc thiết kế dựa vào cấu trúc mã hoặc cách làm việc của chƣơng trình. Ngƣời kiểm thử truy cập vào mã nguồn của chƣơng trình để kiểm tra nó. Các mức độ kiểm thử: Kiểm thử đơn vị (Unit test) Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất. Kiểm thử thực hiện trên các hàm hay thành phần riêng lẻ. Đây là công việc mà để thực hiện đƣợc nó thì ngƣời kiểm thử sẽ phải hiểu biết về mã nguồn, về chƣơng trình và các hàm. Thông thƣờng lập trình viên sẽ làm nó trƣớc khi giao cho kiểm thử viên. Mục đích của việc thực hiện kiểm thử đơn vị là cô lập từng thành phần của chƣơng trình và chứng minh rằng các bộ phận riêng lẻ chính xác về các yêu cầu chức năng. Kiểm thử tích hợp (Intergration test) Một phần mềm đƣợc tạo ra sẽ bao gồm rất nhiều mô đun trong đó. Để chắc chắn rằng phần mềm hoạt động tốt thì việc gom các mô đun lại với nhau để kiểm tra sự giao tiếp giữa các mô đun cũng nhƣ bản thân từng thành phần từng mô đun là hết sức quan trọng. Kiểm thử tích hợp bao gồm hai mục tiêu chính là phát hiện lỗi giao tiếp xảy ra giữa các đơn vị khi tích hợp các đơn vị riêng lẻ thành các hệ thống nhỏ và cuối cùng là 1 hệ thống hoàn chỉnh để chuẩn bị cho bƣớc kiểm thử hệ thống. Kiểm thử hệ thống (System test)