Tài liệu Nghiên cứu về kiểm thử mô hình ứng dụng Web

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN VIỆT ANH NGHIÊN CỨU VỀ KIỂM THỬ MÔ HÌNH ỨNG DỤNG WEB LUẬN VĂN THẠC SĨ Hà nội - 2012 i ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN VIỆT ANH NGHIÊN CỨU VỀ KIỂM THỬ MÔ HÌNH Ứ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Ĩ NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS NGUYỄN VIỆT HÀ Hà nội - 2012 ii MỤC LỤC LỜI CẢM ƠN ................................................................................................................. i LỜI CAM ĐOAN.......................................................................................................... iv MỤC LỤC ...................................................................................................................... v DANH SÁCH BẢNG BIỂU ......................................................................................... vii DANH MỤC CÁC HÌNH VẼ ..................................................................................... viii BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT ..................................................................... x CHƢƠNG 1 ĐẶT VẤN ĐỀ ........................................................................................... 1 1.1. Lý do chọn đề tài ............................................................................................ 1 1.2. Mục đích và nội dung nghiên cứu ................................................................... 2 1.3. Cấu trúc của luận văn ..................................................................................... 2 CHƢƠNG 2 CƠ SỞ LÝ THUYẾT .............................................................................. 3 Các kỹ thuật kiểm thử.................................................................................. 3 2.1. 2.1.1. Khái niệm kiểm thử .................................................................................. 3 2.1.2. Vòng đời và quy trình kiểm của việc kiểm thử ......................................... 3 2.1.3. Kiểm thử hộp trắng .................................................................................. 4 2.1.4. Kiểm thử hộp đen ..................................................................................... 8 2.1.5. Kiểm thử tích hợp .................................................................................. 10 2.2. Kiểm thử mô hình ứng dụng Web ................................................................. 12 2.2.1. Ứng dụng Web là gì? ............................................................................. 12 2.2.2. Các thành phần của ứng dựng Web ........................................................ 12 2.2.3. So sánh kiểm thử Web và kiểm thử truyền thống ................................... 13 2.2.4. Các kiểm thử cho ứng dụng Web ........................................................... 15 CHƢƠNG 3 BÀI TOÁN VÀ GIẢI PHÁP ............................................................ 30 3.1. Mô tả yêu cầu bài toán .................................................................................. 30 3.2. Giải pháp giải quyết bài toán ........................................................................ 30 3.2.1 Đầu vào cho ứng dụng kiểm thử ............................................................. 32 3.2.2 WebDriver ............................................................................................. 33 3.2.3 Giải pháp ghi lại kết quả đầu ra .............................................................. 35 CHƢƠNG 4 THỰC NGHIỆM ................................................................................... 38 4.1. Cài đặt môi trường kiểm thử ......................................................................... 38 v 4.2. Xây dựng chương trình kiểm thử tự động đăng nhập ứng dụng Web............. 39 4.3. Các bước thực hiện kiểm thử tự động ........................................................... 43 4.4. Kết quả thực nghiệm .................................................................................... 45 4.5. Ý nghĩa chương trình kiểm thử tự động ........................................................ 48 CHƢƠNG 5 KẾT LUẬN............................................................................................ 49 TÀI LIỆU THAM KHẢO ........................................................................................... 50 PHỤC LỤC .................................................................................................................. 51 Phụ lục A. Chương trình kiểm thử đăng nhập tự động ứng dụng Web ............... 51 Phụ lục B. Trường hợp kiểm thử đăng bài viết mới ........................................... 54 Phụ lục C. Trường hợp kiểm thử với Ẩn/Hiện bài viết ...................................... 56 Phụ lục D. Một số hàm API khác ..................................................................... 57 vi DANH SÁCH BẢNG BIỂU Bảng 2.1. Đánh giá yêu tố người dùng. ...................................................................... 16 Bảng 3.2: Lựa chọn phương pháp kiểm thử................................................................ 20 Bảng 4.2. Môi trường thực nghiệm ............................................................................ 38 Bảng 4.3. Chương trình hỗ trợ kiểm thử..................................................................... 38 Bảng 4.4. Môi trường WebDriver .............................................................................. 39 vii DANH MỤC CÁC HÌNH VẼ Hình 2.1. Vòng đời kiểm thử[3]. .................................................................................. 3 Hình 2.2. Sơ đồ khối chu trình điều khiển. ................................................................... 5 Hình 2.3. Đồ thị thuật toán (a), Đồ thị luồng(b) ........................................................... 6 Hình 2.4. Độ phức tạp Cyclomatic. .............................................................................. 7 Hình 2.5. Kiểm thử hộp đen. ........................................................................................ 9 Hình 2.6. Kiểm thử Top-Down. ................................................................................. 11 Hình 2.7. Kiểm thử tích hợp dưới lên. ........................................................................ 11 Hình 2.8. Hệ thống ứng dụng Web 3 tầng. ................................................................. 12 Hình 2.9. Mô hình ứng dụng cho Hệ thống máy tính.................................................. 14 Hình 2.10. Các hệ thống Client – Server. ................................................................... 14 Hình 2.12. Tính nhất quán trong phương pháp thiết kế............................................... 16 Hình 2.13. Ứng dụng hiển thị trên IE 7. ..................................................................... 17 Hình 2.14. Ứng dụng hiển thị trên IE 8. ..................................................................... 17 Hình 2.15. Các lớp ODBC. ........................................................................................ 22 Hình 2.16. Tường lửa................................................................................................. 25 Hình 2.17. Thời gian chấp nhận được của ứng dụng. ................................................. 27 Hình 2.18. Sự mất mát trong kinh doanh do thời gian đáp ứng gây ra. ....................... 27 Hình 2.19. Mô hình thành phần giao tác nguồn tài nguyên. ........................................ 28 Hình 2.20. So sánh trên trình duyệt IE và thiết bị di động. ......................................... 29 Hình 3.1. Mô hình giải quyết bài toán ........................................................................ 31 Hình 3.2. Quá trình thực thi ....................................................................................... 31 Hình 3.3: Kiểm thử chức năng tạo bài viết ................................................................. 32 Hình 3.4: Tệp tin mô tả kiểm thử việc đăng bài viết tự động ...................................... 32 Hình 3.5: Mô hình hóa trực quan các trường hợp kiểm thử ........................................ 33 Hình 3.6: Định vị By Id ............................................................................................. 34 Hình 3.7: Định vị Name ............................................................................................. 34 Hình 3.8: Định vị By Xpath ....................................................................................... 34 Hình 4.1. Giao diện trang chủ. ................................................................................... 39 Hình 4.2. Giao diện đăng nhập ................................................................................... 39 Hình 4.3. Màn hình đăng nhập thành công. ................................................................ 40 Hình 4.4. Bảng trạng thái tương ứng. ....................................................................... 40 Hình 4.5. Mô hình trạng thái trực quan. ..................................................................... 40 Hình 4.6. Mô tả quy trình với trường hợp không nhập User và Pass.......................... 41 Hình 4.7. Mô tả quy trình với trường hợp không nhập User và không nhập Pass ...... 42 Hình 4.8. Mô tả quy trình với trường hợp không nhập Pass và không nhập User ....... 42 Hình 4.9. Mô tả quy trình với trường hợp nhập User và Pass ..................................... 43 Hình 4.10. Mô tả quy trình với trường hợp không nhập Pass và nhập User ............... 43 Hình 4.11. Quy trình ghi kết quả ra tệp tin XML ....................................................... 44 viii Hình 4.12. Quy trình ghi kết quả ra tệp tin Excel ....................................................... 44 Hình 4.13. Quy trình ghi xử lý việc kiểm thử ứng dụng Web ..................................... 45 Hình 4.14. Kết quả ghi ra kiểm thử Login ghi ra tệp tin Excel. ................................. 46 Hình 4.15. Trường hợp đăng nhập thành công ........................................................... 47 Hình 4.16. Trường hợp đăng nhập không thành công................................................. 47 ix BẢNG KÝ HIỆU CÁC CHỮ VIẾT TẮT CSDL Cơ sở dữ liệu HTTP Giao thức truyền tải siêu văn bản(Hyper Text Transfer Protocol) HTTPS Giao thức truyền tải siêu văn bản(Sử dụng bảo mật SSL) URL Định danh địa chỉ tài nguyên trang mạng(Uniform Resource Locator) DBMS Quản trị cơ sở dữ liệu(Database Management Systems) V&V Kiểm chứng và xác nhận V&V(Verification and Validation) BVA Phân tích giá trị biên(Boundary Value Analysis) DLL Thư viện liên kết động(Dynamic link library) XML Ngôn ngữ đánh dấu mở rộng(Extensible Markup Language) x CHƢƠNG 1 ĐẶT VẤN ĐỀ 1.1. Lý do chọn đề tài Những năm gần đầy công nghệ thông tin đã và đang đạt được những bước phát triển tích cực, cùng với sự phát triển mạnh mẽ của cơ sở hạ tầng đặc biệt là hệ thống mạng Internet. Những ứng dụng Web phổ biến nhờ vào sự có mặt bất cứ nơi đâu của một chương trình. Khả năng cập nhật và bảo trì ứng dụng Web mà không phải phân phối và cài đặt phần mềm trên hàng ngàn máy tính là lý do chính cho sự phổ biến của nó. Chính nhờ vào sự phổ biến trên mà các ứng dụng Web giờ đây không chỉ là những ứng dụng đơn giản nữa, mà việc xây dựng các ứng dụng Web đã trở nên phức tạp hơn rất nhiều. Các ứng dụng Web được dùng để thực hiện bán hàng trực tuyến, đấu giá trực tuyến, quản trị quan hệ khách hàng,... Tuy nhiên để triển khai được các ứng dụng Web thì có rất nhiều vấn đề sẽ phát sinh và ảnh hưởng trực tiếp đến các ứng dụng Web như: Tính bảo mật, hiệu suất, các thành phần của ứng dụng Web, giao diện, chức năng, khả năng tương thích của ứng dụng Web với trình duyệt và hệ điều hành,… Vậy để đảm bảo chất lượng các ứng dụng Web hoạt động tốt và không có bất kỳ vấn đề nào khi vận hành, thì cần phải đảm bảo tất cả các vấn đề trên đều được giải quyết một cách triệt để. Muốn làm được điều đó ta phải thực hiện “Kiểm thử ứng dụng web”, đó cũng là các bước chính đảm bảo cho toàn bộ ứng dụng web hoạt động tốt hay không. Và sau khi thực hiện các kiểm thử chúng ta có thể tìm ra những vấn đề phát sinh lỗi để có thể giải quyết trước khi đưa ứng dụng web vào sử dụng thực tế. Hầu hết công việc kiểm thử đều thực hiện một cách thủ công, vì vậy việc kiểm thử thủ công sẽ chỉ có thể tin cậy được khi ứng dụng web nhỏ và không có nhiều chức năng, còn khi ứng dụng Web trở nên phức tạp hơn có rất nhiều chức năng thì việc kiểm thử thủ công trên không còn đáng tin cậy và khả thi nữa. Ví dụ một vài ca kiểm thử bị bỏ qua hoặc gặp phải lỗi người kiểm thử không thể biết được các hoạt động được thực hiện để ghi lại những vấn đề và lỗi đó, ngoài ra việc kiểm thử thủ công có thể tẻ nhạt và tốn thời gian (do thực hiện công việc lặp đi lặp lại, các chức năng có thể giống nhau). Chính vì vậy cần phải có một mô hình hoạt động một cách tự động để khắc phục những vấn đề gặp phải của kiểm thử thủ công. Tuy nhiên trong thực tế để xây dựng một mô hình kiểm thử tự động không phải là công việc dễ dàng mà ngược lại nó rất khó khăn và luôn tiềm ẩn lỗi. Mặc dù mô hình hệ thống đã có sẵn và hoàn chỉnh tuy nhiên không dám khẳng định rằng hoàn toàn đúng đắn vì các ứng dụng web luôn được thay đổi thêm bớt các hành vi hoạt động. Ngoài ra còn một khó khăn nữa là khi thực hiện việc kiểm thử mà bên xây dựng ứng dụng và bên kiểm thử không phải là một nơi phát triển thì khi đó chúng ta không thể có mã nguồn và tài liệu thiết kế đầy đủ thì việc kiểm thử cũng vô cùng khó khăn. 1 Vì vậy, việc tìm hiểu nghiên cứu xây dựng mô hình ứng dụng web tự động không chỉ có ý nghĩa trong việc xây dựng một công cụ kiểm thử tự động mà còn mang tính thực tế cao. Do vậy, mà tôi đã quyết định chọn đề tài: “Nghiên cứu kiểm thử mô hình cho ứng dụng Web” để nghiên cứu. 1.2. Mục đích và nội dung nghiên cứu Trong nội dung của bài luận văn tôi tập trung vào việc nghiên cứu về kỹ thuật kiểm thử. Và dựa trên những kiến thức về kỹ thuật kiểm thử sẽ tìm hiểu về kiểm thử ứng dụng Web. Cuối cùng là xây dựng công cụ thực hiện việc kiểm thử tự động ứng dụng Web dựa trên công cụ mã nguồn mở Selenium và WebDriver. 1.3. Cấu trúc của luận văn Các phần còn lại của luận văn có cấu trúc như sau: Chương 2 giới thiệu về khái niệm kiểm thử và các kỹ thuật kiểm thử thông thường, và cụ thể là kiểm thử hộp trắng, và kiểm thử hộp đen. Dựa trên các kỹ thuật kiểm thử sẽ tập trung tìm hiểu về ứng dụng Web, thành phần ứng dụng Web và các kiểm thử đối với ứng dụng Web như: kiểm thử giao diện, kiểm thử chức năng, kiểm thử cơ sở dữ liệu, kiểm thử hiệu năng và kiểm thử với các thiết bị di động. Chương 3 yêu cầu bài toán về việc xây dựng công cụ kiểm thử tự động các ứng dụng Web. Thông qua việc thực hiện trường hợp kiểm thử đăng nhập vào ứng dụng Web. Công cụ kiểm thử tự động sẽ thực hiện việc đọc các trường hợp đầu vào từ tệp tin Excel, sau khi thực hiện việc kiểm thử chương trình ghi kết quả quá trình kiểm thử ra tệp tin Excel, XML và chụp ảnh màn hình để xem việc kiểm thử là thành công hay thất bại. Và để xây dựng công cụ trên giải pháp đưa ra đó là sử dụng các hàm API được cung cấp bởi công cụ Selenium và WebDriver. Chương 4 thực hiện cài đặt ứng dụng Web và xây dựng các hàm API để thực hiện việc kiểm thử, sau khi thực hiện chương trình đưa ra những kết quả đạt được trong quá trình xây dựng công cụ kiểm thử ứng dụng Web tự động. Chương 5 là Kết luận, hướng nghiên cứu.. 2 CHƢƠNG 2 CƠ SỞ LÝ THUYẾT 2.1. Các kỹ thuật kiểm thử 2.1.1. Khái niệm kiểm thử Có rất nhiều các khái niệm khác nhau về thế nào là kiểm thử, tuy nhiên có một khái niệm về kiểm thử của (Glen Myers) được cho là tổng quát nhất: “Việc kiểm thử là quá trình thực thi một chương trình với mục đích là tìm ra lỗi.” [5] Nếu hiểu theo nghĩa mục đích của (Paul Jorgensen) thì việc thực hiện kiểm thử hiển nhiên là việc tìm lỗi (error), sai sót (fault), hỏng hóc (failure). Vì vậy kiểm thử là một cách chạy các ứng dụng theo các trường hợp kiểm thử với mục tiêu: Tìm ra sai sót và giải thích sự hoạt động 2.1.2. Vòng đời và quy trình kiểm của việc kiểm thử Mục đích chính của việc kiểm thử đó là thiết kết một chuỗi các trường hợp kiểm thử mà có khả năng phát hiện được lỗi cao. Và để cho việc kiểm thử đạt được kết quả tốt nhất thì cần phải có sự chuẩn bị về kế hoạch kiểm thử, trải qua các công đoạn khác nhau đồng thời phải có những biện pháp để khắc phục khi phát hiện ra lỗi. Vòng đời của việc kiểm thử thông thường sẽ trải qua đó là: “Mô tả yêu cầu”, “Phân tích thiết kế”, “Lập trình”, “Kiểm thử”, “Ban giao sản phẩm”. Mô hình của một đời kiểm thử: Hình 2.1. Vòng đời kiểm thử[3]. Từ hình vẽ trên có thể thấy rằng lỗi có thể xảy ra ở từ các giai đoạn, “Mô tả yêu cầu”, “Phân tích thiết kế”, “Lập trình”. Và việc chuyển từ giai đoạn này sang giai đoạn khác cũng có thể phát sinh các sai sót (do dư thừa và thiếu mô tả yêu cầu). Cuối 3 cùng đến giai đoạn kiểm thử chúng ta sẽ phát hiện ra những sai sót và cụ thể là kết quả thu được không như mong đợi. 2.1.3. Kiểm thử hộp trắng Kiểm thử hộp trắng (White-Box Testing) hay còn gọi là kiểm thử logic, cho phép kiểm tra cấu trúc bên trúc bên trong của ứng dụng 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 thi ít nhất một lần. Kiểm thử hộp trắng đúng nghĩa là kiểm thử hộp trong suốt, vì vậy mà kiểm thử hộp trắng còn được gọi bằng một số tên khác đó là kiểm thử hộp thủy tinh (Glass-Box Testing) hay kiểm thử trong suốt (Clear-Box Testing). Người kiểm thử truy cập vào mã nguồn chương trình để kiểm tra và lấy nó làm cơ sở cho việc kiểm thử. Và việc kiểm thử này dựa trên quá trình thực hiện xây dựng chương trình ứng dụng. Kiểm thử hộp trắng còn là phương pháp kiểm thử dựa vào cấu trúc/mã lệnh của chương trình. Phương pháp này cho phép kiểm thử một chương trình (một phần chương trình, hay một hệ thống, một phần của hệ thống) đáp ứng tất cả các giá trị đầu vào bao gồm cả các giá trị không đúng hay không theo dự kiến của chương trình. Khi nói đến vần đề kiểm thử hộp trắng cần quan tâm đến vấn đề đường dẫn lệnh trong kỹ thuật hay phương pháp này. Nếu phải thực hiện tất cả các đường dẫn của đồ thị điều khiển trong chương trình thông quan việc chạy tất cả các trường hợp kiểm thử thì có thể nói rằng chương trình đã được kiểm thử một cách triệt để. Tuy nhiên, điều đó là không thể thực hiện được vì số đường dẫn logic khác nhau trong một chương trình là rất lớn. Ngoài những điều kiện không khả thi trên, chương trình còn có thể có rất nhiều lỗi do các nguyên nhân khác gây ra.Và đây chính là nhược điểm của phương pháp kỹ thuật kiểm thử hộp trắng. - Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chương trình đã tuân theo đặc tả. Một chương trình bị sai do thiếu đường dẫn, việc kiểm thử hộp trắng không thể biết được sự thiếu sót này. Việc kiểm thử bằng kỹ thuật hộp trắng không thể phát hiện được lỗi do dữ liệu gây ra. Như vậy nếu chỉ dùng kỹ thuật kiểm thử hộp trắng đế thực hiện việc kiểm thử là không đủ để phát hiện các lỗi. Vì vậy để thiết kế các trường hợp kiểm thử để cho việc kiểm thử triệt để thì cần phải kết hợp với kiểm thử hộp đen (Black-Box Testing). 4 Hình 2.2. Sơ đồ khối chu trình điều khiển. a) Kiểm thử theo đƣờng dẫn Kiểm thử đường dẫn (Basic Path Testing) là một kỹ thuật kiểm thử hộp trắng. Phương pháp kiểm thử theo đường dẫn 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. 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ử. Đồ thị luồng Trong thực tế phương pháp kiểm thử đường dẫn có thể được dùng mà không cần đồ thị luồng (Flow Graph). Tuy nhiên, đồ thị luồng là một công cụ hữu ích để hiểu được luồng điều khiển và minh họa phương pháp tiếp cận. Trong phần này sẽ trình bày những thành phân cơ bản cấu thành nên đồ thị luồng, và mỗi cấu trúc điều khiển tương ứng có một ký hiệu đồ thị luồng tương ứng. Biểu diễn điều kiện phức trong đồ thị luồng Điều kiện phức trong câu lệnh điều kiện được biểu diễn gồm một hoặc nhiều phép toán logic (AND, OR, NOT) và khi gặp phải điều kiện phức này cần phải được chia thành các điều kiện đơn trong thực hiện kiểm thử đường dẫn cơ sở. Mỗi đỉnh chứa điều kiện gọi là đỉnh điều kiện và đặc trưng bởi hai hoặc nhiều cạnh bắt nguồn từ nó. Ngoài ra từ đồ thi thuật toán chuẩn đổi sang đồ thị luồng, ở trong ví dụ sau đấy từ đồ thị thuật toán 2.6 (a) sẽ được chuyển thành đồ thị lường 2.6 (b)[3] 5 Hình 2.3. Đồ thị thuật toán (a), Đồ thị luồng(b) Độ phức tạp cyclomatic Độ phức tạp Cyclomatic được gọi là thước đo của chương trình ứng dụng, cung cấp phép đo định lượng độ phức tạp của chương trình. Khi được sử dụng trong ngữ cảnh của phương pháp kiểm thử đường dẫn cơ sở, giá trị được xác định độ phức tạp Cyclomatic cho phép số lượng đường dẫn độc lập trong một tập cơ sở của chương trình và cung cấp một giới hạn trên số lượng kiểm thử bắt buộc để đảm bảo rằng tất cả các câu lệnh đều được thực hiện ít nhất một lần. Vậy đường dẫn độc lập ở đây được hiểu là bất kỳ đường đường dẫn nào đi từ đầu đến cuối chương trình và xác định một tập hợp có thêm các lệnh mới hay một điều kiện (chưa xuất hiện trong đường dẫn trước đó). Chúng ta có thể dễ dàng xác định được các đường dẫn động lập cho đồ thị luồng trong hình 2.6 (b): - Đường dẫn 1: 1-11 Đường dẫn 2: 1-2-3-6-8-9-10-1-11 Đường dẫn 3: 1-2-3-6-7-9-10-1-11 Đường dẫn 4: 1-2-3-4-5-10-1-11 Mỗi đường dẫn độc lập mới sẽ đưa ra một cung. Đường dẫn 1-2-3-4-5-10-1-23-6-8-9-10-1-11 không được gọi là đường dẫn độc lập vì nó có một tổ hợp các đường dẫn đã được chỉ ra (đường dẫn 2-3) và nó sẽ không đi qua một cung mới nào. Nếu các trường hợp kiểm thử được thiết kế để thực hiện những đường dẫn này thì mọi lệnh trong chương trình sẽ được đảm bảo thực hiện ít nhất một lần và mọi điều kiện sẽ được thực hiện cả hai trường hợp đúng (true) và sai (false). Tuy nhiên, tập cơ 6 sở đường dẫn không phải là duy nhất. Vì trong thực tế, một số các tập cơ sở khác nhau có thể suy diễn cho việc thiết kế một thủ tục được đưa ra. Và theo một số nghiên cứu đã chỉ ra rằng độ phực tạp Cyclomatic càng cao thì xác suất lỗi càng cao. [3] Hình 2.4. Độ phức tạp Cyclomatic. Một số đặc điểm của độ phức tạp Cyclomatic: - Là số đường dẫn độc lập trong tập các đường dẫn cơ bản của chương trình Giá trị này được xem như cận trên của số lần kiểm thử cần được thực hiện để đảm bảo tất cả các câu lệnh được thực hiện ít nhất một lần. Chính vì vậy việc tính toán độ phức tạp Cyclomatic rất quan trọng sẽ giúp cho chúng ta biết có bao nhiêu đường dẫn cần tìm. Giả sử có đồ thị G, độ phức tạp Cyclomatic V(G) sẽ được tính theo 3 cách sau đây: 1. V(G) = R, R là số vùng của đồ thị luồng. 2. V(G) = P + 1, P là số đỉnh điều kiện có trong đồ thị luồng G 3. V(G) = E – N + 2, E là số cạnh của đồ thị, N là số đỉnh của đồ thị Để hiểu rõ hơn về độ phức tạp của đồ thị luồng, quay lại hình vẽ 2.6 (b) chúng ta thực hiện tính độ phức tạp Cyclomatic như sau: 1. V(G) = 4, Có 4 vùng 2. V(G) = 3 + 1 = 4, có 3 đỉnh điều kiện 3. V(G) = 11 – 9 + 2 = 4, Có 11 cạnh, 9 đỉnh Vậy độ phức tạp trong độ thì luồng hình 2.6 (b) là 4. b) Kiểm thử cấu trúc điều khiển Ở trên chúng ta đã hiểu được kiểm thử đường dẫn cơ sở là phương pháp đơn giản và hiệu quả. Tuy nhiên nếu chỉ sử dụng kiểm thử đường dẫn cơ sở thì chưa đủ được vì vậy chúng ta cần xem xét các biến thể trên kiểm thử cấu trúc điều khiển mà có khả năng 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. 7 Kiểm thử điều kiện (Condition Testing): là phương pháp thiết kế trường hợp kiểm thử thực thi các điều kiện logic trên 2 giá trị true và false. Kiểm thử luồng điểu khiển (Control Flow Testing): là một phương pháp kiểm thử của kiểm thử hộp trắng tạo ra một bộ giá trị bao phủ toàn bộ những trường hợp có thể xảy ra với các thành phần của một chương trình. Kiểm thử luồng điều khiển bao gồm: - Phương thức (Method) Cậu lệnh (Statement) Nhánh (Branch) Điều kiện (Condition) Kiểm thử luồng dữ liệu: Phương pháp kiểm thử luồng dữ liệu (Data Flow Testing) lựa chọn các đườ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 thử luồng dữ liệu mỗi câu lệnh được gán một số hiệu duy nhất và mỗi hàm khi thực hiện không thay đổi tham số và biến toàn cục. Kiểm thử vòng lặp: Vòng lặp là cấu trúc cơ bản của cho hầu hết các giải thuật, tuy nhiên chúng ta thường ít quan tâm đến nó khi thực hiện kiểm thử ứng dụng. Kiểm thử vòng lặp (Loop Testing) là một kỹ thuật của kiểm thử hộp trắng được dùng để kiểm thử tính hợp lệ của cấu trúc lặp. 2.1.4. Kiểm thử hộp đen Kiểm thử hộp đen (Black – Box Testing) hay còn gọi là kiểm thử chức năng, việc thực hiện kiểm thử này không cần quan tâm đến thiết kế và mã nguồn chương trình. Kiểm thử hộp đen chỉ quan tâm đến các chức năng của ứng dụng đã được đề ra. Vì vậy kiểm thử loại này chỉ cần dựa vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng hay không? Ngoài ra kiểm thử hộp đen còn được hiểu là kiểm thử hướng dữ liệu (data – driven) hay kiểm thử hướng vào ra (input/output driven). Và với khái niệm này thì người kiểm thử coi ứng dụng như một chiếc hộp đen, có nghĩa là không quan tâm đến cấu trúc và hoạt động bên trong của chương trình. Kiểm thử hộp đen cho phép các kỹ thuật viên kiểm thử xây dựng các nhóm dữ liệu đầu vào mà sẽ thực thi đầy đủ các yêu cầu chức năng của chương trình. Tuy nhiên, kiểm thử hộp đen không phải là một kỹ thuật thay thế cho kỹ thuật kiểm thử hộp trắng mà là một phương pháp bổ sung giúp phát hiện các loại lỗi khác nhau của phương pháp kiểm thử hộp trắng. Kiểm thử hộp đen thực hiện các trường hợp kiểm thử để cố gắng tìm ra các loại lỗi sau: 8 - Thiếu hoặc sai chức năng Lỗi cấu trúc dữ liệu hay dữ liệu bên ngoài Lỗi giao diện Lỗi bắt đầu hay kết thúc chương trình Lỗi thực thi chương trình Khác với kiểm thử hộp trắng thường được thực thi rất sớm để phát hiện lỗi, còn với kiểm thử hộp đen thường thực thi sau cùng vì nó không quan tâm đến cấu trúc điều khiển mà chỉ tập trung vào miền thông tin. Nếu như mong muốn sử dụng phương pháp này để tìm ra tất cả các lỗi trong chương trình thì điểu kiện bắt buộc là phải kiểm thử tất cả các giá trị đầu vào, bởi vì nếu chỉ kiểm thử một giá trị đầu vào thôi thì không dám đảm bảo chương trình có lỗi hay không. Tuy nhiên, điều này trong thực tế là không thể thực hiện được. Hình 2.5. Kiểm thử hộp đen. Phân chia tƣơng đƣơng a) Như trình bày ở trên về kiểm thử hộp đen, muốn thực hiện kiểm thử tất cả đầu vào là điều không thể thực hiện được. Chính vì vậy mà cần phải thực hiện việc phân chia (nếu có thể) các lớp đầu vào để tạo ra một tập hợp các đầu vào nếu có thể. Phân chia tương đương sẽ bao gồm 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 kiểm thử. Nên cố gắng phân chia 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ệc kiểm thử một giá trị bất kỳ của lớp đó. Phân tích giá trị biên (BVA – Boundary Value Analysis) b) Các điều kiện biên là tình trạng 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 giá trị biên khác với phương pháp phân chia tương đương ở hai điểm: - Từ mỗi lớp tương đương, phân chia tương đương sẽ chọn phân tử bất kỳ làm phần tử đại diện, trong khi phân tich 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 là đích của kiểm thử. 9 - Không 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 là các lớp tương đương đầu ra) Kỹ thuật đồ thị nhân quả c) Đồ thị nhân quả (Cause – Effect Graph) là một phương pháp giúp cho việc thiết kế các trường hợp kiểm thử trên cơ sở đưa ra mô tả súc tích các điều kiện logic và các hành vi kèm theo. Đồ thị nhân qua 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 chương trình. 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 với đầu vào. Mỗi kết quả được biểu diễn như một biểu thức Bool biểu diễn 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 ra nhƣ sau: - Tất 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 (đầu vào) và kết quả (đầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic. Từ đồ thị nhân quả ta tạo ra bảng quyết định nguyên nhân và kết quả. Và các dữ liệu kiểm thử được sinh ra trong các qui tắc của bảng này. 2.1.5. Kiểm thử tích hợp Chúng ta thường tự đặt ra câu hỏi là khi mọi module đã được kiểm thử đơn vị xong, nếu tất cả chúng đều làm việc tốt riêng biệt thì tại sao chúng ta lại hoài nghi khi kết hợp các module riêng biệt đó với nhau? Vậy vấn đề ở chỗ là khi chúng ta thực hiện gắn chúng với nhau và làm giao diện cho chúng, thì từ đây dữ liệu có thể mất qua giao diện, một module có thể gặp vần đề sẽ ảnh hưởng đến module khác, các chức năng con khi kết hợp lại không tạo ra một chính năng chính như mong muốn. Kiểm thử tích hợp là một kỹ thuật hệ thống xây dựng cấu trúc chương trình trong khi đồng thời tiến hành các kiểm thử để phát hiện lỗi liên kết với giao tiếp. Mục đích là lấy các module đã được kiểm thử đơn vị xong và xây dựng nên một chương trình được quy định bởi thiết kế. a) Kiểm thử tích hợp từ trên xuống Kiểm thử tích hợp trên xuống (Top-Down) là tiếp cận tằng dần tới việc xây dựng cấu trúc chương trình. Các module được tích hợp bằng cách đi dần xuống qua các cấp bậc điều khiển, bắt đầu với module chính. Các module phụ thuộc vào module chính sẽ được tổ hợp dẫn vào trong cấu trúc theo chiều sâu trước hoặc chiều rộng trước. 10 Hình 2.6. Kiểm thử Top-Down. b) Kiểm thử tích hợp từ dƣới lên Kiểm thử tích hợp dưới lên (Bottom-Up) bắt đầu xây dựng và kiểm thử với các module nguyên tử (tức là các module ở mức thấp nhất trong chương trình). Chiến lược kiểm thử dưới lên được thực hiện qua các bước sau: 1. Các module ở mức thấp được kết hợp thành các nhóm (cluster). 2. Bộ điều khiển (chương trình điểu khiển cho việc kiểm thử) được viết để phối hợp các trường hợp kiểm thử đầu vào và đầu ra. 3. Kiểm thử nhóm. 4. Các bộ điều khiển được loại bỏ và các nhóm được kết hợp chuyển dịch lên trên trong cấu trúc chương trình. Hình 2.7. Kiểm thử tích hợp dưới lên. 11 2.2. Kiểm thử mô hình ứng dụng Web 2.2.1. Ứng dụng Web là gì? Trong kỹ thuật phần mềm, một ứng dụng Web hay một Webapp là một trình ứng dụng mà có thể tiếp cận qua web thông qua mạng như Internet. Các ứng dụng Web là các ứng dụng phần mềm trên nền tảng độc lập được chạy trên web server hoặc trên ứng dụng server, cùng với giao diện người dùng với trình duyệt web của phía người dùng. Đồng thời thực hiện việc giao tiếp thông qua mạng máy tính. Kiến trúc ứng dụng của các ứng dụng web được gọi là mô hình Client – Server. Trong mô hình này Client gửi yêu cầu đến Server, Server lần lượt xử lý các yêu cầu và cung cấp các câu trả lời cho phía Client. Điều này có nghĩa là chu trình đáp ứng yêu cầu và đặt nền tảng cho các ứng dụng Web. Hầu hết các ứng dụng web sử dụng giao thức HTTP. 2.2.2. Các thành phần của ứng dựng Web Nếu chúng ta hiểu được các thành phần bên trong của một ứng dụng Web và sự giao tiếp của các thành phần đó hoạt động với nhau như thế nào thì sẽ giúp cho việc kiểm tử của chúng ta tốt hơn rất nhiều. Thông thường chúng ta hiểu được kiến trúc của một ứng dụng Web thông qua việc đọc mã nguồn. Và một cách khác nữa là phân tích sự giao tiếp giữa các thành phần. Tuy nhiên, chúng ta vẫn cần phải nắm được kiến trúc của ứng dụng Web ở mức độ thành phần để có thể biết được các loại lỗi cần tìm và các câu hỏi đặt ra. Hệ thống Client – Server: trên Web được nhóm thành ba tầng liên quan đến nhau: (1) các thành phần dịch vụ phía người dùng, (2) các thành phần dịch vụ xử lý, (3) các thành phần dịch vụ dữ liệu. [5] Hình 2.8. Hệ thống ứng dụng Web 3 tầng. Các thành phần phần mềm: Mỗi thành phần trong một hệ thống ứng dụng web thì cung cấp một chức năng hay một nhóm các chức năng cụ thể có liên quan đến 12