Nghiên cứu kiểm thử Webservice và xây dựng công cụ hỗ trợ

  • Số trang: 80 |
  • Loại file: PDF |
  • Lượt xem: 78 |
  • Lượt tải: 0
tailieuonline

Đã đăng 27429 tài liệu

Mô tả:

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ TRẦN THỊ THÚY NHUNG NGHIÊN CỨU KIỂM THỬ WEB SERVICE VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN HÀ NỘI – 2014 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ TRẦN THỊ THÚY NHUNG NGHIÊN CỨU KIỂM THỬ WEB SERVICE VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã số: 60480103 LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN NGƢỜI HƢỚNG DẪN KHOA HỌC: TS NGUYỄN ĐỨC DŨNG HÀ NỘI - 2014 LỜI CAM ĐOAN Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm nghiên cứu, tìm hiểu của riêng cá nhân tôi. Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân tôi hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp. Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình. Hà Nội, ngày 30 tháng 10 năm 2014 Người cam đoan Trần Thị Thúy Nhung LỜI CẢM ƠN Tôi xin chân thành cảm ơn TS. Nguyễn Đức Dũng là Phó viện trưởng – Viện hàn lâm khoa học và công nghệ Việt nam đã tận tình giúp đỡ tôi về cả chuyên môn, nghiên cứu và định hướng phát triển trong suốt quá trình làm luận văn. Tôi đã học hỏi được rất nhiều khi nghiên cứu đề tài luận văn trên. Tôi cũng xin gửi lời cám ơn tới các Thầy, Cô giáo của Khoa Công nghệ thông tin, vì đã truyền dạy những kiến thức bổ ích, hiện đại về lĩnh vực Công nghệ phần mềm tôi học tập. Tôi đã được học tập dưới một môi trường giáo dục tốt về ngành công nghệ thông tin của cả nước. Với bạn bè cùng khóa. Xin cám ơn vì đã cho tôi cơ hội trao đổi, chia sẻ kiến thức và kinh nghiệm thực tế qua các môn học. Mọi người đã giúp tôi hiểu thêm những vấn đề mà tôi không có điều kiện tìm hiểu, chỉ cho tôi những thứ tôi chưa làm được. Tôi có thể tiếp thu được thêm nhiều vấn đề mới và biết được giá trị của việc không ngừng cố gắng học tập, nghiên cứu. Cuối cùng, với gia đình và đồng nghiệp, tôi xin gửi lời biết ơn sâu sắc vì gia đình đã luôn ở bên và ủng hộ tôi trên con đường học tập vất vả, cảm ơn đồng nghiệp vì đã tạo điều kiện để tôi có thể hoàn thành được hết khóa học. Tôi mong và hy vọng rằng với những kiến thức học được thì tôi có thể áp dụng được nhiều hơn vào công việc kiểm thử hiện tại của bản thân và đóng góp nhiều hơn các ý tưởng tốt để công việc được tốt hơn. Hà Nội, Tháng 10 - Năm 2014 Trần Thị Thúy Nhung MỤC LỤC BẢNG TỪ VIẾT TẮT .......................................................................................... 4 DANH MỤC HÌNH MINH HỌA ........................................................................ 5 DANH MỤC BẢNG BIỂU ................................................................................... 5 Chƣơng 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM ................................ 9 1.1.Kiểm thử phần mềm ......................................................................................... 9 1.2.Phân loại kiểm thử ........................................................................................... 9 1.3.Các phương pháp kiểm thử ............................................................................... 9 1.3.1.Kiểm thử tĩnh ................................................................................................. 9 1.3.2.Kiểm thử động ................................................................................................ 9 1.4.Các kỹ thuật kiểm thử ..................................................................................... 10 1.4.1.Kiểm thử hộp trắng – White box testing ...................................................... 10 1.4.1.1.Kiểm thử đường dẫn cơ sở (Basic Path Testing) ...................................... 11 1.4.1.2.Kiểm thử cấu trúc điều khiển .................................................................... 12 1.4.2.Kiểm thử hộp đen – Black box testing ......................................................... 14 1.5.Quy trình kiểm thử phần mềm ........................................................................ 17 1.6.Kiểm thử tự động ............................................................................................ 18 1.7.Kết luận chương .............................................................................................. 19 Chƣơng 2. TỔNG QUAN VỀ CÔNG NGHỆ DỊCH VỤ WEB ...................... 20 2.1.Định nghĩa....................................................................................................... 20 2.1.1.Khái niệm ..................................................................................................... 20 2.1.2.Đặc điểm của dịch vụ Web .......................................................................... 20 2.1.3.Ưu điểm và hạn chế của dịch vụ Web ......................................................... 20 2.1.4.Ứng dụng của dịch vụ Web ......................................................................... 21 2.2.Kiến trúc chung của dịch vụ Web................................................................... 21 2.3.Các thành phần của dịch vụ web .................................................................... 23 2.3.1.XML – eXtensible Markup Language .......................................................... 23 2.3.2.WSDL – Web Service Description Language .............................................. 24 2.3.3.Universal Description, Discovery, and Integration (UDDI) ....................... 28 2.3.4.SOAP – Simple Object Access Protocol ...................................................... 29 2.4.Bảo mật dịch vụ web ...................................................................................... 29 2.5.Triển khai và tích hợp dịch vụ web ................................................................ 31 2.5.1.Triển khai dịch vụ web ................................................................................ 31 2.5.2.Tích hợp dịch vụ web .................................................................................. 32 1 2.6.Kiểm thử dịch vụ web ........................................................................................... 33 2.7.Kết luận chƣơng..................................................................................................... 36 Chƣơng 3. XÂY DỰNG CÔNG CỤ HỖ TRỢ KIỂM THỬ DỊCH VỤ WEB ....... 37 3.1.Mô tả và xây dựng bài toán ..................................................................................... 37 3.1.1.Mô tả bài toán ....................................................................................................... 37 3.1.2.Sơ đồ chức năng hệ thống .................................................................................... 40 3.1.3.Thiết kế cơ sở dữ liệu ........................................................................................... 42 3.2.Phân tích và đánh giá hệ thống ................................................................................ 44 3.2.1.Phân tích các chức năng của hệ thống .................................................................. 44 3.2.1.1.Xác định các Actor và Use Case ....................................................................... 44 3.2.1.2.Xây dựng biểu đồ Use Case của toàn hệ thống ................................................. 47 3.2.1.3.Đặc tả danh sách các Use Case.......................................................................... 47 3.2.1.3.1.Use Case Thêm mới thông tin Web service .................................................... 47 3.2.1.3.2.Use Case Chỉnh sửa thông tin Web service ................................................... 47 3.2.1.3.4.Use case xuất mẫu import testcase ................................................................. 48 3.2.1.3.5.Use case Thêm mới testcase ........................................................................... 49 3.2.1.3.6.Use case Chỉnh sửa Testcase ......................................................................... 50 3.2.1.3.7.Use case Xóa Testcase.................................................................................... 51 3.2.1.3.8.Use case Import Testcase ............................................................................... 52 3.2.1.3.9.Use case Thêm mới kiểu dữ liệu ..................................................................... 52 3.2.1.3.10.Use case Chỉnh sửa kiểu dữ liệu .................................................................. 53 3.2.1.3.11.Use case Xóa kiểu dữ liệu ............................................................................ 53 3.2.1.3.12.Use case tạo testcase tự động ....................................................................... 54 3.2.1.3.13.Use case Thực hiện kiểm thử ........................................................................ 55 3.2.1.3.14.Use case Xuất báo cáo ................................................................................. 55 3.2.2.Thiết kế một số giao diện của hệ thống ................................................................ 56 3.2.2.2.Giao diện chính của phần mềm ......................................................................... 56 3.2.2.3.Giao diện danh mục quản lý Web service ......................................................... 56 3.2.2.4.Giao diện danh mục quản lý testcase ................................................................ 57 3.2.2.5.Giao diện màn hình import testcase .................................................................. 57 3.2.2.6.Giao diện màn hình cấu hình kiểu dữ liệu ......................................................... 58 3.2.2.7.Giao diện màn hình tạo testcase tự động ........................................................... 58 3.2.3.Cài đặt, triển khai hệ thống................................................................................... 59 3.2.3.2.Mô hình triển khai hệ thống .............................................................................. 59 3.2.3.3.Phần mềm .......................................................................................................... 60 2 3.2.3.4.Phần cứng ................................................................................................. 60 3.2.4.Phân tích kết quả .......................................................................................... 60 3.2.4.1.Yêu cầu bài toán ....................................................................................... 60 3.2.4.2.Giải pháp thực hiện .................................................................................. 60 3.2.4.3.Triển khai thực hiện .................................................................................. 63 3.2.4.3.1.Xây dựng Web service............................................................................ 63 3.2.4.3.2.Lập kịch bản test .................................................................................... 68 3.2.4.3.3.Thực hiện test ......................................................................................... 69 3.2.4.4.Kết quả đạt được ....................................................................................... 69 3.2.4.5.Đánh giá kết quả ....................................................................................... 69 3.3.Kết luận ........................................................................................................... 74 KẾT LUẬN VÀ ĐỀ XUẤT ................................................................................ 75 DANH MỤC CÁC TÀI LIỆU THAM KHẢO ................................................. 76 3 BẢNG TỪ VIẾT TẮT BVA Boundary Value Analysis MTTR Mean Time To Repair CSDL Cơ sở dữ liệu SOAP Simple Object Access Protocol WSDL Dịch vụ Web Description Language UDDI Universal Description, Discovery, and Integration HTTP HyperText Transfer Protocol TCP/IP Transmission Control Protocol/Internet Protocol SMTP Simple Mail Transfer Protocol FTP File Transfer Protocol XML Extensible Markup Language REST Representational State Transfer API Application Programming Interface RPC Remote Procedure Call SSL Secure Sockets Layer SQL Structured Query Language WS Dịch vụ Web 4 DANH MỤC HÌNH MINH HỌA Hình 1.1. Ví dụ chu trình điều khiển Hình 1.2. Các kiểu vòng lặp Hình 1.3. Giai đoạn kiểm thử trong xử lý phần mềm Hình 1.4. Qui trình kiểm thử phần mềm Hình 2.1. Kiến trúc chung của dịch vụ Web Hình 2.2. Mô hình tương tác Hình 2.3. Thành phần của WSDL Hình 2.4. Một tài liệu WSDL Hình 2.5. Cấu trúc tài liệu WSDL Hình 2.6. Kiểu dữ liệu trong tài liệu WSDL Hình 2.7. Messages trong tài liệu WSDL Hình 2.8. Operations trong tài liệu WSDL Hình 2.9. Port Type trong tài liệu WSDL Hình 2.10. Bindings trong tài liệu WSDL Hình 2.11. Service và port trong tài liệu WSDL Hình 3.1. Mô tả kiểm thử WS qua SoapUI Hình 3.2. Mô tả luồng xử lý công cụ tự động Hình 3.3. Sơ đồ chức năng Hình 3.4. Sơ đồ lớp Hình 3.5. Use Case quản lý thông tin web service Hình 3.6. Quản lý thông tin testcase Hình 3.7. Quản lý thông tin kiểu dữ liệu Hình 3.8. Use case thực hiện kiểm thử và xuất kết quả Hình 3.9. Giao diện chính của phần mềm Hình 3.10. Giao diện danh mục quản lý Web service Hình 3.11. Giao diện danh mục quản lý testcase Hình 3.12. Giao diện màn hình import testcase Hình 3.13. Giao diện màn hình cấu hình kiểu dữ liệu Hình 3.14. Giao diện màn hình tạo testcase tự động Hình 3.15. Mô hình triển khai 5 DANH MỤC BẢNG BIỂU Bảng 3.1. Danh sách các bảng trong cơ sở dữ liệu Bảng 3.2. Các bước xử lý Bảng 3.3. Bảng thiết kế CSDL cho WS Bảng 3.4. Bảng thiết kế các trường hợp kiểm thử 6 MỞ ĐẦU 1. Đặt vấn đề, định hƣớng nghiên cứu Hiện nay ngành công nghệ phần mềm đang rất phát triển ở nhiều lĩnh vực. Tuy nhiên để đảm bảo được sản phầm phần mềm tin cậy thì ngoài việc thiết kế, lập trình phải kể đến một khâu cực kỳ quan trọng đó là kiểm thử. Nếu như phát triển tạo ra được một sản phẩm thì kiểm thử sẽ đảm bảo phần mềm đó hoạt động đúng theo thiết kế. Vì vậy bước kiểm thử rất quan trọng trong vòng đời phát triển của một phần mềm. Mặc dù vậy nhưng để kiểm thử thế nào để đảm bảo chất lượng, tiết kiệm chi phí và tối ưu nhất nguồn lực thì vẫn đang là một bài toán khó cho các công ty phát triển phần mềm. Một giải pháp hợp lý cho các vấn đề đặt ra ở trên đó là áp dụng các công cụ kiểm thử tự động cho các phần mềm để tối ưu nguồn lực và đảm bảo chất lượng. Hiện nay cũng có rất nhiều công cụ hỗ trợ việc này. Tuy nhiên ngoài giá thành cao và khả năng năng áp dụng chưa rộng rãi do đặc thù các loại phần mềm khác nhau nên việc tạo ra một công cụ hiệu quả cho các phần mềm thì vẫn đang là vấn đề cần được nghiên cứu. Luận văn được thực hiện dựa trên ý tưởng từ nhu cầu thực tế và kiến thức được học. Từ đó đưa ra cách thực hiện và đánh giá. Luận văn được chia thành 5 phần: Mở đầu Ở chương này trình bày tổng quan về đề tài như : lý do chọn đề tài, mục tiêu, nội dung của đề tài và công cụ cũng như môi trường để ứng dụng đề tài. Chƣơng 1. Tổng quan về kiểm thử Chương này trình bày khái niệm cơ bản về kiểm thử, các kỹ thuật kiểm thử và công đoạn kiểm thử trong vòng đời phát triển của phần mềm Chƣơng 2. Tổng quan về công nghệ Dịch vụ Web và kiểm thử Dịch vụ Web Chương này trình bày khái quát về công nghệ dịch vụ Web, khái niệm, thành phần, kiến trúc. Vai trò, ý nghĩa, mục đích sử dụng của Dịch vụ Web và một số tiêu chí bổ sung khi kiểm thử dịch vụ Web Chƣơng 3. Xây dựng công cụ hỗ trợ kiểm thử Dịch vụ Web Trong chương này luận văn đưa ra bài toán kiểm thử, cách thức kiểm thử truyền thống và đề xuất xây dựng một công cụ kiểm thử dịch vụ Web tự động. Từ đó đưa ra bài toán và cách áp dụng cụ thể để đánh giá. 7 Kết luận và đề xuất Chương này phân tích và đánh giá việc thực hiện đề tài, những đóng góp và những hạn chế mà đề tài cần khắc phục để hoàn thiện, hướng phát triển của đề tài và các ứng dụng của đề tài trong lý thuyết cũng như trong thực tiễn 2. Mục tiêu của đề tài Mục tiêu của luận văn là tìm hiểu về kiến thức kiểm thử phần mềm, kiến thức về công nghệ dịch vụ Web và kiểm thử dịch vụ Web. Dựa trên mô hình lý thuyết ở trên để thực hiện phân tích và xây dựng công cụ hỗ trợ kiểm thử cho một bài toán kiểm thử dịch vụ Web cụ thể. 3. Nội dung nghiên cứu Đề tài nghiên cứu tổng quát về kiểm thử phần mềm: khái niệm, các kỹ thuật, đưa ra nghiên cứu chi tiết về kiểm thử bảo mật và hiệu năng của dịch vụ Web. Đề tài còn nghiên cứu tổng quát về dịch vụ Web: khái niệm, công nghệ. Từ những cơ sở lý thuyết trên thì đề tài tiến hành đề xuất cài đặt công cụ hỗ trợ kiểm thử cho dịch vụ Web. Cụ thể: 1. Nêu một số khái niệm tổng quan về kiểm thử và dịch vụ Web 2. Xây dựng công cụ hỗ trợ kiểm thử - Đề xuất bài toán - Phân tích và xây dựng thuật toán - Cài đặt minh họa - Đánh giá kết quả 3. Kết luận những nội dung đã đạt được và hướng phát triển, các ứng dụng của đề tài. Học viên thực hiện Trần Thị Thúy Nhung 8 Chƣơng 1. TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1. Kiểm thử phần mềm Kiểm thử phần mềm là quá trình phân tích phần mềm để phát hiện sự khác biệt giữa kết quả của chương trình với đầu ra mong muốn để đánh giá các chức năng của phần mềm. Kiểm thử phần mềm cần được thực hiện trong toàn bộ quá trình phát triển của phần mềm. Kiểm thử phần mềm là rất quan trọng, là một phần bắt buộc của phần mềm. Nó là một kỹ thuật để đánh giá chất lượng của phần mềm và cải thiện nó bằng cách xác định các lỗi và các vấn đề [1]. 1.2. Phân loại kiểm thử Ta phân loại kiểm thử dựa vào các yếu tố: Chiến lược kiểm thử, phương pháp kiểm thử và kỹ thuật kiểm thử. Dựa vào chiến lược kiểm thử ta có thể phân chia kiểm thử thành hai loại: kiểm thử thủ công và kiểm thử tự động. Theo phương pháp tiến hành kiểm thử ta chia kiểm thử làm hai loại: kiểm thử tĩnh và kiểm thử động. Dựa vào kỹ thuật kiểm thử ta có thể phân chia kiểm thử thành hai loại: kiểm thử hộp đen, kiểm thử hộp trắng [1]. 1.3. Các phƣơng pháp kiểm thử 1.3.1. Kiểm thử tĩnh Là phương pháp kiểm thử phần mềm thông qua việc sử dụng giấy, bút trên bàn để kiểm tra logic, kiểm tra từng chi tiết ngay sau khi lập trình xong, chủ yếu kiểm tra mã và xem xét các tài liệu đặc tả. Phân tích tĩnh có thể xem xét tất cả các kết quả có thể phát sinh trong quá trình chạy chương trình. Tiêu chuẩn của kiểm thử tĩnh là tối ưu hóa trình biên dịch. 1.3.2. Kiểm thử động Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình. Đó là kiểm thử dựa trên các ca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình. Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động gồm các công việc, nhập giá trị đầu vào và kiểm tra xem đầu ra có đúng kết quả mong muốn không. 9 Các phương pháp kiểm thử động gồm có kiểm thử đơn vị – Unit Test, Kiểm thử tích hợp – Intergration Test, Kiểm thử hệ thống – System Test, và Kiểm thử chấp nhận sản phẩm – Acceptance Test. Bằng cách thực hiện kiểm thử tĩnh và kiểm thử động thì việc phát hiện lỗi sớm sẽ hạn chế lỗi trong quá trình phát triển phần mềm. Trong thực tế thì việc kiểm thử tĩnh và kiểm thử động được thực hiện liên tục và xen kẽ, Những người kiểm thử và các nhà nghiên cứu cần loại bỏ ranh giới giữa tĩnh và động mà nên tạo ra một kiểm thử hỗn hợp để có thể kết hợp thế mạnh của cả hai phương pháp tiếp cận. [1] 1.4. Các kỹ thuật kiểm thử Quá trình thiết kế trường hợp 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. Thiết kê các trường hợp kiểm thử có vai trò: - Tạo ra các trường hợp 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. - Tạo ra các trường hợp 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.[2] Ba trong số những chiến lược kiểm thử thông dụng nhất bao gồm: Kiểm thử hộp đen, Kiểm thử hộp trắng, và Kiểm thử hộp xám. Ở đây ta tìm hiểu kỹ thuật kiểm thử hộp trắng và kỹ thuật kiểm thử hộp đen. 1.4.1. Kiểm thử hộp trắng – White box testing Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu trúc bên trong của phần mềm với mục đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần. Hộp trắng đúng nghĩa phải gọi là hộp trong suốt . Chính vì vậy, kỹ thuật này còn có một số tên khác là kiểm thử hộp thủy tinh (Glass-Box Testing) hay kiểm thử hộp trong suốt (Clear-Box Testing). Người kiểm thử truy nhập vào mã nguồn chương trình để kiểm tra và đây là cơ sở để hỗ trợ việc kiểm thử. Nguyên tắc của kỹ thuật kiểm thử hộp trắng là: - Thực hiện mọi đường dẫn độc lập ít nhất một lần. - Thực hiện mọi điều kiện logic (if-then-else) trên các giá trị true và false của chúng. 10 - Thực hiện mọi vòng lặp (các vòng lặp for, while-do) tại các biên và trong phạm vi hoạt động của chúng. - Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng Hình 1.1. Ví dụ chu trình điều khiển Trong phương pháp kiểm thử hộp trắng, ta đi vào tìm hiểu các kỹ thuật kiểm thử hộp trắng đó là: - Kiểm thử bao phủ chu trình cơ sở - Kiểm thử cấu trúc điều khiển 1.4.1.1. Kiểm thử đường dẫn cơ sở (Basic Path Testing) Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom McCabe đề xuất, là việc thiết kế các trường hợp kiểm thử trên từng câu lệnh trong chương trình được sẽ được thực hiện ít nhất một lần không quan tâm đến ảnh hưởng lên các đường quyết định. Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợp kiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện. Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở. Các trường hợp kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần trong quá trình kiểm thử. Các bước tiến hành xây dựng một tập hợp kiểm thử như sau: - Dùng tài liệu thiết kế hay mã nguồn để vẽ thuật toán của chương trình hay hàm - Xác định đồ thị V(G) - Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau - Xây dựng trường hợp kiểm thử dựa trên tập đường xác định ở trên 11 1.4.1.2. Kiểm thử cấu trúc điều khiển Phương pháp kiểm thử đường dẫn cơ sở là phương pháp đơn giản và hiệu quả, nhưng nó vẫn chưa đủ. Chúng ta sẽ xem xét các biến thể trên kiểm thử cấu trúc điều khiển mà phủ kiểm thử mở rộng và hoàn thiện chất lượng của kỹ thuật kiểm thử hộp trắng. 1.4.1.2.1. Kiểm thử điều kiện Kiểm thử điều kiện là phương pháp thiết kế trường hợp kiểm thử dựa trên các điều kiện logic của hàm hay module chương trình [1]. Các lỗi phát hiện được: - Lỗi do giá trị của biến - Lỗi do dấu ngoặc - Lỗi do phép toán quan hệ - Lỗi trong biểu thức toán học Một số định nghĩa: - Điều kiện đơn: là một biến logic hoặc một biểu thức quan hệ, có thể có toán tử NOT (!) đứng trước, ví dụ, NOT (a>b) - Biểu thức quan hệ: là một biểu thức có dạng E1 E2, trong đó E1, E2 là các biểu thức số học và là toán tử quan hệ có thể là một trong các dạng sau: <, <=, >, >=, = =, !=, ví dụ, a > b+1. - Điều kiện phức: gồm hai hay nhiều điều kiện đơn, toán tử logic AND (&&) hoặc OR (||) hoặc NOT (!) và các dấu ngoặc đơn „(„ và „)‟, ví dụ, (a > b + 1) AND (a <= max). Vì vậy, các thành phần trong một điều kiện có thể gồm phép toán logic, biến logic, cặp dấu ngoặc logic (bao một điều kiện đơn hoặc phức), phép toán quan hệ, hoặc biểu thức toán học. Mục đích của kiểm thử điều kiện là để xác định không chỉ các lỗi điều kiện mà cả các lỗi khác trong chương trình. Có một số phương pháp kiểm thử điều kiện được đề xuất: Kiểm thử nhánh (Branch Testing): là phương pháp kiểm thử điều kiện đơn giản nhất. Kiểm thử miền (Domain Testing): cần 3 hoặc 4 kiểm thử cho biểu thức quan hệ. Với một biểu thức quan hệ có dạng E1 E2, cần có 3 kiểm thử được thiết kế cho E1= = E2, E1 > E2, E1 < E2. 1.4.1.2.2. Kiểm thử luồng dữ liệu Phương pháp kiểm thử luồng dữ liệu lựa chọn một số đường dẫn kiểm thử của chương trình dựa vào vị trí khai báo và sử dụng các biến trong chương trình. Với kiểm 12 thử luồng dữ liệu mỗi câu lệnh trong chương trình được gán số hiệu lệnh duy nhất và mỗi hàm không thay đổi tham số của nó và biến toàn cục. Cho một lệnh với S là số hiệu câu lệnh. Ta định nghĩa [1]: DEF(S) = là tập các biến được khai báo trong S. USE(S) = là tập các biến được sử dụng trong S. Một chiến lược kiểm thử luồng dữ liệu cơ bản là chiến lược mà mỗi chuỗi DU được phủ ít nhất một lần. Chiến lược này được gọi là chiến lược kiểm thử DU. Kiểm thử DU không đảm bảo phủ hết tất cả các nhánh của một chương trình. Tuy nhiên, một nhánh không đảm bảo được phủ bởi kiểm thử DU chỉ trong rất ít tình huống như cấu trúc if-then-else mà trong đó phần then không có một khai báo biến nào và có dạng khuyết (không tồn tại phần else). Trong tình huống đó, nhánh else của lệnh if là không cần thiết phải phủ bằng kiểm thử DU. Chiến lược kiểm thử luồng dữ liệu là rất hữu ích cho việc lựa chọn các đường dẫn kiểm thử của chương trình có chứa các lệnh if hoặc vòng lặp lồng nhau. 1.4.1.2.3. Kiểm thử vòng lặp Vòng lặp là nền tảng cho hầu hết các thuật toán được cài đặt trong phần mềm. Tuy nhiên, chúng ta thường ít quan tâm đến nó khi thực hiện việc kiểm thử phần mềm. Kiểm thử vòng lặp là một kỹ thuật kiểm thử hộp trắng mà tập trung trên tính hợp lệ của các cấu trúc lặp.[2] Vòng lặp đơn Vòng lặp lồng nhau Vòng lặp nối nhau Hình 1.2. Các kiểu vòng lặp 13 Vòng lặp phi cấu trúc 1.4.2. Kiểm thử hộp đen – Black box testing Kỹ thuật kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data-driven) hay là kiểm thử hướng vào/ra (input/output driven). Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen. Người kiểm thử hoàn toàn không quan tâm cấu trúc và hành vi bên trong của phần mềm, chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm không thực hiện theo đúng đặc tả của nó. Vì thế, dữ liệu kiểm thử sẽ xuất phát từ đặc tả. Kiểm thử hộp đen cố gắng tìm các loại lỗi sau: - Các chức năng thiếu hoặc không đúng. - Các lỗi giao diện. - Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài. - Các lỗi thi hành. - Các lỗi khởi tạo hoặc kết thúc. - Và các lỗi khác… Trong phương pháp kiểm thử hộp đen, ta đi vào tìm hiểu các kỹ thuật kiểm thử hộp đen thường được sử dụng trong thực tế: - Phân vùng tương đương – Equivalence partitioning - Phân tích giá trị biên – Boundary value analysis - Kỹ thuật đồ thị nhân - quả - Cause-Effect Graph - Kiểm thử so sánh - Kiểm thử đoán lỗi – Error guesting testing 1.4.2.1. Phân vùng tương đương Như đã trình bày, chúng ta không thể kiểm tra tất cả các giá trị đầu vào của chương trình. Vì thế, khi kiểm thử chương trình, giới hạn một tập con tất cả các trường hợp đầu vào có thể có. Một tập con như vậy cần có hai tính chất: - Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau có thể để giảm thiểu tổng số các trường hợp cần thiết. - Nên cố gắng phân hoạch các miền đầu vào của một chương trình thành một số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểm thử một giá trị đại diện của mỗi lớp là tương đương với việ kiểm thử một giá trị bất kỳ trong cùng lớp. 14 Hai vấn đề xem xét ở trên tạo thành một phương pháp của kỹ thuật hộp đen và gọi là phân hoạch tương đương. Vấn đề thứ hai được sử dụng để phát triển một tập các điều kiện cần quan tâm phải được kiểm thử. Vấn đề thứ nhất được sử dụng để phát triển một tập cực tiểu các trường hợp kiểm thử phủ các điều kiện trên. Thiết kế trường hợp kiểm thử bằng phân hoạch tương đương được xử lý theo hai bước: phân hoạch các miền đầu vào/ra thành các lớp tương đương, và thiết kế các trường hợp kiểm thử đại diện cho mỗi lớp. Phân tích giá trị biên (BVA – Boundary Value Analysis) 1.4.2.2. Khi thực hiện việc kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xem đầu vào của người dùng, kết quả nhận được và kết quả tạm thời bên trong có được xử lý chính xác hay không. Các điều kiện biên là giá trị trực tiếp ở phía trên và dưới của các lớp tương đương đầu vào và lớp tương đương đầu ra. Việc phân tích các giá trị biên khác với phân lớp tương đương theo hai điểm: - Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳ làm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một hoặc một số phần tử. Như vậy, mỗi biên của lớp tương đương chính là đích kiểm thử. - Không chỉ chú ý tập trung vào những điều kiện đầu vào, các trường hợp kiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức các lớp tương đương đầu ra). Rất khó có thể có thể liệt kê hết các hướng dẫn cụ thể cho các trường hợp. Tuy nhiên, cũng có một số nguyên tắc phân tích giá trị biên như sau: 1. Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, các trường hợp kiểm thử sẽ được thiết kế với giá trị a và b, và các giá trị cận trên và cận dưới a và b. 2. Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợp kiểm thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cực tiểu. Các giá trị cận trên và cận dưới, giá trị cực đại, cực tiểu cũng được kiểm thử. 3. Nguyên tắc 1 và 2 được áp dụng cho các điều kiện đầu ra. 15 4. Nếu cấu trúc dữ liệu chương trình bên trong được qui định các biên (chẳng hạn, mảng được định nghĩa giới hạn 100 mục), tập trung thiết kế trường hợp kiểm thử để thực thi cấu trúc dữ liệu tại biên của nó. Ngoài ra, người kiểm thử có thể sử dụng sự xét đoán và sáng tạo của mình để tìm các điều kiện biên. Tóm lại, chúng ta phải kiểm thử mỗi biên của một lớp tương đương về tất cả các phía. Một chương trình nếu vượt qua những trường hợp kiểm thử đó có thể vượt qua các kiểm thử khác từ lớp đó. Kỹ thuật đồ thị nhân - quả (Cause-Effect Graph) 1.4.2.3. Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần phần mềm. Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện. Đồ thị nhân - quả được tạo như sau: 1.4.2.4. - Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được liệt kê dựa trên đặc tả và được định danh cho mỗi nhân - quả. - Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic. - Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân và kết quả. Dữ liệu kiểm thử được sinh ra dựa trên các qui tắc trong các bảng này. Kiểm thử so sánh Có một số trường hợp (như điện tử máy bay, điều khiển thiết bị năng lượng hạt nhân) trong đó độ tin cậy của phần mềm là tuyệt đối quan trọng, người ta thường gọi là phần mềm tuyệt đối đúng. Trong các ứng dụng như vậy phần cứng và phần mềm không cần thiết thường được sử dụng để tối thiểu khả năng lỗi. Khi phần mềm không cần thiết được phát triển, các nhóm công nghệ phần mềm riêng biệt phát triển các phiên bản độc lập của ứng dụng sử dụng cùng một đặc tả. Trong các trường hợp như vậy, mỗi phiên bản có thể được kiểm thử với cùng dữ liệu kiểm thử để đảm bảo rằng tất cả cung cấp đầu ra y như nhau. Sau đó tất cả các phiên bản được thực thi song song với so sánh thời gian thực các kết quả để đảm bảo tính chắc chắn. Các phiên bản độc 16
- Xem thêm -