Xây dựng ứng dụng kiểm thử phần mềm tự động sử dụng selenium và webdriver

Với selenium cùng một số công cụ hỗ trợ khác như Cucumber, Jenkins, Maven,… kiểm thử viên có thể phát triển thành các framework hỗ trợ cho viết các kịch bản kiểm thử và chạy các kịch bản

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

PHẠM THỊ HẢI YẾN

XÂY DỰNG ỨNG DỤNG KIỂM THỬ PHẦN MỀM TỰ ĐỘNG

SỬ DỤNG SELENIUM VÀ WEBDRIVER

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

HÀ NỘI - 2020

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

PHẠM THỊ HẢI YẾN

XÂY DỰNG ỨNG DỤNG KIỂM THỬ PHẦN MỀM TỰ ĐỘNG

SỬ DỤNG SELENIUM VÀ WEBDRIVER

Ngành: Công nghệ thông tin

Chuyên ngành: Khoa học máy tính

Mã số: 17025064

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS HOÀNG XUÂN HUẤN

HÀ NỘI - 2020

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của cá nhân tôi, thực hiện dưới sự hướng dẫn của PGS TS Hoàng Xuân Huấn Trong toàn bộ nội dung của luận văn, những điều được trình bày hoặc là của cá nhân hoặc là được tổng hợp từ nhiều nguồn tài liệu Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn đúng quy định

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 2020

Học viên Phạm Thị Hải Yến

Mặc dù đã rất cố gắng trong quá trình thực hiện nhưng luận văn không thể tránh khỏi những thiếu sót, tôi rất mong nhận được sự góp ý của các thầy cô và bạn bè

Học viên Phạm Thị Hải Yến

MỤC LỤC

LỜI CAM ĐOAN 1

LỜI CẢM ƠN 2

MỤC LỤC 3

DANH MỤC HÌNH VẼ 6

DANH MỤC BẢNG BIỂU 8

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VÀ CÁC THUẬT NGỮ 9

LỜI MỞ ĐẦU 10

CHƯƠNG 1: GIỚI THIỆU VỀ KIỂM THỬ PHẦN MỀM 12

1.1 Giới thiệu về kiểm thử phần mềm 12

1.2 Phát triển hướng kiểm thử TDD (Test Driven Development) 13

1.2.1 Khái niệm 13

1.2.2 Các cấp độ TDD 16

1.2.3 Các lỗi thường gặp khi áp dụng TDD 16

1.3 Phát triển hướng hành vi BDD (Behaviour Driven Development) 16

1.3.1 Khái niệm 16

1.3.2 Quy trình phát triển phần mềm truyền thống 18

1.3.3 Quy trình phát triển theo hướng BDD 18

CHƯƠNG 2 GIỚI THIỆU VỀ CÔNG CỤ KIỂM THỬ TỰ ĐỘNG VÀ MÔ HÌNH THIẾT KẾ PAGE OBJECT MODEL (POM) 20

2.1 Công cụ kiểm thử tự động Cucumber 20

2.1.1 Khái niệm 20

2.1.2 Ngôn ngữ Gherkin 20

2.1.3 Cách chạy một Cucumber Junit test 22

2.1.4 Chu trình 23

2.1.5 Sơ đồ chu trình làm việc xử lý các bước trong cucumber 27

2.1.6 Cấu trúc dự án cài đặt Cucumber 28

2.1.7 Các thư viện sử dụng để chạy Cucumber 28

2.2 Selenium WebDriver 29

2.2.1 Khái niệm 29

2.2.2 Giới thiệu về đối tượng UI (Locators) 31

2.2.2.1 Xác định phần tử Web theo ID 31

2.2.2.2 Xác định phần tử Web theo Name 32

2.2.2.3 Xác định phần tử Web theo LinkText 32

2.2.2.4.Xác định phần tử Web theo TagName 33

2.2.2.5 Xác định phần tử Web theo ClassName 33

2.2.2.6 Xác định phần tử Web theo CSS 34

2.2.2.7 Xác định phần tử Web theo Xpath 34

2.2.3 Các thư viện sử dụng để chạy Selenium WebDriver 36

2.2.4 Các hàm xử lý chung trong Selenium WebDriver 36

2.3 Giới thiệu mẫu thiết kế (Design pattern) 38

2.3.1 Khái niệm 38

2.3.2 Phân loại mẫu thiết kế (Design Pattern) 39

2.4 Mô hình thiết kế Page Object Model (POM) 41

2.4.1 Lý do chọn mô hình thiết kế Page Object Model (POM) 41

2.4.2 Mô hình thiết kế Page Object Model (POM) là gì? 43

2.4.3 Ưu điểm của mô hình thiết kế Page Object Model (POM) 43

2.4.4 Ví dụ 44

CHƯƠNG 3: HỆ THỐNG TÍCH HỢP LIÊN TỤC 48

3.1 Hệ thống tích hợp liên tục (CI) 48

3.1.1 Khái niệm 48

3.1.2 Áp dụng hệ thống tích hợp liên tục 50

3.1.3 Lợi ích của việc tích hợp liên tục 50

3.1.4 Jenkins 52

CHƯƠNG 4: THỰC NGHIỆM KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY VIVAS VÀ ĐÁNH GIÁ KẾT QUẢ 54

