Sản sinh các tập lệnh hỗ trợ kiểm thử tự động ứng dụng web bằng thư viện từ khóa

Tuy nhiên, thách thức khi xây dựng, sử dụng khung kiểm thử tự động là người kiểm thử viên ngoài yêu cầu phải có kiến thức về kiểm thử phần mềm còn phải có khả năng lập trình,

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

- -

NGUYỄN CHÂU KỲ

SẢN SINH CÁC TẬP LỆNH HỖ TRỢ

KIỂM THỬ TỰ ĐỘNG ỨNG DỤNG WEB

BẰNG THƯ VIỆN TỪ KHOÁ

Chuyên ngành: KHOA HỌC MÁY TÍNH

Mã số : 60.48.01.01

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 12 năm 2018

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

- -

NGUYỄN CHÂU KỲ

SẢN SINH CÁC TẬP LỆNH HỖ TRỢ

KIỂM THỬ TỰ ĐỘNG ỨNG DỤNG WEB

BẰNG THƯ VIỆN TỪ KHOÁ

Generate Test Scripts to Support Automation Testing

On Web Application by Keywords Library

Chuyên ngành: Khoa Học Máy Tính

Mã số : 60.48.01.01

LUẬN VĂN THẠC SĨ

3

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA - ĐHQG - HCM

Cán bộ hướng dẫn khoa học: TS Lê Lam Sơn

Cán bộ chấm nhận xét 1: TS Lê Hồng Trang

Cán bộ chấm nhận xét 2: TS Nguyễn Văn Vũ

Luận văn thạc sĩ được bảo vệ tại Trường Đại Học Bách Khoa, ĐHQG Tp.HCM ngày 27 tháng 12 năm 2018

Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm:


1 Chủ Tịch: TS Trần Minh Quang

2 Thư Ký: PGS.TS Nguyễn Thanh Bình

3 Phản Biện 1: TS Lê Hồng Trang

4 Phản Biện 2: TS Nguyễn Văn Vũ

5 Uỷ Viên: TS Phan Trọng Nhân

Xác nhận của Chủ tịch Hội đồng đánh giá LV và Trưởng Khoa quản lý chuyên ngành sau khi luận văn đã được sửa chữa

CHỦ TỊCH HỘI ĐỒNG TRƯỞNG KHOA KH & KT MÁY TÍNH

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ và tên học viên: Nguyễn Châu Kỳ MSHV: 1570215

Ngày, tháng, năm sinh: 31/05/1992 Nơi sinh: Quảng Ngãi

I TÊN ĐỀ TÀI:

Sản Sinh Các Tập Lệnh Hỗ Trợ Kiểm Thử Tự Động Ứng Dụng Web Bằng Thư Viện

Từ Khoá

II NHIỆM VỤ VÀ NỘI DUNG:

 Thu thập tập các từ khoá mô tả các hoạt động trong quá trình kiểm thử ứng dụng web dựa vào tần suất tương tác của hành động

 Phân loại từ khoá theo từng thành phần của giao diện Web

 Quản lý các đối tượng trên ứng dụng Web theo mô hình phân trang

 Xây dựng khung kiểm thử tự động hướng từ khoá bằng Selenium Webdriver

 Xây dựng Kịch bản mẫu để viết các trường hợp kiểm thử sử dụng từ khoá

III NGÀY GIAO NHIỆM VỤ: 04/09/2017

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 27/12/2018

V CÁN BỘ HƯỚNG DẪN: TS LÊ LAM SƠN

LỜI CẢM ƠN

Em xin gửi lời cảm ơn sâu sắc đến TS Lê Lam Sơn, giảng viên hướng dẫn luận văn của em, người đã tận tình chỉ bảo, hướng dẫn trong suốt thời gian thực hiện đề tài nghiên cứu này Sự hướng dẫn của thầy chính là động lực giúp em vượt qua những giai đoạn khó khăn để có kết quả như ngày hôm nay

Xin chân thành biết ơn đến các giảng viên của trường Đại Học Bách Khoa Thành Phố Hồ Chí Minh và đặc biệt là khoa Khoa học và Kỹ thuật máy tính đã tận tình dạy dỗ và truyền đạt những kiến thức quý báu cho em trong suốt hơn 2 năm học vừa qua

Em cũng xin gửi lời cảm ơn đến các anh chị kiểm thử viên trong công ty KMS Technology Việt Nam đã hỗ trợ em nhiệt tình trong việc khảo sát và thử nghiệm để làm giàu thư viện từ khoá

Cuối cùng, xin gửi lời cảm ơn sâu sắc đến gia đình, bạn bè, những người luôn sát cánh, động viên và giúp đỡ em trong suốt quá trình thực hiện đề tài này

TÓM TẮT LUẬN VĂN

Cho đến nay, đã có rất nhiều nghiên cứu nhằm xây dựng, sử dụng khung kiểm thử tự động để tự động hoá kiểm thử phần mềm trên ứng dụng web Tuy nhiên, thách thức khi xây dựng, sử dụng khung kiểm thử tự động là người kiểm thử viên ngoài yêu cầu phải có kiến thức về kiểm thử phần mềm còn phải có khả năng lập trình, hiểu rõ ngôn ngữ lập trình điều này làm tốn khá nhiều thời gian, chi phí và nguồn lực trong việc đào tạo để có thể sử dụng được khung kiểm thử tự động và tự động hoá các trường hợp kiểm thử thủ công một cách hiệu quả

Đã có nhiều hướng tiếp cận để giải quyết khó khăn trên như xây dựng khung kiểm thử tự động hướng từ khoá hay thực hiện các khung kiểm thử xử lý phức tạp để tăng khả năng ổn định Tuy nhiên, việc các ứng dụng web thay đổi và ra sản phẩm mới liên tục dẫn tới thời gian hiện thực diễn ra dài, quá trình bảo trì gặp khó khăn, khả năng tái sử dụng còn thấp và chi phí cao

Đề tài này hiện thực lại hướng tiếp cận xây dựng Khung kiểm thử tự động hướng từ khoá và giải quyết những khó khăn trong quá trình kiểm thử, kiểm thử viên thủ công có thể viết các kịch bản kiểm thử theo Kịch bản mẫu mà đề tài đưa ra, không hiện thực bất kỳ đoạn code nào khi sử dụng Việc phân loại từ khoá sẽ giúp xây dựng tập hành động riêng biệt ứng với từng thành phần của ứng dụng web qua đó giúp việc

tự động hoá sẽ dễ dàng hơn và hiệu quả cao hơn Đầu tiên là làm giàu thư viện từ khoá bằng cách thu thập các hành động trên các ứng dụng web từ các kiểm thử viên của công ty KMS Technology bằng cách ghi lại các hoạt động kiểm thử của họ và lọc ra theo tần suất xuất hiện các hành động trong quá trình kiểm thử Sau đó phân loại từ khoá dựa trên thành phần ứng dụng web mà hành động tương tác Cuối cùng là sử dụng Selenium để xây dựng khung kiểm thử tự động hướng từ khoá

Sau quá trình nghiên cứu và hiện thực, luận văn đạt được những kết quả khả quan Cụ thể là xây dựng được Khung kiểm thử phần mềm Web hướng từ khoá với hơn 50 từ khoá để tự động hoá hầu hết các hành động xảy ra khi một kiểm thử viên thực hiện hành vi kiểm thử trên ứng dụng Web, qua đó giúp quá trình tự động hoá ứng dụng web diễn ra nhanh và tiết kiệm thời gian hơn

ABSTRACT

So far, there has been a lot of research has been done to build and use an mation Testing Framework to automate software testing on web applications Howev-

Auto-er, the challenge of building, using the Automation Testing Framework is that testers

in addition require knowledge of software testing to be able to program, understand the language to write the script This programming takes a lot of time, cost and resources

in training to be able to use automation testing framework and automate the manual test cases effectively

