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

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ử

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

VIỆN CÔNG NGHỆ THÔNG TIN

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

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

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

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

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

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

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

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

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

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

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

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)

● Đư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

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

○ 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

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

● 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

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 http://agiledata.org/essays/tdd.html)

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

Hình 1.5 Quy trình phát triển truyền thống (Từ trang 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))

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

● 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

○ | (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)

● Chạy test và xem test fail

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

● 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

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

Hình 1.8 Workflow trong Cucumber

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

● 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 …)

● 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)

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

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

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

1.5.2.4 Xác định phần tử Web theo TagName

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

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

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

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

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

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

● Absolute XPath (XPath tuyệt đối)

○ Bắt đầu với node gốc hoặc dấu „/‟

○ Ưu điểm: tìm element nhanh

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

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

○ Khi có thêm một tag giữa body và divà xpath sẽ không tìm được element

html/body/table/div/form/select/option

● Relative XPath (XPath tương đối)

○ Có thể bắt đầu ở bất kỳ node nào với dấu „//‟

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

○ Nhược điểm: tìm element lâu hơn xpath tuyệt đối

○ Ví dụ: //select/option

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

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

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

input[@id='searchInput']

contains Lấy element với

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

tagName[contains(@attribute,„value‟)]

input[contains(@id, 'searchInput')]

starts-with Lấy element với

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

with(@attribute,„value‟)]

tagName[starts-with(@id, 's')]

input[starts-and Kết hợp toán tử AND

với nhiều điều kiện

để lấy element

tag[@attribute=„value' and @attribute=„value']

input[@type='search' and

| @type='submit'] position() Lấy element theo tag[index] option[1]

(index) index tag[position()=index] option[position()=1] text() Lấy element theo

Lấy element cha html/body/div/form/input/

html/body/div/form/input/

1.5.3 Các thư viện cần thiết để chạy Selenium WebDriver

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

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

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