Tài liệu Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng web

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ ĐOÀN MẠNH ĐỨC NGHIÊN CỨU VÀ XÂY DỰNG CÔNG CỤ KIỂM THỬ ỨNG DỤNG WEB 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Ệ ĐOÀN MẠNH ĐỨC NGHIÊN CỨU VÀ XÂY DỰNG CÔNG CỤ KIỂM THỬ ỨNG DỤNG WEB 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. VÕ ĐÌNH HIẾU Hà Nội – 2014 1 LỜI CẢM ƠN Luận văn Thạc sĩ này được thực hiện tại Đại học Công Nghệ - Đại học Quốc Gia Hà Nội dưới sự hướng dẫn của TS. Võ Đình Hiếu. Xin được gửi lời cảm ơn sâu sắc đến thầy về định hướng khoa học, liên tục quan tâm, tạo điều kiện thuận lợi trong suốt quá trình nghiên cứu hoàn thành luận văn này. Tôi xin được gửi lời cảm ơn đến các thầy, cô trong Bộ môn Công nghệ phần mềm cũng như Khoa Công nghệ thông tin đã mang lại cho tôi những kiến thức vô cùng quý giá và bổ ích trong quá trình theo học tại trường. Tôi cũng xin chân thành cảm ơn đến gia đình tôi, những sự quan tâm và động viên của bố, mẹ và em gái đã giúp tôi có thêm nghị lực, cố gắng để hoàn thành luận văn này. Cuối cùng, xin gửi lời cảm ơn chân thành nhất đến các bạn cùng học K19, các bạn đồng nghiệp đã giúp đỡ tôi trong suốt 2 năm học tập. Hà Nội, ngày 30 tháng 10 năm 2014 Đoàn Mạnh Đức 2 LỜI CAM ĐOAN Tôi xin cam đoan luận văn “Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng Web” là công trình nghiên cứu của cá nhân tôi dưới sự hướng dẫn của TS. Võ Đình Hiếu, trung thực và không sao chép của tác giả khác. Trong toàn bộ nội dung nghiên cứu của luận văn, các vấn đề được trình bày đều là những tìm hiểu và nghiên cứu của chính cá nhân tôi hoặc là được trích dẫn từ các nguồn tài liệu có ghi tham khảo rõ ràng, hợp pháp. Tôi xin chịu mọi trách nhiệm và mọi hình thức kỷ luật theo quy định cho lời cam đoan này. Hà Nội, ngày 30 tháng 10 năm 2014 Đoàn Mạnh Đức 3 MỤC LỤC LỜI CẢM ƠN ........................................................................................................................... 1 LỜI CAM ĐOAN ..................................................................................................................... 2 MỤC LỤC ................................................................................................................................. 3 DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT ........................................................... 5 DANH MỤC CÁC BẢNG........................................................................................................ 6 DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ.................................................................................. 7 LỜI GIỚI THIỆU..................................................................................................................... 9 CHƢƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM ............................................... 11 1.1. Các khái niệm cơ bản ................................................................................................... 11 1.1.1. Khái niệm kiểm thử phần mềm .............................................................................. 11 1.1.2. Mức kiểm thử ......................................................................................................... 12 1.1.3. Kiểm thử tự động .................................................................................................... 18 1.1.4. Ứng dụng Web........................................................................................................ 19 1.2. Kỹ thuật kiểm thử tĩnh .................................................................................................. 20 1.2.1. Rà soát .................................................................................................................... 20 1.2.2. Kiểm thử dòng dữ liệu tĩnh..................................................................................... 21 1.3. Kỹ thuật kiểm thử động ................................................................................................ 23 1.3.1. Kiểm thử hàm ......................................................................................................... 23 1.3.2. Kiểm thử dòng điều khiển ...................................................................................... 24 1.3.3. Kiểm thử dòng dữ liệu động ................................................................................... 26 1.4. Các loại kiểm thử ứng dụng Web .................................................................................. 29 CHƢƠNG 2 CÁC CÔNG CỤ KIỂM THỬ TỰ ĐỘNG CHO CÁC ỨNG DỤNG WEB 33 2.1. Công cụ kiểm thử tự động tĩnh ..................................................................................... 33 2.1.1. Công cụ kiểm thử ngôn ngữ lập trình phía máy chủ .............................................. 33 2.1.2. Công cụ kiểm thử ngôn ngữ lập trình phía máy khách .......................................... 35 2.2. Công cụ kiểm thử tự động động ................................................................................... 37 2.2.1. Công cụ kiểm thử giao diện người dùng ................................................................ 37 2.2.2. Công cụ kiểm thử hàm............................................................................................ 38 2.2.3. Công cụ kiểm thử khả năng chịu tải của ứng dụng Web ........................................ 40 2.3. Thư viện hỗ trợ xây dựng công cụ kiểm thử tự động ................................................... 41 CHƢƠNG 3 XÂY DỰNG CÔNG CỤ KIỂM THỬ TỰ ĐỘNG ........................................ 44 3.1. Đặt vấn đề bài toán ....................................................................................................... 44 4 3.2. Phân tích bài toán ......................................................................................................... 45 3.3. Thỏa thuận khi sử dụng công cụ ................................................................................... 50 3.4. Xây dựng công cụ ......................................................................................................... 50 3.5. Ứng dụng công cụ vào thực tế ...................................................................................... 54 3.5.1. Ứng dụng vào form thành viên đăng nhập ............................................................. 54 3.5.2. Ứng dụng vào form đăng ký nhận bản tin .............................................................. 58 3.6. Đánh giá ưu nhược điểm của công cụ .......................................................................... 60 CHƢƠNG 4 KẾT LUẬN ....................................................................................................... 61 4.1. Tóm tắt kết quả làm được .............................................................................................. 61 4.2. Hạn chế .......................................................................................................................... 61 4.3. Hướng nghiên cứu ......................................................................................................... 61 TÀI LIỆU THAM KHẢO...................................................................................................... 62 PHỤ LỤC ................................................................................................................................ 63 Phụ lục 1: Kết quả sau khi thực hiện kiểm thử form thành viên đăng nhập ......................... 63 Phụ lục 2: Kết quả sau khi thực hiện kiểm thử form đăng ký nhận bản tin ......................... 64 5 DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT API C-S CSS HTML HTTP HTTPS STT TDD URL Application Programming Interface, giao diện lập trình ứng dụng. Client-Server, máy khách – máy chủ. Cascading Style Sheets, là ngôn ngữ được dùng để miêu tả cách trình bày các tài liệu viết bằng ngôn ngữ HTML và XHTML. Hypertext Markup Language, ngôn ngữ đánh dấu tạo website. HyperText Transfer Protocol - Giao thức truyền tải siêu văn bản được dùng để trao đổi giữa máy khách và máy chủ ứng dụng Web. Hypertext Transfer Protocol Secure, là sự kết hợp giữa giao thức HTTP và giao thức bảo mật SSL hay TLS cho phép trao đổi thông tin một cách bảo mật trên Internet. Số thứ tự Testing Driven Development, kỹ thuật phát triển phần mềm dựa trên kiểm thử. Uniform Resource Locator, đường dẫn tham chiếu tới tài nguyên trên Internet. 6 DANH MỤC CÁC BẢNG Bảng 1.1. Các điều kiện con kết hợp trong câu lệnh điều kiện ..................................... 26 Bảng 1.2. Một số lỗi thường gặp trên ứng dụng Web ................................................... 32 Bảng 2.1. Minh họa một số quy ước về lập trình của Microsoft. .................................. 34 Bảng 2.2. Hàm và từ khóa thường dùng của Selenium WebDriver .............................. 42 Bảng 3.1. Một số điều kiện đầu vào với input trong ứng dụng Web ............................ 47 Bảng 3.2. Một số dữ liệu đầu vào mẫu cho input ngày tháng Việt Nam ...................... 49 Bảng 3.3. Kết quả thực hiện kiểm thử bằng công cụ kiểm thử tự động với form đăng ký nhận bản tin .............................................................................................................. 59 7 DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ Hình 1.1. Mã nguồn minh họa Driver và Stub .............................................................. 13 Hình 1.2. Kiểm thử hồi quy được thực hiện tại các mức kiểm thử khác nhau. ............. 17 Hình 1.3. Các câu lệnh tuần tự có bất thường loại 1. .................................................... 22 Hình 1.4. Câu lệnh có bất thường loại 2. ....................................................................... 22 Hình 1.5. Sơ đồ chuyển trạng thái của một biến tương ứng với những bất thường về dòng dữ liệu. .................................................................................................................. 23 Hình 1.6. Các biểu tượng xây dựng đồ thị dòng điều khiển. ........................................ 25 Hình 1.7. Mã nguồn tính tổng các số từ 1 đến 9. .......................................................... 25 Hình 1.8. Đồ thị dòng điều khiển của mã nguồn hình 1.9............................................. 25 Hình 1.9. Ví dụ mã nguồn hàm ReturnAverage. ........................................................... 27 Hình 1.10. Đồ thị dòng dữ liệu minh họa hàm ReturnAverage. ................................... 28 Hình 2.1. Giao diện Fxcop ............................................................................................ 33 Hình 2.2. Mã nguồn được phân tích bởi Fxcop ............................................................. 34 Hình 2.3. Kết quả phân tích từ Fxcop ........................................................................... 35 Hình 2.4. Giao diện công cụ JSLint .............................................................................. 36 Hình 2.5. Mã nguồn được phân tích bởi JSLint ............................................................ 36 Hình 2.6. Kết quả phân tích từ JSLint ........................................................................... 36 Hình 2.7. Giao diện Browser Shots ............................................................................... 38 Hình 2.8. Giao diện người dùng trên các trình duyệt khác nhau. .................................. 38 Hình 2.9. Giao diện Selenium IDE. ............................................................................... 38 Hình 2.10. Các thao tác xử lý được Selenium IDE ghi lại. ........................................... 39 Hình 2.11. Mã HTML của ca kiểm thử được Selenium IDE lưu lại. ............................ 40 Hình 2.12. Giao diện công cụ loader.io ......................................................................... 41 Hình 2.13. Kết quả khi thực thi kiểm thử với loader.io. ............................................... 41 Hình 3.1. Form thêm người dùng trên ứng dụng Web. ................................................. 44 Hình 3.2. Minh họa hộp thông báo đăng nhập thành công ........................................... 46 Hình 3.3. Minh họa dòng thông báo từ ứng dụng Web đến người dùng ...................... 46 8 Hình 3.4. Các dữ liệu mẫu sinh ra từ kỹ thuật kiểm thử giá trị biên mạnh. .................. 49 Hình 3.5. Giao diện công cụ kiểm thử tự động. ............................................................ 50 Hình 3.6. Thêm ô textbox chứa input. ........................................................................... 51 Hình 3.7. Lựa chọn các điều kiện cần kiểm thử của input. ........................................... 51 Hình 3.8. Lỗi xuất hiện được thông báo cho kiểm thử viên. ......................................... 52 Hình 3.9. Kiểm tra tính hợp lệ của điều kiện của độ dài tối thiểu và tối đa. ................. 52 Hình 3.10. Thông báo không tìm thấy phần tử có id như đã nhập. ............................... 53 Hình 3.11. Điều kiện và giá trị được sinh ra khi lựa chọn điều kiện cho input. ........... 53 Hình 3.12. Mã nguồn hàm ngẫu nhiên sinh ra chuỗi ký tự có độ dài là........................ 53 tham số truyền vào. ........................................................................................................ 54 Hình 3.13. Kết quả sau khi thực hiện kiểm thử form. ................................................... 54 Hình 3.14. Giao diện form thành viên đăng nhập. ........................................................ 55 Hình 3.15. Thông báo không được bỏ trống tên đăng nhập. ......................................... 55 Hình 3.16. Thông báo tên đăng nhập không được nhỏ hơn 6 ký tự. ............................. 55 Hình 3.17. Thông báo sai tên đăng nhập hoặc mật khẩu. .............................................. 55 Hình 3.18. Lấy id của input. .......................................................................................... 56 Hình 3.19. Điền thông tin form thành viên đăng nhập vào công cụ. ............................ 56 Hình 3.20. Chọn điều kiện cho các input. ..................................................................... 57 Hình 3.21. Kết quả kiểm thử form thành viên đăng nhập. ............................................ 57 Hình 3.22. Giao diện form đăng ký nhận bản tin. ......................................................... 58 Hình 3.23. Thông báo không được bỏ trống email. ...................................................... 58 Hình 3.24. Thông báo nhập sai định dạng email. .......................................................... 58 Hình 3.25. Điền thông tin form đăng ký nhận bản tin vào công cụ. ............................. 59 Hình 3.26. Chọn điều kiện cho input email. .................................................................. 59 9 LỜI GIỚI THIỆU Với sự phát triển của Internet và công nghệ phần mềm, các ứng dụng Web đang dần thay thế các ứng dụng phần mềm truyền thống bởi tính tiện lợi của nó. Đi kèm với thành công mà những ứng dụng Web mang lại cho nhà phát triển đó là những thách thức như phải đảm bảo và nâng cao chất lượng cho người dùng khi sử dụng dịch vụ. Một trong những giải pháp để hoàn thành tốt công việc này đó là thực hiện kiểm thử phần mềm. Kiểm thử là một công việc tốn nhiều thời gian và chi phí, thông thường thời gian dành cho việc kiểm thử chiếm đa số thời gian phát triển ứng dụng phần mềm. Tuy nhiên, để thực hiện kiểm thử đòi hỏi kiểm thử viên phải kiên nhẫn và tỉ mỉ, chính những điều này dẫn tới sự cần thiết của kiểm thử tự động. Kiểm thử tự động sẽ thực hiện tự động các ca kiểm thử theo một kịch bản cho sẵn hoặc tự nó sinh ra. Những lợi ích của các công cụ kiểm thử tự động mang lại là rất lớn tuy nhiên các tài liệu về kiểm thử tự động được viết bằng tiếng Việt lại còn rất hạn chế. Xuất phát từ thực tế đó và được sự gợi ý của giảng viên hướng dẫn, tôi lựa chọn đề tài luận văn “Nghiên cứu và xây dựng công cụ kiểm thử ứng dụng Web” với mong muốn mang lại cho người đọc một tài liệu hỗ trợ hữu ích trước khi quyết định sử dụng kiểm thử tự động cho ứng dụng Web của mình. Luận văn đƣợc cấu trúc thành bốn chƣơng: Chương một sẽ trình bày các tìm hiểu về kiểm thử phần mềm như các khái niệm cơ bản về kiểm thử, các mức kiểm thử, ca kiểm thử, các kỹ thuật kiểm thử tĩnh và động. Chương một cũng sẽ đưa ra khái niệm về ứng dụng Web, phân biệt ứng dụng Web với ứng dụng máy khách – máy chủ và các loại kiểm thử cần chú trọng cho ứng dụng Web. Chương hai sẽ giới thiệu các công cụ kiểm thử tự động phổ biến hiện nay dành cho ứng dụng Web, ngoài việc cung cấp thông tin và cách sử dụng từng công cụ, luận văn còn phân tích ưu nhược điểm của các công cụ giúp người đọc có một gợi ý trước khi lựa chọn công cụ phù hợp cho ứng dụng cần kiểm thử. Xuất phát trên thực tế, mỗi ứng dụng Web đều có những yêu cầu đặc thù riêng biệt nên việc sử dụng các công cụ kiểm thử tự động đã có sẵn có thể không thỏa mãn hoặc phù hợp với việc kiểm thử các ứng dụng này. Luận văn cũng giới thiệu một nền tảng hỗ trợ xây dựng công cụ kiểm thử tự động nhằm giúp người đọc có thể lựa chọn nền tảng giúp tự tạo công cụ kiểm thử cho phù hợp với nhu cầu của mình. Trong ứng dụng Web, việc kiểm tra tính hợp lệ của các dữ liệu đầu vào là rất quan trọng do dữ liệu đầu vào không chỉ yêu cầu phải đúng kiểu dữ liệu mà còn đòi 10 hỏi phải đúng định dạng của loại dữ liệu đó. Do đó, ứng dụng Web cần phải có khả năng kiểm tra tính hợp lệ của dữ liệu đầu vào một cách hiệu quả thì các tiến trình xử lý tiếp theo mới được đảm bảo hoạt động tốt. Một vấn đề nữa là hiện nay có rất nhiều công cụ hỗ trợ cho việc kiểm thử tự động ứng dụng Web, tuy nhiên hầu hết các công cụ chỉ hỗ trợ cho việc thực thi tự động các ca kiểm thử còn việc thiết kế các ca kiểm thử lại rất hạn chế. Chương ba sẽ trình bày về ý tưởng, phân tích và xây dựng công cụ kiểm thử tự động nhằm đánh giá khả năng kiểm tra tính hợp lệ dữ liệu đầu vào của ứng dụng Web. Công cụ được đề xuất có khả năng tự sinh ca kiểm thử, thực thi và lưu lại kết quả kiểm thử. Ngoài ra chương này cũng minh họa áp dụng công cụ trong thực tế và đánh giá ưu nhược điểm của công cụ cùng hướng phát triển. Chương bốn sẽ đưa kết luận về các nội dung đạt được trong luận văn, các mặt hạn chế và hướng phát triển trong thời gian tới của luận văn. 11 CHƢƠNG 1 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 1.1. Các khái niệm cơ bản 1.1.1. Khái niệm kiểm thử phần mềm Kiểm thử phần mềm là công việc được thực hiện nhằm tìm ra lỗi, thiếu sót của phần mềm hoặc chứng minh phần mềm hoạt động đúng đắn. Kiểm thử phần mềm có vai trò rất quan trọng trong việc cải thiện chất lượng phần mềm [4, tr.655-657] và làm giảm chi phí kiểm thử cũng như khắc phục lỗi. Kiểm thử phần mềm sử dụng quy trình kiểm chứng và thẩm định chất lượng phần mềm trong quá trình thực hiện việc kiểm thử. Quy trình kiểm chứng sẽ đảm bảo rằng phần mềm khi được phát triển sẽ đúng với đặc tả của nó và quy trình thẩm định thì sẽ đảm bảo rằng phần mềm thỏa mãn được yêu cầu của người dùng cuối. Quy trình kiểm chứng sẽ được thực hiện trước quy trình thẩm định do sản phẩm phần mềm cần đúng với đặc tả trước. Nếu thực hiện quy trình thẩm định trước quy trình đặc tả, nếu xảy ra lỗi, rất khó có thể xác định lỗi này là do đặc tả sai hay do lập trình sai so với đặc tả. Tuy nhiên, thẩm định nếu được thực hiện quá muộn thì khi phát hiện ra lỗi hoặc thiếu sót sẽ kéo theo chi phí khắc phục lỗi tăng đồng thời khiến thời gian hoàn thiện phần mềm kéo dài. Vì vậy, quy trình thẩm định nên được thực hiện sớm để góp phần làm giảm chi phí cũng như thời gian phát triển sản phẩm phần mềm. Trong phương pháp phát triển phần mềm Agile [4, tr.58-64], khách hàng sẽ đóng vai trò là một thành viên của nhóm phát triển và thực hiện việc thẩm định sản phẩm phần mềm liên tục sau mỗi vòng lặp phát triển trong suốt quá trình thực hiện dự án phần mềm. Chính điều này giúp cho việc phát triển phần mềm theo phương pháp Agile trở nên rất nhanh chóng và giảm được nhiều chi phí cho việc sửa lỗi do lỗi được phát hiện từ rất sớm. Trong kiểm thử phần mềm, các khái niệm như lỗi, sai, khuyết thiếu, thất bại đều có nghĩa khá gần nhau nhưng trên thực tế cần phân biệt rõ các khái niệm này.  Lỗi: do lập trình viên phạm phải trong quá trình lập trình. Khi lỗi được thực thi sẽ dẫn tới thất bại.  Sai: bắt nguồn từ lỗi, do quá trình thực hiện không tuân theo quy trình dẫn đến phần mềm thực hiện một cách không xác định.  Thất bại: xảy ra khi chức năng của phần mềm không thực hiện đúng như mong đợi.  Khuyết thiếu: là sự thiếu sót các trường hợp có thể xảy ra khi phần mềm hoạt động, có thể do đặc tả thiếu hoặc thiếu sót khi lập trình. 12 Kiểm thử phần mềm có thể chia làm hai nhóm kỹ thuật chính là kỹ thuật kiểm thử tĩnh và kỹ thuật kiểm thử động. Kiểm thử tĩnh là kỹ thuật không yêu cầu phải biên dịch và chạy mã nguồn chương trình để thực hiện việc kiểm thử phần mềm. Kỹ thuật này kiểm thử chương trình bằng cách kiểm tra cú pháp, cấu trúc mã nguồn của chương trình hoặc rà soát các tài liệu liên quan như tài liệu đặc tả, tài liệu thiết kế để tìm ra lỗi. Trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử tĩnh được sử dụng trong quy trình kiểm chứng. Kiểm thử động là kỹ thuật chỉ được thực hiện khi mã nguồn chương trình phần mềm được biên dịch và chạy. Mục đích chính của kỹ thuật kiểm thử động là thẩm định xem chương trình phần mềm có hoạt động đúng và đầy đủ các chức năng như những mong muốn của người sử dụng hay không, do đó trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử động được sử dụng trong quy trình thẩm định. 1.1.2. Mức kiểm thử Một sản phẩm phần mềm từ khi bắt đầu phát triển đến khi hoàn thành và đưa đến tay người dùng cuối phải trải qua bốn mức kiểm thử đó là: Kiểm thử mức đơn vị, mức tích hợp, mức hệ thống và mức chấp nhận. Kiểm thử mức đơn vị Kiểm thử mức đơn vị hay còn gọi là kiểm thử thành phần (module testing) là mức thấp nhất trong các mức độ kiểm thử. Đơn vị ở đây có thể là một chức năng cụ thể, một hàm (function), một lớp trong lập trình hướng đối tượng hoặc một thành phần nhỏ đã hoàn thiện trong chương trình. Thường thì các lập trình viên sẽ đảm nhận kiểm thử ở mức này để đảm bảo thời gian do việc phát hiện và sửa lỗi cần được thực hiện liên tục. Có thể áp dụng tất cả các kỹ thuật kiểm thử được nêu ở 1.2 và 1.3 để kiểm thử mức đơn vị. Đa số các lỗi của chương trình đều được phát hiện ở mức đơn vị, các lỗi về tích hợp chưa xuất hiện ở mức này. Càng nhiều lỗi được tìm và sửa ở mức này sẽ càng giúp giảm lỗi ở những giai đoạn phát triển sau của chương trình. Hiện nay, trong phương pháp phát triển phần mềm Agile có một kỹ thuật lập trình khá hiệu quả đó là phát triển dựa trên kiểm thử [4, tr.221-224] (TDD – Testing Driven Development), các lập trình viên sẽ thiết kế các ca kiểm thử trước khi lập trình và từ đó lập trình các chức năng để thỏa mãn các ca kiểm thử. Việc xây dựng trước các ca kiểm thử sẽ giúp lập trình viên xác định được những thiếu sót hay lỗi có thể có nhằm hạn chế lỗi và rút ngắn thời gian thực hiện một cách hiệu quả. Do đơn vị là một thành phần nhỏ trong chương trình nên không thể hoạt động độc lập, để thực hiện kiểm thử động cần giả lập các Driver và Stub. Driver sẽ đóng vai trò gọi thực thi đơn vị còn Stub đóng vai trò là các đơn vị có giao tiếp với đơn vị đang xét. Xét một ví dụ cụ thể với đơn vị được kiểm thử là một hàm có tên TinhNghiemPTBac2 viết bằng ngôn ngữ lập trình C# có nhiệm vụ tính nghiệm của phương trình bậc hai một ẩn số. Tham số đầu vào của hàm là các biến a, b, c kiểu số 13 thực và hàm này có gọi một hàm khác làm nhiệm vụ tính delta. Driver trong ví dụ này sẽ gán cứng ba tham số a, b, c sau đó gọi và truyền ba tham số này cho hàm TinhNghiemPTBac2. Stub ở đây là hàm tính delta có tên TinhDelta, có thể tính hoặc gán cứng giá trị trả về để kiểm tra xem hàm TinhNghiemPTBac2 hoạt động ra sao. public void TinhNghiemPTBac2(double a, double b, double c) { double x1, x2; double delta = TinhDelta(a, b, c); if(delta < 0) Console.WriteLine(“Phuong trinh vo nghiem”); else if (delta == 0) { x1 = -b / 2 * a; Console.WriteLine(“Phuong trinh co 1 nghiem duy nhat x = ” + x1); } else { x1 = (-b + Math.Sqrt(delta)) / 2 * a; x2 = (-b - Math.Sqrt(delta)) / 2 * a; Console.WriteLine(“Phuong trinh co 2 nghiem x1=”+ x1 +“,x2= ” + x2); } } public void Driver() { double a = 2, b = 9, c = 4; TinhNghiemPTBac2(a, b, c); } public double TinhDelta(double a, double b, double c) { return b * b – 4 * a * c; } Hình 1.1. Mã nguồn minh họa Driver và Stub 14 Kiểm thử mức đơn vị có ưu điểm là giúp người thực hiện dễ dàng xác định và sửa lỗi do phạm vi kiểm thử là rất nhỏ. Việc phát hiện lỗi sớm sẽ giảm chi phí kiểm thử so với việc phát hiện lỗi muộn ở những giai đoạn phát triển sau. Tuy nhiên kiểm thử mức đơn vị có một số nhược điểm như tốn nhiều thời gian để thực hiện, chưa phát hiện được các lỗi xảy ra khi tích hợp, ngoài ra Driver và Stub là giả lập chứ không phải chương trình hoàn chỉnh nên vẫn có thể có thiếu sót nhất định. Kiểm thử mức tích hợp Sau khi một đơn vị chương trình hoàn thành việc kiểm thử mức đơn vị, đơn vị này sẽ được tích hợp với các đơn vị chương trình khác có liên quan để dần tạo nên chương trình tổng thể. Các chức năng mà đơn vị chương trình cung cấp cũng như các tham số cần truyền để sử dụng sẽ được thông qua giao diện. Các đơn vị khi được tích hợp sẽ làm việc với nhau thông qua các giao diện. Các loại giao diện chủ yếu chia làm ba loại chính:  Giao diện gọi hàm: một hàm trong đơn vị này sẽ gọi một hàm ở đơn vị khác.  Giao diện dùng chung bộ nhớ: cả 2 đơn vị sẽ cùng dung chung, chia sẻ một khối bộ nhớ. Một ví dụ đơn giản là cả 2 đơn vị dùng chung một biến toàn cục.  Giao diện truyền bản tin: một đơn vị tạo và gửi một bản tin đến đơn vị khác. Một ví dụ đơn giản về truyền bản tin là trong các ứng dụng Web, việc liên lạc giữa máy chủ và máy khách được truyền qua lại thông qua các bản tin HTTP/HTTPS. Kiểm thử mức tích hợp sẽ giúp tìm ra các thiếu sót, lỗi xuất hiện khi tích hợp nếu có. Mặc dù ở mức kiểm thử đơn vị, một đơn vị cũng đã được kiểm tra giao tiếp với các đơn vị khác, cụ thể là các Stub và Driver giả lập, tuy nhiên dù có kiểm tra kỹ thì khi tích hợp với các đơn vị thực tế thì vẫn có thể xảy ra lỗi. Một số lỗi hay thiếu sót có thể xảy ra ở mức kiểm thử tích hợp [2]:  Lỗi không đủ chức năng: lỗi này xuất hiện khi đơn vị cung cấp chức năng không như đơn vị sử dụng mong đợi.  Thay đổi tính năng: một đơn vị được sửa đổi nhưng các đơn vị sử dụng nó không được điều chỉnh theo nên chức năng của chương trình bị ảnh hưởng.  Sử dụng giao diện không đúng: đơn vị sử dụng không đúng giao diện của đơn vị được gọi, có thể là do truyền sai kiểu dữ liệu.  Hiểu giao diện không đầy đủ: xảy ra khi đơn vị gọi hiểu nhầm hoặc không đầy đủ giao diện của đơn vị được gọi. Có thể ví dụ như trong lập trình hướng đối tượng, bằng việc nạp chồng phương thức, có thể có nhiều phương thức trùng tên nhưng khác nhau tham số đầu vào, việc truyền nhầm tham số có thể dẫn tới việc gọi sai phương thức dẫn tới sai kết quả trả về.  Không xử lý lỗi trả về: một đơn vị được gọi có thể trả về một mã lỗi nhưng đơn vị gọi lại không kiểm tra lỗi mà coi đó là kết quả hoặc không biết sửa. 15  Lỗi xung đột tài nguyên: các đơn vị dùng chung bộ nhớ có thể bị xung đột khi sử dụng. Ví dụ: một đơn vị vừa ghi dữ liệu vào một biến toàn cục thì đơn vị khác lại ghi đè dữ liệu vào biến đó.  Các vấn đề về phi chức năng: ví dụ với các hệ thống thời gian thực, việc xử lý chậm có thể gây mất đồng bộ giữa các đơn vị. Một số chiến lược được áp dụng trong kiểm thử mức tích hợp:  Tích hợp từng bước (incremental).  Tích hợp từ trên xuống (top - down).  Tích hợp từ dưới lên (bottom - up).  Tích hợp kẹp (sandwich).  Tích hợp tất cả cùng một thời điểm (big bang). Kiểm thử mức hệ thống Kiểm thử mức hệ thống có nhiệm vụ kiểm tra xem hệ thống hoặc chương trình sau khi đã tích hợp đầy đủ các đơn vị có hoạt động đúng với tài liệu đặc tả yêu cầu hay không. Do hầu hết các lỗi, thiếu sót đã được kiểm tra và sửa chữa ở mức kiểm thử đơn vị và kiểm thử tích hợp nên ở mức kiểm thử hệ thống tuy vẫn kiểm tra lỗi nhưng tập trung nhiều vào đảm bảo chất lượng của chương trình hơn. Các loại kiểm thử được dùng trong mức kiểm thử hệ thống [6, tr.193-194]:  Kiểm thử cơ bản (basic test): kiểm tra xem chương trình có thể cài đặt, gỡ bỏ được hay không, có cấu hình được không, ...  Kiểm thử chức năng (Functionality test): kiểm tra tổng thể các chức năng mà chương trình cung cấp .  Kiểm thử khả năng chịu lỗi (Robustness test): chương trình có thể hoạt động nếu xảy ra lỗi hay không.  Kiểm thử tương thích (Interoperability test): chương trình có thể tương thích với các phần mềm khác trong cùng môi trường hoạt động hay không.  Kiểm thử hiệu năng (performance test): kiểm tra xem hiệu năng của chương trình có đảm bảo không. Ví dụ: thời gian xử lý yêu cầu.  Kiểm thử khả năng mở rộng (Scalability test): kiểm tra giới hạn mà chương trình có thể mở rộng như chức năng, tài nguyên, lượng truy cập,..  Kiểm thử khả năng chịu tải (Stress test): kiểm tra giới hạn tối đa mà chương trình có thể xử lý khi có áp lực cao. Ví dụ: nhiều người truy cập cùng lúc,..  Kiểm thử khả năng ổn định quá tải (Stability test): kiểm tra xem chương trình có thể duy trì hoạt động trong một thời gian quá tải kéo dài hay không.  Kiểm thử độ tin cậy (Reliability test): kiểm tra xem chương trình có thể hoạt động trong một thời gian dài mà không có lỗi xảy ra.  Kiểm thử tài liệu hướng dẫn sử dụng (Documentation test): kiểm tra xem tài liệu hướng dẫn sử dụng cho người dùng cuối có chính xác và dễ dùng không. 16  Kiểm thử tính pháp lý (Regulatory test): kiểm tra tính pháp lý của chương trình có phù hợp với quy định của chính phủ nước sở tại hay không.  Kiểm thử bảo mật (Security test): kiểm tra xem chương trình có đảm bảo khả năng bảo mật, an toàn thông tin trước sự xâm phạm có chủ ý từ bên ngoài hay bên trong không.  Kiểm thử khả năng phục hồi (Recovery test): kiểm tra xem chương trình có thể khôi phục hoạt động ổn định, khôi phục dữ liệu nếu bị tấn công hoặc mất dữ liệu hay không. Kiểm thử mức chấp nhận Ở mức kiểm thử mức chấp nhận, người thực hiện việc kiểm tra chương trình chính là những người sẽ sử dụng trực tiếp chương trình phần mềm sau này hay còn gọi là người dùng cuối. Người dùng cuối là những người hiểu hơn ai hết cái họ muốn ở sản phẩm như phần mềm có đáp ứng đầy đủ những chức năng mà họ cần hoặc có đúng với quy trình công việc mà họ vẫn làm hay không? giao diện chương trình có dễ sử dụng hay không? các thao tác sử dụng có quá phức tạp hay không? đây là những vấn đề mà các kiểm thử viên hay người phát triển không thể kiểm tra được chính xác. Đây cũng là mức quyết định xem sản phẩm đã thực sự hoàn thiện để chuyển tới tay người dùng hay chưa. Các thiếu sót, lỗi sẽ được ghi lại trong quá trình kiểm tra và chuyển tới đội ngũ phát triển để sửa chữa. Kiểm thử mức chấp nhận giúp đảm bảo chương trình phần mềm có thể làm hài lòng người sử dụng đem lại sự thống nhất về kỹ thuật giữa đội ngũ phát triển và khách hàng. Tuy nhiên kiểm thử mức chấp nhận cũng có một số nhược điểm như tốn kém chi phí sửa chữa nếu phát sinh lỗi, thiếu sót, thay đổi. Ngoài ra, người dùng thường sử dụng chương trình một cách cẩn thận, không cố tình tạo ra các vi phạm (nhập sai kiểu dữ liệu, dùng sai quy cách) khiến lỗi chưa thể bị phát hiện trong quá trình kiểm tra. Kiểm thử hồi quy Trong quá trình phát triển phần mềm, nếu có một sự thay đổi xảy ra như thay đổi yêu cầu chức năng, quy trình xử lý thì đòi hỏi cần phải thực hiện việc kiểm tra lại để đảm bảo rằng chương trình phần mềm vẫn hoạt động tốt, không phát sinh ra lỗi, kiểm thử hồi quy sẽ thực hiện việc này. Kiểm thử hồi quy không phải là một mức kiểm thử giống như các mức đã nêu ở trên, nó có thể thực hiện lại các mức kiểm thử và sử dụng lại các ca kiểm thử đã được xây dựng. Hình 1.2 minh họa việc thực hiện kiểm thử ở các mức lần lượt từ kiểm thử mức đơn vị đến kiểm thử mức chấp nhận và áp dụng kiểm thử hồi quy để thực hiện lại việc kiểm thử các mức kiểm thử đơn vị, tích hợp và hệ thống. 17 Kiểm thử hồi quy Kiểm thử mức đơn vị Kiểm thử mức tích hợp Kiểm thử mức hệ thống Kiểm thử mức chấp nhận Hình 1.2. Kiểm thử hồi quy được thực hiện tại các mức kiểm thử khác nhau. Ưu điểm của kiểm thử hồi quy là đảm bảo các chức năng vẫn hoạt động tốt sau khi có sự thay đổi, chỉnh sửa, ngoài ra nó cũng giúp xác định được các lỗi phát sinh sau khi chương trình được thay đổi. Tuy nhiên nhược điểm của kiểm thử hồi quy là chi phí và thời gian để thực hiện khá tốn kém. Ca kiểm thử Ca kiểm thử là một tập các giá trị đầu vào và đầu ra mong đợi đối với mỗi hành vi cần kiểm thử của phần mềm. Để thực hiện kiểm thử động thì cần phải thiết kế các ca kiểm thử hiệu quả có khả năng phát hiện nhiều lỗi nhất với thời gian, chi phí và công sức tối thiểu. Có hai cách tiếp cận để thiết kế các ca kiểm thử, đó là kiểm thử hộp đen và kiểm thử hộp trắng. Kiểm thử hộp đen Với cách tiếp cận hộp đen, có thể xem chương trình như một chiếc hộp màu đen khiến người sử dụng không thể nhìn được mã nguồn, cấu trúc, thuật toán bên trong đó cũng như cách thức nó hoạt động như thế nào. Người thực hiện việc kiểm thử chỉ có thể thao tác với các chức năng mà chương trình cung cấp, đưa dữ liệu vào và nhận được dữ liệu ra sau khi chương trình xử lý, tính toán. Kiểm thử hộp đen đôi khi còn được gọi là kiểm thử chức năng hay kiểm thử về cách hoạt động. Kiểm thử hộp đen cũng chia làm kiểm thử hộp đen tĩnh và hộp đen động. Kiểm thử hộp đen tĩnh chính là kiểm tra tài liệu đặc tả yêu cầu để xác định các chức năng mà chương trình cung cấp cũng như yêu cầu về đầu vào, đầu ra. Kiểm thử hộp đen động chính là kiểm thử chức năng của chương trình đang chạy để kiểm tra xem có lỗi, thiếu sót chức năng và có đúng với đặc tả hay không. Phương pháp kiểm thử hộp đen có ưu điểm là không yêu cầu người thực việc kiểm thử phải biết lập trình hay tham gia vào quá trình viết mã nguồn cho chương trình, thậm chí người dùng cuối cũng có thể tham gia kiểm thử. Phương pháp cũng không phụ thuộc vào cài đặt thuật toán, nếu có thay đổi trong mã nguồn vẫn có thể sử dụng lại ca kiểm thử cũ. Phương pháp này cũng giúp loại bỏ những nhầm lẫn trong việc thống nhất kỹ thuật, chức năng mà chương trình cung cấp giữa người dùng cuối và đội ngũ thực hiện do đưa ra chương trình trực quan và rất hiệu quả khi kiểm thử những chương trình lớn. Tuy nhiên nhược điểm của phương pháp kiểm thử hộp đen là 18 việc kiểm thử đầy đủ các trường hợp dữ liệu vào có thể có là không khả thi. Phương cũng chỉ phát hiện ra các lỗi có thể quan sát được và nếu có lỗi thì không chỉ ra được nguyên nhân, vị trí gây ra lỗi. Ngoài ra nếu không có tài liệu đặc tả chính xác thì rất khó để thiết kế ca kiểm thử chính xác. Kiểm thử hộp trắng Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào các cấu trúc, thuật toán bên trong của chương trình để xác định chương trình có thực hiện đúng không. Để thực hiện kiểm thử hộp trắng đòi hỏi người thực hiện phải có kiến thức về lập trình và kiến trúc phần mềm đang được kiểm thử để có thể truy cập vào mã nguồn, cấu trúc thuật toán. Một số tên gọi khác của kiểm thử hộp trắng là kiểm thử hộp thủy tinh, hộp trong suốt hay kiểm thử cấu trúc, phương pháp này thường được dùng ở mức kiểm thử đơn vị. Kiểm thử hộp trắng cũng chia ra làm kiểm thử hộp trắng tĩnh và hộp trắng động. Kiểm thử hộp trắng tĩnh chính là thực hiện các kỹ thuật rà soát còn kiểm thử hộp trắng động là sử dụng các kỹ thuật kiểm thử luồng điều khiển, kiểm thử luồng dữ liệu động và kiểm thử miền. Ưu điểm của phương pháp là đảm bảo tất cả câu lệnh trong chương trình đều được thực thi ít nhất một lần giúp tránh lỗi tiềm ẩn, tối ưu hóa mã nguồn. Ngoài ra do người thực hiện việc kiểm thử hiểu về mã nguồn, cấu trúc thuật toán, kiến trúc của chương trình nên có thể kiểm thử một cách kỹ lưỡng chương trình. Tuy nhiên phương pháp cũng có nhược điểm như đòi hỏi người thực hiện phải hiểu về mã nguồn, cấu trúc thuật toán, kiến trúc của chương trình. Áp dụng phương pháp khiến tốn kém chi phí, nhân lực và thời gian khi thực hiện do yêu cầu kỹ thuật khá phức tạp. Ngoài ra để kiểm thử tất cả các đường dẫn trong chương trình là việc không khả thi và nếu thay đổi cài đặt thuật toán trong mã nguồn thì phải thiết kế lại ca kiểm thử. Một nhược điểm nữa của phương pháp là khi thực hiện không đảm bảo các chức năng của chương trình hoạt động đúng với tài liệu đặc tả. Nên lựa chọn cách tiếp cận hộp đen hay hộp trắng để thiết kế ca kiểm thử? Mỗi cách tiếp cận đều có ưu và nhược điểm, khi thiết kế ca kiểm thử nên sử dụng kết hợp cả hai cách để đạt hiệu quả tốt nhất với mỗi ca kiểm thử. 1.1.3. Kiểm thử tự động Kiểm thử phần mềm là một công việc tốn nhiều thời gian và chi phí, thông thường thời gian dành cho việc kiểm thử chiếm hơn 50% tổng thời gian phát triển phần mềm. Ngoài ra, để thực hiện kiểm thử đòi hỏi kiểm thử viên phải kiên nhẫn và tỉ mỉ, chính những điều này dẫn tới sự cần thiết của kiểm thử tự động. Kiểm thử tự động sẽ thực hiện tự động các ca kiểm thử theo một kịch bản cho sẵn hoặc tự nó sinh ra. Kiểm thử tự động giúp rút ngắn thời gian, chi phí, nhân lực cho dự án phần mềm. Một ưu điểm nữa là kiểm thử tự động cung cấp cho chúng ta khả năng để thực hiện kiểm thử hồi quy với các chức năng mà mã nguồn liên tục thay đổi. Tuy nhiên đối với một số ca