Tài liệu Phương pháp sinh bộ kiểm thử tự động cho kiểm thử giao diện ứng dụng web

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ HÀ KHÁNH TOÀN PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN Hà Nội - 2013 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ HÀ KHÁNH TOÀN PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. LÊ THANH HÀ Hà Nội - 2013 i LỜI CAM ĐOAN Tôi xin cam đoan đây là công trình nghiên cứu của tôi dƣới sự giúp đỡ rất lớn của Giảng viên hƣớng dẫn là Tiến sĩ Lê Thanh Hà, Tiến sĩ Phạm Ngọc Hùng. Những nội dung nghiên cứu và kết quả trong đề tài này hoàn toàn trung thực. Các trích dẫn từ nguồn tài liệu bên ngoài đều đƣợc liệt kê rõ ràng ở phần cuối của luận văn. Hà Nội, tháng 12 năm 2013 Học viên Hà Khánh Toàn ii LỜI CẢM ƠN Để có thể hoàn thành đề tài luận văn thạc sĩ một cách hoàn chỉnh, bên cạnh sự nỗ lực cố gắng của bản thân còn có sự hƣớng dẫn nhiệt tình của quý Thầy Cô, cũng nhƣ sự động viên ủng hộ của gia đình và bạn bè trong suốt thời gian học tập, nghiên cứu và thực hiện luận văn thạc sĩ. Xin chân thành bày tỏ lòng biết ơn sâu sắc đến Tiến sĩ Lê Thanh Hà, Tiến sĩ Phạm Ngọc Hùng, những ngƣời đã dành rất nhiều thời gian và tâm huyết hƣớng dẫn tôi nghiên cứu và hoàn thành luận văn thạc sĩ. Xin gửi lời tri ân nhất đối với những điều mà các Thầy đã dành cho tôi. Xin chân thành bày tỏ lòng biết ơn đến toàn thể quý Thầy Cô trong khoa Công Nghệ Thông Tin Trƣờng Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội đã tận tình truyền đạt những kiến thức quý báu cũng nhƣ tạo mọi điều kiện thuận lợi nhất cho tôi trong suốt quá trình học tập, nghiên cứu và cho đến khi thực hiện đề tài luận văn. Cuối cùng, tôi xin chân thành bày tỏ lòng cảm ơn đến Ban lãnh đạo Hệ thống Đào tạo Lập trình viên Quốc tế Aprotrain-Aptech đã tạo điều kiện cho tôi rất nhiều trong suốt quá trình làm việc, học tập và thực hiện đề tài luận văn thạc sĩ của mình. Mặc dù tôi đã rất cố gắng hoàn thiện luận văn bằng tất cả sự nhiệt tình và năng lực của mình. Tuy nhiên do trình độ, kinh nghiệm và khả năng chuyên môn có hạn, chắc chắn luận văn còn nhiều thiếu sót. Rất mong nhận đƣợc những góp ý của quý Thầy Cô và các bạn. Hà Nội, tháng 12 năm 2013 Học viên Hà Khánh Toàn iii MỤC LỤC TRANG PHỤ BÌA LỜI CAM ĐOAN LỜI CẢM ƠN MỤC LỤC DANH MỤC CÁC TỪ VIẾT TẮT DANH MỤC CÁC BẢNG DANH MỤC CÁC HÌNH VẼ CHƢƠNG 1. GIỚI THIỆU ............................................................................. 1 CHƢƠNG 2. CƠ SỞ LÝ THUYẾT ............................................................... 3 2.1. Khái niệm Web Application ................................................................ 3 2.2. Các kỹ thuật kiểm thử .......................................................................... 3 2.2.1. Kiểm thử hộp đen.......................................................................... 3 2.2.3. Kiểm thử hộp xám......................................................................... 6 2.2.4. Kiểm thử dựa trên mô hình ........................................................... 7 2.2.5. Kiểm thử sử dụng máy hữu hạn trạng thái.................................... 9 2.3. Các mức kiểm thử .............................................................................. 11 2.3.1. Kiểm thử đơn vị .......................................................................... 12 2.3.2. Kiểm thử tích hợp ....................................................................... 12 2.3.3. Kiểm thử hệ thống....................................................................... 13 2.3.4. Kiểm thử chấp nhận .................................................................... 13 2.4. BỘ CÔNG CỤ SELENIUM – WEBDRIVER TRONG VIỆC KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB .................................................... 13 2.4.1. Tổng quan về Selenium .............................................................. 14 2.4.2. Selenium-RC (Remote Control) ................................................. 14 2.4.3. Selenium 2 (Selenium – Webdriver)........................................... 15 2.4.4. Một số Selenium-Webdriver API ............................................... 15 CHƢƠNG 3. PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB ............................................. 18 iv 3.1. Mục tiêu của phƣơng pháp nghiên cứu .............................................. 18 3.2. Tổng quan .......................................................................................... 18 3.3. Tạo các ca kiểm thử cho ứng dụng Web ............................................ 19 3.3.1. Xây dựng mô hình máy hữu hạn trạng thái ................................ 19 3.3.2. Xây dựng mô hình đồ thị cho máy hữu hạn trạng thái ............... 27 3.3.3. Thực hiện việc tạo ra các ca kiểm thử ........................................ 30 3.3.4. Thuật toán sinh ca kiểm thử ........................................................ 30 CHƢƠNG 4. THỰC NGHIỆM .................................................................... 32 4.1. Phƣơng pháp thực hiện ...................................................................... 32 4.2. Xây dựng công cụ kiểm thử tự động.................................................. 32 4.2.1. Mô tả công cụ kiểm thử .............................................................. 33 4.2.2 Xây dựng ứng dụng Web ............................................................. 34 4.2.3. Xây dựng máy hữu hạn trạng thái cho ứng dụng Web ............... 38 4.3. Kết quả thử nghiệm chƣơng trình ...................................................... 41 4.4. Thảo luận............................................................................................ 44 CHƢƠNG 5. KẾT LUẬN ............................................................................ 45 PHỤ LỤC ...................................................................................................... 47 TÀI LIỆU THAM KHẢO............................................................................. 54 v DANH MỤC CÁC TỪ VIẾT TẮT Viết tắt Cụm từ đầy đủ Ý nghĩa FSM Finite State Machine Máy hữu hạn trạng thái HTTP Hypertext Transfer Protocol Giao thức truyền siêu văn bản WSDL Web Services Description Language Ngôn ngữ mô tả các dịch vụ Web SOAP Simple Object Access Protocol Giao thức truy cập đối tƣợng đơn giản API Application Programming Interface Giao diện lập trình ứng dụng UML Unified Modeling Language Ngôn Ngữ Mô Hình Hóa Thống Nhất SWEBOK Software Engineering Body of Knowledge Tổ chức quốc tế theo chuẩn ISO/IEC TR 19759:2005 vi DANH MỤC CÁC BẢNG Số hiệu bảng Tên bảng Trang 2.1 Bảng chuyển trạng thái 10 3.1 Bảng chuyển trạng thái trang login.aspx 20 3.2 Bảng chuyển trạng thái trang studentInformation.aspx 21 3.3 Bảng chuyển trạng thái trang resultStudent.aspx 22 3.4 Bảng chuyển trạng thái trang addMark.aspx 3.5 Bảng chuyển trạng thái trang logout.aspx 27 4.1 Các phần tử html trang login.aspx 38 4.2 Bảng trạng thái trang login.aspx 38 4.3 Bảng sự kiện trang login.aspx 38 4.4 Bảng biểu diễn trạng thái chuyển trang login.aspx 39 4.5 Các phần tử html trang studentInformation.aspx 39 4.6 Bảng trạng thái trang studentInformation.aspx 39 4.7 Bảng sự kiện trang studentInformation.aspx 39 4.8 Bảng biểu diễn trạng studentInformation.aspx 4.9 Các phần tử html trang resultStudent.aspx 40 4.10 Bảng trạng thái trang resultStudent.aspx 40 4.11 Bảng sự kiện trang resultStudent.aspx 40 4.12 Bảng biểu diễn resultStudent.aspx 4.13 Bảng trạng thái trang logout.aspx 41 4.14 Bảng sự kiện trang logout.aspx 41 4.15 Bảng biểu diễn trạng thái chuyển trang logout.aspx 41 trạng thái thái chuyển chuyển 24-25-26 trang trang 39 41 vii DANH MỤC CÁC HÌNH VẼ Số hiệu hình vẽ Tên hình vẽ Trang 2.1 Kiểm thử hộp đen 4 2.2 Một ví dụ về kiểm thử hộp trắng 5 2.3 Sơ đồ luồng điều khiển đƣợc tạo ra từ chƣơng trình 6 2.4 Các bƣớc thực hiện kiểm thử mô hình 8 2.5 Mô hình đồ thị của máy FSM 11 3.1 Máy hữu hạn trạng thái cho trang login.aspx 27 3.2 Máy hữu hạn trạng thái cho trang studentInformation.aspx 28 3.3 Máy hữu hạn trạng thái cho trang ResultStudent.aspx 28 3.4 Máy hữu hạn trạng thái cho trang addMark.aspx 29 3.5 Máy hữu hạn trạng thái cho trang logout.aspx 30 3.6 Thuật toán duyệt đồ thị theo chiều sâu 31 4.1 Sơ đồ xây dựng bài toán 33 4.2 Giao diện chính của chƣơng trình 34 4.3 Giao diện trang Login.aspx 35 4.4 Giao diện trang studentInformation.aspx 36 4.5 Giao diện trang resultStudent.aspx 36 4.6 Giao diện trang addMark.aspx 37 4.7 Giao diện trang logout.aspx 37 1 CHƢƠNG 1. GIỚI THIỆU Ngày nay, sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác làm việc qua mạng và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu trong cuộc sống của chúng ta. Xu hƣớng này đòi hỏi các ứng dụng không chỉ là những hệ thống đơn lẻ trên một máy và chịu sự phụ thuộc vào một nền tảng cố định nào nữa, mà chúng phải là những hệ thống linh hoạt giúp ngƣời dùng làm việc “mọi lúc, mọi nơi”. Do đó, việc phát triển các ứng dụng Web đang là xu hƣớng tất yếu của ngành công nghiệp phần mềm. Các ứng dụng Web đang đƣợc ứng dụng rộng rãi trong thực tế. Càng ngày các doanh nghiệp nói chung và mọi ngƣời nói riêng càng phụ thuộc vào các ứng dụng Web và làm thế nào để các ứng dụng Web đáp ứng đƣợc các nhu cầu này. Do đó, nhu cầu đảm bảo an toàn chất lƣợng các sản phẩm phần mềm ứng dụng Web ngày càng trở nên cấp thiết. Việc đảm bảo chất lƣợng phần mềm hiện nay đang là một bài toán khó và nó tiêu tốn hơn 50% công sức và chi phí của các doanh nghiệp phần mềm. Kiểm thử đang đƣợc quan tâm nhƣ là phƣơng pháp chủ yếu để đảm bảo chất lƣợng của sản phẩm phần mềm ứng dụng Web nói riêng và sản phẩm phần mềm nói chung. Trong thực tế, các công ty gặp nhiều khó khăn, tốn thời gian và chi phí cao cho việc kiểm thử các ứng dụng Web. Mặc dù họ có thể thuê những ngƣời kiểm thử có kỹ năng kiểm thử giỏi, song những sai sót hoặc thiếu sót trong kiểm thử ứng dụng Web là không thể tránh khỏi do các phƣơng pháp kiểm thử ứng dụng Web thƣờng đƣợc thực hiện thủ công. Do đó, các phƣơng pháp kiểm thử hiện tại không đảm bảo phát hiện ra tất cả các lỗi. Ngoài ra, việc kiểm thử thủ công của một ứng dụng Web có thể tẻ nhạt và tốn thời gian (đôi khi do tƣơng tác ngƣời dùng quá lớn), đặc biệt là khi thực hiện các bài kiểm thử qui hồi trong ứng dụng. Kết quả là các ứng dụng Web hiện nay tiềm ẩn rất nhiều lỗi sau khi triển khai cho khách hàng. Trong kiểm thử các ứng dụng Web, kiểm thử tƣơng tác giao diện ngƣời dùng là một vấn đề khó và thƣờng đƣợc thực hiện thủ công. Trong thực tế, chúng ta có một thiết kế giao diện ngƣời dùng mô tả việc thay đổi trạng thái của màn hình ứng với các tƣơng tác của ngƣời dùng. Các thay đổi trạng thái này có thể xảy ra trong một trang Web hoặc từ trang Web này sang trang Web khác. Làm thế nào để đảm bảo rằng việc cài đặt tuân thủ đúng theo thiết kế này chính là mục đích chính của kiểm thử tƣơng tác giao diện ngƣời dùng cho các ứng dụng Web. Các kỹ thuật kiểm thử tự động đã đƣợc biết đến nhƣ là các giải pháp tiềm năng để giải quyết vấn đề trên. Những kỹ thuật này có thể phát hiện ra tất cả các lỗi có thể trong ứng dụng bằng cách tạo ra và thực hiện tự động các ca kiểm thử. Kết quả là, chúng ta có thể tiết kiệm thời gian và chi phí trong kiểm thử. Tự động kiểm thử là quá trình thực 2 hiện tự động bởi một chƣơng trình máy tính để tránh các lỗi không đƣợc phát hiện khi kiểm thử thủ công. Để đảm bảo tính chính xác, các công cụ kiểm thử tự động thƣờng đƣợc xây dựng dựa trên các phƣơng pháp kiểm thử nhƣ kiểm thử hộp đen, kiểm thử hộp trắng, … Tuy nhiên, các công cụ kiểm thử tự động là rất đắt và nhiều công ty không thể mua chúng. Luận văn này tập trung nghiên cứu các phƣơng pháp kiểm thử dựa trên mô hình nhằm đảm bảo việc cài đặt đúng theo thiết kế ban đầu. Đầu tiên sử dụng mô hình máy hữu hạn trạng thái cho giao diện ứng dụng Web, sau đó tạo ra các bộ kiểm thử từ máy hữu hạn trạng thái, từ đó xây dựng một đồ thị có hƣớng để biểu diễn các trƣờng hợp kiểm thử. Dựa trên đồ thị có hƣớng, theo các nhánh chúng ta có thể tạo ra các trƣờng hợp kiểm thử cho sản phẩm. Mục đích của luận văn này là đề xuất một phƣơng pháp cho phép để xây dựng một phƣơng pháp kiểm thử tự động cho giao diện các ứng dụng Web. Một công cụ kiểm thử tự động hỗ trợ cũng sẽ đƣợc phát triển nhằm minh chứng cho tính hiệu quả của phƣơng pháp này. Các phần tiếp theo của luận văn đƣợc tổ chức nhƣ sau. Chƣơng 2 trình bày về cơ sở lý thuyết của đề tài. Chƣơng này đề cập đến các khái niệm cơ bản của kiểm thử phần mềm, tìm hiểu về kiểm thử dựa trên mô hình, máy hữu hạn trạng thái. Tiếp theo, chƣơng 3 đề cập đến cách làm thế nào để sinh đƣợc các bộ kiểm thử từ máy hữu hạn trạng thái. Sau đó, chƣơng 4 xây dựng chƣơng trình thực nghiệm dùng công cụ Selenium và Webdriver. Nghiên cứu các trƣờng hợp sinh ca kiểm thử bằng chƣơng trình thực nghiệm này. Cuối cùng, chƣơng 5 tóm tắt các kết quả đã đạt đƣợc, kết luận, những hạn chế và hƣớng nghiên cứu phát triển trong tƣơng lai. 3 CHƢƠNG 2. CƠ SỞ LÝ THUYẾT 2.1. Khái niệm Web Application Các ứng dụng Web là các ứng dụng đƣợc giao tiếp với các máy khách thông qua các giao thức Web nhƣ HTTP, WSDL hoặc SOAP. Với sự phổ biến của World Wide Web thì việc các ứng dụng Web đƣợc phát triển ngày càng nhiều. Trình duyệt Web cung cấp cho các nhà phát triển các cơ hội để khai thác năng lực vốn có của trình duyệt để giảm bớt gánh nặng phụ thuộc vào các hệ điều hành khác nhau hoặc các nền tảng phần cứng có sẵn cho ngƣời dùng. Ngày nay các ứng dụng Web đƣợc phát triển khá đa dạng từ trang Web hẹn hò đến các trang thƣơng mại điện tử1, ngân hàng trực tuyến2, đặt vé các hãng hàng không3 … 2.2. Các kỹ thuật kiểm thử Ngày nay, có rất nhiều các phƣơng pháp đƣợc áp dụng trong kiểm thử, mỗi phƣơng pháp sẽ có những ƣu điểm và nhƣợc điểm riêng. Trong phần này sẽ miêu tả một số phƣơng thức kiểm thử nhƣ kiểm thử hộp đen [14], kiểm thử hộp trắng [1], kiểm thử hộp xám [13] và kiểm thử sử dụng máy hữu hạn trạng thái [2]. 2.2.1. Kiểm thử hộp đen Kiểm thử hộp đen hay còn đƣợc gọi là kiểm thử chức năng, kiểm thử hộp đen coi phần mềm nhƣ là một "hộp đen", kiểm thử chức năng mà không cần bất kỳ kiến thức về cấu trúc và hành vi bên trong phần mềm. Các kiểm thử viên chỉ biết về những gì phần mềm phải làm mà không biết là nó làm nhƣ thế nào. Phƣơng pháp kiểm thử hộp đen bao gồm: phân vùng tƣơng đƣơng, phân tích giá trị biên, tất cả các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng quyết định, kiểm thử chéo, kiểm thử dựa trên mô hình, sử dụng các ca kiểm thử, thăm dò kiểm thử và kiểm thử dựa trên đặc điểm kỹ thuật. Kiểm thử dựa trên đặc điểm kỹ thuật nhằm mục đích để kiểm tra các chức năng của phần mềm theo các yêu cầu ứng dụng. Mức độ kiểm thử thƣờng đòi hỏi ca kiểm thử kỹ lƣỡng đƣợc cung cấp bởi các kiểm thử viên, những ngƣời mà sau đó có thể xác minh một cách đơn giản rằng đối với một giá trị đầu vào hoặc đầu ra 1 http://www.alibaba.com https://www.vietcombank.com.vn/ibanking/ 3 http://www.vietnamairlines.com/wps/portal/vn/site/book_your_trip/ 2 4 (hoặc cách xử lý) có thể giống hoặc không so với giá trị kỳ vọng đƣợc định vị trong một ca kiểm thử nhất định. Các ca kiểm thử đƣợc xây dựng quanh các thông số kỹ thuật và các yêu cầu đề xuất, tức là những tất cả những gì ứng dụng đó phải làm. Nó đƣợc sử dụng để mô tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các yêu cầu và thiết kế đƣợc bắt nguồn trong ca kiểm thử. Các kiểm thử này có thể là chức năng hoặc phi chức năng. Hình 2.1 mô tả mô hình của kiểm thử hộp đen với các loại đầu vào nhƣ ngẫu nhiên tạo ra đầu vào trong phạm vi cho phép, trƣờng hợp ranh giới trong phạm vi qui định đầu vào, kiểm tra đầu vào là số không, kiểm tra đầu vào là các giá trị rỗng, đầu vào là các giá trị không hợp lệ hoặc ra khỏi phạm vi dự kiến,... Đầu vào Hộp đen Đầu ra Hình 2.1. Kiểm thử hộp đen. Kiểm thử dựa trên đặc điểm kỹ thuật có thể là cần thiết để đảm bảo chức năng chính xác, nhƣng nó không đủ để bảo vệ chống lại các tình huống phức tạp hoặc có độ rủi ro cao. Một lợi thế của kỹ thuật kiểm thử hộp đen là không yêu cầu nhất thiết phải có kiến thức lập trình. Các kiểm thử viên tiến hành kiểm thử ở các khu vực và các chức năng khác nhau của phần mềm mà không liên quan đến các lập trình viên. Mặt khác, kiểm thử hộp đen đƣợc cho là “đi bộ trong một mê cung tối tăm mà không có đèn pin”. Bởi vì họ không kiểm thử mã nguồn và đã có nhiều tình huống các kiểm thử viên chỉ kiểm thử đƣợc tính năng trong một vài trƣờng hợp chứ không kiểm thử đƣợc toàn bộ hoạt động của chƣơng trình. Phƣơng pháp kiểm thử này có thể đƣợc áp dụng cho tất cả các cấp kiểm thử phần mềm: đơn vị, tích hợp, hệ thống và chấp nhận. Nó không thể thực hiện đƣợc tất cả các kiểm thử các cấp độ cao hơn nhƣng nó có thể tạo ƣu thế tốt khi kiểm thử từng đơn vị. 2.2.2. Kiểm thử hộp trắng Kiểm thử hộp trắng hay còn đƣợc gọi là kiểm thử cấu trúc, quá trình thiết kế các ca kiểm thử 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, khiếm khuyết của phần mềm để xây dựng một phần mềm đạt tiêu chuẩn. Kỹ thuật kiểm thử hộp trắng hay kiểm thử hƣớng lôgic cho phép bạn khảo sát cấu trúc bên trong của chƣơng trình. Kỹ thuật này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính lôgic của chƣơng trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chƣơng trình (và cả mã lệnh thực hiện chúng). 5 Mục đích của bất cứ phƣơng pháp kiểm thử nào cũng là để đảm bảo rằng tình trạng tốt của một hệ thống trên bề mặt của những sự tấn công độc hại hoặc là tránh những sự thất bại của phần mềm thông thƣờng. Kiểm thử hộp trắng là sự thực hiện dựa trên hiểu biết về những phần tử của một hệ thống. Kiểm thử hộp trắng bao gồm phân tích dòng dữ liệu, điều khiển dòng, dòng thông tin, mã thực hành, ngoại lệ và những lỗi trình bày trong hệ thống để kiểm tra những hành động của phần mềm không đƣợc định hƣớng trƣớc. Kiểm thử hộp trắng có thể thực hiện để xác định tính hợp lệ cho dù việc triển khai thực hiện sau mã nhằm thiết kế, xác nhận tính hợp lệ để triển khai thực hiện chức năng bảo mật và giảm rủi ro việc bị tấn công ở những chỗ mở có thể khai thác đƣợc. Kiểm thử hộp trắng yêu cầu truy cập vào mã nguồn mặc dù kiểm thử hộp trắng có thể thực hiện tại bất cứ thời điểm nào trong vòng đời của phần mềm sau khi mã lệnh đƣợc phát triển. Đó là một hành động tốt để thực hiện kiểm thử hộp trắng trong suốt giai đoạn kiểm thử đơn vị. Hình 2.2 hiển thị một kiểm thử hộp trắng đơn giản. Trong hình 2.2, ở Ví dụ 1 chỉ có một đƣờng thi hành nhƣng rất dài: dài 1000*1000*1000 = 1 tỷ lệnh gọi hàm doSomethingWith(i,j,k) khác nhau. Ví dụ 2 gồm 32 câu lệnh if else độc lập nhƣng có 2^32 = 4 tỷ đƣờng thi hành khác nhau. Nhƣ vậy mục tiêu của kiểm thử là đảm bảo mọi đƣờng thi hành của đơn vị phần mềm cần kiểm thử đều chạy đúng. Tuy nhiên trong thực tế, công sức và thời gian để đạt đƣợc mục tiêu trên đây là rất lớn, ngay cả trên những đơn vị phần mềm nhỏ. Hình 2.2. Một ví dụ về kiểm thử hộp trắng. 6 Trong hình 2.3 hiển thị sơ đồ luồng điều khiển của một đoạn mã lệnh. Tại bƣớc đầu tiên, điểm khởi đầu sẽ đi đến khối lệnh xử lý là điểm (1). Sau đó, luồng điều khiển sẽ đến điểm quyết định (2). Ở vị trí (2), luồng điều khiển có hai hƣớng. Nó có thể thực hiện đến điểm (3) để tạo ra một nhánh mới là 1  2  3 hoặc điểm (4) để tạo ra một nhánh khác là 1  2  4. Cả hai nhánh có đều đến điểm (5) và trở về điểm kết thúc. Trong hình 2.3, chúng ta có năm nút quyết định nhị phân trong đồ thị nên có độ phức tạp C = 1 + 1 = 2. Hai đƣờng độc lập tuyến tính trong đồ thị luồng điều khiển. Kiểm thử viên có thể tạo ra hai ca kiểm thử cho đoạn mã trên là: 1. 1  2  3  5 2. 1  2  4  5 Hình 2.3 Sơ đồ luồng điều khiển được tạo ra từ chương trình. 2.2.3. Kiểm thử hộp xám Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhƣng là kiểm thử ở mức ngƣời sử dụng hay mức hộp đen. Việc thao tác với dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống nhƣ một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống đƣợc kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp 7 giữa hai mô-đun mã lệnh đƣợc viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là đƣợc đƣa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ giá trị biên hay thông báo lỗi. 2.2.4. Kiểm thử dựa trên mô hình 2.2.4.1. Khái niệm kiểm thử dựa trên mô hình Kiểm thử dựa trên mô hình [4] là tự động tạo ra các thủ tục kiểm thử phần mềm sử dụng các mô hình yêu cầu hệ thống và hành vi. Mặc dù loại kiểm thử này đòi hỏi nhiều nỗ lực đáng kể trong việc xây dựng các mô hình trƣớc, nhƣng nó cung cấp lợi thế đáng kể so với cách phƣơng pháp kiểm thử phần mềm truyền thống. Các mẫu thiết kế hay mô hình là mô tả đơn giản của hệ thống dựa trên yêu cầu hệ thống và chức năng xác định, giúp chúng ta có thể hiểu và dự đoán đƣợc hành vi của hệ thống. 2.2.4.2. Các bước thực hiện Quá trình kiểm thử 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 [12]. 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 ra các ca kiểm thử. Chúng ta có thể biết kết quả đầu ra mong đợi từ mô hình hoặc từ quy định chuẩn. Khi chạy kịch bản 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ử, … Các bƣớc để thực hiện kiểm thử dựa trên mô hình nhƣ đƣợc trình bày ở hình 2.4 bao gồm các bƣớc sau:  Xây dựng mô hình dựa trên các yêu cầu và chức năng của hệ thống  Tạo đầu ra dự kiến từ mô tả bài toán  Chạy kịch bản kiểm thử  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). 8 Hình 2.4. Các bước thực hiện kiểm thử mô hình 2.2.4.3. Những thuận lợi và khó khăn của kiểm thử dựa trên mô hình Trong 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 phƣơng pháp truyền thống nên thƣờng thiếu thời gian để thực hiện kiểm thử, hoặc giá thành sản phẩm khi hoàn thành thƣờng cao….[4] Và kiểm thử dựa trên mô hình sẽ khắc phục đƣợc một số nhƣợc điểm đó:  Do quá trình sinh ca kiểm thử là tự động vì vậy mà rút ngắn thời gian làm phần mềm, và chất lƣợng phần mềm tốt hơn.  Đặc biệt tuy chi phí lớn cho việc xây dựng mô hình nhƣng điều này sẽ đƣợc khấu trừ do chi phí bảo dƣỡng thấp hơn nhiều khi hệ thống đƣợc hoạt động.  Quá trình sinh ra các ca kiểm thử đƣợc thực hiện một cách tự động nên sinh ra nhiều ca kiểm thử và phát hiện nhiều lỗi.  Ngƣời kiểm thử phần mềm cần thƣờng xuyên trao đổi với ngƣời phát triển phần mềm trong khi xây dựng mô hình hệ thống vì vậy mà tăng khả năng giao tiếp trao đổi giữa ngƣời phát triển phần mềm, và ngƣời kiểm thử. 9  Ngƣời kiểm thử sẽ không bị nhàm chán khi phải thực hiện lặp lại nhiều lần một công việc, điều đó làm cho ngƣời kiểm thử hài lòng với công việc của mình.  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 các ca kiểm thử trùng nhau hoặc không hữu hiệu.  Khi một yêu cầu của hệ thống thay đổi việc thay đổi các ca kiểm thử là rất phức tạp nhƣng nó đƣợc giải quyết khi mà kiểm thử dựa trên mô hình. Việc thay đổi các ca kiểm thử chỉ việc thay đổi mô hình của hệ thống.  Có khả năng đánh giá chất lƣợng phần mềm. Mặc dù có nhiều thuận lợi nhƣng bên cạnh đó cũng có những trở ngại nhất định của kiểm thử dựa trên mô hình:  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.  Trong kiểm thử dựa trên mô hình công việc quan trọng nhất là xây dựng mô hình. Ngƣời kiểm thử phải đầu tƣ đáng kể cả về thời gian, trí tuệ và tiền bạc cho việc xây dựng mô hình hệ thống.  Giống nhƣ các phƣơng pháp kiểm thử khác, việc kiểm thử dựa trên mô hình chỉ phát hiện đƣợc lỗi của hệ thống mà không thể phát hiện đƣợc hệ thống còn lỗi hay không. 2.2.5. Kiểm thử sử dụng máy hữu hạn trạng thái Trong kiểm thử phần mềm có nhiều kiểu mô hình đƣợc sử dụng nhƣ: mô hình máy hữu hạn trạng thái [2], ngôn ngữ mô hình hóa thống nhất - UML, văn phạm, ... Trong nghiên cứu này trình bày về mô hình máy hữu hạn trạng thái. Mô hình máy hữu hạn trạng thái cũng đƣợc gọi là ôtômat hữu hạn trạng thái hoặc chỉ đơn giản là một máy trạng thái. Nó đƣợc sử dụng rộng rãi trong các mô hình tính toán với nhiều ứng dụng. Một máy hữu hạn trạng thái bao gồm ba thành phần chính là các trạng thái, các quá trình chuyển đổi, và các hành động. Các thành phần này có thể phân thành hai loại chính là Máy hữu hạn trạng thái chấp nhận Acceptor Finite State Machine (AFSM) và Bộ chuyển đổi hữu hạn trạng thái Finite State Transducer (FST). Trong thực tế máy hữu hạn trạng thái đóng một vai trò quan trọng trong nhiều lĩnh vực nhƣ công nghệ điện tử, ngôn ngữ học, lôgic và đặc biệt là khoa học máy tính. Trong khoa học máy tính, máy hữu hạn trạng thái 10 đƣợc sử dụng rộng rãi trong các mô hình hóa các hoạt động phần mềm, thiết kế hệ thống phần cứng, dịch thuật,… Do đó luận văn áp dụng mô hình này để xây dựng chƣơng trình kiểm thử tự động cho giao diện ứng dụng Web [3]. Máy hữu hạn trạng thái đƣợc định nghĩa theo mô hình nhƣ sau: M = (Σ, Q, δ, S, F) Trong đó:  Σ: tập tất cả các sự kiện: tất cả các sự kiện có thể xảy ra trong chƣơng trình,  Q: tập trạng thái: các trạng thái khi chƣơng trình thực hiện,  δ: trạng thái chuyển đổi: đƣợc định nghĩa giữa các cặp trạng thái hoặc sự kiện đến các trạng thái tiếp theo,  S: là trạng thái khởi tạo đƣợc khởi tạo khi chƣơng trình bắt đầu thực hiện và  F: là tập kết thúc là tập con của Q. Trong bảng 2.1 hiển thị các trạng thái chuyển đổi[5], dòng đầu tiên là các trạng thái cuối, cột đầu tiên là các trạng thái đầu, còn lại là các trạng thái chuyển đổi. Bảng này đƣợc chuyển đổi thành đồ thị có hƣớng đƣợc biểu diễn trong hình 2.1. Bảng 2.1. Bảng chuyển trạng thái. Result Student.aspx s_Result Student StudentName Khoahoc Student+ KhoaHoc F_main error s_Result Student Student Name Khoahoc - t_Std Name - select_kho ahoc - - - - - del_khoahoc - - - del_Std Name - Student+K hoaHoc F_main error - - t_submit t_StdName select_kho ahoc - t_submit - t_submit - t_submit - - - - Sau đó bảng này sẽ đƣợc chuyển sang đồ thị chuyển trạng thái trong hình 2.5. Hình 2.5 hiển thị mô hình đồ thị máy FSM cũng đƣợc gọi là đồ thị có hƣớng. 11 t_stdNameText select_khoahoc S_ResultS tudent Khoa Hoc del_Name t_stdnameText Student Name StudentName +KhoaHoc del_khoahoc Submit Result Student.aspx Submit select_khoahoc Submit errorSt Submit Hình 2.5. Mô hình đồ thị của máy FSM Từ mô hình đồ thị của máy hữu hạn trạng thái (Hình 2.5). Chúng ta có thể thấy tất cả các đƣờng đi từ đồ thị có hƣớng. Ví dụ một số đƣờng trong đồ thị này là: 1. S_ResultStudent  submit  errorSt 2. S_ResultStudent  select_khoahoc  KhoaHoc  t_stdNameText  StudentName + KhoaHoc  Submit  ResultStudent.aspx 3. S_ResultStudent  select_khoahoc  submit  errorSt 4. S_ResultStudent  t_stdNameText  StudentName  Submit  errorSt 5. S_ResultStudent  t_stdNameText  StudentName  select_KhoaHoc  StudentName + KhoaHoc  Submit  ResultStudent.aspx. 2.3. Các mức kiểm thử Kiểm thử thƣờng xuyên đƣợc nhóm lại theo vị trí chúng đƣợc thêm vào trong quá trình phát triển phần mềm, hoặc do mức độ đặc hiệu của kiểm thử. Các cấp chính trong quá trình phát triển theo quy định của hƣớng dẫn SWEBOK là kiểm thử đơn vị [7], kiểm thử tích hợp [11], và kiểm thử hệ thống [8] đƣợc phân biệt bởi các mục tiêu kiểm thử mà không ám chỉ một mô hình quy trình cụ thể. Các mức độ kiểm thử khác đƣợc phân loại theo mục tiêu kiểm thử.