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 Ngành: Công nghệ thông tin Chuyên ng

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

TÓM TẮT LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội – Năm 2015

MỤC LỤC

MỤC LỤC 1

Chương 1: TỔNG QUAN VỀ BDD - CUCUMBER - SELENIUM - PAGE OBJECT 3 1.1 Tổng quan về kiểm thử phần mềm 3

1.2 TDD (Test Driven Development) 3

1.2.1 TDD là gì? 3

1.2.2 Ba điều luật khi áp dụng TDD 3

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

1.2.4 Các cấp độ TDD 4

1.3 BDD (Behaviour Driven Development) 5

1.3.1 Khái niệm 5

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

1.3.3 Quy trình phát triển theo hướng BDD 6

1.4 Cucumber 6

1.4.1 Khái niệm 6

1.4.2 Ngôn ngữ Gherkin 7

1.4.3 Chạy một Cucumber Junit test 7

1.4.4 Chu trình 7

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

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

1.4.7 Các thư viện cần thiết để chạy Cucumber 9

1.5 Selenium WebDriver 9

1.5.1 Selenium WebDriver là gì 9

1.5.2 Tổng quan về đối tượng UI (Locators) 9

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

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

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

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

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

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

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

1.5.4 Các hàm xử lý chung trong Selenium WebDriver 12

1.6 Page Object Model (POM) 13

1.6.1 Tại sao phải dùng POM 13

1.6.2 Page Object là gì? 13

1.6.3 Lợi ích của Page Object 13

Chương 2: HỆ THỐNG QUẢN LÝ TESTCASE – TESTLINK VÀ HỆ THỐNG TÍCH HỢP LIÊN TỤC 14

2.1 Hệ thống quản lý testcase - TestLink 14

2.1.1 Giới thiệu về TestLink 14

2.1.2 Lợi ích của TestLink 14

2.1.3 Các bước cài đặt TestLink 14

2.1.4 Kết hợp TestLink và kiểm thử tự động 14

2.2 Hệ thống tích hợp liên tục (CI) 15

2.2.1 Khái niệm 15

2.2.2 Thực tiễn hệ thống tích hợp liên tục (Practices of Continuous Integration) 16 2.2.3 Lợi ích của việc tích hợp liên tục 16

2.2.4 Jenkin 17

Chương 3: ÁP DỤNG KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY EXOPLATFORM SEA VÀ ĐÁNH GIÁ KẾT QUẢ 18

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 18

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 18

3.1.2 Quy trình kiểm thử và hoạt động kiểm thử trước đây 18

3.2 Cài đặt và áp dụng kiểm thử tự động trong quá trình phát triển 19

3.2.1 Cấu trúc dự án 19

3.2.2 Cấu trúc mã nguồn 20

3.2.3 Tích hợp Jenkins 20

3.2.4 Report kết quả chạy test 21

3.3 Đánh giá kết quả 22

3.4 Những khó khăn khi triển khai hệ thống kiểm thử tự động trong công ty 22 3.5 Hướng phát triển tiếp theo của framework 22

KẾT LUẬN 23

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

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)

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

Hình 1.2 Các bước thực hiện TDD

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

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

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

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

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

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.3 Chạy một Cucumber Junit test

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)

● Định nghĩa các step

● 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

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

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

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

1.5.4 Các hàm xử lý chung trong Selenium WebDriver

● Locate element sử dụng WebDriver

By.className value của class attribute findElement(By.className("someClassName")) By.cssSelector locator bằng css findElement(By.cssSelector("input#email")) By.id value của id attribute findElement(By.id("someId"))

By.linkText locator bằng value findElement(By.linkText("REGISTRATION")) By.tagName name của tag findElement(By.tagName("div"))