There have been many approaches to solving the above problem, such as ing Keywords Driven Framework or implementing the complexity Test Framework to increase stability However, web application was many changed and releasing product continuosly has led to implementation was a long time, difficult in maintenance, low reusable and high costs

build-This topic redefines the approach of building a Keyword-Driven Testing Framework and resolving difficulties in the testing process, manual tester can write test scripts by following Scenario Template that the topic given, no code when using Keyword classification helps to build a separate action set for each component of the web application, thereby making automation easier and more efficient First step, en-rich the keyword library by collecting actions on web applications from KMS Tech-nology's testers by recording their test activities and filtering out the frequency of oc-currences of the actions are performed during testing process Then classify the key-words based on the component of web application that the action interacts Finally, use Selenium to build a Keyword Driven Testing Framework

After the process of research and implementation, we have achieved positive results In particular, built a Keyword Driven Web Testing Framework with more than

50 keywords to automate most of the actions that occur when a tester performs test havior in Web application, which makes the process of automation testing web appli-cations faster and saves time

be-LỜI CAM ĐOAN

Em xin cam đoan ngoại trừ những kết quả tham khảo từ các công trình khác như đã ghi rõ trong luận văn, sản phẩm phần mềm cũng như báo cáo là do chính em thực hiện dưới sự hướng dẫn của TS Lê Lam Sơn Không có nội dung nào trong luận văn được sao chép từ những công trình khác mà không có ghi chú Nếu có bất cứ sai phạm nào so với lời cam kết, em xin chịu các hình thức xử lý theo quy định

TP HCM, ngày 27 tháng 12 năm 2018

Ký tên

Nguyễn Châu Kỳ

MỤC LỤC

CHƯƠNG I: TỔNG QUAN 14

1.1 Giới thiệu vấn đề 14

1.2 Mục tiêu nghiên cứu 14

1.3 Phạm vi Đề tài 15

1.4 Cấu trúc luận văn 15

CHƯƠNG II: CƠ SỞ LÝ THUYẾT 17

2.1 Kiểm thử tự động phần mềm 17

2.2 Khung kiểm thử tự động phần mềm 19

2.3 Xác định đối tượng UI bằng xpath 22

2.4 Selenium Webdriver 29

CHƯƠNG III: NHỮNG NGHIÊN CỨU LIÊN QUAN 30

3.1 Nghiên cứu về sử dụng KKTTĐ hướng từ khoá 30

3.2 Nghiên cứu về thiết kế và phát triển từ khoá 31

3.3 Nghiên cứu về phân tích và thiết kế KKTTĐ bằng selenium webdriver 31

3.4 Những công cụ hỗ trợ kiểm thử tự động 32

CHƯƠNG IV: THIẾT KẾ & HIỆN THỰC 34

4.1 Phân tích yêu cầu 34

4.2 Thiết kế và Hiện Thực 34

4.3 Xây dựng khung kiểm thử Hướng từ khoá 48

CHƯƠNG V: THỰC NGHIỆM & ĐÁNH GIÁ 53

5.1 Các kịch bản thử nghiệm trên web thực tế 53

5.2 Viết kịch bản bằng scenario template 62

5.3 Chạy scenario template bằng command line 68

5.4 Đánh giá 71

CHƯƠNG VI: TỔNG KẾT 72

6.1 Kết quả đạt được 72

6.2 Những mặt hạn chế 73

6.3 Hướng phát triển 73

TÀI LIỆU THAM KHẢO 74

PHỤ LỤC THƯ VIỆN TỪ KHOÁ 75

LÝ LỊCH TRÍCH NGANG 88

DANH MỤC CÁC TỪ VIẾT TẮT

DANH SÁCH HÌNH VẼ

Hình 2.2.1: Mô hình hướng dữ liệu 20

Hình 2.2.2: Mô hình hướng từ khóa 21

Hình 2.3.1: Định dạng cơ bản của XPath 22

Hình 2.3.2: Ví dụ về biểu thức xpath tuyệt đối của phần tử 23

Hình 2.3.3: Ví dụ về biểu thức XPath tương đối của cùng một phần tử 24

Hình 2.3.4: Ví dụ về sử dụng Contains trong Xpath để bắt đối tượng 25

Hình 2.3.5: Ví dụ việc tìm 2 phần tử có thuộc tính ‘class’ động trong Xpath 26

Hình 2.3.6: Ví dụ sau tìm phần tử có text = ‘Nhớ tài khoản’ 27

Hình 4.2.1: Cửa sổ tạo bản ghi các bước kiểm thử của qTest Explorer 35

Hình 4.2.2: Giao diện của một Alert bình thường 37

Hình 4.2.3: Giao diện của một Alert Prompt 37

Hình 4.2.4: Giao diện của một alert confirmation 38

Hình 4.2.5: Thị phần các trình duyệt web vào đầu quý 1 năm 2017 39

Hình 4.2.6: Giao diện của trình duyệt Chrome 39

Hình 4.2.7: Ví dụ tương tác với bàn phím bằng cách tìm kiếm trên google 41

Hình 4.2.8: Thuộc tính của các đối tượng trên trình duyệt 42

Hình 4.2.9: Đối tượng checkbox và radio button trên trình duyệt 43

Hình 4.2.10: Đối tượng combobox và drop-down list 44

Hình 4.2.11: Đối tượng Frame trên trình duyệt 45

Hình 4.3.1: Nguyên lý hoạt động của KKTTĐ Hướng Từ Khoá 50

Hình 4.3.2: Cấu trúc của KKTTĐ Hướng Từ Khoá 51

Hình 5.1.1: Online Store Web Application 53

Hình 5.1.2: Một Thông Báo trên hệ thống W3School 54

Hình 5.1.3: Trang Demo QA trên trình duyệt Chrome 55

Hình 5.1.4: Radio và Checkbox trên hệ thống Tools QA 56

Hình 5.1.5: Combobox và Drop-down list trên hệ thống Tools QA 57

Hình 5.1.6: Trang Demo QA trên trình duyệt Chrome 58

Hình 5.1.7: Inspect một đối tượng trên Chrome 59

Hình 5.1.8: Dùng xpath trên Console của trình duyệt để bắt đối tượng 60

Hình 5.1.9: Dùng ChroPath để bắt Xpath của đối tượng 60

Hình 5.1.10: Xpath của các đối tượng trên trang Home và Login 61

Hình 5.1.11: Xpath của các đối tượng lưu trữ trong tệp Object Repository 61

Hình 5.2.1: Tạo danh sách các đối tượng quản lý theo Page 63

Hình 5.2.2: Hiển thị danh sách các đối tượng thuộc trang Home 63

Hình 5.2.3: Tạo danh sách các từ khoá dùng Data Validation 64

Hình 5.2.4: Hiện thị danh sách các Từ Khoá trong cột ‘Action Keyword’ 64

Hình 5.2.5: Thông tin 7 Kịch bản mẫu trong Sheet ‘Test Cases’ 65

Hình 5.2.6: Thông tin các bước kiểm thử của Kịch bản Login_01 66

Hình 5.2.7: Thông tin các bước kiểm thử của Kịch bản Alert_02 66

Hình 5.2.8: Thông tin các bước kiểm thử của Kịch bản Browser_03 67

Hình 5.2.9: Thông tin các bước kiểm thử của Kịch bản RadioCheckbox_04 67

Hình 5.2.10: Thông tin các bước kiểm thử của Kịch bản Combobox_05 67

Hình 5.2.11: Thông tin các bước kiểm thử của Kịch bản DropDownList_06 67

Hình 5.2.12: Thông tin các bước kiểm thử của Kịch bản Draggable_07 67

Hình 5.3.1: Đóng gói maven project bằng command line 69

Hình 5.3.2: Thực thi file jar bằng command line 69

Hình 5.3.3: Kết quả trả về của các Kịch bản thử nghiệm trong Sheet ‘Test Cases’ 69

Hình 5.3.4: Kết quả trả về của các Bước kiểm thử trong Sheet ‘Test Steps’ 69

