ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

HÀ KHÁNH TOÀN

PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO
KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB

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

Hà Nội - 2013


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

HÀ KHÁNH TOÀN

PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO
KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB

Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60 48 10

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

NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. LÊ THANH HÀ

Hà Nội - 2013


nhất cho tôi trong suốt quá trình học tập, nghiên cứu và cho đến khi thực hiện đề tài
luận văn.
Cuối cùng, tôi xin chân thành bày tỏ lòng cảm ơn đến Ban lãnh đạo Hệ thống
Đào tạo Lập trình viên Quốc tế Aprotrain-Aptech đã tạo điều kiện cho tôi rất nhiều
trong suốt quá trình làm việc, học tập và thực hiện đề tài luận văn thạc sĩ của mình.
Mặc dù tôi đã rất cố gắng hoàn thiện luận văn bằng tất cả sự nhiệt tình và
năng lực của mình. Tuy nhiên do trình độ, kinh nghiệm và khả năng chuyên môn có
hạn, chắc chắn luận văn còn nhiều thiếu sót. Rất mong nhận đƣợc những góp ý của
quý Thầy Cô và các bạn.

Hà Nội, tháng 12 năm 2013
Học viên

Hà Khánh Toàn


iii

MỤC LỤC
TRANG PHỤ BÌA
LỜI CAM ĐOAN
LỜI CẢM ƠN
MỤC LỤC
DANH MỤC CÁC TỪ VIẾT TẮT
DANH MỤC CÁC BẢNG
DANH MỤC CÁC HÌNH VẼ
CHƢƠNG 1. GIỚI THIỆU ............................................................................. 1
CHƢƠNG 2. CƠ SỞ LÝ THUYẾT ............................................................... 3
2.1. Khái niệm Web Application ................................................................ 3
2.2. Các kỹ thuật kiểm thử .......................................................................... 3

4.2.1. Mô tả công cụ kiểm thử .............................................................. 33
4.2.2 Xây dựng ứng dụng Web ............................................................. 34
4.2.3. Xây dựng máy hữu hạn trạng thái cho ứng dụng Web ............... 38
4.3. Kết quả thử nghiệm chƣơng trình ...................................................... 41
4.4. Thảo luận............................................................................................ 44
CHƢƠNG 5. KẾT LUẬN ............................................................................ 45
PHỤ LỤC ...................................................................................................... 47
TÀI LIỆU THAM KHẢO............................................................................. 54


v

DANH MỤC CÁC TỪ VIẾT TẮT
Viết tắt

Cụm từ đầy đủ

Ý nghĩa

FSM

Finite State Machine

Máy hữu hạn trạng thái

HTTP

Hypertext Transfer Protocol

Giao thức truyền siêu văn bản

SWEBOK

Software Engineering Body of
Knowledge

Tổ chức quốc tế theo chuẩn
ISO/IEC TR 19759:2005


vi

DANH MỤC CÁC BẢNG
Số hiệu
bảng

Tên bảng

Trang

2.1

Bảng chuyển trạng thái

10

3.1

Bảng chuyển trạng thái trang login.aspx

20

4.2

Bảng trạng thái trang login.aspx

38

4.3

Bảng sự kiện trang login.aspx

38

4.4

Bảng biểu diễn trạng thái chuyển trang login.aspx

39

4.5

Các phần tử html trang studentInformation.aspx

39

4.6

Bảng trạng thái trang studentInformation.aspx

39



Bảng biểu diễn
resultStudent.aspx

4.13

Bảng trạng thái trang logout.aspx

41

4.14

Bảng sự kiện trang logout.aspx

41

4.15

Bảng biểu diễn trạng thái chuyển trang logout.aspx

41

trạng

thái

thái

chuyển



Một ví dụ về kiểm thử hộp trắng

5

2.3

Sơ đồ luồng điều khiển đƣợc tạo ra từ chƣơng trình

6

2.4

Các bƣớc thực hiện kiểm thử mô hình

8

2.5

Mô hình đồ thị của máy FSM

11

3.1

Máy hữu hạn trạng thái cho trang login.aspx

27

3.2


Sơ đồ xây dựng bài toán

33

4.2

Giao diện chính của chƣơng trình

34

4.3

Giao diện trang Login.aspx

35

4.4

Giao diện trang studentInformation.aspx

36

4.5

Giao diện trang resultStudent.aspx

36

4.6

