Nghiên cứu và ứng dụng công cụ kiểm thử tự động selenium trong kiểm thử phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN

ĐẶNG THỊ PHƢƠNG

NGHIÊN CỨU VÀ ỨNG DỤNG CÔNG CỤ KIỂM THỬ TỰ
ĐỘNG SELENIUM TRONG KIỂM THỬ PHẦN MỀM

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

Hà Nội - 2015


ĐẠI HỌC QUỐC GIA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN

ĐẶNG THỊ PHƢƠNG

NGHIÊN CỨU VÀ ỨNG DỤNG CÔNG CỤ KIỂM THỬ TỰ
ĐỘNG SELENIUM TRONG KIỂM THỬ PHẦN MỀM

Ngành: Công nghệ thông tin
Chuyên ngành: Quản lý hệ thống thông tin
Mã số: Chuyên ngành đào tạo thí điểm

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

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. ĐỖ ĐỨC ĐÔNG
:

Hà Nội - 2015

1
LỜI CAM ĐOAN
Tôi cam đoan đây là luận văn do tôi làm. Kết quả của luận văn dựa trên kinh
nghiệm thực tế khi tham gia phát triển dự án phần mềm nói chung cũng như kinh
nghiệm trong lĩnh vực kiểm thử tự động nói riêng. Các số liệu, kết quả nêu trong luận
văn là trung thực và chưa từng được công bố trong bất kỳ công trình nào khác. Các số
liệu trích dẫn trong quá trình nghiên cứu đều được ghi rõ nguồn gốc.

Tác giả luận văn

Đặng Thị Phương


2
LỜI CẢM ƠN
Để hoàn thành luận văn này tôi xin chân thành gửi lời cảm ơn đến các thầy cô
trong Viện CNTT – ĐH Quốc Gia Hà Nội đã đóng góp ý kiến, nhận xét và quan tâm
chỉ bảo, giúp đỡ tận tình trong quá trình thực hiện đề tài.
Tôi xin gửi lời cảm ơn sâu sắc nhất đến thầy giáo, TS. Đỗ Đức Đông đã hướng
dẫn, định hướng chuyên môn, quan tâm giúp đỡ tận tình và tạo mọi điều kiện thuận lợi
giúp tôi thực hiện luận văn trong suốt thời gian vừa qua. Đồ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ốt nhất để tôi có thể hoàn thành tốt mọi công việc trong quá 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è.
Tác giả luận văn
Đặng Thị Phương

3
MỤC LỤC
LỜI CAM ĐOAN......................................................................................................................... 1
LỜI CẢM ƠN ............................................................................................................................... 2
MỤC LỤC ..................................................................................................................................... 3
DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT VÀ CÁC THUẬT NGỮ .................... 5
DANH MỤC CÁC HÌNH VẼ ................................................................................................... 6
LỜI MỞ ĐẦU ............................................................................................................................... 7
Chƣơng 1: TỔNG QUAN VỀ BDD - CUCUMBER - SELENIUM - PAGE OBJECT 9
1.1. Tổng quan về kiểm thử phần mềm ....................................................................9
1.2. TDD (Test Driven Development) .......................................................................9
1.2.1. TDD là gì? ......................................................................................................9
1.2.2. Ba điều luật khi áp dụng TDD ......................................................................10
1.2.3. Các bước thực hiện trong chu trình TDD .....................................................11
1.2.4. Các cấp độ TDD ...........................................................................................11
1.2.5. Các lỗi thường gặp khi áp dụng TDD...........................................................12
1.3. BDD (Behaviour Driven Development)...........................................................12
1.3.1. Khái niệm......................................................................................................12
1.3.2. Quy trình phát triển phần mềm truyền thống ...............................................14
1.3.3. Quy trình phát triển theo hướng BDD ..........................................................14
1.4. Cucumber...........................................................................................................15
1.4.1. Khái niệm......................................................................................................15
1.4.2. Ngôn ngữ Gherkin ........................................................................................15
1.4.3. Chạy một Cucumber Junit test ......................................................................17
1.4.4. Chu trình .......................................................................................................17
1.4.5. Sơ đồ workflow xử lý các steps trong cucumber..........................................20
1.4.6. Cấu trúc dự án cài đặt Cucumber .................................................................21
1.4.7. Các thư viện cần thiết để chạy Cucumber ....................................................21