4.1 Phân tích hoạt động kiểm thử tại công ty trước khi áp dụng kiểm thử tự động 54 4.1.1 Tổng quan về công ty, sản phẩm, môi trường kiểm thử 54

4.1.2 Quy trình kiểm thử trước đây tại VIVAS 55

4.2 Cài đặt và áp dụng kiểm thử tự động vào các dự án của VIVAS 58

4.2.1 Cấu trúc dự án 58

4.2.2 Cấu trúc mã nguồn 60

4.2.3 Tích hợp Jenkins 63

4.2.4 Báo cáo kết quả chạy kiểm thử 65

4.3 Đánh giá kết quả sau khi áp dụng kiểm thử tự động vào dự án của VIVAS 67

4.3.1 Tiết kiệm thời gian 68 4.3.2 Tiết kiệm nguồn nhân lực 70

4.4 Những khó khăn khi triển khai hệ thống kiểm thử tự động trong công ty VIVAS

71

4.5 Hướng phát triển tiếp theo của framework 72 KẾT LUẬN 73 TÀI LIỆU THAM KHẢO 74

DANH MỤC HÌNH VẼ

Hình 1.1 Chu trình TDD qua màu sắc (từ trang 1minus1.com) 14

Hình 1.2 Các bước thực hiện TDD Từ trang http://agiledata.org/essays/tdd.html) 15

Hình 1.3 TDD kết hợp với BDD 17

Hình 1.4 Chu trình làm việc kết hợp TDD và BDD 17

Hình 1.5 Quy trình phát triển truyền thống 18

Hình 1.6 Quy trình phát triển BDD 19

Hình 2.1 Mã nguồn viết bằng ngôn ngữ Gherkin 21

Hình 2.2 Mã nguồn viết bằng ngôn ngữ Gherkin 21

Hình 2.3 Mã nguồn để chạy Cucumber 22

Hình 2.4 Chương trình chạy kiểm thử với Cucumber 23

Hình 2.5 Mã nguồn viết bằng ngôn ngữ Gherkin 24

Hình 2.6 Mã nguồn thực thi các bước trong kịch bản kiểm thử 24

Hình 2.7 Kết quả chạy kịch bản kiểm thử và log khi có trường hợp sai 25

Hình 2.8 Mã nguồn thực thi các bước trong kịch bản kiểm thử 25

Hình 2.9 Kết quả chạy các kịch bản kiểm thử đã đúng 26

Hình 2.10 Chu trình làm việc trong Cucumber 27

Hình 2.11 Cấu trúc dự án cài đặt Cucumber 28

Hình 2.12 Thư viện Cucumber cần cài đặt 28

Hình 2.13 Sử dụng Maven để cài đặt các thư viện 29

Hình 2.14 Các hệ điều hành phổ biến 30

Hình 2.15 7 cách xác định phần tử Web 31

Hình 2.16 Xác định phần tử Web bằng ID 32

Hình 2.17 Xác định phần tử Web bằng Name 32

Hình 2.18 Xác định phần tử Web bằng Linktext 33

Hình 2.19 Xác định phần tử Web bằng Tagname 33

Hình 2.20 Xác định phần tử Web bằng Classname 33

Hình 2.21 Xác định phần tử Web bằng CSS 34

Hình 2.22 Ví dụ minh họa cách xác định phần tử 34

Hình 2.23 Thư viện cần thiết để chạy Selenium WebDriver 36

Hình 2.24 Sử dụng Maven để cài đặt các thư viện 36

Hình 2.25 Mã nguồn minh họa cho Selenium Webdriver 38

Hình 2.26 Mã nguồn ví dụ cho việc chỉ sử dụng Selenium Webdriver 42

Hình 2.27 Cấu trúc POM 43

Hình 2.28 Cấu trúc Page Object Model 44

Hình 2.29 Mã nguồn trang Đăng nhập 45

Hình 2.30 Mã nguồn trong PageObjects và PageUIs của trang Đăng nhập 46

Hình 2.31 Mã nguồn chạy nhiều trình duyệt 47

Hình 3.1 Vòng đời CI cơ bản 48

Hình 3.2 Quá trình tích hợp liên tục CI 49

Hình 3.3 Hệ thống tích hợp liên tục 49

Hình 3.4 10 hệ thống CI sử dụng với GitHub 52

Hình 3.5 Giao diện Jenkins 53

Hình 4.1 Quy trình kiểm thử trước đây tại VIVAS 56

Hình 4.2 Cấu trúc dự án thực tế 58

Hình 4.3 Quản lý mã nguồn bằng Github 59

Hình 4.4 Cấu trúc mã nguồn cài đặt thực tế 60

Hình 4.5 Cấu hình thông số cho Jenkins 64

Hình 4.6 Báo cáo kết quả kiểm thử trên Jenkins 65

Hình 4.7 Biểu đồ kết quả kiểm thử trên Jenkins 65

Hình 4.8 Biểu đồ kết quả kiểm thử trên Jenkins 66

Hình 4.9 Báo cáo kết quả kiểm thử trên Extent reports 66

Hình 4.10 Báo cáo kết quả kiểm thử trên TestNG report 67

Hình 4.11 Biểu đồ thống kê tỷ lệ thực hiện được kiểm thử tự động 68

Hình 4.12 Biểu đồ so sánh thời gian thực thi giữa kiểm thử thủ công và tự động trên một trình duyệt 69

