Luận án Thạc sĩ Công nghệ thông tin: Xây dựng ứng dụng kiểm thử phần mềm tự động sử dụng selenium và webdriver

ĐẠ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

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: Khoa học máy tính
Chuyên ngành: Khoa học máy tính
Mã số: 08480101.01

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

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

HÀ NỘI - 2020

1
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 hồn tồ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


2
LỜI CẢM ƠN
Để hồn thành luận văn này tơi xin chân thành gửi lời cảm ơn đến PGS. TS. Hoàng
Xuân Huấn cùng các thầy cô trong khoa Công nghệ thông tin – Đại học Quốc Gia Hà Nội
đã đóng góp ý kiến, nhận xét, quan tâm chỉ bảo và tạo cho tôi những điều kiện tốt nhất từ
khi bắt đầu cho tới khi hồn thành luận văn của mình.
Đồng thời, tơi cũng xin gửi lời cảm ơn đến gia đình, bạn bè và đồng nghiệp đã
luôn quan tâm, chia sẻ, động viên và tạo mọi điều kiện để tơi có thể hồn thành tốt mọi
cơng việc trong q trình thực hiện luận vă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


3

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


4
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 .......................................................................................... 64
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


5
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


6
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 ....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


7
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. Q 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 ......................................................................65
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


8
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


9
DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VÀ CÁC THUẬT NGỮ
STT
Tiếng Anh
1
Automation Test
2
Business Analyst
3
Behavior Driven
Development
4
Continuous Integration
5
Developer
6
Maintenance
7

Manual Test
8
Page Object Model
9
Refactor
10 Regression Test
11 Software Testing
12 Test case
13 Test Driven Development
14 Tester
15 Test script

Tiếng Việt
Kiểm thử tự động
Nhân viên phân tích nghiệp vụ
Phát triển hướng hành vi

Viết tắt
AT
BA
BDD

Tích hợp liên tục
Lập trình viên
Bảo hành, bảo trì
Kiểm thử thủ cơng
Mơ hình Page Object
Tái cấu trúc
Kiểm thử hồi quy
Kiểm thử phần mềm

Trường hợp kiểm thử
Phát triển hướng kiểm thử
Kiểm thử viên
Kịch bản kiểm thử

CI

POM

TDD


10
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ử.
Ngồ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


11
 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.

12
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à q 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.


13
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. u cầu những người có trình độ chun 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.


14

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


15

Hình 1.2. Các bước thực hiện TDD Từ trang />

16
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

1.3.

●

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

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 q trình phát triển
Thay vì chờ đợi sản phẩm hồn thành và kiểm thử, đội ngũ phát triển tham gia vào
q 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.


17

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 />

18

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 />(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


19
Hình 1.6. Quy trình phát triển BDD
(Từ trang />(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
dư thừa.
 Bảo đảm mã nguồn luôn phản ánh đúng và vừa đủ yêu cầu phầm mềm, hạn
chế được công sức tối ưu mã nguồn về sau.
Sau khi giới thiệu tổng quan về kiểm thử tự động cũng như ưu nhược điểm của

kiểm thử tự động. Phần tiếp theo sẽ giới thiệu chi tiết những công cụ kiểm thử tự động
mà luận văn đã sử dụng.


20
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 ngun 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ó chun 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


21
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


22












(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


23
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