1.5. Selenium WebDriver .........................................................................................22
1.5.1. Selenium WebDriver là gì ............................................................................22
1.5.2. Tổng quan về đối tượng UI (Locators) .........................................................23
1.5.2.1. Xác định phần tử Web theo ID ...............................................................24
1.5.2.2. Xác định phần tử Web theo Name .........................................................24
1.5.2.3. Xác định phần tử Web theo LinkText ....................................................25
1.5.2.4. Xác định phần tử Web theo TagName ...................................................25
1.5.2.5. Xác định phần tử Web theo ClassName.................................................25
1.5.2.6. Xác định phần tử Web theo CSS ............................................................26
1.5.2.7. Xác định phần tử Web theo Xpath .........................................................26
1.5.3. Các thư viện cần thiết để chạy Selenium WebDriver ...................................28
1.5.4. Các hàm xử lý chung trong Selenium WebDriver........................................29
1.6. Page Object Model (POM) ..............................................................................30
1.6.1. Tại sao phải dùng POM ................................................................................30


4
1.6.2. Page Object là gì? .........................................................................................32
1.6.3. Lợi ích của Page Object ................................................................................32
1.6.4. Ví dụ .............................................................................................................33
Chƣơng 2: HỆ THỐNG QUẢN LÝ TESTCASE – TESTLINK VÀ HỆ THỐNG
TÍCH HỢP LIÊN TỤC ............................................................................................................ 35
2.1. Hệ thống quản lý testcase - TestLink .............................................................................. 35
2.1.1. Giới thiệu về TestLink ..................................................................................35
2.1.2. Lợi ích của TestLink .....................................................................................35
2.1.3. Các bước cài đặt TestLink ............................................................................36
2.1.4. Kết hợp TestLink và kiểm thử tự động.........................................................36
2.2. Hệ thống tích hợp liên tục (CI)......................................................................................... 39
2.2.1. Khái niệm......................................................................................................39
2.2.2. Thực tiễn hệ thống tích hợp liên tục (Practices of Continuous Integration) 41

2.2.3. Lợi ích của việc tích hợp liên tục..................................................................41
2.2.4. Jenkin ............................................................................................................41
Chƣơng 3: ÁP DỤNG KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY EXOPLATFORM
SEA VÀ ĐÁNH GIÁ KẾT QUẢ ............................................................................................ 43
3.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 ...........................................................................................................................43
3.1.1. Giới thiệu tổng quan về công ty, sản phẩm, môi trường kiểm thử của công ty
................................................................................................................................ 43
3.1.2. Quy trình kiểm thử và hoạt động kiểm thử trước đây ..................................43
3.2. Cài đặt và áp dụng kiểm thử tự động trong quá trình phát triển ................45
3.2.1. Cấu trúc dự án ...............................................................................................45
3.2.2. Cấu trúc mã nguồn ........................................................................................46
3.2.3. Tích hợp Jenkins ...........................................................................................46
3.2.4. Report kết quả chạy test ................................................................................47
3.3. Đánh giá kết quả................................................................................................ 49
3.4. Những khó khăn khi triển khai hệ thống kiểm thử tự động trong công ty .49
3.5. Hƣớng phát triển tiếp theo của framework ....................................................50
KẾT LUẬN ................................................................................................................................. 51
TÀI LIỆU THAM KHẢO........................................................................................................ 52
PHỤ LỤC - CÀI ĐẶT MÔI TRƢỜNG TRÊN UBUNTU 14.04 ..................................... 53


5
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


6
DANH MỤC CÁC HÌNH VẼ
Hình 1.1. Chu trình TDD qua màu sắc (từ trang 1minus1.com) ...................................10
Hình 1.2. Các bước thực hiện TDD ...............................................................................11
Hình 1.3. TDD kết hợp với BDD ..................................................................................13
Hình 1.4. Work flow kết hợp TDD và BDD .................................................................13
Hình 1.5. Quy trình phát triển truyền thống ..................................................................14
Hình 1.6. Quy trình phát triển BDD ..............................................................................14