Hình 4.13 Biểu đồ so sánh thời gian thực thi giữa kiểm thử thủ công và tự động trên ba trình duyệt 70

Hình 4.14 Bảng so sánh nguồn lực thực hiện kiểm thử thủ công và tự động 71

DANH MỤC BẢNG BIỂU

Bảng 2.1 Bảng chú thích lệnh trong thư mục chạy Cucumber 23

Bảng 2.2 Bảng so sánh Selenium WebDriver và các công cụ khác 30

Bảng 2.3 Bảng phân loại Xpath 35

Bảng 2.4 Một số cú pháp trong Xpath 35

Bảng 2.5 Xác định phần tử sử dụng Webdriver 37

Bảng 2.6 Các hàm hay sử dụng trong Selenium Webdriver 37

Bảng 2.7 5 mẫu thiết kế trong mẫu thiết kế kiến tạo 39

Bảng 2.8 Những mẫu thiết kế thuộc nhóm mẫu thiết kế kiến trúc 39

Bảng 2.9 Những mẫu thiết kế thuộc nhóm mẫu thiết kế hành vi 40

Bảng 4.1 Bảng thống kê số kịch bản kiểm thử của một vài dịch vụ tại Vivas 57

Bảng 4.2 Bảng thống kế số kịch bản kiểm thử đã áp dụng thực tế kiểm thử tự động 67

Bảng 4.3 Bảng thống kê thời gian thực thi của kiểm thử thủ công và tự động 68

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VÀ CÁC THUẬT NGỮ

2 Business Analyst Nhân viên phân tích nghiệp vụ BA

6 Maintenance Bảo hành, bảo trì

10 Regression Test Kiểm thử hồi quy

11 Software Testing Kiểm thử phần mềm

13 Test Driven Development Phát triển hướng kiểm thử TDD

LỜI MỞ ĐẦU

Trong nhiều năm qua, tự động hóa được ứng dụng ở rất nhiều lĩnh vực nhằm giảm thời gian, nhân lực và sai sót Ngành công nghệ thông tin mà cụ thể là phát triển phần mềm cũng không ngoại lệ Một sản phẩm công nghệ thông tin hay phần mềm có chất lượng không thể thiếu hoạt động kiểm thử phần mềm, trong khi đó hoạt động này lại tiêu tốn và chiếm tỷ trọng khá lớn công sức và thời gian trong một dự án Do vậy, nhu cầu tự động hoá kiểm thử phần mềm cũng được đặt ra Việc áp dụng kiểm thử tự động hợp lý sẽ mang lại thành công cho hoạt động kiểm thử phần mềm cũng như nâng cao chất lượng của sản phẩm phần mềm Kiểm thử tự động giúp giảm bớt công sức thực hiện, tăng độ tin cậy và rèn luyện kỹ năng lập trình cho kiểm thử viên

Selenium là bộ kiểm thử tự động miễn phí (mã nguồn mở) dành cho các ứng dụng web trên các trình duyệt và nền tảng khác nhau Với selenium cùng một số công cụ hỗ trợ khác như Cucumber, Jenkins, Maven,… kiểm thử viên có thể phát triển thành các framework hỗ trợ cho viết các kịch bản kiểm thử và chạy các kịch bản này một cách tự động, giảm nguồn lực, tăng độ tin cậy và nhàm chán của công việc kiểm thử

Ngoài ra, hiện nay, nhu cầu kiểm thử tự động khá cao nhưng nhân lực trong ngành này không nhiều, đặc biệt là ở Hà Nội Các công ty muốn áp dụng kiểm thử tự động trong quá trình phát triển dự án nhưng việc hiểu biết về kiểm thử tự động khá là mơ hồ và chưa xây dựng được một framework chuẩn áp dụng cho dự án tại công ty mình

Dựa vào những lý do trên cùng với những kinh nghiệm 4 năm tôi có được trong lĩnh vực kiểm thử Tôi muốn xây dựng một framework kiểm thử tự động hỗ trợ các kiểm thử viên Đó là lý do tôi chọn đề tài “Xây dựng ứng dụng kiểm thử phần mềm tự động sử dụng selenium và webdriver”

Đề tài tìm hiểu cơ sở lý thuyết và kinh nghiệm thực tế về kiểm thử cũng như xây dựng ứng dụng kiểm thử phần mềm tự động để giảm nhân lực kiểm thử và đảm bảo chất lượng phần mềm hơn với công việc kiểm thử bằng tay

Mục tiêu chính của đề tài bao gồm:

✓ Đưa ra những khái niệm cơ bản về quy trình phát triển hiện nay cũng như việc áp dụng kiểm thử tự động trong quy trình phát triển phần mềm (TDD, BDD)

✓ Đưa ra những khái niệm cơ bản về các công cụ cần thiết như: Cucumber, Selenium, Jenkins

✓ Đưa ra một framework nhỏ (kết hợp Cucumber và Selenium) và cách chạy các kịch bản kiểm thử này bằng Jenkins

Ngoài phần mở đầu, kết luận và phụ lục phần còn lại của luận văn được chia làm

4 chương, cụ thể như sau:

✓ Chương 1 giới thiệu về kiểm thử phần mềm

✓ Chương 2 giới thiệu về công cụ kiểm thử tự động và các loại mô hình thiết

kế và phân tích lý do chọn cũng như ưu nhược điểm của mô hình Page Object Model (POM)