nói chung. Trong thực tế, các công ty gặp nhiều khó khăn, tốn thời gian và chi phí
cao cho việc kiểm thử các ứng dụng Web. Mặc dù họ có thể thuê những ngƣời
kiểm thử có kỹ năng kiểm thử giỏi, song những sai sót hoặc thiếu sót trong kiểm
thử ứng dụng Web là không thể tránh khỏi do các phƣơng pháp kiểm thử ứng dụng
Web thƣờng đƣợc thực hiện thủ công. Do đó, các phƣơng pháp kiểm thử hiện tại
không đảm bảo phát hiện ra tất cả các lỗi. Ngoài ra, việc kiểm thử thủ công của một
ứng dụng Web có thể tẻ nhạt và tốn thời gian (đôi khi do tƣơng tác ngƣời dùng quá
lớn), đặc biệt là khi thực hiện các bài kiểm thử qui hồi trong ứng dụng. Kết quả là
các ứng dụng Web hiện nay tiềm ẩn rất nhiều lỗi sau khi triển khai cho khách hàng.
Trong kiểm thử các ứng dụng Web, kiểm thử tƣơng tác giao diện ngƣời
dùng là một vấn đề khó và thƣờng đƣợc thực hiện thủ công. Trong thực tế, chúng ta
có một thiết kế giao diện ngƣời dùng mô tả việc thay đổi trạng thái của màn hình
ứng với các tƣơng tác của ngƣời dùng. Các thay đổi trạng thái này có thể xảy ra
trong một trang Web hoặc từ trang Web này sang trang Web khác. Làm thế nào để
đảm bảo rằng việc cài đặt tuân thủ đúng theo thiết kế này chính là mục đích chính
của kiểm thử tƣơng tác giao diện ngƣời dùng cho các ứng dụng Web. Các kỹ thuật
kiểm thử tự động đã đƣợc biết đến nhƣ là các giải pháp tiềm năng để giải quyết vấn
đề trên. Những kỹ thuật này có thể phát hiện ra tất cả các lỗi có thể trong ứng dụng
bằng cách tạo ra và thực hiện tự động các ca kiểm thử. Kết quả là, chúng ta có thể
tiết kiệm thời gian và chi phí trong kiểm thử. Tự động kiểm thử là quá trình thực


2
hiện tự động bởi một chƣơng trình máy tính để tránh các lỗi không đƣợc phát hiện
khi kiểm thử thủ công. Để đảm bảo tính chính xác, các công cụ kiểm thử tự động
thƣờng đƣợc xây dựng dựa trên các phƣơng pháp kiểm thử nhƣ kiểm thử hộp đen,
kiểm thử hộp trắng, … Tuy nhiên, các công cụ kiểm thử tự động là rất đắt và nhiều
công ty không thể mua chúng.
Luận văn này tập trung nghiên cứu các phƣơng pháp kiểm thử dựa trên mô
hình nhằm đảm bảo việc cài đặt đúng theo thiết kế ban đầu. Đầu tiên sử dụng mô

không3 …

2.2. Các kỹ thuật kiểm thử
Ngày nay, có rất nhiều các phƣơng pháp đƣợc áp dụng trong kiểm thử, mỗi
phƣơng pháp sẽ có những ƣu điểm và nhƣợc điểm riêng. Trong phần này sẽ miêu tả
một số phƣơng thức kiểm thử nhƣ kiểm thử hộp đen [14], kiểm thử hộp trắng [1],
kiểm thử hộp xám [13] và kiểm thử sử dụng máy hữu hạn trạng thái [2].

2.2.1. Kiểm thử hộp đen
Kiểm thử hộp đen hay còn đƣợc gọi là kiểm thử chức năng, kiểm thử hộp
đen coi phần mềm nhƣ là một "hộp đen", kiểm thử chức năng mà không cần bất kỳ
kiến thức về cấu trúc và hành vi bên trong phần mềm. Các kiểm thử viên chỉ biết về
những gì phần mềm phải làm mà không biết là nó làm nhƣ thế nào. Phƣơng pháp
kiểm thử hộp đen bao gồm: phân vùng tƣơng đƣơng, phân tích giá trị biên, tất cả
các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng quyết định, kiểm thử
chéo, kiểm thử dựa trên mô hình, sử dụng các ca kiểm thử, thăm dò kiểm thử và
kiểm thử dựa trên đặc điểm kỹ thuật.
Kiểm thử dựa trên đặc điểm kỹ thuật nhằm mục đích để kiểm tra các chức
năng của phần mềm theo các yêu cầu ứng dụng. Mức độ kiểm thử thƣờng đòi hỏi
ca kiểm thử kỹ lƣỡng đƣợc cung cấp bởi các kiểm thử viên, những ngƣời mà sau đó
có thể xác minh một cách đơn giản rằng đối với một giá trị đầu vào hoặc đầu ra
1