Hình 1.7. Chương trình chạy test với Cucumber...........................................................17
Hình 1.8. Workflow trong Cucumber............................................................................20
Hình 1.9. Cấu trúc dự án cài đặt Cucumber ..................................................................21
Hình 1.10. Thư viện Cucumber cần cài đặt ...................................................................21
Hình 1.11. Thư viện cần thiết để chạy Selenium WebDriver .......................................28
Hình 1.12. Cấu trúc POM ..............................................................................................32
Hình 2.1. Giới thiệu về TestLink ...................................................................................35
Hình 2.2. Báo cáo trong TestLink .................................................................................39
Hình 2.3. Quá trình tích hợp liên tục CI ........................................................................40
Hình 2.4. Hệ thống tích hợp liên tục .............................................................................40
Hình 2.5. Giao diện Jenkins ..........................................................................................42
Hình 3.1. Cấu trúc dự án thực tế....................................................................................45
Hình 3.2. Cấu trúc mã nguồn cài đặt thực tế .................................................................46
Hình 3.3. Cucumber Report...........................................................................................48
Hình 3.4. Thucydides report ..........................................................................................48
Hình 3.5.TestLink report ...............................................................................................49


7
LỜI MỞ ĐẦU
1. Lý do chọn đề tài
Ngày nay, tự động hóa được ứng dụng ở rất nhiều lĩnh vực, mục đích thường
rất đa dạng và tùy theo nhu cầu đặc thù của từng lĩnh vực, tuy nhiên điểm chung nhất
vẫn là giảm nhân lực, thời gian 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ệ. Để tạo ra sản phẩm công nghệ thông tin hay
phần mềm có chất lượng thì hoạt động kiểm thử phần mềm đóng vai trò rất quan trọng,
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, giảm sự nhàm chán và rèn luyện kỹ
năng lập trình cho kiểm thử viên.
Selenium là công cụ kiểm thử được phát triển dựa trên mã nguồn mở, hoàn toàn
miễn phí. Với công cụ này cùng với một số công cụ hỗ trợ khác như Cucumber,
TestLink, Jenkins, Maven, Ant, 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 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 và hi vọng sẽ có ngày càng nhiều các bạn yêu thích công việc kiểm thử nói
chung cũng như hiểu rõ và yêu thích kiểm thử tự động nói riêng. Đó là những lý tôi
chọn đề tài “Nghiên cứu và ứng dụng công cụ kiểm thử tự động Selenium trong
kiểm thử phần mềm”
2. Mục tiêu của luận văn
Đề 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ư
cách triển khai công cụ 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)


8
● Đưa ra những khái niệm cơ bản về các công cụ cần thiết như: Cucumber,
Selenium, TestLink, 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.
3. Đối tƣợng và phạm vi nghiên cứu
● Đối tượng nghiên cứu: Công cụ kiểm thử tự động Selenium, Cucumber,
TestLink, Jenkins và các tài liệu, nội dung liên quan đến công cụ này.
● Phạm vi nghiên cứu: Luận văn nghiên cứu công cụ kiểm thử tự động và áp
dụng trong dự án tại công ty phần mềm Exo Platform Sea.
4. Phƣơng pháp nghiên cứu
● Nghiên cứu tổng quan về quy trình phát triển và các công cụ cần thiết trong
kiểm thử tự động Selenium kết hợp với Cucumber.
● Phân tích, tổng hợp các tài liệu đã thu được và triển khai mô hình thử nghiệm
● Đánh giá kết quả, đưa ra những khó khan và hướng triển khai tiếp theo
5. Cấu trúc luận văn
● Mở đầu
● Nội dung
○ Chƣơng 1: Tổng quan BDD - Cucumber - Selenium - Page Object
○ Chƣơng 2: Hệ thống quản lý TestCase – TestLink và hệ thống tích
hợp liên tục
○ Chƣơng 3: Áp dụng kiểm thử tự động tại công ty Exo Platform Sea
và đánh giá kết quả
● Kết luận
● Tài liệu tham khảo
● Phụ lục


9
Chƣơng 1: TỔNG QUAN VỀ BDD - CUCUMBER - SELENIUM - PAGE OBJECT
1.1. Tổng quan về kiểm thử phần mềm
● Kiểm thử phần mềm là một giai đoạn trong quy trình phát triển phần mềm
để đảm bảo độ tin cậy và chất lượng của phần mềm.