✓ Chương 3 giới thiệu về hệ thống tích hợp liên tục và giới thiệu công cụ Jenkins được sử dụng trong dự án thí điểm

✓ Chương 4 giới thiệu về công ty VIVAS và đánh giá hiệu quả của kiểm thử

tự động khi áp dụng vào dự án của công ty VIVAS

CHƯƠNG 1: GIỚI THIỆU VỀ KIỂM THỬ PHẦN MỀM

Một nghiên cứu được tiến hành bởi NIST trong những năm gần đây cho biết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ một con số đáng kể, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn Người

ta thường tin rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó

sẽ rẻ hơn Do vậy kiểm thử phần mềm là hoạt động vô cùng quan trọng trong chu trình phát triển phần mềm ở các công ty công nghệ hiện nay

1.1 Giới thiệu về kiểm thử phần mềm

Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi Kiểm thử phần mềm đảm bảo phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá

và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm [1]

Các mục tiêu chính của kiểm thử phần mềm:

✓ Trong thời gian xác định trước, kiểm thử viên tìm được càng nhiều lỗi càng tốt

✓ Đảm bảo rằng phần mềm cuối cùng phù hợp với các yêu cầu đặc tả của nó

✓ Đo lường chất lượng của sản phẩm và dự án

✓ Viết kịch bản kiểm thử (testcase) chất lượng cao, thực hiện kiểm thử hiệu quả

và đưa ra các báo cáo chính xác

Kiểm thử tự động là thực hiện kiểm thử phần mềm 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 kiểm thử viên không phải lặp

đi lặp lại các bước nhàm chán Trong kiểm thử tự động, có các Testscript được viết sẵn

và chạy tự động để so sánh kết quả thực tế với kết quả mong đợi Kiểm thử tự động hoạt động rất hiệu quả khi cần thực hiện các kiểm tra lặp lại và hồi quy để đảm bảo rằng một ứng dụng hoạt động chính xác sau khi có thay đổi mới Các TestScript chạy với sự trợ giúp của các công cụ, tập lệnh và phần mềm để thực hiện các hành động được xác định trước được viết trong kịch bản kiểm thử

Trong một số dự án, kiểm thử phần mềm chiếm khoảng trên 50% tổng giá phát triển phần mềm Do đó một trong các mục tiêu của kiểm thử là tự động hóa kiểm thử, nhờ

đó mà giảm thiểu chi phí rất nhiều, tối thiểu hóa các lỗi do người gây ra, đặc biệt giúp việc kiểm thử hồi qui dễ dàng và nhanh chóng hơn

Ưu điểm của kiểm thử tự động

a Tính hiệu quả trong công việc: Ưu điểm lớn nhất của kiểm thử tự động là thay thế con người lặp đi lặp lại đúng quy tắc các bước kiểm thử nhàm chán, tránh được hao phí về mặt thời gian

b Độ tin cậy: Dù lặp đi lặp lại nhiều lần vẫn cho ra kết quả giống nhau do vậy độ ổn định cao, tránh được rủi ro có thể phát sinh

c Cải thiện chất lượng: Kiểm thử tự động làm giảm rủi ro về mặt chất lượng sản phẩm, việc kiểm thử được thực hiện một cách nhanh chóng Có thể tái sử dụng các trường hợp kiểm thử

d Tốc độ xử lý cực nhanh: Nếu mất 5 phút để kiểm thử thủ công thì chỉ cần mất 30s nếu sử dụng kiểm thử tự động

e Chi phí thấp: Việc rút ngắn thời gian và tiết kiệm nhân lực giúp cho việc kiểm thử

tự động trở nên hiệu quả

Nhược điểm của kiểm thử tự động

a Ban đầu thì chi phí cho kiểm thử tự động sẽ cao hơn kiểm thử thủ công

b Để kiểm thử tự động thực hiện được thì vẫn cần con người phải bỏ thời gian, công sức và tiền bạc,

c Mất chi phí cho các công cụ tự động hóa như bản quyền, bảo trì, tìm hiểu, training

d Khó mở rộng hơn nhiều so với kiểm thử thủ công

e Yêu cầu những người có trình độ chuyên môn cao mới thực hiện được

f Số lượng công việc phải làm để mở rộng cho kiểm thử tự động sẽ nhiều và khó hơn so với kiểm thử thủ công

1.2 Phát triển hướng kiểm thử TDD (Test Driven Development)

1.2.1 Khái niệm

Phát triển hướng kiểm thử TDD (Test Driven Development) là một phương thức làm việc, hay một quy trình viết mã hiện đại Lập trình viên sẽ thực hiện thông qua các bước nhỏ và tiến độ được đảm bảo liên tục bằng cách viết và chạy các bài kiểm thử tự động Quá trình lập trình trong TDD cực kỳ chú trọng vào các bước liên tục sau:

a Viết 1 kịch bản kiểm thử cho hàm mới Đảm bảo rằng kiểm thử sẽ bị sai

b Chuyển qua lập trình sơ khai nhất cho hàm đó để kiểm thử có thể đúng

c Tối ưu hóa đoạn mã nguồn của hàm vừa viết sao cho đảm bảo kiểm thử vẫn đúng

và tối ưu nhất cho việc lập trình kế tiếp

d Lặp lại cho các hàm khác từ bước 1 Thực tế, nên sử dụng UnitTestFramework cho TDD (như JUnit trong Java), chúng ta có thể có được môi trường hiệu quả vì các kiểm thử được thông báo rõ ràng thông qua màu sắc:

