ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ VŨ THỊ ĐÀO KỸ THUẬT SINH TEST CASE TỰ ĐỘNG TỪ YÊU CẦU PHẦN MỀM LUẬN VĂN THẠC SĨ Hà Nội - 2008
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ VŨ THỊ ĐÀO KỸ THUẬT SINH TEST CASE TỰ ĐỘNG TỪ YÊU CẦU PHẦN MỀM Ngành : Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: LUẬN VĂN THẠC SĨ NGƢỜI HƢỚNG DẪN KHOA HỌC TS.TRƢƠNG ANH HOÀNG : Hà Nội - 2008
LỜI CẢM ƠN Luận văn này là thành quả của quá trình học tập nghiên cứu của tôi cùng sự giúp đỡ, khuyến khích của các quý thầy sau 2 năm tôi theo học Chƣơng trình đào tạo Thạc sỹ, chuyên ngành Công nghệ phần mềm của Khoa Công nghệ, Trƣờng Đại học Công nghệ Hà Nội. Tôi xin đặc biệt cảm ơn Thầy giáo hƣớng dẫn TS. Trƣơng Anh Hoàng. Thầy đã nhiệt tình hƣớng dẫn tôi, 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á trong quá trình nghiên cứu để hoàn thành đề tài này. Xin trân trọng cảm ơn các Thầy giáo của Khoa Công Nghệ và Viện Công nghệ thông tin đã dạy dỗ tôi trong hai năm học, cảm ơn các cán bộ công tác tại Phòng Sau Đại học-đại Học Công nghệ Hà Nội đã giúp đỡ tôi nhiều trong quá trình học tập và công tác bảo vệ luận văn. MỘT LẦN NỮA TÔI XIN CHÂN THÀNH CẢM ƠN!!
MỤC LỤC CHƢƠNG 1. ĐẶT VẤN ĐỀ... 9 1.1. Tầm quan trọng của các yêu cầu phần mềm... 9 1.2. Khái niệm về Test case... 9 1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm.... 10 CHƢƠNG 2. TỔNG QUAN VỀ QUÁ TRÌNH. Error! Bookmark not defined. SINH TEST CASE TỰ ĐỘNG... Error! Bookmark not defined. 2.1. Giới thiệu... Error! Bookmark not defined. 2.2. Tổng quan về các phƣơng pháp sinh Test caseerror! Bookmark not defined. 2.2.1. Sinh Test case dựa trên đặc tả... Error! Bookmark not defined. 2.2.2. Sinh Test case dựa trên mô hình... Error! Bookmark not defined. 2.2.3. Sinh Test case hƣớng đƣờng dẫn... Error! Bookmark not defined. 2.3. Kiểm thử phần mềm và UML... Error! Bookmark not defined. CHƢƠNG 3. CÁC KỸ THUẬT VÀ PHƢƠNG PHÁP SINH Error! Bookmark not defined. TEST CASE TỰ ĐỘNG... Error! Bookmark not defined. 3.1. Giới thiệu... Error! Bookmark not defined. 3.2. Kỹ thuật sinh Test case dựa trên đặc tả... Error! Bookmark not defined. 3.2.1. Các phƣơng thức đặc tả trạng thái SCR... Error! Bookmark not defined. 3.2.2. Kỹ thuật sinh ra Test case dựa theo đặc tả của SCR.. Error! Bookmark not defined. 3.2.3. Kỹ thuật tạo Test case cho đặc tả UML... Error! Bookmark not defined. 3.2.4. Các thuận toán sinh Test case dựa trên đặc tả.error! Bookmark not defined. 3.3. Kỹ thuật sinh Test case dựa trên mô hình... Error! Bookmark not defined. 3.3.1. Tạo ra Test case bằng việc sử dụng các biểu đồ cộng tác UMLError! Bookmark not defined. 3.3.2. Tạo Test case dựa trên Use case cải tiến... Error! Bookmark not defined. CHƢƠNG 4. PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNGError! Bookmark not defined. QUÁ TRÌNH SINH TEST CASE TỰ ĐỘNG... Error! Bookmark not defined. 4.1. Mục tiêu... Error! Bookmark not defined. 4.2. Tóm tắt quá trình sinh Test case tự động... Error! Bookmark not defined. 4.2.1. Ví dụ... Error! Bookmark not defined. 4.2.2. Các Test case của ví dụ... Error! Bookmark not defined. 4.2.3. Tính ứng dụng, các ƣu điểm và nhƣợc điểmerror! Bookmark not defined. 4.2.4. Kết luận... Error! Bookmark not defined.
4.3. Cài đặt... Error! Bookmark not defined. DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT Từ và cụm từ viết tắt UML OCD SCR Test Tester Viết đầy đủ Unified Modeling Language Object Collaboration Diagram Software Cost Reducation Sự kiểm thử Kiểm thử viên
DANH MỤC CÁC HÌNH VẼ Stt Tên hình vẽ 1 Một quy trình kiểm tra cơ bản. 2 Kiểm thử dựa trên đặc tả 3 Kiểm thử dựa trên chƣơng trình 4 Xây dựng các yêu cầu Test case từ cây biểu thức cú pháp 5 Qúa trình chung của việc tạo ra các Test case từ đặc tả SCR 6 Sự kiện gọi (call events) 7 Sự kiện báo hiệu (signal events) 8 Sự kiện thời gian (time Events) 9 Sự kiện thay đổi (Change Events) 10 Qúa trình chung cho việc tạo ra các Test case từ đặc tả UML 11 Cấu trúc của file MDL cho biểu đồ lớp và biểu đồ chuyển trạng thái. 12 Biểu đồ lớp của mô hình thiết kề 13 OCD cho việc sinh ra các Test case chỉnh sửa đầy đủ các thuộc tính 14 OCD cho việc sinh ra các Test case chỉnh sửa chuyển tiếp 15 OCD cho việc sinh ra các Test case chỉnh sửa cặp chuyển tiếp. 16 Thuật toán phân tích đặc tả SCR 17 Thuật toán phân tách đặc tả UML 18 Biểu đồ cộng tác mức độ đặc tả 19 Biểu đồ cộng tác cho một thao tác 20 Các cặp cộng tác 21 Một đƣờng chuỗi thông điệp 22 Thuật toán instrumentation 23 Mô hình hóa các vùng trong thiết kế phần mềm 24 Các hoạt động của cách tiếp cận đƣợc đề xuất bên trong quá trình phát triển phần mềm. 25 Biểu đồ trạng thái mức độ cao nhất cho ví dụ use case của bảng 3. 26 Cải tiến biểu đồ trạng thái cho ví dụ use case của bảng 3 27 Mô hình cách sử dụng có thể cho ví dụ thƣ viện của bảng 3. 28 Mô hình hành vi 29 Các lƣợc đồ test và các giá trị test 30 Test case cho kịch bản chính
DANH MỤC CÁC BẢNG BIỂU Stt Tên bảng biểu 1 Phân biệt các biểu đồ UML và các mức độ test 2 Mẫu cải tiến các use case 3 Một ví dụ về mẫu chi tiết các use case
MỞ ĐẦU Mặc dù việc nghiên cứu về các phƣơng pháp và kỹ thuật sinh Test case tự động từ yêu cầu ngƣời dùng đã đƣợc quan tâm nhiều trên thế giới, nhƣng ở Việt Nam các nghiên cứu và ứng dụng chỉ mới ở bƣớc đầu. Thực vậy, công việc sinh Test case tự động từ yêu cầu ngƣời dùng một cách có hiệu quả trong quá trình kiểm thử là vấn đề cần thiết và bức xúc của các công ty sản xuất phần mềm cũng nhƣ các tổ chức thực hiện phát triển dự án phần mềm. Trong quá trình phát triển dự án phần mềm, thƣờng công việc tạo ra các Test case từ yêu cầu ngƣời dùng do các Tester phụ trách. Nhƣng không phải Tester nào viết các tài liệu Test case này cũng nhƣ nhau. Vì vậy trong các công ty phần mềm cũng nhƣ các tổ chức thực hiện phát triển các dự án phần mềm sẽ phát sinh một vấn đề là: Tester nào viết tài liệu Test case tốt, có hiệu quả thì chất lƣợng phần mềm sẽ tốt hơn những dự án có Test case tồi. Vậy tại sao chúng ta không đồng nhất hóa công việc viết Test case bằng các phƣơng pháp và kỹ thuật tự động nhằm giảm bớt công sức và thời gian của các tester, làm cho chất lƣợng của Test case tốt hơn. Có các hƣớng tiếp cận khác nhau trong việc sinh Test case tự động: thứ nhất là có thể sinh Test case tự động dựa trên đặc tả từ một file input đã đƣợc định sẵn; thứ hai là sinh Test case tự động dựa trên code, chƣơng trình có sẵn; thứ ba là sinh Test case tự động dựa trên các mô hình UML. Trong ba hƣớng tiếp cận trên chúng tôi chọn hƣớng tiếp cận thứ ba và nghiên cứu các phƣơng pháp theo hƣớng tiếp cận này. Trong đề tài luận văn này chúng tôi nghiên cứu các vấn đề về tạo Test case tự động từ yêu cầu ngƣời dùng. Sau đó, chúng tôi xem xét các phƣơng pháp và kỹ thuật hiện có trong việc tạo Test case tự động để từ đó có thể đƣa ra những cải tiến bổ sung và phát triển. Cuối cùng là xây dựng một công cụ sinh Test case tự động có thể áp dụng trong thực tế. Bố cục của luận văn gồm phần mở đầu, phần kết luận và 4 chƣơng nội dung nhƣ sau: Chƣơng 1: Đặt vấn đề, đƣa ra các vấn đề cần thiết và cấp bách trong việc nghiên cứu và xây dựng một kỹ thuật sinh Test case hiệu quả từ yêu cầu ngƣời dùng. Chƣơng 2: Giới thiệu tổng quan về sinh Test case tự động. Trên cơ sở đó chọn hƣớng tiếp cận sẽ đi sâu vào nghiên cứu ở Chƣơng 3. Chƣơng 3: Trình bày các phƣơng pháp và kỹ thuật sinh Test case tự động hiện có. Từ đó đề xuất một kỹ thuật sinh Test case tự động và phân tích ƣu điểm của nó so với các kỹ thuật trƣớc.
Chƣơng 4: Trình bày quá trình sinh Test case hiệu quả dựa trên kỹ thuật đƣợc đề xuất. Đồng thời xây dựng chƣơng trình demo quá trình sinh Test case tự động. Sau khi nghiên cứu và thử nghiệm, trong phần Kết luận có nêu một số tổng kết và nhận xét về việc sinh Test case tự động, đồng thời đề ra hƣớng nghiên cứu tiếp theo. CHƢƠNG 1. ĐẶT VẤN ĐỀ 1.1. Tầm quan trọng của các yêu cầu phần mềm Các yêu cầu phần mềm là rất quan trọng với mọi dự án phần mềm. Các dự án thành công hoặc thất bại có nguyên nhân là do chất lƣợng của các yêu cầu. Các yêu cầu này cấu thành phạm vi của tất cả các công việc sau đó cho nhóm phát triển dự án. Không có các yêu cầu tốt, các dự án sẽ thất bại, bị chậm trễ, tốn kém, hoặc làm ra các hệ thống không bao giờ đƣợc sử dụng. Các vấn đề yêu cầu nên đƣợc cố định sớm, trƣớc khi vào giai đoạn thiết kế, bởi vì các vấn đề là do các yêu cầu kém có khuynh hƣớng gắn chặt vào trong thiết kế và khó để cho việc sửa chữa sau này. Những ngƣời phát triển và ngƣời dùng có một cách nhìn khác nhau từ những yêu cầu khi ngƣời phát triển xem xét yêu cầu từ quan điểm làm thế nào để thực hiện còn ngƣời dùng chỉ cảm nhận vấn đề là sử dụng nó nhƣ thế nào. Cách an toàn nhất để bảo đảm rằng nhu cầu của ngƣời dùng đã đƣợc đáp ứng những gì đã đƣợc đƣa ra, ta nên làm hai tài liệu song song, những gì ngƣời dùng cần, và những gì một hệ thống sẽ phải làm để đáp ứng nhu cầu đó. Đây là các yêu cầu ngƣời dùng và các đặc tả hệ thống theo thứ tự định sẵn. Vậy tại sao cần có các yêu cầu phần mềm tốt? Bất kỳ lỗi nào đƣợc phát hiện trong giai đoạn đầu trong quá trình phát triển dự án phần mềm là kết quả rất quan trọng. Nếu ở các giai đoạn sau lỗi mới đƣợc phát hiện ra thì chi phí cho việc sửa chữa hệ thống phần mềm sẽ tốn kém hơn rất nhiều. Nếu những ngƣời thiết kế hệ thống hƣớng tới mục tiêu không đúng, việc thực thi hệ thống sẽ đi chệch với mong muốn ban đầu. Một yêu cầu sai có thể tạo ra hàng loạt các lỗi thiết kế. Vì vậy để một sản phẩm phần mềm tốt thì điều đầu tiên quan trọng là chúng ta phải có các yêu cầu tốt. 1.2. Khái niệm về Test case Trong quá trình phát triển dự án phầm mềm, thông thƣờng một quy trình kiểm thử có các bƣớc cơ bản nhƣ sau: lập kế hoạch, thiết kế Test, phát triển test script, thực hiện test và đánh giá (xem Hình 1)
Trong đó Test case đƣợc viết trong bƣớc thiết kế test. Mục đích của thiết kế test là viết và chỉ định các Test case trong các bƣớc kiểm tra chi tiết cho mỗi phiên bản phần mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm tra "quét" hết tất cả yêu cầu cần kiểm tra. Vì vậy công việc tạo ra các Test case hiệu quả là đặc biệt quan trọng để đảm bảo chất lƣợng phần mềm. Để làm đƣợc việc đó, trƣớc hết phải hiểu Test case là gì? Một Test case có thể coi là một tình huống kiểm thử, đƣợc thiết kế để kiểm thử một đối tƣợng có thỏa mãn yêu cầu đặt ra hay không. Một Test case thƣờng bao gồm 3 phần cơ bản: Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm thử. Đầu vào: đặc tả đối tƣợng hay dữ liệu cần thiết, đƣợc sử dụng làm đầu vào để thực hiện việc kiểm thử. Kết quả mong muốn: kết quả trả về từ đối tƣợng kiểm thử, chứng tỏ đối tƣợng đã thỏa mãn yêu cầu. Test case có một ý nghĩa vô cùng quan trọng, mục đích đƣa ra các trƣờng hợp test nhằm phát hiện ra các lỗi nhiều nhất có thể, để cho các dự án phát triển phần mềm có chất lƣợng tốt hơn. 1.3. Vấn đề sinh Test case từ các yêu cầu phần mềm. Trong quá trình phát triển dự án phần mềm, thƣờng công việc tạo ra các Test case từ yêu cầu ngƣời dùng do các Tester phụ trách. Nhƣng không phải Tester nào viết các tài liệu Test case này cũng nhƣ nhau.vì vậy trong các công ty phần mềm cũng nhƣ các tổ chức thực hiện dự án phần mềm sẽ phát sinh một vấn đề là: Tester nào viết tài liệu Test case tốt, có hiệu quả thì chất lƣợng phần mềm sẽ tốt hơn những dự án có các Test case tồi (có nhiều trƣờng hợp test trùng lặp nhau hoặc thiếu các trƣờng hợp test). Vậy chúng ta phải chuẩn hóa và đồng bộ hóa để làm sao tạo ra Test case một cách hiệu quả và có chuẩn về chất lƣợng. Để làm điều này, chúng ta phải nghiên cứu các phƣơng pháp và kỹ thuật để tự động tạo ra các Test case. Việc tạo ra Test case một cách tự động cũng làm giảm bớt công sức và thời gian của các tester, giúp giảm bớt chi phí phát triển phần mềm. Qúa trình tạo ra các Test case sẽ giúp các tester phát hiện ra các vấn đề mâu thuẫn hoặc chƣa rõ ràng của các yêu cầu phần mềm. Nếu bƣớc này đƣợc làm sớm, các vấn đề có thể đƣợc loại bỏ sớm, tiết kiệm thời gian và nguồn lực khi phát triển các dự án phần mềm. Vậy việc nghiên cứu các phƣơng pháp và công cụ sinh Test case một cách tự động từ yêu cầu ngƣời dùng rất hữu ích và cần thiết trong quá trình phát triển các dự án phần mềm. Quá trình này nhằm mục đích tạo ra Test case một cách có hiệu quả, có chất lƣợng.
TÀI LIỆU THAM KHẢO [1] Andras Toth, Daniel Varro, Andras Pataricca, 2003, Model Level Automatic Test Generation for UML State-Charts, Sixth IEEE workshop on Design and Diagnostics of Electronic Circuits and System, (DDECS 2003). [2] Clay E. Williams, November 1999, Software testing and the UML, International Symposium on Software Reliability Engineering (ISSRE 99), Boca, Raton. [3] Jeff Offutt, Aynur Abdurazik, October 1999, Generating Tests from UML specifications, Second International Conference on the Unified Modeling Language (UML99). [4] Jeff Offutt, Aynur Abdurazik, October 2000, Using UML Collaboration diagrams for static checking and test generation, Third International Conference on UML, York, UK. [5] Jeff Offutt, Shaoying Liu, Aynur Abdurazik, Paul Ammann, March 2003, Generating Test data from State based Specifications, The Journal of Software Testing, Verification and Reliability. [6] Matthias Riebish, Ilka Philippow, Marco Gotze, UML Based Statistical Test Case Generation".