● Các mục tiêu chính của kiểm thử phần mềm :
○ Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử xác định
trước.
○ Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tả yêu cầu
của nó.
○ Xác thực chất lượng kiểm thử phần mềm đã dùng chi phí và nỗ lực tối
thiểu.
○ Tạo các kịch bản kiểm thử (testcase) chất lượng cao, thực hiện kiểm thử
hiệu quả và tạo ra các báo cáo vấn đề đúng và hữu dụng.
● Kiểm thử phần mềm tốn nhiều chi phí nguồn lực và thời gian. 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. Nếu cần ứng dụng an toàn hơn, chi phí kiểm thử còn cao hơn nữa. 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.
● Tự động hóa việc kiểm thử là việc sử dụng một công cụ kiểm thử để thực thi
các kịch bản kiểm thử thay cho con người. Công cụ kiểm thử tự động có thể
lấy dữ liệu từ bên ngoài đưa vào hệ thống, so sánh kết quả thực tế với kết
quả mong đợi và đưa ra báo cáo.
1.2. TDD (Test Driven Development)
1.2.1. TDD là gì?
● Phát triển hướng kiểm thử TDD (Test-Driven Development) là một phương
pháp triển trong đó 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.
● 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ỏ

(Baby Step) và tiến độ được đảm bảo liên tục bằng cách viết và chạy các
kịch bản kiểm thử tự động (automated tests). 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:
○ Viết một kịch bản kiểm thử cho hàm mới đảm bảo rằng khi chạy test sẽ
fail.
○ Chuyển qua viết mã nguồn sơ khai nhất cho hàm đó để test có thể pass.


10
○ Tối ưu hóa đoạn code của hàm vừa viết sao cho đảm bảo test vẫn pass và
tối ưu nhất cho việc lập trình kế tiếp
○ Lặp lại cho các hàm khác từ bước đầu tiên
● 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 test được thông báo rõ
rang thông qua màu sắc:
○ Đỏ: test fail, chuyển sang viết function cho test pass
○ Xanh lá: viết một test mới hoặc tối ưu code đã viết trong màu đỏ.

Hình 1.1. Chu trình TDD qua màu sắc (từ trang 1minus1.com)
1.2.2. 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 test bị fail trở nên pass.
● Không cho phép viết nhiều hơn một unit test mà nếu chỉ cần 1 unit test cung
đã đủ để fail. Hãy chuyển sang viết code function để pass test đó 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 test
bị fail chuyển sang pass.


11
1.2.3. 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 />1.2.4. Các cấp độ TDD
● Mức chấp nhận (Acceptance TDD (ATDD)): hay còn gọi là Behaviour
Driven Development (BDD). Ta viết một acceptance test hay đặc tả hành vi
và viết các xử lý để đáp ứng được test đó. Thường ở mức đặc tả các yêu cầu
của khách hàng. Hay gọi nôm na là Thoả mãn khách hàng


12
● Mức lập trình (Developer TDD): thường được gọi ngắn gọn là Test Driven
Development, tương đương với mức unit test, thường ở mức xử lý chi tiết và
thiết kế trong của chương trình.
Vậy nên, thực chất BDD là 1 loại TDD, và người ta thường gọi Developer TDD
là TDD.
1.2.5. Các lỗi thường gặp khi áp dụng TDD
●
●
●
●
●
●
●

Không quan tâm đến các test bị fail
Quên đi thao tác tối ưu sau khi viết code cho test pass
Thực hiện tối ưu code trong lúc viết code cho test pass
Đặt tên các test khó hiểu và tối nghĩa
Không bắt đầu từ các test đơn giản nhất và không theo các baby step.
Chỉ chạy mỗi test đang bị fail hiện tại

Viết một test với kịch bản quá phức tạp

1.3. BDD (Behaviour Driven Development)
1.3.1. Khái niệm
● BDD là một quá trình phát triển phần mềm dựa trên kiểm thử hướng hành
vi. BDD quy định rằng các developer và product owner cần hợp tác và xác
định hành vi của người sử dụng. BDD sinh ra hướng tới các feature test mà
người thực hiện là các Acceptance Tester.
○ Thay vì chờ đợi sản phẩm hoàn thành và kiểm thử, tester/analyst
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, tester giúp đỡ developer 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.
○ Developer liên hệ mật thiết với tester và xây dựng mã nguồn với
những phương án mà tester cung cấp theo mô hình TDD.