• Đỏ: kiểm thử sai, chuyển sang viết chức năng cho kiểm thử đúng

• Xanh lá: viết một kiểm thử mới hoặc tối ưu mã nguồn đã viết trong màu đỏ Phát triển hướng kiểm thử TDD (Test-Driven Development) là kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại

mã nguồn (Refactoring)

Mục tiêu quan trọng nhất của TDD là nghĩ về thiết kế trước khi viết mã nguồn cho chức năng Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được

Hình 1.1 Chu trình TDD qua màu sắc (từ trang 1minus1.com)

Ba điều luật khi áp dụng TDD

• Không cho phép viết bất kỳ một mã chương trình nào cho tới khi nó làm một kiểm thử bị sai trở nên đúng

• Không cho phép viết nhiều hơn một kiểm thử đơn vị mà nếu chỉ cần 1 kiểm thử đơn vị cũng đã đủ để sai Hãy chuyển sang lập trình chức năng để làm đúng kiểm thử đó trước

• Không cho phép viết nhiều hơn 1 mã chương trình mà nó đã đủ làm một kiểm thử

bị sai chuyển sang đúng

Các bước thực hiện trong chu trình TDD

Hình 1.2 Các bước thực hiện TDD Từ trang http://agiledata.org/essays/tdd.html)

1.2.2 Các cấp độ TDD

Mức chấp nhận (Acceptance TDD (ATDD)): với ATDD thì bạn viết một kiểm thử chấp nhận đơn hoặc một đặc tả hành vi (behavioral specification) tùy theo cách gọi của bạn; mà kiểm thử đó chỉ cần đủ cho các mã chương trình sản phẩm thực hiện (đúng hoặc sai) được kiểm thử đó Mức chấp nhận (Acceptance TDD) còn được gọi là Behavior Driven Development (BDD)

Mức lập trình (Lập trình viên TDD): với mức này bạn cần viết một kiểm thử lập trình đơn (single lập trình viên test) đôi khi được gọi là kiểm thử đơn vị mà kiểm thử đó chỉ cần đủ cho các mã chương trình sản phẩm thực hiện (đúng hoặc sai) được kiểm thử

đó Mức lập trình (Lập trình viên TDD) thông thường được gọi là TDD.Vậy nên, thực chất BDD là 1 loại TDD, và người ta thường gọi Lập trình viên TDD là TDD

1.2.3 Các lỗi thường gặp khi áp dụng TDD

● Không quan tâm đến các kịch bản kiểm thử bị sai

● Quên đi thao tác tối ưu sau khi viết mã nguồn cho kịch bản kiểm thử đúng

● Thực hiện tối ưu mã nguồn trong lúc viết mã nguồn cho kiểm thử đúng

● Đặt tên các kịch bản kiểm thử khó hiểu và tối nghĩa

● Không bắt đầu từ các kiểm thử đơn giản nhất và không theo các bước nhỏ

● Chỉ chạy mỗi kịch bản kiểm thử đang bị sai hiện tại

● Viết một kịch bản kiểm thử với kịch bản quá phức tạp

1.3 Phát triển hướng hành vi BDD (Behaviour Driven Development)

1.3.1 Khái niệm

Phát triển hướng hành vi Behaviour Driven Development (BDD) là một quá trình phát triển phần mềm có nguồn gốc từ Test Driven Development (TDD) BDD sử dụng các ví dụ để minh họa hành vi của hệ thống được viết bằng ngôn ngữ dễ đọc và dễ hiểu đối với tất cả mọi người tham gia vào quá trình phát triển

Thay vì chờ đợi sản phẩm hoàn thành và kiểm thử, đội ngũ phát triển tham gia vào quá trình xây dựng mã nguồn với vai trò phân tích và xây dựng hệ thống kịch bản kiểm thử dưới góc độ ngôn ngữ tự nhiên dễ hiểu từ các yêu cầu (requirement) Đồng thời, họ giúp đỡ lập trình viên trong việc giải thích và đưa ra các phương án xây dựng mã nguồn mang tính thực tiễn với người dùng ngay trước khi bắt tay xây dựng Người lập trình viên liên hệ mật thiết với người kiểm thử viên và xây dựng mã nguồn với những phương án

mà kiểm thử viên cung cấp theo mô hình TDD

Hình 1.3 TDD kết hợp với BDD

Hình 1.4 Chu trình làm việc kết hợp TDD và BDD