Hình 5.3.5: Thời gian bắt đầu thực thi 7 Kịch bản thử nghiệm trên Command Line 70

Hình 5.3.6: Thời gian kết thúc thực thi 7 Kịch bản thử nghiệm trên Command Line 70

DANH SÁCH BẢNG BIỂU

Bảng 2.1.1: Bảng so sánh điểm mạnh và điểm yếu của hai loại kiểm thử 17

Bảng 3.1.1: Bảng dữ liệu kiểm thử hướng từ khóa cho tính năng Đăng nhập của Yahoo 30

Bảng 4.2.1: Mẫu đặc tả các trường hợp kiểm thử trên ứng dụng web 47

Bảng 4.2.2: Mẫu đặc tả các bước kiểm thử của một một trường hợp kiểm thử 48

Bảng 5.1.1: Thời gian bắt các đối tượng cần kiểm thử của 7 trường hợp kiểm thử 62

Bảng 5.1.2: Thời gian nhập thông tin các bước kiểm thử của 7 trường hợp kiểm thử 68

CHƯƠNG I: TỔNG QUAN

1.1 GIỚI THIỆU VẤN ĐỀ

Xây dựng Khung kiểm thử để tự động hoá kiểm thử phần mềm web là một trong những hướng nghiên cứu quan trọng trong lĩnh vực kiểm thử tự động phần mềm

Hiện tại, có rất nhiều nghiên cứu [1][2][3][4][5][6][7] nhằm xây dựng khung kiểm thử tự động vào việc tự động hoá các ứng dụng web Tuy nhiên, thách thức khi xây dựng khung kiểm thử tự động là việc sử dụng gặp nhiều khó khăn, yêu cầu phải có khả năng lập trình để viết kịch bản điều này làm tốn khá nhiều thời gian, chi phí và nguồn lực trong việc đào tạo để có thể sử dụng được khung kiểm thử tự động nhằm tự động hoá các trường hợp, kịch bản kiểm thử thủ công một cách hiệu quả

Em chọn đề tài “Sản sinh các tập lệnh hỗ trợ kiểm thử tự động ứng dụng Web bằng thư viện từ khoá” Với mong muốn xây dựng một Khung kiểm thử tự động hướng từ khoá nhằm cung cấp một Thư viện từ Khoá để tự động hoá các hành vi kiểm thử trên ứng dụng web, tạo ra một Kịch bản mẫu để chạy các trường hợp kiểm thử một cách thân thiện và dễ dàng sử dụng với kiểm thử viên thủ công, không đòi hỏi khả năng lập trình, đồng thời thiết kế quản lý các đối tượng tương tác trên web theo trang Page Object Model (POM) để dễ dàng bảo trì khi có thay đổi trên web

1.2 MỤC TIÊU NGHIÊN CỨU

Đề tài này hiện thực lại hướng tiếp cận xây dựng Khung kiểm thử tự động hướng từ khoá, kiểm thử viên thủ công (manual tester) có thể viết các kịch bản kiểm thử theo một Kịch bản mẫu, không hiện thực bất kỳ đoạn mã nào khi sử dụng Đồng thời bổ sung việc phân loại từ khoá sẽ giúp xây dựng tập hành động riêng biệt ứng với từng thành phần của ứng dụng web qua đó giúp việc tự động hoá sẽ dễ dàng hơn và hiệu quả cao hơn Với mục tiêu đó những nhiệm vụ đặt ra là:

- Thu thập tập các từ khoá mô tả các hành động trong quá trình kiểm thử một ứng dụng Web của kiểm thử viên

- Phân loại các từ khoá theo thành phần giao diện của ứng dụng Web

- Xây dựng Khung kiểm thử tự động hướng từ Khoá bằng Selenium Webdriver

- Xây dựng Kịch bản mẫu để viết các trường hợp kiểm thử sử dụng từ khoá

1.3 PHẠM VI ĐỀ TÀI

Trong khuôn khổ của nghiên cứu này em chỉ tập trung vào việc xây dựng tập các hành động và khung kiểm thử để thực thi các hành động một cách tự động Đồng thời do giới hạn của đề tài, em chỉ thực hiện tự động hoá trên các ứng dụng Web

Phạm vi thực nghiệm:

- Nhân viên nội bộ trong Công ty KMS Technology Viet Nam (chủ yếu là tester) Việc làm thế nào để thu hút các nhân viên kiểm thử sử dụng công cụ của em

không thuộc phạm vi đề cập trong đề tài nghiên cứu này

Phạm vi nghiên cứu:

- Phân tích giao diện đồ họa người dùng, các hành động thường được thực thi trên từng thành phần của giao diện Từ đó, trích xuất thành tập các hành động cần thiết để phục vụ tự động hóa

- Sử dụng công cụ mã nguồn mở Selenium Webdriver để xây dựng KKTTĐ và

áp dụng KKTTĐ vào kiểm thử chức năng trên ứng dụng web

- Tạo Kịch bản mẫu sử dụng từ khoá để viết kịch bản kiểm thử sử dụng từ khoá

và tạo cơ chế quản lý các đối tượng cần tuơng tác trên web theo Page Object Model (POM) để dễ dàng bảo trì khi ứng dụng web thay đổi

1.4 CẤU TRÚC LUẬN VĂN

Luận văn được chia thành 6 phần, với nội dung từng phần như sau:

Chương 1: Tổng quan

Chương này sẽ giới thiệu tổng quan về nội dung, mục tiêu, và phạm vi đề tài Cuối cùng là cấu trúc luận văn

Chương 2: Kiến thức nền tảng

Chương này trình bày các kiến thức nền tảng được tìm hiểu trong quá trình nghiên cứu

và sử dụng trong luận văn: Khung kiểm thử tự động, Xác định đối tượng UI bằng Xpath, Selenium Web Driver

Chương 3: Những nghiên cứu liên quan

Chương này trình bày những nghiên cứu mà luận văn tham khảo hay tiếp tục phát triển

Chương 4: Thiết kế và Hiện Thực

Trong chương này, em sẽ trình bày bốn phần

 Phần thứ nhất là thu thập tập các hành động được ghi lại trong quá trình kiểm thử của các tester

 Phần thứ hai là phân loại tập các hành động theo thành phần giao diện

 Phần thứ ba là đưa ra kịch bản mẫu để người dùng truyền từ khoá

 Phần cuối cùng là xây dựng khung kiểm thử hướng từ khoá

Chương 5: Thực nghiệm và Đánh giá

Chương này sẽ chạy thực nghiệm 7 kịch bản kiểm thử trên 5 ứng dụng Web để đánh giá lại Thư Viện Từ Khoá mà em đã xây dựng dựa trên tiêu chí là thời gian thực thi

Chương 6: Tổng kết

Chương cuối cùng sẽ rút ra những nhận xét trong quá trình thực hiện đề tài, bao gồm kết quả đạt được, những mặt hạn chế và phương hướng phát triển cho đề tài

CHƯƠNG II: CƠ SỞ LÝ THUYẾT

2.1 KIỂM THỬ TỰ ĐỘNG PHẦN MỀM

Kiểm thử thủ công

KTTC là kiểm thử viên làm mọi công việc hoàn toàn bằng tay, từ viết các trường hợp kiểm thử đến thực hiện kiểm thử, mọi thao tác như nhập điều kiện đầu vào, thực hiện một số sự kiện khác như nhấn nút và quan sát kết quả thực tế, sau đó so sánh kết quả thực tế với kết quả mong muốn trong trường hợp thử nghiệm, điền kết quả kiểm thử

Hiện nay, phần lớn các tổ chức, các công ty phần mềm, hoặc các nhóm làm phần mềm đều thực hiện KTTC là chủ yếu

Kiểm thử tự động

KTTĐ là thực hiện KTPM bằng một chương trình đặc biệt với rất ít hoặc không

có sự tương tác của con người, giúp cho kiểm thử viên không phải lặp đi lặp lại các bước nhàm chán

