Phương pháp sinh bộ kiểm thử tự động cho kiểm thử giao diện ứng dụng web
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.16 MB, 63 trang )
ĐẠ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
i
LỜI CAM ĐOAN
Tơi xin cam đoan đây là cơng trình nghiên cứu của tôi dƣới sự giúp đỡ rất
lớn của Giảng viên hƣớng dẫn là Tiến sĩ Lê Thanh Hà, Tiến sĩ Phạm Ngọc Hùng.
Những nội dung nghiên cứu và kết quả trong đề tài này hoàn toàn trung thực.
Các trích dẫn từ nguồn tài liệu bên ngồi đều đƣợc liệt kê rõ ràng ở phần
cuối của luận văn.
Hà Nội, tháng 12 năm 2013
Học viên
Hà Khánh Toàn
ii
LỜI CẢM ƠN
Để có thể hồn thành đề tài luận văn thạc sĩ một cách hoàn chỉnh, bên cạnh sự
nỗ lực cố gắng của bản thân cịn có sự hƣớng dẫn nhiệt tình của q Thầy Cơ, cũng
nhƣ sự động viên ủng hộ của gia đình và bạn bè trong suốt thời gian học tập,
nghiên cứu và thực hiện luận văn thạc sĩ.
Xin chân thành bày tỏ lòng biết ơn sâu sắc đến Tiến sĩ Lê Thanh Hà, Tiến sĩ
Phạm Ngọc Hùng, những ngƣời đã dành rất nhiều thời gian và tâm huyết hƣớng
dẫn tơi nghiên cứu và hồn thành luận văn thạc sĩ. Xin gửi lời tri ân nhất đối với
những điều mà các Thầy đã dành cho tôi.
Xin chân thành bày tỏ lịng biết ơn đến tồn thể quý Thầy Cô trong khoa
Công Nghệ Thông Tin Trƣờng Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội đã
tận tình truyền đạt những kiến thức quý báu cũng nhƣ tạo mọi điều kiện thuận lợi
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 q 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 chun 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
q 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
2.2.1. Kiểm thử hộp đen.......................................................................... 3
2.2.3. Kiểm thử hộp xám......................................................................... 6
2.2.4. Kiểm thử dựa trên mơ hình ........................................................... 7
2.2.5. Kiểm thử sử dụng máy hữu hạn trạng thái.................................... 9
2.3. Các mức kiểm thử .............................................................................. 11
2.3.1. Kiểm thử đơn vị .......................................................................... 12
2.3.2. Kiểm thử tích hợp ....................................................................... 12
2.3.3. Kiểm thử hệ thống....................................................................... 13
2.3.4. Kiểm thử chấp nhận .................................................................... 13
2.4. BỘ CÔNG CỤ SELENIUM – WEBDRIVER TRONG VIỆC KIỂM
THỬ GIAO DIỆN ỨNG DỤNG WEB .................................................... 13
2.4.1. Tổng quan về Selenium .............................................................. 14
2.4.2. Selenium-RC (Remote Control) ................................................. 14
2.4.3. Selenium 2 (Selenium – Webdriver)........................................... 15
2.4.4. Một số Selenium-Webdriver API ............................................... 15
CHƢƠNG 3. PHƢƠNG PHÁP SINH BỘ KIỂM THỬ TỰ ĐỘNG CHO
KIỂM THỬ GIAO DIỆN ỨNG DỤNG WEB ............................................. 18
iv
3.1. Mục tiêu của phƣơng pháp nghiên cứu .............................................. 18
3.2. Tổng quan .......................................................................................... 18
3.3. Tạo các ca kiểm thử cho ứng dụng Web ............................................ 19
3.3.1. Xây dựng mơ hình máy hữu hạn trạng thái ................................ 19
3.3.2. Xây dựng mơ hình đồ thị cho máy hữu hạn trạng thái ............... 27
3.3.3. Thực hiện việc tạo ra các ca kiểm thử ........................................ 30
3.3.4. Thuật toán sinh ca kiểm thử ........................................................ 30
CHƢƠNG 4. THỰC NGHIỆM .................................................................... 32
4.1. Phƣơng pháp thực hiện ...................................................................... 32
4.2. Xây dựng công cụ kiểm thử tự động.................................................. 32
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
WSDL
Web Services Description
Language
Ngôn ngữ mô tả các dịch vụ
Web
SOAP
Simple Object Access Protocol
Giao thức truy cập đối tƣợng
đơn giản
API
Application Programming
Interface
Giao diện lập trình ứng dụng
UML
Unified Modeling Language
Ngơn Ngữ Mơ Hình Hóa
Thống Nhất
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
3.2
Bảng chuyển trạng thái trang
studentInformation.aspx
21
3.3
Bảng chuyển trạng thái trang resultStudent.aspx
22
3.4
Bảng chuyển trạng thái trang addMark.aspx
3.5
Bảng chuyển trạng thái trang logout.aspx
27
4.1
Các phần tử html trang login.aspx
38
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
4.7
Bảng sự kiện trang studentInformation.aspx
39
4.8
Bảng biểu diễn trạng
studentInformation.aspx
4.9
Các phần tử html trang resultStudent.aspx
40
4.10
Bảng trạng thái trang resultStudent.aspx
40
4.11
Bảng sự kiện trang resultStudent.aspx
40
4.12
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
chuyển
24-25-26
trang
trang
39
41
vii
DANH MỤC CÁC HÌNH VẼ
Số hiệu
hình vẽ
Tên hình vẽ
Trang
2.1
Kiểm thử hộp đen
4
2.2
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
Máy hữu hạn trạng thái cho trang studentInformation.aspx
28
3.3
Máy hữu hạn trạng thái cho trang ResultStudent.aspx
28
3.4
Máy hữu hạn trạng thái cho trang addMark.aspx
29
3.5
Máy hữu hạn trạng thái cho trang logout.aspx
30
3.6
Thuật toán duyệt đồ thị theo chiều sâu
31
4.1
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
Giao diện trang addMark.aspx
37
4.7
Giao diện trang logout.aspx
37
1
CHƢƠNG 1. GIỚI THIỆU
Ngày nay, sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác làm việc
qua mạng và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu
trong cuộc sống của chúng ta. Xu hƣớng này địi hỏi các ứng dụng khơng chỉ là
những hệ thống đơn lẻ trên một máy và chịu sự phụ thuộc vào một nền tảng cố định
nào nữa, mà chúng phải là những hệ thống linh hoạt giúp ngƣời dùng làm việc
“mọi lúc, mọi nơi”. Do đó, việc phát triển các ứng dụng Web đang là xu hƣớng tất
yếu của ngành công nghiệp phần mềm. Các ứng dụng Web đang đƣợc ứng dụng
rộng rãi trong thực tế. Càng ngày các doanh nghiệp nói chung và mọi ngƣời nói
riêng càng phụ thuộc vào các ứng dụng Web và làm thế nào để các ứng dụng Web
đáp ứng đƣợc các nhu cầu này. Do đó, nhu cầu đảm bảo an toàn chất lƣợng các sản
phẩm phần mềm ứng dụng Web ngày càng trở nên cấp thiết. Việc đảm bảo chất
lƣợng phần mềm hiện nay đang là một bài toán khó và nó tiêu tốn hơn 50% cơng
sức và chi phí của các doanh nghiệp phần mềm.
Kiểm thử đang đƣợc quan tâm nhƣ là phƣơng pháp chủ yếu để đảm bảo chất
lƣợng của sản phẩm phần mềm ứng dụng Web nói riêng và sản phẩm phần mềm
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ơ
hình máy hữu hạn trạng thái cho giao diện ứng dụng Web, sau đó tạo ra các bộ
kiểm thử từ máy hữu hạn trạng thái, từ đó xây dựng một đồ thị có hƣớng để biểu
diễn các trƣờng hợp kiểm thử. Dựa trên đồ thị có hƣớng, theo các nhánh chúng ta
có thể tạo ra các trƣờng hợp kiểm thử cho sản phẩm. Mục đích của luận văn này là
đề xuất một phƣơng pháp cho phép để xây dựng một phƣơng pháp kiểm thử tự
động cho giao diện các ứng dụng Web. Một công cụ kiểm thử tự động hỗ trợ cũng
sẽ đƣợc phát triển nhằm minh chứng cho tính hiệu quả của phƣơng pháp này.
Các phần tiếp theo của luận văn đƣợc tổ chức nhƣ sau. Chƣơng 2 trình bày
về cơ sở lý thuyết của đề tài. Chƣơng này đề cập đến các khái niệm cơ bản của
kiểm thử phần mềm, tìm hiểu về kiểm thử dựa trên mơ hình, máy hữu hạn trạng
thái. Tiếp theo, chƣơng 3 đề cập đến cách làm thế nào để sinh đƣợc các bộ kiểm
thử từ máy hữu hạn trạng thái. Sau đó, chƣơng 4 xây dựng chƣơng trình thực
nghiệm dùng công cụ Selenium và Webdriver. Nghiên cứu các trƣờng hợp sinh ca
kiểm thử bằng chƣơng trình thực nghiệm này. Cuối cùng, chƣơng 5 tóm tắt các kết
quả đã đạt đƣợc, kết luận, những hạn chế và hƣớng nghiên cứu phát triển trong
tƣơng lai.
3
CHƢƠNG 2. CƠ SỞ LÝ THUYẾT
2.1. Khái niệm Web Application
Các ứng dụng Web là các ứng dụng đƣợc giao tiếp với các máy khách thông
qua các giao thức Web nhƣ HTTP, WSDL hoặc SOAP. Với sự phổ biến của World
Wide Web thì việc các ứng dụng Web đƣợc phát triển ngày càng nhiều. Trình duyệt
Web cung cấp cho các nhà phát triển các cơ hội để khai thác năng lực vốn có của
trình duyệt để giảm bớt gánh nặng phụ thuộc vào các hệ điều hành khác nhau hoặc
các nền tảng phần cứng có sẵn cho ngƣời dùng.
Ngày nay các ứng dụng Web đƣợc phát triển khá đa dạng từ trang Web hẹn
hò đến các trang thƣơng mại điện tử1, ngân hàng trực tuyến2, đặt vé các hãng hàng
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
một ca kiểm thử nhất định. Các ca kiểm thử đƣợc xây dựng quanh các thông số kỹ
thuật và các yêu cầu đề xuất, tức là những tất cả những gì ứng dụng đó phải làm.
Nó đƣợc sử dụng để mơ tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các
yêu cầu và thiết kế đƣợc bắt nguồn trong ca kiểm thử. Các kiểm thử này có thể là
chức năng hoặc phi chức năng.
Hình 2.1 mơ tả mơ hình của kiểm thử hộp đen với các loại đầu vào nhƣ ngẫu
nhiên tạo ra đầu vào trong phạm vi cho phép, trƣờng hợp ranh giới trong phạm vi
qui định đầu vào, kiểm tra đầu vào là số không, kiểm tra đầu vào là các giá trị rỗng,
đầu vào là các giá trị không hợp lệ hoặc ra khỏi phạm vi dự kiến,...
Đầu vào
Hộp đen
Đầu ra
Hình 2.1. Kiểm thử hộp đen.
Kiểm thử dựa trên đặc điểm kỹ thuật có thể là cần thiết để đảm bảo chức
năng chính xác, nhƣng nó khơng đủ để bảo vệ chống lại các tình huống phức tạp
hoặc có độ rủi ro cao. Một lợi thế của kỹ thuật kiểm thử hộp đen là không yêu cầu
nhất thiết phải có kiến thức lập trình. Các kiểm thử viên tiến hành kiểm thử ở các
khu vực và các chức năng khác nhau của phần mềm mà không liên quan đến các
lập trình viên. Mặt khác, kiểm thử hộp đen đƣợc cho là “đi bộ trong một mê cung
tối tăm mà khơng có đèn pin”. Bởi vì họ khơng kiểm thử mã nguồn và đã có nhiều
tình huống các kiểm thử viên chỉ kiểm thử đƣợc tính năng trong một vài trƣờng hợp
chứ khơng kiểm thử đƣợc tồn bộ hoạt động của chƣơng trình.
Phƣơng pháp kiểm thử này có thể đƣợc áp dụng cho tất cả các cấp kiểm thử
phần mềm: đơn vị, tích hợp, hệ thống và chấp nhận. Nó khơng thể thực hiện đƣợc
tất cả các kiểm thử các cấp độ cao hơn nhƣng nó có thể tạo ƣu thế tốt khi kiểm thử
từng đơn vị.
2.2.2. Kiểm thử hộp trắng
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
lớn, ngay cả trên những đơn vị phần mềm nhỏ.
Hình 2.2. Một ví dụ về kiểm thử hộp trắng.
6
Trong hình 2.3 hiển thị sơ đồ luồng điều khiển của một đoạn mã lệnh. Tại
bƣớc đầu tiên, điểm khởi đầu sẽ đi đến khối lệnh xử lý là điểm (1). Sau đó, luồng
điều khiển sẽ đến điểm quyết định (2). Ở vị trí (2), luồng điều khiển có hai hƣớng.
Nó có thể thực hiện đến điểm (3) để tạo ra một nhánh mới là 1 2 3 hoặc điểm
(4) để tạo ra một nhánh khác là 1 2 4. Cả hai nhánh có đều đến điểm (5) và
trở về điểm kết thúc.
Trong hình 2.3, chúng ta có năm nút quyết định nhị phân trong đồ thị nên có
độ phức tạp C = 1 + 1 = 2. Hai đƣờng độc lập tuyến tính trong đồ thị luồng điều
khiển. Kiểm thử viên có thể tạo ra hai ca kiểm thử cho đoạn mã trên là:
1. 1 2 3 5
2. 1 2 4 5
Hình 2.3 Sơ đồ luồng điều khiển được tạo ra từ chương trình.
2.2.3. Kiểm thử hộp xám
Kiểm thử hộp xám địi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải
thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhƣng là kiểm thử ở
mức ngƣời sử dụng hay mức hộp đen. Việc thao tác với dữ liệu đầu vào và định
dạng dữ liệu đầu ra là không rõ ràng, giống nhƣ một chiếc “hộp xám”, bởi vì đầu
vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống
đƣợc kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp
7
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 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
Q 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 tố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).
8
Hình 2.4. Các bước thực hiện kiểm thử mơ hình
2.2.4.3. Những thuận lợi và khó khăn của kiểm thử dựa trên mơ hình
Trong phát triển phần mềm các kiểm thử viên thƣờng thực hiện cơng việc
của mình bằng phƣơng pháp truyền thống nên thƣờng thiếu thời gian để thực hiện
kiểm thử, hoặc giá thành sản phẩm khi hoàn thành thƣờng cao….[4] Và kiểm thử
dựa trên mơ hình sẽ khắc phục đƣợc một số nhƣợc điểm đó:
Do q trình sinh ca kiểm thử là tự động vì vậy mà rút ngắn thời gian làm
phần mềm, và chất lƣợng phần mềm tốt hơn.
Đặc biệt tuy chi phí lớn cho việc xây dựng mơ hình nhƣng điều này sẽ đƣợc
khấu trừ do chi phí bảo dƣỡng thấp hơn nhiều khi hệ thống đƣợc hoạt động.
Quá trình sinh ra các ca kiểm thử đƣợc thực hiện một cách tự động nên sinh
ra nhiều ca kiểm thử và phát hiện nhiều lỗi.
Ngƣời kiểm thử phần mềm cần thƣờng xuyên trao đổi với ngƣời phát triển
phần mềm trong khi xây dựng mô hình hệ thống vì vậy mà tăng khả năng
giao tiếp trao đổi giữa ngƣời phát triển phần mềm, và ngƣời kiểm thử.
9
Ngƣời kiểm thử sẽ không bị nhàm chán khi phải thực hiện lặp lại nhiều lần
một công việc, điều đó làm cho ngƣời kiểm thử hài lịng với cơng việc của
mình.
Sớm phát hiện lỗi và sự khơng rõ ràng trong đặc điểm kỹ thuật và thiết kế vì
vậy sẽ tăng thời gian giải quyết vấn đề trong kiểm thử.
Tự động tạo và kiểm tra các ca kiểm thử trùng nhau hoặc không hữu hiệu.
Khi một yêu cầu của hệ thống thay đổi việc thay đổi các ca kiểm thử là rất
phức tạp nhƣng nó đƣợc giải quyết khi mà kiểm thử dựa trên mơ hình. Việc
thay đổi các ca kiểm thử chỉ việc thay đổi mô hình của hệ thống.
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 tố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 q 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:
M = (Σ, Q, δ, S, F)
Trong đó:
Σ: tập tất cả các sự kiện: tất cả các sự kiện có thể xảy ra trong chƣơng trình,
Q: tập trạng thái: các trạng thái khi chƣơng trình thực hiện,
δ: trạng thái chuyển đổi: đƣợc định nghĩa giữa các cặp trạng thái hoặc sự
kiện đến các trạng thái tiếp theo,
S: là trạng thái khởi tạo đƣợc khởi tạo khi chƣơng trình bắt đầu thực hiện và
F: là tập kết thúc là tập con của Q.
Trong bảng 2.1 hiển thị các trạng thái chuyển đổi[5], dòng đầu tiên là các
trạng thái cuối, cột đầu tiên là các trạng thái đầu, còn lại là các trạng thái chuyển
đổi. Bảng này đƣợc chuyển đổi thành đồ thị có hƣớng đƣợc biểu diễn trong hình
2.1.
Bảng 2.1. Bảng chuyển trạng thái.
Result
Student.aspx
s_Result
Student
StudentName
Khoahoc
Student+
KhoaHoc
F_main
error
s_Result
Student
Student
Name
Khoahoc
-
t_Std
Name
-
select_kho
ahoc
-
-
-
-
-
del_khoahoc
-
-
-
del_Std
Name
-
Student+K
hoaHoc
F_main
error
-
-
t_submit
t_StdName
select_kho
ahoc
-
t_submit
-
t_submit
-
t_submit
-
-
-
-
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
+KhoaHoc
del_khoahoc
Submit
Result
Student.aspx
Submit
select_khoahoc
Submit
errorSt
Submit
Hình 2.5. Mơ hình đồ thị của máy FSM
Từ mơ hình đồ thị của máy hữu hạn trạng thái (Hình 2.5). Chúng ta có thể
thấy tất cả các đƣờng đi từ đồ thị có hƣớng. Ví dụ một số đƣờng trong đồ thị này là:
1. S_ResultStudent submit errorSt
2. S_ResultStudent select_khoahoc KhoaHoc t_stdNameText
StudentName + KhoaHoc Submit ResultStudent.aspx
3. S_ResultStudent select_khoahoc submit errorSt
4. S_ResultStudent t_stdNameText StudentName Submit
errorSt
5. S_ResultStudent t_stdNameText StudentName select_KhoaHoc
StudentName + KhoaHoc Submit ResultStudent.aspx.
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 q 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.
Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn vị có
thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích dữ liệu, đánh giá
mã cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác.
2.3.2. Kiểm thử tích hợp
Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác
minh các giao diện giữa các thành phần xung đột của một thiết kế. Các thành phần
này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng nhau. Thông thƣờng
cách thức này đƣợc coi là một thực hành tốt hơn vì nó cho phép các vấn đề về giao
diện đƣợc định vị một cách nhanh chóng và cố định hơn.
Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và tƣơng
tác giữa các thành phần tích hợp. Các nhóm thành phần đã đƣợc kiểm thử lớn dần
từng bƣớc tƣơng ứng với các thuộc tính của cấu trúc thiết kế đã đƣợc tích hợp và
kiểm thử cho đến khi phần mềm hoạt động nhƣ một hệ thống.
13
2.3.3. Kiểm thử hệ thống
Kiểm thử hệ thống giúp xác minh rằng một hệ thống đƣợc tích hợp có đáp
ứng đầy đủ các u cầu hay khơng. Ngồi ra, kiểm thử phần mềm phải đảm bảo
rằng các chƣơng trình hoạt động nhƣ kỳ vọng, khơng cịn bị phá hủy hay lỗi phần
nào đó trong mơi trƣờng hoạt động của nó hoặc khơng gặp sự cố khi hoạt động với
tiến trình khác (điều này bao gồm bộ nhớ chia sẻ không bị hỏng, nguồn tài nguyên
không bị dƣ thừa hay chiếm dụng quá mức và không bị đẩy ra khi hoạt động song
song các tiến trình).
2.3.4. Kiểm thử chấp nhận
Kiểm thử chấp nhận thƣờng là nghĩa vụ của khách hàng hoặc ngƣời sử dụng
của hệ thống, các chủ sở hữu khác có thể cũng có liên quan. Mục tiêu của Kiểm thử
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ế.
2.4.1. Tổng quan về Selenium
Selenium ra đời năm 2004 bởi Jason Huggin. Ông đã phát triển một thƣ viện
Javascript điều khiển tƣơng tác với các trang, cho phép chạy lại kiểm thử đối với
nhiều trang. Cuối cùng thƣ viện này đã trở thành Selenium – Core nền tảng của các
chức năng Selenium Remote Control (RC) và Selenium IDE. Selenium RC là sự
đột phá vì khơng có sản phẩm nào cho phép bạn kiểm sốt một trình duyệt từ một
ngơn ngữ lập trình.
Năm 2006, Stimon Stewart là một kỹ sƣ tại Google bắt đầu làm việc với một
dự án có tên là Webdriver. Ơng ấy muốn có một cơng cụ kiểm tra trực tiếp với trình
duyệt bằng cách sử dụng phƣơng pháp tự nhiên cho trình duyệt và hệ điều hành do
đó tránh đƣợc hạn chế của Javascript Sandbox.
Năm 2008 đánh dấu sự kết hợp của Selenium và Webdriver. Selenium có
cộng đồng lớn và hỗ trợ thƣơng mại nhƣng Web Driver là một công cụ của tƣơng
lai. Việc kết hợp hai công cụ này cung cấp tập hợp các tính năng chung cho nhiều
ngƣời sử dụng và lợi ích trong tự động hóa kiểm thử.
2.4.2. Selenium-RC (Remote Control)
Selenium-RC cho phép các nhà phát triển tự động hóa kiểm thử sử dụng một
ngơn ngữ lập trình, nó cho tính linh hoạt tối đa và mở rộng trong việc phát triển
lơgic thử nghiệm. Ví dụ, nếu trình ứng dụng trả về một tập kết quả của việc kiểm
tra, và nếu chƣơng trình thử nghiệm tự động cần chạy thử nghiệm trên mỗi phần tử
trong tập hợp kết quả, hỗ trợ lặp đi lặp lại. Các ngơn ngữ lập trình có thể đƣợc sử
dụng để chuyển đổi thông qua việc tập hợp kết quả, kêu gọi Selenium lệnh chạy thử
nghiệm trên mỗi mục.
Selenium-RC cung cấp một API (Application Programming Interface) và
thƣ viện cho mỗi ngôn ngữ đƣợc hỗ trợ: HTML, Java, C #, Perl, PHP, Python, và
Ruby. Khả năng sử dụng Selenium-RC với một ngơn ngữ lập trình bậc cao để phát
triển các trƣờng hợp thử nghiệm cũng cho phép thử nghiệm tự động đƣợc tích hợp
với một dự án xây dựng môi trƣờng tự động.
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
nghĩa vị trí của một element trên Website trong đó có một số cách phổ biến sau:
Theo ID:
// <div id="coolestWidgetEvah">...</div>
WebElement element = driver.findElement(By.id("id_value"));
Theo Class Name:
// <div class="cheese"><span>Cheddar</span></div>
16
// <div class="cheese"><span>Gouda</span></div>
List<WebElement>
driver.findElements(By.className("cheese"));
cheeses
=
Theo Tag Name:
// <iframe src="..."></iframe>
WebElement frame = driver.findElement(By.tagName("iframe"));
Theo Name:
// <input name="cheese" type="text"/>
WebElement cheese = driver.findElement(By.name("cheese"));
Theo Link Text
// <a href=" />WebElement cheese = driver.findElement(By.linkText("cheese"));
2.4.4.4. Điền các giá trị vào trang Web qua Selenium-Webdriver
Sau khi định vị đƣợc các thành phần trên một Website và ánh xạ chúng với
các WebElement, chúng ta có thể thay đổi giá trị hoặc thực hiện các thao tác chuột
cũng nhƣ các thao tác gõ chữ lên WebElement đó thơng qua các phƣơng thức.
// Find the text input element by its name
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