13

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

Hình 1.4. Work flow kết hợp TDD và BDD
(Từ trang />

14
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 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 Business Analyst (BA) 1 cách chuyên hóa
và khi đến giai đoạn xây dựng (implementing phase) thì đa phần các developer 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 BDD in action (Behavior-Driven Development for the whole
software lifecycle) - John Ferguson Smart (Foreword by Dan North))


15
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ử, developer 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.
1.4. Cucumber
1.4.1. Khái niệm
● Cucumber là một 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 plain-text, mục đích là để hỗ trợ cho việc viết
BDD.
● Cucumber hỗ trợ viết hành vi kiểm thử cho khoảng 60 ngôn ngữ khác nhau
(Ngôn ngữ Gherhin)
● Các plain-text này có thể được đọc bởi mã nguồn được viết bằng nhiều ngôn
ngữ như Java, .Net, Python...
1.4.2. Ngôn ngữ Gherkin
● Cucumber thực thi các .feature file. Các feature files chứa các đặc tả (step)
thực thi, các step này được viết bằng ngôn ngữ Gherkin
● Gherkin là 1 ngôn ngữ mà Cucumber đọc ngôn ngữ ấy chuyển thành test.
Gherkin khá dễ hiểu, 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
● Có 2 quy tắc khi viết Gherkin:
○ Một file Gherkin chỉ mô tả cho một feature.
○ Source file Gherkin là .feature
○ Một feature có thể có nhiều scenario
○ Đươi đây là cấu trúc của một feature file


16

● Ví dụ:

● Trong Gherkin, mỗi dòng sẽ bắt đầu bằng Gherkin keyword. Dưới đây là
các keyword trong gherkin
○ Feature
○ Scenario
○ Given, When, Then, And, But (Steps)
○ Background
○ Scenario Outline

○ Examples
○ """ (Doc Strings)


17
○ | (Data Tables)
○ @ (Tags)
○ # (Comments)
1.4.3. Chạy một Cucumber Junit test

● @RunWith: khai báo TestRunner, có thể là Cucumber.class hoặc
CucumberWithSerenity.class. 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 test
○ features: đường dẫn đến các feature file
○ glue: định nghĩa packages khai báo Steps trong Cucumber
○ tag: định nghĩa các scenrio nào sẽ được chạy
○ formate: khai báo và định nghĩa các reports
1.4.4. Chu trình

Hình 1.7. Chương trình chạy test với Cucumber
● Mô tả lại hành vi dưới dạng plain-text (sử dụng ngôn ngữ Gherhin)


18

● Định nghĩa các step
○ 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 step (^, $, \\d,

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

● Chạy test và xem test fail

● Viết code làm cho các step pass


19

● Chạy lại test và xem những step pass
● Lặp lại các bước đến khi toàn bộ các step pass


20
1.4.5. Sơ đồ workflow xử lý các steps trong cucumber

Hình 1.8. Workflow trong Cucumber


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

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

1.4.7. Các thư viện cần thiết để chạy Cucumber
● Danh sách các thư viện Cucumber cần cài đặt

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

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

1.5. Selenium WebDriver
Trong các phần trước, tôi đã trình bày khái niệm về TDD, BDD và việc sử dụng
Cucumber cho phát triển BDD. Công cụ 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. Câu hỏi đặt ra là 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 em 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.
1.5.1. Selenium WebDriver là gì
● Selenium WebDriver là công cụ kiểm thử tự động các ứng dụng Web
○ Viết scripts với nhiều ngôn ngữ lập trình khác nhau (Java, .Net,
Php, Python …)
○ Hỗ trợ test trên nhiều trình duyệt khác nhau (Firefox, Chrome,
Internet Explorer, Opera, Safari)
○ Hỗ trợ chạy test trên nhiều hệ điều hành khác nhau (Ubunut,
Windows, IOS …)


23

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

Trên thị trường có khá nhiều công cụ kiểm thử Web khác nhau như QuickTestPro,
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.
1.5.2. Tổng quan về đối tượng UI (Locators)
● Trong selenium, các phần tử trên web (WebElement) 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)
○ ID
○ Name
○ LinkText
○ TagName
○ ClassName
○ Css
○ Xpath