DSpace at VNU: 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 Dang Thi Phuong

ĐẠ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.2. Ngôn ngữ Gherkin
●
●

Cucumber thực thi các .feature file. Các feature files chứa các đặc tả (step) thực thi, các
step này được viết bằng ngôn ngữ Gherkin
Gherkin là 1 ngôn ngữ mà Cucumber đọc ngôn ngữ ấy chuyển thành test. Gherkin khá dễ
hiểu, người đọc có thể hiểu kịch bản và hành động mà không cần biết chi tiết chúng được
cài đặt như thế nào

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


2.2.4. Jenkin
●

●

Jenkins là một công cụ đại diện cho khái niệm CI (continuous integration).
Jenkins cung cấp 1 giao diện trực quan hơn, percentage, graph, coverage report, code
convention checking ,v.v….. hoàn toàn tự động, có thể wake up theo svn hoặc git. Jenkins
cũng có rất nhiều plugin và support hầu hết các test framework.

Hình 2.5. Giao diện Jenkins


Chương 3: ÁP DỤNG KIỂM THỬ TỰ ĐỘNG TẠI CÔNG TY EXOPLATFORM SEA VÀ
ĐÁNH GIÁ KẾT QUẢ
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
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
●

●

●

eXo Platform là một công ty phần mềm cung cấp một Platform bao gồm nhiều ứng dụng
dành cho doanh nghiệp, như Quản Lý Hồ Sơ Cá Nhân, Lưu Trữ và Chia Sẻ Tài Liệu
(ECMS), Calendar, (Social), Wiki, Forums, FAQs, Answer, Chat, Video call … Công ty
liên tục phát triển những feature mới để phục vụ cho các yêu cầu và xu hướng của khách
hàng. Sản phẩm của công ty là ứng dụng web, chạy trên nhiểu môi trường khác nhau
(windows, Ubuntu, Android, IOS …)
Hàng năm, công ty luôn có kế hoạch cải tiến sản phẩm và feature hiện tại đồng thời tạo ra
các sản phẩm và feature mới. Mỗi khi một sản phẩm hay feature mới nào được xuất bản ra
ngoài thị trường, sản phẩm và feature đó và những sản phẩm và feature cũ đều phải được
tiến hành kiểm thử trên các môi trường mà sản phẩm đó hỗ trợ.

Các ứng dụng được phát triển và cài đặt trên các môi trường khác nhau
○ Hệ điều hành: Windows, Ubuntu, Android, IOS …
○ Browser: IE, Firefox, Chrome …
○ Database: MySQL, HSQL, Oracle, PSQL …
○ Triển khai sản phẩm: Tomcat, Jboss, Cloud, Cluster …

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

Các giai đoạn cần kiểm thử sản phẩm:

○ Số lượng kịch bản kiểm thử cho mỗi ứng dụng (như ECMS, Calendar, Wiki, Forums,
FAQ …) có thể giao động từ 100 đến khoàng 1000 trường hợp kiểm thử cho mỗi môi
trường. Dưới đây là một số thống kê về số lượng kịch bản kiểm thử của một vài chức
năng trong hệ thống. Số lượng này tính theo một môi trường (Ví dụ: môi trường
Ubuntu+Firefox+MySQL+Tomcat)
Feature

Số lượng testcase

Wiki

342

Gatein

235

PLF

795

Forum

283

ECMS

1132

Calendar

455

Social

620


●

●

●

●

Để kiểm thử cho tất cả ứng dụng, hệ điều hành, trình duyệt và cơ sở dữ liệu khác nhau, số
lượng kịch bản kiểm thử sẽ rất lớn. Bên cạnh đó các feature mới cũng phải tiến hành kiểm
thử song song với các feature cũ. Có thể thấy nguồn lực cho kiểm thử hồi quy (Regression

test) và các kiểm thử cho feature mới sẽ rất lớn.
Ngoài ra, công ty cũng sử dụng CI để deploy sản phẩm hàng ngày. Để có thể phát hiện ra
sớm những vấn để của sản phẩm, kiểm thử tự động cũng sẽ được tích hợp CI để test
những sản phẩm hàng ngày đó.
Từ những lợi ích của BDD-Cucumber-Selenium-TestLink-CI, tôi và các bạn đồng nghiệp
đã xây dựng Framework tích hợp điểm mạnh của BDD-Cucumber-Selenium-TestLink-CI
để hỗ trợ quá trình kiểm thử, build dự án, phát hành sản phẩm với chất lượng tốt hơn.
Dưới đây là kết quả cài đặt, chạy thử và đánh giá kết quả của framework. Do quy định về
luật bảo mật của dự án và quy định vê luật bảo mật của công ty, tôi sẽ không sử dụng mã
nguồn chi tiết trong dự án đang triển khai ở công ty mà sẽ sử dụng mã nguồn tôi viết để
kiểm thử một trang web application (live.guru99.com). Tuy nhiên cấu trúc dự án, cấu trúc
mã nguồn và kết quả đánh giá sẽ dựa vào dự án thực tế tôi đang triển khai.

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