/>3
/>2


4
(hoặc cách xử lý) có thể giống hoặc không so với giá trị kỳ vọng đƣợc định vị trong

Kiểm thử hộp trắng hay còn đƣợc gọi là kiểm thử cấu trúc, quá trình thiết kế
các ca kiểm thử là quá trình xây dựng các phƣơng pháp kiểm thử có thể phát hiện
lỗi, sai sót, khiếm khuyết của phần mềm để xây dựng một phần mềm đạt tiêu
chuẩn. Kỹ thuật kiểm thử hộp trắng hay kiểm thử hƣớng lôgic cho phép bạn khảo
sát cấu trúc bên trong của chƣơng trình. Kỹ thuật này xuất phát từ dữ liệu kiểm thử
bằng sự kiểm thử tính lôgic của chƣơng trình. Kiểm thử viên sẽ truy cập vào cấu
trúc dữ liệu và giải thuật bên trong chƣơng trình (và cả mã lệnh thực hiện chúng).


5
Mục đích của bất cứ phƣơng pháp kiểm thử nào cũng là để đảm bảo rằng
tình trạng tốt của một hệ thống trên bề mặt của những sự tấn công độc hại hoặc là
tránh những sự thất bại của phần mềm thông thƣờng. Kiểm thử hộp trắng là sự thực
hiện dựa trên hiểu biết về những phần tử của một hệ thống. Kiểm thử hộp trắng bao
gồm phân tích dòng dữ liệu, điều khiển dòng, dòng thông tin, mã thực hành, ngoại
lệ và những lỗi trình bày trong hệ thống để kiểm tra những hành động của phần
mềm không đƣợc định hƣớng trƣớc. Kiểm thử hộp trắng có thể thực hiện để xác
định tính hợp lệ cho dù việc triển khai thực hiện sau mã nhằm thiết kế, xác nhận
tính hợp lệ để triển khai thực hiện chức năng bảo mật và giảm rủi ro việc bị tấn
công ở những chỗ mở có thể khai thác đƣợc.
Kiểm thử hộp trắng yêu cầu truy cập vào mã nguồn mặc dù kiểm thử hộp
trắng có thể thực hiện tại bất cứ thời điểm nào trong vòng đời của phần mềm sau
khi mã lệnh đƣợc phát triển. Đó là một hành động tốt để thực hiện kiểm thử hộp
trắng trong suốt giai đoạn kiểm thử đơn vị.
Hình 2.2 hiển thị một kiểm thử hộp trắng đơn giản. Trong hình 2.2, ở Ví dụ
1 chỉ có một đƣờng thi hành nhƣng rất dài: dài 1000*1000*1000 = 1 tỷ lệnh gọi
hàm doSomethingWith(i,j,k) khác nhau. Ví dụ 2 gồm 32 câu lệnh if else độc lập
nhƣng có 2^32 = 4 tỷ đƣờng thi hành khác nhau. Nhƣ vậy mục tiêu của kiểm thử là
đảm bảo mọi đƣờng thi hành của đơn vị phần mềm cần kiểm thử đều chạy đúng.
Tuy nhiên trong thực tế, công sức và thời gian để đạt đƣợc mục tiêu trên đây là rất

giữa hai mô-đun mã lệnh đƣợc viết bởi hai chuyên viên thiết kế khác nhau, trong đó
chỉ giao diện là đƣợc đƣa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm
cả thiết kế đối chiếu để quyết định, ví dụ giá trị biên hay thông báo lỗi.