(Từ trang http://agiledata.org/essays/tdd.html)

1.3.2 Quy trình phát triển phần mềm truyền thống

Hình 1.5 Quy trình phát triển truyền thống

(Từ trang http://agiledata.org/essays/tdd.html) (Từ trang BDD in action (Behavior-Driven Development for the whole software lifecycle) - John Ferguson Smart (Foreword by Dan North))

Trong quy trình phát triển truyền thống, việc phân tích các yêu cầu (requirements) thường được tiến hành bởi chuyên viên phân tích nghiệp vụ (BA) một cách chuyên hóa

và khi đến giai đoạn xây dựng (implementing phase) thì đa phần các lập trình viên tiếp xúc với các yêu cầu phần mềm dưới dạng các bản thiết kế Họ chỉ quan tâm đến đầu vào, đầu ra (Input, Output) của tính năng mình xây dựng mà thiếu đi cái nhìn thực tiễn từ góc nhìn người dùng (end-users) Một hệ quả tất yếu là lỗi phần mềm đến từ việc sản phẩm

ko tiện dụng với người dùng

1.3.3 Quy trình phát triển theo hướng BDD

Hình 1.6 Quy trình phát triển BDD

(Từ trang http://agiledata.org/essays/tdd.html) (Từ trang BDD in action (Behavior-Driven Development for the whole software lifecycle) - John Ferguson Smart (Foreword by Dan North))

Việc ứng dụng BDD góp phần làm gần khoảng cách giữa đội ngũ thiết kế phần mềm và sản phẩm thực tiễn, tối ưu quy trình Cụ thể như sau:

✓ Thông qua kịch bản kiểm thử, lập trình viên có cái nhìn trực quan về sản phẩm ngay trước khi xây dựng mã nguồn Sản phẩm họ tạo ra chính xác và gần gũi người dùng hơn

✓ Phần mã nguồn được thêm vào chỉ vừa đủ để chạy thành công kịch bản kiểm thử, hạn chế dư thừa và qua đó hạn chế khả năng xảy ra lỗi trên những phần

CHƯƠNG 2 GIỚI THIỆU VỀ CÔNG CỤ KIỂM THỬ TỰ ĐỘNG VÀ MÔ

HÌNH THIẾT KẾ PAGE OBJECT MODEL (POM)

Sự thành công trong kiểm thử tự động phụ thuộc vào việc xác định đúng công cụ kiểm thử cho dự án Có rất nhiều công cụ kiểm thử tự động với mã nguồn mở để lựa chọn, chính vì vậy việc lựa chọn công cụ nào khá là khó khăn Việc lựa chọn công cụ kiểm thử trong luận văn này dựa trên số lượng công ty công nghệ đang sử dụng công cụ này và dựa vào tài nguyên sẵn có của công ty làm thực nghiệm Sau đây là những công cụ đã sử dụng trong luận văn

2.1 Công cụ kiểm thử tự động Cucumber

2.1.1 Khái niệm

Cucumber là công cụ kiểm thử tự động dựa trên việc thực thi các chức năng được

mô tả dướng dạng văn bản thuần túy, hỗ trợ Behavior Driven Development (BDD), cho phép người dùng định nghĩa hành vi hệ thống với ngữ nghĩa tiếng anh thông qua cú pháp Gherkin Cucumber hướng tới việc viết kịch bản kiểm thử mà bất kỳ ai cũng có thể hiểu cho dù họ không có chuyên môn kĩ thuật Ví dụ như các nền tảng quen thuộc như Selenium thì thường chỉ người viết kiểm thử hoặc có kĩ năng lập trình mới hiểu được những gì đang kiểm thử, còn khách hàng hoặc các bên liên quan thì không đọc ngay mã nguồn để hiểu mà họ cần hiểu qua tài liệu

Cucumber ban đầu được thực hiện dành riêng cho ngôn ngữ Ruby và sau đó được

mở rộng sang Java, cả Ruby và Java đều sử dụng Junit để chạy test

2.1.2 Ngôn ngữ Gherkin

✓ Cucumber thực thi các feature file Các thư mục feature chứa các đặc tả (step) thực thi, các đặc tả này được viết bằng ngôn ngữ Gherkin Kịch bản kiểm thử đơn vị sẽ được viết trước và thể hiện nghiệp vụ, sau đó Mã nguồn mới được cài đặt để đúng qua tất cả các kịch bản đó

✓ Gherkin là một ngôn ngữ mà Cucumber đọc ngôn ngữ ấy chuyển thành kịch bản kiểm thử Gherkin khá đơn giản, người đọc có thể hiểu kịch bản và hành động

mà không cần biết chi tiết chúng được cài đặt như thế nào Một feature có thể

có nhiều scenario

✓ Có hai quy tắc khi viết Gherkin:

➢ Một thư mục Gherkin chỉ mô tả cho một tính năng

➢ Thư mục mã nguồn Gherkin là feature

Ví dụ 1:

Hình 2.1 Mã nguồn viết bằng ngôn ngữ Gherkin

Ví dụ 2:

Hình 2.2 Mã nguồn viết bằng ngôn ngữ Gherkin

✓ Trong Gherkin, mỗi dòng sẽ bắt đầu bằng từ khóa Gherkin Dưới đây là các từ khóa trong gherkin

➢ Feature: Tất cả các file "*.feature" được quy ước chỉ bao gồm một tính năng Một tính năng thường gồm một danh sách các “Scenario” Có thể viết bất cứ gì cho đến khi bắt đầu “Scenario” đầu tiên (khi dòng mới bắt đầu bằng từ “Scenario:”) Thêm vào đó, tính năng có thể bao gồm “scenario outline” và “background”

➢ Scenario: Scenario là nòng cốt trong cấu trúc Gherkin Mọi Scenario đều bắt đầu với từ khóa “Scenario:” theo sau bởi một tiêu đề tùy ý Mỗi tính năng có thể có một hoặc nhiều Scenario, và mỗi Scenario bao gồm một hay nhiều bước

➢ Given: Được sử dụng để mô tả ngữ cảnh ban đầu của hệ thống Mục đích của Given là đưa hệ thống vào một trạng thái đã biết trước khi sử dụng

(hoặc hệ thống bên ngoài) bắt đầu tương tác với hệ thống (trong bước When) Givens là điều kiện tiên quyết Khi Cucumber thực thi bước Given,

nó sẽ cấu hình hệ thống để được một trạng thái rõ ràng như là: tạo, cấu hình các đối tượng hoặc thêm dữ liệu kiểm thử vào cơ sở dữ liệu

➢ When: Mục đích của When là để mô tả các sự kiện, hành động chính mà người dùng sử dụng

➢ Then: Việc sử dụng từ khóa 'then' là để xem kết quả sau hành động trong bước when Tuy nhiên, bạn chỉ có thể xác minh những thay đổi đáng chú ý

➢ And, But: Dùng để thể hiện có nhiều given when hoặc Then

➢ Background: Từ khóa Background giúp bạn thêm một số bối cảnh vào kịch bản Nó có thể chứa một số bước của kịch bản, nhưng sự khác biệt duy nhất

là nó nên được chạy trước mỗi kịch bản

➢ Scenario Outline: Sử dụng giống với Scenario nhưng bắt buộc phải đi cùng với Data Tables

➢ Examples: Phần ví dụ minh họa

➢ | (Data Tables): Bảng dữ liệu sẽ chạy cho Scenario Outline

➢ @ (Tags): Có thể sử dụng tags để nhóm các feature và scenario lại với nhau, không lệ thuộc vào file và cấu trúc thư mục

➢ # (Comments): Bắt đầu dòng bằng dấu # cho biết dòng đó là dòng comment

và không được thực thi

2.1.3 Cách chạy một Cucumber Junit test

Hình 2.3 Mã nguồn để chạy Cucumber

Bảng 2.1 Bảng chú thích lệnh trong thư mục chạy Cucumber

✓ @RunWith: Khai báo TestRunner, thường là Cucumber Các kịch bản kiểm thử

sẽ không chạy được nếu thiếu cái này

✓ @CucumberOptions: Định nghĩa các lựa chọn cho việc chạy kiểm thử

➢ features: Đường dẫn đến các thư mục feature

➢ glue: Định nghĩa packages khai báo Steps trong Cucumber

➢ monochrome: Dùng để hiển thị đầu ra dễ đọc hơn

➢ dryRun: Dùng để kiểm tra tất cả các bước đã có trong Step Definition hay chưa

➢ plugin: Để xem báo cáo dạng pretty, xem báo cáo mặc định của cucumber

và xem các báo cáo ngoài của maven

➢ snippets: Quy định tên hàm ở bên CucumberOption

➢ tag: Định nghĩa các scenrio nào sẽ được chạy

2.1.4 Chu trình

Hình 2.4 Chương trình chạy kiểm thử với Cucumber

✓ Mô tả lại hành vi dưới dạng văn bản thuần túy (sử dụng ngôn ngữ Gherhin)

Hình 2.5 Mã nguồn viết bằng ngôn ngữ Gherkin

✓ Định nghĩa các bước

➢ Mỗi một bước (step) trong từ khóa gherhin sẽ có một annotation tương ứng

➢ Cucumber sử dụng các biểu thức định nghĩa ra các bước (^, $, \\d,

\"([^\"]*)\" …)

Hình 2.6 Mã nguồn thực thi các bước trong kịch bản kiểm thử

✓ Chạy kịch bản kiểm thử và xem các bước kiểm thử sai

Hình 2.7 Kết quả chạy kịch bản kiểm thử và log khi có trường hợp sai

✓ Lập trình làm cho các bước được kiểm thử đúng

Hình 2.8 Mã nguồn thực thi các bước trong kịch bản kiểm thử

✓ Chạy lại kịch bản kiểm thử và xem những kịch bản đúng

✓ Lặp lại các bước đến khi toàn bộ các kịch bản kiểm thử đúng

Hình 2.9 Kết quả chạy các kịch bản kiểm thử đã đúng

2.1.5 Sơ đồ chu trình làm việc xử lý các bước trong cucumber

Hình 2.10 Chu trình làm việc trong Cucumber

2.1.6 Cấu trúc dự án cài đặt Cucumber

Hình 2.11 Cấu trúc dự án cài đặt Cucumber

2.1.7 Các thư viện sử dụng để chạy Cucumber

✓ Danh sách các thư viện Cucumber cần cài đặt

Hình 2.12 Thư viện Cucumber cần cài đặt

Sử dụng Maven để cài đặt các thư viện trên

Hình 2.13 Sử dụng Maven để cài đặt các thư viện

2.2 Selenium WebDriver

Công cụ kiểm thử tự động Cucumber chỉ hỗ trợ cho kiểm thử viên và lập trình viên

mô tả các hành vi của người dùng dưới dạng ngôn ngữ tự nhiên Ngôn ngữ tự nhiên này giúp toàn thành viên trong đội phát triển cũng như khách hàng có cái nhìn chung về hệ thống mà không cung cấp thư viện để thao tác với các thành phần trên giao diện Web Vậy làm thế nào để có thể thao tác được với các thành phần trên Web để tái hiện lại các hành vi của người dùng được mô tả bởi Cucumber Selenium WebDriver sẽ làm được điều đó Đây là công cụ mã nguồn mở, hoàn toàn miễn phí và cung cấp đầy đủ các thư viện thao tác trên ứng dụng Web Framework kiểm thử tự động được xây dựng dưới đây

có thể thiếu Cucumber nhưng nhất định không thể thiếu Selenium WebDriver Do đó, có thể nói Selenium WebDriver là thành phần cốt lõi chính của framework

thể sử dụng các điều kiện if else, các vòng lặp để tăng tính chính xác cho kịch bản kiểm thử

✓ Hỗ trợ kiểm thử trên nhiều trình duyệt khác nhau (Firefox, Chrome, Internet Explorer, Opera, Safari)

✓ Hỗ trợ chạy kiểm thử trên nhiều hệ điều hành khác nhau (Ubuntu, Windows, IOS …)

Hình 2.14 Các hệ điều hành phổ biến

So sánh giữa Selenium WebDriver và các công cụ kiểm thử tự động khác

Bảng 2.2 Bảng so sánh Selenium WebDriver và các công cụ khác

Trên thị trường có khá nhiều công cụ kiểm thử Web khác nhau như Quicktest professional (QTP), công cụ của IBM Tuy nhiên, các công cụ đó không miễn phí và có những tính năng hỗ trợ ít hơn so với Selenium Dựa vào bảng so sánh trên, ta có thể thấy Selenium là công cụ tuyệt vời để sử dụng

2.2.2 Giới thiệu về đối tượng UI (Locators)

Trong selenium, các phần tử trên web (WebPhần tử) có vai trò rất quan trọng Selenium hỗ trợ người dùng 7 cách để xác định các phần tử web này (Locator)

Hình 2.16 Xác định phần tử Web bằng ID

2.2.2.2 Xác định phần tử Web theo Name

Name là lựa chọn thứ hai sau ID Tuy nhiên, thuộc tính Name đôi khi không đơn nhất Không có một ràng buộc nào bắt Name phải đơn nhất Đối với ID, cũng sẽ không

có lỗi systax nào xảy ra nếu nhà phát triển đặt hai đối tượng UI cùng ID, nhưng nó là một lỗi về ý nghĩa Nếu làm kiểm thử đơn vị, bạn có thể bắt lỗi này

Hình 2.17 Xác định phần tử Web bằng Name

2.2.2.3 Xác định phần tử Web theo LinkText

Link Text - một lựa chọn không tồi nếu bạn không phải kiểm định trên hệ thống với nhiều ngôn ngữ khác nhau Thuộc tính Link Text là không đơn nhất và cũng không

ổn định Một trang web có thể có nhiều liên kết đến một trang khác hay thay đổi từ ngữ nhưng không đổi ý nghĩa Ví dụ: nút “Login” của chúng ta bị chuyển thành “Đăng nhập”

2.2.2.6 Xác định phần tử Web theo CSS

Hình 2.21 Xác định phần tử Web bằng CSS

2.2.2.7 Xác định phần tử Web theo Xpath

✓ Xpath là việc sử dụng những biểu thức để duyệt các node trong XML/HTML

✓ XPath là phương thức được sử dụng nhiều nhất

✓ Dưới đây là ví dụ cấu trúc HTML của một trang web và cách dùng Xpath để duyệt các phần tử trên trang web đó

Hình 2.22 Ví dụ minh họa cách xác định phần tử

✓ XPath tuyệt đối (Absolute Xpath)

➢ Bắt đầu với node gốc hoặc dấu “/”

➢ Ưu điểm: tìm phần tử nhanh

➢ Nhược điểm: nếu có sự thay đổi nào giữa các node là xpath sẽ sai

➢ Ví dụ: html/body/div/form/select/option

➢ Khi có thêm một tag giữa body và div là xpath sẽ không tìm được phần tử html/body/table/div/form/select/option

✓ XPath tương đối (Relative Xpath)

➢ Có thể bắt đầu ở bất kỳ node nào với dấu “//”

➢ Ưu điểm: xpath ngắn

➢ Nhược điểm: tìm phần thử lâu hơn xpath tuyệt đối

➢ Ví dụ: //select/option

✓ Kết hợp giữa xpath tuyệt đối, tương đối

➢ Có thể kết hợp giữa xpath tuyệt đối và tương đối

➢ Ví dụ: html//table/tbody/tr/th

Bảng 2.3 Bảng phân loại Xpath

Xpath tuyệt đối html/body/div/form/select/option

contains Lấy phần tử với thuộc

tính chứa chuỗi bất kỳ

//tagName[contains(@attribute,’value’)]

//input[contains(@id,

‘searchInput’)]

starts-with Lấy phần tử với thuộc

tính bắt đầu bằng chuỗi bất kỳ

with(@attribute,’value’)]

//tagName[starts-//input[starts- with(@id, ‘s’)]

and Kết hợp toán tử AND

với nhiều điều kiện để lấy phần tử

//tagName[@attribute=’value’ and @attribute=’value’]

//input[@type=’search

@id=’searchInput’]

’| @type=’submit’] position() Lấy phần tử theo

vị trí

//tagName[index] //option[1]

2.2.3 Các thư viện sử dụng để chạy Selenium WebDriver

✓ Danh sách các thư viện Selenium WebDriver cần cài đặt

Hình 2.23 Thư viện cần thiết để chạy Selenium WebDriver

✓ Sử dụng Maven để cài đặt các thư viện trên

Hình 2.24 Sử dụng Maven để cài đặt các thư viện

2.2.4 Các hàm xử lý chung trong Selenium WebDriver

✓ Xác định phần tử web sử dụng WebDriver