Tài liệu Nghiên cứu một số giải pháp kiểm thử giao diện tự động sử dụng ranorex

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ THU HÀ NGHIÊN CỨU MỘT SỐ GIẢI PHÁP KIỂM THỬ GIAO DIỆN TỰ ĐỘNG SỬ DỤNG RANOREX LUẬN VĂN THẠC SĨ Hà Nội - 11/2018 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ THU HÀ NGHIÊN CỨU MỘT SỐ GIẢI PHÁP KIỂM THỬ GIAO DIỆN TỰ ĐỘNG SỬ DỤNG RANOREX Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã Số: 8480103.01 LUẬN VĂN THẠC SĨ NGƢỜI HƢỚNG DẪN KHOA HỌC: PGS. TS. PHẠM NGỌC HÙNG Hà Nội - 11/2018 i MỤC LỤC LỜI CẢM ƠN ................................................................................................................. ii LỜI CAM ĐOAN .......................................................................................................... iii BẢNG CÁC TỪ VIẾT TẮT ..........................................................................................iv DANH MỤC HÌNH VẼ .................................................................................................. v DANH MỤC BẢNG BIỂU ............................................................................................vi Chƣơng 1: Đặt vấn đề ...................................................................................................... 1 1.1. Sự cần thiết của đề tài ............................................................................ 1 1.2. Nội dung của luận văn ........................................................................... 2 1.3. Cấu trúc của luận văn ............................................................................. 3 Chƣơng 2: Tổng quan về kiểm thử giao diện ngƣời dùng tự động ................................. 4 2.1. Kiểm thử phần mềm ............................................................................... 4 2.2. Kiểm thử tự động phần mềm ................................................................. 5 2.3. Kiểm thử giao diện ngƣời dùng ........................................................... 10 2 4 Một số kỹ thuật kiểm thử giao diện ngƣời d ng .................................. 11 Chƣơng 3: Kiểm thử giao diện ngƣời dùng sử dụng Ranorex ...................................... 24 3.1. Giới thiệu về Ranorex .......................................................................... 24 3 2 Tính năng nổi bật ................................................................................. 25 Chƣơng 4: Ứng dụng và thực nghiệm ........................................................................... 35 4.1. Giới thiệu về phần mềm Keepass ........................................................ 35 4.2 Thực nghiệm ......................................................................................... 36 Chƣơng 5 Kết luận........................................................................................................ 44 TÀI LIỆU THAM KHẢO ............................................................................................. 46 ii LỜI CẢM ƠN Lời đầu tiên, tôi xin bày tỏ sự cảm ơn chân thành đối với Thầy giáo PGS. TS. Phạm Ngọc Hùng - Giáo viên hƣớng dẫn trực tiếp của tôi. Thầy H ng đã cho tôi những gợi ý và chỉ dẫn quý báu trong quá trình nghiên cứu và hoàn thiện luận văn thạc sĩ Tôi cũng xin gửi lời cảm ơn tới các thầy cô trong khoa Công nghệ thông tin, trƣờng Đại học Công nghệ, Đại học Quốc gia Hà Nội đã hƣớng dẫn, chỉ bảo và tạo điều kiện cho chúng tôi học tập và nghiên cứu tại trƣờng trong suốt thời gian qua. Tôi cũng xin đƣợc cảm ơn gia đình, những ngƣời thân, các đồng nghiệp và bạn bè tôi đã quan tâm, động viên, giới thiệu các tài liệu hữu ích trong thời gian học tập và nghiên cứu luận văn tốt nghiệp. Mặc d đã cố gắng hoàn thành luận văn nhƣng chắc chắn sẽ không tránh khỏi những sai sót, tôi kính mong nhận đƣợc sự thông cảm và chỉ bảo của các thầy cô và các bạn. Tôi xin chân thành cảm ơn! iii LỜI CAM ĐOAN Tôi là Nguyễn Thị Thu Hà, học viên lớp Kỹ Thuật Phần Mềm K23 xin cam đoan báo cáo luận văn này đƣợc viết bởi tôi dƣới sự hƣớng dẫn của thầy giáo, PGS. TS. Phạm Ngọc Hùng. Tất cả các kết quả đạt đƣợc trong luận văn này là quá trình tìm hiểu, nghiên cứu của riêng tôi. Trong toàn bộ nội dung của luận văn, những điều đƣợc trình bày là kết quả của cá nhân tôi hoặc là đƣợc tổng hợp từ nhiều nguồn tài liệu khá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 ….. tháng …… năm 2018 Ngƣời cam đoan Nguyễn Thị Thu Hà iv BẢNG CÁC TỪ VIẾT TẮT STT Từ viết tắt và thuật ngữ 1. API 2. GUI 3. 4. IDE QTP Từ/Cụm từ đầy đủ Application programming Giao diện lập trình ứng interface dụng Graphical user interface Integrated Giải thích Development Environment Giao diện đồ họa ngƣời d ng Là phần mềm cung cấp môi trƣờng tích hợp cho các lập trình viên Quick Test Pro Công cụ kiểm thử Hệ thống quản lý, kiểm 5. SVN Subversion tra các phiên bản mã nguồn 6. TFS 7. UI 8. XML Team Foundation Server User Interface Extensible Language Sản phẩm quản lý mã nguồn thiết kế giao diện ngƣời dùng Marup Là ngôn ngữ đánh dấu mở rộng v DANH MỤC HÌNH VẼ Hình 2.1. Mô hình chữ V ...................................................................................... 5 Hình 2.2. Qui trình kiểm thử phần mềm ............................................................... 8 Hình 2.3. Qui trình kiểm thử tự động phần mềm .................................................. 9 Hình 2.4. Kiểm thử giao diện thủ công ............................................................... 12 Hình 3 1 Tính năng nhận dạng đối tƣợng mạnh mẽ .......................................... 26 Hình 3.2. Hình ảnh chỉnh sửa các hành động ..................................................... 27 Hình 3.3. Hình mô tả các hành động đã đƣợc ghi............................................... 28 Hình 3.4. Chỉnh sửa mã trong Ranorex............................................................... 29 Hình 3.5. Tích hợp Visual Studio ....................................................................... 30 Hình 3.6. Kết quả phân tích lỗi ........................................................................... 33 Hình 3.7. Kích hoạt chế độ bảo trì ...................................................................... 34 Hình 4.1. Mở và chạy chƣơng trình thử nghiệm ................................................. 36 Hình 4.2. Cửa sổ mật khẩu hiển thị ..................................................................... 37 Hình 4.3. Giao diện chính của chƣơng trình ....................................................... 37 Hình 4.4. Giá trị ban đầu khi thực hiện thử nghiệm ........................................... 38 Hình 4 5 Các hành động đƣợc ghi khi thực hiện thử nghiệm ............................ 39 Hình 4.6. Kết quả chạy thử nghiệm từ thử nghiệm............................................. 39 Hình 4 7 Đoạn mã chứa lỗi ................................................................................ 40 Hình 4.8. Giao diện hiển thị sự sắp xếp các phần tử........................................... 41 Hình 4.9. Hiển thị các hành động khi thực thi chƣơng trình .............................. 41 Hình 4.10. Kết quả khi thực thi ........................................................................... 42 Hình 4 11 Đoạn mã chƣơng trình gây ra lỗi ...................................................... 42 vi DANH MỤC BẢNG BIỂU Bảng 2.1. So sánh mức độ thân thiện khi sử dụng công cụ QTP, Selenium và Ranorex .... 18 Bảng 2 2 So sánh tính năng sử dụng của Selenium, QTP và Ranorex ......................... 19 Bảng 2.3. Một số tính năng chuyên sâu của Selenium, QTP và Ranorex ..................... 21 1 Chƣơng 1: Đặt vấn đề 1.1. Sự cần thiết của đề tài Trong vài thập kỉ qua, ngành công nghiệp phần mềm đã có những bƣớc phát triển lớn cả về quy mô và chất lƣợng, đóng vai trò quan trọng vào sự phát triển của hầu hết mọi mặt của các nƣớc. Nếu nhƣ trƣớc đây, phần mềm máy tính chỉ đƣợc sử dụng để tính toán khoa học kỹ thuật và xử lý dữ liệu, thì ngày nay, nó đã đƣợc ứng dụng vào mọi mặt của đời sống hàng ngày của con ngƣời. Các ứng dụng của phần mềm trong cuộc sống rất đa dạng từ các ứng dụng nhỏ để điều khiển các thiệt bị gia dụng nhƣ điện thoại, máy giặt, ti vi, tủ lạnh đến các ứng dụng lớn hơn cho rất nhiều ngƣời dùng cùng sử dụng nhƣ hệ thống quản lý doanh nghiệp, các hệ thống hƣớng dẫn giao thông, hệ thống quản lý việc khám chữa bệnh, v.v. Điều này đòi hỏi chất lƣợng phần mềm ngày càng phải đƣợc nâng cao để đáp ứng nhu cầu của ngƣời sử dụng. Tuy nhiên, quá trình tạo ra một sản phẩm phần mềm có thể sử dụng tốt không thể tránh khỏi những lỗi phần mềm. Chúng ta dù cố gắng đến mức nào thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không thể lúc nào cũng viết đƣợc những đoạn mã không có lỗi. Tính trung bình, ngay cả một lập trình viên loại tốt thì cũng có từ một đến ba lỗi trên một trăm dòng lệnh Ngƣời ta ƣớc lƣợng rằng việc kiểm tra để tìm ra các lỗi này chiếm phân nửa khối lƣợng công việc phải làm để có một phần mềm hoạt động đƣợc [3]. Do vậy, kiểm thử phần mềm là khâu rất quan trọng của sản phẩm trƣớc khi đƣa vào sử dụng, góp phần quyết định sự thành công của dự án phần mềm. Tuy nhiên, kiểm thử là một công việc tiêu tốn rất nhiều thời gian, tiền bạc, công sức. Chi phí kiểm thử phần mềm thƣờng chiếm tới bốn mƣơi phần trăm tổng chi phí cho một dự án phát triển phần mềm Đối với các phần mềm lớn, chi phí này còn tăng lên gấp bội mỗi khi có sự thay đổi, nâng cấp các chức năng của phần mềm, điều này là không thể tránh khỏi đối với mọi phần mềm. Một sản phẩm tuy đƣợc thiết kế tốt nhƣng cũng không thể tránh khỏi các sai sót. Kiểm thử hiệu quả sẽ phát hiện ra đƣợc các sai sót này, tránh các lỗi 2 trƣớc khi phát hành sản phẩm. Kiểm thử đứng dƣới vai trò của ngƣời sử dụng, sẽ giúp cho sản phẩm có sự thích ứng phù hợp hơn với thị hiếu và nhu cầu ngày càng cao của ngƣời dùng. Trên thị trƣờng hiện nay có rất nhiều công cụ kiểm thử tự động đƣợc sử dụng nhƣ Ranorex, QTP, Selenium, v.v. Đề tài này tìm hiểu về các công cụ hỗ trợ kiểm thử tƣơng tác giao diện cho các ứng dụng và đi sâu nghiên cứu công cụ Ranorex vì nó có rất nhiều ƣu điểm nhƣ hỗ trợ đa nền tảng, hỗ trợ nhiều ứng dụng trên Web, Desktop, Mobile. Ranorex có khả năng xác định chính xác các đối tƣợng có trong UI hiện nay Hơn nữa, công cụ này hỗ trợ cơ chế “ghi và chạy lại” kịch bản tƣơng tác UI rất mạnh mẽ. Công cụ này cũng cho phép kiểm thử viên tùy chỉnh kịch bản tƣơng tác UI bằng cách thêm trực tiếp các đoạn mã nhằm tăng tính linh hoạt trong kiểm thử tự động. Giao diện đồ họa ngƣời dùng (Graphical user interface – GUI) là những gì ngƣời dùng nhìn thấy. Nếu bạn truy cập vào một trang Web, những gì bạn thấy trên trang chủ đƣợc gọi là giao diện đồ họa ngƣời dùng của trang Web Ngƣời dùng sẽ không nhìn thấy mã nguồn, giao diện ngƣời dùng chỉ tập trung vào cấu trúc thiết kế, hình ảnh hiển thị ra ngoài có đúng nhƣ lập trình mong đợi hay không [11]. Nếu chúng ta phải làm thử nghiệm GUI, việc đầu tiên cần xác định xem những hình ảnh của trang Web sẽ hiện lên giống nhau trên các trình duyệt khác nhau. Ngoài ra, kiểm thử GUI còn xác nhận các liên kết hoặc các nút hoạt động tốt hay không, nếu ngƣời d ng thay đổi kích thƣớc màn hình thì hình ảnh và nội dung không đƣợc co lại hoặc cắt đi hay chồng chéo lên nhau [11]. Để đạt đƣợc mục tiêu này, luận văn cũng sẽ nghiên cứu về kiểm thử giao diện tự động và các kiến thức liên quan. Cuối cùng luận văn sẽ áp dụng trực tiếp kiểm thử tự động giao diện sử dụng công cụ Ranorex vào để kiểm thử phần mềm bảo mật password Keepass nhằm phát hiện một số lỗi tƣơng tác giao diện cho ứng dụng này. 1.2. Nội dung của luận văn Với mục đích nhƣ trên, luận văn có những nội dung nhƣ sau: Luận văn tổng hợp lý thuyết về kiểm thử phần mềm, kiểm thử tự động, kiểm thử giao diện tự động - một giải pháp góp phần nâng cao năng suất, chất lƣợng hoạt động 3 kiểm thử phần mềm. Luận văn giới thiệu về một số công cụ hỗ trợ kiểm thử giao diện tự động trong đó sẽ đi tìm hiểu sâu về công cụ Ranorex. Luận văn sẽ mô tả từng bƣớc quá trình áp dụng kiểm thử giao diện tự động với công cụ Ranorex từ đó giúp phần mềm giảm bớt chi phí kiểm thử cũng nhƣ tiết kiệm đƣợc thời gian và nhân lực kiểm thử của các kiểm thử viên. Việc phát hiện các lỗi tƣơng tác giao diện sẽ góp phần nâng cao chất lƣợng sản phẩm nói chung và tăng khả năng chấp nhận và sự hài lòng của ngƣời d ng đối với sản phẩm. 1.3. Cấu trúc của luận văn 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 tổng quan về kiểm thử, kiểm thử giao diện ngƣời dùng và các khái niệm cơ bản đƣợc sử dụng trong nghiên cứu của luận văn Chƣơng này chủ yếu giới thiệu về kiểm thử, kiểm thử tự động và kiểm thử giao diện tự động, một số phƣơng pháp hỗ trợ kiểm thử giao diện ngƣời dùng. Tiếp đến, kiểm thử giao diện ngƣời dùng sử dụng Ranorex sẽ đƣợc mô tả trong Chƣơng 3. Trong chƣơng này sẽ giới thiệu chi tiết về công cụ kiểm thử giao diện tự động Ranorex Cơ chế hoạt động sinh kịch bản, chạy kịch bản và xuất ra kết quả của công cụ, giới thiệu cả những tính năng ứng dụng nổi bật của công cụ. Từ đó, luận văn sẽ tổng kết những tính năng nổi bật khi sử dụng công cụ Ranoex trong những dự án lớn. Chƣơng 4 là việc ứng dụng và thực nghiệm. Công cụ kiểm thử giao diện tự động sẽ đƣợc đƣa vào ứng dụng thực tế trong chƣơng trình phần mềm bảo mật password Keepass nhằm minh chứng cho khả năng vận dụng các kiến thức tìm hiểu đƣợc của học viên. Cuối cùng, tổng kết những kết quả đạt đƣợc của luận văn và hƣớng nghiên cứu tiếp theo sẽ đƣợc trình bày trong Chƣơng 5 4 Chƣơng 2: Tổng quan về kiểm thử giao diện ngƣời dùng tự động Hiện nay, phần mềm đƣợc sử dụng rất rộng rãi trong rất nhiều lĩnh vực nhƣ khoa học, kinh tế và xã hội. Vì vậy, việc đảm bảo rằng phần mềm đáp ứng đƣợc các mong muốn của ngƣời sử dụng là rất quan trọng. Kiểm thử phần mềm lúc này trở thành một trong những hoạt động cơ bản và cần thiết nhằm đảm bảo chất lƣợng phần mềm. 2.1. Kiểm thử phần mềm Kiểm thử phần mềm có nhiều cách định nghĩa khác nhau, tuy nhiên chúng cùng bao trùm hai nội dung cơ bản là phát hiện lỗi và đánh giá chất lƣợng của phần mềm Định nghĩa của Glenford J. Myers: “Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm ra lỗi” [4] đƣợc xem là đơn giản và đƣợc sử dụng nhiều nhất. Mục đích của kiểm thử là phát hiện lỗi vì thực tế phần mềm nào cũng có lỗi. Theo Myers, kiểm thử mà không phát hiện đƣợc lỗi đƣợc coi là không thành công [5]. Lỗi phần mềm cần tìm ra sớm vì nếu để sản phẩm đến tay ngƣời dùng thì càng tốn nhiều thời gian và tiền bạc để sửa lỗi Do đó, kiểm thử phần mềm đƣợc thực hiện ngay trong quá trình phát triển phần mềm trƣớc khi sản phẩm đƣợc đến tay ngƣời dùng. Hiện nay, các công cụ hỗ trợ lập trình đã giúp cải thiện năng xuất làm việc của các lập trình viên lên rất nhiều chính điều này đã dẫn đến tăng áp lực lên các kiểm thử viên, những ngƣời gần nhƣ là sẽ phải hoàn thiện khâu cuối cùng và rất quan trọng trƣớc khi đƣa sản phẩm vào ứng dụng Điều này đòi hỏi kiểm thử viên phải kiểm thử nhiều hơn trong thời gian ít hơn Vì vậy, đòi hỏi kiểm thử viên phải tìm ra cách để vừa đảm bảo chất lƣợng phần mềm vừa đảm bảo tiến độ kiểm thử để không ảnh hƣởng tới thời gian bàn giao sản phẩm. Kiểm thử tự động đƣợc xem là giải pháp để giải quyết vấn đề trên vừa nâng cao hiệu suất vừa giảm thời gian kiểm thử. 5 2.2. Kiểm thử tự động phần mềm Phƣơng pháp kiểm thử thủ công vừa tốn nhiều thời gian, công sức để thực hiện, vừa không phải lúc nào cũng có hiệu quả trong việc tìm kiếm các lớp lỗi. Vì vậy, kiểm thử tự động cung cấp một khả năng để thực hiện các loại kiểm thử một cách hiệu quả. Kiểm thử tự động là quá trình thực hiện một cách tự động các bƣớc trong một kịch bản kiểm thử. Kiểm thử tự động sử dụng phần mềm kiểm thử (khác biệt với kiểm thử bằng tay) để kiểm soát việc thực hiện các bài kiểm tra và so sánh kết quả thực tế với kết quả dự đoán Mục đích của kiểm thử tự động là tăng độ tin cậy, tăng tính hiệu quả, giảm thời gian, công sức, kinh phí, giảm sự nhàm chán cho kiểm thử viên trong quá trình kiểm thử. Hình 2.1. Mô hình chữ V [4] Hình 2.1 mô tả mô hình chữ V (V - model) đã khá quen thuộc đối với những ngƣời làm công việc kiểm thử nói riêng và phát triển phần mềm nói 6 chung. Mô hình này thể hiện một cách rõ nhất các hoạt động của kiểm thử từ giai đoạn kiểm thử mức đơn vị, kiểm thử tích hợp, kiểm thử hệ thống cho đến kiểm thử chấp nhận Tƣơng ứng với mỗi công đoạn trong việc phát triển phần mềm là một hoạt động kiểm thử. Phía bên tay trái là các hoạt động phát triển, phía bên tay phải là các hoạt động kiểm thử. Với mỗi một mức kiểm thử chúng ta đều có thể áp dụng kiểm thử tự động. Trong giai đoạn phân tích yêu cầu các yêu cầu đƣợc thu thập, phân tích và nghiên cứu. Ở giai đoạn này điều quan trong là hệ thống có chức năng gì và thỏa mãn những ràng buộc gì (yêu cầu phi chức năng) Trong giai đoạn phân tích yêu cầu hệ thống, các yêu cầu của hệ thống phần mềm đƣợc xác định. Khác với mô hình thác nƣớc, trong giai đoạn này, chúng ta phải sinh ra các ca kiểm thử. Nếu sản phẩm sau này thỏa mãn các ca kiểm thử này thì nó sẽ đáp ứng các yêu cầu đặt ra Tƣơng tự, ở giai đoạn thiết kế kiến trúc, dựa trên thiết kế mức cao kiến trúc phần mềm đƣợc tạo ra, các môđun, mối quan hệ, sơ đồ kiến trúc, bảng cơ sở dữ liệu, chi tiết về công nghệ đều đƣợc hoàn tất trong giai đoạn này Giai đoạn thiết kế mô-đun các thành phần phần mềm đều đƣợc thiết kế riêng. Các lớp, giao diện, kiểu dữ liệu v.v. đều đƣợc hoàn tất trong giai đoạn này Giai đoạn mã hóa, ở giai đoạn này các đoạn mã đƣợc kiểm tra xem xét. Dựa trên mô hình chữ V, chúng ta có thể chia kiểm thử tự động thành bốn cấp độ/mức (testing levels) nhƣ sau: - Kiểm thử mức đơn vị (Unit testing) - Kiểm thử tích hợp (Integrtion test) - Kiểm thử hệ thống (System test) - Kiểm thử chấp nhận (Acceptance test) Kiểm thử tự động mức đơn vị (Unit test): Là kiểm thử mức đầu tiên đƣợc thực hiện khi phát triển các sản phẩm phần mềm. Công việc kiểm thử mức đơn vị rất nhanh và có tính tin cậy cao vì chỉ thực hiện ở mức đơn vị Khi đó kiểm thử viên thƣờng lập trình luôn, khi tạo ra một hàm hoặc một thủ tục, ngay sau đó lập trình viên thƣờng tạo luôn các ca kiểm thử để thực hiện kiểm thử ngay lập tức mà không cần phải chờ đến khi hoàn thiện sản phẩm. Kiểm thử tự động mức 7 đơn vị chiếm khối lƣợng các bộ kiểm thử nhiều nhất và các công cụ kiểm thử cũng rất đa dạng. Các công cụ kiểm thử tự động áp dụng cho mức kiểm thử này nhƣ Junit, Selenium v.v. Kiểm thử mức tích hợp (Integration test): Kiểm thử tích hợp thực hiện những phần mà kiểm thử mức đơn vị chƣa bao phủ và chƣa đƣợc kiểm thử. Nhằm phát hiện ra lỗi giao tiếp xảy ra giữa các thành phần (nếu có). Các thành phần đó có thể là các mô-đun, các ứng dụng riêng lẻ hay các ứng dụng khách hàng/máy chủ (Client/Server) trên một mạng. Mục tiêu của kiểm thử tích hợp là phát hiện ra lỗi giao tiếp xảy ra giữa các đơn vị (Unit) và tích hợp các đơn vị (Unit) đơn lẻ thành các hệ thống để chuẩn bị kiểm tra mức hệ thống. Kiểm thử tích hợp mất nhiều thời gian, chậm và khó để tự động, cần phải lập trình nhiều hơn kiểm thử mức đơn vị. Kiểm thử mức tích hợp chƣa có nhiều công cụ hỗ trợ kiểm thử. Kiểm thử mức hệ thống (System test): là một mức của tiến trình kiểm thử phần mềm. Mục tiêu của kiểm tra mức hệ thống là đánh giá phần mềm có tuân thủ theo các yêu cầu đã đƣa ra không Kiểm thử hệ thống khác với kiểm thử tích hợp là chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp chỉ chú trọng việc giao tiếp giữa các đơn thể hoặc đối tƣợng khi chúng làm việc c ng nhau Thông thƣờng chúng ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để đảm bảo mọi đơn vị (Unit) và sự tƣơng tác giữa chúng hoạt động chính xác trƣớc khi kiểm thử hệ thống. Kiểm thử chấp nhận (Acceptance test): là một cấp độ trong tiến trình kiểm thử phần mềm nhằm kiểm thử hệ thống và khả năng chấp nhận đƣợc của hệ thống. Mục tiêu của kiểm thử này là để đánh giá sự tuân thủ của hệ thống với các yêu cầu nghiệp vụ và thẩm định xem đã có thể bàn giao đƣợc chƣa Thông thƣơng khâu này sẽ đƣợc khách hàng thực hiện hoặc ủy quyền cho một nhóm thứ ba thực hiện. 8 - Qui trình kiểm thử: Hình 2.2. Qui trình kiểm thử phần mềm [4] Hình 2.2 mô tả qui trình kiểm thử phần mềm theo các bƣớc Bƣớc một: Phân tích yêu cầu, việc đầu tiên là cần tiếp nhận và phân tích các yêu cầu đƣợc đặt ra, khi hiểu đƣợc yêu cầu của sản phẩm thì mới có thể có một kế hoạch cụ thể cho các bƣớc tiếp theo Bƣớc hai: Lập kế hoạch kiểm thử, bƣớc này cần lập một kế hoạch kiểm thử rõ ràng, xác định và phân chia một cách hợp lý thời gian, nhân sự, các công cụ cần để sử dụng cho từng chức năng Bƣớc ba: Thiết kế kịch bản kiểm thử viết các trƣờng hợp kiểm thử, viết kịch bản kiểm thử (testcase) cho các trƣờng hợp sẽ kiểm thử (test) bao gồm ba trƣờng hợp: Kiểm thử thành công, kiểm thử không thành công và không xác định kết quả Bƣớc bốn: Thiết lập môi trƣờng kiểm thử, bƣớc này bạn cần phải chuẩn bị môi trƣờng, nền tảng cho công việc kiểm thử phần mềm của mình bao gồm: hệ điều hành, 9 trình duyệt, thiết bị Bƣớc năm: Thực hiện kiểm thử, tiến hành thực thi các kịch bản kiểm thử để thực hiện việc kiểm thử Quá trình này cũng có thể cập nhập thêm một số trƣờng hợp còn thiếu hoặc trƣờng hợp phát sinh thêm Bƣớc sáu: Đóng chu trình kiểm thử, kết thúc công việc kiểm thử chúng ta cần báo cáo hoặc ghi lại các kịch bản đồng thời thống kê lại số liệu cụ thể. - Qui trình kiểm thử tự động: Hình 2.3. Qui trình kiểm thử tự động phần mềm [3] Hình 2.3 mô tả qui trình kiểm thử tự động bao gồm bốn bƣớc Bƣớc một: Phân tích khả năng áp dụng kiểm thử tự động, chúng ta không thể tự động hoá mọi việc trong kiểm thử phần mềm đƣợc. Có những phần mềm mới hay công nghệ viết ra phần mềm mà những công cụ kiểm thử tự động hiện tại chƣa hỗ trợ hoặc chỉ hỗ trợ một phần. Ví dụ rõ ràng nhất là khi chúng ta kiểm thử một trang Web trên một trình duyệt mới, và lúc đó công cụ kiểm thử tự động chƣa có phiên bản mới hỗ trợ trên trình duyệt đó Bƣớc hai: Lựa chọn công cụ kiểm thử tự động thích hợp, sau khi xác định đƣợc sản phẩm hiện tại có thể làm kiểm thử tự động hay không, bƣớc kế tiếp chúng ta cần xác định nên sử dụng công cụ kiểm thử tự động nào. Công cụ nào hỗ trợ kiểm thử tự động cho công nghệ mà sản phẩm sử dụng? Ƣu nhƣợc điểm của từng công cụ? Ngôn ngữ kịch bản nào 10 mà công cụ kiểm thử sử dụng? Nhân sự hiện tại có quen thuộc với công cụ đó hay không? Bƣớc ba: Xây dựng môi trƣờng làm việc, môi trƣờng làm việc bao gồm các khái niệm, chu trình, thủ tục và môi trƣờng mà kịch bản kiểm thử tự động đƣợc thiết kế và viết ra. Bên cạnh đó, nó cũng nên bao gồm luôn cấu trúc thƣ mục, lƣu trữ các kịch bản kiểm thử cũng nhƣ các mối quan hệ logic giữa các thành phần Bƣớc bốn: Viết kịch bản kiểm thử, thực thi và phân tích kết quả, dựa trên các kịch bản kiểm thử đã đƣợc tạo ra bằng kiểm thử thủ công, dựa vào ngôn ngữ kịch bản mà công cụ kiểm thử tự động hỗ trợ, chúng ta viết các đoạn mã tƣơng tác với sản phẩm phần mềm trên các môi trƣờng và thực thi nó. Sau khi thực thi các đoạn mã, chúng ta cần phân tích các kết quả đạt đƣợc và ghi lại các vấn đề của sản phẩm, nếu có. 2.3. Kiểm thử giao diện ngƣời dùng Giao diện ngƣời d ng (User Interface - UI) là một phƣơng thức giao tiếp giữa con ngƣời với các thiết bi, máy móc và chƣơng trình máy tính Trong lĩnh vực phát triển phần mềm, UI đƣợc thiết kế nhằm mục đích giúp con ngƣời điều khiển, sử dụng, tƣơng tác với các chƣơng trình phần mềm để đạt đƣợc mục đích sử dụng của ngƣời d ng Trong lịch sử phát triển, UI đƣợc chia thành nhiều dạng Trong đó, hai dạng UI đƣợc sử dụng phổ biến cho tới ngày nay là giao diện dòng lệnh (Command-line interface) và giao diện đồ họa ngƣời d ng (Graphical user interface - GUI) [1]. Giao diện dòng lệnh là giao diện đƣợc thiết kế để ngƣời sử dụng có thể tƣơng tác bằng bàn phím thông qua các câu lệnh Giao diện này thƣờng đƣợc phát triển đi kèm với một chƣơng trình xử l các câu lệnh và chuyển đổi chúng sang các thao tác hệ thống tƣơng ứng Ƣu điểm của việc sử dụng giao diện dòng lệnh là tốc độ xử lý nhanh, linh hoạt và khả năng truy cập sâu hơn vào hệ thống Ngày nay, giao diện dòng lệnh ngƣời d ng đang dần trở nên k m phổ biến, GUI đƣợc ƣa chuộng hơn bởi tính dễ sử dụng, đặc biệt đối với những ngƣời d ng thông thƣờng không có kinh nghiệm 11 GUI là một dạng của UI cho ph p ngƣời d ng tƣơng tác với các thiết bị điện tử thông qua hình ảnh và chữ viết thay cho việc sử dụng các dòng lệnh đơn thuần GUI đƣợc giới thiệu để khắc phục các nhƣợc điểm của giao diện dòng lệnh. Một trong số các nhƣợc điểm của giao diện dòng lệnh là tiêu tốn nhiều chi phí về thời gian và công sức để học và nhớ các câu lệnh điều khiển. Các hành động ngƣời dùng thực hiện lên GUI thƣờng là các thao tác trực tiếp với các đối tƣợng đồ họa Ngoài máy tính, GUI đƣợc sử dụng trên hầu hết các thiết bị cầm tay nhƣ máy nghe nhạc, máy chơi điện tử cầm tay, điện thoại thông minh, các công cụ văn phòng, v v Hay ta có thể hiểu đơn giản rằng: Kiểm thử giao diện ngƣời dùng là một kỹ thuật kiểm thử đƣợc sử dụng để xác định sự hiện diện của các khiếm khuyết trên một sản phẩm hoặc phần mềm đƣợc kiểm tra bằng cách sử dụng giao diện ngƣời d ng đồ họa. Kiểm thử GUI là một kỹ thuật kiểm thử trong đó giao diện ngƣời dùng của ứng dụng đƣợc kiểm tra xem ứng dụng có hoạt động nhƣ mong đợi đối với hành vi giao diện ngƣời dùng hay không. Kiểm tra GUI bao gồm hành vi ứng dụng đối với chuyển động bàn phím, chuột và cách các đối tƣợng GUI khác nhau nhƣ thanh công cụ, nút, thanh thực đơn, hộp thoại, chỉnh sửa trƣờng, danh sách, hành vi cho ngƣời dùng nhập [1]. 2 4 Mộ phƣơng ph p iểm hử giao iện ngƣời iểm hử giao iện ngƣời ng ng hủ công: Dựa trên tri thức, hiểu biết về miền của kiểm thử viên Kiểm thử viên tập trung kiểm thử các chức năng quan trọng của hệ thống hay các kịch bản có thể gây ra lỗi Tuy nhiên, rất nhiều kịch bản quan trọng có thể bị bỏ sót khi kiểm thử thủ công Trong thực tế, thƣờng có một nhóm các chuyên gia tập trung giải quyết vấn đề bằng cách đánh giá qua kinh nghiệm, tìm giải pháp qua thử nghiệm và rút bớt khuyết điểm Một kỹ thuật khác đƣợc sử dụng là đi qua có nhận thức (Cognitive walkthrough) Kiểm thử viên lần lƣợt sử dụng các chức năng của chƣơng trình, các hành động và phản hồi đƣợc ghi lại để đối chiếu với mục tiêu k vọng Cuối c ng, các điểm cần cải tiến, sửa chữa đƣợc ghi lại Ngoài ra, việc kiểm thử tính dễ sử dụng của chƣơng 12 trình cũng đƣợc kiểm thử viên tiến hành thủ công Kiểm thử UI thủ công có thể phát hiện đƣợc một số lỗi mà kiểm thử tự động không thể phát hiện đƣợc Tuy nhiên, phƣơng pháp này yêu cầu nhiều chi phí về thời gian và nhân lực Đồng thời, độ phủ đạt đƣợc là không cao Đối với các hệ thống có UI phức tạp, kiểm thử thủ công là giải pháp không khả thi Hình 2.4. Kiểm thử giao diện thủ công Hình 2.4 mô tả cách thực thiện kiểm thử giao diện thủ công. Khi kiểm thử giao giện thủ công chúng ta phải thêm từng bƣớc thực hiện đều bằng tay Đầu vào của chƣơng trình từng thao tác đều phải ghi lại mỗi khi thực hiện, việc này sẽ là quá tải với kiểm thử viên khi vào dự án lớn và rất dể xảy ra sự nhầm lẫn khi kiểm thử. iểm hử giao iện ngƣời ng ựa n m h nh: Mô hình là một mô tả đồ họa về hành vi của hệ thống. Nó giúp chúng ta hiểu và dự đoán hành vi của hệ thống. Quá trình kiểm thử UI tự động dựa trên mô hình bao gồm ba giai đoạn chính nhƣ sau:  Mô hình hóa hệ thống từ các bản đặc tả và thiết kế của hệ thống: Hệ thống đƣợc mô hình hóa sử dụng công cụ mô hình hóa c ng với các bản đặc tả, phân tích thiết kế từ khách hàng Việc này giúp hiểu rõ hơn hệ thống cần kiểm thử và UI của hệ thống đó  Sinh kịch bản tƣơng tác UI từ mô hình của hệ thống: T y thuộc vào tiêu chí và thuật toán sinh kịch bản tƣơng tác UI mà số lƣợng kịch bản sinh ra là