By.xpath locator bằng xpath findElement(By.xpath("//html/body/div")

By.name value của name attribute findElement(By.name("someName"))

● Các hàm hay sử dụng

init webdriver WebDriver driver = new FirefoxDriver();

open url driver.get(baseUrl);

init webelement WebElement

element=driver.findElement(By.className("someClassName"))

click an element driver.findElement(By.className("someClassName")).click()

type text to textbox driver.findElement(By.className("someClassName")).sendkey(“test”)

refresh current page driver.navigate().refresh()

back page driver.navigate().back()

forward page driver.navigate().forward()

close browser driver.close() or driver.quit()

pause Thread.sleep(5000);

1.6 Page Object Model (POM)

1.6.1 Tại sao phải dùng POM

Page Object Model (POM) làm cho mã nguồn dễ đọc hơn, dễ bảo trì hơn và dễ sử dụng lại hơn

Hình 1.12 Cấu trúc POM

1.6.2 Page Object là gì?

● POM là một mẫu thiết kế (Design Pattern) có các đặc điểm sau:

○ Tạo Kho đối tượng (object repository) cho các phần tử giao diện của web (UI elements)

○ Dưới mô hình này, mỗi trang web trong ứng dụng đang viết có thể tương ứng với một lớp

○ Lớp này sẽ tìm kiếm tất cả phần tử của web (WebElements) và chỉ chứa các phương thức để thực hiện thao tác trên các phần tử của trang web đó

○ Các phương thức này nên được đặt tên như là nhiệm vụ (task) mà chúng sẽ thực hiện Nó rất dễ dàng ánh xạ với các hành động (actions) xảy ra trong giao diện với người dùng Ví dụ, Nếu muốn nhập user cho textbox user trên một trang, tên phương thức đó có thể là “setUserName”

1.6.3 Lợi ích của Page Object

● Làm cho code trở nên rõ ràng và dễ hiểu hơn, nó tránh sự lặp lại nhiều lần trong code Do

đó, Mô hình này sẽ trở nên dễ dàng hơn trong việc bảo trì và tái sử dụng

● Các kho lưu trữ là độc lập với các kịch bản test Vì vậy, chúng ta có thể sử các kho lưu trữ giống nhau cho các mục đích khác nhau với những tool khác nhau Ví dụ, chũng ta có thể tích hợp POM với TestNG cho việc test chức năng hay Cucumber cho Acceptance Test (Kiểm thử chấp nhận)

Chương 2: HỆ THỐNG QUẢN LÝ TESTCASE – TESTLINK VÀ HỆ THỐNG TÍCH HỢP LIÊN TỤC

2.1 Hệ thống quản lý testcase - TestLink

2.1.1 Giới thiệu về TestLink

● Testlink là công cụ quản lý test case được sử dụng rộng rãi dựa trên mã nguồn mở Nó kết hợp đồng thời cả hai requirements specification và Test specification Công cụ này hỗ trợ người dùng tạo một test project và các kịch bản kiểm thử Ta có thể tạo tài khoản cho nhiều người dùng và assign những quyền người dùng khác nhau

● Testlink hỗ trợ cả hai thực hiện test case bằng tay và tự động thực thi test case

● Với tool này thì người kiểm thử có thể sử dụng để xuất ra file test report và tài liệu Test plan trong 1 phút Nó hỗ trợ xuất ra file Test report của MS Word, Excel, HTML formats

2.1.2 Lợi ích của TestLink

● Hỗ trợ nhiều project

● Dễ dàng import hoặc export test case

● Dễ dàng tích hợp với nhiều tool quản lý defect

● Tự động thực hiện test case thông qua XML-RPC

● Dễ dàng lọc test case theo keywords, version và testcase ID

● Dễ dàng để assign test case tới nhiều user

● Dễ dàng xuất ra test plan, test report

Hình 2.1 Giới thiệu về TestLink

2.1.3 Các bước cài đặt TestLink

● Xem thêm trong phụ lục 5 (Cài đặt môi trường) - Cài đặt công cụ quản lý test case - TestLink)

2.1.4 Kết hợp TestLink và kiểm thử tự động

● Để selenium giao tiếp được với TestLink, TestLink cung cấp chức năng giúp người dùng tạo

ra một API key cho phép người dùng xác thực quyền được truy cập vào TestLink

● Sau khi thực hiện chạy test bằng selenium/cucumber, ta có thể cập nhật kết quả chạy test vào TestLink với hàm sau:

Hình 2.2 Báo cáo trong TestLink

2.2 Hệ thống tích hợp liên tục (CI)

2.2.1 Khái niệm

● Tích hợp liên tục là một hoạt động phát triển phần mềm mà ở đó các thành viên của một nhóm tích hợp công việc của họ với nhau liên tục, thường thì các thành viên tích hợp công việc theo từng ngày, dẫn đến có nhiều sự tích hợp trong ngày Mỗi sự tích hợp như vậy sẽ được kiểm tra bởi một công cụ build tự động (bao gồm test) để phát hiện ra những lỗi tích hợp càng sớm càng tốt

● Hiểu đơn giản, tích hợp liên tục gồm 4 bước

Hình 2.3 Quá trình tích hợp liên tục CI

● Dưới đây là một hệ thống tích hợp liên tục

Hình 2.4 Hệ thống tích hợp liên tục

2.2.2 Thực tiễn hệ thống tích hợp liên tục (Practices of Continuous Integration)

● Quản lý source code

● Tự động hóa quy trình build

○ Quá trình build được thực hiện tự động bằng các đoạn script cài sẵn

○ Thực hiện thường xuyên

○ Tạo ra các script khác nhau để có thể chạy trên nhiều môi trường khác nhau

○ Công cụ: Ant, Maven

● Tạo bản build bao gồm test

○ Chèn các test vào chương trình

○ Nhận dạng source code có khả năng phát sinh lỗi (test code)

○ Công cụ: JUnit, HtmlUnit

● Commit những thay đổi mỗi ngày

● Lấy source code về nơi lưu trữ (mainline)

● Mỗi khi code có thay đổi sẽ build lại (mainline) thông qua build server

● Kiểm thử tự động

○ Được thực hiện bằng các đoạn script viết sẵn

○ Thực hiện sau khi build xong

○ Thực hiện trong quá trình developer build trên máy của họ hoặc vào lúc CI server build mainline

● Báo cáo kết quả cho lập trình viên hoặc những thành viên liên quan

2.2.3 Lợi ích của việc tích hợp liên tục

● Giảm thiểu rủi ro

● Dễ lập kế hoạch

● Dễ dàng phát hiện và loại bỏ lỗi

● Nhận được phản hồi nhanh