Công cụ KTTĐ có thể lấy dữ liệu từ file bên ngoài (excel, csv…) nhập vào ứng dụng, so sánh kết quả mong đợi (từ file excel, csv…) với kết quả thực tế và xuất ra báo cáo kết quả kiểm thử

Bảng 2.1.1: Bảng so sánh điểm mạnh và điểm yếu của hai loại kiểm thử

Kiểm thử Điểm mạnh Điểm yếu

Thủ công - Cho phép kiểm thử viên thực hiện việc

kiểm thử khám phá

- Thích hợp kiểm tra sản phẩm lần đầu tiên

- Thích hợp kiểm thử trong trường hợp các trường hợp kiểm thử chỉ phải thực hiện một số ít lần

- Giảm được chi phí ngắn hạn

- Tốn thời gian Đối với mỗi lần phát hành, người kiểm thử vẫn phải thực hiện lại một tập hợp các trường hợp kiểm thử đã chạy dẫn đến sự mệt mỏi và lãng phí công sức

Tự động - Thích hợp với trường hợp phải kiểm thử

nhiều lần cho một trường hợp, có tính ổn định và tin cậy cao hơn so với KTTC

- Tốn kém hơn KTTC, chi phí đầu tư ban đầu lớn

- KTTC là không thể thay thế

- Có thể thực hiện các thao tác lặp đi lặp lại (nhập dữ liệu, nhấn, kiểm tra kết quả ) giúp kiêm thử viên không phải làm những việc gây nhàm chán và dễ nhầm lẫn như

vậy

- Giảm chi phí đầu tư dài hạn

vì không thể tự động hóa mọi thứ

Lựa chọn loại hình kiểm thử

Khi phát triển phần mềm, việc thực hiện kiểm thử là bắt buộc, cho dù người thực hiện kiểm thử có thể là Lập trình viên, hoặc là Kiểm thử viên Vì thế, có kiến thức về kiểm thử, lựa chọn loại hình kiểm thử phù hợp với sản phẩm là điều cần thiết cho bất cứ người nào tham gia vào quá trình làm sản phẩm Mỗi loại hình kiểm thử đều có điểm mạnh và điểm yếu riêng, vậy nên lựa chọn loại hình kiểm thử nào, trong hoàn cảnh nào là phù hợp

KTTĐ sử dụng khi nào?

KTTĐ được sử dụng khi:

- Các trường hợp kiểm thử được thực hiện lặp đi lặp lại để đảm bảo tính năng của phần mềm/ sản phẩm

- Thực hiện ở các trường hợp mà KTTC khó thực hiện

- Các trường hợp kiểm thử cần tốn nhiều thời gian

KTTĐ sử dụng ở đâu?

- KTTĐ sử dụng trong các giai đoạn kiểm thử:

o Unit Testing (Kiểm thử đơn vị)

o Integration Testing (Kiểm thử tích hợp)

- Và trong các loại kiểm thử:

o Smoke Testing (Kiểm thử khói)

o Functional Testing (Kiểm thử chức năng)

o Regression Testing (Kiểm thử hồi quy)

Tại sao phải KTTĐ?

- KTTĐ sử dụng các công cụ có thể ghi lại bộ kiểm tra này và phát lại nó theo yêu cầu Tiết kiệm thời gian kiểm thử

- Tự động hóa không cần can thiệp của con người nên có thể chạy tự động kiểm tra mà không cần giám sát

- Tự động tăng tốc độ thực hiện kiểm tra Tự động hóa giúp tăng phạm vi kiểm tra

- Kiểm tra bằng tay có thể trở nên nhàm chán và do đó dễ bị lỗi

- Cải thiện độ chính xác Nhanh hơn 70% so với kiểm tra thủ công

2.2 KHUNG KIỂM THỬ TỰ ĐỘNG PHẦN MỀM

Khi bắt đầu làm việc với KTTĐ, chắc chắn chúng ta phải từng nghe đến cụm từ Test Automation Framework – Khung kiểm thử tự động (KKTTĐ) Cụm từ này có thể gây khó chịu cho vài người, làm cho họ cảm thấy nó là một khái niệm khó hiểu và khó thực hiện Bạn có thể hiểu vấn đề này một cách đơn giản

KKTTĐ – một cách đơn giản – là một tập hợp các quy luật, nguyên tắc dùng trong quá trình viết mã kiểm thử Các quy luật giúp chúng ta viết mã theo một cách mà

kết quả cuối cùng là “giảm thiểu việc chỉnh sửa mã kiểm thử khi ứng dụng thay đổi”

Những Mô hình phổ biến hiện nay

- Hướng dữ liệu (Data Driven)

- Hướng từ khóa (Keyword Driven)

HƯỚNG DỮ LIỆU – DATA DRIVEN FRAMEWORK

Đặc điểm cơ bản

- Dữ liệu kiểm thử (giá trị đầu vào và đầu ra) được tách khỏi mã nguồn và lưu trong một tập tin bên ngoài Nó có thể là một tập tin CSV, một bảng Excel hay một cơ sở dữ liệu

- Khi mã kiểm thử thực thi, các giá trị này được lấy ra từ tập tin, chứa vào biến

và thay thế các giá trị cứng (nếu có) trong mã nguồn

- Thực sự hữu ích khi mà cùng một kịch bản kiểm thử cần thực thi với nhiều dữ liệu đầu vào khác nhau

Hình 2.2.1: Mô hình hướng dữ liệu

Có vài ưu điểm khi áp dụng mô hình này Tất cả các giá trị kiểm thử được lưu bên ngoài mã nguồn, do đó, bất kỳ thay đổi nào xảy ra trong quá trình phát triển ứng dụng, chúng ta chỉ cần thay đổi dữ liệu trong tập tin bên ngoài, và mã KTTĐ của chúng ta vẫn được giữ nguyên

Một ưu điểm khác là, khả năng sử dụng một kịch bản kiểm thử cho nhiều dữ liệu khác nhau Ví dụ như, bạn đang làm một kịch bản đăng nhập hệ thống cho 100 users Bạn có thể viết một đoạn mã và một tập tin lưu trữ thông tin của 100 user Sau

đó, bạn chỉ cần thực thi một lần, và đi qua cả 100 bộ dữ liệu Bạn dễ dàng phát hiện, với kiểu dữ liệu nào thì đoạn mã sẽ thất bại Đây cũng là một thế mạnh khi bạn đang làm kiểm thử phủ định (Negative Test)

HƯỚNG TỪ KHÓA – KEYWORD FRAMEWORK

Đặc điểm cơ bản

- Cả dữ liệu và chức năng được định nghĩa bên ngoài mã nguồn

- Cần phát triển các từ khóa cho nhiều chức năng khác nhau

- Mã KTTĐ đôi khi được lưu trữ ở một tập tin bên ngoài mã nguồn giống như

mô hình hướng dữ liệu Các bước của kịch bản kiểm thử được viết từng bước với định dạng bảng, nơi mà sử dụng các từ khóa và dữ liệu kiểm thử

- Mã nguồn chính sẽ đọc các bước trong định dạng bảng và thực thi các chức năng tương ứng

- Cho phép các kỹ sư KTTC, những người không biết về lập trình, có thể là một phần, ở một mức độ, của nhóm KTTĐ

Hình 2.2.2: Mô hình hướng từ khóa

Ưu điểm của mô hình hướng từ khóa

Mô hình này rất hữu dụng trong những trường hợp mà kịch bản kiểm thử có quá nhiều thay đổi Nếu bất kỳ bước nào trong kịch bản kiểm thử bị thay đổi, chúng ta không cần phải chỉnh sửa mã nguồn Chúng ta chỉ cần chỉnh sửa tập tin bên ngoài và như vậy, kịch bản KTTĐ sẽ được chỉnh sửa theo