Hình 3.1. Cấu trúc dự án thực tế


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

Hình 3.2. Cấu trúc mã nguồn cài đặt thực tế
●

Mã nguồn của dự án: />
3.2.3. Tích hợp Jenkins
Dự án có sử dụng Maven để chạy test tích hợp giữa Selenium/Cucumber và Jenkins và
TestLink

3.2.4. Report kết quả chạy test
●

Cucumber report

Hình 3.3. Cucumber Report
●

Thucydides report

Hình 3.4. Thucydides report


●

TestLink report

Hình 3.5.TestLink report
3.3. Đánh giá kết quả
●
●

Hiện tại chúng tôi đã viết kịch bản kiểm thử cho khoảng 50% số lượng kịch bản kiểm thử
và đã áp dụng chạy thử cho một vài giai đoạn kiểm thử.
Dưới đây là bảng thống kê nguồn nhân lực

Số lượng testcase

Kiểm thử thủ công

Kiểm thử tự động

820

60 cases/manday

2-3 manday

 Cần 14 manday để chạy test
●

Từ kết quả trên ta thấy kiểm thử tự động đã giúp giảm bớt nguồn nhân lực trong quá trình
kiểm thử.

3.4. Những khó khăn khi triển khai hệ thống kiểm thử tự động trong công ty
●

●
●

●

Việc tìm nhân lực vừa có kỹ năng kiểm thử vừa có kỹ năng lập trình gặp khó khăn bởi
nhiều bạn nhân viên kiểm thử có kỹ năng kiểm thử tốt nhưng tư duy lập trình không tốt,
các bạn có kỹ năng lập trình tốt thì không muốn làm kiểm thử
Khi một feature có nhiều sự thay đổi về cách tổ chức UI thì mất nhiều thời gian để
maintain mã nguồn của framework.
Kiểm thử tự động sẽ chỉ có hiệu quả cao nhất đối với dự án dài, có regression test nhiều.
Các dự án ngắn, đòi hỏi release sớm thì việc triển khai kiểm thử tự động sẽ không hiệu
quả

Hệ thống hiện tại đang chạy ổn định trên firefox và chrome, vẫn còn một số lỗi khi chạy trên
IE do việc xử lý trên IE và Firefox có một số điểm khác nhau.

3.5. Hướng phát triển tiếp theo của framework
●

●

Xây dựng thêm phần DataDriven trong framework. DataDriven giúp cho hệ thống có thể
đọc được dữ liệu đầu vào từ hệ thống quản lý file hoặc từ một hệ quản trị cơ sở dữ liệu bất
kỳ
Cải tiến framework để hỗ trợ cho các bạn kiểm thử không có kỹ năng lập trình có thể sử
dụng dễ dàng hơn.


KẾT LUẬN
Trong quá trình tìm hiểu và nghiên cứu, luận văn đã đưa ra những khái niệm và hướng áp
dụng của Selenium và các công cụ liên quan khác trong kiểm thử phần mềm. Dựa vào kết quả nghiên
cứu và áp dụng kiểm thử tự động tại công ty Exo Platform Sea, tôi thấy rằng việc ứng dụng selenium
và các công cụ liên quan trong các dự án phần mềm là hoàn toàn khả thi. Do thời gian có hạn, tôi chỉ
đưa ra một framework cơ bản nhất để có thể áp dụng và chạy thử nghiệm luôn, framework vẫn còn
nhiều phần cần phải cải tiến và cập nhật thêm (ví dụ: DataDriven, Dynamic Locator, tốc độ chạy các
kịch bản kiểm thử, tích hợp thành cloud test). Việc cải tiến framework sẽ được nghiên cứu và cập nhật
trong thời gian tới.