2.2.4. Kiểm thử dựa trên mô hình
2.2.4.1. Khái niệm kiểm thử dựa trên mô hình
Kiểm thử dựa trên mô hình [4] là tự động tạo ra các thủ tục kiểm thử phần
mềm sử dụng các mô hình yêu cầu hệ thống và hành vi. Mặc dù loại kiểm thử này
đòi hỏi nhiều nỗ lực đáng kể trong việc xây dựng các mô hình trƣớc, nhƣng nó
cung cấp lợi thế đáng kể so với cách phƣơng pháp kiểm thử phần mềm truyền
thống. Các mẫu thiết kế hay mô hình là mô tả đơn giản của hệ thống dựa trên yêu
cầu hệ thống và chức năng xác định, giúp chúng ta có thể hiểu và dự đoán đƣợc
hành vi của hệ thống.
2.2.4.2. Các bước thực hiện
Quá trình kiểm thử dựa trên mô hình đƣợc bắt đầu bằng việc xác định yêu
cầu của hệ thống từ đó xây dựng mô hình dựa vào các yêu cầu và chức năng của hệ
thống [12]. Việc xây dựng mô hình còn phải dựa trên các yếu tố dữ liệu đầu vào và
đầu ra. Mô hình này đƣợc sử dụng để sinh ra các ca kiểm thử. Chúng ta có thể biết
kết quả đầu ra mong đợi từ mô hình hoặc từ quy định chuẩn. Khi chạy kịch bản và
kết quả thu đƣợc sẽ đƣợc so sánh với kết quả mong đợi. Từ đó, quyết định hành
động tiếp theo nhƣ sửa đổi mô hình hoặc dừng kiểm thử, …
Các bƣớc để thực hiện kiểm thử dựa trên mô hình nhƣ đƣợc trình bày ở hình
2.4 bao gồm các bƣớc sau:
 Xây dựng mô hình dựa trên các yêu cầu và chức năng của hệ thống
 Tạo đầu ra dự kiến từ mô tả bài toán
 Chạy kịch bản kiểm thử
 So sánh kết quả đầu ra thực tế với kết quả đầu ra dự kiến
 Quyết định hành động tiếp theo (Sửa đổi mô hình, tạo thêm ca kiểm thử,
dừng kiểm thử, đánh giá chất lƣợng của phần mềm).


 Có khả năng đánh giá chất lƣợng phần mềm.
Mặc dù có nhiều thuận lợi nhƣng bên cạnh đó cũng có những trở ngại nhất
định của kiểm thử dựa trên mô hình:
 Do phải xây dựng mô hình của hệ thống vì vậy ngƣời kiểm thử phần mềm
phải yêu cầu là những ngƣời có khả năng phân tích và thiết kế hệ thống.
 Trong kiểm thử dựa trên mô hình công việc quan trọng nhất là xây dựng mô
hình. Ngƣời kiểm thử phải đầu tƣ đáng kể cả về thời gian, trí tuệ và tiền bạc
cho việc xây dựng mô hình hệ thống.
 Giống nhƣ các phƣơng pháp kiểm thử khác, việc kiểm thử dựa trên mô hình
chỉ phát hiện đƣợc lỗi của hệ thống mà không thể phát hiện đƣợc hệ thống
còn lỗi hay không.

2.2.5. Kiểm thử sử dụng máy hữu hạn trạng thái
Trong kiểm thử phần mềm có nhiều kiểu mô hình đƣợc sử dụng nhƣ: mô
hình máy hữu hạn trạng thái [2], ngôn ngữ mô hình hóa thống nhất - UML, văn
phạm, ... Trong nghiên cứu này trình bày về mô hình máy hữu hạn trạng thái.
Mô hình máy hữu hạn trạng thái cũng đƣợc gọi là ôtômat hữu hạn trạng thái
hoặc chỉ đơn giản là một máy trạng thái. Nó đƣợc sử dụng rộng rãi trong các mô
hình tính toán với nhiều ứng dụng. Một máy hữu hạn trạng thái bao gồm ba thành
phần chính là các trạng thái, các quá trình chuyển đổi, và các hành động. Các thành
phần này có thể phân thành hai loại chính là Máy hữu hạn trạng thái chấp nhận Acceptor Finite State Machine (AFSM) và Bộ chuyển đổi hữu hạn trạng thái Finite State Transducer (FST). Trong thực tế máy hữu hạn trạng thái đóng một vai
trò quan trọng trong nhiều lĩnh vực nhƣ công nghệ điện tử, ngôn ngữ học, lôgic và
đặc biệt là khoa học máy tính. Trong khoa học máy tính, máy hữu hạn trạng thái


10
đƣợc sử dụng rộng rãi trong các mô hình hóa các hoạt động phần mềm, thiết kế hệ
thống phần cứng, dịch thuật,… Do đó luận văn áp dụng mô hình này để xây dựng
chƣơng trình kiểm thử tự động cho giao diện ứng dụng Web [3].
Máy hữu hạn trạng thái đƣợc định nghĩa theo mô hình nhƣ sau:

Khoahoc

-

t_Std
Name
-

select_kho
ahoc
-

-

-

-

-

del_khoahoc

-

-

-

del_Std
Name


-

-

-

-

Sau đó bảng này sẽ đƣợc chuyển sang đồ thị chuyển trạng thái trong hình
2.5. Hình 2.5 hiển thị mô hình đồ thị máy FSM cũng đƣợc gọi là đồ thị có hƣớng.


11
t_stdNameText

select_khoahoc
S_ResultS
tudent

Khoa
Hoc

del_Name

t_stdnameText
Student
Name

StudentName

2.3. Các mức kiểm thử
Kiểm thử thƣờng xuyên đƣợc nhóm lại theo vị trí chúng đƣợc thêm vào
trong quá trình phát triển phần mềm, hoặc do mức độ đặc hiệu của kiểm thử. Các
cấp chính trong quá trình phát triển theo quy định của hƣớng dẫn SWEBOK là
kiểm thử đơn vị [7], kiểm thử tích hợp [11], và kiểm thử hệ thống [8] đƣợc phân
biệt bởi các mục tiêu kiểm thử mà không ám chỉ một mô hình quy trình cụ thể. Các
mức độ kiểm thử khác đƣợc phân loại theo mục tiêu kiểm thử.


12

2.3.1. Kiểm thử đơn vị
Kiểm thử đơn vị hay còn đƣợc gọi là kiểm thử thành phần, đề cập đến việc
kiểm thử chức năng từng phần của mã, thƣờng ở mức độ chức năng. Trong một
môi trƣờng hƣớng về đối tƣợng thì điều này thƣờng là cấp độ lớp, và các kiểm thử
đơn vị tối thiểu bao gồm hàm dựng và hàm hủy. Nhiều loại kiểm thử đƣợc viết bởi
các nhà phát triển nhƣ họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng
hàm riêng biệt hoạt động đúng nhƣ kỳ vọng. Một hàm có thể có nhiều kiểm thử từ
đó giúp nắm bắt đƣợc các trƣờng hợp góc hoặc các nhánh trong mã lệnh. Kiểm thử
đơn vị một mình không thể đảm bảo hết đƣợc từng chức năng của từng bộ phận
trong phần phềm nhƣng nó đƣợc sử dụng để đảm bảo rằng các khối kiến trúc của
phần mềm hoạt động độc lập với nhau.
Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng
dụng đồng bộ của một loạt các chiến lƣợc phòng ngừa phát hiện lỗi và để giảm
thiểu rủi ro, thời gian và chi phí. Nó đƣợc thực hiện bởi kỹ sƣ hay nhà phát triển
trong suốt giai đoạn xây dựng của vòng đời phát triển phần mềm. Không chỉ tập
trung vào việc đảm bảo chất lƣợng truyền thống mà phải gia tăng nó lên vì thế kiểm
thử đơn vị có mục đích loại bỏ những lỗi cấu trúc trƣớc khi mã hóa rồi mới thúc
đẩy việc quản lý chất lƣợng. Chiến lƣợc này nhằm nâng cao chất lƣợng cũng nhƣ
hiệu quả của phần mềm trong tiến trình quản lý và phát triển chung.

chấp nhận là để xác nhận sự tin tƣởng trong hệ thống, các đặc điểm chức năng hoặc
không có chức năng của hệ thống. Tìm kiếm lỗi không phải là trọng tâm chính của
kiểm thử chấp nhận. Kiểm thử chấp nhận có thể đánh giá sự sẵn sàng của hệ thống
để triển khai và sử dụng, mặc dù nó không nhất thiết phải là mức cuối cùng của
kiểm thử. Ví dụ, một kiểm thử tích hợp có hệ thống trong một phạm vi lớn có thể
đƣợc thực hiện sau khi kiểm thử chấp nhận thực hiện cho một hệ thống.
Hợp đồng và quy định chấp nhận thử nghiệm: Kiểm tra nghiệm thu hợp
đồng đƣợc thực hiện với các tiêu chí chấp nhận một hợp đồng nâng cấp - phát triển
phần mềm. Chuẩn mực chấp nhận phải đƣợc xác định để thực hiện một thỏa thuận
hợp đồng. Điều lệ kiểm thử chấp nhận đƣợc thực hiện trong bất kỳ quy định nào
phải căn cứ vào nhƣ các quy định của chính phủ, pháp luật hoặc các quy định an
toàn.
Kiểm thử Alpha và Beta: Các nhà phát triển của thị trƣờng phần mềm
thƣờng muốn nhận đƣợc thông tin phản hồi từ khách hàng tiềm năng hoặc khách
hàng trong thị trƣờng của họ trƣớc khi sản phẩm phần mềm đƣợc đóng gói thƣơng
mại. Thử nghiệm alpha đƣợc thực hiện tại địa điểm tổ chức đang phát triển. Giai
đoạn thử nghiệm, hoặc trƣờng thử nghiệm, đƣợc thực hiện bởi khách hàng hoặc
khách hàng tiềm năng tại các địa điểm riêng của họ.