Chúng ta định nghĩa toàn bộ kịch bản ở tập tin và đưa cho kỹ sư KTTC, họ sẽ sắp xếp các đoạn văn bản (text) hoặc chỉnh sửa cái có sẵn Bằng cách này, kỹ sư KTTC cũng có thể trở thành một phần của nhóm KTTĐ bởi vì họ không cần phải lập trình gì cả Họ chỉ cần chỉnh sửa tập tin ở những vị trí cần thiết và kịch bản kiểm thử sẽ được chỉnh sửa một cách tự động

Một lợi ích khác của mô hình này là, kịch bản kiểm thử của bạn trở thành một công cụ độc lập Bạn chỉ cần bảo trì kịch bản kiểm thử trong một tập tin và nếu bạn cần thay đổi công cụ kiểm thử tự động ở điểm nào đó, bạn có thể dễ dàng chỉnh sửa bằng cách viết lại cách đọc và thực thi tập tin với công cụ mới

Mặc khác, khuyết điểm của mô hình này là, bạn cần phát triển các từ khóa cho các chức năng khác nhau Trong một dự án lớn, có thể có rất nhiều từ khóa mà bạn cần phải nhớ và tổ chức nó hợp lý Bản thân việc này có thể sẽ làm một công việc nặng nhọc cho quá trình phát triển kiểm thử tự động

Mô hình hướng từ khóa là một mô hình ưa thích của nhiều kỹ sư KTTĐ Robot Framework – công cụ KTTĐ được phát triển bởi Google – là một công cụ phổ biến đi theo hướng từ khóa Những công cụ đi theo hướng từ khóa này còn có Quick Test Pro hay Katalon Studio

2.3 XÁC ĐỊNH ĐỐI TƯỢNG UI BẰNG XPATH

Xpath là gì?

Xpath được định nghĩa là đường dẫn XML Nó là một cú pháp hoặc ngôn ngữ để tìm kiếm bất kỳ phần tử nào trên trang web bằng cách sử dụng biểu thức XML path Xpath được sử dụng để tìm vị trí của bất kỳ phần tử nào trên trang web bằng cách sử dụng cấu trúc DOM HTML

Hình 2.3.1: Định dạng cơ bản của XPath

Cú pháp XPath

XPath chứa đường dẫn của phần tử nằm ở trang web Cú pháp chuẩn để tạo XPath là

Xpath=//tagname[@attribute='value']

- //: Chọn node hiện tại

- Tagname: Tên thẻ HTML của node cụ thể

- @: Select attribute

- Attribute: Tên thuộc tính của node

- Value: Giá trị của thuộc tính

Các loại XPath

XPath tuyệt đối

Đây là cách trực tiếp để tìm phần tử, nhưng nhược điểm của XPath tuyệt đối là nếu có

bất kỳ thay đổi nào được thực hiện trong đường dẫn của phần tử thì XPath sẽ bị lỗi Đặc điểm chính của XPath là nó bắt đầu bằng dấu gạch chéo đơn (/), có nghĩa là bạn

có thể chọn phần tử từ nút gốc

Dưới đây là ví dụ về biểu thức xpath tuyệt đối của phần tử được hiển thị trong màn hình:

/html/body/div[2]/div[1]/div[1]/ul[2]/li[4]/a

Hình 2.3.2: Ví dụ về biểu thức xpath tuyệt đối của phần tử

XPath tương đối

