Tóm tắt Luận án - 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

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.