2.4. BỘ CÔNG CỤ SELENIUM – WEBDRIVER TRONG VIỆC KIỂM
THỬ GIAO DIỆN ỨNG DỤNG WEB
Selenium là một tập hợp mạnh mẽ các công cụ hỗ trợ phát triển nhanh chóng
của các thử nghiệm tự động hóa cho các ứng dụng Web [6]. Selenium cung cấp một
tập phong phú các thử nghiệm chức năng đặc biệt hƣớng đến các nhu cầu của các


14
thử nghiệm trong một ứng dụng Web. Các hoạt động này là rất linh hoạt, cho phép
nhiều tùy chọn cho vị trí các thành phần giao diện và so sánh kết quả thử nghiệm
dự kiến sẽ chống lại hành vi ứng dụng thực tế.



15

2.4.3. Selenium 2 (Selenium – Webdriver)
Selenium 2 là hƣớng tƣơng lai của dự án nó bổ sung mới nhất của công cụ
Selenium. Công cụ này cung cấp những tính năng tuyệt vời, bao gồm API định
hƣớng gắn kết hơn và giải quyết các vấn đề tồn tại của các phiên bản trƣớc. Nó hỗ
trợ các API Webdriver, cùng với công nghệ Selenium 1 API WebDriver cho sự linh
hoạt tối đa trong việc kiểm thử. Ngoài ra, Selenium 2 vẫn chạy Selenium RC 1 của
giao diện để tƣơng thích ngƣợc.

2.4.4. Một số Selenium-Webdriver API
2.4.4.1. Một thể hiện của browser driver
Một browser driver (ví dụ nhƣ FirefoxDriver) là một đối tƣợng, đối tƣợng
này đƣợc coi nhƣ đại diện một trình duyệt trong chƣơng trình.
WebDriver ffdriver = new FirefoxDriver();
Từ đây, đối tƣợng ffdriver sẽ có những phƣơng thức từ đó điểu khiển trình
duyệt ở đây là Firefox. Sau khi thực hiện lệnh này, trình duyệt sẽ đƣợc khởi động.
2.4.4.2. Truy cập một trang Web
Điều đầu tiên chúng ta muốn làm với một Webdriver đó là truy cập vào một
trang Web, thông thƣờng điều này sẽ đƣợc thực hiện qua phƣơng thức:
driver.get("");
Khi đó trình duyệt sẽ đƣợc tự động truy cập vào địa chỉ đã truyền vào.
2.4.4.3. Định vị các thành phần trên giao diện Web
Tất cả các thành phần trên giao diện Web đều có thể định vị bằng nhiều cách
mà Selenium hỗ trợ. Mỗi một thành phần sẽ đƣợc ánh xạ qua một thể hiện của
WebElement.
Webdriver sử dụng một phƣơng thức findElement mà tham số của phƣơng
thức này là định nghĩa vị trí của element trên trang Web. Có rất nhiều cách để định

WebElement element = driver.findElement(By.name("q"));
// Enter something to search for
element.sendKeys("Cheese!");
// Now submit the form.
element.submit();
2.4.4.5. Di chuyển giữa các cửa sổ và frame
Một số ứng dụng Web có thể chứa nhiều cửa sổ hoặc frame, Webdriver cung
cấp phƣơng thức giúp di chuyển giữa các cửa sổ thông qua tên:
driver.switchTo().window("windowName");
driver.switchTo().frame("frameName");
2.4.4.6. Điều hướng trình duyệt
Sau khi trình duyệt truy cập một trang Web và thực hiện một số sự kiện
chuyển sang những trang mới, khi đó chúng ta có thể sử dụng phƣơng thức