ĐẠ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: https://github.com/phuongdt/auto-project.git

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

Cần 14 manday để chạy test

2-3 manday

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