Đối với Xpath tương đối, đường dẫn bắt đầu từ giữa cấu trúc DOM HTML Nó bắt đầu bằng dấu gạch chéo kép (//), có nghĩa là nó có thể tìm kiếm phần tử ở bất kỳ đâu trên trang web Bạn có thể bắt đầu từ giữa cấu trúc DOM HTML và không cần phải viết xpath dài lê thê

Dưới đây là ví dụ về biểu thức XPath tương đối của cùng một phần tử được hiển thị trong màn hình dưới đây Đây là định dạng phổ biến được sử dụng để tìm phần tử thông qua XPath tương đối

//a[@href="/xpath-tester.html"']

Hình 2.3.3: Ví dụ về biểu thức XPath tương đối của cùng một phần tử

Sử dụng XPath xử lý các phần tử phức tạp và động trong Selenium

XPath cơ bản:

Biểu thức XPath chọn các node hoặc danh sách các node trên cơ sở các thuộc tính như

ID, name, class, vv từ tài liệu XML

Một số biểu thức xpath cơ bản hơn:

văn bản một phần của thuộc tính Trong biểu thức XPath dưới đây, giá trị một phần

‘sub’ được sử dụng thay cho nút gửi Nó có thể được quan sát thấy rằng các phần tử được tìm thấy thành công

- Giá trị của thuộc tính type là ‘submit’ nhưng chúng ta chỉ cần sử dụng chuỗi con của

nó là ‘sub’: Xpath=//*[contains(@type,'sub')]

- Ví dụ giá trị của thuộc tính name là ‘btnLogin’, nhưng chúng ta chỉ cần sử dụng một

phần giá trị như sau: Xpath=.//*[contains(@name,'btn')]

Hình 2.3.4: Ví dụ về sử dụng Contains trong Xpath để bắt đối tượng

Sử dụng toán tử OR và ADD:

Trong biểu thức OR, hai điều kiện được sử dụng, cho dù điều kiện 1 HOẶC điều kiện

thứ 2 có đúng không Nó cũng được áp dụng nếu bất kỳ điều kiện nào là đúng hoặc có thể cả hai Có nghĩa là bất kỳ điều kiện nào cũng đúng để tìm phần tử

Trong biểu thức XPath dưới đây, nó xác định các phần tử có một hoặc cả hai điều kiện

là đúng

Xpath = //*[@type='submit' or @name='btnReset']

Trong biểu thức AND, hai điều kiện được sử dụng, cả hai điều kiện phải đúng để tìm

phần tử Nó không tìm thấy phần tử nếu bất kỳ một điều kiện nào là sai

Xpath = //*[@type='submit' and @name='btnReset']

Hàm starts-with() trong XPath:

Với các trang web động khi tải lại hoặc các hoạt động khác tương tự thì giá trị thuộc tính của các phần tử bị thay đổi Trong trường hơp này, bạn nên sử dụng hàm này để tìm phần tử có thuộc tính thay đổi động Bạn cũng có thể tìm thấy phần tử có giá trị thuộc tính là tĩnh (không thay đổi)

Ví dụ: Giả sử ID của phần tử cụ thể thay đổi động như:

Hình 2.3.5: Ví dụ việc tìm 2 phần tử có thuộc tính ‘class’ động trong Xpath

Hàm text() trong Xpath:

Với phương thức này, chúng ta có thể tìm thấy phần tử có văn bản khớp với văn bản được chỉ định

Xpath = //*[text()='Nhớ tài khoản']

Hàm text() có thể kết hợp với hàm contains() Ví dụ:

Xpath = //*[contains(text(), 'Nhớ tài khoản')]

Hình 2.3.6: Ví dụ sau tìm phần tử có text = ‘Nhớ tài khoản’

Các cách xác định trong Xpath

Xác định tuyệt đối “/”

Một dấu slash “/” xác định một đường dẫn tuyệt đối đến một đối tượng UI

Ví dụ: “/html/body/table” cho phép chúng ta lấy ra toàn bộ các bảng html trên trang web ngay sau thẻ body

“//div//span” cho phép chúng ta lấy ra toàn bộ thẻ span mà trước đó có một thẻ div, không quan tâm đến mức độ của thẻ div và span trong mã nguồn

Xác định bằng thuộc tính “@”

Ký hiệu “@” cho phép chúng ta lọc lại các đối tượng UI được trả về thông qua một thuộc tính có bên trong thẻ html

Ví dụ: “//div[@class=’abc’]” cho phép chúng ta lấy ra tất cả thẻ div trong mã nguồn

mà có thuộc tính class là ‘abc’

Xác định bằng nội dung text()

Chức năng text() cho phép chúng ta lọc các đối tượng UI được trả về dựa trên nội dung text bên trong một thẻ html

Ví dụ: “//div[text()=’abc’]” cho phép chúng ta lấy ra tất cả các thẻ div trong mã nguồn

 “//div[contains(text(),’abc’)]” cho phép chúng ta lấy ra tất cả các thẻ div trong

mã nguồn có text chứa đoạn ‘abc’

 “//div[startwith(.,’abc’)]” cho phép chúng ta lấy ra tất cả các thẻ div trong mã nguồn có innertext bắt đầu bằng ‘abc’

 “//div[endwith(text(),’abc’)]” cho phép chúng ta lấy ra tất cả các thẻ div trong

mã nguồn có text kết thúc bằng ‘abc’

Xác định đối tượng cha “/ ”

Ký hiệu “/ ” cho phép chúng ta xác định đối tượng UI ở trên một cấp

Ví dụ: “//div/ ” cho phép chúng ta lấy ra tất cả các thẻ html mà có thẻ div ngay bên dưới nó một cấp

Xác định đối tượng từ một ví trí xác định Preceding và Following

Hai từ khoá preceding và following cho phép chúng ta lọc ra các đối tượng UI từ một đối tượng đã được xác định trước đó Hai từ khoá này không phụ thuộc vào mức độ level của thẻ html trong mã nguồn

Ví dụ:

“//div[@id=’abc’]/following::a” cho phép chúng ta lấy ra tất cả các thẻ a trong mã nguồn bên dưới một thẻ div có id là ‘abc’

2.4 SELENIUM WEB DRIVER

Selenium Web Driver là gì?

WebDriver là một khuôn khổ tự động hóa web cho phép bạn thực hiện các kiểm thử của mình trên các trình duyệt khác nhau Nó nằm trong bộ kiểm thử tự động Selenium

Tại sao sử dụng Selenium Web Driver?

- Tốc độ: Khi so sánh với các công cụ khác của bộ Selenium, WebDriver là công cụ nhanh nhất trong số tất cả do tương tác trực tiếp từ hệ điều hành tới trình duyệt

Sử dụng Selenium Web Driver ở đâu?

Web Driver được hỗ trợ trên các trình duyệt: Firefox, Google Chrome, Internet plorer, Opera browser, Sarafi …

Ex-CHƯƠNG III: NHỮNG NGHIÊN CỨU LIÊN QUAN

3.1 NGHIÊN CỨU VỀ SỬ DỤNG KKTTĐ HƯỚNG TỪ KHOÁ

Bài nghiên cứu “A Keyword Driven Framework for Testing Web Applications” của Rashmi và Neha Bajpai vào tháng 3 năm 2012 Nghiên cứu này khám phá việc sử dụng KKTTĐ hướng từ khoá để thử nghiệm tự động ứng dụng web Nó bao gồm việc tạo ra các mô đun thành phần kiểm tra tái sử dụng Các thành phần này sau đó được lắp ráp thành các tập lệnh kiểm tra, có thể có tham số để làm cho chúng có thể sử dụng lại được trên các tập lệnh kiểm tra khác nhau Các tập lệnh kiểm tra này cũng có thể được chia thành nhiều hành động tái sử dụng Điều này tiết kiệm rất nhiều thủ tục ghi chép Các công cụ hiện có cho thử nghiệm này sử dụng Html, Xml, Spreadsheet, v.v

để duy trì các bước thử nghiệm Các kết quả kiểm tra được phân tích để tạo các báo cáo kiểm tra

Bài nghiên cứu cũng đưa ra một ví dụ về việc sử dụng KKTTĐ hướng từ khóa

để kiểm thử cho một trường hợp đơn giản là đăng nhập vào một ứng dụng web Yahoo Bảng 3.1.1: Bảng dữ liệu kiểm thử hướng từ khóa cho tính năng Đăng nhập của Yahoo

Bài nghiên cứu đã đưa ra nhiều lợi thế khác nhau khi sử dụng các kỹ thuật kiểm tra từ khóa Những ưu điểm này như sau:

- Từ khóa có thể sử dụng lại trong nhiều trường hợp thử nghiệm

- Không phụ thuộc vào công cụ hay ngôn ngữ

- Danh sách từ khóa là mạnh mẽ khi phần mềm có thay đổi nhỏ

- Phân chia các trường hợp thử nghiệm

3.2 NGHIÊN CỨU VỀ THIẾT KẾ VÀ PHÁT TRIỂN TỪ KHOÁ

Bài nghiên cứu ‘An Efficient Keyword Driven Test Automation Framework For Web Aplications’ của Abhishek Jain và Sheetal Sharma vào tháng 5 năm 2012 Mục tiêu chính của công trình nghiên cứu này là thiết kế và phát triển từ khoá Với sự trợ giúp của các từ khóa có thể tạo các trường hợp thử nghiệm một cách dễ dàng và nhanh chóng Nghiên cứu này cũng nêu ra, việc bổ sung các kỹ sư KTPM không phải

là một giải pháp dài hạn, khả thi khi cần cải thiện chất lượng của phần mềm, vì thế cần phải giảm chi phí tổng thể của dự án bằng cách áp dụng các KKTTĐ Có nhiều loại KKTTĐ khác nhau có sẵn cho KTPM KKTTĐ hướng từ khóa đảm bảo ba đặc tính chính: Chất lượng, Thời gian và Chi phí của KTPM KKTTĐ hướng từ khoá làm giảm các vấn đề về kiến thức lập trình phức tạp để tự động hóa trong kiểm thử Người KTTC cũng có thể tạo ra các tập lệnh kiểm tra đơn giản bằng cách kết hợp các từ khoá

Bài nghiên cứu đã đưa ra những lợi ích của KKTTĐ hướng từ khoá như sau:

- Tự động hoá có thể được thực hiện sớm (ngay khi có yêu cầu đặc tả)

- Kiểm thử viên thủ công tạo kịch bản thử nghiệm mà không cần có kiến thức về lập trình

- Quá trình kiểm thử tổng thể trong suốt vòng đời của phát triển phần mềm được rút ngắn

3.3 NGHIÊN CỨU VỀ PHÂN TÍCH VÀ THIẾT KẾ KHUNG KIỂM THỬ TỰ ĐỘNG BẰNG SELENIUM WEBDRIVER

Bài nghiên cứu ‘Analysis and Design of Selenium WebDriver Automation Testing Framework’ của Satish Gojare, Rahul Joshi và Dhanashree Gaigaware vào năm 2015 Mục tiêu chính của công trình nghiên cứu này là phân tích và thiết kế một KKTTĐ mới với sự hỗ trợ của Selenium Webdriver và TestNG nhằm giảm sự can thiệp của con người và các nhiệm vụ lặp lại trong quá trình kiểm thử Selenum

Webdriver hỗ trợ tìm kiếm các đối tượng trên web thông qua các thuộc tính của đối tượng như id, link text, xpath hoặc css selector Tất cả các định vị của đối tượng web được lưu trữ trong Object Repository sẽ dễ dàng để bảo trì khi ứng dụng thay đổi Tuy

nhiên Selenium Webdriver không hỗ trợ xây dựng tính năng tạo ra các báo cáo Vì thế KKTTĐ sử dụng thêm một công cụ là TestNG để sinh ra các báo cáo

Bài nghiên cứu đã đưa ra những lợi ích của KKTTĐ được xây dựng từ Selenium

Webdriver và TestNG như:

- Tạo ra các báo cáo HTML cho từng kịch bản kiểm thử một cách rõ ràng

- Có khả năng tuỳ chỉnh các báo cáo thử nghiệm

- Hỗ trợ phân tích lỗi bằng cách sử dụng ảnh chụp màn hình của các trường hợp thử nghiệm không thành công

Tuy nhiên, KKTTĐ này yêu cầu khả năng lập trình vì kiểm thử ở mức đơn vị (Unit Test) và chúng ta phải sử dụng nó trong môi trường phát triển tích hợp IDE như

Eclipse, Intellij Điều này không dễ dàng cho các lập trình viên thủ công

3.4 NHỮNG CÔNG CỤ HỖ TRỢ KIỂM THỬ TỰ ĐỘNG

Katalon Studio

Gần đây, công ty KMS Technology đưa ra thị trường một công cụ kiểm thử tự động dành cho các ứng dụng Web, API và Mobile – Katalon Studio Điều thú vị là Katalon Studio sử dụng thư viện của Selenium và Appium làm nền tảng cho việc nhận diện và tương tác với ứng dụng cần kiểm thử (Application under Test) Nếu Katalon Studio được xây dựng từ Selenium/Appium, tại sao chúng ta không dùng trực tiếp hai công cụ phổ biến trong cộng động kiểm thử này mà cần phải dùng đến Katalon Studio?

Như mọi công cụ kiểm thử tự động, Katalon Studio cũng có chức năng Playback để chúng ta có thể biết và hiểu được cách ứng dụng viết mã và thực thi kiểm thử Katalon Studio đi theo mô hình kiểm thử tự động hướng từ khóa với cách thiết kế bảng biểu kinh điển mà chúng ta cũng có thể thấy ở QuickTestPro hay RobotFramework Ngoài những từ khóa mà ứng dụng có sẵn (build-in keyword), chúng ta cũng có thể tạo ra những từ khóa mới bằng cách viết theo hướng bảng biểu, sử dụng các từ khóa đã có sẵn, hoặc chúng ta có thể tự viết ra những từ khóa riêng biệt

Record-từ các dòng mã với ngôn ngữ Groovy – một ngôn ngữ gần với Java Đây cũng có thể coi là một điểm trừ của Katalon Studio khi không nhiều người sử dụng Groovy lắm

(theo nghiên cứu của tiobe, năm 2016 này Groovy chỉ đứng ở vị trí 19 trong số những ngôn ngữ lập trình phổ biến)

Quick Test Professional (QTP)

Đây cũng là một công cụ ứng dụng phương pháp Keywork-driven, một kỹ thuật scripting trong kiểm thử tự động hiện đại cho phép kiểm thử viên bổ sung testcase bằng cách tạo file mô tả cho nó mà không cần chỉnh sửa hay bổ sung bất cứ đoạn mã nào Tuy nhiên, QTP chỉ chạy trên môi trường Window và tốn chi phí nên công cụ này không được sử dụng rộng rãi

Robot Framework

Robot Framework là một KKTTĐ sử dụng cách tiếp cận Keyword-driven bên cạnh data-driven Được sử dụng tốt nhất trên môi trường UNIX, Framework có khả năng dễ dàng mở rộng với những thư viện open-source Tuy nhiên framework này chỉ áp dụng ở phần cuối của kiểm thử acceptance testing (test nghiệm thu) nên chi phí bảo trì khi xảy ra lỗi là cao, không tạo kịch bản kiểm thử sớm Robot Framework sử dụng ngôn ngữ lập trình Python nên hạn chế trong những ngôn ngữ phổ biến khác như Java, C# Như vậy, qua các mô hình nghiên cứu trên cũng như các công cụ hỗ trợ kiểm thử tự động hiện có, ta thấy rằng dựa vào rất nhiều yếu tố để quyết định sử dụng loại KKTTĐ nào là hiệu quả trong KTTĐ, những hạn chế khi ứng dụng web thay đổi làm tốn thời gian, chi phí trong quá trình bảo trì Ngoài ra, điểm hạn chế của những bài nghiên cứu trên và các công cụ hỗ trợ kiểm thử tự động hiện nay là chưa phân loại được các từ khoá một cách riêng biệt và hiệu quả theo thành phần giao diện mà chúng tương tác Các đối tượng kiểm thử không được quản lý theo Trang làm cho việc bảo trì chúng diễn ra khó khăn khi các ứng dụng web thay đổi vì ta phải tìm trang nào thay đổi và đối tượng nào bị ảnh hưởng để cập nhập Hạn chế về ngôn ngữ lập trình, hệ điều hành

Chính vì thế bài nghiên cứu của em, sẽ hiện thực lại KKTTĐ hướng từ khoá của những bài nghiên cứu trên sử dụng Selenium Webdriver, đồng thời khắc phục những nhược điểm bằng Thư Viện Từ Khoá mạnh mẽ, các đối tượng sẽ được quản lý theo POM (Page Object Model) dễ dàng bảo trì khi ứng dụng thay đổi và cuối cùng ta

có thể viết nhiều kịch bản thử nghiệm trên cùng một Kịch bản mẫu tạo nên sự nhất quán cho bộ kiểm thử và thân thiện với các lập trình viên thủ công

CHƯƠNG IV: THIẾT KẾ & HIỆN THỰC

4.1 PHÂN TÍCH YÊU CẦU

Mục tiêu của đề tài là xây dựng Thư viện Từ Khoá hỗ trợ kiểm thử tự động ứng dụng Web dành cho Kiểm thử viên thủ công Do đó yêu cầu phải đạt được là:

 Thu thập tập các từ khoá mô tả các hành động trong quá trình kiểm thử một ứng dụng Web của kiểm thử viên thủ công

 Phân loại các từ khoá theo thành phần giao diện của ứng dụng Web

 Xây dựng Kịch bản mẫu để kiểm thử viên thủ công tạo ra các kịch bản kiểm thử sử dụng từ khoá từ thư viện

 Xây dựng Khung kiểm thử tự động hướng từ khoá để thực thi tự động Kịch bản

mẫu trên ứng dụng web bằng Selenium Webdriver

4.2 THIẾT KẾ VÀ HIỆN THỰC

Thu thập tập các từ khoá theo tần suất xuất hiện của các hành động

Để thu thập tập các từ khoá em sử dụng công cụ qTest Explorer của QASymphony (một công ty ra đời bởi các nhà sáng lập KMS Technology Vietnam) Một trong những tính năng của công cụ này là “Record Test Sessions” giúp em tự động theo dõi và ghi lại tất cả các tương tác của người kiểm thử viên thủ công khi họ thực hiện quá trình kiểm thử trên các ứng dụng web như: thực hiện hành động gì, trên đối tượng nào với dữ liệu gì Tính năng này có 3 chức năng chính:

- Record: Ghi lại quá trình tương tác của người dùng trên trình duyệt và ứng dụng desktop

- Capture: Chụp lại toàn màn hình, lựa chọn màn hình và cửa sổ hoạt động để chụp khi người dùng tương tác với ứng dụng

- Document: tự động tạo tài liệu chi tiết có thể được lưu trữ dưới nhiều định dạng file như pdf, word, plaintext

Đầu tiên, em chuẩn bị một máy tính làm Test Server để cài đặt môi trường kiểm thử và công cụ qTest Explorer Trên máy chủ này, qTest Explorer sẽ giúp em theo dõi và ghi

lại tất cả các tương tác của Tester trên các ứng dụng Web mà em đã cài đặt như Demo Store Online Application, W3school Application, Demo QA Application, Automation Practice Form Application, QASymphony và xuất ra dạng file word

Hình 4.2.1: Cửa sổ tạo bản ghi các bước kiểm thử của qTest Explorer

Dựa vào các bản ghi này em sẽ liệt kê tất cả các hành động và phân loại tập các hành động lặp lại (thường là các động từ, ví dụ: click, type, verify, press ) dựa vào tần suất xuất hiện của nó so với tổng số bước kiểm thử trong một bộ các trường hợp kiểm thử Sau đó sắp xếp các hành động này theo chiều giảm dần của tần suất xuất hiện nhằm mục đích xác định độ ưu tiên, sự cần thiết để hiện thực Các hành động có tần suất xuất hiện từ cao (lặp lại nhiều) tới thấp (ít lặp lại hoặc không lặp)

Lưu ý rằng chúng ta sẽ vét cạn tất cả các hành động được ghi lại Việc xác định dựa trên tần suất xuất hiện chỉ để ưu tiên hiện thực cho các hành động phổ biến

Dưới đây là danh sách các hành động thu thập được và phân thành ba nhóm:

 Nhóm 1: nhóm các hành động xuất hiện nhiều hơn 1 lần

 Nhóm 2: nhóm các hành động chỉ xuất hiện 1 lần

 Nhóm 3: nhóm các hành động đặc biệt (xác thực và chờ)

Phân loại Actions

Nhóm 1 acceptAlert, dismissAlert, setAlertText, getAlertText, openBrowser,

close-Browser, backward, forward, refresh, navigateToUrl, captureScreenshot, pressKeyboards, Input, Click, doubleClick, scrollElementIntoView, dra- gAndDrop, mouseOver, rightClick, check, uncheck, deselectOptionByIn- dex, deselectOptionByValue, deselectOptionByLabel, deselectOption- ByVisibleText, selectOptionByIndex, selectOptionByValue, selectOption- ByVisibleText, closeWindowByIndex, switchToWindowByIndex, closeWindowTitle, switchToWindowByTitle, closeWindowByUrl, switch- ToWindowByUrl

deseletAllOption, authenticate, maximizeWindow, getAttribute

Nhóm 3 verifyAlertNotPresent, verifyAlertPresent, waitForAlertNotPresent,

wait-ForAlertPresent, verifyAlertMessage, verifyElementAttribute, fyElementText, threadSleep, verifyElementPresent, verifyElementNot- Present, verifyElementVisible, verifyElementNotVisible , verifyOption- NotPresentByValue, verifyOptionPresentByValue, verifyOption- PresentByLabel, verifyOptionNotPresentByLabel, verifyOptionNot- PresentByIndex, verifyOptionNotSelectedByIndex, verifyOptionNotSelect- edByValue, verifyAnyOptionNotSelected, verifyAnyOptionSelected, veri- fyOptionNotSelectedByLabel,verifyElementEnable, verifyElementNotEna- ble, waitForElementClickable, waitForElementPresent, wait-

veri-ForElementVisible, verifyNumberOfSelectedOption, talOption, verifyElementChecked, verifyElementNotChecked, switchToDe- fautWindow, waitForPageLoad, callTestCase, concatenate, delay, modi- fyObjectProperty, verifyEqual, verifyGreaterThan, verifyGreaterThanOrE- qual, verifyLessThan, verifyLessThanOrEqual, verifyMatch, verifyNotE- qual, verifyNotMatch, focus

verifyNumberOfTo-Phân loại các từ khoá theo thành phần giao diện của ứng dụng Web

Thành phần ứng dụng Web là HTML, CSS (DOM) và JavaScript tối thiểu hỗ trợ giao diện người dùng Các hành động mà em thu thập ở trên sẽ tương tác với đối tượng trên các thành phần của ứng dụng Web Việc phân loại từ khoá theo thành phần giao diện

của ứng dụng Web sẽ giúp xây dựng tập hành động riêng biệt ứng với từng thành phần của ứng dụng Web qua đó giúp việc tự động hoá sẽ dễ dàng hơn và hiệu quả cao hơn

Tương Tác Với Thông Báo – Alert

Alert là một thành phần mà bạn có thể gặp trong khi truy cập vào một số các ứng dụng Ta có thể hiểu đơn giản alert là một dạng message box nhỏ, nó hiển thị lên trên màn hình ứng dụng, nó cung cấp một số thông tin cần thiết cho người dùng, hoặc đôi khi là một message yêu cầu người dùng xác nhận trước khi thực hiện một thao tác nào

đó từ trang ứng dụng đó, với mục đích là hiển thị cảnh báo cho người dùng Ví dụ như các yêu cầu xác nhận về việc điều hướng trang, xác nhận việc đăng ký hoặc mua hàng thành công, hay là xác nhận việc hủy bỏ một thao tác nào đấy…

1 Alert bình thường: Alert này cung cấp một thông tin nào đó cho người dùng biết,

người dùng sau khi đọc thông tin được cung cấp thường sẽ nhấn OK để xác nhận

thông tin, khi đó alert sẽ đóng lại

Hình 4.2.2: Giao diện của một Alert bình thường

2 Alert Prompt: là một loại confirm mà yêu cầu người dùng input một thông tin nào

đó, và có thêm button là sau khi đã nhập thông tin vào alert có thể nhấn OK hoặc cel để đóng popup

Can-Hình 4.2.3: Giao diện của một Alert Prompt

3 Một loại alert khác được gọi alert confirmation, đơn giản hơn loại thứ hai và gần

giống loại đầu tiên, điểm khác biệt là nó có hai lựa chọn, nên ta có thể chọn một trong hai lựa chọn này là OK hoặc Cancel và không phải input thêm thông tin nào:

Hình 4.2.4: Giao diện của một alert confirmation

Selenium webdriver có cung cấp method switchTo() để hỗ trợ chúng ta có thể dễ dàng switch từ màn hình chính của ứng dụng sang Alert để thực hiện thao tác trong alert:

 dismiss() – Để thực hiện click vào button Cancel trong alert

Nhờ đó, ta hiện thực được một số từ khoá riêng biệt để làm việc với alert:

 acceptAlert - Người dùng muốn click on “OK” button của một thông báo

(alert, confirmation popup, prompt)

 dismissAlert - Người dùng muốn click on “Cancel” button của một thông báo

(alert, confirmation popup, prompt)

 setAlertText - Người dùng muốn nhập thông tin trên textbox của một thông

báo (alert, confirmation popup, prompt)

 verifyAlertMessage - Người dùng muốn kiểm tra tin nhắn của một thông báo

(alert, confirmation popup, prompt)

Tương Tác với Trình Duyệt – Browser

Có rất nhiều các trình duyệt Web đang được sử dụng trên thế giới Nhưng phổ biến nhất thì gồm có:

Hình 4.2.5: Thị phần các trình duyệt web vào đầu quý 1 năm 2017

Selenium Webdriver hỗ trở hầu hết các trình duyệt web phổ biến trên như: Chrome, Firefox, IE, Safari, Opera

Hình 4.2.6: Giao diện của trình duyệt Chrome

Selenium webdriver có cung cấp một số method để hỗ trợ chúng ta có thể dễ dàng thao tác trên trình duyệt:

Lệnh Mô tả

driver.get(“URL”) Để điều hướng đến một trang web

driver.navigate().to(“URL”) Chuyển hướng đến URL

driver.navigate().forward() Chuyển hướng đến trang tiếp theo

driver.navigate().back() Chuyển hướng về trang trước

driver.close() Đóng trình duyệt hiện tại và các liên kết đến driver driver.quit() Thoát driver và đóng tất cả các cửa sổ liên quan đến

driver đó

driver.refresh() Tải lại trang hiện tại

Nhờ đó, ta hiện thực được một số từ khoá riêng biệt để làm việc với trình duyệt:

 openBrowser - Người dùng muốn mở trình duyệt (Chrome, Firefox, IE)

 closeBrowser - Người dùng muốn đóng trình duyệt

 backward - Người dùng muốn quay lại trang trước trên trình duyệt

 forward - Người dùng muốn đến trang tiếp theo trên trình duyệt

 refresh - Người dùng muốn tải lại trang trên trình duyệt

 deleteAllCookies - Người dùng muốn xoá tất cả Cookies của trình duyệt

 navigateToUrl - Người dùng muốn đi đến một trang trên trình duyệt

 captureScreenshot - Người dùng muốn chụp lại trang trên trình duyệt

 threadSleep - Người dùng muốn dừng lại trên trình duyệt

 executeJavaScript - Người dùng muốn thực thi một đoạn javascrip trên một đối

tượng của trình duyệt

Tương tác với Bàn phím - Keyboard

Chúng ta sẽ thực hiện thao tác với bàn phím trong Selenium bằng việc sử dụng phương thức WebElement.sendKeys() hoặc Actions.sendKeys() Send keys để biểu diễn bàn phím trong trình duyệt Các phím đặc biệt không phải là văn bản, được biểu thị bằng Khóa được nhận dạng như là một phần của chuỗi ký tự hoặc ký tự riêng lẻ

Ví dụ: